Author Topic: !!!!!Please withdraw relocation of elements when dragged and dropped from one di  (Read 692 times)

PeterHeintz

  • EA User
  • **
  • Posts: 817
  • Karma: +49/-17
    • View Profile
I realized that now, when you drag and drop an element from one diagram to another, the element is relocated under the assumptions that the element should have the same place as if it was created on the diagram.
However, if you want to show the element on several diagrams by creating the drag and drop link, this new (at least for me bad feature) causes the element to jump around within the repository each time you put it to an additional diagram.
Best regards,

Peter Heintz

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9542
  • Karma: +275/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
How do you do that exactly?
 
I just tried dragging some elements from the project browser to a diagram, and I don't see any relocation of the element happening.

Geert

OpenIT Solutions

  • EA User
  • **
  • Posts: 491
  • Karma: +5/-0
    • View Profile
Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9542
  • Karma: +275/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.
That behavior I know and understand. But not just any element on any diagram.

Geert

qwerty

  • EA Guru
  • *****
  • Posts: 10629
  • Karma: +234/-194
  • I'm no guru at all
    • View Profile
Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.
I guess you mean pools/lanes. Swimlanes are just graphics on a diagram.

q.

PeterHeintz

  • EA User
  • **
  • Posts: 817
  • Karma: +49/-17
    • View Profile
No, what I mean has nothing to do with pools/lanes/swim lanes!

When you add an element from the toolbox to a diagram, it gets typically located under the parent of the diagram. This is a solution which fits to most cases I have.

If you add an element to any diagram from the project browser in the very most cases it remains on its project browser location. This is a solution which fits to most cases I have as well.

Before current version(s!), when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram”, the element typically remained on its original location. What was good!

Now in current version(s!) when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram” several types of elements are relocated to the parent of the dropped diagram.

I have several scenarios where this is bad.

Exapmle: In activity diagrams I frequently use a send signal action in one activity diagram and several accept event actions in other diagram.
To get a glue where a signal comes from what is “accepted “, I connect the send/accept actions with trace links and to visualize that link, I drag and drop the send action to the activity diagram having the accept event action.
Before V14 I put the send signal action outside of the activity diagram boarder frame, to clearly mark that it is a kind of visual reference and does not belong the activity. Unfortunately since V14 it is not allowed to have thing outside of the diagram frame anymore.

Anyhow, now when I drag e.g. an action from the project browser to an activity diagram it remains on its browser location and if I do a “Create Link on this Diagram” it jump.
For some (not all) other element types I saw the same. Why on earth, an element what is in !!!addition!!! shown on the second diagram has to move its location anyway? And why only when I fetch the element from a diagram rather than from the project browser?

This behaviour is quiet illogical and annoying.
Best regards,

Peter Heintz

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9542
  • Karma: +275/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
You are not supposed to re-use actions on different Activity Diagrams (owned by different Activities), so I guess that is why this happens.


Geert


PeterHeintz

  • EA User
  • **
  • Posts: 817
  • Karma: +49/-17
    • View Profile
Hi Geert,
you are right, Sparx seem to think somehow in this direction!

However, even if so, with my diagram drag/drop procedure the action is still on many diagrams, owned by different activities. So the implementation is a bug anyway.

From my interpretation of the standard, I would say:
1) An action should be owned only by one activity
2) No action should have a kind of flow to other activity nodes not owned by its own owner
3) An action can have dependency links to actions not owned by its owner
4) !!!And!!! An action can be shown on an activity diagram or any other kind of diagram not owned by its owner

###################
The last one I derive from this part of the standard:
„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.“
####################
Or see here:
https://www.uml-diagrams.org/uml-25-diagrams.html

I have the feeling that Sparx tries to be more UML compliant, what is in principle not a bad thing, but they overshoot somehow.
With the new Sparx implementation it is really hard and might get impossible in future to visualize cross-cutting relationships, and this would be very bad.
Best regards,

Peter Heintz