AggregationKind - one end concept?

[Paolo F Cantoni]

Elsewhere (AggregationKind and end shapescripts) I again mention some of the anomalous behaviour of AggregationKind  and EAAggregations and EACompositions and EAAssociations.

In trying to come up with a consistent approach to the modelling and rendering of meronymys, I noticed that you can set the AggregationKind on both ends of the EAAssociation.

While not wishing to curb the enthusiasm of potential modellers (I've often used existing functionality for other than its originally intended use), it seems to me that by definition (even though the UML 2.2 Superstructure (formal) Specification doesn't explicitly say this) that AggregationKind can only be set to not none for one end of the arc at any one time.

Can anyone suggest any possible semantics for AggregationKind set to not none for both ends of the arc at the same time?

It seems to me that if say, I have origin(source)=none and destination(target)=composite, if I set origin=shared then EA should set destination=none. (and so on...)  The point is that either both ends are set to none or only one end is set to not none.

If we can get agreement on this, then we may be able to provide a possible resolution to issue of EAAggregation/EAComposition versus Aggregated Associations.

Thoughts?
Paolo
[edit]This topic should have been started in the UML category.  See: AggregationKind - client end concept? for an extension to the concept...[/edit]

[beginner]

While I agree to your criticism (yes, aggregation can be just on one side) there is another strange thing around aggregation. EA allows to render connectors of type aggregation which show the diamond at the source side. These are of a different type than association. I just don't see qhy there needs to be two concepts for the same thing. Couldn't the "Aggregation" (and Composition too) quicklink just create associations with one end set to Aggregate?

b.

[Paolo F Cantoni]

While I agree to your criticism (yes, aggregation can be just on one side) there is another strange thing around aggregation. EA allows to render connectors of type aggregation which show the diamond at the source side. These are of a different type than association. I just don't see why there needs to be two concepts for the same thing. Couldn't the "Aggregation" (and Composition too) QuickLink just create associations with one end set to Aggregate?

b.

Hi b,

Check out: Allow replacement of EA Aggregations.  As you can see it's been going a number of years...  

However, as I'm hinting in some other posts yesterday, I think we might be able to come up with a consistent way for EA to handle the (apparently) three types of concepts:  No aggregation, shared aggregation, composite aggregation.

See my recent postings (from 29 Jan) mentioning AggregationKind and contribute your thoughts.  An idea is forming in my mind to allow (close to) the "best of all possible worlds", I hope/

Paolo

[beginner]

Would be happy to see at least one of EAUI being fixed. Though I think it will not be before 10.0 as someone else mentioned in a recent post about another EAUI.

b.

[Geert Bellekens]

Paolo,

I think you are right about the implicit constraint that only one of the ends of an association can be shared or composite. The other end should then have its AggregationKind set to "none".

Although the constraint is not made explicit in the UML superstructure there are some hints that support this statement.

From the UML 2.2 superstructure:

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 first hint is the fact that in this part they make a clear distinction between the whole and the part. If two ends could be shared or composite we could be talking about whole/part anymore.

Second hint is the statement about the acyclic graph's. If there would be two composite ends to an association the graph wouldn't be acyclic anymore.

About this "source/client" and "target/supplier" issue. In UML these concepts are not defined for associations and I think EA should not attach a semantical meaning to the difference.

An association with a composite end at the source should be treated exactly the same as an association with a composite end at the target.
Currently that is not the case.

And for the issue about the special "EA Aggregation". I hope Sparx has now recognised that this is complete nonsense and buries the whole thing. (after migrating all the "EA Aggregations" to regular Associations)

Geert

[Paolo F Cantoni]

[size=18]...[/size]
About this "source/client" and "target/supplier" issue. In UML these concepts are not defined for associations and I think EA should not attach a semantical meaning to the difference.

An association with a composite end at the source should be treated exactly the same as an association with a composite end at the target.
Currently that is not the case.

From a mathematical point of view, Associations are effectively bi-directional:  I am the parent of my children.  The UML specification effectively re-iterates that.  That having been said, we can't "draw" an Association without directedness.  One end has to be the origin and one the destination.  Since, for the vast majority of UML relationships, the client is the origin and the supplier the destination, we could colloquially call the origin the client and the destination the supplier (it's better to be consistently wrong than inconsistently wrong. )

In addition, to paraphrase George Orwell, it seems to me that "all Associations are equal, but some are more equal than others".  That is to say, now we agree that only one end of the Association can have a not none AggregationKind; then one can, impute the notion of client/supplier.

And for the issue about the special "EA Aggregation". I hope Sparx has now recognised that this is complete nonsense and buries the whole thing. (after migrating all the "EA Aggregations" to regular Associations)

Geert

I will shortly (possibly tomorrow) be putting forward proposal for a mechanism to eventually get us to just having Aggregated Associations while preserving the bulk of the current users' investment in the present mechanism.  Watch another space....

Paolo

[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