Combined Fragment has to cover all lifelines

[Matthias Schoettle]

A Combined Fragment has to cover all lifelines, even the ones that are used in nested combined fragments. I.e., when using a lifeline in a nested combined fragment, all containing combined fragments need to be updated as well.

Also, when deleting a lifelines, it needs to be removed from all.

[Matthias Schoettle]

References #162: Added the "covering" of the combined fragment for new messages that are created inside a combined fragment but where the lifelines does not cover the combined fragment yet. Furthermore, nested combined fragments are supported.

→ <<cset ba45cd302f78>>

[Matthias Schoettle]

Resolves #162: Adds the ability to cover lines by combined fragments.

When adding new messages or removing messages, operands or combined fragments, all covered combined fragments are considered (i.e., nested combined fragments). For example, when adding a new message, if it is added inside a combined fragment and the lifeline is not covered yet, it will be.

Furthermore, when figuring out during removal whether empty lifelines will result, all covered lifelines are considered.

The order of covered combined fragments is always from inner most to the outside, which means that in certain cases (e.g., removal) it needs to be reversed.

→ <<cset 06b354093078>>

[Matthias Schoettle]

Removal of nested combined fragments where an empty lifeline is deleted does not work properly. It causes an exception in MessageViewView.removeCombinedFragment(...) where combinedFragmentView is null. If a check is added, an exception occurs in another place during reversal (undo) of a delete.

This points to a more substantial problem with the way the commands are executed. In fact, before an operand is removed, empty lifelines need to be removed and removed from the "covered" of the combined fragments.

[Matthias Schoettle]

Resolves #162: Fixes the order of commands for the removal of a lifeline on covered combined fragments.

The removal of the lifeline and the covered link to combined fragments needs to take place before an operand is removed. There are two cases: When an operand is removed (just that operand is deleted) or during deletion of a combined fragment (before each operand itself is deleted).

This can lead to too many removals of the covered link, which is now avoided by making sure that it only happens when a lifeline was not deleted yet.

→ <<cset fbb922fedf4b>>

[Matthias Schoettle]

References #162: Readds the removal of the fragment which was accidentally removed in the previous commit.

Additionally fixes the removal of the covered link for CombinedFragments to ensure that only lifelines that are not going to be deleted are removed.

A known limitation is that lifelines, which are empty only within the combined fragment (i.e., other fragments outside of the combined fragment cover it), are not removed from the combined fragment. It is difficult to distinguish between the first (target) lifeline and others, which is necessary, because this fact does not apply to target lifelines (when detecting empty lifelines that can be removed). The covered links need to be removed before the fragment itself to avoid problems.

→ <<cset 0816524ab25f>>

[Matthias Schoettle]

Created separate issue for limitation described in previous comment: #304.

[Romain Alexandre]

Merged in Issues/162-combined-fragments (pull request #33)

Resolves #162: Fixes the order of commands when deleting combined fragments

→ <<cset e8ef5ac9197a>>