UML specification defines two major kinds of UML diagram: structure diagrams and behavior diagrams.
Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts.
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time. (the information is on http://www.uml-diagrams.org/)
| 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   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. |
