Direction of Aggregaton?

[mclagett]

Hi --

Something that has bothered me about the way aggregation is represented in a class diagram.  Isn't it backward.  When I draw an aggregation connector and click first on the class that I intuitively feel should be the source and drag a connector to what I intuitively feel should be the target, the aggregation diamond appears connected to the "target".  And the tooltip for the connection reads target -> source.

Isn't this backwards?  Shouldn't the aggregation diamond be connected to the first class I select (what I would think of as the source) and shouldn't the second class be the target?  And shouldn't the tool tip read first_class -> second_class?  Or is there something I'm missing?

[jeshaw2]

I'm not sure what you mean by source and target; those terms have never been defined to my satisfaction.  However, in an aggregation relation, one object represents the holonym (the whole aggregate) and the other represents the meronym (which is a part of the aggregate).  For example Car (holonym or aggregate) has Wheels (meronym or part). The diamond, belongs at the holonym (car) end of the relation.

In any UML tool, you do what you gotta do to make that happen.

-Jim

[KP]

In UML 1.5, the following definition was given for aggregation:

"When placed on one end (the “target” end), specifies whether the class on the target end is an aggregation with respect to the class on the other end (the “source”end). Only one end can be an aggregation. Possibilities are:
• none - The target class is not an aggregate.
• aggregate - The target class is an aggregate; therefore, the source class is  a part and must have the aggregation value of none. The part may be contained in other aggregates.
• composite - The target class is a composite; therefore, the source class is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other composite.

This makes it unambiguously clear that the whole was the "target" and the part was the "source". EA chose to draw these connectors from source to target, other tools chose the other way around, but the underlying model was always the same.

In UML 2, "source" and "target" were replaced by "client" and "supplier" respectively, and the words "source" and "target" no longer have meaning in UML. EA continues to use the terms, but the only meaning they have now is the drawing direction of the connector - which is something that UML doesn't really care about.

Another change in UML 2 was that aggregation and composition ceased to be metaclasses in their own right and became properties of associations. So, for strict UML 2 compliance you should be using associations rather than aggregations and compositions.

I hope this helps.

[thomaskilian]

Hi Neil,
as we are in it: still Aggregation is used as metaclass for aggregated Associations from the quicklink. Could you keep that on the radar to create an Association instead!

Thanks in advance.

[mclagett]

Hi --

Thanks for the reply. I guess it has always been me that has had it backwards, although I'm sure that tools I have used in the past have presented it thus and that much of the discussion around aggregation has spoken of it in terms of a class being "composed of" or "aggregating" another class.  Moreover in component technologies like Microsoft's COM or in the C++ PIMPL idiom, where the aggregating component or class holds a pointer to its included component and forwards requests to it, the whole way of thinking about the relationship is from the point of view of the "aggregator" and not from the "aggregatee", so to speak.  

Just another hazard, I guess, of the informal semantics specification style of UML (although the definition you quote -- and that in my supreme anal retentivity I went to the spec to check for myself -- is pretty clear and unambiguous).  It does, however, seem to me to fly in the face of conventions around the use of aggregation.  As you say, in the end it doesn't really make any difference as long as you use the tool to draw the diagram correctly; you can interpret the diagram however you like.

[Paolo F Cantoni]

If you search the forum for "Aggregation vs Aggregate Association"  (without quotes and for at least 999 days back) you'll see some ramblings on the topic.

HTH,
Paolo

[«Midnight»]

However, to ease the confusion if you use other tools, take a look at the Tools | Options | Links dialog. You can always check the Draw Aggregations Reversed option. The help file explains this option, and refers to just this situation in regards to other tools.

[danm]

Thanks for the explanation KP - I was just puzzling over that nomenclature last night.

[Paolo F Cantoni]

See: Aggregation and Association proposal for a proposal to provide consistent processing and rendering of EA Aggregations, Compositions and Associations.

HTH,
Paolo