v16.1 Can't set Parent_ID where parent is a Note item

[Eve]

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.

[Paolo F Cantoni]

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

[Eve]

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.

[Paolo F Cantoni]

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

[Eve]

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.

[Paolo F Cantoni]

[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

[Modesto Vega]

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.

[Paolo F Cantoni]

[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

[Modesto Vega]

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.

[KP]

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

[Paolo F Cantoni]

[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