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

1
Context-aware Feature-Oriented Modeling with an
Aspect Extension of VDM
SAC2007 (PSC Track)

• 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
Control Software
Air Pressure
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
Step 1 model system specifications
Electronic Pot_0
types Tem ltZerogt ltRoomgt ltHotgt ltMaxgt
Level ltBelowgt ltAbovegt Switch ltOngt
ltOffgt state Pot of temp Tem liquid
Level heat Switch inv pot (pot.liquid
ltBelowgt) gt (pot.heat ltOffgt) init pot pot
mk_Pot(ltRoomgt,ltBelowgt,ltOffgt) end
State Definitions
Invariants
PourIn
SwitchOn
Boil T lt Max
ltT, Below, Offgt
ltT, Above, Offgt
ltT, Above, Ongt
PourOut
SwitchOff
Boil T Max
8
References to State Variables
Operations
operations PourIn() ext wr liquid Level
rd heat Switch pre (liquid
ltBelowgt) and (heat ltOffgt) post (liquid
ltAbovegt) PourOut() ext wr liquid
Level rd heat Switch pre (liquid
ltAbovegt) and (heat ltOffgt) post (liquid
ltBelowgt) Boil() ext wr temp Tem
rd liquid Level wr heat Switch
pre (liquid ltAbovegt) and (heat ltOngt)
post ( (temp ltMaxgt) gt (heat ltOffgt))
and (not(temp ltMaxgt) gt (temp
incTem(temp)))
SwitchOn() ext wr heat Switch
rd liquid Level pre (liquid ltAbovegt) and
(heat ltOffgt) post (heat ltOngt)
SwitchOff() ext wr heat Switch rd
liquid Level pre (liquid ltAbovegt) and
(heat ltOngt) post (heat ltOffgt)
Pre- and Post-Conditions
9
Step 2 model context specifications
Model Water
types Vol ltEmptygt ltLittlegt ltLargegt
ltFullgt Tem ltZerogt ltRoomgt ltHotgt ltMaxgt
Water t Tem v Vol
p real inv mk_Water(x,y,z) (x in
set ltZerogt, ltRoomgt, ltHotgt, ltMaxgt )
and (y in set ltEmptygt, ltLittlegt,
ltLargegt, ltFullgt ) and (z in
set 1.0, 0.53 ) functions heatUp (w
Water) r Water pre w.v ltgt ltEmptygt post
(ltTem(w.t, critical(w.p)) gt (r
mk_Water(incTem(w.t), w.v, w.p))) and ((w.t
critical(w.p)) gt (r mk_Water(w.t,
decVol(w.v), w.p))) critical(p real) r
Tem post ((p 1.0) gt (r ltMaxgt)) and ((p
0.53) gt (r ltHotgt))
Critical Temperature to Boil Depends on
Air-Pressure
10
Step 3 composethe system and context
specifications
Electronic Pot_0
Model Water
Electronic Pot_1

A New Reference to Context Variable
state Pot of temp Tem liquid
Level heat Switch water Water
inv pot (pot.liquid ltBelowgt) gt (pot.heat
ltOffgt) and (pot.temp pot.water.t)
and ((pot.liquid ltBelowgt) ltgt
(ltVol(pot.water.v, ltLittlegt))) init pot
pot mk_Pot(ltRoomgt,ltBelowgt,ltOffgt,mk_Water(lt
Roomgt,ltLittlegt,1.0)) or pot
mk_Pot(ltRoomgt,ltBelowgt,ltOffgt,mk_Water(ltRoomgt,ltLittl
egt,0.53)) end
Further Invariants are Added
11
operations PourIn() ext wr liquid
Level rd heat Switch wr
water Water pre (liquid ltBelowgt) and
(heat ltOffgt) post (liquid ltAbovegt) and
(water.v ltLargegt) PourOut() ext wr
liquid Level rd heat Switch
wr water Water pre (liquid ltAbovegt)
and (heat ltOffgt) post (liquid ltBelowgt)
and (water.v ltLittlegt) Boil() ext wr
temp Tem rd liquid Level
wr heat Switch wr water Water
pre (liquid ltAbovegt) and (heat ltOngt)
post ( (temp ltMaxgt) gt (heat ltOffgt))
and (not(temp ltMaxgt) gt ((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 lt- 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 deno
ted 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 ltBelowgt)
ltgt(ltVol(pot.water.v, ltLittlegt))) replace()
potinit() pot mk_Pot(ltRoomgt,ltBelowgt,lt
Offgt,mk_Water(ltRoomgt,ltLittlegt,1.0)) or pot
mk_Pot(ltRoomgt,ltBelowgt,ltOffgt,mk_Water(ltRoomgt,ltLittl
egt,0.53)) assert() pourinpost() (water.v
ltLargegt) assert() pouroutpost() (water.v
ltLittlegt) 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 SdS

• For init, the initialization pattern may be
  completely changed K(S) changes to L(SdS)
• For inv, the invariant may be added I(V)
  changes to I(V)?J(VdV)

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(VdV)
• The modification to pre is valid ?S' P'
• The modification to post is valid ?S' Q'

note S' refers to SdS
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) n ext(Op)
F 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