SIENA

Banking System Case StudyUsing COMET: 

Banking System Case Study Using COMET Alessandro Siena Università di Genova Dipartimento di Informatica e Scienze dell’Informazione

Summary: 

Summary COMET Software Life Cycle Model The problem Case study development

COMET Software Life Cycle Model: 

COMET Software Life Cycle Model Requirement Modeling Analysis Modeling Design Modeling Incremental Sw Construction Incremental Sw Integration System Testing Throwaway Prototyping Incremental Prototyping User C u s t o m e r

COMET Software Life Cycle Model Requirements Modeling: 

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

COMET Activities inRequirements Modeling: 

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

COMET Software Life Cycle Model Analysis Modeling: 

COMET Software Life Cycle Model Analysis Modeling Static and dynamic models are developed; Static model: structural relationship among problem domain classes; Dynamic model: use cases refinement; Collaboration diagram and/or sequence diagram.

COMET Activities inAnalysis Modeling: 

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

COMET Software Life Cycle Model Design Modeling: 

COMET Software Life Cycle Model Design Modeling The software architecture of the system is designed; Analysis model  Design model; System  Subsystems; Concurrent/Sequential;

COMET Activities inDesign Modeling: 

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.

COMET Software Life Cycle Model Incremental Sw Construction: 

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.

COMET Software Life Cycle Model Incremental Sw Integration: 

COMET Software Life Cycle Model Incremental Sw Integration Integration testing of each sw increment is performed; Integration test cases are developed for each use case; The interface between objects are tested.

COMET Software Life Cycle Model System Testing: 

COMET Software Life Cycle Model System Testing Functional testing of the system; Functional test case are built for each black box use case; Any sw increment released to the customer needs to go through this phase.

The Problem (draw): 

The Problem (draw) Bank Server wan ATM ATM ATM ATM

The Problem: 

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.

The Problem(withdraw funds): 

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

The Problem(transfer funds): 

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

The Problem: 

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.

The Problem: 

The Problem A card is composed by: A magnetic strip in which encodes: Start date; Expiration date; Serial n.

The Problem: 

The Problem An ATM operator can: Start up and close down the ATM to replenish the cash dispenser for routine maintenance

The Problem(what is not in): 

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

Case study development: 

Case study development Use case model Static modeling Object structuring Dinamic modeling

Use Case Model: 

Use Case Model Two users/actors: ATM customer ATM operator An actor represents a role  multiple actors&operators

Use Case Model: 

Use Case Model Validate PIN Withdraw funds ATM Customer Operator Use case diagram

Use case Model(Validate PIN Abstract use case): 

Use case Model (Validate PIN Abstract use case) Use case name: Validate PIN Summary: system validates customer PIN Actor: ATM customer Pre: ATM is idle, displaying a welcome msg Description: 1. Customer inserts … 2. …… Alternatives: …… Post: Customer PIN has been validated

Use Case Model(Withdraw funds Concrete Use Case): 

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

Static Modeling: 

Static Modeling Attention is focused on Problem Domain and System Context The result is a Conceptual Static Model Problem domain System Context Static Model

Static Modeling of the Problem Domain: 

Static Modeling of the Problem Domain Physical entity: Dispenser (cash) Printer (receipt) Card Reader (card) External users: Operator (keyboard/display) Customer (keyboard/display)

Conceptual Static Modeling for the Problem Domain: physical classes: 

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

Static Modeling of the System Context: 

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.)

Static ModelingBanking System context class diagram: 

Static Modeling Banking System context class diagram Customer Interface

Static Modeling of the Entity Classes: 

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

Conceptual Static Model for Problem Domain: entity classes: 

Conceptual Static Model for Problem Domain: entity classes

Conceptual Static Model for Banking System: Class Attributes(partial): 

Conceptual Static Model for Banking System: Class Attributes (partial) (continues…)

Object Structuring: 

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

Object StructuringClient/Server Subsystem Structuring (1): 

Object Structuring Client/Server Subsystem Structuring (1) Subsystems are easily identifiable ATM Client Subsystem Bank Server Subsystem ATM Customer executes both client/server ATM Operator executes entirely on client Bank Server ATM

Object StructuringMajor Subsystems: 

Object Structuring Major Subsystems

Object StructuringClient/Server Subsystem Structuring (2): 

Object Structuring Client/Server Subsystem Structuring (2) Client/Server use case Client Side use case Server Side use case

Object StructuringSubsystem packaging of use cases: 

Object Structuring Subsystem packaging of use cases

ATM Client Object Structuring:Interface Objects: 

ATM Client Object Structuring: Interface Objects Banking system is seen as a package Foreach external class  one interface class One instance of each interface classes for each ATM From System Context Diagram to Interface Objects

Banking System external classes and interface class: 

Banking System external classes and interface class Customer Interface

ATM Client Object Structuring:Objects in Use Cases: 

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

ATM Client Subsystem Classes: 

ATM Client Subsystem Classes

Object Structuring in Server Subsystem: 

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

Dynamic Modeling : 

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)

Dynamic Modeling (2): 

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

Collaboration diagram:ATM Client Validate PIN use case: 

Collaboration diagram: ATM Client Validate PIN use case Server Side

Collaboration diagram:ATM Server Validate PIN use case: 

Collaboration diagram: ATM Server Validate PIN use case

Sequence Diagram:ATM Client Validate PIN use case: 

Sequence Diagram: ATM Client Validate PIN use case

Statechart for ATM Control:ATM Client Validate PIN use case: 

Statechart for ATM Control: ATM Client Validate PIN use case

Toplevel Statechart for ATM Control: 

Toplevel Statechart for ATM Control

Statechart for ATM Control: Processing Customer Input superstate: 

Statechart for ATM Control: Processing Customer Input superstate