UML in Practice - The Art of Modeling Software Systems Demonstrated through Worked Examples and Solutions - Chapter 1 - Aims of the chapter

Oct 25, 2026

Upload by QWQ

UML in Practice presents worked examples to teach how to model software systems using UML, starting from a realistic case study of an automatic teller machine. The chapter focuses on the difficulties of implementing use cases: defining system boundaries, identifying actors, and deriving use cases from service statements. It guides readers to construct use case diagrams, write textual use case descriptions, enrich them with dynamic diagrams, and structure the overall model while emphasizing careful actor identification and the distinction between physical and logical entities.

LanguageEnglish

CategoryTechnology

FormatPDF

Pages34

Reading Time1 h 26 min

AccessFree to download

Aims of the chapter

Case study 1 - Problem statement

Identify the actors, use cases, and diagrams

1.1 Step 1 - Identifying the actors of the ATM

What is an actor in UML

External entities interacting with the ATM

Traps and logical vs physical actors

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 • 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 First, we will identify the actors ofthe ATM system. An actor is a construct employed in use cases that define a role that a user or anyother 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 ofthe ATM. Answer 1.1 What are the external entities that interact directly with the ATM? Let’s look at each of the sentences ofthe 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

FAQs

What is the purpose of the first case study in this chapter?

It illustrates the main difficulties of implementing use cases step by step, including actor identification, system boundary definition, and building UML models from the problem statement.

How do you identify actors for the ATM in step 1?

Actors are external entities with a role in use cases. Readers identify who directly benefits from system use and which external systems authorize or interact with the ATM, while setting the boundary between the system and its environment.

Why should the smartcard and ATM hardware not necessarily be listed as actors?

The text recommends minimizing physical actors in favor of logical actors. Card reader and cash dispenser are part of the ATM, so they are not actors unless the study boundary is restricted; the card itself is external, but the actor should be the card holder who benefits from withdrawing money.

Oct 25, 2026

Upload by QWQ