UML aggregation vs association

Question

Eccomi qui, con un'altra domanda su aggregazione e 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 di solito piuttosto vago su ciò che era e ciò che l'aggregazione era 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 questo come un placebo di modellazione" [Rumbaugh, Riferimento UML].

quanto ho capito da questa citazione e gli argomenti che ho letto su Stack Overflow non importa che uno di quei due rapporti che uso, che significano bassicly la stessa, o c'è qualche situazione in cui l'uso di l'aggregazione invece dell'associazione sarebbe giustificata e/o non potrei cambiare l'una con l'altra senza cambiare il "significato" di un diagramma di classe?

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

Answer 1

La dichiarazione di Rumbaugh è il consiglio più eloquente e lo zio Bob.Come ho detto elsewhere, Aggregation è semanticamente così debole da non offrire nulla di pratico. 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.

Answer 2

Forse questo può aiutare, ma non credo che troverete la perfetta spiegazione:

La differenza è una delle implicazione. Aggregation indica le relazioni intero/parte mentre le associazioni no. Tuttavia, non c'è la probabile 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 che ignori del tutto la relazione di aggregazione.
[Robert C. Martin | UML]

e un esempio per ogni situazione:

a) associazione è un rapporto in cui tutti gli oggetti hanno la loro ciclo di vita e non c'è nessun proprietario. Prendiamo un esempio di Insegnante e Studente. Più studenti possono associarsi a un solo insegnante e lo singolo studente può associarsi a più insegnanti, ma non esiste la proprietà tra gli oggetti e 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 è presente la proprietà e l'oggetto figlio non può appartenere a un altro oggetto padre. Facciamo un esempio di Dipartimento e insegnante. Un singolo insegnante non può appartenere a più dipartimenti , ma se cancelliamo il dipartimento, l'oggetto insegnante non verrà distrutto. Possiamo pensare alla relazione "ha-a".
[Maesh | GeeksWithBlogs]

Answer 3

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 indicato in "Domain Driven Design" di Eric Evans.

E.g. una macchina ha quattro ruote. Si potrebbe voler calcolare la quantità totale di metri che ogni ruota ha guidato, per ogni auto. Questo calcolo viene eseguito dall'entità auto, poiché sa quali ruote ha e non ti importa quali ruote appartengono a quale auto.

L'auto è la radice di aggregazione per tutte le sue parti, come le ruote, e non è possibile accedere alle parti di un'automobile dall'esterno dell'aggregazione, solo la radice.

Quindi in sostanza un'aggregazione racchiude un insieme di classi che appartengono l'una all'altra.

Answer 4

Tendo ad utilizzare l'aggregazione per mostrare una relazione uguale a una composizione con una distinzione importante: la classe contenitore non è responsabile del ciclo di vita dell'oggetto contenuto. In genere, un puntatore (non null) o un riferimento all'oggetto-da-essere-contenuto viene passato al costruttore della classe contenente. L'oggetto contenitore, per la durata del suo ciclo di vita, dipende dall'oggetto contenuto esistente. L'oggetto contenitore non può eseguire il proprio lavoro (completamente) senza l'oggetto contenuto. Questa è la mia interpretazione della relazione "Parte/Intero" implicita da Aggregation.

Answer 5

Non intendono la stessa cosa! Posso mettere in questo modo:

Associazione rapporto: Una classe fa riferimento a un'altra classe. In realtà mostra che una classe è correlata a un'altra classe ma non hanno necessariamente attributi per mostrare questa relazione ... es. Classi 'Insegnante' e 'Studente', sebbene la classe 'Insegnante' non abbia attributo che si riferisce a studenti, ma sappiamo che in realtà un insegnante ha studenti ... E anche la classe 'Scuola' ha 'insegnanti' e le proprietà degli studenti ' ' che ora rendono queste due classi correlate a ciascun altro.

Rapporto di aggregazione: una classe contiene un'altra classe. 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 Associazione.

Ecco anche un tutorial su di esso e sull'intero UML2.0 che spiega tutto facile e semplice, può risultare utile: https://github.com/imalitavakoli/learn-uml2

TIP: Inoltre vorrei ricordare che esiste perché il rapporto Associazione tra le classi più delle volte, a volte non lo rappresentiamo a prevenire inutili complessità.

Answer 6

A livello di implementazione non c'è molta differenza ma concettualmente c'è una grande differenza: le aggregazioni vengono utilizzate per esprimere una gerarchia. Quando si lavora con una gerarchia di componenti ci sono certo tipo di operazioni è necessario avere nell'interfaccia principale:

• sottocomponenti find nella gerarchia
• Add/Remove sottocomponenti da/per la gerarchia di
• cambiamento attributi comuni di tutti i componenti
• traversata la gerarchia in modo ricorsivo (modello Visitor)
• riconfigurare la gerarchia e le collegamenti (associazioni) tra i componenti

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

Answer 7

Questo termine viene spesso confuso.

Aggregazione e composizione sono alcuni dei tipi di associazione. C'è una differenza tra le aggregazioni e le associazioni durante l'implementazione di e molti salteranno del tutto le relazioni di aggregazione in i loro diagrammi con relazione di associazione.

È possibile ottenere l'idea da questa analogia.

Classe: A (persona) e Classe: B (auto) ha associazione relazione, se Classe: A ha una classe : B dichiarazione, e anche Classe: B (auto) l'oggetto è non essenziale per creare un oggetto Classe: A (persona).

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

Cheers!

Answer 8

Per aggiungere, vorrei solo suggerire a scaricare specifica UML dal sito OMG: miglior riferimento e vedere p 110.

nessuno indica che la proprietà non ha la 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, vale a dire che l'oggetto composito ha la responsabilità di l'esistenza e l'archiviazione degli oggetti composti (vedere la definizione di parti in 11.2.3).