RuCORD: Rule-based Composite Operation Recovering and Detection

to Support Cooperative Edition of (Meta)Models

Amanuel Koshima and Vincent Englebert

PReCISE Research Center, University of Namur, Namur, Belgium

Keywords:

Model Refactoring, Rule-based Refactoring, Composite Operation Detection.

Abstract:

The cooperative edition of (meta)models may be enacted by the exchange of change operation journals be-

tween the participants. But these are often composed of atomic operations (create, delete, set, ... ) that have

no useful meaning for the users. Hence, detecting and recovering composite operations is a crucial step to help

users understand the history of their (meta)models in terms of higher level operations. As a result, conﬂict de-

tection, reconciliation, and merging of modeling artifacts will be improved. In addition, composite operations

can also be used to generate model migration instructions that can automatically migrate instance models.

1 INTRODUCTION

Model Driven Engineering (MDE) approach raises

the level of abstraction of software development from

code-centric to model-centric (B´ezivin, 2005). In

(K¨uhne, 2006), a model is deﬁned as “[...] an ab-

straction of a (real or language-based) system al-

lowing predictions or inferences to be made”. In-

deed, models can be used to perform analysis, valida-

tion, simulation, and source code generation (B´ezivin,

2005).

MDE uses Domain Speciﬁc Modeling Languages

(DSML) to comprehend requirements of software ap-

plications within a speciﬁc domain. G. Booch et

al. wrote “the full value of MDA is only achieved

when the modeling concepts map directly to domain

concepts rather than computer technology concepts”

(Booch et al., 2004). It helps to reduce accidental

complexities of a development of software system by

letting domain experts to focus on speciﬁc concepts

which are related to their ﬁeld of expertise instead of

underlying platforms (software/hardware). This ap-

proach has already proved its usefulness in many ap-

plication areas (Kelly and Tolvanen, 2008).

In MDE, concepts are deﬁned at different abstrac-

tion levels such as models, meta-models and meta-

meta-models. A meta-meta-model is a DSML ori-

ented toward software development methods and al-

lows the deﬁnition of modeling languages, for exam-

ple, MOF (Object Management Group (OMG), 2002)

and EMF/Ecore (Steinberg et al., 2009). Finally,

meta-models are DSML instances that specify a set

of rules to construct valid instance models (Gonzalez-

Perez and Henderson-Sellers, 2008).

Modeling complex systems is far-fetched to

achieve for a single user, it’s very often the matter of

groups of stakeholders with speciﬁc specializations.

They need thus to cooperate together with respect to

their respective viewpoints. But like any other soft-

ware artifact, DSMLs evolve along with their do-

main, but also due to new requirements, error correc-

tions, or iterations in the understanding of the domain

(B´ezivin, 2005; Meyers and Vangheluwe, 2011). It’s

thus important to facilitate the collaborative work of

engineers at all the levels of abstraction, that is, to

support concurrent edition of models but also of their

DSML. This leads to speciﬁc and interesting chal-

lenges.

In our research, we are investigating a particu-

lar kind of collaborative work with the following hy-

potheses: 1) meta-models can be considered as spe-

cialized models, 2) users cooperate by exchanging

(meta-)models as autonomous self-contained chunks

of information, and 3) users wish to cooperate in a

“loose” way (i.e. asynchronous). These use cases

are encountered in many situations such as inter-

enterprise cooperation, normalisation workgroups,

outsourced contracts, etc. Supporting this activity en-

tails several challenges such as model comparison,

conﬂict detection, models reconciliation and merging,

and model migration. They are discussed in (Koshima

et al., 2013).

Model comparisonis an important activityto iden-

tify differences (aka. delta) between evolving mod-

585

Koshima A. and Englebert V..

RuCORD: Rule-based Composite Operation Recovering and Detection to Support Cooperative Edition of (Meta)Models.

DOI: 10.5220/0005339305850591

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (CMDD-2015), pages 585-591

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

eling artifacts. Deltas are used to perform con-

ﬂict detection, reconciliation, and merging activities

(Koshima and Englebert, 2014; Langer et al., 2013).

Operation-based and state-based tactics are the two

widely used approaches to ﬁnd deltas between two

versions of a (meta)model (Mens, 2002; Altman-

ninger et al., 2009).

State-based approaches derive deltas from two

successive versions of (meta)models by comparing

their states (Mens, 2002; Altmanninger et al., 2009)

while change-based approaches focus only on mod-

iﬁcations performed on the (meta)models (Mens,

2002; Altmanninger et al., 2009). These operations

are then used to compute deltas between two succes-

sive versions.

Operations constituted in deltas improve users un-

derstanding about the evolution of modeling artifacts

(Langer et al., 2013). These operations can be clas-

siﬁed as atomic, refactoring, or composite change

operations (Langer et al., 2013). Atomic operations

(i.e., creation, addition, deletion, update) are low level

operations and it is a cognitively challenging task

for users to understand and re-construct high level

changes (which might reﬂect the intention of modiﬁ-

cations) from primitive changes. Hence, atomic oper-

ations do not scale (Langer et al., 2013). A composite

change operation denotes any type of in-place model

transformation that executes all its children operations

within one transaction (Langer et al., 2013).

Refactoring operations are composite operations

that modify internal structures of software artifacts

(i.e., models) without changing their external behav-

ior (Mens and Taentzer, 2007). This kind of operation

helps to improve the understanding of modiﬁcations

and intentions of a user who performed changes. The

recovering of refactoring operations is an important

activity in model management (Langer et al., 2013)

and is even a crucial task to ensure collaborativemod-

eling.

Meta-model adaptation might cause instance

models inconsistent. Instance models might not any-

more satisfy the set of rules and constraints speciﬁed

by the meta-model. Therefore, models need to be co-

evolved with their respective meta-models in order to

preserve the conformance between models and meta-

models (Herrmannsdoerfer, 2009). Indeed, complex

operations, which adapt a meta-model, can be cou-

pled with model adaptation instructions to migrate

instance models (Herrmannsdoerfer, 2009). Detect-

ing such complex operations helps to identify a set of

model migration instructions (Vermolen et al., 2012)

that transform instance models.

This article presents the principles of a framework

to recover composite operations that denote refactor-

ing tasks from histories recorded in a journal. This in-

formation is required to guide users when they have to

reconcile concurrent (meta)model versions produced

by cooperative editing tasks. Indeed the reconcilia-

tion process may oblige users to choose between con-

current and conﬂicting operations (e.g. two modiﬁca-

tions on the same resource). Confronted with atomic

operations, this decision may be impossible to take,

since operations have no pertinent meaning from the

user’s viewpoint.

The paper is organized as follows: Section 2

presents the objective of the work and Section 3

describes the related work to detect and recover

both refactoring and complex operations. Addition-

ally, Section 4 gives a detailed description about the

proposed framework, RuCORD. Finally, Section 5

presents the future research direction and conclusion.

2 OBJECTIVE

Figure 1 depicts a sample Petri net meta-model along

with a journal of atomic operations. When coop-

erative frameworks use a change-based approach to

merge and reconcile concurrent versions, users are

confronted with this information that may prove very

difﬁcult to understand. Indeed, it is not related to

users intents but to a technical API. Users mostly rea-

son about modiﬁcations in terms of high level opera-

tions (i.e., refactoring or composite operations). For

example, one refactoring operation like “reﬁne a class

into subtypes” may concern one hundred atomic oper-

ations that wouldn’t have any meaning for the users.

When they have to solve a conﬂict, they would pre-

fer to accept or refuse the “reﬁnement” operation and

certainly not each atomic operation that constitutes it.

There is thus a cognitive gap between the primitive

operations and the mental setup of the modelers about

changes.

The objective of this work is to recover and de-

tect composite operations (including refactoring op-

erations) from a journal composed of primitive op-

erations. In addition, the detected complex opera-

tions can be used to specify model migration instruc-

tions that co-evolve instance models along with meta-

model adaptation (Vermolen et al., 2012).

3 RELATED WORK

Much research work has already be done to detect

refactoring and complex change operations in the

context of object oriented programming. Demeyer

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

586

Figure 1: A Petri net meta-model and atomic meta-model adaptation operations.

et al. proposed a method to detect refactoring oper-

ations from successive versions based on change met-

rics (Demeyer et al., 2000). Besides, Dig et al. pre-

sented a RefactoringCrawler framework that uses a

combination of syntactic analysis and semantic anal-

ysis to detect refactoring operations (Dig et al., 2006).

Composite operations can also be included as part

of the development environment and they will be

tracked whenever they are executed (Herrmannsdoer-

fer, 2009). However, this approach might produce a

wrong list of composite operations, which contains

some composite operation that are nulliﬁed by latest

operations (Langer et al., 2013; Koshima et al., 2013).

Besides, it cannot detect refactoring operations that

are performed manually (Langer et al., 2013).

Operation-based collaborative modeling may can-

onize change operations to speed up the transfer of

data and to facilitate the merging process. As a result,

operations that are superseded by new ones can thus

be cleaned from the history (i.e. the record of change

operations). Hence, canonization of composite op-

erations could produce a different type of composite

operations that might not be deﬁned by the model-

ing environment. Solving this problem requires to re-

group primitive operations into other composite op-

erations manually, that is a tedious and difﬁcult task.

Moreover, removing atomic changes from a compos-

ite operation might invalidateits constraints(Koshima

et al., 2013). Hence, there should be a tool support to

specify composite operations.

Prete et al. use refactoring template rules to re-

cover refactoring operations between two program

versions (Prete et al., 2010). In another work, Xing

et al. (Xing and Stroulia, 2006) proposed an approach

to detect refactoring operations based on UMLDiff.

This is a domain speciﬁc algorithm (UML-aware) that

compares the structural changes between two succes-

sive versions of class models and drives their differ-

ences (Xing and Stroulia, 2005). Queries are applied

on deltas so as to detect different complex change op-

erations. However, this approach is limited to a spe-

ciﬁc modeling language (Langer et al., 2013). Ver-

molen et al. also demonstrated a modeling language

speciﬁc approach that reconstructs complex meta-

model adaptation operations (Vermolen et al., 2012)

. In (Langer et al., 2013), Philip et al. presented

an approach that automatically detects composite op-

erations between two successive models, which are

deﬁned in any Ecore (Steinberg et al., 2009) based

modeling languages. However, their approach does

not provide a facility to aggregate composite changes

from another composite change(s).

Nevertheless, this raises interesting challenges.

An automatic composite operation detection mech-

anism might ﬁnd results that don’t reﬂect users in-

tentions. It would neither allow users interaction to

identify the correct composite operations that reﬂect

his/her intent. For instance, a user may wish to re-

move some atomic change operations from a compos-

ite operation while keeping the constraints of the com-

posite operation. Indeed, an automatic process nec-

essarily tries to compute the largest set of operations

while recovering a composite operation. Neverthe-

less, some operations could be irrelevant because they

RuCORD:Rule-basedCompositeOperationRecoveringandDetection

toSupportCooperativeEditionof(Meta)Models

587

were executed with a different intent or in distinct

stages. Besides, s/he might also add or remove ratio-

nale of changes attached to speciﬁc changes based on

a new context of composite change operation. Hence,

we argue that interactive composite change detection

approach could improve the ﬁnal result. However,

the approach presented in (Prete et al., 2010; Xing

and Stroulia, 2006; Langer et al., 2013; Vermolen

et al., 2012) don’t support user interactions to itera-

tively identify composite change operations.

4 RuCORD

RuCORD is an interactive rule-based composite op-

eration detection and recovery framework. It is in-

tegrated within Eclipse and works with models ex-

pressed with EMF. Like the approach presented in

(Langer et al., 2013) (see Section 3), RuCORD can

work with any modeling language based on Ecore.

RuCORD uses a rule-based engine to detect and to

recover composite operations. Indeed, the deﬁnitions

of composite operations are encoded as rules and they

are stored in the rule-base, whereas deltas between

two successive versions of a (meta)model are trans-

lated into facts in the fact-base. Afterwards, the Java

Expert System Shell (Jess) rule engine (Hill, 2003) is

used to identify the possible sets of composite oper-

ations. RuCORD also provides an interactive facility

so that users can guide the detection and recovery pro-

cess.

The aim of our work consists in recovering and

detecting composite operations from a set of can-

onized operations, which are recorded during the

(meta)model editing phase. Nevertheless, the work

can also be used to ﬁnd composite operations from

diffs computed using state-based comparison. Fig-

ure 2 describes the proposed framework. When-

ever a user adapts a (meta)model, edit operations are

recorded in a history formally deﬁned by the Di-

CoMEF meta-model (Koshima and Englebert, 2014).

Later, these operations are canonized and translated

into Jess facts by using a model-to-text transforma-

tion engine, Java Emitter Template JET (Foundation,

2014).

The deﬁnition of the composite operation patterns

is written as a list of Jess rules. During the execution,

when a rule’s left hand side is satisﬁed, a new fact,

which represents a composite operation, is asserted

into the fact base. Composite operation facts can also

be aggregated into larger facts. The result of this in-

ference is a hierarchical representation of composite

change operations.

The inference process may be non-deterministic.

Figure 2: A rule-based composite operation detection and

recovery steps.

Indeed, the analysis engine may identify overlapping

composite operations. It then displays the result to a

user who can then select the “best” composite opera-

tion, that is, the one which reﬂects his/her intentions.

Besides, if rationale

of modiﬁcations are attached to

change operations, the engine asks the user to verify

if the rationale is still valid for the new composite

operation. Indeed, a user can remove atomic opera-

tions from the proposed composite operation as long

as constraints of the composite operations are satis-

ﬁed.

The analysis engine examines dependencies be-

tween change operations and ordered composite op-

erations. Of course, it uses the “require” relationship

speciﬁed in (Koshima and Englebert, 2014) to iden-

tify the pre-condition of atomic and composite opera-

tions so as to order them. Hence, a user can sequen-

tially execute an ordered list of composite operations

on a base version of a (meta)model and studies their

effect. Moreover,the analysis engine updates the fact-

base based on the user’s decisions and the Jess engine

re-executes the rules until there is no more overlap-

ping operations (composite operations that belong to

different paths of a tree can’t share the same opera-

tion(s)).

The appendix shows a code snippet of Jess facts

that represents a set of operations. They create two

classes (

State

and

Transition

) and one attribute

(

name

). Besides, it speciﬁes a creation rule and ag-

A rationale is an extra information that provides some

explanation about a decision, this information can be a text

or any multimedia ﬁle for instance. This functionality is

supported by the DiCoMEF framework.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

588

gregation rules. For example, a composite operation,

that creates an attribute, contains atomic operations

such as create attribute, set name, set type, set lower

bound, set upper bound, and other modiﬁer operations

related to the same attribute.

5 CONCLUSION AND FUTURE

WORK

This article has presented a framework to recover

refactoring operations from canonized operations or

deltas. This framework is ﬂexible enough to allow

users to guide the result based on her/his preferences.

Users can remove parts of composite operations de-

tected by the analysis engine as long as the validity

of the composite operations are preserved. The anal-

ysis rule can add/remove rationale of modiﬁcations

to/from composite operations based on the user con-

ﬁrmation. It also analyzes dependencies among com-

posite changes and orders them. Users can add their

own composite operation patterns in deﬁning their

own Jess rules.

In the future work, we will study the analysis en-

gine of RuCORD and integrate it with the DiCoMEF

framework (Koshima and Englebert, 2014). Besides,

we will encode different composite operations speci-

ﬁed in (Herrmannsdoerfer,2009) and evaluate the Ru-

CORD framework.

REFERENCES

Altmanninger, K., Seidl, M., and Wimmer, M. (2009). A

Survey on Model Versioning Approaches. Technical

report, Johannes Kepler University Linz.

B´ezivin, J. (2005). On the uniﬁcation power of models.

Software and System Modeling, 4(2):171–188.

Booch, G., Brown, A. W., Iyengar, S., Rumbaugh, J., and

Selic, B. (2004). An MDA Manifesto.

Demeyer, S., Ducasse, S., and Nierstrasz, O. (2000). Find-

ing refactorings via change metrics. SIGPLAN Not.,

35(10):166–177.

Dig, D., Comertoglu, C., Marinov, D., and Johnson,

R. (2006). Automated detection of refactorings in

evolving components. In Proceedings of the 20th

European Conference on Object-Oriented Program-

ming, ECOOP’06, pages 404–428, Berlin, Heidel-

berg. Springer-Verlag.

Foundation, T. E. (2014). JET (java emitter templates).

http://www.eclipse.org/modeling/m2t/?project=jet.

Gonzalez-Perez, C. and Henderson-Sellers, B. (2008).

Metamodelling for Software Engineering. John Wi-

ley, New York.

Herrmannsdoerfer, M. (2009). Operation-based versioning

of metamodels with COPE. In Proceedings of the

2009 ICSE Workshop on Comparison and Versioning

of Software Models, CVSM ’09, pages 49–54, Wash-

ington, DC, USA. IEEE Computer Society.

Hill, E. F. (2003). Jess in Action: Java Rule-Based Systems.

Manning Publications Co., Greenwich, CT, USA.

Kelly, S. and Tolvanen, J.-P. (2008). Domain-Speciﬁc Mod-

eling. Enabling full code generation. Wiley-IEEE

Computer Society Pr.

Koshima, A. and Englebert, V. (2014). Collaborative edit-

ing of emf/ecore metamodels and models: Conﬂict

detection, reconciliation, and merging in dicomef. In

Proc. of the MODELSWARD 2014, Lisbon, Portugal.

Koshima, A., Englebert, V., and Thiran, P. (2013). A recon-

ciliation framework to support cooperative work with

dsm. In Reinhartz-Berger, I., Sturm, A., Clark, T., Co-

hen, S., and Bettin, J., editors, Domain Engineering,

pages 239–259. Springer Berlin Heidelberg.

K¨uhne, T. (2006). Matters of (meta-)modeling. Software

and System Modeling, 5(4):369–385.

Langer, P., Wimmer, M., Brosch, P., Herrmannsd¨orfer, M.,

Seidl, M., Wieland, K., and Kappel, G. (2013). A pos-

teriori operation detection in evolving software mod-

els. J. Syst. Softw., 86(2):551–566.

Mens, T. (2002). A state-of-the-art survey on software

merging. IEEE Trans. Softw. Eng., 28:449–462.

Mens, T. and Taentzer, G. (2007). Model-driven software

refactoring. In Dig, D., editor, 1st Workshop on Refac-

toring Tools, WRT 2007, in conjunction with 21st Eu-

ropean Conference on Object-Oriented Programming,

July 30 - August 03, 2007, Berlin, Proceedings, pages

25–27.

Meyers, B. and Vangheluwe, H. (2011). A framework for

evolution of modelling languages. Sci. Comput. Pro-

gram., 76(12):1223–1246.

Object Management Group (OMG) (2002).

Meta Object Facility(MOF) Speciﬁcation.

http://www.omg.org/spec/MOF/1.4/PDF.

Prete, K., Rachatasumrit, N., Sudan, N., and Kim, M.

(2010). Template-based reconstruction of complex

refactorings. In Proceedings of the 2010 IEEE Inter-

national Conference on Software Maintenance, ICSM

’10, pages 1–10, Washington, DC, USA. IEEE Com-

puter Society.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF: Eclipse Modeling Framework 2.0.

Addison-Wesley Professional, 2nd edition.

Vermolen, S. D., Wachsmuth, G., and Visser, E. (2012).

Reconstructing complex metamodel evolution. In

Proceedings of the 4th International Conference on

Software Language Engineering, SLE’11, pages 201–

221, Berlin, Heidelberg. Springer-Verlag.

Xing, Z. and Stroulia, E. (2005). UMLDiff: An algorithm

for object-oriented design differencing. In Proceed-

ings of the 20th IEEE/ACM International Conference

on Automated Software Engineering, ASE ’05, pages

54–65, New York, NY, USA. ACM.

Xing, Z. and Stroulia, E. (2006). Refactoring detection

based on UMLDiff change-facts queries. In Proceed-

ings of the 13th Working Conference on Reverse En-

gineering, WCRE ’06, pages 263–274, Washington,

DC, USA. IEEE Computer Society.

RuCORD:Rule-basedCompositeOperationRecoveringandDetection

toSupportCooperativeEditionof(Meta)Models

589

APPENDIX

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ;; A t e m p l a t e t h a t repr e se n t s

; ; ;; t he DiCoMEF h is to r y meta−model

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

( deftemplate valueChange ( s lo t name )

( s l ot changeID )

( s l ot element )

( s l ot f e at u re )

( s l ot value )

( s l ot oldValue ) )

( deftemplate nonDeleteChange ( s l o t name )

( s l ot changeID )

( s l ot ty pe )

( s l ot element )

( s l ot f e at u re )

( s l ot t ar g e t )

( s l ot source ) )

( deftemplate deleteC hange ( s l o t name )

( s l ot changeID )

( mult isl o t element )

( s l ot f e at u re )

( s l ot t ar g e t ) )

( deftemplate cr e at eRe f a c t o r i ng

( s l ot name )

( s l ot c on s tr a i n t )

( mult isl o t changes ))

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; ; A s s e r ti o n of f a ct s

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

( d ef fa c ts pr i m itiveCh a nges

( nonDeleteChange ( changeID ”01 ” )

( type ” EClass ” )

( element ”Pt−1” )

( name ” Cr eate ”)

( fe a tu r e ” e E c la ss i fi e r ” )

( t a rg et ”Pt−PK” ) )

( valueChange ( changeID ”02 ” )

( element ”Pt−1” )

( name ” Set ” )

( fe a tu r e ”name ” )

( value ” Plac e ” ) )

( nonDeleteChange ( changeID ”03 ” )

( type ” EClass ” )

( element ”Pt−2” )

( name ” Cr eate ”)

( fe a tu r e ” e E c la ss i fi e r ” )

( t a rg et ”Pt−PK” ) )

( valueChange ( changeID ”04 ” )

( element ”Pt−2” )

( name ” Set ” )

( fe a tu r e ”name ” )

( value ” T r a ns i ti o n ” ))

( nonDeleteChange ( changeID ”05 ” )

( type ” E A t t r ib u te ” )

( element ”Pt−3” )

( name ” Cr eate ”)

( fe a tu r e ” e S t r uc tu r a l Fe a tu r e s ” )

( t a rg et ”Pt−1” ))

( valueChange ( changeID ”06 ” )

( element ”Pt−3” )

( name ” Set ” )

( fe a tu r e ”name ” )

( value ”name” ) )

( valueChange ( changeID ”07 ” )

( element ”Pt−3” )

( name ” Set ” )

( fe a tu r e ” eType ” )

( value ” EString ” ) )

( valueChange ( changeID ”08 ” )

( element ”Pt−3” )

( name ” Set ” )

( fe a tu r e ” uperaBound” )

( value ”1” ))

( valueChange ( changeID ”10 ” )

( element ”Pt−3” )

( name ” Set ” )

( fe a tu r e ” lowerBound” )

( value ”1” ) ))

. . .

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; Je ss Rules t ha t encodes Composite

; ; ; ; op e r at i on s Change patt e r n

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ;; a c r e at i on re f a ct o r i ng r ul e

( defrule create− modelElement

?c1 <−(nonDeleteChange ( name ” Cr eate ” )( ty p e ? t )

( element ? id ))

?c2 <−(valueChange ( name ” S e t ” ) ( element ? i d ) )

( a sse r t Fa c t s( create$” c re at eR efa c t or i ng ” ? id ? t ?c1 ?c2 ) ) )

; ;; a c r e at i on re f a ct o r i ng r ul e

( defrule create− modelElement

?c <−(nonDeleteChange ( name ” Creat e ” ) ( type ? t )

( element ? id ))

( a sse r t Fa c t s( create$ ” c r e a t e R e f a c t o r i n g ” ? id ? t ?c ) ) )

. . .

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; U t i l it y Jes s Rules and Function s th a t

; ; ; ; aggr egate f a c t s

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; ; Th i s fu n c ti o n merges two l i s t s

; ; ; ; ; −the f i r s t ele m ent i s t h e len g th of t h e f i r s t l i s t

; ; ; ; ; −the second elem ent is th e len g t h o f the second l i s t

; ; ; ; ; − l i s t 1 and l i s t 2 added i n to

?args

( deffunction mergeChanges ($ ? args )

( bind ? len1 ( nth$ 1 ? ar g s ) )

( bind ? len2 ( nth$ 2 ? ar g s ) )

( bind ? end1 (+ 2 ? len 1 ) )

( bind ? end2 (+ ?end1 ? le n2 ) )

( bind $ ? chg1 ( subseq$ ? ar g s 3 ? end1 ))

( bind $ ? chg2 ( subseq$ ? ar g s (+ ? end1 1) ?end2 ) )

( bind $ ? temp ( create$ ? chg1 ) )

( foreach ?c ? chg2

( i f ( not (member$ ? c ? temp ) ) then

( bind ? temp ( i n ser t $ ? temp (+ ( length$ ? temp )1) ? c ) ) ) )

( return ?temp ) )

; ; ; ; t h is r u l e a g grega t e s f a c t s and

; ; ; ; i t also r et r ac ts c h i l d r en f ac t s

( defrule merege− creates

? c1 <− ( c rea t eR e f act o r i ng ( name ?x )

( c o ns t r a i nt ? id ) ( changes $? cgs1 ))

? c2 <− ( c rea t eR e f act o r i ng ( name ?x )

( c o ns t r a i nt ? id ) ( changes $? cgs2 ))

( t e s t ( not ( eq ? cgs1 ?cgs2 ) ) )

( bind $ ? i n t e rse c t i on ( i n t er s e ct io n $ ? cgs1 ? cgs2 ) )

( bind ? len ( length$ ? int e rs ec t i o n ) )

( i f ( and (> ? len 0) (= ( length$ ? cgs1 ) ? len ) ) then

( r et r act ?c1 )

el s e ( i f ( and(> ? len 0) ( = ( length$ ? cgs2 )? len ) ) then

( r et r act ?c2 )

el s e

( bind ?p1 ( length$ ? cgs1 ) )

( bind ?p2 ( length$ ? cgs2 ) )

( bind ? merged ( mergeChanges ( create$ ?p1 ? p2 ? cgs1

? cgs2 ) ) )

( as s er t F a c t s 2 ( create$ ” cr e a t e R e f a ct or i ng ” ? id

?x ? merged ) )

( r et r act ?c1 )

( r et r act ?c2 ) ) ) )

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; Jes s Facts ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;

Fact−1 ( nonDeleteChange (name ” Crea t e ” )

( changeID ”01” )

( type ” EClass ” )

( element ”Pt−1” )

( fe a tu r e ” e E c l as si f i e r ” )

( t a rg e t ”Pt−PK” ) ( source n il ) )

Fact−2 ( valueChange ( name ” Set ” )

( changeID ”02” )

( element ”Pt−1” )

( fe a tu r e ”name” )

( value ” Net ”)

( oldValue n i l ) )

Fact−3 ( nonDeleteChange (name ” Crea t e ” )

( changeID ”03” )

( type ” EClass ” )

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

590

( element ”Pt−2” )

( fe a tu r e ” e E c la ss i fi e r ” )

( t a rg et ”Pt−PK” )

( source ni l ) )

Fact−4 ( valueChange ( name ” Se t ”)

( changeID ”04 ” )

( element ”Pt−2” )

( fe a tu r e ”name” )

( value ” T r a ns i t io n ” )

( oldValue n i l ) )

Fact−5 ( nonDeleteChange ( name ” Create ”)

( changeID ”05 ” )

( type ” EClass ” )

( element ”Pt−3” )

( fe a tu r e ” e E c la ss i fi e r ” )

( t a rg et ”Pt−PK” )

( source ni l ) )

Fact−6 ( nonDeleteChange ( name ” Create ”)

( changeID ”06 ” )

( type ” E S t r u c t ur a lF ea tur e ” )

( element ”Pt−4” )

( fe a tu r e ” e S t r uc tu r a l Fe a tu r e s ” )

( t a rg et ”Pt−1” )

( source ni l ) )

Fact−7 ( valueChange ( name ” Se t ”)

( changeID ”07 ” )

( element ”Pt−4” )

( fe a tu r e ”name” )

( value ”name” )

( oldValue n i l ) )

Fact−8 ( valueChange ( name ” Se t ”)

( changeID ”08 ” )

( element ”Pt−4” )

( fe a tu r e ” eType ” )

( value ” ES t r i ng ” )

( oldValue n i l ) )

Fact−9 ( valueChange ( name ” Se t ”)

( changeID ”09 ” )

( element ”Pt−4” )

( fe a tu r e ” uperaBound” )

( value ”1” )

( oldValue n i l ) )

Fact−10 ( valueChange ( name ” Set ” )

( changeID ”10 ” )

( element ”Pt−4” )

( fe a tu r e ” lowerBound” )

( value ”1” )

( oldValue n i l ) )

Fact−11 ( c rea t e R e fa c t o ri n g (name” C r e a t e E St r u c tu ral F e a t u r e ” )

( c o ns t r ai nt ”Pt−4” )

( changes <Fact−6 >))

Fact−12 ( c rea t e R e fa c t o ri n g (name ” CreateE Class ” )

( c o ns t r ai nt ”Pt−3” )

( changes <Fact−5 >))

Fact−13 ( c rea t e R e fa c t o ri n g (name ” CreateE Class ” )

( c o ns t r ai nt ”Pt−2” )

( changes <Fact−3> <Fact−4 >))

Fact−14 ( c rea t e R e fa c t o ri n g (name ” CreateE Class ” )

( c o ns t r ai nt ”Pt−1” )

( changes <Fact−1> <Fact−2 >))

RuCORD:Rule-basedCompositeOperationRecoveringandDetection

toSupportCooperativeEditionof(Meta)Models

591