Abstract metatypes won't automagically generate <stereotypedrelationships> for a

[Paolo F Cantoni]

We've been using supplementary metatypes to automagically generate <stereotypedrelationships> (rather than needing to explicitly specify them at the concrete metatype level).  It's pretty good!  (some "niggles" notwithstanding - see:"With loss of generality" - <stereotypedrelationships>)

An example is:

Code: [Select]

<Stereotype name="SrvdItm" metatype="Served (item)" notes="Can have an inbound Serving relationship" isAbstract="true" generalizes="Root" baseStereotypes="Root">
</Stereotype>
<Stereotype name="CnSrvItm" metatype="Can Serve (item)" notes="Can have an outbound Serving relationship" isAbstract="true" generalizes="Root" baseStereotypes="Root">
<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::SrvdItm"/>
</stereotypedrelationships>
</Stereotype>
Here, two supplemental metatypes are defined that define whether an item (typically a vertex) can generate an outbound or receive an inbound serving relationship.

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).

By assigning the appropriate metatype to the appropriate vertex, EA will automatically create the QuickLinker entries for the serving relationship!   REALLY neat (and tremendously useful)!!!   

For example:

Code: [Select]

<Stereotype name="Hrdwr" metatype="Hardware" generalizes="ClssVrtx" baseStereotypes="ClssVrtx CnSrvItm">
and...
<Stereotype name="Systm" metatype="System" generalizes="ClssVrtx" baseStereotypes="ClssVrtx CmpstItm AggrgtItm CnFlwItm FlwblItm AccssblItm SrvdItm">
(As can be seen, "System" is a complex vertex!)
Will generate the QuickLinker entry that Hardware "serves" a System.

However, when we apply the supplemental metatypes to an Arc, the QuickLinker entries are NOT created!   

Code: [Select]

<Stereotype name="Flow" metatype="Flow" generalizes="Root" basestereotypes="Root CnSrvItm">
and...
<Stereotype name="ETLJob" metatype="ETL Job" generalizes="ClssVrtx" baseStereotypes="ClssVrtx SrvdItm">
"A flow can serve an ETL job"
      
To get the entries, we have to add an explicit <stereotypedrelationships> to "Flow":

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::ETLJob"/>
</stereotypedrelationships>

This looks like a defect to me, but since I'm still "handcrafting" I may have missed something.

Can anybody shed any light as to whether it's a defect or my bad handcrafting?  (Actually, I checked via a test metamodel and it generates¹ this definition)

TIA,
Paolo

¹ It actually generates a slightly (but not substantively) different specification!    The baseStereotypes are always in ascending alphabetical order and the generalizes attribute is always the first alpha stereotype!  (who dreamt that one up?)

[Eve]

Easy question first.

¹ It actually generates a slightly (but not substantively) different specification!    The baseStereotypes are always in ascending alphabetical order and the generalizes attribute is always the first alpha stereotype!  (who dreamt that one up?)

Connectors (unfortunately) are not an ordered relationship. I don't know why EA needs both generalizes and baseStereotypes. What I do know is that prior to it being being explicitly alphabetically ordered the order was unstable. It created a lot of extra work when generating a large technology and reviewing the changes. (Also for tagged value connectors and the three metamodel constraints.

I hope you can agree that any defined order is better than no defined order.

In terms of your actual issue...

Am I correct in my understanding that stereotypes extending EA relationship types aren't inheriting their constraints? Is it just with multiple inheritance or does it fail for all inherited constraints?

[Paolo F Cantoni]

Easy question first.

¹ It actually generates a slightly (but not substantively) different specification!    The baseStereotypes are always in ascending alphabetical order and the generalizes attribute is always the first alpha stereotype!  (who dreamt that one up?)

Connectors (unfortunately) are not an ordered relationship. I don't know why EA needs both generalizes and baseStereotypes. What I do know is that prior to it being explicitly alphabetically ordered the order was unstable. It created a lot of extra work when generating a large technology and reviewing the changes. (Also for tagged value connectors and the three metamodel constraints.

I hope you can agree that any defined order is better than no defined order.

In terms of your actual issue...

Am I correct in my understanding that stereotypes extending EA relationship types aren't inheriting their constraints? Is it just with multiple inheritance or does it fail for all inherited constraints?

(my emphasis)Yes, indeed! A defined order is better than no order.  As I have been wont to say "it's better to be consistently wrong (the current situation) than inconsistently wrong (the previous situation)" 

As to your question about constraints.  I'm not sure if constraints are the issue.  If both ends of the (potential) serving relationship are vertices, the QuickLinker works fine (with only the abstract definitions in play - have I explained it correctly?).  If one end is an arc, it doesn't.  Since I posted the original snippet, I've found that:

Code: [Select]

<stereotypedrelationships>
<stereotypedrelationship stereotype="MyProfile::Srvng" constraint="MyProfile::SrvdItm"/>
</stereotypedrelationships>
also works when added at the arc.
To me, it seems like EA is just ignoring the abstract definition with the multiple inheritance and so I have to materialize it at the concrete arc.

Paolo