UML Diagrams

overview#

the Unified Modelling Language (UML) is a standardised visual language for specifying, constructing, and documenting software systems.

UML diagrams fall into two main categories:

the most commonly used diagrams in software design are:

• class diagrams: static structure of a system
• sequence diagrams: object interactions over time
• use case diagrams: user interactions with the system

class diagrams#

class diagrams show the static structure of a system: classes, their attributes, methods, and relationships.

basic class notation#

a class is represented as a rectangle divided into three compartments:

1. top compartment: class name (bold, centred)
2. middle compartment: attributes (fields)
3. bottom compartment: operations (methods)

visibility modifiers#

attribute notation#

the full syntax for an attribute is:

visibility name : type [multiplicity] = defaultValue {property}

examples:

• - balance : double = 0.0 — private attribute with default value
• + items : List<Item> [0..*] — public collection with multiplicity
• + /age : int — derived attribute (calculated, not stored)

operation notation#

the full syntax for an operation is:

visibility name(parameters) : returnType {property}

examples:

• + withdraw(amount : double) : boolean
• - validateInput(s : String) : void
• + getInstance() : Singleton {static}

stereotypes#

stereotypes extend the UML vocabulary with domain-specific concepts:

common stereotypes:

• «interface»: defines a contract without implementation
• «abstract»: cannot be instantiated directly
• «entity»: represents a persistent domain object
• «service»: business logic layer
• «controller»: handles requests
• «repository»: data access layer

abstract classes and methods#

abstract classes are shown with the class name in italics or with the «abstract» stereotype. abstract methods are also italicised.

relationships#

relationships between classes are shown using different line styles and arrowheads.

association#

a general relationship between classes. one class “knows about” or “uses” another.

• solid line connecting the classes
• multiplicities at each end indicate how many instances participate
• can have a name on the association line

multiplicity#

aggregation#

a “whole-part” relationship where the part can exist independently of the whole. shown with an empty diamond.

• the diamond is on the “whole” side
• if the department is deleted, employees can still exist

composition#

a stronger form of aggregation where the part cannot exist without the whole. shown with a filled diamond.

• the filled diamond is on the “whole” side
• if the house is destroyed, its rooms cease to exist

aggregation vs composition#

inheritance (generalisation)#

an “is-a” relationship where a subclass inherits from a superclass. shown with an empty triangle arrowhead.

• arrow points from subclass to superclass
• subclass inherits all attributes and operations

interface realisation#

a class implements an interface. shown with a dashed line and empty triangle arrowhead.

dependency#

a weaker relationship indicating that one class uses another (e.g., as a parameter or local variable). shown with a dashed arrow.

• dashed arrow points from the dependent class to the class it depends on
• weakest relationship type

relationship summary#

sequence diagrams#

sequence diagrams show how objects interact over time. they emphasise the order of messages exchanged.

basic elements#

• lifeline: vertical dashed line representing an object’s existence over time
• activation box: rectangle on a lifeline showing when an object is active
• message: horizontal arrow from sender to receiver
• return message: dashed arrow showing a response

message types#

example interaction#

Client          Server          Database
  |                |                |
  |--- request --->|                |
  |                |--- query ----->|
  |                |<-- result -----|
  |<-- response ---|                |
  |                |                |

in a sequence diagram, this would show:

1. client sends request() to server
2. server sends query() to database
3. database returns result to server
4. server returns response to client

combined fragments#

sequence diagrams can include control flow using combined fragments:

use case diagrams#

use case diagrams show the high-level functionality of a system from the user’s perspective.

basic elements#

• actor: stick figure representing a user or external system
• use case: oval representing a system function
• system boundary: rectangle enclosing use cases
• association: line connecting actors to use cases

relationships#

example#

      +----------------------------------+
      |        Online Shop               |
      |                                  |
User -|---- Browse Products              |
      |                                  |
      |---- Add to Cart                  |
      |         |                        |
      |         |«include»               |
      |         v                        |
      |    Check Stock                   |
      |                                  |
Admin-|---- Manage Inventory             |
      +----------------------------------+

state machine diagrams#

state machine diagrams show the states an object can be in and the transitions between them.

basic elements#

• state: rounded rectangle representing a condition
• initial state: filled circle
• final state: circle with a dot inside (bullseye)
• transition: arrow with trigger/guard/action

transition notation#

trigger [guard] / action

• trigger: event that causes the transition
• guard: boolean condition (in square brackets)
• action: effect executed during the transition

example#

  ●
  |
  v
+-------+      deposit      +--------+
| Empty | ----------------> | Active |
+-------+                   +--------+
                                |
                          withdraw [balance=0]
                                |
                                v
                             +-------+
                             | Closed|---> ◉
                             +-------+

activity diagrams#

activity diagrams model workflows and business processes. similar to flowcharts.

basic elements#

swimlanes#

swimlanes partition the diagram by actor or component, showing who is responsible for each action.

| Customer     | System       | Warehouse   |
|--------------|--------------|-------------|
| Place Order  |              |             |
|      |       |              |             |
|      +------>| Process Order|             |
|              |      |       |             |
|              |      +------>| Ship Order  |
|              |              |      |      |
|<-------------+--------------+------+      |
| Receive Order|              |             |

component diagrams#

component diagrams show the organisation of physical software components.

basic elements#

• component: rectangle with two small rectangles on the left edge
• interface: lollipop (provided) or socket (required)
• dependency: dashed arrow between components

notation#

+------------------+
|   «component»    |
|   OrderService   |
|                  |
|  o-- IOrder      |  <-- provided interface (lollipop)
|  )-- IPayment    |  <-- required interface (socket)
+------------------+

tips for effective diagrams#

keep it simple#

• don’t try to show everything in one diagram
• focus on the aspect you’re trying to communicate
• use multiple diagrams for different viewpoints

be consistent#

• use the same notation throughout your project
• establish naming conventions for classes and methods
• keep the same level of detail across related diagrams

know when to use each diagram#