D

R
A
F
T
Introduzione alle tecniche di
analisi di modelli a reti di code
Gianfranco Balbo
Dipartimento di Informatica
Universit` a degli Studi di Torino
c Copyright Gianfranco Balbo 2007
D
R
A
F
T
2
D
R
A
F
T
Capitolo 1
Introduzione: Sistemi,
Modelli e Formalismi
Comprendere eettivamente il comportamento di un sistema reale `e sempre
dicile a causa della complessit`a della sua organizzazione e delle interazioni tra
le sue componenti.
La progettazione e la gestione di sistemi reali spesso richiede che vengano in-
dividuate le relazioni tra le scelte organizzative ed i risultati ottenuti in maniera
da poter decidere quali variazioni apportare allarchitettura del sistema ed al-
lambiente operativo in maniera da ottenere delle prestazioni migliori.
In tutti questi casi, ragionare sul comportamento di un sistema diventa pi` u
adabile se sono disponibili delle descrizioni appropriate del sistema stesso che
aiutino a chiarire le relazioni tra le sue componenti. Il modo migliore per ot-
tenere queste descrizioni dettagliate `e quello di costruire un modello del sistema
che evidenzi le particolarit`a pi` u importanti della sua organizzazione e che for-
nisca dei modi per quanticare le sue propriet`a, tralasciando tutti quei dettagli
che sono rilevanti per la realizzazione sica reale, ma che hanno importanza
marginale rispetto allobiettivo dello studio.
I modelli possono essere sviluppati per molte ragioni che includono la neces-
sit`a di comprendere eettivamente il comportamento del sistema, di migliorarne
le prestazioni e di prendere delle decisioni in fase di progettazione o di esercizio.
In ogni caso i modelli sono utili per spiegare perch`e e come certe caratteristiche
di un sistema si presentino eettivamente. Infatti, il modello aiuta a sviluppare
una comprensione profonda delle modalit` a di funzionamento del sistema e a
capire leetto che certi paramentri possono avere sui risultati.
La formulazione matematica di un modello fornisce dei metodi per ragionare
in maniera formale circa il comportamento di un sistema in un modo che `e sicuro
(anche se dicile in certi casi) e passibile di automazione. In questo modo il
modello non fornisce solamente una descrizione qualitativa del funzionamento
del sistema reale, ma introduce degli aspetti quantitativi che sono determinati
per compiere delle scelte oculate.
3
D
R
A
F
T
4 CAPITOLO 1. INTRODUZIONE
La possibilit` a di calcolare i risultati derivanti dallanalisi di un modello
`e quindi un elemento chiave per chiudere un cerchio che incomincia con la-
strazione degli aspetti pi` u importanti del sistema, eseguita durante la fase di
costruzione del modello, e che termina con linterpretazione dei risultati forniti
dal modello e riessi sul sistema reale.
1.1 Sistemi dinamici ad eventi discreti
Il concetto di sistema `e molto generale e noi non tenteremo di denirlo con
precisione. Informalmente parlando, un sistema `e spesso descritto come una
collezione di parti (od oggetti) identicabili, dette componenti, che interagi-
scono tra di loro dando luogo a delle relazioni. Queste componenti possono
corrispondere a delle entit` a indivisibili (dal punto di vista del comportamento
del sistema) oppure possono rappresentare dei sottosistemi aventi la medesima
natura dei sistemi stessi. Gli oggetti sono caratterizzati dai loro attributi che
sono in parte ssi ed in parte variabili. Il valore assunto da un attributo va-
riabile contribuisce (in alcuni casi in maniera sostanziale) alla denizione dello
stato delloggetto (stato locale). Mettendo insieme gli stati di tutti gli oggetti
che compongono il sistema otteniamo uno stato del sistema (stato globale). Lo
stato del sistema `e quindi denito dalla situazione istantanea di tutte le sue
componenti. Le relazioni tra gli oggetti rappresentano i vincoli che guidano
i cambiamenti di stato. Astraendo dallevento particolare che determina un
cambiamento di stato, noi chiamiamo transizioni questi schemi di cambiamento
di stato. Possiamo dire che le variabili di stato sono degli elementi passivi del
modello, mentre le transizioni sono attive.
I Sistemi Dinamici ad Eventi Discreti (DEDS - Discrete Event Dynamic
Systems) sono sistemi in cui lo spazio degli stati `e discreto (cio`e hanno un numero
di stati contabile, anche se potenzialmente innito) e la cui evoluzione non `e
legata direttamente al passaggio del tempo, quanto piuttosto alloccorrenza di
eventi.
Molti sistemi reali possono essere considerati come dei DEDS non a causa di
loro caratteristiche intrinseche, ma per via degli aspetti del loro comportamento
che noi vogliamo evidenziare. Per esempio, un lago articiale che contiene (natu-
ralmente) una quantit`a di acqua variabile con continuit` a, pu` o essere considerato
come un DEDS se noi restringiamo la nostra attenzione al fatto che il livello
dellacqua ecceda o meno una determinata soglia di guardia. In questo caso il
lago pu` o trovarsi solamente in uno di due stati (sicuro o pericoloso) e gli eventi
che possono determinare il cambiamento di stato possono essere identicati con
il vericarsi di temporali e con le azioni di apertura delle paratie della diga.
Questo esempio evidenzia il fatto che non tutte le componenti devono necessa-
riamente essere incluse nella descrizione del sistema (e quindi nella denizione
del modello che lo rappresenta), ma solo quelle che sono rilevanti allo scopo dello
studio permettendo cos` di osservare che un modello corrisponde sempre ad una
rappresentazione astratta (ad una astrazione) del sistema oggetto di studio.
D
R
A
F
T
1.1. SISTEMI DINAMICI AD EVENTI DISCRETI 5
Noi parleremeo quindi di DEDS riferendoci sia a sistemi reali che rispondono
eettivamente ai requisiti che li caratterizzano, sia a sistemi che possono essere
rappresentati in questo modo limitatamente agli scopi dello studio per cui sono
presi in considerazione.
Le caratteristiche dei DEDS permettono di individuarli in ambiti applicativi
anche estremamente diversi.
Nei Sistemi Flessibili di Lavorazione, lo stato del sistema pu`o essere rap-
presentato dal numero di pezzi da lavorare (semilavorati) fermi davanti a
diverse macchine utensili e gli eventi possono corrispondere alla ne delle
lavorazioni eseguite dalle diverse macchine utensili stesse, alla produzione
di pezzi niti o allarrivo di nuove parti da lavorare.
In ambito informatico, lo stato di un sistema pu`o corrispondere al numero
di processi in corso di esecuzione o in attesa del completamento di certe
operazioni di I/O. Esempi di eventi sono, in questo caso, la ne di un
quanto di CPU o loccorrenza degli interrupt provenienti dalle unit`a di
I/O e delle trap conseguenti allesecuzione delle system call.
Nelle reti di telecomunicazione, lo stato pu`o corrispondere al numero di
pacchetti memorizzati nei diversi buer di un sistema e gli eventi relativi
allinvio di messaggi o alle azioni specicate dai protocolli.
Nel caso di traco stradale, lo stato del sistema pu`o corrispondere al
numero di automobili ferme in un posteggio o in attesa di attraversare
un incrocio o ancora in viaggio su un certo tratto di strada, mentre gli
eventi potranno essere degli arrivi e delle partenze di automobili o anche
corrispondere al cambiamento del colore dei semafori.
Nel caso di sistemi biologici, lo stato pu`o essere rappresentato dal nu-
mero di molecole di diverse specie presenti in una cellula e gli eventi dal
vericarsi di reazioni chimiche che le trasformano.
In tutti questi casi, indipendentemente dal signicato reale delle diverse com-
ponenti del sistema, capire il loro comportamento `e normalmente piuttosto dif-
cile a causa della complessit` a intrinseca del problema (per esempio, il numero
di parti e di macchine utensili in un sistema essibile di lavorazione pu`o dare
origine a milioni di stati che sono dicili da immaginare e da tenere sotto con-
trollo anche solo mentalmente), delle interferenze anche subdole che si possono
determinare tra le componenti del sistema (per esempio, nei sistemi di traco,
la presenza di strettoie - colli di bottiglia - temporaneamente nascoste da altri
punti di congestione che generano degli enormi intasamenti, possono vanicare
i miglioramenti attesi a seguito di interventi anche costosi volti a rimuovere i
punti di congestione primari) e di relazioni controintuitive che legano i funzio-
namenti di certe componenti (si pensi per esempio, nel caso di un sistema di
calcolo, al fenomeno del thrashing che insorge quando si cerca di aumentare
lutilizzazione della CPU aumentando il livello di multiprogrammazione e si ot-
tiene invece leetto opposto a causa di un incremento pi` u che proporzionale
D
R
A
F
T
6 CAPITOLO 1. INTRODUZIONE
della paginazionedel sistema). In tutti questi casi, ragionare sul comporta-
mento del sistema reale `e dicile se non si dispone di strumenti appropriati
rappresentati proprio dalla presenza di modelli adeguati. Possiamo allora dire
che i modelli (formali) sono la base per sviluppare una comprensione appro-
fondita delle modalit`a di funzionamento di sistemi esistenti complessi e per la
proposta di soluzioni innovative ecienti ed ecaci.
1.2 Modellazione
Un sistema che evolve nel tempo `e descritto dalla storia dei suoi stati (o succes-
sione cronologica degli stati). Questa storia rappresenta un cammino attraverso
lo spazio di tutti i possibili stati del sistema.
Un modello di un sistema `e una rappresentazione del sistema in esame capace
di riprodurre con precisione suciente gli aspetti salienti del suo comportamen-
to che sono rilevanti al ne dello studio. Segue che ogni stato del modello deve
corrispondere ad uno stato del sistema (e viceversa) e che levoluzione del mod-
ello deve fornire una rappresentazione precisa ed adabile della storia degli stati
del sistema.
Il fatto che lo scopo di un modello sia quello di rappresentare solamente
certi aspetti della realt`a del sistema oggetto di studio, implica che il modello
rappresenti sempre una semplicazione (o astrazione) della realt`a a cui esso si
riferisce. Questo vuole anche dire che un modello di uno stesso sistema risulter`a
adeguato in generale solo per la conduzione di determinati studi. In altri contesti
esso potr` a risultare troppo semplicato o anche troppo dettagliato. In ogni
caso, `e importante tenere presente che il modello, in quanto rappresentazione
simbolica del sistema a cui esso si riferisce, deve sempre rispondere a requisiti
di adeguatezza per il tipo di studio che si vuole condurre.
Si pu` o dire allora che la modellazione rappresenti larte della costruzione di
modelli di sistemi naturali ed articiali. Arte perche, se `e vero che la model-
lazione `e basata su tecniche matematiche e statistiche ben denite, alcuni suoi
aspetti fondamentali, quali la denizione del modello del fenomeno reale o la
scelta del livello di astrazione, richiedono lintuito e lesperienza dellanalista che
compie lo studio.
Nella descrizione di un modello `e importante distinguere lesistenza di tre
tipi di variabili
Le variabili di ingresso (spesso chiamate parametri) sono quelle che pos-
sono essere manipolate dallesterno per studiare la dinamica del modello,
cio`e la sua risposta al variare di questi parametri.
Le variabili di stato sono quelle che descrivono lo stato del sistema o di
una sua componente.
Le variabili di uscita (spesso chiamate indici di prestazione) sono variabili
dipendenti generate dallinterazione tra le variabili di ingresso (parte delle
variabili indipendenti) e le variabili di stato.
D
R
A
F
T
1.2. MODELLAZIONE 7
La denizione di un modello si conclude identicando le caratteristiche fun-
zionali che descrivono linterazione tra le variabili. Queste sono le identit`a
(denizioni) e le caratteristiche operative rappresentate da ipotesi (in generale
delle equazioni matematiche) che pongono in relazione le variabili di uscita con
quelle di ingresso.
Molti dei fenomeni che noi analizzeremo hanno natura completamente de-
terministica. Nel funzionamento di un calcolatore, per esempio, nulla (o quasi)
avviene per caso. A livello microscopico `e sempre possibile individuare sequenze
di azioni che sono completamente deterministiche; da un punto di vista macro-
scopico per` o il funzionamento di un calcolatore `e condizionato da un cos` gran
numero di variabili che risulta impossibile tenerne conto in maniera esplicita.
Molti fenomeni vengono allora considerati aleatori, anche quando aleatori non
sono, solamente perch`e sono il risultato della interazione di un gran numero di
variabili che d` a luogo ad un campo di possibilit`a molto vasto. In questi casi
si preferisce (o si `e costretti) a descrivere questi fenomeni con delle funzioni
probabilistiche che deniscono la frequenza con cui si vericano determinati
eventi.
In questi casi i modelli discreti deterministici diventano modelli discreti
stocastici in cui la storia degli stati diventa una realizzazione della variabile
aleatoria rappresentante il comportamento del sistema.
1.2.1 Modelli analitici e modelli di simulazione
Dato il modello matematico di un sistema, `e talora possibile ottenere infor-
mazioni circa il suo comportamento per via analitica. Questo corrisponde al
fatto di essere in grado di ottenere relazioni funzionali tra le variabili di ingresso
e quelle di uscita. I vantaggi oerti da questa capacit`a sono rappresentati dalla
possibilit`a di stabilire lesistenza di relazioni di causa eetto tra ingressi ed usci-
te, di ottenere la soluzione del modello con costi limitati e di poter utilizzare il
modello in maniera semplice. Oltre allimmediatezza del calcolo della soluzione,
modelli di questo tipo hanno il vantaggio di essere suscettibili di analisi ra-
nate che forniscono molte informazioni sul comportamento dei sistemi che essi
rappresentano, quali, ad esempio, la sensibilit`a alle variazioni dei parametri di
ingresso.
Purtroppo questi aspetti positivi hanno spesso una portata limitata a causa
del fatto che le classi di modelli per cui `e possibile calcolare la soluzione analitica
sono relativamente poche e ristrette.
In alcuni casi, pur essendo in grado di scrivere delle relazioni funzionali tra
ingresso ed uscita in forma implicita, non `e possibile esprimere queste stesse
relazioni in forma esplicita semplice. In questi casi il calcolo della soluzione
pu` o avvenire solo per via numerica (esempio tipico: soluzione di un sistema
di equazioni dierenziali o lineari) e quindi per mezzo delluso di algoritmi che
possono essere computazionalmente convenienti, ma che non permettono uno
studio diretto delle propriet`a delle soluzioni trovate. In particolare, le analisi
di sensitivit`a di questi modelli possono essere condotte solo attraverso la ripe-
tizione del calcolo della soluzione per famiglie di valori dei parametri di ingresso.
D
R
A
F
T
8 CAPITOLO 1. INTRODUZIONE
Nonostante i progressi tecnologici fatti dai calcolatori delle ultime generazioni,
esistono molti casi reali in cui i metodi numerici disponibili richiedono capacit`a
di calcolo eccessive e rendendo questi modelli troppo costosi e quindi di rilevanza
pratica limitata.
Per rendere certi modelli risolvibili analiticamente ed, in certi casi, anche
solo per rendere possibile la scrittura di relazioni tra uscita ed ingresso, lanali-
sta si trova nella necessit` a di introdurre semplicazioni molto drastiche che, per
certi studi, non sono assolutamente accettabili. In tutti i casi in cui modelli re-
alistici del sistema oggetto di studio richiedono livelli di dettaglio tali da rendere
il problema non pi` u trattabile analiticamente o numericamente, lunica risorsa
che rimane allanalista `e quella di riprodurre la storia degli stati del sistema va-
lutando le caratteristiche di comportamento per mezzo di misure condotte sul
modello stesso. Questa tecnica `e quella comunemente nota come tecnica di sim-
ulazione con la quale levoluzione di un sistema `e riprodotta dal comportamento
dinamico di un modello ottenuto per mezzo di un elaboratore digitale.
I modelli utili per condurre esperimenti con la tecnica della simulazione sono
chiamati modelli di simulazione. I modelli matematici costruiti per scopi di sim-
ulazione sono spesso di natura diversa da quelli utilizzati per ottenere soluzioni
analitiche dei problemi, tuttavia questa dierenza non rappresenta una con-
dizione necessaria che deve essere sempre vericata. La dierenza pi` u impor-
tante `e che un modello di simulazione `e normalmente libero da quelle ipotesi
limitative che sono invece necessarie per rendere possibile lanalisi matematica
dei modelli analitici.
I modelli di simulazione possono essere classicati mettendoli in corrispon-
denza con i modelli matematici di cui forniscono la soluzione. Avremo quindi
modelli continui, discreti, deterministici, stocastici, ecc. ecc. Noi prenderemo
esclusivamente in considerazione i modelli discreti in cui i cambiamenti di sta-
to sono predominantemente discontinui ed avvengono ad intervalli di tempo di
lunghezza arbitraria e quindi quei modelli che sono naturalmente adatti per
rappresentare il comportamento dei DEDS. La loro analisi sar`a quindi condot-
ta con la tecnnica simulativa che, applicata a questi modelli discreti, `e spesso
chiamata simulazione ad eventi discreti. Come vedremo meglio in seguito, nel
contesto simulativo il vericarsi di un evento assume una valenza pi` u generale
perche, oltre a determinare una variazione del valore di una variabile di stato,
pu`o anche condurre alla creazione/distruzione di una componente del sistema,
o allattivazione/disattivazione di una funzione.
I vantaggi di generalit` a oerti dai modelli di simulazione sono purtroppo
controbilanciati da due aspetti negativi di questa tecnica
I risultati (le misure) ottenuti non permettono di stabilire delle relazioni
funzionali di causa-eetto tra uscita ed ingresso.
Gli esperimenti di simulazione richiedono normalmente tempi di calcolo
molto lunghi (sono quindi costosi).
Questi svantaggi devono spingere un analista a dare precedenza alluso di
modelli analitici. La tendenza corretta dovrebbe sempre essere quella di ana-
D
R
A
F
T
1.3. MODELLI GERARCHICI E MODULARIT
`
A 9
lizzare il problema reale in modo da scoprire e comprendere quali aspetti della
realt` a sono essenziali e quali sono marginali rispetto a quello che `e lobiettivo
dellanalisi. I modelli di simulazione dovrebbero quindi essere adottati solamente
quando esperimenti (analisi) precedenti abbiano dimostrato linadeguatezza dei
modelli analitici.
Lesperienza pratica insegna che spesso molti dettagli che rendono un mo-
dello non trattabile analiticamente non sono cos` importanti come appaiono a
prima vista e che, in ogni caso, la loro presenza inuisce solo marginalmente sulle
caratteristiche generali di comportamento del sistema. Lo sforzo che lanalista
compie per capire in profondit` a le modalit`a di funzionamento del sistema oggetto
di studio e per decidere (in conseguenza) quali semplicazioni sono apportabili
al modello, fornisce spesso delle indicazioni preliminari non trascurabili circa il
comportamento reale del sistema.
Evidentemente esistono numerosi casi in cui la simulazione discreta rimane
lunica metodologia di analisi disponibile. In questi casi i costi (svantaggi)
della simulazione rappresentano il prezzo da pagare per lo studio del comporta-
mento del sistema che altrimenti sarebbe impossibile.
1.3 Modelli gerarchici e modularit`a
Abbiamo osservato in precedenza come il livello di dettaglio di un determinato
modello dipenda dal tipo di studio del funzionamento del sistema reale che
lanalista intende condurre. Esistono evidentemente dei casi in cui non si pu`o
fare a meno di introdurre certi dettagli nel modello. In queste situazioni il
modello diventa dicile da trattare e non solo pu`o perdere la caratteristica di
analiticit`a, ma la sua stessa simulazione pu` o diventare troppo costosa. Una
tecnica per aggirare questa dicolt`a pu`o essere quella di studiare il problema
per mezzo di unanalisi gerarchica del modello. Lidea che sta alla base di
questo approccio `e che in sistemi molto complessi, in cui entrano in gioco un
gran numero di variabili, `e molto spesso possibile individuare dei sottosistemi
(aggregare gruppi di variabili) tali che :
esiste un grado di interazione molto alto tra le componenti del sottosistema
le interazioni tra i sottosistemi sono relativamente deboli.
In questi casi si pu`o pensare che, mediamente, il sottosistema, sollecitato da
uninterazione con il suo ambiente esterno riesca a raggiungere un funzionamen-
to di equilibrio prima che avvenga linterazione successiva. Questa propriet`a
denita in maniera cos` vaga corrisponde in realt` a a caratteristiche ben precise
del modello matematico del sistema. Queste propriet`a matematiche verranno
riprese pi` u tardi in queste note. Per il momento ci basti osservare che sistemi di
questo tipo possono essere rappresentati con modelli in cui i sottosistemi ven-
gono considerati come scatole nere le cui caratteristiche sono il risultato di
uno studio condotto preliminarmente considerando il funzionamento di ognuna
di esse in isolamento, cio`e staccate dal resto del sistema.
D
R
A
F
T
10 CAPITOLO 1. INTRODUZIONE
secondi
millisecondi
microsecondi
Figura 1.1: Rappresentazione schematica della frequenza di interazione tra
componenti di un sistema
Nel caso dei sistemi di calcolo moderni, lindividuazione dei sottosistemi
`e spesso abbastanza facile a causa dello stile di programmazione strutturata
comunemente adottata e delle metodologie moderne di implementazione dei
sistemi software avanzati che si basano sulla composizione e sul riuso di compo-
nenti pi` u semplici. Lidea dellanalisi gerarchica `e anche molto ane, e resa pi` u
semplice da applicare, alle tecniche di ranamento top-down della soluzione di
problemi complessi.
1.3.1 Modello Gerarchico di un Sistema di Calcolo
Un caso in cui la costruzione di una sequenza di modelli gerarchici `e abbastanza
semplice `e quando si ha a che fare con sistemi in cui le varie attivit`a avvengono
con scale dei tempi molto diverse (vedi Fig. 1.1).
Prendendo spunto da questa considerazione, incominciamo a vedere come sia
possibile costruire un modello di un sistema di calcolo iniziando a considerare
le sue componenti hardware e ranandone la sua struttura in passi successivi.
Livello dellutente esterno A questo livello di astrazione ogni utente che
usa il sistema inviando dei comandi da terminale (sistema client-server), vede il
sistema stesso come ununica scatola nera capace di rispondere alle sue richieste
con un certo ritardo. Un primo modo di rappresentare questa situazione pu`o
essere quello delineato in Fig. 1.2 in cui sono evidenziati proprio i terminali
(client) ed il sistema centrale (server) nel suo complesso.
D
R
A
F
T
1.3. MODELLI GERARCHICI E MODULARIT
`
A 11
Sistema
Centrale
coda di
attesa
.
.
.
1
2
N
Terminali
Figura 1.2: Rappresentazione di un sistema time-sharing visto a livello utente
In questo modello ogni job fatto eseguire dallutente (un comando di ricerca
di una stringa di caratteri in fase di editing di un le `e un job!) viene considerato
come unentit`a indivisibile ed eseguito dal sistema senza interruzione. Il fatto
che il sistema non risponda immediatamente alla richiesta dellutente perch`e
(eventualmente) impegnato nella elaborazione di un altro job `e rappresentato
dalla coda di attesa di fronte al sistema centrale.
Possiamo pensare che lintervallo di tempo che separa mediamente linvio di
due comandi successivi da parte di un medesimo utente possa essere dellordine
dei secondi.
Livello del sistema In realt`a noi sappiamo che tutti i sistemi moderni sono
multiprogrammati e che le operazioni di Input/Output richieste da un certo job
sono sovrapposte ad elaborazioni da parte della CPU compiute per un altro
task. Lesecuzione di un programma pu`o essere considerata come il susseguirsi
di periodi di attivit` a della CPU e di periodi di attivit`a delle unit`a periferiche.
Dopo un numero appropriato di cicli lelaborazione termina ed il risultato viene
restituito allutente. Ragioni siche impongono che un numero massimo K di
job possano essere eseguiti in parallelo. K viene chiamato il livello massimo di
multiprogrammazione. Per rendere pi` u eciente questo tipo di organizzazione,
lattivit`a della CPU pu`o anche essere interrotta. Questa operazione, chiamata
time-slicing viene eseguita per impedire che un job monopolizzi la CPU a scapi-
to dellesecuzione di tutte le altre richieste, rendendo cos` inattivi i processori
dedicati alla gestione delle unit`a periferiche.
Questi dettagli sono ovviamente tutti ignorati dal modello precedente, ma
possono essere presi in considerazione ranando la rappresentazione della sca-
tola nera che prima corrispondeva al sistema centrale.
A questo livello di astrazione, una schematizzazione del funzionamento del
nostro sistema pu` o essere quella contenuta in Fig. 1.3 dove un job in esecuzione
pu` o essere immaginato come un oggetto che si muove ripetutamente tra le varie
D
R
A
F
T
12 CAPITOLO 1. INTRODUZIONE
.
.
.
1
2
N
CPU
DISK
DRUM
Terminali
K<N
Sistema Centrale
Figura 1.3: Rappresentazione di un sistema time-sharing visto a livello delle
componenti di sistema
unit`a siche del sistema ricevendo servizio da esse per poi uscire dal sistema e
ritornare al terminale quando la sua elaborazione `e terminata.
In modelli semplici di questo tipo si pu`o immaginare che ogni job possa
risiedere, ad ogni istante, in una ed una sola stazione di servizio e che quindi, se
un job sta ricevendo servizio dalla CPU (viene elaborato dalla CPU) non possa
contemporaneamente ricevere servizio da ununit`a di I/O
1
.
Uno schema di questo tipo si adatta abbastanza bene a rappresentare lese-
cuzione di un comando di ricerca di una stringa in fase di editing di un le
quando la ricerca si debba estendere attraverso il contenuto di pi` u record del
le.
A questo livello di astrazione possiamo pensare che le varie interazioni tra le
unit`a componenti il sistema centrale avvengano con intervalli di tempo dellor-
dine dei millisecondi.
Livello dei componenti hardware Evidentemente la nostra analisi del pro-
blema pu` o essere spinta ancora pi` u in dettaglio considerando, per esempio, il
caso di un sistema multiprocessore in cui i job possono essere elaborati indif-
ferentemente dai singoli processori che condividono ununica memoria centrale.
Poiche lesecuzione di ogni job corrisponde ad un susseguirsi continuo di ac-
cessi alla memoria, e poiche lorganizzazione sica della memoria centrale dei
calcolatori permette ad un solo processore (od al massimo a pochi processori)
di accedervi in ogni istante di tempo, segue che anche laccesso alla memoria
rappresenta un punto di contesa dove `e possibile che si verichi dellulteriore
ritardo.
Una rappresentazione accurata della CPU multipla potr`a allora essere e-
seguita nel modo descritto in Fig. 1.4. A questo livello di astrazione possiamo
1
Questa restrizione non `e una caratteristica intrinseca dei modelli discussi in queste note,
ma sar` a ugualmente utilizzata nella maggior parte delle rappresentazioni che adotteremo per
sole ragioni di semplicit`a.
D
R
A
F
T
1.3. MODELLI GERARCHICI E MODULARIT
`
A 13
.
.
.
1
2
N
CPU
DISK
DRUM
Terminali
K<N
Sistema Centrale
1
2
M
.
.
.
Memoria
Processori
Figura 1.4: Rappresentazione di un sistema time-sharing visto a livello delle
componenti hardware
pensare che i cicli di memoria avvengano con tempi dellordine dei microsecondi.
Modellazione di un sistema software Come esempio aggiuntivo, consid-
eriamo il caso di voler modellare il funzionamento di un particolare prodotto
software.
Come abbiamo visto nellesempio precedente, lidentit`a di un job `e impor-
tante solamente per lutente esterno che ne ha richiesto lesecuzione e che vuole
quindi ottenerne i risultati.
Dal punto di vista delle unit`a componenti il sistema, non `e importante il
tipo di elaborazione richiesta da ogni singolo programma. In eetti lesecuzione
di un programma pu`o essere scomposta nella cooperazione di vari processi che
provvedono alla realizzazione di operazioni molto particolari. I processi possono
allora essere immaginati come dei frammenti di programma molto specializzati
che, in linea di principio, possono lavorare in parallelo.

E compito degli strati
superiori del sistema operativo quello di coordinare e sincronizzare lattivit` a
di questi processi al ne di ottenere lesecuzione complessiva desiderata dallu-
tente. Non esiste una denizione comunemente accettata di processo, tuttavia
possiamo pensarlo come una computazione in corso di esecuzione (instance of
computation). Lo stato di un processo `e completamente denito dal contenuto
di un certo insieme di registri (Instruction register, Domain register, Program
counter, ...). Associato ad ogni processo vi `e uno spazio di indirizzi diviso in un
dominio da cui il processo preleva i dati di ingresso e in un range (una sfera di
inuenza) in cui il processo deposita i risultati.
Nel caso di calcolatori contenenti un solo processore, i processi vengono
serializzati ed assegnati a turno al processore. Linterruzione dellesecuzione
di un processo pu`o essere dovuta alla necessit` a di eseguire unoperazione di
D
R
A
F
T
14 CAPITOLO 1. INTRODUZIONE
i
R/W
data
address
.... ....
DISK
DRIVER
process i
signal to process i for completion
Figura 1.5: Rappresentazione schematica dellinterazione tra un processo logico
ed una unit` a periferica sica
Input/Output, oppure alla necessit`a di attendere davanti ad un semaforo per
ragioni di sincronizzazione, oppure alla scadenza di un time slice del processore.
Quando il calcolatore su cui girano questi processi `e un multiprocessore, le
condizioni di sincronizzazione possono provocare delle vere e proprie attese da
parte di un processore.
Per fornire un esempio di un processo specializzato, possiamo considerare
lesecuzione di unoperazione di I/O in un sistema operativo organizzato a
processi.
In questo contesto il processo che desidera eseguire loperazione di I/O, non
si incarica sicamente di questa azione, ma invia un comando opportunamente
codicato ad un processo specializzato che ha il solo compito di gestire una
determinata unit`a periferica. Quando loperazione di trasferimento sar`a giun-
ta a conclusione, questo processo avvertir` a il processo originale dellavvenuto
completamento ed incomincer`a a servire unaltra richiesta.
Questa situazione pu`o essere rappresentata dallo schema contenuto in Fig. 1.5
dove la coda di ingresso al driver contiene la codica dei comandi (Read e Write)
da eseguire sullunit`a sica (ad un certo indirizzo) per conto di un certo processo
(P
i
) ed `e quindi una struttura dati a cui possono accedere pi` u processi.
Il processo P
i
che invia il comando e il processo Driver che interpreta il mes-
saggio ed esegue loperazione di trasferimento possono allora essere considerati
come processi cooperanti.
Evidentemente, esistono dei problemi di sincronismo che devono essere af-
frontati per evitare (cosa che potrebbe capitare con la coda vuota) che il proces-
so P
i
ed il processo Driver possano accedere contemporaneamente alla stessa
posizione della coda. Analogamente, `e anche necessario evitare che due proces-
si P
i
e P
j
depositino contemporaneamente i loro due messaggi nella medesima
posizione della coda.
Per questa ragione, la struttura dati rappresentante la coda deve essere
modicata solo allinterno di una regione critica
2
.
Gli eventuali altri processi che vogliano accedere alla struttura dati, se la
regione critica `e occupata, dovranno attendere allesterno.
2
Una regione critica `e un costrutto software che, in ogni istante, permette al suo interno
uno ed uno solo processo.
D
R
A
F
T
1.3. MODELLI GERARCHICI E MODULARIT
`
A 15
1
M
Analisi del
dead-lock
Rete
di
moduli
non
critici
Regioni
critiche
.
.
.
Figura 1.6: Accesso coordinato di processi concorrenti a regioni critiche
Premesse queste considerazioni, un sistema di calcolo che possiede pi` u pro-
cessori pu` o essere modellato da un punto di vista software rappresentando i
moduli software come entit`a siche statiche, mentre i processori possono essere
considerati come degli oggetti che circolano da un modulo software allaltro ed
eventualmente attendono in coda quando intendono eseguire una porzione di
programma racchiusa allinterno di una regione critica gi` a in uso da parte di un
altro processore.
Evidentemente la presenza di regioni critiche in un sistema pu`o portare a
delle situazioni di dead-lock. In generale, ci sar` a allora un modulo software che,
prima di permettere ad un processo di accodarsi nella lista di attesa di una
regione critica, analizzer` a lo stato del sistema e vericher`a che questa mossa
non porti il sistema in dead-lock
3
.
Lesecuzione dei processori pu` o allora essere immaginata come una serie di
cicli del seguente tipo:
esecuzioni di moduli non critici
esecuzione del modulo contenente il meccanismo di analisi del dead-lock
esecuzione della regione critica
Un possibile modello risultante `e quello riportato in Fig. 1.6.
Modelli di questo tipo sono stati utilizzati in letteratura per analizzare lef-
fetto della presenza di regioni critiche in sistemi multi-processore. Un risultato
possibile di unanalisi di questo tipo `e la quanticazione del vantaggio reale
derivante dallaggiunta al sistema di un processore in pi` u.
3
Un approccio di questo tipo viene chiamato nel contesto della teoria dei sistemi operativi
dead-lock avoidance
D
R
A
F
T
16 CAPITOLO 1. INTRODUZIONE
Modello
dettagliato
(livello di
astrazione
basso)
Modello
risultante
(livello di
astrazione
elevato)
sottosistema i sottosistema j
Esperimenti
controllati
stazione
equivalente
SISTEMA
j
i
stazione
equivalente
SISTEMA
sottosistema i
sottosistema j
Figura 1.7: Rappresentazione schematica dellanalisi gerarchica di un modello
complesso
1.4 Implicazioni pratiche della modellazione ger-
archica
Lo sviluppo di modelli gerarchici si basa sullipotesi, gi` a accennata in preceden-
za, che sia possibile individuare allinterno di un sistema (di calcolo) complesso
la presenza di gruppi di componenti (sottosistemi) il cui comportamento sia
sucientemente indipendente da quello del resto del sistema (dal contesto in
cui sono inseriti). In questi casi, detti sottosistemi possono essere analizzati in
isolamento con lobiettivo di costruirne delle rappresentazioni equivalenti che
possano essere utilizzate in modelli di alto livello, mascherando il loro compor-
tamento interno ed esibendo solamente quegli aspetti che li caratterizzano dal
punto di vista delle loro interazioni. In pratica, questo corrisponde alla con-
duzione di esperimenti, detti controllati, i cui risultati possono essere utilizzati
per parametrizzare una stazione equivalente (una scatola nera che li rappresen-
ta) che pu`o cos` venire utilizzata in modelli del sistema corrispondenti ad un
livello di astrazione superiore, come indicato schematicamente in Fig. 1.7. Le
tecniche usate per lanalisi dei sottosistemi in isolamento possono essere le pi` u
svariate e quindi si pu` o pensare di studiare il comportamento del sottosistema
utilizzando un modello analitico, oppure un modello di simulazione, oppure un
approccio gerarchico pi` u dettagliato. Queste metodologie possono essere uti-
lizzate contemporaneamente per studiare diverse componenti di un medesimo
sistema dando cos` luogo a quella che `e chiamata una Simulazione Ibrida.
D
R
A
F
T
1.5. VALUTAZIONE DELLE PRESTAZIONI 17
1.5 Valutazione delle prestazioni dei sistemi di-
namici ad eventi discreti
Una delle ragioni per lo sviluppo di un modello di un DEDS `e quella della
realizzazione di una rappresentazione formale che possa essere utilizzata per
ottenere degli indicatori numerici utili per guidare la scelta tra alternative ar-
chitetturali diverse in modo da progettare un sistema con le migliori prestazioni
possibili e per assistere le strategie operative necessarie per assicurare un buon
funzionamento anche in presenza di possibili guasti.
Per raggiungere questo obiettivo `e necessario che il formalismo utilizzato per
sviluppare il modello permetta di includere delle speciche temporali (normal-
mente espresse in termini di ritardi necessari per compiere determinate azioni)
e delle informazioni relative allinstradamento di oggetti allinterno del sistema
in maniera naturale.
La grande diversit` a dei sistemi reali `e comunemente riessa nel modello per
mezzo delluso di variabili casuali che portano alla costruzione (ed alla successiva
soluzione) di modelli probabilistici.
La valutazione delle prestazioni e delladabilit`a dei sistemi `e lambito sci-
entico che usa i modelli matematici e simulativi per il calcolo di indici di
prestazione legati al tempo.
I modelli introdotti nelle sezioni precedenti si congurano come delle reti di
code (o di le di attesa o di punti di congestione) rappresentati per mezzo di
un formalismo che non `e specico dei questi sistemi, ma che ha una validit`a pi` u
generale. Lanalisi di modelli di questo tipo `e condotta utilizzando una branca
della probabilit`a applicata che si chiama Teoria delle code.
Modelli a rete di code vengono usati per rappresentare situazioni di traco
che possono presentarsi con signicati e in contesti molto diversi:.
traco urbano (automobili, strade, semafori, rotonde,...)
traco di persone (clienti di una banca o di un supermercato, pazienti in
unospedale,...)
traco di oggetti (sistemi di produzione con pezzi lavorati da pi` u macchine
in cascata, carrelli trasportatori, ...)
traco di comunicazioni (messaggi telefonici, pacchetti circolanti in una
rete di telecomunicazione, ...)
traco di processi (componenti software di sistemi operativi o di basi di
dati, ussi organizzativi, work-ow, ...)
Questo elenco fa vedere come le metodologie che tratteremo nei prossimi
capitoli non sono solamente utilizzabili in ambito informatico, ma hanno una
valenza molto pi` u ampia.
Nella discussione generale condotta no a questo punto si `e sempre generica-
mente parlato di studio del comportamento di un sistema, senza precisare meglio
gli obiettivi di questanalisi.
D
R
A
F
T
18 CAPITOLO 1. INTRODUZIONE
Negli esempi precedenti abbiamo visto come i sistemi possano essere rappre-
sentati da reti di code che interagiscono tra di loro.

E allora abbastanza naturale
pensare che le prestazioni dei sistemi che noi esamineremo saranno valutate in
base al comportamento di queste code o stazioni di servizio.
Le grandezze a cui noi rivolgeremo la nostra attenzione sono:
Lunghezze delle code
Tempi di attesa trascorsi dai job (clienti) nelle code del sistema prima di
ricevere servizio
Utilizzazioni delle stazioni di servizio
Poiche abbiamo deciso di studiare il comportamento dei DEDS per mezzo
di modelli stocastici, tutte queste grandezze non hanno un valore preciso e
unico, ma sono piuttosto caratterizzate da distribuzioni di probabilit`a ovvero
da frequenze con cui i loro valori sono stati osservati durante diversi periodi di
misura.
Queste distribuzioni sono spesso dicili (o costose) da calcolare ed `e per-
tanto comunemente accettata la prassi di denire il comportamento del sistema
specicando i seguenti indici (medi) di prestazione:
Utilizzazione (U): Frazione di tempo durante il quale una stazione `e
risultata occupata
Throughput (X): Numero medio di operazioni completate dalla stazione
di servizio nellunit`a di tempo
Lunghezza media della coda (n): Numero medio di job (clienti) in attesa
di ricevere (e/o riceventi) servizio dalla stazione
Tempo medio di soggiorno (w): Durata media dellintervallo di tempo
intercorrente tra listante di arrivo di un job (cliente) alla stazione di
servizio e quello della sua partenza
A questi indici medi di prestazione si pu`o anche aggiungere la distribuzione
seguente:
p
i
(n) che rappresenta la frazione di tempo durante cui la stazione di
servizio di indice i ha avuto n job (clienti) al suo interno (in coda e/o
servizio), sapendo che spesso essa non verr` a calcolata per ogni possibile
valore di n, ma solamente per alcuni punti signicativi
1.6 Pianicazione di un esperimento di model-
listica
Indipendentemente dal metodo di analisi utilizzato per studiare il comportamen-
to di un determinato sistema, lesperimento di studio per mezzo di un modello
dovrebbe sempre essere preparato seguendo una procedura di questo tipo:
D
R
A
F
T
1.6. PIANIFICAZIONE DEGLI ESPERIMENTI 19
1. Formulazione del problema
2. Acquisizioni di dati dal sistema reale
3. Formulazione del modello
4. Stima dei parametri e delle caratteristiche operative del sistema reale
5. Analisi preliminare del modello
6. Calcolo degli indici di prestazione
7. Convalida dei risultati del modello
8. Progetto degli esperimenti
9. Analisi dei risultati
Non c`e accordo unanime sulla necessit`a e sullordine con cui queste fasi
devono susseguirsi. Evidentemente, i vari punti assumono rilevanza diversa
a seconda degli studi che vogliono essere condotti e delle metodologie usate,
tuttavia una pianicazione di questo tipo assicura una migliore interpretazione
dei risultati dellesperimento.
Formulazione del problema Formulare il problema signica ssare gli obi-
ettivi dello studio e stabilire i criteri per valutare le soluzioni al problema.
Tra gli obiettivi di un esperimento di studio con modelli, possiamo identi-
care tre casi:
Progettazione (Dimensionamento) di sistemi: Stima degli indici di
prestazione del sistema reale (non ancora esistente), sulla base di ipotesi
relative ai parametri ed alle caratteristiche funzionali di comportamnento,
per decidere come scegliere tra varie alternative.
Miglioramento di sistemi: Valutazione (calcolo) degli indici di prestazione
di un sistema esistente e studio degli eetti del cambiamento dei parametri
o delle caratteristiche funzionali sul comportamento del sistema. Analisi
delle strozzature e comportamento asintotico al variare dellintensit`a del
carico.
Scelta di sistemi: Valutazione delle prestazioni di diversi sistemi es-
istenti sottoposti a condizioni di carico simili o confrontabili.
Acquisizioni di dati dal sistema reale La denizione dei parametri di
un modello rappresenta una delle operazioni pi` u dicili da eseguire. I risul-
tati di un modello sono fortemente condizionati dalla precisione della stima dei
parametri di ingresso. Spesso la scarsa attendibilit` a dei risultati di un modello
deve essere attribuita pi` u allinaccuratezza dei parametri di ingresso che non
alle decienze strutturali del modello stesso. Quando si ha a disposizione un
sistema reale di cui si vuole costruire un modello, i parametri di questultimo
D
R
A
F
T
20 CAPITOLO 1. INTRODUZIONE
devono essere ottenuti da misurazioni eseguite sul sistema reale. In fase di pro-
getto, i parametri vanno ricavati da misure eseguite su sistemi confrontabili.
Nel caso del progetto di sistemi veramente nuovi, questi parametri devono es-
sere ipotizzati. Un aspetto particolarmente interessante e dicile da trattare `e
la stima delle distribuzioni associate ai parametri dingresso. La denizione dei
parametri dingresso `e spesso resa pi` u dicile dallincertezza relativa alle per-
sone che interagiscono con il sistema e che ne rappresentano il carico. Questo
aspetto diventa particolarmente importante quando lobiettivo dello studio `e la
scelta tra soluzioni alternative perch`e in realt` a scelte diverse comportano anche
spesso modi diversi di utilizzo.
Formulazione del modello La specica del modello avviene in tre fasi:
Specicazione delle componenti
Specicazione delle variabili
Specicazione delle relazioni funzionali
La specicazione delle componenti `e direttamente legata al tipo di studio che
si deve compiere e che denisce il livello di astrazione con cui il modello deve
rappresentare il sistema reale. La scelta del modello `e per` o anche condizionata
da considerazioni circa la complessit`a (logica e computazionale) del modello
stesso, la scelta della metodologia di analisi ed i costi dellesperimento.
La specicazione delle variabili ha un impatto notevole sulle dimensioni del
problema da analizzare. Per esempio, la scelta di una descrizione troppo det-
tagliata dello stato del sistema pu`o condurre, oltre che ad un problema di pi` u
dicile soluzione, anche alluso di quantit` a di risorse (memoria e tempo) de-
cisamente elevate. La scelta delle variabili di ingresso che hanno rilevanza per
lo studio che si vuole compiere ha unimportanza particolare. La specicazione
delle relazioni funzionali `e normalmente legata al tipo di problema che si sta
analizzando.
Stima dei parametri e delle caratteristiche operative del sistema reale
Questo passo ha il compito di trasferire nel modello i parametri e le carat-
teristiche operative del sistema reale, stimate sulla base dei dati raccolti in
precedenza. Esso si traduce nellapplicare tecniche statistiche per la stima dei
tipi di distribuzioni interessate e dei loro momenti. In questa fase rientrano
anche i metodi per lapprossimazione di caratteristiche operative a partire da
informazioni ricavate sperimentalmente (metodi dei minimi quadrati, analisi di
regressione, ...).
Analisi preliminare del modello La validit` a della stima dei parametri din-
gresso e delle loro distribuzioni deve essere accertata facendo uso di test stati-
stici. In questa fase `e consigliabile fare anche uso delle propriet`a matematiche e
statistiche delle componenti del modello per rendersi conto dellimportanza che
certe scelte possono avere sui risultati dellesperimento. Per esempio, carichi
D
R
A
F
T
1.6. PIANIFICAZIONE DEGLI ESPERIMENTI 21
di lavoro molto vicini alla capacit`a massima di una stazione di servizio danno
luogo a code molto lunghe e tendono a rallentare la velocit`a con cui il sistema si
porta in condizioni operative di equilibrio. Oppure, certe discipline di gestione
della coda di attesa possono avere eetti diversi sui momenti (valori medi di
funzioni) delle grandezze usate per il calcolo degli indici di prestazione.
Calcolo degli indici di prestazione Questa fase corrisponde alla stesura del
programma che dovr` a calcolare gli indici di prestazione del modello. Se il meto-
do di analisi `e la simulazione, la prima cosa importante da decidere `e la scelta
del linguaggio di programmazione o del package applicativo da adottare. Un
elemento importante che compare nella programmazione di un modello di sim-
ulazione `e la scelta dello stato iniziale e del metodo di raccolta delle statistiche
del modello che serviranno per il calcolo degli indici di prestazione.
Se la tecnica di analisi utilizzata `e quella analitica o numerica, occorrer` a
decidere quale metodo di calcolo utilizzare e se ricorrere alluso di programmi
specializzati reperibili commercialmente.
Convalida dei risultati del modello In questa fase `e necessario vericare
ladeguatezza del modello nel rappresentare il sistema reale oggetto di stu-
dio. Eventuali discordanze possono essere dovute sia ad errori di implemen-
tazione (errori logici di programma ed errori di scrittura) sia alla validit`a ed
alla rilevanza delle ipotesi introdotte nella fase di costruzione del modello.
Per vericare la presenza di errori di implementazione, si pu` o applicare il
programma a casi noti controllando lattendibilit`a dei risultati ottenuti. La
convalida delle ipotesi viene invece condotta facendo uso dei test statistici di
ipotesi.
Progetto degli esperimenti Quando i parametri di ingresso possono varia-
re allinterno di certi intervalli piuttosto ampi, combinazioni diverse dei valori
assunti dagli stessi possono dare luogo a scenari molto dierenti e quindi a risul-
tati molto diversi fra loro. Si dice in questo caso che lo spazio degli esperimenti
`e molto ampio e che `e necessario progettare linsieme degli esperimenti da con-
durre per ottenere le indicazioni desiderate con il minimo costo. Questa fase
aronta quindi due ordini di problemi:
Problemi di pianicazione strategica destinata alla progettazione di un
insieme di esperimenti da condurre
Problemi di pianicazione tattica intesa a stabilire le modalit`a di con-
duzione del singolo esperimento.
La strategia deve stabilire con quali criteri il sistema debba essere guidato at-
traverso lo spazio degli esperimenti possibili e quale livello di signicativit`a
attribuire alle variazioni dei risultati osservati nei vari esperimenti. La tattica
deve stabilire come eseguire gli esperimenti. Nel caso della simulazione, questo
pu` o voler dire decidere quante esecuzioni del simulatore fare per ogni esperimen-
to. Nel caso delluso di metodo analitici o numerici, pu` o voler dire come variare
D
R
A
F
T
22 CAPITOLO 1. INTRODUZIONE
i livelli di precisione con cui si devono calcolare i risultati o come assegnare gli
indici alle diverse stazioni di servizio del sistema.
Analisi dei risultati Questa ultima fase, `e una delle pi` u dicili ed `e stretta-
mente legata al tipo di problema analizzato ed alla tecnica di analisi utilizzata.
In ogni caso, linterpretazione dei risultati deve tenere conto dei seguenti punti:
Sensibilit` a dei risultati ad errori (o variazioni) dei parametri dingresso
Identicazione delle variabili di ingresso e di stato eettivamente rilevanti
ai ni dello studio condotto
Studio esplicito dellimportanza delle ipotesi introdotte nelle fasi di costruzione
e di scelta dei parametri del modello.
1.7 Osservazioni nali
Prima di terminare questa parte introduttiva, ricordiamo che per il caso specico
dello studio delle prestazioni del comportamento dei sistema di calcolo e di
telecomunicazione, loggetto da valutare `e in realt` a un sistema schematizzabile
nel seguente modo:
non-deterministico deterministico
WORKLOAD
(carico di lavoro)
SISTEMA
Figura 1.8: Rappresentazione di un sistema time-sharing visto a livello delle
componenti di hardware
Il problema della valutazione delle prestazioni di un sistema di questo tipo
consiste quindi nella caratterizzazione del carico di lavoro a cui `e sottoposto il
sistema e nella scelta delle tecniche di analisi da utilizzare.
Il carico di lavoro `e la quantit` a di servizio richiesta (od imposta) ad un
determinato sistema e corrisponde quindi alla specicazione delle variabili di
ingresso del modello espressa normalmente in termini di:
D
R
A
F
T
1.7. OSSERVAZIONI FINALI 23
Processo con cui le richieste sono sottoposte al sistema (frequenza degli
arrivi, variabilit`a della cadenza, ...)
Quantit`a di attivit`a di CPU associata ad ogni richiesta
Quantit`a di memoria centrale usata da ogni programma
Quantit`a di operazioni di I/O associate ad ogni programma
Numero di moduli software usati da ogni programma
Il funzionamento del sistema, che `e spesso intrinsecamente deterministico, as-
sume quindi una connotazione stocastica proprio per eetto delle caratteristiche
del carico di lavoro che tiene conto al suo interno della natura aleatoria dellin-
terazione del sistema con la componente umana. Interagendo quindi il sistema
con delle persone, diventa indispensabile considerare la natura stocastica del-
loggetto di studio e quindi sviluppare tecniche di analisi basate essenzialmente
sullo studio dei processi stocastici.
D
R
A
F
T
24 CAPITOLO 1. INTRODUZIONE
D
R
A
F
T
Bibliograa
25