Deleting messages from a Message View broken in some cases

[Matthias Schoettle]

In some cases, when a message is deleted from a message view, not enough or too many subsequent messages are removed.

At least in the following two scenarios this occurs:

• a message with no reply, where a message follows (as a definition of behaviour of the first message), when deleting the first one, the second message (nested behaviour) is not removed
• same scenario as above, but a third message is existing originating from and to the same lifelines as the first message. When deleting message #2, the third one is deleted as well.

It should also be checked that other fragments (combined fragments and execution statements) in nested behaviour are removed as well.

[Matthias Schoettle]

References issue #194: Fixed the retrieval of toIndex when deleting messages. In case the message end is not the receive event or it is not a message occurrence, the index also needs to be set to index - 1, because this means that the current fragment is not part of the message to be deleted.

→ <<cset 6f0a812433e7>>

[Matthias Schoettle]

References issue #194: Fixed out of bounds problem.

When undoing the removal of messages, the messages are added again in a different order than they are deleted. For that reason the view index needs to be decreased to the maximum possible value.

→ <<cset eef09ed7b936>>

[Matthias Schoettle]

References issue #194: Made ValueSpecificationHandler generic (it only supports to change the value of a specific value specification) in order to be able to sub-class it (the full functionally is now in ReferenceAndValueHandler) so that it can be used for execution statement specifications, interaction constraints and the value specifications of return messages or parameter values in messages.

→ <<cset 5e08a2b8c7c9>>

[Matthias Schoettle]

References issue #194: Fixed problem when adjusting the view index. The view index should only be decreased by 2 if it hasn't been adjusted already, because the view index is greater than the existing children.

→ <<cset 49b2c84cca08>>

[Matthias Schoettle]

References issue #194: Fixed retrieval of toIndex, which also has to be done when the current fragment is not a message end.

→ <<cset 431c6da7a6b2>>

[Matthias Schoettle]

References issue #194: Fixed problems when deleting messages.

• changed check when determining how many fragments need to be deleted, because CombinedFragments can have multiple covered lifelines, so that containsAll on covered of a messag end will always be false
• changed DeleteCommand to RemoveCommand for the fragments so that the result of the compound command will contain the fragments in it (the DeleteCommand is only properly initialized before execution)

→ <<cset cfa4972c57e9>>

[Matthias Schoettle]

References #194: Fixes index out of bounds problem when adding a fragment to a lifeline that starts with a create message, but the message is added inside a combined fragment. In that case, the view index does not need to be adjusted, since its event container is not affected by this special case.

→ <<cset df8f27bdef5e>>

[Matthias Schoettle]

References #194: Updates the HandlerFactory to make the InteractionConstraint and ExecutionStatement handlers stateful (since they are). Otherwise, when openeing two or more keyboards, invalid behaviour is observed (all text views with an opened keyboard will get their data overwritten with the first one).

→ <<cset 20789a19904e>>

[Matthias Schoettle]

The problem still exists based on the below screenshot, if you remove the create message, the second call to bla() is removed as well.

In MessageViewController.createRemoveMessagesCommand when determining the toIndex, it still does not consider if on the calling lifeline, there is no reply message coming back, so either too many (if there additional unrelated fragments) or not enough (if there are no fragments on the same lifeline) fragments are removed.

The proposed change in #399 would make this a lot easier.

[Matthias Schoettle]

References #438 and #194: Adds more test cases for nested behaviour.

Also, for #194, a specific test case is added (testRemoveMessages_NestedNestedBehaviour), which fails right now.

→ <<cset 8f664f61f16c>>

[Matthias Schoettle]

References #438 and #194: Adds another test case for nested nested behaviour.

This test cases checks the second case of getting the toIndex, where no other fragment is on the outgoing lifeline, which causes only the one message being removed.

→ <<cset 5edfe37d93f6>>

[Matthias Schoettle]

References #304, #438, #194: Improves removal of fragments and messages.

All removal is now performed by the FragmentsController, i.e., the MessageViewController delegates this task to it now.

Removal is improved significantly in that: - all to be deleted fragments are determined - all affected messages are deleted - unused properties are removed - unused combined fragments are removed from lifelines (when no other fragment within a combined fragment covers a lifeline) - unused lifelines are removed

The end of the message behaviour (for nested behaviour) is properly detected. Nested behaviour needs to be terminated with a reply message. However, it still works in the case that another fragment is placed on the same originating lifeline.

→ <<cset 569a78a97a89>>

[Matthias Schoettle]

References #304, #438, #194: Fixes test cases and models to address changes introduced.

Create message with nested behaviour now have a reply message. When removing a combined fragment or operand, the fragments are not specifically removed, but are removed by removing the container (operand).

→ <<cset 0dadc71a6aea>>

[Matthias Schoettle]

References #304, #438, #194: Moves helper method to remove temporary properties to FragmentsController.

→ <<cset 225c64c31658>>

[Matthias Schoettle]

Merged in Issues/165-MessageView-Improvements (pull request #94)

Message View Moving and Stability and Association and Code Generator Improvements

Resolves #165, #304, #438, #194

Approved-by: Emmanuel Ng Cheng Hin [e-mail]

→ <<cset 5cb678b133d5>>

[Matthias Schoettle]

References #304, #438, #194: Fixes order of fragment removal commands to prevent problem when undoing.

The call to isSelfMessage caused an OCL exception because the coveredBy of the send event was not set yet. Therefore the coveredBy is removed separately after all fragments are removed, so that this is already set when undoing it.

Small refactoring in MessageViewController to pass the message instead of the end, to ensure that the send event is passed to removeInteractionFragment.

→ <<cset f8ccee565d88>>