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

25/may/2001Banking System Case Study2 Summary COMET Software Life Cycle Model COMET Software Life Cycle Model COMET Software Life Cycle Model COMET Software Life Cycle Model The problem The problem The problem The problem Case study development Case study development Case study development Case study development

25/may/2001Banking System Case Study3 COMET Software Life Cycle Model Requirement Modeling Analysis Modeling Design Modeling Incremental Sw Construction Incremental Sw Integration System Testing Throwaway Prototyping Incremental Prototyping User CustomerCustomer

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

25/may/2001Banking System Case Study5 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/2001Banking System Case Study6 COMET Software Life Cycle Model Analysis Modeling Static and dynamic models are developed; Static and dynamic models are developed; Static model: structural relationship among problem domain classes; Static model: structural relationship among problem domain classes; Dynamic model: use cases refinement; Dynamic model: use cases refinement; Collaboration diagram and/or sequence diagram. Collaboration diagram and/or sequence diagram.

25/may/2001Banking System Case Study7 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/2001Banking System Case Study8 COMET Software Life Cycle Model Design Modeling The software architecture of the system is designed; The software architecture of the system is designed; Analysis model Design model; Analysis model Design model; System Subsystems; System Subsystems; Concurrent/Sequential; Concurrent/Sequential;

25/may/2001Banking System Case Study9 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: obj s, msg s ; develop a detailed sw design.

25/may/2001Banking System Case Study10 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/2001Banking System Case Study11 COMET Software Life Cycle Model Incremental Sw Integration Integration testing of each sw increment is performed; Integration testing of each sw increment is performed; Integration test cases are developed for each use case; Integration test cases are developed for each use case; The interface between objects are tested. The interface between objects are tested.

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

25/may/2001Banking System Case Study13 The Problem (draw) Bank Server wan ATM

25/may/2001Banking System Case Study14 The Problem A customer can: Withdraw funds Withdraw funds Query an account Transfer funds 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/2001Banking System Case Study15 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/2001Banking System Case Study16 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/2001Banking System Case Study17 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 3 rd attempt fails the card is confiscated.

25/may/2001Banking System Case Study18 The Problem A card is composed by: A magnetic strip in which encodes: Start date; Expiration date; Serial n.

25/may/2001Banking System Case Study19 The Problem An ATM operator can: Start up and close down the ATM to replenish the cash dispenser for routine maintenance

25/may/2001Banking System Case Study20 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/2001Banking System Case Study21 Case study development Use case model Static modeling Object structuring Dinamic modeling

25/may/2001Banking System Case Study22 Use Case Model Two users/actors: Two users/actors: »ATM customer »ATM operator An actor represents a role An actor represents a role multiple actors&operators multiple actors&operators

25/may/2001Banking System Case Study23 Use Case Model Validate PIN Withdraw funds Val.PIN Withdraw Funds Transfer Funds Query Account ATM Customer Operator Add CashShutdownRestart > Use case diagram

25/may/2001Banking System Case Study24 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

25/may/2001Banking System Case Study25 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,… 2. Customer selects withdrawal, enter amounts,… 3. … … 3. … … Alternatives: …… Post: Customer funds have been withdrawn

25/may/2001Banking System Case Study26 Static Modeling Attention is focused on Problem Domain and System Context Attention is focused on Problem Domain and System Context The result is a Conceptual Static Model The result is a Conceptual Static Model Problem domain System Context Static Model

25/may/2001Banking System Case Study27 Static Modeling of the Problem Domain Physical entity: Physical entity: –Dispenser (cash) –Printer (receipt) –Card Reader (card) External users: External users: –Operator (keyboard/display) –Customer (keyboard/display)

25/may/2001Banking System Case Study28 Conceptual Static Modeling for the Problem Domain: physical classes BankATM has 1..* 1 Customer Interface

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

25/may/2001Banking System Case Study30 Static Modeling Banking System context class diagram Customer Interface

25/may/2001Banking System Case Study31 Static Modeling of the Entity Classes Both transaction and account are the generalization of more specialized classes Both transaction and account are the generalization of more specialized classes Entity classes are also required to model the Physical classes Entity classes are also required to model the Physical classes Entity classes Entity 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/2001Banking System Case Study32 Conceptual Static Model for Problem Domain: entity classes

25/may/2001Banking System Case Study33 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/2001Banking System Case Study34 Object Structuring Structuring the system into objects for the dynamic model definitions. 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/2001Banking System Case Study35 Object Structuring Client/Server Subsystem Structuring (1) Subsystems are easily identifiable Subsystems are easily identifiable Subsystems –ATM Client Subsystem –Bank Server Subsystem ATM Customer executes both client/server ATM Customer executes both client/server ATM Operator executes entirely on client ATM Operator executes entirely on client Bank Server ATM

25/may/2001Banking System Case Study36 Object Structuring Major Subsystems

25/may/2001Banking System Case Study37 Object Structuring Client/Server Subsystem Structuring (2) Client/Server use caseuse case Client Side use caseServer Side use case

25/may/2001Banking System Case Study38 Object Structuring Subsystem packaging of use cases

25/may/2001Banking System Case Study39 ATM Client Object Structuring: Interface Objects Banking system is seen as a package Banking system is seen as a package Foreach external class one interface class Foreach external class one interface class One instance of each interface classes for each ATM One instance of each interface classes for each ATM From System Context Diagram to Interface ObjectsSystem Context Diagram Interface Objects

25/may/2001Banking System Case Study40 Banking System external classes and interface class Customer Interface

25/may/2001Banking System Case Study41 ATM Client Object Structuring: Objects in Use Cases Each use case is considered Each use case is considered All the objs participating in use case are determined All the objs participating in use case are determined What is used? (to do what?) What is used? (to do what?) Where info should be stored? Where info should be stored? Is something missing? Is something missing? Result: classes in ATM class subsystem shown as a package

25/may/2001Banking System Case Study42 ATM Client Subsystem Classes

25/may/2001Banking System Case Study43 Object Structuring in Server Subsystem What is in: 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/2001Banking System Case Study44 Dynamic Modeling Depicts interaction among objs participating in each use case Depicts interaction among objs participating in each use case Starting point: Starting point: –Use cases & objs determined in Objs Structuring Sequence of inter-objs comunications are shown (with both sequence or collaboration diagram) Sequence of inter-objs comunications are shown (with both sequence or collaboration diagram)sequence collaborationsequence collaboration

25/may/2001Banking System Case Study45 Dynamic Modeling (2) The system is structured in client & server side The system is structured in client & server side The use cases were divided into abstract client and server use case The use cases were divided into abstract client and server use case The collaboration diagram are structured for client and server subsystems The collaboration diagram are structured for client and server subsystems clientserver clientserver Statecharts shown form state-dependent use cases Statecharts shown form state-dependent use cases Statecharts

25/may/2001Banking System Case Study46 Collaboration diagram: ATM Client Validate PIN use case Server Side

25/may/2001Banking System Case Study47 Collaboration diagram: ATM Server Validate PIN use case

25/may/2001Banking System Case Study48 Sequence Diagram: ATM Client Validate PIN use case

25/may/2001Banking System Case Study49 Statechart for ATM Control: ATM Client Validate PIN use case

25/may/2001Banking System Case Study50 Toplevel Statechart for ATM Control

25/may/2001Banking System Case Study51 Statechart for ATM Control: Processing Customer Input superstate