1

Context-aware Feature-Oriented Modeling with an Aspect Extension of VDM

Naoyasu Ubayashi (Kyushu Institute of Technology)Shin Nakajima (National Institute of Informatics)

March 13, 2007

SAC2007 (PSC Track)

2

Motivation

Embedded systems react to a certain change in the context.

The context results in a set of description fragments spreading over a lot of modules.

embedded system

contextfeature

modules

3

Example: an electric pot

water level sensor

heater

thermistor liquid

context

system

pot

liquid - water or milk? - water level - temperature - air pressure …

PourOut BoilPourIn

pot

4

Our approach

We propose - Context-aware FOM (feature-oriented modeling) - VDM-based design for Formal Analysis - AspectVDM (aspect-oriented VDM descriptions) and Proof obligation generation

System features(VDM) Context features

(VDM)

featurecomposition

Cross-cutting

5

Context-aware FOM

Electric Pot

System LineFeatures

Context LineFeatures

ControlSoftware

Sensor

Pressure Liquid Level Thermister

required feature

optional feature

Physical World

Air Pressure Liquid

Water Milk

Actuator

Heater LevelMeter

compose

6

Incremental Development --- Separation of context concerns

ElectricPot_0

Water

PressureElectricPot_1

ElectricPot_2

Step1:model system specifications

Step2:model context specifications

Step3:compose the systemand context specifications

Not discussed here

7

Step 1: model system specificationstypes Tem = <Zero> | <Room> | <Hot> | <Max> ; Level = <Below> | <Above> ; Switch = <On> | <Off> ;

state Pot of temp : Tem liquid : Level heat : Switchinv pot == (pot.liquid = <Below>) => (pot.heat = <Off>)init pot == pot = mk_Pot(<Room>,<Below>,<Off>)end

<T, Below, Off> <T, Above, Off>

PourIn

PourOut

<T, Above, On>

Boil [ T < Max ]

SwitchOff

SwitchOn

Boil [ T == Max ]

ElectronicPot_0

State Definitions

Invariants

8

operations PourIn() ext wr liquid : Level rd heat : Switch pre (liquid = <Below>) and (heat = <Off>) post (liquid = <Above>) ; PourOut() ext wr liquid : Level rd heat : Switch pre (liquid = <Above>) and (heat = <Off>) post (liquid = <Below>) ;

Boil() ext wr temp : Tem rd liquid : Level wr heat : Switch pre (liquid = <Above>) and (heat = <On>) post ( (temp~ = <Max>) => (heat = <Off>)) and (not(temp~ = <Max>) => (temp = incTem(temp~)))

SwitchOn() ext wr heat : Switch rd liquid : Level pre (liquid = <Above>) and (heat = <Off>) post (heat = <On>) ;

SwitchOff() ext wr heat : Switch rd liquid : Level pre (liquid = <Above>) and (heat = <On>) post (heat = <Off>) ;

Pre- and Post-Conditions

Operations References to State Variables

9

Step 2: model context specifications

types Vol = <Empty> | <Little> | <Large> | <Full> ; Tem = <Zero> | <Room> | <Hot> | <Max> ; Water :: t : Tem v : Vol p : real inv mk_Water(x,y,z) == (x in set { <Zero>, <Room>, <Hot>, <Max> }) and (y in set { <Empty>, <Little>, <Large>, <Full> }) and (z in set { 1.0, 0.53 })

functions heatUp (w : Water) r : Water pre w.v <> <Empty> post (ltTem(w.t, critical(w.p)) => (r = mk_Water(incTem(w.t), w.v, w.p))) and ((w.t = critical(w.p)) => (r = mk_Water(w.t, decVol(w.v), w.p))) ;

critical(p : real) r : Tem post ((p = 1.0) => (r = <Max>)) and ((p = 0.53) => (r = <Hot>)) ;

ModelWater

Critical Temperature to Boil Depends on Air-Pressure

10

Step 3: composethe system and context specifications

state Pot of temp : Tem liquid : Level heat : Switch water : Water inv pot == (pot.liquid = <Below>) => (pot.heat = <Off>) and (pot.temp = pot.water.t) and ((pot.liquid = <Below>) <=> (ltVol(pot.water.v, <Little>))) init pot == pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,1.0)) or pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,0.53)) end

ElectronicPot_0

ModelWater

ElectronicPot_1+

A New Reference to Context Variable

Further Invariants are Added

operations PourIn() ext wr liquid : Level rd heat : Switch wr water : Water pre (liquid = <Below>) and (heat = <Off>) post (liquid = <Above>) and (water.v = <Large>); PourOut() ext wr liquid : Level rd heat : Switch wr water : Water pre (liquid = <Above>) and (heat = <Off>) post (liquid = <Below>) and (water.v = <Little>);

Boil() ext wr temp : Tem rd liquid : Level wr heat : Switch wr water : Water pre (liquid = <Above>) and (heat = <On>) post ( (temp~ = <Max>) => (heat = <Off>)) and (not(temp~ = <Max>) => ((temp = incTem(temp~)) and (water = heatUp(water~))));

Pre- and Post-conditions (of Operations) are Changed Adequately

12

Separation of context concerns is nice, but …

Writing down VDM descriptions to follow the idea of separation of context concerns requires to edit various parts of the base description (Electric Pot_0).

The modification is scattered. The process is not systematic as well as error-prone.

Our approach is to introduce aspects in VDM-SL to propose AspectVDM.

13

Introducing Aspects into VDM-SL

Join Point Model Pointcut & Advice <- Basically Editting

Heterogeneous Aspects Dedicated Mostly to a Particular Join Point As opposed to Homogeneous Aspects such as Logging

More? Proof Obligation

Colyer, A. and Clement, A.: Large-Scale AOSD for Middleware.In Proc. AOSD2004

14

AspectVDM JPM

pointcut PCD(): precondition(OP1) || precondition(OP2)

assert() : PCD() == P3

OP1pre P1post Q1

OP2pre P2post Q2

pointcut

advicejoin point

weaving

OP1pre P1 and P3post Q1

OP2pre P2 and P3post Q2

Aspect Module Base Design in VDM

woven VDM

15

Pointcut & Advice

precondition select a set of pre-conditionsdenoted by pre

postcondition select a set of post-conditionsdenoted by post

invariant select a set of invariantsdenoted by inv

init select a set of initializationdenoted by init

assert append logical expressions(connected by and operator)

retract retract logical expressionsreplace replace initializations

Pointcut

Advice

16

Aspect for the Pot Example

aspect pot_water of

Pot.water : Water ext wr Pot.PourIn().water : Water ext wr Pot.PourOut().water : Water ext wr Pot.Boil().water : Water

pointcut potinv() : invariant(Pot.pot) pointcut potinit() : init(Pot.pot) pointcut pourinpost() : postcondition(Pot.PourIn()) pointcut pouroutpost() : postcondition(Pot.PourIn()) pointcut boilpost() : postcondition(Pot.Boil())

assert() : potinv() == (pot.temp = pot.water.t) and ((pot.liquid = <Below>) <=>(ltVol(pot.water.v, <Little>)))

replace() : potinit() == pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,1.0)) or pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,0.53))

assert() : pourinpost() == (water.v = <Large>) assert() : pouroutpost() == (water.v = <Little>) assert() : boilpost() == (water = heatUp(water~))

end

Inter-type declaration

Pointcut & Advice

17

Weaving in AspectVDM

Verification in VDM-SL is performed by Discharging Proof obligations.

Weaving in AspectVDM is not just a syntactical transformation alone.

How Proof Obligations are generated should be considered.

18

Woven Descriptions

For pre, P changes to P'For post, Q changes to Q'

Its component may be added : S changes to S+δS

For init, the initialization pattern may be completely changed : K(S) changes to L(S+δS)

For inv, the invariant may be added : I(V) changes to I(V)∧J(V+δV)

The pre- and post-conditions may be modified :

[note: V represents a set of component names defined in S]

State

Operation

21

Aspect for the pot

aspect pot_water of

Pot.water : Waterext wr Pot.PourIn().water : Waterext wr Pot.PourOut().water : Waterext wr Pot.Boil().water : Water

pointcut potinv() : invariant(Pot.pot)pointcut potinit() : init(Pot.pot)pointcut pourinpost() : postcondition(Pot.PourIn())pointcut pouroutpost() : postcondition(Pot.PourIn())pointcut boilpost() : postcondition(Pot.Boil())

assert() : potinv() == (pot.temp = pot.water.t)and ((pot.liquid = <Below>) <=>(ltVol(pot.water.v, <Little>)))

replace() : potinit() ==pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,1.0))

or pot = mk_Pot(<Room>,<Below>,<Off>,mk_Water(<Room>,<Little>,0.53))

assert() : pourinpost() == (water.v = <Large>)assert() : pouroutpost() == (water.v = <Little>)assert() : boilpost() == (water = heatUp(water~))

end

Inter-type declaration

Pointcut & Advice

19

Consistency is Required

The addition to inv is valid : I(V)∧J(V+δV)The modification to pre is valid : ∀S' | P'The modification to post is valid : ∀S' | Q'

Since an operation Op after weaving (denoted by Opw) should be valid in the context where the original base Op is valid, the formula for Opw should be satisfied.

∀S' | P ⇒ P'

[note: S' refers to S+δS]

Aspect

Operation

20

Not All are Re-Generated

All the operations being not woven are expected to be valid after the weaving.

The proof obligations before the weaving are supposed to be preserved.

An addition to invariants may invalidate

some pre- and/or post-conditions.New proof obligations should be

generated.

Policy for Preservation

Policy for re-generation

21

Re-Generation

All Operators having references to Variables in Added Invariants

v-name(J) ∩ ext(Op) = Φ

should be re-analyzed to generate proof obligations

Aspects will violates the Base Description if

∀S‘ | (P∧I)∧J and ∀S‘ | (Q∧I)∧J

are not satisfied

Added Invariant may violate either P or Q or both of such Op.

v-name(J) : variable names in Jext(Op) : variable names in ext of Op

22

Aspects in VDM

This work Implicit Style Explicit Style (execution semantics) :

Aspects would be different from Ours

Refinement has been Studied Much Refinement : into Programs Weaving : Base and Aspects are at the

same abstraction level

23

Related work

Aspect extension of Z and Object-Z [Yu, H. et al. 2005, 2006]

Aspects in JML [Yamada and Watanabe 2005]

Aspects in Caml [Masuhara et al 2005]

Strongly-typed programming language

Description only (no Proof Obligation studied)

Description only (no Proof Obligation studied)

Aspects in Explicit Style VDM

24

Conclusion

Feature-oriented Modeling Method + VDM-based Formal Design

AspectVDM for Reducing the Gap Heterogenenous Aspects Proof Obligation is Studied

Semantics have not been studied yet