1. Collaborative Editing of EMF/Ecore Meta-models
and Models: Conflict
Detection, Reconciliation, and Merging in DiCoMEF
Amanuel Koshima , Vincent Englebert
MODELSWARD 2014 : 2nd International Conference on
Model-Driven Engineering and Software Development
07 January 2014, Lisbon, Portugal
07 January, 2014, Lisbon , Portugal

2. Outline

Introduction

Collaborative Modeling

State of the art

DiCoMEF

Conflict Detection and Reconciliation

Conclusion and Future Work
www.unamur.be

3. Introduction
Application of software solutions
Kelly,
www.unamur.be Steven. Domain-specific modeling enabling full code generation. Hoboken, N.J: Wiley-Interscience IEEE Computer Society, 2008.

4. Introduction
Model Driven Engineering
mitigates complexities of software
development by
 raising the level of
abstraction from code to
model
DSML: describes solutions using
Metametamodel
http://www.ibm.com/de
veloperworks/library/
« UML Class » Metamodel
« DSL GUI »
Metamodel
domain concepts


better support of variability
reduce the cost of conception
& development: up to 10
[Kelly et. al]
Transformation
www.unamur.be

5. Introduction
Ecore Meta-model
www.unamur.be

6. Introduction
Notation
(Cartesian Product, keys are underlined)
(partial order)
, the inverse relation is
R*: the transitive closure of R
www.unamur.be

7. Introduction
Ecore meta-model element mapping:
Classes:
Associations:
EClass  EC
EDataType  ED
EReference  ER
EAttribute  EA
EObject  EOB
…
Inheritance relationship is modeled :
– using set inclusion constraints or
e.g.
– equality if the super-type is an abstract class
e.g.
www.unamur.be

8. Introduction
• A model M compliant with a meta-model MM
• A class is modeled as a set of instance Eobjects
• An attribute associates an EObject with a data value (s)
• A reference associates two EObjects
• A mapping function that maps an EObject to its Eclass
• The owner of a structural feature: owner(sf)
• Containment relationship:
www.unamur.be

9. Introduction
www.unamur.be

10. Introduction
www.unamur.be

11. Introduction
Simplified Ecore
meta-model
instance (reflexive
definition)
www.unamur.be

12. Collaborative Modeling
modeling alone
www.unamur.be

13. Collaborative Modeling
Collaborative Modeling
– a software system is required to facilitate collaboration (i.e.
communication , reconciliation) among software engineers
((meta)modelers)
Requirements for Collaboration Modeling
1. Engineers need to share meta-models and models
2. Concurrently edited (meta)models need to be integrated
3. Communication among members need to be managed
4. Inconsistency (merge conflicts) needs to be identified
and resolved
www.unamur.be

14. Collaborative Modeling
Source code management systems
makes possible to share efficiently code
source files in such teams (cvs, svn, git,
…), but not suitable for models which
have a graph nature
•creates a new Class named Node
•Moves transition from a State to
Node
•deletes a State Class
•rename transition to edge
•rename Transition to Edge
www.unamur.be
rename State,
transition, and
Transition

15. State of the art
Centralized approach
 there is one central repository
 mode of collaboration: pessimistic VS optimistic [3,4]
 pessimistic approach: uses locks
 optimistic approach: copy-modify-merge
Limitations :
 locking technique is not scalable
 it restricts user to be dependent on one repository
 it introduces administrative access rights (cumbersome and
creates dissatisfaction)
 modification management role is not flexible
Advantage:
 handles conflicts better as compared to distributed approach
Example: EMFStore, MetaEdit+
www.unamur.be

16. State of the art
Distributed approach:
 each member has his/her local copy
 managing change propagation
• with change management
• without change management
Advantage :
 gives members a better control over data
 solves a problem of being dependent on one repository
 modification management role is flexible
Limitations
 keeping all local copies consistent is challenging
• Example: Git, D-Praxis
www.unamur.be

17. State of the art
Most of state-of-the-art tools used a line based approach to compare
models and detect conflicts, but models have graph-based nature
(Mens , 2002) (Altmanninger et al., 2009).CVS, SVN, Git
EMFStore is a collaborative model editing framework based on copymodify-edit premise (Koegel et al., 2010)
A theoretical reconciliation framework for DSML proposed by
(Englebert et al., 2009), without giving a solution
D-Praxis - a peer-to-peer based collaborative model editing framework
(Mougenot et al., 2009) (uses delete semantics and Lamport time
as a means for reconciliation)
www.unamur.be

18. DiCoMEF
DiCoMEF concepts
Hypothesis:
 A controller is a senior staff
 A controller has given a
mandate to accept or reject
modification requests
 every (meta)model element
has a unique id, UUID



www.unamur.be
controller: write/read master (meta)model
editor: writes/reads copy (meta)model
observer: reads copy (meta)model

19. DiCoMEF
DiCoMEF Architecture
www.unamur.be

20. DiCoMEF
www.unamur.be

21. DiCoMEF
• An operation based distributed model editing framework
• An editor communicates his/her modification as a change
request
• A controller supervises modifications of (meta)models
 Meta-model Controller  meta-model adaptation
 Model Controller  model adaptation
• Propagated changes are always applied first in case of
conflicts
• Editor can send his/her conflicting local changes as
change request later
www.unamur.be

22. DiCoMEF
DiCoMEF concepts
• main-line: stores copy (meta)model
• branch: stores the working copy of (meta)model
www.unamur.be

23. DiCoMEF
History Meta-model
www.unamur.be

24. DiCoMEF
Create Operation: creates objects in the context of a
container.
www.unamur.be

25. DiCoMEF
Delete Operation: deletes an existing model element along
with its contents (child elements) from its parent element
www.unamur.be

26. Conflict Detection
Conflicting relation (ordered-multivalued)
Conflicting relation (unordered-multivalued)
www.unamur.be

27. Conflict Detection
Requires relation
www.unamur.be

28. Demo
http://www.youtube.com/watch?v=K_O9QG9jooU&feature=youtu.be
www.unamur.be

29. Conclusion
To fully benefit from DSM tools:
 It is important to ensure collaboration among DSM tools.
Strength of DiCoMEF:
–
–
–
–
–
It manages collaboration of models and meta-models
It lets each member to work in isolation
Modifications are managed by human supervisor
Modification management role is flexible
It can be used extend to handle a community of modelers
Drawbacks:
– Using a central controller could be a bottleneck
www.unamur.be

30. Future work
 The proposed framework will be validated
 More advanced collaborative workflows should also be
investigated and defined on top of DiCoMEF.
www.unamur.be

31. Thank You !
University of Namur
PReCISE Research Center
amanuel.koshima@unamur.be
sites.google.com/site/dicomef
www.unamur.be