Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on February 06, 2023, 02:05:03 pm
-
We create "Neighborhood" Diagrams for our items. Since Diagrams can't have tagged Values, we use the DiagramNote item (effectively the "Title Block" for the diagram) as a surrogate. We make the Parent of the Diagram and the Parent of the DiagramNote the item for whom the Diagram is being generated. This works fine for most items, but recently our Diagrammer Add-In has been crashing on Note Items with the message indicating that the Parent_ID relationship is contrary to UML specifications. That is, when we set the Parent_ID of the DiagramNote to be that of the Note Item (for which we are creating the Neighborhood Diagram), the exception is thrown.
Before I report a defect, can anyone point to the section of the UML specification that indicates this rule (which we appear to be breaking)? A quick check of 7.8.2 Comment [Class] (of the UML 2.5.1 Standard) indicates no such issue.
We have been processing such Note items with our Diagrammer for over a decade, so when did this change?
TIA,
Paolo
-
I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. Seems to make sense, though inconvenient for coder relying on it otherwise.
q.
-
I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.
q.
Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.
Paolo
-
I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.
q.
Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.
Paolo
I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.
Geert
-
Hi Paulo,
Are you setting the Parent_ID of an element, as per Geert comment, or of a diagram? Both, have a Parent_ID.
-
Hi Paulo,
Are you setting the Parent_ID of an element, as per Geert's comment, or of a diagram? Both have a Parent_ID.
Hi Modesto,
The problematic Parent _ID is the Element. The Diagram Parent_ID is set as it used to be. What's confusing is that I'm sure that this didn't happen with v15.2, so I suspect that the new DLL has the bug, and so, since I'm linking to it in the Add-In, even v15.2 activation of the Add-In crashes.
Paolo
-
I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.
q.
Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything.
Paolo
I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.
Geert
Thanks, Geert;
that was my reading of the Standard, but they can be pretty dense, so I wanted another "set of eyes" to confirm or deny.
Let's see what the Sparxians have to say tomorrow.
Paolo
-
Got it into the wrong throat (as we say here). It's probably the special treatment of EA that notes (aren't they call annotation in UML?) never were "real" elements. You did not see them in the browser. Likely that's why they still can not be parent of anything. Will it change for good? Maybe.
q.
-
Got it into the wrong throat (as we say here). It's probably the special treatment of EA that notes (aren't they call annotation in UML?)
Comment in UML, see § 7.8.2 Comment [Class] page 40
Geert
-
Yes, thanks :-) So Sparx has an "excuse" since it's not an UML element (btw. Object isn't UML either). But don't they claim to be UML 2 compliant?
q.
P.S. I can't find a UML compliance statement right now but pretty sure in the past they had some advert in this direction.
-
Yes, thanks :-) So Sparx has an "excuse" since it's not a UML element (btw. Object isn't UML either). But don't they claim to be UML 2 compliant?
q.
P.S. I can't find a UML compliance statement right now, but pretty sure in the past, they had some adverts in this direction.
(my emphasis) If it's NOT UML, then how can it break UML Rules...
The exception message is explicit: The Relationship is NOT allowed by UML Rules" (IIRC).
Paolo
-
It's "The requested connection is not UML compliant". But I meant an explicit statement like "UML 2.0 compliant modeling tool". I seem to remember that ad but there is none anymore. Maybe in one of the heave PDF document files?
q.
P.S. Indeed after searching the Help theres a lot about NIEM, BPMN, etc. compliance but not so much about UML. I found "it is not a strictly UML compliant construct)" in the help about SDs.
-
Are you using Parent_ID instead of Package_ID?
-
Well, "if it looks like a duck...."
and a EA Note element pretty much looks like a UML Comment to me, so for all intends an purposes, I guess we can treat a Note like it's a UML Comment.
Geert
-
Well, "if it looks like a duck...."
But this one barks ;-)
Honestly, this is a Sparx element, not an UML element. Like Object, which is kind of heritage. Eve already told that the latter will not change for compatibilty reasons. Looks like UML InstanceSpecification but...
q.
-
I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.
That logic doesn't quite follow. If it did, it would effectively mean that there are no ownership rules in UML because everything is an Element. So a Multiplicity can own a Package. Here's where you went wrong.
ownedElement is a derived union, which means that the the contents of that set are wholly defined by how the relationship is subsetted. Comment does not have any associations that subset that property so a comment can not own other elements.
I'm sure that this didn't happen with v15.2, so I suspect that the new DLL has the bug, and so, since I'm linking to it in the Add-In, even v15.2 activation of the Add-In crashes.
The dll has no application logic. Either you aren't actually opening EA 15.2 via the API or the behavior was always in 15.2.
Comment in UML, see § 7.8.2 Comment [Class] page 40
I agree that Note is Comment. If you export to XMI it will be exported as Comment.
-
Thanks for the explanation, Eve.
A couple of points, if I may.
1. Since a DiagramNote isn't a UML concept and is merely an administrative support item, should that constraint still apply? We're not trying to create a modelled hierarchy, merely clustering some conceptually related physical objects "together".
2. You can imagine our surprise when this "popped up" this weekend! Are you aware of any changes that would have triggered this? We update the Neighborhood diagrams as needed, so we can't guarantee we've processed a Note recently (until this weekend), but the code has been there for nearly a decade so we were able to successfully process Notes in the past. It would seem to have "appeared" with build 1624.
Your response will help us formulate a plan on how to deal with the issue in the future.
Paolo
-
1. Since a DiagramNote isn't a UML concept and is merely an administrative support item, should that constraint still apply? We're not trying to create a modelled hierarchy, merely clustering some conceptually related physical objects "together".
So you have created a child diagram below the note and placed a diagram note on that diagram? I would consider it a bug that EA allows you to create a diagram, let alone any elements (from UML or anything else) under a Comment.
2. You can imagine our surprise when this "popped up" this weekend! Are you aware of any changes that would have triggered this? We update the Neighborhood diagrams as needed, so we can't guarantee we've processed a Note recently (until this weekend), but the code has been there for nearly a decade so we were able to successfully process Notes in the past. It would seem to have "appeared" with build 1624.
I don't think it's 1624. I would believe that there were unexpected side effects of showing notes in the browser. (16.0) Indeed my attempts at testing meant that EA allowed me to create a diagram when I had a Note selected. The actual effect was a data integrity issue.
My suggestion, if you can't create it via the GUI, it should be excluded from your process.
-
Again, thanks, Eve, for your response.
Yes, we create (and have always created) Neighborhood diagrams for some Notes. Those Notes with Notelinks to more than one item are considered important enough to warrant a Neighborhood diagram. Especially since we often also copy and paste them onto multiple (Non-Neighborhood) diagrams (due to their relative importance). This allows us to keep control over Note contents. As I said, we've always done this in the past, and it has worked well.
Since diagrams are not UML, why shouldn't a Note have a diagram attached? (Just asking for clarification, not complaining).
I accept those true UML elements shouldn't be nested under Notes, but I would have thought that EA-specific contrivances (such as DiagramNotes, Hyperlinks, NavigationCells etc.) should be exempt.
I can see that we can no longer create or place diagrams under a Note via the UI, but these diagrams are very useful for us. They are created automatically, not via the UI, but via the API. If Sparx changes the ability to create such diagrams in this way, we'll have to comply.
Any comment on this?
Paolo
-
Since diagrams are not UML, why shouldn't a Note have a diagram attached? (Just asking for clarification, not complaining).
That particular decision pre-dates my time at Sparx. I'm going to say that we've made that decision that things that can't have a structure to get documented don't get diagrams.
I accept those true UML elements shouldn't be nested under Notes, but I would have thought that EA-specific contrivances (such as DiagramNotes, Hyperlinks, NavigationCells etc.) should be exempt.
Then accept that they have the rules that we specify.
I can see that we can no longer create or place diagrams under a Note via the UI, but these diagrams are very useful for us. They are created automatically, not via the UI, but via the API. If Sparx changes the ability to create such diagrams in this way, we'll have to comply.
You misunderstand me. Adding a diagram under an element in the UI has always required selecting that element in the browser. As Notes did not appear in the browser, there was no way it could be done via the UI prior to 16. The bug I saw in 16.1 was that it tried to create one. (And failed. It created it with no parent and not in any package.)
If you were previously creating these diagrams via the API, then you were already doing something that the UI doesn't allow.
-
[SNIP]You misunderstand me. Adding a diagram under an element in the UI has always required selecting that element in the browser. As Notes did not appear in the browser, there was no way it could be done via the UI prior to 16. The bug I saw in 16.1 was that it tried to create one. (And failed. It created it with no parent and not in any package.)
If you were previously creating these diagrams via the API, then you were already doing something that the UI doesn't allow.
Ah, yes, when we first started doing this, our manual process was to create a diagram at the package level and then insert the note and process it to determine its "neighborhood". Later, when we automated it, the diagram would appear at the package level (where the Note was currently located) (without generating the UML error). Perhaps the API would work "magic" behind the scene (or, more likely, the Project integrity check would set the parent to "0"). To cluster things, our internal processes would then move the Note based diagrams (and Diagram Notes) to a specific folder and move the "invisible" Note items to the same folder - sort of the reverse process.
Anyway, we now understand Sparx's view on the matter and accept that (as the saying goes these days...) "it is what it is".
Thanks again for your explanations.
Paolo
-
I can see that we can no longer create or place diagrams under a Note via the UI, but these diagrams are very useful for us. They are created automatically, not via the UI, but via the API. If Sparx changes the ability to create such diagrams in this way, we'll have to comply.
You misunderstand me. Adding a diagram under an element in the UI has always required selecting that element in the browser. As Notes did not appear in the browser, there was no way it could be done via the UI prior to 16. The bug I saw in 16.1 was that it tried to create one. (And failed. It created it with no parent and not in any package.)
If you were previously creating these diagrams via the API, then you were already doing something that the UI doesn't allow.
I am having a little trouble visualising how Paolo is trying to achieve the desired functionality and wondering why navigation cells (https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_fundamentals/navigation_cells.html) or hyperlinking facilities (https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_fundamentals/hyperlink_facilities.html) are not used instead.
Having said this I see the rationale behind neighbourhood diagrams, if they are akin to what we call context diagrams.
-
[SNIP]
Having said this, I see the rationale behind neighbourhood diagrams if they are akin to what we call context diagrams.
Yes, Modesto
Neighborhood Diagrams are automatically maintained context diagrams. For each (diagrammable) item, we perform (effectively) an "insert Related Elements" and also locate any other diagrams (that are NOT Neighborhood Diagrams) that the item is on. The Diagram is placed hierarchically under the item. We currently have over 71,000 such diagrams in our main repository.
As I mentioned, NOT all Notes get such a diagram "All Notes are equal, but some are more equal than others". Important Notes (normally linked to more than one item or relationship) will get them.
In the neighbourhood diagram, we see the full "context" of the item. The problem is not the drawing of the diagram; it's placing it hierarchically below the Note that it is illuminating.
Paolo
-
Neighborhood Diagrams are automatically maintained context diagrams. For each (diagrammable) item, we perform (effectively) an "insert Related Elements" and also locate any other diagrams (that are NOT Neighborhood Diagrams) that the item is on. The Diagram is placed hierarchically under the item. We currently have over 71,000 such diagrams in our main repository.
As I mentioned, NOT all Notes get such a diagram "All Notes are equal, but some are more equal than others". Important Notes (normally linked to more than one item or relationship) will get them.
In the neighbourhood diagram, we see the full "context" of the item. The problem is not the drawing of the diagram; it's placing it hierarchically below the Note that it is illuminating.
Paolo
Thanks Paolo, if I was trying to this without inheriting any legacy I will probably have an element on an MDG to handle this.
-
I seem to remember a recent post dealing with that. p_id is now zero (since v16?) as notes do not really belong to a package. It seems to make sense, though inconvenient for the coder relying on it otherwise.
q.
Hi q,
it's not the Note's parent that is the problem; it's that it seems it can't be the parent of anything
Paolo
I just check the UML specs, and a Comment is in fact a specialization of Element, and an element can be the owner of other elements.
So there is no (UML) reason notes shouldn't be able to own other elements.
Geert
Yes a Comment can own elements, but it can only own Comments. (ownedElement is a derived field, and in the case of Comments it can only be derived from ownedComment)
EDIT: Ah, there's a whole extra page of replies that I hadn't noticed! I will leave this here though because I don't think anyone else noticed that ownedComment subsets ownedElement
-
[SNIP]
Yes a Comment can own elements, but it can only own Comments. (ownedElement is a derived field, and in the case of Comments, it can only be derived from ownedComment)
EDIT: Ah, there's a whole extra page of replies that I hadn't noticed! I will leave this here, though, because I don't think anyone else noticed that ownedComment subsets ownedElement
Thanks, Neil,
But when I tried to move a Note under another Note, the UI wouldn't let me! Continuing inconsistency?
Paolo