Corsi di laurea triennale/magistrale in Ingegneria Informatica Corsi di Ingegneria del software, Modellazione ed Implementazione di un Sistema Software per la gestione informatizzata di un ristorante: Il PROCESSO UNIFICATO
Traccia del tema d anno Si vuole sviluppare un sistema software per la gestione informatizzata di un ristorante. Tra le funzionalità che il software deve fornire, ad esempio, si dovrà considerare la gestione di un numero illimitato di tavoli, la visualizzazione di tavoli sulla piantina del ristorante, la visualizzazione grafica dello stato di ciascun tavolo, la prenotazione dei tavoli, la gestione delle ordinazioni mediante palmare, la stampa delle comande nei diversi reparti interessati, la stampa di fattura o scontrino fiscale. Selezionato un opportuno modello di processo si produca il piano dettagliato del progetto motivando la scelta effettuata e documentando le considerazioni che hanno condotto alla scelta del modello. Produrre la documentazione del software comprendente: documento dei requisiti, test plan, documentazione di progetto. Implementare il software modellato.
Passo 0: Scelta del modello di processo per lo sviluppo del software Cascata a rigide fasi sequenziali oppure sue varianti con prototipi e ritorni Incrementali realizzazione in più passi (Rapid Application Development) RAD Evolutivi modelli ciclici con ripetute iterazioni interne Prototipi Spirale contesto allargato a modello astratto Modelli specializzati Sviluppo a componenti Software orientato dall aspetto Processo unificato (UP)
Perché il PROCESSO UNIFICATO? UP è un processo iterativo molto diffuso per lo sviluppo del software per la costruzione di sistemi orientati agli oggetti Il cambiamento è incessante nei progetti software. Lo sviluppo iterativo è organizzato in una serie di progetti brevi, di lunghezza fissa, chiamate iterazioni; il risultato di ciascun iterazione è un sistema eseguibile, testato e integrato ma parziale. Ciascuna iterazione comprende la propria mole di attività: di analisi dei requisiti, progettazione, implementazione e test. L idea principale apprezzata e praticata in UP è lo sviluppo iterativo, evolutivo e adattivo, con timeboxing breve( le iterazioni hanno una lunghezza fissata) l uso di un processo non adatto può ridurre la qualità o l utilità del prodotto software che si sta sviluppando, o alzarne i costi
Vantaggi del PROCESSO UNIFICATO Affrontare le problematiche di rischio maggiore e valore elevato nelle iterazioni iniziali Impegnare gli utenti continuamente sulla valutazione, il feedback e i requisiti Creare un architettura coesa nelle iterazioni iniziali Verificare continuamente la qualità Fare della modellazione visuale( con UML) Gestire attentamente i requisiti Gestire le richieste di cambiamento e le configurazioni
Fasi del PROCESSO UNIFICATO E possibile individuare quattro fasi componenti, e precisamente: IDEAZIONE: Visione approssimativa, studio economico, portata, stime approssimative dei costi e dei tempi ELABORAZIONE: Visione raffinata, implementazione iterativa del nucleo dell architettura, risoluzione dei rischi maggiori, identificazione della maggior parte dei requisiti e della portata, stime più realistiche COSTRUZIONE: Implementazione iterativa degli elementi rimanenti più facili e a rischio minore e preparazione al rilascio TRANSIZIONE: Beta test, rilascio agli utenti
I FASE U.P.: IDEAZIONE L ideazione è il passo iniziale che permette di stabilire una visione comune e una portata di base per il progetto. Essa comprende l analisi dettagliata di circa il 10-20% dei casi d uso, l analisi dei requisiti non funzionali più critici, la creazione di uno studio economico e la preparazione dell ambiente di sviluppo, in modo tale che la programmazione possa iniziare nella fasi successive. Gli elaborati in UP sono molteplici e sono considerati del tutto opzionali Poiché si tratta di sviluppo evolutivo, in questa fase non vengono create specifiche complete, ma solo documenti preliminari e approssimativi che verranno raffinati nel corso delle iterazioni della seconda fase del processo unificato
Fase di IDEAZIONE: Analisi dei requisiti Il termine Requisiti sta a indicare quelle capacità e condizioni cui il sistema, e più in generale il progetto, deve essere conforme. In UP i requisiti sono divisi in categorie in base al modello FURPS+, acronimo di: Functionality = Funzionalità (Caratteristiche funzionali, capacità, sicurezza) Usability = Usabilità (Fattori umani, help, documentazione) Reliability = Affidabilità (Gestione degli errori e dei crash) Performance = Prestazioni ( Tempo di risposta, throughput, uso delle risorse,..) Supportability = Supportabilità (Capacità di garantire assistenza, mantenimento, configurabilità) Il segno +, indica requisiti complementari e secondari, quali: Implementazione: Limitazione sulle risorse, linguaggi e strumenti, hardware, Interfaccia: Vincoli imposti dalla necessità di interfacciarsi con sistemi esterni Operativi: Gestione del sistema nel suo contesto operativo Fisici: Per esempio, vincoli sulle dimensioni per l hardware Legali: licenze,. I requisiti di usabilità, affidabilità, prestazioni, supportabilità ed altri sono detti attributi di qualità o requisiti di qualità di un sistema. Nell uso comune, i requisiti sono classificati in requisiti FUNZIONALI ( comportamentali) e requisiti NON-FUNZIONALI (tutti gli altri). L analisi degli attributi di qualità è molto importante perché hanno una forte influenza sull architettura del sistema.
Analisi dei requisiti: Elaborati UP offre diversi elaborati dei requisiti, che sono opzionali. Gli elaborati principali sono: Modello dei Casi d Uso: Descrive i requisiti funzionali in forma di casi d uso (vengono identificati tutti i nomi dei casi d uso ma solo il 10%-20% viene dettagliato nella fase di ideazione); Specifiche Supplementari: Descrive i requisiti non funzionali e caratteristiche funzionali non espresse nei casi d uso (report, packaging, licenze, performance,..); Glossario: Terminologia del dominio e dizionario dei dati (regole di validazione, valori accettabili, struttura dei report, ); Visione: Descrive Obiettivi e vincoli di alto livello, Studio economico, Sommario del progetto. E un documento sintetico per apprendere rapidamente le idee principali del progetto (una sorta di Executive Summary ) Lista dei Rischi & Piano di Gestione dei Rischi: Descrive i rischi( aziendali, tecnici, di risorse, ) e le idee per attenuarli o rispondervi; Piano delle fasi & Piano di sviluppo del software: Ipotesi riguardo alla durata e allo sforzo della fase di elaborazione. Strumenti, persone, formazione e altre risorse; Prototipi e Proof-Of-Concept: Per chiarire la visione e validare delle idee tecniche; Piano dell Iterazione: Descrive che cosa fare nella prima iterazione dell elaborazione; Scenario di Sviluppo: Descrizione della personalizzazione dei passi e degli elaborati di UP per il progetto in studio.
Analisi dei requisiti: Elaborati Si sceglie di produrre esclusivamente quei documenti che aggiungono realmente valore al progetto, scartando gli altri Non vi è rigidità sulla questione dell ordine di realizzazione degli elaborati, essendo un processo evolutivo ed iterativo; gli elaborati vengono creati realizzando bozze iniziali in questa fase, e potrebbero subire raffinamenti, in parte o nella totalità, nella fase successiva Disciplina Elaborato Ideazione Elaborazione Costruzione Transizione Requisiti Modello dei casi I R d uso Visione I R Specifiche Supplementari I R Glossario I R Tabella - Esempio di tempificazione degli elaborati principali di UP ( I= inizio; R= raffinamento)
Analisi dei requisiti: Elaborato «VISIONE» In questa prima fase di UP, viene realizzata una prima bozza dell elaborato Visione, al fine di riassumere i requisiti ad alto livello che saranno dettagliati nel Modello dei casi d uso e nelle specifiche supplementari. Questo documento che verrà raffinato nella fase successiva di UP, in questa prima fase mostra esclusivamente una visione complessiva del progetto e non dettagliata
Analisi dei requisiti: Elaborato «SPECIFICHE SUPPLEMENTARI» Nelle prime due fasi di UP, l elaborato Specifiche supplementari è uno dei più importanti, in quanto raccoglie altri requisiti, informazioni e vincoli che difficilmente vengono colti nei casi d uso, o per l approccio adottato nello stilarli vengono nascosti. In particolare vengono raccolti gli attributi di qualità e i requisiti URPS+ a livello di intero sistema. L elaborato riportato, è solo una bozza realizzata in fase di ideazione
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» La stima dei costi e della tempistica del progetto sono due attività che solitamente vengono eseguite congiuntamente. I costi di sviluppo sono primariamente i costi dello sforzo richiesto. Queste stime iniziali sono importanti al fine di determinare un budget per il progetto e per stabilire il prezzo del software per il cliente. Nel costo totale di un progetto di sviluppo software, i parametri principali da considerare sono: Costi hardware e software, compresa la manutenzione; I costi di viaggio e di formazione; I costi dello sforzo. Tralasciando i costi di viaggio, dal momento che fanno riferimento a quelle spese effettuate quando il progetto viene sviluppato in diverse sedi, i costi dello sforzo sono quelli dominanti. I costi dello sforzo non sono solo lo stipendio degli ingegneri del software coinvolti nel progetto ma occorre considerare altri costi, come: I costi di rifornimento, riscaldamento e illuminazione degli uffici; I costi di supporto allo staff come contabili, amministratori, gestori di sistema, personale delle pulizie e tecnici; I costi di rete e telecomunicazioni; Etc.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Non esiste un metodo semplice per fare una stima accurata dello sforzo richiesto per sviluppare un sistema software. Si dovrebbero fare stime iniziali sulla base della definizione dei requisiti utente di alto livello. E impossibile stimare i costi di sviluppo del sistema accuratamente nei primi stadi del progetto. Nel corso degli ultimi anni, sono stati proposti diversi modelli algoritmici come base per la stima dei costi dello sforzo, che concettualmente sono simili ma utilizzano parametri diversi. Le principali metriche che sono state adottate sono quelle di dimensione, in termini di numero di righe del codice sorgente, e le metriche di funzione, dove la produttività viene espressa in termini di quantità di funzionalità utili da produrre. Tutti i modelli algoritmici soffrono di alcune difficoltà fondamentali; infatti spesso è difficile stimare la dimensione del codice del software al primo stadio di un progetto, e di molto le stime variano da una persona all altra a seconda del background e dell esperienza con il tipo di sistema che si sta sviluppando.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» La stima dei costi da realizzare fa capo al modello COCOMO(COnstructive COst Model, Modello costruttivo di costo), un modello empirico derivato dalla raccolta di dati da un vasto numero di progetti software. La scelta di adottare questo modello deriva dal fatto che: è un modello ben documentato, pubblicamente accessibile e supportato da strumenti pubblici e commerciali, è stato utilizzato e valutato in molte organizzazioni ed infine ha un solido background, dalla sua prima istanziazione avvenuta nel 1981 da parte di Boehm, fino alla sua ultima versione, COCOMO II, pubblicata nel 2000. Il COCOMO I presuppone un sviluppo software secondo un modello a cascata. Visti i cambiamenti radicali nello sviluppo software, venne istanziato il COCOMO II, il quale ricorre a diversi approcci allo sviluppo software come prototipizzazione, sviluppo tramite composizione di componenti e uso di programmazione di database.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Il Modello di stima adottato per il progetto in oggetto è proprio il COCOMO II, il quale integra diversi sotto-modelli che producono stime sempre più dettagliate. Il sotto-modello da adoperare, dal momento che la stima è eseguita in questa prima fase di ideazione dello sviluppo è quello del Modello di progettazione iniziale. Le stime prodotte a questo stadio si basano sulla formula standard: dove: - A è pari a 2.94; Effort (sforzo) = A x Size B x M - Size è la dimensione del sistema espressa in KSLOC, ovvero in migliaia di righe di codice sorgente e si calcola stimando il numero di punti funzione nel software; - B, esponente che riflette lo sforzo richiesto che aumenta con l aumentare con la dimensione del progetto (1,1< B < 1,24 ); - M, moltiplicatore che si basa su un insieme semplificato di caratteristiche di progetto e processo che influenzano la stima.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Questo porta a un calcolo dello sforzo come segue: Dove: Effort= 2,94 x Size B x M M= PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED Tale metodologia prevede al primo passo il calcolo di un valore detto UFP che rappresenta il numero di punti funzione del sistema senza alcun raffinamento basato sui valori di aggiustamento.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Il risultato di questa prima valutazione è influenzato da 5 entità funzionali, meglio dette User Function Types (categorie di funzioni utente) così definite: 1- Input utente: processano dati e/o informazioni di controllo facenti parte dell'applicazione, con la possibilità di causare modifiche ai files logici. 2- Output utente: processano dati e/o informazioni di controllo in uscita dall'applicazione; 3- Interrogazioni utente: combinazioni di I/O che generano output immediati, senza modificare i files logici; 4- Archivi: sono moduli di dati mantenuti e utilizzati all'interno dell'applicazione; 5- Files di interfaccia: altri moduli costruiti in modo da gestire l'interazione tra utente e software.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» I pesi che sono stati assegnati in base alla complessità ad ogni singolo requisito e ad ogni singolo elemento sono riportati nelle tabelle sotto riportate. Input Utente Requisiti Complessità Peso R2 Alta 6 R6 Media 4 R7 Bassa 3 R9 Bassa 3 R10 Bassa 3 R11 Media 4 R12 Alta 6 R13 Media 4 R15 Bassa 3 R16 Bassa 3 R17 Bassa 3 R18 Media 4 R21 Media 4 Quindi il numero di Input Utente influisce nel valore UFP con la seguente quantità: 50.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Output Utente Requisiti Complessità Peso R14 Media 5 R15 Bassa 3 R19 Media 5 Quindi il numero di Output Utente influisce nel valore UFP con la seguente quantità: 13. Interrogazioni Utente Requisiti Complessità Peso R2 Alta 6 R7 Bassa 3 R10 Media 4 R12 Media 4 R15 Bassa 3 R16 Bassa 3 Quindi il numero di Interrogazioni Utente influisce nel valore UFP con la seguente quantità: 23.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Archivi Tipo di Complessità Peso documento Base di dati Media 10 Quindi il numero di Archivi influisce sul valore UFP con la seguente quantità: 10. Interfacce Tipo di interfaccia Complessità Peso Interfaccia Media 7 cameriere/amministra tore Interfaccia responsabile di cassa Media 7 Quindi il numero di Interfacce influisce nel valore UFP con la seguente quantità: 14. Sommando le quantità così ottenute otteniamo il valore: UFP = 50 + 13 + 23 + 10 + 14 = 110
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» A questo punto è possibile calcolare un valore che serve a rifinire la stima effettuata fino ad ora, il Valore del Fattore di Aggiustamento (VAF). Il VAF viene calcolato basandosi sulla valutazione di quattordici parametri che dipendono dalle Caratteristiche Generali del Sistema. Ciascuna di queste caratteristiche viene valutata esplicitando il grado di influenza, sulla complessità del sistema. Il grado di influenza può variare da 0 a 5, secondo le seguenti corrispondenze: 0 Non influente 3 Influenza media 1 Influenza incidentale 4 Influenza significativa 2 Influenza moderata 5 Influenza molto forte.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Caratteristiche generali del sistema Risposta Comunicazione dei dati 5 Processi con dati distribuiti 1 Performance Pesantezza della configurazione utilizzata Grado di transazione 1 1 3 Input interattivo 4 Efficienza lato utente 5 Aggiornamento interattivo Complessità dei processi Ricusabilità Facilità di installazione Facilità di operazione Siti multipli Complessità delle interrogazioni 1 4 0 2 4 0 5 TOTALE 36
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Il calcolo ha, dunque, portato al seguente risultato: VAF = 36 Finalmente è possibile calcolare il numero di punti funzione del nostro sistema usando l espressione: FP= UFP * [0,65 +( 0,01 * VAF)] = 110 * [0,65 + (0,01 * 36)] = 111,10» 111 Determinati i punti funzione, per poter determinare il coefficiente Size occorre infine valutare la dipendenza dei linguaggi di programmazione che si intende usare e associare i corrispettivi pesi. Nel caso in studio si stima di adoperare Java/Android all 80 %, SQLite al 5 % ed infine XML, da non considerare essendo un linguaggio di markup. Allora: size = 111 * [(27 * 0,80) + (13 * 0,05)] / 1000 = 111 * 22,25 / 1000 = 2,47. Coefficienti di backfiring
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Tabella dei coefficienti di backfiring:
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Per determinare invece, il coefficiente B: B=0,91 + 0,01 Wi dove i Wi sono dati da 5 fattori: 1. Lavori precedenti 2. Flessibilità di sviluppo 3. Risoluzioni di Architettura/rischi 4. Coesione del Team 5. Maturità del Processo Assegnando i relativi valori nominali ai 5 fattori, otteniamo B= 1,0997.
Analisi dei requisiti: Elaborato «Stima dei costi e della tempistica: COCOMO II» Infine M è così determinato, stimando i cosiddetti costi driver, come riportato in tabella. Codice Descrizione Valore assegnato RCPX Affidabilità e complessità del prodotto 0,70 RUSE Ricusabilità richiesta n/a PDIF Difficoltà della piattaforma 0,90 PERS Capacità del personale 1,00 PREX Esperienza del personale 0,90 FCIL Destrezza 1,00 SCED Tempi di scadenza del progetto 1,00 Infine: M= PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED = 0,57 Effort= 2,94 x Size B x M = ( 2,94 x 2,47 1,0997 x 0,57 )= 4,53. Le stime effettuate hanno portato alla conclusione che per realizzare il prodotto finale occorrono circa 4 mesi e mezzo di tempo.
Analisi dei requisiti: Elaborato «Piano delle fasi: Diagramma di Gantt» Occorre valutare per ogni flusso di lavoro di ogni fase i giorni uomo necessari in base alle stime effettuate. La tempistica per un gestore di progetto è uno dei compiti più difficili. Vista la natura accademica del progetto, la regola pratica generalmente adottata nello stilare queste stime è quella di valutare come se tutto andasse a buon fine Individuati i giorni uomo necessari, passo successivo è quello di rappresentare le informazioni sulla tempistica del progetto attraverso un grafico a barre denominato Diagramma Di Gantt, che mostra il calendario del progetto, le date di partenza e di fine delle attività: leggendolo da sinistra verso destra mostra chiaramente quando iniziano e quando finiscono.
Analisi dei requisiti: Elaborato «Lista dei Rischi & Piano di gestione dei Rischi» Compito importante di un responsabile software è la gestione del rischio. Prima ancora è necessario prevedere tutti quei rischi che possono influenzare la tempistica del progetto o la qualità del software sviluppato, e prendere quindi provvedimenti per evitarli. Esistono tre categorie di rischio, tra loro collegate: 1- rischi per il progetto: che influenzano la tempistica o le risorse del progetto; 2- rischi per il prodotto: che influenzano la qualità o le prestazioni del software che si sta sviluppando; 3- rischi economici: che influenzano l organizzazione che sta sviluppando o acquistando il software. Prima fase da attuare è quella di identificare i possibili rischi del progetto che possono sorgere, che possono essere classificabili in: rischi tecnologici, riguardanti il personale, organizzativi, strumentali, dei requisiti e di stima Una volta identificati, compito importante è quello di individuare alcune strategie per gestirli
Analisi dei requisiti: Elaborato «Lista dei Rischi»
Analisi dei requisiti: Elaborato «Piano di gestione dei Rischi»
Analisi dei requisiti: Elaborato «Modello dei casi d uso» In UP e in molti metodi moderni, i casi d uso sono il meccanismo centrale per la scoperta e la definizione dei requisiti, soprattutto funzionali o comportamentali, che indicano che cosa farà il sistema. Passo primo, è quello di individuare gli attori. Un attore è qualcosa o qualcuno dotato di comportamento. Gli attori individuati sono: 1- l Amministratore di Sistema; 2- il Cameriere; 3- il Responsabile di cassa. Come previsto da UP occorre individuare per ogni attore i casi d uso. Devono essere prima analizzati e descritti usando il formato breve, successivamente devono essere scritti in formato dettagliato i casi d uso che hanno maggior valore e che sono più rilevanti per l architettura.
Analisi dei requisiti: Elaborato «Modello dei casi d uso» I casi d uso individuati per attore sono: Attore: Amministratore di sistema UC1) Configura sistema UC2) Test connettività UC3) Esegue Disaster Recovery UC4) Avvia Sistema Attore: Cameriere UC5) Crea ordinazione Attore: Responsabile cassa UC6) Calcola conto & Rilascia tavolo UC7) Gestisce Lista di attesa
Analisi dei requisiti: Elaborato «Modello dei casi d uso» DESCRIZIONE DEI CASI D USO UC1) Configura Sistema L Amministratore di sistema configura il Sistema instaurando la comunicazione tra i vari Client ( palmari) e il Server. Il server crea un socket, si mette in ascolto con un indirizzo IP e numero di porta. UC2) Test connettività L amministratore effettua un test di connettività su tutti i Client. Il test consiste nel controllare la configurazione IP del client, indirizzo IP e numero di porta del server, eventuali altri errori dello stack TCP/IP. UC3) Esegue Disaster Recovery L amministratore può sostituire un qualsiasi client a run-time in caso di malfunzionamento. È necessario installare la versione client su un altro palmare e configurarlo. Per garantire anche lato server questa intolleranza ai guasti è necessario prevedere dei backup del database.
Analisi dei requisiti: Elaborato «Modello dei casi d uso» UC4) Avvia Sistema Il Cameriere avvia sul palmare l applicazione, viene eseguito un check dei parametri di connessione ( Indirizzo IP e numero di Porta). Eseguito il controllo viene caricato in memoria il menù, interrogando il Database, se non era già stato caricato in precedenza. Sono possibili ora due alternative: 1- Attraverso una pressione prolungata sul display viene attivato il gestore dell evento e verrà visualizzato lo stato dei tavoli; 2- Attraverso una pressione sul tasto Opzioni sarà possibile inserire indirizzo IP e numero di Porta. Eseguire successivo Test di connettività. UC5) Crea ordinazione Il cameriere crea una ordinazione scorrendo il menù, selezionando le varie pietanze e aggiungendole all ordinazione. Il cameriere ha la possibilità di personalizzare le pietanze, aggiungendo o sottraendo alcuni ingredienti. Il cameriere invia l ordinazione che si scomporrà nei rispettivi reparti. UC6) Calcola conto & Rilascia tavolo Il responsabile di cassa, premendo su un qualsiasi tavolo con Stato in occupato ha la possibilità di calcolare il conto totale e di rilasciare il tavolo, modificando lo stato in libero. UC7) Gestisce Lista di attesa Il responsabile di cassa può all occorrenza inserire o cancellare dalla Lista di attesa le prenotazioni delle persone in attesa di sedersi ad un tavolo.
DIAGRAMMA UML DEI CASI D USO Configura Sistema Avvia Sistema Amministratore di Sistema Test Connettività Esegue Disaster Recovery <<include>> Calcola conto & Rilascia tavolo <<include>> Responsabile di cassa Gestisce Lista di attesa <<include>> Crea ordinazione Cameriere
II FASE U.P.: ELABORAZIONE L elaborazione è la serie iniziale di iterazioni durante le quali in un progetto: Viene preparata e verificata l architettura software principale e rischiosa Viene stabilizzata la maggior parte dei requisiti I rischi maggiori sono attenuati o rientrano Questa fase è spesso costituita da due o più iterazioni. In tabella sono elencati alcuni elaborati che possono essere iniziati durante l elaborazione, sono esclusi gli elaborati per i quali, nella fase di ideazione, è stata già elaborata una prima bozza, quali: Visione, specifiche supplementari e modello dei casi d uso. Disciplina Elaborato Ideazione Elaborazione Costruzione Transizione Modellazione Modello di dominio I del business Progettazione Modello I R di progetto Progettazione Documento I dell architettura software Progettazione Modello dei dati I R Tabella - Esempio di tempificazione degli elaborati principali di UP ( I= inizio; R= raffinamento)
Raffinamento elaborato «SPECIFICHE SUPPLEMENTARI» Inserimento dei vincoli di implementazione...
Elaborato ELABORAZIONE: «Modello di dominio» Il termine Modello di Dominio indica una rappresentazione delle classi concettuali del mondo reale, non di oggetti software. Applicando la notazione UML, un modello di Dominio è illustrato con un insieme di diagrammi delle classi in cui non sono definite operazioni ma fornisce un punto di vista concettuale e può mostrare: Oggetti di dominio o classi concettuali Associazioni tra classi concettuali Attributi di classi concettuali I passi da seguire, nell elaborazione del Modello, essendo vincolati ai requisiti scelti per la progettazione, sono: Individuazione delle classi concettuali Disegnarle come classi in un diagramma delle classi UML Aggiunta di associazioni e attributi.
Figura - Diagramma UML delle classi concettuali
Elaborato ELABORAZIONE: «Modello di progetto» Risultato della progettazione logica è il Modello di Progetto, elaborato che descrive attraverso i diagrammi UML la progettazione logica al fine di rendere più semplice la fase implementativa Il modello di Progetto viene elaborato in fase di Elaborazione e raffinato in fase di COSTRUZIONE L elaborato realizzato in questa prima versione comprende: diagrammi UML dei package diagrammi UML di sequenza
Elaborato ELABORAZIONE: «Modello di progetto»
Elaborato ELABORAZIONE: «Modello di progetto» Figura - Diagramma UML dei package
Elaborato ELABORAZIONE: «Documento dell Architettura Software» Questo elaborato previsto da UP, seppur opzionale come gli altri elaborati, è molto importante in quanto costituisce un aiuto per l apprendimento del sistema che si sta realizzando; riassume gli aspetti principali dell architettura e la loro risoluzione nel progetto. Rappresenta una sorta di riepilogo delle idee di progettazione più significative all interno del Sistema e delle loro motivazioni.
Elaborato ELABORAZIONE: «Documento dell Architettura Software»
Elaborato ELABORAZIONE: «Documento dell Architettura Software» Database SQLite Client << driver jdbc>> Server Responsabile di cassa Server Camerieri Stampante Bar Stampante Cucina Stampanti wireless reparti Figura - Schema dei componenti del Sistema
Elaborato ELABORAZIONE: «Modello dei Dati: Schema E-R della base di dati» Il modello dei dati è l elaborato prodotto in fase di progettazione concettuale e logica della base di dati. Nella prima fase viene studiato l insieme dei dati del sistema informativo; per formalizzare tale insieme vengono identificate e definite le entità e le relazioni coinvolte. Per scegliere i dati da rappresentare si adotta il seguente metodo: - si prendono in considerazione solo i dati realmente necessari alla sperimentazione, escludendo alcuni dati specifici, che comunque potrebbero essere aggiunti facilmente in future espansioni del sistema.
Elaborato ELABORAZIONE: «Modello dei Dati: Schema E-R della base di dati»
III FASE U.P.: COSTRUZIONE In questa terza fase gli elaborati creati durante il lavoro di progettazione, sono utilizzati come input per il processo di generazione del codice. In termini di UP, esiste un MODELLO DI IMPLEMENTAZIONE, modello che è costituito da tutti gli elaborati dell implementazione, come il codice sorgente, la definizione delle basi di dati, le pagine JSP/XML/HTML e così via. Prima di realizzare il Modello di Implementazione risultante, introdurre l ambiente di sviluppo adoperato e raffinare i seguenti elaborati della Fase di Elaborazione: Modello dei Dati Realizzare lo schema logico ottenuto mediante una traduzione verso il modello relazionale Modello di progetto - Realizzare in aggiunta all elaborato pre-esistente i seguenti diagrammi: o diagrammi UML con annidamento dei package o diagrammi UML delle classi software per ogni package o diagramma UML di stato
Raffinamento elaborato «MODELLO DEI DATI» Inserimento del Modello relazionale...
Raffinamento elaborato «MODELLO DI PROGETTO» Inserimento dei diagrammi UML con annidamento dei package, delle classi software per ogni package e diagramma UML di stato del tavolo...
Diagrammi UML con annidamento dei package (Componente Cameriere)
Diagrammi UML con annidamento dei package (Componente Cassiere)
E cosi via anche per i package com.ui.cameriere e com.ui.cameriere
Diagramma UML di Stato Il diagramma UML di Stato riportato in figura mostra le azioni di transizione che determinano la modifica dello stato del Tavolo da Libero ad Occupato e viceversa. Si definisce stato la condizione di un oggetto in un certo intervallo di tempo, il tempo tra due eventi. All avvio del Sistema, lo Stato iniziale del Tavolo è posto a Libero e ne determina il passaggio in Occupato solo l avvio dell azione OccupaTavolo da parte del Cameriere. Il passaggio dello stato a Libero da Occupato è vincolato dall azione di transizione RilasciaTavolo da parte del Cassiere. Si osserva come lo stato finale che precede la chiusura del Sistema sia solo lo stato Libero, in quanto non avrebbe senso chiudere il Sistema avendo ancora tavoli occupati, per i quali non è stato ancora emesso lo scontrino o fattura con successivo rilascio del Tavolo.
Elaborato COSTRUZIONE: «Modello di Implementazione» A differenza degli altri modelli UP realizzati durante il processo di sviluppo del software, costituiti da testo e diagrammi, il modello di implementazione è l effettivo codice sorgente, che comprende gli script SQL per la creazione del database, la definizione delle classi di tutti i package ed infine i file XML che definiscono le interfacce utenti.
Stralcio del «Modello di Implementazione»...
Beta test Rilascio agli utenti IV FASE U.P.: TRANSIZIONE
Testi di riferimento [1] Craig Larman, Applicare UML e i pattern - PEARSON (2005) [2] Gamma, Helm, Johnson,Vlissides, Design pattern - PEARSON (2002) [3] Damiani, Madravio, Bohm, UML pratico - PEARSON (2007)