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;
• 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].
Metodi di valutazione delle prestazioni di sistemi
Misurazione
Modelli
Misurazione diretta
Benchmarking Prototipo Analitici
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
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.
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à.
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
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
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;
• 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
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.
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.
Sviluppo top-down ...
...
...
...
...
... ...
...
livello di astrazione 1 (alto) Modello l
livello di astrazione 2 (medio) Modello 2
livello di astrazione n (basso) Modello n
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
METODO ACCESSO TERMINALI r i s p o s t e
t r a n s a z i o n i
SCHEDULER MEMORIA
SISTEMA INGRESSO BATCH output
j o b b a t c h
PROCESSORE 1 PROCESSORE N
SUPERVISORE I/O
CANALI
PERIFERICHE DISPATCHER
…
…
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
coda servente utenti
in arrivo
utenti in partenza
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].
sistema
...
terminali
Fig. 1.5 - Modello di code chiuso con singolo centro di servizio –
processore
...
terminali
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
processore
...
terminali
periferiche di I/O
...
memoria richiesta
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
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.
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].
