Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Â
Collaborative editing of emf ecore meta models and models conflict detection, reconciliation, and merging in di-comef
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
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
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
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
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
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