Principi di Ingegneria del Software

Transcript

1 CEFRIEL Centro per la Formazione e la Ricerca in Ingegneria dell Informazione Politecnico di Milano Principi di Ingegneria del Software Unified Modeling Language Alfonso Fuggetta Politecnico di Milano e CEFRIEL Alfonso.Fuggetta@polimi.it

2 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language - 2 -

3 Unified Modeling Language E un insieme di linguaggi che, utilizzati congiuntamente, consentono di descrivere/modellare aspetti diversi di un sistema con un approccio O-O Struttura statica Comportamento dinamico Interazioni fra i diversi componenti del sistema Notazione grafica Linguaggio semi-formale Standard OMG per la modellizzazione di sistemi Object-Oriented sin dal 1997 Unified Modeling Language - 3 -

4 Origine di UML Unifica le notazioni e metodologie precedentemente elaborate dai suoi stessi autori quando operavano singolarmente G. Booch J. Rumbaugh (OMT) I. Jacobson Incorpora miglioramenti e suggerimenti provenienti da altre fonti e autori E il risultato della cooperazione di diverse persone ed organizzazioni Digital, HP, IBM, Microsoft, Oracle, Rational, TI, Unisys,... Unified Modeling Language - 4 -

5 Situazione UML 1.0 gennaio 97 Sottomissione a OMG gennaio 97 UML 1.1 settembre 97 UML 1.3 giugno 1999 Dove trovare informazioni costantemente aggiornate: internet newsgroup comp.object Unified Modeling Language - 5 -

6 Caratteristiche Non proprietario chiunque lo può usare chiunque può sviluppare strumenti di supporto Elimina le differenze (spesso inessenziali) presenti tra le notazioni precedenti Semi-formale l enfasi è sulla definizione della notazione c è peraltro un meta-modello semantico cui i tool dovranno fare riferimento la semantica non è comunque rigorosamente definita in tutti i casi (da cui la semi-formalità) Si è considerato il problema dello scambio di dati tra tool diversi (XMI, CDIF,...) Unified Modeling Language - 6 -

7 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language - 7 -

8 I class diagram Forniscono una vista strutturale (statica) del sistema in termini di classi attributi operazioni relazioni tra classi (associazioni, generalizzazioni,...) Un class diagram rappresenta uno schema concettuale se una classe A è in relazione con una classe B, allora ogni istanza di A sarà in relazione con un istanza di B Unified Modeling Language - 8 -

9 Similitudini Entità / Relazioni E una estensione dei diagrammi Entità / Relazioni. Introduce classificazione, istanziazione e aggregazione. Definisce non solo gli attributi, ma anche le operazioni. Altri modelli OO (Booch, OMT) Differenze sintattiche Unified Modeling Language - 9 -

10 Classi Una classe descrive un gruppo di oggetti con caratteristiche comuni attributi comportamento Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e per le relazioni che li legano ad altri oggetti. Unified Modeling Language

11 Notazione generale per le classi Nel caso più generale la notazione è la seguente. NomeClasse nome-attributo-1: tipo-dato-1 = valore-di-default-1 nome-attributo-2: tipo-dato-2 = valore-di-default-2... nome-operazione-1 (lista-argomenti-1): tipo-reso-1 nome-operazione-2 (lista-argomenti-2): tipo-reso-2... Persona Nome: string Età: int CambiaLavoro CambiaIndirizzo File Nome: string Dimensione: int Creazione: data Stampa Disegno Titolo: string Altezza: int Larghezza: int Stampa Ruota(gradi: int) Esempi di Rappresentazione di Classi, Attributi e Operazioni Unified Modeling Language

12 Livello di dettaglio visibile WINDOW WINDOW size: Area visibility: Bool display() public protected private + display() WINDOW {abstract} + size: Area =(100, 100) # visibility: Bool - xptr: Xwindow - attachxwin(xwin:xwindow) E possibile in ogni momento decidere il livello di visibilità: Classi degli attributi Classi dei parametri e dei valori restituiti dai metodi di una classe Qualificatori di attributi ed operazioni Unified Modeling Language

13 Classi: Implementazione Esiste una corrispondenza tra la rappresentazione UML di una classe e l implementazione con un linguaggio O-O (Es. Java) + importo: Real + data: Date + cliente: String - fatture_emesse : int = 0 Fattura Fattura() nome-operazione-1 (lista-argomenti-1): tipo-reso-1 nome-operazione-2 (lista-argomenti-2): tipo-reso-2 public class Fattura { public double importo; public Date data = new Date(); public String cliente; static private int fatture_emesse = 0; public Fattura() { fatture_emesse++; } // Altri metodi //... } Unified Modeling Language

14 Oggetti: Notazione grafica Un oggetto è un istanza di una classe Per rappresentare un oggetto si utilizza lo stesso simbolo usato per rappresentare le classi Il nome viene sottolineato per evidenziare che si tratta di un oggetto Analogamente a quanto accade per le classi è possibile decidere il livello di visibilita per attributi e valori Classe Istanze Order : Order MyOrder: Order MyOrder: Order number=0 amount=10000 Unified Modeling Language

15 Relazioni in UML In un Class Diagram vengono rappresentate relazioni oltre alle classi: Associazioni (semplici, aggregazioni, composizioni) Relazioni di generalizzazione Relazioni di dipendenza Relazioni di raffinamento Unified Modeling Language

16 Associazioni Una Associazione individua una connessione logica tra classi si traduce in una connessione fra oggetti istanze delle classi coinvolte nell associazione Il concetto di associazione è presente anche nella modellazione concettuale di database (Entity-Relationship) Nome (opzionale) dell'associazione Città Nome: string CapoluogoDi Regione Nome: string Nota: una associazione è naturalmente bidirezionale. Unified Modeling Language

17 Cardinalità nelle associazioni Indica il numero di istanze di una classe che possono essere associate ad una singola istanza dell altra classe Può non essere specificata ad uno degli estremi ( association-end ) o a entrambi E in questo caso non significa cardinalità pari a 1! Unified Modeling Language

18 Cardinalità nelle associazioni S2 P7 S1 S3 S5 P1 P3 P6 P5 S4 P2 P4 Situazione da descrivere Indicazione (opzionale) di molteplicità Linea Nome: string 0..* IdentificataDa > < AppartieneA 2 Punto Nome: string Unified Modeling Language

19 Notazione per la cardinalità La molteplicità si può indicare con precisione. Persona Nome: string 1..3, 5 Possiede Auto Modello: string Ogni persona può possedere zero o al più un'auto (magari in comproprietà) Ogni auto ha 1, 2, 3 o 5 (ma non 4) comproprietari * 0, 3..5, 7..* Auto Auto Auto Auto... zero o un'auto... esattamente un'auto... zero o più auto... zero, da 3 a 5 oppure 7 auto e oltre Unified Modeling Language

20 Notazione per la cardinalità(2) Persona Nome: string Possiede 0..* Auto Modello: string Nota: Il class diagram indica che una persona può possedere un numero qualsiasi di auto Quanti sono i proprietari di una singola auto? Il diagramma non fornisce questa informazione, dato che la cardinalità della partecipazione di Persona all associazione risulta non specificata! Inoltre, dato che l associazione è navigabile in una sola direzione, data un auto non è mai possibile risalire ai suoi (o al suo) proprietario Unified Modeling Language

21 Associazioni n-arien Alcune associazioni con cardinalità maggiore di due non sono riducibili a semplici associazioni binarie. Persona UsaPer Progetto Corretto Linguaggio Simbolo indicante la relazione n-aria (ternaria) Sbagliato Persona 0..* LavoraCon 2..* 0..* LavoraIn Linguaggio 1..* Progetto 0..* UsatoIn Se ogni persona conosce C e C++ e ogni progetto usa entrambi i linguaggi, anche se so chi ha lavorato in ciascun progetto perdo la nozione di che linguaggio ha usato in quel progetto. Unified Modeling Language

22 Ruoli nelle associazioni Una classe può partecipare ad un associazione con un ruolo specifico, che può essere indicato Persona 1..* Lavora per 0..1 Impiegato DatoreDiLavoro Azienda Il ruolo (opzionale) viene indicato in stile normale Unified Modeling Language

23 Ruolo obbligatorio nelle associazioni Quando le stesse classi sono coinvolte più volte dalla stessa associazione il ruolo diviene obbligatorio. Utente 1 owner 0..* utente autorizzato 0..* contenente 0..* Directory 0..1 contenuto 0..* Qui il ruolo serve a distinguere due associazioni diverse tra le stesse due classi Qui il ruolo è obbligatorio Alternativa: contiene Unified Modeling Language

24 Associazioni: Implementazione In generale non esiste un mapping diretto su un costrutto di un linguaggio di programmazione Possono essere implementate introducendo degli attributi ad hoc che contengono dei riferimenti (o puntatori) alle istanze delle classi associate Il riferimento a più istanze di una classe può essere modellato con liste, array, etc. Direzionalità In fase di implementazione si può decidere di codificarla solo in una delle due direzioni (con un puntatore), perdendo però così la possibilità di percorrere il link nella direzione opposta! Nota: Una associazione va modellata come tale in UML!! Nascondere le associazioni nelle classi (ad es. come attributi puntatori) porta alla costruzione di diagrammi contenenti dipendenze nascoste difficili da gestire Unified Modeling Language

25 Implementazione delle Associazioni: Esempio Compagnia Assicurazioni 1 compagnia 0..* contratto Contratto public class Compagnia_Assicurazioni { private Vector contratti; /* In alternativa si può usare un array: Contratto[] contratti */ /* Metodi */... } public class Contratto { private Compagnia_Assicurazioni compagnia; /* Metodi */... } Unified Modeling Language

26 Attributi delle associazioni (Association Class) In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi coinvolte. Studente 1..* 1..* Corso Frequenza anno_accademico profitto Questa è la notazione per indicare che una associazione possiede alcuni attributi Non si tratta di attributi dello studente perché cambiano da corso a corso. Nè sono attributi del corso (ad es. ogni corso è frequentato da studenti diversi in anni diversi) Unified Modeling Language

27 Attributi delle associazioni: consiglio Se l'associazione è 1-a-molti gli attributi dell'associazione si possono modellare come attributi della classe. Azienda Datore di lavoro Impiegato Persona Modello consigliato * Lavoro Salario Incarico Azienda Datore di lavoro 1..1 Impiegato 1..* Persona Salario Incarico Modello sconsigliato Unified Modeling Language

28 Attributi delle associazioni n-arien Anno * Stagione Squadra * Squadra * Portiere Giocatore La notazione rimane la stessa delle associazioni binarie Ruolino Goal fatti Goal subiti Vinte Perse Pari Unified Modeling Language

29 Associazioni esclusive Talvolta un associazione può esistere verso una classe o verso un altra (non verso entrambe) Persona Partita IVA {xor} Azienda Unified Modeling Language

30 Il qualificatore E` un attributo dell associazione per associazioni uno a molti e molti a molti distingue un oggetto tra i molti può abbassare la molteplicità Nome Show 1 0..* Ticket Senza qualificatore Rappresentazione Data : Date Posto: SeatNumber qualificatore Show Con qualificatore Nome Data : Date Posto: SeatNumber Ticket Attributi del qualificatore Molteplicità con qualificatore Unified Modeling Language

31 Il qualificatore: significato E un attributo il cui valore consente di selezionare un singolo oggetto tra tutte le istanze di oggetti interessati dalla stessa associazione Azienda 0..* Lavora_per Incarico 1..* Persona Senza qualificatore In questo esempio il qualificatore non ha l'effetto di abbassare la molteplicità Azienda Persona Incarico 0..* Con qualificatore 1..* Unified Modeling Language

32 Diagrammi delle Istanze (Object Diagram) Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un particolare class diagram Adatti a descrivere esempi o situazioni specifiche (punti di vista o fotografie delle istanze esistenti in un certo istante di tempo) Unified Modeling Language

33 Link e Object Diagram Un legame (link) è una connessione fisica o concettuale fra due istanze. Mentre un'associazione connette due classi, un link connette due oggetti. I link sono istanze delle associazioni. ricopre carica in cittadino_di C.A.Ciampi: Persona Italia: Repubblica cittadino_di Dario Fo: Persona Unified Modeling Language

34 Object diagram: Esempio S2 S1 P3 P1 P4 P2 S3 P5 Linea Nome: string 0..* IdentificataDa > < AppartieneA 2 Punto Nome: string Situazione da descrivere S1: Linea P1: Punto S2: Linea S3: Linea P2: Punto P3: Punto P4: Punto P5: Punto Diagramma degli oggetti Unified Modeling Language

35 Aggregazione E un caso particolare di associazione molto comune che significa: è un insieme di". Il rombo vuoto si legge "è un insieme di" Poligono Modello equivalente che usa una associazione convenzionale: 1..* Punto Essendo un tipo particolare di associazione è sempre possibile specificare la cardinalità Poligono InsiemeDi 1..* Punto Unified Modeling Language

36 Composizione E un caso particolare di aggregazione che significa: è composto da". i componenti non possono esistere senza il contenitore la proprietà da parte del contenente è esclusiva la molteplicità dal lato dell aggregato deve essere <=1 Può essere qualsiasi per gli elementi componenti Window scrollbar 2 body 1 close 1 Slider Panel 1 Button Unified Modeling Language

37 Aggregazione e Composizione Per evitare di riempire il diagramma di linee di aggregazione è possibile usare un "albero PC 1..* 0..1 Monitor UnitàBase Mouse Tastiera HardDisk FloppyDisk ModuloRAM CPU Coprocessore Unified Modeling Language

38 Relazioni di aggregazione: Semantica Dipendenza delle parti dall oggetto composito dipendente indipendente Proprietà esclusiva condivisa? *? 1..* + semantica di propagazione delle operazioni definita dall utente (necessaria) Varianti 1 propagazione esclusiva, dipendente, ma assenza di delle operazioni Unified Modeling Language

39 Composizioni vs. Associazioni L'aggregazione è un caso particolare di associazione. Come distinguerle? Contenimento fisico vs. semplice riferimento Le parti sono fisicamente contenute nell oggetto composito L associazione comporta il semplice mantenimento di riferimenti tra oggetti Ciclo di vita L oggetto composito deve gestire la creazione e la distruzione delle parti Non c è dipendenza esistenziale tra le parti nell associazione Unified Modeling Language

40 Associazioni riflessive Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti della stessa classe una associazione ricorsiva indica che più oggetti della stessa classe interagiscono e collaborano in qualche modo Corso Programma 0..* precedenza 0..* 0..* 1..* Blocco Unified Modeling Language

41 Generalizzazione ed ereditarietà Generalizzazione = relazione "is-a" Ogni istanza di una classe è anche istanza di tutte le superclassi La relazione di generalizzazione può essere utilizzata anche fra altri elementi del linguaggio UML (packages, use cases, etc.) Ereditarietà Meccanismo attraverso il quale elementi specializzati incorporano la struttura ed il comportamento di elementi più generali Unified Modeling Language

42 Generalizzazione: Esempi (1) Amico {simmetrica} 0..* Persona Data Nascita 0..* Persona è una generalizzazione di Uomo e di Donna Attributi, operazioni e associazioni vengono ereditati dalle sottoclassi generalizzazione Donna Numero Gravidanze Uomo Posizione Militare Uomo e Donna sono sottoclassi di Persona Esempio di Object Diagram Giorgio Neri : Uomo amico Rosa Verdi : Donna amico Eugenio Rossi : Uomo Unified Modeling Language

43 Generalizzazione ed ereditarietà: Esempi (2) Studente Persona - String nome - String indirizzo + Persona(String nome, String ind) + stampa() + String nome() + String indirizzo() - int matricola - String esami[ ] - int voti[ ] + Studente(String nome, String ind, int mat) + aggiungiesame(string nome, int voto) + int mediavoti() la classe Studente eredita dal padre: attributi metodi Un oggetto Studente può essere trattato esattamente come un oggetto Persona In cosa solitamente può differenziarsi la classe erede aggiunta di attributi e metodi i metodi possono essere ridefiniti Unified Modeling Language

44 Generalizzazione: Esempi (3) Poligono + Colore colore + sposta(float dx, float dy) + ruota(punto centro, float angolo) + disegna(schermo s) Rettangolo Triangolo + float diagonale() Autoveicolo + String targa + String modello + stampalibretto() VeicoloCommerciale + int pesocarico + int pesovuoto + boolean articolato VeicoloPrivato + int numeroporte + int numeroposti Unified Modeling Language

45 Classi astratte Una classe astratta è una classe che non può essere direttamente istanziata Può (anzi deve) avere delle sottoclassi concrete Classi astratte e queste possono essere istanziate (se non sono astratte a loro volta) Figura {abstract} Notazione alternativa: nome della classe in corsivo Poligono {abstract} Cerchio Classi concrete Triangolo Quadrato Unified Modeling Language

46 Classi astratte (2) Il termine astratto viene anche utilizzato per per descrivere una operazione per la quale non è stata definita una implementazione Le operazioni astratte di una classe si rappresentano scrivendo il nome in corsivo Una classe astratta può avere operazioni concrete Almeno una operazione deve essere astratta Tipicamente vengono usate per mettere a fattor comune un'astrazione di un certo tipo per favorire il riuso Unified Modeling Language

47 Classi astratte: Esempio Figura +figurapart #Position : Pos * +draw() 1 Gruppo_Figure Poligono Linea 1 * +lineapart Unified Modeling Language

48 Esempio (Implementazione) public abstract class Figura { public abstract void draw(); } protected Pos position; public class Gruppo_Figure extends Figura { /* Una specializzazione di Vector } contenente solo istanze di Figura */ public FiguraVector figurapart; public void draw() { } for(int i=0; i< figurapart.size(), i++) figurapart.get(i).draw(); public class Poligono extends Figura { public LineaVector lineapart; public void draw() { for(int i=0; i< figurapart.size(), i++) lineapart.get(i).draw(); }; } Unified Modeling Language

49 Associazioni e attributi derivati Alcune associazioni e alcuni attributi sono in realtà una semplice rielaborazione di altri valori e/o legami Persona Data Nascita : Date / Età : int {Età = Data Corrente - Data Nascita} Azienda Le associazioni i cui legami sono calcolabili in base ad altri legami o ai valori degli attributi sono identificati da una barra trasversale /impiega Gli attributi i cui valori sono calcolati in base agli altri sono identificati da una barra ( / ) 1 1..* Divisione 1 lavora_per 1..* Persona Unified Modeling Language

50 Vincoli come restrizioni Si possono porre vincoli e restrizioni sui legami e sul valore degli attributi scrivendoli tra graffe a margine della classe o dell associazione Campo di ammissibilità {Non sovrapposti} 1..* Intervallo Inizio : int Fine : int Vincolo sui legami {Inizio < Fine} Vincolo sugli attributi Impiegato Stipendio Capo Questo vincolo più che sui valori è un vincolo sulla evoluzione dei valori nel tempo Ordine Priorità {Stipendio < Capo.Stipendio} {la Priorità può solo crescere} Unified Modeling Language

51 Vincoli interni sulle associazioni In generale le associazioni "a molti" considerano gli oggetti legati ad uno come se fossero un insieme non ordinato. I vincoli permettono di fissare un certo tipo di ordinamento. Poligono 0..* HaPerVertice 3..* {in ordine ciclico} Punto La sequenza dei vertici lungo il perimetro Persona Ha 1..* {in ordine} Esperienza La sequenza cronologica nel curriculum Unified Modeling Language

52 Vincoli relativi sulle associazioni Le associazioni possono avere vincoli che condizionano una associazione rispetto ad un altra Persona 0..1 ABordoDi {sottoinsieme} AllaGuidaDi 0..1 Auto Una freccia puntinata collega le associazioni soggette al vincolo e una etichetta fra parentesi graffe indica quale sia il vincolo Unified Modeling Language

53 Vincoli relativi sulle associazioni dipendente datore di * impiegato lavoro Persona Azienda 1..* 0..1 capo 0..1 Persona.datore_di_lavoro = Persona.capo.datore_di_lavoro Unified Modeling Language

54 Interfaccia L interfaccia descrive il comportamento esterno di una classe. applicabile anche ad altri elementi, oltre le classi. Evidenzia ciò che viene fornito dalla classe. Può servire a indicare l insieme minimo di servizi richiesti da una classe dipendente. String Hashable * HashTable Realization Relationship IsEqual(String):Boolean Hash():Integer Comparable <<interface>> Comparable IsEqual(String):Boolean Hash():Integer <<use>> Interfaccia: Notazioni alternative Unified Modeling Language

55 Stereotipi Rappresentano uno dei meccanismi attraverso i quali è possibile estendere la notazione UML Vengono utilizzati per specializzare la semantica di elementi predefiniti in UML ( classi, associazioni, etc.) uno stereotipo rappresenta una sottoclasse di un elemento esistente (classe, associazione, package, use case ) ed individua un particolare uso per l elemento un elemento stereotipato può essere utilizzato in tutte le situazioni in cui può essere usato l elemento originale Uno stereotipo può essere descritto in modo testuale (<<StereotypeName>>) o grafico Unified Modeling Language

56 Stereotipi: Esempi Alcuni stereotipi standard per le classi <<entity>> EntityClass <<control>> ControlClass <<boundary>> BoundaryClass Entity Classe passiva: le sue istanze non sono mai iniziatori di interazioni. Control Classe le cui istanze controllano le interazioni fra collezioni di altri oggetti. Boundary Classe posta alla periferia del sistema (comunque all interno del sistema). Svolge il ruolo di Intermediario tra gli attori e le altre parti del sistema Unified Modeling Language

57 Dipendenza Relazione che indica una dipendenza di varia natura tra elementi di un modello UML Si può avere dipendenza tra classi, packages, use cases, etc. Individua una connessione semantica tra due elementi, uno dei quali è dipendente dall altro Una modifica nell elemento indipendente ha effetti su quello dipendente Unified Modeling Language

58 Dipendenza tra classi Esempi di dipendenza tra classi C1 e C2: Un metodo di C1 ha come parametro un oggetto di classe C2 Un metodo di C1 restituisce come risultato un oggetto di classe C2 Un metodo di C1 istanzia un oggetto di classe C2 Un metodo di C1 invia un messaggio ad un oggetto di classe C2 di cui possiede il riferimento Unified Modeling Language

59 Dipendenza: Esempio Classe D Classe A Classe B <<instantiates>> operationz() <<calls>> Classe C Unified Modeling Language

60 Esempi di relazioni di dipendenza tra classi Alcune relazioni di dipendenza (tra classi) esplicitamente citate nella specifica UML: <<instantiates>> Un metodo di una classe crea istanze di un altra classe <<calls>> Indica che un metodo di una classe chiama un metodo di un altra classe <<friend>> Indica la possibilità di accesso al contenuto di un altra classe indipendentemente dalla visibilità prevista dalla classe target <<usage>> Indica che un elemento richiede la presenza di un altro per il suo corretto funzionamento (comprende <<calls>>, <<instantiates>>) Unified Modeling Language

61 Costrutti di raggruppamento Modulo: raggruppa classi, associazioni e generalizzazioni fornisce una vista del problema diminuisce la complessità del problema La suddivisione in moduli può essere fatta in diversi modi. Criterio: forte coesione, scarse connessioni Unified Modeling Language

62 Packages Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML A volte si utilizza il termine subsystem per indicare un package E possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra packages diversi A A B A1 A2 B1 B Unified Modeling Language

63 Dipendenze tra Packages Descrivono, ad un livello di astrazione più alto, dipendenze esistenti tra elementi contenuti nei singoli packages dipendenze multiple dello stesso tipo tra singoli elementi (ad es. Classi) appartenenti a packages diversi vengono riassunte in una singola dipendenza tra i packages contenenti i diversi elementi Tipologie di relazioni tra packages Generalizzazione Esiste almeno una relazione di generalizzazione tra elementi appartenenti a package diversi Dipendenza Esiste almeno una relazione di dipendenza tra elementi appartenenti a package diversi Unified Modeling Language

64 Dipendenze tra Packages (2) In generale, se non si esplicita una relazione di dipendenza, un package non può accedere agli elementi contenuti in un altro package Le relazioni di dipendenza definiscono delle permission per l accesso al contenuto di altri packages (limitatamente agli elementi con visibilità public o protected presenti nel package target) Le relazioni di dipendenza tra packages non sono transitive Se il package A può vedere B e B può vedere C, non è detto che A possa vedere C Unified Modeling Language

65 <<import>> e <<access>> Dipendenza con stereotipo <<access>> Gli elementi contenuti nel package target possono essere referenziati dagli elementi contenuti nel package client (o dai sub-package in esso contenuti) Una dipendenza di tipo <<access>> non modifica il namespace del client e non crea riferimenti di alcun tipo Garantisce solo la possibilità di creare refrences Dipendenza con stereotipo <<import>> I nomi degli elementi presenti nel namespace del package target vengono aggiunti al namespace del package client (con le stesse regole di visibilità valide per <<access>>) Se ci sono conflitti fra i nomi importati e nomi già presenti nel namespace del client, il modello è mal formato (ill formed) Unified Modeling Language

66 Dipendenze tra packages: Esempio Unified Modeling Language

67 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language

68 Interaction diagram e comportamento dinamico del sistema Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un certo comportamento. Tipicamente rappresentano il comportamento di uno specifico use case in termini di specifici oggetti e messaggi scambiati Ci sono due tipi di interaction diagram: Sequence diagram Collaboration diagram Unified Modeling Language

69 Sequence diagram Mostra una interazione tra oggetti come sequenza temporale di azioni. oggetti partecipanti sequenze (temporali) di messaggi scambiati non si vedono le associazioni tra oggetti La forma generica mostra tutte le possibili sequenze La forma d istanza mostra solo una sequenza specifica (consistente con quella generica) Unified Modeling Language

70 Sequence diagram In ascissa sono disposti vari oggetti (istanze specifiche) L ordinata rappresenta il tempo in genere la scala non importa interessa solo la sequenza cioè il rapporto di precedenza tra eventi, non la loro distanza. ma per sistemi real-time si può usare. Unified Modeling Language

71 Sequence diagram: notazione Oggetti Obj1 Obj2 Obj3 Messaggi Istanti di tempo Vincolo temporale Commento {b-a < 1 sec.} This call is routed through the network a b c c do_this() do_that() Messaggio che impiega un certo tempo per essere ricevuto Tempo Unified Modeling Language

72 Esempio 1 Caller Exchange Receiver {b-a < 1 sec.} {c-b < 10 sec.} a b c lift receiver dial tone dial digit... This call is routed d through the network {d -d < 5 sec.} At this point the parties can talk d route ringing tone stop tone phone rings answer phone stop ringing Unified Modeling Language

73 Esempio 2: testo The physician powers up the ECG machine. The physician sets up for four waveforms at 25 mm/sec sweep speed. The physician sets the bradycardia alarm at 40 bpm and the tachycardia alarm at 110 bpm. The patient undergoes an asystole event. The system detects the asystole and raises the alarm. The physician provides therapy to correct the problem (external to the system boundary). The system detects the restarted heart rate to be 45 bpm and lowers the alarm.... Unified Modeling Language

74 Esempio 2: sequence diagram physician sets up for patient monitoring physician waveform controller use 4 waveforms setsweep speed(25) heart rate parameter Rate=50 Rate=47 alarm manager alarm display patient set bradycardia alarm asystole event physician s intervention set tachycardia alarm Rate=0 raise bradycardia alarm alarm text Rate=45 lower bradycardia alarm clear alarm Unified Modeling Language

75 Notazione estesa: terminologia Agente Oggetto creato da op() Oggetto preesistente lifeline dell oggetto condizione, equivale a if (x>=0) { Obj2=new(C2); Obj2.foo(x); } else Obj3.bar(x); op() Obj1:C1 Obj3:C3 [x>=0] foo(x) [x<0] bar(x) doit(w) Oggetto creato da foo(x) Obj2:C2 Unified Modeling Language

76 Processi concorrenti e attivazioni op() Obj1:C1 Obj3:C3 Obj4:C4 [x>=0] foo(x) [x<0] bar(x) doit(w) Obj2:C2 doit(z) more() Unified Modeling Language

77 Notazione estesa: terminologia Attivazioni Obj4:C4 Messaggi return doit(w) Obj2:C2 doit(z) Confluenza delle due possibili evoluzioni Attivazione ricorsiva more() Distruzione dell oggetto Oggetto che prosegue la sua esistenza dopo queste interazioni Unified Modeling Language

78 Messaggi sincroni e asincroni I messaggi possono essere sincroni (equivalenti a una chiamata di procedura) asincroni (equivalenti a qualche forma di comunicazione tra processi) in pratica indicano che chi invia il messaggio continua ad evolvere, senza aspettare la conclusione dell operazione lanciata. Notazione: comunicazione sincrona comunicazione asincrona Unified Modeling Language

79 Collaboration diagram Collaboration: interazione tra parti di un sistema per un certo scopo si isolano parti di sistema e si trascurano le interazioni non essenziali allo scopo L interazione è descritta in rapporto agli oggetti e alle relazioni che li legano. Non c è una dimensione precisa per il tempo le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo Unified Modeling Language

80 Esempio di interazione oggetto : OrderEntryWindow messaggio auto-delega : Order 1: prepare() ordine nella sequenza di messaggi 5: NeedToReorder() 2*: prepare() 3: check() LineaTrenini : OrderLine 4: [check() == true] remove() MagazzinoTrenini : Stock 7: [check() == true] new 6: new : DeliveryItem : ReorderItem Unified Modeling Language

81 Esempio con numerazione decimale Questo tipo di numerazione indica chiaramente quale operazione chiama quale altra : OrderEntryWindow : Order 1: prepare() Ad esempio,order::prepare() chiama check, remove e new(), remove a sua volta chiama NeedToReorder e new : NeedToReorder() 1.1*: prepare() 1.1.1: check() LineaTrenini : OrderLine 1.1.2: [check() == true] remove() MagazzinoTrenini : Stock 1.1.3: [check() == true] new : new : DeliveryItem : ReorderItem Unified Modeling Language

82 Oggetti attivi Sono oggetti che possiedono un proprio thread. {local} job CurrentJob : TransferJob job : FactoryScheduler 1: start(job) A2,B2 / 2: completed(job) : Factory JobManager : FactoryManager 1/B1: start(job) : Robot B2: completed(job) A2: completed(job) : Oven 1/A1: start(job) Unified Modeling Language

83 Sequence e collaboration diagram: confronto I Sequence Diagram mettono più enfasi sulla sequenza temporale delle operazioni indicano esplicitamente la vita degli oggetti I collaboration diagram indicano la connessione tra oggetti NB: non proprio statica: ad es. tra Stock e ReorderItem la relazione si crea perché Stock crea una nuova istanza di ReorderItem. Unified Modeling Language

84 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language

85 State diagram Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte. I diagrammi di stato danno un'astrazione di stati, eventi e transizioni Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli eventi comuni). Unified Modeling Language

86 State diagram Similitudini Automi a Stati Finiti Il modello dinamico è una estensione degli automi a stati finiti. Unifica il modello "output nelle transizioni" e "output negli stati (macchine di Moore e di Mealy). Introduce una nidificazione negli stati. Reti di Petri Permette di modellare la concorrenza. Permette di modellare gli scambi di eventi fra molti automi concorrenti. Terminologia (e concetti) da D. Harel (Statecharts) Unified Modeling Language

87 Concetti fondamentali: stati E' l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo istante Ci interessa lo stato astratto esempio: motore acceso/spento (non ci interessa il numero di giri/min.) può corrispondere a diverse - anche infinite - combinazioni di valori degli attributi Lo stato influenza il comportamento L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova. Esempio: risultato pop dipende dallo stato della pila (vuota o no) Unified Modeling Language

88 Concetti fondamentali: stati Il comportamento quantitativo è influenzato dal valore degli attributi, dei link e dei parametri delle operazioni Uno stato perdura nel tempo finché un evento non fa cambiare stato all oggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo) Unified Modeling Language

89 Concetti fondamentali: eventi Evento = stimolo esterno E' istantaneo il tempo è un attributo implicito Se due eventi sono legati da relazione causa/effetto sono ordinati nel tempo. Può causare nell'oggetto destinatario un cambio di valore, di stato o la produzione di ulteriori eventi. Si intende che un evento ha una individualità ben definita raggruppabili in classi di eventi (con attributi caratterizzanti) La risposta ad uno stimolo dipende dallo stato, e può implicare una transizione di stato esempio del versamento su CC Unified Modeling Language

90 Esempi Classe di eventi Attributi della classe di eventi ParteVoloAereo(Compagnia, NumeroVolo, Città) Città) MouseButtonDown(Posizione, StatoBottoni) Classi di eventi e relativi attributi Classe dell'evento Valori dell'evento ParteVoloAereo(Alitalia, AZ521, AZ521, Milano) Milano) MouseButtonDown(<124,234>, 0xFF) 0xFF) ParteVoloAereo(Quantas, Q1245, Q1245, Sydney) ParteVoloAereo(TWA, TW874, Roma) Roma) MouseButtonDown(<078,230>, 0xA0) 0xA0) ParteVoloAereo(Alitalia, AZ520, AZ520, Roma) Roma) MouseButtonDown(<120,007>, 0x0F) 0x0F) Eventi e relativi valori Unified Modeling Language

91 Generalizzazione degli eventi Gli eventi sono organizzabili in una gerarchia di generalizzazione, lungo la quale gli attributi vengono ereditati La gerarchia consente di rappresentare diversi livelli di astrazione ad esempio, alcuni stati trattano tutti gli user input allo stesso modo, altri fanno differenza tra input da tastiera o da mouse. «signal» mouse click location «signal» IOevent time «signal» user input device «signal» keyboard character character Unified Modeling Language

92 Identificare gli stati Per ciascun oggetto occorre identificare tutti gli stati in cui può trovarsi Suggerimenti Trascurare gli attributi ininfluenti Alcuni attributi non modificano in modo qualitativo il comportamento di un oggetto, ma al più i valori degli eventi che l'oggetto produce. Individuare le condizioni limite Trovare tutti i confini e i limiti dello stato Definire un corretto livello di astrazione Granularità di stati ed eventi Per un sistema di prenotazione la partenza di un aereo è un evento, ma per il software di controllo dell'aereo sono centinaia di eventi distinti. Unified Modeling Language

93 Descrizione degli stati Si può usare un linguaggio strutturato semi-formale per documentare gli stati Stato: Stato: LaSvegliaStaSquillando LaSvegliaStaSquillando Descrizione: Descrizione: il il cicalino cicalino trilla trilla una una volta volta al al secondo secondo per per indicare indicare che che è è stato stato reggiunto reggiunto l'orario l'orario impostato. impostato. Sequeza Sequeza di di eventi eventi che che determina determina lo lo stato: stato: ImpostaSveglia(<tempo>) ImpostaSveglia(<tempo>) Qualunque Qualunque sequenza sequenza di di eventi eventi escuso escuso DisabilitaSveglia DisabilitaSveglia TempoCorrente TempoCorrente = OrarioSveglia OrarioSveglia Condizioni Condizioni che che caratterizzano caratterizzano lo lo stato stato Allarme Allarme = on, on, OrarioSveglia OrarioSveglia < TempoCorrente TempoCorrente < OrarioSveglia+20", OrarioSveglia+20", nessun nessun bottone bottone premuto premuto da da OrarioSveglia OrarioSveglia in in poi poi Eventi Eventi accetati accetati nello nello stato stato Evento Evento Azione Azione Stato Stato seguente seguente TempoCorrente TempoCorrente = OrarioSveglia+20" OrarioSveglia+20" ResetSveglia ResetSveglia normale normale Bottone(<qualunque>) Bottone(<qualunque>) ResetSveglia ResetSveglia normale normale Unified Modeling Language

94 Lo scenario Uno scenario è una sequenza di eventi occorsi durante una specifica esecuzione del sistema. Dà un idea dell ordine degli eventi talune coppie indicano un ordinamento necessario, altre un ordine casuale Il Il chiamante alza alza la la cornetta Inizia Inizia il il tono tono pronto pronto Il Il chiamante compone uno uno Smette Smette il il tono tono pronto pronto Il Il chiamante compone quattro quattro Il Il chiamante compone quattro quattro Il Il chiamante compone uno uno Il Il chiamante compone uno uno Il Il telefono chiamato inizia inizia a squillare Inizia Inizia il il tono tono di di libero libero Il Il telefono chiamato viene viene sganciato Il Il telefono chiamato smette smette di di squillare Smette Smette il il tono tono di di libero libero Unified Modeling Language

95 Il tracciato degli eventi E' il sequence diagram che lega oggetti ed eventi di uno scenario Lo stesso oggetto può inviare più eventi consecutivi senza ricevere eventi in mezzo Chiamante Linea Ricevente Sgancia InizioTonoPronto Compone(1) FineTonoPronto Compone(4) Compone(4) Compone(1) Compone(1) InizioTonoLibero FineTonoLibero AperturaConnessione Aggancia ChiusuraConnessione InizioSquilli Sgancia FineSquil AperturaConnessione li ChiusuraConnessione Aggancia Lo stesso oggetto può inviare più eventi simultanei Unified Modeling Language

96 Ricavare il diagramma degli stati Una collezione sufficientemente ricca di sequence diagram descrive tutte le possibili evoluzioni dell oggetto considerato il fatto di poterle descrivere tutte deriva dalla capacità di astrazione Ad esempio, in uno scenario il chiamante riaggancia per primo, in un altro scenario il ricevente riaggancia: occorre rappresentare la reazione dell oggetto ad entrambi questi eventi. Unified Modeling Language

97 Diagramma degli stati Chiamante.Aggancia Inattivo Chiamante.Aggancia Connesso Tono Occupato Tono Pronto Compone(n) Compos. Numero Occupato Ricevente.Sgancia Chiamante.Sgancia T Compone(n) NumValido ProntoA Connettere Instradato Tono Libero T Tono TimeOut NumNonValido Messaggio Vocale FineMessaggio Unified Modeling Language

98 Stati iniziali e finali Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o finali. Inizio AlBianco Muovere Matto or Abbandono Stallo or Accordo VinceIlNero Mossa Bianca Mossa Nera Stallo or Accordo Patta AlNero Muovere Matto or Abbandono VinceIlBianco Unified Modeling Language

99 Condizioni Sono funzioni booleane sui valori degli oggetti. Sono valide in un intervallo di tempo Sono utili come guardie delle transizioni di stato (non basta l'evento, deve essere verificata la condizione). Evento Condizione Pronto Verde [incrocio.stato=libero] InCorsa Unified Modeling Language

100 Operazioni Durante la loro vita gli oggetti eseguono operazioni. associate allo stato o alle transizioni Le attività hanno una durata continue sequenziali Le azioni sono istantanee Unified Modeling Language

101 Operazioni Azioni Sono operazioni che hanno durata istantanea (rispetto alla granularità del tempo). Tipicamente produzione di eventi. Sono associate alle transizioni di stato oppure all'ingresso o all'uscita da uno stato. Attività Sono operazioni con durata significativa. Sono associate ad uno stato Continue o sequenziali Transizioni automatiche Se uno stato ha una attività associata e una freccia senza eventi esce da questo, la freccia indica la transizione svolta automaticamente al completamento della attività. Unified Modeling Language

102 Notazione generale In caso di ricezione dell'evento1 nello stato A viene eseguito azione3 senza cambio di stato (e quindi senza azioni di entry ed exit) Transizione automatica (evento scatenante fine della attività1) StatoA attributo1: tipo1 = val.iniziale attributo2: tipo2 = val.iniziale do: attività1 entry / azione1 exit / azione2 event1 / azione3 event2 / azione4 Transizione causata dall'evento evento3 sotto condizione condizione1. Vengono eseguite azione2 e azione5 event3 [condizione1] / azione5 event4 [condizione2] / azione6 Pseudo transizione causata dall'evento evento4 nell'ordine vengono eseguiti: azione2, azione6, azione1 Unified Modeling Language

103 Azioni consistenti nell'invio di eventi Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto. esempio: transazione tra stati di un oggetto Window No object selected right-mouse-down(location) [location in window] / object:=pick-object(location); send object.highlight() One object selected invio di messaggio a object (send è opzionale) Unified Modeling Language

104 Invio di eventi Gli eventi possono avere attributi Il destinatario può essere unico o un intero set di oggetti. Tutti gli oggetti riceventi che riconoscono l'evento possono accettarlo e reagire in parallelo. Attenzione alle corse critiche Unified Modeling Language

105 Invio di eventi: notazione grafica Il segnale accende o spegne Il VCR a seconda dello stato corrente power button /send VCR.togglePower power button /send television.togglepower Unified Modeling Language

106 Problemi dei diagrammi a stati piatti Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del problema. Ad esempio, il numero di collegamenti possibili tra stati è quadratico nel numero di stati. Soluzione: diagrammi strutturati la strutturazione favorisce la descrizione sintetica di sistemi complessi L'attività corrispondente ad uno stato può essere espansa in un diagramma a stati di più basso livello, dove ogni stato rappresenta una fase dell'attività. Generalizzazione (specializzazione delle attività, gerarchie di ereditarietà,...) Aggregazione (stati concorrenti) Unified Modeling Language

107 Diagrammi a stati strutturati Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno stato più generale, in un qualunque sotto-stato. I sottostati ereditano le transizioni dei loro superstati (a meno di overriding) Questa transizione, risposta all'evento ferma, viene ereditata da tutti i sottostati di MarciaAvanti Folle Cambio Automatico ferma accelera levaf levan levar levan RetroMarcia MarciaAvanti accelera Prima Seconda Terza decelera decelera Unified Modeling Language

108 Diagramma di stato: esempio (1) Unified Modeling Language

109 Diagramma di stato: esempio (2) Login Read name entry: name prompt Name read Read password entry: password prompt Incorrect name or password Password read Verification Name and password OK Connection Unified Modeling Language

110 Aggregazione e concorrenza Un modello descrive un insieme di oggetti concorrenti, ciascuno col suo stato e col suo diagramma a stati. Lo stato dell'intero sistema è dato dal complesso degli stati degli oggetti componenti (il cui numero può anche cambiare dinamicamente). Il diagrammi a stati di un oggetto complesso è l'aggregazione dei diagrammi di ciascun componente. L'aggregazione è la "and-relationship": lo stato complessivo (aggregato) è dato dall unione degli stati dei vari diagrammi. Unified Modeling Language

111 Concorrenza in oggetti compositi Oggetti diversi hanno dinamica intrinsecamente concorrente si ha concorrenza anche in un oggetto composto. Accendino Serbatoio Fornello Vuoto carica [gas = 0] Pieno [gas > 0] Serbatoio Fornello Chiuso apri chiudi Aperto scintilla Acceso Unified Modeling Language

112 Aggregazione e concorrenza Interazioni tra oggetti Gli stati dei componenti possono interagire (la guardia che regola le transizioni di un oggetto dipende dallo stato di un altro oggetto). carica Vuoto [gas = 0] Fornello apri Chiuso chiudi Serbatoio Pieno [gas > 0] Aperto scintilla Acceso [Serbatoio.stato == Pieno] Unified Modeling Language

113 Sottostati concorrenti Unified Modeling Language

114 Concorrenza di due attività Distratto Naturalmente Attento do: appunti noia do: sbadiglia do: gratta richiamo richiamo Forzatamente Attento do: ghirigori Transazione complessa Sincronizzazione Unified Modeling Language

115 Suggerimenti Rappresentare solo classi con dinamica significativa Usare "scenari" e "tracce degli eventi" Solo attributi ed eventi rilevanti Livello di astrazione adeguato granularità di eventi e stati adatta all applicazione Distinguere tra attività ed azioni Usare diagrammi strutturati dove appropriato Verificare la consistenza incrociata attenzione agli eventi condivisi Diagrammi delle sottoclassi indipendenti da quelli delle superclassi Occhio alle corse critiche Unified Modeling Language

116 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language

117 Activity Graph e Activity Diagram Sono dei casi speciali di macchine a stati, in cui tutti gli stati (o quasi) contengono un azione o una attività tutte le transizioni (o quasi) sono causate dal completamento delle azioni/attività negli stati Un activity graph è associato ad una classe, o all'implementazione di un operazione, o ad uno use case. Un Activity Diagram è un diagramma contenente un activity graph Lo scopo deglio activity graph è di evidenziare l evoluzione guidata dall elaborazione interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram). Unified Modeling Language

118 Un Activity Graph Unified Modeling Language

119 Swimlanes (corsie) Indicano come sono distribuite le responsabilità delle diverse operazioni in una classe (unità organizzative) ogni corsia può essere implementata da uno o più oggetti Unified Modeling Language

120 Relazioni di flusso azioni-oggetti oggetti Le attività operano attraverso e su oggetti: un oggetto (o più d uno) ha la responsabilità dell azione altri oggetti forniscono dati per l azione o ne sono modificati Unified Modeling Language

121 Relazioni di flusso azioni-oggetti oggetti oggetti responsabili di azioni oggetto in ingresso o in uscita da un azione azioni stati degli oggetti Unified Modeling Language

122 Stereotipi opzionali Rappresentano esplicitamente l invio e la ricezione di segnali eventi differiti Unified Modeling Language

123 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language

124 Implementation diagram Component diagram mostrano la struttura del codice Deployment diagram mostrano la struttura del sistema run-time Unified Modeling Language

125 Componenti Unified Modeling Language

126 Component diagram Mostra le dipendenze tra componenti software sorgenti, binari, eseguibili esistenti a compile-time, a link-time, a run-time Gli elementi dei component diagram sono tipi di componenti le istanze si vedono nei deployment diagram Unified Modeling Language

127 Component diagram dipendenze Unified Modeling Language

128 Deployment diagram Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei componenti, processi e oggetti che vi vivono ). Istanze di componenti software rappresentano le attivazioni a run-time delle unità di codice. Componenti che non esistono a run-time non appaiono in questi diagrammi. Unified Modeling Language

129 Deployment diagram Un grafo nodi = risorsa computazionale possono contenere istanze di componenti e/o oggetti archi = comunicazione tipicamente indicano una relazione di utilizzo Unified Modeling Language

130 Migrazione di oggetti tra nodi Unified Modeling Language

131 Indice Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto Unified Modeling Language