Managing Model Evolution Using the CCBM (2)
Final version published in Proceedings of 15th International Conference and Workshops on
Engineering of Computer Based Systems (ECBS 2008), pages 453-462. IEEE Computer Society,
April 2008.
Managing Model Evolution Using the CCBM Approach
Audrey Occello, Anne-Marie Dery-Pinna, Michel Riveill
University of Nice-Sophia Antipolis, France
occello, pinna, riveill@polytech.unice.fr
Abstract
With the adoption of MDE, application evolution is facilitated. Instead of modifying each deployed version, the application is modified only once at the model level and then
regenerated for each platform. On the other hand, to manage application complexity, models are partitioned and then
integrated together to form larger ones. However most of
modeling approaches use an integration mechanism based
on merging existing models that makes it difficult to manage
application evolution in a modular and incremental way.
As an alternative, we propose the Collaborative Component Based Model approach (CCBM) that leverages software components principles and focuses on the specification of how models collaborate with each other. This paper presents how the proposed approach contributes to integrate and manage change of models incrementally by preserving defined collaborations during the whole life-cycle of
an application, from initial, very loosely specified interactions, through step-wise refinements, to the final concretization to a component implementation.
Keywords. MDE, model integration, model evolution,
CBSE.
1. Introduction
Most of the time, industrial products are not built from
scratch but implemented by evolution of existing ones.
When the application is deployed on several middleware
platforms, the difficulty is then to maintain each deployed
versions. With the adoption of MDE, application evolution
is facilitated. Instead of modifying each deployed version,
the application is modified only once at the model level and
then regenerated for each platform. On the other hand, the
complexity of modern applications is mirrored by the complexity of their models. Therefore separation of concerns
need to be leveraged to the model level. The idea of partitioning models and integrating them to form larger ones
is not new and is the core of most of the composition ap-
Günter Kniesel
University of Bonn, Germany
[email protected]
proaches [4] such as in Aspect Oriented Modeling (AOM)
[1] and in Subject Oriented Design (SOD) [8].
Unfortunately, these approaches propose an integration
mechanism based on merging existing models that is not always adequate for some specific model evolutions. First,
the integration with legacy code is impossible if this code
has not been generated from a model. Secondly, if we want
to add, remove or replace a model in the resulting application, we must 1) go back at the design stage and 2) be
capable of having all the input models not only the merged
one so as to define the new composition to be concretized.
Evolution of an application built from merged models implies producing again the entire application from a new set
of model merging. Integration of models through merging
is therefore not an incremental and modular process.
Our goal is to provide a new approach of model integration that makes model evolution easier. For this, we propose
to leverage principles of software components [32] so as
to provide an alternative way to manage model integration
and evolution. The Collaborative Component Based Model
approach (CCBM) achieves black-box reuse of unmodified
models and preserves them. Thus, in CCBM, models are
units of reuse and integration is modular and incremental,
just as for software components in Component Based Software Engineering (CBSE) [15]. This paper presents how
the proposed approach enables the specification of model
collaboration and explains how it takes into account the different steps of the MDE development life-cycle by preserving loose coupling and easy evolvability from the modeling
to the system implementation.
The remainder of this paper is organized as follows.
Section 2 explains the principles of the CCBM approach
as a way to build models by bridging smaller ones and
introduces a case study. Section 3 describes how to specify
model collaboration on the case study and section 4, how
to concretize models and their collaborations as pieces of
software. Finally, section 5 summarizes the benefits and
limitations of our work and presents related work.
2. Overview of the CCBM Approach
The core principle of the CCBM approach is the incremental, structure-preserving integration of models by expressing collaborations between them. Model integration is
specified as a family of control flows that cross the unmodified input models. Every model specifies requirements that
other models must fulfill in order to participate in a collaboration. Hence, the result of the integration is simply a set
of models that, taken together, fulfill all the requirements
stated by any of them. This section introduces the vocabulary of the CCBM approach and the case study that is used
in this paper to explain the approach.
Collaborative model
requires
Collaboration
template
Collaboration
template
Collaboration
template
requires
requires
Model template
constrained by
Collaborative
Collaborative
operation
operation
Collaborative
operation
extended by
Non−Collaborative part
of the model
Figure 1. CCBM concept relationships.
As in other modeling approaches such as UML [34], a
model contains classes that are characterized by attributes
and operations. In addition, in the CCBM approach, a
model is said to be a collaborative model if it contains at
least one collaborative operation. Collaborative operations
are the operations that rely on operations of others models to accomplish a task. The specification of a collaborative operation is a special version of collaboration diagrams
(see Figures 6 and 7) that we refer as collaboration templates . Collaboration templates define implicit constraints
that models must fulfill in order to be chosen as collaboration partners. The sum of these constraints outlines a set of
generic model specifications that we call model templates.
Model templates are generic in the sense that they do not
represent individual models but any models that fulfill the
constraints. Collaboration templates are generic in the sense
that they do not refer directly to specific models, types or
operations but use variables whose values are provided later.
A collaborative model
can be refined by adding more
details about collaborations with others models in collaboration templates. Refinement of
can be specified incrementally in another model by: 1) adding collaborative operations and collaboration templates to the refining model
(model extension), 2) completing the collaboration templates by specifying precisely the called methods, not just
their containing model or type (operation specialization),
or 3) performing any combination of the above.
Models can be incrementally refined by stating more
complete collaboration requirements: each refinement adds
new model templates that are more specific in the sense that
they either provide additional collaboration opportunities or
restrict previously available collaborations, specifying them
more precisely.
Because a collaboration is always defined between a collaborative model and a set of model templates, a model
never references another concrete model directly, avoiding
inconsistent “links” between models. As models never depend on other concrete models, there is no need to track
changes in other models. The way collaborative models,
collaboration templates and model templates interrelate is
depicted in Figure 1.
The refinement process ends when a collaborative model
is concretized. Concretization means mapping a model to
an executable form. It produces an application built from a
set of independent components linked by glue code that implements the specified collaboration templates. Concretization of a collaborative model also involves the concretization of the models used to fulfill its model templates. Figure
2 illustrates the case where the collaborative model model1
contains one collaborative operation whose collaboration
template requires a model template that is replaced by the
model2 in the concretization. In this case, code is generated
from the two models (component1 and component2). But
we can also have the situation where an existing application
can be used directly as the concretization for the model template instead of using model2. Note also that we can define
collaboration with more than two models.
In order to partly automate creation of concrete applications from models, it is necessary to express model transformations. Using successive transformations, applications
can be derived from models. This section explains how the
CCBM approach takes into account the different steps of
the MDE [29] development life-cycle: transformations are
expressed in CCBM by two high-level standard MDE operations on models: refinement and concretization.
part of
Model 1
concretized as
Component 1
uses
Collaboration template
Glue code
concretized as
requires
uses
fulfills
Model template
Model 2
concretized as
concretized as
Component 2
Figure 2. Concretization step.
To ensure well-formed collaborations at the code level,
each model template must correspond to a component (already coded or generated during the concretization) that fulfills the template. This way the application architecture still
reflects the structure of the models from which each component has been derived.
corresponding to application domain concepts: car,
agency, and client (Figure 4(a)). The CarRental
model is intended to manage car allocations. The Storage
model represents the management of a set of articles. Its
two classes provide the operations to add, delete, and transfer articles into and from a stock (Figure 4(b)). The aim of
the integration of the two models is to augment the car rental
functionalities by giving the possibility to move cars from
an agency to another one when an agency is lacking cars or
when it has to many unused cars. The receiving agency has
to pay these transfers.
CarRental
cars
clients
Car
Agency
Client
0..*
0..*
name
address
number
date
constructor
model
rent(c:Car)
name
birthday
phone
address
(a) Car rental model
A sketch of MDE process and the additional tasks required to manage collaborative models is shown in Figure
3. The extended process consists of three steps: specification, refinement and concretization. Each step is decomposed in several tasks detailed in Sections 3 and 4. Figure
illustrates that: 1) collaborative operations can be added to
any model (collaborative or not), 2) the refinement step is
optional (may be skipped) unlike the concretization step.
Storage
in
Stock
Article
0..*
identifier
capacity
ref
transfer(s:Stock)
add(a:Article)
delete(a:Article)
(b) Storage model
Specify the model
Refine the model
Figure 4. Models to be integrated
1. Specify
classes, attrib.
& operations
2. Identify
collaborative
operations
4. Add/refine
classes, attrib.
& operations
5. Refine
existing collab.
templates
3. Describe
collaboration
templates
6. Add
collaborative
operations
7. Add
collaboration
templates
The two next sections explain in detail how to design,
refine and concretize a collaborative model illustrating the
process’s steps on the case study.
3. Specifying & Refining Collaborative Models
Concretize the model
Legend
CCBM
tasks
Traditional
MDE tasks
A
B
Strong dependency between A and B
(If A is done then B must also be done)
8. Concretize
classes, attrib.
& operations
9. Concretize
collaborative
operations
10. Concretize
model
templates
11. Concretize
collaboration
templates
Figure 3. CCBM Modeling Process
Consider the example of a car rental system adapted
from [20]. The CarRental model contains the classes
In this section we provide the technical details of the
CCBM approach missing from the previous overview and
illustrate all concepts by considering the car rental system
introduced in Section 2.
The integration scenario assumes that we have designed
the CarRental model and we want to reuse the existing
Storage model. We start the integration by identifying
collaborative operations in the CarRental model (task 2)
and by defining the collaboration templates (task 3). Then
we refine the integration by refining collaborations between
the two models (task 5). We also show how to integrate
more than two models by integrating the Storage model
with another model. To avoid modifying Storage, we
refine it in order to define these new collaborations (tasks 6
and 7).
!
" #
$
% &
The first step to describe the collaborations of a model
consists of specifying which operations in its classes must
invoke operations of other models. These collaborative operations are represented in UML class diagrams with the
collaborative stereotype defined for the CCBM approach 1 .
In the car rental example, the integration of an inventory
management concern in the CarRental model engenders
the ability for an agency to buy and sell cars (buy and sell
operations of the Agency class) and for a car to be relocated (move operation of the Car class). These operations
are collaborative ones because they rely on other models to
manage inventory. We specify this by associating the collaborative stereotype to buy, sell and move (see Fig. 5).
CarRental
cars
Car
move(a:Agency)
In this example, each operation of the model collaborates
with only one operation of another model. For example,
Agency.buy interacts with ?register. In general,
an operation may interact with several operations of other
models. The ordering of these operations is not decided at
model level but determined at concretization time (see section 4).
Client
0..*
name
address
rent(c:Car)
buy(c:Car)
sell(c:Car)
name
birthday
phone
address
Figure 5. Definition of collaborative operations for the CarRental model.
'(#
#
$
% &
The second step consists of expressing for each collaborative operation which operations from other models are
needed for implementing its task. For this, we use the
Join Point Designation Diagrams (JPDDs) [30] which are a
small deviation from the standard UML sequence diagram
notation. However, their semantics differ in that they allow
expressing situations and conditions upon which actions of
any kind need to be taken. As JPDDs render control flowbased applicability constraints, we use them to show how
a received message (a collaborative operation) triggers the
subsequently sent messages (operations of other models).
Then collaboration templates are described through
JPDDs. Our reading of a JPDD for collaboration template
is as follows. The message that is received by the most left
time line represents the collaborative operation of the currently defined collaboration template. The other time lines
1 “Stereotypes
Figure 6 depicts the collaborative templates for the ,
and
collaborative operations of CarRental.
clients
Agency
0..*
number
date
constructor
model
represent model template classes. The messages received
by these other time line represent operations required by the
collaborative operation. Model templates, classes, operations and types can be unspecified using meta-variables that
replace syntactic entities (? for unnamed ones and ?name
for those with the name ’name’). In refinement steps, the
domain of the meta-variables is gradually specialized. In a
concretization step, meta-variables are substituted by concrete names that cannot be replaced further.
allow you to extend the vocabulary of the UML so
that you can create new model elements, derived from existing ones, but
that have specific properties that are suitable for your problem domain”
(Wikipedia).
CarRental:: Agency
?::?
buy(Car)
?register(..)
CarRental:: Agency
?::?
sell(Car)
?unregister(..)
CarRental:: Car
?::?
move(Agency)
?transfer(..)
Figure 6. Expressing Weakly-constrained collaboration needs
Without more detailed collaboration templates, any concretization of the meta-variables to one or more models,
classes and operations would be legal. However, we want to
express more precisely the kind of operations that must be
used. This requires the ability to express more constrained
collaborations. Next paragraph shows how to refine the
CarRental model to specify fine-grained collaborations.
) ! (
$
% &
A refinement relation is indicated by a dependency with
an associated refines stereotype. It means that some classes
in the refining model specify more detailed collaboration
templates or additional collaborative operations and corresponding collaboration templates. These are available in
the context of the refining model only. Using refinement,
we can add collaborations without changing the model core
by the extension of classes without changing their identity.
The CarRental model is refined as the CarRental2
model. In this new model, only the collaboration templates
associated with the , and
collaborative operations are refined to express additional constraints on new
model templates’ structure. These more precise specifications indicate which operations CarRental2 requires and
how they are constrained (see Figure 7). The meta-variable
names of operations and classes only helps to understand
what is needed and to document it. For instance, buy does
not call an operation named “register”, but just an operation with one parameter of the same type as the operation
chosen for the ?unregister meta-variable.
CarRental2::Agency
?InventoryManagement::
?Inventory
buy(Car)
?register(?Item)
CarRental2::Agency
?InventoryManagement::
?Inventory
the structure of the inventory management model template
(see Figure 8) but it does not refer to a concrete model.
In the concretization step, the operations used to replace
the ?register, ?unregister and ?transfer metavariables will have to be provided by the same model that
will have to offer at least two classes corresponding to
?Inventory and ?Item.
?Inventory management
?Item
?Inventory
?register(i:?Item)
?unregister(i:?Item)
?transfer(i:?Inventory)
Figure 8. Inventory management model template.
Using meta-variables for models, classes and operations
required by collaboratives ones is analogous to design pattern descriptions, which also use just role names instead of
concrete names. This still leaves open whether Storage
or any other model fulfilling the constraints imposed on the
?InventoryManagement model template will be used
as an implementation.
)
*
+
$
% ,
-&
sell(Car)
?unregister(?Item)
CarRental2::Car
?InventoryManagement::
?Item
move(Agency)
?transfer(?Inventory)
Figure 7. Refining the collaboration template of Fig. 6 to express more stronglyconstrained collaboration needs.
From these new collaboration templates, we can deduce
In this section we show that we can integrate
more than two models.
The final car rental application will be composed of CarRental2, Storage
and another concern managing persistence. To avoid
modifying Storage, we refine it in order to define
these new collaborations.
In this example we see
a non-collaborative model can also become collaborative: Storage is refined as PersistentStorage
with two collaborative operations: add and remove
(see Figure 9).
Moreover, the add and remove
collaborative operations of the PersistentStorage
model are not newly defined operations but existing
ones that becomes collaborative. These operations reflect the collaboration of PersistentStorage with the
?PersistenceManagement model template deduced
from the two collaboration templates described in Figure
10. This model template does not constrain very much the
model to use in the concretization step.
PersistentStorage::Stock
Storage
?PersistenceManagement::?
in
Stock
Article
add(Article)
0..*
identifier
capacity
ref
?save(?data)
transfer(s:Stock)
add(a:Article)
delete(a:Article)
PersistentStorage::Stock
?PersistenceManagement::?
refines
PersistentStorage
remove(Article)
?save(?data)
in
Article
Stock
0..*
add(a:Article)
delete(a:Article)
Figure 10. Multiple refinements: Additionally
expressing persistence requirements.
Figure 9. Incremental model extension by
definition of additional collaborative operations for an existing model.
4. Concretizing Collaborative Models
Concretizing a model means mapping it to an executable
form. Then we have to choose the target technological
space (e.g. language, middleware platform, etc). Among
others, this choice also determines a set of the transformation tools that can be used to generate code for concretizing
models and model templates.
The first aim of the CCBM approach is to conserve the
independence of each model and their identity at concretization time. For this, each model is concretized separately.
CBSE [15] platforms are good target candidates because
each model can be concretized directly as a component.
This choice is the logical consequence of the fact that the
CCBM approach is inspired from CBSE. Anyway, others
concretizations are possible, including the option to implement all models simply as a set of classes (in Java, C++,
etc). The drawback of this choice is that in the resulting application the individual models have no first class representation anymore. In this case, information about the initial
models must explicitly be represented by way of conventions (e.g. use of specific design patterns) or metadata. This
is a tedious, manual way to reinvent some basic functionality of component-based systems.
The second aim of the CCBM approach is to preserve
loose coupling of collaborations at the code level. For this,
the collaboration templates are concretized as glue code externally from the concretization of models. Service Oriented Architectures [21] orchestration principles [24] and
coordination languages [2], [26], [16], [18] are well suited.
However, collaboration templates can also be concretized
using AOP [10] or as operation calls implementation in
the collaborative operation body concretization. But in
these cases, collaborations are not separately identifiable
any more in model concretizations.
!
"
$
% . / 0&
Attributes and operations can be partly generated with
usual transformation techniques [6], [35], [17] and manually completed when needed for the business logic part, as
code can rarely be generated completely from models.
Note that the business part of collaborative operations
depends on the technology chosen for the concretization
of the collaboration templates. For example, if we choose
to concretize the collaboration templates as BPEL orchestrations, then each collaborative operation’s business part
will be concretized as a call to the composite service (in
the SOA sense of the term) that reifies the orchestration.
If we choose to concretize the collaboration templates as
component bindings, then we have to create an output port
for each collaboration partner, and each collaborative operation’s business part will be concretized as calls to operations
on the output ports.
! #
$
% 1&
Concretizing of a model template means replacing it
with an existing model (collaborative or not) or with an
application containing elements to fulfill the template. If
the template is concretized as a model, this model must be
concretized too (as described below) and the concretization
must fulfill the template.
As the operations of a model template permit to locate the points of collaboration between models, correspondences between the template operations and the operations
of the model or implementation chosen for the concretization must be supplied. If for any reason, these correspondences cannot be fully established, the whole concretization
process fails. In the CCBM approach, model templates can
be considered as a kind of contract for the concretization
step. This contract serves to establish whether a given piece
of code can be used as an implementation of a given model.
¯ ?InventoryManagement::?Inventory.?register
= PersistentStorage::Stock.add
¯ ?InventoryManagement::?Inventory.?unregister
= PersistentStorage::Stock.remove
¯ InventoryManagement::Item.transfer
= PersistentStorage::Article.transfer
¯ ?PersistenceManagement::?.?save
= ::WareHouse.record
WareHouse
fulfills
component
!
+
concretized as
#
$
% &
PersistenceManagement
At concretization time, the variables used in the collaboration templates to designate models and classes and operations need to be replaced by the names of the model or
application chosen for the concretization using the correspondences that have been defined during the concretization of model templates. Then we can define the glue code
as an orchestration, aspects or a set of operation calls. For
the orchestration choice, this can be easily achieved using
BPEL Web services standard [22] which allows for the description on the orchestration independently of the chosen
technological concretization for each model.
If required by a collaboration, adaptation of parameter or
return types is managed in the glue code, avoiding modification of the components concretizing the models. Note that
the glue code concretizing a collaboration template corresponds to automatically generated mediators [12]. Because
it expresses a collaboration of many types this code cannot
be localized in a wrapper or adapter [12] for any particular
component type. In order not to modify the existing client
components it can also not be added to them.
# !
)
a. The Car Rental Application as the Concretization of
CarRental2
In the example, the CarRental2 collaborative model
is concretized as the CarRental2 component. The
?InventoryManagement model template is replaced
by the PersistentStorage model which is itself a collaborative model. For a complete concretization, its model
templates must also be replaced by models or applications.
Supposing that the ?PersistenceManagement model
template is concretized by an existing application that contains a WareHouse class with a record operation. Then,
the concretization of CarRental2 implies the concretization of PersistentStorage which implies the reuse of
the application with the WareHouse class. These choices
of concretization are summarized in Figure 11. Correspondences are as follows.
fulfills
model
concretized as
component
concretized as
InventoryManagement
model template
Storage
PersistentStorage
requires
model template
CarRental2
requires
model
CarRental
concretized as
component
Figure 11. Concretization of CarRental2.
Concretizing the collaboration templates of the
CarAgency and StockSystem collaborative models
consists in creating simple orchestrations that are just
delegations. This is because the collaboration defined here
are one to one. Anyway, ½ to and to collaborations
can also be defined using the CCBM approach.
This example shows that different jointly used refinements allow for expressing independently and indirectly additional collaboration constraints for the same model. Consider the Storage non-collaborative model and its refinement as the PersistentStorage collaborative model.
If PersistentStorage is used in the concretization
step of CarRental2, then the persistence concern is integrated indirectly to the car rental application. But if the
Storage model is chosen instead, then the car rental application will not benefit from persistence management.
Note that persistence is often a service offered by component platforms [28, 5, 25]. Then, the CCBM facilitates the
integration of the car rental application with this service:
instead of configuring the platform to specify the services
to use, the application itself specifies, at a model level, the
services that it requires.
b. Evolution of the Car Rental Application
Suppose we want to make evolve the car rental application. For example, we may want to use another persistence implementation for the stock of car. For this we
can change our concretization choices: take another component to concretize the ?PersistenceManagement
model template instead of the WareHouse component. To
obtain this new version, only the glue code between the
concretization of CarRental2 and the newly used persistence component need to be regenerated.
In the same way, if we want to use another model
to perform stock management, we only have to generate this new model as the concretization of the
?InventoryManagement model template and the generation of the glue code corresponding to the collaboration
templates of CarRental2.
In this two examples of evolution we don’t have to
change the modeling, only the concretization step is different and not all elements need to be regenerated. But note
that we can also go back on the modeling step and refine
further our models also to make the application evolve.
c. Summary
In the car rental example, we have seen three situations:
1) we have fully designed one model (CarRental) that
has been generated in the concretization step; 2) we have
reused another model (Storage) and added to him collaborations without modifying it thanks to refinement and has
also been generated; 3) we have reused some legacy code
(WareHouse) without changing it. The collaborations between the three components have been described externally.
5. Evaluation of the CCBM approach
!
##
Incremental and modular evolution The CCBM approach allows adding or replacing a model in an application
built from collaborative models without producing again the
entire application from a new composed model. During this
process, the application code is conserved; only new collaboration templates and model templates are concretized.
Legacy code reuse This approach allows for the reuse of
applications developed without MDE [29] since we do not
need to have a model representation of an application in
order to use it as a collaboration partner. This is important
since most of the time industrial products are not built from
scratch but implemented on top of older products built from
heterogeneous technologies.
Integration of services The CCBM approach is particularly of interest for models addressing non functional concerns. In components platforms, non-functional aspects are
treated independently of applications. Specific elements of
component platforms such as EJB containers [28] or Fractal controllers [5] hide the complexity of most of the system
services like transaction, security, persistence, and notification. Such services are developed so as to introduce new
competencies in applications without direct extension of the
laters. But the integration of several services for an application is hardly customizable. Using the CCBM approach, the
application developer master the orchestration of services
that is needed in a platform-independent way.
2
!
##
In its current state, the approach only focuses on MOF
[33] based models: models that are defined as a set of
classes with attributes and operations. And, it doesn’t permit to express how different kinds of models written in different kinds of modeling languages would cooperate.
Moreover, the approach takes into account only the
structural part of models. We don’t manage yet behavioral
contracts [3] such as pre and post conditions on operations,
synchronizations or quality of service.
The approach ensures end-to-end loose coupling and
easy evolvability only under the assumption that the chosen
technical solution (i.e the generated code) is able to represent components in a first-class manner and to express collaborations externally of such components.
)
* %
Composition by merging vs collaborations Asymmetric merged-based approaches assume a primary model (expressing application domain concepts) and a set of additional models (representing additional concerns that may
be independent of the application domain) [11], [31], [20].
The model of the complete application is then computed
as a weaving of the additional models into the primary
model. Symmetric merged-based proposals assume independent models for each view of the system [9], [7], [27].
The model of the application is then computed as a merging
of all these models.
The distinction between both kinds of model merging
and model collaboration lies in the decomposition. Composition by merging creates a new model that does not preserve any information about the previous decomposition
into input models. An application is derived by a sequence
of such merging steps. In contrast, composition by collaboration does not create any new model, it is simply a set
of models that, taken together, fulfill all the requirements
stated by any of them. An application is derived by mapping these models to independent components and by linking them via separate glue code that implements the specified collaborations.
Due to the 1:1 correspondence of components to models,
the application architecture reflects the models from which
each component has been derived. Because each component can itself be made of subcomponents that correspond
to finer grained models, the architecture reflects the composition of models even after several collaboration based
composition steps. Hence separation of concerns is preserved until the final artifact is developed in contrast to
model merging, where elements of a merged model cannot
be traced back to elements of the initial models and elements from different models (concerns) are mixed at each
merging step.
In merged-based approaches, composition using same
pointcuts may lead to undesirable interactions [14]: the
composition order issue occurs when several aspect models
sharing the same pointcuts need to be merged. In the CCBM
approach, a kind of ordering issue arises when several operations of other models are used by the same collaboration
template. However, the composition granularity is not at the
same level. While AOM [1] focuses on the weaving order
of aspect models, the CCBM approach focuses on operation call orchestration. We believe that when complexity
grows, it becomes harder to understand the consequences
of merged-based composition than of collaboration-based
composition: because each interaction is captured by only
one orchestration, “what you see is what you get”.
To conclude, the choice of merging versus finding collaborations isn’t a case of right versus wrong, but of one’s
goals: when traceability and incrementality are needed then
the CCBM approach provides a reasonable solution.
Integration at the language level vs at the platform level
Integration can happen at other levels than in the languages:
at code level using middlewares such as component platforms [13], [5], [25], [28] or using aspect oriented techniques [10] for example. Although these approaches allow
modelers focus on their specific problem domain, they are
not reusable in the sense that the integration is often specific for each component code. By defining collaboration
templates and thus specifying the requirements for the integration, the CCBM approach makes it possible to reuse the
integration part. Moreover, the integration itself remains
at the platform level, which makes sense when following a
MDE approach: the specification of the integration is platform independent whereas the concretization of the integration is platform dependent.
CBSE, ADLs and CCBM Aiming to make model driven
development compatible with component-based software
development (CBSE), the CCBM approach necessarily
bears some resemblance to other techniques used in a CBSE
context. It is similar to architecture description languages
(ADLs) [19], in that it allows to express what a model requires of other, collaborating models. Template models
are to the CCBM approach what required interfaces are to
ADLs: an outside abstraction of a model to impose some
constraints on what a model requires. However, collaboration templates and model templates differ from the classical
‘required interface’ concept of ADLs in several ways. First
of all, they do not describe concrete models, types and operations but parameterized templates. Thus they are more
abstract and generic. Second, they are aimed for use a the
design and modeling phase whereas ADLs are rather close
to an implementation. The advantage of CCBM is the incremental refinement of model templates, which is not part
of CBSE. An ADL can beneficially be used together with
CCBM, as an abstraction of a target platform for concretization. The CCBM generalizes some of the strength of ADLs
and integrates them into model driven engineering.
In this paper we have addressed the issue of a synergetic
combination of model-driven and component based software engineering. We have pointed out that existing, mergebased model composition approaches are not well-suited for
incremental and modular evolution of applications.
As a remedy we proposed the Collaborative Component
Based Model approach (CCBM) that focuses on the specification of how models collaborate with each other. The
approach preserves defined collaborations during the whole
life-cycle of an application, from initial, loosely specified
interactions, through a sequence of step-wise refinements,
to the final concretization as an implemented component.
We have already experimented the CCBM approach to
model a safety service [23] queried by technological platforms that support runtime adaptation to determine whether
an adaptation is safe or not. The service has been designed as a collaborative model with two main model templates: one modeling adaptation introspection requirements
and one modeling typing conformance requirements. Different concretizations of these model templates make it possible for the safety service to interact with heterogeneous
platforms that differ significantly in the notions of safety
and adaptation. Future work will study others practical examples to evaluate the capability to handle the scalability
and complexity issues.
Future work will also address means of describing behavioral constraints on collaborations so that the replacement of a template by a model is not based only on syntactic
constraints. The use of OCL [36] to represent and compare
pre and post conditions on model operations, which is common in large-scale modeling environments today, will be the
logical evolution of the CCBM approach and will permit to
ensure that the behavior of the concrete application is an instance of the family of behaviors specified by collaborative
templates.
References
[1] AOM group.
Aspect Oriented Modeling web site.
www.aspect-modeling.org, 2007.
[2] L. Berger. Mise en oeuvre des interactions en environnements distribués, compilés et fortement typés: le modèle
MICADO. Thèse de doctorat, Université de Nice-Sophia
Antipolis, 2001.
[3] A. Beugnard, J.-M., N. Plouzeau, and D. Watkins. Making
components contract aware. In IEEE Software, pages 38–45,
1999.
[4] G. Brunet, M. Chechik, S. Easterbrook, S. Nejati, N. Niu,
and M. Sabetzadeh. A manifesto for model merging. In
GaMMa ’06: Proceedings of the 2006 international workshop on Global integrated model management, pages 5–12,
New York, NY, USA, 2006. ACM Press.
[5] E. Bruneton, T. Coupaye, and J.-B. Stefani. The fractal component model. http://fractal.objectweb.org/, 2004.
[6] J. Bézivin, G. Dupé, F. Jouault, G. Pitette, and J. E. Rougui.
First experiments with the atl model transformation language: Transforming xslt into xquery. In OOPSLA 2003
Workshop, Anaheim, California, 2003.
[7] J. Bézivin, M. D. D. Fabro, F. Jouault, and P. Valduriez.
Combining preoccupations with models. In Proceedings
of the First Workshop on Models and Aspects - Handling
Crosscutting Concerns in Model-Driven Software Development (MDSD), ECOOP, 2005.
[8] S. Clarke. Extending standard uml with model composition
semantics. Sci. Comput. Program., 44(1):71–100, 2002.
[9] D. D’Souza and A. Wills. Objects, Components and Frameworks With UML: The Catalysis Approach. AddisonWestley, 1999.
[10] R. E. Filman, T. Elrad, S. Clarke, and M. Aksit. AspectOriented Software Development. Addison-Wesley Professional, 2004. ISBN-10: 0321219767.
[11] R. B. France, I. Ray, G. Georg, and S. Ghosh. Aspectoriented approach to early design modelling. IEE Proceedings - Software, 151(4):173–186, 2004.
[12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns. Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, 1994. ISBN 0-201-63361-2.
[13] T. O. M. Group. CORBA 3.0 New Components Chapters.
OMG Document ptc/2001-11-03, 2001.
[14] J. Hanneman, R. Chitchyan, and A. Rashid. Analysis of
aspect-oriented software (aaos) workshop report. Technical
report, University of California, Darmstadt, Germany, 2003.
[15] G. Heineman and W. Councill, editors.
ComponentBased Software Engineering, Putting the Pieces Together.
Addison-Westley, 2001. ISBN: 0-201-70485-4.
[16] C. J-C. Corods: A coordination programming system for
open distributed systems. In Langages et modèles à objets
LMO’2001, volume 7 of L’Objet, pages 11–26, Le Croisic,
France, January 2001. Hermès.
[17] I. Kurtev and K. van den Berg. Mistral: A language for
model transformations in the mof meta-modeling architecture. In U. Aßmann, M. Aksit, and A. Rensink, editors,
European MDA Workshops: Foundations and Applications,
volume 3599 of Lecture Notes in Computer Science, pages
139–158. Springer-Verlag GmbH, 2005.
[18] M. Lumpe, F. Achermann, and O. Nierstrasz. A Formal Language for Composition. In G. Leavens and M. Sitaraman,
editors, Foundations of Component Based Systems, pages
69–90. Cambridge University Press, 2000.
[19] N. Medvidovic and R. N. Taylor. A classification and comparison framework for software architecture description languages. Software Engineering, 26(1):70–93, 1997.
[20] A. Muller, O. Caron, B. Carre, and G. Vanwormhoudt. On
some properties of parameterized model application. In
A. Hartman and e. D. Kreische, editors, ECMDA-FA 2005,
volume 3748 of LNCS, pages 130–144. Springer-Verlag,
2005.
[21] Y. V. Natis. Service-oriented architecture scenario. Gartner,
Inc, 2003.
[22] Oasis.
Web
services
business
process
execution
language.
http://www.oasisopen.org/committees/tc home.php?wg abbrev=wsbpel,
2005.
[23] A. Occello. Capitalisation de la sûreté de fonctionnement
des applications soumises aux adaptations dynamiques: le
modèle exécutable Satin. PhD thesis, Université de Nice
Sophia-Antipolis, June 2006.
[24] C. Peltz. Web services orchestration and choreography.
Computer, 36(10):46–52, 2003.
[25] F. Plasil, D. Balek, and R. Janecek. SOFA/DCUP: Architecture for component trading and dynamic updating. In Proceedings of ICCDS’98, Annapolis, Maryland, USA, 1998.
[26] A. R. and G. D. Formal connectors. Technical Report CMUCS-94-115, Carnegie Mellon University, School of Computer Science, March 1994.
[27] R. Reddy, R. France, S. Ghosh, F. Fleurey, and B. Baudry.
Model composition - a signature-based approach. In O. Aldawud, T. Elrad, J. Gray, M. K. J. Kienzle, and D. Stein, editors, 7th International Workshop on Aspect-Oriented Modeling, Oct. 2005.
[28] E. Roman, S. W. Ambler, and T. Jewell. Mastering Enterprise Java Beans II and the Java 2 Platform. John-Wiley &
Sons Inc., enterprise edition, 2002.
[29] D. C. Schmidt. Model-Driven Engineering. IEEE Computer,
39(2):25–32, 2006.
[30] D. Stein, S. Hanenberg, and R. Unland. Join point designation diagrams: a graphical representation of join point selections. International Journal of Software Engineering and
Knowledge Engineering, 16(3):317–346, 2006.
[31] G. Straw, G. Georg, E. Song, S. Ghosh, R. France, and
J. M. Bieman. Model composition directives. In T. Baar,
A. Strohmeier, A. Moreira, and e. S. J. Mellor, editors, UML
2004: Model Languages and Applications, volume 3273 of
LNCS, pages 84–97, Lisbon, Portugal, 2004. Springer.
[32] C. Szyperski.
Component Software: Beyond ObjectOriented Programming. Addison-Westley, 1999. ISBN: 0201-17888-5.
[33] The Object Managemant Group. Mof 2.0 specification.
OMG Document ptc/03-10-09, 2003.
[34] The Object Managemant Group. Unified Modeling Language Specification. OMG Document formal/03-03-01,
2003.
[35] The Object Managemant Group. Revised Submission for
MOF 2.0 Query/View/Transformations RFP. OMG Document ad/2005-07-01, 2005.
[36] J. Warmer and A. Kleppe. OCL: The constraint language of
the UML. Journal of Object-Oriented Programming, 1999.
Engineering of Computer Based Systems (ECBS 2008), pages 453-462. IEEE Computer Society,
April 2008.
Managing Model Evolution Using the CCBM Approach
Audrey Occello, Anne-Marie Dery-Pinna, Michel Riveill
University of Nice-Sophia Antipolis, France
occello, pinna, riveill@polytech.unice.fr
Abstract
With the adoption of MDE, application evolution is facilitated. Instead of modifying each deployed version, the application is modified only once at the model level and then
regenerated for each platform. On the other hand, to manage application complexity, models are partitioned and then
integrated together to form larger ones. However most of
modeling approaches use an integration mechanism based
on merging existing models that makes it difficult to manage
application evolution in a modular and incremental way.
As an alternative, we propose the Collaborative Component Based Model approach (CCBM) that leverages software components principles and focuses on the specification of how models collaborate with each other. This paper presents how the proposed approach contributes to integrate and manage change of models incrementally by preserving defined collaborations during the whole life-cycle of
an application, from initial, very loosely specified interactions, through step-wise refinements, to the final concretization to a component implementation.
Keywords. MDE, model integration, model evolution,
CBSE.
1. Introduction
Most of the time, industrial products are not built from
scratch but implemented by evolution of existing ones.
When the application is deployed on several middleware
platforms, the difficulty is then to maintain each deployed
versions. With the adoption of MDE, application evolution
is facilitated. Instead of modifying each deployed version,
the application is modified only once at the model level and
then regenerated for each platform. On the other hand, the
complexity of modern applications is mirrored by the complexity of their models. Therefore separation of concerns
need to be leveraged to the model level. The idea of partitioning models and integrating them to form larger ones
is not new and is the core of most of the composition ap-
Günter Kniesel
University of Bonn, Germany
[email protected]
proaches [4] such as in Aspect Oriented Modeling (AOM)
[1] and in Subject Oriented Design (SOD) [8].
Unfortunately, these approaches propose an integration
mechanism based on merging existing models that is not always adequate for some specific model evolutions. First,
the integration with legacy code is impossible if this code
has not been generated from a model. Secondly, if we want
to add, remove or replace a model in the resulting application, we must 1) go back at the design stage and 2) be
capable of having all the input models not only the merged
one so as to define the new composition to be concretized.
Evolution of an application built from merged models implies producing again the entire application from a new set
of model merging. Integration of models through merging
is therefore not an incremental and modular process.
Our goal is to provide a new approach of model integration that makes model evolution easier. For this, we propose
to leverage principles of software components [32] so as
to provide an alternative way to manage model integration
and evolution. The Collaborative Component Based Model
approach (CCBM) achieves black-box reuse of unmodified
models and preserves them. Thus, in CCBM, models are
units of reuse and integration is modular and incremental,
just as for software components in Component Based Software Engineering (CBSE) [15]. This paper presents how
the proposed approach enables the specification of model
collaboration and explains how it takes into account the different steps of the MDE development life-cycle by preserving loose coupling and easy evolvability from the modeling
to the system implementation.
The remainder of this paper is organized as follows.
Section 2 explains the principles of the CCBM approach
as a way to build models by bridging smaller ones and
introduces a case study. Section 3 describes how to specify
model collaboration on the case study and section 4, how
to concretize models and their collaborations as pieces of
software. Finally, section 5 summarizes the benefits and
limitations of our work and presents related work.
2. Overview of the CCBM Approach
The core principle of the CCBM approach is the incremental, structure-preserving integration of models by expressing collaborations between them. Model integration is
specified as a family of control flows that cross the unmodified input models. Every model specifies requirements that
other models must fulfill in order to participate in a collaboration. Hence, the result of the integration is simply a set
of models that, taken together, fulfill all the requirements
stated by any of them. This section introduces the vocabulary of the CCBM approach and the case study that is used
in this paper to explain the approach.
Collaborative model
requires
Collaboration
template
Collaboration
template
Collaboration
template
requires
requires
Model template
constrained by
Collaborative
Collaborative
operation
operation
Collaborative
operation
extended by
Non−Collaborative part
of the model
Figure 1. CCBM concept relationships.
As in other modeling approaches such as UML [34], a
model contains classes that are characterized by attributes
and operations. In addition, in the CCBM approach, a
model is said to be a collaborative model if it contains at
least one collaborative operation. Collaborative operations
are the operations that rely on operations of others models to accomplish a task. The specification of a collaborative operation is a special version of collaboration diagrams
(see Figures 6 and 7) that we refer as collaboration templates . Collaboration templates define implicit constraints
that models must fulfill in order to be chosen as collaboration partners. The sum of these constraints outlines a set of
generic model specifications that we call model templates.
Model templates are generic in the sense that they do not
represent individual models but any models that fulfill the
constraints. Collaboration templates are generic in the sense
that they do not refer directly to specific models, types or
operations but use variables whose values are provided later.
A collaborative model
can be refined by adding more
details about collaborations with others models in collaboration templates. Refinement of
can be specified incrementally in another model by: 1) adding collaborative operations and collaboration templates to the refining model
(model extension), 2) completing the collaboration templates by specifying precisely the called methods, not just
their containing model or type (operation specialization),
or 3) performing any combination of the above.
Models can be incrementally refined by stating more
complete collaboration requirements: each refinement adds
new model templates that are more specific in the sense that
they either provide additional collaboration opportunities or
restrict previously available collaborations, specifying them
more precisely.
Because a collaboration is always defined between a collaborative model and a set of model templates, a model
never references another concrete model directly, avoiding
inconsistent “links” between models. As models never depend on other concrete models, there is no need to track
changes in other models. The way collaborative models,
collaboration templates and model templates interrelate is
depicted in Figure 1.
The refinement process ends when a collaborative model
is concretized. Concretization means mapping a model to
an executable form. It produces an application built from a
set of independent components linked by glue code that implements the specified collaboration templates. Concretization of a collaborative model also involves the concretization of the models used to fulfill its model templates. Figure
2 illustrates the case where the collaborative model model1
contains one collaborative operation whose collaboration
template requires a model template that is replaced by the
model2 in the concretization. In this case, code is generated
from the two models (component1 and component2). But
we can also have the situation where an existing application
can be used directly as the concretization for the model template instead of using model2. Note also that we can define
collaboration with more than two models.
In order to partly automate creation of concrete applications from models, it is necessary to express model transformations. Using successive transformations, applications
can be derived from models. This section explains how the
CCBM approach takes into account the different steps of
the MDE [29] development life-cycle: transformations are
expressed in CCBM by two high-level standard MDE operations on models: refinement and concretization.
part of
Model 1
concretized as
Component 1
uses
Collaboration template
Glue code
concretized as
requires
uses
fulfills
Model template
Model 2
concretized as
concretized as
Component 2
Figure 2. Concretization step.
To ensure well-formed collaborations at the code level,
each model template must correspond to a component (already coded or generated during the concretization) that fulfills the template. This way the application architecture still
reflects the structure of the models from which each component has been derived.
corresponding to application domain concepts: car,
agency, and client (Figure 4(a)). The CarRental
model is intended to manage car allocations. The Storage
model represents the management of a set of articles. Its
two classes provide the operations to add, delete, and transfer articles into and from a stock (Figure 4(b)). The aim of
the integration of the two models is to augment the car rental
functionalities by giving the possibility to move cars from
an agency to another one when an agency is lacking cars or
when it has to many unused cars. The receiving agency has
to pay these transfers.
CarRental
cars
clients
Car
Agency
Client
0..*
0..*
name
address
number
date
constructor
model
rent(c:Car)
name
birthday
phone
address
(a) Car rental model
A sketch of MDE process and the additional tasks required to manage collaborative models is shown in Figure
3. The extended process consists of three steps: specification, refinement and concretization. Each step is decomposed in several tasks detailed in Sections 3 and 4. Figure
illustrates that: 1) collaborative operations can be added to
any model (collaborative or not), 2) the refinement step is
optional (may be skipped) unlike the concretization step.
Storage
in
Stock
Article
0..*
identifier
capacity
ref
transfer(s:Stock)
add(a:Article)
delete(a:Article)
(b) Storage model
Specify the model
Refine the model
Figure 4. Models to be integrated
1. Specify
classes, attrib.
& operations
2. Identify
collaborative
operations
4. Add/refine
classes, attrib.
& operations
5. Refine
existing collab.
templates
3. Describe
collaboration
templates
6. Add
collaborative
operations
7. Add
collaboration
templates
The two next sections explain in detail how to design,
refine and concretize a collaborative model illustrating the
process’s steps on the case study.
3. Specifying & Refining Collaborative Models
Concretize the model
Legend
CCBM
tasks
Traditional
MDE tasks
A
B
Strong dependency between A and B
(If A is done then B must also be done)
8. Concretize
classes, attrib.
& operations
9. Concretize
collaborative
operations
10. Concretize
model
templates
11. Concretize
collaboration
templates
Figure 3. CCBM Modeling Process
Consider the example of a car rental system adapted
from [20]. The CarRental model contains the classes
In this section we provide the technical details of the
CCBM approach missing from the previous overview and
illustrate all concepts by considering the car rental system
introduced in Section 2.
The integration scenario assumes that we have designed
the CarRental model and we want to reuse the existing
Storage model. We start the integration by identifying
collaborative operations in the CarRental model (task 2)
and by defining the collaboration templates (task 3). Then
we refine the integration by refining collaborations between
the two models (task 5). We also show how to integrate
more than two models by integrating the Storage model
with another model. To avoid modifying Storage, we
refine it in order to define these new collaborations (tasks 6
and 7).
!
" #
$
% &
The first step to describe the collaborations of a model
consists of specifying which operations in its classes must
invoke operations of other models. These collaborative operations are represented in UML class diagrams with the
collaborative stereotype defined for the CCBM approach 1 .
In the car rental example, the integration of an inventory
management concern in the CarRental model engenders
the ability for an agency to buy and sell cars (buy and sell
operations of the Agency class) and for a car to be relocated (move operation of the Car class). These operations
are collaborative ones because they rely on other models to
manage inventory. We specify this by associating the collaborative stereotype to buy, sell and move (see Fig. 5).
CarRental
cars
Car
move(a:Agency)
In this example, each operation of the model collaborates
with only one operation of another model. For example,
Agency.buy interacts with ?register. In general,
an operation may interact with several operations of other
models. The ordering of these operations is not decided at
model level but determined at concretization time (see section 4).
Client
0..*
name
address
rent(c:Car)
buy(c:Car)
sell(c:Car)
name
birthday
phone
address
Figure 5. Definition of collaborative operations for the CarRental model.
'(#
#
$
% &
The second step consists of expressing for each collaborative operation which operations from other models are
needed for implementing its task. For this, we use the
Join Point Designation Diagrams (JPDDs) [30] which are a
small deviation from the standard UML sequence diagram
notation. However, their semantics differ in that they allow
expressing situations and conditions upon which actions of
any kind need to be taken. As JPDDs render control flowbased applicability constraints, we use them to show how
a received message (a collaborative operation) triggers the
subsequently sent messages (operations of other models).
Then collaboration templates are described through
JPDDs. Our reading of a JPDD for collaboration template
is as follows. The message that is received by the most left
time line represents the collaborative operation of the currently defined collaboration template. The other time lines
1 “Stereotypes
Figure 6 depicts the collaborative templates for the ,
and
collaborative operations of CarRental.
clients
Agency
0..*
number
date
constructor
model
represent model template classes. The messages received
by these other time line represent operations required by the
collaborative operation. Model templates, classes, operations and types can be unspecified using meta-variables that
replace syntactic entities (? for unnamed ones and ?name
for those with the name ’name’). In refinement steps, the
domain of the meta-variables is gradually specialized. In a
concretization step, meta-variables are substituted by concrete names that cannot be replaced further.
allow you to extend the vocabulary of the UML so
that you can create new model elements, derived from existing ones, but
that have specific properties that are suitable for your problem domain”
(Wikipedia).
CarRental:: Agency
?::?
buy(Car)
?register(..)
CarRental:: Agency
?::?
sell(Car)
?unregister(..)
CarRental:: Car
?::?
move(Agency)
?transfer(..)
Figure 6. Expressing Weakly-constrained collaboration needs
Without more detailed collaboration templates, any concretization of the meta-variables to one or more models,
classes and operations would be legal. However, we want to
express more precisely the kind of operations that must be
used. This requires the ability to express more constrained
collaborations. Next paragraph shows how to refine the
CarRental model to specify fine-grained collaborations.
) ! (
$
% &
A refinement relation is indicated by a dependency with
an associated refines stereotype. It means that some classes
in the refining model specify more detailed collaboration
templates or additional collaborative operations and corresponding collaboration templates. These are available in
the context of the refining model only. Using refinement,
we can add collaborations without changing the model core
by the extension of classes without changing their identity.
The CarRental model is refined as the CarRental2
model. In this new model, only the collaboration templates
associated with the , and
collaborative operations are refined to express additional constraints on new
model templates’ structure. These more precise specifications indicate which operations CarRental2 requires and
how they are constrained (see Figure 7). The meta-variable
names of operations and classes only helps to understand
what is needed and to document it. For instance, buy does
not call an operation named “register”, but just an operation with one parameter of the same type as the operation
chosen for the ?unregister meta-variable.
CarRental2::Agency
?InventoryManagement::
?Inventory
buy(Car)
?register(?Item)
CarRental2::Agency
?InventoryManagement::
?Inventory
the structure of the inventory management model template
(see Figure 8) but it does not refer to a concrete model.
In the concretization step, the operations used to replace
the ?register, ?unregister and ?transfer metavariables will have to be provided by the same model that
will have to offer at least two classes corresponding to
?Inventory and ?Item.
?Inventory management
?Item
?Inventory
?register(i:?Item)
?unregister(i:?Item)
?transfer(i:?Inventory)
Figure 8. Inventory management model template.
Using meta-variables for models, classes and operations
required by collaboratives ones is analogous to design pattern descriptions, which also use just role names instead of
concrete names. This still leaves open whether Storage
or any other model fulfilling the constraints imposed on the
?InventoryManagement model template will be used
as an implementation.
)
*
+
$
% ,
-&
sell(Car)
?unregister(?Item)
CarRental2::Car
?InventoryManagement::
?Item
move(Agency)
?transfer(?Inventory)
Figure 7. Refining the collaboration template of Fig. 6 to express more stronglyconstrained collaboration needs.
From these new collaboration templates, we can deduce
In this section we show that we can integrate
more than two models.
The final car rental application will be composed of CarRental2, Storage
and another concern managing persistence. To avoid
modifying Storage, we refine it in order to define
these new collaborations.
In this example we see
a non-collaborative model can also become collaborative: Storage is refined as PersistentStorage
with two collaborative operations: add and remove
(see Figure 9).
Moreover, the add and remove
collaborative operations of the PersistentStorage
model are not newly defined operations but existing
ones that becomes collaborative. These operations reflect the collaboration of PersistentStorage with the
?PersistenceManagement model template deduced
from the two collaboration templates described in Figure
10. This model template does not constrain very much the
model to use in the concretization step.
PersistentStorage::Stock
Storage
?PersistenceManagement::?
in
Stock
Article
add(Article)
0..*
identifier
capacity
ref
?save(?data)
transfer(s:Stock)
add(a:Article)
delete(a:Article)
PersistentStorage::Stock
?PersistenceManagement::?
refines
PersistentStorage
remove(Article)
?save(?data)
in
Article
Stock
0..*
add(a:Article)
delete(a:Article)
Figure 10. Multiple refinements: Additionally
expressing persistence requirements.
Figure 9. Incremental model extension by
definition of additional collaborative operations for an existing model.
4. Concretizing Collaborative Models
Concretizing a model means mapping it to an executable
form. Then we have to choose the target technological
space (e.g. language, middleware platform, etc). Among
others, this choice also determines a set of the transformation tools that can be used to generate code for concretizing
models and model templates.
The first aim of the CCBM approach is to conserve the
independence of each model and their identity at concretization time. For this, each model is concretized separately.
CBSE [15] platforms are good target candidates because
each model can be concretized directly as a component.
This choice is the logical consequence of the fact that the
CCBM approach is inspired from CBSE. Anyway, others
concretizations are possible, including the option to implement all models simply as a set of classes (in Java, C++,
etc). The drawback of this choice is that in the resulting application the individual models have no first class representation anymore. In this case, information about the initial
models must explicitly be represented by way of conventions (e.g. use of specific design patterns) or metadata. This
is a tedious, manual way to reinvent some basic functionality of component-based systems.
The second aim of the CCBM approach is to preserve
loose coupling of collaborations at the code level. For this,
the collaboration templates are concretized as glue code externally from the concretization of models. Service Oriented Architectures [21] orchestration principles [24] and
coordination languages [2], [26], [16], [18] are well suited.
However, collaboration templates can also be concretized
using AOP [10] or as operation calls implementation in
the collaborative operation body concretization. But in
these cases, collaborations are not separately identifiable
any more in model concretizations.
!
"
$
% . / 0&
Attributes and operations can be partly generated with
usual transformation techniques [6], [35], [17] and manually completed when needed for the business logic part, as
code can rarely be generated completely from models.
Note that the business part of collaborative operations
depends on the technology chosen for the concretization
of the collaboration templates. For example, if we choose
to concretize the collaboration templates as BPEL orchestrations, then each collaborative operation’s business part
will be concretized as a call to the composite service (in
the SOA sense of the term) that reifies the orchestration.
If we choose to concretize the collaboration templates as
component bindings, then we have to create an output port
for each collaboration partner, and each collaborative operation’s business part will be concretized as calls to operations
on the output ports.
! #
$
% 1&
Concretizing of a model template means replacing it
with an existing model (collaborative or not) or with an
application containing elements to fulfill the template. If
the template is concretized as a model, this model must be
concretized too (as described below) and the concretization
must fulfill the template.
As the operations of a model template permit to locate the points of collaboration between models, correspondences between the template operations and the operations
of the model or implementation chosen for the concretization must be supplied. If for any reason, these correspondences cannot be fully established, the whole concretization
process fails. In the CCBM approach, model templates can
be considered as a kind of contract for the concretization
step. This contract serves to establish whether a given piece
of code can be used as an implementation of a given model.
¯ ?InventoryManagement::?Inventory.?register
= PersistentStorage::Stock.add
¯ ?InventoryManagement::?Inventory.?unregister
= PersistentStorage::Stock.remove
¯ InventoryManagement::Item.transfer
= PersistentStorage::Article.transfer
¯ ?PersistenceManagement::?.?save
= ::WareHouse.record
WareHouse
fulfills
component
!
+
concretized as
#
$
% &
PersistenceManagement
At concretization time, the variables used in the collaboration templates to designate models and classes and operations need to be replaced by the names of the model or
application chosen for the concretization using the correspondences that have been defined during the concretization of model templates. Then we can define the glue code
as an orchestration, aspects or a set of operation calls. For
the orchestration choice, this can be easily achieved using
BPEL Web services standard [22] which allows for the description on the orchestration independently of the chosen
technological concretization for each model.
If required by a collaboration, adaptation of parameter or
return types is managed in the glue code, avoiding modification of the components concretizing the models. Note that
the glue code concretizing a collaboration template corresponds to automatically generated mediators [12]. Because
it expresses a collaboration of many types this code cannot
be localized in a wrapper or adapter [12] for any particular
component type. In order not to modify the existing client
components it can also not be added to them.
# !
)
a. The Car Rental Application as the Concretization of
CarRental2
In the example, the CarRental2 collaborative model
is concretized as the CarRental2 component. The
?InventoryManagement model template is replaced
by the PersistentStorage model which is itself a collaborative model. For a complete concretization, its model
templates must also be replaced by models or applications.
Supposing that the ?PersistenceManagement model
template is concretized by an existing application that contains a WareHouse class with a record operation. Then,
the concretization of CarRental2 implies the concretization of PersistentStorage which implies the reuse of
the application with the WareHouse class. These choices
of concretization are summarized in Figure 11. Correspondences are as follows.
fulfills
model
concretized as
component
concretized as
InventoryManagement
model template
Storage
PersistentStorage
requires
model template
CarRental2
requires
model
CarRental
concretized as
component
Figure 11. Concretization of CarRental2.
Concretizing the collaboration templates of the
CarAgency and StockSystem collaborative models
consists in creating simple orchestrations that are just
delegations. This is because the collaboration defined here
are one to one. Anyway, ½ to and to collaborations
can also be defined using the CCBM approach.
This example shows that different jointly used refinements allow for expressing independently and indirectly additional collaboration constraints for the same model. Consider the Storage non-collaborative model and its refinement as the PersistentStorage collaborative model.
If PersistentStorage is used in the concretization
step of CarRental2, then the persistence concern is integrated indirectly to the car rental application. But if the
Storage model is chosen instead, then the car rental application will not benefit from persistence management.
Note that persistence is often a service offered by component platforms [28, 5, 25]. Then, the CCBM facilitates the
integration of the car rental application with this service:
instead of configuring the platform to specify the services
to use, the application itself specifies, at a model level, the
services that it requires.
b. Evolution of the Car Rental Application
Suppose we want to make evolve the car rental application. For example, we may want to use another persistence implementation for the stock of car. For this we
can change our concretization choices: take another component to concretize the ?PersistenceManagement
model template instead of the WareHouse component. To
obtain this new version, only the glue code between the
concretization of CarRental2 and the newly used persistence component need to be regenerated.
In the same way, if we want to use another model
to perform stock management, we only have to generate this new model as the concretization of the
?InventoryManagement model template and the generation of the glue code corresponding to the collaboration
templates of CarRental2.
In this two examples of evolution we don’t have to
change the modeling, only the concretization step is different and not all elements need to be regenerated. But note
that we can also go back on the modeling step and refine
further our models also to make the application evolve.
c. Summary
In the car rental example, we have seen three situations:
1) we have fully designed one model (CarRental) that
has been generated in the concretization step; 2) we have
reused another model (Storage) and added to him collaborations without modifying it thanks to refinement and has
also been generated; 3) we have reused some legacy code
(WareHouse) without changing it. The collaborations between the three components have been described externally.
5. Evaluation of the CCBM approach
!
##
Incremental and modular evolution The CCBM approach allows adding or replacing a model in an application
built from collaborative models without producing again the
entire application from a new composed model. During this
process, the application code is conserved; only new collaboration templates and model templates are concretized.
Legacy code reuse This approach allows for the reuse of
applications developed without MDE [29] since we do not
need to have a model representation of an application in
order to use it as a collaboration partner. This is important
since most of the time industrial products are not built from
scratch but implemented on top of older products built from
heterogeneous technologies.
Integration of services The CCBM approach is particularly of interest for models addressing non functional concerns. In components platforms, non-functional aspects are
treated independently of applications. Specific elements of
component platforms such as EJB containers [28] or Fractal controllers [5] hide the complexity of most of the system
services like transaction, security, persistence, and notification. Such services are developed so as to introduce new
competencies in applications without direct extension of the
laters. But the integration of several services for an application is hardly customizable. Using the CCBM approach, the
application developer master the orchestration of services
that is needed in a platform-independent way.
2
!
##
In its current state, the approach only focuses on MOF
[33] based models: models that are defined as a set of
classes with attributes and operations. And, it doesn’t permit to express how different kinds of models written in different kinds of modeling languages would cooperate.
Moreover, the approach takes into account only the
structural part of models. We don’t manage yet behavioral
contracts [3] such as pre and post conditions on operations,
synchronizations or quality of service.
The approach ensures end-to-end loose coupling and
easy evolvability only under the assumption that the chosen
technical solution (i.e the generated code) is able to represent components in a first-class manner and to express collaborations externally of such components.
)
* %
Composition by merging vs collaborations Asymmetric merged-based approaches assume a primary model (expressing application domain concepts) and a set of additional models (representing additional concerns that may
be independent of the application domain) [11], [31], [20].
The model of the complete application is then computed
as a weaving of the additional models into the primary
model. Symmetric merged-based proposals assume independent models for each view of the system [9], [7], [27].
The model of the application is then computed as a merging
of all these models.
The distinction between both kinds of model merging
and model collaboration lies in the decomposition. Composition by merging creates a new model that does not preserve any information about the previous decomposition
into input models. An application is derived by a sequence
of such merging steps. In contrast, composition by collaboration does not create any new model, it is simply a set
of models that, taken together, fulfill all the requirements
stated by any of them. An application is derived by mapping these models to independent components and by linking them via separate glue code that implements the specified collaborations.
Due to the 1:1 correspondence of components to models,
the application architecture reflects the models from which
each component has been derived. Because each component can itself be made of subcomponents that correspond
to finer grained models, the architecture reflects the composition of models even after several collaboration based
composition steps. Hence separation of concerns is preserved until the final artifact is developed in contrast to
model merging, where elements of a merged model cannot
be traced back to elements of the initial models and elements from different models (concerns) are mixed at each
merging step.
In merged-based approaches, composition using same
pointcuts may lead to undesirable interactions [14]: the
composition order issue occurs when several aspect models
sharing the same pointcuts need to be merged. In the CCBM
approach, a kind of ordering issue arises when several operations of other models are used by the same collaboration
template. However, the composition granularity is not at the
same level. While AOM [1] focuses on the weaving order
of aspect models, the CCBM approach focuses on operation call orchestration. We believe that when complexity
grows, it becomes harder to understand the consequences
of merged-based composition than of collaboration-based
composition: because each interaction is captured by only
one orchestration, “what you see is what you get”.
To conclude, the choice of merging versus finding collaborations isn’t a case of right versus wrong, but of one’s
goals: when traceability and incrementality are needed then
the CCBM approach provides a reasonable solution.
Integration at the language level vs at the platform level
Integration can happen at other levels than in the languages:
at code level using middlewares such as component platforms [13], [5], [25], [28] or using aspect oriented techniques [10] for example. Although these approaches allow
modelers focus on their specific problem domain, they are
not reusable in the sense that the integration is often specific for each component code. By defining collaboration
templates and thus specifying the requirements for the integration, the CCBM approach makes it possible to reuse the
integration part. Moreover, the integration itself remains
at the platform level, which makes sense when following a
MDE approach: the specification of the integration is platform independent whereas the concretization of the integration is platform dependent.
CBSE, ADLs and CCBM Aiming to make model driven
development compatible with component-based software
development (CBSE), the CCBM approach necessarily
bears some resemblance to other techniques used in a CBSE
context. It is similar to architecture description languages
(ADLs) [19], in that it allows to express what a model requires of other, collaborating models. Template models
are to the CCBM approach what required interfaces are to
ADLs: an outside abstraction of a model to impose some
constraints on what a model requires. However, collaboration templates and model templates differ from the classical
‘required interface’ concept of ADLs in several ways. First
of all, they do not describe concrete models, types and operations but parameterized templates. Thus they are more
abstract and generic. Second, they are aimed for use a the
design and modeling phase whereas ADLs are rather close
to an implementation. The advantage of CCBM is the incremental refinement of model templates, which is not part
of CBSE. An ADL can beneficially be used together with
CCBM, as an abstraction of a target platform for concretization. The CCBM generalizes some of the strength of ADLs
and integrates them into model driven engineering.
In this paper we have addressed the issue of a synergetic
combination of model-driven and component based software engineering. We have pointed out that existing, mergebased model composition approaches are not well-suited for
incremental and modular evolution of applications.
As a remedy we proposed the Collaborative Component
Based Model approach (CCBM) that focuses on the specification of how models collaborate with each other. The
approach preserves defined collaborations during the whole
life-cycle of an application, from initial, loosely specified
interactions, through a sequence of step-wise refinements,
to the final concretization as an implemented component.
We have already experimented the CCBM approach to
model a safety service [23] queried by technological platforms that support runtime adaptation to determine whether
an adaptation is safe or not. The service has been designed as a collaborative model with two main model templates: one modeling adaptation introspection requirements
and one modeling typing conformance requirements. Different concretizations of these model templates make it possible for the safety service to interact with heterogeneous
platforms that differ significantly in the notions of safety
and adaptation. Future work will study others practical examples to evaluate the capability to handle the scalability
and complexity issues.
Future work will also address means of describing behavioral constraints on collaborations so that the replacement of a template by a model is not based only on syntactic
constraints. The use of OCL [36] to represent and compare
pre and post conditions on model operations, which is common in large-scale modeling environments today, will be the
logical evolution of the CCBM approach and will permit to
ensure that the behavior of the concrete application is an instance of the family of behaviors specified by collaborative
templates.
References
[1] AOM group.
Aspect Oriented Modeling web site.
www.aspect-modeling.org, 2007.
[2] L. Berger. Mise en oeuvre des interactions en environnements distribués, compilés et fortement typés: le modèle
MICADO. Thèse de doctorat, Université de Nice-Sophia
Antipolis, 2001.
[3] A. Beugnard, J.-M., N. Plouzeau, and D. Watkins. Making
components contract aware. In IEEE Software, pages 38–45,
1999.
[4] G. Brunet, M. Chechik, S. Easterbrook, S. Nejati, N. Niu,
and M. Sabetzadeh. A manifesto for model merging. In
GaMMa ’06: Proceedings of the 2006 international workshop on Global integrated model management, pages 5–12,
New York, NY, USA, 2006. ACM Press.
[5] E. Bruneton, T. Coupaye, and J.-B. Stefani. The fractal component model. http://fractal.objectweb.org/, 2004.
[6] J. Bézivin, G. Dupé, F. Jouault, G. Pitette, and J. E. Rougui.
First experiments with the atl model transformation language: Transforming xslt into xquery. In OOPSLA 2003
Workshop, Anaheim, California, 2003.
[7] J. Bézivin, M. D. D. Fabro, F. Jouault, and P. Valduriez.
Combining preoccupations with models. In Proceedings
of the First Workshop on Models and Aspects - Handling
Crosscutting Concerns in Model-Driven Software Development (MDSD), ECOOP, 2005.
[8] S. Clarke. Extending standard uml with model composition
semantics. Sci. Comput. Program., 44(1):71–100, 2002.
[9] D. D’Souza and A. Wills. Objects, Components and Frameworks With UML: The Catalysis Approach. AddisonWestley, 1999.
[10] R. E. Filman, T. Elrad, S. Clarke, and M. Aksit. AspectOriented Software Development. Addison-Wesley Professional, 2004. ISBN-10: 0321219767.
[11] R. B. France, I. Ray, G. Georg, and S. Ghosh. Aspectoriented approach to early design modelling. IEE Proceedings - Software, 151(4):173–186, 2004.
[12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns. Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, 1994. ISBN 0-201-63361-2.
[13] T. O. M. Group. CORBA 3.0 New Components Chapters.
OMG Document ptc/2001-11-03, 2001.
[14] J. Hanneman, R. Chitchyan, and A. Rashid. Analysis of
aspect-oriented software (aaos) workshop report. Technical
report, University of California, Darmstadt, Germany, 2003.
[15] G. Heineman and W. Councill, editors.
ComponentBased Software Engineering, Putting the Pieces Together.
Addison-Westley, 2001. ISBN: 0-201-70485-4.
[16] C. J-C. Corods: A coordination programming system for
open distributed systems. In Langages et modèles à objets
LMO’2001, volume 7 of L’Objet, pages 11–26, Le Croisic,
France, January 2001. Hermès.
[17] I. Kurtev and K. van den Berg. Mistral: A language for
model transformations in the mof meta-modeling architecture. In U. Aßmann, M. Aksit, and A. Rensink, editors,
European MDA Workshops: Foundations and Applications,
volume 3599 of Lecture Notes in Computer Science, pages
139–158. Springer-Verlag GmbH, 2005.
[18] M. Lumpe, F. Achermann, and O. Nierstrasz. A Formal Language for Composition. In G. Leavens and M. Sitaraman,
editors, Foundations of Component Based Systems, pages
69–90. Cambridge University Press, 2000.
[19] N. Medvidovic and R. N. Taylor. A classification and comparison framework for software architecture description languages. Software Engineering, 26(1):70–93, 1997.
[20] A. Muller, O. Caron, B. Carre, and G. Vanwormhoudt. On
some properties of parameterized model application. In
A. Hartman and e. D. Kreische, editors, ECMDA-FA 2005,
volume 3748 of LNCS, pages 130–144. Springer-Verlag,
2005.
[21] Y. V. Natis. Service-oriented architecture scenario. Gartner,
Inc, 2003.
[22] Oasis.
Web
services
business
process
execution
language.
http://www.oasisopen.org/committees/tc home.php?wg abbrev=wsbpel,
2005.
[23] A. Occello. Capitalisation de la sûreté de fonctionnement
des applications soumises aux adaptations dynamiques: le
modèle exécutable Satin. PhD thesis, Université de Nice
Sophia-Antipolis, June 2006.
[24] C. Peltz. Web services orchestration and choreography.
Computer, 36(10):46–52, 2003.
[25] F. Plasil, D. Balek, and R. Janecek. SOFA/DCUP: Architecture for component trading and dynamic updating. In Proceedings of ICCDS’98, Annapolis, Maryland, USA, 1998.
[26] A. R. and G. D. Formal connectors. Technical Report CMUCS-94-115, Carnegie Mellon University, School of Computer Science, March 1994.
[27] R. Reddy, R. France, S. Ghosh, F. Fleurey, and B. Baudry.
Model composition - a signature-based approach. In O. Aldawud, T. Elrad, J. Gray, M. K. J. Kienzle, and D. Stein, editors, 7th International Workshop on Aspect-Oriented Modeling, Oct. 2005.
[28] E. Roman, S. W. Ambler, and T. Jewell. Mastering Enterprise Java Beans II and the Java 2 Platform. John-Wiley &
Sons Inc., enterprise edition, 2002.
[29] D. C. Schmidt. Model-Driven Engineering. IEEE Computer,
39(2):25–32, 2006.
[30] D. Stein, S. Hanenberg, and R. Unland. Join point designation diagrams: a graphical representation of join point selections. International Journal of Software Engineering and
Knowledge Engineering, 16(3):317–346, 2006.
[31] G. Straw, G. Georg, E. Song, S. Ghosh, R. France, and
J. M. Bieman. Model composition directives. In T. Baar,
A. Strohmeier, A. Moreira, and e. S. J. Mellor, editors, UML
2004: Model Languages and Applications, volume 3273 of
LNCS, pages 84–97, Lisbon, Portugal, 2004. Springer.
[32] C. Szyperski.
Component Software: Beyond ObjectOriented Programming. Addison-Westley, 1999. ISBN: 0201-17888-5.
[33] The Object Managemant Group. Mof 2.0 specification.
OMG Document ptc/03-10-09, 2003.
[34] The Object Managemant Group. Unified Modeling Language Specification. OMG Document formal/03-03-01,
2003.
[35] The Object Managemant Group. Revised Submission for
MOF 2.0 Query/View/Transformations RFP. OMG Document ad/2005-07-01, 2005.
[36] J. Warmer and A. Kleppe. OCL: The constraint language of
the UML. Journal of Object-Oriented Programming, 1999.