Comment 1 Mathieu Velten 2010-10-28 11:21:31 EDT

commited (rev 3048).

Comment 2 Yann Tanguy 2010-10-28 19:09:15 EDT

Thanks for the work done Mathieu. I reopen this task as some issues still need to be addressed.

MessageEndHelperAdvice:
- copyright tag missing

ExecutionSpecificationHelperAdvice:
- The model deletion should not rely on diagram specific information. See following code:

		// add visually linked messages
		for(Setting usage : usages) {
			if(usage.getEObject() instanceof View) {
				dependentsToDestroy.addAll(getLinkedMessagesFromView((View)usage.getEObject()));
			}
		}
		
		The delete from model action should not have a different result if some elements are shown or not on diagram. It would be a good thing to remove message connected to ExecutionSpecification but this has to be done by parsing the model only. Using the order of OccurrenceSpecification along a Lifeline might help with this but requires to maintain a consistent order in the model during the diagram lifecycle. Probably not an easy task but without this order consideration I fear that model will not be fully analysable by tool without parsing notation as well.
		
LifelineHelperAdvice:
- Same comment as the previous one for "Child" lifeline do not rely on the diagram for model deletion:

		for(Setting usage : usages) {
			if(usage.getEObject() instanceof View) {
				dependentsToDestroy.addAll(getChildLifelinesFromView((View)usage.getEObject()));
			}
		}
	
	This should be avoided, and should not be needed. The problem here is that in such a case the sequence diagram does not build the model correctly. While adding a new "Child" lifeline :
	- A New lifeline should be created
	- A PartDecomposition should be created referencing the new lifeline
	- The "Parent" lifeline should reference the new PartDecomposition with "decomposedAs" reference

Comment 3 Mathieu Velten 2010-10-29 04:29:26 EDT

hi Yann,
Thanks for the report.

1) oups :)

2) and 3) Yes I know but ATM it is better than nothing.

The order between InteractionFragment should be correctly handle very soon thanks to Vincent. When it will be stable enough I will patch this.
For the lifeline decomposition I was not aware how it really works, now that I know I will correct that ASAP for the creation and the deletion.

Comment 4 Mathieu Velten 2010-10-29 05:56:32 EDT

3 commited, with correct creation of decomposed lifeline.
please check, since I am not very comfortable with this notion.

Comment 5 Mathieu Velten 2010-11-02 12:38:24 EDT

2 commited, bug closed.

Comment 6 Yann Tanguy 2010-11-03 10:30:31 EDT

(In reply to comment #4)
> 3 commited, with correct creation of decomposed lifeline.
> please check, since I am not very comfortable with this notion.

Normally, the part decomposition should reference an (new) Interaction containing the "Child" Lifeline(s). Also in such a case, the PartDecomposition should show "borders" (like Interaction borders) so that Messages can connect a "Child" Lifeline to a Gate, and possibly use another message to propagate from that Gate to other Lifeline(s) in the initial Interaction.

That said, in my opinion your current implementation is a reasonable choice for now which simplifies the management of messages to (from) "Child" Lifeline(s) and other Lifeline, and allow to use inline PartDecomposition.

The creation of "Child" Lifeline in another Interaction would currently introduce various issues (possibly 2 Seq Diagram showing the content of the same Interaction, allow possible reuse of Gate(s), managing in a diagram views of Lifeline(s) from another Interaction...). This make sense in order to fully respect the specification, but would probably introduce various issues in this diagram. Let me know if you think its easier than what I expect.

I suggest to let this "PartDecomposition" as is for now, and focus on possible issues related to a more classical use of the Sequence Diagram.