Task Structuring [2 a parte] Maurizio Mazza Corso di Ingegneria del Software II.

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

«state dependentcontrol»

: ATMControl

«input deviceinterface»: Receipit

PrintInterface

«input deviceinterface»

: CashDispenserInterface

2: Dispense Cash

7: Receipt Printed

1: Withdrawal OK

8: Eject

4: CashDispensed

5: PrintReceipt

3: DispenserOutput

6:PrinterOutput

Collaboration diagram iniziale (analysis model)


Ejecting Printing

DispensingProcessingWithdrawal 1: Withdrawal OK /

2: Dispense Cash

7: Receipt Printed /8: Eject

4: Cash Dispensed /5: Print Receipt

Satechart associato all’oggetto state-dependent ATM Control


«controlclustering»

: ATMController

1: ATMControlRequest

8: eject

3: dispenserOutput

6: printerOutput

Collaboration diagram finale (design model): i tre oggetti precedentisono 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.

«state dependentcontol»

: CruiseControl

«output deviceinterface»

: ThrottleInterface

«algorithm»: Acceleration

«algorithm»: Cruiser

«algorithm»: Resumption

«entity»: DesiredSpeed

«entity»: CurrentSpeedRead Current Speed value

Read

CurrentSpeed Value

Enable Resume CruisingDisable Resume Cruising

Reached Cruising

ReadDesired

Speed value

DesiredSpeed valueRead

Enable Maintain SpeedDisable Maintain Speed

Enable Increase SpeedDisable Increase Speed

Throttle ValueThrottleValue

Current Speed ValueThrottle Value

«control»: CruiseControl

«mutually exclusiveclustering»

: SpeedAdjustment

«periodic outputdevice interface»: ThrottleInterface


«entity»: CurrentSpeed

read(outcurrentSpeed

Value)

throttleValue


Value)

select()clear()cruiseControl

CommandreachedCruising

Collaboration diagram finale (design model): i tre oggetti precedenti concon stereotopo «algorithm» sono stati rggruppati in un unico task.

Design Restructuring

Scopo: ridurre in modo sistematico il numerodi 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

«control»: ElevatorControl

«multiple instanceinversion»: ElevatorController

«entity»: Elevator

StateInformation

Invece di avere tante istanze di oggetti attivi (come a sinistra) si tiene ununico oggetto attivo a cui si associano tante istanze di oggetti passivi permantenere 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.


«mutually exclusiveclustering»

: SpeedAdjustment

«periodic outputdevice interface»: ThrottleInterface

«external outputdevice»

: Thtottle



cruiseControlRequest


Value)

throttleValue

throttlePosition


Value)

select()clear()cruiseControl

CommandreachedCruising

«external outputdevice»

: Thtottle

throttlePosition

«sequential inversion»: InvertedCruise

Control




Value)

Design Restructuring:Sequential Task Inversion

Collaboration diagram ristrutturato: i tre oggetti precedenti sonostati 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.


«temporalclustering»

: AutoSensor

timer Event



«temporalclustering»

: Calibration

timer Event

«entity»: CalibrationConstant

start(),stop()

Collaboration diagram iniziale (analysis model): i due oggetti «temporal clustering» possono essere raggruppati




«entity»: CalibrationConstant

start(),stop()

«temporal inversion»: Periodic

«external timer»: DigitalClock

timer Event

Collaboration diagram finale (design model): i due oggetti precedentisono stati raggruppati in un unico task con stereotopo «temporal inversion»

Sviluppo dell’architetturadei 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 state-dependent control object e strutturarli come dei control task.

Sviluppo dell’architetturadei 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 delsistema.Quello che manca è stabilire il tipo di comunicazione tra i vari task.

«subsystem»: BankServer

«asynchronousI/O device»

: CardReader

CardReaderInput

CardReaderOutput

«asynchronousI/O deviceinterface»

: CardReaderInterface

«client subsystem»:ATMClient

«dataabstraction»: ATMCard

CardInputData

«user interface»: CustomerInterface

CardData

CardRequestCustomer

Input

DisplayInformation

ATM Transaction Bank Responses


: ATMControl

Card Inserted,Card Ejected,

CardConfiscated

Eject,Confiscate

«dataabstraction»: ATMCash

«passiveoutput

device»: Cash

Dispenser

Dispenser Output

Cash Withdrawal Amount

CashResponse

«userinterface»: OperatorInterface

CashAdded

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown

«data abstraction»: ATM Transaction

Transaction Data

Transaction Details

Update TransactionStatus(Cash Details), Update PIN Status,Transaction Request

Customer Info

Collaboration diagram iniziale (designmodel):le interfacce non sono specificate

Sincronizzazione e Comunicazione tra task

Definizione delle interfacce di comunicazionedei 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 inputdevice interface»: CruiseControlLeverInterface




CruiseControlRequest

CruiseControlRequest

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

«client subsystem»: ATMClient

«server subsystem»: BankServer

ATM Transaction

Bank Response


«server subsystem»: BankServer

ATM Transaction

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

Temperatureand Pressure

Statistics «passive outputdevice interface»: SensorStatisticsDisplayInterface

«non-time-crirical»: SensorStatistics

Algorithm

Temperatureand Pressure

Statistics «passive outputdevice interface»: SensorStatisticsDisplayInterface

Event Synchronization

Esistono tre tipi diversi di eventi per lasincronizzazione: 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

«asynchronousinput device»

: CruiseControlLever


Cruise ControlInput

«asynchronousinput device»

: CruiseControlLever


cruiseControlInterrupt(cruiseControlInput)

Event Synchronization:Eventi Timer


«periodic»: Distance

Timer

DistanceTimer Event


«periodic»: Distance

Timer

distanceTimerEvent

Event Synchronization:Eventi Interni

Si usa quando due task devono sincronizzare leloro operazioni senza bisogno di scambiarsidei 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

«control»: pick&PlaceRobot

«control»: drillingRobot

Part Ready

Part Completed

«control»: pick&PlaceRobot

«control»: drillingRobot

Part Ready

Part Completed

«subsystem»: BankServer

«asynchronousI/O device»

: CardReader

CardReaderInput

CardReaderOutput

«asynchronousI/O deviceinterface»

: CardReaderInterface


«dataabstraction»: ATMCard

write(cardData)

«user interface»: CustomerInterface

Read(Out card

Data)Customer

Input

DisplayInformation

ATM Transaction Bank Responses


: ATMControl

Card Inserted,Card Ejected,

CardConfiscated

Eject,Confiscate

«dataabstraction»: ATMCash

«passiveoutput

device»: Cash

Dispenser

Dispenser Output

withdrawCash

«userinterface»: OperatorInterface

addCash

: ATMCustomer

: Operator

OperatorInput

OperatorInfo

Start Up,Closedown

«data abstraction»: ATM Transaction

Update TransactionStatus(Cash Details), Update PIN Status(

Status), read(outTransaction Data)

updateCustomer Info(cardData,PIN),

updateCustomerSelect(in slection out details)

Collaboration diagram finale (designmodel):tutte le interfacce sono specificate

Task Behavior Specification

Descrive il comportamento di un taskconcorrente. In particolare: Interfaccia Struttura Caratteristiche temporali Priorità Errori

Task Structuring [2 a parte] Maurizio Mazza Corso di Ingegneria del Software II.

Documents

Transcript of Task Structuring [2 a parte] Maurizio Mazza Corso di Ingegneria del Software II.