aggregation/composition/containment navigability

[qwerty]

UML 2.5 does no longer have source and target. It has 2..* ends.

q.

[KP]

UML 2.5 does no longer have source and target. It has 2..* ends.

q.

It depends on the connector type. ControlFlow has source/target, Generalization has specific/general, Dependency has client/supplier, Association has memberEnd/memberEnd. Maybe it would be better to label the properties dialog with the type-specific names, except that probably wouldn't help because we would continue to label the UML 1 constructs aggregation and composition with their correct UML 1 labels of source and target which is what caused the OP to start this thread in the first place.

[Paolo F Cantoni]

UML 2.5 does no longer have source and target. It has 2..* ends.

q.

It depends on the connector type. ControlFlow has source/target, Generalization has specific/general, Dependency has client/supplier, Association has memberEnd/memberEnd. Maybe it would be better to label the properties dialog with the type-specific names, except that probably wouldn't help because we would continue to label the UML 1 constructs aggregation and composition with their correct UML 1 labels of source and target which is what caused the OP to start this thread in the first place.

The problem can be resolved somewhat by reference to "first principles".

NO binary relationship can be drawn without some form of directionality.  One end is the origin, the other the destination for the drawing implement.  As I mentioned, the (usual) convention is that the origin provides the "client" and the destination the "supplier".  Later modelling methodologies, even if based on UML, corrected some of the semantic anomalies of UML.  For example, the ArchiMate Specialization relationship indicates that the client "specializes" the supplier.  Similarly, for the Aggregation relationship, the client "aggregates to".  The (binary) Association relationship is a special case, since it is a restriction on the N-ary relationship which consists of "n" AssociationEnds - each of which is directional.

I've found, over the decades, that thinking in terms of origin and destination clarifies what needs to be done in any case.

Paolo

[robinch]

KP, Paolo,

Thank you for you explanations. I totally agree on subject of source/target/client/supplier/etc., my apologies for fueling this lengthy discussion about terminology which unfortunately lies a bit off topic. I'll try one more attempt to explain what I am after.

As illustrated in the picture hopefully accessible through the link below, I have created a class Car which has a part of class Engine, represented by a composite relationship between the two classes, with the black diamond at Car end.

https://drive.google.com/file/d/1GE1711Fwd1mB_Q5Tdgqm3zxWjKQHLlKutw/view?usp=sharing

Now, looking at the properties of this relationship, in the Role(s) tab, you see that the Navigability property is set to Non-Navigable at the Engine end whereas it is set to Navigable at the Car end, meaning that the resulting links are navigable from the Engine to the Car but not from the Car to the Engine. What I am trying to say is that this is in general wrong for aggregations.

Hope this clarifies the purpose of my initial request. Anyway, many thanks to everyone for your valuable inputs, much appreciated.

Robin

[qwerty]

Hmm. Intersting. Smells buggy. Especially if you set both to navigable since in that case you see both arrows. You should report a bug.

q.

[qwerty]

It depends on the connector type.

Yes. They are specializations. But EA has the source/target concept burned in its basic connector concept.

I can well live with that (since I have my brain to cut that out). But obviously it now leads to confusion. In my script wrappers I replaced the source/target concept since a long time with an opposite concept (which itself neglects the ..* part in the multiplicity).

q.

[Paolo F Cantoni]

Hmm. Intersting. Smells buggy. Especially if you set both to navigable since in that case you see both arrows. You should report a bug.

q.

I will admit that the whole question of navigability has ALWAYS (for at least 2 decades) been problematic for me, coming from a database background and dealing principally with enterprise objects in the non-DB space.  This is because if a link (such as a FK Constraint) is navigable in one direction, it must, ipso facto, be navigable in the other.

However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Paolo

[qwerty]

However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Paolo

Can your body ignore the hand that wrote this sentence?

q.

[robinch]

However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Paolo

Can your body ignore the hand that wrote this sentence?

Or, to put it another way, Paolo are you suggesting that, for instance, if I design a class "polygon" (whole) containing an instance of "std::vector<point>" (part) then instances of my "polygon" are not supposed to navigate to their vector of points but rather I should ask the C++ standard to add a reference to my "polygon" class in their definition of "std::vector<T>"? Does not sound very practical to me...

[Eve]

For the record. Navigability in UML is really a very weak constraint.

Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.

Furthermore, UML does not intend that you can derive navigability from aggregation.

Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.

Although that's a weaker statement than was found in UML 2.4.1, which described them as orthogonal concepts. A correction that I'm glad to see that they have made.

For a relational database the natural navigability is from the part to whole, but it's not hard or even less efficient to navigate the other way.

For code it's usually the other way around. The relationship is usually owned by the whole, and efficient access from the part to the whole requires something extra to be added.

For a conceptual model, the concept of navigability would either be inappropriate or extremely flexible.

[qwerty]

I found navigability always rather useless. As long as you are on a top level you just want to know that there IS a connection. Once you apply roles in the design you know that there must be navigability. Performance issues are from then on part of the whole system design.

q.

[Glassboy]

However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Paolo

Can your body ignore the hand that wrote this sentence?

q.

This doesn't parse as a sentence for a number of reasons, but mostly because bodies aren't sentient.

[qwerty]

This doesn't parse as a sentence for a number of reasons, but mostly because bodies aren't sentient.

So the first word "This" in the sentence you wrote: what does this "This" refer to? The word itself? Then true. A single word "This" is not a sentence. Does it refer to the sentence I wrote? Well, I'm not a native English speaker, but I think it is a sentence. Or maybe that's some kind of joke on a level I don't understand :-?

q.

[KP]

However, using meronomy theory, it seems to me that the meronym (part) needs to know where to find its holonym (whole), whereas the whole can ignore the part - hence the navigability provided.

Paolo

Can your body ignore the hand that wrote this sentence?

q.

This doesn't parse as a sentence for a number of reasons, but mostly because bodies aren't sentient.

Looks fine to me. Not only is it correct English, but it also effectively communicates disagreement with the quoted text and explains the reason, all in a very concise 10 words.

[RoyC]

I think Glassboy has picked up on it because it suggests a BIOLOGICALLY incorrect proposition. A body cannot 'ignore' a hand. That elusive entity called the human mind might choose to ignore chemical signals issuing from receptors in the hand, but the body itself has no capacity to make a decision to 'ignore' those signals. And in fact the major portion of the body has no capacity to receive such signals from the hand.  I could go on, but I think it just comes down to making the point using concepts that are meaningful.

Plus, the sentence refers to Paolo's body ignoring qwerty's hand... let's just stop there.