STUDIO: A COMPONENT-BASED ARCHITECTURE

DESCRIPTION META-MODEL

Extensions to Model Component Behaviour Variability

Cristina Vicente-Chicote, Diego Alonso

Divisi

on de Sistemas e Ingenier

ıa Electr

onica, Universidad Polit

ecnica de Cartagena, 30202 Cartagena, Spain

Franck Chauvel

IRISA, Campus de Beaulieu, 35042 Rennes Cedex, France

Keywords:

Model-Driven Engineering, Component-Based Architecture Description Language, Variability Modelling,

COTS Product Integration.

Abstract:

This paper presents a Model-Driven Engineering approach to component-based architecture description, which

provides designers with two variability modelling mechanisms, both of them regarding component behaviour.

The ﬁrst one deals with how components perform their activities (the algorithm they follow), and the second

one deals with how these activities are implemented, for instance, using different Commercial Off-The-Shelf

(COTS) products. To achieve this, the basic V

Studio meta-model, which allows designers to model both

the structure and behaviour of component-based software systems, is presented. V

Studio takes many of its

elements from the UML 2.0 meta-model and offers three loosely coupled views of the system under develop-

ment, namely: a structural view (component diagrams), a coordination view (state-machine diagrams), and a

data-ﬂow view (activity diagrams). The last two of them, concerning component behaviour, are then extended

in this paper to incorporate the two variability mechanisms previously mentioned.

1 INTRODUCTION

Component-Based Software Development (CBSD)

has proven to obtain highly reusable, extensible and

evolvable designs (Szyperski, 2002). According to

this approach, systems can be built by selecting and

assembling appropriate Commercial Off-The-Shelf

(COTS) components. However, integrating CBSD

(bottom-up) and software architecture design (top-

down) is a non-trivial task which commonly requires

adapting the architecture to make COTS components

ﬁt.

The Model-Driven Engineering (MDE) approach

(Selic, 2003) offers an effective solution for bridg-

ing the gap between architecture design and CBSD.

This approach revolves around the deﬁnition of mod-

els and model transformations. Models represent part

of the function, structure and/or behaviour of a system

(Deelstra et al., 2003), and they are deﬁned in terms

of formal meta-models. Each meta-model includes

the set of concepts needed to describe the system at a

certain level of abstraction together with the relation-

ships existing between these concepts. Model trans-

formations, commonly described as meta-model map-

pings, enable to automatically reﬁne abstract mod-

els into more concrete ones. This process concludes

when the ﬁnal application code is automatically ob-

tained from the lowest level models.

As stated in (Abouzahra et al., 2005), nowadays

there are two main trends in MDE. The ﬁrst one

promotes the use of standard modelling languages

like UML 2.0 (OMG, 2005) or SysML (OMG,

2006), while the second one advocates the beneﬁts

of Domain-Speciﬁc Languages (DSLs). The inclu-

sion of variability mechanisms into meta-models to

enable, for instance, the description of software prod-

uct lines, is currently one of the most active topics

in MDE. However, neither UML 2.0 nor SysML na-

tively support variability modelling, although some

UML proﬁles have been developed to support this

aspect (Ziadi et al., 2003). Nevertheless, as stated

in (B

ezivin, 2005), commonly it is more difﬁcult to

work by restriction (i.e. proﬁling UML) than by

extension (i.e. deﬁning a new DSL). This is why

we decided to deﬁne V

Studio as a new meta-model

(not from scratch but incorporating many of the el-

ements already deﬁned in UML), instead of deﬁn-

ing yet another UML proﬁle. Thus, V

Studio is a

437

Vicente-Chicote C., Alonso D. and Chauvel F. (2007).

V3STUDIO: A COMPONENT-BASED ARCHITECTURE DESCRIPTION META-MODEL - Extensions to Model Component Behaviour Variability.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 437-440

DOI: 10.5220/0001344704370440

 SciTePress

Figure 1: The basic V

Studio meta-model.

general-purpose component-based meta-model which

can deal with behavioural variability, and which can

not be considered a DSL, since it does not include any

domain-speciﬁc concept.

The rest of the paper is organized as follows.

Firstly, the component-based V

Studio meta-model

is presented in section 2. Secondly, the behavioural

variability extensions introduced in this meta-model

are described in section 3. Finally, section 4 outlines

the conclusions and futures research lines.

2 THE V

Studio META-MODEL

The variability mechanisms presented in this paper

are built as an extension to a previously designed

meta-model called V

Studio (see ﬁgure 1). This

meta-model, which takes many of its elements from

UML 2.0 (OMG, 2005), enables a precise description

of component-based software architectures, including

both structural and behavioural features. Actually,

the meta-model encompasses three different views,

namely: a structural view, a coordination view, and

a data-ﬂow view.

As we suggest a component-based approach, the

structural view deﬁnes the system in terms of com-

ponents (either simple or complex) and the intercon-

nections between them. Components provide (re-

quire) services to (from) other components by means

of interfaces, grouped into ports. Component be-

haviour, deﬁned as the set of reactions derived from

its relationship with other components, is described

in terms of a state-machine. Finally, the activities per-

formed in each of the states deﬁned in the component

state-machine are speciﬁed using an activity diagram.

These activities are deﬁned in terms of some inter-

nal actions or making use of the services provided by

other components.

Next, the three views the V

Studio meta-model

has been divided into, are brieﬂy described:

The structural view. System software architecture

can be deﬁned using either a top-down or a

bottom-up approach. In the ﬁrst case, the software

architecture is deﬁned by grouping the main sys-

tem functionalities into high-level components.

Thus, the system is initially considered a com-

plex component built from very high level com-

ponents, assembled using connectors to link their

ports. These high level components are succes-

sively decomposed into simpler ones, until no

more reﬁnements are possible. Conversely, a

bottom-up approach starts from simple compo-

nents, selected to fulﬁl part of the system func-

tionality. These components are linked together

to build more complex functional units, and this

process is incrementally repeated until the ﬁnal

ICSOFT 2007 - International Conference on Software and Data Technologies

438

system functionality is achieved.

The data-ﬂow view. Once the system architecture

has been structurally deﬁned, the behaviour of its

components must be described. Each service pro-

vided by a component is deﬁned in terms of ac-

tivities. Activities represent functional units, such

as functions or blocks in imperative programming

languages. Activities can have input and output

parameters, each one associated to a certain data

type. Activities can be linked together to deﬁne

the execution path, and they can also be grouped

into complex structures to ease their reuse.

The coordination view. Finally, the designer has to

specify how components collaborate with each

other. This collaboration requires specifying

both (1) how components react to messages sent

by other components depending on their current

state, and (2) the (optional) communication pro-

tocol for sending messages or calling services.

The following section presents the modiﬁcations

introduced in the V

Studio meta-model to enable de-

signers to include both data-ﬂow and implementation

variability into their component models.

3 VARIABILITY MECHANISMS

This section presents the data-ﬂow and imple-

mentation variability mechanisms introduced in the

Studio meta-model. For the sake of clarity, two

ﬁgures containing the modiﬁed and newly added ele-

ments in the affected views of V

Studio are included

in each of the following sections.

3.1 Data-Flow Variability

As explained in the introduction, designers often need

to add some variability to the behaviour of compo-

nents. It would be desirable to specify that a ser-

vice can be performed in various ways, using differ-

ent algorithms. To achieve these objectives, the state-

machine part of the V

Studio meta-model is extended

with some new concepts, as shown in ﬁgure 2. As

it can be observed, the new meta-model enforces the

separation between a StatemachineDeﬁnition and the

real Statemachine. It also adds two parallel concepts:

VariableActivity and ActivityBinding. The ﬁrst one is

aimed at deﬁning which activities can vary in those

components that share the same component deﬁni-

tion. The second one speciﬁes the particular activity

executed by the component. All these concepts are

highlighted in ﬁgure 2.

Figure 2: Extension to model data-ﬂow variability.

With this mechanism, variants of the same be-

haviour can be designed by modelling some activi-

ties as parameters. As activities are used to describe

the reactions of components, the behaviour described

by the state-machine is preserved but these reactions

can be customised (Harel, 1987). Modelling compo-

nents this way allows designers to have various com-

ponents that, considered as black boxes, are all ex-

actly the same (so they can be replaced), but consid-

ered as white boxes they are all different, since they

use different algorithms.

3.2 Implementation Variability

Currently, the marketplace offers a wide variety of

COTS products that provide many of the functionali-

ties typically required when developing new applica-

tions. However, generally each of these products uses

its own deﬁned data types, function calling conven-

tions and error handling mechanisms, making it difﬁ-

cult to use them together. In order to allow designers

to incorporate the functionality provided by all these

COTS products, the V

Studio meta-model includes a

wrapping mechanism aimed at encapsulating hetero-

geneous library functions to build homogeneous and

thus inter-connectable implementation units.

This variability mechanism has been added to the

data-ﬂow view of the V

Studio meta-model (see ﬁg-

ure 3). Although the multiplicity of the relationships

is not shown in the diagrams because of a limitation of

the tool, in this case all simple activities contain only

one action. Each action represents a functional block

which might have been imported from one of the ex-

isting COTS libraries. To allow designers to join ac-

tivities containing actions from different COTS, the

PinParamLink connection between activity parame-

ters and action pins must (1) perform the correspond-

ing data type conversion, (2) pass the data to the ac-

V3STUDIO: A COMPONENT-BASED ARCHITECTURE DESCRIPTION META-MODEL - Extensions to Model

Component Behaviour Variability

439

Figure 3: Extension to model implementation variability.

tion using the correct calling convention, and (3) cor-

rectly interpret and handle all possible errors during

the execution.

Allowing only one action into each simple activ-

ity could seem quite restrictive and inefﬁcient (i.e.

linking activities containing actions from the same

COTS will require unnecessary data conversions).

However, designers are free to use actions as com-

plex as they wish into Activities (i.e. complex algo-

rithms implemented using several functions from a

single COTS). Regarding efﬁciency, activity models

built using V

Studio can be easily optimized using a

simple model transformation which avoids unneces-

sary data type conversions when possible.

4 CONCLUSIONS

In this paper we propose an extension to the V

Studio

meta-model, which allows designers to model compo-

nent behaviour variability at early design stages. The

major contribution of this proposal is to enable the

inclusion of variability aspects both into design and

implementation models. Several variants of the same

component can be easily built, while most of the ex-

isting approaches focus on component substitutability

to support product line development.

This approach allows designers to build complete

component deﬁnitions (in which both structural and

behavioural characteristics are ﬁxed) and, optionally,

they can deﬁne the activities that may change be-

tween different components of the same type, by

means of parameterised state-machines. The ex-

tended V

Studio meta-model also considers imple-

mentation variability, that is, how to deal with dif-

ferent implementations of the same functionality pro-

vided, for instance, by different COTS products avail-

able in the marketplace. In this sense, the meta-model

reinforces black-box component reuse.

The work presented in this paper has consider-

ably enriched the previous versions of the V

Studio

meta-model. However, there are still some open is-

sues which must be addressed. Currently we are

working in two main directions, namely: (1) deﬁn-

ing structural variability mechanisms, similar to those

deﬁned in this paper regarding component behaviour,

and (2) including some operational semantics in the

meta-model using KerMeta (Muller et al., 2005).

ACKNOWLEDGEMENTS

This research has been partially funded by the Span-

ish CICYT project MEDWSA (TIN2006-15175-C05-

02) and the PMPDI-UPCT-2006 program (Technical

University of Cartagena, Spain).

REFERENCES

Abouzahra, A., B

ezivin, J., Didonet, M., and Jouault, F.

(2005). A practical approach to bridging domain spe-

ciﬁc languages with uml proﬁles. In Proceedings of

the OOPSLA 2005.

ezivin, J. (2005). On the uniﬁcation power of models.

Journal of SoSyM, 4(2):171–188.

Deelstra, S., Sinnema, M., van Gurp, J., and Bosch, J.

(2003). Model driven architecture as approach to

manage variability in software product families. In

MDAFA 2003, pages 109–114.

Harel, D. (1987). Statecharts: A visual formalism for com-

plex systems. Science of Computer Programming,

8(3):231–274.

Muller, P.-A., Fleurey, F., and J

equel, J.-M. (2005).

Weaving executability into object-oriented meta-

languages. In Proceedings of UML MoDELs 2005,

volume 3713 of LNCS. Springer.

OMG (2005). Uniﬁed modeling language 2.0: Superstruc-

ture speciﬁcation. Ofﬁcial speciﬁcation formal/05-07-

04, Object Management Group, Needham, MA, USA.

OMG (2006). Systems modeling language (sysml

T M

) spec-

iﬁcation. Final Adopted Speciﬁcation ptc/06-05-04,

Object Management Group, Needham, MA, USA.

Selic, B. (2003). The pragmatics of model-driven develop-

ment. IEEE Trans. Soft. Eng., 20(5):19–25.

Szyperski, C. (2002). Component Software - Beyond

Object-Oriented Programming. Addison-Wesley.

Ziadi, T., H

elou

et, L., and J

equel, J.-M. (2003). Towards

a UML proﬁle for software product lines. In Soft-

ware Product-Family Engineering, 5th International

Workshop, PFE 2003, Siena, Italy, November 4-6,

2003, Revised Papers, volume 3014 of Lecture Notes

in Computer Science, pages 129–139. Springer.

ICSOFT 2007 - International Conference on Software and Data Technologies

440