Task Structuring
COMET
TASK STRUCTURING
- Prima parte -
- Introduzione
Indice
- Cosa si intende per task
- Task Stucturing: obiettivi
- Task Stucturing Categories (first 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 stage)
- Task Clustering criteria
- Temporal Clustering
- Sequential Clustering
- Control Clustering
- Clustering mutuamente esclusivo
- Task Inversion criteria
Cosa si intende per task
Cos’è un task
- Un oggetto attivo con un proprio thread
di controllo.
- Dall’ Analysis Model object-oriented si
sviluppa una task architecture :
- tasks concorrenti
- classi passive
Task Structuring: obiettivi
Obiettivi
Separation of concerns :
Un task usa information hiding per aspetti
riguardanti la concorrenza (timing, controllo,
sequenzialitá, comunicazione).
Una classe per aspetti strutturali.
- Semplificare e rendere più chiaro il design
senza introdurre inutilmente troppi tasks
Task Structuring: obbiettivi
Nel ciclo di vita del software COMET
2
Analysis
Modeling
5
Design
Modeling
6
Incremental
Software
Construction
11
10
7
Task Structuring Categories
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.
I/O Task Structuring criteria
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
Task interfaccia per I/O device asincroni
- 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
I/O Task Structuring criteria
Task interfaccia per I/O device asincroni: ESEMPIO
<<asynchronous input
device interface>>
:CruiseControlLever
Interface
:CruiseControl
2: CruiseControl Request
1: CruiseControl interrupt
(CruiseControlInput)
<<asynchronous input
device>>
:CruiseControlLever
I/O Task Structuring criteria
Task interfaccia per I/O device periodici
- É 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.
I/O Task Structuring criteria
Task interfaccia per I/O device periodici: ESEMPIO
<<periodic input device
interface>>
0: TimerEvent
<<external timer>>
:DigitalClock
:EngineInterface
1: read
(out EngineInput)
2: engineOn
<<passive input
device>>
:Engine
2A: engineOff
I/O Task Structuring criteria
Task interfaccia per I/O device passivi
- 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.
I/O Task Structuring criteria
Task interfaccia per I/O device passivi: ESEMPIO
<<passive output device
interface>>
:SensorStatisticDisplay
Interface
<<non-time-critical>>
:SensorStatistics
2: Temperature&Pressure
Statistics
Algorithm
3: SensorStatistics
1: read
(out sensorData)
<<passive output
device>>
:Display
<<entity>>
:SensorData
Repository
I/O Task Structuring criteria
Resource Monitor Task
- É 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.
I/O Task Structuring criteria
Resource Monitor Task: ESEMPIO
:anElevatorControl
1: FloorLamp
Command
<<resource monitor>>
:FloorLamp
<<passive output
device>>
Inteface
:FloorLamp
3,4: FloorLamp
Output
:another
ElevatorControl
2: FloorLamp
Command
Internal Task Structuring criteria
Internal Task Structuring criteria
- Determinare i tasks interni, non di I/O
- Quando si attiva un particolare task interno
Internal Task Structuring criteria
Tasks periodici
- Attività da eseguire periodicamente.
- 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.
Internal Task Structuring criteria
Tasks periodici: ESEMPIO
<<periodic>>
:DistanceTimer
2: Calculate
1: TimerEvent <<external timer>>
:DigitalClock
3: read (out
ShaftRotationCountValue)
<<entity>>
:ShaftRotation
Count
<<entity>>
:Distance
<<entity>>
4: read (out
CalibartionConstantValue)
:Calibartion
Constant
Internal Task Structuring criteria
Tasks asincroni
- 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.
Internal Task Structuring criteria
Tasks asincroni: ESEMPIO
<<output device
interface>>
<<control>>
:CruiseControl
1: Cruise
Control
Command
4: Throttle
Value
<<entity>>
3: read (out
CurrentSpeedValue)
<<asynchronous
algorithm>>
:Cruiser
5: Throttle
Position
:ThrottleInterface
:CurrentSpeed
<<entity>>
2: read (out
DesideredSpeedValue)
:Desired
Speed
Internal Task Structuring criteria
Control Tasks
- Un task che esegue uno statechart sequenzialmente.
- Negli statecharts non è permessa la concorrenza.
Internal Task Structuring criteria
Control Tasks: ESEMPIO
1: CruiseControl
Request
2: CruiseControl
Command
<<control>>
:CruiseControl
Internal Task Structuring criteria
User Interface Tasks
- 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.
Internal Task Structuring criteria
User Interface Tasks: ESEMPIO
1: OperatorCommand
<<user interface>>
:OperatorInterface
:Operator
3: DisplayData
2: read (out
SensorData)
<<entity>>
: SensorData
Repository
Internal Task Structuring criteria
User Interface Tasks (multipli)
- In UNIX un utente può comunque decidere di
eseguire diverse attività concorrentemente, servendosi dei processi in background.
- In Windows otteniamo lo stesso risultato
operando su più finestre.
- Più tasks di interfaccia utente.
Internal Task Structuring criteria
User Interface Tasks: ESEMPIO 2
1: Factory
StatusQuery
<<User Interface>>
2: read (out
FactoryStatus)
<<entity>>
:FactoryStatus
Repository
:FactoryStatus
Window
3: Status
DisplayData
:Operator
1A: Allarm
Query
3A: Allarm
DisplayData
<<User Interface>>
:FactoryAlarm
Window
2A: read (out
AllarmStatus)
<<entity>>
:FactoryAllarm
Repository
Internal Task Structuring criteria
Tasks multipli dello stesso tipo
- É 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.
Internal Task Structuring criteria
Tasks multipli dello stesso tipo: ESEMPIO
<<control>>
:ElevatorControl
Task Priority criteria
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.
- Qui : solo identificare i tasks time-critical e
non-time-critical.
Task Priority criteria
Time-Critical Tasks
- Servono in molti sistemi real-time.
- É necessario che girino ad un alto livello di priorità
( high priority ).
- Caso tipico: I/O task asincrono interrupt-driven,
dove c’è rischio di perdere un interrupt e questo
non deve accadere.
Task Priority criteria
Non-Time-Critical Tasks
- 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.
Task Clustering criteria
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
Temporal Clustering
- Alcuni tasks candidati possono essere attivati dallo
stesso evento, ad es. un timer event.
- Se i tasks sono indipendenti, possono essere
raggruppati e deve essere specificato, dal
designer, un ordine di esecuzione.
- Caso tipico: tasks che vengono attivati
periodicamente.
Task Clustering criteria
Temporal Clustering: ESEMPIO
<<passive input
device>>
:Engine
<<passive input
device>>
:Brake
<<external timer>>
2: read (out
EngineInput)
4: read (out
BrakeInput)
:DigitalClock
1: TimerEvent
<<temporal clustering>>
:AutoSensors
3: EngineOn 3A: EngineOff
5: BrakePressed 5A: BrakeReleased
Task Clustering criteria
Utilizzo di Temporal Clustering
No:
- Se un task candidato è piú time-critical del secondo.
- Se i due task possono essere eseguiti su due
processori diversi.
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
Sequential Clustering
- 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.
Task Clustering criteria
Sequential Clustering: ESEMPIO
<<passive output device
interface>>
<<periodic>>
:DisplayInterface
:ReportGenerator
2: Report
3: ReportOutput
1: TimerEvent
<<passive output
device>>
<<external timer>>
:Display
:DigitalClock
Task Clustering criteria
Sequential Clustering: ESEMPIO
<<sequential clustering>>
<<external timer>>
:ReportGenerator&Display
:DigitalClock
1: TimerEvent
3: ReportOutput
<<passive output
device>>
:Display
NB: 2  messaggio interno
Task Clustering criteria
Utilizzo di Sequential Clustering
- Se un task candidato manda messaggi ad un
oggetto che non è un task allora deve essere
l’ultimo della sequenza.
- Se un task candidato riceve messaggi anche da
altre fonti oltre ai tasks in sequenza deve essere
mantenuto separato.
- Se un task con prioritá minore ne segue uno
time-critilal la sequenza non deve continuare.