Banking System Case Study Using COMET

1. Banking System Case StudyUsing COMET Università di Genova Dipartimento di Informatica e Scienze dell’Informazione Alessandro Siena

2. Summary • COMET Software Life Cycle Model • The problem • Case study development Banking System Case Study

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

4. The Problem (draw) wan ATM Bank Server ATM ATM ATM Banking System Case Study

5. 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. Banking System Case Study

6. 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. Banking System Case Study

7. The Problem • A card is composed by: • A magnetic strip in which encodes: • Start date; • Expiration date; • Serial n. Banking System Case Study

8. The Problem • An ATM operator can: • Start up and close down the ATM • to replenish the cash dispenser • for routine maintenance Banking System Case Study

9. The Problem(what is not in) During modeling the Bank Server should be considered as part of the problem • It is assumed that functionality such as • open/close accounts • create/update/delete customer and cards • is provided by an existing system and isnot part of the problem. Banking System Case Study

10. Case study development Use case model Static modeling Object structuring Dinamic modeling Banking System Case Study

11. Use Case Model • Two users/actors: • ATM customer • ATM operator • An actor represents a role  multiple actors&operators Banking System Case Study

12. <<include>> <<include>> Val.PIN Withdraw Funds Transfer Funds Query Account Add Cash Shutdown Restart <<include>> Use Case Model ATM Customer Operator Validate PIN Withdraw funds Use case diagram Banking System Case Study

13. Static Modeling Problem domain • Attention is focused on Problem Domain and System Context • The result is a Conceptual Static Model Static Model System Context Banking System Case Study

14. Static Modeling of the Problem Domain • Physical entity: • Dispenser (cash) • Printer (receipt) • Card Reader (card) • External users: • Operator (keyboard/display) • Customer (keyboard/display) Banking System Case Study

15. Conceptual Static Modeling for the Problem Domain: physical classes 1 has 1..* Bank ATM Customer Interface Banking System Case Study

16. 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.) Banking System Case Study

17. 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 Banking System Case Study

18. 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 Banking System Case Study

19. Object StructuringClient/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 ATM Bank Server Banking System Case Study

20. Object StructuringClient/Server Subsystem Structuring (2) Client/Server use case Client Side use case Server Side use case Banking System Case Study

21. 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 Banking System Case Study

22. 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 Banking System Case Study

23. 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 Banking System Case Study

24. 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) Banking System Case Study

25. 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 Banking System Case Study

26. Toplevel Statechart for ATM Control Banking System Case Study

27. Statechart for ATM Control: Processing Customer Input superstate Banking System Case Study