"With loss of generality" - <stereotypedrelationships>

[Paolo F Cantoni]

Many of you will have heard me use the phrase "without loss of generality".   It's a mathematical term used in proofs to indicate that an assumption is being made that does not introduce new restrictions to the problem.

Note: this defect was discovered because I was "handcrafting" the MDG, but I believe it may be exposing some underlying issues.

We have a "root" metatype used to define the "highest level" of common relationships for the QuickLinker:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>
</stereotypedrelationships>
As you might be able to infer, Aggregation, Composition, Inheritance, Restriction and Specialization.  In this case to "self" (ala ArchiMate).

So I wanted to add that a composition relationship also exists between any vertex and a "Composite Vertex" and an aggregation relationship exists to an "Aggregate Vertex."
Naturally, I added:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>

<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="MyProfile::AggrgtVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="MyProfile::CmpstVrtx"/>
</stereotypedrelationships>
I tried the new MDG and voila!  I got composition relationships to any CmpstVrtx (Composite Vertex) and aggregation relationships to any AggrgtVrtx (Aggregate Vertex) in the QuickLinker.  Great!
Imagine my surprise when I subsequently discovered that the "self" aggregation and composition relationships had disappeared from the QuickLinker!

Some hours of diagnostic testing over the weekend has revealed that with this syntax, "the last cab off the rank get the guernsey"!  In the example above, the MDG seems to scan the list of inputs and each subsequent definition of the same stereotype will overwrite the previous.  Thus for this version, you get the behaviour reported.  If you switch the order and place the CmpstVrtx and AggrgtVrtx BEFORE the source.metatype.both, you'll get the opposite behaviour.  "Self" works, but the others don't!

The "correct" syntax seems to be:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Aggrgtn" constraint="source.metatype.both;MyProfile::AggrgtVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Cmpstn" constraint="source.metatype.both;MyProfile::CmpstVrtx"/>
<stereotypedrelationship stereotype="MyProfile::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="MyProfile::Spclztn" constraint="source.metatype.both"/>
</stereotypedrelationships>
Where the additional stereotypes are appended.

However, it seems to me that "without loss of generality", both syntaxes should yield the same results!  So I'm reporting the defect!

Paolo

[Eve]

Yes, Enterprise Architect will only generate the latter form and will not accept the former.

There is no "should". If you are hand modifying something it is your responsibility to put it in the correct format.

[Paolo F Cantoni]

Yes, Enterprise Architect will only generate the latter form and will not accept the former.

There is no "should". If you are hand modifying something it is your responsibility to put it in the correct format.

Well, I know that in this particular case Enterprise Architect will generate this output from my model, but I'm NOT aware that it will always generate the "correct" output from a conceptually equivalent but differently specified model.

But my "defect" is not about generation, it's about acceptance.  As far as I'm aware, there is NO requirement that the MDG be specified using the MDG generation technology, and a number of users, myself included, have generated MDGs by other means.   If that is no longer a valid approach, please say so.

Surely, you will concede that having multiple specifications overwrite each other within the same section is conceptually spurious!  Why on earth would anyone want that?  Would the instances being additive be a more likely use case?  Particularly, in the light of the "correct" answer, where both conceptually and physically we have created an additive specification.

Can you point me to the documentation that says that the "correct" format is indeed so?

Paolo

[Eve]

I can't point you to a specification of what the "correct" format is. That's because the assumption has always been that it will be consuming what EA has generated. We specify how to create it in your model, not what the file needs to look like. Nothing has changed in that area. If you choose to create a file yourself, it is your responsibility to emulate what EA would have generated.

Given bad input the behavior is undefined¹. As long as Enterprise Architect hasn't crashed or hung on that input I don't see why development and testing effort should be redirected² away from where they are allocated.

¹ a word that has been used in computing to describe the result of invalid inputs from the start.
² those things are a finite resource. Looking at this would come at a cost to another area.