Content uploaded by Oscar Carrillo

Author content

All content in this area was uploaded by Oscar Carrillo on Mar 07, 2014

Content may be subject to copyright.

Toward Validated Composition in

Component-based Adaptive Middleware

Annie Ressouche1, Jean-Yves Tigli2, and Oscar Carrillo1

1INRIA Sophia Antipolis

2004, route des Lucioles, BP 93

06902 Sophia Antipolis, Cedex France

annie.ressouche@inria.fr, ocrozo@gmail.com

2I3S Laboratory, Nice Sophia University

CNRS, Polytech’Sophia SI 930 route des Colles, BP 145

06903 Sophia Antipolis, Cedex, France

tigli@polytech.unice.fr

Abstract. Nowadays, adaptive middleware plays an important role in

the design of applications in ubiquitous and ambient computing. Cur-

rently most of these systems manage the adaptation at the middleware

intermediary layer. Dynamic adaptive middleware are then decomposed

into two levels : a ﬁrst one to simplify the development of distributed sys-

tems using devices, a second one to perform dynamic adaptations within

the ﬁrst level. In this paper we consider component-based middleware

and a corresponding compositional adaptation. Indeed, the composition

often involves conﬂicts between concurrent adaptations. Thus we study

how to maintain consistency of the application in spite of changes of crit-

ical components and conﬂicts that may appear when we compose some

component assemblies. Relying on formal methods, we provide a well

deﬁned representation of component behaviors. In such a setting, model

checking techniques are applied to ensure that concurrent access does

not violate expected and acceptable behaviors of critical components.

Keywords: component-based middleware, adaptive middleware, validation, for-

mal methods, synchronous modelling

1 Introduction

1.1 Component-based Adaptive and Reactive Middleware

Ubiquitous computing follows an evolution of computer science introduced by

Weiser [21] two decades ago. A major consequence is the arrival of applications

more and more opened on every day environment relying on objects supposedly

communicating and intelligent. Devices managed in ubiquitous computing are

nowadays heterogeneous,variable, and interacting with a physical environment.

Moreover, applications in this domain must often face some variability during

execution time. Moving with a mobile user, such applications have not always

access to the same devices. Thus, it turns out that the appearance and disap-

pearance of these latter need a dynamic evolution of the application. Hence,

evolving in a real environment, ubiquitous applications must be able to react to

changes in the surrounding physical environment.

Then, it is a real challenge to address these constraints for middleware. In-

deed, now they must support a stable applicative model in spite of a heteroge-

neous and variable software infrastructure. Actually, middleware must be reactive

(they must react to context change) and adaptive (they must adapt themselves

continuously to context changes).

Historically, [18] deﬁnes two extremes in the range of strategies for adap-

tation. At one extreme, adaptation is entirely the responsibility of individual

applications. The other extreme of application-transparent adaptation places

entire responsibility for adaptation on the system. Currently most of the work

converge to manage the adaptation at the middleware intermediary layer [1].

In this last case dynamic adaptive middleware are then decomposed into two

levels [7]. The primary level of middleware is to simplify the development of

distributed systems [10]. The second level performs dynamic adaptations within

middleware.

Because ubiquitous computing is based on preexisting devices, middleware

must manage legacy of black-box of software pieces. Three kinds of approaches

are well suited to manage such constraints : component oriented middleware,

service oriented middleware and more recently new popular approaches using

components assembly to compose preexisting services like, SCA or SLCA ([19]).

The second level of adaptive middleware manage dynamic modiﬁcations of

the ﬁrst one to perform adaptation. According to [14] we can distinguish two

main approaches to implement software adaptation. The ﬁrst one is parameter

adaptation. For component based middleware this approach consists in modi-

fying components variables that determine their behavior. The second one is

compositional adaptation. This approach allows component-based middleware

to change dynamically components with others in response to changes in its ex-

ecution environment. In this paper we study how to maintain consistency of the

application in spite of critical components changes and conﬂicts that may ap-

pear when we superpose component assemblies in mechanisms for compositional

adaptation. Indeed in such cases, we need to use veriﬁcation techniques to check

safety and various other correctness properties of the evolving application.

1.2 Need for Validation

Then, the main motivation appears when we introduce new requirements for

ubiquitous applications such as safety. Indeed, few research works in ubiquitous

computing address some partly critical applications. For example, many ubiq-

uitous applications address health care domain without validating some critical

functionalities. Anyway, safety is an important concern in adaptive middleware.

Applications may intervene in critical systems (i.e. system whose failure or mal-

function may result in death or serious injury to people, or loss or severe damage

to equipment or environmental harm). Components may have to satisfy strin-

gent constraints related to security and should be submitted to formal veriﬁca-

tion and validation. Moreover, context change adaptation should preserve safety

rules. Then key problems are :(1) how to specify and validate the behavior of one

assembly connected to a critical component (Cf. section 3), (2) in case of multiple

assemblies sharing some critical components (see the end of section 1.1), how to

compose them and validate properties of the overall application (Cf. section 4).

1.3 Our Proposal

In this work, we introduce a means to describe critical component behaviors

as synchronous monitors for which formal methods and model checking tech-

niques apply. Nevertheless, our major contribution is the deﬁnition of a sound

composition operation also lying on formal methods and useful to perform con-

text adaptation. We prove safety property preservation through this operation,

hence we oﬀer the ability to perform veriﬁcation over assembly composition.

Thus we extend our component-based adaptive middleware with speciﬁc tools

to allow validation of local composition on critical devices and services, using

model checking techniques.

The paper is organized as follows: next section (2) brieﬂy describes the com-

ponent-based middleware use we consider and introduces the example we rely on

all along the paper to illustrate our approach. It is extracted from a use case in

the domain of health care for elderly. Then section 3presents our solution which

introduces synchronous monitors to model critical devices expected behaviors.

They support formal validation. In section 4we introduce a composition oper-

ation between synchronous monitors preserving validated properties. Such an

approach allows us to oﬀer a deterministic solution to multiple access to critical

devices. We discuss the practical issues of our work in section 5. We introduce

our reactive adaptive middleware for ubiquitous computing, named WComp and

also its extension with veriﬁcation facilities. Then we describe the implementa-

tion of the example in our middleware. In section 6we compare our approach

with diﬀerent works which address the problem of reliability of middleware for

ubiquitous computing. Finally, section 7concludes and opens the way for future

works.

2 Component-based Middleware Use

In this work, we consider middleware where communication means are event-

based. Of course event-driven systems are not suitable for very complex design,

but adequate for reactivity, dynamicity and high adaptability. In our approach

such components are often proxies for services for device and then must reﬂect

the device behavior. Some of them are critical and we want to validate their

usage within some middleware assemblies.

We illustrate our approach with the design of (a small part of) an application

in the domain of health care for elderly. The purpose is to monitor old adult in an

instrumented home, using sensing technology. There are diﬀerent kinds of sensors

in the environment: video cameras, contact sensors to indicate closed or opened

status of equipment, wearable sensors, etc. In this framework, we are deep in

the domain where reactive and adaptive middleware solutions apply, since some

sensors can appear and disappear (particularly wearable ones). In this example,

we show the design of a small part of a project dedicated to observe activities

of daily living (ADLs) in an equipped home 3. We consider the recognition of

activities related to kitchen usage. The goal is to send several kinds of alarms

depending on sensor observation results. Component proxies are associated to

four sensors: a contact sensor on the fridge which indicates the state of the door

(opened or closed); a timer which sends a minute information; a camera which

locates a person; a posture sensor which tells if the person is standing, sitting

or lying. This latter is a wearable device composed by accelerometers.

In this application, an Alarm component proxy receives three kinds of alarms:

warning,weak alarm and strong alarm. It is linked with assemblies of compo-

nents for fridge and timer sensors, camera sensor and posture sensor. This Alarm

component is critical and we will ensure that it raises the appropriate alarm in

the designed application. To this aim, we oﬀer a mean to ensure that each out-

put event coming from one of the designed assemblies for sensors is correctly

sent. Indeed, we supply a new component reﬂecting the behaviors of (assemblies

of) components and we check that these latter are used out of harm’s way (see

section 3.2). Moreover, it is not suﬃcient to individually prove that each new

component outputs are not misused. We also must ensure that the combination

of two output events coming from two diﬀerent assemblies and linked with the

same input event of Alarm component works correctly. Thus we introduce a safe

composition between components (see section 4.2).

3 Components with Validated Behaviors

To validation purpose, we introduce models to describe the behavior of appli-

cation components. Finite automata are well adapted to the representation of

device behaviors and moreover provide a lot of veriﬁcation tools based on eﬃcient

model-checking techniques to verify properties.

3.1 Component Behavior as Synchronous Models

The goal is to deﬁne means to represent component behavior. These components

listen to events coming from other components or from an input environment and

will provide output events in reaction. They have to satisfy stringent constraints

(correctness, response time) and they should be submitted to formal veriﬁcation

and validation as they may intervene in a critical decision. Thus determinism

would be an important advantage. A way of reducing the complexity of behavior

description is to consider them evolve through successive phases. During one

3http://gerhome.cstb.fr/

phase, only the external events which were present at the beginning of the phase

and the internal events that occurred as a consequence of the ﬁrst ones are

considered. The phase ends when some stability has been achieved (or when an

external clock decides that it is over). We call such a phase an instant. Such an

instant-based representation will be called a synchronous model. In such models,

a reaction has no duration because its real duration is delayed to the next clock

cycle or next instant of the system. This issue characterizes the synchronous

hypothesis on which all synchronous models rely. A signiﬁcant way well suited

to validation is to express these models as Mealy machines [15]. Mealy machines

are both ﬁnite automata and synchronous models. Indeed a transition in Mealy

machines corresponds to a reaction or an instant of the system.

The Mealy machines we consider are 5-uple of the shape:

< Q, qinit, I, O , T, λ >, where Qis a ﬁnite set of states; qinit ∈Qis the initial

state. I(resp. O) is a ﬁnite set of input (resp. output) events; T ⊆ Q×Qis

the transition relation. λis a labeling function: λ:T × IB7→ 2O

4where IBis

the set of Boolean expressions over I5. It is a Boolean algebra with standard

interpretation for true, f alse, ·,+ and ¬6. In short, qi/o

−−→ q0will denote a

transition with the agreement: (q, q0)∈ T and λ((q, q0), i) = o. Furthermore,

according to the synchronous hypothesis, we want our model deterministic and

reactive:

1. qi/o1

−−−→ q1and qi/o2

−−−→ q2∈ T ⇒ q1=q2and o1=o2(determinism)

2. ∀i∈IB,∀q∈Q, ∃qi/o

−−→ q0∈ T (reactivity)

Critical components will provide a synchronous model of their behavior and

some additional properties (constraints) checked when component is used. This

model is designed as a Mealy machine where each output is connected with an

input event of the critical component. Indeed, let us consider a synchronous mon-

itor speciﬁed as the Mealy machine M=< Q, qinit , I, O, T, λ > and connected

to a critical component with ICas input event set. There must exist an injective

mapping : in :O7→ IC.

3.2 Use Case Synchronous Monitor Deﬁnition

In the application introduced in section 2, there is an assembly related to the

posture sensor and connected to the Alarm component. According to section 3.1,

we will deﬁne a synchronous monitor to describe the behavior of the assembly.

This posture monitor listens to I3={sitting, standing , lying}input event set.

Its output event set is O3={warning3, weak alarm3}. It emits a warning3

event when the person is sitting or standing and a weak alarm3event when

42O

= 2O∪ {}and represents an undeﬁned event.

5Its elements are built according to the following grammar: e:= true |false |I|e·

e|e+e|¬e.

6We will consider usual Boolean algebra rules to infer equality between two elements

of IB.

warning

weak_alarm

strong_alarm

alarm

posture

monitor

from

synchronous

lying

standing

sitting warning3

weak_alarm3

Fig. 1. A synchronous monitor to manage the access to the critical alarm proxy com-

ponent from the posture sensor assembly.

he(she) is lying 7. This monitor is the Mealy machine < Q3, qinit

3, I3, O3,T3, λ3>

with an only state and two transitions:

qinit

3

(standing or sitting)and not lying/warning3

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ qinit

3

qinit

3

(not standing and notsitting)and lying/weak alarm3

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ qinit

3

Finally, the critical Alarm proxy component has

IA={warning , weak alarm, strong alarm}as input event set and there is an

injection in3:O37→ IA:in3(warning3) = warning

in3(weak alarm3) = weak alarm

Figure 1shows the assembly we get in the application for this posture syn-

chronous monitor. Then, safety and liveness properties concerning critical com-

ponent usage can be veriﬁed using model-checking tools ([3] among a lot of

them).

3.3 Component Behavior Validation

Among others validation techniques, the model-checking approach [13] re-

quires a model of systems against which formulas are checked for satisfaction.

The model must express all the possible behaviors of the system, the formulas

depict required properties of such behaviors. Synchronous Mealy machines are

well suited to express these behaviors and they are relevant models to apply

model checking techniques. The properties may be formalized as formulas of a

formal logic interpreted over automata. In order to beneﬁt from well-known re-

sults about the preservation of properties through composition, we will consider

the ∀CT L∗logic [13]. It is a formal language where assertions related to behavior

are easily expressed. It is based on ﬁrst-order logic and oﬀers temporal operators

that make it possible to express properties holding for states and paths. Nowa-

days, almost all model checking tools check ∀C T L∗properties against automata

models.

The logic is interpreted over Kripke structures 8in order to express model

checking algorithms and satisfaction of a state formula is deﬁned in a natural

inductive way (see [13] for complete deﬁnitions). A Mealy machine Mcan be

7it is a weak alarm since lying posture is not dangerous in all contexts.

8AKripke structure Kis a tuple: K=< Q, Q0, A, R, L > where: (1) Qis a ﬁnite

set of states; (2) Q0⊆Qis the set of initial states; (3) Ais a ﬁnite set of atomic

propositions; (4) R⊆Q×Qis a transition relation that must be total: for every

state q∈Q, there is a state q0such that R(q, q0); (5) L:S7→ 2Ais a labeling

function that labels each state by the set of atomic propositions true in that state.

mapped to a Kripke structure K(M), which is also a state machine. We don’t

detail this adaptation, it is fully described in [17].

Deﬁnition 1. We say that a Kripke structure Ksatisﬁes a state formula ψ

(K|=ψ) if property ψis true for the initial states of K. This deﬁnition is

extended to Mealy machines: M|=ψiﬀ K(M)|=ψ;

In our approach, several synchronous monitors can drive the same proxy

component corresponding to several sub-assemblies respectively managing dif-

ferent concerns. Indeed, there is no communication between these monitors and

their output event sets are disjoint. But we need to compose them and specify

a composition mechanism.

4 Synchronous Model Composition

When a critical component has multiple synchronous monitors corresponding

to several concern managements in the application, we want to build an only

synchronous model component which agrees with all these primitive synchronous

monitors and whose output event set is related to the input event set of the

critical component by an injection. We continue to rely on our use case (see

section 2) to illustrate such a situation.

4.1 Use case Multiple Access

warning

in_kitchen from

sitting

lying posture

monitor

from

camera

warning1synchronous

monitor

close_fridge

fridge

fridge_opened

one_minute

standing warning3

weak_alarm3

weak_alarm

strong_alarm

alarm

synchronous

synchronous

monitor

from weak_alarm2

warning2

Fig. 2. Multiple access to alarm

proxy component

warning

weak_alarm

strong_alarm

alarm

synchronous

from posture

monitor

fridgefrom

synchronous

monitor

from camera

monitor

synchronous

ζ

sitting

lying

standing

one_minute

fridge_opened

in_kitchen

close_fridge

Fig. 3. Composition of multiple access to con-

nect the alarm proxy component

In our use case, there are three sub-assemblies linked to the critical Alarm

component. Thus, we introduce three synchronous monitors in this assembly.

The ﬁrst synchronous monitor describes the behavior of Alarm component with

respect to the sub assembly managing the camera device; the second is deﬁned

with respect to the sub assembly related to the door fridge and timer sensors;

and the third tells the behavior of Alarm when it is related to a sub assembly

managing a posture detection sensor. The camera monitor is a Mealy machine

with {in kitchen, close f ridge}as input set, {warning1}as output set. When

both of its inputs are present, warning1 is emitted. The fridge monitor reacts to

{f ridge opened, one minute}input events and sends a warning2event when the

fridge door is opened and a weak alarm2event when it is opened for more than

one minute. The posture monitor has been described in section 3.2. Thus, we get

the assembly described in ﬁgure 2. We can see that warning and weak alarm

entries have multiple access. Our method will replace these three components

by a single component : camera ⊗fridge ⊗posture |ζ(see ﬁgure 3).

4.2 Multiple Access to Components.

To specify how output events sent by diﬀerent synchronous monitors and con-

nected to a critical component, we introduce an operation of composition under

constraints of synchronous models. We achieve this composition operation rely-

ing on the well-deﬁned synchronous product (⊗) of synchronous models and we

replace the outputs of this latter with respect to a set of constraints (ζ).

Deﬁnition 2. The synchronous product of two Mealy machines (M1⊗M2) is

deﬁned as follows: assume that

M1=< Q1, qinit

1, I1, O1,T1, λ1>and M2=< Q2, qinit

2, I2, O2,T2, λ2>,

then M1⊗M2=< Q1×Q2,(qinit

1, qinit

2), I1∪I2, O1∪O2,T, λ >

where T={((q1, q2),(q0

1, q0

2)) |(q1, q0

1)∈ T1,(q2, q0

2)∈ T2}and

∀(q1, q0

1)∈ T1|λ1((q1, q0

1), i1) = o1)and ∀(q2, q0

2)∈ T2|λ2((q2, q0

2), i2) = o2)

then λ(((q1, q2),(q0

1, q0

2)), i1·i2) = o1∪o2).

The synchronous product considers all the combinations of states, taking into

account the simultaneity of events according to our synchronous approach. As

already mentioned, in the composition operation we consider only synchronous

monitors driving the same proxy component. On one hand, the synchronous

product allows to agree with each synchronous monitor. On the other hand, it

introduces transitions whose output label carry events belonging to the union

of the respective event sets of M1(O1) and M2(O2). But we want that the

relationship between the output event set of the composition and the input set

(IC) of the critical component will be at least an injection. Thus, we apply

to the synchronous product a “constraint function” deﬁned according to the

respective injections in1:O17→ ICand in2:O27→ IC. First, we introduce

a new output event set Oand an injection in :O7→ IC. Second, we deﬁne a

surjective function γ:O1∪O2∪O1×O27→ Osuch that: (1) ∀o1∈O1,γ(o1) = o

and in(o) = in1(o1); (2) ∀o2∈O2,γ(o2) = oand in(o) = in2(o2).

From these deﬁnitions, a “constraint” function ζ: 2O1∪O27→ 2Ois deduced:

∀o∈2O1∪O2, if ∃o1, o2∈osuch that γ(o1, o2)6=then γ(o1, o2)∈ζ(o); else

γ(o1)∈ζ(o) and γ(o2)∈ζ(o).

This constraint function is applied to the output label sets of of the syn-

chronous product:

Deﬁnition 3. Assume that M1⊗M2=< Q1×Q2,(qinit

1, qinit

2), I1∪I2, O1∪

O2,T, λ > , then M1⊗ |ζM2=< Q1×Q2,(qinit

1, qinit

2), I1∪I2, O, Tζ, λζ>where

Tζ=Tand λζis deﬁned as follows:

λζ(((q1, q2),(q0

1, q0

2)), i) = oiﬀ λ(((q1, q2),(q0

1, q0

2)), i) = o1∪o2and ζ(o1∪o2) = o

(assuming that λis the labeling function of M1⊗M2).

The synchronous product of two Mealy machines yields a Mealy machine.

It is a well-known result of the synchronous framework. Constraint function

application modiﬁes only output event sets of labels and thus our composition

operation constructs a Mealy machine.

4.3 Composition and Validation.

Our composition operation allows solving the multiple access to a given proxy

component problem. The result of this operation is a Mealy machine against

which model-checking techniques apply as for any synchronous monitor (see

3.3). Moreover, we also want the preservation of properties under composition:

if M1veriﬁes an ∀CT L∗formula Φ(M1|=Φ) then this latter also holds for a

composition where M1is part of (M1⊗ |ζM2|=Φ). To prove such a feature, we

show that K(M1) can be viewed as an “approximation” of K(M1⊗ |ζM2).

Deﬁnition 4. Let K1=< Q1, Q0

1, A1, R1, L1>and K2=< Q2, Q0

2, A2, R2, L2>

be two kripke structures and haa surjection from A1to A2. We say that K2ap-

proximates K1(denoted K1vhK2) when

1. It exists a surjection h:Q17→ Q2such that: h(q1) = q2⇒ ∀a2∈L2(q2),∃a1∈

L1(q1)and ha(a1) = a2.

2. ∀q2∈Q0

2,∃q1∈Q0

1and h(q1) = q2; and

3. ∃q1, q0

1(h(q1) = q2, h(q0

1) = q0

2and R1(q1, q0

1)⇒R2(q2, q0

2)).

Now we make more precise what does mean ∀CT L∗properties are preserved

through our composition operation. In [12], Clarke and all show that ∀CT L∗

formulas are preserved for transition system approximations. We use the same

method to prove that ∀CT L∗formulas are preserved through Kripke structure

approximations. Let K1and K2be two Kripke structures and ha:A17→ A2a

surjective mapping such that there is a surjection hfrom Q1to Q2and K1vh

K2. The method consists in (1) deﬁne a translation (τ) from formulas expressing

properties in K2and formulas expressing properties in K1and to prove that if

a property φholds for K2,τ(φ) holds for K1. For lack of space, we do not detail

the proof but it is an induction on the structure of formulas and it is told in

detail in [17]. We apply these results to synchronous monitors.

For short, we will denote M1⊗ |ζM2as Mζ.K(M1) =<KQ1, Q0

1, A1, L1, R1>

and K(Mζ) =<KQζ, Q0

ζ, Aζ, Lζ, Rζ>are built according to the translation op-

eration (fully described in [17]). Then we deﬁne (1) a surjective ˆ

hafrom Aζto A1

and a surjective mapping: ˆ

h:KQζ7→ KQ1and we prove that K(Mζ)vˆ

hK(M1)

(see [17]). By construction Aζis composed of elements of the form i1.i2(i1be-

longs to I1the input event set of M1and i2to I0

2) and of elements belonging to

O. Indeed, ˆ

hais deﬁned as follows: ˆ

ha(i1.i2) = i1and ˆ

ha(o) = o1if γ(o1) = o.

Now, we deﬁne a translation mapping τζbetween formulas related to K(Mζ)

and those related to K(M1). This mapping is ﬁrst deﬁned on atomic formulas :

τζ(true) = true;τζ(f alse) = false;∀a1∈A1, τζ(a1) = _

aζ∈Aζ

aζ|ˆ

ha(a1) = aζ.

Then it is structurally extended to all formulas according to the syntax of the

logic.

Now, we get the main preservation theorem:

Theorem 1. Let M1and M2be two Mealy machines and φa∀CT L∗formula

related to M1, then M1|=φ⇒M1⊗ |ζM2|=τζ(φ)

The proof of this theorem is also detailed in [17]. It is a corollary of the gen-

eral result about the preservation of ∀CT L∗formulas through Kripke structure

approximations touched on just before.

4.4 Adaptivity

To support both adaptation and safe composition lays down that synchronous

monitors and constraint functions are available at runtime. The drawback of this

approach is the exponential number of constraint functions due to the diﬀerent

combination of synchronous monitor composition. Constraint functions describe

how the diﬀerent outputs of synchronous monitors linked with the same input

of a critical component are reconciled. As monitor output events are disjoint,

we can apply default combination rules for outputs in order to reduce the com-

plexity of constraint function number. Moreover, we can compose monitors in

an incremental way, hence runtime adaptation is made more eﬃcient. Then, the

preservation theorem ensures us that properties holding locally are still valid

after an incremental composition process.

5 Practical Issues

5.1 Our WComp Middleware

Relying on this theoretical approach, we improve our WComp([19]) middleware

to support synchronous component design and validation of behaviors for criti-

cal components. WComp is a reactive and adaptive middleware approach which

takes into account the principles for ubiquitous computing described in sec-

tion 1.1. The ﬁrst level of WComp corresponds to a component-based middle-

ware to compose services for device. The composition is then implemented as a

lightweight component assembly. Components interact through events and some

of them are connected to services for devices. The second level of WComp use

an adaptation paradigm with the original concept named Aspect of Assembly

(AA). Because such a mechanism produces sub-assemblies of components to be

superimposed (weaved in our case) to produce the appropriate application, we

leverage the work presented in this paper to preserve the safety of the evolving

application.

5.2 WComp Critical Component Speciﬁcation

In section 3, we have shown that the introduction of speciﬁc synchronous compo-

nents are an answer to address the multiple access to critical component prob-

lem. Nevertheless, these synchronous components we introduce, represent the

behaviors of critical components as Mealy machines. These latter are models

very well suited to formally prove the soundness of our approach, but they are

not convenient to deal with. Thus we rely on the Lustre [16]synchronous lan-

guages. It respects the synchrony hypothesis which divides time into discrete

instants. It is a data ﬂow language oﬀering two main advantages: (1) It is a

functional language with no complex side eﬀects. This makes it well adapted to

formal veriﬁcation and safe program transformation. Also, reuse is made easier,

which is an interesting feature for reliable programming concerns; (2) it is a

parallel model, where any sequencing and synchronization depends on data de-

pendencies. We choose this language because, ﬁrst, Mealy machines are models

for it and its compilation provides an implicit representation of them. Second,

the synchronous product we rely on to perform the composition of synchronous

monitors is expressed naturally in the language. Third, constraint functions can

be expressed as equations, thanks to the equational nature of the language.

To perform safety properties validation we rely on the model-checking tool

Lesar [9], a symbolic, BDD-based model-checker for Lustre. It is based on the

use of synchronous observers [8], to describe both the properties to be checked

and the assumptions on the program environment under which these properties

are intended to hold. An observer of a safety property is a program, taking as

inputs the inputs/outputs of the program under veriﬁcation, and deciding (e.g.,

by emitting an alarm signal) at each instant whether the property is violated.

Running in parallel with the program, an observer of the desired property, and

an observer of the assumption made about the environment one has just to check

that either the alarm signal is never emitted (property satisﬁed) or the alarm sig-

nal is emitted (assumption violated), which can be done by a simple traversal of

the reachable states of the compound program. Hence, using observer technique

allows to express the property in the same language used to design our syn-

chronous components and avoid to express ∀C T L∗formulas. Veriﬁcation with

Lesar is performed on an abstract (ﬁnite) model of the program. Concretely, for

purely logical monitors the proof is complete, whereas in general (in particular

when numerical values are involved) the proof can be only partial. In our ap-

proach, component events are associated with two Lustre variables, a Boolean

variable is related to the presence of the event, the other carries it’s value. Thus,

properties related to presence or absence of events can be proved, but properties

related to values depend on the abstraction performed by the tool.

5.3 Use Case Implementation

camera

AND

posture

lying

sitting

fridge

one_minute

fridge_opened

OR

AND

close_fridge

in_kitchen

OR

warning1

warning2

warning3

XOR

AND

weak_alarm2

weak_alarm3

AND

IMPLIES OK

OBSERVER

standing

weak_alarm

warning

strong_alarm

camera x fridge x posture ζ

ζ

Fig. 4. The implementation in Lustre of the use case. The overall implementation (the

composed synchronous monitor +the observer) feeds the Lesar model-checker. The

composed synchronous monitor is plugged in the application.

Now we sketch how we implement the use case in WComp. First, we describe

the three synchronous monitors as Lustre programs (called camera,fridge and

posture). Figure 4shows this implementation in Lustre language. As described

in section 4.2, the composition under constraints of camera,f ridge and posture

components is a Mealy machine, which has for input event set the union of their

respective input event sets components. The output set of the composite compo-

nent we built is {warning,weak alarm,strong alarm}9(we will call it O). We

provide a constraint function to specify how these multiple access are managed

and we use it to build the composite component camera ⊗f ridge ⊗posture |ζ.

Informally, it maps all combinations of warning1, warning2and warning3to

warning event. As soon as either weak alarm2or weak alarm3are emitted, ζ

maps the output set to weak alarm and if both of them belong to an output

set, then a strong alarm is sent since that means that the door of the fridge is

opened for more than one minute and the person kept under watch is lying. Of

course, diﬀerent constraints could be deﬁned. For instance, instead of consider-

ing that a warningiis suﬃcient to launch a warning, we could consider that the

camera and f ridge components must agree and emit respectively warning1and

warning2. This would yield another composition result.

Now, we verify the camera⊗f ridge ⊗posture |ζcomponent before introduc-

ing it in the assembly. Thus, we use the observer technique previously described

9As it is in bijection with the input set of Alarm component, we keep the same name

to an easier identiﬁcation of connections.

to prove that if the fridge is opened for more than one minute and the per-

son is lying, then a strong alarm is sent. We deﬁne an observer which listen

fridge open,one minute,lying and strong alarm events and which computes

a Boolean variable ok and we prove with Lesar that ok is always true.

On another hand, we just want to touch on the application of theorem 1.

Assume that with Lesar, we prove that for fridge component, the property:

fridge opened ⇒warning2holds. Clearly, from the deﬁnition of constraints

in alarm comp, we have τζ(warning2) = warning.

Thus, we can deduce that fridge opened ⇒warning also holds in alarm comp.

After this veriﬁcation, we automatically generated WComp input code for

node alarm comp. Indeed a new component has been automatically weaved in

the assembly designing the application in WComp.

6 Related Works

In this work, we rely on a synchronous modelling to verify the functional cor-

rectness under concurrency of component behavior and component assemblies in

a reactive and adaptive middleware. Other works address the reliability of mid-

dleware. For instance, in [20], the authors propose the TLAM (two-level actor

model) approach for specifying and reasoning about components of open dis-

tributed systems. They show, using the QoS broker MM architecture, how the

TLAM framework can be used to specify and reason about distributed middle-

ware services and their composition. They have also shown how speciﬁcations in

the TLAM framework can lead to implementations. They proved that the imple-

mented middleware correctly works (provided that middleware services respect

a set of constraints) and they planned to rely on a theorem prover to achieve

these proofs and automate their method.

However, in the same vein as our approach, some works rely on model-

checking techniques to ensure the reliability of middleware solutions. For in-

stance, PolyORB is a schizophrenic (“strongly generic”) middleware oﬀering

several core functions and a Broker design pattern to coordinate them. In [11],

Hugues and al, generate Petri nets to model the Broker design pattern of Poly-

ORB and use model checking techniques relying on Petri nets models to ver-

ify qualitative properties (deadlock, bounds of buﬀers, appropriate use of crit-

ical section,...). We don’t use such a modelling because (1) we want to rely on

a user-friendly method to describe critical unknown component behaviors; (2)

properties we consider don’t require Petri nets modelling to be checked. Thus,

we prefer to rely on a language allowing to express both component behavior

and properties to be veriﬁed.

Some other approaches like product line engineering, consider that systems

are developed in families and diﬀerences between family members are expressed

explicitly in terms of features. From this hypothesis, lot of works propose formal

modelling and model-checking techniques to describe and verify the combined

behavior of a whole system family (for example [4] and [6]). In our approach we do

not yet consider dependencies between diﬀerent conﬁgurations of the application,

like software product line families. In the same way, in [2] the authors present

a compositional reasoning to verify middleware-based Software Architecture.

They take advantage of the particular structure of applications due to their

middleware-based approach to prove a global property by decomposition into

local properties veriﬁed at sub component level. In our approach, we don’t yet

have such decomposition algorithms to split a global property. By the time, we

have a bottom-up reasoning and our preservation theorem is suﬃcient.

In [5], Delaval and all also use a synchronous data ﬂow language comple-

mented with a mechanism to depict component contrats (BZR) to extend a

high level component-based model (Fractal) in order to enforce safety proper-

ties concerning component interactions during dynamic reconﬁguration. Indeed

from Fractal speciﬁcation it is possible to extract a BZR program made of the

automata representation of the component behavior and the component con-

tract. Then, using an ad-hoc discrete controller synthesis tool, they generate

in a target executive middleware of Fractal an additional validated controller.

But, common component-based middleware as WComp do not supply enough

information to deduce component behaviors and contracts. Then, we solve the

problem of safe reconﬁguration in relying on sound composition of user-deﬁned

synchronous monitors, which preserves component properties already proved.

7 Conclusion and Future Works

The work described in this paper is derived from our experience in providing sup-

port for correct assembly of components in an event-based reactive and adaptive

middleware. In this latter, we solved the adaptation paradigm using the Aspect

of Assembly concept. When using our middleware, a developer beneﬁts from a

composition mechanism between diﬀerent component assemblies to adapt his

application to context change. While deﬁning this composition mechanism, we

realized the need to formalize and verify the multiple access to a critical compo-

nent (i.e related to a critical device). The corresponding formalism, the topic of

this paper, relies on formal methods. Our approach introduces in a main assem-

bly, a synchronous component for each sub assembly connected with a critical

component. This additional component implements a behavioral model of the

critical component and model checking techniques apply to verify safety proper-

ties about it. Thus, we consider that the critical component is validated. Then

we proposed a sound (with respect to our mathematical formalism) composition

operation between synchronous components. We proved that this operation pre-

serves already separately veriﬁed properties of synchronous components. This

operation is an answer to the multiple access to critical components. Our aim is

to improve our middleware WComp with a dedicated tool. Currently, we supply

a graphical interface to design both critical component behaviors and properties

as observers in the synchronous language Lustre (see section 5). Then the val-

idation of properties and the creation of the validated synchronous component

is automatic. But, designing with Lustre language is not obvious for any ex-

pert user and Lesar model-checker does not allow to verify properties related to

events carrying data of complex type. Thus, in the future we aimed at providing

a user-friendly interface to express critical component behaviors and properties.

This interface will report about violation of properties relying on powerful model

checker as NuSMV [3] and straightly (without using the Lustre compiler) gener-

ate internal code to implement synchronous monitors. Nevertheless, to validate

properties dealing with data, we must study how abstraction techniques apply

in our approach or how we can adapt them.

References

1. ARM ’10: Proceedings of the 9th International Workshop on Adaptive and Reﬂec-

tive Middleware, New York, NY, USA, 2010. ACM.

2. Mauro Caporuscio, Paola Inverardi, and Patrizio Pelliccione. Compositional veri-

ﬁcation of middleware-based software architecture descriptions. In ICSE ’04: Pro-

ceedings of the 26th International Conference on Software Engineering, pages 221–

230, Washington, DC, USA, 2004. IEEE Computer Society.

3. A. Cimatti, E. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore, M. Roveri, R. Se-

bastiani, and A. Tacchella. NuSMV 2: an OpenSource Tool for Symbolic Model

Checking. In Ed Brinksma and Kim Guldstrand Larsen, editors, Proceeeding CAV,

number 2404 in LNCS, pages 359–364, Copenhagen, Danmark, July 2002. Springer-

Verlag. Available from: http://nusmv.irst.itc.it.

4. Andreas Classen, Patrick Heymans, Pierre-Yves Schobbens, Axel Legay, and Jean-

Fran¸cois Raskin. Model checking lots of systems: eﬃcient veriﬁcation of temporal

properties in software product lines. In Proceedings of the 32nd ACM/IEEE Inter-

national Conference on Software Engineering - Volume 1, ICSE ’10, pages 335–344,

New York, NY, USA, 2010. ACM. Available from: http://doi.acm.org/10.1145/

1806799.1806850,doi:http://doi.acm.org/10.1145/1806799.1806850.

5. Gwena¨el Delaval and ´

Eric Rutten. Reactive model-based control of reconﬁgu-

ration in the fractal component-based model. In 13th International Symposium

on Component Based Software Engineering (CBSE 2010), Prague, Czech Repub-

lic, June 2010. Available from: http://pop-art.inrialpes.fr/people/delaval/

pub/delaval-cbse10.pdf.

6. Kathi Fisler and Shriram Krishnamurthi. Modular veriﬁcation of collaboration-

based software designs. In Proceedings of the 8th European software engineer-

ing conference held jointly with 9th ACM SIGSOFT international symposium on

Foundations of software engineering, ESEC/FSE-9, pages 152–163, New York, NY,

USA, 2001. ACM. Available from: http://doi.acm.org/10.1145/503209.503231,

doi:http://doi.acm.org/10.1145/503209.503231.

7. Paul Grace. Dynamic adaptation. In H. Miranda B. Garbinato and L. Rodrigues,

editors, Middleware for Network Eccentric and Mobile Applications, pages 285–304.

Springer, 2009.

8. N. Halbwachs, F. Lagnier, and P. Raymond. Synchronous observers and the veriﬁ-

cation of reactive systems. In M. Nivat, C. Rattray, T. Rus, and G. Scollo, editors,

Third Int. Conf. on Algebraic Methodology and Software Technology, AMAST’93,

Twente, June 1993. Workshops in Computing, Springer Verlag.

9. N. Halbwachs and P. Raymond. Validation of synchronous reactive systems: from

formal veriﬁcation to automatic testing. In ASIAN’99, Asian Computing Science

Conference, Phuket (Thailand), December 1999. LNCS 1742, Springer Verlag.

10. Valerie Issarny, Mauro Caporuscio, and Nikolaos Georgantas. A perspective on

the future of middleware-based software engineering. In 2007 Future of Software

Engineering, FOSE ’07, pages 244–258, Washington, DC, USA, 2007. IEEE Com-

puter Society. acmid = 1254722. Available from: http://dx.doi.org/10.1109/

FOSE.2007.2,doi:http://dx.doi.org/10.1109/FOSE.2007.2.

11. J.Hugues, L.Pautet, and F.Kordon. Reﬁning middleware functions for veriﬁcation

purpose. In Proceedings of the Monterey Workshop 2003 (MONTEREY’03), pages

79–87, Chicago, IL, USA, September 2003.

12. E. M. Clarke Jr., O. Grumberg, and D.E. Long. Model checking and abstraction.

ACM Transactions om Programming Languages and Systems, 16(5):1512–1542,

1994.

13. E. M. Clarke Jr., O. Grumberg, and D. Peled. Model Checking. MIT Press, 2000.

14. Philip K. McKinley, Seyed Masoud Sadjadi, Eric P. Kasten, and Betty H.C.

Cheng. Composing adaptive software. IEEE Computer, 37(7):56–64, 2004. Avail-

able from: http://portal.acm.org/citation.cfm?id=1008751.1008762,doi:10.

1109/MC.2004.48.

15. G. Mealy. A method to synthesizing sequential circuits. Bell Systems Technical

Journal, pages 1045–1079, 1955.

16. F. Lagnier N. Halbwachs and C. Ratel. Programming and verifying critical systems

by means of the synchronous data-ﬂow programming language lustre. Special Issue

on the Speciﬁcation and Analysis of Real-Time Systems. IEEE Transactions on

Software Engineering, 1992.

17. Annie Ressouche, Jean-Yves Tigli, and Carillo Oscar. Composition and Formal

Validation in Reactive Adaptive Middleware. Research report, PULSAR - IN-

RIA Sophia Antipolis - INRIA - Laboratoire d’Informatique, Signaux, et Syst`emes

de Sophia-Antipolis (I3S) / Equipe RAINBOW - Universit´e de Nice Sophia-

Antipolis - CNRS : UMR6070, 02 2011. Available from: http://hal.inria.fr/

inria-00565860/en/.

18. M. Satyanarayanan. Fundamental challenges in mobile computing. In Proceedings

of the ﬁfteenth annual ACM symposium on Principles of distributed computing,

PODC ’96, pages 1–7, New York, NY, USA, 1996. ACM. acmid = 248053. Available

from: http://doi.acm.org/10.1145/248052.248053,doi:http://doi.acm.org/

10.1145/248052.248053.

19. J.-Y. Tigli, S. Lavirotte, G. Rey, V. Hourdin, D. Cheung, E. Callegari, and

M. Riveill. Wcomp middleware for ubiquitous computing: Aspects and composite

event-based web services. In Spriner Verlag Paris, editor, Annals of Telecommuni-

cation, volume 6. March-April 2009. ISSN 0003-4347 (Print) 1958-9395 (Online).

20. Nalini Venkatasubramanian, Carolyn Talcott, and Gul A. Agha. A formal

model for reasoning about adaptive qos-enabled middleware. ACM Trans. Softw.

Eng. Methodol., 13(1):86–147, 2004. doi:http://doi.acm.org/10.1145/1005561.

1005564.

21. M. Weiser. The computer for the twenty-ﬁrst century. Scientiﬁc American Ubicomp

Paper, 265:94–104, September 1991.