Introduzione a UML. obiettivo di questa introduzione

Transcript

1 Introduzione a UML Adriano Comai 1998 Pag. 1 obiettivo di questa introduzione fornire elementi di base su UML introdurre i principali diagrammi fornire indicazioni sulle modalità di utilizzo di UML nello sviluppo delle applicazioni questi temi sono trattati in modo approfondito, con esercitazioni, nel corso Rapid Application Development nel corso Analisi e disegno Object Oriented con UML Pag. 2 1

2 lo Unified Modeling Language (UML) un linguaggio (e notazione) universale, per rappresentare qualunque tipo di sistema software uno standard OMG (Object Management Group), dal nov.1997 gli autori: Grady Booch Ivar Jacobson Jim Rumbaugh i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis (e tanti altri) Pag. 3 cos è UML (e cosa non è) è un linguaggio di progettazione, non un linguaggio di programmazione (come Java, VisualBasic, C++, ) quindi serve a progettare un nuovo sistema, o a apportare modifiche alla progettazione di un sistema esistente, senza perdersi nei dettagli dei linguaggi di programmazione è universale, nel senso che può rappresentare sistemi molto diversi senza differenze legate alla tecnologia: dai sistemi web a quelli più tradizionali, dalle vecchie applicazioni Cobol a quelle object oriented e a componenti Pag. 4 2

3 ...cos è UML (e cosa non è)... è un linguaggio, non un metodo (come quelli di Yourdon e DeMarco, o di Rumbaugh o Jacobson) definisce una notazione standard, basata su un metamodello integrato degli oggetti che compongono un sistema software ma non prescrive una sequenza di processo, cioè non dice prima bisogna fare questa attività, poi quest altra quindi può essere (ed è) utilizzato da persone e gruppi che seguono metodi diversi (è indipendente dai metodi ) Pag. 5...cos è UML (e cosa non è). è un linguaggio non proprietario, standard i suoi autori (Grady Booch, Jim Rumbaugh e Ivar Jacobson) non hanno il copyright su UML la versione diventata standard OMG (Object Management Group) ha ricevuto i contributi di molti altri metodologi, e delle più importanti società di software mondiali la sua evoluzione è a carico dell OMG, e soggetta a procedure ben definite per ogni cambiamento Pag. 6 3

4 nuove tecniche e modelli??? UML è un evoluzione di modelli preesistenti, non una rivoluzione Forti affinità con modelli e diagrammi molto noti: Entity - Relationship Flow Chart modelli object oriented Innovazione dei modelli per adeguarsi alle architetture distribuite Pag. 7 Booch Rumbaugh Jacobson OOD 91 OOAD 94 Ott. 95 UNIFIED METHOD NOTATION (vers. 0.8) 94 (RATIONAL) (OMT) 91 (Objectory / OOSE) 92 Ott. 95 (RATIONAL) Lug. 96 UNIFIED MODELING LANGUAGE (vers. 0.9) pre-istoria di UML Microsoft, HP, Oracle e altri OOSE Object Oriented Software Engineering OMT Object Modeling Technique Gen UML 1.0 Nov UML 1.1 IBM, Platinum e altri Pag. 8 4

5 UML: meta-modello e diagrammi UML è basato su un meta-modello integrato, composto da numerosi elementi collegati tra loro, secondo regole precise grazie a queste regole, utilizzando gli elementi del metamodello è possibile creare modelli particolari per le singole applicazioni da progettare molti elementi (ad es. l elemento classe ) hanno una icona che li rappresenta graficamente gli elementi del meta-modello possono comparire in diagrammi di diverso tipo Pag. 9 diagrammi UML livello logico : diagramma dei casi d uso (use case) diagramma delle classi (class) diagramma di sequenza (sequence) diagramma di collaborazione (collaboration) diagramma di transizione di stato (state) diagramma delle attività (activity) livello fisico : diagramma dei componenti (component) diagramma di distribuzione dei componenti (deployment) Pag. 10 5

6 diagramma dei casi d uso Diagramma dei casi d'uso: vendita per corrispondenza effettua ordine Venditore verifica stato avanzamento Customer attore: un utilizzatore del sistema (essere umano, altro sistema, ) caso d uso: una particolare modalità di utilizzo del sistema Pag. 11 casi d uso : a cosa servono rappresentano le modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori) descrivono l interazione tra attori e sistema, non la logica interna della funzione sono espressi in forma testuale, comprensibile anche per i non addetti ai lavori possono essere definiti a livelli diversi (sistema o parti del sistema) ragionare sui casi d uso aiuta a scoprire i requisiti funzionali Pag. 12 6

7 ruolo dei casi d uso Acquirente Venditore requisiti caso d uso: effettua ordine modelli di analisi e disegno unità di rilascio Ordine DataArrivo Numero Prezzo verifica( ) evadi( ) 0..* Cliente nome indirizzo 1 StabilisciCredito( ) casi prova Pag. 13 classe: una tipologia di oggetti, con propri attributi ed operazioni diagramma delle classi Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) Libro prezioso valore : lire = 0 valorizza( ) 0..* 1..* 0..* pubblicato da Prestito scritto da 0..* 1 0..* Editore ragione sociale nome breve indirizzo sede telefono variazione dati editore( Autore nome : type = initval cognome : type = initval anno nascita anno morte Utente variazione anagrafica( ) variazione anagrafica( ) nomeclasse attributi operazioni Pag. 14 7

8 diagramma delle classi gerarchia di specializzazione (superclassesottoclasse) Libro cod_libro titolo data edizione ISDN data acquisizione richiesta( ) restituzione( ) create( ) Libro prezioso valore : lire = 0 valorizza( ) 0..* 1..* 0..* pubblicato da Prestito associazione (relationship) scritto da 1 0..* 0..* Utente Editore ragione sociale nome breve indirizzo sede telefono variazione dati editore( Autore nome : type = initval cognome : type = initval anno nascita anno morte variazione anagrafica( ) variazione anagrafica( ) classe associativa Pag. 15 diagramma delle classi: a cosa serve rappresenta le classi e gli oggetti che compongono il sistema, ed i relativi attributi ed operazioni specifica, mediante le associazioni, i vincoli che legano tra loro le classi può essere definito in fasi diverse (analisi, disegno di dettaglio) può rappresentare diverse tipologie di oggetti (oggetti business, oggetti di interfaccia, ) Pag. 16 8

9 specifica di scenario (caso d uso) : Utente biblioteca consente all'utilizzatore di richiedere in prestito uno o più libri L'utente fornisce i dati relativi al libro (ai libri) che vuole in prestito. Il sistema verifica se l'utente è censito, 1: RichiestaPrestito interfaccia richiesta : interfaccia 6: err: utente non censito ( Verifica quindi se ha 10: err: utente deve restituire libri in prestito da restituire, o se ne ha già tre in prestito, segnala l'impossibilità del prestito. Altrimenti il sistema controlla se i libri sono 15: err: libro già in prestito disponibili, e se lo sono li fornisce all'utente, altrimenti segnala l'errore attività dell oggetto 2: 5: 9: 14: controllo richiesta : Utente 3: ControlloUtentePerPrestito ( 4: 8: 11: richiesta (cod_libro) 13: : Libro : Prestito messaggio 7: PrestitiDelCliente ( ) 12: Prestito ( ) oggetto diagramma di sequenza Pag. 17 diagramma di sequenza: a cosa serve evidenzia il modo in cui uno scenario (uno specifico percorso in un caso d uso) viene risolto dalla collaborazione tra un insieme di oggetti specifica la sequenza dei messaggi che gli oggetti si scambiano può specificare nodi decisionali e iterazioni diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso Pag. 18 9

10 diagramma di collaborazione : Utente biblioteca 1: RichiestaPrestito 10: err: utente deve restituire 6: err: utente non censito ( ) 15: err: libro già in prestito 13: interfaccia richiesta : interfaccia 9: 2: 5: 14: controllo richiesta oggetto 3: ControlloUtentePerPrestito ( ) : Libro 11: richiesta (cod_libro) 12: Prestito ( ) messaggio 8: 4: : Utente : Prestito 7: PrestitiDelCliente ( ) Pag. 19 diagramma di collaborazione: a cosa serve specifica gli oggetti che collaborano tra loro in un dato scenario, ed i messaggi che si indirizzano la sequenza dei messaggi è meno evidente che nel diagramma di sequenza, mentre sono più evidenti i legami tra gli oggetti può essere utilizzato in fasi diverse (analisi, disegno di dettaglio), e rappresentare diverse tipologie di oggetti Pag

11 stato iniziale diagramma transizioni di stato acquisizione libro( dati libro, autori, editore ) evento transizione di stato stato acquisito prestito( data ) in prestito restituzione( data restituzione ) scadenza termini stato finale cancellazione libro( ISDN ) restituzione( data restituzione ) sollecito in ritardo cancellazione libro( ISDN ) Pag. 21 diagramma transizioni di stato: a cosa serve specifica il ciclo di vita degli oggetti di una classe, definendo le regole che lo governano quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri) come risultato di un evento l oggetto può passare ad un nuovo stato (transizione) Pag

12 Cliente Vendite Magazzino richiedi servizio transizione di stato stato di attività paga ricevi ordine completa ordine ricevi merce spedisci merce barra di sincronizzazione diagramma di attività Pag. 23 diagramma di attività: a cosa serve a rappresentare sistemi di workflow, oppure la logica interna di un processo (di qualunque livello, dai business process ai processi di dettaglio) permette di rappresentare processi paralleli e la loro sincronizzazione è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività Pag

13 Cliente Vendite Magazzino richiedi servizio paga ordine [effettuato] diagramma di flusso oggetto - azione ricevi ordine ordine [completato] ordine [inserito] completa ordine ricevi merce ordine [spedito] spedisci merce Pag. 25 diagramma di flusso azione - oggetto: a cosa serve a rappresentare le interazioni tra processi e oggetti è un caso particolare di diagramma di attività è un vero e proprio flow chart Pag

14 diagramma dei componenti ordine database server cliente form inserimento ordine l'esistenza dell'ordine dipende da quella del cliente package dipendenza componente Pag. 27 diagramma dei componenti: a cosa serve evidenzia l'organizzazione e le dipendenze esistenti tra componenti i componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia ben specificata i componenti (come a livello logico le classi) possono essere raggruppati in package Pag

15 diagramma di distribuzione client tcp / ip server locale interfaccia utente application server connessione tra nodi tcp / ip nodo server remoto data server Pag. 29 diagramma di distribuzione: a cosa serve evidenzia la configurazione dei nodi elaborativi in ambiente di esecuzione (run-time), e dei componenti, processi ed oggetti ubicati in questi nodi permette di rappresentare, a diversi livelli di dettaglio, l architettura fisica del sistema Pag

16 benefici portati da UML superamento della "guerra dei metodi" decine (o centinaia?) di metodi di analisi e disegno proposti e praticati difficoltà per chi vuole passare all approccio object oriented: qual è il metodo migliore? quale strumento scegliere, se non c è chiarezza nel campo dei metodi? risposta ai problemi legati allo sviluppo di sistemi complessi con ambienti visuali ritorno di attenzione sul processo di lavoro e sugli approcci utilizzati, non solo sulle tecnologie il metamodello comune favorisce le possibilità di comunicazione tra strumenti di supporto alla progettazione, e più in generale tra i diversi ambienti utilizzabili dai progettisti nello sviluppo Pag. 31 UML è troppo complesso? il metamodello di UML è veramente complesso, perché ha l'ambizione di poter rappresentare qualunque tipo di sistema software, a livelli di astrazione differenziati il numero dei diagrammi è elevato, e per molti diagrammi è possibile scegliere tra forme di rappresentazione leggermente diverse tra loro UML non suggerisce, né tantomeno prescrive una sequenza di utilizzo dei diversi diagrammi, lascia anzi molte strade aperte, tra le quali i progettisti sono liberi di scegliere Pag

17 UML va adattato alle proprie esigenze le realtà che sviluppano software sono molto eterogenee: chi sviluppa da solo, per conto proprio, non ha le stesse esigenze di documentazione e comunicazione di chi opera in un gruppo di lavoro all'interno di un'azienda tra aziende diverse possono esserci differenze anche notevoli nel livello di formalizzazione richiesto ai progettisti, nelle tecniche da adottare, negli approcci da seguire, nel tipo di documentazione da produrre Pag. 33 UML va adattato alle proprie esigenze (segue) i progetti non sono tutti uguali: variano per dimensioni, per tipologia, per criticità, e per molti altri fattori UML può essere utilizzato da tutti, perché è sufficientemente complesso per potersi adattare a tutte le esigenze ma non ha senso che tutti utilizzino UML esattamente nello stesso modo: per scegliere il percorso "ottimale", e quali diagrammi utilizzare davvero tra tutti quelli che UML mette a disposizione, è necessario verificare quali siano le esigenze che dobbiamo concretamente soddisfare Pag

18 conclusioni UML è uno standard, e questo è un bene (uniformità nei concetti e nelle notazioni utilizzate, interoperabilità tra strumenti di sviluppo, indipendenza dai produttori, dalle tecnologie, dai metodi) UML è articolato: può rappresentare qualunque sistema software, a diversi livelli di astrazione UML è complesso: va adattato ("ritagliato") in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto Pag