Model Driven Software Engineering Environments: Requirements and Experiences

Model Driven Software
Engineering Environments:
Requirements and
Experiences
SUMMARY
MDSEEs (Model Driven Software Engineering Environments) are SEEs (Software
Engineering Environment) that fit the MDE (Model Driven Engineering) approach.
MDSEEs offer facilities to manage models, to integrate modeling tools and to support
a model driven software process. Two of the key aspects that have to be addressed
while defining MDSEEs are the data integration and the control integration aspects,
which deal with the management of models and the interaction of tool respectively. In
this document, we present our six years of contributions to the MDSEEs field through
the elaboration of ModelBus, which is an open source tool integration platform that
facilitates the creation of MDSEEs. ModelBus has been defined and validated in two
european IP projects named Modelware and Modelplex.
key words: Model Driven, Software Engineering Environment, ModelBus
1. Introduction
Forty years after the first conference on Software Engineering [2] and almost twenty years
after the IEEE Computed Society has standardized this discipline, Software Engineering is
still struggling to produce large software [27, 23]. As it was already pointed out by the NATO
conference and formalized by M.M. Lehman [32], two main reasons of this situation are the
fact that software have an intrinsic increasing complexity, but also that they are living entities
with a continuous infinite life cycle.
To tackle this main objective, Software Engineering keeps producing new technologies (or
improving existing ones). Among others, middleware, unit tests and even design patterns were
initiated at the time of the NATO conference and are still being improved years after. This
constant profusion of new technologies introduces integration issues. This paradox, identified
in [11], restrains evolution and puts software engineering professionals in front of a dilemma
because they have to choose either to use a new technology but to take the risk of not being
MODEL DRIVEN SOFTWARE ENGINEERING ENVIRONMENT 1
able to afford its integration cost, or to use an older technology but to take the risk of not
being able to solve their current problems.
This paradox is one of the main motivations of Software Engineering Environments (SEEs)
that aim at offering an integrated support to the developers∗ [21, 11, 60, 63, 24, 42]. While
they collaboratively develop software, developers participate to different software activities
(analysis, design, test, etc.). They therefore have to exchange pieces of production, named
software artifacts, and have to jointly use several software engineering tools (editors, compilers,
etc.). SEEs then aim at supporting the exchange of software artifacts; at coordinating the
different tools used by the developers; and at automating the execution of common repetitive
tasks. Moreover, SEEs not only aim at integrating together Software Engineering tools [60, 42]
but also aim at supporting software processes [43, 44, 24]. Thanks to SEEs, developers focus
on their own job and don’t waste their time on collaborative work issues.
In [60], Wasserman has identified that three main issues for building SEEs are (1) the
software artifacts storage and manipulation (data integration), (2) the coordination of tools
(control integration) and (3) the support of the software process (process integration). In the
late 1980s and in the beginning 1990s, many contributions were done in this field [12, 57, 47, 7].
SEEs provided useful facilities such as version control, collaborative edition, tool coordination
(for instance, when the program code is updated, the compiler is automatically called) and
support for process enactment. More conceptually, all SEEs agreed on the need of a formal
definition to support the data integration and on the need of an architecture to support the
control integration. Finally, the fact that the main benefits provided by SEEs come when the
software processes is supported, which can only be addressed when the data integration and
control integration are solved, was pointed out in [24, 44, 13].
With the advent of Model Driven Architecture (MDE), SEEs have however reached their
limit. MDE raises the level of abstraction of the development life cycle by shifting its emphasis
from code to models [36, 50, 49]. The two main MDE principles are (1) everything is a model
and (2) the process is model centered. With MDE, there is no more independent software
activities with their related software artifacts and functionalities. All software activities
contribute one objective that is to to build what we call the global model, which fully represents
the whole system [36]. The coding activity then consists in refining the global model and
applying automatical (or pseudo automatical) code generation. It no more consists in taking
the design specification as an input and writing textual code files as an output.
Regarding data integration, MDE considers that all software artifacts are models that
compose a bigger model, the global model. Models can be considered as graphs of model
elements [40, 22, 14, 30, 3]. The global model is therefore a big graph without a composante
fortement connexe. The data integration aspect then concerns the storage of models and
their collaborative edition. The main issues are the size of the models and their relationships.
Existing models can be small, composed of few model element, or big, composed of millions of
model elements. They may overlap as they may share some of their model elements, or may
∗ Inthis document, we use the term ’developer’ as a synonym for any member of a development team (designer,
architect, project manager, client, etc.)
Copyright c 2010 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2010; 00:0–0
Prepared using speauth.cls
2 P. S.
be connected or not. In such a context, facilities should be provided to developer to store,

exchange and edit any parts of any model.
Regarding control integration, MDE aims at automating steps of software development in
order to reduce development cost and to increase software quality. This automation is realized
by a set of modeling services such as model transformation [17, 9], model verification [33, 31]
or model execution [56]. A modeling service operates on a part of a model. It may result in
modifying this part or in creating a new model. The main issues is the identification of such
a part in order for the modeling service to access it. Control integration can be considered as
Remote Procedure Calls (RPC) [38] for modeling services.
SEEs that aim at supporting MDE then need to manage new software artifacts, to integrate
new tools and new processes [35]. They have to handle models that are complex software
artifacts composed of millions yet related model elements. SEEs have to handle new operations,
such as model collaborative edition, model transformations and model verifications. All those
operations operate on small parts of the global model and are all currently used by developers
in a disconnected mode. SEEs have to assist developers who still work in the context of
defined activities but where the actions they perform instantaneously have an impact on the
consistency of the global model. As pointed out by Douglas C. Schmidt, existing industrial
tools that claim to support the MDE approach are still based on the architecture of past
SEEs. They offer support to specific software activities that take models as inputs and outputs.
They are limited to programs written by a single person or by a team that serialized their
access to files used by these tools [49]. This raises the need for a new generation of Software
Engineering Environments that fully addresses the issues of MDE. We call Model Driven
Software Engineering Environment (MDSEEs) this new generation.
In this document, we present our contributions to the MDSEEs field through the
elaboration of ModelBus, an open source tool integration platform dedicated to the creation
of MDSEEs [53, 51, 52, 54]. We started this work in 2004 when we integrated the different
simple modeling tools we developed for our own usages [10]. From 2004 to 2006 we participated
to the ModelWare project (European Integrated Project - FP6 - 2004/2006) whose goal was
”to define and develop the complete infrastructure required for large-scale deployment of MDE
strategies and validating it in several business domains”. ModelBus was one of the project’s
major deliverable. From 2006 to 2008, we participated to the industrialization of ModelBus in
the context of the Modelplex project (European Integrated Project - FP6 - 2006/2010) whose
goal is ”to develop an open solution for complex systems engineering improving quality and
productivity”. ModelBus is now an industrial product [1].
2. ModelBus
ModelBus is our proposal for a MDSEE. It supports data integration and control integration.
It has been defined and realized during the two European Integrated Projects (Modelware and
Modelplex) to which we participate.
Regarding the Data integration, ModelBus is based on the copy-modify-merge paradigm.
Models are split into several XMI files [41] that are stored in repositories, called the model
bases. The model bases obviously support persistency but also version control. Each developer
Figure 1. ModelBus with one Model Base, one developer and three modeling tools
has his/her own local workspace, called the model workspace, that stores only the XMI files
that contain the model elements used by the developer. Developers can then locally modify
their models and commit their modifications to the model bases. To manage the integration of
developers’ modifications into the model bases, ModelBus proposes dedicated delta extraction
and delta integration mechanisms, which are based on model element’s identifier. The section
2.1 is related to the Data integration aspect and presents those mechanisms in the detail.
Regarding the Control integration, ModelBus proposes a communication layer, called tool
adapter, whose architecture is a classical broker architecture. The tool adapter layer realizes
all actions needed for a tool to consume a modeling service provided by another tool. The
tool adapter is based on web services. Models are encoded into SOAP messages (as XMI
documents) and modeling service calls are web service requests on top of HTTP. ModelBus
includes a domain specific language for specifying modeling services. Once a specification
has been elaborated, ModelBus can be used to generate an adapter skeleton that eases the
bridging of a heterogeneous tool to the tool adapter layer. The section 2.2 is related to the
Control integration aspect and presents those mechanisms in the detail.
The figure 1 represents an illustrative deployment of ModelBus. This deployment integrates
one model base, one developer with his model workspace and three tools that provide modeling
services thanks to the tool adapter layer.
4 P. S.
2.1. Data Integration
As it is described in the section ??, the main requirements for data integration concerns the
size of the models and their distribution into developer views. As a model is a graph of model
elements that can be huge, it has to be fragmented in smaller parts in order to be stored and
collaboratively edited. The two main issues are then how to fragment a model (model encoding)
and how to deal with collaborative edition of fragments (model collaborative edition).
To deal with those difficulties, ModelBus makes use of CVS to store models and to support
version control [52]. In fact, only the CVS protocol is used to transmit model files (files
representing models) between the so called model base and the so called model workspace.
The native CVS delta extraction and delta integration mechanisms (that are only adequate for
flat files) have been replaced by our own ones tailored to model files. The following sections
explain those mechanisms.
2.1.1. Model Encoding
In ModelBus, a model is partitioned into fragments. A model element belongs to only one
fragment. References between model element may cross fragments. If model elements could be
replicated in more than one fragments, then when the model element would be modified, all of
its copies, contained in other fragment, should be maintained consistent. Therefore, ModelBus
does not support model element to be replicated into several fragments in order to minimize
the impact of the modifications done on model elements.
ModelBus proposes to store fragments in model files. ModelBus is not prescriptive for the
number of model files needed to store a model. Models can be encoded either in a single model
file or in a set of model files. Moreover, as we will present it in the next section, model files can
be dynamically created at runtime and model elements can be moved between them. ModelBus
is based on the XMI format for encoding model elements into model files. According to XMI,
model elements are encoded as XML documents. Moreover, the following two characteristics
of XMI are relevant to deal with model files:
• Each model element is encoded by one XML element that has to own an XML attribute
named id, which represents the universal unique identifier of the model element.
• A link between two model elements is encoded by an XML reference. This reference
is expressed thanks to an XML attribute named href owned by the XML element
representing the source of the link. A link can be either an intra-link if the model element,
target of the link, is encoded in the same XML document than the source, or an extra-
link if it is encoded in a different XML document. For intra-links, the value of the href
attribute has to correspond to the id of the model element target of the link. In case of
extra-links, the value of the href attribute corresponds to the URI of the model file that
contains the model element target of the link, plus its id.
In a large software project, which involves a large set of models, models files identification
may become complex and hence the maintenance of external-links may be a real problem.
Model files have then to be organized in a hierarchical structure. ModelBus reuses the CVS
system’s functionalities for supporting such a hierarchical structure of model files.
Figure 2. How to store a model, which is a set of model elements
We call model URI, the unique identification of a model file from the root of the hierarchical
structure. A model URI starts with modelbus:// that corresponds to the root of the
hierarchical structure, and contains the relative path of the model file.
The figure 3 illustrates how ModelBus encodes the UML models into several model files. The
top part of the figure shows a UML class diagram and a sequence diagram. The bottom part of
the figure shows that this UML model is a graph composed of seven connected model elements.
It should be noted that the class diagram is a graphical visualization of the model elements 1,
2 and 3, which respectively represent the two classes and the operation. The sequence diagram
is a graphical visualization of the model elements 1, 2, 3, 4, 5, 6 and 7. The model elements 4
and 5 represent the two life lines, the model element 6 and 7 represent the two messages, the
model element 1, 2 and 3 are used in the sequence diagram as the classes are the types of the
life lines and as the operation is referenced by the message.
This model is partitioned into two fragments. The fragment 1 is stored in a model file
named module1.xml and the fragment 2 is stored in another model file (named module2.xml ).
Figure 3 partially presents the encoding of module2.xml. The type relationship between
the c1 and the Client classes is an extra-link. This link shows the use of model URI.
modelbus://project1/module1/model1.xml identifies the model file named model1.xmi
6 P. S.
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>

<xmi:XMI xmlns:uml=” h t t p : //www. e c l i p s e . o r g /uml2 / 2 . 0 . 0 /UML”
xmlns:xmi=” h t t p : //www. omg . o r g /XMI”>
<uml:Model name=” c l i e n t −s e r v e r ”
x m i : i d=” 7499 c c c c −43fd −4c24−a4ce −1f 2 c 7 1 b 7 2 2 2 2 ”>
<packagedElement name=” c1 ”
x m i : i d=” f 7 0 0 c 5 3 8 −5859−4239−8ca0−daa2a3639339 ”
x m i : t y p e=” u m l : L i f e L i n e ” />
<type h r e f=” m o d e l b a s e : // p r o j e c t 1 / module1 /
model1 . xmi#65 f d 0 a f 7 −c6a5 −4193− a0f0 −f 2 4 4 7 2 7 a c 2 e 1 ”
x m i : t y p e=” u m l : C l a s s ” />
</ packagedElement>
</ uml:Model>
</xmi:XMI>
Figure 3. Example of a model file encoded with the Modelbase XMI format
stored in directory project1/module1, which is relative to the root of the hierarchical

structure.
In ModelBus, model files are stored in the model bases as well as in the developers’ model
workspaces. Each developer imports in her/his model workspace, the model files that contain
model element he/she needs. Since model files are replicated in the model base and in the
model workspaces, the hierarchical structure is partially replicated in both the model base and
in the model workspaces. Resolutions of model URIs can be done either on the model base or
on any model workspace. If the resolution is done on a model workspace then the replica owned
by the model workspace is returned. If the model workspace does not own a replica for the
model URI, then the model file contained in the model base is returned.
The figure 4 illustrates two developers (Alice and Bob) that work on the model presented
in the figure 2. Alice works on the class diagram. Therefore, she has imported the fragment 1
(model1.xml). Bob works on the sequence diagram. Therefore, he has imported the fragment
1 and 2 (model1.xml and model2.xml). This example highlights the fact that, thanks to
ModelBus, developers can work on different model fragments.
2.1.2. Model collaborative edition
To deal with collaborative edition of models, ModelBus supports the copy-modify-merge

approach[58]. In this approach, a developer copies a some model fragments from the repository
to his/her workspace for editing it locally. Once he/she finishes editing, he/she merges this local
copy with the original copy located at the model base. Merging enables his/her modification to
be integrated with other concurrent modifications that have been made by other developers.
Figure 4. Two developers working on different fragments
The copy-modify-merge approach requires two main steps. The first step, delta extraction,
enables the extraction of the modification (or delta) made locally to a set of fragments. The
second step, delta integration, enables the integration of the delta with the fragments of the
model base. The delta integration must be aware of the conflicts between this delta and other
deltas that may have been integrated by other developers. These conflicts need to be solved
either manually or automatically by software merge tools.
The delta extraction mechanism for model files is based on a comparison of model files stored
in the developer’s workspace. This comparison takes as input two versions of a same set of
model files (the V initial version where no modification have been realized, and the V updated
version where modifications have been realized by the developer), and compares them thanks
to the identifiers of the model element they contain. For each model file, the comparison returns
a delta model, instance of the Delta meta-model, which specifies the updates that have been
done to the model (what are the model elements added to the model file, what are the model
elements that have been deleted, what are the new links, etc.).
The Delta Meta-model contains the following meta-classes (cf. Figure 5):
8 P. S.
• The Delta meta-class specifies the delta structure. A delta groups all the update
commands (see UpdateCommand meta-class) that have been realized to the model. A
delta is associated to one model file, identified by its path (modelPath meta-attribute)
whose value corresponds to the model URI of the model.
• The UpdateCommand meta-class is the super meta-class for all update commands.
An UpdateCommand always targets one model element, identified by its id
(contextElementID meta-attribute), and may specify its type (type meta-attribute).
• The Create meta-class specifies creation of model elements. The type of the created
model element is identified by the meta-attribute type (see meta-class UpdateCommand).
• The Delete meta-class specifies deletion of model elements.
• The MoveIn and MoveOut meta-classes specify moving of a model elements (from a model
file to another one). Such updates are realized by developers who want to manage the
size of their model files. It should be noted that for each MoveIn (respectively MoveOut)
update command realized on a model file, there is a corresponding MoveOut (respectively
MoveIn) update command realized on another model file. For instance, if a model element
e1 is moved from model file model1.xml to model2.xml, then there is a MoveOut update
command for e1 regarding model1.xml and a MoveIn update command for e1 regarding
model2.xml. MoveIn update command specifies the source model of the moving (meta-
attribute originModelPath). MoveOut update command specifies the target model of
the moving (meta-attribute targetModelPath).
• The ModifyPrimitiveAtt meta-class specifies a change done on an attribute of a model
element. The attribute is identified by its name (meta-attribute attribute). The change
replaces the old value of the attribute by a new value that may be the empty value (meta-
attribute newValue).
• The InsertLink and RemoveLink meta-classes specify changes done a reference of a
model element. The reference is identified by its name (meta-attribute attribute). Link
inserted or removed are identified by the id of the model element target of the link (cf.
meta-class Link).
The comparison mechanism of ModelBus is based on model element ids as the Ohst’s
and Mehra’s ones [39, 34]. The goal is to identify model elements that have been created in
V updated, ones that have been deleted from V initial, ones that have been moved in the model
files, and ones that have been modified. The following rules apply to create the returned delta:
• A Create update command is generated if a model element exists in V updated but not
in V initial. This update command is added to the Delta that targets the model file that
contains the created model element.
• A Delete update command is generated if a model element exists in V initial, but not
in the V updated. This update command is added to the Delta that targets the model
file that contained the model element.
• A MoveOut and a MoveIn update commands are generated if a model element exists in
both V initial and V updated but when the model element is encoded in two different
model files. The MoveIn update command is added to the Delta that targets the model
file of V updated that contains the model element. The MoveOut update command is
Figure 5. The ModelBus Delta MetaModel
added to the Delta that targets the model file of V initial that contained the model
element.
• A ModifyPrimitiveAtt update command is generated if one property’s value of a model
element is not the same in V updated and in V initial. This update command is added
to the Delta that targets the model file that contains the model element.
• A InsertLink or a RemoveLink update command is generated if a link has been inserted
or removed in V updated whereas it existed in V initial. This update command is added
to the Delta that targets the model file that contains the model element source of the
link.
Before integrating the calculated delta with the model base, conflicts that might occur has
to be detected and handled, which is the goal of the delta integration mechanism. The delta
integration mechanism of ModelBus focuses on the identification of lost updates and dangling
links. A lost update occurs when updates done by a developer cancel updates done by another
one. A lost update occurs when updates done by a developer delete a model element that is
still used by the updates done by another one.
Conflicts might arise when a developer wants to integrate his/her delta (workspaceDelta)
with the model base but when modifications done by another developer have been already
integrated. In such a situation, the model base provide to the developer the integrated delta
(baseDelta). The developer has to compare his/her workspaceDelta with the baseDelta in
order to identify potential conflicts. The ModelBus delta integration mechanism then compares
two deltas and applies the following rules:
10 P. S.
• if a delta contains one of these update commands (ModifyPrimitiveAtt, InsertLink

or RemoveLink) that targets a model element, and if the other delta contains a Delete
update command that targets the same model element, then a lost update identification
is raised as those update commands cannot be automatically combined. If the Delete
update command is executed, it cancels the other update commands.
• if a delta contains a InsertLink update command, and if the other delta contains a
RemoveLink update command that targets the same model element, then a lost update
identification is raised as those update commands cannot be automatically combined.
If the RemoveLink update command is executed, it cancels the InsertLink update
commands.
• if in the two deltas, there are ModifyPrimitiveAtt update commands that target the
same model element and its same property, then a lost update identification is raised as
those update commands cannot be automatically combined. Only one can be executed.
• if in the two deltas, there are InsertLink update commands that target the same model
element and its same reference, then a lost update identification is raised as those update
commands cannot be automatically combined. Depending on the order of realizing those
updates, the list of inserted references won’t be the same.
When lost update conflicts are raised, the developer who has realized the is notified. He/she
then has to deal with those conflicts in order to integrate his/her modifications within the
model base. Classically, he/she either forces his/her updates to be integrated within the model
even if modifications cancel modifications made by other developers, or he/she updates his/her
modifications in order to make them compliant with other developers’ changes.
The following scenario highlights the delta extraction and delta integration mechanisms:
1. Alice locally removes the class named Client and she changes the name of the operation
from runService() to execService().
2. Alice uses the delta extraction mechanism. This mechanism computes a delta that target
the model file model1.xml and that is composed of a Delete and a ModifyPrimitiveAtt.
3. Alice wants to integrate her delta with the base. As the model files stored in the base are
the same as the ones initially stored in the Alice’s workspace. The delta is automatically
integrated.
4. Bob wants to locally change the name of the LifeLine from c1 to c.
5. Bob uses the delta extraction mechanism. This mechanism computes a delta that target
the model file model2.xml and that is composed of a ModifyPrimitiveAtt.
6. Bob wants to integrate his delta with the base. As the model file model1.xml has been
changed, the base return to Bob the delta of Alice, which has been integrated.
7. Bob uses the delta integration mechanism. This mechanism computes one conflict as the
class named Client has been removed but is still referenced by the life line.
8. Bob decides to change the type of the life line and to declare it to be undefined. He can
now integrate his delta in the base.
2.2. Control Integration
As it is described in the section ??, the main requirements for control integration are
the specification of modeling services and the definition of mechanisms that support their
distributed calls. Regarding the specification of modeling services, the key issue is related to
the input and output parameters of the modeling services. The specification has to define
which are the model elements that have to be sent as input; and which model elements will
be returned. Without such a fine grain specification, several model manipulations such as in-
place model transformation [46] and model refactoring [59], that require the ability to modify
some of the model elements, could not be considered to be modeling service. Regarding the
distributed calls, the key issue is related to the marshaling of the model and the handling of
the model references. References that exist between the model elements that are sent and the
ones that are not may result in dangling links after the modeling service send back its result.
The figure 6 highlights those difficulties on the example that was presented in the figure 2.
We consider that a developer wants to use a modeling service that operates on UML classes.
In order to send only useful model elements when calling this modeling service, a specification
has to define which of the model elements are mandatory for the modeling service. In this
example, we consider that the model elements 1 and 2 are mandatory but not the model
element 3. This model element may be requested later by the modeling service, if needed. Now
this useful information is identified, it has to be marshaled in order to be transmitted to the
modeling services. As the modeling service may take time and may return modified model
elements (remove model element 2 for instance), the mechanism has to handle the links that
exist between the model elements 1 and 2 and the others.
To deal with those issues, ModelBus decomposes control integration in two levels: the
modeling service identification level and the modeling service access level.
• At the service identification level, ModelBus provides a language for describing modeling
services. This language is defined as a meta-model called Modeling Service Description
Meta-model. This meta-model defines modeling services as operations having input
and output parameters. In particular, it addresses the issue of the input and output
parameters types.
• At the service access level, ModelBus provides a set of technologies that help tool provider
to plug their tools in ModelBus. Those technologies are based on a classical broker
architecture and make use of existing middleware such as WebServices. They hide the
heterogeneity of tools and manage models marshaling.
2.2.1. Modeling Service Description Meta-model
Any tool that provides its modeling services through ModelBus has to be described by a model
instance of the Modeling Service Description Meta-model. Such a model specifies the services
provided by the tool. In particular, it specifies the model types of the services’ inputs and the
outputs.
The figure 7 presents the The Modeling Service Description Meta-model. The Tool meta-class
is the root meta-class of this meta-model and represents the tool, subject of the description.
12 P. S.
Figure 6. How to store a model, which is a set of model elements
The ModelingInterface meta-class represents a modeling interface of the tool that groups
modeling services provided by the tool. A tool can provide several modeling interfaces. Each
modeling interface has to have a unique name within a tool. The ModelingService meta-class
represents a modeling service provided by the tool. Each modeling service has to be owned by
a modeling interface and has to have a unique name in it. Modeling services have parameters
(meta-class Parameter) and may throw exception (meta-class Exception). Parameters and
exceptions have a type (meta-class Type). A type can be either a primitive type (meta-class
PrimitiveType) or model type (meta-class ModelType).
A model type is specified by a content type (meta-class ModelContentType) that identifies
mandatory meta-classes (meta-class Class belongs to the MOF meta-model). For each
mandatory meta-class of a model type, the model has to contain at least one model element
typed by this meta-class. If no element of this type is contained in the model, the model is
not conform to its model type. Regarding our example, the UML Class Diagram content type
specifies that only the Class meta-classes is mandatory. Therefore, a model will be conform
to a model type specified by this content type, only if it contains at least one UML class.
A model that contains classes and operation is also conform to this type but a model that
Figure 7. The Modeling Service Description Meta-model
contains packages without classes is not. It should be noted that our definition of model type
is compliant with the one proposed by Jim Steel is his PhD thesis [55]. The Steel’s definition
also contains mandatory meta-classes.
2.2.2. ModelBus adapter
Each modeling tool that is plugged to ModelBus is directly connected to one adapter, called its
dedicated adapter. Adapters are classical proxies of the broker architecture [19]. Therefore,
they play (1) a client role when their connected tool wants to consume a modeling service
provided by another tool; and (2) a server role when their connected tool provides modeling
services that are consumed by other tools.
When an adapter connected to a tool plays the client role, the following activity is followed:
1. The tool asks to its dedicated adapter to consume a modeling service.

2. The adapter receives the call from its connected tool. This call is a local call. It contains
the identification of the modeling service that has to be called and pointers to the models
that need to be sent as actual parameters.
3. Thanks to the identification of the modeling service, the adapter localizes the server
tool that provides the modeling service. If the server tool cannot be localized (it may be
down), then the adapter throws an exception to its connected tool.
4. If the server tool is localized, the adapter marshals the models in order to prepare their
sending.
14 P. S.
5. The adapter then sends a message to the server tool. This message contains the name of
the service and the marshaled models.
6. It then waits for the answer of the server tool.
7. When it receives the answer, it un-marshals the models and replaces them in the tool
memory. A dedicated mechanism prevents dangling links.
When an adapter connected to a tool plays the server role, the following activity is followed:
1. As soon as the tool starts, its connected adapter runs and waits for incoming requests.
2. When the adapter receives a request, it opens the containing message and verifies that
identified modeling services corresponds to one of the modeling services provided by the
tool. If the verification fails, the adapter throws an exception.
3. If the identified modeling service is provided by the tool, the adapter un-marshals the
models contained in the message and verifies their types. If their types are not compliant
with the types of the modeling service formal parameters, it throws an exception.
4. If the un-marshaled models are compliant, the adapter stores them into the runtime
memory.
5. The adapter then makes a local call to its connected tool for consuming the provided
modeling services. Un-marshaled models are passed by reference.
6. The tool realizes the modeling service. When it has finished, it notifies the adapter.
7. The adapter marshals the models to return in output.
8. It then creates the return message and sends it back to the client tool.
This adapter architecture makes use of a single registry that binds modeling services to
provider tools. Each time a tool that provides modeling service starts and is plugged to
ModelBus, its dedicated adapter notifies the registry that its modeling services are available.
Each time the tool stops, its dedicated adapter notifies the registry that the modeling services
are not available. The registry then stores an optimistic global vision of available modeling
services. This registry is not tolerant of tool faults.
Regarding the marshaling of models and their transmission, ModelBus is based on call-by-
copy-restore semantic, which is very close to the semantic of the local procedure call. The copy-
restore mechanism of most RPC systems classically transmits a deep copy of parameter values:
the objects that a programmer specifies as parameters and all objects reachable from them
are copied. In our context, parameters are models, which are graph data structures containing
model elements and links between them. Hence, applying this deep-copy mechanism to a
model will result in transmitting the entire model graph, which is inappropriate for reasons
of performance and of access control. Therefore, we use the specification of the modeling
service in order to marshal and to transmit only mandatory model elements. Moreover, as
our concept of mandatory element is only based on a static type system, the marshaling
mechanism only considers mandatory model elements that are directly or indirectly targeted
by the pointers given by the tool to its adapter. This pointer is called an access point in the
ModelBus terminology.
The marshaling mechanism is therefore different from one used by existing RPC systems
as it deals with an incomplete graph transmission. Only the mandatory elements that are
targeted by the access point are serialized and the other elements are not serialized, even if
they are linked with the first ones. Marshaling a model element consists in writing its properties
values. These values are either primitive data or references to other elements. Contrary to the
complete model marshaling mechanism, which serializes all the property values, the model
fragment marshaling mechanism must avoid marshaling the references to elements outside the
scope (i.e. outbound links), because those references will become dangling when transmitted
to the other side.
Like the CORBA INOUT mode, ModelBus supports the modeling service to modify the
input model elements. The modeling service can therefore add/ remove model elements to/from
the scope. Adding elements to the scope enables the service to transmit back the new elements
that do not exist on the caller side. Removing elements from the scope will result in deleting
those elements on the caller side and to delete all dangling links.
2.3. Validation
Section 2.1 has presented how ModelBus allows the Data integration aspect. To that concern,
ModelBus proposes to share model elements that compose a model into fragments. Fragments
are stored into model files that are managed by a version control system. In order to support
specific needs of collaborative edition of models, ModelBus proposes its own mechanisms for
Delta extraction and Delta integration. Those contributions have been validated in [52].
Section 2.2 has presented how ModelBus addresses the Control integration aspect. To that
concern, ModelBus proposes a language for specifying modeling services and a mechanism that
supports the call-by-copy-restore paradigm. Those contributions have been validated in [53, 51].
It should be noted that a stress test has been realized in order to measure the performance of
ModelBus[51]
Moreover, it should be noted that ModelBus has been defined and prototyped in two
European IP projects, named ModelWare and Modelplex. In those projects, ModelBus has
been used to integrate more than ten industrial tools. In particular, during the finale review
of the Modelware project, ModelBus has been used to connect CASE tools. In Modelplex, at
the beginning of the project ModelBus was selected as the basic platform for integration.
3. Related Work Section
The use of Object-Oriented Database (OODB) systems for managing model storage and their
collaborative edition has been proposed in [45, 48]. Model elements are considered to be
objects managed by an OODB system. Modeling tools behave as client programs that use the
OODB system. This approach suffers of the following drawbacks. First, all modeling tools have
to be connected to the OODB. The cost of this integration can be up to 30% of the cost of the
modeling tool [61]. Second, as the OODB proposes its own model representation and as the
modeling tools may have their own internal one, modeling tool programmers would have to
face the impedance mismatch problem when aligning those two representations [6]. Third, the
facilities offered by OODB to support collaborative edition are not really adapted to model
edition as OODB forbids models to be temporarily inconsistent whereas it happens frequently
during the software life cycle [4].
16 P. S.
The use of file version control systems, such as CVS or Subversion, has also been considered
to address model storage and collaborative edition [8, 15, 34]. This approach consists in
encoding models into files in order to benefit from the version control systems. The first
drawback of this approach is to not provide any support to encode models into several files.
Without this support, modeling tools cannot scale up as they cannot manage the storage of
huge models with many inter-model links. The second drawback is the lack of delta extraction
and delta integration mechanisms for models, which are the key mechanisms needed to prevent
conflict during collaborative edition.
In [28], Karsai and al. present the MIC (Model Integration Computing), a MDSEE that
only addresses the Data integration aspect via model transformations. The MIC architecture
is based on several repositories of models. The consistency between those repositories is realized
thanks to automated model transformations. The MIC approach therefore only supports the
huge models and the multi-views data integration requirements.
In [20], Didonet Del Fabro and al. present a MDSEE that only addresses the Data integration
aspect via model transformations. The main advantage of this approach in comparison with
the MIC framework, is that it partially supports bi-directional model transformation. The
Didonet Del Fabro’s approach therefore only supports the huge models and the multi-views
data integration requirements.
In [18], Denton and al. present NAOMI that is an experimental platform for multi-model
integration. Thanks to NAOMI, developers can collaboratively edit models of different natures.
The NAOMI architecture is based on a central model repository that stores all models and that
supports version control. Developers then use their local tool and commit from time to time
their changes to the repository. As a consequence, NAOMI is a MDSEE that only targets the
Data integration aspect and does not support the two others. The NAOMI approach therefore
only supports the huge models, the model distributivity and the multi-views data integration
requirements.
In [5], Barbero and al. present a vision to design a MDSEE. This vision is based on the
notion of Mega model that links together all models edited by developers during the life-cycle
of a software project. This notion of Mega model is comparable to the notion of an intellectual
central model repository. It should be noted that this vision does not address the control
integration.
Regarding the definition level, the majority of MDE approaches that deal with tool
integration pay a little attention on how to precisely describe modeling services [37, 28, 26, 25].
They propose to describe modeling services as functions that inputs and outputs models.
Therefore, modeling services that need a thin type granularity (for example a modeling service
that takes as input a class diagram rather than a full UML model) cannot be described.
Moreover, modeling services that modify the input model (for example model refactoring)
cannot be described.
Regarding the invocation level, the majority of MDE approaches propose an architecture
based on distributed objects. The main principle is to represent model elements by distributed
objects that provide operations corresponding to modeling services [16, 29]. With such an
architecture, any tool can make a distributed call either to browse a model or to ask for
the realization of a modeling service. The two main drawbacks of this architecture are the
excessively thin granularity (all the elements of a model are distributed objects, even ones
that do not provide modeling services) and the poor performance (each time a tool has to
browse a model or to consume a modeling service, it has to perform a distributed call).
4. Conclusion
In [62], Wicks and Deware present a review and an analysis of the literature relevant to
MDSEE. They point out that there are few descriptive papers and conclude that many
contributions probably do not really target true problems of the field. We think this is debatable
since, from our point of view, the field of MDSEE is driven by industrials. In the two IP projects
we participated in (Modelware and Modelplex), industrials presented their issues and worked
closely with academics in order to solve them. However, Wicks and Deware make a valid point
when they say that there are few descriptive papers. Indeed, all requirements presented by
industrial are stored into private database that are only accessible to the project’s partners.
ModelBus addresses all requirements that have been raised in the domain of MDSEE
regarding data integration and control integration[53, 51, 52, 54]. It reuses mechanisms provided
by version control systems and middleware and adapts them for models. Version control
systems have been adapted to deal with model fragments. Middleware have been adapter
to support modeling service calls.
ModelBus has been validated in two european IP project (ModelWare and Modelplex).
Thanks to this ModelBus experience, we can claim that model repositories are mandatory in all
MDSEEs. Without such repositories, there would be no solution to store and to collaboratively
access models. On the contrary, from the Modelware and the Modelplex experiences, we have to
admit that the RPC layer tailored to modeling service may not be usefull for MDSEEs. On the
one hand, it is still very difficult to define stable modeling services that fit every developers’
need; in the other hand, it seems (but this has to be verified by an empirical study) that
nowadays developers prefer to use modeling services that run locally rather than remotely.
ModelBus is now an industrial product[1]. It provides services that are needed to deal with
the process integration aspect, which is the domain of our current research.
REFERENCES
1. Modelbus project, http://www.modelbus.org/modelbus/.

2. Nato software engineering conference. 1968.
3. Marcus Alanen and Ivan Porres. A metamodeling language supporting subset and union properties.
Software and System Modeling, 7(1):103–124, 2008.
4. R. Balzer. Tolerating inconsistency. Proc. Int’ Conf. Software engineering (ICSE ’91), 1:158–165, 1991.
5. Mikaël Barbero, Frédéric Jouault, and Jean Bézivin. Model driven management of complex systems:
Implementing the macroscopes vision. In 15th Annual IEEE International Conference and Workshop on
Engineering of Computer Based Systems (ECBS 2008), pages 277–286, 2008.
6. Maria L. Barja, Norman W. Paton, Alvaro A. A. Fernandes, M. Howard Williams, and Andrew Dinn. An
effective deductive object-oriented database through language integration. In Proc. Int’l Conf. Very Large
Data Bases (VLDB ’94), pages 463–474, San Francisco, CA, USA, 1994. Morgan Kaufmann Publishers
Inc.
7. Noureddine Belkhatir, Jacky Estublier, and Walcélio L. Melo. Software process model and work space
control in the adele system. In Proceedings of the Second International Conference on the Software Process
(ICSP), Berlin, Germany, February 25-26, 1993., pages 2–11, 1993.
18 P. S.
8. Brian Berliner, Prisma Inc, and Mark Dabling Blvd. Cvs ii: Parallelizing software development, 1990.
9. Jean Bézivin. From object composition to model transformation with the mda. In TOOLS USA 2001:
Software Technologies for the Age of the Internet, 39th International Conference & Exhibition, Santa
Barbara, CA, USA, July 29 - August 3, 2001, pages 350–354, 2001.
10. Xavier Blanc, Marie-Pierre Gervais, and Prawee Sriplakich. Model bus: Towards the interoperability of
modelling tools. In MDAFA, volume 3599 of Lecture Notes in Computer Science, pages 17–32. Springer,
2004.
11. Bruce Blum. Understanding the software paradox. SIGSOFT Softw. Eng. Notes, 10(1):43–46, 1985.
12. Gerard Boudier, Ferdinando Gallo, Regis Minot, and Ian Thomas. An overview of PCTE and PCTE+.
SIGSOFT Softw. Eng. Notes, 13(5):248–257, 1988.
13. Aaron G. Cass and Leon Osterweil. Process support to help novices design software faster and better. In
Proc. Int’l Conf. Automated software engineering (ASE ’05), pages 295–299, New York, NY, USA, 2005.
ACM.
14. Tony Clark, Andy Evans, and Stuart Kent. The metamodelling language calculus: Foundation semantics
for UML. In FASE, volume 2029 of Lecture Notes in Computer Science, pages 17–31. Springer, April
2001.
15. Ben Collins-Sussman. The subversion project: buiding a better cvs. Linux J., 2002(94):3, 2002.
16. Stephen Crawley, S. Davies, Jadwiga Indulska, S. McBride, and Kerry Raymond. Meta-meta is better-
better! In Distributed Applications and Interoperable Systems, Proceedings IFIP TC 6.1 Working
Conference DAIS’97, Cottbus, Germany, September 30 - October 2, 1997, 1997.
17. Krzysztof Czarnecki and Simon Helsen. Classification of model transformation approaches, 2003.
18. Trip Denton, Edward Jones, Srini Srinivasan, Ken Owens, and Richard W. Buskens. Naomi - an
experimental platform for multi-modeling. In Model Driven Engineering Languages and Systems, 11th
International Conference, MoDELS 2008, pages 143–157, 2008.
19. H. Rohnert P. Sommerlad M. Stal F. Buschmann, R. Meunier. Pattern-Oriented Software Architecture,
Volume 1, A System of Patterns. Wiley, 1996.
20. Marcos Didonet Del Fabro, Jean Bézivin, and Patrick Valduriez. Model-driven tool interoperability: An
application in bug tracking. In On the Move to Meaningful Internet Systems 2006: CoopIS, DOA, GADA,
and ODBASE, OTM Confederated International Conferences, CoopIS, DOA, GADA, and ODBASE,
pages 863–881, 2006.
21. Stuart I. Feldman. Make — a program for maintaining computer programs. Software Practice and
Experience, vol. 9, no. 4:255–265, 1979.
22. P. Fradet, D. Le Metayer, and M. Peiin. Consistency checking for multiple view software architectures.
In Proc. Joint Conf. ESEC/FSE’99, volume 41, pages 410–428. Springer, September 1999.
23. Steven Fraser, Frederick P. Brooks Jr., Martin Fowler, Ricardo Lopez, Aki Namioka, Linda M. Northrop,
David Lorge Parnas, and Dave A. Thomas. ”no silver bullet” reloaded: retrospective on ”essence and
accidents of software engineering”. In Companion to the 22nd Annual ACM SIGPLAN Conference on
Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2007, October 21-25,
2007, Montreal, Quebec, Canada, pages 1026–1030, 2007.
24. Alfonso Fuggetta. Software process: a roadmap. In ICSE - Future of SE Track, pages 25–34, 2000.
25. Erica Glynn, Ian Hayes, and Anthony MacDonald. Integration of generic program analysis tools into
a software development environment. In ACSC ’05: Proceedings of the Twenty-eighth Australasian
conference on Computer Science, pages 249–257, Darlinghurst, Australia, Australia, 2005. Australian
Computer Society, Inc.
26. Zonghua Gu, Shige Wang, Sharath Kodase, and Kang G. Shin. An end-to-end tool chain for multi-
view modeling and analysis of avionics mission computing software. In RTSS ’03: Proceedings of the
24th IEEE International Real-Time Systems Symposium, page 78, Washington, DC, USA, 2003. IEEE
Computer Society.
27. Frederick P. Brooks Jr. The mythical man-month: After 20 years. IEEE Software, 12(5):57–60, 1995.
28. Gabor Karsai, Janos Sztipanovits, Akos Ledeczi, and Ted Bapty. Model-integrated development of
embedded software. In Proceedings of the IEEE, pages 145–164, 2003.
29. Olaf Kath, Michael Soden, Marc Born, Tom Ritter, Andrei Blazarenas, Motohisa Funabashi, and Chiaki
Hirai. An open modeling infrastructure integrating edoc and ccm. In 7th International Enterprise
Distributed Object Computing Conference (EDOC 2003), 16-19 September 2003, Brisbane, Australia,
Proceedings, pages 198–207, 2003.
30. Thomas Kühne. Matters of (meta-) modeling. Software and System Modeling, 5:369–385, 2006.
31. Diego Latella, István Majzik, and Mieke Massink. Automatic verification of a behavioural subset of uml
statechart diagrams using the spin model-checker. Formal Asp. Comput., 11(6):637–664, 1999.
32. Mm Lehman. Laws of software evolution revisited. In Lecture Notes in Computer Science, pages 108–124.
Springer, 1996.
33. Johan Lilius and Ivan Paltor. vuml: A tool for verifying uml models. In 14th IEEE International
Conference on Automated Software Engineering (ASE’99), 12-15 October 1999, Cocoa Beach, Florida,
USA, Proceedings. IEEE Computer Society, 1999, pages 255–258, 1999.
34. Akhil Mehra, John Grundy, and John Hosking. A generic approach to supporting diagram differencing
and merging for collaborative design. In Proc. Int’l Conf. Automated software engineering (ASE ’05),
pages 204–213, New York, NY, USA, 2005. ACM.
35. Stephen J. Mellor, Anthony N. Clark, and Takao Futagami. Guest editors’ introduction: Model-driven
development. IEEE Software, 20(5):14–18, 2003.
36. J. Miller and J. Mukerji. Mda guide version 1.0.1. Technical report, Object Management Group (OMG),
2003.
37. Wolfgang Mueller, Tim Schattkowsky, Heinz-Josef Eikerling, and Jan Wegner. Dynamic tool integration
in heterogeneous computer networks. In DATE ’03: Proceedings of the conference on Design, Automation
and Test in Europe, page 10946, Washington, DC, USA, 2003. IEEE Computer Society.
38. Bruce Jay Nelson. Remote procedure call. PhD thesis, Pittsburgh, PA, USA, 1981.
39. Dirk Ohst, Michael Welle, and Udo Kelter. Differences between versions of UML diagrams. In Proc.
European Software Engineering Conf. held jointly with Int’l Symp. Foundations of Software Engineering
(ESEC/FSE-11), pages 227–236, New York, NY, USA, 2003. ACM.
40. OMG. Meta Object Facility (MOF) 2.0 Core Specification, January 2006.
41. OMG. MOF 2.0/XMI Mapping, Version 2.1.1, December 2007.
42. Harold Ossher, William Harrison, and Peri Tarr. Software engineering tools and environments: a roadmap.
In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering, pages 261–277, New
York, NY, USA, 2000. ACM.
43. Leon Osterweil. Software processes are software too. In Proc. Int’l Conf. Software Engineering (ICSE
’87), pages 2–13, Los Alamitos, CA, USA, 1987. IEEE Computer Society Press.
44. Leon Osterweil. Software processes are software too, revisited: an invited talk on the most influential
paper of icse 9. In Proc. Int’l Conf. Software Engineering (ICSE ’97), pages 540–548, New York, NY,
USA, 1997. ACM.
45. Chabane Oussalah and Christelle Urtado. Complex object versioning. In Proc. Int’l Conf. Advanced
Information Systems Engineering (CAiSE ’97), pages 259–272. Springer, 1997.
46. Ivan Porres, Turku Centre, and Computer Science. Model refactorings as rule-based update
transformations. In In Proceedings of UML 2003 Conference, Springer-Verlag LNCS 2863, pages 159–174.
Springer, 2003.
47. Steven P. Reiss. Connecting tools using message passing in the field environment. IEEE Software,
7(4):57–66, 1990.
48. Jungkyu Rho and Chisu Wu. An efficient version model of software diagrams. In Proc. Asia Pacific
Software Engineering Conference (APSEC ’98), page 236, Washington, DC, USA, 1998. IEEE Computer
Society.
49. Douglas C. Schmidt. Guest editor’s introduction: Model-driven engineering. IEEE Computer, 39(2):25–
31, 2006.
50. Bran Selic. The pragmatics of model-driven development. IEEE Software, 20(5):19–25, 2003.
51. Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Applying model fragment copy-restore to
build an open and distributed mda environment. In MoDELS, volume 4199 of Lecture Notes in Computer
Science, pages 631–645. Springer, October 2006.
52. Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Supporting collaborative development in an
open mda environment. In ICSM, pages 244–253. IEEE Computer Society, September 2006.
53. Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Supporting transparent model update in
distributed case tool integration. In SAC, pages 1759–1766. ACM, April 2006.
54. Prawee Sriplakich, Xavier Blanc, and Marie-Pierre Gervais. Collaborative software engineering on large-
scale models: requirements and experience in modelbus. In SAC, pages 674–681. ACM, March 2008.
55. Jim Steel and Jean-Marc Jézéquel. On model typing. Software and System Modeling, 6(4):401–413, 2007.
56. Gerson Sunyé, Alain Le Guennec, and Jean-Marc Jézéquel. Using uml action semantics for model execution
and transformation. Inf. Syst., 27(6):445–457, 2002.
57. Richard N. Taylor, Frank C. Belz, Lori A. Clarke, Leon Osterweil, Richard W. Selby, Jack C. Wileden,
Alexander L. Wolf, and Michael Young. Foundations for the arcadia environment architecture. In SDE
3: Proceedings of the third ACM SIGSOFT/SIGPLAN software engineering symposium on Practical
software development environments, pages 1–13, New York, NY, USA, 1988. ACM.
20 P. S.
58. Walter F. Tichy. Rcs—a system for version control. Softw. Pract. Exper., 15(7):637–654, 1985.
59. Lance Tokuda and Don Batory. Evolving object-oriented designs with refactorings. Automated Software
Engg., 8(1):89–120, 2001.
60. Anthony I. Wasserman. Tool integration in software engineering environments. In Proc. Int’l workshop
on environments on Software engineering environments, pages 137–149. Springer, 1990.
61. David L. Wells, José A. Blakeley, and Craig W. Thompson. Architecture of an open object-oriented
database management system. Computer, 25(10):74–82, 1992.
62. M. N. Wicks and R. G. Dewar. Controversy corner: A new research agenda for tool integration. J. Syst.
Softw., 80(9):1569–1585, 2007.
63. Mike Wicks. Tool integration in software engineering: The state of the art in 2004. Technical report,
2004.

Model Driven Software Engineering Environments: Requirements and Experiences

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Model Driven Software Engineering Environments: Requirements and Experiences

Загружено:

Авторское право:

Доступные форматы

Model Driven Software

key words: Model Driven, Software Engineering Environment, ModelBus

be connected or not. In such a context, facilities should be provided to developer to store,

2.1. Data Integration

2.1.1. Model Encoding

Figure 2. How to store a model, which is a set of model elements

<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>

stored in directory project1/module1, which is relative to the root of the hierarchical

2.1.2. Model collaborative edition

To deal with collaborative edition of models, ModelBus supports the copy-modify-merge

Figure 4. Two developers working on different fragments

Figure 5. The ModelBus Delta MetaModel

• if a delta contains one of these update commands (ModifyPrimitiveAtt, InsertLink

2.2. Control Integration

2.2.1. Modeling Service Description Meta-model

Figure 6. How to store a model, which is a set of model elements

Figure 7. The Modeling Service Description Meta-model

2.2.2. ModelBus adapter

1. The tool asks to its dedicated adapter to consume a modeling service.

3. Related Work Section

1. Modelbus project, http://www.modelbus.org/modelbus/.

Вам также может понравиться