Automatic Generation of Models from Their Metamodels Using

Multilayer Perceptron Network

Karima Berramla

1,2 a

, El Abbassia Deba

1 b

and Abou El Hassene Benyamina

1 c

LAPECI Laboratory, University of Oran1 Ahmed Ben Bella, Algeria

University of Science and Technology Mohamed Boudiaf, Algeria

Keywords:

Space Modeling, Models, Metamodels, Automatic Generation of Models, Model Driven-Engineering, OCL

Language, Machine Learning Technique, Multilayer Perceptron Network.

Abstract:

Model driven-Engineering (MDE) is one of the most recent disciplines of software development that enables

us to use models and their transformations during the software life-cycle, from requirements to implementation

and maintenance instead of using the classic programming languages. In this context, the generation of models

is generally done manually to ensure conformity to their metamodels. There are several work (Batot, 2015;

Fleurey et al., 2009; Ben Fadhel et al., 2012) proposed to automate this process, but no one of them can

ensure complete automation without starting from a set of models already deﬁned by the user or with a good

veriﬁcation of all conformity constraints. In this paper, our objective is not only (i) how to generate the models

in an automatic way and verify all conformity constraints but also (ii) how to use one of the most machine

learning techniques to solve modeling problems in MDE context.

1 INTRODUCTION

During the 1990s, the software engineering has faced

an exponential increase in the complexity of systems

to be modeled due to the difﬁculty of implement-

ing development strategies for the lack of appropri-

ate tools as well as the emergence of software product

line problem. In return, often, the produced software

did not meet expectations. Thus, it can be said that

the speciﬁcations do not always properly reﬂect the

requirements.

As in other sciences, generally, we focus much

more on modeling in order to master this complexity

and even to produce the software than to validate it.

Likewise, Model-Driven Engineering (MDE) is one

of the best-proposed solutions to solve the complex-

ity of systems to be modeled and to minimize simulta-

neously development time and costs of new software

especially those that are classiﬁed in the same family.

MDE (Schmidt, 2006) is therefore an approach to

software engineering with which the model is deﬁned

as a ﬁrst presentation of the system to be modeled,

and which aims to construct, maintain and evolve the

https://orcid.org/0000-0002-2847-4895

https://orcid.org/0000-0003-2948-2093

https://orcid.org/0000-0003-4778-0123

software based on transformations of this model. In

a broad sense, MDE paradigm proposes to merge all

aspects of life-cycle process using the concepts of

model and transformation. In this context, the use

of models needs to describe its metamodel by ma-

nipulating one of the metamodeling languages such

as Ecore (Budinsky et al., 2003) and KM3 (Jouault

et al., 2006). Then, a metamodel is an abstract de-

scription of the system to be modeled where its in-

stantiations present models with which the transfor-

mation can be executed to have at the last step an

executable code. To facilitate model-driven develop-

ment (MDD), the Object Management Group (OMG)

has proposed an approach called Model Driven Ar-

chitecture (MDA) (Soley et al., 2000) in November

2000. This approach gives new software develop-

ment strategies with which the speciﬁcations consid-

ered more important than the implementation by con-

centrating on modeling steps.

Moreover, MDA is classiﬁed as the best solution

that has different exploited advantages such as the au-

tomatic bridge construction from one environment to

another, the possibility to regenerate the source code

from a platform-independent model with changing

the infrastructure over time thus it facilitates develop-

ing and maintaining the most important step of an ap-

plication’s life-cycle and the abundance of necessary

272

Berramla, K., Deba, E. and Benyamina, A.

Automatic Generation of Models from Their Metamodels Using Multilayer Perceptron Network.

DOI: 10.5220/0012439300003645

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 12th International Conference on Model-Based Software and Systems Engineer ing (MODELSWARD 2024), pages 272-279

ISBN: 978-989-758-682-8; ISSN: 2184-4348

MDA tools leads to make the software development

process easy.

Although the transformation during the develop-

ment was semi-automated using a set of tools and

languages, the modeling space creation was not com-

pletely automated until now. Therefore, this pa-

per gives a new solution that complements previ-

ous works ((G

omez et al., 2012), (Ben Fadhel et al.,

2012), (Ehrig et al., 2009) and (Batot, 2015)) by (i)

building the models from their metamodels automat-

ically and (ii) exploiting the use of machine learning

technique (iii) without focusing on a set of an initial

models. Our objctive is not only the automation of

space modeling creation but also to simplify and fa-

cilitate the software development process by ensur-

ing the transformation test (Berramla et al., 2017),

(Berramla et al., 2016) and the programming phases

by examples such as (Berramla et al., 2020).

The rest of this paper is structured as follows:

Background, Motivation, and Problem statement are

presented in section 2. Detailed description and eval-

uation of the proposed approach are deﬁned in section

3 and 4. In section 5 we presents related work and ﬁ-

nally section 6 concludes this paper.

2 BACKGROUND, MOTIVATION

& PROBLEM STATEMENT

This section gives a general description of MDA tech-

nology and the modeling requirements.

2.1 Deﬁnitions & MDA Basic Concepts

The principle key of MDA consists to rely on the

UML standard in order to describe separately the

models about the different development phases of an

application in life-cycle. In the following we provide

some deﬁnitions and information about MDA tech-

nology which will be used in the rest of this paper.

More speciﬁcally, MDA has three types of models

(Blanc and Salvatori, 2011) that are used in software

development. In The following, we deﬁne each one

and the relationship between them (see Figure 1):

Computation Independent Model (CIM). A CIM de-

scribes exactly what the system is supposed to do and

masks all technical details related to system imple-

mentation.

Platform Independent Model (PIM). A PIM speciﬁes

system views independently from the platform where

it can be linked to several platforms at the PSM level.

Platform Speciﬁc Model (PSM). A PSM reﬁnes the

PIM with the technical details needed to describe how

the system can utilize a speciﬁc platform. A PIM can

be translated to one or more PSMs, which are for a

speciﬁc implementation technology.

Figure 1: An overview of MDA approach (Adapted from

(Blanc and Salvatori, 2011)).

Figure 1 gives an overview of MDA approach. In

this context, building a new application starts with

the speciﬁcation of one or more requirements model

(CIM). Then, it continues with the deﬁnition of anal-

ysis and abstract-design models (PIM). These models

must be partially created from the CIMs that trace-

ability relations are established. We have seen that

PIM models are perennial models, which do not con-

tain any information about the execution platforms.

To create an application, it is necessary to deﬁne

speciﬁc models of the execution platforms (PSMs).

These models are obtained by a transformation of

PIM(s) by adding the technical information about the

execution platforms. Their main function is to sim-

plify code generation that is considered as a trans-

lation into a textual formalism (Blanc and Salvatori,

2011).

Figure 2: Modeling space and its limit (Adapted from

omez et al., 2012)).

Automatic Generation of Models from Their Metamodels Using Multilayer Perceptron Network

273

Figure 3: Modeling requirements.

Finding 1. Through the separation between

the dependent models on the platform and

the abstract independent models of applica-

tion, MDA approach offers the following ob-

jectives: portability, reusability and interoper-

ability.

Figure 2 borrowed from (G

omez et al., 2012) presents

a general description about the space modeling and

its limit. This space have two model types, the ﬁrst

one describes the well-formed models and the second

deﬁnes the ill-formed models (see ﬁgure 2). When

we generate the models from their metamodels we re-

ceive one of these two types, if the model is well in-

stantiated and it veriﬁes the deﬁned constraints so we

obtain the well-formed model otherwise we receive

an ill-formed model. These results depend on the in-

stantiation process, which is done manually or auto-

matically.

In the following, we present modeling require-

ments to provide models automatically.

2.2 Modeling Requirements

In this sub-section, we deﬁne the modeling require-

ments as questions to provide simple way of compre-

hension for readers. Also, we present these require-

ments schematically in the ﬁgure 3.

RQ1: How Can We Generate the Models

from Their Metamodels Automatically or Semi-

Automatically?

In MDE ﬁeld, the generation of models from their

metamodels and their conformity veriﬁcation are

done manually. This process requires the efforts and

the times even is done by the system developers so

as not to make the mistakes. Thus, the automation

of this process is considered as the challenge of sev-

eral researches such as (G

omez et al., 2012). The

goal of this paper is to solve this problem in different

way compared with the previous work (Batot, 2015;

Fleurey et al., 2009; Ben Fadhel et al., 2012).

RQ2. Can We Verify the Conformity of Models

Automatically or Semi-Automatically?

In general, the conformity veriﬁcation of models

to their metamodels is done semi-automatically by

deﬁning the constraints in OCL language. At this

time, no proposed approach automates the model cre-

ation and the conformity veriﬁcation in parallel to fa-

cilitate the development in MDE context.

RQ3. Can We Find a Technique to Simplify the

System Modeling Process?

The recent software development such as MDA re-

volves around the use of models to separate the preoc

cupations between application logic and implemen-

tation techniques in order to increase the productiv-

ity. Therefore, the system developers must have a

solid experience on modeling by manipulating mod-

els. Then, no proposed technique is considered as the

best solution to simplify the developement software

without mastering one or more tools or languages.

Finding 2: At this moment, we distinguish

that we have modeling & metamodeling pro-

cesses. In our case RQ1, RQ2 and RQ3 are

asked to describe principal requirements in

the modeling step. This latter is considered

as the heart of the development process.

This question set describes the crucial challenges in

the modeling process with which the software devel-

opment productivity is incresed. In the following sec-

tion, we discuss on our proposed approach to answer

the previous questions in order to solve the principal

problems of modeling step in MDE context.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

274

Figure 4: Proposed approach.

3 MODEL’S AUTOMATIC

GENERATION

Nowadays, the use of machine learning classiﬁed at

the heart of many areas such as image, speech and

natural language processing since it replaces the clas-

sic programming. Therefore, we are interested to

exploit its advantages in the modeling step. Figure

4 describes our proposed approach to create mod-

els from their metamodels foncused on the machine

learning technique that called ”Multilayer Perceptron

Network”(MLP). This approach is divided into three

main steps, the ﬁrst one describes data preprocessing,

the second one occupies the deﬁnition of our MLP ar-

chitecture and the third step provides the detailed de-

scription of model generation from MLP output. The

following sub-sections detailed these steps.

3.1 Preprocessing Step

Here, we present our extraction process of all meta-

model information that will be used in the next steps.

Generally, each metamodel is deﬁned by a set of

classes and their relationships. In this case, we can

say that a metamodel is a set of segments and each

segment contains one relationship with its target class

or a root class.

Figure 5: Extracted information & segment structure.

Figure 5 shows the basic information about each seg-

ment and digital extracted information. In this case,

We consider a segment as one or two metamodel el-

ements and each element can be either root class or

relationship and its target class (see ﬁgure 5 exactly

right side).

Table 1: Description of properties.

Property Number Property intituled

P”1” Root-class property.

P”2” Heritage property.

P”3” Composition property.

P”4” Association property.

P”5” Class-association property.

P”6” 1..1 Cardinality.

P”7” 0..n Cardinality.

P”8” 1..n Cardinality.

Once all segments are extracted, we test a set of prop-

erties for each segment in order to compute digital

information about the used metamodel. These prop-

erties are descriped in the table 1.

For instance, the root class in ﬁgure 5 is deﬁned

as the segment number (1) and its digital informa-

tion is shown in the ﬁrst column of the table deﬁned

in the same ﬁgure. These binary information reﬂect

the properties of each segment. In our case, ﬁgure 5

shows the Relational Schema (RS) that contains a set

of tables each table has one or more column and each

column can be deﬁned as primary or foreign key. The

segment number ”1” is deﬁned by the root class RS.

The segment number ”2” is presented by the class Ta-

ble and the relationship Contain. The same principle

is applied to other elements in order to extract the rest

of segments. Once this process is done, the compari-

son of extracted segments with a set of propertises can

be calculated by insering one if the segment verify the

property and zero otherwise.

Following table 2 gives these extracted informa-

tion from RS metamodel as an example of data infor-

Automatic Generation of Models from Their Metamodels Using Multilayer Perceptron Network

275

Table 2: Extracted information from RS metamodel.

P”1” P”2” P”3” P”4” P”5” P”6” P”7” P”8”

Seg1 1 0 0 0 0 0 0 0

Seg2 0 0 1 0 0 0 1 0

Seg3 0 0 1 0 0 0 0 1

Seg4 0 1 0 0 0 0 0 0

Seg5 0 1 0 0 0 0 0 0

mation that will be used as input elements of training

& testing steps.

3.2 Training & Testing Steps

The ﬁrst formal neuron appeared in 1943 proposed by

Mac Culloch and Pitts by introducing it as a calcula-

tion unit. This formal neuron computes a weighted

sum of its inputs x

, . . . , x

and returns 1 if the sum

is greater than a certain threshold θ and 0 otherwise.

Mathematically, this returns to write the following

equation 1:

z = f (

∑

i=1

· x

) + b), (1)

where f is the transfer (or activation) function, w

the weight where it is often referred to as preactiva-

tion. Generally, the bias term b will be replaced by an

equivalent input term x

= 1 weighted by w

= b. The

result of this previous equation is then passed through

a step function of the form

y =

(

1, if z ≥ θ,

0, otherwise,

(2)

which deﬁnes the binary output of the Perceptron. In

the rest, we use this result to classify whether the input

belongs to a speciﬁc class or not.

In the learning step, we modify the network pa-

rameters for example the weights and the bias to ob-

tain good output result. This change is based on the

following rule:

new

= w

old

− η · ( ˆy − y) · x

, (3)

where ˆy is the Perceptron output, y is the target (i.e.,

desired) value, x

and w

old

are the i-the input and

weight at the previous iteration and η is a factor that

permits in order to change the magnitude by which

the weights are modiﬁed.

Once the network parameters are well-changed

the testing step can be started using other input data

information to evaluate the capacity of the network.

In this step, we calculate diretly the ouput ˆy with-

out recompute the network parameters such as the

weights.

Figure 6: Our MLP architecture.

Figure 6 shows our MLP architecture where the input

data are x

and i was varied from 1 to 8 according to

the used properties. These input data are deﬁned by

binary values of each segment while the ouput data ˆy

gives the binary information about each input segment

if will be instancieted or not.

3.3 Posteprocessing Step

This step occupies the creation of models from MLP

output using the following algorithm.

Algorithm 1: From MLP outputs To models.

Require: MLP Output;

Ensure: Creation of Models;

Compute number of MLP outputs

N = size(Classes);

Create set C1 = out puts o f Class1;

Create set C2 = out puts o f Class2;

for i = 1 to N do

while Ci <>

0 do

C = dequeue(Ci);

Let X = Corresponding Segment(C);

Compute number of Segments K =

size(X);

for J = 1 to K do

Execute From Metamodel & Segment

To instantiated Segment (Xj);

if AttrCont(Xj) <>

0 then

Execute Ver-

ify contraint(AttrCont(Xj));

end if

end for

end while

end for

Input Data. Input data of algorithm 1 is our neural

network outputs that describe if the segment will be

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

276

instantiated or not. In our case, we have two classes

(in algorithm 1 N egals two) the ﬁrst one regroups the

segments that will be instantiated and the second class

presents the segments that will not be instantiated.

Output Data. Output data of algorithm 1 is the mod-

els. From this Algorithm 1 we create the models

and we verify some constraints with OCL language

(Cabot and Gogolla, 2012) in order to have well-

formed models. This creation process is also based on

the use of instantiation data that aims to increase the

rate of well-formed models creation. For instance, if

we have as input data the metamodel of family in this

case, we instantiate the name of person by using the

stocked information from instantiation data.

Following algorithm 2 explains the segment insta-

tiation process which extracts from metamodel and

segment a part of model that is computed according

to metamodel structure. Firstly, we ﬁnd the segment

position and its elements after, we instantiate these el-

ements by using instantiation data. After that, we ex-

cute algorithm 3 to verify the conformity constraints.

Algorithm 2: From Metamodel & Segment To Instantiated

Segment.

Require: Metamodel;

Require: Segment;

Ensure: Instantiated Segment;

1: Compute number of segment elements N =

size(Elt − Segment);

2: for i = 1 to N do

3: Xi= Elt-Segment i;

4: while Xi not instantiated do

5: Find its position in its metamodel.

6: create its deﬁnition in the output model by

using Instantiation Data;

7: Verify its indexation in its metamodel;

8: end while

9: end for

Finding 3. Through the separation between

different problems such as the conformity

veriﬁcation, the instantiation process and the

model comparison the model creation process

is well done and in short-time.

Following algorithm 3 expresses veriﬁcation of con-

formity constraints by translationg OCL constraints

into instructions written in Java language. Veriﬁca-

tion conformity algorithm requires a lot of steps start-

ing by reading and extracting OCL constraints, ﬁnd-

ing their elements and ﬁnishing by its translation into

programming language.

Algorithm 3: Conformity contraint Veriﬁcation.

Require: Instantiated Segment;

Ensure: Well-Instantiated Segment;

1: Compute number of segment elements N =

size(Elt − Segment);

2: for i = 1 to N do

3: Xi= Elt-Segment i;

4: while Xi not Veriﬁed do

5: Find its constraints in its metamodel.

6: Verify its constraints deﬁntion in its In-

stantiated Elt-Segment;

7: end while

8: end for

Implementation in Code. We use Java language to

implement our approach. The metamodels are de-

ﬁned by Ecore language and their models are encoded

in XML Metadata Interchange (XMI) using Eclipse

Modeling Framework (EMF). In this case, to use and

evaluate MLP classiﬁer we manipulate Matlab.

4 EXPERIMENTATION &

EVALUATION

This section illustrates the results and the discussion

about our proposed approach to present its initial eval-

uation.

4.1 Results & Interpretation

Here, we discuss on the basic information about

each training and testing data examples that are men-

tionned in the following table 3.

Table 3: Basic information about training & testing data.

Training Data

Metamodel

name

Classes

Segments

Book 02 02

Publication 01 01

Person 03 02

Petrinet 03 05

Statemachine 13 24

Testing Data

Family 02 05

UML-CD 07 14

RS 05 05

These information relate to the speciﬁcation of the

class and the segment numbers with which the exam-

ple complexity is given.

Figure 7 illustrates the mean squared error of

training, validation and testing data. From this ﬁg-

Automatic Generation of Models from Their Metamodels Using Multilayer Perceptron Network

277

Table 4: Comparative study of proposed approaches about model generation.

Authors Input Elements Progm-Language Used Method Output Elements

Our Paper MM

& BiTable

Java & Matlab MLP & Algo Models

omez et al., 2012) MM & Models Java Simulated-Annealing Models

(Ehrig et al., 2009) Meta-Model AGG Graph Grammars Models

(Batot, 2015) MM & Models Java NSGA-II Models

(Jackson, 2002) Meta-Model Alloy SAT Solvers Models

(Wang et al., 2013) MM & STM

// Genetic Algorithm Models

Meta-Model.

Binary information table was deﬁned in section 3.

Structural metrics.

Figure 7: Performance of MLP classiﬁer.

ure, we summarize that the training error reduces af-

ter two epochs and take the best value in seven epochs,

but might stagnated on the training data set after ﬁve

epochs. Generally, our MLP network takes the best

values after seven epochs.

4.2 Threads to Validity

Our proposed approach provides good results in or-

der to produce models from their metamodels with-

out using an initiative set of models which generally

requires a good knowledge about the system to be

modeled and a lot of times. Compared with other so-

lutions such as (G

omez et al., 2012), (Fleurey et al.,

2009), (Ben Fadhel et al., 2012) and (Batot, 2015) our

approach gives new idea that automates the modeling

steps by using the machine learning technique ” mul-

tilayer perceptron neural networks” and answering on

RQ1, RQ2 and RQ3 mentionned in the section 2. For

example, the RQ1 and RQ3 problems are solved by

using ”MLP” technique and our proposed algorithm 1

with which the models are created automatically with-

out using an initial set of models and also by check-

ing some levels of conformity without intervening the

modeling designers where we answer also on RQ2.

5 RELATED WORK

Several approaches have been proposed for automatic

model generation problem. In the following, we de-

scribe some of them dependent on the used mecha-

nism and we show the table 4 that summarizes these

work by presenting some caracteristics for each one

of them.

1) Using Optimization Techniques. The most im-

portant approaches for modeling space are based on

metaheuristic techniques. For instance, this paper

omez et al., 2012) presents a metaheuristic ap-

proach for automatic generation of more precise mod-

els using Simulated Annealing (SA) in conformity

with a set of criteria deﬁned in (Fleurey et al., 2009).

Another work (Ben Fadhel et al., 2012) processes

this problem using another heuristic method called

Genetic Algorithm (GA) to compute from an initial

model set, other well-structured models in order to

increase modeling space. Batot (Batot, 2015) has pro-

posed also another approach to solve modeling space

problem that allows using a non-dominated genetic

algorithm (NSGA-II) using metamodel and a set of

models.

2)Using Graph Grammar Methodology. Karsten et

al. (Ehrig et al., 2009) propose to use graph grammar

for creating model instances of metamodels in auto-

matic way without using an initial set of models. This

approach requires to have a good-basic aspects about

graph grammar methodology that needs a lot of time

and effort.

3) Using Formal Methods. In this context, the use

of formal methods (Clarke and Wing, 1996) is not

supported due to their difﬁculties nevertheless there

are only some proposed work (Jackson, 2002). One

best-known of them is (Jackson, 2002) that focused

on instance generation by using Alloy (Beta, 2005).

This instance generation is based on the translation

of a class diagram to Alloy representation after, SAT

solvers are used to create their instances by enumer-

ating them.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

278

4) Other Related Work. More generally, there are also

other generic approaches that aim to specify or ver-

ify modeling space automatically either to increase

the size of test data for model Transformations with

well-structured models or even to be used as input

data for model transformation by-example. This pa-

per (Fleurey et al., 2009) describes one of the most

genetic approaches by proposing a set of rules used to

evaluate the correctness of input models.

6 CONCLUSION & FUTURE

WORK

In MDE context, one of the most problems faced by

developer’s software is how to automate or facilitate

model creation process in the software development

system. In the last few years, several studies are pro-

posed to answer this question but in general, they gen-

erate models in random way or without verifying all

conformity constraints. In this paper we proposed an

approach to automate the generation of model focused

only on its metamodel by using ”Multilayer Percep-

tron Network” to obtain good and veriﬁed models in

order to reduce costs and time of software develop-

ment.

As perspective work, we propose to take into ac-

count the veriﬁcation of OCL complex constraints by

using other techniques. Also, we propose to apply

other maching learning methods to have a compar-

ative study that aims to select from a set of propoer-

ties the appropriate method for modeling step in MDE

context.

REFERENCES

Batot, E. (2015). Generating examples for knowledge ab-

straction in mde: a multi-objective framework. In

SRC@ MoDELS, pages 1–6.

Ben Fadhel, A., Kessentini, M., Langer, P., and Wim-

mer, M. (2012). Search-based detection of high-level

model changes. In 2012 28th IEEE International Con-

ference on Software Maintenance (ICSM), pages 212–

221. IEEE.

Berramla, K., Deba, E. A., and Benhamamouch, D. (2016).

Model transformation generation a survey of the state-

of-the-art. In 2016 International Conference on In-

formation Technology for Organizations Development

(IT4OD), pages 1–6. IEEE.

Berramla, K., Deba, E. A., Benyamina, A., Touam, R.,

Brahimi, Y., and Benhamamouch, D. (2017). Formal

concept analysis for speciﬁcation of model transfor-

mations. In 2017 First International Conference on

Embedded & Distributed Systems (EDiS), pages 1–6.

IEEE.

Berramla, K., Deba, E. A., Jiechen, W., Sahraoui, H. A.,

and Benyamina, A. E. H. (2020). Model transforma-

tion by example with statistical machine translation.

In MODELSWARD, pages 76–83.

Beta, T. A. A.-. (2005). http://alloy.mit.edu/index.php.

Blanc, X. and Salvatori, O. (2011). MDA en action:

Ing

enierie logicielle guid

ee par les mod

eles. Editions

Eyrolles.

Budinsky, F., Brodsky, S. A., and Merks, E. (2003). Eclipse

Modeling Framework. Pearson Education.

Cabot, J. and Gogolla, M. (2012). Object constraint lan-

guage (ocl): a deﬁnitive guide. In International

School on Formal Methods for the Design of Com-

puter, Communication and Software Systems, pages

58–90. Springer.

Clarke, E. M. and Wing, J. M. (1996). Formal methods:

State of the art and future directions. ACM Computing

Surveys (CSUR), 28(4):626–643.

Ehrig, K., K

uster, J. M., and Taentzer, G. (2009). Gener-

ating instance models from meta-models. Software &

Systems Modeling, 8(4):479–500.

Fleurey, F., Baudry, B., Muller, P.-A., and Le Traon, Y.

(2009). Qualifying input test data for model trans-

formations. Software & Systems Modeling, 8(2):185–

203.

omez, J. J. C., Baudry, B., and Sahraoui, H. (2012).

Searching the boundaries of a modeling space to test

metamodels. In 2012 IEEE Fifth International Con-

ference on Software Testing, Veriﬁcation and Valida-

tion, pages 131–140. IEEE.

Jackson, D. (2002). Alloy: a lightweight object modelling

notation. ACM Transactions on Software Engineering

and Methodology (TOSEM), 11(2):256–290.

Jouault, F., B

ezivin, J., and Team, A. (2006). KM3: a dsl for

metamodel speciﬁcation. In In proc. of 8th FMOODS,

LNCS 4037, pages 171–185.

Schmidt, D. C. (2006). Model-driven engineer-

ing. COMPUTER-IEEE COMPUTER SOCIETY-,

39(2):25.

Soley, R. et al. (2000). Model driven architecture. OMG

white paper, 308(308):5.

Wang, W., Kessentini, M., and Jiang, W. (2013). Test cases

generation for model transformations from structural

information. MDEBE@ MoDELS, 1104:42–51.

Automatic Generation of Models from Their Metamodels Using Multilayer Perceptron Network

279