Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on March 18, 2020, 11:49:31 am
-
The definition of the _HideUmlLinks property in the Metamodel Model method states:
"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."
And so it does!
However, even if we do this, there is still a Dependency, Trace and Information Flow links shown. Is it already possible to suppress these? If not do we need an additional property such as _HideGenericLinks (analogous to the above) to allow us to control whether or not they are visible to the user?
These links generate unstereotyped links which is contrary to our methodology so they are confusing to the user.
Thoughts?
Paolo
-
It's possible, because ArchiMate 3.1 doesn't list those relationships. I can't see that it's doing anything special either.
-
It's possible, because ArchiMate 3.1 doesn't list those relationships. I can't see that it's doing anything special either.
That's dangling a carrot in front of the donkey, then whipping it away at the last moment as it tries to bite! ;)
Any chance of a mechanism to do it?
Paolo
-
My point is that it works without adding something extra.
Here's a profile that the quicklinker doesn't show anything except "C".
<?xml version='1.0' encoding='windows-1252' ?>
<UMLProfile profiletype="uml2">
<Documentation id="9A9A9E6E-B" name="OneConnector" notes="OneConnector" version="1.0"/>
<Content>
<Stereotypes>
<Stereotype name="A" notes="">
<stereotypedrelationships>
<stereotypedrelationship constraint="OneConnector::B" stereotype="OneConnector::C"/>
</stereotypedrelationships>
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="True"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="B" notes="">
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="True"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="C" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="direction" value="Source -> Destination"/>
</Apply>
</AppliesTo>
</Stereotype>
</Stereotypes>
<TaggedValueTypes/>
<ViewDefinitions/>
<Metamodel/>
</Content>
</UMLProfile>
By adding a metarelationship for dependency between the relationships it did show all three relationship types, which seems... unexpected.
-
My point is that it works without adding something extra.
Here's a profile that the quicklinker doesn't show anything except "C".
[SNIP]
By adding a metarelationship for dependency between the relationships it did show all three relationship types, which seems... unexpected.
(my emphasis) I see... I think it may be the "adding something extra". Don't forget I've got both metamodel method and spreadsheet method entries while we changeover. So there may well be some unexpected interactions.
We need to understand the circumstances under which the additional relationships are shown or not shown. Do you need a support request?
To paraphrase our former PM, "We shall decide which QuickLinks shall be shown and the circumstances under which they will be shown". ;D
Paolo
-
I hadn't forgotten your situation. It certainly could contribute.
For the moment I'm not going to be as helpful as I'd like to be... Maybe being able to get rid of those will help you push for time to complete the migration. Do they still show if you remove your quicklink table?
-
I hadn't forgotten your situation. It certainly could contribute.
For the moment I'm not going to be as helpful as I'd like to be... Maybe being able to get rid of those will help you push for time to complete the migration. Do they still show if you remove your quicklink table?
So I had a go and removed the spreadsheet QL definitions. Got interesting (and like you, unexpected) results...
(https://i.imgur.com/i9N0xg1.png)
The entries in lower case are generated by my model (any vertex can have associative relationships with any other vertex).
The rest were generated by EA. I have very few MDGs enabled (other than our own).
Paolo
-
Looks like EA didn't pick up the _HideUmlLinks property at all. In my example the results were correct. I allowed Dependency. EA included specialized types of dependency in the quicklinker (Abstraction, Realization and Usage.) I didn't pick up why they were included initially.
How is your extension defined relative to the stereotypes actually being used? (ie. Where in the inheritance hierarchy for your stereotypes are they?)
-
Looks like EA didn't pick up the _HideUmlLinks property at all. In my example the results were correct. I allowed Dependency. EA included specialized types of dependency in the QuickLinker (Abstraction, Realization and Usage.) I didn't pick up why they were included initially.
How is your extension defined relative to the stereotypes actually being used? (ie. Where in the inheritance hierarchy for your stereotypes are they?)
OK, I think I follow. Needs some more experimentation at my end.
However, when I tried to include your profile below (OneConnector) as one of my technologies (enclosing it in a <MDG.Technology version="1.0"> section,. This was as a separate file in my (usual) path. I tried to create a toolbox to play with it, but it didn't work. So I decided to add it (profile only, not technology) at the start of my normal MDG file. I can put more than one Profile in the MDG file (under the <UMLProfiles> section) can't I? This time, the toolbox was working! Can you explain what's happening here?
Also, separately, since I can now play with your example, can you provide the exact metaconstraint you used so I can observe the same behaviour? Once I understand how your example behaves, I can see what mine is doing.
Paolo
-
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.
To answer your question, I created a metarelationship with metaclass=Dependency.
The result was <metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
</metarelationships>
-
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.
To answer your question, I created a metarelationship with metaclass=Dependency.
The result was <metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
</metarelationships>
I'll provide an extract later. I'll add your constraint and see what happens. Hopefully it (and what you've said) will shed light on things.
Paolo
-
I am not sure this should start from a technical discussion.
We all have our habits. EA was born when "UML Profile" was the ubiquitous religion.
If we step back a little bit, when we define a new domain specific language we do not care about UML.
There is no reason why we should inherit anything from UML.
The fact that, using EA, we create domain specific languages as UML profiles is "un accident de l'histoire" as we say in french.
So by default these UML specific relationships should not be present.
You might have a configuration option to inherit these relationships from UML.
And you would use that only in the case where you would create a language that semantically extends UML.
Btw UML itself can be seen as a domain specific language for modeling software systems.
-
The option you describe is effectively what we have, which is the topic being discussed here. It's specified by the profile author, they know the relationship that the elements in their language should have to UML. It defaults to false because when adding new options it's best not to change the default behavior. (Something that I am aware EA does on occasion with care and awareness of the impact it's going to have)
It's also because EA treats all elements regardless of the language they come from in a unified way that your model can freely re-use elements of multiple languages without needing to re-invent your entire language from scratch.
-
Hi Eve,
Last week, I was able to create an "A and a "B" and connect them with a "C" using the following micro toolbox
<Stereotype name="OC Test" notes="Items specific to OneConnector Testing (v0.1)">
<AppliesTo>
<Apply type="ToolboxPage"/>
</AppliesTo>
<TaggedValues>
<Tag name="isCollapsed" type="bool" description="" unit="" values="true,false" default="true"/>
<Tag name="OneConnector::A" type="" description="" unit="" values="" default="A"/>
<Tag name="OneConnector::B" type="" description="" unit="" values="" default="B"/>
<Tag name="OneConnector::C" type="" description="" unit="" values="" default="C"/>
</TaggedValues>
</Stereotype>
Today, I added the metarelationship as below
<UMLProfile profiletype="uml2">
<Documentation id="9A9A9E6E-B" name="OneConnector" notes="OneConnector" version="1.0"/>
<Content>
<Stereotypes>
<Stereotype name="A" notes="">
<stereotypedrelationships>
<stereotypedrelationship constraint="OneConnector::B" stereotype="OneConnector::C"/>
</stereotypedrelationships>
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="True"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="B" notes="">
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="True"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
<Stereotype name="C" notes="">
<metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
</metarelationships>
<AppliesTo>
<Apply type="Dependency">
<Property name="direction" value="Source -> Destination"/>
</Apply>
</AppliesTo>
</Stereotype>
</Stereotypes>
<TaggedValueTypes/>
<ViewDefinitions/>
<Metamodel/>
</Content>
</UMLProfile>
Did I add it in the right place? Because there was no change in behaviour - the UML links were suppressed, regardless of the presence or absence of the metarelationship.
Any explanation?
Paolo
-
Sorry, I added that metaconstraint to A.
<Stereotype name="A" notes="">
<stereotypedrelationships>
<stereotypedrelationship constraint="OneConnector::B" stereotype="OneConnector::C"/>
</stereotypedrelationships>
<metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
</metarelationships>
<AppliesTo>
<Apply type="Class">
<Property name="_HideUmlLinks" value="True"/>
<Property name="isActive" value=""/>
</Apply>
</AppliesTo>
</Stereotype>
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.
-
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
-
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:
<metarelationships>
<metarelationship metaclass="Dependency" constraint="OneConnector::B"/>
<metarelationship metaclass="Abstraction" constraint="<none>"/>
<metarelationship metaclass="Usage" constraint="<none>"/>
</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)
-
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
-
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.
-
@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 :)
-
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
-
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.
-
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)
-
Yes, the abstract checkbox will be in the 'Stereotype'/type name group of the properties window. Concrete is the inverse of abstract.
-
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)
-
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.
-
@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
-
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.
-
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.
-
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.
-
I've accidentally found that if I BOTH extend my stereotype from a Class metaclass (with the _HideUmlLinks set to True) AND generalise it from the SysML1.4 that my stereotype pickups of the SysML block customisation (as far as I can see that is only the isEncapsulated property) and the blocking of the default quicklinker, allowing me to customise on a per diagram type basis using the contents of the diagram toolbox.
As that works, I'll go with this option unless there is a good reason that anyone can say I shouldn't do this.
-
I've accidentally found that if I BOTH extend my stereotype from a Class metaclass (with the _HideUmlLinks set to True) AND generalise it from the SysML1.4 that my stereotype pickups of the SysML block customisation (as far as I can see that is only the isEncapsulated property) and the blocking of the default Quicklinker, allowing me to customise on a per diagram type basis using the contents of the diagram toolbox.
As that works, I'll go with this option unless there is a good reason that anyone can say I shouldn't do this.
Hi Pete,
I'm not saying don't go with this option, but I would recommend doing a sensitivity analysis on the solution.
In the past (even the very recent past) I thought I had a similar "solutions" but when I went to check that the solution applied everywhere I needed it I found it didn't seem to.
Before you invest too much effort, check the scope of the solution. That there aren't any gotchas hidden nearby.
Paolo
-
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.
Apologies for resurrecting an old thread but this is relevant to me.
It seems that this has been corrected for Dependency, Trace and Help, but I still see 'InformationFlow' in the QL options, alongside my own profile links. The note has been removed from the Help page linked above, so I assume the intention was to remove all of these links, but InformationFlow is still there.
Is this still the case for anyone else? I'm in 16.1 (1628).