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

2 Outline 1. Introduction 2. VDM-based Design for Context-aware Feature-Oriented Modeling 3. Introducing Aspect into VDM-SL 4. Weaving and Proof Obligation 5. 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. embedded system context feature modules

5 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

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 System features (VDM) Context features (VDM) feature composition crosscutting

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

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

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

10 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

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 = ) ;

12 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

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

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~)))); 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 aspect Logging { pointcut publiccall (): call (public * *(..)); before() : publiccall() {logging(); } } join point program execution points including method calls and field access points pointcut advice logging code extract a set of join points related to a specific crosscutting concern from all join points raise effects at the join points AspectJ

19 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

20 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

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 = ) (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

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

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

26 Proof Obligation --- preserved or regenerated ? 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 Preservation 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 inv pot == (pot.liquid = ) => (pot.heat = ) and (pot.temp = pot.water.t) and ((pot.liquid = ) (ltVol(pot.water.v, ))) Example – electric pot 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 = ) ; 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~)))); Regenerate PO invalidate pre/post-conditions v-name(J) ∩ ext(Op) = Φ Regenerate PO

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 level sensor heater thermistor water 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 [requirements]

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 refinement PO for weaving

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