ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini"

Transcript

1 ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia orientata agli oggetti. Tali elementi [Larman97] sono: un linguaggio di modellazione che consente di descrivere il sistema da sviluppare organizzando tale descrizione per mezzo di oggetti; un processo di sviluppo che indica il flusso di lavoro nel corso delle fasi del progetto di sviluppo, specificando quando produrre determinati modelli; un insieme di principi di analisi e progettazione o patterns che codificano soluzioni note e testate a problemi caratteristici, consentendo di applicare tali soluzioni al problema in esame e semplificando in tal modo la produzione di porzioni di un modello del sistema. In particolare saranno approfonditi in maggiore dettaglio i primi due elementi, riservando al terzo una breve introduzione Lo sviluppo di sistemi Lo sviluppo di un sistema informatico è un processo comp lesso; gli elementi critici di tale processo sono: la comprensione del dominio di interesse, i problemi di gestione del processo di sviluppo e la capacità di descrivere e controllare il comportamento del sistema sviluppato. Ciascun sistema informatico viene costruito per risolvere un problema nell ambito di un certo dominio di interesse. Tali problemi presentano spesso numerosi elementi che accrescono la loro complessità, come la presenza di numerose esigenze spesso in contrapposizione fra di loro e la presenza di requisiti non funzionali, quali quelli di usabilità, prestazioni, costo e affidabilità. Inoltre accade spesso che gli utilizzatori del sistema e i suoi progettisti parlino un linguaggio completamente differente, così che i primi abbiano difficoltà ad esprimere con precisione le proprie necessità, mentre i secondi non riescano a spiegare correttamente cosa si apprestano a realizzare. Questa difficoltà di comprensione è difficilmente attenuata da specifiche prolisse espresse in forma testuale, mentre di maggiore utilità possono essere modelli del sistema espressi in un linguaggio formale o prototipi del sistema stesso. 1

2 I sistemi informatici inoltre possono avere una struttura interna complessa ed essere composti da migliaia di moduli, ciascuno dei quali contiene migliaia di linee di codice. La produzione di tali sistemi richiede il contributo di numerosi sviluppatori, il cui lavoro deve essere gestito, coordinato e integrato per arrivare al prodotto finale: la comunicazione fra i diversi sviluppatori è un elemento di successo importante nello sviluppo del sistema, e la descrizione del sistema per mezzo di modelli formali può portare un contributo significativo in tale senso. Un sistema software è un sistema che può assumere uno fra un determinato numero di stati: tale numero è però incredibilmente alto a causa dell esplosione combinatoria derivante dal numero di oggetti che compongono il sistema. La complessità strutturale del sistema induce quindi una complessità comportamentale. Di conseguenza un sistema informatico può eseguire transizioni di stato del tutto inattese in conseguenza di un input esterno non previsto, venendosi a trovare in uno stato di errore, uno stato a partire dal quale il successivo comportamento del sistema risulta imprevedibile. La risposta a questo problema è nella decomposizione del sistema in componenti più piccole la cui descrizione possa essere raffinata separatamente dalle altre, e il cui comportamento complessivo possa essere descritto in termini semplici e precisi a partire dal comportamento delle singole parti. Nell approccio tradizionale la decomposizione di un sistema è realizzata da un punto di vista funzionale: l elemento atomico di tale decomposizione è la funzione o procedura e ciascuna funzione può essere decomposta in altre più semplici. L attenzione del progettista del sistema si concentra quindi sul flusso di controllo e sulla decomposizione algoritmica: tale modalità di decomposizione tende a produrre sistemi difficilmente manutenibili, con un grado di resistenza basso verso l evoluzione dei requisiti Modellazione Object-Oriented Una modalità alternativa di decomposizione è quella di un sistema in oggetti e classi; in questo contesto un oggetto nel sistema corrisponde generalmente ad un concetto presente nel dominio del problema o nello spazio della soluzione, mentre una classe corrisponde ad un insieme di oggetti simili. Ogni oggetto è caratterizzato da un identità, da uno stato e da un comportamento. I vantaggi che una decomposizione ad oggetti presenta rispetto ad una funzionale si possono così riassumere: essa conduce allo sviluppo di sistemi più piccoli e semplici per ché consente di applicare meglio la filosofia di riutilizzo di componenti preesistenti; consente di descrivere il sistema in un modo più comprensibile per gli utenti finali e più vicino al dominio applicativo nel quale il sistema si colloca; conduce alla produzione di sistemi più resistenti alle modifiche. La modellazione object-oriented ha un impatto sulle diverse attività che vengono condotte nel corso dello sviluppo di un sistema (analisi, progetto e codifica). In fase di analisi le specifiche del sistema possono essere espresse in termini degli oggetti che popolano la particolare realtà (dominio di interesse) in cui si colloca il problema che il sistema intende risolvere. Nel corso del progetto il sistema da produrre può essere decomposto per mezzo di oggetti: i documenti prodotti descriveranno, utilizzando notazioni diverse, gli aspetti strutturali (classi e oggetti) e comportamentali (interazioni e 2

3 stati). Infine nell attività di codifica i moduli che compongono il sistema saranno organizzati in termini di classi di oggetti che cooperano fra di loro per svolgere un determinato compito. Un modello object-oriented [Booch94] è caratterizzato dai seguenti elementi costitutivi: astrazione di classificazione, la capacità di descrivere un oggetto mettendo a fuoco le caratteristiche più importanti e ignorando le altre, per mezzo del costrutto di classe; incapsulamento, la possibilità di nascondere i dettagli della implementazione di un oggetto; modularità, la possibilità di decomporre un sistema in un insieme di elementi caratterizzati da un basso grado di accoppiamento e da un elevata coesione interna; ereditarietà, la capacità di specificare una gerarchia fra le classi definite; aggregazione, la possibilità di definire un oggetto come composto da altri oggetti. L astrazione di classe consente di descrivere oggetti con caratteristiche simili per mezzo del costrutto di classe: una classe rappresenterà solamente le caratteristiche desiderate per gli oggetti che la compongono. Persona Nome Cognome Bianchi Rossi Figura 1 - Classificazione Verdi Un esempio ereditarietà è quella mostrata in figura fra le classi IMPIEGATO e DIRIGENTE: la seconda classe può ereditare dalla prima caratteristiche strutturali (nome, cognome, ecc.), comportamentali (la capacità di svolgere un compito assegnato) e di relazione con altre classi (entrambi fanno parte di un organizzazione). 3

4 Impiegato Dirigente Figura 2 - Ereditarietà La relazione esistente fra un IMPIEGATO e il GRUPPO in cui lavora costituisce un esempio di aggregazione: il gruppo risulta definito come oggetto composto da un certo numero di impiegati. Gruppo Impiegato Figura 3 - Aggregazione 1.3. Linguaggi di modellazione La realizzazione di un modello del sistema che si intende sviluppare prima della sua costruzione o della sua ristrutturazione è essenziale così come lo è il progetto per la costruzione di un edificio. L importanza di un modello e il grado di dettaglio necessario crescono proporzionalmente con la complessità dell oggetto che si intende costruire. Una cuccia per un cane può essere costruita da una sola persona senza la necessità di descrivere in alcun modo l obiettivo che si intende raggiungere. Una casa avrà bisogno almeno di un progetto di massima per verificare le necessità per cui viene costruita ed eventualmente affidare una parte dei lavori a ditte specializzate. La costruzione di un palazzo di molti piani avrà bisogno di un progetto dettagliato, un piano di realizzazione e di spesa, una chiara visione degli obiettivi da raggiungere e del modo in cui raggiungerli [Booch98]. Un modello consente di semplificare la realtà da descrivere mettendo in evidenza alcuni aspetti e scartandone altri: lo stesso sistema può essere modellato a diversi livelli di astrazione in diversi momenti del suo sviluppo. Una vista semplificata del sistema da sviluppare consentirà di visualizzare e comprendere meglio gli aspetti essenziali del sistema. Si desidera qui mettere in evidenza l importanza del modello fra gli elementi che compongono il progetto di un sistema. Un modello infatti assolve a compiti diversi: costituisce un elemento di comunicazione fra le persone coinvolte nella costruzione del sistema permette di verificare le caratteristiche del sistema da costruire permette di confrontare le caratteristiche del sistema con standard di costruzione 4

5 facilita la stima dei tempi e dei costi necessari a completare la costruzione del sistema. Ci sono altri fattori in grado di influenzare il successo di un progetto, ma l adozione di un linguaggio di modellazione è un elemento critico. Un linguaggio di modellazione includerà: gli elementi del modello i concetti di base del modello e il significato loro associato la notazione una rappresentazione visiva degli elementi del modello le linee guida il modo in cui gli elementi del modello possono essere composti 1.4. UML e modellazione OO UML (Unified Modelling Language) è un linguaggio per descrivere, specificare e documentare i prodotti del processo di sviluppo del software. Esso può essere utilizzato per sistemi di tipo e grandezza differenti ed è caratterizzato da un alto potere espressivo. UML non specifica un processo per la modellazione e intende anzi essere indipendente dal processo di sviluppo all interno del quale è utilizzato. I vantaggi di tale divisione fra linguaggio e modellazione e processo di sviluppo sono principalmente: la maggiore probabilità di accettazione di un linguaggio di modellazione rispetto ad un processo di sviluppo; la sostanziale invarianza di un linguaggio di modellazione rispetto agli elementi che caratterizzano un sistema software, differentemente da quanto avviene per il processo di sviluppo che può essere profondamente influenzato da tali fattori. UML fornisce il potere espressivo necessario a modellare un sistema informatico da una prospettiva object-oriented: UML infatti consente di rappresentare le classi e gli oggetti che le compongono, lo stato di tali oggetti e il loro comportamento. UML inoltre permette di mantenere diverse viste di uno stesso sistema, descrivendo gli oggetti che lo compongono da differenti punti di osservazione (strutturale, comportamentale) e a diversi livelli di astrazione. Prima della definizione dell UML chiunque desiderasse utilizzare un modello objectoriented si trovava a scegliere fra linguaggi diversi, ma simili fra loro, con differenze a volte minime di potere espressivo. Molti di tali linguaggi condividevano un insieme di concetti di base eppure li interpretavano e rappresentavano in modo leggermente differente, generando in tal modo confusione e scoraggiando l adozione di modelli object-oriented nello sviluppo di sistemi software. UML è il risultato delle sforzo di unificazione condotto a partire dal 1994 per individuare un linguaggio standard nella modellazione orientata agli oggetti. Il linguaggio è stato sviluppato da Rational Software come il successore ai linguaggi di modellazione specificati da Booch, Jacobson (OOSE) e Rumbaugh (OMT) pur attingendo alcuni concetti anche da altri linguaggi di modellazione. La specifica del linguaggio UML ha raggiunto i seguenti obiettivi: ha stabilito un linguaggio di modellazione visuale, fornendo un mezzo di comunicazione standard per la modellazione object-oriented; ha individuato una base formale per la definizione del significato dei modelli supportati; 5

6 ha favorito la proliferazione di strumenti di sviluppo e componenti per la realizzazione di sistemi object-oriented; ha specificato un modello visuale non legato ad un particolare linguaggio o processo di sviluppo; ha integrato alcuni fra gli approcci più interessanti alla modellazione objectoriented. UML è stato proposto per la standardizzazione da parte dell OMG all inizio del 1997 e, dopo un processo di revisione che ha coinvolto le più importanti fra le industrie software, ha ottenuto la approvazione nella sua versione 1.1. UML è ora di dominio pubblico e grazie al processo di standardizzazione in cui è stato coinvolto, ai contributi forniti dalle industrie e dal settore scientifico esso potrà avere una ampia accettazione portando alla nascita di strumenti di modellazione, sviluppo e integrazione basati su di un modello di riferimento comune Schema del processo di sviluppo Nel seguito sarà descritto un processo di sviluppo iterativo, che si concilia con la metodologia object-oriented, con cui verrà condotta la progettazione. Il processo iterativo riduce in modo significativo i rischi di progetto negli stadi iniziali dello sviluppo e permette di ottenere un maggiore controllo sul sistema prodotto. Con un processo di sviluppo iterativo il sistema non viene rilasciato in un unica versione alla fine del progetto, ma viene sviluppato e rilasciato in porzioni, ciascuna delle quali contiene un sottoinsieme progressivamente crescente di funzionalità. Lo sviluppo risulta così suddiviso in iterazioni: durante ogni iterazione si realizza una porzione del sistema rispondente ad un determinato sottoinsieme delle specifiche. Ogni iterazione si articola a sua volta in analisi, progetto, codifica e sperimentazione. Al termine di ogni iterazione è prevista una verifica di quanto sviluppato con i futuri utenti ed i responsabili del progetto. Nel corso del processo di sviluppo vengono prodotti diversi modelli del sistema utilizzando il linguaggio di modellazione prescelto. La prospettiva in cui tali modelli sono prodotti cambierà durante il corso dello sviluppo: essa sarà infatti inizialmente orientata all analisi (definire formalmente cosa sviluppare) quindi al progetto (definire formalmente come svilupparlo, in termini di struttura e comportamento del software) e infine all implementazione (come realizzare, per mezzo degli strumenti di sviluppo individuati le soluzioni progettuali identificate nella fase precedente). Vale la pena di sottolineare in questa sede che, in linea generale, i diagrammi potranno essere disegnati con varie prospettive indipendentemente dal loro tipo. Infatti il tipo di diagramma dipende dal particolare aspetto del sistema (utilizzo, struttura, comportamento) che si desidera descrivere, mentre la prospettiva utilizzata per disegnarlo dipende dal grado di astrazione (concettuale, specifica, implementazione) con cui si è in grado di descriverlo allo stadio corrente del progetto. 6

7 Implementazione Raffinamento progressivo Gli aspetti strutturali del sistema sono descritti con diagrammi dello stesso tipo ma livelli crescenti di dettaglio. Specifica La specifica di differenti aspetti del sistema è descritta con diagrammi di tipo diverso ma medesimo livello di dettaglio. Concettuale Aspetti del sistema Utilizzo Struttura Comportamento Figura 4 - Prospettiva di utilizzo di un modello nei diversi momenti del processo di sviluppo Per utilizzare in modo efficace lo sviluppo iterativo è necessario adottare: un linguaggio di modellazione che garantisca la possibilità di accrescere il progetto del sistema attraverso il riutilizzo di componenti sviluppati precedentemente e sia resistente a successivi raffinamenti delle specifiche; un linguaggio di modellazione in grado di fornire viste del sistema da sviluppare a differenti livelli di astrazione, favorendo la costruzione di una nuova vista a partire da quelle già sviluppate. Il primo requisito è soddisfatto dai linguaggi di modellazione orientati agli oggetti perché, come accennato, questi offrono i migliori strumenti per costruire modelli flessibili e modificabili nel tempo attraverso i meccanismi dell ereditarietà, dell aggregazione e dell incapsulamento. I primi due consentono di costruire nuovi oggetti a partire da quelli preesistenti, sfruttando le relazioni is-a e part-of. Il secondo consente di modificare l implementazione di un determinato oggetto, ad esempio per migliorare le prestazioni di un operazione che esso definisce, senza per questo richiedere la modifica delle classi che utilizzano tale operazione, sfruttando il meccanismo dell incapsulamento. Il secondo requisito è soddisfatto dal linguaggio UML, che integra diversi modelli, permettendo di descrivere diversi aspetti dei componenti del sistema (struttura, comportamento, architettura) a diversi livelli di astrazione (concettuale, logico, implementativo). 7

8 1.6. Patterns UML fornisce un linguaggio per la modellazione mentre i patterns costituiscono il risultato di tale utilizzo: modelli di esempio. Un pattern rappresenta uno problema ricorrente per il quale è stata già individuata una soluzione che è stata applicata nel corso di un esperienza pratica: esso fornisce quindi una soluzione già verificata. D altra parte i patterns devono rappresentare un punto di partenza per individuare la soluzione ad un problema attuale: nel momento in cui si individua un pattern potenzialmente utile esso va provato, calandolo nel contesto del particolare progetto e adattato alle specifiche esigenze del progetto stesso. Gli elementi essenziali di un pattern sono: il nome, che permette di identificarlo all interno di una collezione di patterns; il problema, che descrive in quale contesto il pattern è stato individuato; la soluzione, che illustra le scelte operate per risolvere il problema e mette a disposizione un template per soluzioni a problemi simili; le conseguenze, che mostra i risultati dell applicazione della soluzione allo specifico problema in esame, individuando vantaggi e svantaggi. Vi possono essere pattern utili nelle attività di analisi e di progettazione. Un esempio di pattern di progetto, tratto da [Gamma94], è il seguente: si supponga di voler realizzare un sistema che implementi meccanismi di comunicazione fra oggetti in differenti processi. Un esigenza comune è quella di avere tali processi in esecuzione su procesori differenti e di voler realizzare un architettura in cui gli oggetti in esecuzione su di un processore non debbano specificare esplicitamente su quale processore si trovano gli oggetti cui devono accedere. Una soluzione a tale problema prevede l utilizzo di un proxy sullo stesso processore in cui si trovano gli oggetti chiamanti. Tale proxy presenterà la stessa interfaccia dell oggetto da invocare, così da svincolare gli oggetti locali dalle modalità di chiamata degli oggetti remoti. Subject request() <<method>> RealSubject.request() Real Subject request() Proxy request() Figura 5 - Pattern di progetto di un Proxy Un esempio di pattern di analisi, da [Fowler97B], è invece il seguente: si supponga di voler modellare un meccanismo per la gestione del rischio in un mercato finanziario. È necessario comprendere il modo in cui il valore di un portafoglio di azioni cambia nel 8

9 tempo, ad esempio mantenendo i prezzi per ogni azione con associato un time-stamp. Potrebbe inoltre essere utile essere in grado di prevedere rischi ipotetici oltre a quelli reali, effettuando analisi di tipo what-if. A tale scopo si può considerare il concetto di Scenario che contiene un insieme di azioni diverse. Scenario Istante temporale 1 * 1 Azione * Elemento Quotazione 1 * * 1 Figura 6 - Pattern di analisi di uno Scenario I pattern di analisi sono particolarmente utili per acquistare confidenza con un dominio non noto; d altra parte un pattern individuato nel contesto di un certo dominio può rivelarsi utile anche all interno di un dominio differente 1.7. Un primo esempio In questa sezione viene proposto un primo esempio di specifica di un sistema automatizzato per la prenotazione degli esami universitari. Tale esempio è utile per dare una prima vista generale alle caratteristiche del linguaggio di modellazione UML e identificare una sequenza di modelli prodotti nel corso del processo di sviluppo. In questo esempio sono descritti alcuni strumenti per la cattura dei requisiti e l analisi del sistema, come i diagrammi use case o il modello concettuale del dominio rappresentato per mezzo di un class diagram, e altri utili nella fase di progetto, come l interaction diagram e il modello di progetto delle classi del sistema descritto per mezzo di un class diagram. 9

10 Use cases Un primo use case per il sistema indicato è il seguente: Use case Prenotazione di un esame universitario Attori Descrizione Studente Lo use case inizia quando lo studente fornisce al sistema la propria matricola e il proprio codice fiscale per identificarsi. Il sistema verifica che lo studente sia regolarmente iscritto e quindi fornisce un elenco degli esami che lo studente può sostenere. Lo studente seleziona un esame, quindi il sistema suggerisce le prossime date per sostenere l esame. Lo studente seleziona la data prescelta e conferma la prenotazione. Lo use case termina quando il sistema fornisce un numero di registrazione allo studente. Il sistema può non riconoscere lo studente fra quelli iscritti regolarmente. Lo studente può interrompere la registrazione senza selezionare un esame o una data. Tabella 1- Descrizione testuale di uno use case Lo use case sopra introdotto può essere in parte descritto per messo di uno use case diagram Attore Relazione di associazione Use Case Prenota esame <<uses>> Studente Relazione uses Valida accesso Figura 7 - Diagramma use case Lo use case illustrato descrive una tipica interazione fra l utente del sistema ed il sistema stesso per lo svolgimento di un compito specifico. Esso costituisce un importante strumento di comunicazione fra committente e sviluppatore nel corso della elaborazione del progetto e consente una migliore comprensione dei processi da automatizzare. 10

11 Modello concettuale Il modello concettuale è un altro importante prodotto risultante dall analisi del dominio: mentre gli use cases descrivono i requisiti funzionali del sistema, il modello concettuale illustra il modo in cui gli oggetti vengono classificati e consente di mettere a fuoco il significato dei termini usati nella realtà di interesse. Esso permette di identificare i concetti, gli attributi e le associazioni considerate importanti nel dominio e può essere descritto per mezzo di diagrammi di classi quale quello che segue. Classe Attributi Studente nome matricola CF frequenta Corso materia anno accademico insegna Professore nome sostiene riguarda Relazione di associazione sottoscrive Esame data include Lista prenotazione Figura 8 - Modello concettuale del dominio descritto per mezo di un class diagram Si noti come il mo dello concettuale sopra descritto non descrive componenti software, oggetti del sistema da sviluppare, ma piuttosto rappresenta concetti del mondo reale all interno del dominio di interesse Diagrammi di interazione Un diagramma di interazione (interaction diagram) descrive il modo in cui gruppi di oggetti collaborano fra loro per svolgere un determinato compito. Tipicamente un diagramma di interazione descrive il flusso di eventi rappresentato in uno use case. Esso permette di assegnare delle responsabilità agli oggetti, mostrando come essi interagiscono fra di loro. 11

12 Oggetto : Studente : Modulo di registrazione : Gestore delle prenotazioni : Esame : Lista prenotazione Inserisci Dati Verifica Dati Prenota AggiungiStudente Messaggio Figura 9 Flusso di messaggi fra oggetti del sistema illustrato per mezzo di un sequence diagram Progetto e diagrammi delle classi Dopo aver descritto gli oggetti del sistema ed il modo in cui essi collaborano per la realizzazione di uno use case, per mezzo di un diagramma di interazione, è ora possibile specificare in dettaglio quali classi comporranno il sistema software. Queste informazioni possono essere catturate per mezzo di una diagramma delle classi di progetto. 12

13 Relazione di dipendenza Modulo di registrazione Gestore delle prenotazioni VerificaDati() Classe Esame data Prenota() Corso materia anno accademico * 1 Attributi Studente nome matricola CF 1 Lista prenotazione AggiungiStudente() Relazione di aggregazione Figura 10 Progetto dei componenti software del sistema illustrato per mezzo di un class diagram Questo diagramma illustra in che modo i componenti del sistema software sono connessi e quali metodi realizzano. 2. Il processo di sviluppo Identificare e seguire un processo di sviluppo è un attività necessaria per diminuire i rischi legati allo sviluppo di un sistema software. Inoltre una volta codificato un processo esso può essere ripetuto, rendendo l attività di sviluppo meno dipendente dal contributo che le singole risorse umane sono in grado di offrire [Larman97]. Il processo di sviluppo di un sistema software è costituito da un insieme di passi che consentono di muoversi dalle attività di analisi dei requisiti fino all implementazione e alla consegna del sistema. Obiettivo di tale processo è quello di sviluppare il sistema in oggetto secondo le esigenze del committente. Nel classico approccio allo sviluppo dei sistemi il modello seguito è quello a cascata in cui si distinguono diverse fasi ordinate linearmente: analisi, in cui si definiscono i requisiti del sistema e si descrive cosa si vuole realizzare; progetto, in cui si decide come realizzare il sistema; codifica, con l implementazione del sistema per mezzo di un linguaggio di programmazione; test, in cui si verifica la rispondenza del sistema implementato ai requisiti espressi; manutenzione, in cui si apportano cambiamenti al sistema. 13

14 Analisi Progetto Codifica Test Manutenzione Figura 11 - Schema del modello a cascata Il modello a cascata presenta però notevoli svantaggi. Nel mondo reale infatti i progetti raramente seguono il flusso sequenziale proposto dal modello ed è spesso difficile per il cliente dichiarare tutti i requisiti in modo esplicito nelle prime fasi del progetto. Inoltre il cliente dovrà attendere le ultime fasi del ciclo di vita per poter lavorare con il sistema e verificare quindi che le sue aspettative sono state soddisfatte. Questa situazione può rivelarsi assai penalizzante nello sviluppo di sistemi di grandi dimensioni: infatti tutti i problemi che si riscontreranno nel corso della verifica (test), dovuti ad errori commessi in una delle precedenti fasi, comporteranno correzioni che dovranno essere propagate attraverso tutti i precedenti passi che compongono il ciclo di vita. In tal modo potranno aumentare in modo significativo il tempo e i costi per la consegna del sistema, così come il rischio di insuccesso del progetto ( 1, [Standish95]) Il processo iterativo Il processo proposto nel seguito è stato desunto in larga parte da quello definito dai medesimi autori dell UML e denominato RATIONAL UNIFIED PROCESS e dalla metodologia OBJECTORY definita in [Jacobson94]; spunti significativi sono tratti anche da [Fowler97] e [Larman97]. RATIONAL UNIFIED PROCESS è un processo di sviluppo iterativo e incrementale: il sistema non viene rilasciato un'unica volta alla fine del processo, ma in passi successivi. Questo approccio presenta vantaggi significativi quanto più aumenta la complessità del sistema da sviluppare. Innanzitutto la comprensione del problema da risolvere non avviene in un unica fase iniziale, ma in passi successivi con il raffinamento e la crescita 1 Si consideri che negli USA secondo dati del 1995 circa un terzo dei progetti di sviluppo software non viene completato e più della metà ha un costo doppio rispetto alle previsioni iniziali. 14

15 incrementale di un medesimo modello nel corso di cicli successivi. Inoltre grazie ad un approccio iterativo è possibile accogliere nuove esigenze o modifiche negli obiettivi per i quali viene sviluppato il sistema. Infine l approccio iterativo permette di affrontare e risolvere nelle fasi iniziali i rischi collegati allo sviluppo del sistema, quali i rischi tecnologici, professionali e organizzativi. Il RATIONAL UNIFIED PROCESS è un processo incentrato sugli use cases: tale approccio consente di comprendere a fondo le esigenze degli utenti e gli use case individuati fin dalle prime fasi dello sviluppo del sistema costituiscono delle linee guida per i passi successivi, dalla pianificazione, all analisi dei requisiti, fino al test del sistema stesso. Il processo di sviluppo dovrà mettere in luce fin dall inizio l architettura software di riferimento. Ciò significa identificare i sottosistemi da sviluppare, assegnare loro delle responsabilità precise, individuando le interfacce fra tali componenti e il modo in cui essi possono interagire, allo scopo di realizzare le funzionalità previste dal sistema. L architettura verrà raffinata quindi nel corso dei successivi cicli di sviluppo e la sua qualità potrà essere misurata [Larman97] in termini di: chiarezza nella descrizione; robustezza e solidità rispetto a necessità di modifica dei requisiti; adozione di componenti riutilizzabili; articolazione in una struttura stratificata a sottosistemi; basso grado di accoppiamento fra i sottosistemi, con interfacce ben definite. Si noti infine come lo sviluppo dell architettura dovrà essere focalizzato fin dall inizio su quei componenti e sottosistemi che realizzano le funzionalità più critiche e complesse, allo scopo di minimizzare i rischi legati allo sviluppo del sistema. Altri elementi essenziali nel RATIONAL UNIFIED PROCESS sono: l adozione delle tecnologie object oriented, incluso il linguaggio di mo dellazione UML, la possibilità di configurare il processo di sviluppo per rispondere alle esigenze di sviluppo di sistemi differenti da parte di diverse organizzazioni, l adozione di criteri oggettivi per la misura della qualità dei prodotti nel corso di tutto il processo di sviluppo. Il RATIONAL UNIFIED PROCESS naturalmente non può essere applicato in modo identico nello sviluppo di qualsiasi sistema: esso però può essere adattato in funzione delle esigenze del progetto; fra i fattori che influenzano l esatta sequenza di passi da compiere e i prodotti del processo vi sono da esempio: il tipo di sistema da realizzare (applicazione per l automazione di un ufficio, sistema per il controllo di un satellite geostazionario, sistema informativo distribuito); le dimensioni del sistema (il grado di formalismo necessario nella produzione della documentazione può cambiare se il team è composto da due persone o da 20) Le fasi del processo Il processo di sviluppo delineato può essere suddiviso nelle seguenti fasi: avvio, la fase in cui si individua la necessità di realizzare un sistema, si misurano i benefici attesi e si stimano i costi; elaborazione, in cui si caratterizza in modo più preciso il sistema da realizzare e si mettono a fuoco l architettura di base, il modello concettuale di riferimento e la piattaforma tecnologica; 15

16 sviluppo, suddiviso a sua volta in iterazioni nel corso delle quali si realizzano versioni successive del sistema che soddisfano insiemi sempre più completi di requisiti; rilascio, in cui il sistema viene raffinato in termini di prestazioni e robustezza, e consegnato agli utenti finali. Ciascuna fase può essere suddivisa a sua volta in diverse iterazioni: ciascuna iterazione racchiude in se tutte le fasi di un processo di sviluppo classico, ovverosia analisi, progetto, codifica e test, e si conclude con la consegna di una versione del sistema. Avvio Elaborazione Sviluppo Rilascio Iter. 1 Iter Iter. N Figura 12 - Struttura del RATIONAL UNIFIED PROCESS Si noti come la suddivisione in iterazioni, sebbene enfatizzata in particolare per la fase di sviluppo, possa in realtà essere applicata a tutte le fasi del processo di sviluppo Distribuzione delle attività nelle diverse fasi Il RATIONAL UNIFIED PROCESS definisce inoltre una distribuzione indicativa delle attività che compongono il processo di sviluppo nelle diverse fasi. T EMPO Avvio Elaborazione Sviluppo Rilascio Modellazione del dominio Individuazione dei requisiti ATTIVITÀ Analisi e progettazione Codifica Test Dispiegamento Iterazioni preliminari iter 1 iter 2 iter 3... iter n iter n+1 iter n+2 Figura 13 - Distribuzione delle attività nelle diverse fasi del RATIONAL UNIFIED PROCESS Le medesime attività possono essere svolte nelle diverse fasi del progetto, pur in proporzioni differenti: così la fase di avvio sarà incentrata sulla descrizione della struttura dell organizzazione e dei suoi processi interni, la fase di elaborazione sulle attività di analisi e progettazione, la fase di sviluppo sulla codifica e test del sistema e la fase di rilascio sulle attività di dispiegamento del sistema stesso Avvio Obiettivo della fase di avvio è quello di individuare le esigenze generali alle quali il progetto di sviluppo deve rispondere e i confini del problema che si intende risolvere. Tale fase può essere altamente informale o arrivare a prevedere la stesura di uno studio 16

17 di fattibilità e lo sviluppo di un prototipo per verificare la validità delle esigenze individuate. Alla fine di questa fase si decide l avvio del progetto effettivo, dando inizio ad uno studio più approfondito del problema che contribuisca a identificare i tempi e i costi di realizzazione, e prevedere i rischi Elaborazione La elaborazione è necessaria per analizzare in modo approfondito l ambito del problema che si intende risolvere, identificare un architettura di riferimento, descrivere un possibile piano di sviluppo e ridurre i rischi legati allo sviluppo stesso. In questa fase dovranno essere catturati la maggior parte dei requisiti del sistema allo scopo di verificare che l architettura di riferimento individuata risponda in modo completo alle esigenze prospettate. Come indicato precedentemente anche la fase di elaborazione può seguire delle iterazioni per portare a raffinamenti successivi dei suoi prodotti Requisiti del sistema e dominio di interesse Un primo obiettivo della fase di elaborazione è quello di individuare i requisiti del sistema: essi costituiscono una descrizione delle necessità o dei desideri che gli utenti sono in grado di esprimere in relazione al sistema da realizzare. I requisiti hanno per oggetto gli obiettivi di alto livello che impongono la realizzazione del sistema, le funzioni che il sistema dovrà fornire (cosa fa il sistema) e le caratteristiche che esso offrirà (in che modo il sistema si comporta). Fra le caratteristiche non funzionali del sistema sono comprese la facilità di utilizzo, le prestazioni, la tolleranza all errore. I requisiti funzionali del sistema vengono catturati per mezzo degli use case: ciascuno use case descrive una possibile interazione che un utente ha con il sistema allo scopo di ottenere un risultato. Si pensi ad un impiegato che utilizza un sistema per la gestione di uno sportello bancario: un possibile use case è il seguente: Use Case Attori Descrizione CAMBIO DI UN ASSEGNO IN DENARO CONTANTE Cliente, Cassiere Un cliente arriva allo sportello bancario e consegna un assegno compilato e firmato. Il cassiere prende l assegno, verifica che il conto corrente cui fa riferimento l assegno abbia una disponibilità sufficiente, registra l operazione e consegna al cliente il denaro contante corrispondente. Ciascuno use case descrive una funzione del sistema che l utente può comprendere e rappresenta un oggetto del quale lo sviluppatore può valutare la complessità: esso assume la funzione di unità di misura del sistema da sviluppare. Un insieme di use cases può essere descritto utilizzando l UML per mezzo di uno use case diagram. Nel corso della fase di elaborazione sarà necessario identificare la maggior parte degli use cases relativi al sistema che si vuole realizzare, ad esempio per mezzo di interviste con gli utenti del sistema stesso. Gli use case potranno essere descritti a diversi livelli di dettaglio; a ciascuno di essi potrà essere associato un livello di rischio, una priorità in relazione alle esigenze degli utenti e un livello di astrazione al quale si colloca la descrizione della funzione del sistema. 17

18 Un altro prodotto della fase di elaborazione è il modello concettuale del dominio di interesse. Un modello concettuale descrive gli oggetti del mondo reale che sono di primaria importanza per lo svolgimento delle attività che il sistema deve automatizzare, il modo in cui essi sono associati gli uni agli altri e i loro attributi. Un modello concettuale è rappresentato per mezzo di un class diagram; i passi da compiere per disegnare tale diagramma sono: 1. identificare i concetti principali in base ai requisiti individuati e rappresentarli nel class diagram; 2. rappresentare le associazioni fra tali concetti per mezzo di relazioni fra le classi; 3. rappresentare gli attributi più significativi in ciascuna classe. È importante notare che le classi presenti nel modello concettuale non rappresentano oggetti del sistema da sviluppare ma unicamente oggetti del mondo reale che si intende descrivere. Il flusso del lavoro all interno del dominio, ovvero l insieme delle attività comunemente svolte nella realtà di interesse, può invece essere rappresentato per mezzo di un activity diagram; tale modello costituisce un complemento alla rappresentazione strutturale del dominio fornita dai class diagrams. Si noti che le attività fin qui descritte si influenzano a vicenda e i prodotti di ciascuna attività (insieme dei requisiti, modello dei concetti e modello dei processi) dipendono dagli altri: ad esempio i termini e le operazioni utilizzati nella descrizione dei requisiti possono costituire una base per l individuazione dei concetti e dei processi da modellare; tali modelli a loro volta consentono di verificare la completezza e la coerenza dei requisiti raccolti, e offrono importanti spunti per ampliare la base iniziale. Individuazione dei requisiti Modellazione dei concetti Modellazione dei processi Figura 14 - Flusso di lavoro per la individuazione di requisiti e la costruzione del modello del dominio Nel corso della fase di elaborazione viene inoltre disegnata una prima versione del modello di progetto del sistema; tale modello introduce le classi principali che rappresentano componenti software da sviluppare per un corretto funzionamento del 18

19 sistema e rappresenta l ossatura dell architettura del sistema. Tale modello verrà arricchito nel corso della fase di sviluppo con la verifica e il dettaglio delle decisioni progettuali introdotte. Un ulteriore prodotto della fase di elaborazione può essere un prototipo: questo può essere utilizzato per verificare l esatta comprensione degli aspetti dinamici della realtà in esame Piattaforma tecnologica Nel corso della fase di elaborazione è importante definire la piattaforma tecnologica per lo sviluppo del sistema. Questa include: l insieme delle componenti di sistema utilizzate (sistema operativo, middleware, ); l insieme delle componenti da acquisire da terze parti (DBMS, software per la gestione di un workflow, software per l archiviazione ottica, ); l insieme degli strumenti di sviluppo (inclusi strumenti di supporto alle attività di analisi e progettazione, compilatori, strumenti per l automazione delle attività di test, ); Individuata la piattaforma è importante verificare le possibilità di integrazione fra le componenti individuate, allo scopo di minimizzare i rischi tecnologici: ad esempio un motore di workflow di terze parti potrebbe non integrarsi correttamente con una particolare classe di DBMS e portare a mutare le scelte già effettuate. La verifica di integrazione fra le componenti può essere condotta tramite lo sviluppo di prototipi che utilizzino un sottoinsieme delle componenti tecnologiche selezionate Architettura del sistema La fase di elaborazione ha come prodotto la specifica dell architettura del sistema da realizzare. L architettura è composta da differenti viste del sistema, quali l insieme dei requisiti, il modello concettuale, il modello di progetto e la descrizione della piattaforma tecnologica; essa individua la ripartizione di componenti del sistema secondo due coordinate principali: livelli di astrazione (componenti che poggiano l uno sull altro si collocano a differenti livelli di astrazione); partizioni ad un medesimo livello di astrazione (componenti che si collocano ad un medesimo livello di astrazione e collaborano alla realizzazione di una funzionalità comune ). L architettura individuata in questa fase è inevitabilmente soggetta a modifiche nei dettagli, ma dovrebbe guidare gli sviluppatori nel corso di tutto il processo senza richiedere modifiche sostanziali Piano di realizzazione Un ultimo prodotto della fase di elaborazione è un piano di realizzazione che fornisca: una stima dei tempi e dei costi per lo sviluppo complessivo del sistema; la scelta della durata delle iterazioni e del numero di iterazioni che comporranno la fase di sviluppo; 19

20 l allocazione degli use cases all interno delle iterazioni; l assegnazione ad ogni iterazione di una data di inizio e di fine. Il primo passo in questa attività consiste nella classificazione degli use cases in base a caratteristiche quali: la priorità per gli utenti, la presenza di rischi architetturali o di progetto o tecnologici, la difficoltà nella stima del tempo necessario al loro sviluppo. Quindi per ogni use case viene prodotta una stima del tempo e delle risorse necessarie per lo sviluppo: questa stima deve comprendere tutte le attività classiche per lo sviluppo di una porzione del sistema, analisi, progetto codifica e test. È molto importante che la stima dei tempi di realizzazione e dei costi collegati venga effettuata dalle medesime persone che assumeranno la responsabilità della realizzazione degli use cases. A questo punto viene individuata la durata massima prevista per ciascuna iterazione. Tale scelta è basata su considerazioni pratiche: non è opportuno avere iterazioni troppo brevi, perché ciascuna iterazione comporta un sovraccarico di lavoro per la gestione del suo avvio e della verifica dei risultati raggiunti; non è opportuno avere iterazioni troppo lunghe perché si perderebbero i vantaggi derivanti dall adozione di un processo iterativo, come la diminuzione della complessità e dei rischi di sviluppo per ciascuna iterazione. In letteratura i tempi indicati oscillano fra le due settimane e i due mesi di lavoro [Fowler97] [Larman97]. L allocazione degli use case all interno delle singole iterazioni deve portare a pianificare prima quegli use case che presentano un rischio di sviluppo più elevato: in tal modo è possibile far diminuire più velocemente il fattore di rischio collegato al progetto nel corso della fase di sviluppo. Alcuni use case particolarmente complessi possono essere suddivisi e realizzati in differenti versioni all interno di più iterazioni. La stima del tempo necessario alla fase di rilascio è particolarmente critica: tutte le attività di ottimizzazione, raffinamento e dispiegamento del sistema possono essere più o meno costose in funzione del tipo di sistema da realizzare (una stima riportata in [Fowler97] indica tempi fra il 10% e il 35% del tempo di sviluppo) Sviluppo In questa fase il sistema viene realizzato nel corso di una o più iterazioni. Ciascuna iterazione è simile a un progetto a se stante, completo di tutte le attività dall analisi al test. Al termine di ciascuna iterazione gli utenti collaudano il sistema verificando che esso risponda in modo completo alle caratteristiche indicate per l iterazione in corso. 20

21 Sistema 1 Sistema 2 Sistema finale Figura 15 Ad ogni iterazione gli utenti verificano la versione del sistema che viene prodotto fino ad ottenere un sistema finale che risponde a tutti i requisiti individuati Il sistema nel corso delle successive iterazioni si accresce in modo incrementale: ad ogni iterazione nuove funzionalità vengono sviluppate e aggiunte a quelle previste dagli use cases delle precedenti iterazioni. Nel corso di ogni iterazione potrà essere modificata una parte del sistema già sviluppata allo scopo di migliorare la qualità delle soluzioni già individuate 2 : tali modifiche sono tipicamente piccole, non aggiungono funzionalità, ma comportano in ogni caso l esecuzione di nuovi test sulle porzioni di sistema interessate. Poiché ad ogni iterazione si sviluppa una versione del sistema in produzione a partire da una precedente, è fondamentale che il modello del sistema consenta di costruire nuovi oggetti componendoli per mezzo di oggetti preesistenti, di raffinare un oggetto a partire da oggetti preesistenti, di modificare l implementazione di un oggetto senza modificare la sua interfaccia. Un modello object-oriented è in grado di offrire le caratteristiche desiderate: esso supporta infatti i meccanismi di aggregazione, ereditarietà e incapsulamento. Si supponga di dover realizzare un sistema per la gestione di uno sportello bancario; nel corso di delle precedenti iterazioni si è realizzata una porzione del sistema che include la classe CASSA, che rappresenta l insieme dei valori che un operatore di sportello ha a disposizione, e la classe VALORE, che rappresenta un oggetto generico cui è associato un valore in una determinata divisa. Sfruttando il meccanismo dell aggregazione è possibile specificare un nuovo tipo di oggetto, lo SPORTELLO che aggrega la CASSA, ove in tal modo si intende esprimere il fatto che la cassa è un elemento costituente di uno sportello bancario. Inoltre nel corso della medesima iterazione si potrà definire la classe ASSEGNO come specializzazione della classe VALORE, indicando per la nuova classe le caratteristiche aggiuntive che essa possiede rispetto alla classe di partenza, utilizzando il meccanismo dell ereditarietà. Infine se la classe CASSA mette a disposizione l operazione BILANCIOFINEGIORNATA sarà possibile modificare l implementazione di tale operazione, senza per questo dover modificare il modo in cui tale operazione è utilizzata da altre classi, sfruttando il meccanismo dell incapsulamento. 2 Tale tecnica è detta refactoring. 21

22 All inizio di ciascuna iterazione può essere raffinata o rivista la pianificazione già stabilita, verificando che la situazione corrente sia in accordo con quanto previsto inizialmente. Le date di chiusura di ciascuna iterazione infatti non possono essere modificate, ma se necessario il gruppo di sviluppo e gli utenti possono accordarsi per spostare alcuni use cases da un iterazione all altra. L analisi già effettuata nel corso della fase di elaborazione viene approfondita nelle iterazioni successive: il modello concettuale, il modello del flusso di lavoro e l insieme degli use cases pianificati per l iterazione sono un buon punto di partenza per discutere con gli esperti del dominio. Ogni iterazione prevede le seguenti attività: identificazione delle classi e degli oggetti necessari alla progettazione delle porzione di sistema interessata dall iterazione; specifica del comportamento delle diverse classi; analisi delle relazioni fra le classi; definizione dell interfaccia di ciascuna classe e sua implementazione. Il progetto della porzione di sistema da sviluppare può quindi essere raffinato utilizzando costrutti dell UML quali: gli interaction diagrams, che permettono di illustrare come gli oggetti del sistema dialogano fra di loro per soddisfare i requisiti del sistema; i class diagram di progetto, che consentono di definire i componenti del sistema 3. Un class diagram di progetto descrive la specifica del sistema in termini di classi e interfacce fra le classi; esso comprende: le classi, con le loro associazioni e attributi; le interfacce fra le classi; i metodi che ciascuna classe deve supportare; le relazioni di dipendenza fra le classi. La specifica di un interaction diagram consente di identificare le interazione fra gli oggetti del sistema assegnando loro delle precise responsabilità: questa attività è di fondamentale importanza perché influenza la robustezza del sistema, la possibilità di produrre componenti riutilizzabili, la flessibilità dell architettura. L assegnazione delle responsabilità agli oggetti risulta indispensabile per la produzione del sistema e richiede una profonda esperienza nello sviluppo di sistemi object oriented. Le attività di individuazione di classi e assegnazione di compiti alle classi, allo scopo di realizzare un sistema che assolva determinati compiti secondo i requisiti espressi, possono ricevere un aiuto significativo dall utilizzo di modelli di riferimento che racchiudano in se la soluzione a problemi di progettazione comuni. Tali modelli vengono comunemente chiamati design patterns [Gamma94] Rilascio Sebbene la maggior parte delle attività di sviluppo sono eseguite ciclicamente nel corso delle diverse iterazioni, alcune possono essere pianificate solamente alla fine del 3 Si ricordi invece che i class diagram a livello concettuale consentono di descrivere i concetti presenti nel dominio di interesse. 22

23 processo, quando tutte le funzionalità previste sono state realizzate e il sistema risponde in pieno ai requisiti funzionali. A questo punto dello sviluppo il sistema viene fornito agli utenti: spesso in questa fase sorgono problemi riguardanti le sue prestazioni o la sua stabilità in condizioni operative. È opportuno che l ottimizzazione del sistema sia pianificata alla fine del ciclo di sviluppo, perché può diminuire la chiarezza delle soluzioni adottate, rendendo più difficili ulteriori modifiche al sistema stesso. 3. Modellazione per mezzo dell UML Allo scopo di comprendere come utilizzare l UML si introduce in questa sezione una descrizione informale del linguaggio; tale descrizione include gli elementi atomici del linguaggio e le regole che permettono di comporre tali elementi. Quindi sono descritti i diversi diagrammi prodotti utilizzando il modello Atomi dell UML Gli atomi del linguaggio UML sono gli elementi, le relazioni fra gli elementi e i diagrammi che raggruppano elementi e relazioni di interesse. Gli elementi si articolano a loro volta in: elementi strutturali, che descrivono la parte statica del modello; elementi comportamentali, che descrivono i suoi aspetti dinamici; elementi di raggruppamento, che suddividono un modello in gruppi di oggetti; elementi di annotazione, che consentono di inserire commenti all interno del modello Elementi strutturali Gli elementi strutturali sono elementi grafici che descrivono la parte più statica di un modello, a diversi livelli di specifica. Un primo esempio di elemento strutturale è la CLASSE, che descrive un insieme di oggetti, con i medesimi attributi, operazioni e relazioni. Una classe è rappresentata per mezzo di un rettangolo all interno del quale sono elencati il nome, gli attributi e le operazioni. Paziente Nome Indirizzo Ammetti() Figura 16 - Classe Un secondo elemento strutturale è l INTERFACCIA: esso definisce un insieme di operazioni che costituiscono un servizio offerto da una classe o da un componente. L interfaccia descrive quindi il comportamento di un elemento, così come visibile all esterno, in modo completo o parziale. Un interfaccia definisce un insieme di 23

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML)

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) a cura di Giacomo PISCITELLI Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Questi appunti sono ricavati da una

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

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

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

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

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

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

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

Dettagli

UML - Unified Modeling Language

UML - Unified Modeling Language UML E CASI D USO UML - Unified Modeling Language Linguaggio stardardizzato per identificare e modellizzare le specifiche di un S.I. Coerente con il paradigma della programmazione ad oggetti Definito a

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

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

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del A. A. 2004-2005 1 La progettazione È applicata indipendentemente dal modello di processo utilizzato. Parte dal punto in cui sono

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Un negozio di musica vende anche libri e riviste musicali. Si intende automatizzare l intero processo, dall approvvigionamento alla vendita. Si analizzino i requisiti e se ne rappresentino

Dettagli

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo Progetto software 2008/2009 Docente Marianna Nicolosi Asmundo Obiettivi del corso Coinvolgervi nello sviluppo di un progetto software in cui mettere a frutto le conoscenze che avete acquisito durante i

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

13. Ciclo di Vita e Processi di Sviluppo

13. Ciclo di Vita e Processi di Sviluppo 13. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 13. Ciclo di Vita e Processi

Dettagli

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Luciano Baresi Luciano Baresi 1 OMT Booch UML Sono simili in molti aspetti: Prescrivono un approccio passo-passo Consentono il passaggio dall analisi al progetto in modo omogeneo

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Automazione Industriale 4- Ingegneria del Software

Automazione Industriale 4- Ingegneria del Software Automation Robotics and System CONTROL Università degli Studi di Modena e Reggio Emilia Automazione Industriale 4- Ingegneria del Software Cesare Fantuzzi (cesare.fantuzzi@unimore.it) Ingegneria Meccatronica

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano.

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. di: Enrico MASTROFINI Ottobre 2004 Nella formulazione iniziale del Piano Ict sono di solito inseriti

Dettagli

UML un linguaggio universale per la modellazione del software. Adriano Comai

UML un linguaggio universale per la modellazione del software. Adriano Comai UML un linguaggio universale per la modellazione del software Adriano Comai 2 Finalmente uno standard per l analisi e disegno OO? L'obiettivo è ambizioso. Lo Unified Modeling Language (UML) vuole essere,

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

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

Fase di offerta. Realizzazione del progetto

Fase di offerta. Realizzazione del progetto Linee guida per un buon progetto Commissione dell informazione e dei Sistemi di Automazione Civili e Industriali CONTENUTI A) Studio di fattibilità B) Progetto di massima della soluzione C) Definizione

Dettagli

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it Progetto Struttura del documento di specifica dei requisiti, Casi d uso manuel.comparetti@iet.unipi.it 1 Documenti da produrre Il progetto deve comprendere i seguenti documenti: Documento di specifica

Dettagli

La Gestione della Complessità

La Gestione della Complessità La Gestione della Complessità Only variety can destroy variety (Ross. W. Ashby) Prof. Claudio Saita 1 La struttura del modello cognitivo proposto, conosciuto più comunemente in letteratura come la legge

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

PROGETTAZIONE DEL SOFTWARE

PROGETTAZIONE DEL SOFTWARE PROGETTAZIONE DEL SOFTWARE EMILIANO CASALICCHIO DIPARTIMENTO DI INFORMATICA E SISTEMISTICA SAPIENZA UNIVERSITÀ DI ROMA SEDE DI RIETI HTTP://WWW.CE.UNIROMA2.IT/COURSES/PSW! Cos è UML UNIFIED MODELING LANGUAGE!

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

1. Il ruolo della pianificazione nella gestione del progetto

1. Il ruolo della pianificazione nella gestione del progetto 11 1. Il ruolo della pianificazione nella gestione del progetto Poiché ciascun progetto è un processo complesso ed esclusivo, una pianificazione organica ed accurata è indispensabile al fine di perseguire

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

e.toscana Compliance visione d insieme

e.toscana Compliance visione d insieme Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Ingegneria dei Sistemi Informativi e della Comunicazione I.T.S.A.E. e.toscana Compliance visione d insieme Gennaio 2007 Versione

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 22 Sommario 1 Generalità

Dettagli

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Ingegneria del Software I. UML - Use Case Diagram

Ingegneria del Software I. UML - Use Case Diagram Requisiti e casi d uso Unified Modeling Language Use Case Diagram 1 Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisiti Definizione del Business Model Solitamente informale

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA FIGURA

Dettagli

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I

REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I REQUISITI FUNZIONALI DELLE PROCEDURE ELETTRONICHE PER GLI APPALTI PUBBLICI NELL UE VOLUME I GENNAIO 2005 eprocurement pubblico Clausola di esclusione della responsabilità Commissione europea Original document

Dettagli

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO DIREZIONE EMITTENTE CONTROLLO DELLE COPIE Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile

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

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

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

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

Dettagli

Liceo Tecnologico. Indirizzo Informatico e Comunicazione. Indicazioni nazionali per Piani di Studi Personalizzati

Liceo Tecnologico. Indirizzo Informatico e Comunicazione. Indicazioni nazionali per Piani di Studi Personalizzati Indirizzo Informatico e Comunicazione Indicazioni nazionali per Piani di Studi Personalizzati Indirizzo Informatico e Comunicazione Discipline con attività di laboratorio 3 4 5 Fisica 132 Gestione di progetto

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

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

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

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

TECNICO SUPERIORE PER LE TELECOMUNICAZIONI

TECNICO SUPERIORE PER LE TELECOMUNICAZIONI ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE TELECOMUNICAZIONI STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1]

Progettazione di basi di dati. Progettazione di basi di dati. Ciclo di vita dei sistemi informativi. Fasi del ciclo di vita [1] Progettazione di basi di dati Progettazione di basi di dati Requisiti progetto Base di dati Struttura Caratteristiche Contenuto Metodologia in 3 fasi Progettazione concettuale Progettazione logica Progettazione

Dettagli

REFERENZIAZIONI 2001) NUP

REFERENZIAZIONI 2001) NUP Agenzia del Lavoro Provincia Autonoma di Trento PROFILO FORMATIVO Profilo professionale e percorso formativo DENOMINAZIONE FIGURA PROFESSIONALE - TECNICO INFORMATICO PROGRAMMATORE SOFTWARE E APPLICAZIONI

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Il modello Entity-Relationship per il progetto delle basi di dati

Il modello Entity-Relationship per il progetto delle basi di dati 1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Le metodologie di progettazione delle Basi di Dati 2 Una metodologia

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt IT Project Management Lezione 3 Scope Management Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Progettazione ad oggetti

Progettazione ad oggetti Progettazione ad oggetti Gli elementi reali vengono modellati tramite degli oggetti Le reazioni esistenti nel modello reale vengono trasformate in relazioni tra gli oggetti Cos'è un oggetto? Entità dotata

Dettagli

PARTE SECONDA La pianificazione strategica

PARTE SECONDA La pianificazione strategica PARTE SECONDA La pianificazione strategica 1. La pianificazione strategica dell impresa marketing oriented Di cosa parleremo Tutte le principali economie sono attualmente caratterizzate da continui e repentini

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

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

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

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab.

Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Dalla Conformità al Sistema di Gestione Tab. Il Sistema Qualità come modello organizzativo per valorizzare e gestire le Risorse Umane Gli elementi che caratterizzano il Sistema Qualità e promuovono ed influenzano le politiche di gestione delle risorse

Dettagli

Un modello è ragionevole quando contiene queste tre caratteristiche.

Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Si consideri un agenzia che opera come biglietteria ferroviaria, aerea e navale, accettando diversi modi di pagamento. Si identifichino le principali entità coinvolte illustrando le gerarchie

Dettagli

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio.

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio. Testo Esercizio Si consideri un sistema per la gestione di un magazzino di un negozio scelto a piacere dal candidato Il sistema è in grado di gestire le seguenti operazioni: Arrivo di nuovi prodotti; Controllo

Dettagli

Ministero dell istruzione, dell università e della ricerca. Liceo Tecnologico. Indirizzo Informatico, Grafico e Comunicazione

Ministero dell istruzione, dell università e della ricerca. Liceo Tecnologico. Indirizzo Informatico, Grafico e Comunicazione Ministero dell istruzione, dell università e della ricerca Liceo Tecnologico Indirizzo Informatico, Grafico e Comunicazione Percorso Informatico e Comunicazione Indicazioni nazionali per i Piani di Studio

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

Dettagli

Le fasi di un percorso di consultazione online

Le fasi di un percorso di consultazione online Progetto PerformancePA Ambito A - Linea 1 - Una rete per la riforma della PA Le fasi di un percorso di consultazione online Autore: Angela Creta, Laura Manconi Creatore: Formez PA, Progetto Performance

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

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/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

BOZZA DEL 06/09/2011

BOZZA DEL 06/09/2011 ARTICOLAZIONE: INFORMATICA Disciplina: COMPLEMENTI DI MATEMATICA (C4) Il docente di Complementi di matematica concorre a far conseguire allo studente, al termine del percorso quinquennale, i seguenti risultati

Dettagli

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Si consideri la realizzazione di un semplice programma grafico per il disegno di figure geometriche in due dimensioni. Si analizzino i requisiti e se ne rappresentino i risultati in UML

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