Restrict allowed relationships with the Quicklinker?

[Guillaume]

Hi,
I used the MetaModel stereotyped relationship links in my UML profile to define allowed relationships between stereotyped elements.
e.g. "TypeA" Class can be linked with a "aaa" stereotyped dependency to "TypeB" Class
I also added the  "aaa" stereotyped dependency  in my toolbox

It works when I use the quicklinker on a test project, but the toolbox makes it possible to create a link from TypeB to TypeA.
I read Phil's article on the community site: https://community.sparxsystems.com/tutorials/1232-using-stereotyped-relationships-to-define-quicklink-rules

NOTE: The rules defined using Stereotyped-relationships only apply when using the Quicklinker, these rules can be broken by using any relationships visible in the toolbox.
Therefore, to fully enforce relationship rules, define all relationships using Stereotyped-relationships and do not provide any relationships in the diagram toolbox.

I tried to remove the relationships from the toolbox which prevents me from creating the association from the quicklinker.
Is there any way to apply restrictions on the allowed relationships e.g. in my example so only an "aaa" stereotyped dependency can be created from a TypeA class to a TypeB class?

I haven't tried the old style CSV quicklinker definition ; could this enforce such restrictions?

[Geert Bellekens]

Yes, you can add the attribute "_HideUmlLinks" with default value "true" to the metaclass.
That should hide all default relations for the metatype.

Geert

[philchudley]

Ah

This puzzled me for a while and the answer is use metaconstraint relationships, in addition to stereotype relationships

Say, for example, that Stereotype A can only connect to Stereotype B via a stereotyped Association, then in addition to the stereotype relationship (the quicklinker definition), add a metaconstraint relationship from the stereotyped Association to B (or A), and set the tag value umlRole to target, or umlRole to source. This will enforce these constraints when using the diagram tool box and am error dialog will be displayed.

I presented this at the EAUG meeting Gdansk, so you might be able to download the example used in the presentation from the EAUG web site

A little experimentation with metaconstraints may be necessary in order to see how they work.

All the best

Phil

[Guillaume]

Thank you for your answers.

Geert: the hideUMLLinks options is very useful indeed.
Phil: I tried using the metaconstraint as per your suggestion but I can't get the restriction to work. Using your EAUG presentation sample, I created a test EA Project and imported your MDG.
I created 2 elements: Problem and Cause, and used the toolbox to create a Solved By relationship from Cause to Problem; this doesn't trigger an error message. Is there something that I'm missing? (I can send you with test EA project if needed)

Guillaume

[philchudley]

Hi Guillaume

I have sent you a PM with the e-mail to which to send your EA project so I can take a look

All the best

Phil

[Paolo F Cantoni]

Hi Guillaume

I have sent you a PM with the e-mail to which to send your EA project so I can take a look

All the best

Phil

Hi guys, when this is sorted, can we get a copy of the MDG repository so we can see how and why it works?

Paolo

[Guillaume]

I eventually got it to work by enabling the Strict Connector Syntax option in EA Preferences under Links.
Note: the MDG must be visible in the active perspective (as suggested by Phil).

Thank you Phil for your time in looking at the issue.


Update: the remaining issue I have is to do with a built-in relationship e.g. I added the Association metaclass with a metaconstraint on the Cause (src) and the Problem (target) + a metarelationship from Cause to Problem. I also added the Association to the toolbox profile. The result is not 100% compliant: I can create association between any element (Cause, Problem, Solution) as source or target except from the following: Cause to Solution (it seems to detect a matching source and non matching target).
As a workaround I created a stereotype association (it works) but this is not ideal

[Eve]

NOTE: The rules defined using Stereotyped-relationships only apply when using the Quicklinker, these rules can be broken by using any relationships visible in the toolbox.
Therefore, to fully enforce relationship rules, define all relationships using Stereotyped-relationships and do not provide any relationships in the diagram toolbox.

This seems to be the opposite of the intent. The metamodel relationships define what is allowed, and quicklinkers are generated from the result of that. EA does try to validate rules if you have strict connector syntax enabled. I don't know if it captures every scenario.

As you found, the solution proposed by that article is wrong. If you don't include a link type in the toolbox it will be filtered out of the quicklinker by default.

I haven't tried the old style CSV quicklinker definition ; could this enforce such restrictions?

The CSV quicklinker definition is only that. It doesn't define any rules.

[Paolo F Cantoni]

NOTE: The rules defined using Stereotyped-relationships only apply when using the Quicklinker, these rules can be broken by using any relationships visible in the toolbox.
Therefore, to fully enforce relationship rules, define all relationships using Stereotyped-relationships and do not provide any relationships in the diagram toolbox.

This seems to be the opposite of the intent. The metamodel relationships define what is allowed, and quicklinkers are generated from the result of that. EA does try to validate rules if you have strict connector syntax enabled. I don't know if it captures every scenario.

As you found, the solution proposed by that article is wrong. If you don't include a link type in the toolbox it will be filtered out of the quicklinker by default.

I haven't tried the old style CSV quicklinker definition ; could this enforce such restrictions?

The CSV quicklinker definition is only that. It doesn't define any rules.

As I've previously requested, I believe the metamodel should also be able to cover what is NOT allowed.

Sometimes there is a broad set of specializations, but one (or a restricted number) may not be allowed.  I think this allows for a more natural view of the hierarchy.

Paolo

[Eve]

The authors of UAF (where EA takes the metamodeling relationships from) had similar instances. In a few places they appear to have  introduced superclasses that are effectively "can be a source/target for x". You can use this approach either by inserting the type into the hierarchy, or as a separate inheritance chain.

Conceptually, I don't like creating a relationship in the metamodel that says these types aren't related.