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

1. SAC2007 (PSC Track) 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

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. context feature modules embedded system

3. Example: an electric pot pot thermistor liquid water level sensor context heater system liquid - water or milk? - water level - temperature - air pressure … PourIn PourOut Boil 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 Cross-cutting feature composition System features (VDM) Context features (VDM)

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

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

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

8. References to State Variables Operations 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

9. Model Water 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>)) ; Critical Temperature to Boil Depends on Air-Pressure

10. Electronic Pot_0 Model Water Electronic Pot_1 + Step 3: composethe system and context specifications A New Reference to Context Variable 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 Further Invariants are Added

11. 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 concernsrequires 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 Aspect Module Base Design in VDM pointcut PCD(): precondition(OP1) || precondition(OP2) assert() : PCD() == P3 OP1 pre P1 post Q1 OP2 pre P2 post Q2 pointcut join point advice weaving OP1 pre P1 and P3 post Q1 OP2 pre P2 and P3 post Q2 woven VDM

15. Pointcut & Advice Pointcut precondition select a set of pre-conditions denoted by pre postcondition select a set of post-conditions denoted by post invariant select a set of invariants denoted by inv init select a set of initialization denoted by init Advice assert append logical expressions (connected by and operator) retract retract logical expressions replace replace initializations

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 State 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) [note: V represents a set of component names defined in S] Operation The pre- and post-conditions may be modified : • For pre, P changes to P' • For post, Q changes to Q'

19. Consistency is Required Aspect • 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' [note: S' refers to S+δS] Operation • 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'

20. Not All are Re-Generated Policy for Preservation • 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 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] Description only (no Proof Obligation studied) Description only (no Proof Obligation studied) Strongly-typed programming language  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