Task Structuring [2 a 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 «state dependent control» : ATMControl «input device interface» : Receipit PrintInterface «input device interface» : CashDispenser Interface 2: Dispense Cash 7: Receipt Printed 1: Withdrawal OK 8: Eject 4: Cash Dispensed 5: Print Receipt 3: Dispenser Output 6:Printer Output Collaboration diagram iniziale (analysis model)

Task Clustering Criteria: Control Clustering - Esempio EjectingPrinting Dispensing Processing Withdrawal 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

Task Clustering Criteria: Control Clustering - Esempio «control clustering» : ATM Controller 1: ATMControl Request 8: eject 3: dispenserOutput 6: printerOutput 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.

«state dependent contol» : CruiseControl «output device interface» : ThrottleInterface «algorithm» : Acceleration «algorithm» : Cruiser «algorithm» : Resumption «entity» : DesiredSpeed «entity» : CurrentSpeed ReadCurrent Speed value Read Current Speed Value Enable Resume Cruising Disable Resume Cruising Reached Cruising Read Desired Speed value Desired Speed value Read Enable Maintain Speed Disable Maintain Speed Enable Increase Speed Disable Increase Speed Throttle Value Throttle Value Current Speed Value Throttle Value

«control» : CruiseControl «mutually exclusive clustering» : SpeedAdjustment «periodic output device interface» : ThrottleInterface «entity» : DesiredSpeed «entity» : CurrentSpeed read(out currentSpeed Value) throttle Value read(out currentSpeed Value) select() clear() cruiseControl Command reached Cruising 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 «control» : Elevator Control «multiple instance inversion» : Elevator Controller «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.

«control» : CruiseControl «mutually exclusive clustering» : SpeedAdjustment «periodic output device interface» : ThrottleInterface «external output device» : Thtottle «entity» : DesiredSpeed «entity» : CurrentSpeed cruiseControl Request read(out currentSpeed Value) throttle Value throttlePosition read(out currentSpeed Value) select() clear() cruiseControl Command reached Cruising

«external output device» : Thtottle throttlePosition «sequential inversion» : InvertedCruise Control cruiseControl Request «entity» : CurrentSpeed read(out currentSpeed Value) Design Restructuring: Sequential Task Inversion 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 «temporal clustering» : AutoSensor timer Event «control» : CruiseControl cruiseControl Request «temporal clustering» : Calibration timer Event «entity» : CalibrationConstant start(), stop() Collaboration diagram iniziale (analysis model): i due oggetti «temporal clustering» possono essere raggruppati

Design Restructuring: Temporal Task Inversion «control» : CruiseControl cruiseControl Request «entity» : CalibrationConstant start(), stop() «temporal inversion» : Periodic «external timer» : DigitalClock timer Event 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 state- dependent 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.

Dagli Analysis Model Object ai Design Model Task User interface Device interface Sistem Interface User Interface Sequential clustering Control clustering Asynchronous device interface Periodic device interface Passive device interface Resource monitor Temporal clustering Sequential clustering Asynchronous system interface Qualunque criterio di clustering Analysis Model (object)Design Model (task)

Dagli Analysis Model Object ai Design Model Task Entity Timer State-dependent control Coordinator Buisness logic Algorithm Sequential server Concurrent server Periodic, Temporal clustering Sequential clustering Control, Control clustering Coordinator Sequential clustering Asynchronous buisness logic Periodic buisness logic Asynchronous/Periodic algorithm Non-time-critical Analysis Model (object)Design Model (task)

«subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» :ATMClient «data abstraction» : ATMCard Card Input Data «user interface» : CustomerInterface Card Data Card Request Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output Cash Withdrawal Amount Cash Response «user interface» : Operator Interface Cash Added : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Transaction Data Transaction Details Update Transaction Status(Cash Details), Update PIN Status, Transaction Request Customer Info Collaboration diagram iniziale (design model):le interfacce non sono specificate

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 «control» : CruiseControl «asynchronous input device interface» : CruiseControl LeverInterface «control» : CruiseControl Cruise Control Request Cruise Control Request

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 «client subsystem» : ATMClient «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 Temperature and Pressure Statistics «passive output device interface» : SensorStatistics DisplayInterface «non-time-crirical» : SensorStatistics Algorithm Temperature and Pressure Statistics «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 interface» : CruiseControl LeverInterface Cruise Control Input «asynchronous input device» : CruiseControlLever «asynchronous input device interface» : CruiseControl LeverInterface cruiseControlInterrupt (cruiseControlInput)

Event Synchronization: Eventi Timer «external timer» : DigitalClock «periodic» : Distance Timer Distance Timer Event «external timer» : DigitalClock «periodic» : Distance Timer distance TimerEvent

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 «control» : pick&PlaceRobot «control» : drillingRobot Part Ready Part Completed «control» : pick&PlaceRobot «control» : drillingRobot Part Ready Part Completed

«subsystem» : BankServer «asynchronous I/O device» : CardReader Card Reader Input Card Reader Output «asynchronous I/O device interface» : CardReader Interface «client subsystem» : ATMClient «data abstraction» : ATMCard write (card Data) «user interface» : CustomerInterface Read( Out card Data) Customer Input Display Information ATM TransactionBank Responses «control clustering» : ATMControl Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCash «passive output device» : Cash Dispenser Dispenser Output withdrawCash «user interface» : Operator Interface addCash : ATM Customer : Operator Operator Input Operator Info Start Up, Closedown «data abstraction» : ATM Transaction Update Transaction Status(Cash Details), Update PIN Status( Status), read(out Transaction Data) updateCustomer Info (cardData,PIN), updateCustomerSelect (in slection out details) Collaboration diagram finale (design model):tutte le interfacce sono specificate

Task Behavior Specification Descrive il comportamento di un task concorrente. In particolare:  Interfaccia  Struttura  Caratteristiche temporali  Priorità  Errori

Task Behavior Specification 1.Interfaccia del task  Messaggi input e output  Tipo di interfaccia  Eventi segnalati (input e output)  Input o output esterni  Oggetti passivi riferiti

Task Behavior Specification 1. Interfaccia del task : ESEMPIO Input Input: Eventi: Card reader external interrupt to indicate that a card has been input. Input esterni: cardReaderInput Loosely coopled message communication : Eject,confiscate Output Output: Output esterni: cardReaderInput Loosely coopled message communication : cardInserted, cardEjected, cardConfiscated Passive object acceduti: ATMCard

Task Behavior Specification 2.Informazioni sulla struttura dei Task  Criteri di task structuring usati  Oggetti dell’analysis model mappati nel task 3.Caratteristiche temporali  Frequenza di attivazione  Tempo di esecuzione stimato (C i )

Task Behavior Specification 2.Struttura del task: ESEMPIO Criterio: Asynchronous Input Device Interface Oggetti mappati nel task : cardReaderInterface 3.Caratteristiche temporali: ESEMPIO  Attivazione: Asynchronous-from external card reader. Worst case inter-arrival time = 500 msec. Average inter-arrival time > 5 minutes.  Tempo di esecuzione C i : 5ms per message

Task Behavior Specification 4.Priorità relativa del task 5.Errori riscontrati nel task 6.Event sequence logic  Non ancora visto…

Task Behavior Specification 4.Priorità del task: ESEMPIO  High-Needs to be responsive to incoming cards. 5.Errori riscontrati: ESEMPIO  Unrecognized card. Card reader malfunction 6.Event sequence logic  Ancora da vedere…