Gli oggetti base del sistema da modellare sono le entità e le risorse.

Transcript

1 Capitolo 2 Simulazione discreta In questo capitolo presentiamo i concetti base per la costruzione di modelli di simulazione e i principali approcci alla simulazione discreta. La trattazione è in parte basata sul testo di Pidd [1], al quale rimandiamo per approfondimenti. 2.1 Il sistema da modellare In generale, in un progetto di simulazione il primo passo consiste nell analizzare il sistema in cui è emerso il problema che si vuole affrontare e risolvere. In questo paragrafo descriveremo i principali oggetti e operazioni che caratterizzano un sistema, introducendo anche le notazioni che verranno più frequentemente usate nel seguito. L attenzione sarà diretta al sistema fisico che si vuole modellare, agli elementi che in essi compaiono, alle relazioni tra tali elementi e alle attività che vi si svolgono. Nel paragrafo successivo riesamineremo il processo di modellazione avendo come obiettivo l implementazione di un simulatore del sistema in esame Oggetti Gli oggetti base del sistema da modellare sono le entità e le risorse. Entità. Si tratta di elementi del sistema che vengono considerati individualmente, e del cui stato si mantiene informazione nel corso della simulazione. Tipiche entità sono il paziente che si presenta all accet- 15

2 16 Capitolo 2. Simulazione discreta tazione di un ospedale, il pezzo che viene lavorato in una catena di montaggio, oppure l aereo in attesa di atterrare a un aereoporto. Risorse. Sono in genere elementi del sistema che non richiedono di essere modellati individualmente; l informazione che di essi si mantiene è il numero in cui sono presenti. Ad esempio, nella modellazione di un sistema in cui si trova un posteggio, in genere, non importa sapere come e se è utilizzato un singolo spazio del posteggio, quanto piuttosto conoscere ad ogni istante il numero degli spazi disponibili. Se un elemento debba essere considerato un entità oppure una risorsa è spesso una scelta che compie chi costruisce il modello. Uno stesso elemento può essere considerato un entità oppure una risorsa a seconda del modo in cui si è scelto di modellare il sistema e degli obiettivi della simulazione. Le entità possono essere permanenti o temporanee, attive o passive. Ad esempio, nel caso di una coda a un botteghino teatrale, i clienti che arrivano si mettono in coda ed escono dal sistema una volta serviti, possono essere considerati come entità temporanee e passive, mentre il botteghino svolge il ruolo di entità permanente ed attiva. Comunque la distinzione è a volte arbitraria, dipendendo dalla percezione del sistema che ha colui che costruisce il modello e dalle sue scelte. Le entità sono strutturate in classi. Ogni classe individua un tipo di entità, e ciascuna entità è una istanziazione di una particolare classe. Una classe può essere una sottoclasse di un altra classe. Le classi in generale sono caratterizzate da attributi individuanti alcune caratteristiche delle entità che appartengono a quella classe. Alcune di queste caratteristiche sono comuni a tutte le entità della classe, altre invece distinguono fra loro le singole entità. Del primo tipo è ad esempio il fatto che le entità appartenenti alla classe siano permanenti o temporanee. Al secondo tipo invece, nell esempio del botteghino teatrale visto precedentemente, appartiene la titolarità di un abbonamento; in questo caso le entità della la classe cliente si dividono in due sottoclassi, quella dei clienti abbonati e quella dei clienti non abbonati. Le classi sono poi caratterizzate anche dalle eventuali operazioni che le entità ad esse appartenenti possono effettuare. Ad esempio, sempre nel modello del botteghino teatrale, la classe servente (l addetto al botteghino) esegue le operazioni servizio di prenotazione ed emissione del biglietto e riscossione del pagamento.

3 2.1. Il sistema da modellare 17 Nome della classe Attributi Operazioni Figura 2.1. Rappresentazione grafica di una classe o entità Nel seguito, per rappresentare graficamente i modelli di simulazione useremo la grafica e la sintassi del linguaggio per modellazione UML [5]. Le classi e le entità saranno allora rappresentate da rettangoli divisi in tre sezioni come quello di figura 2.1, in cui le sezioni contengono il nome della classe/entità, gli attributi e le operazioni. Per gli attributi viene spesso anche indicato il tipo di variabile che li definisce (intero, booleano,...), mentre per le operazioni viene indicata la variabile il cui valore l operazione calcola e il tipo di tale variabile Stati, eventi, attività e processi Gli elementi principali che caratterizzano le dinamiche delle diverse entità nella simulazione di un sistema possono essere classificati in stati, eventi, attività, e processi. Uno stato individua la situazione in cui si trova un sistema, o anche una singola entità, in un dato momento. Dal punto di vista della singola entità, uno stato può essere o di attività (stato attivo) o di attesa (stato passivo). Ad esempio, l addetto a uno sportello può stare servendo un cliente oppure essere in attesa del prossimo cliente. Un evento è un fatto che produce un cambiamento significativo nel sistema, quale, ad esempio, l arrivo di un nuovo cliente in un ufficio, l arrivo di un ordine ad un produttore, o il completamento di una operazione. A esso corrisponde il momento in cui il sistema cambia di stato, e corrisponde in generale all inizio o alla fine di una attività 1. Nel modello dello sportello visto prima, un possibile evento è la fine del servizio di un cliente da parte dell addetto allo sportello, che si rende così disponibile per servire il cliente successivo. In questo caso l evento segna, dal punto di vista dell addetto allo 1 Qui il termine attività viene usato in un senso diverso da quello con cui lo stesso termine si usa nel linguaggio UML.

4 18 Capitolo 2. Simulazione discreta sportello, il passaggio fra uno stato di attività ed uno stato di attesa del prossimo cliente. Spesso, nelle notazioni usate per descrivere i modelli di simulazione, si usa il termine evento per indicare l istante di tempo in cui il sistema cambia stato piuttosto che il fatto che provoca tale cambiamento di stato. La scelta che qui abbiamo fatto è stata suggerita dall esigenza di coerenza con le notazioni usate dal linguaggio UML. A volte è utile raggruppare insieme una sequenza di eventi (e quindi di stati); si parla allora di processi. Uno strumento che consente di descrivere le interrelazioni fra i diversi stati attraverso cui transitano le entità nel sistema che si vuole modellare sono i diagrammi degli stati. In questi diagrammi a ciascuna entità è associata la sequenza degli stati che essa può assumere. Nel disegnare un diagramma può essere utile distinguere fra gli stati attivi, in cui in genere si hanno attività dipendenti da una o più entità, gli stati passivi o di attesa. Spesso i due tipi di stati si alternano nello stesso ciclo: ad uno stato attivo segue uno passivo e viceversa. Il diagramma degli stati ci permette di evidenziare bene non solo gli stati veri e propri, ma anche le attività ad essi associate e gli eventi che segnano il passaggio dall uno all altro. Anche qui useremo le notazioni del linguaggio UML illustrate nella figura 2.2, dove abbiamo indicato due stati e la transizione dall uno all altro. Alla transizione viene associata una etichetta composta, in generale, da tre termini: evento, condizione ed azione. L evento, come abbiamo già visto, indica ciò che fa sì che si verifichi il cambiamento di stato. La condizione indica ciò che fa sì che si realizzi quella particolare transizione; ad esempio nel caso del cliente di una banca che voglia effettuare un prelievo ad uno sportello Bancomat, il fatto che arrivi la risposta dal sistema centrale dopo che ha digitato il suo Pin può portare a due transizioni di stato diverse: se la risposta è positiva si passa a svolgere la successiva operazione, cioè il prelievo; se invece la risposta è negativa (ad esempio perché non viene accettao il Pin), si passa ad un altro stato quale ad esempio l uscita dal sistema del cliente che rinuncia al prelievo. L azione è ciò che viene fatto nel momento in cui avviene la transizione, ad esempio viene fatto accedere allo sportello il primo cliente in coda. Come si vede nella figura la sintassi che si usa per descrivere l etichetta associata ad una transizione è evento[condizione]/azione. Questo permette di interpretarla correttamente anche in assenza di alcuni dei termini. Non

5 2.1. Il sistema da modellare 19 Stato A entry/azione A1 do/attività A exit/azione A2 Evento[Condizione]/Azione Stato B entry/azione B1 do/attività B exit/azione B2 Figura 2.2. Le entità è infatti necessario che ogni transizione sia caratterizzata da tutti e tre gli elementi. Ad ogni stato possono poi essere associate delle azioni, che la sintassi UML distingue in tre tipi. Una azione di tipo entry viene eseguita ogni volta che a seguito di una transizione si entra nello stato, e corrispondentemente una azione di tipo exit viene eseguita ogni volta che si esce dallo stato. Le azioni di tipo do corrispondono poi alle attività che si effettuano all interno dello stato. Naturalmente la presenza di tali azioni non è obbligatoria e dipende dalle caratteristiche dello stato. Gli esempi che vedremo nel seguito permetteranno meglio di comprendere l uso dei diagrammi degli stati. Ricordiamo che in questi esempi la modellazione ha come obiettivo la descrizione del sistema e delle operazioni che in esso si svolgono, e non è ancora orientata alla simulazione Esempi Servizio piccoli prestiti Si consideri una banca in cui il servizio dei piccoli prestiti funziona secondo le seguenti modalità. Il cliente si rivolge all ufficio apposito, dove un impiegato esamina la richiesta. Se questa rispetta un certo numero di criteri prefissati, viene approvata; altrimenti il cliente viene rinviato al funzionario responsabile del servizio crediti. Il funzionario riesamina la pratica, rivede col cliente l importo del prestito e le eventuali condizioni, e quindi o approva la richiesta oppure la respinge definitivamente. Ci sono in questo sistema tre classi di entità: cliente, impiegato e funzionario. Le entità cliente sono temporanee e passive: entrano nel sistema secondo una data legge di probabilità, passano attraverso una o due code e

6 20 Capitolo 2. Simulazione discreta Impiegato -Disponibile :Boolean Cliente -Approvato:Boolean * Esame richiesta * Esame richiesta Funzionario -Disponibile :Boolean Figura 2.3. Le entità vengono servite dai relativi serventi, quindi escono dal sistema. Invece, le entità impiegato e funzionario sono permanenti ed attive. Nella figura 2.3 sono indicate le tre entità con l indicazione delle relazioni che le legano. I collegamenti indicano che i clienti entrano in relazione con l impiegato e con il funzionario per l esame della richiesta di prestito. L asterisco dalla parte del cliente e la mancanza di una indicazione dalla parte dell impiegato e del funzionario indica che la relazione è di tipo da molti ad uno: il numero dei clienti non è limitato a priori e ci sono un solo impiegato ed un solo funzionario per svolgere il servizio. Abbiamo indicato qui un solo attributo per ciascuna classe. Il cliente ha come attributo Prestito approvato, di tipo Booleano, che viene inizializzata a Falso. L impiegato ed il funzionario hanno l attributo, Disponibile di tipo Booleano, che viene inizializzato al valore Vero, e che indica la disponibilità a servire un nuovo cliente; se il funzionario e l impiegato stanno servendo un cliente, allora è Disponibile =Falso. Nella figura 2.4 è stato indicato il diagramma del ciclo delle attività dei clienti utilizzando la sintassi UML. Una volta arrivato, il cliente entra in coda e vi aspetta. La transizione avviene quando si verifica l evento che l impiegato si è reso libero ed è soddisfatta la condizione che il cliente è il primo della coda. A questo punto il cliente cambia di stato ed inizia il servizio (primo esame). In questo stato vengono effettuate le seguenti azioni: appena il servizio inizia l attributo Disponibile dell impiegato viene posto a F also 2, viene poi svolto 2 In alcuni tipi di servizio questo è ciò che avviene quando la luce sullo sportello cambia di colore passando da verde a rossa.

7 2.1. Il sistema da modellare 21 Arrivo Cliente /Entra in coda Prima Coda Impiegato.Disponibile=Vero [Cliente Primo in Coda ]/Inizio Servizio 1º esame entry/impiegatodisponibile=falso do/servizio exit/impiegato.disponibile=vero [Cliente.Approvato=Vero ] [Cliente.Approvato=Falso ] [Cliente.Approvato=Vero] Uscita Cliente Seconda Coda [Cliente.Approvato=Falso ] 2º esame entry/funzionario.disponibile=falso do/servizio exit/funzionario.disponibile=vero Funzionario.Disponibile=Vero [Cliente Primo in Coda ]/Inizio Servizio Figura 2.4. Servizio Piccoli Prestiti: Diagramma degli stati del cliente il servizio ed infine si riporta al valore V ero l attributo Disponibile. Poi, se il prestito è stato approvato il cliente esce dal sistema, altrimenti passa alla seconda coda. I passaggi dalla seconda coda al secondo esame e poi l uscita del cliente hanno un andamento analogo a quello relativo al primo esame. 2º esame entry/funzionario.disponibile=falso do/servizio exit/funzionario.disponibile=vero [Servizio terminato] [Coda non vuota] Libero Inizio orario servizio Fine orario servizio[coda vuota ] Figura 2.5. Diagramma degli stati del funzionario Analogamente si possono costruire i diagrammi degli stati dell impiegato e del funzionario, che sono fra loro identici. In figura 2.5 è riportato quello del funzionario.

8 22 Capitolo 2. Simulazione discreta Il centro prelievi Il centro prelievi di un ospedale è aperto nei giorni feriali dalle 7,30 alle 10. Anche qui abbiamo una classe clienti. Un cliente appena arrivato ritira un numero da un apposita macchinetta distributrice ed attende di essere chiamato allo sportello per l accettazione, dove presenterà la richiesta di analisi effettuata dal suo medico curante. I clienti sono chiamati all accettazione in ordine di numero crescente. Dopo l accettazione il cliente si reca allo sportello per il pagamento del ticket per poi mettersi in fila davanti all ambulatorio in cui si effettuano i prelievi; se è esente dal ticket, si recherà direttamente all ambulatorio per il prelievo. Le entità sono: i clienti, lo sportello per l accettazione, lo sportello per il pagamento del ticket e l ambulatorio per i prelievi. I clienti sono entità temporanee e passive, in numero illimitato, caratterizzate da due attributi, Esente e Numero. Il primo indica se il cliente è esente o no dal pagamento del ticket; si tratta di un attributo di tipo Boolean. Il secondo attributo è il numero che viene assegnato al cliente all arrivo; questo numero servirà per la coda dell accettazione e per quella dei prelievi. Le altre entità sono invece entità attive e permanenti; possono essere presenti in più istanze: ad esempio nell ambulatorio possono esserci più infermiere/i che effettuano i prelievi. Queste entità possono anche essere considerate delle risorse. Le entità che sono più critiche dal punto di vista della sequenza degli stati sono i clienti. Il diagramma degli stati relativo ai clienti è riportato nella figura 2.6. Il cliente, appena entrato nel sistema, riceve un numero, che corrisponde al suo ordine di arrivo, ed aspetta che il numero venga chiamato. A questo punto accede ad uno degli sportelli dell accettazione, e interagisce con l addetto, che, alla fine del servizio, gli dà un foglio con tutti i dati degli esami richiesti. Poi, se non è esente dal ticket, il cliente si mette in fila alla cassa e quando si libera una cassa (numero di casse libere, NP, maggiore di zero) accede al pagamento; dopo di che passa alla coda 3. Qui vale il suo numero iniziale, per cui quando il numero viene chiamato il cliente può accedere al servizio prelievo. In generale ci saranno disponibili più sportelli per l accettazione, più cassieri per il pagamento e più ambulatori per il prelievo. Nel diagramma non abbiamo evidenziato questo fatto. Lo avremmo potuto fare espandendo ciascuno degli stati relativi a servizi. Ad esempio, in figura 2.7 è indicata l espansione dello stato Accettazione nell ipotesi di due sportelli di servizio.

9 2.1. Il sistema da modellare 23 /Ricevi Numero Coda 1 Cliente.Numero=NumeroChiamato Accettazione Arrivo Cliente [Cliente.Esente=Falso ] [Cliente.Esente=Vero ] Coda 2 Uscita Cliente Prelievo completato Cliente.Numero=NumeroChiamato Prelievo Coda 3 Pagamento Ticket NP > 0 [Cliente primo in coda ] Pagamento completato Figura 2.6. Ciclo delle attività dei clienti del Centro Prelievi Quando il numero viene chiamato viene anche indicato lo sportello relativo ed il cliente chiamato accederà a quello sportello. Possiamo immaginare che ci sia una classe Accettazione, che ha come attributo la variabile LN, ultimo numero chiamato, e come istanze le entità Sportello 1 e Sportello 2. Ciascuna delle due entità ha come attributo la variabile booleana Disponibile. Quando una di queste entità si rende disponibile chiama il numero successivo; la chiamata, che immaginiamo avvenga attraverso un display che porta oltre al numero chiamato anche quello dello sportello, viene letta dal cliente che si reca allo sportello. Nella figura 2.8 abbiamo indicato il diagramma degli stati relativo all accettazione. Gli sportelli dell accettazione aprono alle 7:30 e chiudono dopo le 10:00 non appena è stato servito l ultimo cliente arrivato. Durante l apertura, non appena ci sia uno sportello disponibile, allora viene chiamato il numero successivo. Con LN, variabile che all inizio ha valore 0, abbiamo indicato il numero dell ultimo cliente chiamato al servizio, e con CMAX abbiamo indicato il numero dell ultimo cliente arrivato. La condizione LN < CM AX indica che il prossimo numero viene chiamato solo se ad esso corrisponde un cliente in attesa. Dopo la chiamata inizia il servizio del cliente chiamato.

10 24 Capitolo 2. Simulazione discreta Accettazione Servizio Sportello 1 Coda 2 Coda 1 Servizio Sportello 2 Coda 3 Figura 2.7. Espansione dello stato Accettazione Prima di iniziare le operazioni si rende non disponibile lo sportello 3, ed alla fine lo si rende di nuovo disponibile. Un deposito per la distribuzione di merci Una cooperativa di distribuzione ha un solo deposito, dove arrivano camion provenienti dai produttori con le merci richieste, e da cui partono i furgoni con le merci destinate ai diversi supermercati appartenenti alla cooperativa. Ci sono 2 banchine per lo scarico dai camion e 4 per il carico dei furgoni. Ci sono 5 squadre di 2 addetti ciascuna, che provvedono a scaricare, mettere in stock e caricare la merce sui furgoni. Esiste poi solo una via di accesso e di uscita, che consente il passaggio o di un camion (indipendentemente dal senso di marcia) o di due furgoni (purché in senso opposto di marcia); non c è lo spazio perché passino contemporaneamente un camion ed un furgone. Se l obiettivo della simulazione è di studiare le attese dei camion e dei furgoni, possiamo pensare di considerare camion e furgoni come delle entità, mentre le banchine di carico e scarico, la via di accesso e le squadre come risorse. I cicli delle attività per i camion è riportato nella figura 2.9, dove abbiamo indicato con N Bc e N S rispettivamente il numero delle banchine disponibili per i camion e quello delle squadre disponibili; all inizio è NB = 2 e NS = 3 Questa operazione potrebbe in pratica corrispondere al fatto che il display relativo allo sportello su cui era comparso il numero chiamato smetta di lampeggiare.

11 2.1. Il sistema da modellare 25 AperturaAccettazione T = 7:30 [LN < CMAX] Chiama Numero entry/ln := LN + 1 exit/numero Chiamato := LN Fine servizio[ln < CMAX ] Accettazione entry/disponibile := Falso do/operazioni Accettazione exit/disponibile := Vero T 10:00 [LN = CMAX ] Chiusura Accettazione Figura 2.8. Ciclo delle attività dei servizio Accettazione 5. Abbiamo assunto che il camion che ha finito di scaricare rimane in attesa alla banchina fino a che l ingresso non risulti libero e quindi possa uscire. Il botteghino del teatro Si consideri il botteghino di un teatro in cui vengono venduti i biglietti. L addetto al botteghino (servente), oltre a vendere i biglietti ai clienti deve anche rispondere alle telefonate fornendo le informazioni richieste. Si hanno pertanto due code, una fisica di clienti, davanti allo sportello, ed una, virtuale, formata da chiamate in attesa (il sistema telefonico si suppone abbastanza sofisticato da consentirlo). Entrambe le code vengono processate con una politica di tipo FIFO e i clienti hanno sempre la precedenza sulle chiamate (mai rischiare di perdere un cliente pagante!). Classi di entità: clienti (un numero illimitato di entità temporanee e passive), chiamate (un numero illimitato di entità temporanee e passive), addetto al botteghino (una sola entità, permanente e attiva). Si costruisca per esercizio il diagramma degli stati relativo all addetto a botteghino.

12 26 Capitolo 2. Simulazione discreta Arrivo Camion /Entra in coda Attesa ingresso NBc 1 [Primo in coda & Ingresso = libero ] Ingresso entry/ingresso := occupato do/entra exit/ingresso := libero Partenza Camion Attesa scarico entry/nbc :+ NBc - 1 NS 1 Uscita entry/ingresso : occupato do/esci exit/ingresso : libero Ingresso = libero Attesa uscita exit/nbc := NBc + 1 Scarico merce entry/ns := NS - 1 do/operazioni di scarico exit/ns := NS + 1 Figura 2.9. Ciclo delle attività dei camion 2.2 Approcci alla modellazione In generale un modello di simulazione è caratterizzato dai seguenti elementi: Controllore Tempo di simulazione Generatore di numeri casuali Entità Eventi e attività Stati Stato corrente delle entità Lista degli eventi Dati statistici Il controllore è la componente del sistema che gestisce la sequenza degli eventi e l evolversi dello stato del sistema nel tempo. In particolare il controllore ha il compito di fare avanzare il tempo di simulazione.per quanto questa

13 2.2. Approcci alla modellazione 27 funzione sia presente in ogni modello, tuttavia il modo in cui essa viene svolta può essere diverso. A diversi approcci alla simulazione corrispondono diversi modi di implementare il controllore. I due approcci principali tradizionalmente usati sono quello basato sulle attività e quello basato sui processi. Li descriveremo nel seguito facendo riferimento al modello dei piccoli prestiti già visto Simulazione per attività In questo approccio, a partire dal diagramma degli stati, si decompongono le attività svolte nel sistema in attività elementari. Queste attività corrispondono agli eventi, cioè a quei fatti o azioni che portano ai cambiamenti di stato del sistema e che quindi danno origine alle transizioni. Il ruolo del controllore sarà quello di gestire la lista delle attività individuate in modo che vengano eseguite. Ogni attività è caratterizzata dalla condizione che la fa avvenire e dalle azioni che vengono corrispondentemente fatte, e viene rappresentato per mezzo di una tabella in cui sono riportate le informazioni rilevanti. Riprendiamo l esempio del modello dell ufficio piccoli prestiti. Per quel che riguarda le entità, osserviamo come ci sia una grande differenza fra l entità cliente e le altre. Le entità impiegato e funzionario possono essere considerate come delle risorse che possono essere disponibili o no. Entrambe possono essere rappresentate per mezzo di una semplice variabile booleana. Diverso è il caso delle entità di tipo cliente. Ciascun cliente, una volta entrato nel sistema, ha una sua individualità e va seguito nel percorso che fa. A questo scopo è opportuno arricchire le informazioni relative all entità cliente che può essere rappresentato per mezzo della seguente classe: Cliente - Tempo Arrivo: Tempo - Approvato: Boolean - Tempo Prossima Attività: Tempo - Prossima Attività: Attività - Esami Conclusi: Boolean Al momento in cui l entità viene generata, gli attributi di tipo boolean vengono posti a Falso, e agli attributi Tempo Arrivo e Tempo Prossima Attività viene dato lo stesso valore, ottenuto attraverso la generazione di una variabile casuale; l attributo Prossima Attività viene infine inizializzato ad Ar-

14 28 Capitolo 2. Simulazione discreta rivo Cliente. Infatti, nel momento in cui viene generato, l entità corrisponde al prossimo cliente che entrerà nel sistema, e ciò avverrà quando il Tempo Arrivo sarà uguale al tempo di simulazione. Passando ad esaminare le attività, osserviamo che la prima attività elementare che viene eseguita è l arrivo del cliente. Possiamo rappresentarla per mezzo della seguente tabella, dove abbiamo con indicato con T c il tempo corrente di simulazione: Attività Condizione Azioni Arrivo Cliente T c = Cliente.Tempo Arrivo - Aggiungi Cliente alla prima coda L effettivo contenuto dell azione aggiungi Cliente alla prima coda dipende dal modo con cui la coda è implementata 4. Qui Cliente indica la generica istanziazione della classe cliente. La seconda attività rilevante si ha quando il cliente si viene a trovare in testa alla coda e l impiegato è disponibile; in questo caso inizia il primo esame. Possiamo allora definire una attività Inizio 1 o Esame che viene rappresentata dalla seguente tabella: Attività Condizione Azioni Inizio 1 o Esame (Prima Coda non vuota) (Impiegato.Disponibile=Vero) - Estrai Cliente dalla testa della prima coda - Impiegato.Disponibile := F also - Cliente.Prossima Attività := Fine 1 o Esame - Genera la durata del servizio, d - Cliente.Tempo Prossima Attività := T c + d Qui la condizione è il verificarsi dell and logico di due condizioni, il fatto che l attributo disponibile relativo all impiegato abbia valore V ero ed il fatto che la prima coda sia non vuota, cioè che ci sia almeno un cliente in attesa. Passato un tempo pari a d il servizio finisce. attività: Si ha allora la seguente 4 Se, ad esempio, la coda è stata implementata per mezzo di una lista a puntatori di tipo FIFO, allora l operazione consiste nell inserimento per mezzo di un puntatore dell entità nella lista

15 2.2. Approcci alla modellazione 29 Attività Condizione Azioni Fine 1 o Esame T c = Cliente.Tempo Prossima Attività (Cliente.Prossima Attività = Fine 1 o Esame) - Aggiorna Cliente.Approvato - If Cliente.Approvato = F also, Then Inserisci il C nella seconda coda, Else poni CLiente.Esami Conclusi := V ero - Impiegato.Disponibile := V ero L aggiornamento dell attributo Prestito approvato avviene attraverso la generazione di una variabile casuale a valori 0/1; se l esito è 0, allora si dà all attributo valore falso, se è 1, si dà valore Vero. Se il prestito viene approvato (Prestito approvato = Vero), l entità cliente si può assumere che esca dal sistema in quanto non verrà più interessata da alcuna delle attività. Le ultime attività da considerare sono Inizio del 2 o esame e Fine del 2 o esame : Attività Condizione Azioni Evento Condizione Azioni Inizio 2 o Esame (Seconda Coda non vuota) (Funzionario.Disponibile = V ero) - Estrai Cliente dalla testa della seconda coda - Funzionario.Disponibile := F also - Cliente.Prossima Attività:= Fine 2 o esame - Genera la durata del servizio, d - Cliente.Tempo Prossima Attività := T c + d Fine 2 o Esame (T c = Cliente.Tempo Prossima Attività) (Cliente.Prossima Attività = Fine 2 o Esame) - Aggiorna l attributo Approvato - Funzionario.Disponibile := V ero - Cliente.Esami Conclusi := V ero Osserviamo che, in questo approccio, abbiamo fatto la scelta di considerare attività elementari comportanti una singola operazione di cambiamento di stato. Ad esempio, nel caso di Arrivo Cliente, anche se la coda è vuota e l impiegato disponibile, si mette il cliente in coda; ci sarà poi un attività Inizio 1 o Esame che si verificherà subito dopo (però sempre nello stesso istante del tempo di simulazione) e che provvederà a fare iniziare il servizio estraendo il cliente dalla coda; per cui il tempo effettivo di permanenza in coda è nullo. Ciascuna di queste attività elementari è indipendente dalle altre.

16 30 Capitolo 2. Simulazione discreta Questo ha il vantaggio di rendere abbastanza semplice l aggiornamento o la manutenzione di programmi di simulazione basati su questo approccio. Analizzando le attività elementari si vede come esse possano essere considerate di due tipi, attività condizionate e attività programmate. Le prime sono attività che si verificano, indipendentemente dal valore del tempo di simulazione, ogni qualvolta siano verificate determinate condizioni logiche. Appartengono a questa classe nel nostro caso le attività Inizio 1 o Esame e Inizio 2 o Esame. Lo svolgersi di queste attività dipende dallo stato complessivo del sistema. Le seconde invece sono destinate a svolgersi in tempi prefissati, indipendentemente dallo stato del sistema. Sono di questo tipo le attività Arrivo Cliente, Fine 1 o Esame e Fine 2 o Esame. In generale, nell esecuzione della simulazione il controllore, ad ogni iterazione, effettua scansioni della lista delle attività, eseguendo le operazioni implicate da quelle che si verificano, fino a che una intera scansione non provoca più alcuna azione. Infatti è possibile che la conclusione di una attività crei le condizioni perché una di quelle precedentemente esaminate nella lista possa essere realizzata a sua volta. Il controllore ha anche il compito di generare gli arrivi dei clienti, cioè le entità cliente. I tempi di arrivo dei clienti vengono ottenuti attraverso la generazione dei tempi di inter-arrivo (intervalli fra il tempo di arrivo di un cliente e quello del cliente successivo) sulla base di una opportuna distribuzione di probabilità. Si può procedere in diversi modi. Il controllore può generare tutti i clienti prima che la simulazione inizi; i clienti poi arriveranno man mano che il tempo di simulazione avanza. Un altra possibilità è che il controllore, ogni volta che fa eseguire l attività Arrivo Cliente, genera l entità corrispondente al cliente successivo con il suo tempo di arrivo. Questo può anche essere realizzato inserendo esplicitamente fra le azioni dell attività Arrivo Cliente l operazione Genera il cliente successivo. In pratica la simulazione viene svolta per mezzo della seguente procedura, articolata in tre fasi principali 5. Nella descrizione della procedura abbiamo indicato con A l insieme delle attività elementari, con A P il sottoinsieme delle programmate e con A C il sottoinsieme delle condizionate. Inizializzazione Viene generata la prima entità cliente, con il suo tempo di arrivo, e viene con essa inizializzata una coda di priorità delle entità cliente, 5 L approccio che qui viene presentato è una implementazione del classico approccio per attività alla simulazione che è stato descritto in [1] col nome di metodo delle tre fasi.

17 2.2. Approcci alla modellazione 31 Q. Questa coda di priorità che potrebbe, ad esempio, essere implementata con un heap binario, utilizza come chiave per l ordinamento dei suoi elementi il tempo di arrivo. Avanzamento del tempo di simulazione Vengono estratte da Q tutte le entità che hanno Tempo Prossima Attività minimo, cioè quelle che saranno le prime ad essere coinvolte in una delle attività programmate; queste entità saranno poste in una lista. Il tempo di queste entità individua il tempo del prossimo cambiamento di stato del sistema, e a questo valore viene posto l orologio della simulazione, cioè il tempo corrente di simulazione T c. Questa è la fase in cui viene fatto avanzare il tempo della simulazione. Esecuzione delle attività programmate Viene estratta la prima entità dalla lista precedentemente costruita, e vengono eseguite le operazioni implicate dall attività indicata dall attributo Prossima Attività. I valori degli attributi Prossima Attività e Tempo Prossima Attività vengono cancellati e posti al valore convenzionale Nil. Questo passo viene eseguito finché la lista non risulta vuota. Esecuzione delle attività condizionate Viene esaminata l insieme A C delle attività condizionate e vengono eseguite le operazioni delle attività per cui le condizioni sono verificate. Se nel corso di una scansione della lista qualche attività si realizza, allora la lista verrà esaminata di nuovo; infatti il cambiamento dello stato del sistema può avere reso possibile il verificarsi di altre attività condizionate. Ci si ferma dopo un intera scansione che non ha portato al verificarsi di alcuna attività. Osserviamo che, a differenza della lista del passo precedente, questa lista non viene modificata nel corso della simulazione Simulazione per processi In questo approccio tutti gli eventi del ciclo di vita di una entità, con le relative operazioni, vengono vengono accorpati in una sequenza detta processo. Un processo è sostanzialmente la sequenza delle operazioni descritte dal diagramma degli stati. Ad esempio nel caso del servizio piccoli prestiti, il processo relativo al cliente C può essere pensato come costituito dalle seguenti operazioni, in cui

18 32 Capitolo 2. Simulazione discreta abbiamo usato le notazioni già introdotte a proposito della simulazione per attività. 1. Arrivo del cliente C quando il tempo di simulazione è uguale al suo tempo di arrivo, cioè T c = C.Tempo Arrivo. 2. Calcolo del tempo di arrivo del cliente successivo, C, C.Tempo Arrivo; 3. Creazione del processo relativo al cliente C ; 4. Il cliente C viene posto in stato di attesa fino a che non risulti T c = C.Tempo Arrivo; 5. Il cliente C viene inserito nella prima coda, e viene posto in stato di attesa fino a quando non si trovi in testa alla coda e risulti Impiegato.Disponibile = V ero; 6. Si pone Impiegato.Disponibile := F also, si calcola il tempo di servizio d, si pone C.Tempo Prossima Attività =T c + d, e si pone il processo in stato di attesa fino a quando T c = C.Tempo Prossima Attività; 7. Si pone Impiegato.Disponibile := V ero e si calcola C.Approvato; 8. If C.Approvato = F also, Then si inserisce C nella seconda coda Else si pone C.Esami Conclusi := V ero e si interrompe il processo; 9. Il processo viene posto in stato di attesa fino a quando C n si trova in testa alla coda e risulta Funzionario.Disponibile = V ero; 10. Si pone Funzionario.Disponibile := F also, si calcola il tempo di servizio d, si pone C.Tempo Prossima Attività = T c + d, e si pone il processo in stato di attesa fino a quando T c = C.Tempo Prossima Attività; 11. Si pone Funzionario.Disponibile := V ero e si calcola C.Approvato e si interrompe il processo. Un processo può essere attivo oppure in attesa. In quest ultimo caso, si può trattare di una attesa condizionata, quando la ripresa dell attività del processo dipende dal realizzarsi di condizioni esterne, oppure di un attesa programmata, quando il tempo in cui il processo verrà riattivato è predefinito. Nell esempio ci sono 2 attese condizionate (operazioni n.5 e n.9) e due attese programmate (operazioni n.1, n.6 e n.10).

19 2.2. Approcci alla modellazione 33 Nell esempio considerato, l impiegato ed il funzionario possono essere considerati come risorse che vengono utilizzate dai processi (clienti). In casi più complessi si possono avere diverse classi di entità e quindi tipi di processi che competono per l uso di risorse comuni. In questo caso si hanno processi che interagiscono, ciascuno condizionato dallo stato degli altri. In questo tipo di approccio, il programma di controllo deve mantenere una lista contenente, per ciascuna entità/processo due informazioni: il tempo di riattivazione (se conosciuto) ed il punto nel processo in cui la prossima riattivazione deve avvenire. Questa lista può essere suddivisa in due sottoliste: quella degli eventi futuri, che contiene i processi in attesa non condizionata ed il cui tempo di riattivazione è maggiore del tempo corrente; quella degli eventi correnti, che contiene i processi in attesa non condizionata che devono al tempo corrente essere riattivati, e tutti quelli in attesa condizionata. Questi ultimi stanno in questa lista, anche se non necessariamente verranno riattivati, perché il riattivarsi di uno degli altri può creare le condizioni per la loro riattivazione. L operazione tipica che il controllore effettua in questo tipo di approccio è: (i) esegue una scansione della sottolista degli eventi futuri, in modo da determinare il nuovo tempo di simulazione che viene quindi aggiornato; (ii) sposta dalla sottolista degli eventi futuri a quella degli eventi correnti le entità il cui tempo di riattivazione coincide con il nuovo tempo di simulazione; (iii) esegue ripetute scansioni della sottolista degli eventi correnti, cercando di spingere ciascuna entità il più avanti possibile nel suo processo (quando un entità viene posta in attesa non condizionata, essa viene spostata alla sottolista degli eventi futuri). Naturalmente all inizio il controllore deve inizializzare il sistema dando valori V ero agli attributi Disponibilità dell impiegato e del funzionario, e generando il primo cliente. L approccio per processi si presenta come molto naturale in fase di costruzione del modello, e porta a programmi di simulazione efficienti computazionalmente, e questo spiega il suo notevole successo. È infatti uno degli approcci più usati. Esso richiede però, soprattutto per modelli complessi, grande attenzione nella gestione delle interazioni tra processi: c è ad esempio il rischio che si creino situazioni di stallo. Questo fatto è particolarmente critico quando si debba intervenire su un modello già esistente, per aggiornarlo o modificarlo.

20 34 Capitolo 2. Simulazione discreta Simulazione per eventi Questo che tradizionalmente viene dato ad un approccio in cui vengono considerati solamente le attività programmate; quelle condizionate e le relative operazioni sono incorporate all interno del corpo delle attività programmate. Questo comporta un numero limitato di attività, ciascuna delle quali comportante molte operazioni. Non si tratta quindi più di attività elementari. Mancando la scansione delle attività condizionate, la simulazione risulta più efficiente computazionalmente. Ad esempio nel problema della valutazione dei prestiti, in questo approccio le attività considerate sono tre: Arrivo Cliente Fine Prima Valutazione Fine Seconda Valutazione Ciascuna di esse corrisponde ad un insieme di diverse azioni che devono essere compiute. Ad esempio, le operazioni effettuate quando si verifica l attività Fine prima valutazione sono: 1. Se l esito è positivo, si rilascia il cliente. Altrimenti lo si inserisce nella seconda coda. 2. Se la prima coda, non è vuota si prende il primo cliente dalla prima coda, si calcola il tempo di servizio ed il prossimo tempo di Fine prima valutazione. Altrimenti, si mette l impiegato in stato di attesa. Per quanto efficiente nell esecuzione, questo approccio comporta una implementazione notevolmente più complessa, con il rischio di errori. Oltre ad una maggiore complessità del debugging c è anche una maggiore complessità della manutenzione, cioè delle eventuali operazioni di modifica ed aggiornamento del programma per tenere conto dell evoluzione del sistema in esame. Il principale problema sta nella difficoltà di mantenere traccia di tutte le conseguenze di un dato evento, in occasioni di aggiornamenti o modifiche del programma. Per questo motivo questo approccio è ormai quasi completamente abbandonato.