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 aspetti diversi di un sistema con un approccio O-O Struttura statica Comportamento dinamico Interazioni fra i diversi componenti del sistema Ricopre l intero ciclo di vita dello sviluppo del software E uno standard aperto Standard OMG per la modellizzazione di sistemi Object-Oriented sin dal 1997 Unifica notazioni e metodologie preesistenti G. Booch J. Rumbaugh (OMT) I. Jacobson E supportato da più strumenti Molti partner industriali Digital, HP, IBM, Microsoft, Oracle, Rational 2 1
è un linguaggio di progettazione, non un linguaggio di programmazione (come Java, VisualBasic, C++, ) definisce una notazione standard fornadata su un metamodello serve a progettare un nuovo sistema, o a apportare modifiche alla progettazione di un sistema esistente, senza perdersi nei dettagli dei linguaggi di programmazione durante la fase progettuale è universale, nel senso che può rappresentare sistemi molto diversi senza differenze legate alla tecnologia: dai sistemi web a quelli più tradizionali, dalle vecchie applicazioni Cobol a quelle object oriented 3 UML è un linguaggio, non un metodo/processo UML non suggerisce, né tantomeno prescrive una sequenza di utilizzo dei diversi diagrammi, lascia anzi molte strade aperte, tra le quali i progettisti sono liberi di scegliere 4 2
UP Una metodologia per UML descrive cosa fare, come, quando e perché comprende un certo numero di attività da portare a termine in un certo ordine aiuta nella produzione di documentazione di progetto esauriente 5 RUP E la versione commerciale, prodotta da Rational Software, di Unified Process, il processo definito da Booch, Rumbaugh, Jacobson (gli autori di UML) E un framework di processo, da adattare alle diverse tipologie di progetto E utilizzato in contesti di business estremamente competitivi, e in ambiti applicativi eterogenei Risponde agli obiettivi primari di time to market, controllo del rischio e visibilità degli stati di avanzamento 6 3
Caratteristiche primarie Guidato dai casi d uso. Essi costituiscono la base per: la definizione e negoziazione dei requisiti, e la loro validazione da parte del committente la progettazione dell architettura e dei componenti la definizione dei test di accettazione la pianificazione dei rilasci (in un ottica incrementale) e quindi del progetto Centrato sull architettura La definizione dell architettura applicativa e tecnologica costituisce il fondamento tecnico dell applicazione e del progetto Il consolidamento dell architettura avviene solo quando si è certi (se necessario, tramite sperimentazioni) della sua fattibilità tecnica. Fino a quando l architettura non è consolidata, non esistono elementi sufficienti per determinare (con precisione sufficiente alla definizione di un contratto) tempi, costi e rischi dell intervento progettuale 7 Caratteristiche primarie Iterativo il progetto si articola in una serie di iterazioni (sequenze di attività), che hanno lo scopo di ridurre progressivamente i rischi di fallimento, a partire da quelli principali (es. incomprensioni sui requisiti, incertezze sull architettura) in ogni iterazione si ripetono, in misura e percentuali diverse, le medesime tipologie di attività (es. analisi dei requisiti, design, implementazione, test) Incrementale la realizzazione (ed eventualmente il rilascio) dell applicazione avviene in modo progressivo la pianificazione è guidata dai casi d uso e dalle priorità architetturali (es. precedenza ai componenti infrastrutturali) 8 4
Caratteristiche primarie Basato sui modelli RUP enfatizza lo sviluppo e il mantenimento di modelli piuttosto che la produzione di montagne di documentazione cartacea Orientato agli oggetti I modelli utilizzato sono UML Basato sui componenti I componenti sono moduli non banali, sottosistemi che realizzano una funzione e possono essere assemblati in una architettura ben definita Orientato al controllo qualità e alla gestione dei rischi Sono parte inscindibile di ciascuna fase Configurabile Nessun processo è adatto per tutte le situazioni; la configurabilità si raggiunge attraverso la selezione delle viste e dei diagrammi utili e attraverso la gestione delle iterazioni 9 Gli ingredienti di RUP Un ruolo definisce il comportamento e le responsabilità di un individuo o un gruppo Il comportamento è espresso in termini di attività Le responsabilità sono espresso in termini di elaborati da produrre e gestire Ruolo Attività Deliverable 10 5
Tipi di deliverable Set di gestione elaborati di pianificazione (software development plan, studio economico, ) elaborati operazionali (stato di avanzamento, descrizione versione, ) Set dei requisiti documento di visione modello dei casi d uso modello di business Set di progettazione modello di design modello architetturale modello di test Set di implementazione codice sorgente ed eseguibili file di dati Set di rilascio agli utenti script di installazione documentazione utente materiale formativo 11 Le due dimensioni di RUP Lungo il tempo si sviluppano gli aspetti del ciclo di vita. Vengono rapresentati gli aspetti dinamici del processo: come comincia e come si suddivide in cicli, fasi, iterazioni e milestone Lungo i componenti di processo, le attività sono raggruppate logicamente. Si rappresentano gli aspetti statici del processo: come è descritto in termini di componenti, attività, workflow, elaborati, ruoli 12 6
Il modello 13 Le fasi Inception: definisce gli obiettivi del progetto, ne investiga la fattibilità, ne stima i costi, il potenziale di mercato e i rischi, analizza i prodotti concorrenti Elaboration: pianifica il progetto e ne definisce le caratteristiche funzionali, strutturali e architetturali Construction: sviluppa il prodotto attraverso una serie di iterazioni, effettua il testing, prepara la documentazione Transition: consegna il sistema agli utenti finali (include marketing, installazione, configurazione, formazione, supporto, mantenimento) 14 7
Output primari delle fasi Inception Documenti fattibilità Elaboration SRS (Specifica dei Requisiti Software) Architettura consolidata e verificata Construction Versione sistema in pre-produzione (Beta) Transition Versione sistema in produzione 15 Tipologie di attività (workflow) Business modeling: descrive la struttura e la dinamica dell organizzazione Requisiti: descrive i requisiti e il loro cambiamento Analisi e progetto: descrive le viste architetturali Implementazione: considera lo sviluppo del sw e l integrazione Test: descrive i casi prova e le metriche Deployment: descrive la configurazione del sistema Gestione configurazione: mantiene le versioni del sistema Gestione progetto: descrive le strategie per gestire un processo iterativo Ambiente: descrive le infrastrutture di sviluppo 16 8
Fasi e workflow 17 Interazioni e workflow 18 9
Fasi, iterazioni e workflow Le fasi sono sequenziali, e corrispondono a milestone significativi per Committenti, Utenti, Management Le tipologie di attività non sono rigidamente sequenziali, e vengono svolte dal progetto in ogni iterazione Il numero delle iterazioni dipende dalle scelte del Project Manager e dai rischi del progetto 19 Rischi Rischi legati ai requisiti: il sistema può non implementare le funzionalità richieste Creare al più presto una documentazione scheletro che modelli i requisiti principali con diagrammi dei casi d uso, delle classi, delle attività Rischi legati alle tecnologie: le metodologie e gli strumenti da usare possono non essere sufficienti a produrre le funzionalità richieste Prototipare, sperimentando diversi strumenti Rischi legati alle capacità: può essere difficile formare il team di progetto con le conoscenze necessarie Pianificare un addestramento accurato Rischi politici: le forze politiche e organizzative in gioco nell azienda committente possono ostacolare il progetto?????? 20 10
Personalizzazioni RUP deve essere adattato, senza stravolgimenti, alle esigenze e alle caratteristiche dell organizzazione L adattamento deve tenere conto di vari fattori: Tipologia di sistemi da realizzare (automazione, gestionale, B2C) Cultura dell organizzazione in cui viene calato Struttura organizzativa, ruoli, responsabilità Modalità di rapporto con i committenti Differenze tra progetti di nuovo sviluppo ed evoluzioni L adattamento deve avvenire in modo progressivo, e costituisce a sua volta un progetto, iterativo e incrementale 21 11