Modeling and Executing Component-based Applications in C-Forge

Francisca Rosique, Diego Alonso, Juan Pastor and Francisco Ortiz

Division of Systems and Electronic Engineering (DSIE), Universidad Polit

ecnica de Cartagena,

Campus Muralla del Mar, E-30202, Cartagena, Spain

Keywords:

Software Engineering, Component-based Software Development, Model-driven Software Development,

Framework, Software Design Patterns, Real-time.

Abstract:

This paper describes a model-driven toolchain for developing component-based applications that enables users

to use the same models that deﬁne their application to execute them. In this vein, models always remain true

to the ﬁnal application, unlike other approaches where a model tranformation generates a skeleton of the ﬁnal

application after the ﬁrst steps of the development process. These kind of approaches normally end up with

models that represent a different application than the one present in the code.

1 INTRODUCTION AND

MOTIVATION

The Component Based Software Engineering

(CBSE) (Crnkovic, 2011) paradigm promotes the

encapsulation of proven solutions into reusable

building blocks, considering components as some-

thing beyond a compiled module or library. CBSE

approaches should consider concerns beyond purely

structure/behavior modeling, such as component

execution, conﬁguration, deployment, analysis,

etc. The Model-Driven Software Development

(MDSD) (Schmidt, 2006) paradigm can help design-

ing development processes for CBSE applications

that take into account all these concerns, allowing

users to concentrate on domain concepts rather

than in code or conﬁguration parameters. Model

transformations (Malavolta, 2010) complement the

approach by providing the means to automatically

generate other representations, either in the form of

models or text (source code).

Generally, model-driven processes for developing

component-based (CB) applications only use models

on the ﬁrst steps of the project. Afterwards, a set

of model transformations generate the code skeletons

where the user ﬁlls-in the code and then the applica-

tion is compiled. The problem with this approach is

that when the user must make a change, he/she forgets

about the original models of the application and now

the user makes all the modiﬁcations directly on the

code. But not all kind of changes should be made at

the code level. For instance, if the application needs

a new component, this component should be added at

the model level and then the code should be regener-

ated in order to keep it true to the model. Otherwise,

the model and the code end representing different ap-

plications. And this is an important problem not only

in CBSE but in many other domains.

One of the possible solutions to this problem is

to really have a model-driven process, from the be-

ginning to the end, where all the involved software

artefacts are either models themselves, or are aware

of the presence of models and use them consistently

and coherently. The goal of such a process would be

to be able to use the same CB models that describe the

application to execute it. In any case, code is neces-

sary, but we should try to use models as long as possi-

ble. This paper describes how we have implemented

these ideas in the context of the C-Forge toolchain. C-

Forge is a development process for CBSE supported

by a MDSD toolchain developed in the Eclipse IDE

that is composed of three parts, shown in Fig. 1:

• WCOMM tool: provides two graphical editors

and a textual one for modeling the structure and

behavior of CB applications from a platform in-

dependent point of view.

• FraCC tool: provides a model loader, a deploy-

ment metamodel and a compiled C

framework.

The framework provides the run-time support re-

quired for executing WCOMM models with dif-

ferent deployment conﬁgurations (distribution of

components to nodes and processes, and assign-

ment of computational load to threads). FraCC

also includes a model loader that instantiates the

Rosique, F., Alonso, D., Pastor, J. and Ortiz, F.

Modeling and Executing Component-based Applications in C-Forge.

DOI: 10.5220/0005905701030108

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 1: ICSOFT-EA, pages 103-108

ISBN: 978-989-758-194-6

103

!"#$$%

!""#$%&'#()*&#

&'(""%

!+&**,'#,-,./%0%#1)*&.#

$)*+,%,)(*+'-%

,22.0(,3)-#&4&($3)-#

()120.&#

)*+

,)(*

$+..(/+.%0%

1234567%.8+,,.%

")9:);+;6.%<568%

=;56+%.6(6+>9(285;+%

1'2856+26?'+%

@+:,)79+;6%9)*+,-%#

,%%07-1&-8#)9#'&70)-%#

8)#8+'&,*%:#2')(&%%&%#

,-*#-)*&%#

;%)#.0<','0&%#

0.&#

*+'

Figure 1: The C-Forge development process comprises two tools (WCOMM and FraCC) and three model-transformations.

application from the WCOMM model and a de-

ployment model (described in the following item).

We said FraCC “executes” WCOMM models be-

cause, unlike other approaches, we do not gener-

ate implementation code. FraCC is already com-

piled and provides a model loader that parses

WCOMM models and instantiates FraCC classes

accordingly. It is not an interpreter, since C

code is executed at runtime, and thus, the per-

formance of the ﬁnal application is not affected.

More details about FraCC’s design are provided

in (Alonso, 2014).

• Three model transformations that generate the

rest of the software artifacts required in differ-

ent steps of the C-Forge development process.

Model transformation (A) generates the C

code

skeletons where the user must add the application-

speciﬁc code. The user code is then compiled into

a dynamic library and loaded by the model loader.

Model transformation (B) generates a deployment

model, which describes how the application is ex-

ecuted by FraCC. Model transformation (C) ex-

ploits the information contained in the WCOMM

and deployment models to generate an analysis

ﬁle for performing a schedulability analysis with

Cheddar, so that the user can check whether the

ﬁnal application will meet its real-time require-

ments.

A detailed description of C-Forge and its appli-

cation in the context of an autonomous underwater

vehicle, performed in collaboration with the Heriot-

Watt University, is described in (Ortiz, 2014). The

aim of C-Forge is to provide (i) full support for the

development of component applications, from mod-

eling to execution, (ii) strict control over the concur-

rency properties of the application, (iii) mechanisms

that foster model reuse in all levels.

The rest of the paper is organized as follows.

Section 2 describes some related works in the

ﬁeld of components, model-driven technologies and

concurrency/real-time speciﬁcation available in the

literature. Section 3 contains the main part of the pa-

per, where we describe with more detail the C-Forge

toolchain. Finally, Section 4 outlines the conclusions

and some future works.

2 RELATED WORK

Given the number of bibliographic references that re-

view the state of the art of CBSD in the literature,

the aim of this section is not to provide a new review,

but to relate the work described in this article with

the currently available component models. In order

to this, we use the classiﬁcation framework described

in (Crnkovic, 2011), which is used by the authors to

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

104

classify a large number of component models. Such

classiﬁcation framework proposes three main charac-

teristics for studying component models, namely Life-

cycle, Construction and Extra-Functional Properties.

Table 1 classiﬁes the elements that comprise C-Forge

according to the aforementioned taxonomy.

C-Forge shares many similarities with approaches

like ProCom (Vulgarakis, 2009), CHESS (Cicchetti,

2012), and RT-CCM (Lopez, 2013), since they are

all component-based approaches supported by model-

driven technologies, and they all provide certain de-

gree of control over concurrency and real-time prop-

erties. The main differences with the aforementioned

approaches are:

ProCom deﬁnes two component layers: the upper

and the lower layer. The former allows devel-

opers to deﬁne large-grained active components,

while the latter consists of basic functional pas-

sive components, which are interconnected inside

subsystem. In C-Forge, all components are active,

but this does not mean that they require their own

thread.

CHESS considers four views: Requirements, Com-

ponents, Deployment, and Analysis. Compo-

nent behavior can be deﬁned with state-machines,

other standard UML diagrams, as well as with the

Action Language for Foundational UML (ALF,

http://www.omg.org/spec/ALF/). The Deploy-

ment view models the target execution platform,

and software to hardware components allocations.

CHESS provides generators to Ada/C/C

/Java

source code. C-Forge focus on a single way to

model component behavior and manage concur-

rency, which makes it easier to generate and com-

pose C

code only.

RT-CCM considers components as black-boxes,

where the user models the concurrency needs

(mainly threads and shared resources), so that

the component implementation can provide them.

The resulting models can be analyzed with

the MAST (http://mast.unican.es) analysis tool.

Compared to them, C-Forge considers that com-

ponents are white-boxes.

3 MODELING AND EXECUTING

COMPONENT-BASED

APPLICATIONS IN C-FORGE

As shown in Fig. 1, the development process pro-

posed by C-Forge is the following. The ﬁrst step com-

prises the deﬁnition of the application datatypes, mes-

sages and activities by using WCOMM’s textual edi-

tor. Afterwards, the user can select to either generate

the code skeletons for the activities or continue mod-

eling the application (i.e. deﬁning simple compo-

nents, modeling the application architecture and gen-

erating the deployment model). Once both parallel

steps have been completed, the user can execute the

application by passing the WCOMM and deployment

models to the FraCC model loader. This process is it-

erative, in the sense that the user can add, modify and

test components as needed. The following subsec-

tions describe the main highlights of WCOMM and

FraCC.

3.1 Modeling Component-based

Applications with WCOMM

An excerpt of the most important classes of the

WCOMM metamodel is shown in Fig. 2. WCOMM

comprises three complementary and loosely coupled

sets of meta-classes that group together the ele-

ments related to modeling (i) the common applica-

tion elements, namely data-types, messages and activ-

ities, (ii) simple components and their behavior, and

(iii) complex components. As can be seen in the ﬁg-

ure, there are several meta-classes devoted to model

“deﬁnitions” (blue meta-classes, like ComponentDef-

inition, PortDeﬁnition, ActivityDeﬁnition, etc.) and

their “instances” (orange meta-classes, like Compo-

nent, Port, Activity, etc.) in order to foster model

reuse. WCOMM deﬁnes simple and complex com-

ponent deﬁnitions. Simple components are the basic

building units, while complex components are built

by assembling component instances, either from sim-

ple or complex components.

A simple component is an entity that encapsulates

its internal state and that comprises both structural

and behavioral parts. The structural part is deﬁned by

the component ports and the message instances ﬂow-

ing through them. Messages can carry data, and are

sent between components following the asynchronous

no-reply communication scheme, which makes possi-

ble to support any communication scheme and assures

a low coupling between components. Component re-

active behavior is deﬁned by means of a ﬁnite-state

machine (FSM), similar to those deﬁned in UML 2.

FSMs only model the circumstances under which

the component’s activities are executed. Thus, the

complexity of the application is mainly embedded in

the C

code executed by an activity. FSMs also de-

ﬁne hierarchical and orthogonal regions, which allow

users to model independent parts of the whole com-

ponent behavior. FraCC then uses this potential con-

currency modeling to organize the threading code and

Modeling and Executing Component-based Applications in C-Forge

105

Figure 2: Excerpt of the WCOMM metamodel. Blue meta-classes model “deﬁnitions” while orange ones model “instances”.

execute the regions sequentially or concurrently, de-

pending on the platform features (e.g., CPU charac-

teristics) and the user desires. Transitions are trig-

gered by events, which can be produced by message

reception or by the results of an internal computation.

States can contain one activity instance, which is a

proxy of the concrete algorithm that will be executed

when the state becomes the region’s active state.

3.2 Executing Component-based

Applications with FraCC

In order to execute WCOMM components we devel-

oped FraCC, which comprises a deployment meta-

model (shown in Fig. 3), a C

framework and a model

loader that instantiates the framework according to

a WCOMM and deployment models, and a set of

model transformations that generate a default deploy-

ment model and the skeletons of the C

classes where

the user must add the application speciﬁc code. The

FraCC meta-model comprises three sets of classes,

ordered vertically in the ﬁgure: (i) hardware deﬁni-

tion, since we want to extend the approach to multi-

core and distributed systems; (ii) concurrency deﬁ-

nition, deﬁning the number of processes and threads

where the regions that deﬁne the component behavior

will be executed; and (iii) allocation of processes and

threads to the hardware (nodes and CPU cores) that

will execute them.

From the information contained in the WCOMM

and deployment models, a model transformation gen-

erates an analysis ﬁle for the Cheddar schedulabil-

ity tool, which checks whether the ﬁnal application

will meet its timing requirements or not. Appropriate

changes can be made in the applications models as

needed based on the outcomes of analysis. A detailed

description and examples of the use of the deploy-

ment model and schedulability analysis are provided

in (Ortiz, 2014). The deployment model provides

C-Forge with ﬂexibility since it can test components

with various deployment conﬁgurations, e.g. same ar-

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

106

Table 1: Features of and MinFr component models according to the classiﬁcation framework described in (Crnkovic, 2011).

A) LIFECYCLE DIMENSION

C-Forge: WCOMM+FraCC

Modeling ADL-like language (datatypes, component structure, component behavior) plus

deployment and concurrency view

Implementation C

framework based on pattern languages

Packaging EMF ﬁles (stored in XML format) and zip ﬁles including code in binary format

Deployment Set at compilation and at run-time

B) CONSTRUCTION DIMENSION: INTERFACE SPECIFICATION

C-Forge: WCOMM+FraCC

Interface Type Port based (message passing)

Provided/Required inter-

faces

No, in/out messages

Interface Language IDL-like and C

header ﬁles.

Interface Levels (syntac-

tic, semantic, behavior)

Syntactic only. However, behavioral (protocols) and semantic (pre, post condi-

tions and invariants) levels are implicitly deﬁned in the FSMs

C) CONSTRUCTION DIMENSION: BINDING AND INTERACTION

C-Forge: WCOMM+FraCC

Connectors are architec-

tural elements

Not yet

Hierarchical composition

of components

Delegation (internal components are not accessible from outside the composite)

Interaction Styles Sender/receiver, message passing

Communication type Asynchronous without response. Synchronous interactions should be deﬁned in

the FSM

Figure 3: Deployment metamodel for FraCC. Related

WCOMM classes are highlighted in orange.

chitecture; different platforms.

There are several changes the user can make

in order to obtain an schedulable application. On

the deployment model, he/she can reallocate regions

to other threads or to new ones, grouping together

regions with similar execution periods. On the

WCOMM model side, he/she can (i) develop new al-

gorithms, so that activities’ execution times are low-

ered, (ii) relax the timing requirements imposed over

the activities if possible, so that the load on the CPUs

can be lowered; or (iii) change the FSM describing a

component behavior, so that there are less regions to

be allocated to threads.

4 CONCLUSIONS

This paper has described a model-driven toolchain for

developing component-based application, entitled C-

Forge, which main characteristics are that (i) the same

models that are used to model the application are also

used to execute it, and (ii) the execution framework

provides the user with full control over its concur-

rency characteristics. Therefore, we take advantage

of all the beneﬁts provided by model-driven technolo-

gies. C-Forge also includes a separation of concerns,

since the application architecture is separated from

the way it will be executed and from the concrete code

that will be executed by each component.

Reuse is also a key feature in C-Forge. We want

Modeling and Executing Component-based Applications in C-Forge

107

to stress that reuse should be taken into account at

all levels, and not only at the modeling one. In

WCOMM, reuse is achieved by separating “deﬁni-

tions” from their “instances” in the meta-model, while

FraCC design’s enable the reuse of previously com-

piled (i.e., in binary format) activities.

Finally, we also want to highlight again that, from

our point of view, it is really important to consider

that model-driven should permeate all the steps and

tools involved in the development process. “Model-

driven” is not just a matter of the tool (e.g. Eclipse),

but rather a responsibility of the whole development

process and all involved tools. In our case, though the

FraCC framework has not been developed by using

Eclipse-based model-driven facilities, but rather C

it is nevertheless aware of the presence of models.

ACKNOWLEDGEMENTS

This work has been partially supported by the Spanish

CICYT Project Visel-TR (ref. TIN2012-39279)and

the Spanish Ministry of Economy and Competitive-

ness under the project cDrone (ref. TIN2013-45920-

R).

REFERENCES

I. Crnkovic, S. Sentilles, A. Vulgarakis, and M. R.

V. Chaudron. A classiﬁcation framework for soft-

ware component models. IEEE Trans. Software Eng.,

37(5):593–615.2011.

D.C. Schmidt. Model-driven engineering. IEEE Computer,

39(2):25–31, February 2006.

I. Malavolta, H. Muccini, P. Pelliccione, and D. Tamburri.

Providing architectural languages and tools interop-

erability through model transformation technologies.

IEEE Transactions on Software Engineering, 36:119

– 140, 2010.

F. Ortiz, C. Insaurralde, D. Alonso, F. S

anchez, and Y.

Petillot. Model-driven analysis and design for soft-

ware development of autonomous underwater vehi-

cles. Robotica, pages 1–20, April 2014.

D. Alonso, F. S

anchez, J. Pastor, and B.

Alvarez. Embedded

and Real Time System Development: A Software En-

gineering Perspective, chapter A ﬂexible framework

for Component based Application with Real-Time Re-

quirements and its Supporting Execution Framework,

pages 3–22. Springer-Verlag, 2014.

A. Vulgarakis, J. Suryadevara, J. Carlson, C. Seceleanu,

and P. Pettersson. Formal semantics of the procom

real-time component model. In Proc. of the 35th Eu-

romicro Conference on Software Engineering and Ad-

vanced Applications, pages 478–485.IEEE, 2009.

A. Cicchetti, F. Ciccozzi, S. Mazzini, S. Puri, M. Panunzio,

A. Zovi, and T. Vardanega.CHESS: a model-driven

engineering tool environment for aiding the develop-

ment of complex industrial systems. In Proc. of the

27th IEEE/ACM International Conference on Auto-

mated Software Engineering, pages 362–365. ACM

Press, 2012.

Patricia L

opez-Mart

ınez, Laura Barros, and Jos

e Drake. De-

sign of component-based real-time applications. Jour-

nal of Systems and Software, 86(2):449–467, 2013.

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

108