Task Structuring [2a parte]
Maurizio Mazza
Corso di Ingegneria del Software II
Sommario
 I/O task structuring criteria
 Internal task structuring criteria
 Task priority criteria
 Task clustering criteria
 Temporal clustering
 Sequential clustering
 Control clustering
 Mutually exclusive clustering
Sommario
 Design Restructuring
 Sviluppo dell’architettura dei task
 Sincronizzazione e comunicazione tra task
 Task Behavior Specification (TBS)
Introduzione
 Task Structuring: strutturazione di un
(sotto)sistema in task concorrenti.
 Creazione di una task architecture


Determinazione dei task concorrenti
Definizione delle interfacce di comunicazione
Introduzione
2 Fasi:
 Criteri di I/O structuring, internal task
structuring e task priority (gia visti…)

Il risultato è un mapping uno a uno da oggetti
dell’analysis modeling a task concorrenti.
 Criteri di task clustering e task inversion

Usati per ridurre il numero di task fisici del sistema.
Task Clustering Criteria:
Control Clustering
 Un control object viene mappato in un task
separato (control task).
 In certi casi un control task può essere
combinato con altri oggetti.

Azioni avviate dal control object a causa di una
transizione di stato che iniziano e completano
l’esecuzione durante la transizione.
Task Clustering Criteria:
Control Clustering - Esempio
5: Print
Receipt
1: Withdrawal OK
«state dependent
control»
: ATMControl
«input device
interface»
: Receipit
PrintInterface
6:Printer
Output
7: Receipt Printed
8: Eject
4: Cash
Dispensed
2: Dispense Cash
«input device
interface»
: CashDispenser
Interface
Collaboration diagram iniziale (analysis model)
3: Dispenser
Output
Task Clustering Criteria:
Control Clustering - Esempio
7: Receipt Printed /
8: Eject
Ejecting
Printing
4: Cash Dispensed /
5: Print Receipt
Processing
Withdrawal
Dispensing
1: Withdrawal OK /
2: Dispense Cash
Satechart associato all’oggetto state-dependent ATM Control
Task Clustering Criteria:
Control Clustering - Esempio
1: ATMControl
Request
6: printerOutput
«control
clustering»
: ATM
Controller
3: dispenserOutput
8: eject
Collaboration diagram finale (design model): i tre oggetti precedenti
sono stati raggruppati in un unico task con stereotopo «control clustering»
Task Clustering Criteria:
Mutually Exclusive Clustering
 Si usa se esiste un gruppo di task in cui, per i
constraint imposti dall’applicazione, uno
solo di loro è in esecuzione in ogni momento.

Questi task possono essere raggruppati dentro ad
un unico task.
Enable Increase Speed
Disable Increase Speed
«state dependent
contol»
: CruiseControl
Enable Resume Cruising
Disable Resume Cruising
Enable Maintain Speed
Disable Maintain Speed
«algorithm»
: Acceleration
«algorithm»
: Cruiser
Read
Throttle
Value
Desired
Speed
value
Throttle Value
«output device
interface»
: ThrottleInterface
Current
Speed
Value
Read
Reached
Cruising
Current Speed Value
«algorithm»
: Resumption
Desired
Speed
value
Read
«entity»
: DesiredSpeed
Throttle Value
Read
«entity»
: CurrentSpeed
Current Speed value
«control»
: CruiseControl
cruiseControl
Command
reached
Cruising
«mutually exclusive
clustering»
: SpeedAdjustment
throttle
Value
«periodic output
device interface»
: ThrottleInterface
select()
clear()
«entity»
: DesiredSpeed
read(out
currentSpeed
Value)
read(out
currentSpeed
Value)
«entity»
: CurrentSpeed
Collaboration diagram finale (design model): i tre oggetti precedenti con
con stereotopo «algorithm» sono stati rggruppati in un unico task.
Design Restructuring
Scopo: ridurre in modo sistematico il numero
di task che costituiscono un sistema.
 Utilizzo dei criteri di task inversion per
raggruppare insieme diversi task e diminuire
l’overhead dovuto alla comunicazione.



Multiple instance task inversion
Sequential task inversion
Temporal task inversion
Design Restructuring:
Multiple Instance Task Inversion
 Sostituzione di tutti i task dello stesso tipo
con un solo task che svolge lo stesso servizio.

Caso tipico: sistema con tante istanze di control
object dello stesso tipo.
Design Restructuring:
Multiple Instance Task Inversion
«multiple instance
inversion»
: Elevator
Controller
«control»
: Elevator
Control
«entity»
: Elevator
StateInformation
Invece di avere tante istanze di oggetti attivi (come a sinistra) si tiene un
unico oggetto attivo a cui si associano tante istanze di oggetti passivi per
mantenere le informazioni relative allo stato (figura a destra)
Design Restructuring:
Sequential Task Inversion
 Si usa quando vi è una comunicazione tightly
coupled (sincrona) tra due o più task.


Il task che genera il messaggio (produttore)
viene combinato in un unico task con il
destinatario (consumatore).
Invece di mandare un messaggio, il produttore
chiama un’operazione fornita dal consumatore.
cruiseControl
Request
«control»
: CruiseControl
cruiseControl
Command
reached
Cruising
select()
clear()
«mutually exclusive
clustering»
: SpeedAdjustment
throttle
Value
«periodic output
device interface»
: ThrottleInterface
throttlePosition
«external output
device»
: Thtottle
read(out
currentSpeed
Value)
«entity»
: DesiredSpeed
read(out
currentSpeed
Value)
«entity»
: CurrentSpeed
Design Restructuring:
Sequential Task Inversion
cruiseControl
Request
«sequential inversion»
: InvertedCruise
Control
throttlePosition
«external output
device»
: Thtottle
read(out
currentSpeed
Value)
«entity»
: CurrentSpeed
Collaboration diagram ristrutturato: i tre oggetti precedenti sono
stati raggruppati in un unico task con stereotopo «sequential inversion»
Design Restructuring:
Temporal Task Inversion
 Con questa tecnica, due o più periodic task
(periodic internal, periodic I/O, temporally
clustered) vengono combinati in un solo task.

Il task globale ha una procedura di schedulazione
che determina quando è il momento giusto di
eseguire una particolare operazione.
Design Restructuring:
Temporal Task Inversion
timer Event
«temporal
clustering»
: AutoSensor
cruiseControl
Request
«control»
: CruiseControl
timer Event
«temporal
clustering»
: Calibration
start(),
stop()
«entity»
: CalibrationConstant
Collaboration diagram iniziale (analysis model): i due oggetti
«temporal clustering» possono essere raggruppati
Design Restructuring:
Temporal Task Inversion
«external timer»
: DigitalClock
timer Event
«temporal inversion»
: Periodic
cruiseControl
Request
«control»
: CruiseControl
start(),
stop()
«entity»
: CalibrationConstant
Collaboration diagram finale (design model): i due oggetti precedenti
sono stati raggruppati in un unico task con stereotopo «temporal inversion»
Sviluppo dell’architettura
dei task
I criteri di task structuring si applicano ìn
questo ordine:
1. Device interface task: si inizia con i device
interface object che interagiscono con il
mondo esterno.
2. Control task: analizzare tutti gli statedependent control object e strutturarli come
dei control task.
Sviluppo dell’architettura
dei task (continua)
3. Periodic task: analizzare tutte le attività
interne periodiche, che vanno strutturate
come periodic task.
4. Altri task interni.
Il risultato di questa fase è un collaboration
diagram concorrente che mostra tutti i task del
sistema.
Quello che manca è stabilire il tipo di
comunicazione tra i vari task.
Collaboration diagram iniziale (design
model):le interfacce non sono specificate
«subsystem»
: BankServer
ATM Transaction
Card
Reader
Input
«asynchronous
I/O device»
: CardReader
Card
Reader
Output
Dispenser Output
«client subsystem»
:ATMClient
«asynchronous
I/O device
interface»
: CardReader
Interface
Card Inserted,
Card Ejected,
Card
Confiscated
Card
Input
Data
Card
Data
Card
Request
«user interface»
: CustomerInterface
: ATM
Customer
Display
Information
Cash Withdrawal Amount
Cash
Response
Eject,
Confiscate
«data
abstraction»
: ATMCard
Customer
Input
Bank Responses
«data
abstraction»
: ATMCash
«passive
output
device»
: Cash
Dispenser
Cash
Added
«control
clustering»
: ATMControl
Transaction Data
Update Transaction
Status(Cash Details),
Update PIN Status,
Transaction Request
Customer Info
Transaction Details
Start Up,
Closedown
«user
interface»
: Operator
Interface
«data abstraction»
: ATM Transaction
Operator
Input
Operator
Info
: Operator
Sincronizzazione e
Comunicazione tra task
Definizione delle interfacce di comunicazione
dei task.
 Fino ad ora le interfacce tra i task sono
semplici messaggi, come descritto
nell’analysis model.
 Necessità di mappare queste interfacce nella
forma di messaggi più specifici.
Loosely Coupled (Asynchronous)
Message Communication
Il task sorgente manda un messaggio al
destinatario e continua la sua esecuzione senza
aspettare una risposta.


Visto che i due task possono evolvere a velocità
diverse, è consigliabile l’introduzione di una
coda di messaggi tra i due.
Se non ci sono messaggi disponibili quando il
destinatario ne richede uno, la sua esecuzione
viene sospesa.
Loosely Coupled (Asynchronous)
Message Communication
«asynchronous input
device interface»
: CruiseControl
LeverInterface
«asynchronous input
device interface»
: CruiseControl
LeverInterface
Cruise
Control
Request
«control»
: CruiseControl
Cruise
Control
Request
«control»
: CruiseControl
Tightly Coupled (Synchronous)
Message Comm. con risposta
Il task sorgente, dopo aver mandato il
messaggio al destinatario, viene sospeso in
attesa di una risposta.



Quando il destinatario riceve il messaggio, lo
processa, genera una risposta e la manda al task
sorgete.
In questo modo entrambi possono continuare.
Se non ci sono messaggi, il destinatario del
messaggio viene sospeso.
Tightly Coupled (Synchronous)
Message Comm. con risposta
ATM Transaction
«client subsystem»
: ATMClient
«server subsystem»
: BankServer
Bank Response
ATM Transaction
«client subsystem»
: ATMClient
«server subsystem»
: BankServer
Bank Response
Tightly Coupled (Synchronous)
Message Comm. senza risposta
Dopo aver mandato il messaggio al task
destinatario, il task sorgente si blocca in attesa
che questi lo riceva.



Quando il messaggio arriva, il destinatario lo
accetta, sbloccando così il sorgrnte.
A questo punto entrambi posssono continare.
Anche in questo caso il destinatario viene
sospeso se non ci sono messaggi.
Tightly Coupled (Synchronous)
Message Comm. senza risposta
«non-time-crirical»
: SensorStatistics
Algorithm
«non-time-crirical»
: SensorStatistics
Algorithm
Temperature
and Pressure
Statistics
Temperature
and Pressure
Statistics
«passive output
device interface»
: SensorStatistics
DisplayInterface
«passive output
device interface»
: SensorStatistics
DisplayInterface
Event Synchronization
Esistono tre tipi diversi di eventi per la
sincronizzazione:
 Eventi esterni

Tipicamente un interrupt da un dispositivo di I/O
 Eventi timer

Rappresentano l’attivazione periodica di un task
 Eventi interni

Rappresentano la sincronizzazione tra un task
sorgente ed uno destinazione
Event Synchronization:
Eventi Esterni
«asynchronous
input device»
: CruiseControlLever
«asynchronous
input device»
: CruiseControlLever
Cruise Control
Input
cruiseControlInterrupt
(cruiseControlInput)
«asynchronous input
device interface»
: CruiseControl
LeverInterface
«asynchronous input
device interface»
: CruiseControl
LeverInterface
Event Synchronization:
Eventi Timer
Distance
Timer Event
«external timer»
: DigitalClock
distance
TimerEvent
«external timer»
: DigitalClock
«periodic»
: Distance
Timer
«periodic»
: Distance
Timer
Event Synchronization:
Eventi Interni
Si usa quando due task devono sincronizzare le
loro operazioni senza bisogno di scambiarsi
dei dati.
 Il task sorgente segnala l’evento.
 Il task di destinazione che aspetta l’evento
viene sospeso finchè l’evento non viene
segnalato.

Se l’evento era già stato segnalato, il
destinatario non viene sospeso.
Event Synchronization:
Eventi Interni
Part Ready
«control»
: pick&PlaceRobot
«control»
: drillingRobot
Part Completed
Part Ready
«control»
: pick&PlaceRobot
«control»
: drillingRobot
Part Completed
Collaboration diagram finale (design
model):tutte le interfacce sono specificate
«subsystem»
: BankServer
ATM Transaction
Card
Reader
Input
«asynchronous
I/O device»
: CardReader
Card
Reader
Output
Dispenser Output
«client subsystem»
: ATMClient
«asynchronous
I/O device
interface»
: CardReader
Interface
Card Inserted,
Card Ejected,
Card
Confiscated
Eject,
Confiscate
write
(card
Data)
«data
abstraction»
: ATMCard
Read(
Out card
Data)
Customer
Input
: ATM
Display
Customer Information
Bank Responses
«user interface»
: CustomerInterface
withdrawCash
«data
abstraction»
: ATMCash
«passive
output
device»
: Cash
Dispenser
addCash
«control
clustering»
: ATMControl
Update Transaction
Status(Cash Details),
Update PIN Status(
Status), read(out
Transaction Data)
updateCustomer Info
(cardData,PIN),
updateCustomerSelect
(in slection out details)
Start Up,
Closedown
«user
interface»
: Operator
Interface
«data abstraction»
: ATM Transaction
Operator
Input
Operator
Info
: Operator
Task Behavior Specification
Descrive il comportamento di un task
concorrente. In particolare:
 Interfaccia
 Struttura
 Caratteristiche temporali
 Priorità
 Errori