Author Topic: Element Hopping; Ups they did it again!!!!!! (Build 1551)  (Read 596 times)

PeterHeintz

  • EA User
  • **
  • Posts: 869
  • Karma: +53/-18
    • View Profile
Element Hopping; Ups they did it again!!!!!! (Build 1551)
« on: June 16, 2020, 08:38:07 pm »
In earlier V14 versions there was an element hopping from parent to parent when elements are dropped to a diagram, which was removed in later V14 versions.
This element hopping from parent to parent is now back again. :'(
A frequent scenario I have is, when using “send signal” and “accept event” actions (SysML). To find out, what send signals are accepted by which action in different activities I put a trace dependency between both actions.
To show this trace in a diagram, I put corresponding action into the subtend diagram. Before V13 I put the “traced action” outside of the frame, to make clear that this action does not belong to the activity shown in the diagram.
Since V14 putting something outside the frame was not allowed anymore. So since V14 those “trace actions” are inside of the activity frame.

What I want to express, are relations of an action in one activity to actions in another activity by traces.
Now in 1551 my actions change its parent again, but even worse as before. When I drop the “foreign action” in my diagram and after creating the trace, the foreign action remains in its original parent. However after moving the “foreign action” within that diagram to another position, the parent of the “foreign action” becomes the parent activity of the diagram.

At least in SysML models moving to newer EA versions recently causes to corrupt the diagram layout frequently. So I will have to fiddle around with element positions and this will cause to move my actions to other parents and I have a lot.
All this is really annoying! >:( >:( >:(
Best regards,

Peter Heintz

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 10519
  • Karma: +358/-31
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #1 on: June 16, 2020, 08:59:06 pm »
Peter,

I'm not familiar with SysML, I think you might be able to avoid the parent hopping by putting the parent activities in different packages.

IIRC the parent hopping like that only happens from one parent to another within the same package.

When we do Business Processes in BPMN we put each Business Process in a separate Package
I wrote a little script that does that: https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/Project%20Browser%20Package%20Group/DivideInPackages.vbs

Added benefit is that you can easily apply a user lock and use this as a unit in version control.

Geert


PeterHeintz

  • EA User
  • **
  • Posts: 869
  • Karma: +53/-18
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #2 on: June 16, 2020, 10:26:47 pm »
Hi Geert,
I tried what you have suggested, and you are right.
Do you see any sense in that it jumps, if the activities are in the same package, but it jumps not if the activities are in different packages?
Is there any sense in that it jumps when the element moves the position on the diagram?
How long can I assume that it doesn’t jump if the activities are in different packages?
Maybe Sparx can enlighten us! ;)
Best regards,

Peter Heintz

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 10519
  • Karma: +358/-31
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #3 on: June 16, 2020, 10:53:56 pm »
The idea is that actions are normally owned by their activity (or the ActivityPartition).
Actions are normally also only used on the activity diagram of the owning Activity.

Moving the parent is useful in case you have multiple activity partitions, and you move an action from one partition to another on the diagram.
Maybe there are also other use cases..

AFAIK the restriction that it doesn't jump if it's in different packages is a deliberate and documented behavior, and I wouldn't expect this to change anytime soon.

Geert

PeterHeintz

  • EA User
  • **
  • Posts: 869
  • Karma: +53/-18
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #4 on: June 17, 2020, 12:40:36 am »
Yes I agree that actions even "shall be owned" by their activity and actions are "normally" also only used on the activity diagram of the owning Activity.
But "normally" means that there are some exceptions which are explicitly mentioned in the UML Spec. see below.

NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not
preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.
Best regards,

Peter Heintz

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7301
  • Karma: +86/-12
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #5 on: June 17, 2020, 10:55:43 am »
As long as I've known, EA has automatically nested elements when moving them on a diagram, and except briefly with BPMN things it only ever did it within the same package.

The SysML frame complicates things a little because everything will always be inside the parent object. If you want to show things explicitly from an outside scope I'd recommend turning off the frame.

Yes I agree that actions even "shall be owned" by their activity and actions are "normally" also only used on the activity diagram of the owning Activity.
But "normally" means that there are some exceptions which are explicitly mentioned in the UML Spec. see below.

The UML metamodel only allows an action to be contained within a single Activity. There are no exceptions.

NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not
preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.
What this is talking about is that you can do something like show an action on a class diagram. It's not an exception to the UML metamodel.
Eve

support@sparxsystems.com

PeterHeintz

  • EA User
  • **
  • Posts: 869
  • Karma: +53/-18
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #6 on: June 17, 2020, 10:32:01 pm »
Hi Eve,
I do this kind of cross referencing and displaying for years with EA.
When you create a new action on a diagram it gets the as parent the activity of the belonging diagram. This is, from my perspective, what it should be and what it was only until V13.
Somewhere in V14 the actions started to move when dropped to another activity diagram but as I remember only when dragged and dropped from a diagram and not from the project browser or vice versa. In some later versions this was gone and I was happy (at least for SysML).
In V15.2 drag and drop does not change the parent anyway, but the parent is changed when the position of the item changes on the diagram. In this way, when you have an action on two activity diagrams and you change the position on either diagram the element can jump around what is really strange.
If we assume that the specs require an action to have one parent and exist on one activity diagram only, it should not be allowed to show an action on different activity diagrams at all, instead of this element movement jumping.
This movement-based jumping gets even more confusing if parent the action belongs to is locked, because than it does not jump.

I admit that neither SysML nor UML specs are very clear in those aspects, but by removing the example in the UML text I read the UML spec as follows:
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types. Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.

Apart of the strange position movement based jump implementation, the problem is that you go from less strict=not strict to more strict=not strict and this causes problems for models created in the “less strict” mode.

With "The UML metamodel only allows an action to be contained within a single Activity. There are no exceptions." I totally agree, but were on earth are diagrams in the UML metamodel at all?

PS Switching of the frames does not help because than I lose my activity parameters.
Best regards,

Peter Heintz

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 10519
  • Karma: +358/-31
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #7 on: June 17, 2020, 10:40:42 pm »
Peter,

I think the frame currently somehow represents the Activity itself, and EA sees that as a potential owner of the action.

The fact that you need to "wiggle" the action before EA recognizes that it needs to update the owner is bug since like since forever.

Geert


Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7301
  • Karma: +86/-12
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #8 on: June 18, 2020, 08:44:53 am »
EA has always set the parent of an object when it is moved on a diagram so that it is (visually) fully enclosed by a potential parent. It's also intentional that adding an element to the diagram doesn't act as a potential move. That's the reason why a 'wiggle' sets the parent. The main exception is when it would result in changing the package.

Where you are seeing a difference is that Sparx Systems bowed to pressure to explicitly show the parent object for all SysML diagrams as an explicit frame. (Completely unnecessary in my opinion, the diagram itself is the frame, but that's another discussion)

As Geert suggested, that parent of the diagram itself is then treated as a potential parent when moving an element on the diagram. That's why there was a change of behavior.

The good news is that there are things that EA offers to help you that I forgot to mention on my last reply.

  • If you don't want the parent set as part of a single move hold ALT before you release the mouse button.
  • If you never or rarely want that to happen Change Start > Desktop > Preferences > Diagram > Behavior > Auto Group Elements (hold ALT to toggle)
  • If you are creating a diagram where you are using elements from other parents you can hide the diagram frame for that diagram, use a non SysML diagram, or put the diagram into a different package
  • If you want to prevent an element's children from moving lock the parent. (Require user lock to edit makes this the default behavior)

With "The UML metamodel only allows an action to be contained within a single Activity. There are no exceptions." I totally agree, but were on earth are diagrams in the UML metamodel at all?
In short, they aren't. More accurately they are very separate.

My summary:
A Diagram is a type of Packageable element (so that they can appear in diagrams)
They have a composition relationship to a DiagramObject.
Along with styling and positioning information each DiagramObject has a reference to an Element in the model.

So, when you add an element to a diagram you are creating a new DiagramObject that references the object you are adding. It doesn't change the element at all.

UML places no constraints on the types of elements that can be referenced by each diagram type (which is what your quote is referring to) or where in the model they are coming from.
« Last Edit: June 18, 2020, 08:58:05 am by Eve »
Eve

support@sparxsystems.com

PeterHeintz

  • EA User
  • **
  • Posts: 869
  • Karma: +53/-18
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #9 on: June 18, 2020, 06:34:49 pm »
Hi Eve,
thank you very much for this very helpful information. Disabling the checkbox as you mentioned in 2. makes me happy.
After looking in my model in some places were I did such kind of things, I realized that in most case luckily, I have the activities in different packages. Not knowing that the package matters I came obviously to the conclusion that you change things frequently.
Although I do not understand, what sense it makes to move e.g. block property under an activity, once you ‘wiggle’ it on the activity diagram, I am with option 2. a happy user again! (at least in this case  ;))
Best regards,

Peter Heintz

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 7301
  • Karma: +86/-12
    • View Profile
Re: Element Hopping; Ups they did it again!!!!!! (Build 1551)
« Reply #10 on: June 19, 2020, 07:30:24 am »
I am with option 2. a happy user again! (at least in this case  ;))
And that makes me a happy developer.
Eve

support@sparxsystems.com