3. 3
1. Introduction
1.1 A bank has several automated teller machines (ATMs), which
are geographically distributed and connected via a wide area
network to a central server. Each ATM machine has a card
reader, a cash dispenser, a keyboard/display, and a receipt
printer. By using the ATM machine, a customer can withdraw
cash from either checking or savings account, query the balance
of an account, or transfer funds from one account to another. A
transaction is initiated when a customer inserts an ATM card into
the card reader. Encoded on the magnetic strip on the back of
the ATM card are the card number, the start date, and the
expiration date. Assuming the card is recognized, the system
validates the ATM card to determine that the expiration date has
not passed, that the user-entered PIN (personal identification
number) matches the PIN maintained by the system, and that
the card is not lost or stolen. The customer is allowed three
attempts to enter the correct PIN; the card is confiscated if the
third attempt fails. Cards that have been reported lost or stolen
are also confiscated.
4. 4
Introduction
1.2 If the PIN is validated satisfactorily, the customer is
prompted for a withdrawal, query, or transfer transaction.
Before withdrawal transaction can be approved, the system
determines that sufficient funds exist in the requested
account, that the maximum daily limit will not be exceeded,
and that there are sufficient funds available at the local
cash dispenser. If the transaction is approved, the
requested amount of cash is dispensed, a receipt is printed
containing information about the transaction, and the card
is ejected. Before a transfer transaction can be approved,
the system determines that the customer has at least two
accounts and that there are sufficient funds in the account
to be debited. For approved query and transfer requests, a
receipt is printed and card ejected. A customer may cancel
a transaction at any time; the transaction is terminated and
the card is ejected. Customer records, account records,
and debit card records are all maintained at the server.
5. 5
Introduction
1.3 An ATM operator may start up and close down
the ATM to replenish the ATM cash dispenser and
for routine maintenance. It is assumed that
functionality to open and close accounts and to
create, update, and delete customer and debit
card records is provided by an existing system
and is not part of this problem.
6. 6
2. Specific Requirements
2.1 The XYZ Bank Inc. can have many automated
teller machines (ATMs), and the new software
system shall provide functionality on all ATMs.
2.2 The system shall enable the customers of XYZ
Bank Inc., who have valid ATM cards, to perform
three types of transactions;
2.2.1 Withdrawal of funds,
2.2.2 Query of account balance, and
2.2.3 Transfer of funds from one bank account to another
account in the same bank.
7. 7
2. Specific Requirements
2.3 An ATM card usage shall be considered valid if it
meets the following conditions:
a) The card was issued by an authorized bank.
b) The card is used after the start date, i.e., the date
when the card was issued.
c) The card is used before the expiration date, i.e., the
date when the card expires.
d) The card has not been reported lost or stolen by the
customer, who had been issued that card.
e) The customer provides correct personal identification
number (PIN), which matches the PIN maintained by
the system.
8. 8
2. Specific Requirements
2.4 The system shall confiscate the ATM card
if it detects that a lost or stolen card has
been inserted by a customer. (The system
shall also display an apology to the
customer).
2.5 The system shall allow the customer to
enter the correct PIN in no more three
attempts.
2.6 The failure to provide correct PIN in three
attempts shall result in the confiscation of
the ATM card.
9. 9
2. Specific Requirements
2.7 The system shall ask for the transaction
type after satisfactory validation of the
customer PIN.
2.8 The customer shall be given three options,
as type of transaction: withdrawal
transaction, or query transaction, or
transfer transaction.
2.9 If a customer selects withdrawal
transaction, the system shall prompt the
customer to enter account number and
amount to be dispensed.
10. 10
2. Specific Requirements
2.10 For a withdrawal transaction, the system
shall determine:
a). that sufficient funds exist in the requested
account,
b).that the maximum daily limit has not be
exceeded, and
c). that there are sufficient funds available at
the local cash dispenser.
11. 11
2. Specific Requirements
2.11 If a withdrawal transaction is approved, the
requested amount of cash shall be dispensed.
2.11.1. A receipt shall be printed containing
information about the transaction, and
the card shall be ejected.
2.11.2 The information printed on the receipt
includes:
a). transaction number,
b). transaction type,
c).amount withdrawn, and
d).account balance.
12. 12
2. Specific Requirements
2.12 If a customer selects query transaction, the
system shall prompt the customer to enter
account number.
2.13. If a query transaction is approved, the system
shall print a receipt and eject the card.
4.13.1The information contained on the
receipt includes:
a). Transaction number,
b). Transaction type, and
c). Account balance.
13. 13
2. Specific Requirements
2.14. If a customer selects transfer transaction,
the system shall prompt the customer to
enter “From Account” number, “To
Account” number, and amount to be
transferred.
2.15. The system shall check if there are
enough funds available in the “From
Account”, which are being requested for
transfer to the “To Account”.
14. 14
2. Specific Requirements
2.16. If the transfer transaction is approved, a receipt
shall be printed and card shall be ejected.
4.16.1. The information printed on the
receipt includes:
a). Transaction number,
b). Transaction type,
c). Amount transferred, and
d). Account balance.
2.17. The system shall cancel any transaction:
4.17.1 if it has not been completed
4.17.2 if the customer presses the Cancel button
15. 15
2. Specific Requirements
2.18. The customer records, account records,
and debit card records will all be
maintained at the server and shall not be
the responsibility of the system.
2.19. The system shall enable an ATM
operator to shutdown or start up an ATM
for routine maintenance.
16. 16
2. Specific Requirements
2.20. The system shall enable an ATM
operator to add cash to the cash
dispenser.
2.21.The system shall not be responsible for
opening or closing of accounts, and to
create, update, and delete customer and
debit card records. These tasks are
performed elsewhere by a bank.
17. 17
2. Specific Requirements
2.22. The system shall be linked with the bank
server through communication systems,
which are beyond the scope of the current
system. It is assumed that this facility is
always available.
2.23.The system shall not be responsible for
the maintenance of the hardware devices
of the ATM or network facilities.
18. 18
3. UML Model
• 3.1 Use-case model
• 3.2 Object model
• 3.3 Functional model
– 3.3.1 Data-flow model
– 3.3.2 SADT model
• 3.4 Dynamic model
– 3.4.1 State charts
– 3.4.2 sequence Diagram
20. Use-case model
• Customers and end users have goals/needs, and
want computer systems to help meet them,
– There are several ways to capture these goals and
system requirements;
• the better ones are simple and familiar because this makes it
easier—especially for customers and end users—to contribute to
their definition or evaluation.
• Use cases are a mechanism to help keep it simple
and understandable for all stakeholders.
– Informally, they are stories of using a system to meet
goals.
• use case is a list of steps, defining interactions
between a role an "actor" and a system, to achieve
a goal.
20
21. Use-case model
• Use cases are text documents, not diagrams, and
use case modeling is primarily an act of writing, not
drawing.
– The UML defines a use case diagram to illustrate the
names of use cases and actors, and their relationships.
• The beauty of use case:
– it aims at describing a system from external usage
viewpoint, rather than from developer's perspective.
– writing use case can be the deciding factor for building a
system that meets users' needs.
21
22. Use case modeling for ATM
• Use case modeling identifies the use cases
of the system, each representing a different
capability that the system provides to its
clients.
– “View Account Balance”
– “Withdraw Cash”
– “Deposit Funds”
• Each use case describes a typical scenario
for which the user uses the system.
22
23. Example
Use Case 1. Withdraw Money
– The system displays the account types available to be
withdrawn from and the user indicates the desired type.
– The system asks for the amount to be withdrawn and the
user specifies it.
– Next, the system debits the user’s account and
dispenses the money.
– The user removes the money, the system prints a
receipt, and the user removes the receipt.
– Then the system displays a closing message and
dispenses the user’s ATM card.
– After the user removes his card, the system displays the
welcome message.
23
25. 25
Number Unique use case number
Name Brief verb-noun phrase
Summary Brief summary of use case major actions
Priority 1-5 (1 = lowest priority, 5 = highest priority)
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action
Extensions Step Branching Action
Open Issues
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
26. 26
Number
Name
Summary
Priority
Preconditions What needs to be true before the use case “executes”
Postconditions What will be true after the use case successfully “executes”
Primary Actor(s)
Secondary Actor(s)
Trigger
Main Scenario Step Action
Extensions Step Branching Action
Open Issues
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
27. 27
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s) Primary actor name(s)
Secondary Actor(s) Secondary actor name(s)
Trigger
Main Scenario Step Action
Extensions Step Branching Action
Open Issues
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
Actor
• Anyone or anything with
behavior
• May be a person or system
• Primary: The stakeholder
who or which initiates an
interaction with the system to
achieve a goal. Is generally a
category of individuals (a
role).
• Secondary: Provides a
service to the system. Is
almost never a person.
28. 28
Number
Name
Summary
Priority
Preconditions
Postconditions
Primary Actor(s)
Secondary Actor(s)
Trigger The action that caused the use case to be invoked
Main Scenario Step Action
Step # This is the “main success scenario” or “happy path”
Step # Description of steps in successful use case “execution”
Step # This should be in a “system-user-system, etc.” format
Extensions Step Branching Action
Open Issues
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
31. 31
Number Unique use case number
Name Brief noun-verb phrase
Summary Brief summary of use case major actions
Priority 1-5 (1 = lowest priority, 5 = highest priority)
Preconditions What needs to be true before use case “executes”
Postconditions What will be true after the use case successfully “executes”
Primary Actor(s) Primary actor name(s)
Secondary Actor(s) Secondary actor name(s)
Trigger The action that causes this use case to begin
Main Scenario Step Action
Step # This is the “main success scenario” or “happy path.”
… Description of steps in successful use case “execution”
… This should be in a “system-user-system, etc.” format.
Extensions Step Branching Action
Step # Alternative paths that the use case may take
Open Issues Issue # Issues regarding the use case that need resolution
Use Case Specification Template*
*Adapted from A. Cockburn, “Basic Use Case Template”
32. 32
Number 1
Name Withdraw Money
Summary User withdraws money from one of his/her accounts
Priority 5
Preconditions User has logged into ATM
Postconditions User has withdrawn money and received a receipt
Primary Actor(s) Bank Customer
Secondary Actor(s) Customer Accounts Database
Use Case Specification Template Example
Continued
…
33. 33
Trigger User has chosen to withdraw money
Main Scenario Step Action
1 System displays account types
2 User chooses account type
3 System asks for amount to withdraw
4 User enters amount
5 System debits user’s account and dispenses money
6 User removes money
7 System prints and dispenses receipt
8 User removes receipt
9 System displays closing message and dispenses user’s ATM card
11 User removes card
10 System displays welcome message
Extensions Step Branching Action
5a System notifies user that account funds are insufficient
5b System gives current account balance
5c System exits option
Open Issues 1 Should the system ask if the user wants to see the balance?
34. 34
Uses Case Diagram for ATM Customer
ATM
Customer
Withdraw
funds
Query
account
Transfer
funds
Validate
PIN
«include»
«include»
«include»
38. Object modeling
• Object models defines concepts such as:
– class, generic function, message, inheritance,
polymorphism, and encapsulation.
• The purpose of the requirements analysis:
– To establish an understanding of the application domain
and to capture, formalize, analyze and validate the user
requirements on the system to be built.
• For this purpose the system is viewed as a black-box and only
the objects and concepts visible on the system boundary and
outside the system are modeled.
38
39. Object modeling
• A class diagram help to understand the
requirements of the problem domain and to identify
its components
– a class represents an object or a set of objects that share
a common structure and behavior
– a relationship is a connection between model elements
• Class diagrams model the classes, or “building
blocks,” used in a system.
– We create classes only for the nouns and noun phrases
that have significance in the ATM system.
– Classes:
• ATM, screen, keypad, cash dispenser, deposit slot, account,
bank database, balance inquiry, withdrawal and deposit
39
40. 40
Conceptual Static Model for Problem
Domain: Physical Classes
ATM
ATMCustomer
1
CardReader CashDispenser ReceiptPrinter
Operator
Maintains
1 1
1 1 1
ATMCard
1
1
Reads
ATMCash
1
Dispenses
1
Receipt
1
Prints
1
41. 41
Banking System Context Class
Diagram
ATMCustomer
CardReader
CashDispenser
ReceiptPrinter
Banking
System
Operator
Operator
ATM
Customer
1
1
1
1
1
1..*
1..*
1..*
1..*
1
1
1
1
1 1..*
1
1
Interacts
with
44. Data Flow Diagram
• A data flow diagram (DFD) is a graphical
representation of the "flow" of data
– A DFD shows what kinds of information will be input to and
output from the system, where the data will come from and go
to, and where the data will be stored.
– A Level 1 DFD shows some of the detail of the system being
modeled.
– The Level 1 DFD shows how the system is divided into sub-
systems (processes),
• each of which deals with one or more of the data flows to or from an
external agent, and provide all of the functionality of the system as a
whole.
44
46. 46
Data Flow Diagram – Level 1
2
Interface
with
Customer
4
Interface
with
Bank
3
Interface
with
Operator
Operator
Instructions
Operator
Responses
Bank
Requests
Bank
Responses
1
Control
ATM
Inputs
from
Customer
Cash
Receipt
Outputs
to
Customer
ATM Card
and
Transactions
Messages
from
Customer
Interface
Messages to
Customer Interface Messages from
Operator Interface
Messages to
Operator Interface
Messages
to Bank
Interface
Messages
from Bank
Interface
ATM
Cash
47. 47
Level 2 DFD: Interface with Customer
1
Control
ATM
ATM Card
and
Transactions
2.1
Read and
Validate
Card
2.2
Process
User Inputs
and Display
2.3
Dispense
Cash
2.4
Print
Receipt
Cash
Receipt
Card
Info
Transaction
Info
PIN
Cancel Display
Messages
Card
Inserted
Eject
Card
Print
Receipt
ATM
Cash
Dispense
Cash
User Input
Read
Cancelled
Display
Message
Confiscate
Card
49. State Chart Model
• It describes different states of a component in a
system.
– The states are specific to a component/object of a
system.
• used to model dynamic nature of a system
• A State-chart diagram describes a state machine
– To clarify it state machine can be defined as a machine
which defines different states of an object and these
states are controlled by external or internal events.
49
50. 50
Statechart for ATM Control: Validate
PIN Use Case
Idle
Entry / Display
Welcome
Waiting
for PIN
Validating PIN
Waiting for
Customer Choice
1.2: Card Inserted /
1.3: Get PIN
2.4: PIN Entered /
2.5: Validate PIN
2.6: Valid PIN /
2.7: Display Menu,
2.7a: Update Status
58. Acknowledgment
• Chapter 3 - SWEBOK 4th edition
• UML Distilled: A Brief Guide to the Standard Object Modeling Language
by Martin Fowler
• UML 2.0 in a Nutshell by Dan Pilone Design Patterns: Elements of Reusable
Object-Oriented Software By Richard Helm, Ralph Johnson, and John Vlissides
•
58
