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