Notazione comune per i diagrammi delle classi...
Gran parte della notazione dei diagrammi delle classi utilizzata più di frequente può essere riassunta in una sola figura:
La maggior parte degli elementi nella figura sono opzionali (per esempio, i modificatori +/- di visibilità, i parametri, le sezioni).
I diagrammi delle classi possono essere utilizzati da un punto di vista concettuale, per visualizzare un modello di dominio. Per la discussione occorre anche un termine univoco che chiarisca quando un diagramma delle classi è invece utilizzato da un punto di vista software o di progetto. A questo scopo, un termine comune nella mdellazione è diagramma delle classi di progetto (DCD: Design Class Diagram). In UP l'insieme di tutti i DCD fa parte del Modello di Progetto. Altre parti del modello di progetto comprendono i diagrammi di interazione e i digrammi dei package di UML.
In UML un classificatore è un "elemento di modello che descrive caratteristiche comportamentali e strutturali". I classificatori sono una generalizzazione di molti degli elementi di UML, comprese le classi, le interfacce, i casi d'uso e gli attori. Nei diagrammi delle classi, i due classificatori più comuni sono le interfacce e le classi.
Attributi delle classi: notazione testuale e linee di associazione...
In UML, le proprietà strutturali di un classificatore comprendono:
- gli attributi della classe (mostrati mediante una notazione testuale)
- le estremità di associazioni della classe (mostrate mediante la notazione delle linee di associazione).
Le proprietà di una classe sono anche chiamate attributi della classe, intendendo con questo termine sia gli attributi mostrati mediante la notazione testuale che le estremità di associazione.
Notazione testuale per gli attributi...
Gli attributi di una classe possono essere mostrati usando notazione testuale:
negli attributi testuali è possibile impostare una visibilità: privata (-) o pubblica (+).
Quando la visibilità non è impostata si ipotizza che gli attributi siano privati.
Le estremità di associazione di una classe vengono mostrate mediante una linea di associazione, usando il seguente stile:
- un freccia di navigabilità rivolta dalla classe sorgente alla classe di destinazione dell'associazione;
- una molteplicità all'estremità vicina alla destinazione, ma non all'estremità vicina alla sorgente;
- un nome di ruolo solo all'estremità vicino alla destinazione, per indicare il nome dell'attributo;
- nessun nome per l'associazione.
Quando si utilizzano i diagrammi delle classi per un modello di dominio, si mostrino i nomi delle associazioni, ma si evitino le frecce di navigazione, poiché un modello di dominio non è da un punto di vista software. Si veda la figura sotto per distinguere bene DCD e modello di dominio.
Un attributo può essere rappresentato in vari modi: mediante notazione testuale, o mediante un'associazione.
Questo dubbio è già stato affrontato nel contesto dello sviluppo di un modello di dominio: tipi di attributo appropriati.
Ribadiamo che un attributo deve utilizzare la notazione testuale se è un tipo di dato come: boolean, date, time, number, character, string, address, color, numero di telefono, numero di previdenza sociale, codice universale di un prodotto, CAP, tipi enumerati.
Mentre occorre utilizzare un'associazione se l'attributo ha un tipo di dato complesso.
Notazione UML per le estremità delle associazioni...
L'estremità di un'associazione può avere una freccia di navigabilità e può anche comprendere un nome di ruolo opzionale per indicare il nome dell'attributo. Può anche mostrare un valore di molteplicità. É anche possibile usare delle stringhe di proprietà come {ordered} o {ordered, List}. {ordered} è una parola chiave definita da UML che implica che gli elementi della collezione sono ordinati. Un'altra parola chiave correlata è {unique}, che implica un insieme di elementi distinti.
{List} indica che l'attributo collezione lineItems sarà implementato con un oggetto che implementa l'interfaccia List.
Simboli per annotazioni: note, commenti, vincoli e corpo dei metodi...
Le note possono essere usate in qualsiasi diagramma UML. Un simbolo nota consente di rappresentare diverse cose, tra cui: una nota, un commento, un vincolo, oppure il corpo di un metodo, ovvero l'implementazione di un'operazione.
L'operazione create nei DCD...
Un messaggio create in un diagramma di interazione viene normalmente interpretato come l'invocazione del costruttore dell'oggetto che si vuole creare. In un DCD un tale messaggio create sarà solitamente rappresentato come la definizione di un costruttore, usando le regole del linguaggio, per esempio con il nome del costruttore uguale al nome della classe.
Operazioni di tipi get e set...
Le operazioni di accesso, come getPrice e setPrice, accedono o modificano gli attributi. Queste operazioni sono spesso escluse (o filtrate) poiché potrebbero essere molte.
Parole chiave...
Una parola chiave in UML è un decoratore testuale per classificare un elemento di un modello. Per esempio «interface» indica che il rettangolo per un classificatore è un'interfaccia anziché una classe normale.
La maggior parte delle parole chiave è mostrata tra virgolette basse («»), ma alcune di esse sono mostrare tra parentesi graffe, come {abstract}.
| Parola chiave | Significato |
|---|---|
| «actor» | il classificatore è un attore |
| «interface» | il classificatore è un interfaccia |
| {abstract} | l'elemento è astratto; non può essere istanziato |
| {ordered} | un insieme di oggetti ha un ordine predefinito |
Generalizzazione, classi astratte, operazioni astratte...
Una generalizzazione è mostrata in UML con una linea continua e una grossa freccia triangolare dalla sottoclasse verso la superclasse.
Dipende. In un diagramma delle classi da un punto di vista concettuale, ovvero in un modello di dominio, la risposta è no. Piuttosto, in questo caso una generalizzazione indica che la superclasse è un sopra-insieme e la sottoclasse è un sottoinsieme. In un DCD mentre la generalizzazione implica l'ereditarietà dalla superclasse alla sottoclasse.
Le classi astratte e le operazioni astratte possono essere mostrate con un tag {abstract}.
Le classi finali e le operazioni finali che non possono essere ridefinite nelle sottoclassi, sono mostrate con il tag {leaf}.
Aggregazione e composizione...
Anche questo argomento è già stato affrontato nel modello di dominio in aggregazione e composizione nelle associazioni.
Anzitutto, come abbiamo ribadito in quel paragrafo: non ci si scomodi a usare le aggregazioni; si usi piuttosto la composizione, quando opportuno.
Identificare le composizioni durante l'analisi a oggetti non è sempre estremamente importante. Può essere talvolta utile farlo.
In una composizione la parte non può esistere al di fuori del tempo di vita dell'intero.
Durante il lavoro di progettazione, ciò ha impatto sulle dipendenze di creazione-cancellazione tra le classi software intero e parte.
La composizione offre un aiuto nell'identificazione di un creatore di oggetti del tipo della parte.
Alcune operazioni (come copia o elimina) applicate all'intero spesso si propagano alle parti.
Una possibile interpretazione generale di composizione tra due classi A e B è la seguente: gli oggetti B non possono esistere indipendentemente dall'oggetto A, e l'oggetto A è responsabile della creazione e distruzione dei suoi oggetti B.
Relazione tra diagrammi di interazione e diagrammi delle classi...
