Sistemi e Modelli In questo capitolo vengono introdotti i concetti e

Transcript

Sistemi e Modelli In questo capitolo vengono introdotti i concetti e
Capitolo 1 - Sistemi e Modelli
In questo capitolo vengono introdotti i concetti e una classificazione dei sistemi e
dei modelli ed il procedimento di creazione ed uso di un modello al fine di valutare le
prestazioni del sistema rappresentato. Viene inoltre discusso tale approccio di
modellamento secondo lo schema iterativo e una struttura a sviluppo gerarchico di
modelli a diversi livelli di astrazione di tipo top-down.
1.1 Definizione di sistemi e modelli
Lo studio e l’analisi di sistemi tramite una rappresentazione astratta o una sua
formalizzazione è utilizzato in molte differenti discipline scientifiche dall’informatica
alla fisica, dalla biologia all’economia.
Definiamo un sistema come un insieme di componenti (elementi, entità)
interdipendenti e che interagiscono per raggiungere un determinato obiettivo.
Un sistema di elaborazione è un insieme di componenti hardware, firmware e
software che permettono l’elaborazione delle informazioni eseguendo programmi di
utente.
Gli enormi progressi tecnologici degli ultimi decenni hanno reso possibile la
costruzione di sistemi informatici sempre più complessi e strutturati. Di conseguenza
per la progettazione e l’analisi del comportamento di tali sistemi non è più sufficiente
applicare un semplice approccio di studio intuitivo e basato sull’esperienza.
Nello studio di un sistema di elaborazione devono essere considerati diversi
fattori, fra i quali aspetti relativi
• alla funzionalità e alla correttezza,
• alla affidabilità,
• al costo e ai fattori economici,
• alle prestazioni.
Lo studio e l’analisi del comportamento di un sistema e la sua valutazione in
termini di costo e prestazioni è fondamentale durante tutto il ciclo di vita del sistema.
In particolare
• nella fase di progettazione:
questo caso include il progetto di sistemi non esistenti, anche in una fase iniziale,
quando occorre operare delle scelte fra configurazioni alternative valutandole
senza avere a disposizione le relative implementazioni;
S. Balsamo
-4-
• nella fase di dimensionamento e acquisizione:
questa fase comprende le scelte fra diversi sistemi o componenti disponibili ed
esistenti;
• nella fase di evoluzione della configurazione e del carico:
in questo caso si considerano tutti gli aspetti e i problemi relativi alla modifica ed
evoluzione di un sistema esistente, tipicamente per una sua espansione o un suo
miglioramento, sia per variazioni della configurazione che per variazioni del
carico di lavoro.
Le metodologie per la valutazione delle prestazioni di sistemi possono essere
distinte in due categorie principali, come illustrato in Fig. 1.1:
• tecniche di misurazione
• tecniche modellistiche.
Le prestazioni di un sistema di elaborazione possono essere quantificate da figure
di merito o indici di prestazione che descrivono l’efficienza dello svolgimento delle
sue funzioni. Nel primo caso gli indici di prestazione del sistema vengono misurati,
mentre nel secondo caso vengono calcolati, applicando e risolvendo modelli analitici,
o stimati, utilizzando ed eseguendo modelli di simulazione [FSZ 81, LAV 83, LAV
89, KAN 92, KOB 78, JAI 90, LK 82, LZG 84].
Misurazione
diretta
Misurazione
Metodi di valutazione
delle prestazioni di sistemi
Benchmarking
Prototipo
Analitici
Modelli
Simulativi
Ibridi
Fig. 1.1 - Metodi di valutazione delle prestazione di sistemi Fra le tecniche di misurazione si possono identificare le tecniche di misurazione
diretta, il benchmarking (misurazione con carico artificiale) e la prototipazione. Nel
primo caso il sistema viene direttamente misurato utilizzando il carico reale del
sistema stesso, tramite opportuni strumenti e metodologie. Nella tecnica di
benchmarking le misurazioni vengono effettuate ancora sul sistema reale, ma
utilizzando un carico artificiale o benchmark. Questo approccio ha come principale
S. Balsamo
-5-
vantaggio, rispetto al precedente, la ripetibilità del procedimento di misurazione e la
possibilità di effettuare misurazioni comparative fra diversi sistemi sotto le stesse
condizioni di carico. Se il sistema su cui effettuare le misurazioni non è disponibile,
in quanto non esistente o in quanto una delle precedenti tecniche di misurazione non è
applicabile, si può ricorrere alla costruzione di un prototipo su cui effettuare le
misurazioni. Se il prototipo è realizzato a livello software, viene anche detto
emulatore del sistema. Lo svantaggio principale di questo approccio è la scarsa
flessibilità e modificabilità, una volta che il prototipo è stato costruito, per lo studio di
scelte alternative. Una trattazione estesa delle tecniche di misurazione si può trovare
in [FER 78, FSZ 81, JAI 90].
L’uso dei modelli per la valutazione e lo studio del comportamento dei sistemi
diventa indispensabile nella fase di progetto di sistemi non esistenti (per cui le
tecniche di misurazione diretta o artificiale non sono applicabili) e in particolar modo
nei primi stadi di progetto in cui è importante poter discernere fra differenti
alternative senza dover scendere ad un livello di dettaglio elevato, come invece
solitamente è necessario nello sviluppo di prototipi.
Un modello è una rappresentazione astratta del sistema che include solo gli
aspetti rilevanti allo scopo dello studio del sistema. Un modello è definito ad un
determinato livello di astrazione, ovvero il sistema viene descritto con un certo
livello di dettaglio, includendo nella rappresentazione solo quelle componenti e
interazioni fra componenti che si ritengono necessarie allo scopo prefisso. Alla
definizione del modello segue la sua parametrizzazione, per poter considerare le
alternative di studio, e la sua valutazione o soluzione per ottenere le informazioni
relative allo studio del sistema.
Fra le tecniche modellistiche si possono distinguere i modelli e i metodi analitici e
i modelli e le tecniche di simulazione.
In un modello analitico le componenti e il carico del sistema sono rappresentate
da variabili e parametri, e le interazioni fra le componenti da relazioni fra queste
quantità. La valutazione del sistema effettuata utilizzando il modello analitico
richiede il calcolo della sua soluzione tramite metodi analitici o soluzioni numeriche.
Un modello di simulazione riproduce il comportamento dinamico del sistema nel
tempo rappresentando le componenti e le interazioni in termini di relazioni funzionali.
La valutazione di un sistema tramite un modello di simulazione richiede l’esecuzione
(run) di un programma di simulazione, o simulatore che rappresenta l’evoluzione
temporale del sistema e su cui si effettuano delle misure per stimare le grandezze di
interesse.
S. Balsamo
-6-
Se da un lato la simulazione fornisce uno strumento potente per la valutazione di
sistemi, per ragioni di flessibilità e di generalità dei modelli risolvibili, d’altra parte il
suo limite maggiore è costituito dal costo sia di sviluppo e di parametrizzazione che
di esecuzione, specialmente se il sistema è rappresentato ad un elevato livello di
dettaglio. Inoltre per le caratteristiche delle misurazioni effettuate negli esperimenti di
simulazione, un corretta analisi dei risultati deve utilizzare opportune tecniche
statistiche per la stima degli indici di prestazione, spesso di non semplice
applicazione [JAI 90, KAN 92, LAV 83, LAV 89, LK 82].
Riassumendo, la definizione e l’impiego di un modello per lo studio di un sistema
presenta diversi vantaggi, fra i quali:
• aumento delle conoscenze:
la definizione di un modello aiuta ad organizzare le conoscenze teoriche e le
osservazioni empiriche sul sistema, portando ad una maggiore comprensione
del sistema stesso; infatti durante il processo di astrazione occorre identificare
quali sono le componenti e le interazioni rilevanti allo scopo dello studio;
• analisi del sistema:
l’impiego di un modello facilita l’analisi del sistema;
• modificabilità:
il modello è maggiormente modificabile e manipolabile rispetto al sistema
stesso permettendo la valutazione di diverse alternative, compatibilmente con la
definizione e il livello di astrazione adottato;
• diversi obbiettivi di studio:
l’impiego di diversi modelli dello stesso sistema permette la valutazione di
diversi obiettivi.
D’altro canto fra i limiti e gli svantaggi delle tecniche modellistiche notiamo:
• scelta del modello:
la scelta del livello di astrazione appropriato può essere un compito non
semplice; l’uso di un modello non appropriato può chiaramente portare ad errori
di valutazione;
• uso errato del modello:
vi è il rischio di utilizzare un modello oltre il suo campo di validità, ovvero
anche quando le assunzioni e le ipotesi che hanno portato alla sua definizione
non sono più verificate; in altre parole, occorre fare attenzione ad un uso
improprio del modello dovuto all’estrapolazione dei risultati oltre il suo campo
di applicabilità.
S. Balsamo
-7-
I modelli basati su processi stocastici sono introdotti ed applicati per valutare la
dinamica dei sistemi ed in particolare le loro prestazioni e/o affidabilità [KOB 78,
TRI 82, LAV 83, KAN 94]. Tale classe di modelli è introdotta nel prossimo capitolo.
I modelli a rete di code costituiscono una classe di modelli ampiamente studiata
e applicata per la valutazione delle prestazioni di sistemi informatici [FSZ 81, GEL
89, JAI 90, KAN 92, KIN 90, KLE 75, KOB 78, LAV 83, LZG 84, SC 79, TRI 82].
Tale classe di modelli permette di rappresentare sistemi di congestione, ovvero
sistemi formati da un insieme limitato di risorse e in cui si osserva competizione per
il loro utilizzo da parte di un insieme di utenti [KLE 75].
Esempi di sistemi di congestione rappresentabili da modelli a rete di code si possono
osservare in diversi campi: dai sistemi di calcolo e di comunicazione ai sistemi di
traffico e di produzione. Ad esempio, in un sistema di calcolo le risorse possono
essere componenti hardware e software e gli utenti i lavori (job) o programmi da
eseguire. Analogamente, in una rete di comunicazione le linee di comunicazione
rappresentano le risorse e i messaggi o pacchetti da trasmettere gli utenti. In un
sistema di traffico, ad esempio un aeroporto, le piste di atterraggio e le torri di
controllo corrispondono alle risorse, e gli aeroplani e i passeggeri corrispondono agli
utenti.
La valutazione delle prestazioni di un sistema di congestione include due
differenti aspetti: dal punto di vista del sistema, si è interessati alla valutazione della
utilizzazione delle risorse, mentre dal punto di vista dell’utente si valutano i tempi di
attesa per l’uso delle risorse. Di conseguenza l’ottimizzazione di tali sistemi può
essere orientata verso due direzioni contrastanti: da un lato la massimizzazione
dell’uso delle risorse e, dall’altro la minimizzazione dei tempi di attesa degli utenti
per il loro utilizzo.
In seguito introduciamo le principali metodologie per valutare i diversi indici di
prestazione nei modelli a rete di code.
1.2 Classificazione di sistemi e di modelli
I sistemi oggetto di studio possono essere sia esistenti che ipotetici. Abbiamo
definito, un sistema come un insieme di componenti o entità interagenti al fine di
raggiungere uno scopo prefissato. L’evoluzione nel tempo di un sistema è descritta,
ad ogni istante, dallo stato del sistema che ne rappresenta la condizione in quel
particolare momento. Lo stato è espresso in termini di variabili di stato che
descrivono le entità del sistema e i loro attributi. Le attività delle componenti nel
tempo e le interazioni fra le componenti sono descritte dalle regole di trasformazione
fra stati. La descrizione nel tempo del comportamento del sistema e della sua
S. Balsamo
-8-
evoluzione è rappresenta dalla storia degli stati, ovvero dalla successione temporale
degli stati del sistema.
Un sistema opera in un ambiente che può influenzare il comportamento del
sistema stesso. Occorre quindi identificare senza ambiguità il sistema e la sua
interfaccia rispetto all’ambiente esterno. Le variabili di stato si distinguono in
variabili endogene, se il loro cambiamento è dovuto soltanto ad attività interne al
sistema, e variabili esogene se sono influenzate dall’ambiente esterno al sistema. Un
sistema è detto chiuso se il suo comportamento è completamente determinato da
attività interne, cioè se non esistono variabili esogene. Al contrario, un sistema è
aperto se interagisce con l’ambiente esterno, come viene espresso dalle variabili
esogene.
I sistemi si distinguono in continui o discreti a seconda del tipo di cambiamento
dei valori, continuo o discreto, delle variabili di stato. Ad esempio se la variabile di
stato rappresenta la temperatura in un dato luogo, poiché i suoi cambiamenti sono
graduali e continui, abbiamo un sistema continuo. Viceversa, se ad esempio il sistema
è descritto dal numero di persone presenti in una stanza, i cambiamenti avvengono
istantaneamente per passi discreti e quindi si osserva un sistema discreto.
Il modo in cui avvengono le trasformazioni fra stati determina se un sistema è
deterministico o stocastico. Nel primo caso le regole di trasformazione determinano
univocamente il cambiamento di stato del sistema, mentre nel secondo caso da uno
stato è possibile raggiungere diversi stati secondo una legge di probabilità associata
alla regola di trasformazione. Esempi di sistemi deterministici si possono osservare in
alcuni sistemi di produzione e di automazione (per esempio in una catena di
montaggio può essere vista come un sistema deterministico, in quanto ogni attività
determina univocamente lo stato successivo del sistema). I sistemi stocastici in cui le
variabili di stato variano con casualità secondo leggi di distribuzione di probabilità si
osservano in diversi campi. Alcuni esempi sono l’osservazione delle turbolenze
atmosferiche in un sistema naturale, il numero di pazienti in un ospedale, il numero di
utenti collegati ad un sistema di calcolo interattivo, il numero di messaggi trasmessi
su una linea di comunicazione in un sistema di comunicazione, il numero di
automobili che attraversano un casello autostradale in un sistema di traffico.
La natura stocastica o deterministica, continua o discreta di un sistema non è una sua
proprietà assoluta, ma dipende dalla visione da parte dell’osservatore del sistema
stesso che è determinata dagli obiettivi e dal metodo di studio, così come
dall’esperienza dell’osservatore.
Analogamente ai sistemi, anche i modelli possono essere distinti in aperti e chiusi,
continui e discreti, deterministici e stocastici. Non necessariamente il tipo di modello
corrisponde al tipo di sistema rappresentato. Ad esempio un sistema continuo può
essere rappresentato da un modello discreto, introducendo una discretizzazione del
S. Balsamo
-9-
campo di definizione delle variabili continue del sistema per definire variabili discrete
del modello. Analogamente un sistema stocastico può essere descritto da un modello
deterministico ad esempio facendo riferimento ai soli valori medi delle variabili del
sistema.
La natura del modello dipende non solo dal tipo di sistema studiato ma anche dal
livello di astrazione impiegato e dall’obiettivo per il quale il modello è definito.
Infatti il modello deve riprodurre tutte quelle proprietà elementari delle componenti
del sistema e le loro interazioni da cui dipendono le funzionalità, oggetto di studio,
che si è interessati a rappresentare e a valutare.
I modelli si distinguono in due principali categorie: modelli fisici e modelli
simbolici.
I modelli simbolici includono i modelli matematici su cui concentreremo la
nostra attenzione, e i modelli non matematici. A questa ultima categoria appartengono
alcuni modelli linguistici, grafici, e schematici (diagrammi, mappe).
Un modello matematico è costituito da un insieme di variabili e parametri che
rappresentano le componenti del sistema e da un insieme di relazioni fra variabili e
parametri che rappresentano le regole di trasformazione o attività del sistema,
espresse in un formalismo logico-matematico.
Vediamo ora di schematizzare il procedimento di valutazione di un sistema
tramite la definizione, parametrizzazione e soluzione di un modello che lo
rappresenti.
1.3 Creazione ed uso di modelli: ciclo dei modelli
Il procedimento di definizione, parametrizzazione e soluzione di un modello per
la valutazione e l’analisi di un sistema consiste solitamente in un processo iterativo di
raffinamenti successivi.
Ogni modello viene definito ad un determinato livello di astrazione e si basa su di
un insieme di assunzioni ed ipotesi sul sistema, sul suo comportamento e
sull’ambiente esterno. Tali assunzioni e ipotesi devono essere chiaramente definite,
per una loro corretta comprensione e possibile modifica, motivate e giustificate, per
meglio identificare l’effetto sui risultati della valutazione.
Tipicamente le assunzioni introdotte in fase di definizione del modello sono dovute a
ragioni di
• semplicità del modello: è opportuno includere nel modello solo quelle
componenti, caratteristiche ed interazioni che appaiono rilevanti alla
descrizione del sistema per lo scopo prefissato; spesso un modello semplice
riesce a fornire risposte sufficientemente accurate, specialmente in fase di
progettazione;
S. Balsamo
- 10 -
• adeguatezza delle misure: nella fase di parametrizzazzione è necessario disporre
degli strumenti adatti per valutare le grandezze necessarie alla definizione delle
variabili del modello;
• facilità di soluzione del modello: soltanto per alcune classi di modelli è
possibile calcolare efficientemente la soluzione; per poter utilizzare un modello
appartenete ad una certa classe si è spesso costretti ad introdurre delle
semplificazioni.
Il procedimento di creazione ed uso di modelli (modelling cycle ) per valutare un
sistema si può schematizzare come segue [LZG 84, JAI 90]:
1. Definizione degli obiettivi dello studio.
2. Definizione del modello e formulazione delle assunzioni e ipotesi.
3. Parametrizzazione.
4. Valutazione (soluzione) del modello e interpretazione dei
risultati.
5. Validazione del modello e valutazione dei risultati.
6. Documentazione. Analisi di sensitività.
1. Definizione degli obiettivi dello studio.
Questo punto comprende la definizione e la comprensione del sistema oggetto di
studio, delle sue componenti, attributi, attività, interazioni e delle relazioni fra il
sistema e l’ambiente esterno. La definizione degli scopi dello studio del sistema porta
alla identificazione delle variabili da valutare o indici di prestazione.
Contemporaneamente si stabiliscono anche i criteri di valutazione delle soluzioni che
saranno ottenute dal o dai modelli.
In questa fase sono incluse l’acquisizione dei dati dal sistema e la misurazione del
carico del sistema, tramite opportune tecniche.
2. Definizione del modello e formulazione delle assunzioni e ipotesi.
Dagli obiettivi di studio e dalla definizione del sistema, attraverso un processo di
formalizzazione e fissato un dato livello di astrazione si perviene alla definizione del
modello. Sono identificate le componenti, gli attributi, le caratteristiche funzionali e
le relazioni fra le componenti del modello, così come le assunzioni ed ipotesi
utilizzate. Da tale definizione deriva la complessità strutturale del modello e la sua
risolubilità.
3. Parametrizzazione.
In questa fase sono identificate le variabili del modello da misurare e i corrispondenti
S. Balsamo
- 11 -
strumenti di misurazione e la caratterizzazione del carico, ovvero il modello che
rappresenta il carico del sistema e le tecniche per definirlo [FSZ 81, JAI 90].
4. Valutazione (soluzione) del modello e interpretazione dei risultati.
Una volta che il modello è stato definito e parametrizzato si sceglie il metodo di
soluzione più appropriato, considerando fattori di complessità computazionale e
accuratezza dei risultati.
5. Validazione del modello e valutazione dei risultati.
Questo passo consiste nella valutazione della adeguatezza del modello a descrivere il
sistema oggetto di studio e a valutare l’obiettivo prefissato al punto 1 e nella
valutazione dei risultati ottenuti.
Se il modello non è soddisfacente per rappresentare correttamente il sistema ai fini
preposti si itera o al passo 1, nel caso in cui occorra rivedere la definizione del
sistema e/o degli obiettivi, oppure al passo 2 per modificare la definizione del
modello e/o delle ipotesi e assunzioni impiegate.
Se, pur essendo il modello accettabile, i risultati non permettono di rispondere alle
domande prefissate per una parametrizzazione non corretta si itera il procedimento al
passo 3.
Altrimenti si conclude il processo di creazione e uso del modello, possibilmente
includendo il punto successivo.
6. Documentazione. Analisi di sensitività.
Un aspetto importante del processo di modelling è la documentazione che include sia
i dettagli relativi al modello finale, in termini di assunzioni, metodi di soluzione,
sperimentazione, validità, costo, conclusioni e raccomandazioni, sia una descrizione
del processo di definizione del modello.
L’analisi di sensitività costituisce un altro importante aspetto che dovrebbe essere
incluso nella analisi descritta e consiste nello studio dell’influenza delle assunzioni
impiegate nel modello sui risultati ottenuti. Due tipici approcci per realizzare l’analisi
di sensitività sono i seguenti [LZG 84]:
• analisi di robustezza: in questo caso il modello viene analizzato e risolto
variando le ipotesi ed assunzioni da valutare e si confrontano i risultati ottenuti;
• casi limite: si considerano soltanto situazioni estreme, definendo delle assunzioni
limite sotto le quali si analizza il modello per ottenere dei limiti (bounds) agli
indici valutati.
Nella valutazione dell’adeguatezza del modello si devono esaminare aspetti
relativi non solo dalla significatività dei risultati, ma anche alla complessità risolutiva
del modello e alla semplicità di uso.
S. Balsamo
- 12 -
Un possibile mancato raggiungimento dello scopo prefissato è la presenza nel
sistema di colli di bottiglia (bottleneck) o strozzature dovute alla elevata utilizzazione
di un certo insieme di risorse. Nel ciclo descritto si operano allora delle modifiche al
sistema e/o al modello per eliminare tali colli di bottiglia; il procedimento è iterativo
in quanto i bottleneck identificati possono mascherarne altri che si manifestano
soltanto quando i primi sono risolti.
1.4 Livelli di astrazione e modelli a sviluppo gerarchico
Il ciclo di creazione e uso di modelli per la valutazione di un sistema ha una
struttura iterativa dovuta alla possibile modifica o degli obiettivi definiti al punto 1, o
delle assunzioni e della definizione del modello al punto 2 o della parametrizzazione
e delle tecniche di misurazione al punto 3.
Nello sviluppo top-down di una gerarchia di modelli per la analisi e valutazione di
un sistema si considerano diversi modelli corrispondenti a diversi livelli di astrazione
e ad obbiettivi e risultati via via più dettagliati, scendendo nella scala della gerarchia
[LZG 84, MIR 94]. In Fig. 1.2 è illustrato uno schema di modelli in relazione
gerarchica. Al modello definito al livello di astrazione n (n≥1) è associato l’insieme di
obiettivi e l’insieme dei risultati ottenibili da quel modello. In uno sviluppo di modelli
gerarchico di tipo top-down è definita una relazione fra i modelli ai diversi livelli di
astrazione; spesso gli obiettivi del livello n sono un sottoinsieme degli obiettivi del
livello n+1, così come il modello n+1 è una estensione o sviluppo o
particolarizzazione del modello del livello n.
Nelle prime fasi di progetto molti aspetti non possono essere definiti con un
elevato grado di dettaglio, e quindi è opportuno definire un primo modello ad un
elevato grado di astrazione per poter effettuare delle prime valutazioni di scelte
alternative [LZG 84, LAV 83, JAI 90].
Esemplifichiamo il procedimento di sviluppo gerarchico di modelli considerando
il progetto di un sistema di elaborazione rappresentato da modelli a rete di code [LAV
83, Cap.1].
In Fig. 1.3 è illustrato uno schema di un sistema di elaborazione come insieme di
alcune risorse sia hardware (processori, memoria, canali e periferiche di I/O,
terminali) che software (metodo di accesso ai terminali, sistema di ingresso batch,
scheduler per la gestione dello spazio di memoria, dispatcher per la gestione dei
processori e supervisore di I/O per la gestione delle richieste al sottosistema di I/O)
che interagiscono per fornire un servizio ad un insieme di utenti. Gli utenti sono sia di
tipo interattivo, lanciando transazioni per ricevere risposte dal sistema, che di tipo
batch. Le frecce mostrano il flusso dei lavori nel sistema.
S. Balsamo
- 13 -
Modello l
livello di astrazione 1 (alto)
...
Modello 2
livello di astrazione 2 (medio)
...
Sviluppo
top-down
...
...
...
...
...
...
Modello n
livello di astrazione n (basso)
Fig. 1.2- Schema di modelli in relazione gerarchica Nel sistema gli utenti, provenienti sia dal sistema interattivo che dal flusso batch,
competono per l’uso delle risorse. Obiettivo di progetto di un sistema di elaborazione
è da un lato garantire una efficiente utilizzazione delle risorse, e dall’altro fornire un
insieme di funzionalità del sistema che garantisca tempi di risposta del sistema
accettabili agli utenti, in special modo per gli utenti interattivi.
Poiché le attese per l’uso delle risorse da parte degli utenti hanno un notevole
impatto sulle prestazioni del sistema, l’intero sistema può essere rappresentato da un
modello a rete di code in cui sono espressi e quantificati i ritardi introdotti.
L’elemento di base dei modelli a rete di code è il centro di servizio che, nel caso
più semplice, è formato da una coda (eventualmente vuota) e da un servente. Il
sistema rappresentato in Fig. 1.4 è il più semplice modello di code aperto: un utente
S. Balsamo
- 14 -
transazioni
…
METODO ACCESSO
TERMINALI
risposte
SCHEDULER
MEMORIA
job batch
output
SISTEMA INGRESSO
BATCH
DISPATCHER
PROCESSORE 1
…
PROCESSORE N
SUPERVISORE I/O
CANALI
PERIFERICHE
Fig. 1.3 - Schema di un sistema di elaborazione arriva al sistema dall’esterno, attende eventualmente un periodo di tempo in coda,
riceve il servizio dal servente e infine lascia il sistema. Ogni utente è caratterizzato
dall’istante di arrivo e dalla richiesta di servizio effettuata. Analizzeremo in dettaglio
questi modelli nei capitoli 3 e 4.
Il semplice modello di Fig. 1.4 può essere utilizzato ad un livello di astrazione
molto alto per rappresentare l’intero sistema come un unica risorsa, assumendo che
l’intero carico di lavoro sia rappresentabile da un singolo flusso di utenti e tutte le
risorse del sistema siano condensate in un singolo centro di servizio.
La specifica delle caratteristiche operative di questo primo modello include la
descrizione del carico, delle domande di servizio degli utenti al sistema e
dell’algoritmo di ordinamento in coda. Definiti i parametri del modello, la sua
soluzione permette di valutare indici di prestazione quali il tempo di risposta
dell’intero sistema, la sua utilizzazione, la lunghezza di coda, il throughput o numero
medio di utenti serviti per unità di tempo.
Un diverso modello si ottiene, ad esempio, assumendo che il carico del sistema sia
generato da utenti collegati ad un insieme di terminali. Il modello, illustrato in Fig.
1.5, è chiuso e rappresenta ancora il sistema come un’unica risorsa. Fra i parametri di
S. Balsamo
- 15 -
utenti
in partenza
utenti
in arrivo
coda
servente
Fig. 1.4 - Modello di code aperto con singolo centro di servizio questo sistema vi è il numero di terminali e la caratterizzazione del carico di lavoro da
essi generato. Analogamente al caso precedente, dalla sua soluzione si valutano gli
indici di prestazione del sistema. Un modello di questo tipo è stato applicato negli
anni ‘60 durante il progetto del sistema operativo IBM OS/360 TSO (Time Sharing
Option), per valutare le prestazioni del sistema assumendo singola partizione di
memoria [LAV 83]. Un obiettivo di studio è ad esempio la determinazione del
numero di terminali collegabili al sistema garantendo che il tempo di risposta non
superi un valore limite prefissato.
Introduciamo ora un secondo livello nella gerarchia di modelli considerando, in modo
più realistico, la rappresentazione esplicita nel modello di alcune risorse del sistema.
Per esempio in un sistema multiprogrammato diversi utenti risiedono in memoria e si
può realizzare un parallelismo fra le attività di elaborazione del o dei processori e
delle periferiche di ingresso e uscita. Questa situazione può essere rappresentata da un
modello a rete di code formato da più centri di servizio interconnessi. Un esempio è
mostrato in Fig. 1.6, dove compaiono oltre ai terminali, dei centri di servizio che
rappresentano sia il processore che le periferiche di I/O. Un modello di questo tipo
può essere ulteriormente esteso definendo altri livelli di gerarchia, per rappresentare
altre risorse del sistema ed altre caratteristiche del sistema, quali ad esempio tipi
differenti di utenti. I modelli a rete di code e le relative metodologie di soluzione sia
esatte che approssimate saranno descritti nei capitoli 4 e 5. Particolare importanza
riveste una classe di modelli a rete di code, detta in forma prodotto, la cui soluzione
può essere efficientemente calcolata tramite opportuni algoritmi a complessità
computazionale polinomiale nel numero di componenti del modello.
Pur essendo la classe dei modelli a rete di code uno strumento importante ed
efficiente per la rappresentazione e la valutazione delle prestazioni di sistemi
per un’ampia varietà di applicazioni, tuttavia essa si basa su alcune assunzioni.
Esistono diverse caratteristiche dei sistemi che portano alla definizione di modelli che
non sono risolvibili efficientemente. Infatti la valutazione analitica di modelli
complessi che non rientrano nella classe di modelli di code in forma prodotto in molti
casi può essere ricondotta alla soluzione di sottostanti processi stocastici, la cui
complessità computazionale è tuttavia quasi sempre esponenziale [KLE 75, LAV 83].
S. Balsamo
- 16 -
terminali
sistema
...
Fig. 1.5 - Modello di code chiuso con singolo centro di servizio –
terminali
...
...
processore
periferiche di I/O
Fig. 1.6 - Modello a rete di code chiuso In questi casi o si applicano metodologie di soluzione approssimate, o si ricorre a
diversi approcci fra cui la simulazione [KAN 92, LK 82, LAV 83].
Esempi di caratteristiche di sistemi che portano alla definizione di sistemi
complessi sono particolari discipline di servizio, meccanismi di sincronizzazione,
situazioni di blocco, e richiesta da parte di un utente di più risorse
contemporaneamente. Nell’esempio analizzato quest’ultima situazione si presenta
rappresentando esplicitamente la richiesta di spazio di memoria, come illustrato in
Fig. 1.7. In questo modello, definito ad un livello di astrazione più basso dei
precedenti, la risorsa memoria è rappresentata esplicitamente, un utente che richiede
l’uso del processore e delle periferiche non può ricevere servizio prima di aver
acquisito una partizione di memoria. L’utente chiede contemporaneamente l’uso delle
risorse memoria e una fra processore e periferiche. Si forma quindi una coda di
richieste per lo spazio di memoria che, una volta acquisito, viene rilasciato soltanto al
termine del ciclo di elaborazione processore-periferiche.
Il modello di Fig. 1.7 non appartiene alla classe di reti in forma prodotto e non è
risolvibile efficientemente in modo esatto [LAV 83]. Diversi metodi approssimati
sono stati proposti e applicati per valutare le prestazioni di questi sistemi, spesso
S. Balsamo
- 17 -
...
richiesta
...
processore
terminali
periferiche di I/O
memoria
rilascio
Fig.1.7 - Modello a rete di code estese con richiesta simultanea di risorse basati su metodi di aggregazione e decomposizione. Nel capitolo 5 introduciamo i
concetti fondamentali di questa metodologia.
Aumentando il livello di dettaglio nella definizione del modello, in corrispondenza di
un più basso livello di astrazione si arriva alla definizione di modelli talmente
complessi la cui soluzione può essere affrontata soltanto tramite simulazione. Per
una estesa trattazione dei modelli e metodi di simulazione si veda [LK 82, LAV 83,
JAI 90, PAW 90].
1.5 Modelli per la valutazione delle prestazioni di sistemi: analitici, simulativi e
ibridi
Nell’esempio di creazione ed uso di modelli per un sistema di elaborazione sono
stati introdotti alcuni esempi di modelli a rete di code.
I modelli per la valutazione delle prestazioni di sistemi includono modelli
analitici, simulativi e ibridi. Una classe di modelli analitici nata inizialmente
nell’ambito dello studio delle prestazioni di sistemi telefonici è la teoria delle code
(queueing theory), disciplina matematica nell’ambito della probabilità applicata [KLE
75]. Tale teoria utilizza diverse metodologie per analizzare modelli di code e ha
trovato svariate applicazioni, come riportato dalla ampia letteratura in ricerca
operativa, e più recentemente, dagli anni ‘60-’70, per la valutazione delle prestazioni
di sistemi di elaborazione, di comunicazione, di traffico e produzione.
Nell’ultimo decennio sono state proposte trattazioni sistematiche
dell’applicazione della teoria delle code e in particolare dei modelli a rete di code
(queueing networks) per la valutazione di sistemi di elaborazione e/o di
comunicazione [FSZ 81, LAV 83, LZG 84, GEL 89, JAI 90, KAN 92, KIN 90, KLE
S. Balsamo
- 18 -
75, SC 81, SCH 87]. I modelli a rete di code sviluppati e le efficienti tecniche di
soluzione proposte hanno portato alla definizione di strumenti e ambienti di sviluppo
per la valutazione di sistemi tramite l’uso integrato di modelli analitici e simulativi
[ALL 94, LAV 83, LZG 84, SC 81, JAI 90]. Questi strumenti permettono di definire
agevolmente modelli dei sistemi oggetto di valutazione a diversi livelli di astrazione,
spesso tramite interfacce grafiche, e rendendo trasparente all’utente le scelte e le
metodologie di soluzione.
I modelli analitici basati su processi stocastici e su modelli di code sono trattati in
dettaglio nei successivi capitoli. Tali modelli possono essere studiati anche con
tecniche di simulazione, nel qual caso diventano modelli di simulazione. Tuttavia,
come osservato, la simulazione permette una maggiore generalità nella definizione
del modello, includendo anche descrizioni di tipo procedurale. Rimandiamo alla
letteratura per una descrizione dettagliata dei modelli e metodi di simulazione [LK
82, LAV 83, JAI 90, PAW 90].
Un’altra categoria di modelli per la valutazione delle prestazioni di sistemi che ha
ricevuto un notevole interesse negli ultimi anni è la classe di modelli a rete di Petri
temporizzate stocastiche, definite come un’estensione del modello a rete di Petri
originariamente introdotto per rappresentare la sincronizzazione in sistemi
concorrenti [MBC 86, KAN 92]. I modelli a rete di Petri stocastiche si prestano
naturalmente a modellare sincronizzazione di attività concorrenti di sistemi, ma non
la competizione per l’uso delle risorse. Possiamo affermare che tale classe di modelli
ha quindi caratteristiche complementari a quella dei modelli a rete di code che
permettono di modellare naturalmente la congestione, ma non la sincronizzazione di
attività. I metodi di analisi di reti di Petri stocastiche si riconducono prevalentemente
all’analisi del processo stocastico sottostante la rete. Recentemente sono state definite
alcune sottoclassi la cui analisi è più efficiente. Per una introduzione ai modelli a rete
di Petri stocastiche per la valutazione delle prestazioni di sistemi si veda [MBC 86,
KAN 92]. Non tratteremo qui tale classe di modelli.
Una categoria particolare di modelli per la valutazione delle prestazioni di sistemi
è costituita dai modelli ibridi, che combinano le caratteristiche dei modelli analitici e
di simulazione. Tali modelli sono particolarmente adeguati per rappresentare sistemi
di grandi dimensioni eventualmente nell’ambito di metodologie di sviluppo
gerarchico. Applicando il principio di decomposizione del modello, che verrà
introdotto nel capitolo 5, si riconduce lo studio del modello a quello di un insieme di
sottomodelli ed ad una loro combinazione. Se i sottomodelli e la loro composizione
sono analizzati con tecniche diverse (analitiche e simulative) si parla di modello e
metodologia ibrida. Scopo di tale metodologia combinata è sfruttare i vantaggi delle
due classi di modelli e metodi: la semplicità ed efficienza risolutiva dei modelli e
metodi analitici e la generalità della simulazione.
S. Balsamo
- 19 -
In letteratura la tecnica combinata analitico-simulativa è prevalentemente
presentata come un approccio empirico per l’analisi di sistemi complessi e di grandi
dimensioni e non come una vera e propria metodologia. Una prima semplice
definizione è stata proposta in [LZG 84] per modelli a reti di code in forma prodotto.
In generale, tuttavia, non è semplice identificare condizioni e criteri generali sulla
base dei quali è opportuno e conveniente definire un modello ibrido ed applicare la
metodologia ibrida in termini di riduzione dei costi rispetto alle altre metodologie
[LZG 84, JAI 90, KAN 92, MIR 94]. Uno studio dettagliato sia analitico che
sperimentale per analizzare tali problemi nell’ambito dei modelli gerarchici si può
trovare in [MIR 94].
S. Balsamo
- 20 -