Concurrent Modeling in the Early Phases of the
Software Development Life Cycle
Petra Brosch, Philip Langer, Martina Seidl,...
Reality vs. Truth


                    Modeler A
      Modeler E




                                Modeler B




     M...
The Elephant and the Blind WoMen




   Copyright: John Godfrey Saxe „The Elephant and the Blind Men“   3
   Picture: G.R....
Common Knowledge Base


                            Modeler A
    Modeler E




                                        Mo...
Tool Support
Optimistic Model Versioning Systems




                                                                     ...
Issues of Serial Versioning




              C                    C                    C                       C




    ...
Tool Support Needed…


                                            Modeler A


     Modeler E


                          ...
Issues of Standard Merge Scenario
                                                             Passport as
               ...
Issues of Standard Merge Scenario
                                               V1a                                      ...
Issues of Standard Merge Scenario

 Only one modeler is responsible for conflict resolution
      Nearly impossible to d...
Conflict-tolerant Merge

   To avoid conflict resolution during check-in
   To distribute the responsibility when mergin...
Conflict-tolerant Merge
                                                   V1a              Delete/Update
                ...
<<Delete/Update Conflict>>

                                                                                         --Use...
Consolidation

  Alice
                         Violation                                            Delete/Update
       ...
Realization

 Conflict-tolerant merge algorithm
      Extension of standard versioning systems

 Provision of conflict ...
Conflict-tolerant Merge Algorithm 1/2


                      Modeler A
                                     apply Changes...
Conflict-tolerant Merge Algorithm 2/2
                                                       Create a copy of the
Input: o...
Model-based for Conflict Representation

      Conflict Report                                   dependsOn
               ...
UML Profile for Conflict Visualization

 Representation and visualization of conflicts with UML Profile
       Light-wei...
Turning Conflicts into Collaboration
Tool Support in Eclipse




                                       20
Benefits of Realization

 UML-conform models
     Profiled models are still compliant to UML
     Are handled by most U...
Conclusions

 Conflicts are not considered as negative results of collaboration
 All opinions and intentions are covered...
Ongoing Work

 UI is of huge importance
     Models might grow big with many conflicting modifications
     Filters and...
Thank you for your attention!
Questions?


• http://www.modelversioning.org




                                   The End
Backup




         25
Conflict Profile in EA




                         26
Upcoming SlideShare
Loading in …5
×

Concurrent Modeling in the Early Phases of the Software Development Life Cycle

744 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
744
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Concurrent Modeling in the Early Phases of the Software Development Life Cycle

  1. 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. 2. Reality vs. Truth Modeler A Modeler E Modeler B Modeler D Modeler C 2
  3. 3. The Elephant and the Blind WoMen Copyright: John Godfrey Saxe „The Elephant and the Blind Men“ 3 Picture: G.R. Guzlas
  4. 4. Common Knowledge Base Modeler A Modeler E Modeler B ? Modeler D Modeler C 4
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Turning Conflicts into Collaboration Tool Support in Eclipse 20
  21. 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. 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. 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. 24. Thank you for your attention! Questions? • http://www.modelversioning.org The End
  25. 25. Backup 25
  26. 26. Conflict Profile in EA 26

×