Task Structuring COMET TASK STRUCTURING - Prima parte -

Task Structuring

COMETCOMET

TASK TASK STRUCTURINGSTRUCTURING

- Prima parte -- Prima parte -

Indice- IntroduzioneIntroduzione

- Cosa si intende per task- Task Stucturing: obiettivi

- Task Stucturing Categories (first Task Stucturing Categories (first stage)stage) - I/O Task Structuring criteria

- Task interfaccia per I/O device asincroni

- Task interfaccia per I/O device periodici

- Task interfaccia per I/O device passivi

- Resource Monitor Task

- Internal Task Structuring criteria- Tasks Periodici

- Tasks Asincroni

- Control Tasks

- User Interface Tasks

Indice

- Task Priority criteria- Time-Citical Tasks

- Non-Time-Critical Tasks

-Task Stucturing Categories (second Task Stucturing Categories (second stage)stage) - Task Clustering criteria

- Temporal 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 taskCos’è un task

Task Structuring: obiettivi

- Semplificare e rendere più chiaro il designsenza introdurre inutilmente troppi tasks

ObiettiviObiettivi

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 COMETNel ciclo di vita del software COMET

Analysis

Modeling

2

Task Structuring: obbiettivi

Design

Modeling

Incremental Software

Construction

5

6

7

1011

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 CategoriesTask 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 criteriaI/O Task Structuring criteria


Attività iniziali:Attività iniziali:

- Analizzare le caratteristiche degli I/O devices

- Analizzare la natura dei dati


Caratteristiche degli I/O deviceCaratteristiche 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


Natura dei datiNatura 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


- 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 asincroniTask interfaccia per I/O device asincroni


Task interfaccia per I/O device asincroni: ESEMPIOTask interfaccia per I/O device asincroni: ESEMPIO

<<asynchronous input device>>

:CruiseControlLever

1: CruiseControl interrupt

(CruiseControlInput)

:CruiseControl

<<asynchronous input device interface>>

:CruiseControlLever Interface

2: CruiseControl Request


- É 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 periodiciTask interfaccia per I/O device periodici


Task interfaccia per I/O device periodici: ESEMPIOTask interfaccia per I/O device periodici: ESEMPIO

<<passive input device>>

:Engine

1: read

(out EngineInput)

<<external timer>>

:DigitalClock

<<periodic input device interface>>

:EngineInterface

0: TimerEvent

2: engineOn

2A: engineOff


- 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 passiviTask interfaccia per I/O device passivi


Task interfaccia per I/O device passivi: ESEMPIOTask interfaccia per I/O device passivi: ESEMPIO

<<passive output device>>

:Display

3: SensorStatistics

<<non-time-critical>>

:SensorStatistics

Algorithm

<<passive output device interface>>

:SensorStatisticDisplay Interface 2: Temperature&Pressure

Statistics

<<entity>>

:SensorData

Repository

1: read

(out sensorData)


- É 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 TaskResource Monitor Task


Resource Monitor Task: ESEMPIOResource Monitor Task: ESEMPIO


:FloorLamp

:anElevatorControl

3,4: FloorLamp Output

<<resource monitor>>

: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 Internal Task Structuring criteriacriteria


- 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 periodiciTasks periodici

- Attività da eseguire periodicamente.


Tasks periodici: ESEMPIOTasks periodici: ESEMPIO

<<entity>>

:Distance

3: read (out ShaftRotationCountValue)

<<external timer>>

:DigitalClock

<<periodic>>

:DistanceTimer

1: TimerEvent

2: Calculate<<entity>>

:ShaftRotationCount

<<entity>>

:CalibartionConstant

4: read (out CalibartionConstantValue)


- 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 asincroniTasks asincroni


Tasks asincroni: ESEMPIOTasks asincroni: ESEMPIO

<<asynchronous algorithm>>

:Cruiser

3: read (out CurrentSpeedValue)

<<output device interface>>

:ThrottleInterface

<<control>>

:CruiseControl 4: Throttle Value

1: Cruise Control

Command

<<entity>>

:CurrentSpeed

<<entity>>

:Desired Speed

2: read (out DesideredSpeedValue)

5: Throttle Position


- Un task che esegue uno statechart sequenzial-mente.

Control TasksControl Tasks

- Negli statecharts non è permessa la concorrenza.


Control Tasks: ESEMPIOControl Tasks: ESEMPIO

1: CruiseControl Request

<<control>>

:CruiseControl

2: CruiseControl Command


- 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 TasksUser Interface Tasks


User Interface Tasks: ESEMPIOUser Interface Tasks: ESEMPIO

1: OperatorCommand

<<user interface>>

:OperatorInterface

2: read (out SensorData)

:Operator

<<entity>>

: SensorData Repository

3: DisplayData


- 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)User Interface Tasks (multipli)


User Interface Tasks: ESEMPIO 2User Interface Tasks: ESEMPIO 2

1: Factory StatusQuery <<User Interface>>

:FactoryStatus Window

2: read (out FactoryStatus)

:Operator

<<entity>>

:FactoryStatus Repository

3: Status DisplayData

<<User Interface>>

:FactoryAlarm Window

2A: read (out AllarmStatus) <<entity>>

:FactoryAllarm Repository

1A: Allarm Query

3A: Allarm DisplayData


- É 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 tipoTasks multipli dello stesso tipo


Tasks multipli dello stesso tipo: ESEMPIOTasks multipli dello stesso tipo: ESEMPIO

<<control>>

: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 criteriaTask Priority criteria

- Qui : solo identificare i tasks time-critical e non-time-critical.


- 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 TasksTime-Critical Tasks

- É necessario che girino ad un alto livello di priorità ( high priority ).


- 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 TasksNon-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 criteriaTask Clustering criteria


- Alcuni tasks candidati possono essere attivati dallo stesso evento, ad es. un timer event.

- Caso tipico: tasks che vengono attivati periodicamente.

Temporal ClusteringTemporal Clustering

- Se i tasks sono indipendenti, possono essere raggruppati e deve essere specificato, dal designer, un ordine di esecuzione.

Temporal Clustering: ESEMPIOTemporal Clustering: ESEMPIO<<passive input

device>>

:Engine

4: read (out BrakeInput)

<<external timer>>

:DigitalClock

<<temporal clustering>>

:AutoSensors

1: TimerEvent


<<passive input device>>

:Brake

2: read (out EngineInput)

3: EngineOn 3A: EngineOff

5: BrakePressed 5A: BrakeReleased


No:- Se un task candidato è piú time-critical del

secondo.- Se i due task possono essere eseguiti su due

processori diversi.

Utilizzo di Temporal ClusteringUtilizzo 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).


- 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 ClusteringSequential Clustering

Sequential Clustering: ESEMPIOSequential Clustering: ESEMPIO


:Display

3: ReportOutput

<<periodic>>

:ReportGenerator

<<passive output device interface>>

:DisplayInterface

2: Report

<<external timer>>

:DigitalClock

1: TimerEvent


Sequential Clustering: ESEMPIOSequential Clustering: ESEMPIO


:Display

3: ReportOutput

<<external timer>>

:DigitalClock

<<sequential clustering>>

:ReportGenerator&Display

1: TimerEvent


NB: 2 messaggio interno


- Se un task candidato manda messaggi ad un oggetto che non è un task allora deve essere l’ultimo della sequenza.

Utilizzo di Sequential ClusteringUtilizzo 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.

Task Structuring COMET TASK STRUCTURING - Prima parte -

Documents

Transcript of Task Structuring COMET TASK STRUCTURING - Prima parte -