SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico 2000 - 2001 Demergasso Daniela.

Presentazione sul tema: "SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico 2000 - 2001 Demergasso Daniela."— Transcript della presentazione:

1 SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico 2000 - 2001 Demergasso Daniela

2 SOFTWARE ARCHITECTURAL DESIGN Design modeling phase and software architectural design Software architectural styles System decomposition System decomposition issues Guidelines to determining subsystems Separation of concerns in subsystems design Kinds of subsystems (Subsystem structuring criteria) Static modeling at the design level Consolidated collaboration diagrams Refined static model (Esempio: Banking System)

3 DESIGN MODELING PHASE AND SOFTWARE ARCHITECTURAL DESIGN Nella DESIGN MODELING PHASE del metodo COMET si progetta l’architettura software dell’intero sistema. L’enfasi si sposta sul dominio della soluzione Lo scopo è definire un refined static model per il dominio della soluzione come raffinamento dello static model per il dominio del problema.

4 DESIGN MODELING PHASE AND ARCHITECTURAL SOFTWARE DESIGN Si compone di diverse attività: Individuazione del architectural style più adatto al sistema in base ai risultati dell’analysis modeling fase. Suddivisione del sistema in sottosistemi in base alle funzionalità degli oggetti che lo compongono. Realizzazione del consolidated collaboration diagram per ogni sottosistema. Realizzazione del refined static model.

5 SOFTWARE ARCHITECTURAL STYLES Sono identificabili diversi stili di architetture software per applicazioni concorrenti: client/server architectural style layers of abstraction architectural style communicating task architectural style blending architectural style

6 CLIENT /SERVER ARCHITECTURAL STYLE Usato per applicazioni distribuite. Ogni server fornisce servizi di cui usufruiscono i client. L’architettura più semplice prevede un unico server e molti client.

7 CLIENT/SERVER ARCHITECTURAL STYLE > Banking System > ATMClient Subsystem > BankServer Subsystem 1..* 1 > Receipt Printer > Cash Dispenser > Card Reader > Operator > ATMCustomer 1 11 11 1 1 1 1 ESEMPIO: Banking System 1 note

8 CLIENT/SERVER ARCHITECTURAL STYLE ESEMPIO: applicazione ATM per una singola banca con server centrale. Si evidenzia, con l’indicazione della cardinalità delle relazioni tra sottosistemi e/o oggetti, che un unico server interagisce con uno o più client.

9 CLENT/SERVER ARCHITECTURAL STYLE Sistemi più complessi usano più server comunicanti tra loro. Ogni client può interagire con uno o più server. ESEMPIO: Un consorzio interbancario consiste di molte banche interconnesse, dotate di sistemi del tipo visto nell’esempio precedente (sistemi multi-client/multi- server).

10 CLIENT/SERVER ARCHITECTURAL STYLE Alcuni sistemi usano: BROKER I client richiedono servizi ai broker che ne favoriscono la localizzazione. COMMUNICATING SOFTWARE AGENTS Sono intermediari tra client e server.

11 LAYERS OF ABSTRACTION ARCHITECTURAL STYLE Il sistema è strutturato a livelli. Ad ogni livello i componenti forniscono servizi al livello superiore. Ogni livello fornisce una classe distinta di servizi. Un componente può richiedere servizi ad un componente di livello inferiore ma non ad uno di livello superiore.

12 LAYERS OF ABSTRACTION ARCHITECTURAL STYLE > AutoControl Subsystem > Distance&Speed Subsystem > Calibration Subsystem > Shaft Subsystem > TripAverages Subsystem > Maintenance Subsystem ESEMPIO: Cruise Control and Monitoring System note

13 LAYERS OF ABSTRACTION ARCHITECTURAL STYLE ESEMPIO: Cruise Control and Monitoring System. Il design del sistema è una gerarchia in cui i sottosistemi a basso livello computano i dati usati dai sottosistemi ai livelli più alti.

14 COMMUNICATING TASK ARCHITECTURAL STYLE Usato con applicazioni distribuite e real-time. Si ha una rete di task (processi) concorrenti con flusso di controllo separato per ogni task. Esistono due varianti: task comunicanti mediante memoria condivisa: i task concorrenti risiedono sullo stesso nodo e devono essere sincronizzati task comunicanti senza memoria condivisa: i task possono essere allocati su nodi differenti in ambiente distribuito

15 COMMUNICATING TASK ARCHITECTURAL STYLE ESEMPIO: distribuited software architecture: Elevator Control System. > :ElevatorLamp > :Motor > :ArrivalSensor > :ElevatorButton > :Scheduler > :FloorButton > :DirectionLamp > :ElevatorSubsystem > :FloorLamp > :FloorSubsystem > :Door Arrival Sensor Input Door Command Door ReponseElevator Lamp Output Elevator Button Request Motor Command Motor Reponse Floor Lamp Command Direction Lamp Command Service Request Scheduler Request Arrival(Floor#) Departed(Floor#) Elevator Commitment Direction Lamp Output Floor Lamp Output Floor Button Request > :ElevatorControl System note

16 COMMUNICATING TASK ARCHITECTURAL STYLE ESEMPIO: distribuited software architecture: Elevator Control System. Ad ogni sottosistema corrisponde un task che porta a termine un determinato compito. L’architettura usa una rete di tasks concorrenti comunicanti mediante scambio di messaggi. C’è un unico :Scheduler che coordina le attività dei :FloorSubsystem e :ElevatorSubsystem. Si possono avere più istanze di :FloorSubsystem ed :ElevatorSubsystem, rispettivamente per ogni piano e ogni ascensore.

17 BLENDING ARCHITECTURAL STYLE Gli stili visti non sono mutuamente esclusivi. Alcuni esempi: architettura stratificata con una rete di task concorrenti ad ogni strato (Cruise Control and Monitoring System) comunicazioni client/server tra sottosistemi di task entro una rete di task distribuiti (Factory Automation System)

18 SYSTEM DECOMPOSITION ISSUES Un sottosistema deve contenere oggetti fortemente dipendenti tra loro dal punto di vista funzionale (high coupling). Un sottosistema dovrebbe essere relativamente indipendente dagli altri sottosistemi (low coupling). Un sottosistema è visto come un oggetto composto o aggregato. Nella fase di decomposizione in sottosistemi l’enfasi è sulla separation of concerns.

19 SYSTEM DECOMPOSITION ISSUES Un sottositema può a sua volta essere suddiviso in sottosistemi. Indipendenza nel subsystem design. Decomposizione del sistema a partire dagli use case. High o low coupling a seconda della partecipazione agli use case. Un oggetto è assegnato al sottosistema con cui ha accoppiamento più stretto.

20 GUIDELINES FOR DETERMINING SUBSYSTEMS I sottosistemi sono identificabili in base a: distribuzione geografica è “ricavata” dalla descrizione del problema. Coopartecipazione allo use case gli oggetti nello stesso use case sono candidati ad essere nello stesso sottosistema purché non siano geograficamente distribuiti.

21 GUIDELINES FOR DETERMINING SUBSYSTEMS > Banking System > ATMClient Subsystem > BankServer Subsystem 1..* 1 ESEMPIO: sistema client/server decomposto per distribuzione geografica

22 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN La SEPARATION OF CONCERNS è fatta considerando la natura degli oggetti componenti il sistema. Concern = pertinenza, partecipazione, preoccupazione

23 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN AGGREGATE/COMPOSITE OBJECT Oggetti appartenenti allo stesso oggetto composto o aggregato rientrano nello stesso sottosistema. Un oggetto composto è costituito da oggetti collegati che lavorano in modo coordinato. Un’applicazione può prevedere l’uso di più istanze di un oggetto composto e di ognuno dei suoi oggetti costituenti.

24 COMPOSITION AND AGGREGATION HIERARCHIES COMPOSITION e AGGREGATION sono particolari relazioni di tipo is part of. Composition è più forte di aggregation. Composition: le componenti sono create, vivono e muoiono con l’intero. Ogni componente può appartenere ad un unico intero. Aggregation: le istanze di componenti sono aggiunte o rimosse dall’aggregato. Ogni componente può appartenere a più aggregazioni.

25 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN La relazione tra oggetti composti e loro costituenti è descritta mediante class diagram che consente di indicare la molteplicità delle associazioni. 1..* 11 Elevator ElevatorButtonElevatorLamp MotorDoor destinationFloor#: Integer elevator#: Integer currentFloor#: Integer direction: DirectionType

26 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN GEOGRAPHICAL LOCATION Oggetti separati in locazioni differenti sono in diversi sottosistemi. La comunicazione tra sottosistemi in ambiente distribuito avviene con scambio di messaggi. ESEMPIO: Elevator Control SystemElevator Control System Ogni istanza del sottosistema elevator potrebbe risiedere su un microprocessore posto sull’ascensore reale.

27 ESEMPIO: Elevator Control System. > :ElevatorLamp > :Motor > :ArrivalSensor > :ElevatorButton > :Scheduler > :FloorButton > :DirectionLamp > :ElevatorSubsystem > :FloorLamp > :FloorSubsystem > :Door Arrival Sensor Input Door Command Door ReponseElevator Lamp Output Elevator Button Request Motor Command Motor Reponse Floor Lamp Command Direction Lamp Command Service Request Scheduler Request Arrival(Floor#) Departed(Floor#) Elevator Commitment Direction Lamp Output Floor Lamp Output Floor Button Request > :ElevatorControl System SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN

28 CLIENT AND SERVER Client e server devono essere in sottosistemi separati. ESEMPIO: Banking System.Banking System. INTERFACE TO EXTERNAL OBJECTS Ogni oggetto esterno deve interfacciarsi con un solo sottosistema. ESEMPIO: Elevator Control System.Elevator Control System.

29 > Banking System > ATMClient Subsystem > BankServer Subsystem 1..* 1 > Receipt Printer > Cash Dispenser > Card Reader > Operator > ATMCustomer 1 11 11 1 1 1 1 ESEMPIO: Banking System 1 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN

30 > :ElevatorLamp > :Motor > :ArrivalSensor > :ElevatorButton > :Scheduler > :FloorButton > :DirectionLamp > :ElevatorSubsystem > :FloorLamp > :FloorSubsystem > :Door Arrival Sensor Input Door Command Door Reponse Elevator Lamp Output Elevator Button Request Motor Command Motor Reponse Direction Lamp Output Floor Lamp Output Floor Button Request > :ElevatorControl System note

31 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN Ognuno degli external object considerati si interfaccia con un unico sottosistema. :ElevatorSubsystem si interfaccia con gli external device :Motor, :ElevatorButton, :ElevatorLamp, :ArrivalSensor e :Door. :FloorSubsystem con :FloorButton, :FloorLamp e :DirectionalLamp.

32 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN USER INTERFACE Per ogni interfaccia utente individuata si ha un sottosistema (maggior flessibilità). Gli oggetti interfaccia sono spesso client. Sono spesso oggetti aggregati.

33 SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN SCOPE OF CONTROL Un control object, tutte le entità e gli oggetti interfaccia da esso controllati sono nello stesso sottosistema.control object ENTITY OBJECT High coupling con gli oggetti che lo aggiornano, low coupling con quelli che leggono da esso. E’ nello stesso sottosistema degli oggetti che l’aggiornano.

34 ENTITY OBJECT Oggetto che conserva informazioni. E’ un oggetto cui tipicamente accedono diversi use cases.

35 STATE-DEPENDENT CONTROL OBJECT CONTROL OBJECT fornisce coordinazione per l’escuzione di uno use case. STATE-DEPENDENT CONTROL OBJECT Control object il cui comportamento varia a seconda del proprio stato. Riceve eventi a fronte dei quali cambia stato e genera altri eventi con cui controlla altri oggetti. Il suo output dipende dall’input ricevuto e dallo stato corrente.

36 KINDS OF SUBSYSTEMS Esistono diversi tipi di sottosistemi: CONTROL SUBSYSTEM Controlla un dato aspetto del sistema. Se state-dipendent include uno state-dependent control object.state-dependent control object Riceve input dall’ambiente esterno o da altri sottosistemi. Genera output verso l’ambiente esterno o verso altri sottosistemi. ESEMPIO: Elevator Control Subsystem Elevator Control Subsystem

37 KINDS OF SUBSYSTEMS Control Subsystem > :Scheduler > :ElevatorSubsystem > :FloorSubsystem Floor Lamp Command Direction Lamp Command Service Request Scheduler Request Arrival(Floor#) Departed(Floor#) Elevator Commitment > :ElevatorControl System ESEMPIO: Control Subsystem nell’Elevator Control System note

38 KINDS OF SUBSYSTEMS Control Subsystem L’:ElevatorSubsystem è un control subsystem. Dice cosa fare a Direction Lamp e Floor Lamp del :FloorSubsystem in base alle richieste del subsystem :Scheduler.

39 KINDS OF SUBSYSTEMS COORDINATOR SUBSYSTEM Coordina i control subsystems qualora questi non siano completamente indipendenti. L’uso del coordinator subsystem è vantaggioso rispetto ad un approccio che prevede che i control subsystem si coordinino da se. ESEMPIO: Elevator Control Subsystem Elevator Control Subsystem

40 KINDS OF SUBSYSTEMS Coordinator Subsystem > :Scheduler > :ElevatorSubsystem > :FloorSubsystem Floor Lamp Command Direction Lamp Command Service Request Scheduler Request Arrival(Floor#) Departed(Floor#) Elevator Commitment > :ElevatorControl System ESEMPIO: Coordinator Subsystem nell’Elevator Control System note

41 KINDS OF SUBSYSTEMS Coordinator Subsystem Lo :Scheduler è un coordinator subsystem. Coordina l’attività di :ElevatorSubsystem in base a: richieste di servizio del :FloorSubsystem informazioni fornite dall’ :ElevatorSubsystem stesso. :ElevatorSubsystem istruirà quindi il :FloorSubsystem da esso dipendente. :Scheduler non interagisce con external object.

42 KINDS OF SUBSYSTEMS DATA COLLECTION SUBSYSTEM Memorizza i dati raccolti dall’esterno dopo averli analizzati e ridotti. Risponde a richieste sui dati da parte di altri sottosistemi. DATA ANALYSIS SUBSYSTEM Analizza dati e riporta risultati ad altri sottosistemi. Data analysis, al contrario di data collection, non è fatta a real-time. ESEMPIO: Data Collection e Data Analysis Subsystems.

43 KINDS OF SUBSYSTEMS Data Collection and Data Analysis Subsystems > :SensorDataCollection > :SensorDataAnalysis > :OperatorInterface > :SensorDataServer Raw Sensor Data Process Sensor Data Sensor Reports Sensor Display Data Operator Request Displayed Information Processed Sensor Data Sensor Data Request Sensor Data note

44 KINDS OF SUBSYSTEMS Data Collection and Data Analysis Subsystems :SensorDataCollection raccoglie dati “grezzi” da sensori digitali e analogici. I dati analogici sono convertiti in unità appropriate. I dati sono mandati al :SensorDataAnalysis subsystem che: li analizza esegue analisi statistiche produce resoconti rileva e notifica l’esistenza di scostamenti rispetto a quanto atteso.

45 KINDS OF SUBSYSTEMS SERVER SUBSYSTEM Fornisce servizi ai sottosistemi che li hanno richiesti. Coprende coordinator objects e business logic objects. Tipici servizi di server subsystem sono accessi a data base o a I/O devices. ESEMPIO: Sensor Data Server

46 KINDS OF SUBSYSTEMS Server Subsystem > :SensorDataCollection > :SensorDataAnalysis > :OperatorInterface > :SensorDataServer Raw Sensor Data Process Sensor Data Sensor Reports Sensor Display Data Operator Request Displayed Information Processed Sensor Data Sensor Data Request Sensor Data note

47 KINDS OF SUBSYSTEMS Server Subsystem :SensorDataServer è il server subsystem. Immagazzina dati storici e correnti forniti da :SensorDataCollection. I dati sono trasmessi al sottosistema che ne fa richiesta.

48 KINDS OF SUBSYSTEMS USER INTERFACE SUBSYSTEM Fornisce l’interfaccia utente e l’accesso ai servizi forniti dai server. Può esserci uno user interface subsystem per ogni categoria di utenti. E’ spesso un oggetto composto formato da user interface objects semplici. ESEMPIO: Operator Interface Subsystem

49 KINDS OF SUBSYSTEMS User Interface Subsystem > :SensorDataCollection > :SensorDataAnalysis > :OperatorInterface > :SensorDataServer Raw Sensor Data Process Sensor Data Sensor Reports Sensor Display Data Operator Request Displayed Information Processed Sensor Data Sensor Data Request Sensor Data note

50 KINDS OF SUBSYSTEMS User Interface Subsystem :OperatorInterface è lo user interface subsystem. Ha la funzione di visualizzare le informazioni richieste. Richiede i dati al server subsystem. Ne possono esistere molteplici istanze.

51 KINDS OF SUBSYSTEMS I/O SUBSYSTEM Raggruppa device interface classes. Uso funzionale allo sviluppo di device interface classes. SYSTEM SERVICES SUBSYSTEM Fornisce servizi tipici del livello di sistema. Sottosistemi di questo tipo non sono parte dell’applicazione.

52 STATIC MODELING AT THE DESIGN LEVEL Design modeling phase: sviluppo di un class diagram per il dominio della soluzione, refined static model, a partire dal consolidated collaboration diagram.

53 CONSOLIDATED COLLABORATION DIAGRAM Fusione ordinata dei collaboration diagram per ogni sottosistema in cui si omettono i numeri di sequenza dei messaggi: START: si sovrapprone il collaboration diagram del secondo use case a quello del primo ottenendo un consolidated diagram. NEXT: si sovrappone il collaboration diagram del terzo use case sul consolidated diagram dei primi due use case e così via.

54 CONSOLIDATED COLLABORATION DIAGRAM Oggetti e interazioni che compaiono in più di un collaboration diagram sono mostrati una sola volta. Mostra tutti i messaggi risultato dell’esecuzione, anche delle funzionalità “alternative”. Ad ogni passo si aggiungono oggetti e interazioni.

55 CONSOLIDATED COLLABORATION DIAGRAM Collaboration diagram for Validate PIN use case: Valid PIN (estratto) > :CardReader > :BankServer > :ATMControl I/O device interface>> :CardReader Interface > :ATMCard 1: Card Reader Input 1.2: Card Inserted 1.1: Card Input Data 2.5: Validate PIN (Customer Info) 2.6 [Valid]: Valid PIN 2.4: PIN Entered (Customer Info) note

56 CONSOLIDATED COLLABORATION DIAGRAM Collaboration diagram for Valid PIN Si considerano i messaggi generati dal normale comportamento del sistema in esecuzione (la card è valida e il PIN digitato è corretto). Tra :CardReaderInterface e :ATMControl si ha 1.2: Card Inserted. Tra :CustomerInterface e :ATMControl si hanno 2.4: PIN Entered (Customer Info) 1.3: Get PIN, 2.7: Display Menu

57 CONSOLIDATED COLLABORATION DIAGRAM Collaboration diagram for Validate PIN use case: stolen or expired card (estratto) > :CardReader > :BankServer > :ATMControl I/O device interface>> :CardReader Interface > :ATMCard 1: Card Reader Input 1.2: Card Inserted 1.1: Card Input Data 2.5: Validate PIN (Customer Info) 2.6c [Stolen OR Expired]: Card Stolen, Card Expired 2.6c.2: Confiscate Card 2.6c.1: Confiscate 2.4: PIN Entered (Customer Info) note 1.3: Get PIN 2.7: Display Menu

58 CONSOLIDATED COLLABORATION DIAGRAM Collaboration diagram for stolen or expired card Si considerano i messaggi generati dal sistema che segue un comportamento alternativo in esecuzione (La carta è rubata o scaduta). Tra :CardReaderInterface e :ATMControl si hanno 1.2: Card Inserted 2.6c.1: Confiscate Tra :CustomerInterface e :ATMControl si ha 2.4: PIN Entered (Customer Info) sequenze di messaggi relativi al Display.

59 CONSOLIDATED COLLABORATION DIAGRAM Consolidated Collaboration diagram for ATM Client subsystem (estratto) > :CardReader > :ATMControl I/O device interface>> :CardReader Interface > :ATMCard Card Reader Input Card Inserted, Card Edjected, Card Confiscated Card Input Data ATM Transaction Bank Reponses Card Reader Output Eject, Confiscate > :BankServer Customer Events note Display Prompts

60 CONSOLIDATED COLLABORATION DIAGRAM Consolidated Collaboration diagram for ATMClient Subsystem Tra :CardReaderInterface e :ATMControl si hanno Card Inserted (compare una sola volta), Card Edject, Card Confiscated Eject, Confiscate (dalla sequenza alternativa). Tra :CustomerInterface e :ATMControl si hanno Customer Events, Display Prompts.

61 CONSOLIDATED COLLABORATION DIAGRAM Cresce il volume delle informazioni nel diagramma. Riduzione del volume: messaggi aggregati collaboration diagram ad alto-livello

62 CONSOLIDATED COLLABORATION DIAGRAM messaggi aggregati Si etichettano le interconnessioni con messaggi aggregati. ESEMPIO: ATMClient Subsystem. Il messaggio aggregato Customer Events include i messaggi PIN Entered (collaboration diagram for Valide PIN) e With Drawal Selected (collaboration diagram for Withdraw: non lo vediamo). Si usano dizionari di messaggi per definire il contenuto di ogni messaggio aggregato.

63 CONSOLIDATED COLLABORATION DIAGRAM subsystem software architecture Si sviluppa un consolidated collaboration diagram per ogni sottosistema. I nterazioni dinamiche tra sottosistemi sono descritte su un subsystem collaboration diagram che è un consolidated collaboration diagram di alto livello.

64 CONSOLIDATED COLLABORATION DIAGRAM subsystem software architecture > :ATM Customer > :Operator > :ReceiptPrinter > :CashDispenser > :BankServer > :ATMClient > :BankingSystem Card Reader Input Card Reader Output Customer Input Display Information Operator Input Operator Information Printer Output Dispenser Output ATM Transaction Bank Transition > :CardReader

65 Consolidated collaboration diagram for ATMClient : Operator «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» : perator Interface Cash Added : ATM Customer Operator Input Operator Info Start Up, Closedown «entity» : ATM Transaction Transaction Details Update Transaction Status (Cash Details), Update PIN Status Customer Info 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 CONSOLIDATED COLLABORATION DIAGRAM subsystem software architecture

66 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request > :Transfer TransactionManager > :Card Account > :Debit Card > :Savings Account > :Transaction Log Credit, Debit, Read Log Account Data Validate Read Log Account Data Credit, Debit, Read Account Data Read Account Numbers Card Data Check, Update Daily Limit Reponse Credit, Debit, Read Account Data Credit, Debit, Read Account Data Read CONSOLIDATED COLLABORATION DIAGRAM subsystem software architecture Consolidated collaboration diagram for ATMClient

67 STATIC MODELING AT THE DESIGN LEVEL Realizzazione del refined static model Si parte dal conceptual static model E’ il class diagram dell’intero sistema. Non evidenzia la “distribuzione” delle classi tra i sottosistemi. Le classi del conceptual s.m. vengono “divise” tra i sottosistemi cui corrispondono i consolidated collaboration diagrams. Si ha un refined static model per ogni sottosistema.

68 Gli oggetti del consolidated collaboration diagram sono mappati nelle classi da cui sono istanziati. Per ogni collegamento tra oggetti esiste una relazione corrispondente. Alcune relazioni che appaiono nel class diagram non hanno corrispondenza nel collaboration diagram (dynamic model). Si considera la direzione di navigabilità delle associazioni, dalla classe user alla classe provider. STATIC MODELING AT THE DESIGN LEVEL Realizzazione del refined static model

69 Si ottiene è una sorta di “fusione” tra classi del conceptual static model complessivo classi le cui istanze generiche compaiono come ruoli nel consolidated collaboration diagram del sottosistema. STATIC MODELING AT THE DESIGN LEVEL Realizzazione del refined static model

70 STATIC MODELING AT THE DESIGN LEVEL Esempio Definizione di un refined static model attraverso l’esempio del BANKING SYSTEM. Il sistema è stato: decomposto in sottosistemi secondo lo stile client/server (Client/Server architectural style)Client/Server architectural style descritto mediante consolidated collaboration diagram per ogni sottosistema usando anche collaboration diagram ad alto livello (Subsystem software architecture ).Subsystem software architecture

71 STATIC MODELING AT THE DESIGN LEVEL Esempio Vediamo: Conceptual static model del Banking System Consolidated collaboration diagrams per Bank Server subsystem ATM Client subsystem Refinede static model per Bank Server subsystem Bank Server subsystem ATM Client subsystem

72 STATIC MODELING AT THE DESIGN LEVEL Conceptual static model for Banking System > ATMTransaction > CardAccount > Customer > DebitCard > Bank > ATMInfo > Account > Checking Account > Saving Account > Transfer Transaction > PINValidation Transaction Identifies Modifies Maintains Has Manages Owns Provides access to Owns 1 1 1 1 1 1,2 1..* 0..1 * * * > Query Transaction > Whitdrawal Transaction note Classi in BankServer Subsystem Classi in ATMClient Subsystem

73 STATIC MODELING AT THE DESIGN LEVEL Il conceptual static model non evidenzia la “distribuzione” delle classi tra i sottosistemi. Non c’è distinzione tra classi associate al client subsystem e classi associate al server subsystem.

74 > :ATMClient > :BankTransactionServer ATM Transaction bankResponse > :BankServer > :Checking Account > :Query TransactionManager > :PINValidation TransactionManager > :Withdrawal TransactionManager Transfer Response Query Transaction Query Response Transfer Transaction Withdraw Response Withdraw, Confirm, Abort PINValidation Response PINValidation Request > :Transfer TransactionManager > :Card Account > :Debit Card > :Savings Account > :Transaction Log Credit, Debit, Read Log Account Data Validate Read Log Account Data Credit, Debit, Read Account Data Read Account Numbers Card Data Check, Update Daily Limit Reponse Credit, Debit, Read Account Data Credit, Debit, Read Account Data Read Consolidated collaboration diagram for ATMClient STATIC MODELIN AT THE DESIGN LEVEL note

75 STATIC MODELING AT THE DESIGN LEVEL BankServer Subsystem Nel c.c.d., oltre agli oggetti entity per le classi del conceptual static model, compaiono nuovi oggetti di tipo business logic :TransferTransactionManager, :QueryTransactionManager, :WhidrawalTransactionManager e :PINValidationTransactionManager per gestire l’applicazione coordinator :BankTransactionServer che coordina gli oggetti business logic.

76 Consolidated collaboration diagram for ATMClient : Operator «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» : perator Interface Cash Added : ATM Customer Operator Input Operator Info Start Up, Closedown «entity» : ATM Transaction Transaction Details Update Transaction Status (Cash Details), Update PIN Status Customer Info 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 STATIC MODELIN AT THE DESIGN LEVEL note

77 STATIC MODELING AT THE DESIGN LEVEL ATMClient Subsystem Nel c.c.d., oltre alle entity :ATMTransaction, del conceptual static model, e :ATMCard e :ATMCash compaiono oggetti di tipo: state dependent control :ATMControl riceve richieste di transazioni dall’esterno e le redirige al sottosistema BankServer. I/O device interface :CardReaderInterface, :CustomerInterface, ReceiptPrinterInterface, :OperatorInterface, :CashDispenserInterface.

78 > 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 Has Owns Credits, Debits, Reads Logs Reads Checks, Updates Validates Queries Delegates to note STATIC MODELING AT THE DESIGN LEVEL Refinede static model for BankServer subsystem

79 STATIC MODELING AT THE DESIGN LEVEL Sono “fuse” parti del conceptual static model con parti del consolidated collaboration diagram. La classe per ATMTransaction che compariva nel conceptual static model non è nel refined static mode. (Compare nella parte client). Compaiono le classi relative agli oggetti business logic: che aggiornano gli oggetti entity coordinatore: delega loro le richieste. Entity: TransactionLog consente di rendere persistenti le modifiche agli Account dovute al “lavoro” dell’applicazione.

80 > Customer Interface > ATMCard > 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 > CardReader Interface > CashDispenser Interface > ReceiptPrinter Interface note STATIC MODELING AT THE DESIGN LEVEL Refinede static model for ATMClient subsystem

81 STATIC MODELING AT THE DESIGN LEVEL Le classi per ATMTransaction e sua generalizzazione sono le uniche che compaiono sia nel conceptual s. m. sia nel refined s. m. Dal consolidated collaboration diagram di hanno classi user interface: consentono di ricevere input dall’esterno device interface: consentono di mandare output all’esterno. entity ATMCard e ATMCash. Memorizzano dati indispensabili per il funzionamento del sistema. ATMControl riceve richieste per BankServer da user e device interface object risposte da BankServer per user e device interface object.