Author Topic: Drag-and-Drop pattern for nesting  (Read 788 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Drag-and-Drop pattern for nesting
« on: June 30, 2005, 07:06:31 pm »
Hi,  below is a quote from a bug report I've sent to Sparx regarding swimlane behaviour.
Quote
When I put a number of elements in a swimlane and I press autosize, I (and the modeller in the street - 'cos I did a survey :-)) expect that the size should become the smallest size that will fit the current set of enclosed shapes on that diagram - particularly if they have been formally nested using the nesting connection!

Can this be fixed please...

Do you think the nesting relationship should be automatically created if I move an element into the swimlane?  We think so.  Further, if you Drag an element out of the swimlane, the nesting connector should show (which it does).  If I Alt-Drag the element out of the swimlane, I want the nesting broken.  If I move (Drag) the element between swimlanes, the nesting should be transferred to the new swimlane.  If I copy (Ctrl-Drag) the element between swimlanes, I swimlanes, I want a copy made in the new swimlane.

I think this is such a powerful pattern...
Aside from asking for comments on whether the swimlane behaviour should be as I outlined, it seems to me that there are many places within EA where such nesting occurs.  

Should we encourage the Sparxians to orthogonally reproduce this behaviour in all such places?

I'm seeking feedback on the conceptual design (did I forget anything, is there a better combination of keys etc) I proposed and also on the parts of EA where such a design could be applied.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

skiwi

  • EA Practitioner
  • ***
  • Posts: 1727
  • Karma: +23/-49
    • View Profile
Re: Drag-and-Drop pattern for nesting
« Reply #1 on: July 21, 2015, 09:12:55 am »
+1
Orthogonality rules
Using EA12.1 (1229) on Windows 10 Enterprise/64 bit. Repositories in SQLServer2014 R2 & Access2003/JET4.0

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Drag-and-Drop pattern for nesting
« Reply #2 on: July 21, 2015, 09:38:07 am »
Quote
+1
Hi skiwi,

That's a "blast from the past"!

Since then, my thoughts around nesting and other collective relationships (Aggregation, Composition, Specialisation,  ArchiMate Grouping  etc.) have been refined.

Perhaps it's time to open a topic in the UML section on the nature of such relationships and any support Sparx should give.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

skiwi

  • EA Practitioner
  • ***
  • Posts: 1727
  • Karma: +23/-49
    • View Profile
Re: Drag-and-Drop pattern for nesting
« Reply #3 on: July 21, 2015, 12:21:43 pm »
Well yes. I was looking for some usability enhancements for diagrams, and though that I'd review old postings.

A useful posting indicates that partitions (in the activity toolbox) are the improved solution.

However swimlanes and matrices have a place, and it seems to me some minor changes could provide significant improvements for use.
Orthogonality rules
Using EA12.1 (1229) on Windows 10 Enterprise/64 bit. Repositories in SQLServer2014 R2 & Access2003/JET4.0

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5874
  • Karma: +71/-77
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Drag-and-Drop pattern for nesting
« Reply #4 on: July 21, 2015, 05:50:13 pm »
Quote
Well yes. I was looking for some usability enhancements for diagrams, and though that I'd review old postings.

A useful posting indicates that partitions (in the activity toolbox) are the improved solution.

However swimlanes and matrices have a place, and it seems to me some minor changes could provide significant improvements for use.
In my view it's all wrapped up in the notion of Collection relations/elements.  You need to answer the question:
Can an element be in more than one collection at a time?  A collection could be the items in a partition/swimlane - to cite JUST one example.

If the answer is yes, then what we have now is difficult to manage.

Notwithstanding there's a thread here, I think this needs to start afresh with a discussion of the concepts involved, leading to proposals for how to manage them more effectively and efficiently.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!