parameterized regular expressions in JavaMOP CS 119 which file? - PowerPoint PPT Presentation

parameterized regular expressions in JavaMOP CS 119 “which file?”

http://fsl.cs.uiuc.edu/index.php/Monitoring-Oriented_Programming 2

What is MOP? (their own words) • Framework for reliable software development – Monitoring is basic design discipline • … rather than “add on” grafted onto existing code – Recovery allowed and encouraged – Provides to programmers and hides under the hood a large body of formal methods knowledge/techniques • Monitor synthesis algorithms – Generic for different languages and application domains 3

MOP Approach to Monitoring Keep the following distinct and generic: • specification formalisms • event definitions • validation handlers 4

MOP Monitoring Oriented Programming • Same idea as design by contract: specifications are written as comments in code. Monitors are generated from specs. • Philosophy: no silver-bullet logic for specs • MOP logic plugins (a subset): – ERE (extended regular expressions) – CFG (context free grammars) – PtLTL (Past-time LTL) and FtLTL (Future-time LTL) – JML (fragment of Java modeling language) – ATL (Allen temporal logic) – Jass (The CSP Process algebra) • Generic wrt. parameters – Provide a plugin for a propositional logic, and MOP does the rest wrt. data parameterization. – Makes designing a new logic extremely easy compared to other frameworks. 5

Instances of MOP MOP JavaMOP BusMOP HardwareMOP … logic plugins MOP … CFG ptLTL ptCaRet ERE LTL languages JavaMOP BusMOP … today 6

JavaMOP Operation under the hood AspectJ JavaMOP 7

properties of Java library APIs properties of Java library APIs R 1 : There should be no two calls to next() without a call to hasNext() in between, on the same iterator . 8

Iterator next next i) suffix suffix trace semantics ii)looking for validation 9

Property in JavaMOP Property in avaMOP PROPOSITIONAL! /*@ check trace suffix partial track all events scope = global logic to be used logic = ERE HasNext { event hasnext : end(call(* Iterator.hasNext())); events event next : begin(call(* Iterator.next())); formula : next next formula to be checked } code to be executed validation handler{ if formula becomes System.err.println("*** call hasNext() before next()"); validated } @*/ 1 0

The propositional property The propositional property does oes not not flag flag the following error he following error class class Test { public public static tatic void oid main(String[] args) { Vector<Integer> v1 = new ew Vector(); Vector<Integer> v2 = new ew Vector(); v1.add(1); v1.add(3); v2.add(5); v2.add(7); Iterator it1 = v1.iterator(); Iterator it2 = v2.iterator(); int int sum = 0; should have been: if if(it1.hasNext()) if if(it2 it2.hasNext()) sum += (Integer)it2.next(); if if(it1.hasNext()) sum += (Integer)it2.next(); ) System. out .println(”sum(v2) = " + sum); } unguarded calls: } it2 it2.next() execution emits: hasNext() next() hasNext() next() spec “next next” does not match and hence no error detected 1 1

Improved Property in Improved Property in JavaMOP avaMOP PARAMETERIZED! /*@ centralized tracking partial centralized of values. We will scope = global get to this logic = ERE parameterized with HasNext(Iterator i) iterator { event hasnext<i> : end(call(* i.hasNext())); events refer to event next<i> : begin(call(* i.next())); parameter formula : next next } validation handler{ this causes the System.err.println("*** call hasNext() before next()"); handler to be } invoked @*/ 1 2

DEMO ON SLIDES 1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

2 1

2 2

2 3

2 4

2 5

END OF DEMO ON SLIDES 2 6

data values • handling of data values efficiently in monitoring frameworks is one of the current research challenges. • different frameworks approach it differently, achieving different expressiveness and efficiency. 2 7

in this simple case: store monitor in iterator our program again class class Test { public public static tatic void oid main(String[] args) { Vector<Integer> v1 = new ew Vector(); Vector<Integer> v2 = new ew Vector(); v1.add(1); v1.add(3); v2.add(5); v2.add(7); Iterator it1 = v1.iterator(); Iterator it2 = v2.iterator(); int int sum = 0; if if(it1.hasNext()) v 1 v 2 sum += (Integer)it2.next(); if if(it1.hasNext()) it 1 it 2 sum += (Integer)it2.next(); System. out .println(”sum(v2) = " + sum); } } only objects of interest it 1 associate a monitor with each object of interest it 2 2 8

Piggy-back (transportation), something that is riding on the back of something else algorithm • assume a property only mentions one kind of object (an iterator in this case). • note, there could be many objects monitored (it 1 ,it 2 ). • one can piggy-back a monitor on each object that is monitored. • alternatively: keep a map from objects to their monitors. • when an operation of interest occurs (hasNext() or next()) that refers to an object, the monitor of that object is “executed”. If null, a monitor is first created. i 1 associate a monitor with each object of interest i 2 2 9

algorithm pseudo-code Consider a call of it.next() for example. This could lead to the following monitoring code: if (it.monitor == null) it.monitor = new Monitor(); it.monitor.next(); not to mention however, this does not work when that the java property refers to more than 1 object, library cannot be instrumented where to store the monitor? easily. 3 0

properties of Java library APIs properties of Java library APIs R 2 : An enumeration should not be propagated after the underlying vector has been changed . 3 1

R 2 : An enumeration should not be propagated after the underlying vector has been changed . create next* updatesource updatesource* next now the property must refer Piggy-back no longer works. There is not a 1-1 correspondence to more than one object: between objects and monitors a vector and an enumerator suffix validation 3 2

many vectors and enumerators v 1 v 2 Vector v1 = new ew Vector(); e 1 e 2 e 3 Vector v2 = new ew Vector(); v1.add(1); v1.add(2); v2.add(4); v2.add(5); add Enumeration e1 = v1.elements(); Enumeration e2 = v1.elements(); Enumeration e3 = v2.elements(); while(e1.hasMoreElements()) print (e1.nextElement()); while v1.add(99); while(e2.hasMoreElements()) print (e2.nextElement()); while next while(e3.hasMoreElements()) print (e3.nextElement()); while 8 (v,e) 2 { (v 1 ,e 1 ),(v 1 ,e 2 ),(v 2 ,e 3 ) } events: create(v,e) catch create(v,e) next(e) * this next(e) updatesource(v) + pattern updatesource(v) next(e) 3 3

/*@ specification partial centralized scope = global logic = ERE SafeEnum (Vector v, Enumeration+ e) { event create<e, v> : end(call(Enumeration v.elements())) with (e); event updatesource<v> : end(call(* v.add*(..))) \/ end(call(* v.clear())) \/ end(call(* v.insertElementAt(..))) && \/ end(call(* v.remove*(..))) \/ end(call(* v.retainAll(..))) \/ end(call(* v.set*(..))); event next<e> : begin(call(Object e.nextElement())); formula : create next* updatesource updatesource* next } validation handler { System.out.println("datasource changed during iteration!"); } @*/ 3 4

MOP’s distinguished feature: separate handling of values • The problem : how to monitor a universally quantified specification efficiently ! create<v,e> ( ∀ v,e ) ϕ udatesource<v> next<e> create next* updatesource+ next 3 5

two approaches to data • Eagle, PQL, PTQL, Tracematches, … : – Choose a quantified logic – Device monitor synthesizer for it: ( ∀ p ) ϕ Mon ( ∀ p ) ϕ • MOP: – only knows how to generate monitors for ϕ – The ( ∀ p ) is dealt with separately, and once-and-for-all, for all logics ( ∀ p ) ϕ p ! Mon ϕ 3 6

handling of data values • value embedding scheme : the values become part of the monitors (state machines), for example by labeling transitions. This means modifying the state machine concept. i=i 1 • value indexing scheme : Keep automata atomic and index them with data i 1 – If one object per property max: • Map objects to monitors i 2 • Or piggyback monitor on object – If more than one object per property: • Centralized index table from data to monitors • Perhaps combination of piggybacking and centralized index table 3 7

MOP’s propositional monitors one propositional monitor instance per parameter instance M ϕ <v1,e1> M ϕ <v1,e2> M ϕ <v2,e3> 3 8

MOP’s propositional monitors The problem: The problem: how can one retrieve all needed monitor M ϕ <v1,e1> instances efficiently? M ϕ <v1,e2> updatesource<v1> M ϕ <v2,e3> Naïve implementation Very inefficient 3 9