software architectural design nel metodo comet corso di ingegneria del software 2 anno accademico...
Post on 03-May-2015
219 Views
Preview:
TRANSCRIPT
SOFTWARE ARCHITECTURAL DESIGN
NEL METODO COMET
Corso di Ingegneria del Software 2Anno Accademico 2000 - 2001
Demergasso Daniela
SOFTWARE ARCHITECTURAL DESIGNDesign 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 levelConsolidated collaboration diagramsRefined static model (Esempio: Banking System)
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<<system>>
Banking System
<<subsystem>>
ATMClientSubsystem
<<subsystem>>
BankServerSubsystem
1..*
1
<<external output device>>
Receipt Printer
<<external output device>>
Cash Dispenser
<<external input/output device>>
Card Reader
<<external user>>
Operator
<<external user>>
ATMCustomer
1
1 1
11
1
1
11
ESEMPIO: Banking System
1
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/multi-server).
CLIENT/SERVER ARCHITECTURAL STYLE
Alcuni sistemi usano:BROKERI client richiedono servizi ai broker che ne
favoriscono la localizzazione.COMMUNICATING SOFTWARE AGENTSSono intermediari tra client e server.
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<<subsystem
>>AutoControl Subsystem
<<subsystem>>
Distance&Speed Subsystem
<<subsystem>>
Calibration Subsystem <<subsystem
>>Shaft Subsystem
<<subsystem>>
TripAverages Subsystem
<<subsystem>>
Maintenance 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: 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
COMMUNICATING TASK ARCHITECTURAL STYLE
ESEMPIO: distribuited software architecture: Elevator Control System.
<<external output
device>> :ElevatorLamp
<<external output
device>> :Motor
<<external input device>> :Arrival
Sensor
<<external input device>> :Elevato
rButton
<<coordinator subsystem>> :Sc
heduler
<<external input device>> :FloorBu
tton
<<external output
device>> :DirectionLamp
<<control subsystem>> :ElevatorSubsystem
<<external output device>>
:FloorLamp
<<data collection subsystem>> :Flo
orSubsystem
<<external output
device>> :DoorArrival Sensor Input Door Command Door ReponseElevator Lamp Output
Elevator Button Request
Motor Comman
dMotor
Reponse
Floor Lamp Command
Direction Lamp
Command
Service Request
Scheduler
Request
Arrival(Floor#)
Departed(Floor#)
Elevator Commitment
Direction Lamp OutputFloor Lamp
Output
Floor Button
Request
<<system>> :ElevatorContro
l System
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 ISSUESUn 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
<<system>> Banking
System
<<subsystem>>
ATMClientSubsystem
<<subsystem>>
BankServerSubsystem
1..*
1
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
La relazione tra oggetti composti e loro costituenti è descritta mediante class diagram che consente di indicare la molteplicità delle associazioni.
1..*1..* 11
Elevator
ElevatorButton
ElevatorLamp
Motor DoordestinationFloor#: Integer
destinationFloor#: Integer
elevator#: IntegercurrentFloor#:
Integerdirection: DirectionType
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 SUBSYSTEMSEsistono 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 SUBSYSTEMSDATA 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 SUBSYSTEMSData Collection and Data Analysis Subsystems
<<data collection subsystem>> :Senso
rDataCollection
<<data analysis subsystem>> :Senso
rDataAnalysis
<<user interface subsystem>> :Oper
atorInterface
<<server subsystem>> :Sens
orDataServer
Raw Sensor Data
Process Sensor Data
Sensor Reports Sensor
Display Data
Operator Request
Displayed Informatio
n
Processed Sensor Data
Sensor Data
Request
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 SUBSYSTEMSServer Subsystem
<<data collection subsystem>> :Senso
rDataCollection
<<data analysis subsystem>> :Senso
rDataAnalysis
<<user interface subsystem>> :Oper
atorInterface
<<server subsystem>> :Senso
rDataServer
Raw Sensor Data
Process Sensor Data
Sensor Reports Sensor
Display Data
Operator Request
Displayed Informatio
n
Processed Sensor Data
Sensor Data
Request
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 SUBSYSTEMSUser Interface Subsystem
<<data collection subsystem>> :Senso
rDataCollection
<<data analysis subsystem>> :Senso
rDataAnalysis
<<user interface subsystem>> :Opera
torInterface
<<server subsystem>> :Sens
orDataServer
Raw Sensor Data
Process Sensor Data
Sensor Reports Sensor
Display Data
Operator Request
Displayed Informatio
n
Processed Sensor Data
Sensor Data
Request
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
Collaboration diagram for Validate PIN use case: Valid PIN (estratto)
<<external I/O device>> :CardReader
<<subsystem>> :BankServ
er
<<state dependent control>> :ATMCon
trol
I/O device interface>> :CardReader
Interface
<<entity>> :ATM
Card
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
CONSOLIDATED COLLABORATION DIAGRAM
Collaboration diagram for Validate PIN use case: stolen or expired card (estratto)
<<external I/O device>> :CardReader
<<subsystem>> :BankServ
er
<<state dependent control>> :ATMCon
trol
I/O device interface>> :CardReader
Interface
<<entity>> :ATM
Card
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
CONSOLIDATED COLLABORATION DIAGRAM
Consolidated Collaboration diagram for ATM Client subsystem (estratto)
<<external I/O device>> :CardReader
<<state dependent control>> :ATMCon
trol
I/O device interface>> :CardReader
Interface
<<entity>> :ATM
Card
Card Reader Input
Card Inserted, Card Edjected,
Card Confiscated
Card Input Data
ATM Transaction
Bank Repons
es
Card Reader Output Eject,
Confiscate
<<subsystem>> :BankServ
er
Customer
Events
note
Display Prompt
s
CONSOLIDATED COLLABORATION DIAGRAM
Cresce il volume delle informazioni nel diagramma.
Riduzione del volume:messaggi aggregaticollaboration diagram ad alto-livello
CONSOLIDATED COLLABORATION DIAGRAMmessaggi 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 DIAGRAMsubsystem 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 DIAGRAMsubsystem software architecture
<<actor>>
:ATM Custome
r
<<actor>>
:Operator
<<external output device>> :ReceiptPrinte
r
<<external output device>> :CashDispense
r
<<server subsystem>> :
BankServer
<<client subsystem>> :ATMClien
t
<<system>> :BankingSystem
Card Reader Input
Card Reader Output
Customer Input
Display Information
Operator
Input
Operator Informati
onPrinter Output
Dispenser Output
ATM Transactio
n
Bank Transition
<<external I/O device>> :CardReade
r
STATIC MODELING AT THE DESIGN LEVELRealizzazione del refined static model
Si parte dal conceptual static modelE’ 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 .
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 LEVELRealizzazione del refined static model
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 LEVELRealizzazione del refined static model
STATIC MODELING AT THE DESIGN LEVELEsempio
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)
descritto mediante consolidated collaboration diagram per ogni sottosistema usando anche collaboration diagram ad alto livello (Subsystem software architecture).
STATIC MODELING AT THE DESIGN LEVELEsempio
Vediamo:
Conceptual static model del Banking System
Consolidated collaboration diagrams per Bank Server subsystem ATM Client subsystem
Refinede static model per Bank Server subsystem ATM Client subsystem
STATIC MODELING AT THE DESIGN LEVEL
Conceptual static model for Banking System
<<entity>> ATMTransacti
on
<<entity>> CardAccoun
t
<<entity>> Customer
<<entity>> DebitCard
<<entity>> Bank
<<entity>> ATMInfo
<<entity>> Account
<<entity>> Checking Account
<<entity>> Saving
Account
<<entity>> Transfer
Transaction
<<entity>> PINValidati
on Transaction
Identifies
Modifies
Maintains
Has
Manages
Owns
Provides access to
Owns 1
1
11
1
1,2
1..*
1..*
1..*
1..*
1..*
0..1
*
*
*
<<entity>> Query
Transaction
<<entity>> Whitdrawal Transaction
note
Classi in BankServer Subsystem
Classi in ATMClient Subsystem
<<subsistem>> :ATMClient
<<coordinator>> :BankTransactionServer
ATM Transaction
bankResponse
<<server subsystem>> :BankSer
ver
<<entity>> :Checking Account
<<business logic>> :Query
TransactionManager
<<business logic>> :PINValidation TransactionManager
<<business logic>> :Withdrawal TransactionManager
Transfer Response
Query Transaction Query
ResponseTransfer Transaction
Withdraw Response
Withdraw, Confirm,
AbortPINValidation
Response
PINValidation Request
<<business logic>> :Transfer
TransactionManager
<<entity>> :Card Account
<<entity>> :Debit Card
<< entity >> :Savings
Account
<< entity >> :Transaction
Log
Credit, Debit, Read
Log
Account Data Validate
Read
LogLogAccount
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 Account
Data
Read
Consolidated collaboration diagram for ATMClient
STATIC MODELIN AT THE DESIGN LEVEL
note
Consolidated collaboration diagram for ATMClient
: Operator
«subsystem»: BankServer
«asynchronousI/O device»
: CardReader
CardReaderOutput
«I/O deviceinterface»
: CardReaderInterface
«client subsystem»:ATMClient
«entity»: ATMCard
CardInputData
«user interface»: CustomerInterface
CardData Card
Request
CustomerInput
DisplayInformation
ATM Transaction Bank Responses
«state dependentcontrol»
: ATMControl
Card Inserted,Card Ejected,
CardConfiscated
Eject,Confiscate
«entity»: ATMCash
«externaloutputdevice»: Cash
Dispenser
Dispenser Output
Cash Withdrawal
AmountCashResponse
«userinterface»: perator Interface
CashAdded
: ATMCustomer
OperatorInput
Operator Info
Start Up,Closedown
«entity»: ATM
TransactionTransaction Details
Update Transaction
Status (Cash Details), Update PIN Status
Customer Info
Display Prompts
Customer Events
(Transaction Details)
<<output device interface>> :CashDipenser Intreface
Cash Dispensed
Dispense Cash (Cash Details)
<<output device interface>> :Rec
eiptPrinter Interface
<<external output
device>> :Receipt Printer
Card Reader input
Printer Output
Transaction Request
Transaction Data
Print Receipt
Receipt Printed
STATIC MODELIN AT THE DESIGN LEVEL
note
<<coordinator>> BankTransaction
Server
<<business logic>> Query
TransactionManager
<<business logic>> PINValidation
TransactionManager
<<business logic>> Withdrawal
TransactionManager
<<business logic>> Transfer
TransactionManager
<<entity>> Checking Account
<< entity >> Transaction Log
<< entity >> Savings Account
<<entity>> Debit Card
<<entity>> Card Account
<<entity>> Account <<entity>>
Customer
<<entity>> Bank
<<entity>> ATMInfo
Provides Access to
Manages
HasOwns
Owns
Credits, Debits, Reads
Credits, Debits, Reads
Credits, Debits, Reads
Credits, Debits, Reads
LogsLogs
Logs
ReadsReads Checks,
Updates
Validates
Queries
Delegates to
Delegates to
Delegates to
Delegates to
note
STATIC MODELING AT THE DESIGN LEVEL
Refinede static model for BankServer subsystem
<<user interface>> Customer Interface
<<entity>> ATMCard
<<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
<<device interface>> CardReader Interface
<<device interface>> CashDispenser Interface
<<device interface>> ReceiptPrinter Interface
note
STATIC MODELING AT THE DESIGN LEVEL
Refinede static model for ATMClient subsystem
top related