Friendly & Interactive Schedule Helper Uno scheduler per attività umane

Transcript

1 Friendly & Interactive Schedule Helper Uno scheduler per attività umane Luca Salvatore Lorello Progetto di Ingegneria del Software, Università degli studi di Urbino. Matricola Anno accademico

2 Indice 1 Specifica del problema Struttura di un impegno Cosa fornire all esterno Interfaccia Specifica dei requisiti Specifiche contestualizzate nel dominio del problema Diagramma dei casi d uso Template dei casi d uso Analisi e progettazione Pattern utilizzati Singleton Iterator Strategy Model-View-Controller Scelte di progetto Scelte relative agli algoritmi Scelte relative alle strutture dati Scelte relative alle interazioni complesse (pattern) Diagrammi di attività Diagrammi delle classi Implementazione Processo di sviluppo utilizzato Peculiarità di C#: proprietà e indexer Implementazione in C# Namespace ShortTermScheduler Namespace ShortTermScheduler/Algorithms Namespace ShortTermScheduler/Fitters Namespace Data Namespace Tester

3 5 Test Test black-box Test white-box Compilazione ed esecuzione Requisiti di sistema Requisiti minimi Requisiti consigliati Compilazione Compilazione con MSBuild Compilazione con Visual Studio 2013 Community Edition Compilazione con Visual Studio 2013 Ultimate Edition Esecuzione

4 Diagrammi 2.1 Diagramma dei casi d uso Diagramma di attività di Scheduler.Schedule() Diagramma di attività di TesterController.TestScheduler() Diagramma di attività di SJF.GetBest() Diagramma delle classi della libreria Diagramma delle classi dell interfaccia di test

5 Template dei casi d uso 2.1 Caso d uso: Configurazione Test Caso d uso: Acquisizione manuale impegni Caso d uso: Generazione automatica impegni Caso d uso: Esecuzione test Caso d uso: Restituzione esito

6 Listati 1.1 Algoritmo di invocazione tipico del sistema Implementazione del metodo Instance() del pattern Singleton Due modi equivalenti per implementare una proprietà banale Esempio di indexer Esempi di accesso a proprietà e indexers Classe Algorithm Classe FIFO Classe SJF Classe LJF Classe Prio Classe Fitter Classe FFit Classe BFit Classe WFit Classe Job Classe Interval Classe Validator Classe Program (entrypoint del programma) Classe InputView Classe TesterController Classe OutputView Test di unità di SJF.GetBest() Compilazione tramite MSBuild in modalità Debug Compilazione tramite MSBuild in modalità Release Raggiungimento del percorso dell applicazione compilata Esecuzione dell applicazione compilata in modalità Debug Esecuzione dell applicazione compilata in modalità Release

7 Capitolo 1 Specifica del problema Si vuole realizzare un sistema che gestisca un insieme di attività umane (impegni) in maniera automatica in termini di tempi d esecuzione. Nello specifico ci si vuole limitare all organizzazione nell arco delle 24 ore, con una precisione al quarto d ora. Il sistema dovrà gestire una tabella oraria (dalle 00:00 alle 23:45) e popolarla con gli impegni forniti dall utente secondo i seguenti criteri (che dovranno essere interamente configurabili): Se l orario di esecuzione di un impegno è stato stabilito dall utente, allora non dovrà essere modificato L ordine con cui verrà popolata la tabella dovrà procedere dall impegno più importante a quello meno importante, ciò vuol dire che gli intervalli temporali migliori verranno assegnati agli impegni più importanti Il criterio di importanza verrà scelto dall utente (tra First In First Out, Shortest Job First, Longest Job First, criterio per priorità e criterio casuale) Il criterio di scelta dell intervallo migliore dovrà essere scelto dall utente (tra First Fit, Best Fit e Worst Fit) Si dovrà dare all utente la possibilità di scegliere tra un esecuzione pigra (si massimizzerà il tempo libero tra due impegni consecutivi) o efficiente (si cercherà di concentrare gli impegni a inizio giornata). Il sistema, anche in presenza di più esecutori (e quindi tabelle orarie e configurazioni), dovrà assicurare un controllo centralizzato delle decisioni per facilitare eventuali implementazioni in ambiente concorrente e/o distribuito. 6

8 1.1 Struttura di un impegno Ogni impegno è genericamente costituito da un nome, una descrizione e un identificatore univoco. Un impegno può essere di tre tipi: Normale: l utente si limita a specificare durata e/o priorità Interrompibile: l utente specifica anche una granularità con cui dividere l impegno Fissato: l utente specifica solamente ora d inizio e fine, forzando l esecuzione in quell intervallo temporale. Gli impegni interrompibili dovranno essere interrotti solo se strettamente necessario ed esattamente in frammenti di dimensione pari alla granularità imposta (ad eccezione, naturalmente, dell ultimo frammento che potrebbe avere dimensione inferiore alla granularità). Non è consentita la cancellazione di un singolo frammento di impegno interrompibile (ne è tuttavia consentita la modifica della durata e degli altri parametri) e la rimozione dovrà dunque avvenire in toto. 1.2 Cosa fornire all esterno Il sistema dovrà fornire al mondo esterno le seguenti funzionalità: Configurazione del sistema Creazione, modifica e validazione di un impegno Modifica della lista di impegni da gestire (inserimenti e rimozioni di singoli impegni e svuotamento della lista) Popolamento della tabella oraria Azzeramento delle decisioni riguardo agli impegni futuri, ma non passati e presenti (eliminazione dalla tabella oraria di tutto ciò che è futuro) Restituzione della lista di impegni inseriti in tabella oraria e della lista di impegni che non è stato possibile inserire in tabella oraria Restituzione della frammentazione (1 dimensione intervallo libero massimo tempo libero totale ) e del tempo libero (in percentuale) calcolati sulla tabella oraria corrente. 7

9 1.3 Interfaccia Si deve fornire un interfaccia dimostrativa (a linea di comando) di un flusso canonico d esecuzione che funzioni in due modalità: Manuale: l utente genera manualmente gli impegni da ordinare Semiautomatica: l utente impone il soddisfacimento di alcune condizioni statistiche e l interfaccia genera casualmente gli impegni da ordinare. I parametri statistici su cui dovrà basarsi la modalità semiautomatica sono: Numero di impegni da generare Durata media degli impegni Percentuale di impegni fissati Percentuale di impegni interrompibili. L interfaccia dimostrativa dovrà restituire: Lista di impegni inseriti Lista di impegni che il sistema ha fallito nell organizzare Tabella oraria (coppia (orario; impegno)) Percentuale di tempo libero Percentuale di frammentazione della giornata Rappresentazione grafica dell occupazione della giornata. Poiché il sistema deve fornire solo funzionalità a basso livello (come descritto nella sezione 1.2), l interfaccia dimostrativa dovrà testare un algoritmo di invocazione tipico (listato 1.1). Listato 1.1: Algoritmo di invocazione tipico del sistema 1 Sistema.Reset(); 2 foreach (Impegno i in listaimpegni) 3 { 4 Sistema.Inserisci(i); 5 } 6 Sistema.Ordina(oraCorrente); 8

10 Non si impone che la tabella oraria sia ordinata temporalmente (si delega l ordinamento ad un più alto livello d astrazione, ad esempio alla memorizzazione permanente degli impegni su database o file). Per semplicità l interfaccia non dovrà restituire valori in tempo canonico (formato hh:mm) e potrà utilizzare qualunque formato interno si ritenga appropriato in fase di analisi senza imporre alcuna conversione, sia per gli input che per gli output. L interfaccia dimostrativa non dovrà tenere conto di riordini, modifiche, eliminazioni e nuovi inserimenti durante la giornata, l esecuzione dovrà dunque essere lineare e procedere nell ordine: 1. Configurazione della libreria 2. Creazione e validazione degli impegni 3. Esecuzione dell algoritmo di popolamento 4. Restituzione dell esito all utente. 9

11 Capitolo 2 Specifica dei requisiti Osservando la specifica del problema, risulta evidente che il dominio del problema sia quello che in teoria dei sistemi operativi prende il nome di scheduling (più nello specifico la sola componente a breve termine). Il popolamento della tabella oraria deve inoltre risolvere il problema dell allocazione contigua, ben codificato nell area della teoria dei sistemi operativi che si occupa di gestione della memoria principale. 2.1 Specifiche contestualizzate nel dominio del problema Si vuole implementare uno scheduler a breve termine che operi a tempo discreto, con time quantum di dimensione 15 minuti, su un process control block che modelli delle attività umane e che contenga: Nome dell attività Descrizione dell attività Identificatore Parametri di scheduling: Durata Time quantum d inizio Time quantum di fine Priorità Granularità Flag di interrompibilità Flag di impegno fissato. 10

12 Lo scheduler dovrà simulare la preemption (possibilità di interrompere un impegno in esecuzione e di sostituirlo con uno a maggiore importanza) solo per impegni interrompibili e i possibili punti di scheduling dovranno essere forzati ad intervalli pari alla granularità dell impegno. A differenza di uno scheduler tradizionale, sarà necessario non soltanto scegliere quale impegno mandare in esecuzione, ma anche quando mandarlo in esecuzione (all interno di una tabella oraria che verrà gestita tramite gli algoritmi di allocazione contigua della memoria principale noti in letteratura). Tale vincolo aggiunge la possibilità che l impegno scelto dall algoritmo di scheduling risulti non schedulabile a causa di mancanza di spazio nella tabella, si deve dunque aggiungere una nuova struttura dati che contenga tutti gli impegni non schedulabili, lasciando all utente il compito di gestirli (eliminandoli, rinviandoli al giorno dopo, affidandoli ad un altro esecutore o altro). L intero scheduler dovrà essere configurabile (in termini di algoritmi da utilizzare), come descritto nel capitolo 1, pertanto è necessario abbandonare il forte vincolo di efficienza (algoritmi che operano in tempo costante) imposto dall applicazione tradizionale della teoria dei sistemi operativi. 2.2 Diagramma dei casi d uso Di seguito è riportato il diagramma dei casi d uso relativo alla libreria (sottosistemi Data e ShortTermScheduler) e all interfaccia dimostrativa (sottosistema Tester). Si noti che l intero sottosistema Tester può essere visto come un istanza specifica dell attore LibraryUser. 11

13 Figura 2.1: Diagramma dei casi d uso 2.3 Template dei casi d uso Nel capitolo 5 si descriverà un test black-box relativo all interfaccia dimostrativa, vengono pertanto riportati qui tutti i template dei casi d uso relativi. Poiché il processo di sviluppo utilizzato (sezione 4.1) prevede lo sviluppo orientato ai test, non è necessario effettuare dei test di tipo black-box sulla libreria (durante lo sviluppo vengono creati test white-box che coprono quasi tutti i possibili flussi d esecuzione) ed è quindi superfluo descrivere i template dei casi d uso della libreria. 12

14 Actor Preconditions Basic course of action Postconditions Alternative paths TesterUser Lo scheduler è configurato con le impostazioni predefinite. L attore effettua la scelta dell algoritmo di scheduling. L attore effettua la scelta dell algoritmo di fitting. L attore sceglie se attivare la pigrizia. L attore imposta il time quantum corrente. L attore inserisce il numero di impegni da schedulare. L attore sceglie se creare una lista d impegni manualmente o automaticamente. Lo scheduler è configurato in base alle scelte dell utente. È noto il numero di impegni che verranno schedulati. Viene eseguito il caso d uso 2.2 se si è scelto l inserimento manuale, altrimenti il caso d uso 2.3. Nel caso in cui una scelta non venga inserita correttamente (ad esempio configurazioni non contemplate dall interfaccia), l interfaccia chiede di effettuare nuovamente la scelta. Tabella 2.1: Caso d uso: Configurazione Test 13

15 Actor Preconditions Basic course of action Postconditions Alternative paths TesterUser I parametri dello scheduler sono stati impostati correttamente. È noto il numero di impegni che verranno schedulati. Per un numero di volte pari al numero di impegni acquisito: L attore inserisce il nome dell impegno L attore inserisce la descrizione dell impegno L attore inserisce il tipo dell impegno L attore inserisce la durata e la priorità se il tipo è normale o interrompibile L attore inserisce la granularità se il tipo è interrompibile L attore inserisce il time quantum d inizio e di fine se il tipo è fissato L impegno viene validato e inserito in una lista temporanea. La lista temporanea ha cardinalità pari al numero d impegni acquisito in precedenza e contiene tutti gli impegni acquisiti. L identificatore di ogni impegno è assegnato incrementalmente. Viene eseguito il caso d uso 2.4. Nel caso in cui un parametro non venga inserito correttamente (ad esempio una durata non intera), l interfaccia riprova ad acquisire il parametro. Se la validazione di un impegno fallisce (ad esempio perché il time quantum d inizio è successivo al time quantum di fine), l impegno non viene inserito e si chiede di inserirne un altro. Tabella 2.2: Caso d uso: Acquisizione manuale impegni 14

16 Actor Preconditions Basic course of action Postconditions Alternative paths TesterUser I parametri dello scheduler sono stati impostati correttamente. È noto il numero di impegni che verranno schedulati. L attore inserisce durata media degli impegni, percentuale di impegni fissati e percentuale di impegni interrompibili. Vengono generati casualmente (rispettando i parametri stabiliti dall attore) un numero di impegni pari al numero acquisito in precedenza, ogni impegno ha un identificatore casuale e univoco e, se viene validato, viene inserito in una lista temporanea. La lista temporanea ha cardinalità pari al numero d impegni acquisito in precedenza e contiene tutti gli impegni generati. Viene eseguito il caso d uso 2.4. Nel caso in cui un parametro non venga inserito correttamente (ad esempio una durata media non intera), l interfaccia effettua nuovamente la richiesta. Se un impegno generato non supera la validazione, si ritenta finché non si genera un impegno valido. Nota: la somma delle percentuali di impegni interrompibili e fissati non può superare il 100 % (1.0). Tabella 2.3: Caso d uso: Generazione automatica impegni 15

17 Actor Preconditions Basic course of action Postconditions Alternative paths TesterUser Lo scheduler è configurato. La lista temporanea contiene tutti gli impegni da schedulare. Vengono resettate le decisioni di scheduling Si inserisce ogni impegno della lista temporanea nelle liste di scheduling Si invoca lo scheduler. La tabella oraria è stata popolata. Una lista contiene eventuali impegni non schedulabili. Nessuno. Tabella 2.4: Caso d uso: Esecuzione test Actor Preconditions Basic course of action Postconditions Alternative paths TesterUser La tabella oraria è stata popolata. Una lista (eventualmente vuota) contiene gli impegni non schedulabili. L attore legge la lista degli impegni da schedulare (nel formato id: nome, descrizione). L attore legge la lista degli impegni non schedulabili (costituita dai soli id). L attore legge la lista di impegni schedulati (nel formato time quantum iniziale - time quantum finale: id). L attore legge le percentuali di fallimenti, tempo libero e frammentazione. L attore visualizza una rappresentazione grafica dell occupazione della giornata. L attore preme un tasto per terminare l esecuzione. L attore ha letto l output del programma e il programma è terminato. Nessuno. Tabella 2.5: Caso d uso: Restituzione esito 16

18 Capitolo 3 Analisi e progettazione 3.1 Pattern utilizzati Un design pattern è una descrizione di un problema di progettazione ricorrente e una sua soluzione generica, applicabile dunque un numero indefinito di volte variandone i dettagli implementativi. In genere, per descrivere un design pattern, sono necessari quattro elementi: Nome: necessario per codificare problema e soluzione in maniera rapida e univoca Problema: dominio di applicazione del pattern, può essere la descrizione di un problema specifico o di strutture generiche; a volte sono presenti anche dei vincoli da soddisfare per l applicabilità del pattern Soluzione: elementi che descrivono strutture (classi e oggetti nel contesto della programmazione orientata a oggetti) e relazioni, responsabilità e collaborazioni tra strutture atte a risolvere il problema Conseguenze: risultati e vincoli (in termini di spazio, tempo, flessibilità e via dicendo) ottenuti applicando il pattern. I design pattern si categorizzano in: Pattern creazionali: forniscono un astrazione del processo di istanziazione degli oggetti, gli elementi fondamentali di un pattern creazionale sono la capacità di incapsulare la conoscenza delle classi concrete da utilizzare e di nasconderne le modalità di creazione e composizione Pattern strutturali: implementano modalità di composizione di classi (per comporre interfacce e implementazioni) e oggetti (per creare nuove funzionalità) atte a formare strutture complesse 17

19 Pattern comportamentali: implementano algoritmi e assegnano responsabilità tra oggetti collaboranti, possono operare su classi, oggetti o sulla comunicazione tra oggetti, risolvono problemi causati da flussi di controllo complessi spostando l attenzione sul modo in cui si interconnettono i vari oggetti. Si noti che l interpretazione della natura di un pattern dipende fortemente dal livello di astrazione utilizzato: a bassi livelli d astrazione un pattern è qualcosa da implementare, ad alti livelli invece si riconduce ad una primitiva fornita dal linguaggio di programmazione usato (ad esempio è stato necessario implementare il pattern Singleton, descritto in sezione 3.1.1, mentre il pattern Iterator, sezione 3.1.2, è già implementato dalla libreria standard di C# come interfaccia IIterator o come costrutto foreach). La scelta del paradigma e del linguaggio di programmazione influiscono molto anche su cosa considerare pattern, ad esempio il polimorfismo è una funzionalità fondamentale del paradigma a oggetti, mentre può essere considerato un pattern nel paradigma procedurale. I design pattern utilizzati per lo scheduler sono stati Singleton, Iterator e Strategy. Per l interfaccia dimostrativa si è usato Model-View-Controller che non è un design pattern, bensì un pattern architetturale, ossia una descrizione di un problema architetturale (anziché progettuale) ricorrente con la relativa soluzione Singleton Singleton è un pattern creazionale basato su oggetti che risolve il problema di assicurare che per una classe esista un unica istanza accessibile con semplicità, facendo in modo che sia la classe stessa ad istanziarsi. Singleton è applicabile quando: Deve esistere un unica istanza di una classe accessibile da un riferimento noto a tutti gli utilizzatori L unica istanza deve essere estesa con sottoclassi e anch esse devono ammettere un unica istanza. Per far funzionare correttamente il pattern, il costruttore della classe deve essere privato (nel caso in cui si debba verificare la prima precondizione) o protetto (nel caso in cui si debba verificare la seconda). L implementazione di Singleton consiste nella creazione di un metodo pubblico e statico (in genere chiamato Instance) che restituisce il riferimento all istanza, non accessibile direttamente dall esterno, dell oggetto (in genere contenuta nell attributo privato _instance), se il riferimento è nullo, invoca il costruttore prima di restituirlo. Listato 3.1: Implementazione del metodo Instance() del pattern Singleton 18

20 1 if (_instance == NULL) { 2 _instance = new Singleton(); 3 } 4 return _instance; Le conseguenze dell applicazione di Singleton sono: Controllo stretto dell accesso all istanza (in termini di modalità e tempi di accesso da parte degli utilizzatori) poiché viene incapsulata dal metodo Instance Riduzione dello spazio dei nomi rispetto all utilizzo di variabili globali Possibilità di estendere la classe singleton con sottoclassi che avranno a loro volta un unica istanza (le sottoclassi possono fare override del metodo Instance, sfruttando il costruttore protetto della classe base) Possibilità di convertire facilmente l implementazione di Singleton in un implementazione di Multiton (pattern che prevede l utilizzo di un numero di istanze finito o comunque tenuto sotto controllo dalla classe stessa) Maggiore flessibilità rispetto all utilizzo di classi statiche (in alcuni linguaggi, come il C++, le classi statiche non possono sfruttare il polimorfismo) Iterator Iterator (anche noto come Cursor) è un pattern comportamentale basato su oggetti che risolve il problema della visita di una struttura dati complessa, senza esporne la struttura interna e permettendo l attraversamento da parte di utilizzatori diversi (con i singoli elementi correnti indipendenti tra loro). Iterator è applicabile quando: È necessario accedere al contenuto di un oggetto contenitore senza esporne la struttura interna Sono necessari attraversamenti contemporanei di uno stesso oggetto contenitore È necessario fornire un interfaccia comune a classi contenitore diverse, ovvero fornire un attraversamento polimorfico. La responsabilità dell attraversamento viene gestita da un oggetto esterno che tiene traccia dell elemento corrente e fornisce un interfaccia di accesso (in genere con metodi che restituiscono gli elementi primo e corrente della struttura dati, un metodo di avanzamento all elemento successivo e un metodo di controllo del raggiungimento della fine della struttura dati). Grazie 19

21 al disaccoppiamento tra struttura dati e oggetto iteratore, è possibile implementare diverse politiche di attraversamento, ad esempio per una struttura Tree si potrebbero creare gli iteratori TreePreIterator, TreeInIterator e Tree- PostIterator che implementano rispettivamente le visite pre-order, in-order e post-order dell albero. Si noti che un classe iteratore sarà fortemente dipendente dalla classe della struttura dati da iterare, perciò per implementare iteratori polimorfici (in modo che l utilizzatore non modifichi il proprio codice per strutture di tipo diverso), e necessario definire due classi astratte, dalla prima deriveranno tutte le strutture dati da utilizzare e dalla seconda tutti gli iteratori, in modo che ogni sottoclasse iteratrice possa implementare la visita di ogni struttura dati. La creazione di un iteratore polimorfico è di responsabilità della classe astratta da cui derivano le strutture dati, fornendo un metodo (in genere chiamato CreateIterator) che implementa il pattern Factory Method (un pattern creazionale basato su classi che definisce un interfaccia di creazione di un oggetto di una classe, lasciando però alle sottoclassi la decisione di cosa istanziare, ovvero implementa un meccanismo atto a rendere polimorfica la creazione di un oggetto) per poter istanziare l iteratore corrispondente ad ogni sottoclasse della struttura dati. Le conseguenze dell applicazione di Iterator sono: Gestione di varianti della visita di una struttura dati, tramite semplice sostituzione delle istanze degli iteratori utilizzati Semplificazione dell interfaccia della struttura dati, in quanto la visita è delegata all oggetto iteratore Gestione di visite multiple da parte di più utilizzatori su una stessa istanza della struttura dati semplificata. In C#, il pattern Iterator è implementato nativamente dal costrutto foreach e dall interfaccia generica di libreria standard IIterator<T>; per essere visitabile con foreach, una struttura dati deve estendere l interfaccia IIEnumerable<T> (implementando il metodo GetEnumerator) Strategy Strategy è un pattern comportamentale basato su oggetti che risolve il problema di definire una famiglia di algoritmi intercambiabili dinamicamente senza dover cambiare il codice nella classe che li utilizza. Strategy è applicabile quando: Esistono molte classi che differiscono solo per il comportamento Sono necessarie più varianti di un algoritmo 20

22 Un algoritmo utilizza strutture dati interne che devono essere nascoste al client Sono presenti istruzioni switch contenenti comportamenti multipli e vanno sostituite con qualcosa di più manutenibile. L implementazione di Strategy consiste nella creazione di un interfaccia Strategy che verrà implementata dalle classi dei singoli algoritmi e che fornisce un unico metodo d esecuzione dell algoritmo e nella creazione di una classe Context che contiene la struttura dati su cui opera l algoritmo e un riferimento a una classe derivata di Strategy e fornisce dei metodi per l esecuzione e per la scelta dell algoritmo (in genere consiste semplicemente nel passare al costruttore di Context un istanza di una classe derivata da Strategy), senza esporre al mondo esterno né l algoritmo, né la struttura dati usati. Le conseguenze dell applicazione di Strategy sono: Definizione di una famiglia di algoritmi simili tra loro e riusabili Creazione di un alternativa all ereditarietà che rende più leggibile il codice (implementare lo stesso comportamento tramite ereditarietà semplice gestirebbe insieme algoritmi e strutture dati all interno di classi derivate da quella che nel pattern corrisponde a Context) Rimozione di istruzioni switch utilizzate per gestire algoritmi simili Possibilità scegliere a tempo d esecuzione più implementazioni dello stesso algoritmo Necessità dei client di conoscere a priori quali implementazioni esistano, aggiungendo di fatto una dipendenza per ogni algoritmo implementato (a causa di questo svantaggio, Strategy viene implementato solo quando è il client a richiedere la necessità di variare dinamicamente algoritmo) Costo elevato per la collaborazione tra Context e Strategy in quanto alcuni algoritmi potrebbero non usare tutti i dati forniti da Context (ad esempio la famiglia di algoritmi di ricerca del percorso minimo su un grafo ha la necessità di lavorare su liste o matrici, non essendo noto a priori quale algoritmo usare, Context dovrà memorizzarle entrambe e renderle consistenti ad ogni modifica) Se non utilizzato insieme al pattern Flyweight (pattern strutturale che accorpa insieme più oggetti di piccole dimensioni per ridurne il numero), Strategy potrebbe portare alla creazione di troppi oggetti per famiglie di algoritmi numerose. 21

23 3.1.4 Model-View-Controller Model-View-Controller (MVC) è un pattern architetturale utilizzato per l implementazione di interfacce utente che disaccoppia la logica funzionale dalla sua rappresentazione in tre componenti (chiamate Model, View e Controller, come suggerisce il nome del pattern). Il Model è costituito dalla logica funzionale, il View dall interfaccia con cui interagisce l utente e il Controller costituisce la componente intermedia tra Model e View (implementa metodi di passaggio dei valori tra Model e View, di validazione degli input, di memorizzazione permanente e via dicendo). È possibile progettare un architettura MVC partendo da un diagramma di robustezza, semplicemente convertendo ogni oggetto Entity in una classe Model, ogni oggetto Control in una classe Controller, ogni oggetto Boundary in una classe View e ogni relazione da un oggetto a un altro in una chiamata, da parte del primo, di un metodo del secondo. Un diagramma di robustezza deve soddisfare i seguenti vincoli: Un oggetto Boundary può comunicare solo con attori (oggetti che modellano gli utenti del sistema) e oggetti Control Un oggetto Entity può comunicare solo con oggetti Control Un oggetto Control può comunicare con oggetti di qualsiasi tipo, esclusi attori. Un operazione nota come analisi di robustezza permette di creare un diagramma di robustezza procedendo incrementalmente a partire da un diagramma UML dei casi d uso e trasformando i singoli casi d uso in oggetti Entity, Boundary o Control e aggiungendo, se necessario, nuovi oggetti intermedi (in genere Control) in modo che il diagramma finale soddisfi i vincoli per ogni oggetto. Grazie a questa conversione semiautomatica è possibile generare un architettura MVC con estrema semplicità a partire dai requisiti. 3.2 Scelte di progetto Scelte relative agli algoritmi Il vincolo riguardante la configurabilità degli algoritmi di scheduling e di fitting, impone di sovrascrivere dinamicamente il comportamento dello scheduler in base alla coppia di algoritmi scelti, poiché ci sono cinque algoritmi di scheduling e tre algoritmi di fitting, si avrebbero quindici comportamenti diversi da implementare (senza contare il parametro di pigrizia, che porterebbe a trenta le implementazioni) che tuttavia differiscono di poco tra loro, i 22

24 principi della programmazione orientata agli oggetti di astrazione e polimorfismo permettono una soluzione più elegante del problema, rendendo inoltre possibile un espandibilità futura del sistema. La gestione della pigrizia può avvenire in tre punti, nella classe Scheduler, nella classe base Fitter (tramite metodo protetto non sovrascritto dalle classi derivate) oppure nelle singole classi derivate da Fitter. Poiché le specifiche non indicano come implementare la pigrizia, sfruttando tale libertà, si è optato per l implementazione più semplice, ossia il posizionamento di un impegno esattamente a metà dell intervallo scelto (ad esempio se per un impegno di durata cinque time quantum viene scelto un intervallo di ampiezza nove time quantum, l impegno verrà posizionato lasciando due time quantum liberi prima e due dopo). L indeterminatezza di tale specifica però ha anche lo svantaggio di poter essere molto probabilmente modificata in futuro, pertanto per l implementazione si è scelta la variante più flessibile: implementare la gestione della pigrizia nelle singole classi derivate (in modo che, teoricamente, ognuna possa utilizzare implementazioni diverse senza vincoli). In un sistema operativo tradizionale, l interruzione di un processo può avvenire in due situazioni: Se il processo rilascia volontariamente l esecuzione (in caso di attese di interrupt, IO, sincronizzazione o altro, il processo rilascia la CPU e lo scheduler sceglie un altro processo) Se lo scheduler è preemptive e sopraggiunge un processo più importante che quindi ha maggiore diritto ad eseguire. Le specifiche del problema non contemplano la possibilità che si verifichi la prima situazione, la seconda è modellata dalla specifica sugli impegni interrompibili. Per modellare il vincolo secondo il quale un impegno può essere interrotto solo al sopraggiungere di un impegno più importante, è necessario forzare l utilizzo dell algoritmo di fitting First Fit con pigrizia disattiva, infatti si tratta dell unica configurazione in grado di minimizzare il numero di interruzioni, fornendo anche l effetto collaterale di permettere l utilizzo di impegni interrompibili come filler in grado di ridurre la frammentazione. Il modo più semplice per implementare un impegno interrompibile consiste nel dividerlo in più sottoimpegni di dimensione pari alla granularità e che condividono lo stesso identificatore, infatti, avendo lo stesso identificatore, verranno eliminati tutti i frammenti dalla funzionalità di rimozione e, avendo gli stessi parametri di scheduling, verranno schedulati da qualsiasi algoritmo (ad eccezione, ovviamente, dell algoritmo casuale) uno di seguito all altro (ricordando che a parità di parametri, la scelta tra più impegni avviene secondo algoritmo FIFO, nel momento in cui viene scelto il primo frammento, tutti gli altri frammenti verranno scelti subito dopo e solo alla 23

25 fine verrà scelto un nuovo impegno perché questo è l ordine con cui sono stati inseriti). Poiché gli impegni fissati sono, di fatto, impegni su cui lo scheduler non può operare, conviene smistarli in una lista separata che verrà attraversata in ordine FIFO e su cui non opererà l algoritmo di fitting (l intervallo di posizionamento di un impegno fissato è noto a priori). Non ha senso azzerare le decisioni di scheduling relative al passato, pertanto il metodo di azzeramento delle decisioni (flush dello scheduler) dovrà prima ricercare l impegno attualmente in esecuzione, determinarne il punto di fine e azzerare le decisioni a partire da quel punto, le specifiche richiedono già un metodo di ricerca dell impegno corrente (che si limita a cercare nella lista degli impegni schedulati l unico che ha time quantum iniziale minore o uguale al time quantum corrente e il time quantum finale maggiore), pertanto verrà riusato anche all interno del flush. L algoritmo di test è già stato descritto nel template 2.4, non è necessario dunque ripetere come opera Scelte relative alle strutture dati Come già accennato nella sezione 3.2.1, conviene smistare gli impegni fissati da tutti gli altri, in realtà conviene anche smistare tra impegni schedulati, da schedulare e non schedulabili, ottenendo pertanto quattro liste (la scelta delle liste come strutture dati risulta la più naturale per un insieme di dati omogenei e di dimensione variabile): Impegni fissati da schedulare Impegni non fissati da schedulare (grazie alla gestione degli impegni interrompibili come più frammenti, non è necessario distinguere tra impegni normali e interrompibili) Impegni schedulati Impegni non schedulabili. Da specifica, la durata di un time quantum è costante, pertanto anche il numero di time quantum contenuti in una giornata lo è. La struttura dati che modella gli intervalli è un semplice array booleano (ovviamente incapsulato) di dimensione pari al numero di time quantum della giornata che offre dei metodi aggiuntivi (ad esempio il calcolo della frammentazione). Un valore vero alla posizione n indica che il time quantum n-esimo è occupato, mentre un valore falso indica che il time quantum è libero. Un impegno è una semplice struttura dati che contiene i campi necessari allo scheduling, per garantire il corretto funzionamento dello scheduler, è necessario validarne il contenuto controllando che: 24

26 In un impegno fissato time quantum iniziale e finale devono essere definiti e, rispettivamente, minore dell ultimo time quantum della giornata e compreso tra time quantum iniziale e minore dell ultimo time quantum della giornata In un impegno non fissato time quantum iniziale e finale non devono essere definiti e la durata deve essere un valore positivo e minore del numero di time quantum rimanenti alla fine della giornata. Si noti che la conoscenza del time quantum corrente impossibilita la validazione dell impegno all interno dei setter degli attributi, si è optato per l implementazione di una classe statica il cui unico scopo è quello di validare gli impegni Scelte relative alle interazioni complesse (pattern) Il vincolo sul controllo centralizzato delle decisioni è banalmente implementato se si impone che durante l esecuzione sia presente un solo scheduler, il pattern più appropriato allo scopo è Singleton (sezione 3.1.1). Modellando lo scheduler come una classe Scheduler, che opera delegando alle classi base Algorithm e Fitter l effettiva esecuzione degli algoritmi (che verranno sovrascritti dalle classi derivate), si ottiene un implementazione del pattern Strategy (sezione 3.1.3), dove la classe Context coincide con la classe Scheduler (le strutture dati incapsulate sono le liste di scheduling e l istanza di Interval). In realtà le due classi implementano una variante polimorfica del pattern, in quanto, anziché essere interfacce, si tratta di classi che offrono un comportamento base che verrà sovrascritto dalle classi derivate (la classe Algorithm implementa l algoritmo casuale, mentre la classe Fitter restituisce un eccezione NotSupportedException, si è preferito infatti rimanere consistenti anziché implementare contemporaneamente Strategy vero e proprio e la variante polimorfica). Per quanto riguarda l interfaccia dimostrativa, si è implementato il pattern Model-View-Controller (sezione 3.1.4), dove il Model è costituito dalla classe di scheduling, il Controller implementa l algoritmo di test e due View implementano rispettivamente l acquisizione dell input dell utente e la restituzione dell output. 3.3 Diagrammi di attività Di seguito sono riportati i diagrammi di attività dei metodi Scheduler.Schedule() (diagramma 3.1), TesterController.TestScheduler() (diagramma 3.2) e SJF.GetBest() (diagramma 3.3). Il diagramma 3.1 descrive il comportamento del metodo chiave dell intero sistema, mentre il diagramma 3.2 aiuta a visualizzare meglio l algoritmo descritto dal template

27 Il diagramma 3.3 mostra il funzionamento di uno degli algoritmi di scheduling e sarà utilizzato nel capitolo 5 per esemplificare uno dei test di unità usati durante lo sviluppo. Figura 3.1: Diagramma di attività di Scheduler.Schedule() 26

28 Figura 3.2: Diagramma di attività di TesterController.TestScheduler() 27

29 Figura 3.3: Diagramma di attività di SJF.GetBest() 28

30 3.4 Diagrammi delle classi Figura 3.4: Diagramma delle classi della libreria 29

31 Figura 3.5: Diagramma delle classi dell interfaccia di test 30