ATM Details 1

8/6/2019 ATM Details 1

1/51

Banking System Case StudyBanking System Case Study

Using COMETUsing COMET

Alessandro SienaAlessandro Siena

Universit di GenovaUniversit di Genova

Dipartimento di Informatica e Scienze dellInformazioneDipartimento di Informatica e Scienze dellInformazione


2/51

25/may/2001 Banking System Case Study 2

SummarySummary

COMET Software Life Cycle ModelCOMET Software Life Cycle Model

The problemThe problem

Case study developmentCase study development


3/51



Requirement

Modeling Analysis

Modeling Design

ModelingIncremental

Sw

ConstructionIncremental

Sw

Integration

System

Testing

Throwaway

Prototyping

Incremental

Prototyping

User

Cust

omer


4/51



Requirements ModelingRequirements Modeling A requirement model is developed;A requirement model is developed;

Functional requirements are expressed as:Functional requirements are expressed as:

ActorsActors Use case (with narrative description)Use case (with narrative description)

Essential:Essential:

User inputsUser inputs

Active participationActive participation

A throwaway prototype can be developed to clarify requirementsA throwaway prototype can be developed to clarify requirements


5/51


COMET Activities inCOMET Activities in

Requirements ModelingRequirements ModelingThe system is considered as a black box.The system is considered as a black box.

Emphasis is on understanding the problem.Emphasis is on understanding the problem.

Activities: use case modelingActivities: use case modeling


6/51



Analysis ModelingAnalysis Modeling

Static and dynamic models are developed;Static and dynamic models are developed;

StaticStatic modelmodel:: structuralstructural relationshiprelationship amongamongproblemproblem domaindomain classesclasses;;

DynamicDynamic modelmodel:: useuse casescases refinementrefinement;;

CollaborationCollaboration diagramdiagram and/orand/or sequencesequence

diagramdiagram..


7/51



Analysis ModelingAnalysis ModelingThe analysis of the problem domain is considered.The analysis of the problem domain is considered.

Activities: static modeling;Activities: static modeling;

object structuring;object structuring;

finite state machines modeling;finite state machines modeling;

dynamic modeling.dynamic modeling.


8/51



Design ModelingDesign Modeling

The software architecture of the system is designed;The software architecture of the system is designed; Analysis modelAnalysis model Design model;Design model;

SystemSystem Subsystems;Subsystems;

Concurrent/Sequential;Concurrent/Sequential;


9/51

25/may

/2001Banking System Case Study 9


Design ModelingDesign ModelingThe solution domain is considered.The solution domain is considered.

The analysis model is mapped to a concurrent designThe analysis model is mapped to a concurrent design

model.model.Activities: develop consolidate object collaborationActivities: develop consolidate object collaboration

diagram;diagram;

decide subsystem structuring;decide subsystem structuring;

decide about: objdecide about: objss, msg, msgss;;

develop a detailed sw design.develop a detailed sw design.


10/51

25/may

/2001Banking System Case Study

10


Incremental Sw ConstructionIncremental Sw ConstructionFor each subset of the system to be constructed:For each subset of the system to be constructed:

detailed design,detailed design,

coding,coding, testing,testing,

of each class in the subset.of each class in the subset.

The Sw is gradually constructed.The Sw is gradually constructed.


11/51

25/may


11

COMET Software Life CycleCOMET Software Life Cycle

ModelModelIncremental Sw IntegrationIncremental Sw Integration

IntegrationIntegration testingtesting ofof eacheach swsw incrementincrement isis performedperformed;;

IntegrationIntegration testtest casescases areare developeddeveloped forfor eacheach useuse casecase;;

TheThe interfaceinterface betweenbetween objectsobjects areare testedtested..


12/51

25/may


12


System TestingSystem Testing FunctionalFunctional testingtesting ofof thethe systemsystem;;

FunctionalFunctional testtest casecase areare builtbuilt forfor eacheach blackblack boxbox useuse

casecase;;

AnyAny swsw incrementincrement releasedreleased toto thethe customercustomer needsneeds

toto gogo throughthrough thisthis phasephase..


13/51

25/may


13

The ProblemThe Problem (draw)(draw)

Bank Server

wan

ATM

ATM

ATM

ATM


14/51

25/may


14

The ProblemThe 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/51

25/may


15


(withdraw funds)(withdraw funds)Before approving:Before approving:

Do sufficient fundsDo sufficient funds

exist?exist?

Is the max limitIs the max limit

excedeed?excedeed?

Is there sufficient cashIs there sufficient cash

in the dispenser?in the dispenser?

If approved:If approved:

Cash is dispensed;Cash is dispensed;

A receipt is printed;A receipt is printed;

The card is ejectedThe card is ejected


16/51

25/may


16


(transfer funds)(transfer funds)Before approving:Before approving:

Has the customer atHas the customer at

least two accounts?least two accounts?

Are there sufficientAre there sufficient

funds in the accountfunds in the account

to be debited?to be debited?

If approved:If approved:

A receipt is printed;A receipt is printed;

The card is ejectedThe card is ejected


17/51

25/may


17


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 thecorrect PIN; if the 3rd attempt fails the card is

confiscated.


18/51

25/may


18


A card is composed by:

A magnetic strip in which encodes: Start date;

Expiration date;

Serial n.


19/51

25/may


19


An ATM operator can:

Start up and close down the ATM

to replenish the cash dispenser

for routine maintenance


20/51

25/may


20


(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 ofthe

problem.

During modeling the

Bank Server should be

considered as part of

the problem


21/51

25/may


21

Case study developmentCase study development

Use case model

Static modeling

Object structuring

Dinamic modeling


22/51

25/may


22

Use Case ModelUse Case Model

Two users/actors:Two users/actors:

ATM customerATM customer

ATM operatorATM operator An actor represents a roleAn actor represents a role

FFmultiple actors&operatorsmultiple actors&operators


23/51

25/may


23

Use Case ModelUse Case Model

Validate PIN

Withdraw funds

Val.PIN

Withdraw

Funds

Transfer

Funds

Query

AccountATM

Customer

Operator

Add Cash

Shutdown

Restart

Use case diagram


24/51

25/may


24

Use case ModelUse case Model

(Validate PIN Abstract use case)(Validate PIN Abstract use case)Use case nameUse case name: Validate PIN: Validate PIN

SummarySummary: system validates customer PIN: system validates customer PIN

ActorActor: ATM customer: ATM customer

PrePre: ATM is idle, displaying a welcome msg: ATM is idle, displaying a welcome msg

DescriptionDescription: 1. Customer inserts : 1. Customer inserts

2. 2.

AlternativesAlternatives: :

PostPost: Customer PIN has been validated: Customer PIN has been validated


25/51


26/51


Static ModelingStatic Modeling

Attention is focused onAttention is focused onProblem DomainProblem Domain

andand System ContextSystem Context

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

Problem

domain

System

Context

Static

Model


27/51


Static Modeling of theStatic 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)


28/51


Conceptual Static Modeling for theConceptual Static Modeling for the

Problem Domain:Problem Domain:physical classesphysical classesBank ATMhas 1..*1

Customer

Interface


29/51



System ContextSystem ContextDevelopedDeveloped toto showshow thethe externalexternal classesclasses toto whichwhich thethe

BankingBanking SystemSystem (aggregate(aggregate class)class) hashas toto interfaceinterface..

TheThe contextcontext classclass diagramdiagram isis developeddeveloped consideringconsidering

physicalphysical classesclasses determineddetermined duringduring staticstatic modelingmodeling

ofof thethe problemproblem domaindomain (one(one instanceinstance ofof thesethese

externalexternal classesclasses forfor eacheach ATM)ATM)..

ExternalExternal classesclasses ~~ usersusers && I/OI/O devicesdevices ((figfig..))


30/51


Static ModelingStatic Modeling

B

anking System context class diagramB

anking System context class diagram

Customer

Interface


31/51



Entity ClassesEntity Classes BothBoth transactiontransaction andand accountaccount areare thethe

generalizationgeneralization ofof moremore specializedspecialized classesclasses

EntityEntity classesclasses areare alsoalso requiredrequired toto modelmodel thethePhysicalPhysical classesclasses

ATMATM CardCard:: infoinfo readread fromfrom thethe magneticmagnetic stripstrip

ATMATM CashCash:: amountamount ofof cashcash maintainedmaintained inin

ATMATM ReceiptReceipt:: infoinfo aboutabout aa transactiontransaction(unnecessary(unnecessary becausebecause holdsholds infoinfo similarsimilar totoTransactionTransaction classclass


32/51


Conceptual Static Model forConceptual Static Model for

Problem Domain:Problem Domain: entity classesentity classes


33/51


Conceptual Static Model for BankingConceptual Static Model for Banking

System:System: Class AttributesClass Attributes(partial)(partial)

entity

Bank

bankName: String

bankAddress: String

entity

DebitCardaccountNumber: String

amount: Real

balance: Real

(continues)


34/51


Object StructuringObject Structuring

StructuringStructuring thethe systemsystem intointo objectsobjects forfor thethe

dynamicdynamic modelmodel definitionsdefinitions.. ObjectsObjects andand classesclasses areare determineddetermined

ForFor eacheach useuse casecase aa collaborationcollaboration (or(or sequence)sequence)

diagramdiagram isis developeddeveloped


35/51


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

SubsystemsSubsystems are easily identifiableare 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 ServerATM


36/51


Object StructuringObject StructuringMajor SubsystemsMajor Subsystems


37/51


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

Client/Server use case

Client Side use case Server Side use case


38/51


Object StructuringObject StructuringSubsystem packaging of use casesSubsystem packaging of use cases


39/51


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 classForeach external class one interface classone interface class

One instance of each interface classes forOne instance of each interface classes for

each ATMeach ATM

From System Context Diagram to Interface Objects


40/51


Banking System external classesBanking System external classes

and interface classand interface class

Customer

Interface


41/51


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 areAll 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 aResult: classes in ATM class subsystem shown as a

packagepackage


42/51


ATM Client Subsystem ClassesATM Client Subsystem Classes


43/51


Object Structuring in ServerObject 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 CardDebit Card

ATM TransactionATM 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


44/51


Dynamic ModelingDynamic Modeling

DepictsDepicts interactioninteraction amongamong objsobjs participatingparticipating

inin eacheach useuse casecase

StartingStarting pointpoint:: UseUse casescases && objsobjs determineddetermined inin ObjsObjs StructuringStructuring

SequenceSequence ofof inter inter--objsobjs comunicationscomunications areare

shownshown (with(with bothboth sequencesequence oror collaborationcollaboration

diagram)diagram)


45/51


Dynamic ModelingDynamic Modeling (2)(2)

TheThe systemsystem isis structuredstructured inin clientclient && serverserver sideside

TheThe useuse casescases werewere divideddivided intointo abstractabstract clientclient

andand serverserver useuse casecase TheThe collaborationcollaboration diagramdiagram areare structuredstructured forfor

clientclient andand serverserver subsystemssubsystems

StatechartsStatecharts shownshown formform statestate--dependentdependent useusecasescases


46/51


Collaboration diagram:Collaboration diagram:

ATM ClientValidate PIN use caseATM ClientValidate PIN use case

Server Side


47/51


Collaboration diagram:Collaboration diagram:

ATM ServerValidate PIN use caseATM ServerValidate PIN use case


48/51


Sequence Diagram:Sequence Diagram:



49/51


Statechart for ATM Control:Statechart for ATM Control:



50/51


Toplevel Statechart for ATM ControlToplevel Statechart for ATM Control


51/51


Statechart for ATM Control:Statechart for ATM Control:

Processing Customer Input superstateProcessing Customer Input superstate

Documents

ATM Details 1