Ing. Andrea Bulgarelli UML 1.3

Transcript

1 1. UNA BREVE INTRODUZIONE A UML UML Rappresentazione (perspective) USE CASES Costruzione di Use Cases Diagram Quando si utilizzano gli Use Case Diagram Esempio CLASS DIAGRAM Esempio CLASS DIAGRAM (CONCETTI AVANZATI) Generalizzazione ed ereditarietà INTERACTION DIAGRAM Sequence diagram Collaboration Diagram Quando utilizzare gli Interaction Diagram PACKAGE DIAGRAM STATE DIAGRAM ACTIVITY DIAGRAM Dead End e End Point Swimlanes Esempi IMPLEMENTATION DIAGRAM UTILIZZO DEI DIAGRAMMI

2 1. UNA BREVE INTRODUZIONE A UML UML UML è un linguaggio di modellazione, non un metodo. Infatti un metodo è in genere costituito da un linguaggio di modellazione e da un processo, dove il processo indica i passi necessari per eseguire il progetto, e il linguaggio di modellazione è una notazione che il metodo usa per rappresentare il progetto stesso. UML è quindi indipendente dal processo utilizzato nello sviluppo del software. Il processo è infatti scelto dal progettista, in base alle sue esperienze e al tipo di applicazione da sviluppare Rappresentazione (perspective) E importante avere chiaro fin dall inizio il punto di vista utilizzato nello sviluppo di un particolare modello del sistema in esame. Tre sono i differenti punti di vista: concettuale : consente di costruire un modello del sistema in esame rappresentando i concetti del dominio dell utente. Questo è il punto di vista utilizzato nel presente documento; di specificazione : è il primo passo verso il software, ma ci si occupa del software solo a livello di interfacce. Ci si muove non più nel dominio utente, ma nel dominio applicativo; implementativo: tale punto di vista consente di descrivere l implementazione del software. UML non distingue tra i tre punti di vista, permettendo di descrivere l applicazione in ognuno di essi. Uno dei punti di forza (comune comunque anche ad OMT) sta proprio in questa flessibilità. Lo svantaggio è comunque ovvio: se non si ha chiara la distinzione tra i tre punti di vista, è possibile costruire un modello derivante dall analisi non buono, cioè un modello di analisi che, anziché concentrarsi sull analisi del problema in esame, contiene già elementi di soluzione. 2

3 1.2 Use Cases Uno use case descrive una tipica interazione tra l utente 1 e il sistema in analisi. Tali iterazioni sono formalmente descritte mediante uno o più Use Case Diagram. Le primitive utilizzate nella costruzione di uno Use Case Diagram sono: actor: ruolo che l utente ha rispetto al sistema. use case: entità grafica che rappresenta tutto ciò che riguarda le funzionalità esterne richieste dal sistema. Specifica il comportamento di un sistema o di una parte di un sistema ed e una descrizione di un set di sequenze di azioni. Si usano per catturare il comportamento del sistema in esame, senza dover specificare come il comportamento è realizzato. Un actor esegue (nel senso che utilizza) uno o più use case. A sua volta uno use case può essere eseguito da più actor. Questa relazione tra actor e use case è stabilita mediante messaggi, come nella seguente figura: ChiedePreventivo Utente Acquista Figura 1: esempio di Use Case Diagram Possono essere presenti diversi tipi di relazioni tra use case: include : si verifica quando un determinato comportamento si ripete in più casi d uso e non si vuole ripetere la sua descrizione; generalizzazione : si utilizza quando un caso d uso è simile ad un altro ma fa qualcosa di più (generalizzazione nel senso dell estensione). Questo permette di rappresentare scenari alternativi. extend: è simile alla generalizzazione, ma ci sono più regole. Quando si utilizza questo costrutto il caso d uso che estende un caso base può aggiungervi comportamento, ma stavolta il caso d uso base deve 1 Non è detto che un utente debba essere inteso come umano. Può anche essere un sistema esterno che necessità di informazioni dal sistema in esame. 3

4 dichiarare dei punti di estensione e il caso che lo estende può aggiungere comportamento solamente in corrispondenza dei punti specificati Costruzione di Use Cases Diagram Nella costruzione di uno Use Case Diagram bisogna avere ben chiara la differenza tra: system interaction (interazione col sistema); user goals (obbiettivi dell utente). Spesso è presente una dicotomia tra questi due aspetti, che viene rilevata in fase di analisi dei requisiti 2. Per risolverla è possibile concentrarsi sugli obbiettivi dell utente e ottenere una serie di Use Case Diagram che descrivono le iterazioni col sistema necessarie per soddisfare gli obbiettivi dell utente. Per la costruzione del diagramma, è possibile partire da una lista di actor e poi passare agli use cases, selezionando il dettaglio che si ritiene più opportuno Quando si utilizzano gli Use Case Diagram Uno Use Case Diagram può essere utilizzato in modo molto efficace nei primi stadi del ciclo di vita del software, in particolare in fase di analisi. Tali diagrammi consentono di individuare con chiarezza gli obbiettivi dell utente e le interazioni del sistema con gli elementi esterni ad esso. Può anche essere utilizzato, vista la sua semplicità sintattica, come supporto nella fase di specificazione dei requisiti. Ogni use case può potenzialmente descrivere una caratteristica che il sistema deve soddisfare (ad esempio, svolgimento di particolari compiti, ecc.) Esempio L esempio riguarda la definizione dei flussi informativa in una Università. Livello di Facoltà ATTORI: Preside di Facoltà: è l utente definito per ciascuna Facoltà che ha i permessi relativi alla gestione e responsabilità completa sulle informazioni del Manifesto degli Studi e del Regolamento Didattico riguardanti la Facoltà di appartenenza. Dal punto di vista organizzativo si pensa che questa competenza sia delegata alle singole Segreterie di Facoltà. Referente/Presidente di Corso di Studio: è l utente definito per ciascun Corso di Studio che ha i permessi relativi alla gestione e responsabilità completa sulle informazioni del Manifesto degli Studi e del Regolamento Didattico relative al proprio Corso di Studio. 2 Ad esempio, costruire gli use case diagram focalizzando l attenzione solo sull iterazione col sistema può portare a non comprendere appieno quali sono le reali necessità dell utente. 4

5 Docente : è l utente che rappresenta il singolo docente incaricato di uno o più insegnamenti; ha il compito di inserire il programma, l eventuale materiale didattico ed i testi consigliati dell insegnamento, ed eventualmente alcune informazioni anagrafiche che lo riguardano. Tali informazioni sono pubblicate nei singoli siti web delle Facoltà. La competenza di queste informazioni è del singolo Docente. Delegato per l Orientamento di Facoltà: ha il compito di definire i tempi e le modalità di aggiornamento delle informazioni, di monitorarne il corretto svolgimento, di validare le informazioni inserite abilitandone la pubblicazione sul Portale di Ateneo in accordo con il Delegato per l Orientamento di Ateneo. Amministratore di Facoltà: ha il compito, a livello di Facoltà, di definire i singoli utenti, di definire/controllare i permessi di accesso alle informazioni, monitorare il corretto flusso delle informazioni nel rispetto della tempistica prevista. 5

6 <<include>> Gestione programma Docente Gestione Insegnamento <<include>> Gestione materiale didattico Referente/Presidente Corso di Studio Definizione Regolamento Didattico Preside di Facolta' Definizione Manifesto degli Studi Pubblicazione Regolamento Didattico Pubblicazione Manifesto degli Studi Figura 2: Use Case Diagram dell Offerta Didattica a livello di Facoltà 1.3 Class Diagram Una classe UML è indicata da un rettangolo suddiviso in tre parti distinte: nella prima parte è indicato il nome della classe; 6

7 nella seconda parte sono elencati gli attributi della classe: agli attributi viene associata una visibilità: + indica public, # indica protected e indica private. I simboli testuali possono essere sostituiti da rappresentazioni grafiche degli stessi concetti; nella terza parte sono indicate le operazioni della classe: vale anche in questo caso il discorso della visibilità del punto precedente. Le classi sono relazionate tra loro mediante associazioni. Le associazioni, oltre ad avere una cardinalità, possono anche avare un nome (role name) e possono essere navigabili (se sull associazione è specificata una freccia). La navigabilità indica come verrà realizzata l associazione da un punto di vista realizzativo Nella figura seguente si mostra il caso dell associazione fra l ordine e il cliente, in cui si è deciso che solo la classe Ordine deve mantenere la navigabilità, mentre la classe Cliente non implementa in alcun modo il collegamento verso Ordine. Cliente nome : String indirizzo : String Cliente() -c Ordine n_ordine : int priorita : int numero_linea : int data_emissione : java.util.date Ordine() evadi() aggiungi_linea() getlineaordine() evadilinea() Figura 3 Per la due classi sono anche stati elencati gli attributi e le operazioni associate. UML distingue due ulteriori tipi di associazione: l aggregazione, indicata con il rombo vuoto, che rappresenta una relazione di part-of in cui l oggetto può essere condiviso in aggregazione da altre classi; 7

8 la composizione, indicata con il rombo pieno, in cui si richiede la partecipazione esclusiva del composto nel componente, inoltre il componente è destinato a seguire le sorti del composto quando questo viene distrutto; Il seguente esempio illustra un esempio di uso delle due varianti di questo concetto: Poligono vertice 3..* Punto 1 centro Cerchio 0..* 0..* 1 Stile 1 Figura 4 Il punto in se viene visto come valore, e non viene condiviso dalle classi, mentre lo stile può essere condiviso da più classi (il che significa che lo stile è visto come un oggetto dotato di identità). Le gerarchia di generalizzazione (primitiva IS_A) è rappresentata da un collegamento terminante con una freccia vuota, come riportato nella seguente figura. Cliente Azienda Privato Figura Esempio Il class diagram di seguito riportato è relativo all organizzazione di una università. 8

9 Ateneo 1..* Dipartimento Orientamento 0..* 0..* 1..* Facolta 1 1..* Corso di Studio durata tipo 1 1..* 1..* 0..* Insegnamento Preside di Facolta' (from Facolta) 1..n Regolamento Didattico anno_corso periodo 1..* Referente/Presidente Corso di Studio (from Facolta) 1 Manifesto degli Studi Docente (from Facolta) Figura 6: Diagramma delle classi che rappresenta la struttura del livello di Ateneo 1.4 Class Diagram (concetti avanzati) Il diagramma delle classi di UML è molto simile a quello presente in OMT. E possibile affermare che tutte le primitive e la semantica di OMT sono racchiuse nel class diagram di UML, con qualche variazione relativamente all aspetto grafico. Ovviamente il class diagram di UML ha primitive in più. Le principali differenze rispetto ad OMT sono le seguenti: un diverso modo per indicare la molteplicità delle associazioni: simbolo significato * [0, + [ 9

10 a..b a..* [a, b] a > b [a, + [ E stata introdotta una sintassi specifica per le operazioni: visibility name (parameter list): return-type-expression {property string} dove: - visibility può essere: + (public), # (protected), - (private) 3 - name è una stringa - parameter list è una lista di argomenti (opzionale) è possibile indicare regole di restrizione, includendole in {}. Per la scrittura di tali regole, è possibile utilizzare linguaggio comune oppure l OCL. Tali regole possono essere applicate a associazioni, generalizzazione, attributi, ecc. si distingue tra aggregazione e composizione : con la composizione, la classe componente può appartenere solo ad una classe composta. Per tale motivo gli oggetti di tale classe componente hanno lo stessa durata degli oggetti della classe composta. E introdotto il concetto di interfaccia di una classe, che viene comunque implementata mediante classi astratte Si distingue tra reference object e value object. I value object sono gli oggetti che descrivono i tipi di dato, e sono immutabili. All interno di UML, gli attributi sono generalmente indicati per specificare i value object Generalizzazione ed ereditarietà Oltre ad avere la possibilità di indicare dei discriminatori (caratteristica presente comunque anche in OMT), è ora possibile indicare: classificazione singola e multipla: nel caso della classificazione multipla, una superclasse può essere specializzata in più sottoclassi è possibile marcare un discriminatore come {mandatory}, per specificare l obbligatorietà di una gerarchia classificazione statica o dinamica: la classificazione dinamica permette ad un oggetto di cambiare tipo all interno della struttura dei sottotipi. 3 E ovvio che questi concetti sono più utili per un punto di vista implementativo che non concettuale. 10

11 L esempio seguente riassume le tre caratteristiche descritte in precedenza: Male Female Sex Person {mandatory} Job <<dynamic>> Salesman Engineer Manager Figura 7 Esiste invece una differenza semantica sostanziale tra la generalizzazione implementata in OMT e quelle implementata in UML. In generale, la generalizzazione può essere utilizzata per estendere una superclasse (nel senso che una sottoclasse può aggiungere nuove caratteristic he) oppure per restringere una superclasse. La restrizione riguarda: una sottoclasse può vincolare gli attributi delle superclasse; una sottoclasse può inibire l uso di alcune operazioni di una superclasse; è possibile cambiare la signature e nome di alcune operazioni o attributi. OMT implementa sia la restrizione che l estensione (si veda [Rumbaugh-91]). UML si limita invece all implementazione della generalizzazione per estensione. Infatti per descrivere tale concetto si fa uso del Principio di Sostituibilità. La maggior parte dei linguaggi ad oggetti è basata sull idea che una sottoclasse equivalga ad un sottotipo. Questa affermazione viene spesso presentata con il principio di Sostituibilità di Liskov, che si propone di chiarire cosa significhi derivare un sottotipo (o sottoclasse): B è un sottotipo 4 di A sse per ogni programma che usi oggetti di classe A è possibile utilizzare al loro posto oggetti di classe B lasciando immutato il comportamento logico del programma 4 Ricordo che per sottotipo (o sottoclasse) si intende la classe derivata. Vedi una nota precedente. 11

12 Questo principio è molto restrittivo e fonte di paradossi come quello del Quadrato-Rettangolo 5. Per ulteriori approfondimenti si faccia riferimento a [Pescio97-62]. 1.5 Interaction diagram Sono diagrammi che descrivono come gruppi di oggetti interagiscono in alcuni comportamenti. Si definiscono quindi degli scenari. In genere, si cattura il comportamento di Use Case, mostrando alcuni oggetti e i messaggi scambiati. Ci sono due tipi di Interaction Diagram: Sequence Diagram Collaboration Diagram Sequence diagram Con riferimento alla Figura 8, ogni oggetto è rappresentato da un box (contenete il nome dell oggetto nella forma objectname: classname), al di sotto del quale è presente una lifeline, la quale rappresenta la vita dell oggetto durante l interazione con gli altri oggetti. Ogni messagge è rappresentato da una freccia, al di sopra della quale è presente il nome del messaggio stesso. E possibile la self-delegation (un messaggio spedito da un oggetto a se stesso). E anche possibile indicare delle condition, che indicano le condizioni rispetto alle quali il messaggio può essere spedito. Con l iteration maker (indicato con *) è possibile indicare la spedizione di messaggi multipli. A fianco di tale marcatore è presente una condizione che indica il criterio rispetto al quale avviene la spedizione multipla. E possibile indicare anche un return, mediante linea tratteggiata 6, che indica il ritorno da un messaggio, non un nuovo messaggio. 5 Per i linguaggi ad oggetti che rispettano questo principio, un quadrato non è un rettangolo. Infatti da una classe rettangolo che accetti come parametri le due lunghezze dei lati, non è possibile derivare la classe quadrato che necessita invece di una sola misura del lato. 6 Questo è quello che prevede lo standard, ma lo strumento CASE utilizzato non consentiva di tracciare una linea tratteggiata, così ho indicato i return con una scritta tra parentesi vicino alla linea. 12

13 condition Ordine : Ordine _Cliente Riga : Riga_ Preventivo ArticoloVenduto : Articolo * [for all Riga] Prepara() object InMagazzino = CheckQuantità( ) iteration maker [InMagazzino] ModificaQuantità( ) messagge Riordinare := DaRiordinare() lifeline self-delegation Figura Collaboration Diagram Rappresenta la stessa informazione e le stesse interazioni del Sequence Diagram, ma in un'altra forma. Infatti, la sequenza dei messaggi è indicata mediante numerazione progressiva (in vari formati). 4: Riordinare := DaRiordinare() ArticoloVenduto : Articolo 2: InMagazzino = CheckQuantità( ) 3: [InMagazzino] ModificaQuantità( ) Ordine : Ordine _Cliente 1: * [for all Riga] Prepara() Riga : Riga_ Preventivo Figura 9 : Collaboration Diagram del Sequence Diagram della figura precedente 13

14 1.5.3 Quando utilizzare gli Interaction Diagram Sono diagrammi utili quando è necessario mostrare il comportamento di parecchi oggetti all interno di un singolo Use Case. L utilizzo del sequence o collaboration diagram dipende da quello che si vuole mostrare 7 : sequence diagram: enfatizza la sequenza dei messaggi; collaboration diagram: utile per vedere come gli oggetti sono connessi staticamente. Sono diagrammi utili anche per gestire processi concorrenti. 1.6 Package Diagram Diagramma che mostra raggruppamenti di classi (package ) e le dipendenze fra loro. Un package diagram può essere visto come un altra forma di class diagram. Una dipendenza esiste tra due package se esiste tra le classi costituenti il package. E possibile anche definire package che contengono altri package oppure definire la generalizzazione tra package (con lo stesso significato presente tra le classi). Esistono anche package marcati come {abstract}, che definiscono l interfaccia, implementata poi da altri package collegati al package astratto mediante generalizzazione. Acquisti Prodotti In Vendita Il Package Diagram è molto importante per grandi progetti, oppure se il class diagram diviene poco leggibile. SystemUser Gestione Magazzino Figura 10 : Esempio di Package Diagram 1.7 State Diagram UML utilizza la stessa sintassi e semantica presente negli State diagram di OMT. Si faccia quindi riferimento a [Rumbaugh91] per maggiori dettagli. Gli State Diagram sono utili per descrivere il comportamento di un singolo oggetto attraverso diversi Use Case. 7 Lo strumento CASE utilizzato consente comunque di passare in modo automatico da una forma all altra. 14

15 1.8 Activity Diagram L Activity Diagram descrive la sequenza delle attività e supporta un comportamento condizionale e parallelo. Si tratta di una variante del diagramma di stato in cui tutti gli stati hanno associata una attività Gli elementi di un Activity Diagram sono i seguenti: Activity: dal punto di vista concettuale, indicano un lavoro che deve essere svolto. Dal punto di vista più strettamente implementativo, un activity può essere un metodo di una classe. Da ogni activity possono uscire uno o più transazioni, che indicano il percorso da una activity ad un altra. Start e End Point: punti di inizio e fine del diagramma. Gli End Point possono anche non essere presenti, oppure essere più di uno. Branch e merge : il comportamento condizionale è determinato da questi due costrutti. Il branch ha una singola transazione entrante e più transazioni uscenti in cui solo una di queste sarà prescelta. Il merge ha più transazioni entranti e una sola uscente e serve a terminare il blocco condizionale cominciato con un branch. Fork e join: il comportamento parallelo è determinato da questi due costrutti. Quando scatta la transazione entrante, si eseguono in parallelo tutte le transazioni che escono dal fork. Con il parallelismo non è specificata la sequenza. Per la sincronizzazione delle attività parallele è presente il costrutto di join che ha più transazioni entranti ed una sola transazione uscente. Un Activity Diagram è particolarmente utile per descrivere: workflow process, e quindi business process; parallel process. Da un punto di vista più vicino ad UML, tali diagrammi sono utili per: descrivere metodi di classe; descrivere use case Dead End e End Point Non è necessario che in un Activity Diagram sia presente in modo esplicito un End Point. Un End Point in un Activity Diagram può essere un punto nel quale i thread si possono fermare perché la condition di uscita è falsa oppure perché non sono presenti uscite dall Activity stessa Swimlanes E possibile combinare più Activity Diagram per evidenziare come le attività presenti in uno schema possono influenzare le attività presenti in un altro schema. Questo è utile soprattutto quando si rappresenta il comportamento di use case. Gli Activity Diagram ci dicono che cosa succede, ma non ci dicono chi fa che cosa. Non vengono quindi indicate le responsabilità, cioè non viene indicato quale classe compie l azione. 15

16 Un modo per indicare queste responsabilità è introdurre un etichetta che indichi il responsabile, e separare il diagramma mediante linee verticali in zone. L etichetta presente in ogni zona indica la classe responsabile dell azione. Swimlanes è un buon metodo, in quanto combina la rappresentazione logica degli Activity Diagram con la rappresentazione della responsabilità presente nell Interaction Diagram Esempi L esempio che segue è sempre relativo alla definizione dei flussi informativi in un Ateneo. 16

17 Definizione tempi di pubblicazione [ Non valido ] [ Non valido ] Verifica Regolamento di Facoltà Verifica Manifesto degli Studi [ Valido ] [ Valido ] Autorizza pubblicazione Regolamento Autorizza pubblicazione Manifesto Pubblicazione Regolamento Pubblicazione Manifesto Figura 11: Activity Diagram del Delegato per l Orientamento di Facoltà L esempio successivo riguarda l evasione di un ordine. 17

18 Riceve ordine Soddisfa ordine Invia conto [ordine rapido] [else] Spedizione 24h Spedizione standard Ricevi pagamento Chiudi ordine Figura 12: esempio Activity Diagram 18

19 1.9 Implementation Diagram 8 Mostrano gli aspetti dell implementazione, inclusa la struttura del codice e le strutture per l implementazione run-time del progetto. Si dividono in Component Diagram, che mostra le dipendenze fra componenti software. Il Deployment Diagram mostra le relazione fisiche fra componenti software e hardware Component diagram I component diagram forniscono una vista fisica del modello corrente, mostrando l organizzazione e le dipendenze fra componenti software, inclusi moduli di codice sorgente, di codice binario e componenti eseguibili. Questi diagrammi mostrano anche il comportamento visibile esternamente dei componenti, mostrandone le interfacce. Le dipendenze sono mostrate mediante opportune relazioni tra componenti ed interfacce. I component diagram sono composti da: component packages; components; interfaces; dependency relationships I component packages rappresentano un insieme di componenti logicamente correlati. In tal modo è possibile partizionare il modello fisico del sistema. Nella figura sono rappresentati due packages e una relazione di dipendenza. NomePackage_1 NomePackage_1 Figura: component packages Un componente (component) rappresenta un modulo software con una ben definita interfaccia. L interfaccia è rappresentata da uno o più elementi d interfaccia che il componente fornisce. I componenti sono usati per rappresentare dipendenze tra i moduli (a tempo di compilazione, run-rime, di chiamata). E anche possibile visualizzare le classi implementate nel modulo. Un sistema potrebbe essere composto da parecchi moduli software di diversa specie. Per distinguere le differenti specie di moduli, è utilizzato il concetto di stereotipo 9. 8 Si veda [UML Notation Guide ] 9 Rappresenta una sotto-classificazione (una specializzazione) di un elemento del modello UML. 19

20 L icona di un componente è rappresentata nella seguente figura: NomeComponente OLE Data Figura: component Un cerchio attaccato all icona del componente significa che questo supporta una particolare interfaccia. Le interfacce sono delle classi appartenenti al componente, e definite nel diagramma delle classi. E possibile disegnare una relazione di dipendenza tra i componenti. Questo tipo di relazione sta ad indicare che le classi contenute nel componente client 10 usano le classi contenute nel componente supplier. Si consideri il seguente esempio: NewComponent Data NewComponent2 App Figura Errore. L'origine riferimento non è stata trovata..1 In questo esempio, il componente client è NewComponent2, ed utilizza la classe Data contenuta nel componente NewComponent Deployment diagram Un deployment diagram mostra l integrazione del programma con la struttura hardware e software. Gli elementi costituenti il diagramma sono: processors: componente hardware in grado di eseguire programmi. Opzionalmente è anche possibile visualizzare i processi attivi sul processore e il tipo di scheduling; device: componente hardware che non è in grado di eseguire programmi; connection: rappresenta un accoppiamento hardware tra due entità. 10 Cioè il componente che fornisce utilizza i servizi forniti da un componente supplier. 20

21 NewProcessor connection NewDevice preemptive NewMain SubProgram Figura Errore. L'origine riferimento non è stata trovata Utilizzo dei diagrammi Conviene usare l Interaction Diagram per osservare il comportamento di parecchi oggetti all interno di un singolo Use Case. Se si vuole descrivere il comportamento di un oggetto attraverso molti Use case, si utilizzo lo State Diagram se invece si vuole osservare il comportamento di uno o più oggetti attraverso molti Use case e/o molti threads, si utilizzi l Activity Diagram. 21