Task Structuring 2 a parte Maurizio Mazza Corso

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 n Mutually exclusive clustering

Sommario w Design Restructuring w Sviluppo dell’architettura dei task w Sincronizzazione e comunicazione tra task w Task Behavior Specification (TBS)

Introduzione w Task Structuring: strutturazione di un (sotto)sistema in task concorrenti. w Creazione di una task architecture n n Determinazione dei task concorrenti Definizione delle interfacce di comunicazione

Introduzione 2 Fasi: w Criteri di I/O structuring, internal task structuring e task priority (gia visti…) l Il risultato è un mapping uno a uno da oggetti dell’analysis modeling a task concorrenti. w Criteri di task clustering e task inversion l Usati per ridurre il numero di task fisici del sistema.

Task Clustering Criteria: Control Clustering w Un control object viene mappato in un task separato (control task). w In certi casi un control task può essere combinato con altri oggetti. n 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 Print. Interface 6: Printer Output 7: Receipt Printed 8: Eject 4: Cash Dispensed 2: Dispense Cash «input device interface» : Cash. Dispenser Interface Collaboration diagram iniziale (analysis model) 3: Dispenser Output

Task Clustering Criteria: Control Clustering - Esempio Ejecting 7: Receipt Printed / 8: Eject Printing 4: Cash Dispensed / 5: Print Receipt Processing Withdrawal 1: Withdrawal OK / 2: Dispense Cash Dispensing Satechart associato all’oggetto state-dependent ATM Control

Task Clustering Criteria: Control Clustering - Esempio 1: ATMControl Request 8: eject 6: printer. Output «control clustering» : ATM Controller 3: dispenser. Output 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 w 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. n Questi task possono essere raggruppati dentro ad un unico task.

Enable Increase Speed Disable Increase Speed «state dependent contol» : Cruise. Control 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» : Throttle. Interface Current Speed Value Read Current Speed Value «entity» : Current. Speed Reached Cruising «algorithm» : Resumption Desired Speed value Read «entity» : Desired. Speed Throttle Value Read Current Speed value

«control» : Cruise. Control cruise. Control Command reached Cruising «mutually exclusive clustering» : Speed. Adjustment throttle Value «periodic output device interface» : Throttle. Interface select() clear() read(out current. Speed Value) «entity» : Desired. Speed «entity» : Current. Speed Collaboration diagram finale (design model): i tre oggetti precedenti 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. w Utilizzo dei criteri di task inversion per raggruppare insieme diversi task e diminuire l’overhead dovuto alla comunicazione. n n n Multiple instance task inversion Sequential task inversion Temporal task inversion

Design Restructuring: Multiple Instance Task Inversion w Sostituzione di tutti i task dello stesso tipo con un solo task che svolge lo stesso servizio. n 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 State. Information 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 w Si usa quando vi è una comunicazione tightly coupled (sincrona) tra due o più task. n n 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.

cruise. Control Request «control» : Cruise. Control cruise. Control Command reached Cruising «mutually exclusive clustering» : Speed. Adjustment throttle Value «periodic output device interface» : Throttle. Interface throttle. Position «external output device» : Thtottle select() clear() read(out current. Speed Value) «entity» : Desired. Speed read(out current. Speed Value) «entity» : Current. Speed

Design Restructuring: Sequential Task Inversion cruise. Control Request «sequential inversion» : Inverted. Cruise Control throttle. Position «external output device» : Thtottle read(out current. Speed Value) «entity» : Current. Speed Collaboration diagram ristrutturato: i tre oggetti precedenti sono stati raggruppati in un unico task con stereotopo «sequential inversion»

Design Restructuring: Temporal Task Inversion w Con questa tecnica, due o più periodic task (periodic internal, periodic I/O, temporally clustered) vengono combinati in un solo task. n 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» : Auto. Sensor cruise. Control Request «control» : Cruise. Control timer Event «temporal clustering» : Calibration start(), stop() «entity» : Calibration. Constant Collaboration diagram iniziale (analysis model): i due oggetti «temporal clustering» possono essere raggruppati

Design Restructuring: Temporal Task Inversion «external timer» : Digital. Clock timer Event «temporal inversion» : Periodic cruise. Control Request «control» : Cruise. Control start(), stop() «entity» : Calibration. Constant 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: w Device interface task: si inizia con i device interface object che interagiscono con il mondo esterno. w Control task: analizzare tutti gli statedependent control object e strutturarli come dei control task.

Sviluppo dell’architettura dei task (continua) w Periodic task: analizzare tutte le attività interne periodiche, che vanno strutturate come periodic task. w 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» : Bank. Server ATM Transaction «asynchronous I/O device» : Card. Reader Card Reader Input Card Reader Output Dispenser Output «client subsystem» : ATMClient «asynchronous I/O device interface» : Card. Reader Interface Card Input Data Card Inserted, Card Ejected, Card Confiscated Card Data Card Request «user interface» : Customer. Interface : 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. w Fino ad ora le interfacce tra i task sono semplici messaggi, come descritto nell’analysis model. w 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. n n 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» : Cruise. Control Lever. Interface Cruise Control Request «control» : Cruise. Control

Tightly Coupled (Synchronous) Message Comm. con risposta Il task sorgente, dopo aver mandato il messaggio al destinatario, viene sospeso in attesa di una risposta. n n n 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» : Bank. Server 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. n n n 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» : Sensor. Statistics Algorithm Temperature and Pressure Statistics «passive output device interface» : Sensor. Statistics Display. Interface

Event Synchronization Esistono tre tipi diversi di eventi per la sincronizzazione: w Eventi esterni n Tipicamente un interrupt da un dispositivo di I/O w Eventi timer n Rappresentano l’attivazione periodica di un task w Eventi interni n Rappresentano la sincronizzazione tra un task sorgente ed uno destinazione

Event Synchronization: Eventi Esterni «asynchronous input device» : Cruise. Control. Lever Cruise Control Input cruise. Control. Interrupt (cruise. Control. Input) «asynchronous input device interface» : Cruise. Control Lever. Interface

Event Synchronization: Eventi Timer Distance Timer Event «external timer» : Digital. Clock distance Timer. Event «external timer» : Digital. Clock «periodic» : Distance Timer

Event Synchronization: Eventi Interni Si usa quando due task devono sincronizzare le loro operazioni senza bisogno di scambiarsi dei dati. w Il task sorgente segnala l’evento. w Il task di destinazione che aspetta l’evento viene sospeso finchè l’evento non viene segnalato. n Se l’evento era già stato segnalato, il destinatario non viene sospeso.

Event Synchronization: Eventi Interni «control» : pick&Place. Robot Part Ready «control» : drilling. Robot Part Completed «control» : pick&Place. Robot Part Ready Part Completed «control» : drilling. Robot

Collaboration diagram finale (design model): tutte le interfacce sono specificate «subsystem» : Bank. Server ATM Transaction «asynchronous I/O device» : Card. Reader Card Reader Input Card Reader Output Dispenser Output «client subsystem» : ATMClient «asynchronous I/O device interface» : Card. Reader Interface write (card Data) Card Inserted, Card Ejected, Card Confiscated Eject, Confiscate «data abstraction» : ATMCard Customer Input : ATM Display Customer Information Bank Responses Read( Out card Data) «user interface» : Customer. Interface withdraw. Cash «data abstraction» : ATMCash «passive output device» : Cash Dispenser add. Cash «control clustering» : ATMControl Update Transaction Status(Cash Details), Update PIN Status( Status), read(out Transaction Data) update. Customer Info (card. Data, PIN), update. Customer. Select (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: w Interfaccia w Struttura w Caratteristiche temporali w Priorità w Errori