TV1 – Case Study: Automated Banking System

Software Engineering
Computer Science
Academic Year 2023/2024

Gerard Albà Soler

1
 ATM Case Study
We are going to look at modeling with UML by using a case study of an Automated
Banking System:
• Clients may take money from their accounts, deposit money or ask for their
current balance.
• All these operations are accomplished using either automatic taller machines
(ATM) or counter tellers.
• Transactions on an account may be done by cheque, standing order or using the
teller machine and card.
• There are two kinds of account: savings accounts and chequing accounts.
• Savings accounts give interest and cannot be accessed by the automatic tellers.
• When a cheque is deposited it must be cleared before the funds can be used by
the depositor.
 ATM Case Study: Use Case model
• Object-oriented development methods take a user-oriented approach to system development.
• We identify the users of the system and the tasks that they require the system to perform (functional
analysis). These are the uses cases, or use case modeling.
• UML uses the term actor. An actor is the role played by a user.
• We represent the use cases graphically in a use case diagram:
ü It consists of actors and the use cases with which they are involved.
ü Each use case is given a natural language description.
ü Several other use cases can be added to the diagram.
• A use case documents some behaviour that the actor needs from the system.
• Use cases enable the informal requirements to be reformulated in a more structured manner. The set
of use cases are the set of requirements as seen by the users of the system.
• Object-oriented modelling is primarily concerned with modelling the underlying system. We will not
include here the user (GUI) interface/front-end in the system we are developing. Remember that the
boundaries of the system can change depending on the detail/application of our software system.
ATM Case Study: Questions

Question 1: Use Cases

• Draw the Use Case Diagram in UML for this automated banking system.
• Write the textual description of the use cases (Remember: they must be
written in terms of what the user expects the system to do rather than as a
passive description of what has to be done).
 ATM Case Study: Classes and Objects
• The next step in the modeling is identifying the classes in the static analysis of our system
domain (or the objects, at this level of abstraction).

• As a first step, we can take our informal requirements and identify the nouns or noun phrases,
i.e. identify the words that potentially represent things in our system.
• Some objects are fairly easy to identify, while others are more difficult. Identifying nouns in
the informal requirements is a good way of identifying domain objects, i.e. objects that
belong to the problem.
• When considering a problem, it is often easier to think initially in terms of objects rather than
classes. Humans tend to think in terms of a Volkswagen car, i.e. an object rather than in terms
of the class Volkswagen car. Remember to translate typical objects or real things into classes.
• You can also identify, in some cases, several classes which are specialisations (subclass) that
can be generalised (superclass) if they have properties in common. You can use the concepts
of OOP learned in Module2 of this course.
 ATM Case Study: Class Diagram
• We can now use these classes to build an
initial class diagram in UML.

• We have not yet identified many

attributes or operations; that can come
later.

• An important part of the class diagram is

the associations that exist between
objects of a class.
• We can give the multiplicity of these
associations and also attach a label to
them to indicate how they relate to each
other.
ATM Case Study: Questions
Question 2: Class Diagram

• Explain the classes of the suggested class diagram on the previous slide:

ü Relationship with objects of the problem domain and the requirements.

Relate use cases to this initial class diagram.
ü Object-Oriented concepts: like inheritance, abstraction, etc

ü Other associations between classes

ü Etc
ATM Case Study: interaction diagrams
• The class diagram shows the static structure of the system, but does not show its dynamic
behaviour, i.e. how objects interact to carry out some task. UML has interaction diagrams
to show how objects can communicate with one another.
• Sequence diagrams in particular, can represent scenarios, i.e. sequences of events which
show a particular system behaviour. Sequence diagrams can be useful to:
ü better understand and specify what may happen in a use case.
ü help us identify the operations offered by each object.
ü help us identify new classes that are required to support the behaviour.
• As interaction diagrams are dealing with behaviour, they are presented in terms of objects
rather than classes (interaction happens through method calls).
• We can also represent actors as objects in a sequence diagram.
• Later in the design phase, we are likely to identify more objects within the system and
interactions between these objects.
 ATM Case Study: Sequence diagrams
• The next step is to create sequence diagrams to show
the scenarios that can result from the use cases. Hence
sequence diagrams are developed from use cases.
• Let us now consider one of the use cases: “deposit cash
with counter teller”.
• A customer gives cash to a counter teller. The counter
teller enters the amount and the account number. The
system updates the account and issues a receipt.
• This is a use case very simple and sequence diagram.
• Remember that a class shows the operations offered by
that class. It does not show the operations called by its
objects. We show object calls in a sequence diagram. An
arrow to an object in a sequence diagram shows a call of
an operation offered by the object while an arrow from
the object shows a call made by the object.
 ATM Case Study: Sequence diagrams

• A sequence diagram shows the objects that take part in

a scenario and the messages that are sent between
them.
• The vertical axis represents time, and so the order in
which the messages are sent is specified.
• Each object has a vertical column; its lifeline. While the
object exists, it is shown by a dashed line.
• While the activation of a method in the object is active,
it is shown by a double line.
 ATM Case Study: Sequence diagrams
• To show how sequence diagrams can help us identify classes and operations,
consider now a more complex use case of our system: ”deposit cheque with
counter taller”.
• A customer deposits a cheque with a counter teller. The systems reads the
information on a cheque and updates the appropriate chequing account.
• However, the system does not confirm the updating of the account until the
cheque has been cleared, i.e. until the system has checked that there are sufficient
funds in the account on which the cheque is drawn. This may involve the system
sending a message to another bank.
ATM Case Study: Sequence diagrams
 ATM Case Study: Sequence diagrams
• It seems likely that we will need a cheque object. The purpose of the Cheque object is to
coordinate activity (it is also called a control class):
ü to communicate with the Account object and
ü to send a message to another bank via the ToBank (bounday) class.
• Note that in creating this use case and associated sequence diagram, we have identified new
classes: the control class ChequeC and the boundary class ToBank through which we can check
that the other account has sufficient funds.
• We also identify operations such as perhapsDeposit and confirmDeposit and note that Account
will need to have an extra attribute to hold the amount deposited by cheques (Although we can
only write cheques drawn on a chequing account, we can pay cheques into any kind of account.)
• We also identify another use case: “check funds for issued cheque”.
• Our bank must be able to deal with the case where another bank checks if one of our accounts
has sufficient funds and if so we debit the account. Dealing with the new use case may lead to the
discovery of further classes. It could also lead to another sequence diagram where information is
sent from another bank.
 ATM Case Study: Sequence diagrams
• We can now add the
information from these
sequence diagrams to
expand the initial class
diagram.
• Note how we are
incrementally adding to our
understanding of the
problem and dealing in
parallel with static and
dynamic:
ü use cases,
ü sequence diagrams,
ü and the class diagram.
ATM Case Study: Questions
Question 3: Sequence Diagram

• Draw and analyze a new sequence diagram corresponding to the use case
“withdraw cash from the ATM”

ü Explain the objects, responsibilities (purpose of the object) and

operations of the objects involved.
ü These should be also included in the static class diagram. Check that
this is already the case, or include whatever you think could be useful.
 ATM Case Study: Activity diagrams
Aspect Sequence Diagram Activity Diagram

Represents the interaction between objects in a particular Illustrates the flow of activities or processes within a system,
Purpose
sequence or scenario. including decision points and parallel activities.

Emphasizes the order of messages exchanged among Focuses on the flow of actions or activities within the
Focus
objects over time. system, often showing concurrent and parallel behaviors.

Typically consists of lifelines (representing objects), Utilizes nodes (representing actions or activities), transitions
Notation
messages, and activations. (depicting flow), and decision points (showing branching).

Usually depicts detailed interactions at the level of method Offers a broader view, showcasing high-level processes and
Granularity
calls or system events. activities without intricate method-level detail.

Shows the chronological order of events, with time Does not necessarily represent time explicitly; rather, it
Time Representation
progressing from top to bottom. focuses on the logical flow of activities.

Limited capability for representing decision points, often Allows for explicit representation of decision points, loops,
Decision Making
depicted with combined fragments. and parallel activities using control nodes.

Ideal for modeling cases involving multiple objects and Suited for modeling complex processes, business workflows,
Use Cases their interactions, such as system sequences or or system behaviors involving multiple steps and decision
collaborations. points.
ATM Case Study: Questions
Question 4: Activity Diagram
• The next UML diagram shows a business
process of our system.

• Explain the elements of the diagram and how it

relates to our problem domain.

• What are the differences with other sequence

diagrams used in this case study? Why do you
think activity diagrams can be useful when
dealing with the dynamic analysis of the system.

• What other activity diagrams could be useful to

do for the analysis and description of the
behavior our system?