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

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

<<server subsystem>> :BankS

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

Transfer

Confirm

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

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

: 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

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

: 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

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

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

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)

: CardReader

CardReaderInput

CardReaderOutput

write(cardData)

read(outCardData)Customer

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)

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)

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)

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

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

<< entity >> Savings Account

<<entity>> Debit Card

<<entity>> Card

Account

<<entity>> Account <<entity>>

Customer

<<entity>> Bank

<<entity>> ATMInfo

Provides Access to

Manages

HasOwns

Credits, Debits, Reads

Credits, Debits, Reads Credits,

Debits, Reads

Credits, Debits, Reads

Checks, Updates

Validates

Queries

Delegates to

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

ValidateCard Data

Account Numbers

Log Log

Account Data

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)

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

Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola.

Documents

Transcript of Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola.

MANTOVA DISPENSA SECONDA PARTE

Big Data en el entorno Bancario

Un breve analisis bancario

Plan Contable Bancario 2012

Manual Cajero Bancario II

EL Instituto Bancario Internacional

Sector Bancario y Financiero Sistemaaa

Boleto Bancario Processing Implementation Guide

Sistema Financiero Bancario

Feta Seconda parte

SECTOR DE INTERMEDIARIOS FINANCIEROS NO BANCARIO

Indicadores bancario citibank peru

yyxxCaurga seconda C

Reputación del sector bancario en Colombia

Emociones en El Sector Bancario 2014

Calendario Bancario 2015 Banesco

La Seconda Opportunità.

Catalogo PL-SQL de sistema bancario

Conversation ii luis vallarino

25 MT AUBURN ST, SUITE 203, CAMBRIDGE, MA, USA 02138 .... Vallarino EcoLogic...Barbara Vallarino, Executive Director. Gabriela González García, Regional Director of Programs. Margaret