Separation of Context Concerns --- Applying Aspect Orientation to VDM

1. Second Overture Workshop at FM'06 Separation of Context Concerns --- Applying Aspect Orientation to VDM Naoyasu Ubayashi (Kyushu Institute of Technology) Shin Nakajima (National Institute of Informatics) August 21, 2006

2. Outline • Introduction • VDM-based Design for Context-aware Feature-Oriented Modeling • Introducing Aspect into VDM-SL • Weaving and Proof Obligation • Discussion and Conclusion

3. 1. Introduction

4. Motivation • Identifying the features is not trivial. • In particular, embedded systems should 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

5. 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

6. Our approach • We propose - Context-aware FOM (feature-oriented modeling) - VDM-based design method for context-aware FOM - AspectVDM (aspect-oriented VDM descriptions) and Proof obligation policies crosscutting feature composition System features (VDM) Context features (VDM)

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

8. 2. VDM-based Design for Context-aware FOM

9. Development Scenario --- 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

10. 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 SwitchOn PourIn Boil [ T < Max ] <T, Bellow, Off> <T, Above, Off> <T, Above, On> PourOut SwitchOff Boil [ T == Max ]

11. 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>) ;

12. 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>)) ;

13. Electronic Pot_0 Model Water Electronic Pot_1 + 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 adding a reference to the context (i.e. water), and modifing the associated mk patterns

14. 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~)))); adding logical expressions that represent the properties of the context to invariants and pre/post-conditions

15. 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 (Eclectic Pot_0). • The modification is scattered. The process is not systematic as well as error-prone. • By introducing the notion of the aspect in an explicit manner, the process is expected to be systematic, and possibly automatic.

16. 3. Introducing Aspect into VDM-SL

17. What is Aspect Orientation ? • Aspect-oriented programming (AOP) can separate crosscutting concerns including logging, error handling, and transaction. • These concerns are modularized as aspects. logging

18. AO Mechanism--- JPM: Join Point Mechanism advice join point pointcut logging code program execution points including method calls and field access points extract a set of join points related to a specific crosscutting concern from all join points raise effects at the join points AspectJ aspect Logging { pointcut publiccall (): call (public * *(..)); before() : publiccall() {logging(); } }

19. 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

20. 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

21. Aspect for the pot 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

22. 4. Weaving and Proof Obligation

23. Weaving in AspectVDM • Weaving in AspectVDM is not just a syntactical transformation alone. • How proof obligation is generated should be considered.

24. Effect of weaving 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'

25. Conditions for consistency in weaving 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'

26. Proof Obligation --- preserved or regenerated ? Policy for Preservation • All the operations being not woven are expected to be valid after the weaving. • The proof obligations before the weaving should be preserved. • An addition to invariants may invalidate their pre- or post-conditions. • The new proof obligations should be regenerated. Policy for regeneration

27. Regeneration of proof obligations All Operators satisfying the formula v-name(J) ∩ ext(Op) = Φ should be re-analyzed to generate proof obligations For such an Op, if the formulas ∀S‘ | (P∧I)∧J and ∀S‘ | (Q∧I)∧J are not satisfied, then the current aspect definition is not correct in that the 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

28. Example – electric pot Regenerate PO Regenerate PO 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~)))); 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>) ; invalidate pre/post-conditions v-name(J) ∩ ext(Op) = Φ inv pot == (pot.liquid = <Below>) => (pot.heat = <Off>) and (pot.temp = pot.water.t) and ((pot.liquid = <Below>) <=> (ltVol(pot.water.v, <Little>)))

29. 5. Discussion and Conclusion

30. Refinement vs. weaving • Refinement and weaving are similar in that both concerns with the model transformations. • In the refinement, the description becomes concrete toward the programming level implementation. • In the weaving, the woven description stays at the same level as before because the base and the aspect look at the same abstraction level.

31. Related work • Aspect extension of Z and Object-Z [Yu, H. et al. 2005, 2006] • Aspect introduction into JML [Yamada and Watanabe 2005] • Integration of the aspectual notion with strongly-typed functional programming language Caml [Masuhara et al 2005]

32. Conclusion • Separation of concerns is important to reduce the complexity of software design. • This research examined a software development method starting with the feature-oriented modeling method to have VDM-based formal design. • In order to overcome the problem that a feature may be scattered over the VDM design description, the notion of the aspect was adapted to propose AspectVDM.

33. Etc

34. Example: an electric pot water thermistor water level sensor heater [requirements] • the pot changes its mode to the heat-retaining mode when the temperature becomes 100 Celsius • the pot observes the water volume from the level sensor that detects whether the liquid is below or above the specified level

35. SPL & FOM • Embedded systems such as consumer appliances have a wide variety of similar but different products. So, their development require to identify a set of commonalities and variabilities. • Feature-Oriented Modeling (FOM) has been proposed for supporting Software Product Line (SPL).

36. Proof Obligation PO for weaving PO for refinement

37. Explicit vs. Implicit • VDM-SL allows both explicit and implicit specifications, the latter of which are studied in this research. • Since explicit specification is meant to execute, the notion of the aspect would be very similar to that found in AspectJ. • Studying how the aspect in two specification styles are related is important.

38. New version of AspectVDM aspect pot_water of Pot.water : Water ext wr Pot.{PourIn(),Pot.PourOut(),Pot.Boil()}.water : Water pointcut potinv() : invariant(Pot.pot) pointcut potinit() : init(Pot.pot) pointcut liquid_above() : condition(pot.liquid = <Above>) pointcut liquid_below() : condition(pot.liquid = <Below>) 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() : liquid_above() == (water.v = <Large>) assert() : liquid_below() == (water.v = <Little>) assert() : boilpost() == (water = heatUp(water~)) end

39. Regeneration of proof obligations Let ext(Op) be the collection of variable names appeared in ext of Op and v-name(J) be the collection of variable names appeared in J, then all Op's satisfing the formula v-name(J) ∩ ext(Op) = Φ should be re-analyzed to generate proof obligations again where v-name(J) ⊆ J(V+δV) and ext(Op) ⊆ V. Further, for such an Op, if the formulas ∀S‘ | (P∧I)∧J and ∀S‘ | (Q∧I)∧J are not satisfied, then the current aspect definition is not correct in that the added invariant may violate either P or Q or both of such Op.

40. Example – electric pot (cont’d) operations 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~)))); inv pot == (pot.liquid = <Below>) => (pot.heat = <Off>) and (pot.temp = pot.water.t) and ((pot.liquid = <Below>) <=> (ltVol(pot.water.v, <Little>))) S’: temp, liquid, heat, water P: (liquid = <Above>) and (heat = <On>) Q: (temp~ = <Max>) => (heat = <Off>)) and (not(temp~ = <Max>) => ((temp = incTem(temp~)) and (water = heatUp(water~) I: (liquid = <Below>) => (heat = <Off>) J: (temp = water.t) and ((liquid = <Below>) <=> (ltVol(water.v, <Little>))) [pre_heatup water.v <> <Empty>] ∀S‘ | (P∧I)∧J  OK ∀S‘ | (Q∧I)∧J  NG! violate! (if water.p = 0.53: air pressure)