AN IMPLEMENTATION FRAMEWORK FOR COMPONENT-BASED

APPLICATIONS WITH REAL-TIME CONSTRAINTS

Extensions for Achieving Component Distribution

Francisco Sánchez-Ledesma, Juan A. Pastor, Diego Alonso and Francisca Rosique

School of Telecommunication Engineering, Technical University of Cartagena

Plaza del Hospital n

1, 30202 Cartagena, Spain

Keywords:

Component distribution, Middleware, Component-based software development.

Abstract:

Reactive system design requires the integration of structural and behavioural requirements with temporal ones

(along with V&V activities) to describe the application architecture. We have adopted the Model-Driven

Software Development approach to address these problems globally: from the deﬁnition of the application

architecture to the generation of both code and analysis models. An Object Oriented framework was developed

in order to ease the generation of code, as well as to provide the required properties for the ﬁnal application

(speciﬁcally, temporal behaviour). This paper describes how distribution support was added to the framework

in a regular way without disrupting its design, and allowing users to integrate communication overload in

timing analysis.

1 INTRODUCTION

There is a well established tradition of applying

Component Based Software Development (CBSD)

(Szyperski, 2002) principles in the robotics commu-

nity, which has resulted in the appearance of several

tool–kits and frameworks for developing robotic ap-

plications (Rosta, 2010). The main drawback of such

frameworks is that, despite being Component-Based

(CB) in their conception, designers must develop, in-

tegrate and connect these components using Object-

Oriented (OO) technology. The problem comes from

the fact that CB designs require more (and rather dif-

ferent) abstractions and tool support than OO technol-

ogy can offer. Moreover, most of these frameworks

impose the overall internal behaviour of their compo-

nents. In particular, robotic systems are reactive sys-

tems with Real-Time (RT) requirements by their very

nature, and most of the frameworks for robotics do

not provide mechanisms for managing such require-

ments. Additionally, these systems normally com-

prise several computational nodes, and thus distribu-

tion is also an important issue. From our point of

view, the design and implementation of CB frame-

works for robotic applications development should

overcome, among others, the following problems:

1. The deﬁnition or adoption of a component lan-

guage for modelling applications. This language

should allow designers to work with CB abstrac-

tions rather than with OO ones. It should also take

into account the systems requirements, including

their timing properties.

2. The translation of the resulting models to exe-

cutable code and to analysis models that can be

injected to tools in order to analyse both the CB

application properties and the properties of the re-

sulting executable code.

3. It is necessary to provide services for component

distribution that are compatible with the CB archi-

tecture and its RT requirements.

As explained below, the Model Driven Software

Development (MDSD) (Schmidt, 2006) approach al-

lows addressing these problems globally, and con-

stitutes the technological framework where the work

presented in this paper is being developed. MDSD

enables us to deﬁne a component language for mod-

elling the application architecture, to deﬁne a set of

model transformations for both generating implemen-

tation code and analysis models from the previously

deﬁned models, and to integrate component distribu-

tion and timing properties in an orthogonal way.

290

Sánchez-Ledesma F., A. Pastor J., Alonso D. and Rosique F..

AN IMPLEMENTATION FRAMEWORK FOR COMPONENT-BASED APPLICATIONS WITH REAL-TIME CONSTRAINTS - Extensions for Achieving

Component Distribution.

DOI: 10.5220/0003500402900293

In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 290-293

ISBN: 978-989-8425-77-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

The remainder of this paper is organized as follows.

Section 2 explains the overall approach and the way

in which CB concepts have been translated into OO

concepts to generate executable programs, resulting

in the development of an OO implementation frame-

work. Section 3 explains the importance of including

in the framework support for component distribution,

as well as to justify the approach taken to do so. Sec-

tion 4 explains in detail component deployment. Fi-

nally, Section 5 presents the conclusions and future

work.

The paper considers the domain of service robots,

but it could be extended to other domains with sim-

ilar characteristics, since we consider “generic” or

“domain-independent” concepts.

2 GENERAL OVERVIEW AND

PREVIOUS WORKS

Our global development approach starts by mod-

elling the architecture of the application using the

CBSD approach, and then use a series of model

transformations to generate both analysis models

and executable code. Though any modelling lan-

guage can be used for performing the ﬁrst step,

we developed our own modelling language, entitled

CMMV3CMM V

CMMV3CMM (Iborra et al.,

2009). This language provides three complementary

but loosely coupled views that allows designers to de-

ﬁne and connect software components, namely: (1) an

architectural view to deﬁne components (interfaces,

ports, services offered and required, composite com-

ponents, etc.), (2) a coordination view to specify com-

ponent behaviour, based on timed automata theory,

and ﬁnally (3) an algorithmic view to express the se-

quence of actions executed by a component according

to its current state, based on activity diagrams.

In order to ease the generation of executable code

from the application expressed in terms of architec-

tural components, an OO framework was designed

and implemented (Pastor et al., 2010). Such frame-

work provides the base classes for implementing the

components of the architectural design deﬁned in

CMMV3CMM, and an infrastructure for the user

to choose the concurrency features that he ultimately

wants for the application: number of threads, code

allocated to such threads, deadlines, priorities, etc.

The framework provides an OO interpretation of the

CBSD concepts that allows translating the CB de-

signs to OO applications. The design and documen-

tation of the framework was carried out using de-

sign patterns, which is a common practice in Soft-

ware Engineering (Buschmann et al., 2007). Figure

ﬁg:secuenciaPatrones shows the sequence of patterns

applied to the design of the framework in order to

meet the following requirements:

1. Control over concurrency policy: thread number,

thread spawning (static vs. dynamic policies) and

thread characteristics (deadline, period, priority,

etc.), scheduling policy (ﬁxed priority schedulers

vs. dynamic priority scheduler). Unlike most

frameworks, these tasking issues are very impor-

tant for us, and can be selected by the user of the

framework.

2. Control over the allocation of activities to threads,

that is, control over the computational load as-

signed to each thread. The framework allows allo-

cating all the activities to a single thread, allocat-

ing every activity to its own thread, or a combina-

tion of both policies. In any case, the framework

design ensures that only the activities belonging

to active states are executed.

3. Control over the communication mechanisms be-

tween components. The communication mecha-

nism implemented by default in the framework is

the asynchronous without reply scheme, based on

the exchange of messages.

4. Facilitate the instantiation of the framework to ob-

tain OO code from the CBSD model.

5. Control over the distribution policy of the compo-

nents in computational nodes.

The framework deﬁnes extra regions and activi-

ties to manage the ﬂow of messages through ports,

the internal memory of the component, and each re-

gion of the component’s state machine. It is worth

highlighting that this design facilitates schedulability

analysis, since no code is “hidden” in the framework

implementation, but it must be explicitly allocated to

a particular thread.

With all this, the framework code is organized into

three groups with clearly deﬁned interfaces: (C1) pro-

vides the runtime support, (C2) provides an OO inter-

pretation of the CBSD concepts and the framework

’hot-spots’, and (C3) the application-speciﬁc code

that supplement the ’hot-spots’ of the framework to

create a speciﬁc application. This classiﬁcation en-

ables providing an alternative interpretation of CBSD

concepts (C2) that use the same run-time (C1), and

reusing the same application (C3) in a different run-

time (C1), provided that C2 is not changed.

3 COMPONENT DISTRIBUTION

Despite the number of currently available middleware

technologies, we decided to develop an ad-hoc mid-

AN IMPLEMENTATION FRAMEWORK FOR COMPONENT-BASED APPLICATIONS WITH REAL-TIME

CONSTRAINTS - Extensions for Achieving Component Distribution

291

Figure 1: Dependency relationships existing between the patterns considered in the framework development and the

CMMV3CMM V

CMMV3CMM views.

dleware for carrying out component distribution for

the following reasons:

• The users of commercial middleware normally

lose the control over the execution of the appli-

cation (the “inversion of control” problem), as

well as some RT characteristics (like number of

threads, thread periods, computing time, etc.) that

must be taken into account if RT analysis is re-

quired, as in our case.

• We do not need all the distribution services nor-

mally provided by middlewares like CORBA. In

our case, the components that make the applica-

tion up and the connections among them are de-

ﬁned in the input models, and therefore services

like naming, registering, searching, etc. are not

needed.

Newly, the artefacts in charge of managing com-

ponent distribution and deployment are considered

“normal” components, in the sense that they use the

same elements and behave exactly like any other com-

ponent in the application. This allows us to regularly

include the communication overhead in the RT anal-

ysis, provided that transmission times are known and

can be incorporated to the execution time associated

to the activities that manage communications.

In order to make the distribution possible and fea-

sible, two artefacts have been deﬁned: one belonging

to the CBSD domain (the LOCALPROXYMANAGER

component) and the other a class of the framework

(the APPLICATIONDEPLOYER class). It is worth

highlighting that the implementation of both elements

did not require modifying the original framework

structure, but they only instantiate the base classes

provided by it.

The APPLICATIONDEPLOYER class acts as the

master node for application deployment, and

thus it must be executed in its own node before

the application can be deployed. The APPLI-

CATIONDEPLOYER is in charge of notifying

each LOCALPROXYMANAGER component

(previously deployed in each and every node

that make the application up) which component

it must create (or destroy), which ports it must

connect (or disconnect), and to which other nodes

it must establish a TCP connection. Thus, the

APPLICATIONDEPLOYER can be considered as a

simpliﬁed Broker (Schmidt et al., 2000), without

explicit register nor look-up services.

The LOCALPROXYMANAGER component is de-

ﬁned using V

CMMV3CMM, in terms of ports,

operations, states, etc., and its objectives are (i) to

create and connect component instances in the

node it manages, and (ii) to act as a proxy of the

ports of remote components. This component is

not meant to be directly added by the application

developer, but, for each deployment node, one of

such components is automatically added to the

architecture of the application, and then imple-

mented by the framework distribution service.

At the time of making application deployment,

every LOCALPROXYMANAGER create ports that

replicates local ports of the components hosted

on others nodes as commanded by the APPLICA-

TIONDEPLOYER. In this way communication is

carried out as if both components were contained

within the same node.

4 CONCLUSIONS AND FUTURE

WORK

This paper has described the evolution of a previous

work, where a OO framework for implementing CB

designs was described. The new features consist on

the support for component distribution. Distribution

capacity was added in a regular way to the frame-

work, respecting its original design. This regularity

allows us to analyse the impact on the temporal char-

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

292

acteristics of the application that has a certain dis-

tribution of its components. Only the strictly neces-

sary distribution services have been incorporated to

the framework in order to perform component dis-

tribution, taking into account that the architecture is

deﬁned previously, and thus it is an input parame-

ter to the master node. The proposed solution is not

closed to future improvements, but it is a stable start-

ing point for further development. The approach has

been validated with small–scale applications, targeted

to “academic” platforms (the in–house developed ve-

hicle Lazaro, the Pioner P3AT commercial robot, and

a simple electrical vehicle). Therefore it still needs to

be tested in larger applications.

The work described in this article is a work in

progress. Currently, work is continuing to extend

the framework with additional features following a

pattern-driven approach. Among these extensions it

is worth highlighting the following (1) the addition

of heuristics to determine the number of threads and

carry out the assignment of the activities of the com-

ponents to these threads, (2) development of model

transformations to instantiate the framework from an

input componentmodel, (3) adapt the implementation

to be compliant with the Ravenscar proﬁle for design-

ing strict RT applications, and (4) development of a

model transformation for generating input models for

analysis tools.

ACKNOWLEDGEMENTS

This work has been partially supported by the Spanish

CICYT Project EXPLORE (ref. TIN2009-08572).

REFERENCES

Buschmann, F., Henney, K., and Schmidt, D. (2007).

Pattern-Oriented Software Architecture, Volume 5:

On Patterns and Pattern Languages. John Wiley and

Sons Ltd.

Iborra, A., Alonso, D., Ortiz, F., Franco, J., Sánchez, P., and

Álvarez, B. (2009). Design of service robots. IEEE

Robot. Automat. Mag., Special Issue on Software En-

gineering for Robotics, 16(1):24–33.

Pastor, J., Alonso, D., Sánchez, P., and Álvarez, B. (2010).

Towards the deﬁnition of a pattern sequence for real-

time applications using a model-driven engineering

approach. In Proc. of the 15

Ada-Europe Interna-

tional Conference on Reliable Software Technologies,

Ada Europe 2010, LNCS, pages 167–180. Springer-

Verlag.

Rosta (2010). Robot Standards and Reference Archi-

tectures (RoSTa), Coordination Action funded under

EU’s FP6.

Schmidt, D. (2006). Model-driven engineering. IEEE Com-

puter, 39(2):25–31.

Schmidt, D., Stal, M., Rohnert, H., and Buschmann, F.

(2000). Pattern-oriented software architecture, vol-

ume 2: patterns for concurrent and networked objects.

Wiley.

Szyperski, C. (2002). Component software: beyond object-

oriented programming. A-W, 2 edition.

AN IMPLEMENTATION FRAMEWORK FOR COMPONENT-BASED APPLICATIONS WITH REAL-TIME

CONSTRAINTS - Extensions for Achieving Component Distribution

293