Delta-oriented Monitor Specification Eric Bodden, Kevin Falzon Ka I - PowerPoint PPT Presentation

Delta-oriented Monitor Specification Eric Bodden, Kevin Falzon Ka I Pun, Volker Stolz EC-SPRIDE, Darmstadt Universitetet i Oslo October 2012 GROUP Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Motivation ◮ What is RV? ◮ Does ABS support infrastructure for RV? (before: aspect-oriented programming) ◮ How do we define variable protocols for different products? ◮ How do we make protocols part of the spec/file? (machine readable protocols) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Runtime Verification Use protocol to describe permitted API use. Here: CoCoME. i n t e r f a c e Cashdesk { s Unit s t a r t S a l e ( ) ; Unit e n t e r I t e m ( I n t code , I n t qty ) ; startSale Unit f i n i s h S a l e ( ) ; pay b enterItem I n t pay ( I n t given ) ; } finishSale f Transition labels: method names (of a single class) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Guards and Binders ◮ Transitions of form: g & m ( x 0 , . . . , x n ) ◮ Guard g may refer to previously bound variable ◮ Variables x i bound to actual parameters during run ◮ Requires wellformedness of automaton/LTS m !mode & cardPay cashPay setExpress( bool mode ) s startSale startSale b enterItem finishSale f Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Formalization (Automaton) Θ := VAR → VAL : set of variable bindings over values. ◮ Base automaton M : � Q , Σ × − − → VAR , q 0 , θ 0 , Γ � ◮ Alphabet with a list of formal parameters ◮ Initial variable binding θ 0 ∈ VAR → VAL Transitions Γ : Q × (Σ × − VAR ) × (Θ → B ) × ((Θ × − − → − → VAL ) → Θ) × Q Single transition: e ( c 0 ,..., c n ) → M ( q ′ , θ ′ ) := ( q , e ( x 0 , . . . , x n ) , guard , binding , q ′ ) ∈ Γ ( q , θ ) − − − − − − c ) = θ ′ ∧ guard ( θ ) ∧ binding ( θ, � Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Formalization (Wellformedness) Need classical def-before-use analysis on variables. Assume vars : Γ → 2 VAR . Transition � S , a , g , b , T � is wellformed , iff vars ( g ) ⊆ defs M ( S ) where defs M ( S ) : Q → 2 VAR  dom ( θ 0 ) iff s = q 0 ;  � ( defs M ( S p ) ∪ { x 0 , . . . , x n } ) defs M ( S ) := otherwise  γ ∈ Γ γ = ( S p , e ( x 0 , . . . , x n ) , g , θ, S ) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Formalization (Wellformedness) Need classical def-before-use analysis on variables. Assume vars : Γ → 2 VAR . Transition � S , a , g , b , T � is wellformed , iff vars ( g ) ⊆ defs M ( S ) m !mode & cardPay cashPay setExpress( bool mode ) s startSale startSale b enterItem finishSale f Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

So much for RV Back to Software Engineering! Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

ABS and Deltas Our Cashdesk: simple OO. (Actually not even OO.) qty ) { Unit enterItem ( I n t code , I n t Item item = s t o r e . lookup ( code ) ; t o t a l = t o t a l + qty ∗ p r i c e ( item ) ; items = Cons ( item , items ) ; } More interesting: variability with Deltas. Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Variability Optional payment with credit card: d e l t a C r e d i t Cashdesk modi fies c l a s s adds Bool cardPay ( CCData cc ) { s t o r e . a u t h o r i z e ( cc ) ; } return adds I n t cashPay ( I n t given ) { pay ( given ) ; } return Express mode with restricted functionality: d e l t a Express ( I n t k ) modi fies c l a s s Cashdesk adds Bool mode = F a l s e ; { mode = m; } adds Unit s e t E x p r e s s ( Bool m) modi fies Unit e n t e r I t e m ( I n t code , I n t qty ) { // You are allowed to buy k items i n ExpressMode i f (mode && l e n g t h ( items ) == k ) { a s s e r t F a l s e ; } { o r i g i n a l ( code , qty ) ; } e l s e Deltas are not oblivious— Express -delta must know about items . Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Our Product Line Special case from use case: d e l t a ExpressCC modi fies c l a s s Cashdesk modi fies Bool cardPay ( CCData cc ) { a s s e r t ˜mode ; // Not allowed i n e x p r e s s mode return o r i g i n a l ( cc ) ; } p r o d u c t l i n e CoCoME Express , C r e d i t ; f e a t u r e s product C r e d i t ( C r e d i t ) ; d e l t a C r e d i t when C r e d i t ; product Ex ( Express ) ; Express (10) Express ; d e l t a when product CCEx( Express , C r e d i t ) ; d e l t a ExpressCC a f t e r C r e d i t Express && C r e d i t ; when Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Back to Protocols! Observation: Monitoring becomes a feature just like other variabilities. How to describe protocols for different products ? Alternatives: ◮ Give new protocol per product Disadvantage: presumably unwieldily large ◮ Give base protocol, attach protocol-change to delta √ Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Formalization (Delta automaton) Q ∆ , Σ ∆ × − − → � � VAR , q ∆ 0 , θ ∆ 0 , Γ ∆ + , Γ ∆ Delta automaton ∆ := with: − ◮ Q ∆ new introduced states, ◮ Σ ∆ × − − → VAR new symbols, ◮ q ∆ 0 an optional redefined start state, ◮ θ ∆ 0 new initial bindings, ◮ Γ ∆ + and Γ ∆ − transitions added/removed. Q M , Σ M , q M 0 , Γ M � � Given base automaton M = , � Q ∆ , Σ ∆ , q ∆ 0 , Γ ∆ + , Γ ∆ � delta automaton ∆ = . − Application of ∆ to M : M ′ := M ↓ ∆ Q M ∪ Q ∆ Q ′ := ′ × − − → Σ M × − VAR ∪ Σ ∆ × − − → − → Σ := VAR VAR , q ′ q M if q ∆ 0 = ⊥ , q ∆ := 0 otherwise 0 0 θ ′ θ M if θ ∆ := 0 = ⊥ , otherwise: 0 0 λ c . ( case θ ∆ 0 ( c ) = ⊥ ⇒ θ M 0 ( c ); otherwise , θ ∆ 0 ( c )) (Γ M ∪ Γ ∆ Γ ′ + ) − Γ ∆ := − (Check resulting automaton for wellformedness.) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Protocol Deltas (Credit Card Payment) finishSale s 0 cardPay [cashPay/pay] s 1 startSale ∆ CC := �∅ , no new state { cashPay , cardPay } , new alphabets ⊥ , ⊥ , no new initial state/symbols { ( f , cashPay , λ s . true , λ ( s , � c ) . s , s ) , transitions added ( f , cardPay , λ s . true , λ ( s , � c ) . s , s ) } , { ( f , pay , λ s . true , λ ( s , � c ) . s , s ) }� transition removed Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Protocol Deltas (Express Mode/Special Case) finishSale s 0 s 0 setExpress( bool mode ) !mode & cardPay s 1 startSale s 1 startSale setExpress startSale s 2 �{ m } , { setExpress } , m , �∅ , ∅ , ⊥ , λ c . ( case c = “ mode ” ⇒ true ) , ⊥ , { ( m , setExpress , λ s . true , λ ( s , x ) . ( λ y . ( case y = “ mode ” ⇒ x ; { ( f , cardPay , λ s . ( ¬ s (” mode ”)) , λ ( s , � c ) . s , m ) } , otherwise ⇒ s ( y ))) , s ) , ( m , ǫ, λ s . true , λ ( s , � c ) . s , b ) } , ∅� { ( f , cardPay , λ s . true , λ ( s , � c ) . s , m ) }� Note: “before” advice relocates initial state! Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Generating Monitor Deltas Straightforward. Base monitor: s startSale pay b enterItem finishSale f (More interesting if more than one incoming edge. . . ) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Generating Monitor Deltas Straightforward. Base monitor: data State = I n i t | Buying | F i n i s h e d ; d e l t a Monitor Cashdesk modi fies c l a s s adds State s t a t e = I n i t ; Unit s t a r t S a l e ( ) { modi fies i f ( s t a t e == I n i t ) { o r i g i n a l ( ) ; s t a t e = Buying ; } { F a l s e ; }} e l s e a s s e r t modi fies Unit e n t e r I t e m ( I n t code , I n t qty ) ( s t a t e == Buying ) { o r i g i n a l ( code , qty ) ; } i f e l s e { a s s e r t F a l s e ; }} Unit f i n i s h S a l e () modi fies { o r i g i n a l ( ) ; s t a t e = F i n i s h e d ; } i f ( s t a t e == Buying ) e l s e { a s s e r t F a l s e ; }} modi fies I n t pay ( I n t given ) I n t r e s = − 1; { r e s = o r i g i n a l ( given ) ; s t a t e = I n i t ; } i f ( s t a t e == F i n i s h e d ) e l s e { a s s e r t F a l s e ; } / ∗ e n d i f ∗ / return r e s ; } (More interesting if more than one incoming edge. . . ) Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12

Binding and Testing State Introduce state variable: d e l t a ExpressMon Cashdesk modi fies c l a s s adds Maybe < Bool > monMode = Just ( F a l s e ) ; modi fies Unit s e t E x p r e s s ( Bool m) { monMode = Just (m) ; // r e c o r d mode // Only allowed between s a l e s { } { a s s e r t } i f ( s t a t e == I n i t ) o r i g i n a l (m) ; e l s e F a l s e ; } d e l t a ExpressCCMon { Cashdesk { modi fies c l a s s modi fies Bool cardPay ( CCData cc ) { ˜ fromJust (monMode ) ; o r i g i n a l ( cc ) ; a s s e r t return } Delta-oriented Monitor Specification Bodden/Falzon/Pun/Stolz ISoLA’12