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 context feature 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 Boil PourIn 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) feature composition Cross-cutting

5 Context-aware FOM Electric Pot System Line Features Context Line Features Control Software Sensor Pressure Liquid LevelThermister required feature optional feature Physical World Air Pressure Liquid WaterMilk Actuator Heater Level Meter compose

6 Incremental Development --- Separation of context concerns Electric Pot_0 Water Pressure Electric Pot_1 Electric Pot_2 Step1: model system specifications Step2: model context specifications Step3: compose the system and context specifications Not discussed here

7 Step 1: model system specifications types Tem = | | | ; Level = | ; Switch = | ; state Pot of temp : Tem liquid : Level heat : Switch inv pot == (pot.liquid = ) => (pot.heat = ) init pot == pot = mk_Pot(,, ) end PourIn PourOut Boil [ T < Max ] SwitchOff SwitchOn Boil [ T == Max ] Electronic Pot_0 State Definitions Invariants

8 operations PourIn() ext wr liquid : Level rd heat : Switch pre (liquid = ) and (heat = ) post (liquid = ) ; PourOut() ext wr liquid : Level rd heat : Switch pre (liquid = ) and (heat = ) post (liquid = ) ; Boil() ext wr temp : Tem rd liquid : Level wr heat : Switch pre (liquid = ) and (heat = ) post ( (temp~ = ) => (heat = )) and (not(temp~ = ) => (temp = incTem(temp~))) SwitchOn() ext wr heat : Switch rd liquid : Level pre (liquid = ) and (heat = ) post (heat = ) ; SwitchOff() ext wr heat : Switch rd liquid : Level pre (liquid = ) and (heat = ) post (heat = ) ; Pre- and Post-Conditions Operations References to State Variables

9 Step 2: model context specifications types Vol = | | | ; Tem = | | | ; Water :: t : Tem v : Vol p : real inv mk_Water(x,y,z) == (x in set {,,, }) and (y in set {,,, }) and (z in set { 1.0, 0.53 }) functions heatUp (w : Water) r : Water pre w.v <> 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 = )) and ((p = 0.53) => (r = )) ; Model Water Critical Temperature to Boil Depends on Air-Pressure

10 Step 3: compose the system and context specifications state Pot of temp : Tem liquid : Level heat : Switch water : Water inv pot == (pot.liquid = ) => (pot.heat = ) and (pot.temp = pot.water.t) and ((pot.liquid = ) (ltVol(pot.water.v, ))) init pot == pot = mk_Pot(,,,mk_Water(,,1.0)) or pot = mk_Pot(,,,mk_Water(,,0.53)) end Electronic Pot_0 Model Water Electronic Pot_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 = ) and (heat = ) post (liquid = ) and (water.v = ); PourOut() ext wr liquid : Level rd heat : Switch wr water : Water pre (liquid = ) and (heat = ) post (liquid = ) and (water.v = ); Boil() ext wr temp : Tem rd liquid : Level wr heat : Switch wr water : Water pre (liquid = ) and (heat = ) post ( (temp~ = ) => (heat = )) and (not(temp~ = ) => ((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 OP1 pre P1 post Q1 OP2 pre P2 post Q2 pointcut advice join point weaving OP1 pre P1 and P3 post Q1 OP2 pre P2 and P3 post Q2 Aspect ModuleBase Design in VDM woven VDM

15 Pointcut & Advice preconditionselect a set of pre-conditions denoted by pre postconditionselect a set of post-conditions denoted by post invariantselect a set of invariants denoted by inv initselect a set of initialization denoted by init assertappend logical expressions (connected by and operator) retractretract logical expressions replacereplace 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 = ) (ltVol(pot.water.v, ))) replace() : potinit() == pot = mk_Pot(,,,mk_Water(,,1.0)) or pot = mk_Pot(,,,mk_Water(,,0.53)) assert() : pourinpost() == (water.v = ) assert() : pouroutpost() == (water.v = ) 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

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 Op w ) should be valid in the context where the original base Op is valid, the formula for Op w 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 J ext(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)  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