Aggregazione UML vs associazione

Eccomi, con un’altra domanda sull’aggregazione e l’associazione. Volevo imparare alcune basi di UML, così ho iniziato a leggere “UML distillato” di Martin Fowler. Leggo entrambi i capitoli sulle classi, e c’è una cosa che non riesco a comprendere appieno, e cioè l’aggregazione contro l’associazione. Nel libro c’è questa citazione:

Nei giorni pre-UML, le persone erano solitamente piuttosto vaghe su cosa fosse l’aggregazione e quale fosse l’associazione. Indifferenti o meno, erano sempre in contrasto con tutti gli altri. Di conseguenza, molti modellisti pensano che l’aggregazione sia importante, anche se per ragioni diverse. Quindi l’UML includeva l’aggregazione (Figura 5.3) ma quasi nessuna semantica. Come dice Jim Rumbaugh, “Pensa a un placebo della modellazione” [Rumbaugh, UML Reference].

Come ho capito da questa citazione e dagli argomenti che ho letto su Stack Overflow, non importa quale di queste due relazioni io uso, esse significano il bassico lo stesso, o c’è qualche situazione in cui l’uso dell’aggregazione anziché dell’associazione sarebbe giustificato e / o non potrei cambiarne uno senza cambiare il “significato” di un diagramma di class?

Lo sto chiedendo, perché questo libro è del 2003 e alcune cose potrebbero cambiare in quei pochi anni.

La dichiarazione di Rumbaugh è il consiglio più eloquente e lo zio Bob. Come ho già detto altrove , Aggregation è semanticamente così debole da non offrire nulla di utile. Ha solo un caso d’angolo valido (aciclicità di relazioni ricorsive), anche se poche persone lo sanno e lo capiscono. Quindi finisci per dover indicare comunque nei commenti.

Io proprio non lo uso. E non ho mai sentito alcuna perdita. Segui semplici associazioni binarie e concentrati su ciò che conta davvero, ottenendo la cardinalità e il nome giusto. Otterrete molto più da ciò che cercare di decidere l’associazione indecidibile contro l’aggregazione.

hth.

Forse questo può aiutarti, ma non penso che troverai la spiegazione perfetta:

La differenza è di implicazione. L’aggregazione denota relazioni intere / parziali mentre le associazioni no. Tuttavia, non è probabile che ci sia molta differenza nel modo in cui le due relazioni sono implementate. Cioè, sarebbe molto difficile guardare il codice e determinare se una particolare relazione dovrebbe essere aggregazione o associazione. Per questo motivo, è abbastanza sicuro ignorare del tutto la relazione di aggregazione.
[Robert C. Martin | UML]

E un esempio per ogni situazione:

a) L’associazione è una relazione in cui tutti gli oggetti hanno il loro ciclo di vita e non c’è proprietario. Facciamo un esempio di insegnante e studente. Più studenti possono associarsi a un singolo insegnante e il singolo studente può associarsi a più insegnanti, ma non esiste alcuna proprietà tra gli oggetti ed entrambi hanno il proprio ciclo di vita. Entrambi possono creare ed eliminare indipendentemente.

b) L’aggregazione è una forma di associazione specializzata in cui tutti gli oggetti hanno il proprio ciclo di vita, ma esiste la proprietà e l’object figlio non può appartenere a un altro object padre. Prendiamo un esempio di Dipartimento e insegnante. Un singolo insegnante non può appartenere a più reparti, ma se cancelliamo il dipartimento, l’object insegnante non verrà distrutto. Possiamo pensare alla relazione “ha-a”.
[Maesh | GeeksWithBlogs]

Tendo ad usare l’aggregazione per mostrare una relazione che è la stessa di una composizione con una grande distinzione: la class contenente non è responsabile per il ciclo di vita dell’object contenuto. In genere, un puntatore (non null) o un riferimento all’object-da-essere-contenuto viene passato al costruttore della class contenente. L’object contenitore, per la durata del suo ciclo di vita, dipende dall’object contenuto esistente. L’object contenitore non può eseguire il proprio lavoro (completamente) senza l’object contenuto. Questa è la mia interpretazione della relazione “Parte / Intero” implicita da Aggregation.

Nell’aggregazione UML è sottostimato e poiché non hanno alcuna semantica chiaramente definita. Un caso d’uso valido di un’aggregazione è l’incapsulamento di diverse classi, come dichiarato in “Domain Driven Design” di Eric Evans.

Ad esempio, una macchina ha quattro ruote. Potresti voler calcolare la quantità totale di metri che ogni ruota ha guidato, per ogni auto. Questo calcolo viene effettuato dall’entity framework auto, poiché sa quali ruote ha e non ti importa quali ruote appartengono a quale auto.

L’auto è l’aggregazione-radice per tutte le sue parti, come le ruote, e non è ansible accedere alle parti di una macchina dall’esterno dell’aggregazione, solo la radice.

Quindi fondamentalmente un’aggregazione incapsula un insieme di classi che appartengono l’una all’altra.

Per quanto riguarda l’implementazione, non c’è molta differenza, ma concettualmente c’è una grande differenza: le aggregazioni sono usate per esprimere una gerarchia . Quando lavori con una gerarchia di componenti, ci sono determinati tipi di operazioni che devi avere nell’interfaccia di root:

  • trova sottocomponenti nella gerarchia
  • aggiungere / rimuovere sottocomponenti a / dalla gerarchia
  • cambia gli attributi comuni di tutti i componenti
  • attraversare la gerarchia in modo ricorsivo (modello Visitor)
  • riconfigurare la gerarchia e i collegamenti (associazioni) tra i componenti

Molte di queste operazioni non sono necessarie quando si tratta di associazioni.

Questo termine viene spesso confuso.

L’aggregazione e la composizione sono alcuni dei tipi di associazione. Non c’è quasi differenza tra aggregazioni e associazioni durante l’implementazione, e molti salteranno del tutto le relazioni di aggregazione nei loro diagrammi con la relazione di associazione.

È ansible ottenere l’idea da questa analogia.

Classe: A (persona) e Classe: B (auto) ha relazione di associazione , se Classe: A ha una Classe: B dichiarazione, e anche Classe: B (auto) l’ object non è essenziale per creare una Classe: A (persona) object .

Classe: A (auto) e Classe: B (pneumatico) ha relazione di aggregazione , se Classe: A ha una dichiarazione Classe: B , e anche l’object Classe: B (pneumatico) è essenziale per creare un object Classe: A (auto) .

Saluti!

Per aggiungere, vorrei solo suggerire di scaricare le specifiche UML dal sito OMG: miglior riferimento e vedi p 110.

none Indica che la proprietà non ha semantica di aggregazione.

condiviso Indica che la proprietà ha condiviso la semantica di aggregazione. La semantica precisa dell’aggregazione condivisa varia in base all’area dell’applicazione e al modellatore.

composito Indica che la proprietà è aggregata in modo compositivo, cioè che l’object composito ha la responsabilità dell’esistenza e della memorizzazione degli oggetti composti (vedere la definizione delle parti in 11.2.3).

Non significano lo stesso! Posso metterlo in questo modo:

Rapporto di associazione : una class fa riferimento a un’altra class. In realtà mostra che una class è correlata a un’altra class, ma non necessariamente hanno attributi per mostrare questa relazione … ad esempio classi “Insegnante” e “Studente”, sebbene la class “Insegnante” non abbia attributi che si riferiscono agli studenti, ma sappiamo che in realtà un insegnante ha studenti … E anche la class ‘Scuola’ ha proprietà ‘insegnanti’ e ‘studenti’ che ora rendono queste due classi legate l’una all’altra.

Relazione di aggregazione : una class contiene un’altra class. Ma se il contenitore (ClassRoom) viene distrutto, il contenuto (Chair) non lo è. In realtà la ClassRoom è proprietaria della sedia. L’aggregazione è una relazione più forte rispetto alla relazione dell’Associazione.

Ecco anche un tutorial su di esso e l’intero UML2.0 che spiega tutto in modo facile e semplice, potresti trovarlo utile: https://github.com/imalitavakoli/learn-uml2

SUGGERIMENTO : Lasciatemi menzionare anche che, poiché la relazione di associazione esiste spesso tra le classi, a volte non la disegniamo per evitare complessità non necessarie.