Universit di Genova

Dipartimento di Informatica e Scienze dellInformazione

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

COMET Software Life Cycle Model

User Requirement Modeling Analysis Modeling Design Modeling

Incremental Sw Construction

Throwaway Prototyping

Incremental Sw Integration

Incremental Prototyping
25/may/2001 Banking System Case Study

System Testing
3

C u s t o m e r

COMET Software Life Cycle Model

Requirements Modeling
A requirement model is developed; Functional requirements are expressed as: Actors Use case (with narrative description) Essential: User inputs Active participation
A throwaway prototype can be developed to clarify requirements
25/may/2001 Banking System Case Study 4

COMET Activities in
Requirements Modeling
The system is considered as a black box. Emphasis is on understanding the problem. Activities: use case modeling

25/may/2001

Banking System Case Study

COMET Software Life Cycle Model

Analysis Modeling
   

Static and dynamic models are developed; Static model: structural relationship among model: problem domain classes; classes; Dynamic model: use cases refinement; model: refinement; Collaboration diagram and/or sequence diagram. diagram.

25/may/2001

Banking System Case Study

COMET Activities in
Analysis Modeling
The analysis of the problem domain is considered. Activities: static modeling; object structuring; finite state machines modeling; dynamic modeling.

25/may/2001

Banking System Case Study

COMET Software Life Cycle Model

Design Modeling

   

The software architecture of the system is designed; Analysis model Design model; System Subsystems; Concurrent/Sequential;

25/may/2001

Banking System Case Study

COMET Activities in
Design Modeling
The solution domain is considered. The analysis model is mapped to a concurrent design model. Activities: develop consolidate object collaboration diagram; decide subsystem structuring; decide about: objs, msgs; develop a detailed sw design.
25/may/2001 Banking System Case Study 9

COMET Software Life Cycle Model

Incremental Sw Construction
For each subset of the system to be constructed:
detailed design, coding, testing,

of each class in the subset. The Sw is gradually constructed.

25/may/2001

Banking System Case Study

10

COMET Software Life Cycle Model

Incremental Sw Integration
  

Integration testing of each sw increment is performed; performed; Integration test cases are developed for each use case; case; The interface between objects are tested. tested.

25/may/2001

Banking System Case Study

11

COMET Software Life Cycle Model

System Testing
  

Functional testing of the system; system; Functional test case are built for each black box use case; case; Any sw increment released to the customer needs to go through this phase. phase.

25/may/2001

Banking System Case Study

12

The Problem (draw)

wan
Bank Server ATM

ATM
25/may/2001

ATM

Banking System Case Study

ATM

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
(withdraw funds)
Before approving:
Do sufficient funds exist? Is the max limit excedeed? Is there sufficient cash in the dispenser?

If approved:
Cash is dispensed; A receipt is printed; The card is ejected

25/may/2001

Banking System Case Study

15

The Problem
(transfer funds)
Before approving:
Has the customer at least two accounts? Are there sufficient funds in the account to be debited?

If approved:
A receipt is printed;

The card is ejected

25/may/2001

Banking System Case Study

16

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)
It is assumed that functionality such as open/close accounts create/update/delete customer and cards is provided by an existing system and is not part of the problem.
During modeling the Bank Server should be considered as 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

F multiple actors&operators

25/may/2001

Banking System Case Study

22

Use Case Model

Withdraw Funds Query ATM Customer Account <<include>> Transfer Funds Add Cash <<include>> <<include>> Val.PIN

Shutdown Operator Restart

Validate PIN Use case diagram

25/may/2001 Banking System Case Study

Withdraw funds
23

Use case Model

(Validate PIN Abstract use case)
Use case name: Validate PIN name: Summary: Summary: system validates customer PIN Actor: Actor: ATM customer Pre: Pre: ATM is idle, displaying a welcome msg Description: Description: 1. Customer inserts 2. Alternatives: Alternatives: Post: Post: Customer PIN has been validated
25/may/2001 Banking System Case Study 24

Use Case Model

(Withdraw funds Concrete Use Case)
Use case name: Withdraw funds name: Summary: Summary: Customer withdraws a specific amount of funds from a valid bank account Actor: Actor: ATM customer Pre: Pre: ATM is idle, displaying a welcome msg Description: Description: 1. Include Validate PIN abstract use case 2. Customer selects withdrawal, enter amounts, 3. Alternatives: Alternatives: Post: Post: Customer funds have been withdrawn
25/may/2001 Banking System Case Study 25

Static Modeling
Problem domain System Context Static Model

Attention is focused on Problem Domain and System Context  The result is a Conceptual Static Model
Banking System Case Study 26

25/may/2001

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

Bank 1 has
1..*

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. 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). ATM).
External classes ~ users & I/O devices (fig.) fig.
25/may/2001 Banking System Case Study 29

Static Modeling Banking System context class diagram

Customer Interface

25/may/2001

Banking System Case Study

30

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 Card: ATM Cash: amount of cash maintained in Cash: ATM Receipt: Receipt: info about a transaction (unnecessary because holds info similar to Transaction class
25/may/2001 Banking System Case Study 31

Conceptual Static Model for Problem Domain: entity classes

25/may/2001

Banking System Case Study

32

Conceptual Static Model for Banking System: Class Attributes

(partial)
entity Bank bankName: String bankAddress: String entity DebitCard accountNumber: String amount: Real balance: Real

(continues)
25/may/2001 Banking System Case Study 33

Object Structuring
Structuring the system into objects for the dynamic model definitions. 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)

Bank Server


ATM

Subsystems are easily identifiable

ATM Client Subsystem Bank Server Subsystem

 

ATM Customer executes both client/server ATM Operator executes entirely on client
Banking System Case Study 35

25/may/2001

Object Structuring
Major Subsystems

25/may/2001

Banking System Case Study

36

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

Object Structuring
Subsystem packaging of use cases

25/may/2001

Banking System Case Study

38

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

Banking System external classes and interface class

Customer Interface

25/may/2001

Banking System Case Study

40

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

ATM Client Subsystem Classes

25/may/2001

Banking System Case Study

42

Object Structuring in Server Subsystem



What is in:
Objs accessible from each ATM (customer, account, (customer, debit card)

Entity classes
Customer, Account (Superclass), (Superclass), Checking/Saving Account (Subclasses), (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: point:


Use cases & objs determined in Objs Structuring



Sequence of inter-objs comunications are intershown (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 statecases
25/may/2001 Banking System Case Study 45

Collaboration diagram: ATM Client Validate PIN use case

Server Side
25/may/2001 Banking System Case Study 46

Collaboration diagram: ATM Server Validate PIN use case

25/may/2001

Banking System Case Study

47

Sequence Diagram: ATM Client Validate PIN use case

25/may/2001

Banking System Case Study

48

Statechart for ATM Control: ATM Client Validate PIN use case

25/may/2001

Banking System Case Study

49

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