UML 2.2 Diagrams Overview
A UML diagram is a partial graphical representation (view) of a model of a system under design, implementation, or already in existence. UML diagram contains graphical elements (symbols) - UML nodes connected with edges (also known as paths or flows) - that represent elements in the UML model of the designed system. The UML model of the system might also contain other documentation such as use cases written as templated texts.
The kind of the diagram is defined by the primary graphical symbols shown on the diagram. For example, a diagram where the primary symbols in the contents area are classes is Class diagram. A diagram which shows use cases and actors is Use Case diagram. Sequence diagram shows sequence of message exchanges between lifelines.
UML specification does not preclude mixing of different kinds of diagrams, e.g. to combine structural and behavioral elements to show a state machine nested inside a use case. Consequently, the boundaries between the various kinds of diagrams are not strictly enforced. At the same time, some UML Tools do restrict set of available graphical elements which could be used when working on specific type of diagram.
Classification of UML 2.2 Diagrams
UML 2.2 specification defines two major kinds of UML diagram: structure diagrams and behavior diagrams.
Structure diagrams show the static structure of the system and it's 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.
UML 2.2 diagrams are categorized hierarchically as shown below:
UML 2.2 Diagrams Overview
Structure Diagrams
Structure diagrams show the static structure of the system and it's 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.
Structure diagrams are not utilizing time related concepts, do not show the details of dynamic behavior. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Class Diagram is static structure diagram describing structure of a system on the (lowest) level of classifiers (classes, interfaces, etc.). It shows system's classifiers, their attributes, and the relationships between classifiers.
Object diagram shows instances of classifiers and links (instances of associations) between them.
Package Diagram shows packages and dependencies between the packages.
Component diagram shows components and dependencies between them. This type of diagrams is used for Component-Based Development (CBD), to describe systems with Service-Oriented Architecture (SOA).
Composite Structure diagram could be used to show:
- Internal structure of a classifier
- A behavior of a collaboration
Internal Structure diagrams show internal structure of a classifier - a decomposition of the classifier into its properties, parts and relationships.
Collaboration Use diagram shows objects in a system cooperating with each other to produce some behavior of the system.
Deployment diagram shows execution architecture of a system that represent the assignment (deployment) of software artifacts to deployment targets (usually nodes).
Profile diagram is auxiliary UML diagram which allows to define custom stereotypes, tagged values, and constraints. The Profile mechanism has been defined in UML for providing a lightweight extension mechanism to the UML standard. Profiles allow to adapt the UML metamodel for different
- platforms (such as J2EE or .NET), or
- domains (such as real-time or business process modeling).
Profile diagrams were first introduced in UML 2.0.
Behavior Diagrams
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.
Use Case Diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors) to provide some observable and valuable results to the actors or other stakeholders of the system(s).
Note, that UML 2.2 specification also defines Use Case diagrams as specialization of class diagrams which are structure diagrams. Use Case diagrams are in fact a special case of class diagrams where classifiers shown are restricted to be either actors or use cases and the major relationship shown is association.
Activity diagram shows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models.
State Machine diagram is used for modeling discrete behavior through finite state transitions. In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage protocol of part of a system. These two kinds of state machines are referred to here as behavioral state machines and protocol state machines.
Interaction diagrams include several different types of diagrams:
- Sequence diagrams,
- Interaction Overview Diagrams,
- Communication diagrams, (known as Collaboration diagrams in UML 1.x)
- Timing Diagrams,
- Interaction Tables.
Sequence diagram is the most common kind of Interaction Diagram, which focuses on the Message interchange between a number of Lifelines.
Communication diagrams (previously known as Collaboration Diagrams) is a kind of Interaction Diagram, which focuses on on the interaction between Lifelines where the architecture of the internal structure and how this corresponds with the Message passing is central. The sequencing of Messages is given through a sequence numbering scheme.
Interaction Overview diagrams define Interactions through a variant of Activity diagrams in a way that promotes overview of the control flow. Interaction Overview diagrams focus on the overview of the flow of control where the nodes are Interactions or Interaction Uses. The Lifelines and the Messages do not appear at this overview level.
Timing diagrams are used to show interactions when a primary purpose of the diagram is to reason about time. Timing diagrams focus on conditions changing within and among Lifelines along a linear time axis.