UML: va bene usare solo l'associazione in un diagramma di classe?

Sì, certo che va bene. Sia l'aggregazione che la composizione sono tipi di associazione. Quindi ciò che crei potrebbe non avere tutti i dettagli che potrebbe avere ma sarà comunque corretto. Puoi sempre aggiungere i dettagli più tardi.

Ricorda che i diagrammi UML sono modelli e descrizioni non complete del software attuale.

Mi piace aggiungere che in molti casi, non esiste una risposta chiara o obiettiva alla domanda se una data relazione è aggregazione, composizione o solo associazione.

Per maggiori dettagli, puoi controllare questo articolo .

Ecco perché questo è così confuso:

^{c-sharpcorner.com | Dipendenza, Generalizzazione, Associazione, Aggregazione, Composizione in OOP}

            |  Ownership  | Lifetime dependency |        
Association | none/anyone |        none         |
Aggregation |  one owner  |        none         |
Composition |  one owner  |      on owner       |

Queste sono alcune definizioni molto chiare. Li descriviamo in questo modo:

^{eclipse.org | Guida di papiro > Guida dell'utente > Guida introduttiva | 7.4.6 Relazioni}

Tuttavia quando vedi

Ciò garantisce che non vi è alcuna proprietà o semplicemente non insistere sulla proprietà? La composizione è un'associazione dopotutto. Ora prova a leggere questo:

        4  1     1  1
  [Tire]---◆[Car]♢---[Spare Tire]
              | 1
              | 1 
       [Cup of Coffee]

E dimmi se i nomi o l'UML ti offrono una migliore comprensione di ciò che sta accadendo. Se non puoi fidarti di me per usare sempre la rappresentazione della relazione più stretta possibile, i simboli smettono di essere importanti.

Tienilo a mente quando fai un diagramma. Non sto dicendo che devi essere sempre fedele al 100%, la maggior parte delle persone non lo è, ma assumersi la responsabilità per questo e in qualche modo farci sapere quando sei serio riguardo ai simboli e quando non lo sei. Altrimenti diventa una scrittura una volta, non leggi mai l'esercizio.

Essenzialmente, quando si ha un'associazione, si afferma che almeno un'istanza di A può essere collegata dinamicamente ad almeno un'istanza di B. Non si è vincolati dal tipo di collegamento esistente tra i due, altri che è un collegamento dinamico, a livello di classe / istanza (cioè, un attributo, non una variabile locale in un metodo, che sarebbe invece una relazione di dipendenza). Ciò è utile, ad esempio, quando un'istanza utilizza semplicemente un'altra istanza in una delega.

Quando usi un'aggregazione, stai semanticamente affermando che l'istanza di A sta aggregando (ad es. "parte di") almeno un'istanza di B. Questa è una versione specializzata di un'associazione, usata ad esempio per modellare un contenitore e gli elementi in esso contenuti (gli elementi di un elenco).

La composizione è il tipo più specializzato di aggregazione (e, per estensione, di associazione). Semanticamente esprime che A non solo aggrega B, ma che l'istanza non può esistere senza le sue parti. Usando un esempio di vita reale, è come dire che un LivingPerson ha bisogno di un cervello e un cuore.

Naturalmente, si tratta di perfezionare il modello. Se stai bene solo modellando l'associazione e non entrando in molti dettagli (di solito nelle prime fasi del design / sviluppo, una pratica raccomandata da Robert C. Martin), vai solo per le associazioni. Se un'aggregazione o una composizione è semanticamente molto rilevante per il modello, allora sei un po 'forzato a usarli. Lo stesso vale per molti altri elementi UML (gli stereotipi di una dipendenza, cardinalità ...) La parte fondamentale è che il modello è abbastanza chiaro per essere comprensibile, ma abbastanza conciso da fornire una chiara comprensione dell'idea che viene modellata.