Data Integration between Objectiver and DB-Main: A Case Study of a
Model-Driven Interoperability Bridge
Francisco Javier Berm
udez Ruiz
, Jes
us Joaqu
ın Garc
ıa Molina
and Oscar D
ıaz Garc
University of Murcia, Murcia, Spain
University of the Basque Country, San Sebasti
an, Spain
Tool Integration, Interoperability, Model-Driven Engineering, Data Engineering, Goal-oriented Requirements
In building software systems, the integration of tools with the purpose of exchanging data (i.e. tool inter-
operability) is common practice. Such an integration is one of the application scenarios of Model-Driven
Engineering (MDE), which is often called Model-Driven Interoperability (MDI). In the last few years, some
MDI approaches have been presented, and they have shown how MDE techniques are useful in bridging tools
in order to integrate data. However, the number of case studies is still limited and more practical experiences
of building MDI bridges should be published. In this article, we present an MDI bidirectional bridge that
integrates the Objectiver and DB-Main tools. DB-Main database schemas are obtained from Objectiver object
models, and they are kept consistent. Through this case study, we contrast the majority of techniques that can
be used to implement a MDI solution. We mainly focus on the level of automation offered by each alternative.
Some lessons learned are commented on.
The development of software systems commonly in-
volves the need to integrate tools. A kind of integra-
tion is the exchange of data between tools (Thomas
and Nejmeh, 1992). Such an integration is called tool
interoperability and it is defined as the ability of two
tools to exchange information so that the informa-
tion generated by one tool can be used by the other
(Geraci, 1991) (Thomas and Nejmeh, 1992). Because
the exchanged data are represented and interpreted in
a different way in each tool, building an interoperabil-
ity solution (commonly known as a bridge) normally
requires the implementation of syntactic and semantic
mapping. MDE techniques, especially metamodeling
and model transformation, are appropriate to imple-
ment such bridges, and Model-Driven Interoperability
(MDI) is one of the recognized application scenarios
of MDE (Brambilla et al., 2012).
Several approaches to building MDI bridges have
been presented in the last few years (Bruneliere et al.,
2010) (Sun et al., ) (Diallo et al., 2013), which are
based on (i) the use of metamodels to represent the
information exchanged by each tool, and (ii) the ap-
plication of a model transformation in order to align
the tools (i.e. a mapping between the metamodels),
so that the information exchanged can be used in
the target tool. Moreover, some examples of MDI
bridges between software tools have been described,
e.g. code clone detection textual reports to SVG
code (Sun et al., ) and Eclipse/EMF (Steinberg et al.,
2009) model/metamodels to Microsoft modeling tools
(Bruneliere et al., 2010). However, the number of
case studies and practical experiences reported is still
limited and the presented works have not faced the
choice between several implementation alternatives.
In this article we present an MDI bidirectional
bridge between the DB-Main and Objectiver tools.
DB-Main is a data engineering tool that assists de-
velopers in designing database schemas and tasks in-
volved in data reverse engineering, data evolution and
data maintenance. Objectiver is a requirement engi-
neering tool based on the KAOS methodology. The
bridge aims to obtain DB-Main database schemas
from KAOS object models created in Objectiver, as
well as the opposite transformation. Therefore, ob-
ject models and schemas are kept consistent by this
bridge. Since DB-Main offers three ways to interop-
erate (API, XML and grammar format), several MDE
techniques may be used to build the syntactic map-
ping (i.e. obtaining models from exchanged data and
vice versa). The different implementation strategies
Ruiz, F., Molina, J. and García, O.
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge.
DOI: 10.5220/0005653504770488
In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 477-488
ISBN: 978-989-758-168-7
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
are described and contrasted. With regard to the se-
mantic mapping (i.e. establishing links between the
data used in each tool), we have explored the use of
QVT relational, and more specifically its capability to
write bidirectional model transformations and to keep
the source and target models synchronized. To our
knowledge this work is one of the first reports on a
bidirectional MDI bridge that provides an assessment
of different implementation strategies.
The rest of this article is organized as follows.
The next section motivates the problem and Section 3
outlines the proposed approach. The implementation
of the approach is then described in detail. Firstly,
Section 4 introduces the pivot metamodels; Section 5
discusses several strategies to implement the syntac-
tic mapping and includes an assessment of them; and
Section 6 analyzes how the semantic mapping can be
implemented by means of a bidirectional model trans-
formation written in the QVT Relational language.
Section 7 shows the application of the described ap-
proach to an object model example. Finally, some
related works are commented on and some lessons
learned are indicated in the conclusions.
Building software systems involves using multiple
tools with different purposes, which cover all the
stages of the software development life-cycle. There-
fore, tool integration has always been a topic of great
interest for the software community (Thomas and Ne-
jmeh, 1992). We have tackled the integration of the
DB-Main database engineering tool
with the Ob-
jectiver requirement engineering tool
, as part of a
collaboration with the Precise research group, which
created DB-Main at 1993.
DB-Main is a mature and free tool with a rich
functionality for data engineering. To facilitate inte-
gration with other tools, DB-Main provides an API
Java named JIDBM (Java Interface for DB-Main)
which allows data and metadata of DB-Main projects
to be manipulated. The DB-Main project files (.lun
extension) offer an alternative to the use of this API;
they represent all the information involved in a DB-
Main project in a non-XML proprietary format (here-
after LUN format), which defines a complex structure
with which to save and load the DB-Main projects.
In addition, a plugin that exports historical data and
schemas in XML format is being developed, and an
initial version of this plugin is supported in a beta ver-
sion (at this moment the tool does not yet support the
XML importation).
KAOS is a well-known goal-oriented requirement
engineering method (Dardenne et al., 1993). The ba-
sic concepts of this method are the following: (i) re-
quirements are described by means of a hierarchy of
goals (i.e. desired system properties); (ii) each goal
is assigned to the agent (or agents) responsible for
achieving it; (iii) goals involve domain entities (a.k.a.
objects) and relationships between them; and (iv) be-
havior that agents need to fulfill is expressed by means
of operations, which are triggered by events, and work
on objects. A requirement elicitation is therefore
expressed by means of four kinds of models: Goal
model, Responsibility model, Object model and Op-
eration model. Objectiver is a payment tool support-
ing KAOS methodology: it allows analysts to create
KAOS models and generates requirement documents
conforming to existing standards, among other func-
tionalities. This tool not only allows the export/import
of project data in XML format, but also as Ecore mod-
els (Steinberg et al., 2009). To achieve this, Objec-
tiver defines an Ecore metamodel which describes the
four kind of KAOS models. This feature promotes the
MDE interoperability of the tool as will be discussed
The aim of our work has been to build an MDE
interoperability bridge between Objectiver and DB-
Main. More specifically, a bridge able to establish
a bidirectional mapping between Objectiver object
models and DB-Main logical schemas. Objectiver ob-
ject models (which represents the concepts of the ap-
plication domain in KAOS methodology) are used to
create a database schema in DB-Main. On the other
hand, the changes applied to database schemas in DB-
Main are propagated to the object model managed by
Objectiver. Therefore, the solution not only allows the
generation of a final system’s software artifact (i.e. a
database schema) from a requirement model (i.e. the
object model), but the inverse transformation is also
possible. In this way, the object model and the schema
are kept synchronized.
Interoperability normally requires addressing both
syntactic and semantic mappings because each tool
or component to be integrated can represent the ex-
changed information in a different format and can also
give a different meaning to this information. MDE
facilitates the implementation of tool interoperability
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
Model A
Metamodel A
Format A
Input A
Model B
Metamodel B
Format B
Input B
Figure 1: Using MDI techniques between two systems (ex-
tracted from (Brambilla et al., 2012)).
through the use of metamodeling and model trans-
formation. Models and metamodels provide a high-
level representation for the exchanged information,
and they act as a lingua franca between the tools
(Brambilla et al., 2012). Model transformations ease
the implementation of the necessary mappings. In ad-
dition, existing MDE tooling can automate some im-
plementation tasks.
Figure 1 shows the elements of a generic MDI
bridge for tools A and B (Brambilla et al., 2012), each
one using its own data format. Applying MDE in or-
der to build an interoperability bridge involves defin-
ing a pivot metamodel for each tool, which represents
the concepts underlying to the information managed
by the tool. In Figure 1, metamodels A and B are
the pivot metamodels and both share the same meta-
metamodel (e.g. Ecore). Once the pivot metamod-
els are created, the syntax and semantic mappings can
then be implemented. A bidirectional transformation
between the pivot metamodels performs the semantic
mapping between both tools. If the bridge is bidi-
rectional then two model-to-model (M2M) transfor-
mations should be implemented, one for each direc-
tion, unless the M2M transformation language sup-
ports bidirectionality. Since each tool uses its own
format to represent data, the semantic mapping re-
quires a syntactic mapping which consists of two pro-
cesses: i) the injection process: the exchanged data by
the source tool must be converted into the input model
to the M2M transformation, and ii) the extraction pro-
cess: data to be used by the target tool are generated
from the model outputted by the M2M transforma-
tion. Therefore the building of an MDI bridge implies
the following four development tasks:
Creating the Pivot Metamodel for each Tool.
These metamodels should not be created if the
two tools support exportation of the exchanged
information to a metamodel and both metamod-
els have been defined with the same metamod-
eling language (e.g. Ecore). If the metamod-
els have been created with different metamodel-
ing languages then an interoperability at level of
meta-metamodel must be defined. An approach to
bridge Ecore metamodels and metamodels created
with DSL Tools is described in (Bruneliere et al.,
2010). Actually, most existing tools do not sup-
port exportation to models, and those that export
some kind of information to models use Ecore
Creating Injectors. An injector obtains a model,
which conforms to a metamodel, from data ex-
pressed in another technology (e.g. XML or
source code). In MDE interoperability, the in-
jectors are used to represent the source tool data
in the form of models that conform to the source
pivot metamodel. An injector performs two tasks.
Firstly, it parses the source information expressed
in the format used by the tool (e.g. a proprietary
format or XML). Then, it creates the model that
conforms to the source metamodel. How injec-
tors are built depends on the data format. Most
tools use a textual format to represent information
(e.g. XML or file format). Therefore, the injectors
must normally implement text-to-model transfor-
mations. Several strategies for building injectors
for different formats are analyzed in Section 5.
Creating Semantic Mappers. If the bridge is
unidirectional any M2M transformation language
could be used. However, if the bridge is bidi-
rectional, a language supporting bidirectionality
should be used to write only one transformation
instead of writing one for each direction. QVT
Relational is a good option for this purpose, al-
though the bidirectionality is still an issue open in
QVT (Stevens, 2013).
Creating Extractors. An extractor performs the
opposite operation to an injector. In MDE inter-
operability, the extractors are used to obtain data
usable by the target tool from a model that con-
forms to the target pivot metamodel. As indicated
above, most tools represent the information in tex-
tual format. Therefore extractors are normally im-
plemented by means of model-to-text transforma-
tions. Several strategies for building extractors for
different formats are analyzed in Section 5.
Figure 2 shows the Objectiver/DB-Main bridge
which has been built so as to achieve MDE inter-
operability between DB-Main and Objectiver, where
database schemas and KAOS object models is the
information to be exchanged. Since Objectiver im-
ports/exports KAOS models from/to an Ecore meta-
model, we have just defined a pivot metamodel which
represents the database schemas in DB-Main. There-
fore, the creation of an injector and an extractor is not
needed for Objectiver. Instead, three kind of injectors
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge
EMF XML + m2m
Gra2MoL + m2t
DSL workbench
Figure 2: Objectiver/DB-Main bridge.
have been created for DB-Main, taking into account
the three options provided by this tool which it uses
to access its information. As shown in Figure 2, for
each option two implementation strategies have been
considered. QVT Relational has been used to imple-
ment the semantic mapping.
In building a MDI bridge, the first stage is the cre-
ation of the pivot metamodels. In the case of the
Objectiver/DB-Main bridge, only the pivot meta-
model for DB-Main must be created. Objectiver in-
cludes a KAOS metamodel that defines 44 elements,
but we have only considered those related to the ob-
ject model. Figure 3 shows this part of the KAOS
metamodel. An Objectiver model is represented by a
KModel and this is made up of one package (KPack-
age) named rootPackage. Packages are composed of
KAOS diagrams (KDiagram), KAOS entities (KEn-
tity) and KAOS relationships (KRelationship). KAOS
Diagrams provide graphical data in order to visual-
ize models. KAOS Relationships allow the definition
of responsibilities (Responsibility) between agents
(Agent) and requirements (Requirement). KAOS En-
tities are the basic elements of the Objectiver mod-
els. In addition to the requirements and expectations
properties (Expectation), the following abstract ob-
jects (AbstractObject) are defined: (i) agents (Agent),
(ii) goals (Goal), (iii) entity objects (Entity) that rep-
resent the objects in the Object model, and (iv) re-
lationships (Relationship) which contain links (Link)
that define connections between abstract objects and
register the multiplicity of the link. These abstract ob-
jects are characterized by attributes (Atribute) which
contain a name and a domain.
KModel KPackage
AbstractObject AbstractProperty
Expectation Requirement
Agent Goal
rootPackage 1
* diagrams entities *
* relationships
1 package
attributes *
requirement 1
responsible 1
* link
1 linksTo
Figure 3: Excerpt of the Objectiver pivot metamodel.
Column Tabl e
* *
* *
source destination
Figure 4: DB-Main pivot metamodel.
We have defined the DB-Main metamodel shown
in Figure 4. This metamodel has been devised ac-
cording to the data structure used in DB-Main to rep-
resent database schemas. Thereby, the implementa-
tions of injectors/extractors to/from DB-Main are less
complex. A database schema (Schema) is composed
of a collection of tables (Table) and a collection of
foreign keys (ForeignKey). Each table is formed by
a collection of columns (Column), and references to
collections of indexes (Index) and identifiers (Identi-
fier). Each column has a type (ColumnType) whose
attributes are: type which defines the domain of a col-
umn; minCard and maxCard which define the car-
dinality in case of the multivalued columns; length
which delimits the size in the case of a string type;
decimalNumber which delimits the precision of the
decimal part in the case of a number type; and default-
Value which establishes a default value for the type.
Schemas, tables and columns have a name. Each
identifier has a boolean attribute isPrimary to indicate
if it is the primary key of the table that references it.
Foreign keys (ForeignKey) reference the source and
destination columns, which are stored in two ordered
sets of the same size. Given a position, a column in
the source set represents the foreign key column of a
table which references a column in the destination set
which represents the primary key column of another
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
Once the pivot metamodels are available, the injectors
and extractors must be created if the tool does not sup-
port the facilities to export/import data to/from Ecore
models. As indicated previously, we have only cre-
ated injectors/extractors for DB-Main, since they are
already included in the Objectiver tool.
Several MDE tools may be used in order to au-
tomate the creation of injectors and extractors. For
XML schemas, Eclipse/EMF provides a generic in-
jector/extractor to/from Ecore models. EMF requires
the XML Schema of the XML documents, and au-
tomatically generates a metamodel which represents
the information specified in the XML Schema. The
EMF injector transforms a XML document conform-
ing to the XML Schema in a model conforming to the
previously generated metamodel. The EMF extractor
performs the reverse process.
For a grammar format, DSL definition tools (a.k.a.
DSL workbenches), such as Xtext
and EMFText
can be used to automatically generate an injector and
extractor. The grammar is specified by means of the
notation provided by the workbench to express the
DSL grammar. Injectors can also be automatically
generated by means of a text-to-model transformation
language, such as Gra2MoL (C
anovas Izquierdo and
ıa Molina, 2014), which allows the expression of
mappings between grammars and metamodels.
The use of a Java API can be automated by means
of the API2MoL tool (Izquierdo et al., 2012), which
automates the creation of (i) the API metamodel, (ii)
the injector that obtains a model from API objects,
and (iii) the extractor that generates API objects from
As indicated in Section 2, DB-Main provides three
alternatives for integrating data: the JIDBM API, and
the LUN and XML formats. Figure 5 shows four di-
agrams which outline the injection/extraction strate-
gies that can be implemented for DB-Main, which are
explained below.
5.1 Strategies to Implement the
For the JIDBM API (see Figure 5(a)), we have con-
trasted the manual creation of a Java application with
the automated generation of the injector by means of
the API2MoL tool.
Using the EMF API. A Java application uses
JIDBM to access the DB-Main data (it is not re-
Generated by
< XML >
XML Serializer
EMF Parser
XML file
< XML >
m2t: Xpand, Acceleo
Project file
t2m: Gra2Mol
(a) (b)
Figure 5: Injectors and extractors for DB-Main.
quired that the tool was in execution) and the re-
flective EMF API to create the DB-Main model
which represents the database schema. The per-
sistence service of EMF is used to store the model.
Using API2MoL. API2MoL automatically gen-
erates the JIDBM metamodel and the injec-
tor/extractor for this metamodel. The API2MoL
input should be a Java program using the API.
For the bridge proposed here, the program
uses JIDBM to recover all the data of a DB-
Main project. Regarding the previous solution,
API2MoL avoids implementing the manual task
of creating the model by using the EMF API.
In our case, the generated API metamodel is
slightly different to the defined DB-Main meta-
model. Hence an additional M2M transformation
is needed, although it could also have been used
as the pivot metamodel.
For the XML format (see Figures 5(b) and (c)), we
have contrasted the manual creation of a Java applica-
tion with the automated generation of the injector by
means of the EMF generic injector.
Using the EMF API. The EMF API can be used
to create a model from either the data produced in
an XML parsing or the Java objects obtained in a
XML-to-Java mapping. We have created a XML
parser using the SAX parser included in JAXP
Although JAXP also provides a DOM parser that
loads all the data contained in the XML document
in memory at once, the restrictions in the queries
of the XML document promote the use of SAX.
On the other hand, we have used the JAXB API
which maps Java objects to XML documents and
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge
vice versa. To build an injector, the unmarshall
tool provided in JAXB allows the loading of the
XML data into memory as Java objects. Then, a
Java program can analyze these objects and use
the EMF API to create a model that conforms to
the DB-Main metamodel.
Using the generic XML injector provided by EMF.
As indicated above, EMF provides a generic in-
jector for XML documents. The models injected
conform to the XML Schema metamodel. An
additional M2M transformation that converts the
model injected into a DB-Main model would be
therefore necessary.
LUN files store the data and metadata of a DB-
Main project, in particular the database schema, the
history of the different schema versions, and the op-
erations applied in a data engineering process. Since
the LUN format is defined by a grammar, DSL work-
benches and text-to-model transformations may be
used to automate the building of injectors. Therefore,
we have again contrasted an EMF-based manual so-
lution with the use of DSL workbenches, in partic-
ular EMFText, and the Gra2MoL language (see Fig-
ure 5(d)). However, the complexity and variability of
the LUN format makes it very difficult to implement
the EMFText grammar as well as the Gra2MoL trans-
formation. For instance, the meaning of some data are
dependent of their position and type in the LUN file.
5.2 Strategies to Implement the
As with injectors, we have experimented with sev-
eral strategies for each DB-Main interoperability op-
tion (see Figure 5). In the case of JIDBM (Fig-
ure 5(a)), the two strategies previously described for
the injectors are bidirectional because JIDBM also
includes methods for creating and updating the DB-
Main data. Therefore, the JIDBM and EMF APIs
could be used to create an extractor manually. How-
ever, this extractor could be automatically generated
by using API2MoL.
Using the XML schema, the strategies used for in-
jectors are bidirectional, so that they can again be ap-
plied to create extractors but in the opposite direction.
The EMF API is used to traverse the DB-Main
pivot model, and a XML parser or the JAXB map-
per in order to create the XML document (Fig-
ure 5(b)). In this scenario, the DOM parser could
be more appropriate than the SAX parser due to
the fact it eases the creation of XML trees.
The generic extractor available in EMF could
be used by previously writing an M2M transfor-
mation that converts the DB-Main model into a
model that conforms to the XML schema’s meta-
model. Then, the generic extractor could serial-
ize the XML model into a XML document (Fig-
ure 5(c)). It is worth remarking that a single M2M
transformation could be enough if a M2M trans-
formation language supporting bidirectionally is
Finally, a LUN file could be generated from a DB-
Main model by using a M2T transformation (see Fig-
ure 5(d)). However, the complexity of the LUN gram-
mar makes it difficult to implement this transforma-
tion and the effort required is much greater than for
the other implementation strategies.
5.3 Assessment of the Strategies
In the previous section, different strategies have been
proposed which implement the Objectiver/DB-Main
bridge for the EMF framework. Four main criteria
could be considered to choose the most appropriate
Automation Level. Instead of creating solutions
from scratch by means of GPLs and APIs, MDE
technology (tools and languages) can be used to
automate the creation process. In this way, the
effort involved in development is significantly re-
Bidirectionality. Which bidirectionality facilities
are provided should be taken into account. An
ideal solution would be to implement the injection
and extraction process at once.
Ease of Learning. Learning the applied technolo-
gies involves an effort which must be taken into
consideration when evaluating the cost of devel-
oping a solution.
Maturity Level of Tools. The lack of mature MDE
tools is hindering its industrial adoption. Many
tools stem from academic projects and they lack
the required standards of quality.
Table 1 summarizes the assessment of the applied
strategies regarding the considered criteria. With re-
gard to the level automation, the following marks are
used: 7 indicates that the solution is totally manual,
3 if the automation is achieved by writing model
transformations, 33 if an additional m2m transfor-
mation is required, and 333 when injectors and ex-
tractors are automatically generated. Bidirectionality
is supported if the injector/extractor can be generated
from an only specification (or program). In assess-
ing easiness, we have considered that GPLs, involved
APIs, and BNF grammars are easy to use and learn.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
Table 1: Assessment of the strategies.
Strategy Automation Bidirectional Easiness Maturity
API2MoL 333 3 7 7
XML Document SAX/DOM or JAXB + EMF 7 7 3 3
EMF XML + m2m 33 3 3 3
LUN format manual parser/generator + EMF 7 7 3 3
Gra2MoL + m2t 3 7 7 7
DSL workbench 333 3 3 3
Finally, we have considered as mature tools those cre-
ated by companies or consortium that have provides
an stable support for several years.
The ideal strategy would be a strategy capable of
automatically creating a bidirectional solution (i.e. in-
jector and extractor are automatically generated), and
is based on mature technology which is easy to use
and learn. Next, we will analyze the MDE technol-
ogy involved in the outlined strategies.
API2MoL is shown as the best choice from a tech-
nical point of view, because it automatically gener-
ates a bidirectional solution. This tool also generates
the API metamodel (in this case, the JIDBM meta-
model), which could be adequate as a pivot meta-
model. An additional M2M bidirectional transforma-
tion would be needed if the API metamodel is not
the pivot metamodel, and developers should just write
a simple program that uses the API for building the
data objects to be injected. However, API2MoL is
an academic tool that has been discontinued. More-
over, lack of documentation makes learning it diffi-
cult. It is also worth noting that the metamodel gener-
ated by API2MoL may be incomplete, as discussed in
(Izquierdo et al., 2012). Developers should therefore
write an APi2MoL specification in order to obtain the
complete metamodel, as well as the corresponding in-
jector and extractor. In our case, the metamodel gen-
erated by API2MoL was complete.
EMF also provides a bidirectional solution
through the generic injector and extractor available
for a XML Schema. As indicated above, an additional
M2M transformation is always needed to map the
XML schema metamodel and the pivot metamodel.
This mapping should be implemented by means of
a bidirectional transformation. Regarding API2MoL,
the use of these tools is simpler and the effort involved
in learning it is significant lower.
With regard to the grammar format, DSL work-
benches allow the obtaining of a bidirectional so-
lution from a BNF-like grammar specification. In
addition, T2M and M2T transformations may be
used to implement injectors and extractors, respec-
tively. To our knowledge, Gra2MoL is the only
available T2M transformation language, but this lan-
guage is specially tailored to inject models from GPL
code. A detailed comparison of Gra2MoL and DSL
workbenches is discussed in (C
anovas Izquierdo and
ıa Molina, 2014). On the other hand, M2T
transformation languages (e.g. Acceleo and Xpand)
are widely used to generate textual software artefacts
from models, and they are easy to learn and use. In
our case, these three strategies are the choice that in-
volve a larger development effort due to the complex-
ity of the LUN format.
Once the syntactic mapping has been created, the se-
mantic mapping could be implemented. In our case,
a bidirectional mapping between the DB-Main pivot
metamodel shown in Figure 4 and the excerpt of the
Objectiver metamodel shown in Figure 3. A bidirec-
tional M2M transformation should be written to im-
plement such a mapping, instead of writing two uni-
directional M2M transformations. In this way, the
implementation and maintenance effort would be re-
duced. Among the most widely used M2M trans-
formation languages, QVT Relational is the only
one supporting bidirectionality. Although QVT was
proposed with the purpose of becoming a standard
language for M2M transformations, only a few im-
plementations are currently available and none have
achieved the desired level of maturity. ModelMorf
and Medini QVT
are the commonly used imple-
mentations. We have used Medini QVT ”due to its
greater visibility on the Web, Eclipse integration, de-
bugging facilities and other developer-friendly fea-
tures” (Stevens, 2013). Below, we describe the de-
fined QVT transformation.
Figure 6 represents the mapping applied without
considering foreign keys (FK). The graphical nota-
tion depicts the metamodel’s classes as boxes and the
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge
dbm: Schema
tables: Table
kaos: KModel
rootPackage: KPackage
entities: Entity
[isObjectModel = true]
id , name
columns: Column
identifiers: Identifier
new columnKey:: Column
id := new
name := ‘id’ + name
type := ‘INTEGER’
DB-Main Model Objectiver Model
new identifier:: Identifier
id:= new
isPrimary:= ‘true’
OrderedSet { ‘id’ + name }
attributes: Attribute
name ,
colum_type == domain
Figure 6: Semantic mapping for tables entities.
semantic links between them as bidirectional arrows.
The arrows are labeled by the attributes mapped in
the link (== is used to denote the mapping but it is
omitted if the name is the same in both metamodels).
The reference and aggregation relationships between
classes are represented by means of nested boxes.
Figure 6 shows that a DB-Main schema (Schema)
maps to a root package (KPackage) of an Objectiver
model (KModel). The schema and the root package
will have the same name, and each table (Table) of
the schema maps to an entity object (Entity) of the
package. A table and its mapped entity will have the
same name and identifier (id). Each column (Colum)
of a table maps to an attribute (Attribute) of an en-
tity. A column and its mapped attribute will have the
same name and the column type are given by the do-
main of the attribute. A new column for registering
the primary key is directly instantiated. Its type is
’INTEGER’ and its name is formed by concatenating
the table name to the prefix ’id’. It is worth noting that
the attributes of an entity do not have id but columns
and identifiers in the DB-Main model and require an
unique id. New ids for the elements of a DB-Main ta-
ble are created by systematically concatenating the id
of the container element to a sequential counter which
starts from zero for each container element. A new
identifier is also instantiated. Its isPrimary attribute
is ’true’ and its columns attribute is the name of the
new column key added.
Figure 7 represents how FKs are mapped to
relationships. This mapping is similar to the
conversion between the Entity/Relationship model
and the Relational model (without considering op-
tional/mandatory relationships, i.e. not considering
multiplicity 0). The conversion implies that the table
having multiplicity 1 propagates the columns of its
primary key to the table with multiplicity N, where a
new FK comprising the propagated columns is added.
An Objectiver object model can include three kinds of
dbm: Schema
tables: Table
dbm: Schema
tables: Table
columns: ColumnsFK
DB-Main Model Objectiver Model
kaos: KModel
rootPackage: KPackage
link1: Link
link2: Link
multiplicity = 1
linksTo: Entity
multiplicity = N
linksTo: Entity
source: Column
destination: Column
id , name
identifiers: Identifier
columns: Column
id , name
columns: Column
id , name
new columnFK:: Column
Figure 7: Semantic mapping for f oreign keys
relationships: 1:1, 1:N and N:N. A FK (ForeignKey)
of a table maps a relationship (Relationship) between
entities. A relationship has two links that represent
the multiplicities at each end. For relationships 1:1
and 1:N, each link maps a table, more specifically the
table mapped to the entity referenced by the link (ref-
erence linksTo). In accordance with the previously
explained conversion, the entity in the link with the
multiplicity 1 corresponds to the table that propagates
its primary column to the other table as the FK col-
umn. Note that the column propagation occurs only
in the DB-Main model. As we can see in Figure 7,
links are mapped to tables by the attribute linksTo.
Once we have identified both the tables in DB-Main
involved in the relationship of Objectiver, the propa-
gation of the new column in the DB-Main model is
simple. We should create a new column from the col-
umn that comprises the identifier of a table in order to
represent the new columnFK in the other table. Both
columns, the new FK column of a table and the iden-
tifier column of the other one are the source and des-
tination columns of the ColumnsFK element in the
DB-Main model, respectively. For N:N relationships
a new table is generated in the DB-Main model. It is
composed of the columns which comprise the primary
key of the two tables involved in the N:N relationship.
The two new 1:N relations between the new table and
the tables of the relationship are resolved by using the
previous 1:N mapping.
Once the semantic mapping of our bridge is de-
fined, we shall illustrate how the mapping has been
implemented by means of Medini QVT. We shall
show only one pair of QVT relations due to space lim-
The next relation corresponds to the mapping be-
tween schemas and Objectiver models. It is only ap-
plied when the Objectiver model is an object model.
For this, the isObjectModel() helper checks if the
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
name of the Objectiver model contains the ”object”
string. The mapping establishes that entities and ta-
bles have the same name. Finally, the Table2Entity
relation that maps the tables of the schema and
the entities of the root package is resolved. The
TableKey2Entity relation that establishes a table iden-
tifier for each entity is also resolved.
top relation SchemaToModel {
n : String;
idModel : String;
enforce domain dbmain dbm : dbmain::Schema {
name = n,
tables = tb : dbmain::Table {}
enforce domain objectiver obj:kaos::KModel {
rootPackage = root : kaos::KPackage {
subPackages = subs : kaos::KPackage {
name = n,
entities = en : kaos::Entity {}
when { isObjectModel(n);}
where {
idModel =’:’);
TableKey2Entity(tb,en, idModel);
Table2Entity(tb,en, idModel);
The relation that maps to 1 : N relationships is
shown below. When this relation is applied the iden-
tifiers are mapped and the ColumnsFK2Links relation
is resolved in order to map the FK columns and the
two links of the relationship.
relation FK2Relation1N {
i : String;
idI : Integer;
lk1 : kaos::Link; lk2 : kaos::Link;
enforce domain dbmain fk :
dbmain::ForeignKey {id = idI };
enforce domain objectiver rel :
kaos::Relationship { id = i };
primitive domain idModel : String;
when {
idI = toIdInteger(i);
i = toIdString(idModel,;
where {
lk1.multiplicity = ’1’;
lk2.multiplicity = ’n’;
ColumnsFK2Links(cl,lk2, lk1);
We have taken an excerpt of the automated train con-
trol system example presented in (van Lamsweerde,
Figure 8: Goal model of the running example.
Figure 9: Object model of the running example.
2000) to illustrate the bridge between Objectiver
and DB-Main. This example shows how KAOS
can be used to model the requirements involved in
a train traffic security system. The goal model is
shown in Figure 8 and defines an expectation (Safe
transport), a main goal to accomplish (Avoid
train collisions) and several refinements by us-
ing simpler requirements. The agents involved in
the goals are: Speed control system, On board
train controller and Tracking system. The en-
tities managed by the goals are Train, Line and
The object model is shown in Figure 9. As can be
observed in this figure, the notation for these mod-
els complies with those used in UML for class di-
agrams. This model represents the entities (Train,
Line, and TrackSegment) and the relationships be-
tween entities, but agents are not included. Train
has its own association to be able to define the prece-
dence between trains. Line includes the position
attribute which refers to the position inside the track
segment (considering that each line has a position
in each track). Each Line contains one or more
TrackSegments and each TracSegment could be as-
signed to one or more Lines (contain association).
To apply our bridge to the previous example, we
must firstly export the Objectiver project to an Ecore
model, conforming to the Objectiver metamodel (see
Figure 10). We should then apply the previously pre-
sented QVT transformation to obtain the DB-Main
model (see Figure 11). Next, we have performed
the API2MoL extractor to generate the DB-Main
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge
Figure 10: Ecore model of the Objectiver project.
Figure 11: Ecore model of DB-Main after the semantic
Figure 12: DB-Main project extracted by the syntactic map-
database schema, which is shown in Figure 12. Each
relationship has been converted into a foreign key.
For the N:N relationship a new table has been created
(LineTrackSegment) along with its foreign keys.
Next, we applied some changes to the generated
schema and the object model in order to test the syn-
chronization. For instance, we added a new number
attribute to the Train table in the DB-Main schema
(wagons). After applying the injection process and
the semantic mapping, the new object model shown
in Figure 13 was generated.
Figure 13: Ecore model of the Objectiver project after the
Tool integration has been a topic of great interest
from the early years of software engineering. In
(Thomas and Nejmeh, 1992), tool integration is an-
alyzed from several dimensions and more recently a
research agenda has been proposed in (Wicks and De-
war, 2007). According to the definitions proposed
in (Thomas and Nejmeh, 1992), our work is focused
on tool interoperability In the review of the literature
presented in (Wicks and Dewar, 2007), Model-driven
interoperability approaches are not considered since
MDE was then just emerging and XMI is shown only
as a novel format which exchanges data.
The injection and extraction processes needed in
a model-driven interoperability are an example of
bridging Modelware technology (i.e. MDE) and
other technologies (e.g. XML, Grammarware and
APIs). The concept of technical space was intro-
duced in (Kurtev et al., 2002) to define technologies
at a high-level of abstraction. This notion was used
in (B
ezivin and Kurtev, 2005) to establish bridges
between different technologies (e.g. Grammarware,
Modelware and Ontologies). Each technical space
is characterized by the pair of concepts data/format
and the formalism used to define the data formats,
e.g. code/grammar and EBNF for Grammarware, and
model/metamodel and metamodeling language for
Modelware. In this way, mapping between technolo-
gies can be established at three different levels: data,
format and formalism. Gra2MoL (C
anovas Izquierdo
and Garc
ıa Molina, 2014) and Api2MoL (Izquierdo
et al., 2012) are examples of tools created in order
to build bridges between Modelware and other tech-
nical spaces, in particular Grammarware and APIs,
respectively. Textual DSL workbenches also bridge
Modelware and Grammarware. Support in order to
bridge Modelware and XML technology is provided
by EMF (Steinberg et al., 2009). In the case of
the Objectiver/DB-Main bridge, Modelware can be
mapped to three different technical spaces: Grammar-
ware (LUN format), XML and APIs (JIDBM). There-
fore, we have considered the above mentioned tools.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development
How MDE could be used in the tool interoper-
ability scenario was shown in (Fabro et al., ) for the
AMMA MDE framework. This work proposed to im-
plementing semantic mapping by means of a weaving
model created with the AWM (Atlas Weaver Model)
tool. The approach was illustrated by means of a
bidirectional bridge between two bug tracking tools.
A weaving model allows only express links between
model elements, and this can only be applied if the
mapping is very simple. Therefore, M2M transforma-
tions are normally used to implement MDI bridges. In
(Sun et al., ), another MDI approach is presented for
the AMMA framework, which uses an M2M transfor-
mation to implement a unidirectional semantic map-
ping for converting textual reports generated by a
clone detection tool into SVG files. AMMA provides
a DSL definition tool named TCS (Textual Concrete
Syntax), which is used to automatically generate the
injector for the clone detection reports. A similar ap-
proach to integrate tools is described in (Amelunxen
et al., 2008) for the MOFLON framework, which used
MOF as metamodeling language. In contrast to these
two approaches our work has tackled the building of
a bidirectional bridge for EMF that is the most widely
used MDE platform. Moreover, we have considered
different alternatives for implementing the injector
and extractor. A bridge for integrating models created
with different metamodeling languages, in particular
Ecore and metamodeling language used in some Mi-
crosoft modeling tools (e.g. DSL Tools) is proposed
in (Bruneliere et al., 2010). This approach could be
used in our work if a platform different to EMF is
used to integrate Objectiver to other tools.
Applying MDE techniques to automate tasks in
the area of requirement engineering has been widely
addressed in the literature. Great research effort has
been devoted to defining MDE solutions that generate
software artefacts from requirement models. For in-
stance, conceptual multidimensional model for data
warehouses are generated from i* goal models in
on and Trujillo, 2007), security software arti-
facts (e.g. rules implementing security policies or se-
curity code for a database from security models in
anchez et al., 2009), or KAOS goal models from
mind maps in (Wanderley and Ara
ujo, ). Note that
the work presented here is mainly focused on build-
ing MDI bridges, rather than addressing other topics
related to the model-driven requirement engineering.
However, it is worth remarking that our approach il-
lustrates an MDE application scenario to be explored
in this area, that is, how requirement tools may be in-
tegrated with other tools in building software systems,
and how software artefacts can be generated from re-
quirement models.
We have presented an MDI approach for a case study
based on the integration of Objectiver and DB-Main.
This integration have allowed us to experiment with
the majority of concerns involved in the construction
of an MDI bridge: (i) tools may export exchanged
data to models or not, (ii) tools can offer several forms
to allow access to its data; and (iii) the integration can
be unidirectional or bidirectional. In our case, Objec-
tiver provides support to export/import its models to
Ecore models, but DB-Main does not offer such sup-
port; DB-Main provides three interoperability forms
(API, XML and grammar format); and the integration
is bidirectional. Therefore, we have explored sev-
eral implementation strategies for creating injectors
and extractors for DB-Main data, as well as the use
of QVT Relational to write bidirectional transforma-
tions. Some of the main lessons learned in building
the Objectiver/DB-Main are the following:
Automation provided by MDE tools can signifi-
cantly reduce the implementation effort compared
to using GPLs (e.g. Java) and a metamodeling
API (e.g. EMF) to build the bridge from scratch.
The choice of MDE tool depends on the available
data formats, and the criteria introduced in Sec-
tion 5 for injectors and extractors.
API2MoL and DSL workbenches provide a high
level of automation, since they can automati-
cally generate injectors and extractors. How-
ever, API2MoL is discontinued and lacks ade-
quate documentation.
When XML is used, it is worth remarking that the
strategies using SAX/DOM or JAXB can be bidi-
rectional although completely manual, whereas
the use of the EMF parser/serializer only requires
writing one or two M2M transformations (de-
pending on the bidirectional supporting) only in
case of the metamodel generated by EMF was not
valid as pivot metamodel.
DSL workbenches and EMF’s XML injec-
tor/extractor are mature tools which are easy to
use and learn. Injectors and extractors generated
by DSL workbenches that requires the pivot meta-
model as input are directly usable, while an addi-
tional M2M transformation is normally required
for EMF.
Whenever a grammar format is used to ex-
port/import exchanged data, DSL workbench
would be the preferable solution if the grammar
is not too complicated. In our case, these tools
could not be used because the LUN grammar is
large and complex.
Data Integration between Objectiver and DB-Main: A Case Study of a Model-Driven Interoperability Bridge
Considering the use of QVT, the implementa-
tion of a bidirectional mapping is more compli-
cated than a unidirectional one. Owing to the
fact that mapping declarations must be applied in
two ways, some restrictions have to be considered
(e.g. the right side of an assignment can not con-
tain complex runtime expression because it is also
the left side of the assignment when the transfor-
mation is applied in the opposite way). As writing
imperative code is commonly needed, the possi-
bility of defining helper functions in Medini QVT
is very useful. The tool allow the combination of
imperative code and OCL-style declarative code.
Medini QVT provides a lot of useful functionality
but the debug support should be improved.
We gratefully acknowledge the support provided by
the Objectiver team from the Respect-IT company
through one professional license of the Objectiver
tool. We also would like acknowledge the Precise re-
search group from the University of Namur their as-
sistance in using DB-Main.
Amelunxen, C., Klar, F., Konigs, A., Rotschke, T., and
Schurr, A. (2008). Metamodel-based tool integra-
tion with moflon. In Software Engineering, 2008.
ICSE ’08. ACM/IEEE 30th International Conference
on, pages 807–810.
Brambilla, M., Cabot, J., and Wimmer, M. (2012). Model-
Driven Software Engineering in Practice. Synthesis
Lectures on Software Engineering. Morgan & Clay-
pool Publishers.
Bruneliere, H., Cabot, J., Clasen, C., Jouault, F., and
ezivin, J. (2010). Towards model driven tool inter-
operability: Bridging eclipse and microsoft modeling
tools. In Modelling Foundations and Applications, 6th
European Conference, ECMFA 2010, Paris, France,
June 15-18, 2010. Proceedings, pages 32–47.
ezivin, J. and Kurtev, I. (2005). Model-based technology
integration with the technical space concept. In Procs.
of the Metainformatics Symposium. Springer-Verlag.
anovas Izquierdo, J. and Garc
ıa Molina, J. (2014). Ex-
tracting models from source code in software mod-
ernization. Software & Systems Modeling, 13(2):713–
Dardenne, A., van Lamsweerde, A., and Fickas, S. (1993).
Goal-directed requirements acquisition. Science of
computer programming, 20(1-2):3–50.
Diallo, P. I., Champeau, J., and Lagadec, L. (2013). A
model-driven approach to enhance tool interoperabil-
ity using the theory of models of computation. In Soft-
ware Language Engineering - 6th International Con-
ference, SLE 2013, Indianapolis, IN, USA, October
26-28, 2013. Proceedings, pages 218–237.
Fabro, M. D. D., B
ezivin, J., and Valduriez, P. Model-driven
tool interoperability: An application in bug tracking.
In On the Move to Meaningful Internet Systems 2006:
CoopIS, DOA, GADA, and ODBASE, OTM Confeder-
ated International Conferences, Montpellier, France,
October 29 - November 3, 2006. Proceedings, Part I,
pages 863–881.
Geraci, A. (1991). IEEE Standard Computer Dictionary:
Compilation of IEEE Standard Computer Glossaries.
IEEE Press, Piscataway, NJ, USA.
Izquierdo, J. L. C., Jouault, F., Cabot, J., and Molina, J. G.
(2012). Api2mol: Automating the building of bridges
between apis and model-driven engineering. Informa-
tion & Software Technology, 54(3):257–273.
Kurtev, I., B
ezivin, J., and Aksit, M. (2002). Technological
spaces: An initial appraisal. In CoopIS, DOA’2002
Federated Conferences, Industrial track.
on, J.-N. and Trujillo, J. (2007). A model driven mod-
ernization approach for automatically deriving multi-
dimensional models in data warehouses. volume 4801
of LNCS, pages 56–71. Springer.
anchez, O., Molina, F., Garc
ıa-Molina, J., and Toval,
A. (2009). Modelsec: A generative architecture for
model-driven security. J.UCS, 15(15):2957.
Steinberg, D., Budinsky, F., Paternostro, M., and Merks,
E. (2009). EMF: Eclipse Modeling Framework.
Addison-Wesley, Boston, MA, 2. edition.
Stevens, P. (2013). A simple game-theoretic approach to
checkonly qvt relations. Software and System Model-
ing, 12(1):175–199.
Sun, Y., Demirezen, Z., Jouault, F., Tairas, R., and Gray, J.
A model engineering approach to tool interoperabil-
ity. In Software Language Engineering SLE, Toulouse,
France, September 29-30, 2008, pages 178–187.
Thomas, I. and Nejmeh, B. A. (1992). Definitions of tool in-
tegration for environments. IEEE Software, 9(2):29–
van Lamsweerde, A. (2000). Requirements engineering in
the year 00: a research perspective. In International
Conference on Software Engineering, pages 5–19.
Wanderley, F. and Ara
ujo, J. Generating goal-oriented mod-
els from creative requirements using model driven en-
gineering. In International Workshop on MoDRE, Rio
de Janeiro, Brasil, July 15, 2013, pages 1–9.
Wicks, M. N. and Dewar, R. G. (2007). A new research
agenda for tool integration. Journal of Systems and
Software, 80(9):1569–1585.
MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development