Friendly & Interactive Schedule Helper Uno scheduler per attività umane

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1 DIAGRAMMI A BLOCCHI TEORIA ED ESERCIZI 1 1 Il linguaggio dei diagrammi a blocchi è un possibile formalismo per la descrizione di algoritmi Il diagramma a blocchi, o flowchart, è una rappresentazione grafica

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

I file di dati. Unità didattica D1 1

I file di dati. Unità didattica D1 1 I file di dati Unità didattica D1 1 1) I file sequenziali Utili per la memorizzazione di informazioni testuali Si tratta di strutture organizzate per righe e non per record Non sono adatte per grandi quantità

Dettagli

FASE DEBUGGING: Compiler Linker. controllando che la voce Genera le informazioni per il debug cioè. "Generate debugging information"

FASE DEBUGGING: Compiler Linker. controllando che la voce Genera le informazioni per il debug cioè. Generate debugging information FASE DEBUGGING: Prima della compilazione, si devono inserire 1 nel progetto informazioni per il debug cioè si devono visualizzare le opzioni di progetto seguendo il percorso: controllando che la voce Genera

Dettagli

La fase di realizzazione. La fase di realizzazione (cont.) Traduzione in Java del diagramma degli use case

La fase di realizzazione. La fase di realizzazione (cont.) Traduzione in Java del diagramma degli use case Università degli Studi di Roma La Sapienza Corso di Laurea in Ingegneria dell Informazione Sede di Latina Corso di Laurea in Ingegneria dell Informazione Consorzio Nettuno La fase di realizzazione si occupa

Dettagli

Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati

Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati Condizione di sincronizzazione Qualora si voglia realizzare una determinata politica di gestione delle risorse,la decisione se ad

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Classi ed Oggetti in JAVA

Classi ed Oggetti in JAVA Classi ed Oggetti in JAVA Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dell Informazione Università di Siena Via Roma 56 53100 SIENA Uff. 0577233606 rigutini@dii.unisi.it www.dii.unisi.it/~rigutini/

Dettagli

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Scuola Specializzazione Istruzione Superiore Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Michele Batocchi ITC Vittorio Emanuele II Perugia A.S. 2007/2008 Introduzione

Dettagli

Elementi di semantica denotazionale ed operazionale

Elementi di semantica denotazionale ed operazionale Elementi di semantica denotazionale ed operazionale 1 Contenuti! sintassi astratta e domini sintattici " un frammento di linguaggio imperativo! semantica denotazionale " domini semantici: valori e stato

Dettagli

Quando A e B coincidono una coppia ordinata é determinata anche dalla loro posizione.

Quando A e B coincidono una coppia ordinata é determinata anche dalla loro posizione. Grafi ed Alberi Pag. /26 Grafi ed Alberi In questo capitolo richiameremo i principali concetti di due ADT che ricorreranno puntualmente nel corso della nostra trattazione: i grafi e gli alberi. Naturale

Dettagli

Esercizi Capitolo 5 - Alberi

Esercizi Capitolo 5 - Alberi Esercizi Capitolo 5 - Alberi Alberto Montresor 19 Agosto, 2014 Alcuni degli esercizi che seguono sono associati alle rispettive soluzioni. Se il vostro lettore PDF lo consente, è possibile saltare alle

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti Dai sistemi concorrenti ai sistemi distribuiti Problemi nei sistemi concorrenti e distribuiti I sistemi concorrenti e distribuiti hanno in comune l ovvio problema di coordinare le varie attività dei differenti

Dettagli

Descrizioni VHDL Behavioral

Descrizioni VHDL Behavioral 1 Descrizioni VHDL Behavioral In questo capitolo vedremo come la struttura di un sistema digitale è descritto in VHDL utilizzando descrizioni di tipo comportamentale. Outline: process wait statements,

Dettagli

Programmazione Java: Variabili membro, Metodi La parola chiave final

Programmazione Java: Variabili membro, Metodi La parola chiave final Programmazione Java: Variabili membro, Metodi La parola chiave final romina.eramo@univaq.it http://www.di.univaq.it/romina.eramo/tlp Roadmap Definire una classe» Variabili membro» Metodi La parola chiave

Dettagli

Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera

Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera L. De Giovanni AVVERTENZA: le note presentate di seguito non hanno alcuna pretesa di completezza, né hanno lo scopo di sostituirsi

Dettagli

AA 2006-07 LA RICORSIONE

AA 2006-07 LA RICORSIONE PROGRAMMAZIONE AA 2006-07 LA RICORSIONE AA 2006-07 Prof.ssa A. Lanza - DIB 1/18 LA RICORSIONE Il concetto di ricorsione nasce dalla matematica Una funzione matematica è definita ricorsivamente quando nella

Dettagli

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table Universita' di Ferrara Dipartimento di Matematica e Informatica Algoritmi e Strutture Dati Rappresentazione concreta di insiemi e Hash table Copyright 2006-2015 by Claudio Salati. Lez. 9a 1 Rappresentazione

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

! Programmazione strutturata ! TDA. ! Classi, incapsulamento, ! OO. ! Scambio messaggi, eredità, polimorfismo. ! OO in Java

! Programmazione strutturata ! TDA. ! Classi, incapsulamento, ! OO. ! Scambio messaggi, eredità, polimorfismo. ! OO in Java Riassunto Rassegna API - 1 Stefano Mizzaro Dipartimento di matematica e informatica Università di Udine http://www.dimi.uniud.it/mizzaro/ mizzaro@uniud.it Programmazione, lezione 17 3 maggio 2015! Programmazione

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Algebra di Boole: Concetti di base. Fondamenti di Informatica - D. Talia - UNICAL 1. Fondamenti di Informatica

Algebra di Boole: Concetti di base. Fondamenti di Informatica - D. Talia - UNICAL 1. Fondamenti di Informatica Fondamenti di Informatica Algebra di Boole: Concetti di base Fondamenti di Informatica - D. Talia - UNICAL 1 Algebra di Boole E un algebra basata su tre operazioni logiche OR AND NOT Ed operandi che possono

Dettagli

P a s q u a l e t t i V e r o n i c a

P a s q u a l e t t i V e r o n i c a PHP: OOP Pasqualetti Veronica Oggetti Possiamo pensare ad un oggetto come ad un tipo di dato più complesso e personalizzato, non esistente fra i tipi tradizionali di PHP, ma creato da noi. 2 Gli oggetti

Dettagli

PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI

PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI PROBLEMA DELLA RICERCA in termini generali: Dati in input un insieme S di elementi (numeri, caratteri, stringhe, ) e un elemento

Dettagli

Sistemi Operativi Sincronizzazione tra Processi

Sistemi Operativi Sincronizzazione tra Processi Sistemi Operativi Processi Docente: Claudio E. Palazzi cpalazzi@math.unipd.it Crediti per queste slides al Prof. Tullio Vardanega 1 Processi indipendenti possono avanzare concorrentemente senza alcun vincolo

Dettagli

Sottoprogrammi: astrazione procedurale

Sottoprogrammi: astrazione procedurale Sottoprogrammi: astrazione procedurale Incapsulamento di un segmento di programma presente = false; j = 0; while ( (j

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Ricerca sequenziale di un elemento in un vettore

Ricerca sequenziale di un elemento in un vettore Ricerca sequenziale di un elemento in un vettore La ricerca sequenziale o lineare è utilizzata per ricercare i dati in un vettore NON ordinato. L algoritmo di ricerca sequenziale utilizza quan non ha alcuna

Dettagli

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java]

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java] Desideriamo realizzare una applicazione web che ci consenta di calcolare il fattoriale di un numero. L'esercizio in sé non particolarmente difficile, tuttavia esso ci consentirà di affrontare il problema

Dettagli

PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++

PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++ PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++ Classi ed oggetti. Classi derivate, ereditarietà e polimorfismo. Template Capitoli 12, 13, 14 Luis Joyannes Aguilar. Fondamenti di Programmazione in C++. Algoritmi,

Dettagli

Le Stringhe. Un introduzione operativa. Luigi Palopoli

Le Stringhe. Un introduzione operativa. Luigi Palopoli Le Stringhe p.1/19 Le Stringhe Un introduzione operativa Luigi Palopoli ReTiS Lab - Scuola Superiore S. Anna Viale Rinaldo Piaggio 34 Pontedera - Pisa Tel. 050-883444 Email: palopoli@sssup.it URL: http://feanor.sssup.it/

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Manipolazione di testi: espressioni regolari

Manipolazione di testi: espressioni regolari Manipolazione di testi: espressioni regolari Un meccanismo per specificare un pattern, che, di fatto, è la rappresentazione sintetica di un insieme (eventualmente infinito) di stringhe: il pattern viene

Dettagli

Funzioni. Corso di Fondamenti di Informatica

Funzioni. Corso di Fondamenti di Informatica Dipartimento di Informatica e Sistemistica Antonio Ruberti Sapienza Università di Roma Funzioni Corso di Fondamenti di Informatica Laurea in Ingegneria Informatica (Canale di Ingegneria delle Reti e dei

Dettagli

esercizi Esercizi / problemi

esercizi Esercizi / problemi Sistemi informativi applicati (reti di calcolatori): esercizi 1 Esercizi / problemi 1. Creare un applicazione che calcoli la media aritmetica dei seguenti valori interi: 35, 117, 23 e ne visualizzi il

Dettagli

Ambienti di sviluppo integrato

Ambienti di sviluppo integrato Ambienti di sviluppo integrato Un ambiente di sviluppo integrato (IDE - Integrated Development Environment) è un ambiente software che assiste i programmatori nello sviluppo di programmi Esso è normalmente

Dettagli

Progettazione Orientata agli Oggetti

Progettazione Orientata agli Oggetti Progettazione Orientata agli Oggetti Sviluppo del software Ciclo di vita del software: comprende tutte le attività dall analisi iniziale fino all obsolescenza (sviluppo, aggiornamento, manutenzione) Procedimento

Dettagli

Ricapitoliamo. Ricapitoliamo

Ricapitoliamo. Ricapitoliamo Ricapitoliamo Finora ci siamo concentrati sui processi computazionali e sul ruolo che giocano le procedure nella progettazione dei programmi In particolare, abbiamo visto: Come usare dati primitivi (numeri)

Dettagli

Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi

Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi Le funzioni di shell La bash supporta la programmazione procedurale e prevede la possibilità di definire funzioni utilizzando le sintassi alternative: function nome { lista-comandi } oppure nome ( ) {

Dettagli

Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova. Metodi per supportare le decisioni relative alla gestione di progetti

Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova. Metodi per supportare le decisioni relative alla gestione di progetti Project Management Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Project Management 2 Metodi per supportare le decisioni relative alla gestione di progetti esempi sono progetti nell

Dettagli

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

Dettagli

Accuratezza di uno strumento

Accuratezza di uno strumento Accuratezza di uno strumento Come abbiamo già accennato la volta scora, il risultato della misurazione di una grandezza fisica, qualsiasi sia lo strumento utilizzato, non è mai un valore numerico X univocamente

Dettagli

Tipicamente un elaboratore è capace di trattare domini di dati di tipi primitivi

Tipicamente un elaboratore è capace di trattare domini di dati di tipi primitivi TIPI DI DATO Tipicamente un elaboratore è capace di trattare domini di dati di tipi primitivi numeri naturali, interi, reali caratteri e stringhe di caratteri e quasi sempre anche collezioni di oggetti,

Dettagli

GUIDA RAPIDA emagister-agora Edizione BASIC

GUIDA RAPIDA emagister-agora Edizione BASIC GUIDA RAPIDA emagister-agora Edizione BASIC Introduzione a emagister-agora Interfaccia di emagister-agora Configurazione dell offerta didattica Richieste d informazioni Gestione delle richieste d informazioni

Dettagli

/** * VETTORE DINAMICO elementi */ private Vector elementi; /** * METODO COSTRUTTORE */ public coda() { elementi=new Vector(); }

/** * VETTORE DINAMICO elementi */ private Vector elementi; /** * METODO COSTRUTTORE */ public coda() { elementi=new Vector(); } import java.util.*; class coda * Questa classe contiene tutti i metodi per la gestione della coda * @author D'Ambrosio Giovanni Classe 4D I.T.I.S. Grottaminarda * @version 26/02/2010 * VETTORE DINAMICO

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Lezione III: Oggetti ASP e interazione tramite form HTML

Lezione III: Oggetti ASP e interazione tramite form HTML Lezione III: Oggetti ASP e interazione tramite form HTML La terza lezione, come le precedenti, ha avuto una durata di due ore, di cui una in aula e l altra in laboratorio, si è tenuta alla presenza della

Dettagli

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. - lezione 14 - Thread in Java

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. - lezione 14 - Thread in Java Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008 Alessandro Longheu http://www.diit.unict.it/users/alongheu alessandro.longheu@diit.unict.it - lezione 14 - Thread in Java 1 Cos è un

Dettagli

Gli algoritmi. Gli algoritmi. Analisi e programmazione

Gli algoritmi. Gli algoritmi. Analisi e programmazione Gli algoritmi Analisi e programmazione Gli algoritmi Proprietà ed esempi Costanti e variabili, assegnazione, istruzioni, proposizioni e predicati Vettori e matrici I diagrammi a blocchi Analisi strutturata

Dettagli

Visibilità dei Membri di una Classe

Visibilità dei Membri di una Classe Visibilità dei Membri di una Classe Lezione 10 Ogni classe definisce un proprio scope racchiude il codice contenuto nella definizione della classe e di tutti i suoi membri ogni metodo della classe definisce

Dettagli

Arduino: Programmazione

Arduino: Programmazione Programmazione formalmente ispirata al linguaggio C da cui deriva. I programmi in ARDUINO sono chiamati Sketch. Un programma è una serie di istruzioni che vengono lette dall alto verso il basso e convertite

Dettagli

Architettura dei Calcolatori

Architettura dei Calcolatori Architettura dei Calcolatori Sistema di memoria parte prima Ing. dell Automazione A.A. 2011/12 Gabriele Cecchetti Sistema di memoria parte prima Sommario: Banco di registri Generalità sulla memoria Tecnologie

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Le Liste. Elisa Marengo. Università degli Studi di Torino Dipartimento di Informatica. Elisa Marengo (UNITO) Le Liste 1 / 31

Le Liste. Elisa Marengo. Università degli Studi di Torino Dipartimento di Informatica. Elisa Marengo (UNITO) Le Liste 1 / 31 Le Liste Elisa Marengo Università degli Studi di Torino Dipartimento di Informatica Elisa Marengo (UNITO) Le Liste 1 / 31 Cos è una Lista Una lista è una collezione di elementi omogenei che: potrebbero

Dettagli

GeoGebra 4.2 Introduzione all utilizzo della Vista CAS per il secondo biennio e il quinto anno

GeoGebra 4.2 Introduzione all utilizzo della Vista CAS per il secondo biennio e il quinto anno GeoGebra 4.2 Introduzione all utilizzo della Vista CAS per il secondo biennio e il quinto anno La Vista CAS L ambiente di lavoro Le celle Assegnazione di una variabile o di una funzione / visualizzazione

Dettagli

INTRODUZIONE, LINGUAGGIO, HANDS ON. Giuseppe Cirillo g.cirillo@unina.it

INTRODUZIONE, LINGUAGGIO, HANDS ON. Giuseppe Cirillo g.cirillo@unina.it INTRODUZIONE, LINGUAGGIO, HANDS ON Giuseppe Cirillo g.cirillo@unina.it Il linguaggio C 1972-Dennis Ritchie 1978-Definizione 1990-ANSI C 1966 Martin Richars (MIT) Semplificando CPL usato per sviluppare

Dettagli

Bloodshed Dev-C++ è l IDE usato durante le esercitazioni/laboratorio. IDE = Integrated Development Environment

Bloodshed Dev-C++ è l IDE usato durante le esercitazioni/laboratorio. IDE = Integrated Development Environment Bloodshed Dev-C++ Bloodshed Dev-C++ è l IDE usato durante le esercitazioni/laboratorio IDE = Integrated Development Environment Gerardo Pelosi 01 Ottobre 2014 Pagina 1 di 8 Dev-C++ - Installazione Potete

Dettagli

Fondamenti dell Informatica Ricorsione e Iterazione Simona Ronchi Della Rocca (dal testo: Kfoury, Moll and Arbib, cap.5.2)

Fondamenti dell Informatica Ricorsione e Iterazione Simona Ronchi Della Rocca (dal testo: Kfoury, Moll and Arbib, cap.5.2) Fondamenti dell Informatica Ricorsione e Iterazione Simona Ronchi Della Rocca (dal testo: Kfoury, Moll and Arbib, cap.5.2) Definiamo innanzitutto una relazione d ordine tra le funzioni. Siano φ e ψ funzioni

Dettagli

Informatica Applicata

Informatica Applicata Ing. Irina Trubitsyna Concetti Introduttivi Programma del corso Obiettivi: Il corso di illustra i principi fondamentali della programmazione con riferimento al linguaggio C. In particolare privilegia gli

Dettagli

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

Le formule possono essere scritte utilizzando un insieme di funzioni predefinite che Excel mette a disposizione, raggruppate per argomento.

Le formule possono essere scritte utilizzando un insieme di funzioni predefinite che Excel mette a disposizione, raggruppate per argomento. Excel: le funzioni Le formule possono essere scritte utilizzando un insieme di funzioni predefinite che Excel mette a disposizione, raggruppate per argomento. DEFINIZIONE: Le funzioni sono dei procedimenti

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Dati importati/esportati

Dati importati/esportati Dati importati/esportati Dati importati Al workspace MATLAB script Dati esportati file 1 File di testo (.txt) Spreadsheet Database Altro Elaborazione dati Grafici File di testo Relazioni Codice Database

Dettagli

Iniziamo con un esercizio sul massimo comun divisore: Esercizio 1. Sia d = G.C.D.(a, b), allora:

Iniziamo con un esercizio sul massimo comun divisore: Esercizio 1. Sia d = G.C.D.(a, b), allora: Iniziamo con un esercizio sul massimo comun divisore: Esercizio 1. Sia d = G.C.D.(a, b), allora: G.C.D.( a d, b d ) = 1 Sono state introdotte a lezione due definizioni importanti che ricordiamo: Definizione

Dettagli

CAPITOLO PRIMO IL CONCETTO DI ALGORITMO 1

CAPITOLO PRIMO IL CONCETTO DI ALGORITMO 1 1.1 Che cos è un algoritmo CAPITOLO PRIMO IL CONCETTO DI ALGORITMO 1 Gli algoritmi sono metodi per la soluzione di problemi. Possiamo caratterizzare un problema mediante i dati di cui si dispone all inizio

Dettagli

Corso di Informatica Generale (C. L. Economia e Commercio) Ing. Valerio Lacagnina Rappresentazione in virgola mobile

Corso di Informatica Generale (C. L. Economia e Commercio) Ing. Valerio Lacagnina Rappresentazione in virgola mobile Problemi connessi all utilizzo di un numero di bit limitato Abbiamo visto quali sono i vantaggi dell utilizzo della rappresentazione in complemento alla base: corrispondenza biunivoca fra rappresentazione

Dettagli

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL

Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone. SQL: il DDL Basi di Dati prof. Letizia Tanca lucidi ispirati al libro Atzeni-Ceri-Paraboschi-Torlone SQL: il DDL Parti del linguaggio SQL Definizione di basi di dati (Data Definition Language DDL) Linguaggio per modificare

Dettagli

Gestione dinamica di una pila

Gestione dinamica di una pila Gestione dinamica di una pila Una pila o stack è una lista lineare a lunghezza variabile in cui inserimenti (push) ed estrazioni (pop) vengono effettuate ad un solo estremo, detto testa (top) della pila.

Dettagli

Indicizzazione terza parte e modello booleano

Indicizzazione terza parte e modello booleano Reperimento dell informazione (IR) - aa 2014-2015 Indicizzazione terza parte e modello booleano Gruppo di ricerca su Sistemi di Gestione delle Informazioni (IMS) Dipartimento di Ingegneria dell Informazione

Dettagli

Tipologie di pianificatori. Pianificazione. Partial Order Planning. E compiti diversi. Pianificazione gerarchica. Approcci integrati

Tipologie di pianificatori. Pianificazione. Partial Order Planning. E compiti diversi. Pianificazione gerarchica. Approcci integrati Tipologie di pianificatori Pianificazione Intelligenza Artificiale e Agenti II modulo Pianificazione a ordinamento parziale (POP) (HTN) pianificazione logica (SatPlan) Pianificazione come ricerca su grafi

Dettagli

Gli array. Gli array. Gli array. Classi di memorizzazione per array. Inizializzazione esplicita degli array. Array e puntatori

Gli array. Gli array. Gli array. Classi di memorizzazione per array. Inizializzazione esplicita degli array. Array e puntatori Gli array Array e puntatori Laboratorio di Informatica I un array è un insieme di elementi (valori) avente le seguenti caratteristiche: - un array è ordinato: agli elementi dell array è assegnato un ordine

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Algoritmi Algoritmi Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Il procedimento (chiamato algoritmo) è composto da passi elementari

Dettagli

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata Giampiero Carboni Davide Travaglia David Board Rev 5058-CO900C Interfaccia operatore a livello di sito FactoryTalk

Dettagli

Energy risk management

Energy risk management Il sistema di supporto alle tue decisioni Energy risk management Un approccio orientato agli attori M.B.I. Srl, Via Francesco Squartini 7-56121 Pisa, Italia - tel. 050 3870888 - fax. 050 3870808 www.powerschedo.it

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Appunti di Sistemi Operativi. Enzo Mumolo e-mail address :mumolo@units.it web address :www.units.it/mumolo

Appunti di Sistemi Operativi. Enzo Mumolo e-mail address :mumolo@units.it web address :www.units.it/mumolo Appunti di Sistemi Operativi Enzo Mumolo e-mail address :mumolo@units.it web address :www.units.it/mumolo Indice 1 Cenni su alcuni algoritmi del Kernel di Unix 1 1.1 Elementi di Unix Internals.................................

Dettagli

Strutture. Strutture e Unioni. Definizione di strutture (2) Definizione di strutture (1)

Strutture. Strutture e Unioni. Definizione di strutture (2) Definizione di strutture (1) Strutture Strutture e Unioni DD cap.10 pp.379-391, 405-406 KP cap. 9 pp.361-379 Strutture Collezioni di variabili correlate (aggregati) sotto un unico nome Possono contenere variabili con diversi nomi

Dettagli

Sistemi Operativi 1. Mattia Monga. a.a. 2008/09. Dip. di Informatica e Comunicazione Università degli Studi di Milano, Italia mattia.monga@unimi.

Sistemi Operativi 1. Mattia Monga. a.a. 2008/09. Dip. di Informatica e Comunicazione Università degli Studi di Milano, Italia mattia.monga@unimi. 1 Mattia Dip. di Informatica e Comunicazione Università degli Studi di Milano, Italia mattia.monga@unimi.it a.a. 2008/09 1 c 2009 M.. Creative Commons Attribuzione-Condividi allo stesso modo 2.5 Italia

Dettagli

SIMATIC. SCL per S7-300/400 Programmazione di blocchi. Prefazione, Contenuto. Parte 1: Sviluppo di programmi. Parte 2: Uso e test

SIMATIC. SCL per S7-300/400 Programmazione di blocchi. Prefazione, Contenuto. Parte 1: Sviluppo di programmi. Parte 2: Uso e test Prefazione, Contenuto Parte 1: Sviluppo di programmi Parte 2: Uso e test SIMATIC Parte 3: Descrizione del linguaggio Programmazione di blocchi Appendici Glossario, Indice analitico Manuale Numero di ordinazione

Dettagli

Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica. Programmazione I - corso B a.a. 2009-10. prof.

Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica. Programmazione I - corso B a.a. 2009-10. prof. Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica Programmazione I - corso B a.a. 009-10 prof. Viviana Bono Blocco 9 Metodi statici: passaggio parametri, variabili locali, record

Dettagli

Ricorsione. Corso di Fondamenti di Informatica

Ricorsione. Corso di Fondamenti di Informatica Dipartimento di Informatica e Sistemistica Antonio Ruberti Sapienza Università di Roma Ricorsione Corso di Fondamenti di Informatica Laurea in Ingegneria Informatica (Canale di Ingegneria delle Reti e

Dettagli

Così come le macchine meccaniche trasformano

Così come le macchine meccaniche trasformano DENTRO LA SCATOLA Rubrica a cura di Fabio A. Schreiber Il Consiglio Scientifico della rivista ha pensato di attuare un iniziativa culturalmente utile presentando in ogni numero di Mondo Digitale un argomento

Dettagli

INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI

INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI Prima di riuscire a scrivere un programma, abbiamo bisogno di conoscere un metodo risolutivo, cioè un metodo che a partire dai dati di ingresso fornisce i risultati attesi.

Dettagli

Le variabili. Olga Scotti

Le variabili. Olga Scotti Le variabili Olga Scotti Cos è una variabile Le variabili, in un linguaggio di programmazione, sono dei contenitori. Possono essere riempiti con un valore che poi può essere riletto oppure sostituito.

Dettagli

Cos è una stringa (1) Stringhe. Leggere e scrivere stringhe (1) Cos è una stringa (2) DD Cap. 8 pp. 305-341 KP Cap. 6 pp. 241-247

Cos è una stringa (1) Stringhe. Leggere e scrivere stringhe (1) Cos è una stringa (2) DD Cap. 8 pp. 305-341 KP Cap. 6 pp. 241-247 Cos è una stringa (1) Stringhe DD Cap. 8 pp. 305-341 KP Cap. 6 pp. 241-247 Una stringa è una serie di caratteri trattati come una singola unità. Essa potrà includere lettere, cifre, simboli e caratteri

Dettagli