Corso di Ingegneria del Software 2 Anno Accademico

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

SOFTWARE ARCHITECTURAL DESIGN Design modeling phase and software architectural design l Software architectural styles l System decomposition l l l 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 l Refined static model (Esempio: Banking System) l

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.

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.

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

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.

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

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/multiserver).

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

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.

LAYERS OF ABSTRACTION ARCHITECTURAL STYLE <> Auto. Control Subsystem <> Trip. Averages Subsystem Maintenance Subsystem <> Distance&Speed Subsystem <> Calibration Subsystem <> Shaft Subsystem ESEMPIO: Cruise Control and Monitoring System note

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: l task comunicanti mediante memoria condivisa: i task concorrenti risiedono sullo stesso nodo e devono essere sincronizzati l task comunicanti senza memoria condivisa: i task possono essere allocati su nodi differenti in ambiente distribuito

COMMUNICATING TASK ARCHITECTURAL STYLE <> : Arrival. Sensor <> : Elevator. Lamp Elevator Lamp Output Arrival Sensor Input Elevator Button Request <> : Elevator. Button <> : Floor. Button Floor Lamp Command Motor Reponse Direction Lamp Command <> : Floor. Subsystem Floor Button Request Door Command Service Request Floor Lamp Output <> : Floor. Lamp ESEMPIO: distribuited software architecture: Elevator Control System. Door Reponse <> : Elevator. Control System <> : Elevator. Subsystem Motor Command <> : Motor <> : Door Elevator Commitment Departed(Floor#) Scheduler Request Arrival(Floor#) <> : Scheduler Direction Lamp Output <> : Direction. Lamp note

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)

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.

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.

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.

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

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

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.

SEPARATION OF CONCERNS IN SUBSYSTEM DESIGN Elevator elevator#: Integer current. Floor#: Integer direction: Direction. Type 1. . * Elevator. Button destination. Floor#: Integer 1 Elevator. Lamp destination. Floor#: Integer 1 Motor Door La relazione tra oggetti composti e loro costituenti è descritta mediante class diagram che consente di indicare la molteplicità delle associazioni.

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 System Ogni istanza del sottosistema elevator potrebbe risiedere su un microprocessore posto sull’ascensore reale.

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

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.

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. 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.

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. Riceve input dall’ambiente esterno o da altri sottosistemi. Genera output verso l’ambiente esterno o verso altri sottosistemi. ESEMPIO: Elevator Control Subsystem

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

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.

KINDS OF SUBSYSTEMS Data Collection and Data Analysis Subsystems Raw Sensor Data <> : Sensor. Data. Collection Process Sensor Data Sensor Reports <> : Sensor. Data. Analysis Processed Sensor Data Operator Request Sensor Data Request <> : Sensor. Data. Server Sensor Display Data <> : Operator. Interface Displayed Information Sensor Data note

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

KINDS OF SUBSYSTEMS Server Subsystem Raw Sensor Data <> : Sensor. Data. Collection Process Sensor Data Sensor Reports <> : Sensor. Data. Analysis Processed Sensor Data Operator Request Sensor Data Request <> : Sensor. Data. Server Sensor Display Data <> : Operator. Interface Displayed Information Sensor Data note

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

KINDS OF SUBSYSTEMS User Interface Subsystem Raw Sensor Data <> : Sensor. Data. Collection Process Sensor Data Sensor Reports <> : Sensor. Data. Analysis Processed Sensor Data Request <> : Sensor. Data. Server <> : Operator. Interface Sensor Display Data Operator Request Displayed Information Sensor Data note

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.

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.

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.

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.

CONSOLIDATED COLLABORATION DIAGRAM <> : Card. Reader 1: Card Reader Input <> : Bank. Server I/O device interface>> : Card. Reader Interface 1. 1: Card Input Data 2. 5: Validate PIN (Customer Info) 2. 6 [Valid]: Valid PIN 1. 2: Card Inserted <> : ATMControl <> : ATMCard 2. 4: PIN Entered (Customer Info) Collaboration diagram for Validate PIN use case: Valid PIN (estratto) note

CONSOLIDATED COLLABORATION DIAGRAM <> : Card. Reader 1: Card Reader Input 2. 6 c. 2: Confiscate Card <> : Bank. Server I/O device interface>> : Card. Reader Interface 2. 5: Validate PIN (Customer Info) 2. 6 c. 1: Confiscate <> : ATMControl 1. 1: Card Input Data <> : ATMCard 1. 2: Card Inserted 2. 6 c [Stolen OR Expired]: Card Stolen, Card Expired 2. 4: PIN Entered (Customer Info) 1. 3: Get PIN 2. 7: Display Menu Collaboration diagram for Validate PIN use case: stolen or expired card (estratto) note

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

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

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.

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

CONSOLIDATED COLLABORATION DIAGRAM subsystem software architecture <> : Card. Reader <> : ATM Customer Operator Input Card Reader Output Card Reader Input Customer Input Display Information Operator Information <> : Banking. System <> : ATMClient ATM Transaction Bank Transition Printer Output <> : Bank. Server Dispenser Output <> <> : Receipt. Printer : Operator <> : Cash. Dispenser

STATIC MODELING AT THE DESIGN LEVEL Realizzazione del refined static model Si parte dal conceptual static model l E’ il class diagram dell’intero sistema. l 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.

STATIC MODELING AT THE DESIGN LEVEL Realizzazione del refined static model 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 Si ottiene è una sorta di “fusione” tra l classi del conceptual static model complessivo l classi le cui istanze generiche compaiono come ruoli nel consolidated collaboration diagram del sottosistema.

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

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

STATIC MODELING AT THE DESIGN LEVEL Manages 1. . * <> Debit. Card Owns 0. . 1 Has <> Bank 1 1. . * * 1. . * <> Card. Account 1. . * 1 Classi in Bank. Serv er Subsyste C mlassi in ATMClien t Subsyste m Identifies * 1. . * <> Saving Account Maintains <> ATMInfo Owns <> Account 1 1 <> Customer Provides access to <> Checking Account 1 Modifies 1, 2 <> Whitdrawal Transaction Conceptual static model for Banking System <> * ATMTransaction <> Query Transaction <> Transfer Transaction <> PINValidation Transaction note

<> : ATMClient ATM Transaction STATIC MODELIN AT THE DESIGN LEVEL bank. Response <> : Bank. Server Transfer Response <> : Bank. Transaction. Serve r PINValidatio Withdra Query n Request w, Query Transacti Confirm, Withdraw Respon Abort PINValidati on Transfer Response se on Transacti Response on <> : Transfer : Query : Withdrawal : PINValidation Transaction. Manager Account Credit, Card Data Account Data Credit, Debit, Read Account Check, Data Debit, Validate Read Credit, Data. Credit, Account Daily Update Read Debit, Limit Data Account Log Read Log Repons Data Numbers e <> << entity >> : Transaction : Debit Card : Savings : Checking Log Account Consolidated collaboration diagram for ATMClient note

STATIC MODELIN AT THE DESIGN LEVEL «subsystem» : Bank. Server ATM Transaction «asynchronous «client subsystem» : ATMClient I/O device» : Card. Reader Card Reader input Card Reader Output «I/O device interface» : Card. Reader Interface Card Inserted, Card Ejected, Card Confiscated Bank Responses «external output device» : Cash Dispenser <

> Dispense : Cash. Dipenser Cash (Cash Intreface Details) Dispenser Cash Withdrawal Output Response Amount Cash «entity» Dispense : ATMCash d : Operator «state dependent Start Up, Cash Customer Closedown control» Added Operator «entity» Events Input : ATMControl : ATMCard «user Print (Transactio Receip interface» n Details) Card Update Operator Info t Transaction Card : perator Data Status (Cash Details), : ATM Request Printe Interface Displa Recei r Update PIN Status pt Customer Outpu y t Printe <

> output Transaction Display device> Transaction : Receipt. Print Transaction Details Information Request > er Interface : Receipt Consolidated collaboration diagram for ATMClient Printer note Card Input Data Eject, Confiscate

Delegat es to <> Bank. Transaction Server Delegat es to STATIC MODELING AT THE DESIGN LEVEL Delegat es to <> Withdrawal PINValidation Transaction. Manager Checks, Reads Credits, Reads Update Queries Credits, Debits, s Debits, Credits, Reads Validates Reads Debits, Logs Credits, Reads <> Logs < Debits, << entity >> Debit Card << entity >> Reads Savings > Account Transaction Checking Log Account Manages Owns <> Transfer Transaction. Manager <> Query Transaction. Manager <> Account Refinede static model for Bank. Server subsystem Owns Provides Access to <> Customer Has <> Bank <> ATMInfo note

STATIC MODELING AT THE DESIGN LEVEL <> Customer Interface Update Read s <> Card. Reader Interface Notifie s <> ATMCard Notifie s Create s <> Withdrawal Transaction <> Cash. Dispenser Controls Interface Startup, Close <> ATMControl Updates Dispense s Replenish es < < ATM interface>> Cash Operator Interface Controls <> ATM Transaction <> Query Transaction Refinede static model for ATMClient subsystem <> Receipt. Printer Interface Reads <> Transfer Transaction <> PINValidation Transaction note