Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Modesto Vega on January 31, 2020, 09:33:48 pm
-
I think I know the answer to this but, just in case, I will ask the question. Is there are a way to graphically represent 'Root' nodes on a diagram (similar to how packages can be represented)?
AFIK, this cannot be done on V13 but have not tried V15.
P.S.: The reason for the question is that I am documenting how a repository with multiple root nodes is structured.
P.S.2: I also know that root nodes are proprietary and appear to lack a package element.
-
Why not manually assigning a stereotype to the root packages then showing it in diagrams?
-
Why not manually assigning a stereotype to the root packages then showing it in diagrams?
Thanks Richard.
In V13 right click on a root node does not display any properties, the only way to get a properties dialogue is by using the ribbon (Design\Package (Manage)\Properties. What appears on screen is essentially the element properties window (not that I am surprised).
What am I getting into if I choose that route?
-
Why not manually assigning a stereotype to the root packages then showing it in diagrams?
You can't. The stereotype is stored in t_object, and since root packages don't have a t_object record, you can't assign a stereotype to them (or show them on a diagram for that matter)
Geert
-
Hello Modesto,
I don't think it's possible to assign stereotypes to Root Nodes. As you note, while other packages in EA (including 'View' packages) are represented internally as both a package and an element (a row in both t_package and t_object), Root Nodes are not -- they have a row in t_package but not in t_object. (In the API, they are Packages with, again as you note, no valid Package.Element.)
Since the stereotype is a property of the Element / column in t_object, I don't see how you could assign a stereotype to a Root Node even if you did manage to get one to appear in a property dialog. (What you describe with the Design ribbon doesn't appear to work in 15.0, sounds like a bug that has been fixed.)
if you want to see the Root Nodes in a diagram, the only way I can think of offhand is to create a Model View (https://sparxsystems.com/enterprise_architect_user_guide/15.1/model_publishing/define_a_model_view_chart.html) with the following query:
select Name as Root from t_package where t_package.Parent_ID = 0
order by Name
If you want them in browser order, replace the order clause with
order by t_package.TPos
This will list the names of the root nodes. You can add any other columns from t_package (and the query editor will tell you what they are), but as you'll see most of the interesting properties aren't actually in there -- they're in t_object. There is a Notes column, but since you can't edit Root Node properties I don't see how that column could ever contain anything. Unless you've scripted something in there.
A word of warning.
The query editor will encourage you to include the specially-handled columns
t_object.ea_guid as CLASSGUID
t_object.Object_Type as CLASSTYPE
in your query. These are intended to allow the user to right-click an entry in the list and select either Find in Browser or Find in Diagrams.
Obviously you can't join t_package with t_object in this case, that's the whole point, but you can hard-code 'Package' for the CLASSTYPE. I would have expected that to allow you to Find in Browser, but it doesn't.
It also enables the Find in Diagrams menu item, which is pointless because Root Nodes can't be placed in diagrams (duh) but more to the point that function requires a GUID and EA (15) doesn't actually sanity-check this, but appears to search for all elements whose GUID match an empty string, returning a list of all elements that appear in any diagram.
;D
So don't bother with that bit, but if nothing else you can get a list of the Root Nodes this way. They're not individual things like elements or "real" packages, but you can at least see them.
HTH,
/Uffe
-
Thanks Geert and Uffe. I have managed to stereotype a Root Package in v13 (I have not tried this with v15.1 yet), as described on my reply to Richard - please see snippet below.
[SNIP]
In V13 right click on a root node does not display any properties, the only way to get a properties dialogue is by using the ribbon (Design\Package (Manage)\Properties. What appears on screen is essentially the element properties window (not that I am surprised).
At this point I am very seriously confused (I also thought it was not possible) and need a coffee.
-
Good to know, thanks!
Why not manually assigning a stereotype to the root packages then showing it in diagrams?
You can't. The stereotype is stored in t_object, and since root packages don't have a t_object record, you can't assign a stereotype to them (or show them on a diagram for that matter)
Geert
-
Good to know, thanks!
Why not manually assigning a stereotype to the root packages then showing it in diagrams?
You can't. The stereotype is stored in t_object, and since root packages don't have a t_object record, you can't assign a stereotype to them (or show them on a diagram for that matter)
Geert
Trouble is that I just manage to do what you described, and I am still confused - see previous post.
If I can stereotype it, it is an element. If it is an element, I should be able to add it to a diagram but I cannot add it to diagram, therefore it is not a proper element (but can be stereotyped). Could somebody translate this Sparxian logic for me?
-
You can't stereotype a root. It's kinda special thing like the views which are a bit more like packages. That design decision might have made sense to G.S. in the past. Honstely it confused me more than it helped. It Roots and Views were just (stereotypes) packages, the world would be a better on. They aren't and in my lifetime I will not see that change. Also, anything the Sparxians call "logic" is "logic", but only in their own world and matching it to human logical will cause the wave function to break down.
q.
-
If it is an element, I should be able to add it to a diagram but I cannot add it to diagram, therefore it is not a proper element (but can be stereotyped).
I would dearly love this feature. Without, it makes it hard to model certain aspects about the model!
-
Trouble is that I just manage to do what you described, and I am still confused - see previous post.
If I can stereotype it, it is an element. If it is an element, I should be able to add it to a diagram but I cannot add it to diagram, therefore it is not a proper element (but can be stereotyped). Could somebody translate this Sparxian logic for me?
If you have managed to stereotype a root node, it's a bug.
And while some people would undoubtedly like to be able to use them like any other model element, I'm not confident that can be done without causing lots of problems.
-
Trouble is that I just manage to do what you described, and I am still confused - see previous post.
If I can stereotype it, it is an element. If it is an element, I should be able to add it to a diagram but I cannot add it to diagram, therefore it is not a proper element (but can be stereotyped). Could somebody translate this Sparxian logic for me?
If you have managed to stereotype a root node, it's a bug.
And while some people would undoubtedly like to be able to use them like any other model element, I'm not confident that can be done without causing lots of problems.
If it is/was a v13 bug, I would expect it corrected in v15.1 (I have not tried this yet in v15.1). If it is still in v15, it is more like feature than bug.
I also think it will be a nice feature to have, but wouldn’t hold my breath.
-
FWIW, I'm OK with root nodes being special in some ways. It's a little less defensible once you make the decision to allow multiple roots, but fine, whatever.
I have much more of a problem with the View concept, which serves absolutely no useful purpose in any real model (Mickey-Mouse examples are not real models) and is just annoying. Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
/U
-
FWIW, I'm OK with root nodes being special in some ways. It's a little less defensible once you make the decision to allow multiple roots, but fine, whatever.
I have much more of a problem with the View concept, which serves absolutely no useful purpose in any real model (Mickey-Mouse examples are not real models) and is just annoying. Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
/U
Wot 'e sed!
Paolo
-
FWIW, I'm OK with root nodes being special in some ways. It's a little less defensible once you make the decision to allow multiple roots, but fine, whatever.
I have much more of a problem with the View concept, which serves absolutely no useful purpose in any real model (Mickey-Mouse examples are not real models) and is just annoying. Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
/U
Agreed
-
FWIW, I'm OK with root nodes being special in some ways. It's a little less defensible once you make the decision to allow multiple roots, but fine, whatever.
I have much more of a problem with the View concept, which serves absolutely no useful purpose in any real model (Mickey-Mouse examples are not real models) and is just annoying. Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
/U
Me three
Geert
-
I never really understood the point of Views. Is it in the UML 2.5 standard? If not, off with its head.
-
I never really understood the point of Views. Is it in the UML 2.5 standard? If not, off with its head.
No, just a Sparx invention.
Geert
-
I never really understood the point of Views. Is it in the UML 2.5 standard? If not, off with its head.
No, just a Sparx invention.
Geert
One I have never managed to use/get working with a real model.
-
I have much more of a problem with the View concept, which serves absolutely no useful purpose in any real model (Mickey-Mouse examples are not real models) and is just annoying. Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
yes indeed
See also
https://www.sparxsystems.com/forums/smf/index.php/topic,30277.msg220994.html#msg220994
https://www.sparxsystems.com/forums/smf/index.php/topic,24984.msg199898.html#msg199898 (see info from RoyC)
-
Some things never change. One of those things seems to be that customer suggestions get ignored by Sparx over and over.
q.
-
Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
When was the last time you tried?
If it is/was a v13 bug, I would expect it corrected in v15.1 (I have not tried this yet in v15.1). If it is still in v15, it is more like feature than bug.
If I followed your instructions it is fixed, since when does a bug going unnoticed for a long time turn it into a feature?
-
since when does a bug going unnoticed for a long time turn it into a feature?
lol, when it get used !
-
[SNIP]
since when does a bug going unnoticed for a long time turn it into a feature?
A bug becomes a feature when 1)it is not resolved, 2) it may be useful, and, skiwi noted, 3)gets used. I cannot tell when this was resolved but it was certainly there with v13.
As I said above, I have no problems with root nodes being special. Although, I also think Sparx EA will be a better tool if they were treated like a package.
-
If I followed your instructions it is fixed, since when does a bug going unnoticed for a long time turn it into a feature?
In gaming environment they call it exploit.
q.
-
Yes, you can hack your way around the stupid restriction on moving packages to and from the Magic Level One Where Only Views May Exist, but you shouldn't need to.
When was the last time you tried?
13.5, and there's no mention of any changes to this behavior in https://sparxsystems.com.au/products/ea/14/history.html, https://sparxsystems.com.au/products/ea/14.1/history.html, https://sparxsystems.com.au/products/ea/15/history.html or https://sparxsystems.com/products/ea/history.html.
But yes, that restriction has been removed somewhere between 13.5 and 15.0. Just on the quiet, like.
/U
-
In EA 14.1.1427 the restriction is still there.
In EA 15.1.1526 not anymore :D
I'm happy with the change, but it would have been nice if it was mentioned in the release notes. (or maybe it was but I missed it)
Geert