Home

Introduction to the UML

The Unified Modeling Language (UML) is a standardised, universal, semi-formal modelling notation designed for the visualisation, specification, development, and documentation of software systems. It serves as a comprehensive language for software-intensive systems.

Historical Development of UML

The journey towards UML began with earlier modelling methods. From approximately 1980 to the mid-1990s, "Structured Methods" such as Structured Analysis (SA) and Structured Analysis/Real-Time (SA/RT) were dominant in modelling. However, with the rising success of object-oriented systems and programming languages like Smalltalk, Eiffel, and C++, attempts were made in the late 1980s to apply the object-oriented paradigm to modelling methods.

The early 1990s saw the emergence of various object-oriented modelling methods, including SHLAER/MELLOR's Object Oriented Systems Analysis (1988), WIRFS-BROCK et al.'s Responsibility-Driven Design (1990), COAD/YOURDON's Object Oriented Analysis and Design (1991), JACOBSON's Object Oriented Software Engineering (1992), RUMBAUGH et al.'s Object Modeling Technique (OMT, 1991), and BOOCH's Object Oriented Analysis and Design (OOAD, 1991).

A significant turning point occurred when Jim Rumbaugh (OMT) joined Grady Booch (OOAD) at Rational Software Corp. in 1994, aiming to combine their methods into a "Unified Method" (UM). In 1995, Rational acquired Objectory, bringing Ivar Jacobson (OOSE) into the collaboration. By 1996, the goal of a single standard method was abandoned, and the "three amigos" (Booch, Jacobson, Rumbaugh) shifted their focus to defining a standard notation, which became UML.

In 1997, the UML was adopted as a standard by the Object Management Group (OMG). The OMG, a leading international consortium for industrial standardisation of IT technologies, took over the coordination and further development of UML, with major companies like Microsoft, Oracle, DEC, HP, and IBM involved. UML 1.3 became a de-facto standard in industrial software development, followed by minor updates in versions 1.4 (2000) and 1.5 (2003). A fundamentally revised standard, UML 2.0, was officially published by the OMG in 2005, with subsequent versions (2.1 to 2.5.1) refining it.

What is UML?

UML is more than just a drawing tool; it is a language with a well-defined syntax and semantics.

  • Syntax formally dictates whether a model description is correct according to the UML language definition.

  • Semantics semi-formally defines how a syntactically correct model description should be understood, specifying the properties of the target system fixed by the description.

The language definition of UML itself is formulated in UML, using a small "language core" called the "UML-Infrastructure" or "UML Metamodel". The Metamodel defines the entire concept world of UML and formally regulates how these concepts can be combined to form correct models.

As a modelling language, UML is primarily used for modelling software systems. It provides a notation to adequately describe various aspects, views, and abstraction levels of a system model. UML can be used throughout all phases of the software development process, with a primary focus on the analysis and design phases. It offers notation elements for nearly all relevant modelling subjects, including static system structure (Structural Modeling), dynamic system behaviour (Behavioral Modeling), and system architecture (Architectural Modeling).

UML is a "unified" modelling language because it brings together the concepts and notations from the most important object-oriented modelling methods of the 1990s, effectively rendering them obsolete. It supports the union of almost all established basic modelling concepts, such as Entity-Relationship Models (ERM), class structures, state machines, Petri nets, data flows, control flows, and interaction structures. Importantly, UML integrates all these supported modelling concepts into a single, unified system model. While consistently using the object-oriented paradigm, it also allows for functional, data-oriented, control-flow-oriented, scenario-based, or state-oriented views for specific aspects of the system model.

Objectives of UML

According to the UML User Guide, UML is a language for:

  • Visualising: It allows for both textual and graphical modelling, recognising that some system structures transcend what can be represented in a programming language.

  • Specifying: It enables the creation of precise, unambiguous, and complete models, addressing all crucial analysis, design, and implementation decisions in developing and deploying software-intensive systems.

  • Documenting: UML supports the documentation of a system's architecture and its details, including requirements and tests.

  • Constructing: While not a programming language itself, UML models can be directly connected to various programming languages. It facilitates "round-trip engineering," allowing work in either graphical or textual views while tools maintain consistency between them through forward code generation and reverse engineering.

Role in System Development and Documentation

UML system models are typically created with tool support and managed in a model repository. This model-driven software development offers several advantages:

  • Automated code generation is facilitated.

  • System documentation can be automatically generated and remains consistent and up-to-date.

  • Ideally, changes can be performed exclusively at the model level.

  • The principle of "Round-Trip-Engineering" allows modifications to be made either at the system model level or the code level, with automatic generators ensuring consistency between the two.

What UML is NOT

It is crucial to understand what UML is not:

  • UML is a modelling notation, not a modelling method. A modelling method combines basic concepts and notations and defines an integrated process model, whereas UML only provides the notation.

  • UML supports the entire software development process but does not prescribe a specific development process. Projects using UML still need an individual process model.

  • The use of UML does not enforce a restriction to specific concepts (e.g., object-oriented ones) or system architectures.

  • It does not mandate the use of particular modelling methods or process models, nor does it dictate the use of specific programming languages or modelling/development tools.

Key Concepts: Elements, Relationships, and Diagrams

The UML Metamodel defines the fundamental building blocks of UML specifications.

  • Vocabulary: Every UML system model is built from a finite set of well-defined graphical and textual basic components. This vocabulary is broadly classified into:

    • Model Elements (Elements): Abstractions for components of a system model (e.g., Classes, Objects, Components, Interfaces, Nodes, Use Cases, Activities, Actions, Interactions, Collaborations, State Machines, Packages, Comments, and Constraints)

    • Relationships (Relationships): Define semantic connections between model elements (e.g., Associations, Aggregations, Compositions, Generalizations/Specializations, Dependencies, and Realizations)

  • Diagrams: Model elements and their relationships can be combined into diagrams according to specific syntactic rules. A UML diagram is a graphical representation of a group of semantically related model elements and their relationships. Formally, any UML diagram can be interpreted as a graph with nodes (model elements) and edges (relationships).

UML in the Software Development Process

UML allows for various, largely independent "views" on the target system's model, all founded on a common "Model Repository". These views include:

  • Structure Model (Static System Model): Covered by Class Diagrams, Instance Diagrams, Package Diagrams, Composite Structure Diagrams.

  • Architecture Model: Covered by Package Diagrams, Component Diagrams, Deployment Diagrams, and Composite Structure Diagrams.

  • Behaviour Model (Dynamic System Model): Covered by Use Case Diagrams, State Machine Diagrams, Activity Diagrams, and Interaction Diagrams.

While UML provides the notation, it does not prescribe a specific modelling method. Therefore, every large development project using UML requires an individual process model to define the phases, activities, actors, and artefacts involved, as well as which UML concepts and diagram types to use at each stage. UML can be applied at varying levels of abstraction across different phases of the software development lifecycle, from high-level external scenarios in requirements definition to fine-grained internal logic in design.

Conclusion

In essence, UML serves as an indispensable tool for comprehending, designing, and maintaining complex software, fostering clarity and collaboration among development teams by providing a shared, comprehensive visual language.

Further Reading

  • UML 2.5 Specification

  • Fowler, M. (2003). UML distilled: A brief guide to the standard object modeling language (3rd ed.). Addison‑Wesley Professional.

  • Rumbaugh, J., Jacobson, I., & Booch, G. (2004). The Unified Modeling Language reference manual (2nd ed.). Addison‑Wesley Professional.