Unified Modeling Language UML: diagrammi di classe e modelli strutturali

Unified Modeling Language

UML

Diagrammi di classe

Modelli di sistema e UML Modelli strutturali

I modelli strutturali del software mostrano l'organizzazione di un sistema in funzione dei suoi componenti e le relazioni fra questi componenti.

0 I modelli strutturali possono essere statici, se rappresentano l'organizzazione del progetto del sistema, o dinamici, se rappresentano l'organizzazione del sistema durante la sua esecuzione. I diagrammi di classe possono essere utilizzati per modellare la struttura statica delle classi degli oggetti in un sistema software.

Modelli di sistema e UML Diagrammi di classe

I diagrammi di classe si usano quando si sviluppa un modello di sistema orientato agli oggetti per mostrare le classi di un sistema e le loro associazioni. Una classe di oggetti può essere pensata come una definizione generale di un tipo di oggetti del sistema. Un'associazione è un collegamento tra classi che indica che esiste qualche relazione tra queste classi.

Modelli di sistema e UML Diagrammi di classe: notazione classe (a)

Una classe è rappresentata da un rettangolo diviso in 3 sottosezioni: nome, attributi e operazioni

• Solo il nome è obbligatorio ed è posto in cima al rettangolo
• gli attributi della classe sono nella parte centrale; sono inclusi i nomi degli attributi e, facoltativamente, i loro tipi
• le operazioni (chiamate metodi in Java o in altri linguaggi di programma zione orientata agli oggetti) associate alla classe di oggetti sono indicate nella parte inferiore del rettangolo.

Modelli di sistema e UML Diagrammi di classe: notazione classe (b)

Versione completa Versione ridotta Nome Finestra Finestra Attributi + .. () Operazioni

Modelli di sistema e UML Diagrammi di classe: dettagli notazione

Molteplicità Visibilità Finestra - privato # protetto + pubblico -dimensioni[2] : int = (100,100) #visibile ~ package : bool = false +Finestra(in | : int, in h : int) Valori iniziali +Nascondi() +Mostra() Ambito di classe (metodi static e costruttori) Parametri Ambito di istanza

Modelli di sistema e UML Attributi

Gli attributi hanno una struttura di questo tipo: visibilità nome molteplicità: tipo = valoreIniziale (opzionale) (obbligatorio) (opzionale)

0 La visibilità può essere:

• private (-)
• protected (#)
• public (+)
• package (~)

La molteplicità si indica con la notazione tipica degli array: [n] Un'eventuale sottolineatura indica che l'attributo appartiene ad un ambito di classe (static) e non di istanza E' possibile indicare un valore iniziale

Modelli di sistema e UML Operazioni

Le operazioni sono i metodi della classe e hanno una struttura del tipo: visibilità nome(nomeParam: tipoParam, ... ) : tipoRestituito Anche per le operazioni solo il nome è obbligatorio

1 Le visibilità sono uguali a quelle degli attributi La sottolineatura indica metodi static e costruttori I parametri possono essere preceduti da un modificatore che indica la "direzione" di uso:

• in: parametro in ingresso (per valore)
• out: parametro di uscita (serve per restituire un risultato: per riferimento)
• inout: parametro di ingresso e uscita (per riferimento)

Modelli di sistema e UML Classi e metodi astratti

Le entità astratte vengono rappresentate in corsivo: questo vale sia per le classi che per i metodi Employee -name : String +getName() : String +calcPay() : double abstract class Employee { public getName () { return name; } public abstract double calcPay () ; private String name; }

Modelli di sistema e UML Interfacce

Le interfacce hanno rappresentazione simile a quella delle classi Vengono identificate tramite lo stereotipo «interface» Manca la sezione degli attributi I metodi sono in corsivo (astratti) Esiste anche una rappresentazione grafica compatta costituita da un cerchietto e una linea «interface» Command Versione estesa +dolt() interface Command { void doIt (); Command Versione compatta }

Modelli di sistema e UML Relazioni

In UML una relazione è definita come: "Una connessione semanticamente significativa tra elementi di modellazione" Nei diagrammi delle classi troviamo 3 tipi di relazioni:

• Dipendenze (relazioni d'uso)
• Associazioni (associazione semplice, aggregazione, composizione)
• Generalizzazioni e realizzazioni (ereditarietà fra classi e implementazione di interfacce)

Modelli di sistema e UML Dipendenze

"Una dipendenza è una relazione tra due elementi dove un cambiamento ad uno di essi (fornitore) può influenzare o fornire informazioni necessarie all'altro (cliente)" Il tipo più comune è la relazione d'uso che esprime un rapporto client- server fra due classi o fra una classe e un'interfaccia

0 Si rappresenta con una linea tratteggiata e con lo stereotipo «uses» (che di solito però viene omesso) «uses»

Modelli di sistema e UML Relazione d'uso tra classi

Una relazione d'uso fra due classi si ha nei seguenti 3 casi:

• Un metodo di Class1 ha un parametro di tipo Class2
• Un metodo di Class1 restituisce un valore di tipo Class2
• Un metodo di Class1 usa un oggetto di tipo Class2 ma non come attributo.

O L'esempio più comune del terzo caso si ha quando in un metodo di Class1 si dichiara una variabile locale di tipo Class2 Class1 Class2

Modelli di sistema e UML Relazione d'uso fra una classe e un'interfaccia

Nel caso di una classe e di un'interfaccia la relazione d'uso ha un significato più generico Indica semplicemente che la classe invoca uno o più metodi definiti nell'interfaccia

0 Talvolta si parla di relazione client-of «interface» Interface1 Class3

Modelli di sistema e UML Associazioni

Un'associazione è una relazione fra classi Può essere caratterizzata da:

• Nome
• Nomi dei ruoli
• Molteplicità
• Navigabilità

ruoli navigabilità (Verso) nome Azienda -Datore impiega -Impiegato Persona 1 molteplicità

Modelli di sistema e UML Nomi e ruoli

Un'associazione può essere indicata con un nome o semplicemente con i nomi dei ruoli Sia nome che ruoli sono facoltativi . La freccetta accanto al nome indica la direzione di lettura del nome:

• Il termine "impiega" ha senso se si legge l'associazione da sinistra a destra
• Si potrebbe invertire la direzione di lettura cambiando anche il nome dell'associazione in "è impiegato"

Modelli di sistema e UML Molteplicità

La molteplicità è un vincolo la cui funzione è quella di limitare il numero di oggetti di una classe che possono partecipare ad un'associazione in un dato istante Un'azienda impiega molte persone Azienda Persona 1 Ogni persona lavora per una sola azienda

Modelli di sistema e UML Espressioni di molteplicità

La molteplicità può essere espressa:

• Con un solo simbolo (0 1 *)
• Con un intervallo (0 .. 2 1 ..* )
• Con una lista di simboli o intervalli separati da virgole (0 .. 3,5,6 .. 9)

Esempi:

• 0 .. 1 Zero o uno
• 1 Esattamente uno
• 0 ..* Zero o più
• * Zero o più
• 1 ..* Uno o più
• 1 .. 6 Da uno a 6
• 1 .. 3,7,19 ..* Da 1 a 3, oppure 7 oppure da 19 in su

Modelli di sistema e UML Esempio di molteplicità

Un'azienda deve avere esattamente sette dipendenti Un dipendente lavora solo per un'azienda e non può essere disoccupato Azienda -datoreLavoro 7 -dipendente 1 Persona 1 -delegato Una persona può essere delegata ad operare su un numero qualunque di conti (anche nessuno) Una persona può essere correntista di un numero qualsiasi di conti correnti (anche nessuno) -correntista 1 ..* ContoCorrente 0 ..* Un conto corrente può avere uno ed un solo correntista 0. * Per ogni conto ci possono essere uno o più delegati

Modelli di sistema e UML Navigabilità

La navigabilità, indicata con una punta di freccia su un lato dell'associazione, indica una direzione nella relazione

0 Specificando la navigabilità si riduce la dipendenza fra le classi: i legami bidirezionali sono critici Associazione Employer Employee class Employer { // ... private Employee itsWorker; } class Employee { private Employer itsBoss; } Associazione navigabile Employee BenefitsPackage class Employee { // ... private BenefitsPackage itsBenefits; } class BenefitsPackage { .. Non c'è un riferimento all' immpiegato }

Modelli di sistema e UML Aggregazione e composizione

Oltre all'associazione semplice esistono altre due relazioni di tipo analogo: l'aggregazione e la composizione Entrambe sono relazioni part-of, in cui un oggetto di una classe diventa parte di un oggetto dell'altra Aggregazione

• Rappresentata come associazione con un rombo bianco vicino alla classe contenitore

Composizione

• Rappresentata come associazione con un rombo nero vicino alla classe contenitore

Modelli di sistema e UML Aggregazione vs Composizione

Aggregazione: è una forma specializzata di associazione in cui tutti gli oggetti hanno il proprio ciclo di vita, con oggetti che sono proprietari di altri oggetti.

• Esempio: Dipartimento e insegnante. Un singolo insegnante può appartenere a più dipartimenti e un dipartimento ha più insegnanti, ma se cancelliamo l'oggetto dipartimento, l'oggetto insegnante non sarà distrutto

Composizione: è una forma specializzata di Aggregazione. L'oggetto figlio non ha il suo ciclo di vita e se l'oggetto genitore viene eliminato, anche tutti gli oggetti figli vengono eliminati. Gli oggetti figli non possono appartenere ad un altro oggetto genitore

• Esempio: Università e dipartimento. L'università ha più dipartimenti e un dipartimento può appartenere ad una sola università. Se eliminiamo l'università eliminiamo anche i dipartimenti.

Modelli di sistema e UML Esempio su aggregazione e composizione

Un esempio classico per comprendere la differenza è quello dell'automobile: sia il telaio che le gomme sono parti dell'auto Ma la relazione con il telaio è più stretta: il telaio può appartenere ad una sola auto e nasce e muore assieme all'auto Automobile Aggregazione Composizione 1 1 4 1 Gomma Telaio

Modelli di sistema e UML Esempio su aggregazione e composizione - 2

Vediamo l'implementazione della classe Automobile: class Automobile { private Gomma gomme []; private Telaio telaio; public Automobile () { telaio = new Telaio () ; . } public Gomma getGomma (int n) { return Gomme [n] ; } public void setGomma (Gomma g; int n) { gomme [n] = g; } }

Modelli di sistema e UML