Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola

Caso di studioSistema Bancario

Seconda parte: Design

Vallarino Paola

Dove siamoPosizione all’interno del ciclo di vita di COMET

Requirements Modeling

Analysis Modeling

Design Modeling

Incremental Software

ConstructionIncremental

Software Integration

System Testing

Throwaway Prototyping

Incremental Prototyping

User

Customer

Particolarità di questo caso di studio

Il sistema bancario è un sistema client-server quindi la divisione in sottosistemi è già stata fatta nell’Anaysis Modeling:

sottosistema ATMClient sottosistema BankServer

Fasi del Design in COMET

1 Sviluppo di un Consolidated Collaboration Diagram.

2 Divisione del sistema in sottosistemi e definizione delle interfacce dei sottosistemi.

3 Strutturazione in Task.4 Progettazione delle Information Hiding

Classes.5 Sviluppo del Detailed Software Design.

Eccezione per questo caso di studio

Indice

Definizione delle interfacce dei sottosistemi Sottosistema ATMClient

Consolidated Collaboration model Refined Static model Strutturazione in Tasks Information Hiding Classes Detailed Software Design

Sottosistema BankServer Consolidated Collaboration model Refined Static model Strutturazione in Tasks Information Hiding Classes

Configurazione del sistema

Argomenti trattati nel seminario

I Sottosistemi

<<Client subsystem>> :ATMC

lient

<<server subsystem>> :BankS

erver

Definizione delle distributed message interfaces

ATMTransaction

bankResponse

La message Interface è una Tightly coupled message communication con risposta.

I messaggi scambiati sono aggregate messages.

IL server usa una coda FIFO per la gestione dei messaggi provenienti da più client.

PIN Validation

Withdraw

Query

Transfer

Confirm

Abort

Il sottosistema ATMClient

Il Consolidated Collaboration diagram per l’ATMClient è il risultato dell’unione (merge) dei collaboration diagrams sviluppati nella fase precedente per gli use cases: Client Validate PIN Client Withdraw Funds Client Transfer Funds Client Query Account Operator Add Cash, Startup, Shutdown

Consolidated Collaboration Model

«subsystem»: BankServer

«asynchronousI/O device»

: CardReader

CardReaderOutput

«I/O deviceinterface»

: CardReaderInterface

«client subsystem»:ATMClient

«entity»: ATMCard

CardInputData

«user interface»: CustomerInterface

CardData

CardRequest

CustomerInput

DisplayInformation

ATM Transaction Bank Responses

«state dependentcontrol»

: ATMControl

Card Inserted,Card Ejected,

CardConfiscated

Eject,Confiscate

«entity»: ATMCash

«externaloutput

device»: Cash

Dispenser

Dispenser Output

Cash Withdrawal

Amount

CashResponse

«userinterface»: OperatorInterface

CashAdded

: ATMCustomer

: OperatorOperatorInput

OperatorInfo

Start Up,Closedown

«entity»: ATM

Transaction

Transaction Details

Update Transaction

Status (Cash Details), Update PIN Status

Customer Info

Consolidated collaboration diagram

Display Prompts

Customer Events

(Transaction Details)

<<output device interface>> :CashDipenser Intreface

Cash Dispensed

Dispense Cash (Cash Details)

<<output device interface>> :ReceiptPrinter Interface

<<external output device>> :Receipt Printer

Card Reader input

Printer Output

Transaction Request

Transaction Data

Print Receipt

Receipt Printed

note

Refined Static Model

ATMClient

Nell’Analysis Modeling lo static model contiene solo classi «entity» :

ATMTransaction WithdrawalTransaction TransferTransaction PINValidation

Sulla base del Consolidate Collaboration diagram si sviluppa un Refined Static model che include le classi da cui sono istanziati gli oggetti del C.C.D

<<user interface>> Customer Interface

<<entity>> ATMCard

<<device interface>> CardReader Interface

<<device interface>> CashDispenser Interface

<<device interface>> ReceiptPrinter Interface

<<state dependent control>>

ATMControl

<<user interface>> Operator Interface

<<entity>> ATM Cash

<<entity>> ATM

Transaction

<<entity>> Withdrawal Transaction

<<entity>> Query

Transaction

<<entity>> Transfer

Transaction

<<entity>> PINValidation

Transaction

ReadsUpdate

Notifies

Startup, Close

Replenishes

ControlsUpdates

Creates Reads

NotifiesControls

Dispenses


Static model

Consol.Coll.Diagram

note Static model

ATMClient

Per determinare i task del sottosistema consideriamo i collaboration diagram dell’Analysis Model, in particolare: PINValidate WithdrawFunds

Per ognuno analizziamo la sequenza dei messaggi scambiati tra gli oggetti

Progettazione della Concurrent Task Architecture



: CardReader



«entity»: ATMCard

1.1:CardInputData


2.2:CardData

2.1: CardRequest

1.4: PIN Prompt2.8: Selection Menu

2: PIN Input

2.5: Validate PIN (customer Info)

2.6[Valid]: Valid PIN


: ATMControl

1.2: Card Inserted

: ATMCustomer

«entity»: ATM

Transaction

2.7: UpdateStatus

2.3: Customer Info

Analisi del Validate PIN collaboration diagram

1.3: Get PIN 2.7: Display Menu

2.4: PIN Entered

(Customer Info)

1:Card Reader input

note



: CardReader

CardReaderOutput

<<asyncronousI/O deviceinterface»



«data abstraction»: ATMCard

CardInputData


CardData

CardRequest

CustomerInput

DisplayInformation



: ATMControl


CardConfiscated

Eject,Confiscate

«data abstraction»: ATMCash

«externaloutput

device»: Cash

Dispenser

Dispenser Output

Cash Withdrawal

Amount

CashResponse


CashAdded

: ATMCustomer

: OperatorOperatorInput

OperatorInfo

Start Up,Closedown

«dataabstraction»

: ATMTransaction

Transaction Details

Update Transaction

Status (Cash Details), Update PIN Status

Customer Info

Intial Concurrent collaboration diagram (parziale)

Display Prompts

Customer Events

(Transaction Details)

<<output device interface>> :CashDipenser Intreface

Cash Dispensed

Dispense Cash (Cash Details)



Card Reader input

Printer Output

Transaction Request

Transaction Data

Print Receipt

Receipt Printed

ATMClient

Questo collaboration diagram ha molti oggetti in comune con quello per PINvalidate.

In più ha: Receipt Printer Interface Cash Dispenser Interface ATMCash

Occorre analizzare l’ATMControl Statechart per capire come ATMControl interagisce con Receipt Printer Interface e Cash Dispenser Interface

Analisi del Withdraw Funds Collaboration diagram



: CardReader

3.17: CardReaderOutput



«user interface»: CustomerInterface3: Selection

Input

3.4a.1: Wait Prompt3.11a.1: Cash Dispensed Prompt3.20: Cash Ejected Prompt



: ATMControl

3.18: Card Ejected

3.16: Eject

«entity»: ATMCash

«externaloutput

device»: Cash

Dispenser

3.9: Dispenser Output

3.7: Cash Withdrawal

Amount

3.8: CashResponse

: ATMCustomer

«entity»: ATM

Transaction3.2: Transaction

Details

3.6a: UpdateStatus (Cash Details)

3.1: Customer Selection

Analisi del Withdraw collaboration diagram

3.4a: Display Wait 3.11a: Display Cash Dispensed 3.19: Display Ejected

3.3: Withdrawal

Selected (Transaction

Details)

<<output device interface>> :CashDipenser Interface

3.10 Cash Dispensed

3.6: Dispense Cash (Cash Details)



3.14: Printer Output

3.12: Transaction

Request

3.13: Transaction Data

3.15: Receipt Printed

3.11: Print Receipt

statechart

note



: CardReader

CardReaderInput

CardReaderOutput

«asynchronousI/O deviceinterface»



«dataabstraction»: ATMCard

CardInputData


CardData

CardRequest

CustomerInput

DisplayInformation


«controlclustering»

: ATMController


CardConfiscated

Eject,Confiscate

«dataabstraction»: ATMCash

«passiveoutput

device»: Cash

Dispenser

Dispenser Output

Cash Withdrawal Amount

CashResponse


CashAdded

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown

«data abstraction»: ATM Transaction

Transaction Data

Transaction Details

Update TransactionStatus(Cash Details), Update PIN Status,Transaction Request

Customer Info

Initial concurrent collaboration diagram

CustomerEvent(transactionDetails)

DisplayPrompts

*



: CardReader

CardReaderInput

CardReaderOutput





CardInputData


CardData

CardRequestCustomer

Input

DisplayInformation



: ATMControl


CardConfiscated

Eject,Confiscate


«passiveoutput

device»: Cash

Dispenser

Dispenser Output

Cash Withdrawal Amount

CashResponse


CashAdded

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown


Transaction Data

Transaction Details

Customer Info

Initial concurrent collaboration diagram

Update TransactionStatus(Cash Details), Update PIN Status,Transaction Request


DisplayPrompts

*

note

ATMClient

L’oggetto ATMController Task comunica con tutti i task nel sottosistema ATMClient.

In particolare vediamo le interfacce della comunicazione tra l’ATMController e : Customer Interface CardReader Interface

Tutte le interfacce vengono raffigurate in un Revised Concurrent Collaboration Diagram

Definizione delle Task Interfaces



: CardReader

CardReaderInput

CardReaderOutput





write(cardData)


read(outCardData)Customer

Input

DisplayInformation



: ATMController


CardConfiscated

Eject,Confiscate


«passiveoutput

device»: Cash

DispenserDispenser Output


Addcash (in fivesAdded, in tenAdded,in twentiesAdded)

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown


Revised concurrent collaboration diagram

Update TransactionStatus(Cash Details), Update PIN Status,

read(out Transaction Data)


DisplayPrompts *

updateCustomerInfo(cardData, PIN),

updateCustomerSelection(in selection,

out transactionDetails)

Withdraw Cash (in cash Amount, out fivesTo Dispense, out tenTo Dispense, out twenties ToDispense)

note



: CardReader

CardReaderInput

CardReaderOutput





write(cardData)


read(outCardData)Customer

Input

DisplayInformation



: ATMController


CardConfiscated

Eject,Confiscate


«passiveoutput

device»: Cash

DispenserDispenser Output


Addcash (in fivesAdded, in tenAdded,in twentiesAdded)

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown



Update TransactionStatus(Cash Details), Update PIN Status,

read(out Transaction Data)


DisplayPrompts *

updateCustomerInfo(cardData, PIN),

updateCustomerSelection(in selection,

out transactionDetails)

Withdraw Cash (in cash Amount, out fivesTo Dispense, out tenTo Dispense, out twenties ToDispense)

note

ATMClient

«data abstraction» classes ATMTransaction

«device interface» classes ReceiptPrinterInterface CashDispenserInterface

«state dependent control» class ATMControl

Information Hiding classes

Task Behaviour Specifications Per documentare i task si sviluppa una Task Behaviour

Specification (TBS) per ogni Task

Ad es. TBS per CardReader Interface

ATMClient

L’ATMController ha una loosely coupled message comunication interface attraverso cui riceve i messaggi.

Il meccanismo di comunicazione viene incapsulato in un Connettore ( ATMControl Message Queue)

Sviluppo del Detailed Software Design

Detailed software design of ATM Controller (Design of ATMController connectors)

<<Asyncronous I/O device

interface>> :CardReader Interface

<<user interface>> :Operator

Interface

<<user interface>> :Customer

Interface

<<connector>> CardReader

MessageBuffer

<<connector>> ATMControl

MessageQ

<<connector>> promptMessage Queue

<<connector>> bankServer Proxy

<<control clustering>> :ATMCo

ntroller

receive (out cardreaderMsg)

send (in ATMControl Request)

send (in ATMControlRequest) send (in

cardreaderMsg)send (in

ATMTransaction, out bankResponse)

send (in ATMControlRequest)

receive (out displayPrompt)

receive (out ATMControlRequest)

send (in displayPrompt)

note

ATMClient

L’ATM Controller è un task che ha al suo interno oggetti passivi

Occorre definire la sua struttura interna: Coordinator object ATMControl CashDispenser Interface ReceiptPrinter Interface

Detailed Software Design

<<coordinator>>:ATMCoordinator

<<state dependent control>>

:ATMControl

processEvent (in event, out action)

<<output device interface>>

:ReceiptPrinter Interface

<<output device interface>>

:CashDispenser Interface

printReceipt (in receiptInfo, out

printStatus)

dispenseCash(in cashAmount,

out dispenseStatus)

<<control clustering>>:ATMController

send (in ATMTransaction,out bankResponse

send (in cardReader msg)

receive (out ATMControl Request)

send (in display Prompt)

updateTransaction (cashDetails), updatePINStatus (status)

printer Output

read (out transaction data)

Dispenser Output

Detailed software design of ATM Controller (Internal Design of ATMController)

note

statechart

ATMClient

Le TBSs vengono completate con lo sviluppo delle Task Event Sequencing Logic

Ad es. CardReader Interface Task Event

Sequencing Logic

ATMContol Task Event Sequencing Logic

Detailed Software Design

Il sottosistema BankServer

Il Consolidated Collaboration diagram per il sottosistema BankServer è il risultato dell’unione (merge) dei collaboration diagram sviluppati per gli use cases:

Server Validate PINServer Withdraw FundsServer Transfer FundsServer Query Account

Consolidate Collaboration Diagram

<<subsistem>> :ATMClient

<<coordinator>> :BankTransactionServer

ATM Transaction

bankResponse

<<server subsystem>> :BankServer

<<business logic>> :Transfer

TransactionManager

<<entity>> :Checking Account

<<business logic>> :Query

TransactionManager

<<business logic>> :PINValidation TransactionManager

<<business logic>> :Withdrawal TransactionManager

<< entity >> :Transacti

on Log

<< entity >> :Savings Account

<<entity>> :Debit Card

<<entity>> :Card

Account

Consolidated collaboration diagram

Transfer Response

Query Transaction Query

ResponseTransfer Transaction

Withdraw Response

Withdraw, Confirm,

AbortPINValidation

Response

PINValidation Request

note

BankServer

Alcune classi del Conceptual Static Model risiedono nel Bank Server: Account, Customer, Bank, ATMInfo, Card

Account, Debit Card

Dal Consolidate Collaboration diagram si ottengono le classi da cui sono istanziati gli oggetti del diagramma: BankTransactionServer, i 4 Transaction

Manager, Transaction Log


Refined Static Model<<coordinator>> BankTransaction

Server

<<business logic>> Query

TransactionManager

<<business logic>> PINValidation

TransactionManager

<<business logic>> Withdrawal

TransactionManager

<<business logic>> Transfer

TransactionManager

<<entity>> Checking Account

<< entity >> Transaction

Log

<< entity >> Savings Account

<<entity>> Debit Card

<<entity>> Card

Account

<<entity>> Account <<entity>>

Customer

<<entity>> Bank

<<entity>> ATMInfo

Provides Access to

Manages

HasOwns

Owns

Credits, Debits, Reads

Credits, Debits, Reads Credits,

Debits, Reads

Credits, Debits, Reads

Logs

Logs

Logs

Reads

Reads

Checks, Updates

Validates

Queries

Delegates to

Delegates to

Delegates to

Delegates to

note

BankServer

Il BankServer contiene il Database Centralizzato del sistema bancario

Business Decision: le entity classes nel server devono essere memorizzate come relazioni (flat files) di un database relazionale.

Queste classi incapsuleranno le interfaccie per il database e saranno <<database wrapper classes>>

Concurrent Task Architecture

BankServer

Decisione: usare un server sequenziale (ogni transazione è messa in una coda FIFO e aspetta la fine della precedente per essere attivata)

Con questa scelta il server risulta essere un unico task (un unico thread di controllo)

Concurrent Tasks Architecture

Initial concurrent collaboration diagram<<subsistem>>

:ATMClient


ATM Transaction

bankResponse



TransactionManager

<<database wrapper>> :

Checking Account


TransactionManager



<<database wrapper>> :Transaction Log


Savings Account

<<database wrapper>> :Debit Card

<<database wrapper>>

:Card Account

Transfer Response

Query Transaction Query

ResponseTransfer Transaction

Withdraw Response

Withdraw, Confirm,

AbortPINValidation

Response

PINValidation Request

Account Data

Credit, Debit, Read

Log

Credit, Debit, Read

ValidateCard Data

Account Numbers

Read

Log Log

Account Data

note

Information Hiding Classes <<business logic>>:

WithdrawalTransactionManager PinValidationTransactionManager QueryTransactionManager TransfeTransactionManager

<<database wrapper>>: CardAccount TransactionLog DebitCard Account ( Cheking e Saving Account)

BankServer

Ogni transazione è eseguita fino alla fine e ritorna il risultato al BankTransaction Server

Le interfacce interne al sottosistema sono di tipo sincrono (vengono definite in termini di chiamate di operazioni)

Definizione delle Interfacce

<<subsistem>> :ATMClient


ATM Transaction

bankResponse



TransactionManager


Checking Account


TransactionManager



<<database wrapper>> :Transaction Log


Savings Account

<<database wrapper>> :Debit Card

<<database wrapper>>

:Card Account


transfer (in fromAccount, in toAccount#, in amount, out t_response)

query (in account#, out q_response)

withdraw (in account#, in amount, out w_response), confirm (account#, amount), abort (account#, amount)

validatePIN (in cardID, in PIN, out v_response)

note

Configurazione del sistema bancario

:ATMClient

{1 node per ATM}

:BankServer

{1 node}

<<wide area network>>

Deployment diagram

Sistema client-server => istanze multiple del sottosistema client e una istanza del sistema server

Ogni istanza viene eseguita sul suo nodo

Alternativa

Usare un server concorrente anziché un server sequenziale

Differenza nella Task Architecture il BankTransactionServer e gli oggetti

<<business logic>> sono progettati come task separati

Documents

Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola