Improve CombinedFragment support

[Matthias Schoettle]

Continues issue #131.

The support for CombinedFragments needs to be further improved:

• Ability to create and delete new operands
• Either don't allow to create/delete minimum amount of operands or add constraints; if there's only one it should never be possible to delete it; loop, critical and opt have 1, alt and disruptable have 2 or more.

[Matthias Schoettle]

An idea for CombinedFragment support we discussed in a meeting on 11.06.2014:

• double-tap to change the operator type
• tap-and-hold for option menu to delete (except first) and add new operands (except for those with max 1)
• add new ones at the end
• allow to reorder the operands (by dragging)

[Matthias Schoettle]

References issue #166: Increased width of CombinedFragmentView to have some space after the last lifeline.

→ <<cset c358fff710da>>

[Matthias Schoettle]

References issue #166: Notifications from any operand regardless of how nested the combined fragments are are considered.

→ <<cset 5d329ca0a025>>

[Matthias Schoettle]

References issue #166: Actual view (that PlacerholderView represents) is not destroyed when the placeholder is destroyed. Otherwise, when deleting a LifelineView that contains a placeholder for a combined fragment, the CombinedFragmentView is destroyed as well. However, it doesn't mean that the combined fragment is deleted as well. In the case of removing an execution statement, the actual view is destroyed in addition.

→ <<cset fc192e470cd3>>

[Matthias Schoettle]

References issue #166: Layouting improved in order to support re-layouting when messages in an operand are removed. After removing a message the message view is re-layouted even though the send and receive event are removed after. The layouting algorithm ignores removed messages, so there is no need to wait for the removal of the events anymore.

→ <<cset 620f71b74700>>

[Matthias Schoettle]

References issue #166: The spacers after a combined fragment only allow message creation for the first lifeline.

→ <<cset ec43743d5783>>

[Matthias Schoettle]

References issue #166: Added support for adding and removing interaction operands.

The initial operator kind is now opt with one operand. Then, more operands can be added by tapping-and-holding on the constraint. All operands except the first one can be removed.

When removing an operand, first the contents (messages and other fragments) are removed. The same for removal of the whole combined fragment: First, the operands and their contents are removed from the bottom up. This ensures proper and consistent undo/redo support.

→ <<cset e8abff087d72>>

[Matthias Schoettle]

References issue #166: Added constraints to assure that depending on the operator kind the number of operands is valid.

→ <<cset 4f8df9327753>>

[Matthias Schoettle]

References issue #166: Added support to delete lifelines that become empty as a result of deleting a combined fragment, operand or message inside a combined fragment.

→ <<cset 222e8ef939a1>>

[Matthias Schoettle]

References issue #166: Extracted method that takes care of removal of empty lifelines that can be called from several places:

• when removing a complete combined fragment
• when removing an interaction operand
• when removing messages

→ <<cset 03bb12cdce62>>

[Matthias Schoettle]

References issue #166: Removed the default minimum height, which would prevent the combined fragment view from shrinking smaller when it is needed (e.g., removing the second operand with an empty first operand).

→ <<cset 2b53397c0b3d>>

[Matthias Schoettle]

References issue #166: Fixed the commands concerning covered/covered By. Over all commands, the same feature of this bidirectional association needs to be modified. Otherwise wrong modifications can occur depending on the order of commands, for example:

• Add message (in combined fragment)
• remove message (between same lifelines) outside of combined fragment and above
• undo twice

When removing the previously added message, the wrong fragment is removed from the lifeline, because the order of the events on the lifeline has changed.

Using the same side of the association in all commands resolves this issue.

→ <<cset 6f06032c97ca>>

[Matthias Schoettle]

Merged pull request #8 into master.

Remaining issue: Creating a lifeline inside a combined fragment is not layouted properly.

[Matthias Schoettle]

References #166: Adds support for create message inside a combined fragment:

• the operands height on a lifeline is calculated correctly if it is created in the combined fragment. This has to be done when the lifeline gets a request to set the operand height, because all required information is available there.
• if there are operands above the one where it is created, the operands are first added, but need to be removed once this information is available (this is only once the message is added, so after addInteractionOperand was called, in moveRelationshipEnd)
• consideration is necessary that an operand view could not exist
• the lifeline's first spacer on the base event container is hidden as well

→ <<cset e78ae1b56195>>

[Matthias Schoettle]

Merged pull request #9 into master.

[Matthias Schoettle]

References #166: Updates the calculation of combined fragment's width to take into consideration the width of statements (basically assignment and execution), since they can become wider depending on their content.

Every fragment that is an ancestor of a combined fragment is used to calculate the max width, which prevents nested combined fragments to become wider than its parent combined fragment.

→ <<cset 250ebed4b309>>