Le associazioni che è utile mostrare sono solitamente quelle che implicano la conoscenza di una relazione che deve essere memorizzata per una certa durata di tempo, che a seconda del contesto potrebbe essere di millisecondi o di anni. In altre parole tra quali oggetti è necessaria una certa memoria di una relazione?

Poiché il modello di dominio descrive un punto di vista concettuale, queste affermazioni sulla necessità di ricordare fanno riferimento a una necessità nel mondo reale.

Nel dominio del Monopoly, dobbiamo ricordare su quale Square si trova un Piece (pedina); il gioco non funziona se non ci si ricorda questo aspetto. Inoltre dobbiamo ricordare quale Piece è posseduto da un certo Player. D'altra parte non serve ricordare il numero di Die (passi) che fa un Piece per arrivare su un certo Square. È vero, serve, ma non occorre che si abbia un ricordo continuo di questo fatto.

Viene utilizzato uno dei metodi descritti in come creare un modello di dominio.
Ecco, sotto, l'elenco delle categorie comuni che vale la pena di prendere in considerazione, soprattutto per i sistemi informatici aziendali.

È bene evitare di inserire troppe associazioni in un modello di dominio. Molte linee producono un "disturbo visivo" che non migliorano la leggibilità del diagramma stesso.

Durante la modellazione di dominio, un'associazione non rappresenta una decisione sulle variabili d'istanza o sui collegamenti tra oggetti in una soluzione software, né sui vincoli di chiave esterna nelle basi di dati. Piuttosto è un'affermazione che una relazione è significativa da un punto di vista concettuale e di modellazione della realtà.

Ciò detto, molte di queste relazioni saranno implementate nel software come percorsi di navigazione e visibilità. Ma il modello di dominio viene costruito per migliorare la comprensione del dominio di interesse, non è un documento per oggetti software o basi di dati.

Le estremità di una associazione possono contenere un'espressione di molteplicità, che indica le relazioni numeriche tra le istanze delle classi (del dominio). Un'associazione è bidirezionale.
Il nome di un'associazione può contenere una freccia che indica il senso di lettura della stessa, non è obbligatoria, poiché in assenza di essa l'associazione viene letta da sinistra verso destra o dall'alto verso il basso.

I nomi, anche qui, devono essere significativi. Vanno evitati, possibilmente, nomi di associazione come: "Ha" o "Usa", perché non migliorano la comprensione del dominio.

Per esempio:

• Sale Paid-by CashPayment
  • cattivo esempio: Sale Uses CashPayment
• Player Is-on Square
  • cattivo esempio: Player Has Square

I nomi delle associazioni iniziano per lettera maiuscola.
Le associazioni formate da più parole possono essere scritte come segue:

• Nome-associazione
• NomeAssociazione

Ciascuna estremità di una associazione è anche chiamata ruolo. I ruoli possono avere opzionalmente:

• molteplicità delle associazioni;
• nome;
• navigabilità.

La molteplicità di un ruolo definisce quante istanze di una classe possono essere associate a un'istanza di un'altra.
Per esempio si consideri l'associazione Stocks (Immagazzina) fra le classi Store e Item. Si consideri poi un'istanza di Store (ovvero un negozio) e ci si chieda quante istanze di Item (articoli) possono essere immagazzinate nel negozio: la risposta è molti (zero o più ()). Questa quantità va scritta accanto all'estremità dell'associazione Stocks vicino alla classe Item (poiché indica quante istanze Item possono essere associate a un'istanza di Store). Poi si consideri una singola istanza di Item e ci si chieda in quante istanze di Store può essere immagazzinato quell'articolo: in questo caso la risposta è 1. Item è un oggetto tangibile, reale, e non può trovarsi in più luoghi contemporaneamente, questa molteplicità va scritta nel ruolo (estremità dell'associazione) che corrisponde alla classe Store.

Come si vede dalla figura, la molteplicità può anche essere indicata nel seguente modo: dove rappresenta il minimo e il massimo.

Le associazioni vengono classificate in base alla loro molteplicità:

• uno a uno
• uno a molti
• molti a uno
• molti a molti

Il valore della molteplicità dipende dalle scelte dello sviluppatore e in base anche a ciò che ritiene necessario rappresentare:

Nella seguente associazione: un Item può trovarsi in un solo Store e in un Store possono esserci più Item.
La molteplicità potrebbe anche essere 0..1, cioè un Item potrebbe anche non trovarsi i nessuno Store, qual è la molteplicità più adatta?

La risposta dipende dall'interesse che si ha nell'utilizzo del modello. Normalmente e praticamente, la molteplicità indica un vincolo del dominio che ci interessa poter controllare nel software, se questa relazione viene implementata o è riflessa in oggetti software o in una base di dati. Per esempio un particolare articolo potrebbe essere venduto o scartato, quindi non essere più disponibile in magazzino. Da questo punto di vista 0...1 è logico, ma ci interessa questo punto di vista? Se questa relazione fosse implementata nel software, probabilmente vorremmo assicurarci che ciascuna istanza software di Item sia sempre correlata a una particolare istanza di Store; se ciò non è vero vuol dire che si è verificato un guasto o un errore negli elementi software o nei dati.

Questo modello di dominio parziale non rappresenta oggetti software, ma le molteplicità registrano dei vincoli il cui valore pratico è normalmente correlato al nostro interesse per la costruzione del software o delle basi di dati e dei relativi controlli di validità. Da questo punto di vista "1" può essere il valore desiderato.

In un diagramma UML delle classi, è possibile che due classi siano collegate da più di un'associazione.
Esempio:

Da dove parte il volo e dove arriva sono due relazioni distinte.

Talvolta è utile mostrare il nome dei ruoli di un'associazione. Il nome descrive idealmente il ruolo svolto dagli oggetti nelle associazioni.

Un nome di ruolo esplicito non è sempre richiesto, ma è utile quando il ruolo dell'oggetto non è chiaro.

Una classe può anche avere un'associazione con sé stessa, tale associazione è detta riflessiva.

Un'associazione può essere calcolata o derivata come composizione di altre associazioni nel dominio.

In figura per esempio il volo (Flight) è associato alla descrizione del volo (FlightDescription) che a sua volta è associato all'aeroporto (Airport). La destinazione, per esempio, di un certo volo è associata alla descrizione e non direttamente al volo. In caso di associazioni di questo tipo, in cui potrebbe non essere chiaro il fatto che il volo è associato anche all'aeroporto, si può creare un'associazione derivata (Flies-to). I nomi delle associazioni derivate sono preceduti da "|" o "/": |Flies-to, /Flies-to.

Altro motivo per cui potrebbe essere necessario mostrare un'associazione derivata è il fatto che esiste nel dominio un nome (significativo) che rappresenta quell'associazione (ricavabile tramite derivazioni) la cui rappresentazione potrebbe essere semplificata indicandola nel diagramma.

Ecco un esempio che si focalizza sulle associazioni di un modello di dominio.

L'aggregazione in UML, è un tipo di associazione che suggerisce, in modo vago, una relazione intero-parte. Un esempio è l'aggregazione fra un auto e le sue ruote.

La composizione, nota anche come aggregazione composta, è un tipo forte di aggregazione intero-parte che è utile da mostrare in alcuni modelli. Una relazione di composizione implica che:

• ciascuna istanza della parte appartiene a una sola istanza del composto alla volta; per esempio, ciascuna Square in Monopoly appartiene ad un solo Board;
• ciascuna parte deve sempre appartenere ad un composto; per continuare l'esempio di prima, non ci sono Square che esistono se non per essere una parte di Board;
• la vita delle parti è limitata da quella del composto: le parti sono create dopo il composto (non prima) e possono essere distrutte prima del compost (non dopo); da un punto di vista concettuale, non è possibile distruggere un Board (un tabellone fisico, cartaceo) senza distruggere le Square che contiene.

L'aggregazione fra l'automobile e le sue ruote non è anche una composizione, perché le ruote potrebbero essere state create prima dell'auto.

Identificare la composizione nei modelli non è fondamentale, tuttavia scoprirle e mostrarle può offrire alcuni vantaggia durante la fase di progettazione.

Un aeroporto contiene 1 o più terminal.
L'aeroporto aggrega i terminal.

Il nome di una composizione è in genere: Contiene, Composto-da.

Nei nostri casi di studio: