Hiding the remaining Generic Links in QuickLinker

[Paolo F Cantoni]

Sorry, I added that metaconstraint to A.

[SNIP]

So what my sample profile was doing was saying that in addition to the connector C between those elements you can also create a UML dependency. The result is that you get Dependency in the QuickLinker and model validation between those elements even though you aren't inheriting any UML relationships. But it wouldn't allow a dependency to any other types. You may want to use something like that if you didn't want to add additional metadata to a particular relationship.

OK, I now get the additional 4 UML relationships (including Dependency).  I guess we should have seen JUST Dependency, yes?

Now I'll have a look at my MDG when I get some time.

Paolo

[Eve]

OK, I now get the additional 4 UML relationships (including Dependency).  I guess we should have seen JUST Dependency, yes?

That's the assumption I initially made too. Abstraction, Realization, and Usage are specializations of Dependency.You're seeing them because they don't override the Dependency rules so the Dependency rules including yours have been inherited.

If you don't want them you can create a metarelationship rule for them to a metaclass '<none>'.

The result would be something like:

Code: [Select]

<metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
<metarelationship metaclass="Abstraction" constraint="&lt;none&gt;"/>
<metarelationship metaclass="Usage" constraint="&lt;none&gt;"/>
</metarelationships>
I've omitted Realization from above because it is a specialization of Abstraction. (And because then I don't need to work out if it needs to be Australian or American spelling)

[Paolo F Cantoni]

Not sure I expressed myself properly.

What you are seeing is consistent with _HideUmlLinks not existing at all. I can't see any way you could reproduce that result accidentally otherwise. That's why I asked about where you are defining it.

[SNIP]

Hi Eve,
The above DOES seem to be the case.  I thought the <Property name="_HideUmlLinks" value="true"/> entry (which I added to a higher level abstract metatype) setting would be inherited by the descendants.  However, this doesn't seem to be the case.  In order to hide the UML links at a leaf metatype, I need to assign it directly at the leaf node.  Is that your understanding of how it should work?  (NOT complaining, just looking for clarification)

Paolo

[Eve]

That's it.

EA will only see one extension for each metaclass. It doesn't combine them.

It's possible to put it on metaclass a base stereotype is extending. That would be viable for stereotypes that don't have unique composite diagram types.

I think in your case what you want is to add it to all metaclasses.

[adepreter]

@Eve: About "The option you describe is effectively what we have".

I checked... and indeed I can see that in the last version (Build 1527), the quick linker column "Exclusive to ST Filter +" is now properly interpreted as described here:
https://sparxsystems.com/enterprise_architect_user_guide/15.1/modeling/quick_linker_definition_format.html

Since we automatically generate this value to TRUE, it now works as documented.

Thank you

[Paolo F Cantoni]

That's it.

EA will only see one extension for each metaclass. It doesn't combine them.

It's possible to put it on metaclass a base stereotype is extending. That would be viable for stereotypes that don't have unique composite diagram types.

I think in your case what you want is to add it to all metaclasses.

(my emphasis) I think I did have it on all the metaclasses for the "abstract" metatypes - from which all the concrete metatypes inherit.  But it wasn't enough.  I needed to add the _HideUmlLinks property to the concrete metatypes (I guess the equivalent of "adding it to all the metaclasses" - both abstract and concrete, yes?).

BTW: how do I designate a metatype as an "abstract" metatype?  Just set the [Abstract] property on the Element Properties window Stereotype section or by some other means?

Paolo

[Eve]

I don't think there are abstract or concrete metaclasses in EA profiles. There is certainly no inheritance between the metaclasses, which is distinct from a stereotype inheriting the extension of a metaclass. But I'm assuming that's just terminology.

If I have an abstract stereotype 'A' that extends Class.
If 'B' specializes 'A' but also extends 'Class' 'B' will not use the extension of 'A' at all. It will override the extension of Class with its own copy.
If 'C' specializes 'A' but doesn't define an additional extension, it will use the extension defined at 'A' because it isn't overridden.

In my hypothetical profile above, you only need _HideUmlLinks on the Extension for 'A' because there is a concrete stereotype that doesn't define it. If you removed 'C' or added an extension there too, the extension of 'A' is serving no purpose. But I'm saying to add it to everything because that's an easier rule and is less likely to cause unexpected behavior if you later add another stereotype.

FYI. I believe that UML supports this behaviour. An extension is actually a specialized association. Both of the extensions will generate the same role name referencing class, which means that the inherited property is automatically hidden. It doesn't become a merge of the two.

[Paolo F Cantoni]

I don't think there are abstract or concrete metaclasses in EA profiles. There is certainly no inheritance between the metaclasses, which is distinct from a stereotype inheriting the extension of a metaclass. But I'm assuming that's just terminology.

If I have an abstract stereotype 'A' that extends Class.
If 'B' specializes 'A' but also extends 'Class' 'B' will not use the extension of 'A' at all. It will override the extension of Class with its own copy.
If 'C' specializes 'A' but doesn't define an additional extension, it will use the extension defined at 'A' because it isn't overridden.

In my hypothetical profile above, you only need _HideUmlLinks on the Extension for 'A' because there is a concrete stereotype that doesn't define it. If you removed 'C' or added an extension there too, the extension of 'A' is serving no purpose. But I'm saying to add it to everything because that's an easier rule and is less likely to cause unexpected behaviour if you later add another stereotype.

FYI. I believe that UML supports this behaviour. An extension is actually a specialized association. Both of the extensions will generate the same role name referencing class, which means that the inherited property is automatically hidden. It doesn't become a merge of the two.

(my emphasis)
Sorry, my bad, I meant abstract vs concrete stereotypes (metatypes)

[Eve]

Yes, the abstract checkbox will be in the 'Stereotype'/type name group of the properties window. Concrete is the inverse of abstract.

[adepreter]

About: Hide Default Quick Linker Settings
https://sparxsystems.com/enterprise_architect_user_guide/15.1/modeling/hiding_default_quick_linker_se.html

Unfortunately, as described at the end of the:
"Note that this technique does not affect the automatic appearance of 'Dependency', 'Trace', 'Information Flow' and 'Help' options on the Quick Linker menu"

When shall we have this fixed? (We have been asking that for years)

[Eve]

About: Hide Default Quick Linker Settings
https://sparxsystems.com/enterprise_architect_user_guide/15.1/modeling/hiding_default_quick_linker_se.html

Unfortunately, as described at the end of the:
"Note that this technique does not affect the automatic appearance of 'Dependency', 'Trace', 'Information Flow' and 'Help' options on the Quick Linker menu"

When shall we have this fixed? (We have been asking that for years)

I'll ask for it to be updated to reference the help for _HideUmlLinks instead.

[adepreter]

@Eve: I hope you don't mean to solve the problem by removing the feature from the user guide?

This useful feature should simply work as described in the documentation!!
https://sparxsystems.com/enterprise_architect_user_guide/15.1/modeling/hiding_default_quick_linker_se.html

[Eve]

There are two ways to remove the common quicklinker items. _HideUmlLinks and strict perspectives.

The only problem with the exclusive to stereotype column (that I am aware of) is that the documentation says that it "Unfortunately" doesn't cover a use case which is covered by other functionality, but doesn't refer to that functionality.

[PeteEA]

Is there a way of applying this to stereotypes that are Generalisations of a SysML block?

I added _HideUmlLinks, set to True on a SysML1.4::block from which I have more specific stereotypes, but it didn't work as the generic block quick linker options were present (I then realised the SysML1.4::block is not a metaclass). I tried adding the Class metaclass (with _HideUmlLinks, set to True) and extending my SysML1.4::block from that (that didn't work - I didn't really expect it to as I probably shouldn't be able to override SysML).

Obviously if I extend my block from my new Class metaclass then the generic links are hidden as expected.

[Eve]

No. As suggested by the name, it only hides UML link types.

Assuming you're wanting to specialize block for reasons other than the link rules, you can override the relationships that it does expose or rely on the toolbox filters to hide SysML elements.