The Unified Modeling Language
The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for
- modeling business and similar processes,
- analysis, design, and implementation of software-based systems
UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.
UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace, healthcare, etc.) It can be used with all major object and component software development methods and for various implementation platforms (e.g., J2EE, .NET).
UML is a standard modeling language, not a software development process. UML 1.4.2 Specification explained that process:
- provides guidance as to the order of a team’s activities,
- specifies what artifacts should be developed,
- directs the tasks of individual developers and the team as a whole, and
- offers criteria for monitoring and measuring a project’s products and activities.
UML is intentionally process independent and could be applied in the context of different processes. Still, it is most suitable for use case driven, iterative and incremental development processes. An example of such process is Rational Unified Process (RUP).
UML is not complete and it is not completely visual. Given some UML diagram, we can't be sure to understand depicted part or behavior of the system from the diagram alone. Some information could be intentionally omitted from the diagram, some information represented on the diagram could have different interpretations, and some concepts of UML have no graphical notation at all, so there is no way to depict those on diagrams.
For example, semantics of multiplicity of actors and multiplicity of use cases on use case diagrams is not defined precisely in the UML specification and could mean either concurrent or successive usage of use cases.
Name of an abstract classifier is shown in italics while final classifier has no specific graphical notation, so there is no way to determine whether classifier is final or not from the diagram.
Versions of UML
The current version of the Unified Modeling Language™ is UML 2.5, released in June 2015 [UML 2.5 Specification]. UML® specification (standard) is updated and managed by the Object Management Group (OMG™) OMG UML. The first versions of UML were created by "Three Amigos" - Grady Booch (creator of Booch method), Ivar Jacobson (Object-Oriented Software Engineering, OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT).
Version | Date | Description |
---|---|---|
1.1 | 11-1997 | UML 1.1 proposal is adopted by the OMG. |
1.3 | 03-2000 | Contains a number of changes to the UML metamodel, semantics, and notation, but should be considered a minor upgrade to the original proposal. |
1.4 | 09-2001 | Mostly "tuning" release but not completely upward compatible with the UML 1.3. Addition of profiles as UML extensions grouped together. Updated visibility of features. Stick arrowhead in interaction diagrams now denotes asynchronous call. Model element may now have multiple stereotypes. Clarified collaborations. Refined definitions of components and related concepts. Artifact was added to represent physical representations of components. |
1.5 | 03-2003 | Added actions (see Part 5 of spec) - executable actions and procedures, including their run-time semantics, defined the concept of a data flow to carry data between actions, etc. |
1.4.2 | 01-2005 | This version was accepted as ISO specification (standard) ISO/IEC 19501. UML 1.5 was released 2 years before. |
2.0 | 08-2005 |
New diagrams: object diagrams,
package diagrams,
composite structure diagrams,
interaction overview diagrams,
timing diagrams,
profile diagrams.
Collaboration diagrams were renamed to
communication diagrams.
Activity diagrams and sequence diagrams were enhanced. Activities were redesigned to use a Petri-like semantics. Edges can now be contained in partitions. Partitions can be hierarchical and multidimensional. Explicitly modeled object flows are new. Classes have been extended with internal structures and ports (composite structures). Information flows were added. A collaboration now is a kind of classifier, and can have any kind of behavioral descriptions associated. Interactions are now contained within classifiers and not only within collaborations. It is now possible for use cases to be owned by classifiers in general and not just packages. New notation for concurrency and branching using combined fragments. Notation and/or semantics were updated for components, realization, deployments of artifacts. Components can no longer be directly deployed to nodes. Artifacts should be deployed instead. Implementation has been replaced by «manifest». Artifacts can now manifest any packageable element (not just components, as before). It is now possible to deploy to nodes with an internal structure. New metaclasses were added: connector, collaboration use, connector end, device, deployment specification, execution environment, accept event action, send object action, structural feature action, value pin, activity final, central buffer node, data stores, flow final, interruptible regions, loop nodes, parameter, port, behavior, behaviored classifier, duration, interval, time constraint, combined fragment, creation event, destruction event, execution event, interaction fragment, interaction use, receive signal event, send signal event, extension, etc. Many stereotypes were eliminated from the Standard UML Profile, e.g. «destroy», «facade», «friend», «profile», «requirement», «table», «thread». Integration between structural and behavioral models was improved with better support for executable models. |
2.1 | 04-2006 | Minor revision to UML 2.0 - corrections and consistency improvements. |
2.1.1 | 02-2007 | Minor revision to the UML 2.1 |
2.1.2 | 11-2007 | Minor revision to the UML 2.1.1 |
2.2 | 02-2009 | Fixed numerous minor consistency problems and added clarifications to UML 2.1.2 |
2.3 | 05-2010 | Minor revision to the UML 2.2, clarified associations and association classes, added final classifier, updated component diagrams, composite structures, actions, etc. |
2.4.1 | 08-2011 | UML revision with few fixes and updates to classes, packages - added URI package attribute; updated actions; removed creation event, execution event, send and receive operation events, send and receive signal events, renamed destruction event to destruction occurrence specification; profiles - changed stereotypes and applied stereotypes to have upper-case first letter - «Metaclass» and stereotype application. |
2.5 | 06-2015 |
UML 2.5 is called a "minor revision" to the UML 2.4.1,
while they spent a lot of efforts to simplify and reorganize UML specification document.
The UML specification was re-written "to make it easier to read".
For example, they tried to "reduce forward references as much as possible".
There are no longer two separate infrastructure and superstructure documents, the UML 2.5 specification is a single document. Package merge is no longer used within the specification. Four UML compliance levels (L0, L1, L2, and L3) are eliminated, as they were not useful in practice. UML 2.5 tools will have to support complete UML specification. Information flows, models, and templates are no longer auxiliary UML constructs. At the same time, use cases, deployments, and the information flows became "supplementary concepts" in UML 2.5. UML 2.5 has a number of fixes, clarifications, and explanations added. They updated description for multiplicity and multiplicity element, clarified definitions of aggregation and composition, and finally fixed wrong «instantiate» dependency example for Car Factory. New notation for inherited members with a caret '^' symbol was introduced. UML 2.5 clarified feature redefinition and overloading. They also moved and rephrased definition of qualifiers. Default for generalization sets was changed from {incomplete, disjoint} to {incomplete, overlapping}. There are few clarifications and fixes for stereotypes, state machines, and activities. Protocol state machines are now denoted using «protocol» instead of {protocol}. Use cases are no longer required to express some needs of actors and to be initiated by an actor. |
UML 2.5 Diagrams
You can proceed to UML 2.5 diagrams overview, specific UML diagrams in the site navigation, or to the examples of UML diagrams.