SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico...

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


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


: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


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.


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


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.


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.


USER INTERFACE

Per ogni interfaccia utente individuata si ha un sottosistema (maggior flessibilità).

Gli oggetti interfaccia sono spesso client.

Sono spesso oggetti aggregati.


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


rDataCollection


rDataAnalysis

<<user interface subsystem>> :Oper

atorInterface

<<server subsystem>> :Senso

rDataServer

Raw Sensor Data

Process Sensor Data


Display Data

Operator Request


n


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


rDataCollection


rDataAnalysis

<<user interface subsystem>> :Opera

torInterface

<<server subsystem>> :Sens

orDataServer

Raw Sensor Data

Process Sensor Data


Display Data

Operator Request


n


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.


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.


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


Collaboration diagram for Validate PIN use case: stolen or expired card (estratto)



er


trol


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 for ATM Client subsystem (estratto)



trol


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


er

Customer

Events

note

Display Prompt

s


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.


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


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




LogsLogs

Logs

ReadsReads Checks,

Updates

Validates

Queries

Delegates to

Delegates to

Delegates to

Delegates to

note


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


Refinede static model for ATMClient subsystem

SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico...

Documents

Transcript of SOFTWARE ARCHITECTURAL DESIGN NEL METODO COMET Corso di Ingegneria del Software 2 Anno Accademico...