Elementi UMLI diagrammi di caso d'uso descrivono le relazioni e le dipendenze tra un gruppo di Casi d'uso e gli attori partecipanti al processo.
È importante notare che i diagrammi di caso d'uso non sono adatti a rappresentare la progettazione, e non possono descrivere le parti interne di un sistema. I diagrammi di caso d'uso servono a facilitare la comunicazione con gli utenti futuri del sistema e con il cliente, e sono particolarmente utili a determinare le funzionalità necessarie che il sistema deve avere. I diagrammi di caso d'uso dicono cosa deve fare il sistema, ma non specificano come si deve fare (e non possono).
Umbrello UML Modeller che mostra un diagramma di caso d'uso
Un Caso d'uso descrive, dal punto di vista degli attori, un gruppo di attività in un sistema che produce un risultato concreto e tangibile.
I casi d'uso sono descrizioni delle interazioni tipiche tra gli utenti di un sistema e il sistema stesso. Rappresentano l'interfaccia esterna del sistema, e specificano un modulo di requisiti di cosa il sistema deve fare (ricorda, solo cosa, non come).
Lavorando con i casi d'uso, è importante ricordare alcune semplici regole:
Ogni caso d'uso è relativo ad almeno un attore
Ogni caso d'uso ha un iniziatore (cioè un attore)
Ogni caso d'uso porta a un risultato rilevante (un risultato con «valore di business»)
I casi d'uso possono anche avere relazioni con altri casi d'uso. I tre tipi più comuni di relazioni tra casi d'uso sono:
<<inclusione>> che specifica che un caso d'uso avviene all'interno di un altro caso d'uso
<<estensione>> che specifica che in certe situazioni, o a un certo punto (chiamato punto di estensione) un caso d'uso sarà esteso da un altro.
La generalizzazione specifica che un caso d'uso eredita le caratteristiche del «sovra»caso d'uso, e può sostituirne alcune o aggiungerne nuove in un modo simile all'ereditarietà tra classi.
Un attore è un'entità esterna (fuori dal sistema) che interagisce con il sistema partecipando a (e spesso iniziando) un caso d'uso. Gli attori possono essere persone reali (per esempio utenti del sistema), altri sistemi o eventi esterni.
Gli attori non rappresentano le persone fisiche o i sistemi, ma il loro ruolo. Ciò significa che quando una persona interagisce con il sistema in modi diversi (assumendo ruoli diversi) sarà rappresentata da diversi attori. Per esempio una persona che fornisce supporto per telefono e immette ordini dal cliente nel sistema sarebbe rappresentato da un attore «Squadra di supporto» e un attore «Rappresentante di vendita»
I diagrammi di classe mostrano le diverse classi che costituiscono un sistema e come si relazionano una all'altra. I diagrammi di classe sono detti essere diagrammi «statici» perché mostrano le classi, insieme ai loro metodi e attributi oltre alle relazioni statiche tra loro: quali classi «sanno» di quali classi o quali classi «fanno parte» di un'altra classe, ma non mostrano le chiamate ai metodi tra di loro.
Umbrello UML Modeller che mostra un diagramma di classe
Una classe definisce gli attributi e i metodi di un insieme di oggetti. Tutti gli oggetti di questa classe (istanze di questa classe) condividono lo stesso comportamento, e hanno lo stesso insieme di attributi (ogni oggetto ha il suo insieme). A volte il termine «Tipo» è usato invece di classe, ma è importante ricordare che questi due non sono la stessa cosa, e Tipo è un termine più generale.
In UML le classi sono rappresentate da rettangoli con il nome della classe, e possono anche mostrare gli attributi e le operazioni della classe in due altri «scompartimenti» all'interno del rettangolo.
Rappresentazione visiva di una classe in UML
In UML gli attributi sono mostrati con almeno il loro nome, e possono mostrare anche il loro tipo, il valore iniziale e altre proprietà. Gli attributi possono anche essere mostrati con la loro visibilità:
+sta per attributi pubblici#sta per attributi protetti-sta per attributi privati
Anche le operazioni (metodi) sono mostrate con almeno il loro nome, e possono mostrare anche i loro parametri e i tipi restituiti. Le operazioni possono, come gli attributi, mostrare la loro visibilità:
+sta per operazioni pubbliche#sta per operazioni protette-sta per operazioni private
Le classi possono avere modelli, un valore che è usato per una classe o untipo non specificato. Il tipo di modello è specificato quando viene iniziata una classe (cioè cioè viene creato un oggetto). I modelli esistono nel C++ moderno e saranno introdotti in Java 1.5 dove saranno chiamati Generics.
Le classi possono relazionarsi (essere associate) una con l'altra in diversi modi:
L'ereditarietà è uno dei concetti fondamentali della programmazione a oggetti, in cui una classe «acquisisce» tutti gli attributi e le operazioni della classe da cui eredita, e può sostituire o modificare alcuni di loro, oltre ad aggiungere altri attributi e operazioni proprie.
In UML, un'associazione di Generalizzazione tra due classi le mette in una gerarchia rappresentante il concetto di ereditarietà di una classe derivata da una classe di base. In UML le generalizzazioni sono rappresentate da una linea che connette le due classi, con una freccia sul lato della classe di base.
Rappresentazione visiva di una generalizzazione in UML
Un'associazione rappresenta una relazione tra classi, e dà la semantica e la struttura comuni a molti tipi di «connessioni» tra oggetti.
Le associazioni sono i meccanismi che permettono agli oggetti di comunicare tra loro. Descrivono la connessione tra diverse classi (la connessione tra gli oggetti reali è chiamata una connessione tra oggetti, o collegamento).
Le associazioni possono avere un ruolo che specifica lo scopo dell'associazione e può essere uni- o bidirezionale (indica se i due oggetti che partecipano alla relazione possono mandare messaggi all'altro, o se solo uno di loro sa dell'altro). Ogni parte dell'associazione ha un valore di molteplicità, che detta quanti oggetti su questo lato dell'associazione possono relazionarsi a un oggetto sull'altro lato.
In UML le associazioni sono rappresentate come linee che connettono le classi che partecipano alla relazione, e possono anche mostrare il ruolo e la molteplicità di ciascuno dei partecipanti. La molteplicità è mostrata come un intervallo [minimo..massimo] di valori non negativi, con un asterisco (*) sul lato massimo per rappresentare l'infinito.
Rappresentazione visiva di un'associazione in UML
Le aggregazioni sono un tipo speciale di associazioni nel quale le due classi partecipanti non hanno un rango uguale, ma hanno una relazione «intero-parte». Un'aggregazione descrive come la classe che ha il ruolo dell'intero è composta di (ha) altre classi, che hanno il ruolo di parti. Per le aggregazioni, la classe che fa da intero ha sempre molteplicità di uno.
In UML le aggregazioni sono rappresentate da un'associazione che mostra un rombo sul lato dell'intero.
Rappresentazione visiva di una relazione di aggregazione in UML
Le composizioni sono associazioni che rappresentano aggregazioni molto forti. Ciò vuol dire che anche le composizioni formano relazioni intero-parte, ma la relazione è così forte che la parte non può esistere di per sé. Esistono solo all'interno dell'intero, e se l'intero è distrutto anche le parti muoiono.
In UML le composizioni sono rappresentate da un rombo solido sul lato dell'intero.
I diagrammi di classe possono contenere diversi altri elementi oltre alle classi.
Le interfacce sono classi astratte, che vuol dire che non se ne possono creare istanze direttamente. Possono contenere operazioni ma non attributi. Le classi possono ereditare dalle interfacce (attraverso una associazione di realizzazione) e possono essere create delle istanze di queste classi.
I tipi di dati sono delle primitive tipicamente incorporate in un linguaggio di programmazione. Gli esempi comuni includono gli interi e i booleani. Non possono avere relazioni con le classi, ma le classi possono avere relazioni con loro.
Le enumerazioni sono semplici elenchi di valori. Un esempio tipico è un'enumerazione dei giorni della settimana. Le opzioni di un'enumerazione sono chiamate letterali dell'enumerazione. Come i tipi di dati non possono avere relazioni con le classi, ma le classi possono avere relazioni con loro.
I diagrammi di sequenza mostrano lo scambio di messaggi (cioè la chiamata ai metodi) tra diversi oggetti in una situazione temporale precisa. Gli oggetti sono istanze di classi. I diagrammi di sequenza mettono particolare enfasi sull'ordine e l'ora a cui i messaggi sono inviati agli oggetti.
Nei diagrammi di sequenza gli oggetti sono rappresentati con linee verticali tratteggiate, con il nome dell'oggetto in cima. Anche l'asse temporale è verticale, e aumenta andando in giù, in modo che i messaggi sono inviati da un oggetto all'altro nella forma di frecce con l'operazione e il nome del parametro.
Umbrello UML Modeller che mostra un diagramma di sequenza
I messaggi possono o essere sincroni, il tipo normale di chiamate ai messaggi dove il controllo è passato all'oggetto chiamato fino a quando quel metodo ha finito l'esecuzione, o asincrono, dove il controllo è ripassato direttamente all'oggetto chiamante. I messaggi sincroni hanno un riquadro verticale a lato dell'oggetto chiamato per mostrare il flusso di controllo del programma.
I diagrammi di collaborazione mostrano le interazioni che avvengono tra gli oggetti che partecipano a una situazione specifica. È più o meno la stessa informazione mostrata nei diagrammi di sequenza, ma lì l'enfasi è messa su come le interazioni avvengono nel tempo, mentre i diagrammi di collaborazione mettono in primo piano le relazioni tra gli oggetti e la loro topologia.
Nei diagrammi di collaborazione i messaggi inviati da un oggetto a un altro sono rappresentati da frecce, che mostrano il nome, i parametri e la sequenza del messaggio. I diagrammi di collaborazione sono specialmente adatti a mostrare un particolare flusso o situazione di programma e sono uno dei migliori tipi di diagramma per dimostrare o spiegare rapidamente un processo nella logica del programma.
Umbrello UML Modeller che mostra un diagramma di collaborazione
I diagrammi di stato mostrano i diversi stati di un oggetto durante la sua vita e gli stimoli che gli fatto cambiare stato.
I diagrammi di stato vedono gli oggetti come macchine di stato o automi finiti che possono essere in uno stato di un insieme di stati finiti e che possono cambiare stato con uno stimolo di un insieme finito di stimoli. Per esempio un oggetto di tipo ServerDiRete può essere in uno dei seguenti stati durante la sua vita:
Pronto
In ascolto
Attivo
Fermato
e gli eventi che possono far cambiare stato all'oggetto sono
L'oggetto è creato
L'oggetto riceve il messaggio di ascolto
Un client richiede una connessione sulla rete
Un client termina una richiesta
La richiesta è eseguita e conclusa
L'oggetto riceve un messaggio di fermata
ecc.
Umbrello UML Modeller che mostra un diagramma di stato
Gli stati sono i mattoni del diagramma di stato. Uno stato appartiene a esattamente una classe e rappresenta un riassunto dei valori che gli attributi di una classe possono assumere. Uno stato UML descrive lo stato interno di un oggetto di una classe particolare
Nota che non tutti i cambiamenti negli attributi di un oggetto dovrebbe essere rappresentato da uno stato, ma solo quei cambiamenti che influenzano significativamente il funzionamento dell'oggetto
Ci sono due tipi speciali di stati: Inizio e Fine. Sono speciali perché non ci sono eventi che possono far tornare un oggetto al suo stato di Inizio, allo stesso modo in cui non è possibile riportare un oggetto dal suo stato di Fine una volta che lo raggiunge.
I diagrammi di attività descrivono la sequenza di attività in un sistema con l'aiuto delle attività. I diagrammi di attività sono una forma speciale dei diagrammi di stato, che contengono solo (o per lo più) attività.
Umbrello UML Modeller che mostra un diagramma di attività
I diagrammi di attività sono simili ai diagrammi di flusso procedurali, con la differenza che tutte le attività sono chiaramente connesse a degli oggetti.
I diagrammi di attività sono sempre associati a una classe, un'operazione o un caso d'uso.
I diagrammi di attività supportano attività sequenziali e parallele. L'esecuzione parallela è rappresentata con le icone Separa/Attendi; per le attività in esecuzione in parallelo, non è importante l'ordine in cui sono eseguite (possono essere eseguite allo stesso tempo o una dopo l'altra)
Un'attività è un singolo passo in un processo. Un'attività è uno stato del sistema con attività interna e, almeno, una transizione all'esterno. Le attività possono anche avere più di una transizione all'esterno se hanno più condizioni.
Le attività possono formare gerarchie, vale a dire che un'attività può essere composta di più attività di «dettaglio», nel qual caso le transizioni all'interno e all'esterno dovrebbero corrispondere alle transizioni all'interno e all'esterno del diagramma dei dettagli.
Ci sono alcuni elementi in UML che non hanno una vera e propria semantica per il modello, ma aiutano a chiarificare parti del diagramma. Questi elementi sono
Righe di testo
Note di testo e ancore
Riquadri
Le righe di testo sono utili per aggiungere brevi informazioni testuali a un diagramma. È testo libero e non ha significato per il modello stesso.
Le note sono utili per aggiungere informazioni più dettagliate su un oggetto o una situazione specifica. Hanno il grande vantaggio che le note possono essere ancorate a elementi UML per mostrare che la nota «appartiene» a un oggetto o una situazione specifici.
I riquadri sono rettangoli liberi che possono essere usati per raggruppare insieme degli elementi per rendere i diagrammi più leggibili. Non hanno nessun significato logico nel modello.
I diagrammi dei componenti mostrano i componenti software (tecnologie componenti come KPart, componenti CORBA, Java Beans o solo sezioni del sistema che sono chiaramente distinguibili) e i manufatti di cui sono fatti come file di codice sorgente, librerie di programmazione o tabelle di banche dati relazionali.
I componenti possono avere interfacce (cioè classi astratte con operazioni) che permettono associazioni tra componenti.
I diagrammi di dispiegamento mostrano le istanze dei componenti durante l'esecuzione e le loro associazioni. Includono i nodi, che sono risorse fisiche, tipicamente un computer singolo. Mostrano anche interfacce e oggetti (istanze di classi).
I diagrammi di relazioni tra entità (diagrammi RE) mostrano la progettazione concettuale delle applicazioni di banche dati. Mostrano le varie entità (concetti) nel sistema informativo e le relazioni e i vincoli esistenti tra di loro. Un'estensione dei diagrammi di relazioni tra entità, chiamata «diagrammi di relazioni tra entità estesi» (REE) o «diagrammi di relazioni tra entità migliorati», è usata per incorporare le tecniche di progettazione orientata agli oggetti nei diagrammi RE.
Umbrello UML Modeller che mostra un diagramma di relazioni tra entità
Un'entità è un qualsiasi concetto del mondo reale con un'esistenza indipendente. Può essere un oggetto con forma fisica (per esempio, un computer o un robot) o può essere un oggetto concettuale (come un corso universitario). Ogni entità ha un insieme di attributi che ne descrivono le proprietà.
Nota: non esiste nessuna notazione standard per tracciare i diagrammi RE. Diversi testi su questo tema usano notazioni diverse. I concetti e le notazioni dei diagrammi REE usati in Umbrello sono presi da questo libro: Elmasri R. and Navathe S. (2004). Fundamentals of Database Systems 4th edn. Addison Wesley.
In un diagramma RE, le entità sono rappresentate da rettangoli con il nome dell'entità sopra, e possono anche mostrare gli attributi dell'entità in un altro «scompartimento» all'interno del rettangolo.
Rappresentazione visiva di un'entità in un diagramma RE
Nei diagrammi RE, gli attributi delle entità sono mostrati con il loro nome in uno scompartimento diverso dell'entità a cui appartengono.
I vincoli nei diagrammi RE specificano le restrizioni sui dati nello schema informativo.
Ci sono quattro tipi di vincoli supportati da Umbrello:
Chiave primaria: l'insieme di attributi dichiarati come chiave primaria è unico per l'entità. Ci può essere solo una chiave primari in un'entità e nessuno dei suoi membri può essere nullo.
Chiave univoca: l'insieme di attributi dichiarati come chiave univoca è unico per l'entità. Ci possono essere molti vincoli univoci in un'entità. I loro membri possono essere nulli. Le chiavi univoche e primarie identificano univocamente una riga in una tabella (entità).
Chiave esterna: una chiave esterna è un vincolo referenziale tra due tabelle. La chiave esterna identifica una colonna o un insieme di colonne in una tabella (referente) che si riferisce a una colonna o insieme di colonne in un'altra tabella (referenziata). Le colonne nella tabella referenziata devono formare una chiave primaria o univoca.
Vincolo di controllo: un vincolo di controllo (noto anche come vincolo di controllo della tabella) è una condizione che definisce i dati validi quando si aggiunge o si aggiorna una voce di una tabella in una banca dati relazionale. Un vincolo di controllo viene applicato a ogni riga nella tabella. Il vincolo deve essere un predicato. Può riferirsi a una sola o a più colonne della tabella.
Esempio: prezzo >= 0
La specializzazione è un modo di formare nuove entità usando entità che sono già state definite. Le nuove entità, note come entità derivate, sostituiscono (o ereditano) gli attributi delle entità preesistenti, che sono dette entità di base. Ciò è inteso per riutilizzare i dati esistenti con poche o nessuna modifica.
In Umbrello, si possono definire le specializzazioni di «Scollegamento» e «Sovrapposizione».
La specializzazione disgiunta specifica che le sottoclassi della specializzazione devono essere disgiunte. Ciò significa che un'entità può fare parte di al più una delle entità derivate dalla specializzazione.
Rappresentazione visiva della specializzazione disgiunta in un diagramma REE
Quando le entità derivate non sono vincolate ad essere disgiunte, il loro insieme di entità è detto essere una specializzazione sovrapposta. Ciò significa che la stessa entità, nel mondo reale, può fare parte di più di una entità derivata dalla specializzazione.
Rappresentazione visiva della specializzazione sovrapposta in un diagramma REE
Un'entità derivata è detta essere una categoria quando rappresenta una raccolta di oggetti costituente un sottoinsieme dell'unione dei tipi di entità distinti. Una categoria è modellata quando serve una relazione singola tra superclasse e sottoclasse con più di una superclasse, dove le superclassi rappresentano diversi tipi di entità (in modo simile all'ereditarietà multipla nella programmazione ad oggetti).
Rappresentazione visiva di una categoria in un diagramma REE