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

Presentazione sul tema: "Caso di studio Sistema Bancario Seconda parte: Design Vallarino Paola."— Transcript della presentazione:

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

2 Dove siamo Posizione all’interno del ciclo di vita di COMET Requirements Modeling Analysis Modeling Design Modeling Incremental Software Construction Incremental Software Integration System Testing Throwaway Prototyping Incremental Prototyping User Customer

3 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

4 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

5 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

6 I Sottosistemi > :ATMClient > :BankServer 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

7 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

8 «subsystem» : BankServer «asynchronous I/O device» : CardReader «I/O device interface» : CardReader Interface «entity» : ATMCard 1.1:Card Input Data «user interface» : CustomerInterface 2.2:Card Data 2.1: Card Request 1.4: Pin Prompt 2.8: Selection Menu 2: PIN input 2.5: Validate PIN (customer Info) 2.6[Valid]: Valid PIN «state dependent control» : ATMControl 1.2: Card Inserted : ATM Customer «entity» : ATM Transaction 2.7: Update Status 2.3: Customer Info Validate PIN collaboration diagram 1.3: Get PIN 2.7: Display Menu 2.4: PIN Entered (Customer Info) 1:Card Reader input

9 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Output «I/O device interface» : CardReader Interface «client subsystem» :ATMClient «entity» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM Transaction Bank Responses «state dependent control» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «entity» : ATMCash «external output device» : Cash Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «entity» : ATM Transaction Transaction Details Update Transaction Status (Cash Details), Update PIN Status Customer Info Consolidated collaboration diagram (PIN Validate) Display Prompts Customer Events (Transaction Details) > :CashDipenser Intreface Cash Dispensed Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer Card Reader input Printer Output Transaction Request Transaction Data Print Receipt Receipt Printed

10 «subsystem» : BankServer «asynchronous I/O device» : CardReader 3.17: Card Reader Output «I/O device interface» : CardReader Interface «user interface» : CustomerInterface 3: Selection Input 3.4a.1: Wait Prompt 3.11a.1: Cash Dispensed Prompt 3.20: Cash Ejected Prompt ATM Transaction Bank Responses «state dependent control» : ATMControl 3.18: Card Ejected 3.16: Eject «entity» : ATMCash «external output device» : Cash Dispenser 3.9: Dispenser Output 3.7: Cash Withdrawal Amount 3.8: Cash Response : ATM Customer «entity» : ATM Transaction 3.2: Transaction Details 3.6a: Update Status (Cash Details) 3.1: Customer Selection Withdraw collaboration diagram 3.4a: Display Wait 3.11a: Display Cash Dispensed 3.19: Display Ejected 3.3: Withdrawal Selected (Transaction Details) > :CashDipenser Intreface 3.10 Cash Dispensed 3.6: Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer 3.14: Printer Output 3.12: Transaction Request 3.13:Transaction Data 3.15: Receipt Printed 3.11: Print Receipt

11 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Output «I/O device interface» : CardReader Interface «client subsystem» :ATMClient «entity» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «state dependent control» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «entity» : ATMCash «external output device» : Cash Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «entity» : ATM Transaction Transaction Details Update Transaction Status (Cash Details), Update PIN Status Customer Info Consolidated collaboration diagram (Withdraw Funds) Display Prompts Customer Events (Transaction Details) > :CashDipenser Intreface Cash Dispensed Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer Card Reader input Printer Output Transaction Request Transaction Data Print Receipt Receipt Printed

12 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Output «I/O device interface» : CardReader Interface «client subsystem» :ATMClient «entity» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «state dependent control» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «entity» : ATMCash «external output device» : Cash Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info 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) > :CashDipenser Intreface Cash Dispensed Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer Card Reader input Printer Output Transaction Request Transaction Data Print Receipt Receipt Printed note

13 Note ATMControl partecipa a tutte le collaborazioni lato client Alcuni messaggi sono aggregate messages Ad es. - CustomerEvents include - PINEntered - WithDrawalSelected - Display Prompts include - GetPIN, DisplayMenu - DisplayWait, DisplayCashDispensed, DisplayEject Il diagramma include tutte le alternative sequences Ad es. Confiscate e CardConfiscated sono originati dalla sequenza alternativa in cui la transazione non ha successo Consolidated Collaboration Diagram ATMClient

14 Refined Static Model ATMClient Nell’Analysis Modeling lo static model contiene solo classi «entity» :static model 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

15 > Customer Interface > ATMCard > CardReader Interface > CashDispenser Interface > ReceiptPrinter Interface > ATMControl > Operator Interface > ATM Cash > ATM Transaction > Withdrawal Transaction > Query Transaction > Transfer Transaction > PINValidation Transaction Reads Update Notifies Startup, Close Replenishes Controls Updates Creates Reads Notifies Controls Dispenses Refined Static Model Static model Consol. Coll. Diagram noteStatic model

16 Note La direzione di navigabilità sul class diagram riflette la direzione in cui gli oggetti comunicano con gli altri nel consolidated collaboration diagram Refined Static Model

17 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

18 «subsystem» : BankServer «asynchronous I/O device» : CardReader «I/O device interface» : CardReader Interface «entity» : ATMCard 1.1:Card Input Data «user interface» : CustomerInterface 2.2:Card Data 2.1: Card Request 1.4: PIN Prompt 2.8: Selection Menu 2: PIN Input 2.5: Validate PIN (customer Info) 2.6[Valid]: Valid PIN «state dependent control» : ATMControl 1.2: Card Inserted : ATM Customer «entity» : ATM Transaction 2.7: Update Status 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

19 Note CardReader Interface ---> è un task, ha il comportamento: all’inizio l’oggetto è “dormant” viene attivato da un interrupt legge l’input lo converte in un formato interno scrive i contenuti nell’ATMCard manda un CardInserted mess. all’ATMControl ATMCard ---> è un «data abstraction», non ha un thread di controllo separato ATMControl ---> control task manda getPIN mess. a Customer Interface ATMTransaction ---> è un «data abstraction», non ha un thread di controllo separato Analisi del PIN Validate Collaboration diagram

20 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Output <<asyncronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «state dependent control» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «external output device» : Cash Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Transaction Details Update Transaction Status (Cash Details), Update PIN Status Customer Info Intial Concurrent collaboration diagram (parziale) Display Prompts Customer Events (Transaction Details) > :CashDipenser Intreface Cash Dispensed Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer Card Reader input Printer Output Transaction Request Transaction Data Print Receipt Receipt Printed

21 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 InterfaceStatechart Analisi del Withdraw Funds Collaboration diagram

22 «subsystem» : BankServer «asynchronous I/O device» : CardReader 3.17: Card Reader Output «I/O device interface» : CardReader Interface «user interface» : CustomerInterface 3: Selection Input 3.4a.1: Wait Prompt 3.11a.1: Cash Dispensed Prompt 3.20: Cash Ejected Prompt ATM Transaction Bank Responses «state dependent control» : ATMControl 3.18: Card Ejected 3.16: Eject «entity» : ATMCash «external output device» : Cash Dispenser 3.9: Dispenser Output 3.7: Cash Withdrawal Amount 3.8: Cash Response : ATM Customer «entity» : ATM Transaction 3.2: Transaction Details 3.6a: Update Status (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) > :CashDipenser Interface 3.10 Cash Dispensed 3.6: Dispense Cash (Cash Details) > :ReceiptPrinter Interface > :Receipt Printer 3.14: Printer Output 3.12: Transaction Request 3.13: Transaction Data 3.15: Receipt Printed 3.11: Print Receipt statechart note

23 Note Il Cash Dispenser è un output device passivo -> non ha bisogno di un task separato. Non è possibile che l’ATMControl e il Cash Dispenser siano in esecuzione contemporaneamente perché il solo modo per l’ATMControl di lasciare lo stato dispensing (vedere statechart) è ricevere un messaggio dal Cash Dispenser. Perciò il Cash Dispenser può essere combinato con l’ATMControl secondo il principio del control clustering. Un ragionamento analogo può essere fatto per l’ATMCash. Si ottiene un unico task : ATMController Analisi del Withdraw Funds Collaboration diagram

24 EjectingPrinting Dispensing Processing Withdrawal Withdrawal OK / Dispense Cash Receipt Printed / Eject Cash Dispensed / Print Receipt Closed Down Entry/Diplay System Down Insufficient Cash/ Eject Statechart for ATMControl (partial)

25 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMController Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Transaction Data Transaction Details Update Transaction Status(Cash Details), Update PIN Status, Transaction Request Customer Info Initial concurrent collaboration diagram Customer Event (transaction Details) Display Prompts *

26 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Transaction Data Transaction Details Customer Info Initial concurrent collaboration diagram Update Transaction Status(Cash Details), Update PIN Status, Transaction Request Customer Event (transaction Details) Display Prompts * note

27 Note L’Operator user interface è un task poiché ha bisogno di un suo thread di controllo separato. L’ATM Cash invece è di tipo «data abstraction» N.B.: Non sono disponibili i collaboration diagrams che coinvolgono l’operatore! Concurrent Collaboration Diagram - Operator Interface

28 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

29 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard write (card Data) «user interface» : CustomerInterface read(out Card Data) Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMController Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output «user interface» : Operator Interface Addcash (in fivesAdded, in tenAdded, in twentiesAdded) : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Revised concurrent collaboration diagram Update Transaction Status(Cash Details), Update PIN Status, read(out Transaction Data) Customer Event (transaction Details) Display Prompts * updateCustomerInfo (cardData, PIN), updateCustomerSelection (in selection, out transactionDetails) Withdraw Cash (in cash Amount, out fivesTo Dispense, out tenTo Dispense, out twenties To Dispense) note

30 Note L’interfaccia tra ATMController e CustomerInterface deve essere loosely coupled perché: dopo aver mandato una richiesta al controller la customer interface non può bloccarsi perché deve poter ricevere operazioni di annullamento dal customer

31 «subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard write (card Data) «user interface» : CustomerInterface read(out Card Data) Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMController Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output «user interface» : Operator Interface Addcash (in fivesAdded, in tenAdded, in twentiesAdded) : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Revised concurrent collaboration diagram Update Transaction Status(Cash Details), Update PIN Status, read(out Transaction Data) Customer Event (transaction Details) Display Prompts * updateCustomerInfo (cardData, PIN), updateCustomerSelection (in selection, out transactionDetails) Withdraw Cash (in cash Amount, out fivesTo Dispense, out tenTo Dispense, out twenties To Dispense) note

32 Note ATMControl manda un messaggio di Eject o Confiscate al CardReader Interface Task. Questa comunicazione è tightly coupled perché, dopo aver spedito il messaggio all’ATMController, la CardReaderInterface aspetta un messaggio di ritorno di tipo Eject o Confiscate.

33 ATMClient «data abstraction» classes ATMTransaction «device interface» classes ReceiptPrinterInterface CashDispenserInterface «state dependent control» class ATMControl Information Hiding classes

34 > ATMTransaction - transactionID: String - cardID: String - PIN: String = null - selection: TransactionType - transactionData: TransactionRecord + updateCustomerInfo (cardData,PIN) +updateCustomerSelection (in selection, out transactionDetails) +updatePINStatus (status) +updateTransactionStatus (cashDetails) +read (out transactionData) ATMClient ATMTransaction Information Hiding Class

35 > ATMcontrol + processEvent (in event,out action) +currentState () :State ATMClient ATMControl Information Hiding Class

36 Task Behaviour Specifications Per documentare i task si sviluppa una Task Behaviour Specification (TBS) per ogni TaskTBS Ad es. TBS per CardReader Interface

37 Task Behaviour Specifications Una Task Behavior Specification (TBS) descrive l’interfaccia, la struttura, le caratteristiche temporali, la priorità relativa, la event sequencing logic e gli errori rilevati di un task. Le TBSs si sviluppano durante la task architecture, tranne l’event sequencing logic che viene rimandata al detailed software design.

38 TBS 1. Interfaccia del task: Input Input: Eventi: Card reader external interrupt to indicate that a card has been input. Input esterni: cardReaderInput Tightly coupled message communication : Eject,confiscate Output Output: Output esterni: cardReaderInput Loosely coupled message communication : cardInserted, cardEjected, cardConfiscated Passive object acceduti: ATMCard Card Reader Interface Task

39 TBS 2.Struttura del task: Criterio: Asynchronous Input Device Interface Oggetti mappati nel task : cardReaderInterface 3.Caratteristiche temporali:  Attivazione: Asynchronous-from external card reader. Worst case inter-arrival time = 500 msec. Average inter-arrival time > 5 minutes.  Tempo di esecuzione C i : 5ms per message Card Reader Interface Task

40 TBS 4.Priorità del task: High-Needs to be responsive to incoming cards. 5.Errori riscontrati: Unrecognized card. Card reader malfunction 6.Event sequence logic Rimandato alla fase di detailed software design Card Reader Interface Task

41 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

42 Detailed software design of ATM Controller (Design of ATMController connectors) > :CardReader Interface > :Operator Interface > :Customer Interface > CardReader MessageBuffer > ATMControl MessageQ > promptMessage Queue > bankServer Proxy > :ATMController receive (out cardreaderMsg) send (in ATMControl Request) send (in cardreaderMsg) send (in ATMTransaction, out bankResponse) send (in ATMControlRequest) receive (out displayPrompt) receive (out ATMControlRequest) send (in displayPrompt) note

43 Note ATMControl Message Queue Card Reader, Operator e Customer Interface sono tutti task produttori che chiamano l’operazione send del connettore Message Queue. Il connettore Message Queue mantiene una coda FIFO dei messaggi diretti all’ATMController Prompt Message Queue loosely coupled serve all’ATMController per mandare messaggi di Display Prompt a Customer Interface. Connettori Continua

44 Note Card Reader Message Buffer tightly coupled serve all’ATMController per mandare i messaggi Eject o Confiscate a Card Reader Interface Bank Server Proxy ATTIVO : per nascondere i dettagli della comunicazione con il Bank server remoto (comunicazione sincrona con risposta) Ad es. in Java si implementerebbe con una Remote Method Invocation Interface Connettori

45 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

46 > :ATMCoordinator > :ATMControl processEvent (in event, out action) > :ReceiptPrinter Interface > :CashDispenser Interface printReceipt (in receiptInfo, out printStatus) dispenseCash (in cashAmount, out dispenseStatus) > :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

47 Note Coordinator Object riceve i messaggi in arrivo all’ATM Controller coordina l’esecuzione degli altri tre oggetti interni ATMControl incapsula l’ATMStatechart (implementato come una state transition table) Struttura interna dell’ATMController

48 ATMClient Le TBSs vengono completate con lo sviluppo delle Task Event Sequencing Logic Ad es. CardReader Interface Task Event Sequencing Logic CardReader Interface Task Event Sequencing Logic ATMContol Task Event Sequencing Logic Detailed Software Design

49 -- Inizialize Card Reader; cardReaderDI.inizialize(); loop --Wait for external interrupt from card reader wait (cardReaderEvent); --Read card data held on card’s magnetic strip cardReaderDI.read (cardInput); if card recognized then... Il Card Reader Interface Task è svegliato da un evento esterno, legge la carta,... Task Event sequencing Logic Card Reader Interface Task

50 ATMClient ATMController Task CashDispenserInterface e ReceiptPrinterInterface sono oggetti contenuti nello stesso task quindi le azioni dispenseCash e printReceipt sono tradotte come semplici chiamate di funzioni. ATMController Task Behaviour Specification

51 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 PIN Server Withdraw Funds Server Transfer Funds Server Query Account Consolidate Collaboration Diagram

52 > :ATMClient > :PINValidation TransactionManager > :Debit Card > :Card Account Server ValidatePIN collaboration diagram V6: PINValidatio n Response (Status) V1: PINValidation Request (CardID, PIN) V2:Validate (CardID, PIN) V3: Card Data V4: Read (CardID) V5: Account Numbers indietro

53 > :ATMClient > :Account > :Withdrawal TransactionManager > :Transaction Log > :Debit Card Server WithdrawFunds collaboration diagram W1: Withdrawal Request (Transaction Details) W8: Withdrawal Response (Cash Details) W5: Account Data W4: Debit (Account#, Amount) W7: Log Transact ion W3: Daily Limit Response W2: Check Daily Limit (cardId, Amount) indietro W2: Update Daily Total (cardId, Amount)

54 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account > :Debit Card > :Card Account Consolidated collaboration diagram Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request note

55 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account > :Debit Card Consolidated collaboration diagram (Zoom) Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request Credit, Debit, Read Account Data Log Account Data Credit, Debit, Read Daily Limit Response Check, Update... indietro

56 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account Consolidated collaboration diagram (Zoom) Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request Read Account Data Log Read Account Data... indietro

57 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account > :Debit Card > :Card Account Consolidated collaboration diagram (Zoom) Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request Account Data Credit, Debit, Read Log Credit, Debit, Read Validate Card Data Account Numbers Read... indietro

58 Note Per ogni transazione c’è un Transaction Manager object che incapsula la business logic per la transazione Coordinator object riceve le richieste dai client delega le richieste al Transaction Manager appropriato Problema: i messaggi dal Withdrawal Transaction Manager agli Account possono essere Credit e Read? Consolidated Collaboration diagram per il Bank Server

59 BankServer Alcune classi del Conceptual Static Model risiedono nel Bank Server:Conceptual Static Model 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

60 Conceptual static Model for problem domain > :Checking Account > :Withdrawal Transaction > :Savings Account > :Debit Card > :Card Account > :Query Transaction > :Transfer Transaction > :PINValidation Transaction > : Account > : Customer > : Bank > : ATMInfo > : Transaction 1 Mantains  1 1 1..* 1 1,2 1..* * * * 0..1 Provides access to   Modifies Identifies  Owns  Manages  Has 

61 Refined Static Model > BankTransaction Server > Query TransactionManager > PINValidation TransactionManager > Withdrawal TransactionManager > Transfer TransactionManager > Checking Account > Transaction Log > Savings Account > Debit Card > Card Account > Account > Customer > Bank > ATMInfo Provides Access to Manages HasOwns Credits, Debits, Reads Logs Reads Checks, Updates Validates Queries Delegates to note

62 Note La direzione di navigabilità nel class diagram riflette la direzione in cui avvengono le comunicazioni tra gli oggetti nel Consolidate collaboration diagram Refined Static Model per il Bank Server

63 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 > Concurrent Task Architecture

64 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

65 Initial concurrent collaboration diagram > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account > :Debit Card > :Card Account Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request Account Data Credit, Debit, Read Log Credit, Debit, Read Validate Card Data Account Numbers Read Log Account Data note

66 Note Tutti gli oggetti all’interno del sottosistema BankServer sono passivi. Le entità sono diventate databasewrapper perché sono interfacce verso il database centralizzato del sistema bancario. Le database wrapper classes, quindi, non contengono dati. Al contrario delle data abstraction classes usate nell’ATMClient. Task Architecture per il Bank Server

67 Information Hiding Classes >: WithdrawalTransactionManager PinValidationTransactionManager QueryTransactionManager TransfeTransactionManager >: CardAccount TransactionLog DebitCard Account ( Cheking e Saving Account)

68 > CardAccount + read(in cardID,out accountNumber) +update (in cardID, out accountNumber) BankServer CardAccount Information Hiding Class

69 > WithdrawalTransactionManager + inizialize() + withdraw (in accountNumber, in amount, out w_response) + confirm (accountNumber, amount) + abort (acountNumber, amount) BankServer WithdrawalTransactionManager Information Hiding Class

70 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

71 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager > :Transaction Log > :Savings Account > :Debit Card > :Card Account Revised concurrent collaboration diagram 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

72 Note Oltre alle interfacce, nel Revised Concurrent Collaboration diagram vengono specificate le operazioni e i loro attributi Interfacce per il Bank Server

73 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Transfer TransactionManager Revised concurrent collaboration diagram (zoom)... > :Checking Account > :Transaction Log > :Savings Account transfer (in fromAccount, in toAccount#, in amount, out t_response) debit (account#, amount), credit (account#, amount), readBalance

74 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Query TransactionManager Revised concurrent collaboration diagram (zoom)... > :Checking Account > :Transaction Log > :Savings Account readBalance, readLast Deposit Amount log (in transaction) readBalance, readCumulative Interest query (in account#, out q_response)...

75 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Withdrawal TransactionManager Revised concurrent collaboration diagram (zoom)... > :Checking Account > :Transaction Log > :Savings Account Debit (account#, amount), credit (account#, amount), readBalance log (in transaction) checkDaily Limit (cardID, amount), updateDaily Total (cardID, amount)... withdraw (in account#, in amount, out w_response), confirm (account#, amount), abort (account#, amount) > :Debit Card log (in transaction)

76 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :PINValidation TransactionManager Revised concurrent collaboration diagram (zoom) > :Debit Card Validate (cardID, PIN) read (in cardID, out account#)... > :Card Account validatePIN (in cardID, in PIN, out v_response)

77 BankServer Event Sequencing Logic per il BankServer Task Detailed Software Design

78 Configurazione del sistema bancario :ATMClient {1 node per ATM} :BankServer {1 node} > Deployment diagram Sistema client-server => istanze multiple del sottosistema client e una istanza del sistema server Ogni istanza viene eseguita sul suo nodo

79 Alternativa Usare un server concorrente anziché un server sequenziale Differenza nella Task Architecture il BankTransactionServer e gli oggetti > sono progettati come task separati