AggregationKind - client end concept?

[Paolo F Cantoni]

In AggregationKind - one end concept? (which I now realise I should have started in this category), I put forward the notion that only one end of an arc should have AggregationKind set to not none at any one time.

This topic extends that idea and discusses which end it should be.

The vast majority of UML relationships have the origin (source) as the Client end and the destination (target) as the Supplier end.

So, in a meronymy (the relationship between the whole and the part) who is the client and who the supplier?  The holonym (whole) or meronym (part)?

My view, at present, is that (somewhat paradoxically) the holonym is the client and the meronym the supplier.  I take this view because (certainly for composite aggregations and most of the time for shared aggregations) the whole doesn't usually exist without at least one part.

What do others think?

TIA,
Paolo
PS: I'm aware that (now much) older versions of UML dictated that the target end was the end containing the AggregationKind.  I'm pretty sure that restriction has been lifted for UML2.  I'm talking here about the conceptualization of the issue.

[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

[Paolo F Cantoni]

In AggregationKind - one end concept?
Geert Bellekens writes (and I reply):

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

I would appreciate feedback on some ideas which are now coalescing regarding the consistent (if not correct) treatment of meronymies (the whole-part relationship).

At the end of the quote above, I mention that one can impute the notion of client/supplier to a meronymy (I'm using this term since I don't want to confuse Aggregation the concept with the arc type of Aggregation), because, in my view, while notionally Associations are bi-directional, the existence of the (single) AggregationKind changes the nature of the bi-directionality into a semantically directional relationship (similar to dependencies, realizations etc).

My question is:  Is the directionally a universally true concept for meronymies, or is it a matter of convention within any specific model?  Note, if the latter, then each model should indicate the convention being used for Ha model.

OK!  So, it seems to me that the question hinges on the semantics of the arc (meronymy).  Again,for the sake of (perhaps incorrect) consistency, I'm going to call the origin the client and the destination the supplier.  Thus, if I have the AggregationKind diamond at the supplier, I would seem to be saying:  "Client is a meronym of Supplier" (Supplier is thus the holonym - the whole).
Whereas, if I place the AggregationKind diamond at the client, I would seem to be saying:  "Supplier is a meronym of Client" (Client is thus the holonym - the whole).

With the other UML relationships, this is well specified (even if, in the case of Generalization, in the reverse):  client realizes supplier; client is dependent on supplier, client specialized supplier, even client requires supplier (for an Assembly connector).

So far, in my modelling, I've adopted the convention that  "Supplier is a meronym of Client" - that is to place the AggregationKind diamond at the origin of the arc.  I've reiterated that position in the first post of this topic above.  But now, I'm not so sure that's correct.

That's why I'm seeking your views...  Since I've been consistent, once I've canvassed your views and come to a conclusion, I will be able to either:  Leave what I've got alone - since it still retains the semantics I expressed.  Or run a standard query to convert to the different semantics.  (Since having been consistently wrong, I'm in a much better position than if I'd been inconsistently wrong...  ).

So to be clear, I'm asking for feedback on which is the "correct" semantics of the meronymy arc:

• Client is a meronym of Supplier (and thus Supplier is holonym of Client)
  
  or
• Client is holonym of Supplier (therefore Supplier is meronym of Client)
  

Thank you for your contribution.
Paolo

[beginner]

I wonder whether Client and Supplier are correct terms at all. I haven't studies Superstructures in that respect, so I'm not at all influenced from that side. But when I work with relations I try to get grip of the Opposite always depending on which part is looking. I would rather expect to get ONE Opposite property to be returned from GetConnector rather than Client and Supplier which do not mean anything to me except a lot of confusion.

b.

[Paolo F Cantoni]

Hi b,

this has NOTHING to do with the internals of EA.  It's about the semantics of a relationship "drawn" from one element (the client) to another (the supplier).

Think of me using a whiteboard...

Paolo

[Geert Bellekens]

Paolo,

I think it is indeed a matter of convention which end you like to call source/client and which part target/supplier.
For me it feels most natural to have the client be the aggregate/composite/whole/holonym and the supplier the part/meronym

But as I said, I don't think there is a universal truth with regards to these concepts.

Geert

[beginner]

Paolo,
please excuse my API oriented look. But still when I look at relations I just see the "other side" or "opposite" first. Whether one is supplier or client is something opposed when you add e.g. a role to one side. Still then you can have roles on both sides.

From my point of view you don't seem to see the trees 'cause of the wood (as we say in Germany). Or probably I'm simply too dumb to float on these esoteric waves?

b.

[Paolo F Cantoni]

Paolo,
please excuse my API oriented look. But still when I look at relations I just see the "other side" or "opposite" first. Whether one is supplier or client is something opposed when you add e.g. a role to one side. Still then you can have roles on both sides.

From my point of view you don't seem to see the trees 'cause of the wood (as we say in Germany). Or probably I'm simply too dumb to float on these esoteric waves?

b.

No, not too dumb  

All I'm saying is:  While I acknowledge that I could set the AggregationKind at either end of an Association; I have/want to have a consistent mechanism for drawing these aggregations so that the semantics of the "representation" are consistent.

As Geert suggests, it may be merely a matter of convention, although it's interesting he came to the same conclusion as me.  I was hoping there might be some underlying "truth" which would allow me to take a stronger stance.

The important thing is that everyone looking at the diagram takes away the same understanding.  I'm developing a convention that says:

"We place the AggregationKind diamond at the origin end".

That allows us to query the model and investigate situations where that isn't the case and resolve them - often due to a slip of the mind.

Paolo

[Frank Horn]

To bring another technical aspect into it:

The source and target concept EA uses for associations is a UML 1 thing and obsolete in UML 2, but it determines in which package the connector is stored. This is essential when it comes to working with controlled packages.

Say you have a classical composition, like a car with four wheels. I would draw an association from car to wheel and set the wheel role as composite, which results in a solid rhombus symbol being rendered on the car side of the connector. The connector will be stored in the parent package of the car class, so I would not have to check out the package containing the wheel class. This is important, for a colleague working on the bicycle package will be using the wheel package as well.

If you use the "old" aggregation connector, the rhombus will show up on the wheel side, but still the wheel role will be marked as composite. Drawing it from wheel to car just for sake of getting the rhombus on the car side would be fatal, because the connector would end up in the wrong package and the wrong role would be marked as composite within the model.

[Paolo F Cantoni]

[size=18]...[/size]
Say you have a classical composition, like a car with four wheels. I would draw an association from car to wheel and set the wheel role as composite, which results in a solid rhombus symbol being rendered on the car side of the connector.
[size=18]...[/size]

Before I comment on the VERY important point you're making Frank, if I follow your instructions I don't up with your result.  I think we should sort that out first.

If I draw an Association from Car to Wheel, and I open the Association properties [Alt+Enter] I end up with Source=Car and Target=Wheel.  If I select the Target Tab, I can see: Wheel Role:.   If I set the Aggregation: to composite, I get the AggregationKind diamond on the Wheel (Target) end of the Association.  Have I followed your instructions correctly?

Paolo

[Frank Horn]

Sorry, Paolo, so I mixed it up once more. It's the "Source Role" I set to "Aggregation:composite", and then have the diamond on the car side. On the "Target Role" tab I would only set "Navigability:Navigable" and "Multiplicity:4".

Anyway, what I said is no argument for having the diamond here or there, it's just to point out that the obsolete source and target concept is still essential in EA because there is no other way to determine to which package a connector will belong.

That would mean, of course, that I might as well use the old "aggregation" connector and draw it the same way. The diamond would be on the same side, and the same role would be marked as composite. Which leaves the question why we need two different kinds of connectors for the same thing.

[Paolo F Cantoni]

No problem Frank!  It IS confusing - that's why I'm trying to get things sorted.  The confusion is compounded by the fact that EA always (up to build 850 at least) puts the AggregationKind diamond at the destination/target end of the arc for EAAggregations.

When EA says [X] Draw Aggregations Reversed it literally does that, it swaps the Origin/Source and Destination/Target elements to keep the AggregationKind diamond at the Destination/Target end.  It appears to be a throwback to UML 1.1.

Interestingly, you also draw UML Aggregations with the AggregationKind diamond at the Origin/Source/Client end of the Association.

If you haven't already, have a look at the proposal referenced in the second post in the topic.

Now that we've sorted the drawing of the Aggregation, I'll comment on the point you made in a separate post.

Paolo

[Paolo F Cantoni]

To bring another technical aspect into it:

The source and target concept EA uses for associations is a UML 1 thing and obsolete in UML 2, but it determines in which package the connector is stored. This is essential when it comes to working with controlled packages.
[size=18]...[/size]

OK, Looking at the t_connector table, there's no mechanism directly referencing a package.  Therefore, the connector is not stored in any package.  But I think the point you are making is that when a package is exported, the the connector is exported in the package of which the source element is a child.

Is that correct?

Consequently, you only need to check out the package containing the source end of the Aggregated Association.  If you use an EA Aggregation because it ALWAYS puts the AggregationKind diamond on the target end, things get more complicated...  

Have I understood it correctly?

Paolo

[Frank Horn]

Here's what I found in the superstructure, v2.1.1 on page 44:

An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as
a terminal adornment at the aggregate end of the association line. The diamond shall be noticeably smaller than the
diamond notation for associations. An association with aggregationKind = composite likewise has a diamond at the
aggregate end, but differs in having the diamond filled in.

I take this to mean that the diamond should be placed at the end connected to the whole, and not at the end connected to the part.

Or do I misunderstand the term "aggregate end"? Maybe some native speakers of english can comment on this.

[Paolo F Cantoni]

Here's what I found in the superstructure, v2.1.1 on page 44:

[size=18]...[/size]

I take this to mean that the diamond should be placed at the end connected to the whole, and not at the end connected to the part.

Or do I misunderstand the term "aggregate end"? Maybe some native speakers of English can comment on this.

No, you've got it correct...  However, EA (like most UML tools) implicitly contains the notion of directionality in that one element is designated as the source and the other the target (the prevailing default is that arcs are "drawn" from the source to the target).

UML doesn't care about this AT ALL.  All the section quoted says is:  "Whichever end has the AggregationKind diamond will be the Aggregate (holonym).  The other end is the meronym."

Consequently, UML doesn't care which end (direction wise) has the diamond.  

All I'm promoting is that each repository adopt a convention as to which end (origin/destination) has the diamond.  This allows much easier queries to filter stuff etc...  Your point about package version control give even more emphasis to the problem.

Does that help?