UML in Practice
The Art of Modeling Software Systems Demonstrated
through Worked Examples and Solutions
Pascal Roques
, 1
Case study: automatic
teller machine 1
Aims of the chapter
By means of the first case study, this chapter will allow us to illustrate the main
difficulties step by step, which are connected to implementing the technique of use
cases.
Once we have identified the actors that interact with the system, we will develop
our first UML model at a system level, in order to be able to establish precisely the
boundaries of the system.
We will then learn how to identify use cases, and how to construct use case
diagrams linking actors and use cases. Then we will see how to specify the
functional view by explaining in detail the different ways in which actors can use
the system. For this goal, we will learn to write textual descriptions as well as to
draw complementary UML diagrams (such as sequence or activity diagrams).
Elements involved
• Actor
• Static context diagram
• Use case
• Use case diagram
• Primary actor, secondary actor
• Textual description of a use case
• Scenario, sequence
• System sequence diagram
• Activity diagram
,4 1 Case study: automatic teller machine
• Inclusion, extension and generalisation of use cases
• Packaging use cases.
Case study 1 – Problem statement
This case study concerns a simplified system of the automatic teller machine
(ATM). The ATM offers the following services:
1. Distribution of money to every holder of a smartcard via a card reader and a
cash dispenser.
2. Consultation of account balance, cash and cheque deposit facilities for bank
customers who hold a smartcard from their bank.
Do not forget either that:
3. All transactions are made secure.
4. It is sometimes necessary to refill the dispenser, etc.
From these four sentences, we will work through the following activities:
• Identify the actors,
• Identify the use cases,
• Construct a use case diagram,
• Write a textual description of the use cases,
• Complete the descriptions with dynamic diagrams,
• Organise and structure the use cases.
Watch out: the preceding problem statement is deliberately incomplete and
imprecise, just as it is in real projects!
Note also that the problem and its solution are based on French banking systems
and the use of smartcards: the system you actually use in your country may be
significantly different! It is not very important. What is important is the way of
thinking to solve this functional problem as well as the UML concepts and
diagrams that we use.
, 1.1 Step 1 – Identifying the actors of the ATM 5
1.1 Step 1 – Identifying the actors of the ATM
First, we will identify the actors of the ATM system.
An actor is a construct employed in use cases that define a role that a user or any
other system plays when interacting with the system under consideration. It is a
type of entity that interacts, but which is itself external to the subject. Actors may
represent human users, external hardware, or other subjects. An actor does not
necessarily represent a specific physical entity. For instance, a single physical entity
may play the role of several different actors and, conversely, a given actor may be
played by multiple physical entities.3
** 1.1 Identify the main actors of the ATM.
Answer 1.1
What are the external entities that interact directly with the ATM?
Let’s look at each of the sentences of the exposition in turn.
Sentence 1 allows us to identify an obvious initial actor straight away: every
“holder of a smartcard”. He or she will be able to use the ATM to withdraw money
using his or her smartcard.
However, be careful: the card reader and cash dispenser constitute part of the
ATM. They can therefore not be considered as actors! You can note down that the
identification of actors requires the boundary between the system being studied
and its environment to be set out exactly. If we restrict the study to the control/
command system of physical elements of the ATM, the card reader and cash
dispenser then become actors.
Another trap: is the smartcard itself an actor? The card is certainly external to the
ATM, and it interacts with it... Yet, we do not recommend that you list it as an actor,
as we are putting into practice the following principle: eliminate “physical” actors
as much as possible to the advantage of “logical” actors. The actor is the who or
what that benefits from using the system. It is the card holder who withdraws
money to spend it, not the card itself!
Sentence 2 identifies additional services that are only offered to bank customers
who hold a smartcard from this bank. This is therefore a different profile from the
previous one, which we will realise by a second actor called Bank customer.
Sentence 3 encourages us to take into account the fact that all transactions are
made secure. But who makes them secure? There are therefore other external
entities, which play the role of authorisation system and with which the ATM
3. From the OMG document: “Unified Modeling Language: Superstructure (version 2.0)”.
The Art of Modeling Software Systems Demonstrated
through Worked Examples and Solutions
Pascal Roques
, 1
Case study: automatic
teller machine 1
Aims of the chapter
By means of the first case study, this chapter will allow us to illustrate the main
difficulties step by step, which are connected to implementing the technique of use
cases.
Once we have identified the actors that interact with the system, we will develop
our first UML model at a system level, in order to be able to establish precisely the
boundaries of the system.
We will then learn how to identify use cases, and how to construct use case
diagrams linking actors and use cases. Then we will see how to specify the
functional view by explaining in detail the different ways in which actors can use
the system. For this goal, we will learn to write textual descriptions as well as to
draw complementary UML diagrams (such as sequence or activity diagrams).
Elements involved
• Actor
• Static context diagram
• Use case
• Use case diagram
• Primary actor, secondary actor
• Textual description of a use case
• Scenario, sequence
• System sequence diagram
• Activity diagram
,4 1 Case study: automatic teller machine
• Inclusion, extension and generalisation of use cases
• Packaging use cases.
Case study 1 – Problem statement
This case study concerns a simplified system of the automatic teller machine
(ATM). The ATM offers the following services:
1. Distribution of money to every holder of a smartcard via a card reader and a
cash dispenser.
2. Consultation of account balance, cash and cheque deposit facilities for bank
customers who hold a smartcard from their bank.
Do not forget either that:
3. All transactions are made secure.
4. It is sometimes necessary to refill the dispenser, etc.
From these four sentences, we will work through the following activities:
• Identify the actors,
• Identify the use cases,
• Construct a use case diagram,
• Write a textual description of the use cases,
• Complete the descriptions with dynamic diagrams,
• Organise and structure the use cases.
Watch out: the preceding problem statement is deliberately incomplete and
imprecise, just as it is in real projects!
Note also that the problem and its solution are based on French banking systems
and the use of smartcards: the system you actually use in your country may be
significantly different! It is not very important. What is important is the way of
thinking to solve this functional problem as well as the UML concepts and
diagrams that we use.
, 1.1 Step 1 – Identifying the actors of the ATM 5
1.1 Step 1 – Identifying the actors of the ATM
First, we will identify the actors of the ATM system.
An actor is a construct employed in use cases that define a role that a user or any
other system plays when interacting with the system under consideration. It is a
type of entity that interacts, but which is itself external to the subject. Actors may
represent human users, external hardware, or other subjects. An actor does not
necessarily represent a specific physical entity. For instance, a single physical entity
may play the role of several different actors and, conversely, a given actor may be
played by multiple physical entities.3
** 1.1 Identify the main actors of the ATM.
Answer 1.1
What are the external entities that interact directly with the ATM?
Let’s look at each of the sentences of the exposition in turn.
Sentence 1 allows us to identify an obvious initial actor straight away: every
“holder of a smartcard”. He or she will be able to use the ATM to withdraw money
using his or her smartcard.
However, be careful: the card reader and cash dispenser constitute part of the
ATM. They can therefore not be considered as actors! You can note down that the
identification of actors requires the boundary between the system being studied
and its environment to be set out exactly. If we restrict the study to the control/
command system of physical elements of the ATM, the card reader and cash
dispenser then become actors.
Another trap: is the smartcard itself an actor? The card is certainly external to the
ATM, and it interacts with it... Yet, we do not recommend that you list it as an actor,
as we are putting into practice the following principle: eliminate “physical” actors
as much as possible to the advantage of “logical” actors. The actor is the who or
what that benefits from using the system. It is the card holder who withdraws
money to spend it, not the card itself!
Sentence 2 identifies additional services that are only offered to bank customers
who hold a smartcard from this bank. This is therefore a different profile from the
previous one, which we will realise by a second actor called Bank customer.
Sentence 3 encourages us to take into account the fact that all transactions are
made secure. But who makes them secure? There are therefore other external
entities, which play the role of authorisation system and with which the ATM
3. From the OMG document: “Unified Modeling Language: Superstructure (version 2.0)”.
