Metatypes - multiple inheritance precedence order?

[Paolo F Cantoni]

When creating metatypes in the MDG, we can have multiple-inheritance.  When generated by the MDG Generator, the order of the base stereotypes is alphabetic.

However, since there may be multiple paths to the new metatype, what is the precedence order of applying properties, constraints etc?  For example if one path implies _HideUmlLinks=false and another implies _HideUmlLinks=true, which takes precedence?

TIA,
Paolo

[Eve]

If you have multiple paths to a metatype... rearrange your hierarchy.

[Paolo F Cantoni]

If you have multiple paths to a metatype... rearrange your hierarchy.

Isn't that how you organise supplemental stereotypes?

"This metatype is a Class, 'a Composite', 'Can compose into' and 'Servable'"  The first is a metaclass, the others are supplemental stereotypes.  I'm talking about the multiple supplemental paths, not the main path derived from the metaclass.

Paolo

[Modesto Vega]

If you are saying that you want to have 1 stereotype, let's call it 'A', extending both a Class and an Activity metaclass. I suggest that you may be creating a problem for yourself. When extending Sparx, my experience is that it is better to create a tree with the metaclasses at the top and not an inverted tree. In other words,

It is better to do
<<metaclass>> Class
----<<stereotype>>A
<<stereotype>>Activity
----A (a different stereotype)

than
<<stereotype>>A
-----<<metaclass>> Class
-----<<stereotype>>Activity

I know Sparx allows it but this does not mean it is a good idea to extend this way.

[Paolo F Cantoni]

If you are saying that you want to have 1 stereotype, let's call it 'A', extending both a Class and an Activity metaclass. I suggest that you may be creating a problem for yourself. When extending Sparx, my experience is that it is better to create a tree with the metaclasses at the top and not an inverted tree. In other words,

It is better to do
<<metaclass>> Class
----<<stereotype>>A
<<stereotype>>Activity
----A (a different stereotype)

than
<<stereotype>>A
-----<<metaclass>> Class
-----<<stereotype>>Activity

I know Sparx allows it but this does not mean it is a good idea to extend this way.

No Modesto, I'm NOT saying that.  For the present, we have no multi-metaclass metatypes.

The supplemental stereotypes have NO metaclass assigned, as advised by Eve (and we'd already come to the same conclusion).

We intend to use the supplemental stereotypes to assign properties and behaviours to the basic metatypes as required.

From what we are seeing, it seems a most powerful mechanism assuming it works as it should.

Paolo

[Modesto Vega]

If you are saying that you want to have 1 stereotype, let's call it 'A', extending both a Class and an Activity metaclass. I suggest that you may be creating a problem for yourself. When extending Sparx, my experience is that it is better to create a tree with the metaclasses at the top and not an inverted tree. In other words,

It is better to do
<<metaclass>> Class
----<<stereotype>>A
<<stereotype>>Activity
----A (a different stereotype)

than
<<stereotype>>A
-----<<metaclass>> Class
-----<<stereotype>>Activity

I know Sparx allows it but this does not mean it is a good idea to extend this way.

No Modesto, I'm NOT saying that.  For the present, we have no multi-metaclass metatypes.

The supplemental stereotypes have NO metaclass assigned, as advised by Eve (and we'd already come to the same conclusion).

We intend to use the supplemental stereotypes to assign properties and behaviours to the basic metatypes as required.

From what we are seeing, it seems a most powerful mechanism assuming it works as it should.

Paolo

Which version are you suing v15.1 or the v15.2 beta?

[Paolo F Cantoni]

v15.2 beta

Paolo

[Modesto Vega]

Could you please describe with an example what you are trying to do and how are you linking a metaclassless supplemental stereotype to a tag or an stereotype extending a metaclass?

P.S.: I cannot visualise what you are trying to do.

[Paolo F Cantoni]

Here you go, Modesto,
(with the proviso that this is hand-crafted)

Code: [Select]

<Stereotype name="Root" metatype="Root (Concept)" notes="" cx="120" cy="220" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0" isAbstract="true">
<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Aggrgtn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::AggrgtnLnk" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::CmpstnLnk" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::Inhrtnc" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::Rstrctn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::Spclztn" constraint="source.metatype.both"/>
<stereotypedrelationship stereotype="PrIME::Trnstn" constraint="source.metatype.both"/>

<stereotypedrelationship stereotype="PrIME::Assctn" constraint="PrIME::Root"/>
<stereotypedrelationship stereotype="PrIME::AssctnLnk" constraint="PrIME::Root"/>
<stereotypedrelationship stereotype="PrIME::AssctnEnd" constraint="PrIME::Root"/>
<stereotypedrelationship stereotype="PrIME::AssctnEndLnk" constraint="PrIME::Root"/>

<stereotypedrelationship stereotype="PrIME::CncptlDfntn" constraint="PrIME::Cncpt"/>
<stereotypedrelationship stereotype="PrIME::CncptlInvlvmnt" constraint="PrIME::Cncpt"/>

</stereotypedrelationships>
</Stereotype>
<Stereotype name="Spplmntl" metatype="Supplemental" notes="" isAbstract="true" generalizes="Root" baseStereotypes="Root">
</Stereotype>
<Stereotype name="Vrtx" metatype="Generic (vertex)" notes="" isAbstract="true" generalizes="Root" baseStereotypes="Root">
</Stereotype>
<Stereotype name="ClssVrtx" metatype="Class (vertex)" notes="" cx="148" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0" isAbstract="true" generalizes="Vrtx" baseStereotypes="Vrtx">
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="true"/>
</Apply>
</AppliesTo>
</Stereotype>

<Stereotype name="Hlnymc¯S" metatype="Holonym (supplemental)" notes="The base abstract item for Holonomies (meronymies)" isAbstract="true" generalizes="Spplmntl" baseStereotypes="Spplmntl">
<TaggedValues>
<Tag name="IsHolonym" default="True"/>
</TaggedValues>
</Stereotype >
<Stereotype name="Cmpst¯S" metatype="Composite (supplemental)" notes="Can have an inbound Composition or CompositionLink relationship" isAbstract="true" generalizes="Hlnymc¯S" baseStereotypes="Hlnymc¯S">
<TaggedValues>
<Tag name="IsComposite" default="True"/>
</TaggedValues>
</Stereotype >
<Stereotype name="CnCmps¯S" metatype="Can Compose (into) (supplemental)" notes="Can have an outbound Composition or CompositionLink relationship" isAbstract="true" generalizes="Spplmntl" baseStereotypes="Spplmntl">
<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Cmpstn" constraint="PrIME::Cmpst¯S"/>
<stereotypedrelationship stereotype="PrIME::CmpstnLnk" constraint="PrIME::Cmpst¯S"/>
</stereotypedrelationships>
</Stereotype>

<Stereotype name="Srvbl¯S" metatype="Servable (supplemental)" notes="Can have an inbound Serving relationship" isAbstract="true" generalizes="Spplmntl" baseStereotypes="Spplmntl">
</Stereotype>
<Stereotype name="CnSrv¯S" metatype="Can Serve (supplemental)" notes="Can have an outbound Serving relationship" isAbstract="true" generalizes="Spplmntl" baseStereotypes="Spplmntl">
<stereotypedrelationships>
<stereotypedrelationship stereotype="PrIME::Srvng" constraint="PrIME::Srvbl¯S"/>
</stereotypedrelationships>
</Stereotype>
<Stereotype name="DBSrvr" metatype="DB Server" notes="" cx="50" cy="50" bgcolor="15658671" fontcolor="16711680" bordercolor="13387839" borderwidth="2" hideicon="0" generalizes="ClssVrtx" baseStereotypes="ClssVrtx Cmpst¯S Srvbl¯S">
</Stereotype>
(We name our stereotypes by exi=cising the vowels - that stay we don;t conflict with anything much.

If you follow the hierarchies, you'll see that a DB Server is defined as a class that its always a composite, and can have inbound serving relationships.

All the appropriate properties and behaviours are automagically included.  That's why it's vital that this stuff works.  IT is REALLY, REALLY powerful for creating consistent modelling technologies.

Any questions, feel free...
Paolo