v15.2 – Specific stereotyped relationship obliterates more general

[Paolo F Cantoni]

Many of you will be aware that we are using a highly structured metamodel to do (seemingly) magical things with our MDG.  In the past, I have waxed somewhat lyrical concerning how well the mechanism hangs together.  Today, I'm afraid I'm going to hand out a BIG brickbat!

So, using the ArchiMate concept of anything can compose into itself, we have a root definition:  Stereotype "R"

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="source.metatype.both"/>
</stereotypedrelationships>
Things work fine over many of the specialized stereotypes:
i.e.   B1 Composes to B2 etc. Q3 composed to Q5 etc.
   
Then one day I notice that C1 won't compose to C2.  HOURS of debugging reveals that the problem was that stereotype "C" ALSO had a composition relationship to stereotype "D".
Stereotype C had the following in its specification:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="PrIME::D"/>
</stereotypedrelationships>
When we created the composition to "D" in the model we were assuming we were saying:
"In addition to composing to itself, C can also compose to D".

Turns out, that's NOT what happens...
What is implemented is: "Instead of composing to itself, C can ONLY compose to D".

That is, the specific stereotyped relationship obliterates the more general.

This has to be a defect in the mechanism, yes?  If it's NOT, how do I create what we were after?

Thoughts?
Reported,
Paolo

[Eve]

Yes, it's intentional that a specialized class can override/replace the behavior from the superclass. I'm sure you can think of reasons why that has to be possible.

Overriding all allowed targets on any relationship specified was the means we used to allow that behavior. To keep the superclass relationships in the past I have recreated them.

Although it occurs to me that it may be possible/safer to use multiple inheritance from an abstract superclass to add the added behavior.

[Paolo F Cantoni]

Yes, it's intentional that a specialized class can override/replace the behavior from the superclass. I'm sure you can think of reasons why that has to be possible.

Overriding all allowed targets on any relationship specified was the means we used to allow that behavior. To keep the superclass relationships in the past I have recreated them.

Although it occurs to me that it may be possible/safer to use multiple inheritance from an abstract superclass to add the added behavior.

(my emphasis)
Yes, we had already found that "work-around" for this particular case.  But that doesn't scale and makes the metamodel vastly more complex than it has to be; not to mention much more difficult to maintain!

It occurred to me as I posted that this is an example of the problem I addressed in How to show features need to be removed in an inheritance (specialization)? (the original post, not the excursion by q and myself into Meyer's book).
It seems to me that the addition of a modifier to the specific stereotyped relationship would allow the use-cases we might need.

I'm going to think about the issue (in the context of the other post) and come back later.

I also have a feeling that there might be another solution, but I need to think about it also (and run some tests).

I DO feel that it is important that this is addressed as it can really make the mechanism both flexible and scalable (and thus much easier to maintain)!

Would it be possible, Eve, for you to describe the use cases that have been considered?

Paolo

[Eve]

The examples I have come from UML relationships. Generally an association can be between any two types. However, for an Actor it's restricted to a subset of those.

A specialized connector can also override the behavior from the parent. A dependency can be between any two NamedElements, but the specialization InterfaceRealization is between a Type and and Interface.

In short, it took effort to allow a specialized class to override the set of available targets for a relationship. You may not like the result, but it is intentional.

[Paolo F Cantoni]

The examples I have come from UML relationships. Generally, an association can be between any two types. However, for an Actor, it's restricted to a subset of those.

A specialized connector can also override the behaviour from the parent. A dependency can be between any two NamedElements, but the specialization InterfaceRealization is between a Type and an Interface.

In short, it took an effort to allow a specialized class to override the set of available targets for a relationship. You may not like the result, but it is intentional.

(my emphasis)
The initial post says that. 
BTW, I agree with the intention ("allow a specialized class to override the set of available targets for a relationship") but not the implementation.
The response from Sparx Support states:
"At each level of inheritance, a single constraint is specified from the list of stereotyped relationships they have. That set is inherited by specialized stereotypes until one of those overrides it."  While awaiting the response from both you and Support, it occurred to me that creating a synthetic target such as "inherited.metatypes" could signal that the inherited metatypes should still be allowed (similar to source.metatype.both).
Since :

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="PrIME::D;PrIME::E"/>
</stereotypedrelationships>says that a Cmpstn can be between C and either/both D or E...

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="inherited.metatypes;PrIME::D;PrIME::E"/>
</stereotypedrelationships>could say that a Cmpstn is additive, for C.  (in this particular case, inherited.metatypes translates to source.metatype.both but is more general, picking up any additional metatypes "along the way".

Thoughts, specifically for Eve, but anyone can "chime in"?
Paolo

[Edit:  you could even allow...

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="inherited.metatypes;PrIME::D;-PrIME::E"/>
</stereotypedrelationships>To control that even if normally C could compose to E (by inheritance) we want to exclude E from the list!
Just (another) thought]

[Edit2:  AS I was dropping off to sleep, I realised that under this syntax:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="-inherited.metatypes;PrIME::D;PrIME::E"/>
</stereotypedrelationships>would suppress the inherited metatypes explicitly.]

[Eve]

I don't hate the idea of something like "inherited.metatypes".

I don't think you're likely to see a change in the default behavior. My opinion on that is that it is likely to break something, for a questionable benefit.

Adding an explicit negation would require a new relationship type, (or a boolean on the existing ones). The tricky part of that is that we did take this notation from an existing standard. This takes it firmly into the scenario of abandoning that stance.

[Paolo F Cantoni]

I don't hate the idea of something like "inherited.metatypes".

I don't think you're likely to see a change in the default behavior. My opinion on that is that it is likely to break something, for a questionable benefit.

Adding an explicit negation would require a new relationship type, (or a boolean on the existing ones). The tricky part of that is that we did take this notation from an existing standard. This takes it firmly into the scenario of abandoning that stance.

(my emphasis)
Since I'm not familiar with that part of the standard, I can't comment.  (would appreciate a synopsis of how it comes about).

My reading of "At each level of inheritance, a single constraint is specified from the list of stereotyped relationships they have. That set is inherited by specialized stereotypes until one of those overrides it." is that if we can stop the explicit creation of a stereotyped relationship at the concrete metatype  (in our example:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="PrIME::D;PrIME::E"/>
</stereotypedrelationships> NOT generate this explicit output, but inherit the equivalent, then the default behaviour wouldn't interfere.  Have I understood that correctly?

If so, what happens with multiple inheritance?  A union?

Paolo

[Eve]

If so, what happens with multiple inheritance?  A union?

It didn't act as a union when I tried it. I didn't investigate beyond that.

I suspect the worst, it obeys one undefined superclass.

[Paolo F Cantoni]

If so, what happens with multiple inheritance?  A union?

It didn't act as a union when I tried it. I didn't investigate beyond that.

I suspect the worst, it obeys one undefined superclass.

(my emphasis)
AFAIK, the documentation doesn't preclude multiple inheritance.
Consequently, is this a defect?

Paolo

[Paolo F Cantoni]

[SNIP]
AFAIK, the documentation doesn't preclude multiple inheritance.
Consequently, is this a defect?

Paolo

<===  THIS!

Paolo