Despite the fact that DSM tools become very powerful and more frequently used, the support for their cooperation has not reached its full strength and the demand for model management is growing. In cooperative work, the decision agents are semi-autonomous and therefore a solution for reconciliating DSM after a concurrent evolution is needed. Many GPML environments are proposed by the CSCW community but they do not usually provide reconciliation, merging or versioning functionalities after asynchronous evolutions. In this paper we propose a reconciliation framework for cooperative work with a DSM language. The main goal is to support the e ciency of software developers and the reuse of software artifacts.
and al. [
We propose to support a weakly coupled cooperation work for DSM users. This mode of cooperation implies dealing with its speci c features: 1. Users store models in local repositories; 2. Models can be exchanged between users for long periods of time; 3. Users can be distributed in the world and belong to heterogeneous pro les; 4. Users can work concurrently on models in asynchronous way; 5. Users can delegate their models ownership to other users; 6. When a user owns several models that had a common ancestor model in the past (i.e. they are the result of concurrent modi cations applied on a common model the ancestor), an oracle should be able, if possible, to reconcile the models and to merge them into one unique model by preserving the consistency.
Dealing with cooperative issues for DSM tools entails new problems. As
DSMs are de ned to match as close as possible the application domain, DSMs
have to follow its evolution and the new requirements of the stakeholders [
In this paper, we argue that a weakly coupled cooperative work is possible for DSM tool users, even if we take into consideration the natural evolution of the language (its metamodel). We present in the next sections the principles of a framework that makes possible the de nition of a reconciliation oracle for both models and their metamodels, and that meets the hypothesis of the weakly coupled cooperation model.
The paper is structured as follows: Section 2 gives a small summary of the related work on reconciliation after cooperative work, Section 3 illustrates the issues of cooperative work for DSM tools with an example, Section 4 introduces the data description language that de nes the methods data (e.g., models, metamodels), and the reconciliation framework is introduced in Section 5. Section 6 presents the bene ts of our framework and Section 7 concludes the paper. 2
Many GPML environments are proposed by the Computer Supported
Cooperative Work (CSCW) community but they do not usually provide reconciliation,
merging or versioning functionalities for asynchronous evolution. For instance,
[
Regarding DSM, to the best of our knowledge, few approaches have been
proposed so far. MetaEdit+ uses a Client/Server approach with a smart locking
strategy to share data between users. It also o ers import-export facilities for
the asynchronous modelling development. This can update the source
repository, so that imports into target repositories update the source models there
rather than creating new ones. The tool is able to support asynchronous
cooperative work with its model patches for common scenarios that are propagated
to all users. It allows the users to reference, reuse or create their
representation of these core models. Eclipse Modelling Framework Project (EMF) [
The approach in [
Computer Aided Design (CAD) is also a well established eld for CSCW
as a domain of inquiry. Objects can be described from di erent viewpoints,
representing results of either synchronous or asynchronous cooperative work.
Maintaining the relationships amongst these models has been discussed in [
one metaclass one metaproperty
one entity and its name
metaclass mcname:String
instanceof The cooperation scenario can be illustrated by a simple example. A user Alice creates an Entity-Relationship model M along with its metamodel M M (Figure 1). M and M M are then sent to Bob to be re ned. Bob has then to import model M and its metamodel M M while preserving its local knowledge to avoid any clash between Alice’s concepts and his own. Once the data is imported, he extends M M by adding a persistent eld to the entity metaclass, and valuates that eld as SQL for thecustomer entity. He then renames this entity as Customer (with an uppercase), and he nally changes the name of theentity metaclass to EntityType . The result(M1; M M1) is sent back to Alice and Bob deletes this information from his repository. The problem consists in merging M with M1 along with the merging of M M with M M1. If in the same time, Alice modi es M (i.e. M2) or M M (i.e. M M2), the problem becomes more complex: the artifacts evolve independently and the reconciliation of M 1=M 2 and M M 1=M M 2 may require to solve inconsistencies, redundancies, semantic mismatches, etc. For instance, Alice can change the name of the customer entity in M from customer to CUSTOMER . This scenario is illustrated in Figure 2. Of course, this scenario must be generalized since models can be the object of much more complex work ows. For the sake of simplicity, only the simple scenario is discussed in this paper. 4
This research is carried out in the context of the MetaDone project that aims to develop a metaCASE tool whose functionalities are driven by rst-class models. This goal leads us to adopt a fully rei ed and bootstrapped repository with a speci c meta data description language: MetaL. Contrary to EMF or UML, there is no distinction between models and metamodels, items can have several types
M2/MM2
M1/MM1
M/MM
Fig. 2. Cooperative Scenario. This gure shows the exchange of information and the
successive evolutions of the (meta)models. Modi cations are indicated with bold letters.
Cross symbols denote import and reconciliation processes. The upper cross consists
mainly in importing the chunk by preserving the local data. The bottom cross requires
a more complex reconciliation process.
(e.g. both an EClass and a EAttribute), items can belong to distinct abstraction
levels at the same time. The bene ts of this approach are discussed in [
Data is modelled as a set of items D de ned as the non-disjoined union of two
sets O and P . Elements of O denote objects, while those of P denote properties
characterized by a domain and a range that are objects themselves. A subset of O
(OT ) denotes object types and a many-to-many relationship iof exists between
O and OT . In the same way, a subset of P (P T ) represents property types and
a one-to-many relationship pof is de ned between P and P T a property has
exactly one property type. For the sake of simplicity, we will not describe the
specialization relationship, and the constraints of this language. A subset OVS of
O will hold string values. Let’s just make clear that cycles are allowed in the iof
and pof graphs and items can play several roles (object or/and property) at the
same time, and can lose or gain roles. A function name = OT [ P T ! String
maps types to unique identi ers. This language is presented in [
String:type
Figure 3 illustrates the graphical syntax of the MetaL language and how the DSM language from Figure 1 is described with MetaL. We will reuse this example in the rest of this paper. iof and pof relationships are not represented graphically, but are explicit in our approach.
MetaL describes the rst layer of our metaCASE architecture, a second
layer (MetaL2) exists with more abstract concepts (metaobjects,
metaproperties, metaroles, metamodels, identi ers, cardinalities, . . . ) in the same way that
OWL is de ned on top of RDF [
name:name
MR:MO,MR Me ta Me ta Mode l Le ve l
T:T «»,String:String,T
MP:MP,MO We rst formally describe the hypothesis of the world in which users play. We note U the set of all the possible users who can play some roles in a cooperative work. They can join or leave the game (i.e. cooperative work) whenever they want. Let’s call R the databases/repositories users work with. The relation use µ U £ R denotes the use of a database by a user; given that databases are not shared between users. Each database is lled to store a MetaL speci cation (i.e. a set D). We note data : R ! T £ L this process, where T is an in nite set of names and L denotes all the sets Ds (see Section 4) that ful l the axioms of the MetaL language. At this time, the name in T denotes the repository from where data is coming from. The initial situation of our scenario would be described as use = f(A; RA); (B; RB)g where Alice (A) and Bob (B) are resp. using repositories RA and RB. They are populated as: data(RA) = frAg £ DA, data(RB ) = frB g £ DB where DA;B 2 L.
The cooperation scenario is implemented by the exchange of a repository chunk from A to B. This chunk is a subset S of data(RA) that contains information relevant for the user and that meets the axioms of MetaL2: it is cohesive and autonomous. The chunk is built by a xpoint process that improves the chunk at each step in order to meet the axioms. This process is explained hereafter: Let’s rst de ne some preliminary functions: function ° : 2D ! B returns true if the information is consistent wrt. the MetaL axioms. Function ± : 2D ! 2D computes which elements from D are lacking in order to make the argument more consistent, indeed, the addition of new elements can in turn infringe other axioms. The following properties are satis ed: P1 ´ °(D) = true, and P2 ´ 8X µ D : ±(X) µ D. If C: C µ D denotes the elements of interest to user A, then the chunk can be computed as:
while not °(C) do C : = C [ ±(C) This computes the smallest consistent set S containing C. The ±(X) function is built from rules such as: if 9x 2 X \ O; 9ot 2 OT n X : iof (o; ot); and features of ot are used in X, then ±(X) must return ot. From properties P1 and P2, we see that a) such a set exists, b) that the process terminates, and c) that the result is contained in D.
When Bob receives S, the problem consists in adding S to data(RB ). But this last process must make sure to preserve the distinct identity of the data that would be speci c to A and to merge the common data between A and B for instance, elementary types such as object types String, metaclass, etc. We suppose that a function IR : D 7! Z maps every item to a unique negative number if this item is a common knowledge. Otherwise it maps every item to a unique positive number. Of course, there are as many functions IR as there are repositories3. If we keep the information about the original repository with every data, we can now merge S and data(RB ) as:
data(RB) [ ©(r; d) 2 S j IRA (d) ¸ 0ª
An action is an elementary access to the repository (create, read, update, delete) with additional information. Let’s name Action the set of actions that can be performed on one element.
Bob can now modify his copy of the chunk: create/read/update/delete (CRUD)
data at the model and metamodel levels. Once this job is nished, the modi ed
2 i.e. fdj9(r; d) 2 Sg 2 L.
3 These functions can be de ned as an increment, and then, several repositories could
hold the same data while building distinct functions I.
chunk can be sent back to Alice. As in [
Another issue is the consistency of the repository that may occur when a
part is replicated and maybe modifed by concurrent users. The journals can
help to detect such problems and even to solve them sometimes. But this action
unfortunately occur a-posteriori and this may be too late. A weight-watchers
technique [
String:type or a thick line. This scenario doesn’t illustrate items deletion. r A r B r A r B r
B
trsf_ER2SQL
Our proposition allows the exchange of method chunks that consists in both
models and metamodels data. The reconciliation of both models and metamodels
may require to solve inconsistencies, redundancies and semantic mismatches. By
preserving in a unique language the relationships between the instances and
their types, we can provide a reconciliation process that encompasses several
abstraction levels at the same time. To the best of our knowledge, [
We envision other bene ts as the journals could be interactively reiterated
to explain the contribution of the concurrent users or become rst-class objects.
The journal enables the recreation of models/metamodels at di erent stages of
their development. Although our approach has been introduced with the MetaL
language, it will be possible to extend this framework to other works such as
RDF/OWL [
The support for cooperative tasks between DSM tools is still an open issue, especially for asynchronous collaboration. This cooperative approach can be achieved by the exchange of method chunks. Our paper presents a theoretical framework that allows such exchanges at all the abstraction levels (models & metamodels) based on an ad-hoc meta data description language (MetaL).
This work is carried out in the context of the MetaDone DSM tool. It is based on MetaL and is currently being implemented in Java (30 KLOC). Although MetaL proposes interesting advantages over other DSLs like EMF or UML (rei cation, de ning relationships between elements of distinct abstraction levels, management of all the abstraction levels in a homogenous way), these make the reconciliation process more complex. The proposed reconciliation framework is still at its early stage of design. Speci c DSM reconciliation aspects should be considered: maintaining the consistency, re ning the reconciliation oracle and explaining its strategies to the users, and de ning a methodological framework for method chunks reconciliation.