Task Structuring COMET TASK STRUCTURING - Prima parte -

Indice Introduzione - Introduzione - Cosa si intende per taskCosa si intende per task - Task Stucturing: obiettiviTask Stucturing: obiettivi Task Stucturing Categories (first stage) - Task Stucturing Categories (first stage) - I/O Task Structuring criteriaI/O Task Structuring criteria - Task interfaccia per I/O device asincroni Task interfaccia per I/O device asincroni - Task interfaccia per I/O device periodici Task interfaccia per I/O device periodici - Task interfaccia per I/O device passivi Task interfaccia per I/O device passivi - Resource Monitor Task Resource Monitor Task - Internal Task Structuring criteriaInternal Task Structuring criteria - Tasks Periodici Tasks Periodici - Tasks Asincroni Tasks Asincroni - Control Tasks Control Tasks - User Interface Tasks User Interface Tasks

Indice - Task Priority criteriaTask Priority criteria - Time-Citical Tasks Time-Citical Tasks - Non-Time-Critical Tasks Non-Time-Critical Tasks -Task Stucturing Categories (second stage) - Task Clustering criteriaTask Clustering criteria - Temporal Clustering Temporal Clustering - Sequential Clustering Sequential Clustering - Control Clustering - Clustering mutuamente esclusivo - Task Inversion criteria

Cosa si intende per task - -Un oggetto attivo con un proprio thread di controllo. - -Dall’ Analysis Model object-oriented si sviluppa una task architecture : - tasks concorrenti - classi passive Cos’è un task

Task Structuring: obiettivi - -Semplificare e rendere più chiaro il design senza introdurre inutilmente troppi tasks Obiettivi Separation of concerns : Un task usa information hiding per aspetti riguardanti la concorrenza (timing, controllo, sequenzialitá, comunicazione). Una classe per aspetti strutturali.

Nel ciclo di vita del software COMET Analysis Modeling 2 Task Structuring: obbiettivi Design Modeling Incremental Software Construction

Task Structuring Categories - -Per aiutare il designer esistono delle linee guida ( criteria ), divise in categorie. - -Questa divisione si basa sull’ attività di Task Structuring a cui le categorie si riferiscono. Task Structuring Categories

I/O Task Structuring criteria - -Determinare gli I/O tasks come interfacce dei device esterni - -Quando si attiva un particolare I/O task I/O Task Structuring criteria

Attività iniziali: - -Analizzare le caratteristiche degli I/O devices - -Analizzare la natura dei dati

I/O Task Structuring criteria Caratteristiche degli I/O device - -Device asincrono : è interrupt - driven - -Device passivo : non genera interrupt al completamento delle operazioni di I/O - -Comunication link : alcuni device esterni al sistema comunicano con esso attraverso un collegamento, con scambio di messaggi

I/O Task Structuring criteria Natura dei dati - -Dato discreto : ha un numero finito di valori; viene campionato ad ogni cambiamento - -Dato analogico : può avere anche un numero infinito di valori; viene campionato su richiesta o periodicamente

I/O Task Structuring criteria - -Se esiste un device asincrono deve esistere anche un suo task di interfaccia verso il sistema, che si attiva tramite un interrupt generato dal device - -Se occorre un task di interfaccia può demandare la computazione ad altri task e rimettersi in attesa di un altro interrupt Task interfaccia per I/O device asincroni

I/O Task Structuring criteria Task interfaccia per I/O device asincroni: ESEMPIO > :CruiseControlLever 1: CruiseControl Input :CruiseControl > :CruiseControlLever Interface 2: CruiseControl Request ANALYSIS MODEL

I/O Task Structuring criteria Task interfaccia per I/O device asincroni: ESEMPIO > :CruiseControlLever 1: CruiseControl interrupt (CruiseControlInput) :CruiseControl > :CruiseControlLever Interface 2: CruiseControl Request

I/O Task Structuring criteria - -É un task di interfaccia per un device passivo ( es: sensore ), i cui dati devono essere campionati periodicamente. - -Si attiva con un timer event, porta a termine le operazioni di I/O e ritorna in attesa per il prossimo timer event. Task interfaccia per I/O device periodici

I/O Task Structuring criteria Task interfaccia per I/O device periodici: ESEMPIO > :Engine 1: EngineInput > :EngineInterface 2: engineOn 2A: engineOff ANALYSIS MODEL

I/O Task Structuring criteria Task interfaccia per I/O device periodici: ESEMPIO > :Engine 1: read (out EngineInput) > :DigitalClock > :EngineInterface 0: TimerEvent 2: engineOn 2A: engineOff

I/O Task Structuring criteria - -Simile al precedente, si usa però per ricevere o inviare dati a device passivi su richiesta, in genere tramite messaggio. - -Si utilizzano maggiormente con device di output. Task interfaccia per I/O device passivi

I/O Task Structuring criteria Task interfaccia per I/O device passivi: ESEMPIO > :Display 3: SensorStatistics > :SensorStatistics Algorithm > :SensorStatisticDisplay Interface 2: Temperature&Pressure Statistics > :SensorData Repository 1.1: Sensor Data 1: Sensor Request ANALYSIS MODEL

I/O Task Structuring criteria Task interfaccia per I/O device passivi: ESEMPIO > :Display 3: SensorStatistics > :SensorStatistics Algorithm > :SensorStatisticDisplay Interface 2: Temperature&Pressure Statistics > :SensorData Repository 1: read (out sensorData)

I/O Task Structuring criteria - -É un caso speciale di task per I/O device passivi. - -Richieste da sorgenti diverse: -coordinare tali richieste -evitare la perdita di dati -garantire che vengano soddisfatte sequenzialmente. Resource Monitor Task

I/O Task Structuring criteria Resource Monitor Task: ESEMPIO > :FloorLamp :anElevatorControl 3,4: FloorLamp Output > :FloorLamp Inteface 1: FloorLamp Command :another ElevatorControl 2: FloorLamp Command ANALYSIS MODEL

I/O Task Structuring criteria Resource Monitor Task: ESEMPIO > :FloorLamp :anElevatorControl 3,4: FloorLamp Output > :FloorLamp Inteface 1: FloorLamp Command :another ElevatorControl 2: FloorLamp Command

Internal Task Structuring criteria - -Determinare i tasks interni, non di I/O - -Quando si attiva un particolare task interno Internal Task Structuring criteria

- -Soprattutto in sistemi concorrenti o real-time. - -Si attiva con un timer event, porta a termine le operazioni di I/O e ritorna in attesa per il prossimo timer event. Tasks periodici - -Attività da eseguire periodicamente.

Internal Task Structuring criteria Tasks periodici: ESEMPIO > :Distance 3.1: ShaftRotation CountValue > :DigitalClock > :DistanceTimer 1: TimerEvent 2: Calculate > :ShaftRotation Count > :Calibartion Constant 4.1: Calibartion ConstantValue 3: Read 4: Read ANALYSIS MODEL

Internal Task Structuring criteria Tasks periodici: ESEMPIO > :Distance 3: read (out ShaftRotationCountValue) > :DigitalClock > :DistanceTimer 1: TimerEvent 2: Calculate > :ShaftRotation Count > :Calibartion Constant 4: read (out CalibartionConstantValue)

Internal Task Structuring criteria - -Attività su richiesta. - -Si attiva su richiesta tramite un messaggio interno od un evento, inviato ad es. da un’altro task, porta a termine le operazioni e ritorna in attesa per il prossimo messaggio od evento. Tasks asincroni

Internal Task Structuring criteria Tasks asincroni: ESEMPIO > :Cruiser 3.1: CurrentSpeedValue > :ThrottleInterface > :CruiseControl 4: Throttle Value 1: Cruise Control Command > :CurrentSpeed > :Desired Speed 2.1: DesideredSpeedValue 5: Throttle Position 3: Read 2: Read ANALYSIS MODEL

Internal Task Structuring criteria Tasks asincroni: ESEMPIO > :Cruiser 3: read (out CurrentSpeedValue) > :ThrottleInterface > :CruiseControl 4: Throttle Value 1: Cruise Control Command > :CurrentSpeed > :Desired Speed 2: read (out DesideredSpeedValue) 5: Throttle Position

Internal Task Structuring criteria - -Un task che esegue uno statechart sequenzial- mente. Control Tasks - -Negli statecharts non è permessa la concorrenza.

Internal Task Structuring criteria Control Tasks: ESEMPIO 1: CruiseControl Request > :CruiseControl 2: CruiseControl Command ANALYSIS MODEL

Internal Task Structuring criteria Control Tasks: ESEMPIO 1: CruiseControl Request > :CruiseControl 2: CruiseControl Command

Internal Task Structuring criteria - -Situazione : un utente porta a termine una serie di operazioni sequenzialmente. - -Tale task si interfaccia con I/O device ( tastiera, display, mouse...) in modo standard tramite il sistema operativo. User Interface Tasks

Internal Task Structuring criteria User Interface Tasks: ESEMPIO 1: OperatorCommand > :OperatorInterface 2.1: SensorData :Operator > : SensorData Repository 3: DisplayData 2: SensorRequest ANALYSIS MODEL

Internal Task Structuring criteria User Interface Tasks: ESEMPIO 1: OperatorCommand > :OperatorInterface 2: read (out SensorData) :Operator > : SensorData Repository 3: DisplayData

Internal Task Structuring criteria - -In UNIX un utente può comunque decidere di eseguire diverse attività concorrentemente, ser- vendosi dei processi in background. -In Windows otteniamo lo stesso risultato operando su più finestre. - -Più tasks di interfaccia utente. User Interface Tasks (multipli)

Internal Task Structuring criteria User Interface Tasks: ESEMPIO 2 1: Factory StatusQuery > :FactoryStatus Window 2: read (out FactoryStatus) :Operator > :FactoryStatus Repository 3: Status DisplayData > :FactoryAlarm Window 2A: read (out AllarmStatus) > :FactoryAllarm Repository 1A: Allarm Query 3A: Allarm DisplayData

Internal Task Structuring criteria - -É possibile che si debbano usare molti task che sono istanze di uno stesso tipo. - -Nel caso di oggetti di controllo state-dependent che eseguono uno stesso statechart, abbiamo un control task per ogni oggetto. Tasks multipli dello stesso tipo

Internal Task Structuring criteria Tasks multipli dello stesso tipo: ESEMPIO > :ElevatorControl ANALYSIS MODEL

Internal Task Structuring criteria Tasks multipli dello stesso tipo: ESEMPIO > :ElevatorControl

Task Priority criteria - -Considerano la priorità in fase di Task Structuring, distinguendo in high e low priority. - -Questo aspetto viene spesso affrontato più tardi nel ciclo di sviluppo. Task Priority criteria - -Qui : solo identificare i tasks time-critical e non-time-critical.

Task Priority criteria - -Servono in molti sistemi real-time. - -Caso tipico: I/O task asincrono interrupt-driven, dove c’è rischio di perdere un interrupt e questo non deve accadere. Time-Critical Tasks - -É necessario che girino ad un alto livello di priorità ( high priority ).

Task Priority criteria - -Un task non-time-critical può girare a priorità bassa ( low priority ) sfruttando i cicli di CPU liberi, eseguendo intense attività computazionali. - -Caso tipico: task che legge dei dati da un sensore, ne calcola il significato e li rende disponibili. Non-Time-Critical Tasks

Task Clustering criteria - -Capire se alcuni task della prima fase di Task Structuring possono essere raggruppati per diminuirne il numero e ridurre la complessità del design model. - -Individuare i task candidati e raggrupparli in phisical tasks. I task riuniti non possono più essere esuguiti concorrentemente. Task Clustering criteria

- -Alcuni tasks candidati possono essere attivati dallo stesso evento, ad es. un timer event. - -Caso tipico: tasks che vengono attivati periodicamente. Temporal Clustering - -Se i tasks sono indipendenti, possono essere raggruppati e deve essere specificato, dal designer, un ordine di esecuzione.

Temporal Clustering: ESEMPIO > :Engine 4: read (out BrakeInput) > :DigitalClock > :AutoSensors 1: TimerEvent Task Clustering criteria > :Brake 2: read (out EngineInput) 3: EngineOn 3A: EngineOff 5: BrakePressed 5A: BrakeReleased

Task Clustering criteria No: - -Se un task candidato è piú time-critical del secondo. - -Se i due task possono essere eseguiti su due processori diversi. Utilizzo di Temporal Clustering Si: - -Se i task hanno funzionalitá simili e uguale importanza a livello di scheduling. - -Se i due task hanno uguali periodi di attivazione o comunque multipli tra loro (es. 50/100 msec).

Task Clustering criteria - -Alcuni tasks candidati, per esigenze applicative, sono eseguiti in ordine sequenziale. - -Caso tipico: il primo task è triggerato da un evento asincrono o periodico, il secondo viene eseguito di seguito. Sequential Clustering

Sequential Clustering: ESEMPIO > :Display 3: ReportOutput > :ReportGenerator > :DisplayInterface 2: Report > :DigitalClock 1: TimerEvent Task Clustering criteria

Sequential Clustering: ESEMPIO > :Display 3: ReportOutput > :DigitalClock > :ReportGenerator&Display 1: TimerEvent Task Clustering criteria NB: 2  messaggio interno

Task Clustering criteria - -Se un task candidato manda messaggi ad un oggetto che non è un task allora deve essere l’ultimo della sequenza. Utilizzo di Sequential Clustering -Se un task con prioritá minore ne segue uno time-critilal la sequenza non deve continuare. -Se un task candidato riceve messaggi anche da altre fonti oltre ai tasks in sequenza deve essere mantenuto separato.