CASL S1uu?

A1M
Introduction
What you will Find Here
This page is the starting point into a series oI pages that attempt to give a complete example oI
object-oriented analysis, and design, applied to a moderate size problem: the simulation oI an
Automated Teller Machine. You will be beneIited Irom seeing a complete example oI OO
methodology applied to a single problem.
Beginning with a statement oI requirements, the process proceeds through analysis, overall
design, and detailed design and implementation, culminating with some suggestions Ior
maintenance.
Analysis is done by identiIying the use cases and detailing a Ilow oI events Ior each. Also, an
initial set oI Iunctional test cases is speciIied, to serve as a vehicle Ior checking that the
implementation is complete and basically correct. Analysis culminates in identiIying classes
implied by the use cases, and documenting them using an Analysis Class Diagram. (The State
chart diagrams done under design are also, in part, analysis tasks. In OO, the line between
analysis and design is not always a sharp one.)
Overall design begins by using C|ass kespons|b|||ty Co||aborat|on (CRC) cards to assign
responsibilities to various classes. The static structure oI the design is summarized by means oI
an overall Class Diagram. Then the dynamic aspects oI the design are developed, using State
Charts Ior the major controller classes, plus an Interaction Diagram Ior each oI the main use
cases.
The detailed design is developed by spelling out the attributes and methods Ior each class, using
a class diagram Ior each class with all three "compartments" Iully Iilled in. A package diagram is
used to show how the various classes are grouped into packages
Using these Pages
Probably the best way to start using these pages is to Iirst read the requirements, and then work
through the entire analysis, design, and implementation process.
1. Begin with the Statement oI Requirements and then view the Use Cases. The Use Case
document has a Use Case Diagram and a series oI Ilows oI events, one Ior each use
case. The analysis phase can be studied both in terms oI the "big picture" and in terms
oI the details oI the use cases.
4 BeIore studying the Ilows oI events in detail, it might be helpIul to look at the
diagram showing the Analysis classes to get an overall view oI the system
implicit in the use cases. The Analysis Class Diagram captures the basic class
structure implied by the use case Ilows oI events.
4 Then it is time to study the Ilows oI events in detail.

2. Having looked at the requirements/analysis documents, you can then study the design
phase by viewing the CRC cards, the overall Class Diagram, and the State chart and
Interaction Diagrams.
4 There is one CRC card Ior each class, incorporating all responsibilities oI the
class arising Irom all oI the use cases, linked to Irom the icon Ior the class in
either Class Diagram. The CRC cards were created by "walking through" each use
case, assigning the responsibility Ior each task to some class. Note that there are
CRC cards Ior classes that do not appear in the Analysis Class Diagram; the need
Ior these classes became apparent as the other cards were being created. (This is
typical; Booch suggests that the ratio oI classes in a complete application to
analysis classes may be as much as 5:1; in this particular case, it is about 2:1.)
4 The Class Diagram pulls together all oI the structural inIormation Irom the CRC
Cards and shows the needed links between classes. Each class icon is linked to
other relevant design documents, including a detailed design Ior that class.
4 or the major controller classes, there is also a State chart diagram depicting the
various states the corresponding object can be in. This, too, is accessible Irom the
class's icon in either Class Diagram.
4 inally, there is one Interaction diagram Ior each use case, linked to Irom the use
case Ilow oI events. This shows the objects that work together to realize the use
case, and the Ilow oI messages between them. This records the same assignment
oI responsibilities as in the CRC cards, but in a diIIerent way (organized by use
case, rather than by class), with additional detail. (These, rather than the CRC
cards, were actually used when creating the detailed design. CRC cards are not
actually a UML diagram, but are a useIul tool to help in discovering the design
that does get recorded in UML Interaction diagrams.)
In terms oI the order in which these would be created, the Analysis Class Diagram and
the CRC cards (CRC Cards are optional) would be done Iirst, then the overall Class
Diagram, and Iinally the Statechart and Interaction Diagrams. Thus, to understand the
design process, these could be read in the order they were created. However, in terms oI
understanding the design itselI, it may be desirable to read the Class Diagram Iirst.
#equirements Statement for Example ATM System
The soItware to be designed will control a simulated automated teller machine (ATM) having a
magnetic stripe reader Ior reading an ATM card, a customer console (keyboard and display) Ior
interaction with the customer, a slot Ior depositing envelopes, a dispenser Ior cash (in multiples
oI 20), a printer Ior printing customer receipts, and a key-operated switch to allow an operator to
start or stop the machine. The ATM will communicate with the bank's computer over an
appropriate communication link. (The soItware on the latter is not part oI the requirements Ior
this problem.)
The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identiIication number (PIN) - both oI which will be sent to the bank Ior
validation as part oI each transaction. The customer will then be able to perIorm one or more
transactions. The card will be retained in the machine until the customer indicates that he/she
desires no Iurther transactions, at which point it will be returned - except as noted below.
The ATM must be able to provide the Iollowing services to the customer:
1. A customer must be able to make a cash withdrawal Irom any suitable account linked to
the card, in multiples oI $20.00. Approval must be obtained Irom the bank beIore cash is
dispensed.
2. A customer must be able to make a deposit to any account linked to the card, consisting
oI cash and/or checks in an envelope. The customer will enter the amount oI the deposit
into the ATM, subject to manual veriIication when the envelope is removed Irom the
machine by an operator. Approval must be obtained Irom the bank beIore physically
accepting the envelope.
3. A customer must be able to make a transIer oI money between any two accounts linked to
the card.
4. A customer must be able to make a balance inquiry oI any account linked to the card.
A customer must be able to abort a transaction in progress by pressing the Cancel key instead oI
responding to a request Irom the machine.
The ATM will communicate each transaction to the bank and obtain veriIication that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it
has been approved. In the case oI a deposit, a second message will be sent to the bank indicating
that the customer has deposited the envelope. (II the customer Iails to deposit the envelope
within the timeout period, or presses cancel instead, no second message will be sent to the bank
and the deposit will not be credited to the customer.)
II the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN beIore a transaction can proceed. II the customer is unable to successIully enter the
PIN aIter three tries, the card will be permanently retained by the machine, and the customer will
have to contact the bank to get it back.
II a transaction Iails Ior any reason other than an invalid PIN, the ATM will display an
explanation oI the problem, and will then ask the customer whether he/she wants to do another
transaction.
The ATM will provide the customer with a printed receipt Ior each successIul transaction,
showing the date, time, machine location, type oI transaction, account(s), amount, and ending
and available balance(s) oI the aIIected account ("to" account Ior transIers).
The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing oI customers. AIter turning the switch to the "on" position, the operator will be
required to veriIy and enter the total cash on hand. The machine can only be turned oII when it is
not servicing a customer. When the switch is moved to the "oII" position, the machine will shut
down, so that the operator may remove deposit envelopes and reload the machine with cash,
blank receipts, etc.
The ATM will also maintain an internal log oI transactions to Iacilitate resolving ambiguities
arising Irom a hardware Iailure in the middle oI a transaction. Entries will be made in the log
when the ATM is started up and shut down, Ior each message sent to the Bank (along with the
response back, iI one is expected), Ior the dispensing oI cash, and Ior the receiving oI an
envelope. Log entries may contain card numbers and dollar amounts, but Ior security will 3ever
contain a PIN.
Use Cases for Example ATM System

(Click on a use case above to go to the flow of events for that use case)

Flows of Events for Individual Use Cases

System Startup Use Case
The system is started up when the operator turns the operator switch to the "on" position. The
operator will be asked to enter the amount oI money currently in the cash dispenser, and a
connection to the bank will be established. Then the servicing oI customers can begin.
| Interaction Diagram |

System Shutdown Use Case
The system is shut down when the operator makes sure that no customer is using the machine,
and then turns the operator switch to the "oII" position. The connection to the bank will be shut
down. Then the operator is Iree to remove deposited envelopes, replenish cash and paper, etc.
| Interaction Diagram |

Session Use Case
A session is started when a customer inserts an ATM card into the card reader slot oI the
machine. The ATM pulls the card into the machine and reads it. (II the reader cannot read the
card due to improper insertion or a damaged stripe, the card is ejected, an error screen is
displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then
allowed to perIorm one or more transactions, choosing Irom a menu oI possible types oI
transaction in each case. AIter each transaction, the customer is asked whether he/she would like
to perIorm another. When the customer is through perIorming transactions, the card is ejected
Irom the machine and the session ends. II a transaction is aborted due to too many invalid PIN
entries, the session is also aborted, with the card being retained in the machine.
The customer may abort the session by pressing the Cancel key when entering a PIN or choosing
a transaction type.
| Interaction Diagram |

Transaction Use Case
ote. Tra3sactio3 is a3 abstract ge3erali:atio3 Each specific co3crete type of tra3sactio3
impleme3ts certai3 operatio3s i3 the appropriate way The flow of eve3ts give3 here describes
the behavior commo3 to all types of tra3sactio3 The flows of eve3ts for the i3dividual types of
tra3sactio3 (withdrawal, deposit, tra3sfer, i36uiry) give the features that are specific to that type
of tra3sactio3
A transaction use case is started within a session when the customer chooses a transaction type
Irom a menu oI options. The customer will be asked to Iurnish appropriate details (e.g.
account(s) involved, amount). The transaction will then be sent to the bank, along with
inIormation Irom the customer's card and the PIN the customer entered.
II the bank approves the transaction, any steps needed to complete the transaction (e.g.
dispensing cash or accepting an envelope) will be perIormed, and then a receipt will be printed.
Then the customer will be asked whether he/she wishes to do another transaction.
II the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be
perIormed and then an attempt will be made to continue the transaction. II the customer's card is
retained due to too many invalid PINs, the transaction will be aborted, and the customer will not
be oIIered the option oI doing another.
II a transaction is cancelled by the customer, or Iails Ior any reason other than repeated entries oI
an invalid PIN, a screen will be displayed inIorming the customer oI the reason Ior the Iailure oI
the transaction, and then the customer will be oIIered the opportunity to do another.
The customer may cancel a transaction by pressing the Cancel key as described Ior each
individual type oI transaction below.
All messages to the bank and responses back are recorded in the ATM's log.
| Interaction Diagram |

Withdrawal Transaction Use Case
A withdrawal transaction asks the customer to choose a type oI account to withdraw Irom (e.g.
checking) Irom a menu oI possible accounts, and to choose a dollar amount Irom a menu oI
possible amounts. The system veriIies that it has suIIicient money on hand to satisIy the request
beIore sending the transaction to the bank. (II not, the customer is inIormed and asked to enter a
diIIerent amount.) II the transaction is approved by the bank, the appropriate amount oI cash is
dispensed by the machine beIore it issues a receipt. (The dispensing oI cash is also recorded in
the ATM's log.)
A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time
prior to choosing the dollar amount.
| Interaction Diagram |

eposit Transaction Use Case
A deposit transaction asks the customer to choose a type oI account to deposit to (e.g. checking)
Irom a menu oI possible accounts, and to type in a dollar amount on the keyboard. The
transaction is initially sent to the bank to veriIy that the ATM can accept a deposit Irom this
customer to this account. II the transaction is approved, the machine accepts an envelope Irom
the customer containing cash and/or checks beIore it issues a receipt. Once the envelope has been
received, a second message is sent to the bank, to conIirm that the bank can credit the customer's
account - contingent on manual veriIication oI the deposit envelope contents by an operator later.
(The receipt oI an envelope is also recorded in the ATM's log.)
A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to
inserting the envelope containing the deposit. The transaction is automatically cancelled iI the
customer Iails to insert the envelope containing the deposit within a reasonable period oI time
aIter being asked to do so.
| Interaction Diagram |

Transfer Transaction Use Case
A transIer transaction asks the customer to choose a type oI account to transIer Irom (e.g.
checking) Irom a menu oI possible accounts, to choose a diIIerent account to transIer to, and to
type in a dollar amount on the keyboard. No Iurther action is required once the transaction is
approved by the bank beIore printing the receipt.
A transIer transaction can be cancelled by the customer pressing the Cancel key any time prior to
entering a dollar amount.
| Interaction Diagram |

Inquiry Transaction Use Case
An inquiry transaction asks the customer to choose a type oI account to inquire about Irom a
menu oI possible accounts. No Iurther action is required once the transaction is approved by the
bank beIore printing the receipt.
An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior
to choosing the account to inquire about.
| Interaction Diagram |

Invalid PIN Extension
An invalid PIN extension is started Irom within a transaction when the bank reports that the
customer's transaction is disapproved due to an invalid PIN. The customer is required to re-enter
the PIN and the original request is sent to the bank again. II the bank now approves the
transaction, or disapproves it Ior some other reason, the original use case is continued; otherwise
the process oI re-entering the PIN is repeated. Once the PIN is successIully re-entered, it is used
Ior both the current transaction and all subsequent transactions in the session. II the customer
Iails three times to enter the correct PIN, the card is permanently retained, a screen is displayed
inIorming the customer oI this and suggesting he/she contact the bank, and the entire customer
session is aborted.
II the customer presses Cancel instead oI re-entering a PIN, the original transaction is cancelled.
| Interaction Diagram |



Initial Functional Test Cases for Example ATM System
The Iollowing initial test cases can be identiIied early in the design process as a vehicle Ior
checking that the implementation is basically correct. o attempt has bee3 made at this poi3t to
do thorough testi3g, i3cludi3g all possible errors a3d bou3dary cases That needs to come later.
These cases represent an initial check that the Iunctionality speciIied by the use cases is present.
Some writers would argue Ior developing test cases like these i3 place of use cases. Here, they
are presented as a vehicle Ior "Ileshing out" the use cases, not as a substitute Ior them.
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
System
Startup
System accepts
initial cash amount
System is
requesting cash
amount
Enter a legitimate
amount
System is on
System
Startup
Connection to the
bank is established
System has just
been turned on
PerIorm a
legitimate inquiry
System output should
demonstrate that a
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
transaction connection has been
established to the
Bank
System
Shutdown
System is shut down
when the switch is
turned "oII"
System is on and
not servicing a
customer
Activate the "oII"
switch
System is oII
System
Shutdown
Connection to the
Bank is terminated
when the system is
shut down
System has just
been shut down

VeriIy Irom the bank
side that a connection
to the ATM no longer
exists
Session
System reads a
customer's ATM
card
System is on and
not servicing a
customer
Insert a readable
card
Card is accepted;
System asks Ior entry
oI PIN
Session
System rejects an
unreadable card
System is on and
not servicing a
customer
Insert an
unreadable card
Card is ejected;
System displays an
error screen;
System is ready to
start a new session
Session
System accepts
customer's PIN
System is asking
Ior entry oI PIN
Enter a PIN
System displays a
menu oI transaction
types
Session
System allows
customer to perIorm
a transaction
System is
displaying menu
oI transaction
types
PerIorm a
transaction
System asks whether
customer wants
another transaction
Session
System allows
multiple transactions
in one session
System is asking
whether customer
wants another
transaction
Answer yes
System displays a
menu oI transaction
types
Session
Session ends when
customer chooses
not to do another
transaction
System is asking
whether customer
wants another
transaction
Answer no
System ejects card
and is ready to start a
new session
Transaction
Individual types oI
transaction will be
tested below

Transaction System handles an A readable card Enter an incorrect The Invalid PIN
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
invalid PIN properly has been entered PIN and then
attempt a
transaction
Extension is
perIormed
Withdrawal
System asks
customer to choose
an account to
withdraw Irom
Menu oI
transaction types
is being displayed
Choose
Withdrawal
transaction
System displays a
menu oI account
types
Withdrawal
System asks
customer to choose a
dollar amount to
withdraw
Menu oI account
types is being
displayed
Choose checking
account
System displays a
menu oI possible
withdrawal amounts
Withdrawal
System perIorms a
legitimate
withdrawal
transaction properly
System is
displaying the
menu oI
withdrawal
amounts
Choose an amount
that the system
currently has and
which is not
greater than the
account balance
System dispenses this
amount oI cash;
System prints a
correct receipt
showing amount and
correct updated
balance;
System records
transaction correctly
in the log (showing
both message to the
bank and approval
back)
Withdrawal
System veriIies that
it has suIIicient cash
on hand to IulIill the
request
System has been
started up with
less than the
maximum
withdrawal
amount in cash on
hand;
System is
requesting a
withdrawal
amount
Choose an amount
greater than what
the system
currently has
System displays an
appropriate message
and asks customer to
choose a diIIerent
amount
Withdrawal
System veriIies that
customer's balance is
suIIicient to IulIill
System is
requesting a
withdrawal
Choose an amount
that the system
currently has but
System displays an
appropriate message
and oIIers customer
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
the request ammount which is greater
than the account
balance
the option oI
choosing to do
another transaction or
not.
Withdrawal
A withdrawal
transaction can be
cancelled by the
customer any time
prior to choosing the
dollar amount
System is
displaying menu
oI account types
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Withdrawal
A withdrawal
transaction can be
cancelled by the
customer any time
prior to choosing the
dollar amount
System is
displaying menu
oI dollar amounts
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Deposit
System asks
customer to choose
an account to deposit
to
Menu oI
transaction types
is being displayed
Choose Deposit
transaction
System displays a
menu oI account
types
Deposit
System asks
customer to enter a
dollar amount to
deposit
Menu oI account
types is being
displayed
Choose checking
account
System displays a
request Ior the
customer to type a
dollar amount
Deposit
System asks
customer to insert an
envelope
System is
displaying a
request Ior the
customer to type
a dollar amount
Enter a legitimate
dollar amount
System requests that
customer insert an
envelope
Deposit
System perIorms a
legitimate deposit
transaction properly
System is
requesting that
customer insert
an envelope
Insert an envelope
System accepts
envelope;
System prints a
correct receipt
showing amount and
correct updated
balance;
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
System records
transaction correctly
in the log (showing
message to the bank,
approval back, and
acceptance oI the
envelope)
Deposit
A deposit transaction
can be cancelled by
the customer any
time prior to
inserting an envelope
System is
displaying menu
oI account types
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Deposit
A deposit transaction
can be cancelled by
the customer any
time prior to
inserting an envelope
System is
requesting
customer to enter
a dollar amount
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Deposit
A deposit transaction
can be cancelled by
the customer any
time prior to
inserting an envelope
System is
requesting
customer to insert
an envelope
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Deposit
A deposit transaction
is cancelled
automatically iI an
envelope is not
inserted within a
reasonable time
System is
requesting
customer to insert
an envelope
Wait Ior the
request to time out
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
TransIer
System asks
customer to choose
an account to
Menu oI
transaction types
is being displayed
Choose TransIer
transaction
System displays a
menu oI account
types speciIying
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
transIer Irom transIer Irom
TransIer
System asks
customer to choose
an account to
transIer to
Menu oI account
types to transIer
Irom is being
displayed
Choose checking
account
System displays a
menu oI account
types speciIying
transIer to
TransIer
System asks
customer to enter a
dollar amount to
transIer
Menu oI account
types to transIer
to is being
displayed
Choose savings
account
System displays a
request Ior the
customer to type a
dollar amount
TransIer
System perIorms a
legitimate transIer
transaction properly
System is
displaying a
request Ior the
customer to type
a dollar amount
Enter a legitimate
dollar amount
System prints a
correct receipt
showing amount and
correct updated
balance;
System records
transaction correctly
in the log (showing
both message to the
bank and approval
back)
TransIer
A transIer
transaction can be
cancelled by the
customer any time
prior to entering
dollar amount
System is
displaying menu
oI account types
speciIying
transIer Irom
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
TransIer
A transIer
transaction can be
cancelled by the
customer any time
prior to entering
dollar amount
System is
displaying menu
oI account types
speciIying
transIer to
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
TransIer
A transIer
transaction can be
cancelled by the
customer any time
System is
requesting
customer to enter
a dollar amount
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
prior to entering
dollar amount
choosing to do
another transaction or
not.
Inquiry
System asks
customer to choose
an account to inquire
about
Menu oI
transaction types
is being displayed
Choose Inquiry
transaction
System displays a
menu oI account
types
Inquiry
System perIorms a
legitimate inquiry
transaction properly
System is
displaying menu
oI account types
Choose checking
account
System prints a
correct receipt
showing correct
balance;
System records
transaction correctly
in the log (showing
both message to the
bank and approval
back)
Inquiry
An inquiry
transaction can be
cancelled by the
customer any time
prior to choosing an
account
System is
displaying menu
oI account types
Press "Cancel" key
System displays an
appropriate message
and oIIers customer
the option oI
choosing to do
another transaction or
not.
Invalid PIN
Extension
Customer is asked to
reenter PIN

Enter an incorrect
PIN;
Attempt an inquiry
transaction on the
customer's
checking account
Customer is asked to
re-enter PIN
Invalid PIN
Extension
Correct re-entry oI
PIN is accepted
Request to re-
enter PIN is being
displayed
Enter correct PIN
Original transaction
completes
successIully
Invalid PIN
Extension
A correctly re-
entered PIN is used
Ior subsequent
transactions
An incorrect PIN
has been re-
entered and
transaction
completed
PerIorm another
transaction
This transaction
completes
successIully as well
Use Case
Function Being
Tested
Initial System
State
Input Expected Output
System
Startup
System is started
when the switch is
turned "on"
System is oII
Activate the "on"
switch
System requests
initial cash amount
normally
Invalid PIN
Extension
Incorrect re-entry oI
PIN is not accepted
Request to re-
enter PIN is being
displayed
Enter incorrect
PIN
An appropriate
message is displayed
and re-entry oI the
PIN is again
requested
Invalid PIN
Extension
Correct re-entry oI
PIN on the second
try is accepted
Request to re-
enter PIN is being
displayed
Enter incorrect
PIN the Iirst time,
then correct PIN
the second time
Original transaction
completes
successIully
Invalid PIN
Extension
Correct re-entry oI
PIN on the third try
is accepted
Request to re-
enter PIN is being
displayed
Enter incorrect
PIN the Iirst time
and second times,
then correct PIN
the third time
Original transaction
completes
successIully
Invalid PIN
Extension
Three incorrect re-
entries oI PIN result
in retaining card and
aborting transaction
Request to re-
enter PIN is being
displayed
Enter incorrect
PIN three times
An appropriate
message is displayed;
Card is retained by
machine;
Session is terminated

Analysis Classes
An initial reading oI the use cases suggests that the Iollowing will be part oI the system.
O A conLroller ob[ecL represenLlng Lhe A1M lLself (managlng Lhe boundary ob[ecLs llsLed below)

O oundary ob[ecLs represenLlng Lhe lndlvldual componenL parLs of Lhe A1M

4 peraLor panel
4 Card reader
4 CusLomer console conslsLlng of a dlsplay and keyboard
4 -eLwork connecLlon Lo Lhe bank
4 Cash dlspenser
4 Lnvelope accepLor
4 ecelpL prlnLer


O ConLroller ob[ecLs correspondlng Lo use cases (-oLe class A1M can handle Lhe SLarLup and
ShuLdown use cases lLself so Lhese do noL glve rlse Lo separaLe ob[ecLs here)

4 Sesslon
4 1ransacLlon (absLracL generallzaLlon responslble for common feaLures wlLh concreLe
speclallzaLlons responslble for Lypespeclflc porLlons)


O An enLlLy ob[ecL represenLlng Lhe lnformaLlon encoded on Lhe A1M card lnserLed by cusLomer

O An enLlLy ob[ecL represenLlng Lhe log of LransacLlons malnLalned by Lhe machlne

This leads to the Iollowing diagram oI analysis classes:





C#C Cards for ATM Example (OPTIONAL)
Using CRC cards to assign responsibilities to various classes Ior the tasks required by the various
use cases leads to the creation oI the Iollowing cards.
The Iollowing links can be used to go directly to the CRC cards Ior the various classes:
O Class ATM

O Boundary/entity objects - component parts of the ATM

4 Class CardReader
4 Class CashDispenser
4 Class CustomerConsole
4 Class EnvelopeAcceptor
4 Class Log
4 Class NetworkToBank
4 Class OperatorPanel
4 Class ReceiptPrinter


O Controller objects corresponding to the various use cases

4 Class Session
4 Class Transaction
4 Class Withdrawal
4 Class Deposit
4 Class TransIer
4 Class Inquiry


O Entity objects found necessary when assigning responsibilities to other objects

4 Class Balances
4 Class Card
4 Class Message
4 Class Receipt
4 Class Status

Class ATM
#esponsibilities Collaborators
Start up when switch is turned on
OperatorPanel
CashDispenser
NetworkToBank
Shut down when switch is turned oII NetworkToBank
Start a new session when card is inserted by customer CustomerConsole
Session
Provide access to component parts Ior sessions and transactions



Class Card#eader
#esponsibilities Collaborators
Tell ATM when card is inserted ATM
Read inIormation Irom card Card
Eject card

Retain card



Class Cashispenser
#esponsibilities Collaborators
Keep track oI cash on hand, starting with initial amount

Report whether enough cash is available

Dispense cash Log

Class CustomerConsole
#esponsibilities Collaborators
Display a message

Display a prompt, accept a PIN Irom keyboard

Display a prompt and menu, accept a choice Irom keyboard

Display a prompt, accept a dollar amount Irom keyboard

Respond to cancel key being pressed by customer


Class EnvelopeAcceptor
#esponsibilities Collaborators
Accept envelope Irom customer; report iI timed out or cancelled Log

Class Log
#esponsibilities Collaborators
Log messages sent to bank

Log responses Irom bank

Log dispensing oI cash

Log receiving an envelope


Class NetworkToBank
#esponsibilities Collaborators
Initiate connection to bank at startup

Send message to bank and wait Ior response Message
Log
Balances
Status
Terminate connection to bank at shutdown



Class OperatorPanel
#esponsibilities Collaborators
InIorm ATM oI changes to state oI switch ATM
Allow operator to speciIy amount oI initial cash


Class #eceiptPrinter
#esponsibilities Collaborators
Print receipt Receipt

Class Session
#esponsibilities Collaborators
PerIorm session use case ATM
CardReader
Card
CustomerConsole
Transaction
Update PIN value iI customer has to re-enter it


Abstract Class Transaction
#esponsibilities Collaborators
Allow customer to choose a type oI transaction ATM
CustomerConsole
Withdrawal
Deposit
TransIer
Inquiry
PerIorm Transaction Use Case ATM
CustomerConsole
Withdrawal
Deposit
TransIer
Inquiry
Message
NetworkToBank
Receipt
ReceiptPrinter
PerIorm invalid PIN extension CustomerConsole
Session
CardReader

Class Withdrawal
#esponsibilities Collaborators
PerIorm operations peculiar to withdrawal transaction use case CustomerConsole
CashDispenser
Message
Receipt

Class eposit
#esponsibilities Collaborators
PerIorm operations peculiar to deposit transaction use case CustomerConsole
Message
EnvelopeAcceptor
Receipt

Class Transfer
#esponsibilities Collaborators
PerIorm operations peculiar to transIer transaction use case CustomerConsole
Message
Receipt

Class Inquiry
#esponsibilities Collaborators
PerIorm operations peculiar to inquiry transaction use case CustomerConsole
Message
Receipt

Class Balances
#esponsibilities Collaborators
Represent account balance inIormation returned by bank


Class Card
#esponsibilities Collaborators
Represent inIormation encoded on customer's ATM card



Class Message
#esponsibilities Collaborators
Represent inIormation to be sent over network to bank


Class #eceipt
#esponsibilities Collaborators
Represent inIormation to be printed on a receipt


Class Status
#esponsibilities Collaborators
Represent transaction status inIormation returned by bank


Class iagram for Example ATM System
Shown below is the class diagram Ior the ATM system. The basic structure oI the class diagram
arises Irom the responsibilities and relationships discovered when doing the CRC cards and
Interaction Diagrams. (II a class uses another class as a collaborator, or sends a message to an
object oI that class during an Interaction, then there must either be an association linking objects
oI those classes, or linking the "sending" class to an object which provides access to an object oI
the "receiving" class.)
In the case oI the ATM system, one oI the responsibilities oI the ATM is to provide access to its
component parts Ior Session and Transaction objects; thus, Session and Transaction have
associations to ATM, which in turn has associations to the classes representing the individual
component parts. (Explicit "uses" links between Session and Transaction, on the one hand, and
the component parts oI the ATM, on the other hand, have been omitted Irom the diagram to
avoid making it excessively cluttered.)
The need Ior the various classes in the diagram was discovered at various points in the design
process.
O Some classes were dlscovered when dolng analysls (see Lhe Analysls Class ulagram developed
earller)

O Some classes were dlscovered when dolng CC cards

4 Message used Lo represenL a message Lo Lhe bank
4 ecelpL used Lo encapsulaLe lnformaLlon Lo be prlnLed on a recelpL
4 SLaLus used Lo represenL reLurn value from message Lo Lhe bank
4 alances used Lo record balance lnformaLlon reLurned by Lhe bank

O Some classes were dlscovered when dolng deLalled deslgn or wrlLlng code

4 Money used Lo represenL money amounLs ln numerous places
4 AccounLlnformaLlon conLalns names of varlous Lypes of accounLs cusLomer can choose
from
That is, OO design is not a "waterIall" process - discoveries made when doing detailed design
and coding can impact overall system design.
To prevent the diagram Irom becoming overly large, only the name oI each class is shown - the
attribute and behavior "compartments" are shown in the detailed design, but are omitted here.

Click on a class icon for links to further information about it


State Charts for Example ATM System
Three oI the objects we have identiIied have behavior that is suIIiciently complex to warrant
developing a State Chart Ior them. (These are the objects that were identiIied as the major
controller objects.)
O The object representing the machine itselI (responsible Ior the System Startup and
Shutdown use cases)
O Objects representing a customer session (one per session) (responsible Ior the Session use
case)
O Objects representing an individual transaction (one per transaction) (responsible Ior the
Transaction use case, use cases Ior the speciIic types oI transaction, and Invalid PIN
extension).





| CRC Card Ior Session | | Interaction diagram Ior Session |


| CRC Card Ior Transaction | | Interaction diagram Ior Transaction |



Interaction iagrams for Example ATM System
UML deIines two types oI Interaction Diagram: the Sequence Diagram and the Collaboration
Diagram. In order to illustrate both types, the major use cases are documented using Sequence
Diagrams, and the speciIic subclasses oI transaction (withdrawal, etc.) and the Invalid PIN
Extension are documented using Collaboration Diagrams. (The major reason Ior using two
diIIerent types oI diagram is pedagogical - to illustrate each type.)
O Sequence Diagram Ior System Startup Use Case
O Sequence Diagram Ior System Shutdown Use Case
O Sequence Diagram Ior Session Use Case
O Sequence Diagram Ior Transaction Use Case(Since transaction is abstract, this gives the
overall Ilow oI a transaction. See the interactions below Ior speciIic concrete cases.)
O Collaboration realizing speciIics oI Withdrawal Transaction Use Case
O Collaboration realizing speciIics oI Deposit Transaction Use Case
O Collaboration realizing speciIics oI TransIer Transaction Use Case
O Collaboration realizing speciIics oI Inquiry Transaction Use Case
O Collaboration realizing Invalid PIN Extension



















Package iagram for Example ATM System
The package diagram shows how the various classes are grouped into packages. There are two
"top-level" classes - ATMMain and ATMApplet - which allow the system to be run
(respectively) as an application or as an Applet. (Only one oI the two would be instantiated in
any particular use oI the system.)
Each oI these classes, in turn, depends on the package atm which contains the class ATM that
represents the system as a whole, and the class Session that represents one session. ATM
depends on Session, and vice versa - since the ATM creates Sessions, and each Session, in turn,
uses the ATM to interact with the customer.
The subpackage transaction contains the classes used to represent individual transactions that a
customer initiates. The class Session depends on the transaction package because it creates
individual transaction objects. These, in turn, again depend on the ATM to interact with the
customer.
The subpackage physical contains the classes that represent the various physical components oI
the ATM. or the purposes oI this simulation, these are simulated by a GUI. A real ATM would
have quite diIIerent classes in this package - classes that actually control its physical
components. The class ATM makes use oI these components, and Session and the various kinds
oI transaction gain access to them through ATM to actually perIorm the needed operations.
inally, the package banking contains classes that represent the banking enterprise itselI and the
inIormation communicated back and Iorth between the ATM and the bank - i.e. classes which
might be the same in a totally diIIerent implementation oI an ATM that interacts with the same
bank.
This is, oI course, a simulation. However, most oI the code that is speciIic to the simulation
resides in the package physical, plus the two top-level classes. Presumably, the other classes and
packages might be similar in a real system.



Downloaded Irom the given site on 23-12-2010 and edited.
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/ Visit this site and use
simulation.