Banking System Case Study Using COMET

1
Banking System Case StudyUsing COMET
Università di Genova Dipartimento di Informatica
e Scienze dellInformazione

• Alessandro Siena

2
Summary

• COMET Software Life Cycle Model
• The problem
• Case study development

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
System Testing
Incremental Prototyping
4
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

5
COMET Activities inRequirements Modeling

• The system is considered as a black box.
• Emphasis is on understanding the problem.
• Activities use case modeling

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

7
COMET Activities inAnalysis Modeling

• The analysis of the problem domain is considered.
• Activities static modeling
• object structuring
• finite state machines modeling
• dynamic modeling.

8
COMET Software Life Cycle Model Design Modeling

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

9
COMET Activities inDesign 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.

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

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

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

13
The Problem (draw)
wan
ATM
Bank Server
ATM
ATM
ATM
14
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.

15
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

16
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

17
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.
18
The Problem

• A card is composed by
• A magnetic strip in which encodes
• Start date
• Expiration date
• Serial n.

19
The Problem

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

20
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 is not part of the problem.
21
Case study development
Use case model Static modeling Object
structuring Dinamic modeling
22
Use Case Model

• Two users/actors
• ATM customer
• ATM operator
• An actor represents a role
• ? multiple actorsoperators

23
Use Case Model
ATM Customer
Operator
Validate PIN Withdraw funds
Use case diagram
24
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
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

26
Static Modeling
Problem domain
Static Model
System Context

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

27
Static Modeling of the Problem Domain

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

28
Conceptual Static Modeling for the Problem
Domain physical classes
has
1..
1
Bank
ATM
Customer Interface
29
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.)

30
Static ModelingBanking System context class
diagram
Customer Interface
31
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

32
Conceptual Static Model for Problem Domain
entity classes
33
Conceptual Static Model for Banking System
Class Attributes(partial)
(continues)
34
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

35
Object StructuringClient/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

36
Object StructuringMajor Subsystems
37
Object StructuringClient/Server Subsystem
Structuring (2)
Client/Server use case
Client Side use case
Server Side use case
38
Object StructuringSubsystem packaging of use
cases
39
ATM Client Object StructuringInterface 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

40
Banking System external classes and interface
class
Customer Interface
41
ATM Client Object StructuringObjects 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

42
ATM Client Subsystem Classes
43
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, QueryTransactionMana
  ger, TransferTransactionManager

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

45
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

46
Collaboration diagramATM Client Validate PIN
use case
Server Side
47
Collaboration diagramATM Server Validate PIN
use case
48
Sequence DiagramATM Client Validate PIN use case
49
Statechart for ATM ControlATM Client Validate
PIN use case
50
Toplevel Statechart for ATM Control
51
Statechart for ATM Control Processing Customer
Input superstate