Università di Genova

Dipartimento di Informatica e Scienze dell’Informazione

Banking System Case Study

Using COMET
Alessandro Siena
 Summary

 COMET Software Life Cycle Model

 The problem
 Case study development

25/may/2001 Banking System Case Study 2

 COMET Software Life Cycle Model
User

Requirement
Modeling Analysis
Modeling Design
Modeling
Incremental
Sw
Construction
Incremental C
Throwaway u
Sw s
Prototyping t
Integration o
m
e
r
Incremental System
Prototyping Testing

25/may/2001 Banking System Case Study 3

 The Problem (draw)

wan
wan
ATM
Bank Server

ATM
ATM
25/may/2001
ATM Banking System Case Study 13
 The Problem
A customer can:
 Withdraw funds
 Query an account
 Transfer funds
 Delete a transaction in any moment so:
• The transaction is aborted
• The card is ejected

Customer records, account records debit card records are all

mantained on the server.
25/may/2001 Banking System Case Study 14
 The Problem
A transaction starts when:
 Card is inserted
 Card is recognized (assumed true)
 Card validated
 PIN is inserted & validated

The customer is allowed three attempts to enter the

correct PIN; if the 3rd attempt fails the card is
confiscated.
25/may/2001 Banking System Case Study 17
 The Problem

A card is composed by:

 A magnetic strip in which encodes:
• Start date;
• Expiration date;
• Serial n.

25/may/2001 Banking System Case Study 18

 The Problem

An ATM operator can:

 Start up and close down the ATM
to replenish the cash dispenser
for routine maintenance

25/may/2001 Banking System Case Study 19

 The Problem
(what is not in)
During modeling the
Bank Server should be
considered as part of
It is assumed that functionality such as the problem

open/close accounts
create/update/delete customer and cards
is provided by an existing system and is not part of the
problem.

25/may/2001 Banking System Case Study 20

 Case study development

Use case model

Static modeling
Object structuring
Dinamic modeling
25/may/2001 Banking System Case Study 21
 Use Case Model
 Two users/actors:
» ATM customer
» ATM operator
 An actor represents a role
 multiple actors&operators

25/may/2001 Banking System Case Study 22

 Use Case Model
Withdraw
Funds <<include>>

Query <<include>> Val.PIN

Account
ATM
<<include>>
Customer
Transfer
Add Cash
Funds

Shutdown

Operator
Restart
Validate PIN

Use case diagram Withdraw funds

25/may/2001 Banking System Case Study 23
 Static Modeling
Problem
domain Static
Model
System
Context

 Attention is focused on Problem Domain

and System Context
 The result is a Conceptual Static Model

25/may/2001 Banking System Case Study 26

 Static Modeling of the
Problem Domain

 Physical entity:
– Dispenser (cash)
– Printer (receipt)
– Card Reader (card)
 External users:
– Operator (keyboard/display)
– Customer (keyboard/display)

25/may/2001 Banking System Case Study 27

Conceptual Static Modeling for the
Problem Domain: physical classes
1 has 1..*
Bank ATM

Customer
Interface

25/may/2001 Banking System Case Study 28

 Static Modeling of the
System Context
Developed to show the external classes to which the
Banking System (aggregate class) has to interface.

The context class diagram is developed considering

physical classes determined during static modeling
of the problem domain (one instance of these
external classes for each ATM).

External classes ~ users & I/O devices (fig.)

25/may/2001 Banking System Case Study 29

 Static Modeling of the
Entity Classes
 Both transaction and account are the
generalization of more specialized classes
 Entity classes are also required to model the
Physical classes
– ATM Card: info read from the magnetic strip
– ATM Cash: amount of cash maintained in
ATM
– Receipt: info about a transaction
(unnecessary because holds info similar to
Transaction class
25/may/2001 Banking System Case Study 31
 Object Structuring

 Structuring the system into objects for the

dynamic model definitions.
– Objects and classes are determined
– For each use case a collaboration (or sequence)
diagram is developed

25/may/2001 Banking System Case Study 34

 Object Structuring
Client/Server Subsystem Structuring (1)

ATM
Bank Server

 Subsystems are easily identifiable

– ATM Client Subsystem
– Bank Server Subsystem
 ATM Customer executes both client/server
 ATM Operator executes entirely on client
25/may/2001 Banking System Case Study 35
 Object Structuring
Client/Server Subsystem Structuring (2)
Client/Server use case

Client Side use case Server Side use case

25/may/2001 Banking System Case Study 37

 ATM Client Object Structuring:
Interface Objects
From System Context Diagram to Interface Objects

 Banking system is seen as a package

 Foreach external class  one interface class
 One instance of each interface classes for
each ATM

25/may/2001 Banking System Case Study 39

 ATM Client Object Structuring:
Objects in Use Cases
 Each use case is considered
 All the objs participating in use case are
determined
 What is used? (to do what?)
 Where info should be stored?
 Is something missing?

Result: classes in ATM class subsystem shown as a

package
25/may/2001 Banking System Case Study 41
 Object Structuring in Server
Subsystem
 What is in:
– Objs accessible from each ATM (customer, account,
debit card)
– Entity classes
» Customer, Account (Superclass),
Checking/Saving Account (Subclasses), Debit
Card
» ATM Transaction obj migrates from client to server
– Business Logic
» PIN Validation, TransactionManager,
WithdrawalTransactionManager,
QueryTransactionManager,
TransferTransactionManager
25/may/2001 Banking System Case Study 43
 Dynamic Modeling
 Depicts interaction among objs participating
in each use case
 Starting point:
– Use cases & objs determined in Objs Structuring
 Sequence of inter-objs comunications are
shown (with both sequence or collaboration
diagram)

25/may/2001 Banking System Case Study 44

 Dynamic Modeling (2)
 The system is structured in client & server side
 The use cases were divided into abstract client
and server use case
 The collaboration diagram are structured for
client and server subsystems
 Statecharts shown form state-dependent use
cases

25/may/2001 Banking System Case Study 45

Toplevel Statechart for ATM Control

25/may/2001 Banking System Case Study 50

 Statechart for ATM Control:
Processing Customer Input superstate

25/may/2001 Banking System Case Study 51