Nabila Salmi
email: nabila.salmi@univ-savoie.fr

Patrice Moreaux
email: patrice.moreaux@univ-savoie.fr

Malika Ioualalen
email: ioualalen@lsi-usthb.dz

Performance evaluation of Fractal component based systems

Keywords: Modelling, performances, component, interaction, CBS, SWN, synchronous composition, asynchronous composition

Component based system development is now a well accepted design approach in software engineering. Numerous component models have been proposed and for most of them, specific software tools allow building Component Based System (CBS). Although these tools perform several checks on the built system, few of them provide formal verification of behavioural properties nor performance evaluation of the resulting system. In this context, we have developed a general method associating to a CBS, a formal model, based on Stochastic Well formed Nets, a class of high level Petri Nets, allowing qualitative behavioural analysis together with performance evaluation of this CBS. The definition of the model heavily depends on the (run time) component model used to describe the CBS. In this paper, we instantiate our method to Fractal CBS and its reference Java implementation Julia. The method starts from the Fractal architectural description of a system, and defines rules to systematically generate elements models of the CBS and their interactions. We then apply a structured method both for qualitative and performance analysis taking into account the given implementation of the Fractal model. The main interest of our method is to take advantage of the compositional definition of such systems to carry out an efficient analysis. The paper concentrates on performance evaluation and presents our method step by step with an illustrative example.

Introduction

Component based technology [START_REF] Szyperski | Component Software Beyond Object-Oriented Programming[END_REF] is an attractive paradigm, widely used for the development of software and hardware systems. In this paradigm, components are developed in isolation or reused from previous works, and are then assembled to build a Component Based System (CBS). The main goals of such approaches are to produce high quality applications, reduce cost and time developments, and achieve more reliability, higher maintainability and easier upgrade. Since the mid'70, a lot of component models have been proposed in the literature, among them EJB, CCM and CORBA, COM+/.NET, Fractal [START_REF]EJB 3.0 specification[END_REF][START_REF]Common object request broker architecture (CORBA) -specification, version 3.1[END_REF][START_REF]Common object request broker architecture (CORBA) -specification, version 3.1, part 2: CORBA interfaces[END_REF][START_REF]Net 3.0 framework[END_REF], and are used in effective applications. Building CBS is supported by sets of tools associated to each component model. These tools allow description of the CBS through Architecture Description Languages (ADL) [START_REF] Medvidović | A classification and comparison framework for software architecture description languages[END_REF] and provide the architect with several checking tools mainly based on syntactic analysis of the description and the source code of the elementary units of the component model (such as components, connectors, interfaces, configuration descriptions). They ensure for instance that interfaces required by one component are provided by another component and that the interconnection between these interfaces is provided either directly or through a compatible connector. Beyond this "static" analysis, the complexity of many CBSs requires verification of behavioural properties such as deadlock-freeness, reachability of some states and so on. This is achieved by defining a formal semantics to the component model and by (model) checking required properties against the semantic model of the CBS. We emphasize that such an analysis should be based on a runtime component model and not only on an architectural component model. Formal semantics of the component model is most often given by a Labelled Transition Systems (LTS) either directly or derived from a higher formal model such as process algebras or state based models (for instance Stat-echarts, Petri Nets) generating a LTS. To cope with the classical problem of the state space explosion (huge size of the LTS of the system), model checking should be based on the formal models of the components and their composition, allowing several levels of component behaviour models (abstraction) [START_REF] Da Silva | Composition of software artifacts modelled using colored Petri nets[END_REF] and merging of several component models into a single one (hierarchy) [START_REF] Kupferman | Compositionality: The Significant Difference[END_REF].

For what concerns performance analysis of CBSs, it is usually carried out through measures on existing systems, whereas predictive performance evaluation remains an important field of application in the perspective of software performance engineering [START_REF] Smith | Performance Engineering of Software Systems[END_REF]. This is the context of our work and we develop stochastic models of CBSs to provide performance indices about them during the design phase.

Here also we should try to take into account the specific, component based, architecture, as for instance [START_REF] Rugina | Aadl-based dependability modelling[END_REF] in the context of dependability modelling using the description language AADL, and [START_REF] Wu | Performance modeling from software components[END_REF][START_REF] Grassi | Filling the gap between design and performance/reliability models of component-based systems: A model-driven approach[END_REF] which start from a UML design model and build a performance analysis model based on Layered Queuing Networks [START_REF] Petriu | Architecture-based performance analysis applied to a telecommunication system[END_REF].

Among component models that gained attention these last years, the Fractal model [START_REF] Bruneton | The fractal component model and its support in java: Experiences with auto-adaptive and reconfigurable systems[END_REF] offers a hierarchical and reflective component model with dynamic configuration, component composition, management and sharing capabilities. A Fractal component is a runtime entity exposing provided and required services through a set of functional interfaces. It is also endowed with a set of control capabilities, defined through control interfaces. Fractal components are assembled to form a software application, either "by hand", that is directly in the Java code, but most often with the help of software development tools, like the Fractal ADL, etc. Fractal CBSs may be developed using several target programming languages (Java, C, C#, SmallTalk). For each language, a reference implementation is defined (Julia for Java, Think for C). Note that a completely specified runtime Fractal CBS cannot be modelled without taking into account specific implementation details, which implies knowing the target language of the application.

In the present paper, we focus on performance analysis of Julia Fractal CBSs based on formal models of the components and systematic building of the formal model of these CBSs. The main advantage of our approach is to exploit as much as possible, the compositional architecture of the system in order to reduce complexity of performance indices computation.

Components and the global system are modelled with the Stochastic Well formed (SWN) formalism [START_REF] Chiola | Stochastic well-formed colored nets and symmetric modeling ap-plications[END_REF], a special class of high level Petri nets, useful to express symmetrical behaviours and allowing performance analysis. Although we can take into account both functional and non-functional aspects of a Fractal CBS within our approach, we concentrate in this work on "stable" configurations, that is to say on Fractal architectures after initialization phase or between We first translate systematically interfaces and interactions between Fractal components in the SWN context. Then for a given Fractal CBS, we suppose given SWN models of the primitive components. Next, from the architecture description of a Fractal system (provided by Fractal ADL), we show how to build the global SWN of the CBS. We have now a global SWN and a set of sub-SWNs modelling the components. Finally, we apply, when possible, a structured method allowing to compute performance indices. In order to apply this structured compositional method, we derive from the architecture of the CBS, a compositional view of the system at the SWN level, and we apply a modified version of our previous works [START_REF] Delamare | Efficient implementation for performance evaluation of synchronous decomposition of high level stochastic Petri nets[END_REF][START_REF] Delamare | Performance evaluation with asynchronously decomposable SWN: implementation and case study[END_REF] which proposed a structured analysis method for either a synchronous or asynchronous decomposition of SWNs. This method is based on a combined aggregation/tensorial representation of the underlying Markov chain of the global SWN.

The paper is organized as follows. Section 2 reminds main features of the Fractal component model and introduces an illustrative example. Section 3 presents the general method we have developed for behavioural qualitative analysis and performance evaluation of CBSs. Then, we describe in section 4 application of our method in the Fractal CBS case, providing a SWN based formal model of any such CBS. Section 5 shows how to manage a structured performance analysis of the model built previously and presents some results for the illustrative example. We conclude and describe future work in section 6.

The Fractal Component model

Fractal [START_REF] Bruneton | The fractal component model, version 2.0-3[END_REF][START_REF] Bruneton | The fractal component model and its support in java: Experiences with auto-adaptive and reconfigurable systems[END_REF] is a general component model developed within the consortium ObjectWeb by France Telecom R&D and the INRIA. It is intended to implement, deploy, monitor and dynamically configure complex software systems, including operating systems and middleware.

Main features

A Fractal component is a runtime entity that interacts with its environment (i.e. other components) through well-defined interfaces (figure 1 1 ). An interface is an access point to a component, that specifies provided services or required services exposed by other components. There are two kinds of interfaces: server interfaces correspond to points accepting incoming operation invocations, and client interfaces support outgoing operation invocations.

A Fractal component possesses two parts: a content part and a controller part. The content part consists of a finite number of other components, called sub-components, making the model recursive and allowing components to be nested at an arbitrary level. At the lowest level, a Fractal component is a black box, called base or primitive component, that doesn't provide introspection or intercession capabilities. A Fractal component whose content is not empty is said composite.

The controller part, termed the membrane, provides a set of control interfaces, supporting introspection (monitoring) and reconfiguration of internal features of the component, such as suspending and resuming activities of a subcomponent. A component may be shared by several enclosing components. In this case, it is subject to the control of their In order to define the architecture of an application, Fractal components are connected by bindings (see figure 2) i.e. connections between two or more components. The Fractal model specification defines primitive and composite bindings. A primitive binding is a direct connection between a client interface and a server interface. It can be a normal binding when the client and server interfaces are external, and the corresponding communicating components have a direct common enclosing component. It can also be an export binding, respectively an import binding, when the client interface is internal, and the server interface is external, and the component exposing the service (server) is a sub-component of the other (respectively, the client interface is external, and the server interface is internal, the component requiring the service (client) is a sub-component of the other). Whereas, a composite binding is a communication path between an arbitrary number of component interfaces. It is itself a Fractal component, built out of a combination of primitive bindings and ordinary components. Hence, binding generalizes the notion of connector in other component models.

The Fractal model specification defines a set of constraints on the interplay between functional and non functional operations, namely:

-Content and binding control operations are possible only when the component is stopped. -A component can emit or accept invocations when started.

-A component does not emit invocations when stopped, and must accept invocations through control interfaces.

In order to define component architectures for the Fractal model, an open and extensible language has been developed: the Fractal Architecture Description Language (ADL) [START_REF] Bruneton | Fractal ADL tutorial[END_REF]. As its name implies, an ADL definition describes a component architecture, and only that, i.e. its does not describe the resulting runtime system. It is made of an open and extensible set of ADL modules, where each module defines an abstract syntax for a given architectural "aspect", such as interfaces, bindings, attributes or containment relationships.

Fractal ADL is an XML based ADL that can be used to describe Fractal component configurations. In this paper, we only consider the ADL aspects of Fractal ADL. In fact, it is also the name of a toolchain framework allowing introduction of new tools in the generation process of a Fractal based application.

Fractal ADL is strongly typed. The first step to define a component architecture is therefore to define the types of the components. Each component type must specify what components of this type provide to, and require from other components. The definition of a primitive component is done by specifying the interfaces it provides, the interfaces it requires, and the class that implements this component.

A composite component is similarly defined by specifying its interfaces, the sub components it contains, and bindings between these sub components and with the composite component itself. Component definitions are then defined by extending existing definitions. The extension mechanism is similar to class inheritance, i.e. a sub definition can add and override elements in its super definition. This mechanism can be used to define concrete components as sub definitions of abstract component definitions.

Once the application's architecture has been defined, it can either be compiled, which gives a Java class (for the Julia implementation), in source code, or it can be directly interpreted. In both case, the Fractal ADL parser performs preliminary verifications to check the architecture and, in particular, to check that there is no missing or invalid binding.

Example: the Comanche application

Along the paper, we use an effective example to illustrate our method. This example consists of a minimal HTTP Server, Comanche, used in [START_REF] Bruneton | Tutorial: Developping with fractal[END_REF] to illustrate how to implement and deploy Fractal component based applications. This server accepts connections on a server socket and, for each connection, starts a new thread to handle it. Each connection is handled in two steps: the request is analyzed and logged to the standard output, and then the requested file is sent back to the client (or an error is returned if the requested file is not found).

Two main services are identified at a high level of the Comanche architecture, namely a request receiver service and a request processor service. At a lower level, the request receiver service uses a scheduler service, responsible of creating a new thread for each request. The scheduler service can be implemented in several ways: sequential, multi thread, multi thread with a thread pool, and so on. We suppose in our case that it is multithread.

In order to process the request, a request analyzer service and a logger service are used before effectively responding to a request. This response is itself constructed by a request dispatcher service, that uses a file server service, or an error manager service. The request dispatcher service dispatches requests to several request handlers sequentially, until one handler can handle the request (we can then imagine file handlers, servlet handlers, and so on).

In terms of components, the application defines a component for each service, leading thus to seven primitive components: (request) Receiver, (request) Analyzer, (request) Dispatcher, File (request handler), Error (request handler), Scheduler and Logger (see figure 3). Some of these components are encapsulated in composite components: The Receiver and Scheduler components are included in the Frontend component, the Dispatcher, File and Error components make up the (request) Handler component, and this latter together with the Analyzer and the Logger make up the Backend component.

The Frontend and Backend composite components are themselves contained in the Comanche server application, which is the highest level component.

A general method for analysis of CBSs

As mentioned in the introduction, we have developed a general method for behavioural qualitative and performance analysis of CBSs. Before explaining the application of the method to Julia Fractal CBS, we present the main lines of the method. The method is based on the Stochastic Well-Formed Petri Net model (SWN), a high level (coloured) model of Petri net with probabilistic extensions for performance analysis. Our choice of the SWN formalism is first motivated by the fact that we need a state based model to be able to evaluate performance indices related to configurations of the systems (number of requests pending in some part of the system, mean usage time of some resource, etc.). Petri Nets are state based models which are well known for being able to model complex systems with concurrency and conflicts, even in the stochastic context, in contrast with Queuing networks or process algebras models for instance. Moreover, although Petri Nets are not by themselves a compositional model, interaction between Petri nets representing sub-components may be easily defined as transition or place "fusion" (merging). If complex primitive components are involved, high level Petri Nets are almost inevitably required so that the SWN model is nicely adequate. The SWN model can also take advantage of behaviourial symmetries of system's entities if there are such symmetries. Finally, SWNs are a well studied class of high level stochastic Petri nets and benefit from a large set of analysis algorithms and tools. Among formal models of Fractal CBSs, [START_REF] Barros | Model checking distributed components : The vercors platform[END_REF] also proposes an approach for specification and verification, but based on LTS derived from communicating automata networks [START_REF] Arnold | Nivats processes and their synchronization[END_REF][START_REF] Arnold | Finite transition systems: semantics of communicating systems[END_REF]. However, this work is devoted to the Fractive [START_REF] Baude | From distributed objects to hierarchical grid components[END_REF] implementation of the Fractal component model and does not allow us to compute performance indices of Fractal CBSs.

The Well formed and the Stochastic Well formed Petri nets models

A Well-formed (WN) net [START_REF] Chiola | Stochastic well-formed colored nets and symmetric modeling ap-plications[END_REF] is a high level Petri net model. It is a coloured Petri net, where places and transitions are provided with a structured type of tokens.

In this model, tokens are grouped into basic classes called colour classes. These classes are bringed together to form a colour domain, which is associated to places and transitions. Colours of a place label its tokens, whereas colours of a transition define possible firings of the transition. Thus, an initial marking of a place is defined as a multiset (bag) of coloured tokens. A colour function is attached to each arc: its role is to define for, a given colour of the associated transition, the number of coloured tokens to add or to remove from the attached place.

A colour domain is a Cartesian product of colour classes. A total order, expressed by a successor function, can be defined on a colour class. The Cartesian product defining a colour domain can be empty (for example, in the case of a place containing neutral tokens). It can also contain repetition of a class (modelling internal synchronization of this class). A colour class, grouping colours of same nature (eg. processes, resources), can be divided into static sub-classes, where a sub-class contains colours with identical behaviours, even in terms of performance.

A colour function is built from standard operations (linear combination, composition, etc) of basic functions. The projection (denoted by X or X j i in figures) selects an element of a tuple; it is represented by a typed variable or by X if no confusion is possible. The synchronization/diffusion (denoted by Si or Si, k) returns the set of all colours of a class (Si) or a sub-class (Si, k). The successor function is defined for ordered classes only and returns the colour following a given colour.

A transition or an arc function can be guarded by an expression which is a linear combination of atomic predicates. An atomic predicate expresses the equality of two variables, or restricts the colour domain of a variable to a static subclass [START_REF] Chiola | Stochastic well-formed colored nets and symmetric modeling ap-plications[END_REF]. A predicate is evaluated on colours of a transition firing.

The structured definition of a WN allows us to exploit automatically system symmetries, by compacting its reachability graph, leading to a Symbolic Reachability Graph (SRG). An SRG is composed of symbolic markings, where each symbolic marking represents a set of ordinary (coloured) markings having equivalent behaviours (see [START_REF] Chiola | Stochastic well-formed colored nets and symmetric modeling ap-plications[END_REF] for more details). Several qualitative properties can be checked on the SRG (reachability of a marking, deadlock freeness, etc.) From WNs was derived the Stochastic Well-formed (SWN) model, which associates to each transition an exponentially distributed delay. This delay can depend on static sub-classes of the colours considered at firing. The SRG of an SWN, augmented with stochastic firings information, results in an aggregated Markov chain of the chain derived from the coloured net. Thus, we can study performances of a system directly on this aggregated chain. Formal definitions of WN and SWN are given in appendix A. The method starts by building a global SWN for a CBS, viewed as a composition of SWN models of components and interconnections. Then, a structured analysis method is applied for deriving performance indices.

Before giving details on the approach, we introduce some terms related to component models used in the sequel.

Terminology

Component SWNs An element of a CBS (component or connector) is modelled with an SWN model. This model is built from the component content behaviour or implementation and predefined sub-models modelling interfaces. The component content can be a simple component in case of a primitive component, or connected sub-components in composites. The primitive component behaviour is modelled by a SWN by an expert, where places correspond to data storage resources, state of active entities, etc. and transitions to activities consuming data and producing other data. The composite component behaviour consists of an interconnection of its sub-components behaviours with adapted interaction (or connector) components. We term Component SWN (C-SWN) models of primitive or composite components. Obviously, obtained C-SWNs can be gathered into libraries, and reused possibly later.

The translation of an interface of a component in the corresponding C-SWN is heavily dependent on the semantics of the runtime component model. In general, it is a subnet of the C-SWN which may consist of just a set of places, a set of transitions, or can be more complex with a combination of places and transitions. We provide translation of interfaces for Julia Fractal CBS in the next section.

Interaction SWNs Components are related by interaction relationships described in the architecture description, and so are the C-SWNs. This interaction relationships between C-SWNs are translated into Interaction SWNs (I-SWN). An I-SWN connects two interfaces of distinct C-SWNs. I-SWNs could be more or less complex SWNs; in the Julia Fractal case, we will show that functional interfaces could be directly interconnected, so that I-SWNs are useless.

Global SWN model of the CBS

The global SWN (G-SWN) of a CBS is built from the set of C-SWNs and their corresponding I-SWNs. The C-SWNs are composed together with I-SWNs, through fusion of interfaces elements, obtaining thus a global model.

Steps of the method

We can describe our method into five main steps. The first three of them are devoted to the construction of the global SWN of a CBS and its compositional structure, and the two other steps aim to perform the analysis of the system:

1. Translation of the ADL description of the CBS, together with the description of components behaviours (i.e. source code), into the SWN framework, leading to a set of C-SWNs and a set of I-SWNs. 2. Modification of the C-SWNs and I-SWNs so that to be composable with others, in the sense of Petri net composition (fusion of places or transitions). This modification should not impact the semantics of the modelling. The set of obtained models are called Composable Component SWNs (CC-SWNs) and Composable Interaction SWNs (CI-SWNs). 3. The CC-SWNs and the CI-SWNs are then composed together through fusion of element interfaces, providing the global G-SWN model corresponding to the whole system. CC-SWNs and CI-SWNs are now seen as a unique set of subnets SWN 1 , . . . , SWN K ′ (see figure 4, step 3). 4. We then start from the set of SWN k k∈{1,...,K ′ } . We search the set of SWNs (N k ) 1≤k≤K" representing a possible decomposition of the G-SWN, that fulfill conditions for a structured representation of the SRG and its aggregated generator (see section 5.1). These SWNs can be one of (SWN k ) 1≤k≤K ′ or a groupment of a subset of them. 5. When conditions are satisfied, the structured analysis method is applied to compute performance indices (see section 5).

Mapping Julia Fractal CBS to SWN models

In this section, we address the SWN modelling of Julia implementation of a Fractal CBS, following the method presented above. We assume that the CBS is defined through an ADL description and a set of Java classes corresponding to the primitive components.

General considerations

Modelling stable configurations and dynamics of Fractal CBS

The architecture of a Fractal CBS is defined first by an initial configuration and then may evolve through runtime reconfigurations. Although the capability of runtime evolution of the architecture is a leading property of Fractal CBSs, we claim that behavioural analysis of Fractal CBSs cannot be efficiently carried out with a single formal model of the system. In fact, any modification of the structure (binding changes, addition or deletion of sub-components, etc.) requires a specific modelling, primarily devoted to check that, starting from a configuration A, the application will eventually reach a given configuration B. In contrast, analysis of a configuration (say A or B) addresses both qualitative (reachability, deadlock freeness, etc.), and quantitative (computation of performance indices) aspects of this configuration. Moreover, in the performance evaluation context, switching from A to B probably corresponds to a "short" time period (transient phase), whereas performance indices of software systems are mainly computed over long periods (steady-state analysis).

In the present work, we do not address the verification of the reconfiguration behaviours of Fractal CBSs and we concentrate on "stable" (i.e. fixed) architectures. Hence, since control interfaces of Fractal components are used to manage the initialization and reconfiguration phases of the architecture, we do not model control interfaces.

Note however that we can compare performances of two configurations A and B, studying each one with our method. We have then two G-SWNs and two sets of SWN subnets.

Implementation dependencies

Since we wish to derive performance indices of a Fractal CBS, we emphasize that the architecture description of the CBS does not allow alone performance modelling: it must be complemented with information from the implementation of the component model. We can find in the literature several Fractal implementations developed in Java and C: Julia (the Java reference implementation), Fractive [START_REF] Baude | From distributed objects to hierarchical grid components[END_REF] and AOKell [START_REF] Seinturier | A component model engineered with components and aspects[END_REF] in Java, and Think [START_REF] Fassino | Think: A software framework for component-based operating system kernels[END_REF] the C implementation. Studying these implementations, we noted that they differ significantly. For instance, Fractive uses an asynchronous (late) operation invocation which allows the client to continue processing until it needs results returned by the service. In contrast, Julia and Think use a classical synchronous (blocking) method call. In this paper, we model the Julia implementation of Fractal.

Colours

Basic colour classes can model either data entities or active entities of components. Data entities consist of data flow such as requests, parameters of requests, results or even resources. Active entities are execution flows (processes and threads).

We can illustrate colour semantics by basic colours used in the Comanche example. We consider sockets, HTTP requests, files, streams, and even threads as our basic colour classes. In our model, as we abstract some component details, we use the following basic colour classes: UC models HTTP User requests, IDS models scheduled threads, IDL is the basic class of Log requests, IDF that's of File requests, and IDE models Error identifications.

Translation to SWN models

Building the G-SWN of a Fractal CBS starts from the low level of architecture, and goes up into the higher levels of architecture until reaching the highest level.

First, primitive components are modelled, leading to a set of C-SWNs. Obviously, abstraction may be used at this stage by selecting an appropriate level of details of primitive components. At the highest abstraction level, the content of a primitive component can be modelled by a very simple SWN (see figure 13). Modelling a component requires modelling its interfaces. Functional interfaces are modelled by transitions of the SWNs (see details below). The obtained C-SWN of a component is transformed into a CC-SWN, with the translation of functional interfaces to the adequate form as it is explained later. Next, based on bindings between components, composite components of higher levels are translated by assembling CC-SWNs of enclosed subcomponents. From this translation, we obtain also a CC-SWN for each composite component. This CC-SWN may also be simplified to abstract some detailed behaviours as for primitive components (see below and figure 13).

Functional interfaces

Functional interfaces of a component consists of a required (client) interface which needs a service from other components, or an offered (server) interface exposing a service to others. For a composite component, these interfaces, said external, allow to do export and import bindings, connecting thus sub-components interfaces to functional interfaces of the enclosing composite component. In each case (external or not), a functional interface is modelled with a set of coloured places and transitions as given by the following mapping rules.

Mapping rule 1 A server interface of a component, identified by a set of colours STh modeling possible server threads, offering a set MP of operations or methods with their parameters, is modeled by representing the beginning of service provided and its ending with two transitions, respectively t BPS and t EPS (figure 5 The model of a server depends a priori on the invoked method and its parameters. In our mapping rule, we do not separate them: if such a level of detail is required for per- formance analysis, a colour class is defined with static subclasses sorting the possible pairs (method, its parameters) into disjoint subsets. For instance, when the modeller interest is to know whether the size of data sent between components impacts the overall performance of the architecture, he should model the data parameter. Note that if the pair is irrelevant for a given level of detail, we simply omit this colour class.

Mapping rule 3 defines the CC-SWN, extending the client interface part of a C-SWN to allow composition of SWN and subsequent structured analysis, without modifying the semantics of the component.

Mapping rule 3: CC-SWN for clients

The client interface of a C-SWN is modified, leading to a CC-SWN, by adding a place (and associated arcs) as a postcondition of the beginning transition t BRS and as a precondition of the transition t ERS . (see the left side of figure 5 Mapping rule 4: Multiple clients for one server The server interface of a CC-SWN having multiple connected clients is modified as follows with respect to the single client case: (i) The transitions t BPS and t EPS of beginning and ending service are duplicated as many times as the number of clients;

(ii) An IDC colour class is used to distinguish between several components exposing a client interface. The resulting interface is given by figure 6, right.

Primitive components

The C-SWN of a primitive component is built through several steps:

-Initially, model the "core" of the Fractal component behaviour by an SWN. This is done by analyzing the Java code of the component and fixing a level of details of the model. -For each set of methods related to a server interface, model the server interface using mapping rule.

- The analyzer receives requests on its server interface using two basic colours classes IDA and MA, modelling respectively identified analysis requests and related invoked methods with their parameters. It invokes two operations through two client interfaces: a log operation, and a handle operation. First, we model the core of the component, getting the SWN of figure 7. Then, we add explicit server and clients interfaces introducing request and result transitions for each interface. This gives us the C-SWN of figure 8. Next, this one is completed with places and arcs to get the CC-SWN of figure 9 (bottom).

Considering the Comanche example, figures 9, 10, 11 and 12 show the CC-SWNs of the seven components:

-The receiver exposes a server interface which uses two basic colours classes IDC and M, modelling respectively identified clients and method with their parameters. This component creates for each received request a task, and sends it to the scheduler to schedule it by creating an associated thread. Once the thread is started, it invokes an analysis request. Thus, the receiver has two client interfaces: one for invoking a schedule request and another for asking for a request analysis. -The scheduler has only one interface which is of server type. It uses two basic colours classes IDS and MS, modelling respectively scheduled threads associated to requests and related invoked methods with their parameters. -The analyzer: see above.

-The dispatcher processes handle operations received on its server interface, by dispatching them to either the file We note that there is no server interface with multiple clients in this application, so that identities of the client component are not modelled in the CC-SWNs.

Composite components

A composite component is made up of a set of interconnected sub-components being primitive or composite themselves. We assume that CC-SWNs of its sub-components are built. Building of the SWN model of the composite requires connecting sub-components' CC-SWNs and modelling external interfaces.

In the Julia context, primitive binding of interfaces are directly translated by transition fusion of the CC-SWNs of the corresponding sub-components: associated transition (for instance Invoke service-Receive request and Receive result-Send result in figure 5) are pairwise merged; Fusion of two transitions consists in defining a unique transition and keeping associated arcs of fused transitions. Colour classes of the two transition are mapped in one to one correspondence for common parameters of the interface (name of a method for instance) and specific colour classes of each transition are kept. Hence, the colour domain of the fused transition is the Cartesian product of colour classes of the fused transition, without repetition, together with the specific colour classes of each transition. This fusion definition is different from the proposed approach of [START_REF] Bernardi | Implementing compositionality for stochastic Petri nets[END_REF] where several transitions can be fused but some arcs may be duplicated on several fused transitions. We have then a CC-SWN partially modelling the composite component It is completed by modelling external interfaces as specified in mapping rule 3. As mentioned above, we can also build an abstract model of a composite component from this CC-SWN. At the highest abstraction level, we get a very elementary CC-SWN shown in figure 13.

When assembling CC-SWN models of sub-components, name conflicts (of place, transition or colour class) may occur. They are eliminated by renaming. Such a renaming re- Note that, together with the CC-SWN of the composite, we keep track of the CC-SWNs of its sub-components; They will be used during the analysis phase.

Modelling the highest composite component

Starting from the first level of composite components, we successively build the CC-SWNs of the composite components up to the highest level. The resulting CC-SWN is then completed to provide the G-SWN of the application: Since we model applications with finite state space models, we need to "close" interfaces of the composite corresponding to the application as a whole. This is a classical method, allowing to limit the number of entities in the model. In the Petri net context, we add a Petri net to each external interface of the application with an adapted initial marking, generally an upper bound of the number of entities. An example of such a closing SWN is given in figure 14.

We summarize this modelling in the following algorithm allowing the building of the CC-SWN of a composite of N hierarchichal levels, and so the building of the G-SWN.

G-SWN (composite CC-SWN) building algorithm BEGIN

Let N be the number of levels of the composite (CBS). 1. Model primitive components of level 0. 2. For (i=1; i<N; i++) a. For each composite C of a level i : (i) Assemble CC-SWNs of components of level i-1:

For each couple of sub-components related with a service invocation, merge corresponding transitions (TBRS,TBPS) and (TERS,TEPS). (ii) Each import/export binding defined in the Fractal ADL and related to the composite C corresponds to an external interface of C. b. Model primitive components of level i. 3. Close external interfaces of the highest level component with a closing Petri net. END

G-SWN of the Comanche application

Going back to our Comanche example, we can build the CC-SWN of the request handler composite component, then

Performance Analysis of Fractal CBSs

Analysis of a Fractal CBS can be performed through the analysis of the G-SWN obtained from the assembly of components. This approach has been followed in [START_REF] Bernardi | Implementing compositionality for stochastic Petri nets[END_REF] for analysis of a different composition process of SWNs, and implemented in the Algebra tool of the GreatSPN package [START_REF] Group | GreatSPN home page[END_REF]. In our approach, we rather try to benefit from the compositionality features of the CBS, in order to provide an efficient steady-state performance analysis with regard to computation time and memory costs. For this purpose, we rely on previous work [START_REF] Delamare | Efficient implementation for performance evaluation of synchronous decomposition of high level stochastic Petri nets[END_REF][START_REF] Delamare | Performance evaluation with asynchronously decomposable SWN: implementation and case study[END_REF] which defines an analysis method allowing to avoid the explicit construction of the aggregated Markov chain corresponding to the global SWN. This method uses a tensorial representation of the Symbolic Reachability Graph(SRG), hence enabling important memory and com- putation time savings, reducing analysis complexity. We adapt this approach to Fractal CBS.

Principle of structured analysis method

The structured analysis method was defined to apply on a global SWN N. The main idea in this method is to start from a global SWN, decompose it into several subnets, and study each subnet augmented with "parts" aggregating interactions with other subnets. These separated studies are then used to derive a tensorial representation of the generator of the underlying aggregated Markov chain of the global net, and so to compute performance indices. For this purpose, two kinds of decompositions into SWNs were defined:

-A "synchronous" decomposition (figure 16) modelling a complex synchronization of type "Rendez-vous" between two SWNs. -An "asynchronous" decomposition (figure 17) which corresponds to an asynchronous method call or a message sending and receiving between two or more SWNs. Each kind of decomposition requires a set of conditions which can be checked at the SWN definition level. We refer the reader to [START_REF] Haddad | Aggregation and decomposition for performance evaluation of synchronous product of high level Petri nets[END_REF] for a detailed presentation of these conditions. We have extended and adapted this initial decomposition method to CBS. Adaptation was faced to three problems:

1. The first problem is to compose SWN models of components, as we start from the definition of components in the case of a CBS. This is in contrast to the previous method where a global SWN is decomposed into several subnets. Composition of SWNs in the Fractal framework has been explained above. 2. The second problem is to try bringing an interconnection of components into a synchronous or asynchronous composition of SWNs. This problem depends on the component model of the CBS. In the context of the Julia implementation of Fractal CBSs, we noted that service invocations of a component are in fact synchronous method calls. Thus, we model interactions between Fractal components with synchronous compositions of their corresponding SWN models as shown in the previous section. 3. The third problem consists of studying the impact of the simultanous presence of synchronous and asynchronous compositions in the same global model, as the structured method was defined for either a synchronous composition or else asynchronous composition of SWNs. In this paper, this problem does not appear, as we model Fractal components interactions with only synchronous compositions.

Structured CBS analysis algorithm

Our adapted method proceeds in several steps for analyzing a CBS. We assume that the G-SWN model of the application and the CC-SWNs of the components have been defined. These CC-SWNs make up the initial set of SWNs subnets denoted by

N k (1 ≤ k ≤ K ′ ):
1. Checking applicability conditions on the G-SWN for a structured representation of the SRG and its aggregated generator. if they are fulfilled, goto 2 else merge some of the CC-SWNs which do not satisfy applicability conditions to new SWNs trying to fulfill conditions. Each new SWN replaces the SWNs it stands for. Goto to 1. 2. Extension of the SWNs N k to autonomous SWNs N k , in order to take into consideration interaction with other subnets. These autonomous SWNs are called extended nets (see [START_REF] Haddad | Aggregation and decomposition for performance evaluation of synchronous product of high level Petri nets[END_REF] for details). 3. Generation of the SRGs of these extended SWNs. We apply this method to SWNs models of Julia Fractal CBSs presented in section 4. For what concerns conditions for synchronous composition of SWNs (point 1 above), one important property must be verified: an entity of a subnet which could be synchronized (i.e. linked to an entity of another subnet during common actions) must be, at any time, either not synchronized, or else synchronized with only one entity of another subnet. This means, at the programmatic level, that such entities should not be duplicated, for instance with concurrent threads or processes, in a given component. Structured analysis of a composition of SWNs is interesting as long as it allows for savings w.r.t. computations based on the wole G-SWN. The granularity of composed SWNs is indeed a very important parameter w.r.t. the computation time of the performance indices. Roughly and in a very imprecise way, a "large" number of "small" SWNs implies a bigger computation time than a model where "some" SWNs are merged. This is particularly due to the time taken to study each extended SWN, which exhibits more behaviours than the corresponding part of the whole system. We deduce that component oriented design could be quite different from component oriented analysis. Unfortunately, we think that there are no general rules on the structure of the model allowing estimation of the granularity level for best computation time. However we are working on definition of some heuristic guidelines to help the modeller in the merging process for what concerns this computation time.

Application to the Comanche example

The obtained G-SWN of the Comanche application satisfies conditions of structured analysis. So, we did not need to merge some CC-SWNs. We used our tool compSWN to apply our method and compute steady-state probabilities. We also used the GreatSPN environment on the G-SWN to compare results of both analysis methods. We ran the two tools on a Suse linux 9.2 workstation with 512 MO.

Savings with the structured method

Before giving some performance indices of the Comanche example, we first show time and memory savings due to the use of the structured analysis. To this end, we vary the cardinalities of our basic colour classes, and we study the be- We also indicate the state space sizes of the global net. Notations for tables 1 and 2 are the following: |Colour| is the cardinality of the static colour subclass, NbS is the number of symbolic markings, NbO is the number of ordinary markings, TGreat is the computation time of GreatSPN, TComp is the computation time of compSWN, MGreat is the memory used by GreatSPN and MComp is the memory used by compSWN. Note that with our method and tool, we are able to compute the SRG of the G-SWN and its steady-state probabilities for all given configurations, while the computation was not possible with the GreatSPN tool for certain configurations (Cf6, Cf7, Cf8) because of the huge size of state space.

Performance results for the Comanche example

In this paper, we only present some of the results we have gathered and refer the reader to a forthcoming research report for a fully detailed performance analysis of the example.

Parameters of the system First, we present results for only one configuration (Cf4) of the system. Note that a colour may model a group of elementary entities, for instance a request colour can stand for 10, 100 or 1000 requests; obviously, firing rates of transitions involving this colour should be adapted to the semantics of a colour (100 requests provide a possibly 100 times (or more) slower method request

Response time variations

We are mainly interested in computing variations of the response time with respect to several parameters: the load induced by client's requests, the rate of the analysis request, the rate of file or data retrieval and the error rate. Figure 18 shows response time variations with respect to the first two parameters. From the left diagram, we see that the CBS presents a slightly better response time as far as the client requests arrival duration increases. This a priori contradictory behaviour indicates that the system is not saturated until request arrival rate of 2. Indeed, the curve becomes flatter when the request arrival rate increases. The right diagram shows a reduced response time with the increasing of request analysis rate. This was expected since the system becomes more powerful with higher request analysis rate. However, we observe that the response time first shuts down significantly and then (0.4 and more) becomes almost stable. This phenomenon proves that the analysis is no more the bottleneck of the system for rates higher than 0.4.

Response time analysis could be completed by steadystate probabilities of markings in several components of the system.

Conclusion

In this paper, we have presented a method allowing to study, in an efficient way, performance indices of Fractal Component Based Systems (CBS), restricted to stable configurations (i.e. without reconfiguration) of the CBSs. We quote that implementation semantics heavily impact modelling Fractal CBSs and must be taken into account by any modelling method. In this work, we model Fractal CBS using Julia, the Java reference implementation of the Fractal component model.

The presented method is an instance of a general method for analysis of CBSs. It starts from the description of a Fractal application, given by its description expressed in the Fractal Architecture Description Language and the Java source code of the primitive components. For each component, we build a SWN model (the CC-SWN) describing its functional behaviour and its interfaces. The CC-SWNs are then interconnected following the architecture of the system, beginning from primitive components up to the highest level composite component for which we provide a global SWN (the G-SWN). We then apply, whenever possible, to the G-SWN and the CC-SWNs, a structured analysis method to compute performance indices of the system. This analysis is based on synchronous composition of SWNs we have previously developed. We show that our model of Julia Fractal CBS can indeed be analyzed with this approach which provides important savings in computation time and memory usage during the analysis. We illustrate our method with the HTTP server Comanche application. Results are computed with the help of our compSWN tool. Detailed performance analysis of this example will be available in a forthcoming research report.

Work in progress will first partially automate extraction of information from the description of the CBS for direct definition of the interfaces of the CC-SWNs. Moreover, gains of the structured analysis being dependent on the number Fig. 18: Response time versus request arrival rate (left) and request analysis rate (right) and the size of SWNs making up the global SWN, we are studying some heuristic rules to merge subnets of the model for better analysis times. Finally, we are working on modelling reconfiguration features of Fractal CBSs and verification of their behaviours.

Fig. 1 :

 1 Fig. 1: The Fractal component model

  Several control interfaces have been defined in the Fractal model specification, namely: -The Life cycle Controller (LC) manages the component life cycle, in support for dynamic reconfiguration. Basic methods supported are starting and stopping the execution of the component. -The Binding Controller (BC) manages connections or bindings to other components. It allows to bind and unbind interfaces of communicating components (see below). -The Content Controller (CC) provides content operations such as listing, adding and removing sub-components. -The Attribute Controller (AC) exposes getter and setter operations for attributes (configurable properties, service attribute in the figure) of a component. The membrane of a component can have external and internal interfaces. External interfaces are reachable from outside the component, while internal interfaces are only reachable from its sub-components, and are not visible from the outside. External interfaces of a sub-component are exported by interceptors as an external interface of the composite parent component. Interceptors may introduce specific operations between incoming and outgoing operation invocations of an exported interface.

Fig. 2 :

 2 Fig. 2: Bindings between Fractal components

Fig. 3 :

 3 Fig. 3: A Fractal application: the Comanche Server

Fig. 4 :

 4 Fig. 4: Analysis method of a CBS

Fig. 5 :

 5 Fig. 5: SWNs models of interfaces: Client(left), server(right)

Fig. 6 :

 6 Fig. 6: CC-SWNs interfaces with multiple client interfaces for one server interface

Fig. 7 :

 7 Fig. 7: SWN model of the core of the analyzer component

Fig. 8 :

 8 Fig. 8: C-SWN model of the analyzer component

Fig. 9 :Fig. 10 :

 910 Fig. 9: CC-SWNs of the receiver (up) and analyzer (bottom) components

Fig. 11 :

 11 Fig. 11: CC-SWNs of the scheduler (up) and logger (bottom) components

Fig. 12 :

 12 Fig. 12: CC-SWNs of the File handler (up) and Error handler (bottom) components

Fig. 13 :Fig. 14 :Fig. 16 :Fig. 17 :

 13141617 Fig. 13: A very abstract CC-SWN of a component

4 .

 4 Computation of the synchronized product of these SRGs and of the tensorial representation of the generator of the underlying aggregated Markov chain. 5. Computation of the steady state distribution of the aggregated model and computation of the required performance indices. 6. Expression of the results in the initial context of the components.

  (right)). t BPS is controlled by two places ServTH and SoMP modeling respectively server threads and methods with their parameters. Possibly, a third place ResServ coloured with a basic class R is used modeling specific resources needed during execution of a service. Whereas, t EPS is controlled with a place Result coloured with tuples belonging to ST h × MP × R modeling the result of request processing.

	Mapping rule 2 A client interface of a component, iden-
	tified by a set of colours CTh modeling possible request
	threads of the client component is modeled with two tran-
	sitions t BRS and t ERS representing the beginning of service
	request and its ending (figure 5, left). t BRS (resp.t ERS ) is con-
	trolled by a place PBegReq (resp. PEndReq) coloured with
	CTh and modeling respectively requesting and released client
	threads.

  , right). The colour domain of this place is either CT h × ST h or else CT h ×ST h × IDC when several client components, identified with the IDC colour class, require the same service (see below).

	T10 <ida,ma,pa> IDA,MA,PA P15	<ida,ma,pa>	LogRequests IDA,MA,PA
	P16	T11 <ida,ma,pa>	<ida,ma,pa>	P4
	IDA,MA,PA		IDA,MA,PA
	<ida,ma,pa>
	T22
	<ida,ma,pa>
	IDA,MA,PA P27 <ida,ma,pa> T28	<ida,ma,pa>	dispatchRequests IDA,MA,PA
	P28	T17 <ida,ma,pa>	<ida,ma,pa>	P9
	IDA,MA,PA		IDA,MA,PA

  Model internal activities to the server interface, if modelling details are required.

	-For each service invocation, model the client interface
	using mapping rule 2.
	Let us illustrate building of the CC-SWN of a primitive
	component with the analyzer component of the Comanche
	application. The implementation code of this component is
	given below.
	public class RequestAnalyzer implements RequestHandler
	{
	private Logger l;
	private RequestHandler rh;
	// functional concern
	public void handleRequest(Request r) throws IOException
	{ r.in = new InputStreamReader(r.s.getInputStream());
	r.out = new PrintStream(r.s.getOutputStream());
	String rq = new LineNumberReader(r.in).readLine();
	l.log(rq);
	if (rq.startsWith("GET "))
	{ r.url = rq.substring(5, rq.indexOf(' ', 4));
	rh.handleRequest(r);
	}
	r.out.close();
	r.s.close();
	}
	}

Table 1 :

 1 Various configurations for the Comanche example haviour of the solvers for several configurations (Cfi) summarized in table1.We report in table 2 behaviours of the two solvers (Great-SPN and compSWN) for what concerns memory usage (in bytes) and computation times for the SRG generation phase only of the resolution, i.e. without computing steady-state probabilities nor performance indices (probabilities were found identical with the two tools, within numerical errors).

	|Colour|	Cf1 Cf2 Cf3 Cf4 Cf5 Cf6 Cf7 Cf8
	|UC|	3	5	10	2	3	5	10	20
	|IDC|	1	1	1	2	2	2	2	2
	|M|	2	2	2	2	2	3	3	3
	|IDS|	3	5	10	2	3	5	10	20
	|MS|	2	2	2	2	2	2	2	2
	|IDA|	1	1	1	2	2	3	3	3
	|MA|	2	2	2	2	2	2	2	2
	|IDL|	2	2	2	2	2	5	5	5
	|ML|	2	2	2	2	2	3	3	3
	|IDD|	1	1	1	2	2	3	3	3
	|MD|	2	2	2	2	2	3	3	3
	|IDF|	2	2	2	2	3	5	5	5
	|MF|	2	2	2	2	2	5	5	5
	|IDE|	2	2	2	2	2	5	5	5
	|ME|	2	2	2	2	2	4	4	4

Table 2 :

 2 State space sizes and computation times for SRG generation of the Comanche example for various configurations

		Config	NbS	NbO TGreat(s) TComp(s) MGreat (B) MComp (B)
		Cf1	82	35144	4	0	402	1484
		Cf2	136	239392	5	0	510	1652
		Cf3	271	16139264	12	0	780	2072
		Cf4	406	2392068	485	1	6305	5336
		Cf5	784	24279944	4919	1	7095	6008
		Cf6	1540 3656635680	-	2	-	7368
		Cf7	3430 3113239552	-	3	-	10728
		Cf8	7210	999926785	-	22	-	17448
	Component	Transition	Rate value
	Receiver	ReceiveRequest	0.6
	Scheduler	ScheduleRequest	0.9
	Analyzer	AnalysisRequest	0.6
	Analyzer	T10		0.75
	Logger	LogRequest	0.9
	Dispatcher	DispatchRequest	0.9
	Dispatcher	T29		0.9
	Dispatcher	T30		0.1
	File Handler	FileHRequest	0.9
	Error Handler	ErrorHRequest	0.1

Table 3 :

 3 Transition rates of the studied configuration rate for instance). We also take fixed rate values of a critical set of transitions, then, we vary some transition rates, and study the evolution of response time from obtained steadystate probabilities. Main transitions rate values are given in table3and transitions not appearing in this table have rate 1 (i.e. faster than all other transitions, rates being given in the same unit).

A WN and SWN formal definitions

We remind the reader with the definitions of WN and SWN. A detailed presentation of these models can be found in [START_REF] Chiola | Stochastic well-formed colored nets and symmetric modeling ap-plications[END_REF]. -S is a Well-Formed Net.

-θ a function defined on T such that:

-The weight of t for the colour c in the marking M, if π(t) > 0 (t is immediate). the firing probability of t(c) in M is then:

-The firing rate of t for the colour c in M, if π(t) = 0 (t is timed):

the enabling duration before the firing of t(c, M) follows an exponential probability distribution with mean θ (t)( c, M).

In this definition, c is the representation of the colour c in terms of static sub-classes, and M(p) is the representation of the symbolic marking of p in terms of tuples of static sub-classes. θ (t) depends only on static sub-classes of concerned colours.


Diego Alonso
email: diego.alonso@upct.es

Cristina Vicente-Chicote
email: cristina.vicente@upct.es

Olivier Barais
email: barais@irisa.fr

V 3 Studio: A Component-Based Architecture Modeling Language

Component-Based Software Development (CBSD) has proven to obtain highly reusable, extensible and evolvable designs. This paper presents a Model-Driven Engineering approach to CBSD which revolves around the definition of the V 3 Studio component-based meta-model and a set of graphical modeling tools implemented to support it. V 3 Studio has been designed to model the structure and behavior of a wide variety of reactive systems by means of three complementary views, namely: one for describing the components of the architecture (structural view), and two for describing their behavior (coordination and algorithmic views). Dividing the V 3 Studio meta-model into these three loosely coupled views considerably simplifies the overall design process, allowing designers to reuse previously defined models. In order to show the feasibility and the benefits of the proposal, a simple but complete case study regarding the design of a vision guided robotic system will be presented.

Introduction

Physical systems capable of perceiving and responding to external stimuli coming from its environment are considered reactive systems. This definition encompasses all physical devices that exhibit some organized behaviour, as well as interconnections of these devices into large networks of dynamic and interacting components.

Our research group is interested in developing reactive system following a Component-Based Software Development (CBSD) approach. Specifically, we have gained quite a lot of experience developing robotic systems [START_REF] Álvarez | An architectural framework for modeling teleoperated service robots[END_REF], machine-vision systems [START_REF] Vicente-Chicote | Image processing application development: From rapid prototyping to SW/HW cosimulation and automated code generation[END_REF] and, more recently, Wireless Sensors and Actuators Network (WSAN) applications [START_REF] Losilla | Wireless sensor network application development: An architecture-centric mde approach[END_REF]. We have followed a bottom-up CBSD approach to build our systems trying to incorporate some of the related Off-The-Self (OTS) components currently available (commonly as part of domain-specific libraries) in the marketplace.

As stated in [19], "software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution". This definition points out the close relationship existing between software architecture and component specification [START_REF] Crnkovic | Building Reliable Component-Based Software Systems[END_REF].

Component-Based Software Development (CBSD) has proven to obtain highly reusable, extensible and evolvable designs [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF]. 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 (topdown) is a non-trivial task which commonly requires adapting the architecture to make COTS components fit.

The Model-Driven Engineering (MDE) [START_REF] Selic | The pragmatics of model-driven development[END_REF] approach offers an effective solution for bridging the gap between architecture design and CBSD. MDE owes part of its success to the number of standards the Object Management Group (OMG) has developed as part of its Model-Driven Architecture (MDA) [START_REF] Omg | Model Driven Architecture Guide Version v1[END_REF] proposal. The MDE approach revolves around the definition of models and model transformations. Models represent part of the functionality, structure and/or behavior of a system [START_REF] Deelstra | Model driven architecture as approach to manage variability in software product families[END_REF], and they are defined in terms of formal meta-models. A meta-model includes the set of concepts needed to describe a domain at a certain level of abstraction, together with the relationships existing between them. Model transformations, commonly described as meta-model mappings, enable the automatic transformation and evolution of models into (1) other models, defined at any level of abstraction, or (2) any given textual format (e.g. code) [START_REF] Mens | A taxonomy of model transformation[END_REF].

In the context of MDE and CBSD, this paper presents the V 3 Studio meta-model and a set of graphical modeling tools implemented to support reactive system componentbased architecture design.

In spite of having been conceived to fit our needs regarding reactive system design and implementation, V 3 Studio is a general purpose and platform-independent meta-model, which allows designers to model both the structure and the behavior of a wide range of applications. The reduced set of concepts included in the meta-model makes it simple to use, and its division in three loosely coupled views allows designers to easily reuse previously defined models.

Before presenting the meta-model in detail, the following section briefly reviews the two current trends in MDE regarding meta-model design (i.e. profiling general purpose meta-models such as UML or SysML and defining new domain-specific ones), and justifies why V 3 Studio has been defined following a combined approach. Then, the rest of the paper is organized as follows. Firstly, section 3 introduces the V 3 Studio meta-model and the three loosely coupled views it has been divided into, while section 4 details the three graphical modeling tools implemented to support these views. A case study, regarding the design of a vision guided robotic system, is presented in section 5. Finally, section 6 reviews some related works, and section 7 presents the conclusions and outlines some future research lines.

V 3 Studio: neither a DSL nor a UML profile

As stated in [START_REF] Abouzahra | A practical approach to bridging domain specific languages with UML profiles[END_REF], nowadays there are two main trends in MDE. The first one promotes the use of standard modeling languages like UML 2.x [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF] or SysML [START_REF] Omg | OMG Systems Modeling Language (OMG SysML ) Specification v1[END_REF], while the second one advocates the benefits of Domain-Specific Languages (DSLs) [START_REF] Van Deursen | Domain-specific languages: an annotated bibliography[END_REF]. UML 2.x provides a rich set of modeling notations and offers some restriction and extension mechanisms (stereotypes, tags and constraints) which allow developers to adapt it to their particular domains. These customized versions of UML are commonly known as profiles. On the other hand, DSLs commonly provide a reduced and well-focused set of concepts and tailored notations for describing specific domains.

As previously stated, this research is focused on the definition of a meta-model which should exhibit the following characteristics: (1) it should be a general purpose modeling language, which enable the description of component-based software architectures for a wide range of reactive systems; (2) it should be expressive but simple, dealing with as few concepts as possible; (3) it should be independent of the target platform and of the specific reactive application domain (robotics, computer vision, etc.); and (4) it should be easy to integrate with other meta-models as part of an overall MDE software development process. In order to obtain such a meta-model, the following options were considered: Option 1: select UML 2.x [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF] as the target meta-model.

UML fulfills all the previous requirements but the one regarding simplicity. As its name states, UML supports general purpose system modeling, covering the whole software development life cycle, from analysis to deployment. As a consequence, UML includes hundreds of elements, although just a few of them are directly involved in the software design step and related to component structure and behavior specification. Thus, it is not easy (or even possible) to take only the required elements and diagrams and leave the rest of UML behind (for instance, all the elements related to Use Case modeling). Besides, the semantics associated to some UML elements should be completed, as they remain undefined in the UML specification (this lack of a unique definition is called "semantic variation point").

Option 2: define a UML profile, which will only take those elements needed for specifying component-based reactive system designs, and which will precisely define the variation points associated to them (if any). However, obtaining a reduced set of concepts and relationships by profiling a huge meta-model like UML 2.x is neither easy nor efficient. Actually, as stated in [START_REF] Bézivin | On the unification power of models[END_REF] by Bézivin "it is much more difficult to work by restriction than by extension". Besides, although the resulting meta-model would be simpler and more precise than UML, models built from this profile would be rambling (plenty of tags and stereotypes) and difficult to inspect and debug. In fact, the UML 2.x Superstructure [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF] standard states the following about profiles:

"The profiles mechanism is not a first-class extension mechanism (i.e., it does not allow for modifying existing meta-models). Rather, the intention of profiles is to give a straightforward mechanism for adapting an existing meta-model with constructs that are specific to a particular domain, platform, or method [. . . ] Firstclass extensibility is handled through MOF, where there are no restrictions on what you are allowed to do with a meta-model: you can add and remove meta-classes and relationships as you find necessary [. . . ]"

Option 3: define a DSL which only includes the required modeling elements, precisely defined with the desired meaning. However, the reactive systems domain is quite wide (actually it includes many very different application domains), and we are interested in modeling general-purpose component-based reactive systems rather than applications belonging to a very specific domain. In other words, we do not want concepts such as robot, camera or wireless-link to appear in our meta-model. As a consequence, considering V 3 Studio a DSL and a general-purpose meta-model at a time could seem a bit artificial and confusing, unless component-based reactive systems are considered a "wide although specific" domain.

The benefits and the drawbacks of these three options were carefully analyzed and, finally, we decided to define the V 3 Studio meta-model using a combined approach: we have selected those UML 2.x concepts needed to describe the structure and behavior of reactive system components but, instead of using a profiling technique, V 3 Studio has been designed as a stand-alone meta-modeled, directly from MOF [START_REF] Omg | Meta-Object Facility[END_REF] (like most DSLs). This allowed us to define the precise meaning of the selected UML elements, and to slightly modify some of them to improve, for instance, model reuse thanks to the definition of three loosely coupled component views. In spite of the minor changes that will be described in the following section, the resulting V 3 Studio meta-model remains very close to the original subset of UML it was extracted from and, in this sense, it can be considered UML-compliant. Actually, a model transformation from V 3 Studio to UML 2.x (and vice versa) is straight forward.

Description of the V 3 Studio meta-model

As stated in the previous section, the resulting V 3 Studio meta-model was built to help us design component-based reactive systems. V 3 Studio is aimed at modeling both component structure and behavior, as components provide more reusable, extensible, and evolvable designs [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF].

Even at the risk of being repetitive, we want to make it clear again that UML would have been also a valid option for modeling the kind of applications we are interested in, but we decided not to use it because it contains many concepts we do not need, and that would have only polluted the resulting models. In fact, as it will be further explained in this section, V 3 Studio takes and adapts many of the concepts already included in UML (in fact, V 3 Studio is largely based on UML). V 3 Studio contains only the essential concepts and relationships required to describe the kind of systems we are interested in. However, we think that V 3 Studio is general enough to be used in other domains to design component-based applications.

In order to model component behavior, two alternatives were considered, namely: state-machines and activity diagrams, both of them available in UML 2.x. Statemachines describe how components react to different stimulus coming, either from outside (e.g. from other component which require some service), or from the component itself (e.g. when an error condition is detected). Conversely, activity diagrams describe a data-flow oriented behavior, enumerating the sequence of activities performed by the component when it is in a certain state (e.g. idle, working, onError, etc.). Thus, state-machines and activity diagrams do not offer equivalent but complementary behavioral views.

Although UML 2.x allows designers to choose only one of these conventions to model component behavior, in most cases a combined approach is required to provide a complete behavioral description. This is why V 3 Studio provides the facilities to model both, state-machines and activity diagrams, although using only a subset of the concepts included in the equivalent UML 2.x views. Besides, V 3 Studio makes these two views compulsory, that is, a component is not complete (and thus, not valid) until (1) a state-machine defining its behavior is specified, and (2) for each state included in this state-machine, an activity diagram defining the behavior of the state is associated to it.

In order to enable model reuse, the three views the V 3 Studio meta-model has been divided into (structural, coordination, and algorithmic), are not just highly cohesive, but also very loosely coupled. To achieve these two characteristics, inter-view relationships have been modeled using plain association links instead of composition ones, as it will be further explained in the following subsections. Such a meta-model partition exhibits several advantages, namely: (1) it eases the overall design process since designers only deal with a reduced set of concepts at a time;

(2) the loosely coupling of the three views promotes model reuse, and (3) the inter-model consistency is assured, since all models are build from the same meta-model.

Component structure description

As stated before, the V 3 Studio meta-model describes the static architecture of a system in terms of its components and the connections existing between them. V 3 Studio components are modeled according to the UML 2.x [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF] definition of component: "a component is a self contained unit that encapsulates certain behavior. It specifies the services provided to its clients and those required from other components, defined in terms of its provided and required interfaces. Components are substitutable units that can be replaced, at design time or run-time, by a component that offers equivalent functionality (based on compatibility of its interfaces)". This definition is captured in Figure 1, which shows the structural part of the V 3 Studio meta-model, while Figure 4 shows a snapshot of the graphical tool representing this view.

As shown in Figure 1, the architectural view (represented by the SimpleComponent class) is coupled with the coordination view (represented by the StatMachine class) by means of an association named behavior. Using a simple association instead of a composition relationship achieves a loosely coupling between these two views. This allows designers to reuse their V 3 Studio state-machine models for defining the behavior of different components, which is one of the main objectives of the design of V 3 Studio. The same strategy has been applied to define those concepts which can be reused in different contexts or places. For instance, as it can be seen in Figure 1, the definition of the system Interfaces also follows this strategy, so different ports (even belonging to different components) can reuse the same interfaces.

Figure 1 shows that components can be simple (concept represented by the SimpleComp class) or complex (ComplexComp class) and that all components, either simple or complex, contain a series of Ports. These ports group together the component Interfaces, which define the Services the component provides (i.e. the services it offers to the rest of the components of the system), and those it requires (i.e. those required by the component and that must be provided by other components). Simple components represent the basic architectural and behavioral units of the system, while complex ones encapsulate and coordinate other components (either simple or complex, up to any level). As it can be seen in Figure 1, the ComplexComp class uses the Composite design pattern [START_REF] Gamma | Design patterns : elements of reusable object-oriented software[END_REF] to contain other components and encapsulate them. A complex component, thus, establishes a boundary and limits the access to its inner components. It is worth noting that V 3 Studio defines the system architecture, that is, the application as a whole, as a reference to a complex component. This makes it possible to reuse any previously defined architecture design (in the form of a ComplexComp).

V 3 Studio assumes that only simple components need to define their behavior using a state-machine. As shown in Figure 1 ports can be "compatible" and, thus, linked. V 3 Studio takes them into account and defines an attribute that characterizes the PortLink being used:

DELEGATION PortLink. This kind of link connects a port defined in an inner component (whether simple or complex) to a compatible port defined in its container. In this case "compatible" means that these two ports can be linked if and only if they provide and require exactly the same interfaces. Thus, a complex component port is just an extension of the inner port, as the complex component will delegate every service requirement to it. Delegation links allows the creation of ComplexComp using a white-box view, as the developer can choose which inner component will fulfill part of the functionality offered by the complex component.

ASSEMBLY PortLink. This kind of link connects two ports defined in two components (whether simple or complex) that are created at the same level, that is, none of them contains the other. In this case, components are being assembled and "compatible" means that ports can be linked if and only if they are conjugated, that is, they must provide all the interfaces required by the other and vice versa. This kind of view enforces the use of components as black-boxes.

As a summary of the rules for connecting compatible ports, it can be stated that (1) components defined at the same level (contained in the same complex component) are always linked using ASSEMBLY port links, while (2) in order to connect a component to its container a DELEGATION port link is required. Thus, (3) simple components are always linked using ASSEMBLY port links, while (4) complex components support both types of connections (they can be internally linked by a DELEGATION Portlink but also assembled by an ASSEMBLY Portlink). Of course, these restrictions do not appear in the V 3 Studio meta-model which is shown along this section, but it is necessary to add some OCL [START_REF] Omg | Object Constraint Language (OCL) Specification v2[END_REF] constraints to verify them.

Component behavior description

As stated at the beginning of this section, in V 3 Studio only simple components have their own behavior, which is modeled by means of a state-machine diagram in the coordination view. Figure 2 shows the coordination view of the V 3 Studio meta-model together with the loosely coupled relationships with the structural view (represented by the class SimpleComp, red association link named behavior, see section 3.1), and the algorithmic view (represented by the abstract class Activity, red association links fire, do, onEntry and onExit, see section 3.3). In this case, a state-machine can reuse any predefined Activity model to complete the definition of their States and Transitions, stating which activity is going to be executed when a state is entered o exited, while staying at the state, or when a transition is successfully fired. As shown in Figure 2, this part of the V 3 Studio metamodel is a simplified version of its UML 2.x counterpart, and it follows the execution dynamics and semantics defined in UML 2.x. But, unlike UML 2.x, V 3 Studio does not include either regions (to model macro-states, i.e., states that contain other states), or sub state-machines (to reuse a part of an already defined state-machine), or the always controversial Event. Besides these limitations, this view allows designers to model (1) the different states a component can go through their lifetime, and (2) the transitions that model the change of state. For every state and transition it is possible to select the algorithm to be executed from a set of already defined activities (see algorithmic view, section 3.3). Specifically, it is possible to: • Model two types of Vertex: observable states of the state-machine (class State) and non-observable states (class Pseudostate). In the first case, it is possible to specify the activities that should be executed when the state is entered (OnEntry association), exited (onExit association) or when the state is active (do association). As can be seen, it is also possible to define a FinalState (which is an observable state) to mark the end of the state-machine. Finally, V 3 Studio establishes that each and every statemachine must have an INITIAL Pseudostate that marks the state in which a component is initialized when created. This condition avoids the definition of what UML calles "ill-formed" state-machine diagrams (see [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF], chapter 15). Of course, this condition has to be checked by defining additional OCL constraints. As shown in Figure 3, the abstract class ActivityVertex constitutes the core class of this view, as the rest of the classes available to designers to model the different kind of activities inherit from this one. The following two classes directly inherit from ActivityVertex:

Algorithmic description

Activity: this abstract class models all the classes that represent the real execution of some code. As it can be seen in Figure 3, only the following two concrete classes represent an algorithm that models the behavior of a state or transition:

SimpleActivity: this class models a simple activity, that is, one that contains only executable code. Simple activities represent the description of a basic unit of behaviour. As next item points out, complex activities are just a medium for reusing and linking previously defined activities.

ComplexActivity: this class allows designers to group together and link activities (whether simple or complex) in order to create more complex activities for describing the behavior of a state or transition. Again, the Composite design pattern [START_REF] Gamma | Design patterns : elements of reusable object-oriented software[END_REF] is used to recursively contain all the Activity classes needed to describe a ComplexActivity. Besides, a complex activity contains ActivityLinks that allow designers to link ActivityVertex classes in order to establish the flow of execution inside a ComplexActivity.

PseudoActivity: this class models a kind of activities that do not represent the real execution of any code but that are necessary to correctly define the V 3 Studio algorithmic view. Two different kind of pseudoactivities has been modeled: INITIAL, which points to the first activity that should be executed when executing a complex activity, and FINAL, which models the end of the flow of activities. V 3 Studio establishes that every complex activity should have one PseudoActivity of each class to be correct. These restrictions have been added by means of two OCL constraints.

It is worth noting that, as shown in Figure 3, the addition of the Activity class prevents the use of a PseudoActivity as the associated behavior of a state or transition. This is an example of how a design decision can ease the definition of the semantics of the models. In this case, we could have removed the Activity class and make every activity class directly inherit from ActivityVertex. This decision would have eliminated one class from the meta-model but would also have forced us to add more additional constraints to check the rules that are naturally enforced by the actual V 3 Studio metamodel. It can be generally said that the reduction of the number of classes in a meta-model forces the addition of OCL constraints to check model validity.

V 3 Studio does not include any control-flow mechanism to allow designers modeling loops or bifurcations. We plan to add this mechanism in a future version of the metamodel, as it will be further explained in section 7.

The V 3 Studio graphical modeling tools

As stated before, V 3 Studio allows designers to model component-based software architectures using three complementary views. Such a meta-model partition exhibits several advantages, namely: (1) it eases the overall design process since designers only deal with a reduce set of concepts at a time; (2) the loosely coupling of the three views promotes model reuse and, last but not least, (3) the intermodel consistency is assured since all models are build from the same meta-model.

To keep all the benefits derived from the use of different views, we have implemented three graphical modeling tools (in fact four, but the interface definition tool is very simple), one for describing the system architecture (component view, see Figure 4), another for modeling state-machines (coordination view, see Top of Figures 5 and6), and the last one for depicting activity diagrams (algorithmic view, see Bottom of Figures 5 and6) using the facilities provided by the Eclipse platform, namely the Graphical Modeling Framework (GMF) plug-in. Each of these tools generates a model that includes only part of the concepts appearing in the complete V 3 Studio meta-model. These models are fully reusable since they can be loaded from the other tools to complete other models. For instance, the activity diagram tool allows designers to build activities which then can be loaded by the statemachine tool to fill the onEntry property of some of its states. The resulting state-machine model can also be loaded by the component tool to fill the behavior of any of its simple components. Some example diagrams, built using the implemented graphical modeling tools, will be shown in the following section, where a vision-guided robotic system case study is presented.

A case study on vision guided robotics

This section presents a simple but complete case study regarding the design of a vision guided robotic system and shows the definition of the system architecture, using components, and the definition of their behavior, using state-machines and activity diagrams. The purpose of the robotic system is to pick up objects that have a given characteristic (shape, color, etc). The vision system is in charge of identifying the object and generating the trajectory of the movement of the robot, which is finally executed and controlled by the Controller.

Figure 4 presents the component diagram and the interface design tools used to model the case study system architecture. The structure of this system, as shown in Figure 4, is defined as a complex component (as said in section 3.1, it is compulsory to define the architecture of the whole system as a complex component) comprising three internal simple components, namely: a Computer Vision System, a Robot Control System and a Controller, which plays the role of mediator between the other two components (it receives commands from the vision system and generates the appropriate movement commands).

Both, the computer vision and the robot control systems, are linked to their owner by means of a DELEGATION port link (discontinuous red line). These ports have a required interface used to request some functionality from the environment. More precisely, the computer vision system uses its port to send image request messages to the camera (that should be connected to the external port on the left), while the robot control system uses its port to send move commands to the robot (connected to the external port on the right).

The controller is connected to the other two components by means of ASSEMBLY port links (continuous black lines). It uses its left port to collect the visual inspection results obtained by the computer vision system. Then it decides whether the inspected object should be picked up by the robot or not. If the robot must pick up the object then it sends a move order using its right port.

The computer vision system behavior has been modeled as shown in Figure 5 (top). As expected, the result is a very simple state-machine and quite a complex activity diagram (see Figure 5 bottom), provided the data-flow nature of this component. Conversely, as shown in Figure 6, modeling the behavior of the robot control system required a more complex state-machine while the activity diagram associated to the most complex of its states (moveXYZ) is quite simple in this case.

Related work

The work presented in this paper draws from a number of related research works. Within the domain of software and system engineering, probably the most closely related technologies are those concerning Architecture Description Languages (ADLs) [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF] and the modeling languages provided by the OMG, namely UML 2.x [START_REF] Omg | Unified Modeling Language (UML) Superstructure Specification v2[END_REF] (which was previously criticized in section 2) and SysML [START_REF] Omg | OMG Systems Modeling Language (OMG SysML ) Specification v1[END_REF].

The Systems Modeling Language (SysML) was developed by the OMG to provide a modeling language for system engineering, which supports the specification, analy- sis, design, verification and validation of a broad range of systems and systems-of-system. SysML is defined as a UML profile, but it is actually an extension of a subset of UML. So, SysML is smaller, easier to use and learn than UML. In fact, SysML removes many of the softwarecentric constructs of UML, and thus the overall language is smaller (measured both in diagram types and total constructs). However, SysML is still difficult to understand and to use, and the limits between its different views are not clearly defined. Besides, the SysML Block concept, one of the core classes of this standard, cannot be (strictly) considered equivalent to the software concept "component".

Conversely, the software architecture design community focuses on building formal notations which enable the definition of the structure and behavior of software systems, and the non-software entities the system interfaces with. Recently, the Architecture Analysis and Design Language (AADL) [START_REF] Feiler | The architecture analysis & design language (AADL): An introduction[END_REF] has been designed and standardized by the Society of Automotive Engineers (SAE), in collaboration with the Software Engineering Institute (SEI). AADL follows a MDE approach, and has a strong foundation on previous work regarding ADLs definition done by the SEI (e.g. ACME, Wright, or UniCon) [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF]. However, most of these ADLs are focused on component interaction, because the separation between the data-flow and the control-flow is difficult to model.

The Cadena [START_REF] Childs | Calm and Cadena: Metamodeling for component-based product-line development[END_REF] platform also provides tools for building component-based software system, covering the whole application development life cycle. Cadena is also based on many of the concepts provided by traditional ADLs (actually, it provides its own ADL, called CALM) and relies on a middleware technology to achieve platform independence. However, Cadena has been specifically designed to build component-based software product lines, which is not the main objective of V 3 Studio.

Finally, openArchitectureWare (oAW) provides a modular MDA/MDD generator framework. oAW supports arbitrary model parsing and provides a family of model checking and transformation languages, together with code generation facilities. However, oAW was still in an alpha state when we started developing V 3 Studio, although we do not discard using it in a near future, as it provides a uniform environment for MDE.

Conclusions and future research

In this paper we have presented the V 3 Studio component-based meta-model, which allows designers to model the structure and behavior of their systems, providing them with three highly cohesive and loosely coupled views. Although it was initially conceived to target the design of reactive systems, V 3 Studio can be considered a general-purpose meta-model for describing a wide range of component-based applications. The V 3 Studio meta-model allows designers (1) to design and validate component-based applications using customized tools, and (2) to reuse previously defined models in different contexts (for instance, a state-machine can be reused to describe the behavior of different components).

Three graphical modeling tools have been implemented on top of V 3 Studio to support its three (in fact four) views. Models depicted using these tools can be easily loaded and reused to define new models. To probe the feasibility and the benefits of the proposed approach, a simplified vision guided robotic system has been presented.

Currently, the V 3 Studio meta-model and the associated graphical modeling tools are still in an alpha state, although they are completely operative. In the future we plan to improve V 3 Studio in the following directions:

1. Decouple component definitions from their implementations in order to allow designers to model completely reusable component definitions.

2. Include some mechanisms to enable the description of structural and behavioral variability.

3. Manage time constraints in the component behavior specification.

4. Use V 3 Studio as an intermediate abstraction level for different DSLs created for the specific reactive system domains enumerated at the beginning of this paper (robotics, computer-vision, and WSAN applications). This intermediate level will play the role a MDA PIM meta-model, providing a common layer for each and every reactive system developed using those DSLs. As a PIM, V 3 Studio will reduce the semantic distance between the very-high level models defined using the different DSLs and the final system implementation, and thus it will help reducing the complexity of the required model transformations.

5. Define a set of Model-to-Text transformations to automatically generate executable code from V 3 Studio models. In this line, some results have already been achieved for the state-machine view [START_REF] Alonso | Automatic Ada code generation using a model-driven engineering approach[END_REF].

15th

  Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems 978-0-7695-3141-0/08 $25.00 © 2008 IEEE DOI 10.1109/ECBS.2008.9 346 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems 978-0-7695-3141-0/08 $25.00 © 2008 IEEE DOI 10.1109/ECBS.2008.9

Figure 1 . The V 3

 13 Figure 1. The V 3 Studio structural view (component diagrams). The red association links define the relationships between the architectural and behavioral views and between the definition of components and interfaces.These associations make it possible to reuse previously defined models.

  Figures 5 and 6 (top figure) show snapshots of the graphical tool representing this view.

Figure 2 .

 2 Figure 2. The V 3 Studio coordination view (state-machine diagrams). Again, red association links show the relationships between the different views of the V 3 Studio metamodel, specifically between the coordination and the architectural and algorithmic views.

•

  Model two kinds of Transitions: INTERNAL and EXTERNAL. A transition models the conditions that control the change of state in a state-machine. As UML 2.x does, V 3 Studio allows designers to (1) specify whether the firing of the transition should really change state (EXTERNAL transition) or it is just a reaction, that only executes the fire activity and does not change the current state of the statemachine (INTERNAL transition); and (2) select one of the already defined activities to be executed as a consequence of this transition being fired (red association link named fire).

Figure 3

 3 Figure3shows the algorithmic view of the V 3 Studio meta-model and its loosely coupled relationships with the coordination view (represented by classes State and Transition, see section 3.2). This final part of the meta-model is also a simplified version of the UML 2.x activity diagrams counterpart. Just like the coordination view is very similar to the UML 2.x state-machine diagram, the activity diagram shown in this section is a very simplified version of the UML 2.x activity diagram, as its UML counterpart has around a hundred classes available. Figures5 and 6(bottom figure) show a snapshot of the graphical tool representing this view.As shown in Figure3, the abstract class ActivityVertex constitutes the core class of this view, as the rest of the classes available to designers to model the different kind of activities inherit from this one. The following two classes directly inherit from ActivityVertex:

Figure 3 .

 3 Figure 3. The V 3 Studio algorithmic view (activity diagrams).

Figure 4 .

 4 Figure 4. Models developed as part of the vision-guided robotic system case study. Top: architecture view of the system, Bottom: interfaces and services definition tool.

Figure 5 .

 5 Figure 5. Models developed as part of the vision-guided robotic system case study. Top: Computer Vision System coordination view, Bottom: Activity diagram associated to the InspectingImage state.

Figure 6 .

 6 Figure 6. Models developed as part of the vision-guided robotic system case study. Top: Robot Control System coordination view, Bottom: Activity diagram associated to the MovingXYZ state.

Authorized licensed use limited to: IEEE Xplore. Downloaded on March 5, 2009 at 09:32 from IEEE Xplore. Restrictions apply.

Acknowledgement

This work has been partially funded by the Spanish CICYT project MEDWSA (TIN2006-15175-C05-02), and the PMPDI-UPCT-2006 program (Universidad Politécnica de Cartagena).