2IX20 Software Specification

UNIFIED MODELLING LANGUAGE (UML)

Based on the slides provided by M.Seidl,

M.Scholz, C. Huemer and G.Kappel,
authors of the book UML@Classroom
Under the Creative Commons Attribution-
NonCommercial 4.0 International licence.
See http://www.uml.ac.at/en/lernen.

Jeroen Keiren

Mathematics & Computer Science / Formal System Analysis

Bugs: Post office scandal

• UK post office `Horizon` accounting and stocktaking software

• “More than 900 people who ran post offices were prosecuted after
faulty computer software made it look like money was missing from
their branches.”
• Issues with integrity, consistency, etc. E.g. when cancelling transfer lack of
transactions lead to transfer recorded in one system not in another.
• Explanation on YouTube by Computerphile
https://youtu.be/hBJm9ZYqL10?si=UjJ3EW8VY3qUXLT7

• Hearings currently ongoing

2 2IX20 Unified Modelling Language Shared by Madoc Karthaus
Overview

3 2IX20 Unified Modelling Language

Exercise: Requirement Syntax (ex. 3.1)

Are the following requirements written according to the syntax

described in the ISO 29148 standard? If not, rewrite the requirement
according to the syntax. In both cases, clearly indicate the parts of
the syntax ([Subject], etc.) in the requirement.

• The system shall provide the means for the resource provider to
see on which project this resource is working.

4 2IX20 Unified Modelling Language

Exercise: Requirement Syntax (ex. 3.1)

Are the following requirements written according to the syntax

described in the ISO 29148 standard? If not, rewrite the requirement
according to the syntax. In both cases, clearly indicate the parts of
the syntax ([Subject], etc.) in the requirement.

• If one of the resources disappears while it was performing a job,

the system should re-queue the job.

5 2IX20 Unified Modelling Language

Exercise: Requirement Syntax (ex. 3.2)

Analyse these requirements according to the characteristics of individual

requirements. If the requirements does not satisfy the characteristics,
propose an alternative requirement, and also indicate how that
requirement fits with the requirement syntax.

• In order to obtain a CERN car sticker the person must have a valid CERN
ID.

6 2IX20 Unified Modelling Language

Exercise: Requirement Syntax (ex. 3.2)

Analyse these requirements according to the characteristics of individual

requirements. If the requirements does not satisfy the characteristics,
propose an alternative requirement, and also indicate how that
requirement fits with the requirement syntax.

• The opening of the software shall take less than 3-4 seconds under
normal working conditions.

7 2IX20 Unified Modelling Language

Literature
UML @ Classroom:
An Introduction to Object-Oriented Modeling
Martina Seidl, Marion Scholz, Christian Huemer and
Gerti Kappel
Springer Publishing, 2015
ISBN 3319127411

§ Use Case Diagram

§ Structure Modeling
§ State Machine Diagram
§ Sequence Diagram
§ Activity Diagram

8 2IX20 Unified Modelling Language

Slides

Based on slides provided by the authors of the textbook

Slides published under

Creative Commons Attribution-NonCommercial 4.0 International license.
http://www.uml.ac.at/en/lernen

9 2IX20 Unified Modelling Language

Unified Modelling Language (UML)

Standardized (ISO/IEC 19501:2005)

• general-purpose modelling language in the field for software
engineering
• includes graphic notation techniques to create visual models of
object-oriented software-intensive systems
UML 1.1 UML 2.4 UML 2.5.1
(1997) (2011) (2017)

UML 2.0 UML 2.5

(2005) (2015)

10 2IX20 Unified Modelling Language

History of object-oriented modelling

Guido Zockoll, Axel Scheithauer

& Marcel Douwe Dekker (Mdd),
CC BY-SA 3.0

11 2IX20 Unified Modelling Language

UML 2.5.1

http://www.omg.org/spec/UML/2.5.1/ An OMG® Unified Modeling Language ® Publication

OMG® Unified Modeling Language® (OMG UML®)

Version 2.5.1

796 pages
OMG Document Number: formal/2017-12-05
IDate:
do not expect you December
to learn2017UML specification by heart, but
please consult it
Normative Reference:
in case of doubt.
http://www.omg.org/spec/UML/2.5.1

Machine readable files: http://www.omg.org/spec/UML/20161101

12 2IX20 Unified Modelling Language
Normative: http://www.omg.org/spec/UML/20161101/PrimitiveTypes.xmi
http://www.omg.org/spec/UML/20161101/UML.xmi
 UML diagram types

Diagram

Structure Behavior
Diagram Diagram

Class Package Profile Object Activity State Machine Interaction Use Case
Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Deployment Composition Component Sequence Communication Interaction Timing

Diagram Structure Diagram Diagram Diagram Overview Diagram
Diagram Diagram

13 2IX20 Unified Modelling Language

 UML diagram types in this course

Diagram

Structure Behavior
Diagram Diagram

Class Package Profile Object Activity State Machine Interaction Use Case
Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Deployment Composition Component Sequence Communication Interaction Timing

Diagram Structure Diagram Diagram Diagram Overview Diagram
Diagram Diagram

14 2IX20 Unified Modelling Language

Use case diagrams

Diagram

Structure Behavior
Diagram Diagram

Class Package Profile Object Activity State Machine Interaction Use Case
Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Deployment Composition Component Sequence Communication Interaction Timing

Diagram Structure Diagram Diagram Diagram Overview Diagram
Diagram Diagram

15 2IX20 Use case diagrams

 Requirements vs Use Cases
Requirements Use Cases
• Large documents • How parties interact with the system
• Static description • Structured diagrams
• Little structure • UML standard

Interaction Systems - Users

[CC0]

[CC BY-NC-ND 4.0]

16 2IX20 Use case diagrams

Use cases

Use case
• Fundamental concept of many object-oriented development methods

Use case diagram

• Expresses expectations of customers/stakeholders
• Essential for detailed design
• Used during entire analysis and design process
• Can be used to answer:
• What is being described? (The system.)
• Who interacts with the system? (The actors.)
• What can the actors do? (The use cases.)

17 2IX20 Use case diagrams

Example: Student Administration System

• System
(what is being described?)
• Student administration system

• Actors
(who interacts with the system?)
• Professor

• Use cases
(what can the actors do?)
• Query student data
• Issue certificate
18 2IX20 Use case diagrams
Use Case

• Describes functionality expected from system under development

• Provides benefit for one or more actors that communicate with use case
• Derived from collected customer/stakeholder wishes
• Set of all use cases describes functionality system shall provide
• Documents the functionality that a system offers.
• Alternative notations:

19 2IX20 Use case diagrams

Actors

• Interact with the system …

• by using use cases,
i.e., the actors initiate the execution of use cases
• by being used by use cases
i.e., the actors provide functionality for the execution of use cases
• Represent roles that users adopt
• Specific users can adopt and set aside multiple roles simultaneously
• Are not part of the system
i.e., they are outside of the system boundaries

20 2IX20 Use case diagrams

Alternative notations

21 2IX20 Use case diagrams

Actors

• User data usually administered within system

• Data is modeled within system as objects and classes
• Example: actor Assistant
• Actor Assistant interacts with the system Laboratory Assignment by
using it
• class Assistant describes objects representing user data (e.g., name, ssNr, …).

22
7 2IX20 Use case diagrams
Actors

• Human Student, Professor,…

• Non-human E-Mail Server,…

• Primary: has main benefit of execution of use case

• Secondary: receives no direct benefit

• Active: initiates the execution of use case

• Passive: provides functionality for execution of the use case

23 2IX20 Use case diagrams

Example
Human Human
Primary Primary
Active Active

Non-human Human
Secondary Secondary
Passive Active

24 2IX20 Use case diagrams

Detailed use case descriptions

25 2IX20 Unified Modelling Language

Detailed description of Use Cases

Structured approach
• Name
• Short description
• Precondition: prerequisite for successful execution
• Postcondition: system state after successful execution
• Error situations: errors relevant to the problem domain
• System state on the occurrence of an error
• Actors that communicate with the use case
• Trigger: events which initiate/start the use case
• Standard process: individual steps to be taken
• Alternative processes: deviations from the standard process

[A. Cockburn: Writing Effective Use Cases, Addison Wesley, 2000]

26 2IX20 Use case diagrams
Description of Use Cases - Example
• Name: Reserve lecture hall
• Short description: An employee reserves a lecture hall at the university for an event.
• Precondition: The employee is authorized to reserve lecture halls.
• Postcondition: A lecture hall is reserved.
• Error situations: There is no free lecture hall.
• System state in the event of an error: The employee has not reserved a lecture hall.
• Actors: Employee
• Trigger: Employee requires a lecture hall.
• Standard process: (1) Employee logs in to the system.
(2) Employee selects the lecture hall.
(3) Employee selects the date.
(4) System confirms that the lecture hall is free.
(5) Employee confirms the reservation.
• Alternative processes: (4’) Lecture hall is not free.
(5’) System proposes an alternative lecture hall.
(6’) Employee selects alternative lecture hall and confirms the reservation.

27 2IX20 Use case diagrams

Notation Elements
Name Notation Description

Boundaries between the system and the

System
users of the system

Use case Unit of functionality of the system

Actor Role of the users of the system

28 2IX20 Use case diagrams

Relationships between Use Cases and Actors

• Actors are connected with use cases via solid lines (associations)
• Every actor must communicate (be associated) with at least one use
case
• An association is always binary
• Multiplicities may be specified

29 2IX20 Use case diagrams: relationships

Relationships between Use Cases
«include» - Relationship

The behavior of one use case (included use case) is integrated in the
behavior of another use case (base use case)

Base use case

requires the behavior of the included use
case to be able to offer its functionality

Included use case

may be executed on its own

30 2IX20 Use case diagrams: relationships

Example
«include» - Relationship

31 2IX20 Use case diagrams: relationships

Relationships between Use Cases
«extend» - Relationship

• Behavior of extending use case may be integrated in behavior of base

use case but does not have to
• Both use cases may also be executed independently of each other
• A decides if B is executed.

Base use case

Extending use case

32 2IX20 Use case diagrams: relationships

Example
«extend» - Relationship

Student Administration

Reserve
lecture hall

«extend»

Announce
lecture

«extend»
Announce Professor
exam

33 2IX20 Use case diagrams: relationships

Relationships between Use Cases
«extend» - Relationship: Extension points

• Extension points:
• define at which point the behavior is
integrated
• written directly within the use case
• Multiple extension points can be
specified
• Conditions define under which
circumstances the behavior is
integrated

34 2IX20 Use case diagrams: relationships

Relationships between Use Cases
Generalization of Use Cases

• Use case A generalizes use case B

• B inherits behavior of A and may
extend/overwrite it
• B inherits all relationships from A
Base use case
• B adopts basic functionality of A but
decides what part of A is executed or changed Sub use case
• A may be labeled {abstract}
• Cannot be executed directly
• Only B is executable

35 2IX20 Use case diagrams: relationships

Example
Generalization of Use Cases

36 2IX20 Use case diagrams: relationships

Relationships between Actors
Generalization of Actors

• Actor A inherits from actor B

• A can communicate with X and Y
• B can only communicate with Y
• Multiple inheritance is permitted
• Abstract actors are possible Super-actor
Sub-actor

37 2IX20 Use case diagrams: relationships

 Example
Generalization of Actors

Professor AND Assistant needed Professor OR Assistant needed

for executing Query student data for executing Query student data

38 2IX20 Use case diagrams: relationships

Notation Elements
Name Notation Description

Relationship between use cases and

Association
actors

Inheritance relationship between actors

Generalization
or use cases

B extends A: optional use of use

Extend relationship
case B by use case A

A includes B: required use of use

Include relationship
case B by use case A

39 2IX20 Use case diagrams: relationships

Creating use cases

• How to create use cases

• Best practices

40 2IX20 Unified Modelling Language

Best Practices: Identifying Actors

Ask (and answer):

• Who uses the main use cases?
• Who needs support for their daily work?
• Who is responsible for system administration?
• What are the external devices/(software) systems with which the
system must communicate?
• Who is interested in the results of the system?

41 2IX20 Use case diagrams: pitfalls and best practices

Best Practices: Identifying Use Cases

Ask (and answer):

• What are the main tasks that an actor must perform?
• Does an actor want to query or modify information in the system?
• Does an actor want to inform the system about changes in other systems?
• Should an actor be informed about unexpected events within the system?

42 2IX20 Use case diagrams: pitfalls and best practices

Example: Vending machine

After client interview, the following scenarios were identified:

• A customer buys a product
• The supplier restocks the machine
• The supplier collects money from the machine; this happens during
restocking

Actors:
• Customer
• Supplier
• Collector (in this case, Collector = Supplier)

43 2IX20 Use case diagrams: pitfalls and best practices

Example: Vending machine

After client interview, the following scenarios were identified:

• A customer buys a product
• The supplier restocks the machine
• The supplier collects money from the machine; this happens during
restocking

Use cases:
• Buy product
• Restock machine
• Collect money

44 2IX20 Use case diagrams: pitfalls and best practices

Example: Vending machine

Vending machine

Buy product

Restock machine

«includes» Supplier
Customer
Collect money

45 2IX20 Use case diagrams: pitfalls and best practices

Be careful
«include»
UML standard Common mistake

In this course, we follow the UML standard!

46 2IX20 Use case diagrams: pitfalls and best practices

Be careful
«extend»
UML standard Common mistake

In this course, we follow the UML standard!

47 2IX20 Use case diagrams: pitfalls and best practices

Best Practices: Typical Errors To Avoid (1/5)

Use case diagrams do not model processes/workflows!

48 2IX20 Use case diagrams: pitfalls and best practices

Best Practices: Typical Errors To Avoid (2/5)

Actors are not part of the system, hence, they are positioned outside the
system boundaries!

49 2IX20 Use case diagrams: pitfalls and best practices

Best Practices: Typical Errors To Avoid (3/5)

Use case Issue information needs EITHER one actor

Assistant OR one actor Professor for execution

50 2IX20 Use case diagrams: pitfalls and best practices

ü
Best Practices: Typical Errors To Avoid (4/5)

Many small use cases that have the same objective may be grouped to
form one use case

ü
51 2IX20 Use case diagrams: pitfalls and best practices
Best Practices: Typical Errors To Avoid (5/5)

The various steps are part of the use cases, not separate use cases
themselves! à NO functional decomposition

ü
52 2IX20 Use case diagrams: pitfalls and best practices
Summary

• Use case focuses on steps required

to achieve goal, including specific
inputs and expected outputs
• Set of all use cases describes
functionality system shall provide
• Use case diagram describes
relation between actors and use
cases

53 2IX20 Unified Modelling Language

Notation Elements (1/2)
Name Notation Description

Boundaries between the system and the

System
users of the system

Use case Unit of functionality of the system

Actor Role of the users of the system

54 2IX20 Lecture 2
Notation Elements (2/2)
Name Notation Description

Relationship between use cases and

Association
actors

Inheritance relationship between actors

Generalization
or use cases

B extends A: optional use of use

Extend relationship
case B by use case A

A includes B: required use of use

Include relationship
case B by use case A

55 2IX20 Lecture 2
Next steps

Read
• Chapter 4 reader

Do
• Exercises 4.1-4.12
• Extra exercise: create a use case diagram for a social media app
• Weekly test 1
• Assignment 1: finish requirements, start on use case diagram

Look around for software bugs and send them to me

56 2IX20 Unified Modelling Language

Exercise

Create a use case diagram for a social media app

57 2IX20 Unified Modelling Language