Author Topic: Confused about diamond position in aggregations  (Read 2537 times)

vanyatka

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Confused about diamond position in aggregations
« on: February 20, 2009, 04:58:14 am »
Hi,

According to UML spec the diamond should be at the owning side of the association (which I presume is the source side), but in EA it appears at the target side. I'm confused...  :-/ Should the owning side of aggregation be the target role?

Thanks,

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6481
  • Karma: +56/-6
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #1 on: February 20, 2009, 08:01:30 am »
You could have found plenty of information on this with a search on the forum.  One post that I would like to point out is the following, that I believe covers the important details.

Quote
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.

Also, taking into account that many people believe as you do, EA has an option to change the drawing direction of the aggregation.  
Quote
Just to be sure, check your Tools | Options | Links settings. What are your settings for Draw Aggregations Reversed and Association default direction?

Simon

support@sparxsystems.com

vanyatka

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #2 on: February 21, 2009, 05:16:15 am »
Simon, thanks a lot for your reply, much appreciated.
However nearly all examples of UML2 do use aggregations and compositions, moreover with diamonds at the "source".

Even sparx UML2 tutorial shows the same
http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_classdiagram.html

It seems that "Draw Aggregations Reversed" should be the default option.


sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Confused about diamond ... YYYYAAARRRGH!
« Reply #3 on: February 21, 2009, 10:19:34 pm »
As one of the original protagonists in this d*mn debate, let me say this (only once)...

UML2 precept #2134:  The presence of aggregation diamonds in a diagram is evidence of over analysis.

You don't need them, you don't  want them.  They only confuse both the modeler and the audience.  They convey exactly $0.00 of information.

(Can I go back to sleep now)
bruce

[dog] <>---[leg]
[dog] ---<> [leg]

who care's! unless you're the dog.  In which case, it's not visible to ::[dog_observer]
« Last Edit: February 21, 2009, 10:23:30 pm by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

vanyatka

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Confused about diamond ... YYYYAAARRRGH!
« Reply #4 on: February 21, 2009, 11:15:46 pm »
Quote
As one of the original protagonists in this d*mn debate, let me say this (only once)...
UML2 precept #2134:  The presence of aggregation diamonds in a diagram is evidence of over analysis.
I'd love to see more info on this.
Could you point me to the discussion?

ps. About UML2 precept #2134. Is it in OMG Unified Modeling Language (OMG UML),
Superstructure, V2.1.2?

Thanks,


Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +0/-0
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #5 on: February 22, 2009, 07:30:36 am »
Whether "UML2 precept #2134" actually exists or is just one of Bruce's jokes: I think the aggregation or composition diamond may well carry useful information.

For instance we frequently use it in class diagrams for simple data classes which carry nothing but a set of attributes and associations. We create C# code from them, and the composition diamond on an association indicates that the complete target will be written under the source node in XML serialization (whereas for the target of a non-composite association the source node will only contain a key).

By the way: we put the diamond on the source side, but I don't care if people do it vice versa (as long as they do it consistently).

Matt Edwards

  • EA Novice
  • *
  • Posts: 17
  • Karma: +0/-0
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #6 on: March 12, 2009, 11:43:28 am »
Well diamonds do clue the reader into the fact that the association is static, concrete and navigable as opposed to dynamic (uses) or conceptual (traces). The composite vs aggregate distinction seems somewhat esoteric though, and prone to misuse.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6292
  • Karma: +106/-91
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #7 on: March 12, 2009, 04:57:39 pm »
Quote
Well diamonds do clue the reader into the fact that the association is static, concrete and navigable as opposed to dynamic (uses) or conceptual (traces). The composite vs aggregate distinction seems somewhat esoteric though, and prone to misuse.
Well, one can come up with a non-esoteric distinction that is NOT prone to mis-use.

My former colleague Darren Sampson and I came to the conclusion that the solid diamond (composition) meant that: "the holonym has the right to destroy the meronym (and that might be part of the holonym "dying" or not).  In addition, the constraints on the meronym instance was that it could be only part of one composition at a time.  The open diamond (shared aggregation), meant the that ""the holonym does not have the right to destroy the meronym - under any circumstance".  Accordingly, if the holonym dies, the meronym (even if attached at the time) lives on.
No other inference could (or should) be drawn.  That has served us well in the more than two years since we came up with that definition.

HTH,  thoughts welcome
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 8556
  • Karma: +209/-26
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Confused about diamond position in aggregation
« Reply #8 on: March 12, 2009, 08:17:34 pm »
Formally there a a few constraints that define the difference between the different aggregationkinds
  • none: represent a regular association
  • shared: an aggregation end. The only extra constraint is that the association containing a shared end must have exaclty two ends. (where a regular association can have 2..* ends)
  • composite: same as shared constraint about the 2 ends.

a part can be part of only one whole at a point in time
a part will be deleted together with its whole
[/list]
For those interested, here is a quote of the relevant part in the UML superstructure v 2.1.2
Quote
An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be
aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most
one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where
allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.
Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an
element in one part of the graph will also result in the deletion of all elements of the subgraph below that element.
Composition is represented by the isComposite attribute on the part end of the association being set to true.

The discussion about source and target is completely meaningless in my opinion.
I do agree that the "draw aggregation reverse" option should be the default as it is more intuitive to draw the relation from the whole to the part.

«Midnight»

  • EA Guru
  • *****
  • Posts: 5651
  • Karma: +0/-0
  • That nice Mister Grey
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #9 on: March 12, 2009, 10:03:33 pm »
FWIW,

Note however that the assertions regarding the number of association ends can be changed. In particular, we see this in SPEM.

Such a change - renders the assertion regarding exactly 2 ends as false only in those profiles where this change is explicitly made. It also makes the source and target (client and supplier) discussion meaningful, in those profiles.

Just adding my 0.02 CAD to the discussion, whatever that's worth these days.

David

NB: And yes, it does muddy the waters somewhat. Please don't blame me though; see the relevant OMG documents for whatever wisdom you can glean.
No, you can't have it!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6292
  • Karma: +106/-91
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Confused about diamond position in aggregation
« Reply #10 on: February 02, 2010, 11:44:13 am »
See: Aggregation and Association proposal for a proposal to provide consistent processing and rendering of EA Aggregations, Compositions and Associations.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!