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

Banking System Case StudyBanking System Case StudyUsing COMETUsing COMET

Alessandro SienaAlessandro Siena

Università di GenovaUniversità di GenovaDipartimento di Informatica e Scienze dell’InformazioneDipartimento di Informatica e Scienze dell’Informazione

25/may/2001 Banking System Case Study 2

SummarySummary

COMET COMET Software Life Cycle ModelSoftware Life Cycle Model The problemThe problem Case study developmentCase study development


COMET Software Life Cycle ModelCOMET Software Life Cycle Model

Requirement

Modeling Analysis

Modeling Design

ModelingIncremental

Sw

ConstructionIncremental

Sw

Integration

System

Testing

Throwaway

Prototyping

Incremental

Prototyping

User

Customer


The Problem The Problem (draw)(draw)

Bank Server

wanwan

ATM

ATM

ATM

ATM


The ProblemThe ProblemA 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 ProblemThe 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.



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



An ATM operator can: Start up and close down the ATM

to replenish the cash dispenser

for routine maintenance


The ProblemThe Problem(what is not in)(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 developmentCase study development

Use case model

Static modeling

Object structuring

Dinamic modeling


Use Case ModelUse Case Model

Two users/actors:Two users/actors:» ATM customerATM customer» ATM operatorATM operator

An actor represents a role An actor represents a role multiple actors&operatorsmultiple actors&operators


Use Case ModelUse Case Model

Validate PIN

Withdraw funds

Val.PIN

Withdraw

Funds

Transfer

Funds

Query

AccountATM

Customer

Operator

Add Cash

Shutdown

Restart

<<include>>

<<include>>

<<include>>

Use case diagram


Static ModelingStatic Modeling

Attention is focused on Attention is focused on Problem DomainProblem Domain and and System ContextSystem Context

The result is a The result is a Conceptual Static ModelConceptual Static Model

Problem domain

System Context

Static Model


Static Modeling of the Static Modeling of the Problem DomainProblem Domain

Physical entity:Physical entity:– Dispenser (cash)Dispenser (cash)– Printer (receipt)Printer (receipt)– Card Reader (card)Card Reader (card)

External users:External users:– Operator (keyboard/display)Operator (keyboard/display)– Customer (keyboard/display)Customer (keyboard/display)


Conceptual Static Modeling for the Conceptual Static Modeling for the Problem Domain: Problem Domain: physical classesphysical classes

Bank ATMhas 1..*1

Customer

Interface


Static Modeling of the Static Modeling of the System ContextSystem Context

Developed to show the external classes to which the Developed to show the external classes to which the Banking System (aggregate class) has to interface.Banking System (aggregate class) has to interface.

The context class diagram is developed considering The context class diagram is developed considering physical classes determined during static modeling physical classes determined during static modeling of the problem domain (one instance of these of the problem domain (one instance of these external classes for each ATM).external classes for each ATM).

External classes ~ users & I/O devices (External classes ~ users & I/O devices (fig.fig.))


Static Modeling of the Static Modeling of the Entity ClassesEntity Classes

Both transaction and account are the Both transaction and account are the generalization of more specialized classesgeneralization of more specialized classes

Entity classes are also required to model the Entity classes are also required to model the Physical classesPhysical classes– ATM CardATM Card: info read from the magnetic strip: info read from the magnetic strip– ATM CashATM Cash: amount of cash maintained in : amount of cash maintained in

ATMATM– ReceiptReceipt: info about a transaction : info about a transaction

(unnecessary because holds info similar to (unnecessary because holds info similar to TransactionTransaction class class


Object StructuringObject Structuring

Structuring the system into objects for the Structuring the system into objects for the dynamic model definitions.dynamic model definitions.– Objects and classes are determinedObjects and classes are determined– For each use case a collaboration (or sequence) For each use case a collaboration (or sequence)

diagram is developeddiagram is developed


Object StructuringObject StructuringClient/Server Subsystem Structuring Client/Server Subsystem Structuring (1)(1)

Subsystems are easily identifiableSubsystems are easily identifiable– ATM Client SubsystemATM Client Subsystem– Bank Server SubsystemBank Server Subsystem

ATM Customer executes both client/serverATM Customer executes both client/server ATM Operator executes entirely on clientATM Operator executes entirely on client

Bank Server ATM


Object StructuringObject StructuringClient/Server Subsystem Structuring Client/Server Subsystem Structuring (2)(2)

Client/Server use case

Client Side use case Server Side use case


ATM Client Object Structuring:ATM Client Object Structuring:Interface ObjectsInterface Objects

Banking system is seen as a packageBanking system is seen as a package Foreach external class Foreach external class one interface class one interface class One instance of each interface classes for One instance of each interface classes for

each ATMeach ATM

From System Context Diagram to Interface Objects


ATM Client Object Structuring:ATM Client Object Structuring:Objects in Use CasesObjects in Use Cases

Each use case is consideredEach use case is considered All the objs participating in use case are All the objs participating in use case are

determineddetermined 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 Result: classes in ATM class subsystem shown as a packagepackage


Object Structuring in Server Object Structuring in Server SubsystemSubsystem

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

– Entity classesEntity classes» Customer, Account (Customer, Account (SuperclassSuperclass), ), Checking/Saving Account (Checking/Saving Account (SubclassesSubclasses), Debit ), Debit CardCard

» ATM Transaction ATM Transaction obj migrates from client to serverobj migrates from client to server– Business LogicBusiness Logic

» PIN Validation, TransactionManager, PIN Validation, TransactionManager, WithdrawalTransactionManager, WithdrawalTransactionManager, QueryTransactionManager, QueryTransactionManager, TransferTransactionManagerTransferTransactionManager


Dynamic ModelingDynamic Modeling

Depicts interaction among objs participating Depicts interaction among objs participating in each use casein each use case

Starting point:Starting point:– Use cases & objs determined in Objs StructuringUse cases & objs determined in Objs Structuring

Sequence of inter-objs comunications are Sequence of inter-objs comunications are shown (with both sequence or collaboration shown (with both sequence or collaboration diagram)diagram)


Dynamic ModelingDynamic Modeling (2)(2)

The system is structured in client & server sideThe system is structured in client & server side The use cases were divided into abstract client The use cases were divided into abstract client

and server use caseand server use case The collaboration diagram are structured for The collaboration diagram are structured for

client and server subsystemsclient and server subsystems Statecharts shown form state-dependent use Statecharts shown form state-dependent use

casescases


Toplevel Statechart for ATM ControlToplevel Statechart for ATM Control


Statechart for ATM Control: Statechart for ATM Control: Processing Customer Input superstateProcessing Customer Input superstate

Documents

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