Solutions To Laboratory Problems (Instructor Only) : Use Case Driven Development - The View Balance Use Case

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

Solutions to laboratory problems (instructor only)

Use Case Driven Development - The View Balance Use Case


Use case model:

Withdraw Money

Depos it Money

Bank Cus tomer

Trans fer between Accounts

View Balance
Solutions to laboratory problems (instructor only)
Analysis model:

Complete ATM analysis structure:

Dispenser Withdrawal_Control

Bank Customer Transfer_Control Account_Entity


CashierInterface
(f rom Use Case View)

MoneyReceptor Deposit_Control

ViewBalance_Control

Analysis classes that participate in the realization of the View Balance use case:

<<trace>>

View Balance View Balance Realization


(f rom Use Case View)

ViewBalance_Control Account_Entity
CashierInterface
(f rom Analy sis Model) (f rom Analy sis Model)
(f rom Analy sis Model)
Solutions to laboratory problems (instructor only)

Communication /collaboration (interaction) diagram for the basic flow of the View
Balance use case realization in analysis:

1: identify 2: request balance 3: balance info

5: show info 4: provide info


: Bank Customer : CashierInterface : ViewBalance_Control : Account_Entity
Solutions to laboratory problems (instructor only)
Design model:

Design classes tracing to analysis classes for the View Balance use case realization:

CashierInterface ViewBalance_Control

(f rom Analy sis Model) (f rom Analy sis Model)

<<trace>>
<<trace>>
ViewBalance
Display KeyPad CardReader (f rom v iewBalance)
(f rom client) (f rom client) (from client)
TransactionManager
ClientManager (from transaction)
(from client)

Account_Entity
(f rom Analy sis Model)

<<trace>>

AccountManager Account PersistentAccount


(from account) (f rom account) (from account)
Solutions to laboratory problems (instructor only)
Class diagram – the relationship between the design classes that participate in the
realization of the View Balance use case:

PersistentAccount
(from account)
CardReader
(from client)

Display ClientManager AccountManager Account


(f rom client)
(from client) (from account) (f rom account)

Bank Customer
(f rom Use Case View) KeyPad
(f rom client) TransactionManager
(from transaction)

ViewBalance
(f rom v iewBalance)
Solutions to laboratory problems (instructor only)
Sequence (interaction) diagram for the basic flow of the View Balance use case
realization in design. Only the initial part of the interaction, which models Customer
identification (which is actually similar for all the use cases), is shown. The students may
wish to give a more complete solution. The students should notice that the amount of
detail is significantly grater than in the corresponding communication / collaboration
diagram from the analysis model.

: CardReader : Display : KeyPad : CashSensor : CashReceptor : CashCounter : ClientManager : TransactionManager : Deposit : AccountManager : Account
: Bank Customer

1: insertCard

2: readCard

3: ask_for_PIN_code

4: showRequest

5: specifyPIN

6: readPIN

7: PINvalidation
Solutions to laboratory problems (instructor only)
Grouping and deployment (this diagram actually comprises the classes participating in all
use cases) – the designer can decide to deploy the components that implement the three
main sub-systems (client, transaction, account) on three distinct nodes (ATMClient,
ATMApplicationServer, ATMDataServer):

transaction account
client
TransactionManager AccountManager
ClientManager
CardReader Account
Display PersistentAccount
KeyPad withdrawal deposit
CashFeeder (from transaction) (from transaction)
CashCounter Withdrawal Deposit
CashSensor
CashReceptor

viewBalance transfer
(from transaction) (from transaction)
ViewBalance Transfer

ATMClient ATMApplicationServer ATMDataServer


Solutions to laboratory problems (instructor only)
Implementation model:

This model shows components (files that implement the design classes) and their
dependencies; e.g., for a Java-based implementation (of the View Balance use case) you
can show the following compilation dependencies:

<<file>> <<file>>
ClientManager.java ClientManager.class

<<file>> <<file>>
CardReader.java CardReader.class

<<file>> <<file>>
KeyPad.java KeyPad.class

<<file>> <<file>>
Display.java Display.class

<<file>> <<file>>
TransactionManager.java TransactionManager.class

<<file>> <<file>>
ViewBalance.java ViewBalance.class

<<file>>
<<file>> AccountManager.class
AccountManager.java

<<file>>
Account.class

<<file>> <<file>>
PersistentAccount PersistentAccount.
.java class
Solutions to laboratory problems (instructor only)
Test model:

In the test workflow you derive a set of test-cases for each use case.
Example - Test case for the basic flow of the View Balance use case:

(from Use Case Model) (from Test Model)

<<trace>
>

View Balance View Balance – Basic Flow

Test Case: View Balance– Basic Flow

Input:
 The Bank Customer’s account 17-721-3242 has a balance of $2000
 The Bank Customer identifies himself / herself correctly and requests to view the
balance of his / her account 17-721-3242
Result:
 The ATM displays $2000 (the balance of the Bank Customer’s account 17-721-
3242)
Conditions:
 No other use cases (instances) are allowed to access the account 17-721-3242
during this test case

You might also like