Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: qwerty on May 18, 2021, 05:59:02 pm
-
I seem to remember this being asked before (and anticipating the answer as well). But again: is it somehow possible to turn off that toolbox? The new Metaconstraints seem to be a (now rare) nugget which is why I'm after them now. There's that Filter to Toolbox check mark. And that includes the Common Relationships as well (it probably does for elements but I'm not that far yet). Now it's really nice that we now can show our own relevant connectors in the menu (don't tell me the old QL could do that as well...). But the Common ones are included as well. Is there any way to turn them off so we can be really strict in our modeling environment - and not just somehow strict.
q.
-
Adding the attribute _HideUMLLinks=true in the metaclass helps with Filter to Toolbox = true (but I think it needs to be for every item in the profile - leastways that's what we've done)
HTH,
Paolo
-
No, I don't think you can turn them off.
But you can be strict though (at least if working with your own stereotypes). I never rely on the existence of a toolbox to determine what I want to allow or not.
If you set the _HideUMLLinks property to true, your stereotype will no longer inherit the standard UML relations.
You then have to make sure to provide all the allowed relationships in your profile.
Geert
PS. I see that Paolo has the same suggestion :)
-
Ah, good to hear. Sounds like labor but I'm already chained here...
Thank you both!
q.
-
Well, that attribute's meaning is obfuscated. The Common Relationships are there are before. I'll play around a bit more, but obviously my goal to just plainly get rid of an imposed toolbox is not achievable.
q.
-
Well, that attribute's meaning is obfuscated. The Common Relationships are there are before. I'll play around a bit more, but obviously my goal to just plainly get rid of an imposed toolbox is not achievable.
q.
You definitely can't get rid of the common toolboxes.
The only thing you can can do is make the rules so strict the relationships on there cannot be used on any of your artifacts.
Geert
-
I think I now see a bit more clear. This attribute has to be set to the element and not for any relation itself. I had been thinking the wrong way...
q.
P.S. That does not seem to work too. I'll have a break...
-
Ah well, to and fro it turned out to be case sensitive. It must be _HideUmlLinks. Using _HideUMLLinks does not work. Feel scolded, Paolo AND Geert! ;-)
q.
P.S. Oh my! It works now for one stereotype. But doing the exact same thing to another one yields nothing. UML connectors present despite adding the Hide.
-
It does not look like this is working at all. I boiled it down to a very simple example where I have a stereotyped relationship from Package to Artifact. That's well show in the QL with the respective names. But once I turn on _HideUmlLinks the dropdown is completely empty.
<Stereotype name="represent" notes="">
<AppliesTo>
<Apply type="Dependency">
<Property name="direction" value="Source -> Destination"/>
<Property name="_MeaningForwards" value="Represent"/>
<Property name="_MeaningBackwards" value="Represented by"/>
</Apply>
</AppliesTo>
</Stereotype>
and <Metamodel>
<Metaclass name="Package" notes="">
<stereotypedrelationships>
<stereotypedrelationship stereotype="myProf::represent" constraint="Artifact"/>
</stereotypedrelationships>
</Metaclass>
</Metamodel>
is what the profile holds.
P.S. And the source stereo looks like
<Stereotype name="theBadOne" notes="">
<AppliesTo>
<Apply type="Package">
<Property name="URI" value=""/>
<Property name="_HideUmlLinks" value="true"/>
</Apply>
</AppliesTo>
</Stereotype>
Without the Hide property the list is complete. And with it it's not present.
q.
-
And what really made my day:
<Metamodel>
<Metaclass name="Package" notes="">
<stereotypedrelationships>
<stereotypedrelationship stereotype="myProf::represent" constraint="Package"/>
</stereotypedrelationships>
</Metaclass>
</Metamodel>has the same effect. The QL from a package to another (or anything) is empty.
Why?
q.
-
I suspect your problem is that you're adding myProf::represent to a UML type. Then on your stereotyped package you are saying not to include any relationships inherited from the UML type, which includes your relationship.
If you want to hide the UML relationships you will need to define your relationships as starting from your stereotypes instead/as well.
PS. You can hide individual items from a common toolbox by defining and selecting a perspective. Set it to 'Strict' (meaning nothing outside the perspective can be created) and then 'Restrict' it to a subset of the included technologies, which includes selection of the items in the common toolboxes. If you're so inclined you can even turn off specific Link/Source/Target combinations.
-
I suspect your problem is that you're adding myProf::represent to a UML type.
Sorry, but I don't understand that :-/
Maybe you did not see the definition in the 2nd last post?
q.
-
No, I saw the second post. They are both doing the same thing. Adding a target for myProf::represent to UML Package.
The rule is added to all unstereotyped packages. Stereotyped packages will inherit it from the Package definition as well by default.
The problem that _HideUmlLinks is not intended to hide UML relationship types, it hides all relationships defined against the base UML element. In your particular example that includes your custom relationship.
Is your intention to define myProf::represent so that it is offered as a relationship between unstereotyped Package and Artifact/Package? Or is that a misunderstanding of what you need to do to use it within your own profile?
You can and should define the relationships against your stereotypes. The only reason to include any metaclass elements is if you explicitly want unstereotyped elements as a valid source or target. This definition should mean that theBadOne is allowed to have a myProf::represent to a UML Artifact, Package or myProf::otherPackage. In the model that would correspond to 3 stereotyped relationship connectors.
<Stereotype name="theBadOne" notes="">
<AppliesTo>
<Apply type="Package">
<Property name="URI" value=""/>
<Property name="_HideUmlLinks" value="true"/>
</Apply>
</AppliesTo>
<stereotypedrelationships>
<stereotypedrelationship stereotype="myProf::represent" constraint="Artifact;Package;myProf::otherPackage"/>
</stereotypedrelationships>
</Stereotype>
-
I think I know what you mean, but it needs to settle down first. Pretty sure it's what I call "Sparxian thinking".
What I meant was to add the stereotyped relation to all packages and to show this as the only one being allowed (for this test case). That's why I added it for the Package metaclass and my intention of setting the _Hide was to eliminate everything else. As said, I have to brood over that for a moment.
Anyway, thanks for the pointers.
q.
-
I got it. Indeed it is that Sprarxian thinking. Or as your CDO might say "bloody user thinking". So when using the _Hide it's of no use to define metaconstraints between metaclasses. Rather I have to do that for each and ever stereotype. Well, I have to dig that.
q.
-
Version 17 seems to have introduced a way to hide common toolboxes, at least manually.
Click the burger button at the top of the Toolbox , choose Set Toolbox Visibility to open the Pinned Toolbox Pages window.
Click the burger button at the top of this window as choose Settings...
You can also get to this by clicking on the All Perspectives in the top right corner of EA and choosing Settings...
Uncheck to deselect all System Perspective Sets in the lefthand panel except Specialized. Click Save and close all windows.
Marvel at a Toolbox without Common or other random toolbox groups.