![]() 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. Recommendationĭue to the complex nature of the problem, there's no one-size-fits-all solution for these types of conflicts. This will cause similar problems to the above example, as the position information of all messages after the deleted one will also be affected.ĭeleting a message will only change the PtStartX/PtStartY properties of the following messages, while leaving the SeqNo properties intact. To demonstrate this, we will edit version B further by removing the message verify pin():įigure 4: Message verify pin() has been deleted Similar conflicts can occur when removing messages aswell. SeqNo: The position of the message relative to the other messages.PtStartY: The starting position of the message on the Y-Axis.PtStartX: The starting position of the message on the X-Axis.If you look at these conflicts in the property viewer, you will see something like this:įigure 3: Conflicting Properties of unchanged messages 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. Merging these two versions (with the correct base model) will lead to this merge preview:įigure 2: Merge Preview of Conflict caused by adding messages in parallel Version B has two new messages after pin ok().Version A has a new message after insert(card).To demonstrate this, two change-sets have been applied to our ATM example: Possible Consequences Of Different Modifications Adding/Removing/Moving Messages At Different Positions Adding Messagesĭifferent types of conflicts can occur when messages have been added at different positions to different versions of a sequence diagram. The following paragraphs detail multiple variants of parallel changes to this sequence diagram and the potential pitfalls when merging them with LemonTree. Let us consider this simplified sequence diagram for an ATM transaction:įigure 1: Simplified ATM transaction sequence diagram ExampleĪn example is always good for understanding (especially in this case). LemonTree neither interprets nor merges the semantics of the models it processes. However, this stands in conflict with LemonTree's philosophy as a merge tool. This means that merging sequence diagrams correctly is possilby even more important than other diagram types. In a sequence diagram, positions are important not only for the look-and-feel of a diagram, but also for its semantics. Sequence diagrams are a special case for LemonTree, which comes with its own difficulties.
0 Comments
Leave a Reply. |