# Fondamenti di &UML;

## Informazioni su &UML;

Questo capitolo ti darà una rapida panoramica dei fondamenti di &UML;. Tieni presente che questo non è un corso completo di &UML;, ma piuttosto una breve introduzione a &UML;, che può essere letta come un corso di &UML;. Se vuoi saperne di più sul Linguaggio di Modellazione Unificato, o in generale sull'analisi e la progettazione del software, riferisciti a uno dei molti libri disponibili sull'argomento. Ci sono anche molti corsi su Internet che puoi usare come punto di partenza.

Il Linguaggio di Modellazione Unificato (&UML;) è un linguaggio o notazione di diagrammi per specificare, visualizzare e documentare modelli di sistemi di software a oggetti. &UML; non è un metodo di sviluppo, cioè non ti dice cosa fare prima e dopo o come progettare il tuo sistema, ma ti aiuta a visualizzare il tuo progetto e a comunicare con gli altri. &UML; è controllato dal Gruppo di Gestione Oggetti (OMG) ed è lo standard industriale per descrivere graficamente il software.

&UML; è progettato per la progettazione di software a oggetti, e ha un uso limitato per altri paradigmi di programmazione.

&UML; si compone di molti elementi di modelli che rappresentano le diverse parti di un sistema software. Gli elementi &UML; sono usati per creare diagrammi, che rappresentano una certa parte, o punto di vista del sistema. &umbrello; supporta i seguenti tipi di diagrammi:

- I diagrammi di caso d'uso mostrano gli attori (persone o altri utenti del sistema), i casi d'uso (gli scenari di quando usano il sistema), e le loro relazioni

- I diagrammi di classe mostrano le classi e le relazioni tra loro

- I diagrammi di sequenza mostrano gli oggetti e una sequenza di chiamate a metodi che essi fanno ad altri oggetti.

- I diagrammi di collaborazione mostrano gli oggetti e le loro relazioni, ponendo l'attenzione sugli oggetti che partecipano nello scambio di messaggi

- I diagrammi di stato mostrano gli stati, i cambi di stato e gli eventi in un oggetto o in una parte del sistema

- I diagrammi di attività mostrano le attività e i cambiamenti da un'attività all'altra con gli eventi che accadono in qualche parte del sistema

- I diagrammi dei componenti mostrano i componenti della programmazione di alto livello (come KPart o Java Beans).

- I diagrammi di dispiegamento mostrano le istanze dei componenti e le loro relazioni.

- I diagrammi di relazioni tra entità mostrano i dati con le loro relazioni e vincoli.

## Elementi &UML;

### Diagramma di caso d'uso

I 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).

Un esempio di diagramma di caso d'uso. &umbrello; che mostra un diagramma di caso d'uso

&umbrello; che mostra un diagramma di caso d'uso

#### 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 (&ie; 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 sovracaso d'uso, e può sostituirne alcune o aggiungerne nuove in un modo simile all'ereditarietà tra classi.

#### Attore

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

#### Descrizione di caso d'uso

Le descrizioni di caso d'uso sono racconti testuali del caso d'uso. Prendono normalmente la forma di una nota o di un documento che è in qualche modo collegato al caso d'uso, e ne spiega i processi o le attività.

### Diagramma di classe

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.

Un esempio di diagramma di classe &umbrello; che mostra un diagramma di classe

&umbrello; che mostra un diagramma di classe

#### 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.

Una classe in &UML; Rappresentazione visiva di una classe in &UML;

Rappresentazione visiva di una classe in &UML;

##### Attributi

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

##### Operazioni

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

##### Modelli

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 (&ie; cioè viene creato un oggetto). I modelli esistono nel C++ moderno e saranno introdotti in Java 1.5 dove saranno chiamati Generics.

#### Associazioni di classi

Le classi possono relazionarsi (essere associate) una con l'altra in diversi modi:

##### Generalizzazione

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. Generalizzazione Rappresentazione visiva di una generalizzazione in &UML;

Rappresentazione visiva di una generalizzazione in &UML;

##### Associazioni

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. Associazione &UML; Rappresentazione visiva di un'associazione in &UML;

Rappresentazione visiva di un'associazione in &UML;

##### Aggregazione

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. Aggregazione Rappresentazione visiva di una relazione di aggregazione in &UML;

Rappresentazione visiva di una relazione di aggregazione in &UML;

##### Composizione

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.

Composizione Rappresentazione visiva di una relazione di composizione in &UML;

#### Altri elementi dei diagrammi di classe

I diagrammi di classe possono contenere diversi altri elementi oltre alle classi.

##### Interfacce

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 questi diagrammi.

##### Tipi di dati

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.

##### Enumerazioni

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.

##### Pacchetti

I pacchetti rappresentano un namespace in un linguaggio di programmazione. In un diagramma sono usati per rappresentare parti di un sistema che contiene più di una classe, forse centinaia di classi.

### Diagrammi di sequenza

I diagrammi di sequenza mostrano lo scambio di messaggi (&ie; 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.

Diagramma di sequenza &umbrello; che mostra un diagramma di sequenza

&umbrello; 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.

### Diagrammi di collaborazione

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.

Collaborazione &umbrello; che mostra un diagramma di collaborazione

&umbrello; che mostra un diagramma di collaborazione

### Diagramma di stato

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.

Diagramma di stato &umbrello; che mostra un diagramma di stato

&umbrello; che mostra un diagramma di stato

#### 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.

### Diagrammi di attività

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à.

Un esempio di diagramma di attività. &umbrello; che mostra un diagramma di attività

&umbrello; 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)

#### Attività

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.

### Elementi ausiliari

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.

### Diagrammi dei componenti

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 (&ie; classi astratte con operazioni) che permettono associazioni tra componenti.

### Diagrammi di dispiegamento

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).

### Diagrammi di relazioni tra entità

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.

Un esempio di diagramma di relazioni tra entità. &umbrello; che mostra un diagramma di relazioni tra entità

&umbrello; che mostra un diagramma di relazioni tra entità

#### 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.

Un'entità in un diagramma RE Rappresentazione visiva di un'entità in un diagramma RE

Rappresentazione visiva di un'entità in un diagramma RE

##### Attributi delle entità

Nei diagrammi RE, gli attributi delle entità sono mostrati con il loro nome in uno scompartimento diverso dell'entità a cui appartengono.

##### Vincoli

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

### Concetti dei diagrammi di relazioni delle entità estesi (REE)

#### Specializzazione

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».

##### Specializzazione disgiunta

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.

Entità partecipanti a una specializzazione disgiunta Rappresentazione visiva della specializzazione disgiunta in un diagramma REE

Rappresentazione visiva della specializzazione disgiunta in un diagramma REE

##### Specializzazione sovrapposta

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.

Entità partecipanti a una specializzazione sovrapposta Rappresentazione visiva della specializzazione sovrapposta in un diagramma REE

Rappresentazione visiva della specializzazione sovrapposta in un diagramma REE

##### Categoria

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).

Entità partecipanti a una relazione di categoria Rappresentazione visiva di una categoria in un diagramma REE

Rappresentazione visiva di una categoria in un diagramma REE