UML Forum
All Things related to UML 2

UML FAQ: Frequently Asked Questions about UML

The UML FAQ answers frequently asked questions about the Unified Modeling Language (UML), the industry standard visual architecture modeling language for software-intensive systems.

General Questions

UML FAQ: What is the Unified Modeling Language (UML)?

The Unified Modeling Language (UML) is a general-purpose architecture modeling language for visually specifying software-intensive systems. More precisely, it is a graphical language for visualizing, specifying, constructing and documenting the artifacts of software-intensive systems. UML is a key enabling technology for Software Developers and Software Engineers who seek to transition from traditional, human-intensive, code-centric software development processes to Model-Driven Development (MDD) processes that are requirements-driven and architecture-centric.
UML 2 & Visual Modeling Language Evolution

UML 2 & Visual Modeling Language Evolution

Reproduced by Permission © 2003-2012 PivotPoint Technology Corp.





The UML was originally derived from the object modeling languages of three leading object-oriented methods: Booch, Object Modeling Technique (OMT) and Object-Oriented Software Engineering (OOSE). It was first added to the list of Object Management Group (OMG) adopted technologies in 1997, and has since become the industry standard for modeling software-intensive systems. The UML specification is an open standard that is publicly available for download. The most recent revision is UML v. 2.1.4. (See UML Specifications.)

UML 2 Diagram Taxonomy

UML 2 Diagram Taxonomy

Reproduced by Permission © 2003-2012 PivotPoint Technology Corp.



UML FAQ: Why use UML?

If you are a Software Developer and want to improve the precision and efficiency of your communications with fellow Software Developers and other system and business stakeholders, then UML is an excellent choice for a lingua franca. (If on the other hand, you are a Systems Engineer or a Business Analyst who wants to improve communications with your peers and other system stakeholders, then SysML or BPMN may be better choices.) Here's a list of reasons why Software Developers may want to use UML and either an Agile Modeling or Model-Driven Development process for their work:
  • Facilitate communication among various stakeholders across the System Development Life Cycle
  • Capture and manage corporate Intellectual Property related to system architectures, designs, and processes
  • Compare and contrast “As Is” and “To Be” solutions
  • Provide scalable structure for problem solving
  • Furnish rich abstractions to manage size and complexity
  • Explore multiple solutions or ideas concurrently with minimal risk
  • Detect errors and omissions early in System Development Life Cycle

UML FAQ: Who created UML and how did it get its name?

The short answer is that the Unified Modeling Language (UML) originated from the fusion of the three leading object methods of the early 1990's: Grady Booch's Booch Method, James Rumbaugh's Object Modeling Technique, and Ivar Jacobson's Objectory method.

However, a longer and more accurate answer follows. James Rumbaugh, the primary methodologist for the Object Modeling Technique (OMT) method, joined Grady Booch, the Chief Scientist at Rational Software who authored the Booch Method, at Rational Software in 1994. At Rational Software Booch and Rumbaugh collaborated on the Unified Method v. 0.8, which combined their object modeling method notations and was released at the Object-Oriented Programming and LAnguages (OOPSLA) conference in 1995. After realizing that the problem of unifying their object modeling notations was more tractable than unifying their methods, Booch and Rumbaugh were joined by Ivar Jacobson, the primary methodologist for the Objectory method, at Rational Software at 1995. These three object modeling methodologists, were collectively referred to as the "Three Amigos".


Seeing the business opportunity to exploit UML standardization leadership to further its marketing strategy for Rational Rose and other software development tools, Rational organized the UML Partners consortium in 1996 to respond to the OMG's RFP for object modeling tool interoperability. The original UML Partners consortium consisted of a strategic mix of software tool vendors and systems integrators, including Rational Software Corporation, Microsoft, Hewlett-Packard, Oracle, Texas Instruments, MCI Systemhouse, Unisys, ICON Computing, and Intellicorp. At first the Three Amigos functioned as technical co-chairs and Ed Eykholt, a Rational employee, was the project leader. The UML Partners' UML 1.0 specification draft was proposed to the Object Management Group (OMG) in January 1997, but its semantics were considered inadequate for OMG adoption. Consequently, the Three Amigos asked Cris Kobryn, who was then a Chief Scientist at MCI Systemhouse with expertise in AI linguistics and formal languages, to chair a UML Semantic Task Force to finalize UML semantics and integrate them with related OMG standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and was formally adopted by the OMG in November 1997.

UML2 Postscript: Kobryn went on to chair the UML Revision Task Force that specified the UML 1.2-1.4 minor revisions (1997-2002). During 2000-2003 he organized and chaired the UML2 Partners consortium, which successfully specified a UML 2.0 major revision that was formally adopted by the OMG in 2003. During 2003-2006 Kobryn chaired the SysML open source specification project, which specified the Systems Modeling Language (SysML) dialect of UML for Systems Engineering applications.

UML FAQ: What is Agile Modeling?

Agile Modeling is a Model-Based Engineering subdiscipline that specializes in the use of visual modeling techniques, typically using UML diagrams, to supplement Agile Software development methods (e.g., Scrum). In contrast to Model-Driven Development methods that emphasize heavyweight modeling techniques (e.g., Round-Trip Engineering, where model = software code), Agile Modeling techniques tend to be less rigorous (e.g., “UMLasSketch”).

For more information about Agile Modeling and Model-Driven Development check out the Model-Based Engineering Forum.

UML FAQ: What is Model-Driven Development (MDD)?

Model-Driven Development (MDD), a.k.a. Model-Driven Software Engineering (MDSE), is a software development paradigm that emphasizes the use of rigorous visual modeling techniques throughout the Software Development Life Cycle (SDLC). MDD is a subdiscipline of the Model-Based Engineering paradigm that promotes the use of open standards for visual modeling (e.g., UML2, BPMN, SysML, ArchiMate), and encourages the integration of visual modeling and traditional Software Development best practices, including Agile Development.

For more information about Model-Driven Development and related Model-Based Engineering subdisciplines check out the Model-Based Engineering Forum.

UML FAQ: What is the relationship between UML and Model-Driven Development (MDD)?

A recommended best practice for any Model-Driven Development (MDD) approach is the synergistic application of Model-Based Languages, Model-Based Tools, Model-Based Processes, and Model-Based Architecture Frameworks.

System Architecture Tetrad

System Architecture Tetrad


Reproduced by Permission © 2003-2015 PivotPoint Technology Corp.



As an open standard Architecture Description Language (ADL) for software-intensive applications, UML is the Model-Based Language of choice for many MDD endeavors. However, if you don't choose and apply the other key enabling MDD technologies properly (Modeling Tools, Model-Based Processes, and Architecture Frameworks) your MDD project will likely achieve poor or mixed results.

UML FAQ: What is the relationship between MDD and other similar Model-Driven/Model-Based acronym expressions (MBSE, MDSE, MDE, MDA, MBE, MBSD)?

Model-Driven Development (MDD) is frequently confused with several other acronym expressions that begin with either "Model-Based" or "Model-Driven". The short answer is that Model-Driven Development is a subdiscipline of the more generic Model-Based Engineering system development paradigm. MBE is a system development paradigm that emphasizes the use of rigorous visual modeling techniques throughout the System Development Life Cycle (SDLC); MDD is a specialization of MBE that applies MBE principles and best practices to Software Engineering applications.

For a longer and more thorough explanation of the relationships among Model-Driven Development, Model-Based Engineering, and related MBE subdisciplines check out the Model-Based Engineering Forum and the Model-Based Engineering Visual Glossary.

UML FAQ: What is the relationship between UML and SysML?

SysML is defined as a dialect (Profile) of UML 2.x, the industry standard modeling language for software-intensive applications. The advantage of defining SysML as a UML Profile is that it can reuse the relatively mature notation and semantics of UML 2.x, which many modeling tool vendors have already implemented. The disadvantage of specifying SysML as a UML Profile is that SysML inherits many of the problems associated with UML 2.x, such as gratuitously complex notation, imprecise semantics, and a dysfunctional diagram interoperability standard (XMI).

Relationship between SysML & UML

Relationship between SysML & UML

Reproduced by Permission © 2003-2013 PivotPoint Technology Corp.





SysML offers systems engineers the following advantages over UML for specifying systems and systems-of-systems:
• SysML expresses systems engineering semantics (interpretations of notations) better than than UML. It reduces UML's software bias and adds two new diagram types for requirements management and performance analysis: Requirement diagrams and Parametric diagrams, respectively.
• SysML is smaller and easier to learn than UML. Since SysML removes many software-centric and gratuitous constructs, the overall language is smaller as measured in diagram types (9 vs. 13) and total constructs.
• SysML model management constructs support the specification of models, views, and viewpoints that are architecturally aligned with IEEE-Std-1471-2000 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems).
The following table compares SysML diagrams with their UML counterparts where one exists. Where no UML diagram counterpart exists for a SysML diagram (e.g., Parametric and Requirement diagrams), it is marked N/A; similarly, where no SysML diagram counterpart exists for UML diagram it is marked N/A (e.g., Communication diagram).

UML FAQ: What is the current version of UML?

The current version of the OMG UML specification is UML v. 2.4.1, which is available from the UML Specifications page of this web or can be downloaded from the OMG web.

UML FAQ: What changes were made in UML 2.0, the last major revision of UML?

Noteworthy changes made in the UML 2.0 major revision include:
  • Hierarchical decomposition of structures and support for component-based development. UML 2 introduces a major new diagram type, Composite Structure diagrams, that includes new constructs (Parts, Ports and Connectors) which allow you to recursively decompose a a system-of-systems into systems, subsystems, components, sub-components, etc.
  • Hierarchical decomposition of behavior. UML 2 enhances Activity and Sequence diagrams so that you can recursively decompose behaviors into sub-behaviors. For example, you can decompose Action Nodes into sub-Action Nodes, sub-sub-Action Nodes, etc.
  • Improved integration between structural and behavioral constructs. When properly applied UML 2 Parts allow you to seamlessly integrates structural and behavioral diagrams. For example, the same EFI Part in a Composite Structure diagram for an Engine might also be reused for a swimlane partition in an Activity diagram for the Activate Cruise Control process.
  • Enhanced support for executable models. UML 2 includes a fully integrated Action Semantics that enables executable models capable of driving simulations and automatically generating programming code.

UML FAQ: What is new in UML v. 2.4?

Although the improvements to UML in the UML 2.0 major revision were substantive (see UML FAQ: What changes were made in UML 2.0?), from an end user perspective changes in subsequent minor revisions, including UML 2.4, have been insignificant and largely relegated to editorial corrections and clarifications.

UML FAQ: What is new in UML v. 2.5 Beta?

Although OMG tried to hype UML v. 2.5 Beta as a significant milestone in the evolution of the language in a 2012 press release celebrating the 15th anniversary of UML adoption, the technical reality is this yet another “dot release” of the UML 2.0 major revision proposal that was first adopted by the OMG in 2003, and has been subsequently been patched by a long series of minor revisions.

While UML 2.5 Beta purports to simplify and clarify the UML 2.x specification, the vast majority of its clean up work is relevant to tool vendors rather than UML modelers. Unfortunately, UML 2.5 Beta fails to address the major shortcomings of the UML 2 series that make it problematic to apply as an architectural modeling language for Agile Architecture & Design purposes. Consequently, it shouldn’t be surprising that the reception to UML 2.5 Beta has been generally negative, ranging from blasé to scathing. (See Scott Ambler’s UML 2.5: Do You Even Care? article.)

What the UML user community really needs, of course, is a bona fide major revision (UML 3.0) that addresses Agile Architecture & Design needs, rather than yet another “dot release” patch for a bloated and flawed UML 2.x. Unfortunately, UML 2.5 remains in Beta, and the OMG has not yet announced a public roadmap for either finalizing UML 2.5 or working on a badly needed UML 3.0 major revision.
The Object Management Group (OMG) has adopted and maintains the Unified Modeling Language (UML) specification. As with any OMG specification, minor revisions to UML are effected by Revision Task Forces (RTFs) and major revisions are effected by Requests for Proposals (RFPs). For more details regarding the OMG revision processes see the the OMG web.

UML FAQ: What are the pros & cons of UML 2 as a visual architecture modeling language for software-intensive systems?

When used by skilled Software Architects and Designers who have mastered its complex syntax and semantics, UML 2 is an effective architecture modeling language for specifying large, complex software-intensive systems. However, UML 2 doesn’t address the urgent needs of Agile developers who are wary of entrapment by BUFD (Big Up Front Design) methods and who seek an architecture modeling language that is easier to learn and master.

The following are some constructive recommendations for improving UML in its next major revision (UML 3.0) so that it will better meet the needs of Agile Architects and Designers.
  • GENERAL ISSUES
    • Language bloat.
      UML 2.x is that it is gratuitously large and complex. Although the UML 2.0 proposal was reasonably layered when it was proposed to the OMG and initially adopted in 2003, somehow its layering was lost in the OMG’s byzantine finalization process.
      • Recommendations: Refactor UML into three common usage layers (e.g., Agile, Intermediate, Executable), define appropriate compliance points, and enforce compliance via a reference implementation and test suites.
    • Voodoo Semantics for Behavioral Constructs.
      in general, UML 2.x semantics are ambiguous and imprecise. This is especially true to UML 2’s executable semantics for driving simulations and generating executable code.
      • Recommendations: Architecturally align all major behavioral diagram types (Activities, Sequences, State Machines) to shore common elements for behavioral simulations and code generation.
    • Dysfunctional interoperability.
      UML 2.x interoperability, like UML 1.y interoperability before it, is a sham based on a poorly designed model interchange standard called XMI.
      • Recommendations: Define full interoperability standards for common usage layers, define appropriate compliance points, and enforce compliance via a reference implementation and test suites.
    • Lack of a clear, concise glossary.
      Although the UML 2.0 proposal included a draft glossary when it was proposed to the OMG and initially adopted in 2003, somehow the glossary work was never completed and became lost in the OMG’s byzantine finalization process.
      • Recommendations: Define clear, concise glossary of UML 2 terms that are used consistently by the UML 2 specification.
  • SPECIFIC ISSUES
    • Remove the syntactic and semantic overlap between Composite Structure and Component diagrams
    • Provide a standard Model Library to support Service-Oriented Architectures (SOA) and its variants (SaaS, PaaS, IaaS).
    • Provide a standard Model Library to support Network Architectures and Cybersecurity Frameworks.
    • Provide a standard Model Library to support Cybersecurity Frameworks.

UML FAQ: What is the best way to learn UML?

Learning any new language is challenging, whether it is a natural language (e.g., Japanese, Swahili, English) or an artificial language, such as UML. Since UML 2 is a bon fide architectural modeling language and a major improvement over the shortcomings of UML 1.x, mastering its syntax and semantics can be as challenging as learning a programming language. if you have only dabbled with UML 1 and have succumbed to UML 1 worst practices (e.g., Use Case Abuse), your previous bad exposure to UML 1 may be a liability rather than an asset!

In order to increase your likelihood of achieving UML language fluency, you may want to consider a multi-pronged approach to learning UML. For example, if you have the opportunity you may want to start off with basic UML hands-on training, followed up by expert coaching (mentoring) for On-the-Job (OTJ) training, which in turn is followed up with advanced UML hands-on training. For the best learning experience, ensure that all your UML training is taught by expert practitioners with extensive application experience on large projects, and includes frequent hands-on practice sessions and Q&A sessions.

In addition, you should also also read voraciously about UML techniques and best practices, so that you can further benefit from the experience (and mistakes) of others.

You can find a listing of selected UML training resources on the UML Training page of this web.

You can find a listing of selected UML tutorials on the UML Tutorials page of this web.

You can find a listing of selected UML publications (including books, papers, and articles) on the UML Publications page of this web.

UML FAQ: How can I report a UML issue or make a UML change request?

The OMG UML v 2.6 Revision Task Force (RTF) is working on proposed improvements to UML based on feedback from the UML tool vendor and user communities. The OMG UML 2 RTF's Issue List (http://www.omg.org/issues/uml2-rtf.open.html) is public and is organized into open and closed issues. You can comment on any open issue by sending email to uml2-rtf@omg.org. In addition you can submit new issues, including change requests, by sending email to issues@omg.org.
Please email your questions using the Contact page.

UML Tools & Interoperability

You can find selected lists of both Commercial-Off-the-Shelf (COTS) UML tools and Free & Open Source Software (FOSS) UML tools on the UML.Tools web, which features editor and user reviews of popular UML modeling tools.
You can find general recommendations for selecting a UML modeling tool in the How to Select a UML Modeling Tool for Agile Modeling or MDD article.

UNIFIED MODELING LANGUAGE and UML are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.