Sparx Systems Forum
Enterprise Architect => Suggestions and Requests => Topic started by: robinch on November 10, 2015, 08:37:10 pm
-
Hi,
By default, EA creates relationships which are navigable from the source to the target. Unfortunately, for aggregation/composition/containment (and perhaps other) relationships, the definition of the source & target elements are the opposite of what we would intuitively expect, e.g. for composition the whole is the target and the part is the source, thereby creating a relationship which is navigable from the part to the composite by default. However, in most cases, a composition defines links which are navigable from the whole to the part.
Instead of having to manually undo the default navigability, I wish EA could either define relationships which by default are navigable from target to source for these cases or even just leave the navigability undefined in both ends.
(Using EA 12.0.1215, same behavior observed in previous versions)
-
Hmm. EA offers to create them in both directions when choosing from the quick linker.
q.
-
Yes, it is possible to select the gesture direction but the diamond (or "+ in a circle" in case of a composite relationship) is always set at the target of the relationship and the navigable end is therefore always set at the diamond end of it.
Basically you can choose to draw from target to source or from source to target but it does not change the final result, model-wise.
-
In UML aggregations don't have a source or target. It's better to read them that way despite the fact that in EA they do.
You can swap the aggregation easily enough, including defining it on an association. That may create unintuitive behavior in other areas such as locking though.
-
True, it is possible to create association first and define an end as an aggregation afterwards. However, EA groups the target ends when using tree style representations, so the notion of source & target ends cannot be completely ignored.
My suggestion was more to not assign navigability by default than to find a workaround. Pepole usally use the fastest way to create relationships (quick linker comes first) but they do not always remember to unset the navigability at the target end. And all those links with inverted navigability look very odd in reports.
-
I think you can turn the default navigability on and off in the options.
But I agree with you. It feels wrong to always have the source at the part and the target at the whole end, even though in UML these notions (source/target) don't exist.
Geert
-
I think you can turn the default navigability on and off in the options.
Thanks Geert, that would be quite useful to us. The only one I found is the tick box "Links->General->Association default = source-->target" and made sure it is not ticked, but aggregation/composition/... relationships still get the inverted navigability. Perhaps there is another option somewhere (EAUI I think it is called here)? I'll have a look.
-
That was the option I was referring to. I expected it to control the navigability in the aggregations as well.
Geert
-
That was the option I was referring too. I expected it to control the navigability in the aggregations as well.
Ok, thanks. I'll stop searching then :).
-
See http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1447767256/4#4
I wrote a little script that switches source and target to make sure the composite end is always on the source.
Geert
-
Hi Geert,
I wrote a little script that switches source and target to make sure the composite end is always on the source.
Thanks for the link, I will definitely have a look into it. I am still pondering whether changing the source<->target ends or just inverting the navigability attributes is the best.
Apparently, when using tree style representations, EA always considers the target ends as the tree root and the source ends as the tree leaves (works well with e.g. generalization relationships). However, most of the times we are using tree style representations for aggregation-like relationships, the root is actually at the diamond ends, hence requiring the diamonds to be kept at the target ends.
-
Hi Rob?,
It is now (fairly) common modelling convention that relationships are drawn from the client (origin) end to the supplier (destination) end. This provides "directionality". Navigability on the other hand, is about the ability to traverse the relationship to the navigable end. EA conflates Directionality and Navigability. However, if you apply the convention above, it doesn't really matter.
For the majority of relationships, the end with a glyph (Arrow, Triangle, Lozenge etc.) is at the supplier end. In the case of aggregation, EA allows you to determine which way you like to "Draw" as opposed to "Store" aggregations. The combination of the directionality of your drawing and the [] Draw Aggregations Reversed option, allow you to "choose your poison". If you prefer to draw an aggregation from the meronym to the holonym, keep the option box unchecked. If you like to draw from the holonym to the meronym, then check the box. Either way, you end up with the lozenge at the supplier (destination) end.
HTH,
Paolo
-
Apparently, when using tree style representations, EA always considers the target ends as the tree root and the source ends as the tree leaves (works well with e.g. generalization relationships)
Robin,
I'm pretty sure tree style is not UML compliant for associations. The problem is that you then don't have a place to put your multiplicity/rolename etc.. anymore.
This is different from things like a Generalization or Realization where there are no properties at the relationship end.
I would advise against using it for associations.
Geert
-
Hi Paolo, Geert,
It is now (fairly) common modelling convention that relationships are drawn from the client (origin) end to the supplier (destination) end. This provides "directionality". Navigability on the other hand, is about the ability to traverse the relationship to the navigable end. EA conflates Directionality and Navigability. However, if you apply the convention above, it doesn't really matter.
Not sure to understand what you mean by "it doesn't really matter". My initial request was to change the default behavior of having navigability towards the end with the diamond because, usually, this end is at the client side. A concrete example would be, say, a C++ application class containing an std::vector<T>. The diamond would be at the application class end and obviously navigability should go from the application class to the vector<T> rather than the opposite.
For the majority of relationships, the end with a glyph (Arrow, Triangle, Lozenge etc.) is at the supplier end.
This is where I tend to disagree, perhaps because I am missing something, what you are saying stands for simple dependencies (Arrow) and generalizations/realizations (Triangle). For diamonds, it is exactly the opposite, i.e. the diamonds are at the client ends rarther than the supplier ends. Therefore, EA systematically assigning navigability to the target end of relationships is not optimal in my opinion.
I'm pretty sure tree style is not UML compliant for associations. The problem is that you then don't have a place to put your multiplicity/rolename etc.. anymore.
This is different from things like a Generalization or Realization where there are no properties at the relationship end.
I would advise against using it for associations.
Makes a lot of sense, very good advice which I will follow to the letter.
Robin
-
OK, so a little bit of history. UML 1.5 specification, page 2-22, said the following about "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 clearly stated that the end with the diamond was the target, and that is how we implemented it, i.e. correctly. Then when UML 2 came along and didn't even have a metaclass for aggregation or composition, there didn't seem to be a case for changing it, so we didn't.
My advice to anyone who is concerned about the directionality of aggregations and compositions would be to use associations instead. They are essentially non-directional, and you can draw them in whichever direction you like.
-
UML 2.5 does no longer have source and target. It has 2..* ends.
q.
-
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.
-
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
-
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
-
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.
-
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.
-
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
-
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
You'll have to forgive me, I was indirect as I didn't want you to perceive it as a personal attack. RoyC is part way there, although a human mind doesn't directly perceive any transmitters just that the receivers are turned on :-)
Your sentence contained both pronoun confusion and an incorrect proposition. (I wanted to post a link to Olivia Colman demonstrating with dolls from I Give It A Year, but the only imagine I could find was NSFW.)
And now that I scan back through the thread I am less than clear what ownership means, and whether there is an axiom that states a relationship can only have one owner. I'm sure if I proposed that to my wife she'd become tearful whereas my ex would state it was a fundamental principle of human social relationships.
-
I think that the only area where ownership of relations is of interest is memory management (so on a very low level). Only if you have a picture about who owns which relation you can safely deallocate objects. This is the only area where I think it might be of importance. Else I cant imagine a meaningful concept that puts meaning on "ownership of relations".
q.