1. Concurrent Modeling in the Early Phases of the
Software Development Life Cycle
Petra Brosch, Philip Langer, Martina Seidl, Konrad Wieland,
and Manuel Wimmer
CRIWG 2010, Sept. 20-23, 2010, Maastricht, The Netherlands
www.modelversioning.org
Konrad Wieland
Business Informatics Group
Institute of Software Technology and Interactive Systems
Vienna University of Technology
Favoritenstraße 9-11/188-3, 1040 Vienna, Austria
phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896
office@big.tuwien.ac.at, www.big.tuwien.ac.at

2. Reality vs. Truth
Modeler A
Modeler E
Modeler B
Modeler D Modeler C
2

3. The Elephant and the Blind WoMen
Copyright: John Godfrey Saxe „The Elephant and the Blind Men“ 3
Picture: G.R. Guzlas

4. Common Knowledge Base
Modeler A
Modeler E
Modeler B
?
Modeler D Modeler C
4

5. Tool Support
Optimistic Model Versioning Systems
Comparison
Resolution
Detection
Conflict
Conflict
Version 0 Version 1
Merge
Front End
Sally Check Out Check In
Back End
Model Repository
Check Out Check In
Front End
Harry Version 0 Version 2
t0 t1 t2 t3
5

6. Issues of Serial Versioning
C C C C
It‘s a
Rope!
It‘s a Fan! It‘s a It‘s a Tree!
Spear!
Modeler A Modeler B Modeler C Modeler D
C … Changes
6

7. Tool Support Needed…
Modeler A
Modeler E
Modeler B
 to assist a collaborative process of modeling
 to allow integrating different points of view
 D
Modeler to promote multilateral perspectives for conflict resolution
Modeler C
7

8. Issues of Standard Merge Scenario
Passport as
V1a part of one
Person Passport Person
name passNo
Delete/Update
birthday hash
citizen
Person
V2 Conflict!
Harry name
birthday
passNo
V1 hash
V1b citizen
Person Passport Person
Sally
name passNo name
bday bday
passNo
Sally
One class for
Alice efficient
querying
V1c
Person * Passport
name passNo Several
doB expiry
persons in
one passport
Joey
Model stored in the 8
Repository

9. Issues of Standard Merge Scenario
V1a Delete/Update
Person Passport Conflict!
name passNo
birthday hash
citizen
Update/Update
V2 Conflict!
Person
Harry
name
birthday
V1 passNo
hash
V1b citizen V3
Person Passport Person
Sally
Person * Passport
name passNo name
bday bday name expiry
passNo doB
hash
Sally citizen
Alice passNo
Joey
V1c
Person * Passport
name expiry
doB passNo
Joey
9

10. Issues of Standard Merge Scenario
 Only one modeler is responsible for conflict resolution
 Nearly impossible to divine the reasons behind the changes
 Own point of view would always be prioritized
 Final version does not reflect all intentions of the modelers
 Conflicts are considered to be negative
 Conflict Avoidance
 Synchronous modeling or locking
 Conflict Resolution
 Often error-prone and time-consuming task
 Conflicts are not subject of discussion
10

11. Conflict-tolerant Merge
 To avoid conflict resolution during check-in
 To distribute the responsibility when merging
 To avoid loss of information
 To create a basis for discussion and consolidation (early project
phases!)
 Merge incorporates ALL changes
 Changes are represented in an unified view
 Potential conflicts have to be marked, tracked, and managed later on in
a collaborative setting
 Conflict-tolerant Merge
11

12. Conflict-tolerant Merge
V1a Delete/Update
Person Passport Delete/Update
name passNo
birthday hash
citizen
V2
1
Harry Person Passport
name 2 hash
V1 birthday citizen
passNo Violation
V1b
Person Passport Person
name passNo name
bday bday 3 V3
passNo
* 1
Person Passport
Sally
name 2 passNo 4
Alice
doB 5 expiry
hash
V1c citizen
Person * Passport
name passNo
doB expiry Update/Update
Update/Update
Joe
Model stored in the 12
Repository

13. <<Delete/Update Conflict>>
--User related Metadata
Metadata Annotations User_del = Sally
User_upd = Harry
<<Violation>> User_upd = Joe
Owner = Alice
--User related Metadata
User_upd = Harry --Involved Model Elements
User_upd = Joe Del_Elements = {Passport}
Owner = Alice Upd_Elements = {expiry, hash,
3 citizen}
1
--Involved Model Elements
Upd_Elements = {Composition1} Person * Passport --Time related Metadata
Upd_Elements = {Multiplicity *}
name 2 passNo Revision_del = 3
4 Revision_upd = 2
doB 5 expiry
--Time related Metadata Revision_upd = 4
hash
Revision_upd = 2
citizen 1
Revision_upd = 4
3
<<Update/Update Conflict>> <<Update/Update Conflict>>
--User related Metadata --analogous to 2
User_upd = Harry …
User_upd = Joe …
Owner = Alice 4
--Involved Model Elements
Upd_Element = {doB} <<Delete/Update Conflict>>
Upd_Feature = Attribute.name
Upd_Values = {Joe:doB, --analogous to 1
Harry:birthday} …
…
--Time related Metadata
Revision_upd = 2 2
13
Revision_upd = 4 5

14. Consolidation
Alice
Violation Delete/Update
Delete/Update
Harry
4
1
*
Sally
Person Passport
name 2 passNo 3
Joe
doB 5
birthday expiry
hash
Update/Update
citizen
Update/Update
Result of Standard
Versioning Process
Person * Passport
name passNo
doB expiry
hash
citizen
Joe
14

15. Realization
 Conflict-tolerant merge algorithm
 Extension of standard versioning systems
 Provision of conflict model
 Allows to store conflicts explicitly
 UML Profile for conflict visualization
 Allows for reusing standard UML modeling editors
15

16. Conflict-tolerant Merge Algorithm 1/2
Modeler A
apply Changes
Central Repository
MergedModel
OriginModel V0 HeadModel V0+ 1 + 2
copy
1
apply Changes
2 and annotations
MergedModel(delta1+delta2(originModel))
without conflict resolution
Modeler B
RevisedModel
16

17. Conflict-tolerant Merge Algorithm 2/2
Create a copy of the
Input: originModel, revisedModel, headModel headModel as basis for the new
Output: mergedModel mergedModel
mergedModel = headModel.clone() Calculate change set
for c ∈ changeSet do
between origin and revised
ChangeSet c = calculateChanges(originModel, revisedModel)
model
element = mergedModel.getElementById(c.getElement().getId())
if c instanceof Insert then
container = mergedModel.getElementById(c.getElement().getContainer().getId())
if container.isDeleted() then
container.annotate(new DeleteUpdate(c)) Add all inserted elements
end including annotations if
mergedModel.apply(c) Delete/Update Conflict
else if c instanceof Delete then
if mergedModel.getElementById(c.getElement().getId()).isUpdated()
then
element.annotate(new DeleteUpdate(c))
end Do NOT apply deletions,
element.markAsDeleted() just annotate element
element.addMetaInfo(createMetaInfo(c))
else if c instanceof Update then
if element.isDeleted() then
element.annotate(new DeleteUpdate(c))
end
feature = c.getUpdatedFeature() Also store the updated
if element.isUpdated(feature) then feature.
element.annotate(new UpdateUpdate(c), feature)
element.addMetaInfo(createMetaInfo(c))
end
mergedModel.apply(c)
end Apply all updates
end Validate merged model 17
...

18. Model-based for Conflict Representation
Conflict Report dependsOn
Change Report
*
*
ConflictReport Conflict
ChangeReport
leftChange 1
*
PostMergeViolation ContradictingChange * 1 Change
rightChange
*
Delete/Update Update/Update
Conflict Conflict
1 violated Additional
Specification
Constraint
18

19. UML Profile for Conflict Visualization
 Representation and visualization of conflicts with UML Profile
 Light-weight extension of UML
 Stereotypes are used to extend standard UML metaclasses
 Apply stereotypes to instances of the extended metaclasses
 Tagged values provide additional information
 Syntactic sugar (e.g., icons) for defined stereotypes may be configured to
improve visualization
 Profile is used as follows
 Stereotypes mark added, deleted, updated model elements
 Stereotypes mark update/delete and update/update conflicts as well as
violations
 Tagged values contain additional information like conflict metadata
 Involved user
 Revision number etc.
19

20. Turning Conflicts into Collaboration
Tool Support in Eclipse
20

21. Benefits of Realization
 UML-conform models
 Profiled models are still compliant to UML
 Are handled by most UML tools
 No editor modifications
 Modification of graphical editors of UML tools are not necessary
 User-friendly visualization
 Merge conflicts in concrete syntax
 Integrated view
 One single diagram to provide a complete overview of conflicts
 Model-based representation
 Conflict information is not lost when importing/exporting the model
 Resolve conflicts at a later time
 Different diagram filters based on stereotypes
21

22. Conclusions
 Conflicts are not considered as negative results of collaboration
 All opinions and intentions are covered
 Important in early phases of the software lifecycle
 When a general agreement has not been established
 At this time, design flaws are cheap to correct
 Novel kind of thinking for the modelers
 Models containing different points of view explicitly
 Conflicts may serve as a basis
 for finding differences in stakeholder goals
 for detecting critical parts of models
 for improving the software development process
22

23. Ongoing Work
 UI is of huge importance
 Models might grow big with many conflicting modifications
 Filters and strategies to guide the modelers
 Language-independent annotations
 Model extensions for each Ecore-based model
 Empirical Study with our students
23

24. Thank you for your attention!
Questions?
• http://www.modelversioning.org
The End

25. Backup
25

26. Conflict Profile in EA
26