v16.1 - Composition Links will not allow constraint into Middle Bottom Label

[Paolo F Cantoni]

We manage connector labels in our shapescripts.  In particular, we place the contents of the SourceConstraint column into the Middle Bottom Label.  This worked for all the connector types we used, including general Associations.  However, when we tried to do the same to "Composition" relationships (Associations with AggregationKind set to Composite), we couldn't set the content value into the Middle Bottom Label!

By default, the Source Constraint appears in the Left Bottom Label (and that is understandable); however, we can't understand why it is (apparently) prohibited to use the value in any other label (should we wish to override it for that particular metatype).

Can anyone suggest a rationale, or is it just a defect?

Paolo

[Modesto Vega]

I wonder if it has something to do with directionality, compositions are directional source to target.

[Paolo F Cantoni]

I wonder if it has something to do with directionality, compositions are directional source to target.

That's not relevant to my argument.
Notwithstanding that Sparxians have conflated directionality and navigability, this is how shapescripts must work.  If I specify the contents of a label, I expect that to be rendered.   I can render any other content (that we tested) for the Middle Bottom Label, but when we say print("#source.constraints#"); it won't print except in the Left Bottom Label.  It works fine for all other connector types we tested, including Generalizations, which are just as directional as Compositions.

Paolo

[Modesto Vega]

I knew I was stretching it. When you use the term "composition links" do you mean connectors?

I also cannot work out by there are so many labels, 8, supported for connectors and what is the purpose of each.

[Paolo F Cantoni]

I knew I was stretching it. When you use the term "composition links" do you mean connectors?

Yes, I mean a composition relationship between two instances (but the problem is the same for normal Composition Relationships).  In our MDG, we use a different mechanism for connections between instances, not classifiers, than the use of UML::Connectors vs UML::Associations.  Both are of the same type, a different stereotype determines if it connects instances or classifiers/placeholders.

I also cannot work out by there are so many labels, 8, supported for connectors, and what is the purpose of each.

Well, there are many things that need to be rendered according to the UML standard.  In fact, there probably aren't enough  - because they were denoted by position, not by use.  Thus under some circumstances, they have to overload the label with multiple properties, much to our annoyance.  So we decided to take over label management for our metatypes - which has proved useful until now!

Paolo