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
G¨unter Kniesel
University of Bonn, Germany
[email protected]
Abstract
With the adoption of MDE, application evolution is facil-itated. Instead of modifying each deployed version, the ap-plication is modified only once at the model level and then regenerated for each platform. On the other hand, to man-age 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 Com-ponent Based Model approach (CCBM) that leverages soft-ware components principles and focuses on the specifica-tion of how models collaborate with each other. This pa-per presents how the proposed approach contributes to in-tegrate and manage change of models incrementally by pre-serving defined collaborations during the whole life-cycle of an application, from initial, very loosely specified interac-tions, through step-wise refinements, to the final concretiza-tion to a component implementaconcretiza-tion.
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 com-plexity of their models. Therefore separation of concerns need to be leveraged to the model level. The idea of par-titioning models and integrating them to form larger ones is not new and is the core of most of the composition
ap-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 al-ways 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 appli-cation, 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 im-plies 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 integra-tion that makes model evoluintegra-tion 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 Soft-ware Engineering (CBSE) [15]. This paper presents how the proposed approach enables the specification of model collaboration and explains how it takes into account the dif-ferent steps of the MDE development life-cycle by preserv-ing loose couplpreserv-ing and easy evolvability from the modelpreserv-ing 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.
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,
2. Overview of the CCBM Approach
The core principle of the CCBM approach is the
incre-mental, structure-preserving integration of models by
ex-pressing collaborations between them. Model integration is specified as a family of control flows that cross the unmod-ified input models. Every model specifies requirements that other models must fulfill in order to participate in a collab-oration. 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 vocabu-lary of the CCBM approach and the case study that is used in this paper to explain the approach.
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 mod-els to accomplish a task. The specification of a collabora-tive operation is a special version of collaboration diagrams (see Figures 6 and 7) that we refer as collaboration
tem-plates . Collaboration temtem-plates define implicit constraints
that models must fulfill in order to be chosen as collabora-tion 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.
Because a collaboration is always defined between a col-laborative model and a set of model templates, a model never references another concrete model directly, avoiding inconsistent “links” between models. As models never de-pend 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.
In order to partly automate creation of concrete applica-tions from models, it is necessary to express model trans-formations. 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 oper-ations on models: refinement and concretization.
Non−Collaborative part of the model
template Collaboration
Collaborative operation
requires requires requires
extended by
Collaborative model
constrained by
Collaboration
Collaborative template
operation operation Collaboration template
Collaborative
Model template
Figure 1. CCBM concept relationships.
A collaborative modelcan be refined by adding more
details about collaborations with others models in collabo-ration templates. Refinement of can be specified
incre-mentally in another model by: 1) adding collaborative op-erations and collaboration templates to the refining model (model extension), 2) completing the collaboration tem-plates 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.
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 im-plements the specified collaboration templates. Concretiza-tion of a collaborative model also involves the concretiza-tion 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
uses
Figure 2. Concretization step.
To ensure well-formed collaborations at the code level, each model template must correspond to a component (al-ready coded or generated during the concretization) that
ful-fills the template. This way the application architecture still
reflects the structure of the models from which each com-ponent has been derived.
A sketch of MDE process and the additional tasks re-quired to manage collaborative models is shown in Figure 3. The extended process consists of three steps: specifica-tion, refinement and concretization. Each step is decom-posed 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.
6. Add Strong dependency between A and B
4. Add/refine
& operations classes, attrib.
Concretize the model Specify the model Refine the model
Legend
Figure 3. CCBM Modeling Process
Consider the example of a car rental system adapted
from [20]. The CarRentalmodel contains the classes
corresponding to application domain concepts: car,
agency, and client (Figure 4(a)). The CarRental
model is intended to manage car allocations. TheStorage
model represents the management of a set of articles. Its two classes provide the operations to add, delete, and trans-fer 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
(a) Car rental model
0..*
Figure 4. Models to be integrated
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
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 theCarRentalmodel and we want to reuse the existing
Storagemodel. We start the integration by identifying collaborative operations in theCarRentalmodel (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 theStoragemodel
with another model. To avoid modifying Storage, we
! " # $% &
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
op-erations are represented in UML class diagrams with the collaborative stereotype defined for the CCBM approach1. In the car rental example, the integration of an inventory
management concern in theCarRentalmodel engenders
the ability for an agency to buy and sell cars (buyandsell
operations of theAgencyclass) and for a car to be relo-cated (moveoperation of theCarclass). These operations are collaborative ones because they rely on other models to manage inventory. We specify this by associating the
col-laborative stereotype tobuy,sellandmove(see Fig. 5).
move(a:Agency)
Car
date constructor number
model address
birthday phone
Client
name
sell(c:Car) buy(c:Car) rent(c:Car) address name
Agency
<<collaborative>> <<collaborative>> <<collaborative>>
0..*
cars clients
0..*
CarRental
Figure 5. Definition of collaborative opera-tions for the CarRental model.
'(# #
$% &
The second step consists of expressing for each collab-orative 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 flow-based 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 cur-rently defined collaboration template. The other time lines
1“Stereotypes 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).
represent model template classes. The messages received by these other time line represent operations required by the collaborative operation. Model templates, classes, opera-tions 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 con-crete names that cannot be replaced further.
Figure 6 depicts the collaborative templates for the,
and collaborative operations of CarRental.
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 sec-tion 4).
buy(Car)
Car
CarRental:: ?::? ?::? CarRental:: Agency
?::? Agency
CarRental::
?unregister(..)
?transfer(..) ?register(..)
move(Agency) sell(Car)
Figure 6. Expressing Weakly-constrained col-laboration needs
Without more detailed collaboration templates, any con-cretization 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
) ! ( $% &
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 corre-sponding 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.
TheCarRentalmodel is refined as theCarRental2
model. In this new model, only the collaboration templates
associated with the,and collaborative
oper-ations are refined to express additional constraints on new model templates’ structure. These more precise
specifica-tions indicate which operaspecifica-tionsCarRental2requires 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,buydoes not call an operation named “register”, but just an oper-ation with one parameter of the same type as the operoper-ation
chosen for the?unregistermeta-variable.
move(Agency)
?transfer(?Inventory) ?unregister(?Item)
?InventoryManagement:: ?Item
?Inventory
?InventoryManagement::
?register(?Item)
?InventoryManagement:: ?Inventory
CarRental2::Agency
CarRental2::Agency
CarRental2::Car
buy(Car)
sell(Car)
Figure 7. Refining the collaboration tem-plate of Fig. 6 to express more strongly-constrained collaboration needs.
From these new collaboration templates, we can deduce
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,?unregisterand?transfer meta-variables will have to be provided by the same model that will have to offer at least two classes corresponding to
?Inventoryand?Item.
?Inventory management
?transfer(i:?Inventory)
?Item ?Inventory
?register(i:?Item) ?unregister(i:?Item)
Figure 8. Inventory management model tem-plate.
Using meta-variables for models, classes and operations required by collaboratives ones is analogous to design pat-tern descriptions, which also use just role names instead of
concrete names. This still leaves open whetherStorage
or any other model fulfilling the constraints imposed on the
?InventoryManagementmodel template will be used as an implementation.
) * +
$% , -&
In this section we show that we can integrate
more than two models. The final car rental
appli-cation 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
collabora-tive: 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
re-flect the collaboration ofPersistentStoragewith the
<<collaborative>>
Article
ref
transfer(s:Stock)
Article
delete(a:Article) add(a:Article)
Stock Stock
identifier capacity
add(a:Article) delete(a:Article)
PersistentStorage Storage
in
0..*
in
0..*
refines
<<collaborative>>
Figure 9. Incremental model extension by definition of additional collaborative opera-tions 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 transforma-tion 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 concretiza-tion 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 imple-ment all models simply as a set of classes (in Java, C++, etc). The drawback of this choice is that in the resulting ap-plication the individual models have no first class represen-tation anymore. In this case, information about the initial models must explicitly be represented by way of conven-tions (e.g. use of specific design patterns) or metadata. This is a tedious, manual way to reinvent some basic functional-ity 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 ex-ternally from the concretization of models. Service Ori-ented Architectures [21] orchestration principles [24] and coordination languages [2], [26], [16], [18] are well suited. However, collaboration templates can also be concretized
remove(Article)
?save(?data) ?save(?data)
PersistentStorage::Stock
PersistentStorage::Stock ?PersistenceManagement::?
?PersistenceManagement::?
add(Article)
Figure 10. Multiple refinements: Additionally expressing persistence requirements.
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 manu-ally 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 orches-trations, 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 opera-tion’s business part will be concretized as calls to operations on the output ports.
! #
$% 1&
As the operations of a model template permit to lo-cate the points of collaboration between models, correspon-dences between the template operations and the operations of the model or implementation chosen for the concretiza-tion must be supplied. If for any reason, these correspon-dences 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.
! +
# $% &
At concretization time, the variables used in the collab-oration templates to designate models and classes and op-erations need to be replaced by the names of the model or application chosen for the concretization using the corre-spondences that have been defined during the concretiza-tion 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 de-scription 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 modifica-tion of the components concretizing the models. Note that the glue code concretizing a collaboration template corre-sponds 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, theCarRental2collaborative model
is concretized as the CarRental2 component. The
?InventoryManagement model template is replaced
by thePersistentStoragemodel which is itself a
col-laborative model. For a complete concretization, its model templates must also be replaced by models or applications.
Supposing that the?PersistenceManagementmodel
template is concretized by an existing application that
con-tains aWareHouseclass with arecordoperation. Then,
the concretization ofCarRental2implies the
concretiza-tion ofPersistentStoragewhich implies the reuse of
the application with theWareHouseclass. These choices
of concretization are summarized in Figure 11. Correspon-dences are as follows.
¯ ?InventoryManagement::?Inventory.?register
=PersistentStorage::Stock.add
¯ ?InventoryManagement::?Inventory.?unregister
=PersistentStorage::Stock.remove
¯ InventoryManagement::Item.transfer
=PersistentStorage::Article.transfer
¯ ?PersistenceManagement::?.?save
=::WareHouse.record
concretized as
component component Storage WareHouse component
model template InventoryManagement PersistenceManagement model template
PersistentStorage model
model CarRental2
concretized as fulfills
requires requires
concretized as fulfills concretized as
CarRental
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,½toandtocollaborations
can also be defined using the CCBM approach.
This example shows that different jointly used refine-ments allow for expressing independently and indirectly ad-ditional collaboration constraints for the same model. Con-sider theStoragenon-collaborative model and its
refine-ment as thePersistentStoragecollaborative model.
If PersistentStorage is used in the concretization step of CarRental2, then the persistence concern is in-tegrated indirectly to the car rental application. But if the
Storagemodel is chosen instead, then the car rental ap-plication will not benefit from persistence management.
Note that persistence is often a service offered by compo-nent 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 appli-cation. For example, we may want to use another per-sistence implementation for the stock of car. For this we can change our concretization choices: take another
com-ponent to concretize the ?PersistenceManagement
model template instead of theWareHousecomponent. To
concretization of CarRental2 and the newly used per-sistence component need to be regenerated.
In the same way, if we want to use another model to perform stock management, we only have to gen-erate this new model as the concretization of the
?InventoryManagementmodel template and the gen-eration of the glue code corresponding to the collaboration
templates ofCarRental2.
In this two examples of evolution we don’t have to change the modeling, only the concretization step is differ-ent and not all elemdiffer-ents 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 collab-orations without modifying it thanks to refinement and has also been generated; 3) we have reused some legacy code (WareHouse) without changing it. The collaborations be-tween the three components have been described externally.
5. Evaluation of the CCBM approach
! ##
Incremental and modular evolution The CCBM
ap-proach 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 collab-oration 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
particu-larly of interest for models addressing non functional con-cerns. In components platforms, non-functional aspects are treated independently of applications. Specific elements of component platforms such as EJB containers [28] or Frac-tal controllers [5] hide the complexity of most of the system services like transaction, security, persistence, and notifi-cation. 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 applica-tion 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 per-mit to express how different kinds of models written in dif-ferent 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 repre-sent components in a first-class manner and to express col-laborations externally of such components.
) * %
Composition by merging vs collaborations
Asymmet-ric merged-based approaches assume a primary model (ex-pressing application domain concepts) and a set of addi-tional models (representing addiaddi-tional 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 inde-pendent 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. Com-position by merging creates a new model that does not pre-serve any information about the previous decomposition into input models. An application is derived by a sequence of such merging steps. In contrast, composition by collab-oration 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 map-ping these models to independent components and by link-ing them via separate glue code that implements the speci-fied collaborations.
composition steps. Hence separation of concerns is pre-served 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 ele-ments 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
op-erations 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 opera-tion call orchestraopera-tion. 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 col-laborations 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 plat-forms [13], [5], [25], [28] or using aspect oriented tech-niques [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 spe-cific for each component code. By defining collaboration templates and thus specifying the requirements for the inte-gration, 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 plat-form independent whereas the concretization of the integra-tion 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 re-quires 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, collabora-tion 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 op-erations 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 in-cremental 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 concretiza-tion. 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 soft-ware engineering. We have pointed out that existing, merge-based 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
spec-ification 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 plat-forms that support runtime adaptation to determine whether
an adaptation is safe or not. The service has been
de-signed as a collaborative model with two main model tem-plates: one modeling adaptation introspection requirements and one modeling typing conformance requirements. Dif-ferent concretizations of these model templates make it pos-sible 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 ex-amples to evaluate the capability to handle the scalability and complexity issues.
Future work will also address means of describing be-havioral constraints on collaborations so that the replace-ment 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 com-mon 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 in-stance of the family of behaviors specified by collaborative templates.
References
[2] L. Berger. Mise en oeuvre des interactions en environ-nements distribu´es, compil´es et fortement typ´es: le mod`ele MICADO. Th`ese de doctorat, Universit´e 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 work-shop 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 com-ponent model. http://fractal.objectweb.org/, 2004.
[6] J. B´ezivin, G. Dup´e, F. Jouault, G. Pitette, and J. E. Rougui. First experiments with the atl model transformation lan-guage: Transforming xslt into xquery. In OOPSLA 2003 Workshop, Anaheim, California, 2003.
[7] J. B´ezivin, 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 Develop-ment (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
Frame-works With UML: The Catalysis Approach.
Addison-Westley, 1999.
[10] R. E. Filman, T. Elrad, S. Clarke, and M. Aksit. Aspect-Oriented Software Development. Addison-Wesley Profes-sional, 2004. ISBN-10: 0321219767.
[11] R. B. France, I. Ray, G. Georg, and S. Ghosh. Aspect-oriented approach to early design modelling. IEE Proceed-ings - Software, 151(4):173–186, 2004.
[12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Addison-Wesley Publishing Company, Inc., Read-ing, 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. Component-Based 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`eles `a objets LMO’2001, volume 7 of L’Objet, pages 11–26, Le Croisic, France, January 2001. Herm`es.
[17] I. Kurtev and K. van den Berg. Mistral: A language for model transformations in the mof meta-modeling architec-ture. 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 Lan-guage 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 com-parison framework for software architecture description lan-guages. 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.oasis-open.org/committees/tc home.php?wg abbrev=wsbpel, 2005.
[23] A. Occello. Capitalisation de la sˆuret´e de fonctionnement des applications soumises aux adaptations dynamiques: le mod`ele ex´ecutable Satin. PhD thesis, Universit´e 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: Architec-ture for component trading and dynamic updating. In Pro-ceedings of ICCDS’98, Annapolis, Maryland, USA, 1998. [26] A. R. and G. D. Formal connectors. Technical Report
CMU-CS-94-115, Carnegie Mellon University, School of Com-puter Science, March 1994.
[27] R. Reddy, R. France, S. Ghosh, F. Fleurey, and B. Baudry. Model composition - a signature-based approach. In O. Al-dawud, T. Elrad, J. Gray, M. K. J. Kienzle, and D. Stein, ed-itors, 7th International Workshop on Aspect-Oriented Mod-eling, Oct. 2005.
[28] E. Roman, S. W. Ambler, and T. Jewell. Mastering Enter-prise 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 desig-nation diagrams: a graphical representation of join point se-lections. 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
Object-Oriented Programming. Addison-Westley, 1999. ISBN: 0-201-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 Lan-guage Specification. OMG Document formal/03-03-01, 2003.
[35] The Object Managemant Group. Revised Submission for MOF 2.0 Query/View/Transformations RFP. OMG Docu-ment ad/2005-07-01, 2005.
[36] J. Warmer and A. Kleppe. OCL: The constraint language of the UML. Journal of Object-Oriented Programming, 1999.
