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

Transcript

1 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 Unified Process (UP) è il processo di ingegneria del software diventato standard industriale Definisce il chi, il cosa, il quando e il come dello sviluppo del software UP definisce un modello generale di processo da cui si sono sviluppate diverse varianti Rational Unified Process (RUP) è sicuramente la variante più conosciuta 2 Page 1

2 Nascita di UP 1967 Presso Ericsson si pongono le basi del Component-Based Development Un sistema complesso è visto come un insieme di blocchi interconnessi 1976 CCITT rilascia il Specification and Description Language Linguaggio per sistemi di telecomunicazione dove i sistemi sono modellati come un insieme di componenti che si scambiano segnali 1987 Jacobson fonda Objectory AB che mette sul mercato un processo di ingegneria del software: Objectory (Object Factory) Il processo è basato su un set di documentazione standard e uno strumento CASE 1995 Rational Rose acquisisce Objectory AB 1997 UML diventa standard OMG 1999 nasce UP 3 UP e UML UML inizialmente doveva fornire sia un linguaggio visuale che il processo di ingegneria del software Ad oggi UML fornisce solo il linguaggio visuale UP fornisce il processo di ingegneria del software che utilizza come linguaggio visuale UML 4 Page 2

3 UP come Processo Generico UP è un processo di sviluppo del software generico e deve essere istanziato per ogni organizzazione e progetto Il processo di istanziazione deve definire e integrare: Gruppo di lavoro Modelli di documento Strumenti: compilatori, gestione delle configurazioni, Archiviazione: gestione bug, gestione del progetto Ciclo di vita 5 Assiomi di UP UP è basato su tre assiomi fondamentali: È pilotato dai casi di uso e dai fattori di rischio È importante individuare il prima possibile gli eventuali rischi che si possono dover affrontare nel processo di sviluppo e predisporre le modalità con cui possano essere superati È incentrato sull architettura L architettura di un sistema descrive gli aspetti strategici di un sistema (come è scomposto in componenti, come questi componenti interagiscono, etc.) Quindi una buona architettura è la base di un buon sistema È iterativo e incrementale Il progetto viene scomposto in sottoprogetti (iterazioni) ognuno dei quali porterà al rilascio di alcune nuove funzionalità 6 Page 3

4 Iterazioni Ogni iterazione contiene tutte le attività tipiche di un processo di sviluppo di ingegneria del software: Pianificazione Analisi e progettazione Costruzione Integrazione e test Rilascio Ogni iterazione porta al raggiungimento di una baseline corrispondente a una versione parzialmente completa del sistema finale e la relativa documentazione La differenza tra due baseline consecutive viene detta incremento 7 Iterazioni Ogni iterazione si basa principalmente su cinque flussi di lavoro che devono essere eseguiti in cascata: Raccolta dei requisiti (Requirements) Elenca le funzionalità che il sistema dovrebbe avere Analisi (Analysis) Completa e raffina le funzionalità elencate nella fase di raccolta dei requisiti e definisce un modello del sistema (modello di analisi) concentrato sulle funzionalità Progettazione (Design) Progetta un architettura e le differenti componenti che realizzano le funzionalità definite nella fase di analisi Implementazione (Implementation) Realizza il sistema definito dalla fase di progettazione Test (Test) Verifica il corretto funzionamento e il soddisfacimento dei requisiti 8 Page 4

5 Modelli UML e Flussi di Lavoro Ogni tipo di flusso di lavoro si basa su alcune classi di modelli (diagrammi) UML: Raccolta dei requisiti (Requirements) Use Case Model (Use Case, Sequence, Statechart, Activity) Analisi (Analysis) Analysis Model (Class, Sequence, Collaboration, Statechart, Activity) Progettazione (Design) Design Model (Class, Sequence, Collaboration, Statechart, Activity) Deployment Model (Deployment, Sequence, Collaboration) Implementazione (Implementation) Implementation Model (Component, Sequence, Collaboration) Test (Test) Test Model 9 Fasi di UP Inception Elaboration Construction Transition Il ciclo di vita di un progetto è diviso in quattro fasi in cascata Ogni fase si conclude con un importante milestone: Obiettivi (Vision) Architettura (Baseline architecture) Capacità operativa iniziale (Initial capability) Rilascio del prodotto (Product release) 10 Page 5

6 Fasi e Flussi di Lavoro La quantità di lavoro richiesto per ciascuno dei cinque flussi di lavoro fondamentali varia nelle diverse fasi del progetto 11 Fasi e Iterazioni Una fase può comprendere più iterazioni; in particolare, per le fasi di Elaborazione e Costruzione 12 Page 6

7 Avvio Questa fase ha l obiettivo di far decollare il progetto attraverso: Studio di fattibilità Generazione di un caso di business (business case) Definizione dei requisiti essenziali Identificazione dei rischi più critici Questa fase si basa quasi completamente sulle attività relative alla raccolta dei requisiti e all analisi Attività di progettazione e di implementazione potrebbero essere richieste se si rendesse necessaria la realizzazione di un prototipo o di alcune prove di fattibilità 13 Avvio Milestone di questa fase è la definizione degli obiettivi del progetto A questa milestone corrisponderà il rilascio di alcuni artefatti: Documento di alto livello con i principali requisiti, caratteristiche e vincoli del progetto Modello dei casi di uso iniziale (completo al 10-20%) Glossario del progetto (elenco dei principali requisiti) Caso di business Prima pianificazione del progetto (costi e tempi) Documento di valutazione dei rischi Uno o più prototipi Documento iniziale sull architettura del sistema 14 Page 7

8 Ingegneria dei Requisiti L ingegneria dei requisiti è la disciplina che si occupa di: Raccogliere e tenere aggiornato l insieme dei requisiti Assegnare le priorità ai diversi requisiti Documentare i diversi requisiti È un processo di negoziazione che cerca di raggiungere un buon compromesso per tenere conto delle diverse esigenze del sistema L ingegneria dei requisiti ha una grande importanza nel processo di sviluppo del software La prima causa di fallimento dei progetti software è il mancato successo delle attività di ingegneria dei requisiti La seconda causa di fallimento dei progetti software è la mancanza di coinvolgimento dei futuri utenti 15 Requisiti Funzionali e Non Funzionali L ingegneria dei requisiti dovrebbe trattare due tipi diversi di requisiti: Requisiti funzionali, cioè cosa deve fare il sistema Requisiti non funzionali, cioè i vincoli che il sistema deve rispettare (prestazioni, affidabilità, etc.) In teoria, i requisiti dovrebbero indicare esclusivamente cosa un sistema deve fare e non il come lo deve fare Tuttavia, possono esistere dei vincoli sul comportamento del sistema che, almeno in parte, predeterminano, il come 16 Page 8

9 Attività dell Ingegneria dei Requisiti Le attività coinvolte nella raccolta dei requisiti sono le seguenti: Individuare i requisiti funzionali Individuare i requisiti non funzionali Assegnare le priorità ai requisiti Estrarre i casi d uso dai requisiti Descrivere i casi d uso Strutturare il modello dei casi d uso 17 Formulazione dei Requisiti I requisiti possono essere specificati in differenti modi: Frasi in linguaggio naturale Strumenti di ingegneria dei requisiti L insieme di specifiche generato viene comunemente indicato con il nome di Specifiche dei Requisiti di Sistema (SRS) UML non fornisce alcuna indicazione su come scrivere una SRS Un formato molto semplice, ma efficace è identificare ogni requisito nel seguente formato: <id> <sistema> dovrà <funzione> dove: <id> è un identificatore univoco <sistema> identifica il sistema <funzione> identifica la funzione richiesta al sistema 18 Page 9

10 Esempio di Formulazione dei Requisiti SRS per uno sportello automatico tipo bancomat Requisiti funzionali RF1: il sistema dovrà controllare la validità della tessera inserita RF2: il sistema dovrà controllare la validità del PIN digitato dal cliente RF3: il sistema dovrà erogare non più di 500 per carta nell arco di 24 ore RF4: il sistema dovrà erogare non meno di 10 per operazione RF5: il sistema dovrà essere sempre attivo Requisiti non funzionali RNF1: il sistema dovrà comunicare con la banca tramite un codice cifrato a 256 bit RNF2: il sistema dovrà controllare la validità della tessera inserita entro 3 secondi RNF3: il sistema dovrà controllare la validità del PIN digitato dal cliente entro 3 secondi 19 Filtro dei Requisiti Se i requisiti di un SRS sono formulati in linguaggio naturale, allora possono essere raffinati attraverso una tecnica propria dell analisi del linguaggio naturale: La grammatica delle trasformazioni I requisiti possono essere raffinati attraverso tre filtri: Rimozione RF4: il sistema dovrà essere sempre attivo Distorsione RF3: il sistema dovrà erogare non più di 500 per carta nell arco di 24 ore RF3: il sistema dovrà erogare non più di un certo valore per carta nell arco di 24 ore in base al tipo di carta Generalizzazione RF4: il sistema dovrà erogare non meno di 10 per operazione RF4: il sistema dovrà erogare non meno di un certo valore per operazione 20 Page 10

11 Mappatura dei Requisiti L operazione di mappatura dei requisiti permette di individuare i requisiti che non sono coperti da nessun caso di uso Questa operazione mette in relazione i requisiti funzionali contenuti nel SRS e i casi di uso Questa operazione ha lo scopo di individuare: La presenza di requisiti non coperti da casi di uso La mancanza di requisiti RF1 RF2 RF3 RF4 UC1 X UC2 X UC3 X X UC4 X UC5 RF5 RF6 X 21 Glossario del Progetto Il glossario del progetto è il dizionario che: Contiene i principali termini del dominio e la loro definizione Risolve i casi di sinonimia e omonimia: Ad ogni termini viene associata una lista di sinonimi Viene scelto un unico significato per il termini e se possibile vengono introdotti altri termini per gestire gli altri significati UML non fornisce alcun standard per questo glossario Un formato molto semplice, ma efficace è quello di un dizionario: Elenco di vocaboli ordinati alfabeticamente Ad ogni vocabolo è associata una definizione e una lista di sinonimi È molto importante che gli stessi vocaboli e definizioni vengano usati in tutti i documenti del processo di ingegneria del software 22 Page 11

12 Elaborazione Questa fase ha i seguenti obiettivi: Creare una baseline eseguibile Perfezionare la valutazione dei rischi Definire gli attributi di qualità (velocità di individuazione dei difetti, densità massima di difetti accettabili, etc.) Fissare i casi d uso relativi ad almeno l 80% dei requisiti funzionali del sistema da realizzare Creare un piano dettagliato della fase di costruzione Formulare una valutazione iniziale delle risorse, tempo, strumenti, persone e costi richiesti nella realizzazione del sistema La baseline eseguibile non sarà un prototipo, ma piuttosto una prima approssimazione del sistema obiettivo del progetto su cui si appoggeranno le baseline realizzate dalle fasi successive 23 Elaborazione Questa fase si basa su tutti i cinque flussi di lavoro fondamentali e ognuno di essi ha degli obiettivi ben definiti Raccolta dei requisiti Fissare la maggioranza dei requisiti Raffinare l ambito del sistema Analisi Definire ciò che deve essere costruito Progettazione Definire un architettura stabile Implementazione Costruire una baseline eseguibile Test Testare la baseline Le attività relative alla raccolta, analisi e progettazione hanno il maggior peso, tuttavia, verso la fine della fase di Elaborazione, l implementazione inizia ad assumere un peso maggioritario 24 Page 12

13 Elaborazione Milestone di questa fase è la definizione dell architettura del sistema A questa milestone corrisponderà il rilascio di alcuni artefatti: Baseline eseguibile Modello dei casi di uso UML, Modello statico e dinamico UML Documentazione descrittiva del sistema Pianificazione del progetto aggiornata (opzionale) Caso di business aggiornato (opzionale) Documento di valutazione dei rischi aggiornato (opzionale) Accordo firmato 25 Flusso di Lavoro dell Analisi Il flusso di lavoro di analisi ha l obiettivo di produrre un modello di analisi Si concentra su che cosa il sistema deve fare Il dettaglio del come farlo è compito del flusso di lavoro di progettazione Il modello di analisi è basato su una collezione di diagrammi e di elementi di modellazione, in particolare, su due artefatti: Classi di analisi: modellano i concetti chiave del dominio del problema Casi di uso: mostrano come le istanze delle classi di analisi possono interagire per realizzare il comportamento del sistema 26 Page 13

14 Modello di Analisi Il modello di analisi si dovrebbe basare esclusivamente su quelle classi che fanno parte del vocabolario del dominio del problema (il Glossario) Bisogna evitare di introdurre delle classi di progettazione (classi per l accesso alla rete o a database, a meno che ) L obiettivo è fornire una rappresentazione semplice e concisa della struttura e del comportamento del sistema Tutte le decisioni implementative devono essere lasciate ai flussi di lavoro della progettazione e implementazione 27 Modello di Analisi Si possono indicare alcune regole pratiche ed efficaci per la modellazione dell analisi: Esprimere il modello dell analisi nel linguaggio del problema (uso del Glossario) Creare modelli che raccontano una storia (uso dei casi di uso) Concentrare l attenzione sulle viste di insieme (disuso dei dettagli) Mantenere una netta distinzione tra il dominio del problema (requisiti del business) e il dominio delle soluzioni (dettagli di progettazione) Concentrare l attenzione sulle astrazioni del dominio applicativo (uso di classi corrispondenti a entità del business e disuso di classi corrispondenti a soluzioni implementative) Limitare le interdipendenze tra le classi di analisi (uso appropriato delle relazioni di ereditarietà, molteplicità e navigabilità) Fornire modelli utili a tutte le parti (committenti, progettisti e sviluppatori) Mantenere semplice il modello (uso di ereditarietà e polimorfismo) 28 Page 14

15 Individuazione delle Classi di Analisi Non esiste un algoritmo che permette di individuare le classi di analisi, se esistesse, questo algoritmo sarebbe un metodo infallibile per progettare il software Tuttavia esistono delle tecniche che sono state provate e sperimentate per trovare delle buone soluzioni Queste tecniche si basano sull analisi del testo e sulle interviste agli utenti e agli esperti del dominio Due tecniche molto utilizzate sono: L analisi nome/verbo L analisi classe, responsabilità e collaboratori (CRC) Spesso più di una tecnica viene utilizzata e le classi vengono individuate dal confronto dei risultati delle varie tecniche di analisi 29 Analisi Nome/Verbo L analisi nome/verbo è un modo molto semplice per estrarre le classi dai documenti forniti dal flusso di lavoro di raccolta dei requisiti: I nomi e le frasi nominali rappresentano le classi e gli attributi I verbi e le frasi verbali le responsabilità e le operazioni delle classi I problemi più ricorrenti sono: Trattare i casi di sinonimia e omonimia Individuare le classi nascoste cioè le classi implicite del dominio del problema che possono anche non essere mai menzionate esplicitamente Ad esempio, in un sistema di prenotazione di una compagnia di viaggi si potrebbe parlare di prenotazione, richiesta, ma tralasciare il termine ordine 30 Page 15

16 Analisi Nome/Verbo I passi dell analisi nome/verbo sono i seguenti: Raccolta delle fonti di informazione SRS (se esiste) Casi di uso Glossario di progetto Altri documenti esistenti (architettura, visione aziendale, ) Estrazione degli elementi di analisi dei documenti I nomi I predicati nominali (ad esempio, numero del volo) I verbi I predicati verbali (ad esempio, verificare la carta di credito) Definizione delle classi di analisi Individuazione delle classi Assegnazione di attributi e responsabilità alle classi Individuazione di relazioni tra le classi 31 Analisi CRC L analisi classe, responsabilità e collaboratori (CRC) è un modo efficiente di coinvolgere gli utenti nella ricerca delle classi Questa tecnica si basa sull uso di comuni foglietti nota adesivi (in genere di colore giallo): I foglietti vengono suddivisi in tre aree per contenere Il nome della classe Le responsabilità I collaboratori I foglietti vengono appiccicati ad un muro o a una lavagna Se viene usata la lavagna, per evidenziare le relazioni possono venire tracciate delle linee tra le classi che collaborano 32 Page 16

17 Analisi CRC I passi dell analisi CRC sono raggruppati in due fasi: Brainstorming per raccogliere l informazione Spiegazione ai partecipanti che si tratta di un brainstorming Tutte le idee sono considerate buone e registrate La discussione e l analisi verrà effettuata successivamente Richiesta ai partecipanti di nomi di cose che agiscono nel dominio del problema Ogni cosa viene scritta su un foglietto diverso Ogni foglietto viene appiccicato ad una parete o a una lavagna Richiesta ai partecipanti di indicare le responsabilità che quelle cose potrebbero avere Individuazione assieme ai partecipanti delle classi che potrebbero lavorare insieme Analisi dell informazione Individuazione di classi e attributi 33 Costruzione Questa fase ha i seguenti obiettivi: Completare la raccolta dei requisiti, l analisi e la progettazione Far evolvere la baseline eseguibile realizzata nella fase di Elaborazione nella versione finale Vincolo molto importante in questa fase è il mantenimento dell integrità dell architettura del sistema 34 Page 17

18 Costruzione Questa fase si basa su tutti i cinque flussi di lavoro fondamentali e ognuno di essi ha un obiettivo ben definito Raccolta dei requisiti Completare la lista dei requisiti Analisi Completare il modello di analisi Progettazione Completare il modello di progettazione Implementazione Test Costruire la cosiddetta capacità operativa iniziale Testare la capacità operativa iniziale In questa fase le attività di implementazione sono le più importanti, ma anche il test ha una sua importanza: Ad ogni incremento bisogna eseguire gli unit test e i test di integrazione 35 Costruzione Milestone di questa fase è la realizzazione della cosiddetta capacità operativa iniziale cioè di un sistema software finito su cui gli utenti possano eseguire il beta test A questa milestone corrisponderà al rilascio di alcuni artefatti: Prodotto software Modelli UML Test suite Manuale utente Descrizione di rilascio Pianificazione del progetto (confronto tra costi reali e previsti) 36 Page 18

19 Flusso di Lavoro della Progettazione Il flusso di lavoro di progettazione ha l obiettivo di definire in modo completo come le funzionalità definite nella fase di analisi debbano essere implementate La progettazione comporta lo studio e l integrazione delle soluzioni tecniche (librerie software, meccanismi di persistenza, ), che appartengono al dominio delle soluzioni, per la messa a punto di un modello del sistema (modello di progettazione) che possa essere effettivamente implementato 37 Modello di Progettazione Il modello di progettazione si basa sul modello di analisi e può essere considerato una sua evoluzione o elaborazione Il modello di progettazione utilizza principalmente due termini: Sottosistema Interfaccia L attività di progettazione si concentra nell individuazione e modellazione delle interfacce principali 38 Page 19

20 Modello di Progettazione Il modello di progettazione è composto da cinque tipi di artefatti: Sottosistemi di progettazione Classi di progettazione Interfacce Realizzazione di casi di uso Diagramma di deployment 39 Modello di Progettazione Classi, interfacce e casi di uso derivano dal modello di analisi: Una classe di analisi in genere rappresenta una rappresentazione concettuale, di alto livello delle classi del sistema Può richiedere più di una classe e/o interfaccia di progettazione 40 Page 20

21 Classi di Progettazione Le classi di progettazione sono classi le cui specifiche sono così complete che possono essere effettivamente implementate Le classi di progettazione hanno due origini: Il dominio del problema La classe viene definita attraverso un processo di rifinitura delle classi di analisi Esiste una relazione «origine» tra una classe di analisi e la classe o le classi di progettazione Il dominio delle soluzioni Il dominio delle soluzioni contiene Librerie di utilità e di componenti riutilizzabili (classi per gestire tipi comuni, classi contenitori, ) Middleware (comunicazione, persistenza dei dati, ) Framework di componenti (CORBA, DCOM, EJB, ) 41 Classi di Progettazione Durante l analisi si cerca di fissare il comportamento richiesto al sistema senza preoccuparsi di come sarà realizzato La progettazione deve specificare esattamente come le classi del sistema assolveranno le loro responsabilità Per raggiungere questo obiettivo è necessario per ogni classe: Completare l insieme degli attributi e specificare completamente ogni attributo (nome, tipo, ) Ricavare dalle operazioni definite durante l analisi l insieme completo dei metodi 42 Page 21

22 Transizione Questa fase ha come principali obiettivi: Sistemazione dei difetti scoperti nel beta test del sistema Preparazione del rilascio a tutti gli utenti Questi due obiettivi possono essere dettagliati nella seguente lista di obiettivi: Correggere i difetti Modificare il software nel caso in cui sorgessero dei problemi non previsti Preparare i siti utente per il nuovo software Adattare il software in modo da operare correttamente presso i siti utente Aggiornare il manuali utente e create eventuale altra documentazione Fornire consulenti agli utenti Eseguire un riepilogo di fine progetto 43 Transizione Questa fase si basa quasi completamente sulle attività relative all implementazione e al test Tuttavia, un minimo di progettazione può essere necessario per correggere eventuali errori di progettazione scoperti durante il beta test Ognuno di questi tre flussi di lavoro ha un obiettivo ben definito Progettazione Rivedere il modello se sono insorti problemi durante il beta test Implementazione Adattare il software al rilascio presso i siti utente e correggere i difetti scoperti durante il beta test Test Beta test e test di accettazione eseguiti presso i siti clienti 44 Page 22

23 Transizione Milestone di questa fase è la realizzazione del prodotto finito rilasciato agli utenti A questa milestone corrisponderà il rilascio di alcuni artefatti: Prodotto software Pianificazione del supporto tecnico Manuale utente 45 Flusso di Lavoro di Implementazione Il flusso di lavoro di implementazione ha l obiettivo di trasformare il modello di progettazione in codice eseguibile Si concentra sulla produzione di codice Dal punta di vista del progettista ha anche l obiettivo di produrre il modello di implementazione del sistema In alcuni casi, il modello di implementazione può essere un sottoprodotto dell attività di implementazione Il modello viene estratto automaticamente dal codice tramite tecniche di reverse engineering In altri casi, il modello di implementazione è necessario perché: Si vuole generare il codice dal modello tramite tecniche di forward engineering Si vuole assegnare le classi e le interfacce a dei componenti in modo da massimizzare il loro riuso 46 Page 23

24 Modello di Implementazione Il modello di implementazione è una vista del modello di progettazione Ogni sottosistema di implementazione realizza esattamente lo stesso insieme di classi e interfacce del sottosistema di progettazione I sottosistemi di progettazione sono entità logiche che raggruppano elementi di progettazione I sottosistemi di implementazione corrispondono a meccanismi di raggruppamento del linguaggio di programmazione scelto per l implementazione Gli artefatti utilizzati nel modello di implementazione sono: Il diagramma dei componenti, che ha lo scopo di modellare le dipendenze tra I componenti software che costituiscono il sistema Il diagramma di deployment: che ha lo scopo di modellare i nodi fisici su cui verrà dislocato il software e le relazioni tra questi nodi 47 Cosa è un Componente? Un componente è una parte, fisica e sostituibile, di un sistema che Contiene un certo numero di classi Rispetta un certo insieme di interfacce Ne fornisce una realizzazione Un componente può essere considerato un unità di riuso Un componente può essere composto da altri componenti 48 Page 24

25 Cosa è un Componente? I seguenti artefatti possono essere considerati componenti: File di codice sorgente Sottosistema di implementazione Controllo ActiveX JavaBean Enterprise JavaBean Servlet Java Java Server Page 49 Page 25