Empty Lifeline in combined fragment not removed

[Matthias Schoettle]

When removing a message inside a combined fragment, which leads to the lifeline not having any fragments left within the combined fragment, the lifeline is not removed from the combined fragment. I.e., the combined fragment still covers the lifeline.

Instead, it should be automatically removed.

Consider the following example where, when do() inside the combined fragment is deleted, the myObs lifeline is not removed from the combined fragment(s).

A possible solution is to find out whether any fragments inside a combined fragment will be left on the lifeline. If not, the lifeline is removed from the combined fragment(s). However, the first lifeline the combined fragment is on cannot be removed. To find out, it might be possible to use RAMModelUtil.findInitialMessage(...) and get the lifeline of the receive event.

Related: #162

[Matthias Schoettle]

References #304: Adds test cases to check removal of messages within combined fragments.

Specifically, it is tested that when lifelines are removed from the combined fragment as being covered by the combined fragment.

→ <<cset 5d4c0d800b07>>

[Matthias Schoettle]

References #304: Adds test cases for nested combined fragments.

→ <<cset 3a5eb7fc83c9>>

[Matthias Schoettle]

References #304: Adds test cases for removal of CombinedFragments and InteractionOperands.

The model to test is based on the one used for removal of messages (see Messages.ram from commit 3a5eb7f).

→ <<cset 632c3d0e9f37>>

[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>>