Metamodel Constraints - Meta-Relationship

[i4mdone]

In 14.1 build 1427 I am attempting to add a relationship constraint between Foo and Bar:

<metarelationship> {metaclass = Generalization}

The only UML Connectors that show up in QuickLinker are those that I have set with an <exposes> connector in the Metamodel View spec.

[Eve]

That's correct. The quicklinker will be filtered to the metamodel view. If you want to include Generalization, add an expose connector to a metaclass with the name Generalization.

[i4mdone]

If that is true, then what is the purpose of the Meta-Relationship function?

Meaning I thought it meant to establish a "valid" UML Connector between the two Stereotypes. However what happens is that whatever is added with an <exposes> connector is available in the QuickLinker regardless of what I established with the Meta-Relationship connection.

I thought the intention was that only what I have established with the Meta-Relationship would be available in the QuickLinker. In this case I would only expect "Generalization" to show up as a valid UML Connector in the QuickLinker. However if I <expose> other connector types with or without using the Meta-Relationship function they all show up in the QuickLinker.

[Eve]

It's likely that Generalize is valid between the two base classes that you are using.

You can also add the attribute _HideUmlLinks=True to your source metaclass element to suppress that. Then you should only get the types you have modeled.

[Ian Mitchell]

I'm also struggling to make this work.
I have added some new types to the 'Animal' example, with some 'metarelationship' connectors, as specified in the help.
Generating the MDG then does everything OK - the MDG itself, the diagram (ecoSystem) and the new toolbox items all work just fine, but the Quick Linker is unchanged.
The profile part of the MDG contains things like:
<Stereotype name="Other thing" notes="" cx="0" cy="0">
   <metarelationships>
      <metarelationship metaclass="Generalization" constraint="Ian::Thing"/>
   </metarelationships>
etc
...which looks like the example in the help. ("Ian" is my MDG name)

But the quicklinker (from an 'Other thing' to a 'Thing', and same the other way around) just shows options of:
Substitution
-------------
Abstraction
Dependency
Information Flow
Realization
Usage
-------
Trace
(filter to toolbox is checked)

I think i've done everything exactly as per the help, but the discussion above suggests I may need to do more. Are there further steps ?
And if I want to suppress the other UML links, where does the "_HideUmlLinks=True" go? I tried creating a TV in the 'Other thing' metaclass definition, but that didn't seem to make any difference.
What am I missing ?
Thanks

[Geert Bellekens]

Ian,

I used the _hideUMLLinks in the past on my own stereotypes
In that case you had to add the attribute to the «metaclass»

There is now a specific page about that topic https://www.sparxsystems.com/enterprise_architect_user_guide/15.0/modeling/hiding_default_quick_linker_se.html
and it says:

Metamodel Method
In the <<metaclass>> element for each source stereotype element, add the attribute  _HideUmlLinks set to "True" so that quicklinks with this stereotype as the source element will not include quicklinks inherited from the base UML metaclass.

I know I got it working, but it took me a while to get all the i's dotted and the t's crossed.
And as you know, if there's something wrong it just doesn't work (silently)

Geert

[Ian Mitchell]

I don't suppose you have a simple 'hello world' example i could use as a base?
I just can't get ANYTHING to work with the quick linker - either the new-style metarelationship method, or the old CSV approach.

[Geert Bellekens]

Nothing I can share publicly, but I'll send you an email.

Geert

[Eve]

I just can't get ANYTHING to work with the quick linker - either the new-style metarelationship method, or the old CSV approach.

At a guess, is the filter to toolbox option checked in your quicklinker menu?

If it isn't checked, that item will only show if both Generalization and Ian::Thing appear in the current toolbox.

Also, be careful with your fq name. You commented that "Ian" is your MDG name. It needs to be the name of the profile containing the stereotype "Thing". That may or not be the same as the MDG. If you've added that to the ecoSystem profile, it would be ecoSystem::Thing.

And as you know, if there's something wrong it just doesn't work (silently)

The problem is that in most cases it's valid, just not what you expected.

[Ian Mitchell]

Ah - I thought that the combination of Eve AND Geert would fix it!

My error was in making _HideUmlLinks an attribute of each <<stereotype>>, and not the <<metaclass>>Class.

That has almost 100% fixed it.
- Where I specify a 'Generalization' between two types, it get the correct link in the QL, and nothing else 
- For the QL in the opposite direction, EA shows 'Specialization', which was a pleasant surprise!
- Where no relationships are defined, none are shown
- For another link where I only specified a 'Dependency', I get a QL with only Abstraction, Dependency, Realization and Usage, which is not so good.

Can anyone think what might be causing these extra, un-wanted options?

Also, do we have any style guidance as to how we should meta-model these kinds of relationship?
- Geerts approach seems to create specialised forms of the UML relationships types (maybe to show them to your users in their required national language?) then add these as <metaconstraints>>, which works fine,
- but I'm following the advice in the help and using <<metarelationships>>.

@Geert - is it just the language translation which made you choose the former?

[Geert Bellekens]

About the Dependency. I guess you are seeing that because Abstraction, Realization and Usage are all sub-types of Dependency in UML

I made specialized relation stereotypes because I wanted them to be specialized.
They could have
- a different meaning than the general form.
- a different shapescript
- different meaningforwards/meaningBackwards (what the user sees in the quicklink)

I think I've also used metaRelationships in the past, but I don't remember where and why exactly.

Geert

[philchudley]

Hi All

Please permit me to blow my own trumpet and refer you to the Community Article I wrote and also presented at Gdansk EA User Group

https://community.sparxsystems.com/tutorials/1232-using-stereotyped-relationships-to-define-quicklink-rules

Agreed its not meta-relationship but stereotype relationship, but it maybe of some help and interest.

All the best

Phil

[Eve]

In response to this thread I've played around with the ecoSystem example profile

The rules in the existing quicklinker correspond to the following connectors.

• animal «stereotyped relationship» {stereotype= ecoSystem Stereotypes::habitat } to plant
• animal «stereotyped relationship» {stereotype= ecoSystem Stereotypes::food } to plant
• animal «stereotyped relationship» {stereotype= ecoSystem Stereotypes::food } to animal

To get customized labels you need to split the «metaclass» Dependency used by both connectors, and add _MeaningForwards, _MeaningBackwards.

A common use of metarelationship is to allow generalization only between the specialized types.

• animal «metarelationship» {metaclass=Generalization } to animal
• plant «metarelationship» {metaclass=Generalization } to plant

Yes, if you use «metarelationship» with a metaclass that has specializations you will get all the concrete specializations in your menu. The only way to avoid that would be to create an additional rule for each specialization you don't want referencing a non-existing type. I haven't investigated it yet, but if I use dependency I don't get anything in the menu.

One additional point. If you want to link to a stereotype from another profile, drag the metaclass and select it from the stereotype page. Do not drag it from another part of your model.