A Pattern-matching based Approach for Problem Solving in Model

Transformations

Youness Laghouaouta, Pierre Laforcade and Esteban Loiseau

Le Mans Universit

e, LIUM, EA 4023, France

Keywords:

Model Driven Engineering, Model Transformation, Pattern Matching, Constraint Satisfaction Problem.

Abstract:

As MDE (Model Driven Engineering) principles are increasingly applied in the development of complex

software, the use of constraint solving in the speciﬁcation of model transformations is often required. However,

transformation techniques do not provide fully integrated supports for solving constraints, and external solvers

are not well adapted. To deal with this issue, this paper proposes a pattern-matching based approach as

a promising solution for enforcing constraints on target models. A transformation infrastructure is semi-

automatically generated and it provides support for specifying patterns, searching for match models, and

producing valid target models. Finally, a use case is presented in order to illustrate our contribution.

1 INTRODUCTION

Model Driven Engineering (MDE) proposes models

to represent all artifacts handled by a software de-

velopment process. The principle is to raise the ab-

straction level by using models as ﬁrst class entities

in dedicated model management operations (e.g. mo-

del transformation, model composition, model valida-

tion. . . ).

Among these operations, the transformation of

models is the most important and well-studied ope-

ration. It allows the automatic generation of tar-

get models from source ones. These models con-

form to metamodels that deﬁne the structure and well-

formedness rules. Besides, a transformation speci-

ﬁcation/deﬁnition includes descriptions of how con-

structs of source metamodels can be transformed into

constructs of target metamodels (Mens and Gorp,

2006).

Several related techniques have been proposed

in the literature (Jouault and Kurtev, 2005)(Kolovos

et al., 2008)(OMG, 2008). Despite their differences

(e.g. textual or graphical concrete syntax; declarative,

imperative or hybrid nature; rule-based or relation-

based languages. . . ), their shared goal is to provide

developers with supports to specify the production of

valid target models from source ones (i.e. generally

higher-level models).

A target model is valid when it conforms to the

structuring deﬁned by its metamodel and satisﬁes all

the related constraints. In practice, constraints can-

not be expressed by means of metamodel constructs

and implies the use of additional formalisms (e.g.

OCL (OMG, 2014)). Likewise, model transforma-

tion techniques are not well supported for enforcing

all constraints, and usually developers require using

external constraint solvers or libraries. However, ex-

pressing a Constraint Satisfaction Problem (CSP) is a

complex and error prone activity because developers

are faced with the domain divergence of the managed

elements (i.e. model elements in model transformati-

ons versus numeric values in constraint solvers).

Our contribution is then a practical constraint sol-

ving approach for model transformations. The ob-

jective is to allow enforcing constraint on target mo-

dels while simplifying the expression of the constraint

based problem. To this aim, a CSP is considered as a

pattern matching problem speciﬁed by means of mo-

del elements. Besides, the pattern matching is inclu-

ded in a global process that allows producing the ex-

pected target models of a given transformation scena-

rio.

The remainder of this paper is structured as fol-

lows. In Section 2, we present the context of our pro-

posal and motivate the need for a practical constraint

solving approach for model transformations. Section

3 gives an overview of the main concepts of our ap-

proach as well as relevant implementation details. In

section 4, we demonstrate the soundness of our ap-

proach using an illustrative transformation scenario.

Section 5 lists related work. Finally, Section 6 sum-

marizes this paper and presents future work.

Laghouaouta, Y., Laforcade, P. and Loiseau, E.

A Pattern-matching based Approach for Problem Solving in Model Transformations.

DOI: 10.5220/0006847900790089

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 79-89

ISBN: 978-989-758-320-9

2 MOTIVATION

This work has been motivated by the need for a fra-

mework that eases the design and the validation of a

serious game for helping children with ASD (Autis-

tic Syndrome Disorder) to improve their visual skills.

Given the speciﬁc needs of the players, it is predomi-

nant to take into account the domain experts’ directi-

ons and requirements during the design phase. This

includes the domain elements, and the rules involved

during the generation of adapted learning scenarios.

MDE provides principles for conducting collabo-

rative design and validation sessions between compu-

ters scientists and domain experts. It allows represen-

ting the domain elements as active models (i.e. child-

ren proﬁles, game components and game scenarios).

As a consequence, the scenarization process can be

dynamically generated by means of model transfor-

mations (i.e. the other alternative would be to design

and implement all possible conﬁgurations of scena-

rios). Indeed, the proﬁle model and game component

model can be transformed to produce adapted scena-

rios. The latter are used to validate the generation ru-

les and will subsequently form a basis for real exploi-

tation within the game.

In previous work (Laforcade et al., 2018), we have

proposed a metamodel for structuring all the dimen-

sions related to the game. As for the generation of

scenarios adapted to children proﬁles, it is implemen-

ted as a model transformation written in Java/EMF

(Steinberg et al., 2009). Certainly, the proposed im-

plementation allows optimizing the validation task in

the sense that game scenarios are generated in de-

mand and without additional effort. However, the pro-

blem arises when domain experts propose modiﬁcati-

ons to the generation rules.

Indeed, it is not easy to identify the transformation

fragments impacted by the expressed changes. The

way the transformation is speciﬁed does not reveal

matches between each experts direction/requirement

(i.e. considered here as a constraint) and the transfor-

mation fragments that allow building conformed mo-

dels. In addition, the experts directions/requirements

are not easy to implement even when the transforma-

tion is speciﬁed from scratch. Several constraints are

expressed in order of priority. They are global con-

straints as they are attached to a set of model elements

and not to separated ones. In fact, the proposed model

transformation uses an external constraints solving li-

brary to tackle some very speciﬁc generation steps.

We conducted past experiences with domain ex-

perts using the aforementioned implementation. It al-

lowed us to collect feedbacks and drew two conclu-

sions. MDE principles ease the co-design and valida-

tion tasks (i.e. by structuring the domain elements and

allowing the automatic generation of adaptive scena-

rios). However, the way to implement the production

of learning scenarios is problematic (i.e. especially

when changes are expressed). A ﬁrst way to deal with

this issue consisted in testing other languages/sup-

ports for model transformations. Concretely, we have

exploited the ETL language (Kolovos et al., 2008) and

the meta-language Melange (Degueule et al., 2015)

for expressing generation of scenarios.

Although ETL allows specifying the transforma-

tion in a much more structured way compared to Ja-

va/EMF (e.g. rules, operations, pre and post blocks),

the lack of a CSP (Constraint Satisfaction Problem)

support raises a signiﬁcant issue. As for Melange (i.e.

a language workbench that allows expressing ope-

rational semantics by augmenting meta-classes with

behaviors), the generation concern is speciﬁed in a

modular manner which helps to identify the compo-

nents (e.g. meta-classes, operations) related to the ex-

pressed change. Also, it is possible to reuse existing

Java libraries for CSP solving. However, like the Ja-

va/EMF transformation, it is not easy to express the

direction/requirement of the expert by means of CSP.

This is due to the divergence between domains of va-

lues supported by the CSP solver (essentially integer

and real values) and the concerned model elements.

Accordingly, we have set three requirements for

the design and validation framework discussed above.

Even if we are focusing on the development of the

presented serious game, we think that the application

scope of such framework can be extended to softwa-

re/systems with complex and variant constraints. Our

goal is to provide support for:

1. the generation of target models by transforming

source ones;

2. the speciﬁcation of constraints applied to target

models in a simple manner and constraint solving;

3. the modiﬁcation or reconﬁguration of the trans-

formation in case of constraint changes.

The next section details our proposal for a model

transformation approach that facilitates the expres-

sion of problems addressed by constraints satisfaction

(objectives 1 and 2). This proposal ﬁts into our co-

design and validation framework. Indeed, it was de-

signed in order to meet the third objective as well.

However, details concerning the modiﬁcation/recon-

ﬁguration of the transformation when changes occur

are out of the paper scope.

ICSOFT 2018 - 13th International Conference on Software Technologies

3 PATTERN MATCHING FOR

CSP SOLVING IN MODEL

TRANSFORMATIONS

This section explains how a model transformation im-

plying constraint solving could be considered as a

pattern matching problem. First, we present a glo-

bal overview and give the principles of our approach.

Thereafter, we present the conﬁguration metamodel

that deﬁnes the relevant concepts. Finally, we detail

the generation process of the infrastructure supporting

the proposed approach.

3.1 Global Overview

Basically, a CSP is deﬁned as a set of variables, va-

riable domains (i.e. possible values for each varia-

ble) and a set of constraints. A solution is an assig-

nment of values to each variable that satisﬁes every

constraint. As for graph pattern matching, it is ba-

sed on (sub)graph isomorphism and requires ﬁnding

an image (i.e. match) of a given graph (i.e. pattern

graph) in another graph (i.e. source graph) (Larrosa

and Valiente, 2002).

In the literature, several work address the joint use

of CSP and pattern matching (Rudolf, 1998)(Larrosa

and Valiente, 2002)(Taentzer et al., 1999). Essenti-

ally, the graph pattern matching is expressed and re-

solved as a CSP. The aim is to improve matching per-

formance by exploiting the rich and advanced rese-

arch work done in the CSP ﬁeld. In order to obtain the

CSP equivalent of a pattern matching problem, some

matches have been established between concepts of

the two domains (Rudolf, 1998):

• CSP variables correspond to the objects of the pat-

tern graph;

• variable domains correspond to the source graph

objects to be matched into;

• constraints correspond to the restrictions that ap-

ply to a graph morphism.

Our approach is based on a reverse use of these

matches. The core principle is to consider a pattern

matching problem as a high level speciﬁcation of a

CSP. Hence, a CSP problem over a model can be di-

rectly expressed by means of model elements rather

than establishing non evident matches to basic varia-

ble domains supported by CSP solvers (e.g. integers,

reals).

Figure 1 gives a global overview of our approach.

A model transformation that implies constraint sol-

ving is decomposed into two steps: a pattern matching

step and a transformation step. The idea is to express

all constraints to enforce on target models through a

relevant pattern. The found match is then transformed

into valid target models. Therefore, the expression

of the pattern has to consider the following require-

ments:

• although the pattern is expressed by means of

source model elements, it has to ensure the satis-

faction of all constraints related to target models;

• a match model has to be sufﬁcient enough to ens-

ure a complete generation of target models.

Furthermore, the expression of a pattern is decom-

posed into two parts. The structure part refers to the

elements to be matched into source models, while the

constraint part refers to the different constraints that

force the identiﬁcation of a match model. This de-

coupling makes it possible to associate multiple con-

straints (i.e. classed by order of priority) to the same

pattern. Also, variation of a constraint does not af-

fect the transformation because this latter is speciﬁed

using the pattern structure.

Figure 1: Global overview of the transformation process.

Figure 2 illustrates our proposal. The source mo-

del contains a set of squares with a colored back-

ground. Each one contains numbered triangles of dif-

ferent areas. The transformation scenario consists of

piling up 4 colored triangles. Each target triangle re-

sults from the transformation of a source one while

preserving the same area. As for its background co-

lor, it corresponds to the color of the square container

of the source counterpart. Two constraints have to be

satisﬁed by the target model:

• the area of the contained triangle must be less than

the container one in order to produce a coherent

piling up;

• two adjacent triangles must have different colors.

For this transformation scenario, the pattern struc-

ture consists of an ordered set of four triangles. Each

A Pattern-matching based Approach for Problem Solving in Model Transformations

Figure 2: Simple application example.

one can match one of the source triangles. As for

the constraint part, we specify that a match is valid

if the matched triangles are in descending order of

area. Furthermore, successive triangles must belong

to different squares. Once a valid match occurs, the

transformation is applied on each matched triangle for

copying it and assigning the background color of its

container. We have to note that squares are not mat-

ched by the pattern. They are derived from matched

triangles.

3.2 Conﬁguration Metamodel

As discussed before, the pattern speciﬁcation (i.e.

structure and constraints parts) underpins the propo-

sed transformation approach. The relevant informa-

tion is considered as a conﬁguration for generating the

transformation infrastructure. It is stored in a model

which conforms to the metamodel depicted in Figure

A conﬁguration references different models (i.e.

source models, target models and the implied meta-

models). As for the pattern structure, a conﬁguration

is deﬁned by multiple role types. Each one can be

considered as an abstraction of a set of concrete ro-

les (i.e. pattern elements used to match source mo-

del elements) sharing same characteristics or mana-

ged as a set. Indeed, a RoleType is characterized by

the number of concrete roles nbRoles and references

Figure 3: Conﬁguration metamodel.

a speciﬁc source model element type. For example,

the pattern depicted in Figure 2 can be expressed by

one RoleType instance. This latter references the mo-

del element type corresponding to triangles and has

an nbRoles equals to four. Therefore, the declared

role type is an abstraction of four concrete roles and

each of them is used to match a unique triangle of the

source model.

ICSOFT 2018 - 13th International Conference on Software Technologies

Besides, the isSequence attribute is used to ex-

press that a role type must match a sub-set of source

elements (i.e the same element cannot be matched

multiple times). While the asSequence attribute al-

lows grouping multiple elements matched by the cor-

responding roles in order to be managed as one ele-

ment (i.e. essentially for optimizing the validation

and transformation tasks).

As for to the pattern constraint part, a conﬁ-

guration expresses if a match model is validated

against one constraint level (SimpleConstraint) or

multi-levels and prioritized constraints (Prioritized-

Constraint). A constraint is characterized by a name

that gives an idea of the validation logic. One can

note that the complete constraints speciﬁcation (i.e.

by means of conditions for example) is not covered

by the proposed metamodel. Indeed, the conﬁgura-

tion model does not ensure the generation of the en-

tire transformation infrastructure. This latter includes

resources that have to be manually completed by de-

velopers. The next section details these aspects by

presenting the infrastructure generation process.

3.3 Infrastructure Generation Process

The ﬁrst step to produce transformation infrastructure

is the generation of the conﬁguration (see Figure 4).

For that, we provide developers with a GUI allowing

them to specify all paths of the managed models and

metamodels to which they conform. A conﬁguration

model can then be automatically generated. It inclu-

des the input information as well as other automati-

cally derived data (e.g. metamodels URIs, model ele-

ments types).

As previously stated, the conﬁguration model

have to be completed with the pattern structure as well

as with the constraints type (i.e. simple or hierarchi-

cal). To make this task easier for developers, we have

associated a concrete textual syntax to the conﬁgura-

tion metamodel and implemented a dedicated XText

editor (Bettini, 2016).

Once the conﬁguration is completed, developers

can then ask for the automatic generation of the trans-

formation infrastructure. This is concretely done

by associating a speciﬁc EPL pattern (Kolovos and

Paige, 2017) to each constraint level (i.e. in case of

hierarchical constraints). EPL is a language that pro-

vides support for the speciﬁcation and detection of

structural patterns in models that conform to diverse

metamodels (Kolovos and Paige, 2017). Essentially,

an EPL pattern consists of a set of typed roles used

to capture adequate combinations from source mo-

dels and a match condition to evaluate the validity of

a combination. In our case, typed roles are derived

from RoleType instances (i.e. with respect to nbRo-

les, type and refModel values) while the match condi-

tion is viewed as a Boolean operation that references

a considered constraint.

Besides, the sequencing of the patterns execution

is described as an ANT-based Epsilon workﬂow (Ko-

lovos et al., 2017). For each EPL pattern, a dedicated

target and task pair is generated. Besides, depends

properties of each generated target are speciﬁed in or-

der to prohibits the execution of a successor pattern

(i.e. with respect to constraint priorities) if a match

has already been found for the current pattern.

These details are hidden to developers by separa-

ting the patterns (i.e. generated automatically) from

some required resources to be completed. Since all

the patterns have the same structure (i.e. derived from

the conﬁguration model), a developer needs to pro-

vide only one speciﬁcation for transforming match

models. The transformation is speciﬁed by means of

EOL operations (Kolovos et al., 2006). Regarding

constraints, they are expressed in the validation re-

source. Indeed, for each constraint, an EOL operation

is generated according to pattern roles. Each of them

must be implemented by the developer in order to ex-

press the validation logic (i.e. when a model captured

by pattern roles is considered to be a valid match).

Domain restriction resources make it possible to

reﬁne the constraints speciﬁcation. Unlike the vali-

dation which applies on an entire match model, the

restriction concerns only one single role (e.g. do not

capture a triangle if its area exceeds a threshold). Fi-

nally, the remaining resource allows the developer to

assign operations to meta-classes. These operations

can be called by other resources.

The way in which the transformation infrastruc-

ture is structured brings further beneﬁts. When a

constraint changes, the transformation resource is not

impacted. Besides, the operations associated to the

implied meta-classes can be reused when changing

the pattern structure or the transformation scenario as

long as the same metamodels are involved.

4 APPLICATION

This section is dedicated to the application of the pro-

posed approach. First, we brieﬂy present the serious

game that motivates the overall proposal and we des-

cribe the selected use case. Then, we illustrate each

step of the process of generating the transformation

infrastructure.

A Pattern-matching based Approach for Problem Solving in Model Transformations

Figure 4: Process for generating the transformation infrastructure.

4.1 Use Case

The application context is the development of a mo-

bile learning game dedicated to children with ASD

(Autistic Syndrome Disorder). The game intends to

support the learning of visual skills. This game is

based on mechanics from ”escape-room” games: the

player’s goal is to open a locked door to escape the

room; to this end, the user has to solve numerous puz-

zles often requiring observation and deduction. The

mobility feature will allow the learning to take place

wherever the parents, therapeutics, or child wants it.

The global domain elements required for the gene-

ration of game sessions are structured into three rela-

ted parts: game description elements, proﬁle-related

elements, and scenario elements. The required con-

structs have been deﬁned by a dedicated metamodel.

• game description model: it describes all the game

elements (e.g. skills, resources or exercisers, in-

game objects. . . );

• proﬁle model: it describes a user proﬁle;

• scenario model: it describes the targeted learning

objectives, the selected exercises and involved re-

sources; it is generated from the two ﬁrst models.

In addition, this scenario is decomposed into three

different scenarios:

• objective scenario: it references the selected vi-

sual performance skills in accordance to the cur-

rent child proﬁle.

• structural scenario: it refers to the various scenes

where game levels will take place. This scena-

rio extends the previous one. It is generated from

knowledge domain rules stating the relations bet-

ween scenes and the targeted skills they can deal

with.

• features scenario: it expresses the additional

inner-resources/ﬁne-grained elements to be asso-

ciated to each selected scene (e.g. objects appea-

ring in a scene, their positions. . . ). The features

scenario includes components of previous scena-

rios. It speciﬁes the overall information required

by a game engine to drive the set-up of a learning

game session.

For convenience, the proposed use case is limi-

ted to the generation of the higher-level scenario (i.e.

objective scenario). The two input models (i.e. game

description and proﬁle) conform to the metamodel de-

picted in Figure 5. It is worth noting that the presen-

ted metamodel is just an excerpt of the global one that

deﬁnes all the game constructs.

The game description model has been speciﬁed on

the base of experts’ requirements. It expresses four vi-

sual performance skills B3-B4-B8-B25 (respectively

matching object to object, matching object to image,

sorting categories of objects, making a seriation) and

their dependency relations. Figure 6 shows that the

B3 skill unlocks the B4 and B8 skills (i.e. comple-

ting B3 at its highest difﬁculty allows children to pro-

gress independently with the learning of the B4 and

B8 skills).

A ﬁctive child proﬁle model (see Figure 7) expres-

ses that the B3 skill is acquired at its highest level.

The B4 skill is at the elementary level, B8 is at the

ICSOFT 2018 - 13th International Conference on Software Technologies

Figure 5: Objective scenario metamodel.

expert level but is not acquired by the child, and B25

is at the beginner level. Note that we have used the

Emf2gv

project to provide a user friendly represen-

tation of the managed models.

Figure 6: Game description model.

Regarding the generation of the objective scena-

rio, the expert has expressed four constraints to en-

force on the output model:

• Constraint 1: it has to include exactly four targe-

ted skills.

• Constraint 2: targeted skills are proposed among

the proﬁle skills for which the child has acquired

See http://sourceforge.net/projects/emf2gv.

Figure 7: Proﬁle model.

the corresponding prerequisites and did not reach

a maximum level.

• Constraint 3: it would be best to propose diffe-

rent targeted skills.

• Constraint 4: if constraint 3 fails, the objective

scenario must be arranged in view of excluding

successor elements referencing the same skill.

4.2 Infrastructure Generation

In order to perform the described transformation sce-

nario, we start by generating the relevant conﬁgura-

tion. This latter can be completed by deﬁning the

pattern structure and identifying constraints through

a dedicated Xtext editor.

For the presented use case, the pattern comprises

ﬁve roles in order to satisfy constraint 1: one Pro-

ﬁle and four Skill2Consider elements. Indeed, the

matched Skill2Consider elements are viewed as the

source equivalents of the targeted skills to be gene-

rated. As for constraints 3 and 4, they are expressed

as prioritized constraints (see Figure 8) while greatest

priority is given to the ﬁrst declared constraint. Aside

from the pattern structure and constraints parts, all the

other elements are automatically generated.

Once the conﬁguration model is completed, the

transformation infrastructure can be generated (see

Figure 9). Recalling from Section 3.3, an EPL pat-

tern is automatically generated for each constraint le-

vel and the related details are hidden to developers by

separating patterns and the required resources. For the

application example, two EPL patterns are generated

respectively for constraints 3 and 4. Listing 1 illustra-

tes an excerpt of the pattern generated for constraint 3

(i.e. proposing different targeted skills).

Regarding the operations resource, for each mo-

del element type an EOL script is provided to allow

deﬁning speciﬁc operations. As for the domain re-

striction resource, it is possible to specify guard con-

ditions in order to restrict the possible elements to be

A Pattern-matching based Approach for Problem Solving in Model Transformations

Figure 8: Conﬁguration model.

Figure 9: Transformation infrastructure.

caught by a role. Listing 2 illustrates the way the con-

straint 2 is expressed as a domain restriction. The

maxLevel() and hasPrerequiste() operations are de-

ﬁned in the context of the Skill2Consider metaclass

(Skill2ConsiderOperations.eol). The added code is

highlighted.

p a t t e r n P a t t e r n

r 0 : m1! P r o f i l e

g ua r d : r 0 . P r o f i l e D o m a i n R e s t r i c t i o n ( ) ,

r 1 : m1! S k i l l 2 C o n s i d e r

g ua r d :

r 1 . S k i l l 2 C o n s i d e r D o m a i n R e s t r i c t i o n ( ) ,

r 2 : m1! S k i l l 2 C o n s i d e r

g ua r d :

r 2 . S k i l l 2 C o n s i d e r D o m a i n R e s t r i c t i o n ( ) ,

r 3 : m1! S k i l l 2 C o n s i d e r

g ua r d :

r 3 . S k i l l 2 C o n s i d e r D o m a i n R e s t r i c t i o n ( ) ,

r 4 : m1! S k i l l 2 C o n s i d e r

g ua r d :

r 4 . S k i l l 2 C o n s i d e r D o m a i n R e s t r i c t i o n ( )

{

ma tch : v a l i d a t e P a t t e r n a l l D i f f e r e n t ( r0 , r1 , r2 , r3 , r 4 )

on ma tch

{

t r a n s f o r m P a t t e r n ( r0 , r1 , r2 , r3 , r 4 ) ;

}

Listing 1: Excerpt of the EPL pattern generated for con-

straint 3.

o p e r a t i o n m1 ! P r o f i l e P r o f i l e D o m a i n R e s t r i c t i o n ( ) : Bo o le an

{

r e t u r n t r u e ;

}

o p e r a t i o n m1 ! S k i l l 2 C o n s i d e r

S k i l l 2 C o n s i d e r D o m a i n R e s t r i c t i o n ( ) : Boo le a n

{

r e t u r n not s e l f . maxLevel ( ) and s e l f . h a s P r e r e q u i s t e ( ) ;

}

Listing 2: Domain restriction resource.

Listing 3 depicts an excerpt of the validation re-

source. The two operations are automatically gene-

rated with respect to the constraints type and names.

We complete these operations with action blocks that

express the speciﬁc validation logic for models mat-

ched by the pattern. The allDifferent() and following-

ICSOFT 2018 - 13th International Conference on Software Technologies

NotMatch() operations are predeﬁned operations. In-

deed, we deﬁned a list of operations (e.g. sort(),

maxOccurs(). . . ) which are automatically added to

the operations resource.

o p e r a t i o n v a l i d a t e P a t t e r n a l l D i f f e r e n t ( r 0 : m1 ! P r o f i l e , r 1

: m1 ! S k i l l 2 C o n s i d e r ,

r 2 : m1! S k i l l 2 C o n s i d e r , r 3 : m1! S k i l l 2 C o n s i d e r , r 4

: m1 ! S k i l l 2 C o n s i d e r ) : B ool ea n

{

r e t u r n a l l D i f f e r e n t ( Seq ue n ce { r1 , r2 , r3 , r 4 } ) ;

}

o p e r a t i o n v a l i d a t e P a t t e r n f o l l o w i n g N o t M a t c h ( r 0 :

m1! P r o f i l e , r 1 : m1 ! S k i l l 2 C o n s i d e r ,

r 2 : m1! S k i l l 2 C o n s i d e r , r 3 : m1! S k i l l 2 C o n s i d e r , r 4

: m1 ! S k i l l 2 C o n s i d e r ) : B ool ea n

{

r e t u r n fo l l o w ing N o t M atc h ( S equ en ce { r1 , r2 , r3 , r 4 } ) ;

}

Listing 3: Validation resource.

As for the transformation resource (see Listing 4),

we complete it with actions to be applied to the match

model in order to produce a valid objective scenario.

A predeﬁned launch conﬁguration is provided to per-

form this task.

o p e r a t i o n t r a n s f o r m P a t t e r n ( r 0 : m1 ! P r o f i l e , r 1 :

m1! S k i l l 2 C o n s i d e r ,

r 2 : m1! S k i l l 2 C o n s i d e r , r 3 : m1! S k i l l 2 C o n s i d e r , r 4 :

m1! S k i l l 2 C o n s i d e r )

{

v a r s = c r e a t e S ( ) ;

v a r o s= c r e a teO S ( ) ;

s . o b j e c t i v e S c e n a r i o = os ;

f o r ( r i n S eq ue nc e { r1 , r 2 , r3 , r 4 } )

{

os . t a r g e t e d S k i l l s . a dd ( c r e a t e T S ( r ) ) ;

}

o p e r a t i o n c r e a t e S ( ) : m3 ! S c e n a r i o

{

r e t u r n new m3 ! S c e n a r i o ;

}

o p e r a t i o n cr e a t eO S ( ) : m3 ! O b j e c t i v e S c e n a r i o

{

r e t u r n new m3 ! O b j e c t i v e S c e n a r i o ;

}

o p e r a t i o n c r e a t e T S ( s : m1! S k i l l 2 C o n s i d e r ) : m3! T a r g e t e d S k i l l

{

v a r t s = new m3! T a r g e t e d S k i l l ;

t s . d i f f i c u l t y L e v e l =s . c u r r e n t L e v e l ;

t s . b x S k i l l =s . b x S k i l l ;

r e t u r n t s ;

}

Listing 4: Transformation resource.

Figure 10 presents the generated scenario. We can

see that it satisﬁes constraints 1 and 2. However, the

proposed skills do not satisfy constraint 3. In fact,

no combination of the possible skills allows enfor-

cing the constraint because the skill B3 is acquired

at its highest level. For that, the transformation ge-

nerates a scenario with respect to a less prioritized

constraint (constraint 4 in our case). Indeed, the se-

quencing of the two generated EPL patterns (i.e. for

enforcing constraints 3 and 4) is derived from the con-

ﬁguration model and automatically expressed by me-

ans of an ANT-based Epsilon workﬂow (c.f. Section

3.3).

Figure 10: The generated objective scenario.

5 RELATED WORK

Our approach for constraint solving is based on ex-

pressing constraints to enforce on target models by

means of source model elements. This proposal is in-

spired from graph transformations techniques where

constraints on the involved graphs can be expressed

through application conditions (Ehrig et al., 2004).

Besides, the proposed transformation process (i.e. in-

cluding the match and transformation steps) is simi-

lar to the application of graph transformations. For

these latter, the source graph fragments concerned

with the application of a transformation are ﬁrst de-

termined with respect to the LHS (Left Hand Side)

graph. Then, the matched fragments are replaced with

the structure of the RHS (Right Hand Side) graph.

The main difference is the way the pattern is deﬁ-

ned. In fact, the pattern structure is separated from the

constraints which allows expressing different and pri-

oritized constraints for the same pattern. Besides, it is

much easier to express complex constraints within our

approach (e.g. textual syntax, feature navigation, pre-

deﬁned operations. . . ). In contrast, for graph trans-

formations the pattern is deﬁned as one block (i.e. the

LHS graph) and constraints are expressed like sub-

graphs.

Several proposals have addressed the problem of

directly enforcing constraints on target models. Petter

et al. (Petter et al., 2009) have proposed an implemen-

tation to extend the QVT-Relations language (OMG,

2008) with constraint solving capabilities. However,

the proposal focuses on constraints related to attribute

values and disregards global constraints.

Other related work address the automatic genera-

tion of models. In this case, models are not considered

as targets of applying model transformations but are

viewed as valid instances of constrained metamodels

(Kleiner et al., 2010). Cabot et al. (Cabot et al., 2008)

have proposed an approach where metamodels and

A Pattern-matching based Approach for Problem Solving in Model Transformations

OCL constraints are translated into a CSP and a de-

dicated solver allows producing a valid instance. Ba-

sed on similar principles, Ferdjoukh et al. (Ferdjoukh

et al., 2013) have proposed an approach for model ge-

neration while dealing with performance.

In the limited scope of the presented use case,

we have experimented the use of model generation

techniques to perform the transformation scenario.

The idea was to express the source models informa-

tion, the way to construct the target model and the ex-

pert requirements, as OCL constraints. Hence, a mo-

del generation support (we chose Grimm (Ferdjoukh

et al., 2013)) can be used to deal with the generation

of the expected objective scenario. However, the tool

failed because it does not support some essential OCL

operations.

6 CONCLUSION

In this paper, we have presented a practical approach

for constraint solving in model transformations. The

base principle is to consider pattern matching problem

as a high level speciﬁcation of CSP. Furthermore, the

pattern structure is decoupled from the validation con-

straints so as to allow associating multiple constraints

to a same pattern and specifying shared transforma-

tion rules for all validation logics.

This proposal also includes a transformation infra-

structure. This latter is generated in a semi-automatic

manner and it provides support for pattern speciﬁca-

tion, match model search, and transformation into va-

lid target models. A use case has been selected to

illustrate these tasks.

We are currently exploring the deﬁnition of pa-

rameterized patterns essentially for avoiding the pro-

blem of ﬁxed roles numbers. Hence, the same pattern

deﬁnition can be used in various transformation sce-

narios even if involving slightly different match mo-

dels. Besides, we intend to integrate this proposal in a

co-design and validation framework for the presented

serious game.

In this case, we have to deal with two issues. First,

the regeneration of the transformation infrastructure

must consider the extent of the variation expressed

by the expert (e.g. adding a constraint must imply

changing the validation resource without impacting

the transformation and operations resources). Second,

we found that even if several solutions are possible,

the same scenario is always generated for different

executions. This confuses the validation task and pre-

vents the experts from considering several illustrati-

ons. Currently, we can set the transformation infra-

structure in an iterative mode to allow the generation

of all possible targets. Moreover, we are planning to

implement a solution to address random generation.

REFERENCES

Bettini, L. (2016). Implementing domain-speciﬁc languages

with Xtext and Xtend. Packt Publishing Ltd.

Cabot, J., Claris, R., Riera, D., et al. (2008). Veriﬁcation of

uml/ocl class diagrams using constraint programming.

In First International Conference on Software Testing

Veriﬁcation and Validation, ICST 2008., pages 73–80.

IEEE.

Degueule, T., Combemale, B., Blouin, A., Barais, O., and

equel, J.-M. (2015). Melange: A meta-language

for modular and reusable development of dsls. In

Proceedings of the 2015 ACM SIGPLAN Internatio-

nal Conference on Software Language Engineering,

pages 25–36. ACM.

Ehrig, H., Ehrig, K., Habel, A., and Pennemann, K.-H.

(2004). Constraints and application conditions: From

graphs to high-level structures. In International Con-

ference on Graph Transformation, pages 287–303.

Springer.

Ferdjoukh, A., Baert, A.-E., Chateau, A., Coletta, R., and

Nebut, C. (2013). A csp approach for metamodel

instantiation. In 2013 IEEE 25th International Con-

ference on Tools with Artiﬁcial Intelligence, pages

1044–1051. IEEE.

Jouault, F. and Kurtev, I. (2005). Transforming models

with atl. In International Conference on Model Driven

Engineering Languages and Systems, pages 128–138.

Springer.

Kleiner, M., Del Fabro, M. D., and Albert, P. (2010). Model

search: Formalizing and automating constraint sol-

ving in mde platforms. In European Conference on

Modelling Foundations and Applications, pages 173–

188. Springer.

Kolovos, D., Rose, L., Garcia-Dominguez, A., and Paige,

R. (2017). The epsilon book (2017).

Kolovos, D. S. and Paige, R. F. (2017). The epsilon pattern

language. In 9th IEEE/ACM International Workshop

on Modelling in Software Engineering, MiSE@ICSE

2017, pages 54–60. IEEE.

Kolovos, D. S., Paige, R. F., and Polack, F. A. (2006). The

epsilon object language (eol). In European Confe-

rence on Model Driven Architecture-Foundations and

Applications, pages 128–142. Springer.

Kolovos, D. S., Paige, R. F., and Polack, F. A. (2008).

The epsilon transformation language. In International

Conference on Theory and Practice of Model Trans-

formations, pages 46–60. Springer.

Laforcade, P., Loiseau, E., and Kacem, R. (2018). A model-

driven engineering process to support the adaptive ge-

neration of learning game scenarios. In Proceedings of

the 10th International Conference on Computer Sup-

ported Education.

Larrosa, J. and Valiente, G. (2002). Constraint satisfaction

algorithms for graph pattern matching. Mathematical

Structures in Computer Science, 12(4):403–422.

ICSOFT 2018 - 13th International Conference on Software Technologies

Mens, T. and Gorp, P. V. (2006). A taxonomy of model

transformation. Electronic Notes in Theoretical Com-

puter Science, 152:125–142.

OMG (2008). Meta object facility (mof) 2.0 query/view/-

transformation speciﬁcation.

OMG (2014). Object constraint language 2.4 speciﬁcation.

Petter, A., Behring, A., and M

uhlh

auser, M. (2009). Solving

constraints in model transformations. In International

Conference on Theory and Practice of Model Trans-

formations, pages 132–147. Springer.

Rudolf, M. (1998). Utilizing constraint satisfaction techni-

ques for efﬁcient graph pattern matching. In Interna-

tional Workshop on Theory and Application of Graph

Transformations, pages 238–251. Springer.

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

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

Addison-Wesley Professional, 2nd edition.

Taentzer, G., Ermel, C., and Rudolf, M. (1999). The agg ap-

proach: Language and tool environment. Handbook of

graph grammars and computing by graph transforma-

tion, 2:551–603.

A Pattern-matching based Approach for Problem Solving in Model Transformations