Sommario Unified Modeling Language Ing. Gianluca Di Tomassi www.ditomassi.it Modelli del processo SW Modello a cascata Sviluppo iterativo del SW Modello incrementale Modello a spirale Unified Modeling Language Un po di storia e gli obiettivi I diagrammi di UML Use case Diagram Activity Diagram Class Diagram Interaction Diagram State Transaction Diagram Package Diagram Deployment Diagram Component Diagram Alcune metodologie per lo sviluppo di un progetto applicat. RUP (Rational Unified Process) XP (extreme Programming) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 2 Modelli del processo SW Ciclo di vita di un progetto software = Modello delle attività di sviluppo e dell operare il sistema informatico. Tipi di modelli: Il modello sequenziale lineare ( modello a cascata ) Il modello basato sulla prototipazione Il modello RAD (Rapid Application Development) Modelli evolutivi Il modello incrementale Il modello a spirale Il modello ad assemblaggio di componenti Il modello dei metodi formali Elementi che influiscono sulla scelta del modello del processo: la natura del progetto e dell applicazione le competenze specifiche e l esperienza acquisita in progetti precedenti dai membri del team di sviluppo i metodi e strumenti che si vogliono utilizzare i controlli e prodotti richiesti. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 3 Modello a cascata Strutturazione e modellazione del sistema e dei dati (livello sistema) Analisi dei requisiti sw. Progettazione Codifica Collaudo dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce strutture di dati, architettura del software, interfacce, algoritmi delle operazioni Il software è una parte di un sistema più ampio. Sono necessarie un analisi e una progettazione di alto livello per raccogliere tutti i requisiti, da cui il software utilizza solo una parte. codice Problemi: i progetti reali non si conformano allo schema sequenziale ogni modifica nello schema può causare confusioni non può essere governata l incompletezza dei requisiti versione funzionante solo verso la fine del progetto stati bloccanti per colpa della sincronizzazione tra le attività o tra i membri del team Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 4

Sviluppo iterativo del SW Modello Incrementale 1. Non c è tempo per una versione completa però dobbiamo uscire sul mercato. 2. Esiste un nucleo di requisiti di sistema ma i dettagli delle estensioni non esistono ancora. Soluzione: modello di processo per un prodotto che evolve nel tempo Definire l output del sistema Specificare l incremento del sistema Costruire l incremento del sistema Collaudare l incremento del sistema Strutturazione del sistema e dei dati Analisi Proget tazione Codifica Stadio 1 Utile quando la disponibilità del personale è insufficiente a garantire l implementazione completa. Si comincia con un piccolo team. Il team accresce se l accoglienza è positiva. Collaudo Consegna dello stadio 1 Vantaggi dello sviluppo iterativo È pianificato e gestito È prevedibile Permette variazioni dei requisiti più facilmente Rilasciare l incremento del sistema È basato su prototipi eseguibili evolutivi e non solo documentati Implica il cliente nell arco dell intero processo È guidato da rischi Sistema è completo? Completare il rilascio del sistema Stadio 2 Stadio 3 Analisi Stadio 4 Analisi Proget tazione Analisi Proget tazione Proget tazione Codifica Codifica Collaudo Codifica Collaudo Consegna dello stadio 2 Collaudo Consegna dello stadio 3 Consegna dello stadio 4 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 5 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 6 Sei attività portanti (task region): Modello a spirale Asse dei punti di entrata Valutazione da parte del cliente Comunicazioni con il cliente Il modello abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale. Pianificazione Costruzione e rilascio Analisi dei rischi Strutturazione Progetti di sviluppo di nuove idee Progetti di sviluppo di un nuovo prodotto Progetti di miglioramento di un prodotto Progetti di manutenzione di un prodotto Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 7 Sommario Modelli del processo SW Modello a cascata Sviluppo iterativo del SW Modello incrementale Modello a spirale Unified Modeling Language Un po di storia e gli obiettivi I diagrammi di UML Use case Diagram Activity Diagram Class Diagram Interaction Diagram State Transaction Diagram Package Diagram Deployment Diagram Component Diagram Alcune metodologie per lo sviluppo di un progetto applicat. RUP (Rational Unified Process) XP (extreme Programming) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 8

Un pò di storia Un pò di storia UML nasce per soddisfare il bisogno di un linguaggio di modellazione per sistemi complessi che sia semplice e capace di affrontare tutte le problematiche del progetto di tali sistemi complessi Lo sviluppo di UML comincia nell ottobre del 1994 UML e il prodotto di una unificazione dei metodi 1. Booch espressivo durante il progetto e adatto ad applicazioni engineering-intensive (Autore Grady Booch) 2. OMT (Object Modeling Tecnique) è un linguaggio di modellazione per l analisi e adatto a sistemi data-intensive 2. OOSE (Object Oriented Software Engineering) orientato agli use-case fornisce un eccellente supporto all analisi dei requisiti Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 9 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 10 Che cosa è UML 1. E un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e altri sistemi non strettamente software. 2. Rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi 3. Permette di visualizzare, per mezzo di un formalismo rigoroso, manufatti dell ingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni prese 4. Favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale de facto non legato alle singole imprese (Dal 1997 standard effettivo adottato dall OMG) 5. Permette di realizzare modelli potranno essere implementati con diversi linguaggi di programmazione Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 11 Che cosa NON è UML 1. Non è un linguaggio di programmazione visuale 2. Non è un processo di sviluppo (cioè non dice prima bisogna fare questa attività, poi quest altra ) 3. UML include suggerimenti utili per coloro che si occupano di realizzare dei tool di supporto, ma non stabilisce ogni necessario particolare. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 12

Obiettivi dell UML 1. Fornire agli utenti un linguaggio di modellazione visuale pronto ad essere utilizzato per sviluppare e scambiare modelli espressivi 2. Fornire meccanismi di estensione e specializzazione al fine di accrescere i concetti presenti nel nucleo. 3. Supportare specifiche che risultino indipendenti da un particolare linguaggio di programmazione o processo di sviluppo. 4. Fornire le basi formali per comprendere il linguaggio di modellazione. 5. Incoraggiare la crescita del mercato dei tool Object Oriented 6. Supportare concetti di sviluppo di alto livello come componenti, collaborazioni, framework e pattern. 7. Integrare le best practices. Generalità In UML vi sono quatto costrutti grafici: Le icone I simboli bidimensionali I collegamenti Le stringhe Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 13 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 14 S t a t i c i D i n a m i c i I m p l e m. I diagrammi UML Use case diagram (Diagramma dei casi d uso):elenca i casi d uso del sistema e le loro relazioni Class diagram (Diagramma delle classi):descrive la struttura dati degli oggetti, del sistema e le loro relazioni Object diagram (Diagramma degli oggetti):insieme di oggetti della realtà d interesse e loro relazioni Interaction diagram (Diagramma d interazione): interazione tra oggetti Sequence diagram (Diagramma sequenziale) Collaboration diagram (Diagramma di collaborazione) State e activity diagram (Diagramma di stato e di attività): Stato di un oggetto e sequenze eventi-azioni-transazioni Component diagram (Diagramma dei componenti): Descrive l architettura fisica del sistema Deployment diagram (Diagramma di distribuzione):descrive la struttura del sistema HW e l allocazione dei moduli SW Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 15 Use case diagram: Elementi Fondamentali Un caso d caso d uso uso rappresenta un possibile modo di utilizzo del sistema descrive l interazione tra attori e sistema, non la logica interna della funzione una funzionalità dal punto di vista di chi la utilizza Mostra: le modalità di utilizzo del sistema (casi d uso) gli utilizzatori e coloro che interagiscono con il sistema (attori) le relazioni tra attori e casi d uso Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 16

Use case diagram: Come si producono? (01) Use case diagram: Come si producono? (02) Gli use case possono essere ricavati dalle interviste con gli utenti. Si identificano: Gli obiettivi: ciò che il sistema dovrebbe fare secondo gli utenti Le interazioni: cosa vorrebbero (o potrebbero) fare i diversi utenti Gli use case di alto livello sono generici I dettagli si aggiungono raffinando le funzionalità del sistema La loro definizione è iterativa Si inizia identificando i comportamenti più semplici Si continua descrivendo i comportamenti più complessi Quando ci si può fermare? Un buon livello di dettaglio facilità tutte le attività successive Se ci si focalizza troppo sui dettagli questi: Potrebberò introdurre troppo presto scelte progettuali Non consentirebbero una visione d insieme Complicherebbero la descrizione Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 17 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 18 Use case diagram: Elementi Fondamentali Use case diagram: Esempio Notazione grafica Semantica Attore: è qualcuno (utente) o qualcosa (sistemi esterni - hardware) che: Scambia informazioni con il sistema Fornisce input o riceve output dal sistema attore: un utilizzatore del sistema acquistare articoli Responsabile dell istanziazione di 1 o più Use Case Non fa parte del sistema cliente log in cassiere Casi: un caso è un unità funzionale parte del sistema tipiche interazioni fra utente e sistema esprimono le procedure esistenti nel dominio in termini di scenari operativi rimborsare articoli venduti caso d'uso: un "modo" di utilizzare il sistema Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 19 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 20

Use case diagram: Relazioni Fondamentali Use case diagram: Extends Notazione grafica <uses> <extends> Semantica Interazione: indicano relazioni tra attori e casi Uses (o include): uso di una certa funzionalità (utile quando funzionalità simili sono presenti in più contesti o Use Case, utile per evitare ripetizioni) extends: definisce una funzionalità per estensione di una funzionalità già esistente (descrive una variazione sul normale comportamento) Extends: indica che uno use case è simile a un altro ma è più specifico Pertanto gli attori hanno una relazione verso lo use case che viene esteso Si assume che un dato attore sia legato sia al caso base che a tutte le estensioni Nota: uno use case che estende un altro sono allo stesso livello, ma offrono funzionalità diverse (uno non è più generico dell altro) Esempio: Ordine di un prodotto e ordine via internet <extends> cliente Ordine Ordine via Internet Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 21 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 22 Use case diagram: Uses Use case diagram: Alcuni suggerimenti Uses (o include): fattorizza attività ricorrenti e condivise. Quindi uno use case ne utilizza un altro (magari comune a più use case); è una dipendenza (stereotipo predefinito) Esempio: Ordine di un prodotto Gestione credito <uses> <uses> Ordine <uses> <uses> Mod. pagamento Identificare sostantivi e verbi Distinguere tra sostantivi che indicano componenti interni ed esterni Selezionare i verbi che indicano azioni principali da parte del sistema Dati cliente Disp. prodotto Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 23 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 24

Use case diagram : Utilizzo Use case diagram: Esercizio-Sistema registrazione corsi (01) Modellazione ad alto livello del comportamento di un elemento: intero sistema o sottosistema Strumento di comunicazione fra analisti, utenti, sviluppatori Base per il test Un possibile metodo per definire gli use case Individuare gli attori Organizzare gli attori (casi particolari: generalizzazioni) Per ogni attore individuare le principali iterazioni con il sistema (casi base e alternative ed eccezioni) Organizzare gli use case All inizio di ogni semestre, l ufficio amministrativo dell università dovrà fornire agli studenti la lista dei corsi disponibili, attraverso un sistema di registrazione on-line. Il sistema dovrà fornire tutte le informazioni relative al corso: professore, dipartimento eventuali propedeuticità. Il nuovo sistema dovrà consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente indicherà due alternative. Nessun corso potrà avere più di 10 studenti. Corsi con meno di 3 studenti verranno cancellati in modo automatico dal sistema. In caso di richiesta adeguata si potrebbero anche fare più corsi per la stessa materia. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 25 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 26 Use case diagram: Esercizio-Sistema registrazione corsi (02) Use case diagram: Possibile soluzione I professori dovranno essere in grado di accedere al sistema on-line per indicare i corsi in cui insegneranno e anche per vedere gli studenti iscritti ai loro corsi. Il processo di registrazione dura 3 giorni. Il primo giorno è riservato agli studenti del primo anno. Il secondo giorno è riservato agli altri studenti. Durante il terzo giorno si risolvono eventuali conflitti. Finito il processo di registrazione, le informazioni relative ad un studente sono inviate all ufficio contabile per determinare le tasse da pagare. Durante il semestre gli studenti devono essere in grado di accedere al sistema per aggiungere o togliere corsi Ufficio Contabile Studente Gestione Curriculum Registrazione Corsi Cambiamento Agenda Corsi Richiesta Catalogo Corsi Gestione Informazioni Studenti Archivista Cambiamento Organizzazione Corso Richiesta Iscritti Professore Selezione Corso Gestione Informazioni Professori Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 27 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 28

Use case diagram: Scenari Use case diagram: Scenari Uno scenario è un istanza di uno use case: Definisce gli eventi in un caso particolare di esecuzione del programma Uno scenario è solitamente definito in linguaggio naturale. Si rispetta l ordine temporale Gli eventi devono essere semplici e autoesplicativi (non devono includere alternative complesse) NOTA: Servono tanti scenari quanti sono quelli necessari per capire il sistema Bisogna considerare diversi livelli d astrazione Ogni use case potrebbe avere un insieme di scenari: Scenario principale (più possibile) Tutto funziona correttamente Scenari secondari (pochi e significativi) Eccezioni (eventuali problemi o malfunzionamenti) Gli scenari sono descritti per mezzo dei diagrammi di interazione (di sequenza e di collaborazione) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 29 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 30 Use case diagram: Un esempio di scenario Registrazione ai corsi: Gianluca sceglie i corsi: informatica, fisica, analisi e disegno Come corsi alternativi sceglie: fotografia e giornalismo I corsi scelti sono immessi nel sistema di registrazione Lo studente viene aggiunto ai primi 3 corsi principali Il quarto corso non è disponibile SE la prima alternativa è disponibile ALLORA lo studente viene aggiunto al corso ALTRIMENTI SE la seconda alternativa è disponibile ALLORA lo studente viene aggiunto al corso ALTRIMENTI si notifica allo studente che non è iscritto ad un numero sufficiente di corsi SE NON fallisce ALLORA Si crea la cartella corsi dello studente Si mandano le informazioni all ufficio contabile Use case diagram: Documentazione Per ogni caso d uso: Titolo Autori Descrizione Attori Pre-condizioni Post-condizioni Eccezioni Scenari Computo tasse Rossi e Bianchi Quando le iscrizioni di uno studente sono state accettate si inviano le informazioni all ufficio contabile Ufficio contabile, Studente registrato Non identificate.... Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 31 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 32

Activity Diagrams Activity Diagrams: Elementi Permette di modellare processi paralleli e la loro sincronizzazione Si descrive il comportamento attraverso un insieme di attività Modellazione di workflow: Attività a livello abbastanza alto (il flusso di oggetti può essere importante; le corsie possono essere utili) Modellazione di operazioni: A livello più dettagliato (branch, fork, join sono importanti) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 33 Stati: i nodi del diagramma Stati di azioni (action state): atomici Stati di attività: decomponibili Stati particolari: inizio e fine Transizioni: archi che descrivono il passaggio da una attività ad un'altra Semplici Diramazioni (branching) Stati concorrenza: fork e join Corsie (swimlanes): descrivono la "competenza" per lo svolgimento delle attività (in termini di soggetti del mondo reale) Si delimita da altri gruppi con una linea verticale. Flusso di oggetti: le attività si possono inviare oggetti, nel cedere il controllo Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 34 Activity Diagrams: Elementi principali Activity Diagrams: Esempio Rilascio autorizzazione etichetta [ espress. Bool. ] * Stato di azione (Attività) Pseudo stato iniziale Pseudo stato finale Transizione Barra di sincronizzazione (Join, fork) Condizione guardiano,trigger Decisione Iterazione Possono essere associati all implementazione di un operazione, ad un caso d uso o una classe. Servono ad enfatizzare i flussi dell elaborazione interna. Sono utili nei casi in cui la fine delle attività interne è considerata un evento oppure è accompagnata dall emissione di uno o più eventi. I diagrammi di attività sono un alternativa agli STD in cui i nodi/stati sono attività/azioni che rappresentano l esecuzione di operazioni. Quando gli eventi sono asincroni, sono preferibili i diagrammi STD. Barra di sincronizzazione Cliente Vendite Magazzino Richiedi servizio Paga Ricevi merci Ricevi ordine Spedisci merce Completa ordine attività corsie Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 35 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 36

Activity Diagrams: Fork e Join Activity Diagrams: Esempio Fork = Rappresenta un flusso di controllo spaccato in più flussi di controllo concorrenti. Una fork ha un flusso in ingresso e più flussi in uscita. Per ciascun flusso in uscita, le attività associate continuano in parallelo con le attività dei flussi paralleli. fork Mettere il caffè nel filtro Mettere il filtro nella macchina Trovata la bevanda [ trovato il caffè ] Aggiungere acqua decisione [ manca il caffè ] Rilasciare il bichiere Rilasciare barattolo Cola [ manca Cola ] Join = Rappresenta la sincronizzazione di due o più flussi di controllo concorrenti. All arrivo nella join, un flusso deve aspettare finché tutti i flussi sono arrivati. Tra una fork e la join Le attività che sono in flussi corrispondente ci deve essere un paralleli possono comunicare bilanciamento: N flussi escono dalla tra loro inviando dei segnali fork, N flussi debbono entrare nella join. join Attivare la macchina [ le luci spente ] Fare bollire il caffe Consumare la bevanda Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 37 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 38 Activity Diagrams: Esercizio Activity Diagrams: Possibile soluzione Descrivere il processo con un activity diagram Ricevi Ordine La ricezione di un ordinativo in un azienda comporta il controllo della forma di pagamento prevista ed il controllo della disponibilità delle merci ordinate. La mancata autorizzazione al pagamento comporta la cancellazione dell ordine. Ogni merce, se disponibile, viene assegnata all ordine. Quando tutte le merci richieste sono state selezionate l ordine può essere evaso e si procede a riordinare le merci la cui disponibilità non è più sufficiente. Cancella Ordine Evadi Ordine fallimento Controlla Pagamento successo tutte le merci disponibili * Per ogni linea dell ordine Controlla Disponibilità Assegna a Ordine Riordina Merce Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 39 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 40

Class Diagrams E il caposaldo dell object oriented e definiscono la visione statica del sistema Rappresenta le classi di oggetti del sistema con i loro attributi e operazioni Mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione) Può essere utilizzato a diversi livelli di dettaglio (in analisi e in disegno) Class Diagrams Descrizione statica del sistema: Classi Nomi Attributi (lo stato) Metodi (il comportamento) Relazioni tra classi Associazioni (uso) Generalizzazione (ereditarietà) Aggregazione (contenimento) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 41 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 42 Class Diagrams: Classi Una classe è un insieme di entità del sistema o dell ambiente, con caratteristiche comuni. Una classe è composta da tre parti: nome attributi metodi Nome Professore Nome e metodi Nome e attributi Professore Nome Cognome Professore Create() Delete() Professore Nome Cognome Create() Delete() Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 43 Class Diagrams: Classi come individuarle? Guardare Cercare Considerare Quindi: Considerare i risultati precedenti e altri sistemi, prototipi, specifiche Strutture, cose ed eventi, ruoli, unità organizzative, procedure operative molteplicità di attributi e istanze, funzioni sempre presenti, requisiti del dominio Evidenziare i nomi (oggetti) nella specifica del problema Considerare gli use case e gli scenari Si definiscono gli use case Si specificano alcuni use case in scenari Si identificano gli oggetti propri di ogni scenario Si raggruppano gli oggetti in classi Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 44

Class Diagrams: Esercizio Class Diagrams: Possibile soluzione Identificare gli oggetti per il sistema di registrazione dei corsi a partire da: use case (slide 26, 27) scenario (slide 31) Gianluca Corso Informatica Fisica Analisi Disegno Corso alternativo Fotografia Giornalismo Sistema di registrazione Studente Corso principale Alternativa Notifica Cartella studente Informazioni Selezione Ufficio contabile Come raggruppare? Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 45 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 46 Class Diagrams: Come raggruppare Class Diagrams: Esercizio Esaminando gli oggetti identificati negli scenari, alcuni oggetti possono essere raggruppati Tutti i corsi specifici appartengono alla classe Corso Definire il modello iniziale delle classi per il sistema Registrazione corsi slide 26, 27 a partire dalla lista di nomi identificati Si individua anche la classe Studente, Professore,.. La lista può crescere considerando i diversi scenari Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 47 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 48

Class Diagrams: Soluzione modello iniziale delle classi Class Diagrams: Attributi come individuarli? (01) Un attributo è una caratteristica della classe Corso Studente Catalogo Corsi Gli attributi hanno una loro identità non la si deve aggiungere Ogni attributo deve essere definito in modo preciso Gli attributi dipendono dal dominio Cartella Studente Informazioni Contabili Professore Elenco Iscritti ESEMPIO: Persona in ambito bancario nome, cognome, codicefiscale, numeroconto Persona in ambito medico nome, cognome, peso, altezza Per studente attributi corretti nome, cognome Per studente attributi NON corretti CorsiScelti Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 49 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 50 Class Diagrams: Attributi come individuarli? (02) Class Diagrams: Attributi derivati Direttamente nel testo della specifica Durante la definizione delle classi stesse Conoscenza del dominio applicativo Un attributo derivato è un attributo il cui valore viene calcolato in base ai valori di altri attributi (quindi calcolato e non memorizzato) Si usa quando non si vuole ricalcolare tutti i valori per quell attributo nei vari oggetti ESEMPIO: età, area, perimetro Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 51 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 52

Class Diagrams: Metodi Class Diagrams: Relazioni Un metodo è una trasformazione applicabile a una istanza di una classe Tutti e solo i metodi rilevanti per il dominio applicativo ESEMPIO: In ambito bancario ApreContoCorrente, EffettuaPrelievo, In ambito medico EsegueEsame, PrendeMedicina, Una relazione definisce un canale di comunicazione bidirezionale fra due classi Tutti i sistemi sono composti da oggetti che collaborano per realizzare le funzionalità richieste Alcune relazioni sono: associazioni e aggregazioni La molteplicità definisce il numero di istanze che prendono parte alla relazione Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 53 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 54 Class Diagrams: Relazioni durante l analisi ed il progetto Class Diagrams: Associazioni Durante l analisi si stabiliscono relazioni (associazioni o aggregazioni) fra classi Le connessioni sono date dalla (insite nella) natura stessa del problema Si deve pensare alle possibili molteplicità per esplicitare assunzioni implicite Un associazione: indica una relazione tra classi (ad es. una persona che lavora per una azienda) deve avere un nome, solitamente un verbo (un etichetta al centro della linea che definisce l associazione) Durante il progetto: Corso appare CartellaStudente Le molteplicità vengono modificate e raffinate Le associazioni stesse vengono raffinate Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 55 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 56

Class Diagrams: Molteplicità Class Diagrams: Molteplicità La molteplicità indica: Se l associazione è obbligatoria oppure no 1..1 Esattamente 1 Il numero minimo e massimo di oggetti che possono essere relazionati ad un altro oggetto * 0 o più ESEMPIO: 0..1 0 o uno Corso 0..* segue 3.. 10 Studente m..n, 4..7, 9 entro gli estremi specificati Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 57 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 58 Class Diagrams: Aggregazioni Class Diagrams: Associazione o aggregazione? Le aggregazioni sono una forma particolare di associazione. Una parte è in relazione con un oggetto (part-of) Aggregazione se due oggetti sono uniti da una relazione part-of (ad es: auto con motore e ruote) A B Indica che A e parte di B Associazione se due oggetti sono solitamente considerati indipendenti, anche se spesso collegati ESEMPIO: ESEMPIO: Corso 1..* 1..1 Curriculum Curriculum 1..1 1..* Corso 0..* segue 3..10 Studente Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 59 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 60

Class Diagrams: Associazioni riflessive Class Diagrams: Attributi delle associazioni La Un associazione èriflessiva se coinvolge oggetti della stessa classe Indicano oggetti multipli della stessa classe che collaborano in qualche modo Corso 0..* 0..* Propedeuticità Parte Aggregazione L attributo si mette all interno dell icona di una classe e si collega l icona all associazione (si parla di classe associativa) La classe attributo può avere proprietà specifiche È permesso una sola classe attributo per associazione ESEMPIO: Studente 3..10 segue Frequenza Profitto Percentuale 0..* Corso Solo un istanza della classe associativa tra ogni coppia di oggetti associati Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 61 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 62 Class Diagrams: Esempio Class Diagrams: Ereditarietà ( Generalizzazione) Persona * lavora Impiego Periodo 0..1 Azienda Si permette ad una persona di avere al massimo un impiego nella stessa azienda Esplicità eventuali comportamenti comuni Richiede che si debba: Aggiungere nuove proprietà alle classi Ridefinire/modificare metodi esistenti Padre general. Persona Da classe associativa a classe quando? Definisce il concetto di generalizzazione Persona * lavora 0..1 Azienda 1 Impiego 1 0..* Periodo * Si permette ad una persona di avere più di un impiego nella stessa azienda La classe figlie ereditano attributi e metodi dalla classe padre e possono avere propri attributi e metodi Studente Docente Figli general. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 63 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 64

Class Diagrams: Esempio Class Diagrams: Esercizio Pag. Contanti Prodotto 1 descrive 0..* Aggregazione Riga vendita ha 1..* 1 data ora Pagamento importo 1 riferito a 1 Vendita crea_vendita() Pag. Carta Credito Specializzazione/ Generalizzazione Definire le relazioni per il modello delle classi per il sistema di registrazione corsi (slide 26, 27) Corso Studente Catalogo Corsi Cassiere utilizzato da 1 1 POST 1 * avviato da * 1..* 1 Negozio Associazione Cartella Studente Professore 1 Amministratore nome indirizzo Informazioni Contabili Elenco Iscritti Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 65 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 66 Class Diagrams: Una soluzione (inizio) Catalogo Corsi Cartella Studente 1..1 1..* 1..1 1..* 1..* 1..1 3..10 Corso Studente 0..* 0..* 0..* Elenco Iscritti 1..1 Precedenze Professore 1..1 Interaction Diagrams Descrivono il comportamento dinamico del sistema. Specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico Ad uno use case si possono associare diversi interaction diagrams Comprendono Sequence Diagram Collaboration Diagram Elementi fondamentali Oggetti Scambio messaggi Sequenza di invocazione dei messaggi Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 67 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 68

Interaction Diagrams: Messaggi e interazione Interaction Diagrams: Notazione per i messaggi e interazione Interazione: specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico. Call: Interazione sincrona: Messaggio: specifica di una comunicazione tra istanze, che trasmette informazione nell'aspettativa che ne consegua attività evento Tipi di messaggi: Call: invoca un'operazione su oggetto (anche se stesso) Return: restituisce un valore al chiamante Send: invia un "segnale" ad un oggetto Create: crea un oggetto Destroy: distrugge un oggetto (anche se stesso) Return: Send: Create: Destroy: <<create>> <<destroy>> risposta: Interazione asincrona: Interazione non specificata (di solito asincrona) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 69 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 70 Sequence diagram Sequence diagram: elementi principali E utilizzato per definire la logica di uno scenario (specifica sequenza di eventi) di un caso d uso (in analisi e poi ad un maggior livello di dettaglio in disegno) E uno dei principali input per l implementazione dello scenario Oggetto Linea della vita dell oggetto Attivazione Mostra il periodo in cui un oggetto realizza un azione Asse verticale: tempo, dall'alto verso il basso Asse orizzontale: oggetti, da sinistra verso destra in ordine decrescente di importanza; nella prima colonna l'oggetto che avvia la collaborazione Mostra gli oggetti coinvolti specificando la sequenza temporale dei messaggi che gli oggetti si scambiano E un diagramma di interazione ed evidenzia come un caso d uso è realizzato tramite la collaborazione di un insieme di oggetti etichetta {b-a<5sec} b Messaggio - call - return - send - create - destroy Vincolo Tempo della transizione Per ogni oggetto due caratteristiche importanti la "linea della vita rappresenta l esistenza dell oggetto o dell attore il "focus of control": evidenzia il periodo di tempo durante il quale un oggetto sta eseguendo un'azione, direttamente o utilizzando una procedura subordinata Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 71 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 72

Sequence diagram: Esempio Sequence diagram: Quando e perché utilizzarli? Oggetti Utente Selezione corso Corso Usati per modellare un flusso di controllo per ordine temporale Individuare il contesto dell interazione (sistema, sottosistema, ) Scegli corso Inoltra selezione Registrazione OK Corso disponibile? Aggiungi Utente Identificare gli oggetti coinvolti e posizionarli per importanza Utilizzare il focus of control per visualizzare il nesting dei messaggi o i tempi in cui avviene la computazione Aggiungere se necessario vincoli di spazio e tempo o pre o post condizioni ai msg Si possono specificare nodi decisionali o iterazioni Tempo Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 73 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 74 Sequence diagram: Esercizio Sequence diagram: Una soluzione Scrivere il sequence diagram corrispondente ad un prestito in una biblioteca Utente Controllo tessera Ricerca volume Utente Controllo tessera Ricerca volume Invia richiesta Tessera OK Ricerca volume Volume disponibile Prestito OK Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 75 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 76

Collaboration diagram: elementi principali E un diagramma di interazione e rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso d uso Classe: Oggetto Oggetto partecipante 2: etichetta Messaggio Link Self-link Non prevedono l uso del concetto di tempo A differenza del diagramma di sequenza, mostra i link (legami) tra gli oggetti che si scambiano messaggi, mentre la sequenza di tali messaggi è meno evidente Può essere utilizzato in fasi diverse (analisi, disegno di dettaglio) Collaboration diagram: Esempio Si vuole realizzare un applicazione per la condivisione di file. Gli utenti devono autenticarsi con il server fornendo una username e password. Una volta autenticati possono effettuare ricerche per cercare file. Trovato il file desiderato l utente puo effettuarne il download Realizzare il corrispondente sequence diagram 1: Autenticazione :Utente 2: Ricerca 3: Risultato :Server 4: Dowload Utente Autenticazione Ricerca Risultato Download Server Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 77 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 78 Collaboration diagram: Esercizio Collaboration diagram: Soluzione Riprendere l esercizio sul Sistema registrazione corsi (slide 26, 27) e realizzare il relativo Collaboration diagram 2: Seleziona informatica 3: Seleziona analisi 4: Seleziona fisica 5: Seleziona disegno 7: Seleziona fotografia 8: Seleziona giornalismo 9: Sottometti corsi :Studente 1: Seleziona 4 corsi 6: Seleziona 2 corsi alt. :Corso :SelezioneCorso 10: Corso disponibile 11: Aggiungi Studente 12: Crea cartella 13: Crea info contabili :InformazioniContabili :CartellaStudente Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 79 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 80

Riassumendo... State Transition Diagrams Uno scenario può essere rappresentato per mezzo di un interaction diagram, Sequence diagram e collaboration diagram che quindi rappresentano le stesse informazioni Cambia la forma concreta Si pone l enfasi su aspetti leggermente diversi I collaboration facilitano il raggruppamento delle classi in packages e sono più evidenti i legami fra gli oggetti Commenti testuali possono fornire ulteriori dettagli al modello definito In UML Statechart E normalmente utilizzato per modellare il ciclo di vita degli oggetti di una singola classe Mostra gli eventi che causano la transizione da uno stato all altro, le azioni eseguite a fronte di un determinato evento Quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri) è opportuno utilizzarlo solo per le classi che presentano un ciclo di vita complesso e segnato da una successione ben definita di eventi Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 81 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 82 State Transition Diagrams: elementi principali State Transition Diagrams: Esempio stato Stato dell oggetto Pseudo stato iniziale Pseudo stato finale Definiscono il comportamento degli oggetti di una classe Per ogni oggetto significativo acquisisci ordine aggiungi riga ordine acquisito Stato c/a [n<5] Transizione Condizione/azione Auto transizione Condizione guardiano Decomposizione in OR Decomposizione in AND Stati e transizioni Eventi e azioni Condizioni (Se le condizioni sono vere allora si avvia la transazione e vengono eseguite le azioni) Transizione verificato e completato pagato verifica ordine pagamento ricevuto scadenza termini di pagamento spedizione al cliente annullato dopo un anno spedito dopo un anno Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 83 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 84

State Transition Diagrams: Esercizio State Transition Diagrams: Possibile Soluzione Progettare il diagramma degli stati (Statechart) per la classe selezione corso Il sistema dovrà consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente indicherà due alternative Creazione corsi < 4 Selezione corsi corsi < 2 sospendi Sospeso ricomincia Selezione corsi extra corsi = 2 Salva quit Sottometti Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 85 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 86 Package Diagrams Permettono la partizione del sistema in sottosistemi (utili per dominare la complessità del dominio) costituiti da elementi omogenei di: natura logica (classi, casi d uso, ) natura fisica (moduli, tabelle, ) altra natura (processori, risorse di rete, ) Ogni elemento appartiene ad un solo package Un package può referenziare elementi appartenenti ad altri package Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 87 Package diagram: elementi principali Pacchetto Relazione di dipendenza Relazione di generalizzazione Streotipizzare <<subsystem>> Relazione possiede global (from XX) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 88 XX (from XX) Ai pacchetti si applicano cinque stereotipi standard: facade - specifica un pacchetto che è solo una vista su un altro pacchetto framework - specifica un pacchetto che contiene patterns stub - specifica un pacchetto che serve come un proxy per gli elementi esportati di un altro pacchetto subsystem - specifica un pacchetto che rappresenta una parte indipendente del sistema da modellare system - specifica un pacchetto che rappresenta l intero sistema da modellare.

Package Diagrams: Esempio Deployement Diagrams Negozio Sono propri della fase di implementazione Negozio 1 1..* * 1 Manager Raggruppamento del codice in moduli Evidenziano le dipendenze tra i moduli Package Servizi di base Oracle Java Virtual Machine Java.applet Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 89 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 90 Component Diagrams Component Diagrams: Notazione Evidenzia l'organizzazione e le dipendenze tra i componenti software I componenti (come a livello logico i casi d uso o le classi) possono essere raggruppati in package NewPackageSpec Specifica di un nuovo Package Si esplicitano le dipendenze tra moduli Un componente è una qualunque porzione fisica riutilizzabile con un identità e un interfaccia (dichiarazione di servizi offerti) ben definite Un componente può essere costituito dall aggregazione di altri componenti NewPackage Package I component e deployment diagrams sono simili ai diagrammi delle classi, eccetto che invece di contenere classi contengono componenti e nodi rispettivamente NewCom ponent Componente Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 91 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 92

Component Diagrams: Esempio UML: Considerazioni Vendita.java Java.awt Componente UML rappresenta un evoluzione dei modelli preesistenti, più che una rivoluzione UML è adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi Prodotto.java UML può descrivere un sistema software a diversi livelli di astrazione, dal piano più svincolato dalle caratteristiche tecnologiche fino all allocazione dei componenti software nei diversi processori in un architettura distribuita POST.java Vendita.exe Dipendenza UML è sufficientemente complesso per rispondere a tutte le necessità di modellazione, ma è opportuno ritagliarlo in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 93 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 94 Sommario Modelli del processo SW Modello a cascata Sviluppo iterativo del SW Modello incrementale Modello a spirale Unified Modeling Language Un po di storia e gli obiettivi I diagrammi di UML Use case Diagram Activity Diagram Class Diagram Interaction Diagram State Transaction Diagram Package Diagram Deployment Diagram Component Diagram Alcune metodologie per lo sviluppo di un progetto applicat. RUP (Rational Unified Process) XP (extreme Programming) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 95 Metodologie per UML Per usare con successo UML occorre adottare una metodologia Utilizzare una metodologia aumenta la possibilità di riuso Le caratteristiche di una metodologia Descrive cosa fare, come, quando e perchè Comporta un certo numero di attività da portare a termine in un certo ordine Permette la realizzazione di una documentazione di progetto esauriente Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 96

Metodologie per UML: Requisiti (01) Guidata dai casi d uso I casi d uso catturano i requisiti funzionali del sistema, e influenzano tutte le fasi Centrata sull architettura L architettura di massima deve essere stabilita prima possibile L architettura definisce le parti del sistema, le loro relazioni e interazioni, i meccanismi di comunicazione Iterativa Metodologie per UML: Requisiti (02) Lo sviluppo di ciascun diagramma comprende una sequenza di passi, ognuno aggiunge informazioni o dettagli Ciascuna iterazione viene valutata ed eventualmente prototipata Conviene affrontare i problemi più difficili durante le prime iterazioni Incrementale Il sistema non viene rilasciato tutto insieme al termine del progetto, ma viene sviluppato e rilasciato (esternamente o internamente) in più parti Un incremento del sistema (versione) è costituito da una o più iterazioni Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 97 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 98 Sviluppo tradizionale Analisi dei requisiti: genera un accordo tra il cliente e il fornitore del sistema su aspetti funzionali, prestazionali, di affidabilità; ambienti operativi; integrazione con l esistente; Produce diagrammi dei casi d uso, alcuni semplici diagrammi delle classi, eventualmente qualche diagramma di attività Analisi: genera un modello del dominio applicativo, libero da dettagli tecnici e implementativi Produce diagrammi delle classi, di interazione, di stato e di attività Progettazione: genera una estensione tecnica del modello di analisi,che specifica dettagli tecnici e implementativi produce diagrammi dei componenti e di distribuzione Implementazione Testing Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 99 RUP ovvero Rational Unified Process 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 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 100

RUP: Principali caratteristiche (01) RUP: Principali caratteristiche (02) 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 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) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 101 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 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 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) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 102 RUP: Principali caratteristiche (03) Basato sui modelli RUP enfatizza lo sviluppo e il mantenimento di modelli piuttosto che la produzione di montagne di documentazione cartacea Orientato agli oggetti Gran parte dei modelli usati sono basati sui concetti di classe, oggetto, associazione 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 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 103 RUP: Un modello 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 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 104

RUP: Elaborati RUP: Le fasi Set di gestione elaborati di pianificazione (software development plan, ) elaborati operazionali (Sal, descrizione versione, ) Set dei requisiti documento di visione modello dei casi d uso modello di business Set di progettazione documento di design modello architetturale modello di test Set di implementazione codice sorgente ed eseguibili Set di rilascio agli utenti script di installazione file di dati documentazione e materiale formativo Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 105 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) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 106 RUP: Output fasi RUP: Fasi e attività (01) Inception: Documenti fattibilità Elaboration: SRS (Specifica dei Requisiti Software) e Architettura consolidata e verificata Construction: Versione sistema in pre-produzione (Beta) Transition: Versione sistema in produzione Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 107 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 108

RUP: Fasi e attività (02) RUP: Caratteristiche del processo (01) Le fasi sono sequenziali, e corrispondono a milestone significativi per Committenti, Utenti, Management Iterativo e incrementale 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 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 109 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 110 RUP: Caratteristiche del processo (02) RUP: Punti di forza I problemi gravi sono evidenziati all inizio del ciclo di vita,quando il costo per la correzione è inferiore Viene incoraggiato lo scambio di informazioni con gli utenti Il team di sviluppo si focalizza da subito sugli aspetti più critici del progetto Il test eseguito a ogni iterazione permette una valutazione oggettiva dello stato di avanzamento del progetto Le incoerenze tra requisiti e progetto vengono identificate molto presto Il carico di lavoro del team è suddiviso nel tempo in modo più uniforme Il team può utilizzare le competenze acquisite nel corso del progetto per migliorare il processo di sviluppo Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 111 E un processo ampiamente utilizzato, da anni, in contesti eterogenei quindi è sperimentato e consolidato Comprende una massa notevole di linee guida e template: fornisce indicazioni concrete su come operare in un approccio di progettazione Object Oriented Definisce in modo approfondito: i ruoli coinvolti nel processo di sviluppo le attività da effettuare i documenti in input e in output alle diverse attività Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 112

RUP: Limiti RUP: Cosa fare per utilizzarlo? È un processo il cui ambito è esclusivamente il singolo progetto è un framework di processo generico, non mirato ad alcuna tipologia specifica di applicazioni Ha origine in una cultura di sviluppo mirata alla realizzazione di prodotti commerciali, e quindi non prevede: La gestione dei rapporti contrattuali tra committenti business e sviluppatori la gestione dei rapporti contrattuali con fornitori l acquisizione (ed eventuale personalizzazione) di package commerciali deve essere adattato, senza stravolgimenti, alle esigenze e alle caratteristiche dell organizzazione tenendo conto di: 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 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 113 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 114 RUP: Costi RUP: Costi di impatto organizzativo Costi di impatto organizzativo Costi di impatto culturale Costi tecnologici Costi a Regime Il processo può risultare molto diverso dagli stili di lavoro in essere nell organizzazione che lo adotta Può portare ad una ridefinizione dei ruoli, rispetto a quelli in essere Può portare ad una ridefinizione delle modalità di comunicazione e di rapporto con Committenti e Utilizzatori Può portare ad una ridefinizione delle modalità di comunicazione e di rapporto con eventuali Fornitori Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 115 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 116

RUP: Costi di impatto culturale RUP: Costi tecnologici Può portare: un cambiamento significativo del modo di lavorare (procedure,responsabilità, tecniche) Una diversa percezione del proprio ruolo in rapporto alla committenza ed agli utilizzatori Una ridefinizione di alcuni concetti cardine dello sviluppo (analisi, requisiti, test, manutenzione) La necessità di apprendere nuove tecniche (es. approccio Object Oriented alla progettazione dei sistemi, gestione dei requisiti) L utilizzo del nuovo processo può essere agevolato dall acquisizione di strumenti specifici disponibili sul mercato per le attività primarie di sviluppo, tra cui: gestione dei requisiti e delle richieste di cambiamento analisi e design generazione di codice testing La disponibilità degli strumenti non è comunque un prerequisito indispensabile per l efficacia del processo Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 117 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 118 RUP: Costi a regime XP ovvero extreme Programming Il processo deve essere gestito in un ottica di continuo miglioramento e adattamento all evolversi delle esigenze aziendali Deve essere adattato ad ogni specifico progetto, per tenere conto delle specifiche caratteristiche e limitazioni Processo recente e molto dibattuto XP è un rappresentante delle cosiddette metodologie agili Una metodologia agile è una metodologia leggera ed adattiva: Una metodologia si dice leggera se prevede lo svolgimento di un numero ridotto di attività e produzione di relativamente pochi elaborati (ma in quantità e di qualità sufficiente per il progetto di interesse) una metodologia si dice adattiva se è in grado di gestire efficacemente cambiamenti e richieste di cambiamenti, ad esempio cambiamenti nei requisiti. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 119 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 120

XP: Punti caratteristici (01) XP: Punti caratteristici (02) L idea di fondo che legittima l intero processo è l insufficienza cronica di tempo tipica dei progetti invece di non seguire assolutamente un processo, il che rischierebbe di produrre risultati assolutamente non desiderabili, probabilmente è più opportuno seguirne uno intuitivo, leggero, pragmatico e quindi molto operativo Tutte le fasi del ciclo di vita del software vengono compresse a favore dell attività di codifica l evoluzione delle API del sistema si acquisisce leggendo direttamente il codice, il comportamento di oggetti complessi viene definito per mezzo della codifica di appositi casi di test, gli inconvenienti vengono mostrati attraverso i problemi emersi dall esecuzione dei casi di test,... elevata importanza agli unit test prima di scrivere il codice effettivo è assolutamente necessaria la scrittura dei relativi casi di test La realizzazione di unit test equivale a dire che il comportamento viene analizzato e modellato a priori sempre attraverso codice Quindi: Il processo di sviluppo equivale ad una continua reingegnerizzazione del software Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 121 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 122 XP: Vantaggi XP: Svantaggi (01) Utile se si lavora a progetti con cicli di consegna molto compressi Utile se si lavora a progetti con fattori di rischio tecnologico molto elevati Ottimo strumento a supporto di persone intelligenti Utile nel realizzare opportuni framework la collezione di classi via via prodotte viene immediatamente verificata ed eventuali lacune vengono alla luce rapidamente. NOTA : Il processo non rifiuta completamente la fase di disegno, ma ne prevede l utilizzo in casi estremi, quando non sia possibile codificare: in tutti gli altri casi l attività di implementazione ha la precedenza. Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 123 complicato sottoporre il modello ad altre persone, al fine di ricevere qualche considerazione complicato considerare i modelli stessi come risorse preziose per il futuro ESEMPIO: Si pensi agli Use Case o modelli di analisi e disegno presenti in organizzazioni bancarie che rappresentano veri e propri investimenti indipendenti dal linguaggio utilizzato per l implementazione, di un valore elevatissimo per futuri sviluppi e reingegnerizzazioni Il team deve prevedere persone di talento, cooperative, dotate di buon affiatamento, coordinate da un Team Leader dotato di esperienza e capacità personali Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 124

XP: Svantaggi (02) XP: Per tutti? L XP non porta a produrre tutta una serie di modelli estremamente importanti per l organizzazione in cui il sistema funzionerà La metodologia RUP permette di realizzare, oltre al sistema stesso, tutta una serie di manufatti di estremo interesse, come per esempio il modello del business che può essere utilizzato per aggiornare il sistema, per future reingegnerizzazioni, per insegnare a nuovi dipendenti l area di business, ecc. Per capirne l importanza, basti pensare che mentre la tecnologia tende a rinnovarsi molto rapidamente, non altrettanto vale per il business, e quindi un buon modello può risultare valido per decine di anni Progetti di dimensioni medio-piccole Team di buona qualità e di dimensioni medio/piccole Persone in grado di capire i limiti e le virtù del processo stesso Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 125 Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 126 Riferimenti BIBLIOGRAFIA UML Distilled Guida rapida al linguaggio di modellazione standard Autore Fowler Martin, Editore Pearson Education Italia Titolo originale UML Distilled: a brief guide to the standard object modeling language, third edition (Addison Wesley) The Unified Modeling Language - UserGuide Autore G. Booch, J. Rumbaugh, I. Jacobson, Editore Addison-Wesley UML e ingegneria del software - Dalla teoria alla pratica Download: http://www.mokabyte.it/umlbook/index.htm Rational Unified Process Autore P. Kruchten, Editore Addison-Wesley SITOGRAFIA http://www.rational.com/ http://www.omg.org Rational Object Management Group (per documenti ufficiali UML) Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 127