Systems

Engineering
Lecture 4: System Modelling with UML
Sarah Sanders | sarah.sanders@ucl.ac.uk
Learning outcomes

By the end of today’s lecture, you should

• Know what the Unified Modelling Language (UML) is and why it is
useful for system modelling
• Be aware of the different types of UML diagrams and where they are
to be used
• Understand what a use case is and where use case diagrams can be
used to help bridge requirements and modelling

If you complete the practice activities then you should also be able to
draw the key UML diagrams that may be useful for your group project
Today’s topics

1. The Unified Modelling Language

2. Behaviour diagrams

3. Structure diagrams

4. Summary
THE UNIFIED MODELLING
LANGUAGE (UML)
Introduction to the Unified Modelling
Language
The Unified Modelling Language (UML) is a language for visualising,
specifying, constructing, documenting, and communicating the
artefacts of a (software) system.

Adopted as a standard by the Object Management Group (OMG), an

international consortium of over 600 members (including Microsoft,
Sun, IBM, etc.)
Why use UML?

Use UML because:

• supports diverse application areas

• is based on experience and needs of the user community

• is supported by many methods and tools

• is considered a core skill for software engineers

• is the de facto standard for software design modelling

Views and diagrams

During modelling, many views

comprising one or more diagrams will
be created.

A UML CASE (Computer Aided Software

Engineering) tool will enforce
consistency and the correct
construction of diagrams.

Numerous free online and

downloadable options such as
LucidChart (search UML tools)
Uses of graphical models

1. As a means of facilitating discussion about an existing or

proposed system: Incomplete and incorrect models are OK as
their role is to support discussion.

2. As a way of documenting an existing system: Models should be

an accurate representation of the system but need not be
complete.

3. As a detailed system description that can be used to generate a

system implementation: Models have to be both correct and
complete.
Use of UML models in Agile projects

Models support communication and understanding with an emphasis

on facilitating discussion, rather than detailed system description.

Focus on the use models when and where they add value, gathering “just
enough” information, with detail only at the point you need it.

Note: Alistair Cockburn and Martin Fowler were among the thought leaders
who signed the original agile manifesto

NB: For your coursework create models as if

they are a detailed system description,
though you may provide hand drawn or
CASE drawn models
http://paulgestwicki.blogspot.com/2013/02/spring-2013-game-studio-modeling-first.htm
UML diagrams

Diagrams are at the heart of UML and they provide a view into a
model

Each diagram:
• Is presented from a particular aspect
• Provides a partial representation of the system
• Depicts modelling elements and relationships
• Is (or should be) semantically consistent with other views (models)
Overview of UML diagrams

This diagram is itself a UML diagram!

UML notation: Classifiers

The basic modelling element in UML is the classifier. A classifier

represents a group of things with common properties. E.g. a class is
a classifier as they have common properties (methods, attributes,
etc.).

A classifier’s generic notation is a rectangle

that can be divided into compartments and
endowed with adornments (e.g. restrictions,
stereotypes).
Notation: Relationships

Modelling elements do not exist in isolation, UML provides

numerous mechanisms for defining the relationships between
modelling elements:
Dependency (... uses-a ...)
Association (... has-a ...) including Aggregation and Composition
Generalisation (... is-a ...)
Realisation (... implements ...)

In UML, arrow and line types matter

An example association (has-a) relationship
Research into UML in practice

Developers tend to focus modelling efforts on the more complex or critical

parts of systems [1]
35 out of 50 software engineers didn’t use UML at all, those that did mainly
used class, sequence and activity diagrams [1]
Even if UML is viewed as the ‘de facto’ standard, it is by no means
universally adopted [1]
Only Class Diagrams are being used regularly by over half the respondents,
with Sequence and Use Case Diagrams used by about half [2]
The use case diagram has a specific role for the requirement specifications
based on use cases (and it seems to be used also without any other UML
diagram) [3]
NB: References are listed in the page notes of the presentation
For this course, we focus on…

Use cases and use case diagram, which show the interactions
between a system and its environment

Class diagrams, which show the object classes in the system and the
associations between these classes (Analysis class diagram and
Design class diagram)

For the coursework try to select those UML diagrams you believe are
most useful for your application, possibly:
• Activity diagrams, which show the activities involved in a process or
in data processing
• Sequence diagrams, which show interactions between actors and the
system and between system components
Is UML sufficient?

In this course we have already covered a number of diagrams that

are not UML and yet may be useful in designing a system:

• Wireframes and screen flows

• Context diagram

We will cover others, e.g.

• Entity relationship diagram (database modelling)

Most of the UML is not covered in this
course!
We are going to look at a subset of the UML diagrams

It is worth noting that:

• There is much more detail than is given in the lecture slides. Focus on
what is presented in lectures, and then use other sources (see
ReadingList) to expand your knowledge.
• We won’t be attempting to cover all of UML. UML is an iceberg...
BEHAVIOUR DIAGRAMS
Overview of behaviour diagrams
Unified Process (UP) and use cases

Use cases are important for many different software process models
and they can drive many of the steps:
Use case modelling

Use Case Modelling is a form of requirements engineering for driving

out functional requirements and includes the activities of:
• Finding the system boundary (last week we looked at the context
diagram)
• Finding the actors (i.e. who or what uses the system)
• Developing scenarios and use cases
Use case modelling: actors

Actors represent who or what uses the system.

An actor is an entity that interacts directly with the system (e.g. a

person, another system, a time-based trigger).

Actors have specific roles.

Primary actors trigger use cases. Secondary actors are those the
system communicates with in carrying out the use case.
Use case modelling: identifying actors

Actors can be identified by observing the direct users of the system

and noting:
• What roles do these users/systems play in the interaction?
• Who/what provides information to the system?
• Who/what receives information from the system?
An actor plays a role, the same external entity may take on the roles
of several actors (e.g. a Librarian who is also a BookBorrower).

An actor can represent many instances of an external reality (e.g.

Multiple BookBorrowers at any given library).
Use cases and scenarios

The full use case model consists of a collection of use cases, each
describing how a task (interaction) with the system is carried out.

A scenario is an instance of a use case model as it would actually be

carried out in a given set of circumstances.

One use case may map to many scenarios; a scenario is one specific
path through the use case model.

A use case specification must cover all potential scenarios.

Scenarios

Scenarios of the same use case can involve different behaviour but
they are all attempts to carry out the same task.
• Primary scenarios show the normal behaviour (i.e. the “happy” path)
• Secondary scenarios who alternatives, exceptions, errors, etc.
Scenarios help to identify and document use cases as well as help
surface requirements.
Use case modelling: example

Use Case: Borrow Copy of Book

Primary scenario BookBorrower Theo borrows the Library’s

only copy of The New Testament, when she
has no other Book out on loan. The System
grants the Loan and updates Theo’s Status
accordingly.

Secondary scenario BookBorrower Nathan tries to borrow the

Library’s 3rd copy of Dinosaur Zoom, but is
refused because she already has six Books
out on loan, which is her maximum
allowance. The system refuses the Loan and
makes no change to Nathan’s Status.
Use case modelling: flows

A use case needs to capture alternatives and errors as well as the

normal flow of events.

Scenarios can help identify the different outcomes of a use case.

The alternative and error flows need to be included when the system
is designed and implemented, otherwise there will be missing
behaviour.
Use case modelling: identifying use cases

So how do we identify use cases?

1. Identify the candidate actors and their goals:

• Write the main success scenario
• List the failure extensions
• List the variations
2. Merge trivial use cases, split up long complex use cases

3. Describe system behaviour from an external point of view, avoid

lower level details.

4. Iterate and review frequently!

Use case modelling: describing use cases

When describing use cases, start with a straightforward textual

description.

Once the use case stabilises create a structured use case

specification.

They should be written in normal text – third person, active voice.

Sometimes it might be useful to employ role playing tactics to help

uncover use cases.
Use case modelling: templates

There is no standard template defined by UML (lots of variations)

Name <Use case name/title>
ID: <ID code, e.g. UC5>
Brief Description: <One sentence overview>
Primary Actor(s): <Actor(s) that invoke the use case>
Secondary Actor(s): <Actor(s) that are invoked by the use case>
Preconditions: <Conditions that need to be true before use case starts>
Main Flow: <Interaction between system and actor(s)>
Postconditions: <Conditions that need to be true after use case ends>
Alternative Flows: <Alternative interactions to those in the main flow>

Martin Fowler, UML Distilled, recommends that you work hard

to keep the use cases brief and easy to read!
Use case specification: example
Use case diagram

The use case diagram provides a graphical overview of the set of use
cases.

Shows which actors carry out which use cases.

(Optionally) shows include and extend relationships between use

cases.
Use case diagram notation
Use case diagrams: include

An including use case calls or invokes the included one

Inclusion is used to show how a use case breaks into smaller steps (useful if
those steps are common across several use cases)

The included use case is at the arrowhead end

The including use case is incomplete without the included use case

UML2 in Action, Grassle et al.

Use case diagrams: extends

An extending use case adds goals and steps to the extended use case

The extended use case is at the arrowhead end

The extending use case is usually optional and can be triggered

conditionally

Taken from [Booch 1999]

Use cases: using extend and include
relationships
When one action is dependent on another action, use
an include relationship

When one action is an extension of another action (or a more

specific version of that action), use extend to show that relationship

Caution: Avoid over-use of include and extend relationships

• Martin Fowler suggests extend is never needed and include should
only be used if you really have a need for it
• Alistair Cockburn in Writing Effective Use Cases, also suggests
caution in using extends
Use case modelling: diagrams versus textual
descriptions
The value of use cases lie in creating the textual specifications.

UML Use Case diagrams act as a useful visual summary of actors, use
cases, and relationships. However, they lack all the other important
information in the textual version.

Martin Fowler in his book UML Distilled suggests that the textual
detail in the use cases is what is important, and recommends that
you don’t put too much effort into the use case diagram!
Requirements to use cases: traceability

Use case models document requirements in a complementary way to

traditional requirements documents.

Items in the requirement document should be linked to items in the

use case models to ensure coverage, to help assess completeness of
the requirements, and to ensure consistency.

Hint: This is a
useful matrix to
include in your
coursework!
Behaviour diagrams: activity diagram

Activity diagrams capture

activity-oriented dynamic
behaviour.

They can be useful to

model business
workflows and procedural
logic.

Initial state (start point)

Activity

Action flow

Diagram taken from [Booch 1999]

Activity diagram: ‘swim lane’ format

An activity diagram can be partitioned (often referred to as “swim

lanes”), to show which entities carry out which tasks:
Behaviour diagrams: sequence diagram

Sequence diagrams are used to capture time-oriented dynamic

behaviour. That is, they model the flow of control and illustrate
typical scenarios.

Taken from [Booch 1999]

Sequence diagram to illustrate a use case

Sequence diagrams can be used to illustrate use cases

The following is a partial extract of a sequence diagram, see source

for the full diagram: agilemodelling.com
Sequence diagram example (Sommerville)

Example from Sommerville

Sequence diagram example (Sommerville)

Example from Sommerville

Sequence diagrams: summary

Sequence diagrams:
• show the interactions between objects in the sequential order that
those interactions occur, they start to show how the system will work
• typically describes part of a system or a scenario
• useful to communicate how the business currently works by showing
how various business objects interact
• can be used as parts of the requirements documentation to
communicate requirements, taking use cases to the next level by
providing a more formal level of refinement
Further information:
• Lynda.com video: how to create sequence diagrams
• Online sequence diagram tool
STRUCTURE DIAGRAMS
Structure diagrams overview
Class diagrams

These are the most familiar form of diagram, they capture the
vocabulary of the system: classes and associations
UML Diagrams

Class diagrams are built and refined throughout development at

increasingly lower levels of abstraction

They are primarily used to name and model concepts in the system

They also specify collaborations (relationships) between objects

Note: for the coursework you are asked to provide class diagrams at
two stages, initially at the analysis stage and later at the design stage.
The differences between these will be covered in subsequent
lectures.
SUMMARY
Summary

The key points from today’s lecture are:

• UML provides a way of graphically communicating and describing

key system design concepts.

• There are numerous UML diagram types grouped as structural

and behavioural models. Use the subset of diagrams that works
for you and the system being designed.

• Use cases and scenarios can be used in conjunction with

requirements analysis to help solidify the understanding of a
system.
UML references in the ReadingList

UML distilled, Martin Fowler (print copy only in

library)

Learning UML 2.0, Russ Miles And Kim Hamilton

(online access available)
PGTA meeting this week

Review documented requirements (or user stories)

Review wireframes (if you chose to create them at this stage)

Start to consider which UML models may be useful – though you may
not yet be able to decide this
Reminder of the mid-term coursework

Question 2 Draw a UML use case diagram for the given scenario

Question 4 Draw a UML 2.0 sequence diagram for the given use case.
Practical activities

Worksheet is on Moodle with the following practice activities:

1. Write a use case

2. Draw a use case diagram

3. Draw a sequence diagram

4. Draw an activity diagram

(Class diagrams are covered in more detail in subsequent lectures)

Sample solutions will be made available on Moodle