Merge of Sequence Diagrams
Sequence diagrams are a special case for LemonTree, which comes with its own difficulties. In a sequence diagram, positions are important not only for the look-and-feel of a diagram, but also for its semantics.
This means that merging sequence diagrams correctly is possilby even more important than other diagram types.
However, this stands in conflict with LemonTree's philosophy as a merge tool. LemonTree neither interprets nor merges the semantics of the models it processes.
An example is always good for understanding (especially in this case). Let us consider this simplified sequence diagram for an ATM transaction:
Figure 1: Simplified ATM transaction sequence diagram
The following paragraphs detail multiple variants of parallel changes to this sequence diagram and the potential pitfalls when merging them with LemonTree.
Possible Consequences Of Different Modifications
Adding/Removing/Moving Messages At Different Positions
Different types of conflicts can occur when messages have been added at different positions to different versions of a sequence diagram.
To demonstrate this, two change-sets have been applied to our ATM example:
- Version A has a new message after insert(card)
- Version B has two new messages after pin ok()
Merging these two versions (with the correct base model) will lead to this merge preview:
Figure 2: Merge Preview of Conflict caused by adding messages in parallel
Which looks fine at first glance. However, the problem is that adding these new message has changed the properties of all of the following messages in both models, leading to conflicts for all of these messages aswell, even though they haven't been edited.
If you look at these conflicts in the property viewer, you will see something like this:
Figure 3: Conflicting Properties of unchanged messages
The affected properties are:
- PtStartX: The starting position of the message on the X-Axis
- PtStartY: The starting position of the message on the Y-Axis
- SeqNo: The position of the message relative to the other messages
Similar conflicts can occur when removing messages aswell. To demonstrate this, we will edit version B further by removing the message verify pin():
Figure 4: Message verify pin() has been deleted
This will cause similar problems to the above example, as the position information of all messages after the deleted one will also be affected.
Deleting a message will potentially only change the SeqNo properties of the following messages, while leaving the PtStartX/PtStartY properties intact.
Similar conflicts can occur when removing messages aswell. To demonstrate this, we will restore the message verify pin() in version B, and move it to a different position instead.
Figure 5: Message verify pin() has been moved
This will cause similar problems to the above example, as the position information of all messages after the moved one will also be affected.
Deleting a message will only change the PtStartX/PtStartY properties of the following messages, while leaving the SeqNo properties intact.
Due to the complex nature of the problem, there's no one-size-fits-all solution for these types of conflicts. The general recommendation is to take the properties from the side (A or B) that you think fits is less work to fix up, and the re-adjust the diagram manually in Enterprise Architect afterwards.
Adding A Message At The Same Position Without Moving Other Messages
A special case within this special diagram type occurs when both versions of the model have added a new message at the same position in the model without moving any of the other messages.
Sucha modification can be seen here:
Figure 6: Messages added at the same position in A and B
This case is tricky to detect with LemonTree. All of the following messages will receive new SeqNo values, but, because these values will be increased by 1 in both A and B, they will be identical in both models. As such, LemonTree doesn't detect a conflict in this scenario at all.
Should such a case occur, the consequences in the merge model depend on the PtStartX/PtStartY assigned to the respective new messages. The messages may appear on top of each other, or in an order that is not semantically correct. Currently, this must be manually rectified by the modeller after the merge.
Concurrently moving lifelines will also result in conflicts. The result of such a move can be seen here:
Figure 7: Conflict caused by conflicting moves of lifeline elements
Moving the lifelines has changed their page index (stored as value cx as apart of the PDATA property) to different values in both A and B.
If this is the only change to the PDATA property, you can safely pick the PDATA from either side. You should still check the result in the merge model, though.
Merging fragments can lead to a multitude of problems, none of which are detected as a conflict in LemonTree:
- overlapping fragments
- resizing of fragments, leading to messages either "falling into" or "falling out of" a fragment
An example for a merge resulting in overlapping fragments can be seen in this figure:
Figure 8: Overlapping fragments because of concurrent edits
Merges of fragments currently require a manual review of the merge result in all cases.
Using filters to analyze changes on sequence diagrams
It is possible to use the Filter Feature in order to better understand the changes made on sequence diagrams.
The following example is given:
In one of the diffed versions, a new sequence message was added. The sequence message was added between other existing messages, which leads to a reordering of the message displayed below the new message.
If you want to find out, which sequence messages have been added only and not modified by the automatic reordering, you can use the following filter:
NOT UmlType: ea\_Diagram AND NOT ChangeIn: "EA Specifics 1.0::SeqNo" AND NOT ChangeIn: "EA Specifics 1.0::PDATA5" $HideGraphicalChanges $OnlyMatchingChildElements
This will reduce the Tree Browser and the Impacted Diagrams List to the newly added connectors and with their connecting elements.
If you want to also hide the lifelines / components / ports that are shown as changed (because there was a new link added to them), you can use the following filter:
NOT UmlType: ea\_Diagram AND NOT ChangeIn: "EA Specifics 1.0::SeqNo" AND NOT ChangeIn: "EA Specifics 1.0::PDATA5" AND NOT UmlType: InstanceSpecification AND NOT UmlType: Component AND NOT UmlType: Port $HideGraphicalChanges $OnlyMatchingChildElements
With this filter, the Tree Browser and the Impacted Diagrams List is reduced to all sequence messages, that were added to the diagram.
The original source (in german) is available here:
The models mentioned in the article can be downloaded here: