Hi Bob, et al.,

I find it a good initiative to bring this to the dev list.



Bob Tarling wrote:
> It seems there is some work to do yet in sequence diagrams in order to
> have the model and diagram in synch regarding activators and
> predecessors.
> 
> If the user changes activator or predecessor using the property panel
> then the ordering of messages on the diagram should change to reflect
> that.

The proppanel functionality is quite limited and buggy in this area - 
needs more work.

But, these model changes may also be invoked by notation, i.e. editing 
the texts on the diagram can also reshuffle messages. Please do not 
underestimate the possibilities here - I was quite surprised myself when 
I found out some of it.

E.g. changing "1.1:blabla()" into "2:blabla()" does change the model 
accordingly!


> ...



> Whats more there may be several sequence diagrams showing different
> views of the same interaction. A change to position of messages in a
> diagram may require change to the model which in turn may require
> change to position of messages in other diagrams.
 >
 > These diagrams may well be incomplete showing only some of the parts
 > of a sequence diagram interaction.
 >

Thanks to the discussion in issue 4087 (and 4086, 4128) ArgoUML will not 
allow this in any near future, so this problem is not a problem.
In short: for now: one collaboration = one diagram.


> ...
> 
> I see three choices
> 
> 1)
> 
> Allow the FigMessage positions and model to get out of synch and
> expect the user to correct (but preferably have critics that can
> report this as high priority)
> 
> 2)
> 
> Restrict dragging of messages so that the user can't reorder then.
> 
> Dragging of messages will still be allowed within a restricted range
> so that the user can still arrange position and layout better than
> they can in the current stable release.
> 
> The user can still change activator and predecessor in the property
> panel (should that break sequence on diagram we should have a critic)
> 
> 3)
> 
> We complete the work in full for first release so that diagram and
> model are in synch.
> 
> 
> 
> I would suggest we go for option 1 on first release with post release
> sequence work concentrating on removing that restriction and getting
> us to option 3.
> 

Agreed.



Kind regards,
Michiel

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1047005

To unsubscribe from this discussion, e-mail: 
[[email protected]].

Reply via email to