COMET
Detailed Software Design
Detailed Software Design
1) Progettazione di Task compositi
1.1) Task e Classi: mutue relazioni e singole
responsabilità
1.2) Criteri di progettazione per Task e Oggetti
2) Accesso alle classi
2.1) Tecniche di sincronizzazione
Detailed Software Design
3) Comunicazioni Inter-Task
3.1) Connettori per la comunicazione
3.2) Task cooperanti con connettori
4) Sequenzialità logica degli eventi
4.1) Esempio
Detailed Software Design
Dove si colloca in COMET ?
 Nella fase di Design Modeling
Quali sono gli obiettivi ?
 Definire le componenti interne dei Task
 Definire il comportamento dei Task
 Come comunicano
 Come si comportano rispetto agli eventi
1) Progettazione di Task
compositi
Definizione:
Un Task Composito è un Task che
incapsula gli oggetti annidati che contiene
Tutte le funzionalità del Task sono fornite
dagli oggetti che contiene
Ogni Task composito ha un
oggetto coordinatore
1.1) Relazioni e Responsabiltà
RELAZIONI
L’Oggetto Attivo (Task) è attivato da un evento;
poi invoca un’operazione fornita da un Oggetto
Passivo
 Classi annidate
 Classi esterne
 Modularità e Riuso separando i concetti
di COME e QUANDO
1.1) Relazioni e Responsabiltà
RESPONSABILITÀ
Task: Controllo, sequenzialità e comunicazione
Classi: Dettagli strutturali
La divisione delle responsabilità è un esempio di
separazione dei compiti (concerns)
1.1) Relazioni e Responsabiltà
Esempio
Un Task di interfaccia di dispositivo di I/O
contiene un oggetto interfaccia di dispositivo
L’oggetto incoropora i dettagli di come leggere
o scrivere sul dipositivo (reale)
Il Task affronta il problema di quando e come
il dispositivo è attivato e gestisce le
comunicazioni con gli altri oggetti (attivi o
passivi)
1.2) Criteri di progettazione
 Temporal clustering
 Task attivati nello stesso momento
evento temporale)
(stesso
 Control clustering
 Task attivati dallo stesso evento (asincrono)
1.2) Criteri di progettazione
Esempio di Temporal Clustering
«external input
device» : Engine
«external input
device» : Brake
Engine
Input
Brake
Input
«Input device
Interface» :
EngineInterface
Engine On,
Engine Off
Brake Pressed,
Brake Released
«Input device
Interface» :
BrakeInterface
1.2) Criteri di progettazione
Esempio di Temporal Clustering (continua)
«external timer»
: DigitalClock
timer
Event
«passive input
device» : Engine
read (out
engineInput)
«Input device Interface»
: AutoSensors
«passive input
device» : Brake
read (out
brakeInput)
engineOn,
engineOff,
Brake Pressed,
Brake Released
1.2) Criteri di progettazione
Esempio di Control Clustering
«output device
interface»
:Receipt
PrinterInterface
5: Print
Receipt
6: Printer
Output
1: Withdrawal OK
7: Receipt Printed
«state dependent control»
:ATMControl
8: Eject
2: Dispense Cash
4: Cash
Dispensed
«output device
interface»
:Cash
DispenserInterface
3: Dispenser
Output
1.2) Criteri di progettazione
Esempio di Control Clustering (continua)
1: ATMControl
Request
8: Eject
6: printedOutput
«control clustering»
:ATM Controller
3: DispenserOutput
2) Accesso alle Classi
 Quanti Task accedono ad una classe ?
 Quali sono le strutture dati accedute ?
 Quali operazioni utilizza un Task ?
Nel caso di più Task si deve:
 Sincronizzare l’accesso ai dati
 Stabilire il tipo di sincronizzazione
 Adottare un algoritmo di sincronizzazione
2.1) Tecniche di Sincronizzazione
Scelte Possibili
 Mutua Esclusione
 Lettori e Scrittori Multipli
 Con Monitor
 Senza “Writer Starvation”
Esempi
3) Comunicazioni
Inter-Task
Si possono avere
 Servizi forniti dal Kernel sottostante
 Meccanismi offerti dal Linguaggio di
programmazione utilizzato
Tipi di comunicazione
 Messaggi accoppiati debolmente
 Messaggi accoppiati fortemente
 Con risposta
 Senza risposta
3.1) Connettori
 Le classi connettori incapsulano i dettagli
della comunicazione inter-Task
 Ogni connettore è progettato come monitor
 Utilizzo di Condizioni di Sincronizzazione
3.2) Task cooperanti
Esempio 1
Coda di messaggi per messaggi accoppiati
debolmente
aProducerTask
aConsumerTask
Send
(in message)
Receive
(out message)
«connector»
aMessageQueue
Vedi
Pseudocodice
3.2) Task cooperanti
Esempio 2
Buffer di messaggi per messaggi accoppiati
fortemente senza risposta
aProducerTask
aConsumerTask
Send
(in message)
Receive
(out message)
«connector»
aTightlyCoupled
MessageBuffer
Vedi
Pseudocodice
3.2) Task cooperanti
Esempio 3
Buffer di messaggi per messaggi accoppiati
fortemente con risposta
aProducerTask
aConsumerTask
Send
(in message)
Receive
(out message)
«connector»
aMessage
Buffer&Response
Vedi
Pseudocodice
3.2) Task cooperanti
Esempio 4
Gruppi di Task cooperanti comunicanti attraverso
oggetti connettori
Gli oggetti connettori incapsulano i meccanismi
per una comunicazione sincrona
3.2) Task cooperanti
Esempio 4 (continua)
«asynchronous I/O
device interface»
:CardReader
Interface
«user interface»
:Operator
Interface
receive (out
cardreaderMsg)
send (in
ATMControl
Request)
send (in
ATMControlRequest)
«connector»
CardReader
MessageBuffer
Send (in
ATMTransaction, out
bankResponse)
«connector»
ATMControl
MessageQ
send (in
ATMControl
Request)
«user interface»
:Customer
Interface
receive (out
displayPrompt)
send (in
cardreader Msg)
«connector»
:bankServer Proxy
«connector»
promptMessage
Queue
receive (out
ATMControl
Request)
«control clustering»
:ATMController
send (in
displayPrompt)
4) Sequenzialità logica
degli eventi
Si descrivono
 Le risposte di un Task a messaggi o eventi
 L’output per ogni input
Nei Task compositi l’oggetto coordinatore riceve
i messaggi in input e invoca le operazioni degli altri
oggetti annidati
4) Sequenzialità logica
degli eventi
4.1) Esempio
Descrizione dell’operazione send
loop
Prepare message containing message name (type) and
optional message parameters;
send(message) to receiver;
endloop;