UML Diagram Types

The Unified Modeling Language (UML) defines various types of diagrams used for visualising, specifying, developing, and documenting software-intensive systems. A UML diagram is a graphical representation of a group of semantically related model elements and the relationships between them. These diagrams can be formally interpreted as graphs consisting of nodes (representing model elements) and edges (representing relationships).

UML diagrams are categorised into two main groups: Structure Diagrams and Behaviour Diagrams.

Structure Diagrams

Structure diagrams are used to model the static system structure. They include:

• Class Diagrams: These diagrams illustrate a set of semantically related classes and their relationships. They provide a structural description of the static data or object model.

• Instance Diagrams: Also known as Object Diagrams, these show a set of semantically related object instances, their current state at a specific time, and their relationships. They capture a "snapshot" of the system's dynamic state at a particular runtime moment.

• Package Diagrams: These depict a set of packages, their contents, and their relationships. They serve to partition the target system into modular subsystems and clarify their connections and dependencies.

• Composite Structure Diagrams (CSDs): These diagrams illustrate the internal structure of a complex model element, such as complex objects, components, or collaborations. They describe the internal cooperation between parts and the communication with the external environment via ports.

• Component Diagrams: These show the internal structure of a component and the relationships (especially dependencies) between components. They relate the required and provided interfaces of the depicted components.

• Deployment Diagrams: Also known as Allocation Diagrams, these display the hardware configuration where the running target system will be used, and the distribution of software artefacts onto individual nodes of the hardware configuration. A node typically contains various system artefacts.

Behaviour Diagrams

Behaviour diagrams are used to model the dynamic system behaviour. They include:

• Use Case Diagrams (UCDs): These diagrams show a set of semantically related use cases and actors, along with their relationships. Their primary goal is to model the external system behaviour from the user's perspective. They are primarily used in the requirements definition phase.

• Activity Diagrams: These diagrams illustrate control and data flows within complex dynamic processes, the coordination and synchronisation of concurrent activities, and the responsibilities of individual objects or actors for executing activities. They integrate concepts from flowcharts, SDL, data flow diagrams, and Petri nets.

• State Machine Diagrams (Statecharts): A State Diagram is the graphical representation of a state machine. It describes the dynamic behaviour of object instances, interfaces, and/or collaborations based on event-driven transitions between discrete states. They are especially useful for modeling object lifecycles.

• Interaction Diagrams: These diagrams are used to represent an interaction, which consists of interacting partners and their relationships, particularly the messages exchanged between them. UML distinguishes four types of interaction diagrams:

  • Sequence Diagrams: Focus on describing the relative temporal order of an interaction. They are well-suited for displaying non-trivial control structures.

  • Communication Diagrams: Emphasise the communication between interacting partners and their underlying relationships. They are considered "dynamic instance diagrams".

  • Timing Diagrams: Aim for a precise description of the absolute time behaviour of objects and systems. They are specifically suited for time-critical, technical applications.

  • Interaction Overview Diagrams (IODs): Provide an overview of the flow of control among multiple encapsulated interactions. Syntactically, they are a hybrid of interaction and activity diagrams, where action nodes are replaced by interactions or interaction references.

Conclusion

These diagram types are used across various phases of software development, from requirements definition to design, to represent different aspects and levels of abstraction of the system model.