Software Analysis

What Is UML?

UML stands for Unified Modeling Language. It is used to visually describe software systems, their structure, behavior, and how their individual parts communicate with one another.

Put simply, it helps transform an idea or system design into a diagram that can be understood by IT analysts, architects, developers, testers, and stakeholders alike.

UML as a Technical Blueprint of a System

A UML diagram can be compared to a technical drawing. Just as a construction plan shows the important parts of a building, a UML diagram captures a selected part of a software system.

For example, a diagram can show:

  • which functions the system provides to users,
  • which classes or components it consists of,
  • how the individual parts communicate with one another,
  • how a particular process works,
  • which states an object can be in,
  • which environment the application will run in.

What UML Is Not

UML is neither a programming language nor a software development methodology. It does not replace source code or determine how a team should manage a project. It provides a shared visual language for designing, explaining, and documenting a system.

Who Created UML?

UML emerged in the first half of the 1990s in response to the many different methods and notations used in object-oriented analysis and design.

Grady Booch

Creator of the Booch method.

James Rumbaugh

Co-creator of OMT – Object Modeling Technique.

Ivar Jacobson

Creator of the OOSE method and the concept of use cases.

Three Amigos

This trio combined proven principles from existing approaches into a single modeling language. Technology companies and other experts also contributed to its further development.

Who Standardizes UML?

Object Management Group

International Standard

UML is standardized by the Object Management Group (OMG), an international nonprofit technology consortium that maintains standards for software, systems engineering, and business processes.

The official specification is extensive. For the everyday work of an IT analyst, it is more important to understand the meaning of the elements, follow the basic notation rules, and create clear, easy-to-understand diagrams.

1997
OMG adopted UML as a standard.
UML 2.0
Expanded capabilities and a more precise language.
ISO/IEC 19505
International standardization of UML 2.

Why Is UML Important?

Software development brings together people with different perspectives on a system. The stakeholder focuses on the required features, the analyst on system behavior, the architect on the overall design, and the developer on the technical implementation. UML helps connect these perspectives.

A well-designed diagram can:

  • refine requirements before development begins,
  • reveal missing relationships or ambiguities,
  • make communication between team members easier,
  • explain a complex process more clearly than a lengthy text,
  • capture important architectural decisions,
  • serve as a basis for implementation and testing,
  • simplify future system maintenance,
  • help new team members understand the solution more quickly.
An appropriate level of detail is essential. The value of UML does not lie in the number of diagrams. An overly detailed or outdated diagram can, in fact, be confusing.

A Model and a Diagram Are Not Quite the Same

Model

Represents information about the system being designed and the relationships within it.

Diagram

Provides a specific graphical view of a selected part of the model.

A single system can therefore contain multiple diagrams, each answering a different question. A class diagram shows the static structure of a system, while a sequence diagram describes communication between its parts in a particular scenario.

There is no need to capture the entire system in one extensive diagram. In practice, it is usually more useful to create several smaller, easy-to-read diagrams.

Two Basic Views of a System

UML diagrams can be divided into two main groups:

1

Structural Diagrams

  • Describe what a system consists of.
  • Capture the parts of a system and their relationships.
  • Represent its static view.
2

Behavioral Diagrams

  • Describe how a system behaves.
  • Capture processes, communication, and state changes.
  • Represent its dynamic view.
The structural view resembles a map of the system's parts. The behavioral view captures what happens within the system. The two complement each other: one shows the existing components, while the other explains how they communicate in a particular scenario.

Main Behavioral Diagrams

Behavioral diagrams capture what a system does, how it responds to events, and how its parts communicate with one another.

System Functions

Use Case Diagram

  • Represents the main functions of a system.
  • Shows the perspective of users and external systems.

Answers the questionWhat can individual users do with the system?

Process Flow

Activity Diagram

  • Describes a process or workflow.
  • Captures steps, decisions, branching, and parallel activities.

Answers the questionHow does the process progress from start to finish?

Life Cycle

State Machine Diagram

  • Describes the possible states of an object.
  • Shows the events that cause a change of state.

Answers the questionWhich states can an object be in, and what triggers a change?

Communication

Sequence Diagram

  • Captures communication in chronological order.
  • Shows participants and the sequence of messages or calls.

Answers the questionWho communicates with whom, and in what order?

Other Interaction Diagrams
  • communication diagram
  • interaction overview diagram
  • timing diagram

In everyday analytical practice, the sequence diagram is by far one of the most commonly encountered.

Main Structural Diagrams

Structural diagrams capture the parts of a system, their properties, interfaces, locations, and mutual relationships.

Data Model

Class Diagram

  • Shows classes, properties, and operations.
  • Illustrates relationships between classes.
  • Supports both domain analysis and implementation design.

Answers the questionWhich main objects exist in the system, and how are they related?

Specific Situation

Object Diagram

  • Captures specific instances of classes.
  • Represents the state of part of a system at a particular point in time.

Answers the questionWhat might a specific set of objects look like while the system is running?

Architecture

Component Diagram

  • Shows components, modules, and services.
  • Illustrates their dependencies and interfaces.

Answers the questionWhich technological parts make up the solution?

Infrastructure

Deployment Diagram

  • Shows servers, devices, containers, and other nodes.
  • Shows the physical distribution of the system's parts.

Answers the questionWhere will the individual parts of the system run?

Organization

Package Diagram

  • Groups elements into logical units.
  • Shows dependencies between packages.

Answers the questionHow is the system divided into areas, layers, or modules?

Less Commonly Used Structural Diagrams
  • composite structure diagram
  • profile diagram

Is It Necessary to Use Every UML Diagram?

Short AnswerNo, it is not.

A project should use only the diagrams that provide genuine value. The scope depends on the project phase, system complexity, and target audience.

  • 1Smaller application: several use cases, a class diagram, and one or two sequence diagrams.
  • 2Distributed system: component and deployment diagrams as well.
  • 3Conceptual level: the main idea behind the solution without implementation details.
  • 4Detailed level: the information required for implementation and testing.

UML should support communication. It should not become an administrative obligation or an end in itself.

Summary

  • UML is a standardized visual language for modeling software and other systems.
  • It captures the structure and behavior of a system, as well as communication between its individual parts.
  • It provides a common means of communication for the people involved in development.
  • There is no need to memorize every diagram and symbol.
  • What matters is choosing the right type of diagram and communicating the information clearly.

A well-designed UML diagram can explain a complex part of a system more quickly and precisely than several pages of written documentation.