Software Modelling with UML

Software Engineering

(for Intelligent Distributed Systems)

A.Y. 2024/2025

Giovanni Ciatto

Compiled on: 2025-06-30 — printable version

back

Modelling in Engineering

Architects and civil engineers create models of the things they are going to build

Model in Statistics / Machine Learning

In statistics (and machine learning) a model is a mathematical representation of a real-world process
(commonly attained by fitting a parametric function over a sample of data describing the process)

e.g.: $f(x) = \beta_0 + \beta_1 x $ where $f$ is the amount of minutes played, and $x$ is the age

What is a model?

(cf. https://plato.stanford.edu/entries/models-science/)

A model is a simplified representation of something complex

What are models useful for?

• Understanding of the real world, via simplification and abstraction (i.e., by removing details)

  • think about the many models of the atom (Bohr, Rutherford, etc.), or the wooden miniature of a bridge

• Explain a phenomenon by fitting the model onto the observed data, to reconstruct the process

  • think about the attachment theory in psychology

• Predicting the dynamic behaviour of a system (possibly, before/without building the system)

  • think about the weather forecast, or, again, the wooden miniature of a bridge

Models are simplifications

(cf. https://en.wikipedia.org/wiki/All_models_are_wrong)

“All models are wrong, but some are useful” — George Box

• Each model is stressing some aspects of the real world, and ignoring others
• Focus on the purpose and the context of a model:
  • if the goal is understanding, the model should be simple and intuitive
  • if the goal is prediction, the model should be accurate and precise

Example

• Newton’s Laws: they are not fully correct (Einstein’s relativity refined them)
  • but they are still useful for engineering and daily physics

Why do engineers model systems?

• Models allow engineers to design and study a system before building it

• Building is commonly more expensive and time-consuming than modelling

• Models can verify (to some extent) the system they want to create, before fully building it

• Models allow designers to take design decisions early, and cheaply

• Models can be used to represent and communicate the design of a system

  • useful for collaboration and documentation…
  • … which in turn allow new people to join the project

What about software?

• Writing software implies modelling the world and representing it in a formal way

  • so, in a sense, the source code is a model of the world (or, at least, of the problem)

• Yet, the source code of a project can easily grow in complexity

  • think about large projects with millions of LoC:
    1. how can a person keep them all in their mind?
    2. how could that person transfer all that knowledge to others?

• Indeed, as software projects tend to grow complex, the aforementioned motivations for modelling apply to software as well

  • we need more abstract (than code) and visual ways to represent software systems

Software systems are commonly modelled using the Unified Modelling Language (UML)

The Unified Modelling Language (UML)

(cf. https://en.wikipedia.org/wiki/Unified_Modeling_Language)

• General-purpose, graphical, modeling language in the field of software engineering

  • intended to provide a (semi)-formal way to visualize the design of a software system

• UML is a standard (ISO/IEC 19501:2005) managed by the Object Management Group (OMG) since 1997

• Actually, nowadays, most practitioners do not properly use UML, but instead produce informal diagrams

  • more or less inspired by UML, but not strictly following the standard

• In any case, the focus is on giving a graphical language to represent various aspects of a software system

What can UML represent?

• UML can represent many aspects of a software system, via as many sorts of diagrams
  • broadly categorized in structural and behavioural diagrams

Class Diagrams

• Modelling the structure of a system
• Focus on classes and their relationships

Class Diagrams Overview

(cf. https://en.wikipedia.org/wiki/Class_diagram)

Class Diagram Example

(Remark: this is not a “good” diagram from a real system, but just an example to show the graphical syntax)

Class Diagram Explained (pt. 1)

1. Focus on classes (here intended as data types)

   • report class names
   • report sort of classes (e.g. abstract, interface, enum, class)
     • enums are types whose values are fixed and enumerated

2. Focus on relationships among classes

   • inheritance a.k.a. “extends” (solid line with a triangle)
   • implementation a.k.a. “implements” (dashed line with a triangle)
   • aggregation (solid line with a white diamond): the container may exist without items
   • composition (solid line with a filled diamond): the composed entity cannot exist without the component
   • association (solid line, with or without arrow): any other relevant sort of symmetric (no arrow) or asymmetric (with arrow) relation

Class Diagram Explained (pt. 2)

3. Focus on the attributes of each class
   • private attributes (beginning with a -, or red square)
   • protected attributes (beginning with a #, or yellow diamond)
   • public attributes (beginning with a +, or green square)
   • abstract attributes (italics)
   • static or class attributes (underline)
   • fields or properties, i.e. attributes without parentheses (beginning with a unfilled symbol)
   • methods or functions, i.e. attributes with parentheses (beginning with a filled symbol)

Class Diagram Explained (pt. 3)

Common questions

• should you include type information in attributes? $\Rightarrow$ not mandatory, but recommended
• should you include visibility information in attributes? $\Rightarrow$ yes
• should you include Python’s underscore prefixes for visibility (_ or __)in the diagram $\Rightarrow$ as you like
• should you include all attributes?
  • if you’re willing to provide a complete model of the code’s structure $\Rightarrow$ yes
  • if you’re willing to provide an overview of the public API $\Rightarrow$ public attributes only
  • if you’re willing to an overview of the types $\Rightarrow$ no

Sequence Diagrams

• Modelling the interaction among the components of a system
• Focus on objects / components and their interactions over time
  • i.e., who’s sending which message to whom, when

Sequence Diagrams Overview

Participant -> Participant: stateless\nprocedure
Participant -> Actor: another response
deactivate Participant

Sequence Diagram Example in OOP (pt. 1)

Visualising the Iterator Pattern (compliant to Python’s iterator protocol)

class MyIterator:
    def __init__(self, items):
        self.__items = items
        self.__index = 0

    def __next__(self):
        if self.__index >= len(self.__items):
            raise StopIteration
        current_item = self.__items[self.__index]
        self.__index += 1
        return current_item

class MyCollection:
    def __init__(self):
        self.items = []

    def add(self, item):
        self.items.append(item)

    def __iter__(self):
        return MyIterator(self.items)

collection = MyCollection()
collection.add("A")
collection.add("B")
collection.add("C")

iterator = iter(collection)
while True:
    try:
        item = next(iterator)
        print(item)
    except StopIteration:
        break

Sequence Diagram Example in OOP (pt. 2)

• Participants are named after classes, yet they refer to instances of those classes

• Arrows are named after method calls when possible

• The following pieces of code are completely equivalent in Python:

iterator = iter(collection)
while True:
    try:
        item = next(iterator)
        print(item)
    except StopIteration:
        break

for item in collection:
    print(item)

Sequence Diagram Example in Distributed Systems

State Diagram

• Modelling the state of an object and the transitions among them
• Focus on classes and how method calls affect their fields/properties

State Diagram Overview

• State diagrams only make sense for mutable entities
  • i.e., entities whose state can change over time
• Essentially, they represent finite state machines (FSM)
  • a.k.a. finite state automata (FSA)
• Boxes represent the different states the modelled system can be in
  • further descriptions can be written inside the boxes
• Arrows represent the transitions among the states
  • most commonly caused by events
• Initial state is marked by a black dot
  • mandatory, unique
• Final state is marked by a circle with a black dot inside
  • optional (systems may also not terminate!), unique
• Loops: relevant events leaving the state unchanged
• Arrows are labelled with the event causing the transition
  • [optional] + the condition for the transition to happen
  • [optional] + the action to be performed upon transitioning
• State descriptions may include entry and exit actions
  • and/or permanence conditions for that state

State Diagram Example in OOP

Enum for admissible colours

from enum import Enum

class Color(Enum):
    GREEN = 0
    YELLOW = 1
    RED = 2

    def next(self):
        return Color((self.value + 1) % 3)

State Machine for a Traffic Light

class Semaphore:
    def __init__(self):
        self.__color = Color.GREEN
        self.__on = True

    def next(self):
        self.__color = self.__color.next()

    def toggle(self):
        self.__on = not self.__on

    def __str__(self):
        return f'{self.__color} {"on" if self.__on else "off"}'

Time-related code

from time import sleep
from datetime import timedelta, datetime

T1 = timedelta(seconds=10)
T2 = timedelta(seconds=5)
T3 = timedelta(seconds=15)
T_flash = timedelta(seconds=1)

semaphore = Semaphore()
instant_init = datetime.now()
while True:
    for T in [T1, T2, T3]:
        instant_start_period = datetime.now()
        print(datetime.now() - instant_init, semaphore)
        while datetime.now() - instant_start_period < T:
            sleep(T_flash.total_seconds())
            semaphore.toggle()
            print(datetime.now() - instant_init, semaphore)
        semaphore.next()

Output

0:00:00.000006 Color.GREEN on
0:00:01.005111 Color.GREEN off
0:00:02.010381 Color.GREEN on
0:00:03.011538 Color.GREEN off
0:00:04.013307 Color.GREEN on
0:00:05.033300 Color.GREEN off
0:00:06.038391 Color.GREEN on
0:00:07.043062 Color.GREEN off
0:00:08.048151 Color.GREEN on
0:00:09.051959 Color.GREEN off
0:00:10.057036 Color.GREEN on
0:00:10.057134 Color.YELLOW on
0:00:11.062204 Color.YELLOW off
0:00:12.065133 Color.YELLOW on
0:00:13.069653 Color.YELLOW off
0:00:14.074754 Color.YELLOW on
0:00:15.077038 Color.YELLOW off
0:00:15.077119 Color.RED off
0:00:16.080739 Color.RED on
0:00:17.085859 Color.RED off
0:00:18.090981 Color.RED on
0:00:19.096069 Color.RED off
0:00:20.099124 Color.RED on
0:00:21.104888 Color.RED off
0:00:22.106639 Color.RED on
0:00:23.111723 Color.RED off
0:00:24.116843 Color.RED on
0:00:25.118087 Color.RED off
0:00:26.123146 Color.RED on
0:00:27.126476 Color.RED off
0:00:28.128466 Color.RED on
0:00:29.133614 Color.RED off
0:00:30.138698 Color.RED on

Activity Diagram

• Modelling the workflow of one or more processes
• Like a flow chart, but more flexible and richer, and supporting parallelism

Overview on Activity Diagrams

• Activity diagrams can represent socio-technical workflows
  • i.e. workflows involving people and machines
• They can represent business processes
  • e.g. order processing, customer service, product development
• They can represent software processes
  • e.g. an algorithm, a use case, a system operation
• Boxes represent activities, expressed in natural language
• Several control structures are supported:
  • sequence (straight arrows): one activity follows the other
  • choiches (diamonds): a branch in the workflow
    • based on a condition
  • loops (back arrows): a cycle in the workflow
  • forks (black bars, opening): activities are started in parallel
  • joins (black bars, closing): activities are joined
    • joining an activity $\equiv$ waiting for its termination
• Two sort of joins:
  • AND join: all activities must terminate
  • OR join: at least one (i.e. “any”) activity must terminate
• Beginning and termination $\leftrightarrow$ explicit bullets

Example: Activity Diagram To Represent Algorithms

def bubble_sort(xs):
    xs = list(xs)
    n = len(xs)
    for i in range(n):
        for j in range(0, n - 1 - i):
            if xs[j] > xs[j + 1]:
                xs[j], xs[j + 1] = xs[j + 1], xs[j]
    return xs

Other relevant UML Diagrams by Example

Use Case Diagram

Modelling the actors interacting with a system and the use cases they can perform

(cf. https://en.wikipedia.org/wiki/Use_case_diagram)

• Stick figures represent the actors
  • a.k.a. the personas interacting with the system
    • i.e. sorts of users in the eyes of the system
• Ovals represent the use cases
  • i.e. the functionalities the system provides
• Lines associate actors to use cases
  • i.e. how actors contribute to each use case
• Dashed arrows represent the generalization relationship
  • i.e. how a use case is a specialization of another
• The system is represented as a box
  • containing the use cases

Deployment Diagram

Modelling the physical architecture (a.k.a. infrastructure) of a system

• Outer blocks represent the nodes (a.k.a. devices) of the system
  • e.g. servers, PCs, smartphones, IoT devices
• Intermediate blocks represent the software components of the systems
  • e.g. Web Server, Web Browser, DBMS technology, etc.
• Inner blocks represent the components (a.k.a. software artifacts) of the system
  • e.g. Jars for Java software, Python modules, etc.
• Lines represent communication paths

(cf. https://sparxsystems.com/resources/tutorials/uml2/deployment-diagram.html)

How much details should I put in a diagram?

• Enough to convey the essential information

  • but not too much to make it unreadable

• Think about the reader and what they need to know

  • e.g. a developer needs more details than a manager

• When presenting, consider following the C4 approach, which suggests zooming-in from high-level to low-level details:

  1. Context: high-level overview (e.g. via use case diagram)
  2. Containers: overview on the main containers (e.g. deployment diagram)
  3. Components: detailed view on the components (e.g. package diagram, components diagram)
  4. Code: the actual code (e.g. class diagram)

• When designing, you may proceed (this is highly subjective, find your way!):

  • outside-in: deployment $\rightarrow$ package $\rightarrow$ class
  • inside-out: class $\rightarrow$ package $\rightarrow$ deployment
  • in either cases:
    • start with use cases to design the functionalities, and the actors involved in the system
    • use sequence diagrams to design how components/classes _interact
    • use state diagrams to design how stateful components/classes work
    • use activity diagrams to design the workflow of the system

PlantUML: https://plantuml.com/

• Technology for generating UML diagrams (in either .png or .svg format) out of a simple declarative language

• Online documentation (useful to learn the declarative language from examples):

  • Use Case Diagrams
  • Sequence Diagrams
  • Class Diagrams
  • Activity Diagrams
  • State Diagrams
  • Deployment Diagrams

• Online editor: https://www.plantuml.com/plantuml/uml

  • assigning embeddable URLs to your diagrams (e.g., as images in Markdown documents):

    ![Diagram description](http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKiX8pSd9vt98pKi1IW80)
    

  • the string SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKiX8pSd9vt98pKi1IW80 encodes the diagram’ content

    • URL http://www.plantuml.com/plantuml/svg/ENCODED_DIAGRAM_STRING will return the diagram as an SVG image
    • URL http://www.plantuml.com/plantuml/png/ENCODED_DIAGRAM_STRING will return the diagram as a PNG image
    • URL http://www.plantuml.com/plantuml/uml/ENCODED_DIAGRAM_STRING will open the PlantUML editor with the diagram

Check your understanding

• What is a model? What are the potential purposes of a model?
• How can software be modelled?
• What is UML?
• In the context of UML, what are class diagrams? What do they model? How?
• In the context of UML, what is the difference between aggregation and composition?
• In the context of UML class diagrams, what are the possible relations among classes?
• In the context of UML, what are sequence diagrams? What do they model? How?
• In the context of UML, what are state diagrams? What do they model? How?
• In the context of UML, what are activity diagrams? What do they model? How?
• In the context of UML, what are use case diagrams? What do they model? How?
• In the context of UML, what are deployment diagrams? What do they model? How?
• In the context of UML, what are package diagrams? What do they model? How?
• What is PlantUML?

Lecture is Over

Compiled on: 2025-06-30 — printable version

back to ToC