V15 - MDG Technology MeaningBackwards / Forwards attributes on metaclasses

[rgupta4]

I am creating a MDG Tech for a custom meta-model. If I create a connector and inherits from a standard UML meta-type (like Association) and add _MeaningBackwards & _MeaningForwards attributes to the metaclass these values will appear in quick link menus. If I create a connector and inherit from a non UML type like an Archimate connector which then in turn extends form a standard UML meta-type (like Association) and add the above attributes to either the parent meta-class or the the archimate stereotype I am unable to get the values assigned to the above attributes to appear in quick link menus.
Am I doing something wrong? Is this expected behavior? Is there a workaround?

[Paolo F Cantoni]

I am creating an MDG Tech for a custom meta-model. If I create a connector and inherits from a standard UML meta-type (like Association) and add _MeaningBackwards & _MeaningForwards attributes to the metaclass these values will appear in quick link menus. If I create a connector and inherit from a non-UML type like an ArchiMate connector which then in turn extends from a standard UML meta-type (like Association) and add the above attributes to either the parent meta-class or the the ArchiMate stereotype I am unable to get the values assigned to the above attributes to appear in quick link menus.
Am I doing something wrong? Is this expected behaviour? Is there a workaround?

I'm also interested in this mechanism.  Elsewhere, I've expressed the view that _MeaningBackwards & _MeaningForwards are incorrectly assigned to the metaclass rather than the stereotype itself.  I'll be testing an abstract hierarchy for arcs (I've got one working - more or less - for vertices - after some pointers from Sparxian Eve) shortly and I'll report my findings.  Since the abstract hierarchy involves inheritance via stereotypes and not metaclasses, I'm not sure how the _MeaningBackwards & _MeaningForwards will be correctly propagated.

Paolo

[Eve]

Since the abstract hierarchy involves inheritance via stereotypes and not metaclasses, I'm not sure how the _MeaningBackwards & _MeaningForwards will be correctly propagated.

I'd recommend defining an extension only for your concrete metaclasses. (And extension is not inheritance)

[Paolo F Cantoni]

Since the abstract hierarchy involves inheritance via stereotypes and not metaclasses, I'm not sure how the _MeaningBackwards & _MeaningForwards will be correctly propagated.

I'd recommend defining an extension only for your concrete metaclasses. (And extension is not inheritance)

I understand that extension is not inheritance.  Looking at the hierarchy I have created for arcs, it doesn't involve specialization of stereotypes, but metaclasses.
I supply the appropriate attributes at each level of specialization and the MDG/QL seems to figure it out.  For example,

An Aggregation («stereotype» - defines _image, _metatype, icon) extends Aggregation₁ («metaclass» defines _MeaningBackwards & _MeaningForwards) specializes Aggregation₂ («metaclass» defines compositionKind) specializes Association₃ («metaclass» defines direction)

While an Aggregation Link^[1] («stereotype» - defines _image, _metatype, icon) extends Aggregation₄ («metaclass» defines _MeaningBackwards & _MeaningForwards) specializes Aggregation₂ («metaclass» defines compositionKind) specializes Association₃ («metaclass» defines direction)

For both, the _mage, _metatype, icon,  _MeaningBackwards & _MeaningForwards are different, but everything else is the same.

Is this the right way to do it for arcs?

(in case it's not obvious, having the same subscript means it's the same object.)

As I said, it seems to work.

Paolo

^[1] An Aggregation Link aggregates specific instances (its multiplicity is always [1:1])

[Eve]

Am I reading it correctly that your stereotype is extending a single metaclass, which is a specialization of another?

Just performed a quick test, the export of a profile appears to ignore that completely. The stereotype is exported only with the properties of the direct extension. (No compositionKind or direction exported at all) It's also worth noting that the quicklinker didn't offer a generalization connector between two metaclasses.

[Paolo F Cantoni]

Am I reading it correctly that your stereotype is extending a single metaclass, which is a specialization of another?

Yes!

Just performed a quick test, the export of a profile appears to ignore that completely. The stereotype is exported only with the properties of the direct extension. (No compositionKind or direction exported at all) It's also worth noting that the quicklinker didn't offer a generalization connector between two metaclasses.

As I said, it seemed to work.  As you say, closer inspection indicates I've been "fooled".


Oh well...  I'll try a different technique.


Any chance, a feature request could be considered to propagate the attributes down the specialization chain?  I could write a script to automagically simulate that, but it would be nicer if it was native.


Paolo