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

Progetto Ingegneria del Software. Anno Accademico 2014-2015. Sessione invernale. SoSolitario. Una tipologia di solitario come tante

Progetto Ingegneria del Software. Anno Accademico 2014-2015. Sessione invernale. SoSolitario. Una tipologia di solitario come tante Progetto Ingegneria del Software Anno Accademico 2014-2015 Sessione invernale SoSolitario Una tipologia di solitario come tante Giulia Talamonti n 248899 Indice 2 1. Specifica del problema 4 2. Specifica

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

OBIETTIVI SPECIFICI DI APPRENDIMENTO

OBIETTIVI SPECIFICI DI APPRENDIMENTO Disciplina:... Anno scolastico: 20.../20... Classe/i :... Docente:... DI APPRENDIMENTO SEZIONE 1 Premesse matematiche Nozioni fondamentali sui sistemi di numerazione Sistemi di numerazione in base diversa

Dettagli

Fondamenti di Informatica T2 Modulo 2. Corso di Laurea in Ingegneria Informatica Anno accademico 2014/2015. Ancora Phone Plan

Fondamenti di Informatica T2 Modulo 2. Corso di Laurea in Ingegneria Informatica Anno accademico 2014/2015. Ancora Phone Plan Università degli Studi di Bologna Scuola di Ingegneria e Architettura Fondamenti di Informatica T2 Modulo 2 Corso di Laurea in Ingegneria Informatica Anno accademico 2014/2015 Ancora Phone Plan Quanto

Dettagli

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36 10. Design Patterns Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 10. Design Patterns 1 / 36 Problemi Ci focalizziamo nelle problematiche riguardanti la

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX NB: il candidato troverà nell archivio ZIP scaricato da Esamix anche il software Start Kit

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

GESTIONE DEI PROCESSI

GESTIONE DEI PROCESSI Sistemi Operativi GESTIONE DEI PROCESSI Processi Concetto di Processo Scheduling di Processi Operazioni su Processi Processi Cooperanti Concetto di Thread Modelli Multithread I thread in Java Concetto

Dettagli

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007 2007 SISTEMI OPERATIVI Gestione della memoria Domande di verifica Luca Orrù Centro Multimediale Montiferru 18/06/2007 Gestione della memoria 1. Si descriva il concetto di memoria virtuale (esame del 19-06-2006)

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

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

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

L applicazione di MVC alla simulazione di ascensore I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1

L applicazione di MVC alla simulazione di ascensore I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1 I COMPONENTI DELLE INTERFACCE UTENTE GRAFICHE: PARTE II 1 3.13 (Caso di studio facoltativo) Pensare a oggetti: Modello-Vista-Controllore I design pattern descrivono strategie efficaci per costruire sistemi

Dettagli

DESIGN PATTERN CREAZIONALI INGEGNERIA DEL SOFTWARE INTRODUZIONE SINGLETON. Scopo dei design pattern creazionali

DESIGN PATTERN CREAZIONALI INGEGNERIA DEL SOFTWARE INTRODUZIONE SINGLETON. Scopo dei design pattern creazionali DESIGN PATTERN CREAZIONALI DESIGN PATTERN CREAZIONALI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2013 2014 rcardin@math.unipd.it

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 11 + Credits I lucidi di questa lezione sono stati preparati da: Professor Stefano Mizzaro Professor Paolo Coppola e sono stati modificati e completati dal Dr. Paolo

Dettagli

Sistemi Operativi Kernel

Sistemi Operativi Kernel Approfondimento Sistemi Operativi Kernel Kernel del Sistema Operativo Kernel (nocciolo, nucleo) Contiene i programmi per la gestione delle funzioni base del calcolatore Kernel suddiviso in moduli. Ogni

Dettagli

Il supporto al Sistema Operativo

Il supporto al Sistema Operativo Il supporto al Sistema Operativo Obiettivi e funzioni del S.O. Il Sistema Operativo è il software che controlla l esecuzione dei programmi e amministra le risorse del sistema. Ha due obiettivi principali:

Dettagli

Scheduling Introduzione Tipi di scheduler Scheduler di lungo termine (SLT) Scheduler di medio termine (SMT) Scheduler di breve termine (SBT)

Scheduling Introduzione Tipi di scheduler Scheduler di lungo termine (SLT) Scheduler di medio termine (SMT) Scheduler di breve termine (SBT) Scheduling Introduzione Con scheduling si intende un insieme di tecniche e di meccanismi interni del sistema operativo che amministrano l ordine in cui il lavoro viene svolto. Lo Scheduler è il modulo

Dettagli

Programmazione Orientata agli Oggetti in Linguaggio Java

Programmazione Orientata agli Oggetti in Linguaggio Java Programmazione Orientata agli Oggetti in Linguaggio Java Design Pattern: Storia Parte b versione 2.1 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima pagina)

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Linguaggi di Programmazione Michele Tomaiuolo Linguaggi macchina I

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1 a cura di Giancarlo Cherchi 1 Introduzione Il meccanismo dell eredità consente di sfruttare delle relazioni tipo/sottotipo, ereditando attributi

Dettagli

Scheduling della CPU:

Scheduling della CPU: Coda dei processi pronti (ready( queue): Scheduling della CPU primo ultimo PCB i PCB j PCB k contiene i descrittori ( process control block, PCB) dei processi pronti. la strategia di gestione della ready

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Elementi di Informatica

Elementi di Informatica Università degli Studi di Udine Facoltà di Ingegneria CORSO DI LAUREA IN SCIENZE dell ARCHITETTURA Elementi di Informatica Algoritmi, e Programmi D. Gubiani 29 marzo 2010 D. Gubiani Algoritmi, e Programmi

Dettagli

Esercitazione sui Design Pattern

Esercitazione sui Design Pattern Esercitazione sui Design Pattern Pattern Creazionali Singleton Permette la creazione di una sola istanza della classe all interno dell applicazione Fornisce un metodo con cui ottenere l istanza Il costruttore

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

L ambizione dei design pattern (letteralmente schemi di programmazione) è quella di offrire soluzioni a problemi ricorrenti che facilitano lo

L ambizione dei design pattern (letteralmente schemi di programmazione) è quella di offrire soluzioni a problemi ricorrenti che facilitano lo Design Pattern L ambizione dei design pattern (letteralmente schemi di programmazione) è quella di offrire soluzioni a problemi ricorrenti che facilitano lo sviluppo dei programmi, il loro mantenimento,

Dettagli

Tipi di Dato Ricorsivi

Tipi di Dato Ricorsivi Tipi di Dato Ricorsivi Luca Abeni September 2, 2015 1 Tipi di Dato Vari linguaggi di programmazione permettono all utente di definire nuovi tipi di dato definendo per ogni nuovo tipo l insieme dei suoi

Dettagli

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9

!#$%&&'()#*%+%+!#$',,'()#*%+ -)%*&'&'+'$.)+-$$%&&) !#$%&&'(%)'*+%,#-%#.'%&'#/0)-+#12+3,)4+56#7+#.')8'9 !"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&)!"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9 Slide 1 Paradigmi di Programmazione! Un linguaggio supporta uno stile di programmazione se

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Corso di Esercitazioni di Programmazione

Corso di Esercitazioni di Programmazione Corso di Esercitazioni di Programmazione Introduzione Dott.ssa Sabina Rossi Informazioni Pagina web del corso: News Orari Mailing list Lezioni Esercitazioni Date esami Risultati esami.. http://www.dsi.unive.it/~prog1

Dettagli

Proff. Fabio Ciao e Raffaele Bortone

Proff. Fabio Ciao e Raffaele Bortone ISTITUTO D ISTRUZIONE SUPERIORE FERRARIS BRUNELLESCHI - EMPOLI Materia: INFORMATICA PROGRAMMAZIONE ANNUALE A.S. 2014/2015 Classe IV C Informatica Proff. Fabio Ciao e Raffaele Bortone Libro di testo: Cloud

Dettagli

Struttura logica di un programma

Struttura logica di un programma Struttura logica di un programma Tutti i programmi per computer prevedono tre operazioni principali: l input di dati (cioè l inserimento delle informazioni da elaborare) il calcolo dei risultati cercati

Dettagli

Algoritmi e Strutture Dati

Algoritmi e Strutture Dati schifano@fe.infn.it Laurea di Informatica - Università di Ferrara 2011-2012 [1] Strutture dati Dinamiche: Le liste Una lista è una sequenza di elementi di un certo tipo in cui è possibile aggiungere e/o

Dettagli

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

Dettagli

INFORMATICA 1 L. Mezzalira

INFORMATICA 1 L. Mezzalira INFORMATICA 1 L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software del modello

Dettagli

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented Informatica Prof. A. Longheu Introduzione ai Linguaggi Object-Oriented 1 Generalità programmazione OO La programmazione ad oggetti è un particolare modo di scrivere il programma. Si prevede che: 1) si

Dettagli

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario Processi e thread Dipartimento di Informatica Università di Verona, Italy Sommario Concetto di processo Stati di un processo Operazioni e relazioni tra processi Concetto di thread Gestione dei processi

Dettagli

Scheduling della CPU Simulazione in linguaggio Java

Scheduling della CPU Simulazione in linguaggio Java Scheduling della CPU Simulazione in linguaggio Java Realizzato da: Amelio Francesco 556/001699 Di Matteo Antonio 556/000067 Viola Antonio 556/000387 Progetto di Sistemi Operativi Docente Giancarlo Nota

Dettagli

Corso di Visual Basic (Parte 8)

Corso di Visual Basic (Parte 8) Corso di Visual Basic (Parte 8) di MAURIZIO CRESPI Questo mese il corso di programmazione in Visual Basic focalizza la propria attenzione sulle procedure, talvolta dette subroutine L oggetto dell ottava

Dettagli

ProgettAzione V anno Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni

ProgettAzione V anno Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni Unità 3 - Architetture per applicazioni web Lezione: Esempio sviluppo applicazioni Web service Hello world con Visual Studio 2012 Si tratta di un semplice esempio di web service, infatti come tutti I programmi

Dettagli

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio QUEUE : considerazioni QUEUE : considerazioni Si è realizzata una struttura dati complessa utilizzandone una primitiva, l array. Il pregio di tale implementazione è il basso costo computazionale, mentre

Dettagli

1 introdurre le monete per l importo necessario. 2 selezionare la quantità di zucchero. 3 selezionare la bevanda desiderata

1 introdurre le monete per l importo necessario. 2 selezionare la quantità di zucchero. 3 selezionare la bevanda desiderata Esempi di Problema: Prendere un Caffè al Distributore Università degli Studi di Udine Facoltà di Ingegneria CORSO DI LAUREA IN SCIENZE dell ARCHITETTURA Elementi di Informatica, e Programmi D. Gubiani

Dettagli

Metodologie di programmazione in Fortran 90

Metodologie di programmazione in Fortran 90 Metodologie di programmazione in Fortran 90 Ing. Luca De Santis DIS - Dipartimento di informatica e sistemistica Anno accademico 2007/2008 Fortran 90: Metodologie di programmazione DIS - Dipartimento di

Dettagli

Lezione 6. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata.

Lezione 6. Sistemi operativi. Marco Cesati System Programming Research Group Università degli Studi di Roma Tor Vergata. Lezione 6 Sistemi operativi 31 marzo 2015 System Programming Research Group Università degli Studi di Roma Tor Vergata SO 15 6.1 Di cosa parliamo in questa lezione? La schedulazione 1 e caratteristiche

Dettagli

Programmazione a Oggetti Modulo B

Programmazione a Oggetti Modulo B Programmazione a Oggetti Modulo B Lezione 5 Dott. Alessandro Roncato 08/11/2011 Riassunto Pattern Singleton Pattern Plolimorfismo Classi e Interfacce 2 Ereditarietà multipla In Java una classe può estendere

Dettagli

CORSO DI PROGRAMMAZIONE

CORSO DI PROGRAMMAZIONE ISTITUTO TECNICO INDUSTRIALE G. M. ANGIOY SASSARI CORSO DI PROGRAMMAZIONE ELEMENTI STATICI E CLASSI STATICHE DISPENSA 15.03 15-03_OOP_Static_[15] Questa dispensa è rilasciata sotto la licenza Creative

Dettagli

Alcuni Design Pattern in Java

Alcuni Design Pattern in Java Marco Faella Alcuni Design Pattern in Java basato su Progettazione del Software e Design Pattern in Java, di Cay Horstmann Pattern ITERATOR Contesto: 1) Un oggetto (aggregato) contiene altri oggetti (elementi)

Dettagli

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

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

Dettagli

Ingegneria del Software Progettazione

Ingegneria del Software Progettazione Ingegneria del Software Progettazione Obiettivi. Approfondire la fase di progettazione dettagliata che precede la fase di realizzazione e codifica. Definire il concetto di qualità del software. Presentare

Dettagli

Monitor. Introduzione. Struttura di un TDA Monitor

Monitor. Introduzione. Struttura di un TDA Monitor Monitor Domenico Cotroneo Dipartimento di Informatica e Sistemistica Introduzione E stato introdotto per facilitare la programmazione strutturata di problemi in cui è necessario controllare l assegnazione

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

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

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX NB: il candidato troverà nell archivio ZIP scaricato da Esamix anche il software Start Kit

Dettagli

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012

Esercitazioni di PROGETTAZIONE DEL SOFTWARE A.A. 2011-2012 Sapienza Università di Roma Facoltà di Ingegneria dell Informazione, Informatica e Statistica Corso di Laurea in Ingegneria Informatica ed Automatica Corso di Laurea in Ingegneria dei Sistemi Informatici

Dettagli

Concetti di base. Scheduling della CPU. Diagramma della durata dei CPU-burst. Sequenza Alternata di CPU Burst e I/O Burst

Concetti di base. Scheduling della CPU. Diagramma della durata dei CPU-burst. Sequenza Alternata di CPU Burst e I/O Burst Impossibile visualizzare l'immagine. Scheduling della CPU Concetti di base La multiprogrammazione cerca di ottenere la massima utilizzazione della CPU. L esecuzione di un processo consiste in cicli d esecuzione

Dettagli

Ingegneria del Software. Introduzione ai pattern

Ingegneria del Software. Introduzione ai pattern Ingegneria del Software Introduzione ai pattern 1 Definizione di pattern [dal [dal vocabolario vocabolario Garzanti] Garzanti] Alcuni esempi: Pattern architetturale Pattern di circuito stampato Pattern

Dettagli

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi

Linguaggio Java. Robusto. Orientato agli oggetti. Protegge e gestisce dagli errori. Non permette costrutti pericolosi Linguaggio Java Robusto Non permette costrutti pericolosi Eredità Multipla Gestione della Memoria Orientato agli oggetti Ogni cosa ha un tipo Ogni tipo è un oggetto (quasi) Protegge e gestisce dagli errori

Dettagli

Un sistema operativo è un insieme di programmi che consentono ad un utente di

Un sistema operativo è un insieme di programmi che consentono ad un utente di INTRODUZIONE AI SISTEMI OPERATIVI 1 Alcune definizioni 1 Sistema dedicato: 1 Sistema batch o a lotti: 2 Sistemi time sharing: 2 Sistema multiprogrammato: 3 Processo e programma 3 Risorse: 3 Spazio degli

Dettagli

Progettazione : Design Pattern Creazionali

Progettazione : Design Pattern Creazionali Progettazione : Design Pattern Creazionali Alessandro Martinelli alessandro.martinelli@unipv.it 30 Novembre 2010 Progettazione : Design Pattern Creazionali Aspetti generali dei Design Pattern Creazionali

Dettagli

Processi e Thread. Scheduling (Schedulazione)

Processi e Thread. Scheduling (Schedulazione) Processi e Thread Scheduling (Schedulazione) 1 Scheduling Introduzione al problema dello Scheduling (1) Lo scheduler si occupa di decidere quale fra i processi pronti può essere mandato in esecuzione L

Dettagli

Definizione di processo. Un processo è un programma (o una parte di una programma) in corso di esecuzione

Definizione di processo. Un processo è un programma (o una parte di una programma) in corso di esecuzione SISTEMI OPERATIVI (parte prima - gestione dei processi) Tra i compiti di un sistema operativo sicuramente troviamo i seguenti: Gestione dei processi Gestione della memoria Gestione del file-system Ci occuperemo

Dettagli

Scheduling della CPU

Scheduling della CPU Scheduling della CPU Scheduling della CPU Obiettivo della multiprogrammazione: massimizzazione dell utilizzo della CPU. Scheduling della CPU: attivita` di allocazione della risorsa CPU ai processi. Scheduler

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Pronto Esecuzione Attesa Terminazione

Pronto Esecuzione Attesa Terminazione Definizione Con il termine processo si indica una sequenza di azioni che il processore esegue Il programma invece, è una sequenza di azioni che il processore dovrà eseguire Il processo è quindi un programma

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Obiettivo della multiprogrammazione: massimizzazione dell utilizzo CPU. Scheduling della CPU: commuta l uso della CPU tra i vari processi

Obiettivo della multiprogrammazione: massimizzazione dell utilizzo CPU. Scheduling della CPU: commuta l uso della CPU tra i vari processi Scheduling della CPU Scheduling della CPU Obiettivo della multiprogrammazione: massimizzazione dell utilizzo CPU Scheduling della CPU: commuta l uso della CPU tra i vari processi Scheduler della CPU (a

Dettagli

DESIGN PATTERN STRUTTURALI INGEGNERIA DEL SOFTWARE INTRODUZIONE ADAPTER. Scopo Convertire l interfaccia di una classe in un altra.

DESIGN PATTERN STRUTTURALI INGEGNERIA DEL SOFTWARE INTRODUZIONE ADAPTER. Scopo Convertire l interfaccia di una classe in un altra. DESIGN PATTERN STRUTTURALI DESIGN PATTERN STRUTTURALI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2013 2014 rcardin@math.unipd.it

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

Progettazione di Applicazioni Web

Progettazione di Applicazioni Web 1 Argomenti della lezione Progettazione di Applicazioni Web Sviluppo delle applicazioni Processo di sviluppo Formalismi grafici di supporto diagrammi UML (cenni) Scelta dell architettura Sviluppo di applicazioni

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Uno dei pregi di Java è quello di integrare la documentazione con il codice stesso Formato dei commenti:

Uno dei pregi di Java è quello di integrare la documentazione con il codice stesso Formato dei commenti: Javadoc Uno dei pregi di Java è quello di integrare la documentazione con il codice stesso Formato dei commenti: /* commenti */ // commenti /** commenti documentazione */ Questi ultimi generano automaticamente

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi a.a. 2010/2011 Francesco Fontanella Il Sistema Operativo Sistema Operativo 2 Il Sistema Operativo Il Sistema Operativo è uno strato

Dettagli

www.wlascuola.4000.it

www.wlascuola.4000.it 1 Cenni di programmazione Risolvere un problema significa trovare un procedimento che consenta di produrre i risultati, a partire dai dati iniziali, attraverso un processo di elaborazione. La metodologia

Dettagli

Analisi Modelli per la specifica dei requisiti

Analisi Modelli per la specifica dei requisiti Modelli per la specifica dei requisiti Modelli semantici dei dati Entità-Relazioni (E-R) Modelli orientati all elaborazione dati Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD) Modelli orientati

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16 Pietro Frasca Lezione 15 Martedì 24-11-2015 Struttura logica del sottosistema di I/O Processi

Dettagli

Esercizi di Ingegneria del Software

Esercizi di Ingegneria del Software Esercizi di Ingegneria del Software Il caso della Grande Distribuzione V. Ambriola, C. Montangero e L. Semini Corso di Laurea in Informatica Corso di Laurea in Informatica Applicata Dipartimento di Informatica

Dettagli

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira

FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira Appunti del corso 1 Introduzione all informatica: algoritmi, linguaggi e programmi Indice 1. Introduzione 2. Risoluzione automatica di problemi - Algoritmi

Dettagli

Design Pattern in Java

Design Pattern in Java Design Pattern in Java Claudio Di Ciccio, Massimiliano de Leoni (con la supervisione del docente Massimo Mecella) Università di Roma La Sapienza - Sede di Latina Corso di Progettazione del Software A.A.

Dettagli

Use Case Driven Object Modeling: ICONIX

Use Case Driven Object Modeling: ICONIX Use Case Driven Object Modeling: ICONIX Un esempio di specifica, analisi, progetto e sviluppo utilizzando ICONIX Ditta di Noleggio Dvd Un sistema per la gestione di una ditta di noleggio dvd che ha più

Dettagli

LA GESTIONE DELLA MEMORIA

LA GESTIONE DELLA MEMORIA LA GESTIONE DELLA MEMORIA Ambiente Monoprogrammato (monoprogrammazione) In ambiente monoprogrammato é possibile far girare un solo programma per volta. Tutte le risorse sono dedicate all unico programma

Dettagli

Secondo biennio Articolazione Informatica TPSIT Prova Quarta

Secondo biennio Articolazione Informatica TPSIT Prova Quarta Sistema operativo: gestione memoria centrale La Memoria Virtuale consente di superare i limiti della Memoria Centrale : A. no B. a volte C. si, ma non sempre e' adeguata D. si, attraverso tecniche di gestione

Dettagli

Lo scheduling. Tipici schedulatori

Lo scheduling. Tipici schedulatori Lo scheduling Un processo durante la sua evoluzione è o running o in attesa di un evento. Nel secondo caso trattasi della disponibilità di una risorsa (CPU, I/O, struttura dati, ecc.) di cui il processo

Dettagli

Introduzione. Perché è stato scritto questo libro

Introduzione. Perché è stato scritto questo libro Introduzione Perché è stato scritto questo libro Sul mercato sono presenti molti libri introduttivi a Visual C# 2005, tuttavia l autore ha deciso di scrivere il presente volume perché è convinto che possa

Dettagli

Gestione dei processi. Marco Cesati. Schema della lezione. Blocco di controllo 2. Sezioni e segmenti. Gestione dei processi. Job.

Gestione dei processi. Marco Cesati. Schema della lezione. Blocco di controllo 2. Sezioni e segmenti. Gestione dei processi. Job. Di cosa parliamo in questa lezione? Lezione 4 Cosa è un processo e come viene gestito dal SO 1 e job 2 Il blocco di controllo Sistemi operativi 3 Struttura di un file eseguibile 4 La schedulazione dei

Dettagli

SISTEMI OPERATIVI. Gestione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 13/05/2007

SISTEMI OPERATIVI. Gestione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 13/05/2007 2007 SISTEMI OPERATIVI Gestione dei processi Domande di verifica Luca Orrù Centro Multimediale Montiferru 13/05/2007 Gestione dei processi 1. Qual è la differenza tra un programma e un processo? Un programma

Dettagli

Tipi primitivi. Ad esempio, il codice seguente dichiara una variabile di tipo intero, le assegna il valore 5 e stampa a schermo il suo contenuto:

Tipi primitivi. Ad esempio, il codice seguente dichiara una variabile di tipo intero, le assegna il valore 5 e stampa a schermo il suo contenuto: Tipi primitivi Il linguaggio Java offre alcuni tipi di dato primitivi Una variabile di tipo primitivo può essere utilizzata direttamente. Non è un riferimento e non ha senso tentare di istanziarla mediante

Dettagli