CS 520. Theory and Prac2ce of So4ware Engineering Fall November 16, Model inference of processes

Transcription

1 CS 520 Theory and Prac2ce of So4ware Engineering Fall 2021 Model inference of processes November 16, 2021

2 Thursday (November 18) Fourth (and last) in-class exercise On model inference of processes (today is a prelude with useful info) Form 3-, 4-, or 5- person teams Use Moodle to self-select a team; open from today un2l Thursday at 11:59 PM (almost midnight) In-class exercise 4: Group selec2on

3 Problem Missing or inaccurate system documenta2on makes it challenging to understand the intended system behaviors Complex logs of unintended system behaviors makes it difficult to debug them

4 Goal Take as input a set of observed traces (usually represented as sequences of events) of a given system Automa2cally produce an inferred model (o4en represented as an FSA) that must accept all of the observed traces May also accept some unobserved traces

5 Model inference tool: Architecture [Synop2c] Sequences of events (o4en method calls) [Log + Regular expressions] Model inference algorithm [Bisim algorithm] Inferred model [Conceptually an FSA] h[ps://people.cs.umass.edu/~brun/pubs/pubs/beschastnikh11fse.pdf

6 Shopping cart: API (wri[en in PHP) invalid-coupon valid-coupon reduce-price check-out get-credit-card

7 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from that trace graph 3. Create ini<al inferred model by par22oning the trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model

8 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from the trace graph 3. Create ini<al inferred model by par22oning trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model

9 1. Extract: Log and regular expressions Log, e.g., Line: [06/Jan/2011:07:24:13] GET HTTP/1.1/checkout.php Regular expression(s), e.g., Line parsing: (?<ip>).+/(?<type>.+).php Special events for INITIAL and TERMINAL. Each event specified as a triple <trace ID, 2mestamp, event type>, e.g., < , 06/Jan/2011:07:24:13, check-out>

10 1. Extract: Trace graph Each event specified as a triple <trace ID, 2mestamp, event type> Also special events for INITIAL and TERMINAL Each trace is a linear graph where: Each event corresponds to a vertex The total ordering among the events (specified by their 2mestamps) corresponds to the edges among the nodes A trace graph is the union of the set of traces

11 Shopping cart: Inputs Regular Expressions: Line parsing: (?<ip>).+/(?<type>.+).php Trace mapping: \k<ip>

12 Shopping cart: Trace graph

13 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from the trace graph 3. Create ini<al inferred model by par22oning trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model

14 2. Mine invariants Capture temporal rela2onships between event types in a given trace graph a Always Followed by b (a b) e.g., INITIAL check-out a Never Followed by b (a b) e.g., valid-coupon invalid-coupon a Always Precedes b (a b) e.g., check-out get-credit-card Must be sa2sfied by all of the poten2al traces through that graph

15 2. Mine invariants Capture temporal rela2onships between event types in a given trace graph a Always Followed by b (a b) e.g., INITIAL check-out a Never Followed by b (a b) e.g., valid-coupon invalid-coupon a Always Precedes b (a b) e.g., check-out get-credit-card Use the Dwyer et al. property pa[erns Must be sa2sfied by all of the poten2al traces through that graph

16 Shopping cart: Invariants

17 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from the trace graph 3. Create ini<al inferred model by par22oning trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model

18 Shopping cart: Trace graph

19 Shopping cart: Ini2al model

20 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from the trace graph 3. Create ini<al inferred model by par22oning trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model

21 BisimH algorithm 1. Extract a trace graph from a given log using the regular expressions 2. Mine invariants from the trace graph 3. Create ini<al inferred model by par22oning trace graph 4. While (current inferred model violates invariants) 1. Generate counterexample path through the current inferred model illustra2ng a viola2on of a given invariant 2. Refine current inferred model based on that counterexample path to produce next inferred model sa2sfying that invariant 5. Coarsen current inferred model to produce final inferred model Use counterexample guided abstrac2on refinement (CEGAR)

22 4. CEGAR: Generate counterexample path Employ a model checker to determine if all poten2al paths through the current inferred model sa2sfy the invariants If so, report sa2sfied If not, report violated and a counterexample path illustra2ng a viola2on of one of the invariants

23 Shopping cart: Counterexample path Violates invariant: valid-coupon invalid-coupon

24 4. CEGAR: Refine 1. Refine the current inferred model based on the violated invariant Heuris2cally select a vertex relevant to that invariant 2. Create the refined inferred model that sa2sfies that invariant Split the selected vertex into mul2ple ver2ces

25 Shopping cart: Refined model

26 5. Coarsen Coarsen the refined inferred model Search for ver2ces that didn t need to be split by the refine heuris2c and merge them The coarsened inferred model sa2sfies all of the invariants. (It is the final inferred model.)

27 Shopping cart: Coarsened model

28 Shopping cart: Final model

29 Shopping cart: Final model Does the inferred model illustrate any unintended behavior (i.e. a bug)?

30 Shopping cart: Final model Does the inferred model illustrate any unintended behavior (i.e. a bug)? YES

31 Challenges for model inference How does the selec2on of the event sequence set affect the final model? affect performance? How does the parameteriza2on of the model inference algorithm affect the final model? How do you compare/contrast (or diff) two inferred models? How to support other high-level language features such as concurrency, real-2me constraints,?

32 Learning from system traces Logs, e.g., Synop2c, InvariMint h[ps:// Counterexample paths, e.g., libalf: Automata learning framework h[p://libalf.informa2k.rwth-aachen.de Usage scenarios, e.g., h[ps://dl.acm.org/doi/pdf /

33 Homework 3: Overview Due: Tuesday November 30, 11:59 PM (a li[le before midnight) New branch v2.0.0: The RowGameModel class has encapsulated the player and movesle4 fields. That class also is using the Player enum type for type safety of the player field. The RowGameGUI class is applying the Composite design pa[ern. The test suite updated the exis2ng testnewgame test case and added new test cases for testlegalmove and testillegalmove.

34 Homework 3: What to do 1. The RowGameModel class should apply the Observer design pa[ern. 2. The RowGameController class should apply either the Strategy or Template Method design pa[ern. 3. In a Java IDE, your project should build, run, and be debugged. NOTE) There should be git commit messages about the above.

35 Architecture padern: MVC (Model View Controller) sees Client uses View Controller updates Model manipulates Separates data representa2on (Model), visualiza2on (View), and client interac2on (Controller)

36 Architecture padern: PAC (Presenta2on Abstrac2on Control) sees Client uses sets Presenta2on updates Control gets Abstrac2on Separates data representa2on (Abstrac2on), visualiza2on (Presenta2on), and client interac2on (Control) h[ps://en.wikipedia.org/wiki/presenta2on%e2%80%93abstrac2on%e2%80%93control

37 Architecture padern: PAC (Presenta2on Abstrac2on Control) sees Client uses sets Presenta2on updates Control Applies the Mediator design padern gets Abstrac2on Separates data representa2on (Abstrac2on), visualiza2on (Presenta2on), and client interac2on (Control) h[ps://en.wikipedia.org/wiki/presenta2on%e2%80%93abstrac2on%e2%80%93control

38 Which architecture? sees Client uses View Controller MVC: updates Model manipulates PAC: Presenta2on sees updates Client uses Control sets gets Abstrac2on

39 Design paderns: Observer and Strategy sees View Client Swing applies the Observer padern uses Controller You ll apply the Strategy padern You ll apply the updates Observer padern Model manipulates Separates data representa2on (Model), visualiza2on (View), and client interac2on (Controller)

40 RowGameController: Suppor2ng different row game rules Different row game rules: Three in a row Tic tac toe Two possible solu2ons: Strategy design pa[ern Template method design pa[ern

41 Strategy design pa[ern: RowGameController <<interface>> Median +median(a:double[]):double 1 <<interface>> Sorter +sort(array:double[]) StrategyMedian -sortstrategy:sorter +median(a:double[]):double +setsorter(s:sorter) HeapSort +sort(...)... QuickSort +sort(...) median delegates the sor2ng of the array to a sortstrategy

42 Template method design pa[ern: RowGameController AbstractMedian {abstract} + median(a:double[]):double # sort(a:double[]) Should the median method be final? The template method (median) implements the algorithm but leaves the sor<ng of the array undefined. SimpleMedian # sort(a:double[]) The concrete subclass only needs to implement the actual sor<ng.

43 Design paderns: Observer and Strategy sees View Client Swing applies the Observer padern uses Controller You ll apply the Strategy padern You ll apply the updates Observer padern Model manipulates Separates data representa2on (Model), visualiza2on (View), and client interac2on (Controller)

44 Observer pa[ern Observable {abstract} # observers:set<observer> + register(o:observer) + unregister(o:observer) + statechanged() <<interface>> Observer + update() public void statechanged() { for (Observer o : observers) { o.update(); } } MyObservable MyObserver - state:state + getstate():state + setstate(state:state) + update() // For the setstate method, use the statechanged method

45 Observer padern: Reset JBu[on and RowGameController Observable {abstract} # observers:set<observer> + register(o:observer) + unregister(o:observer) + statechanged() reset JBuDon MyObservable - state:state public void statechanged() { for (Observer o : observers) { o.update(); } } <<interface>> Observer + update() RowGameController MyObserver + getstate():state + setstate(state:state) + update() // For the setstate method, use the statechanged method

46 Learn by example h[ps://docs.oracle.com/en/java/javase/14/ docs/api/java.desktop/javax/swing/jbu[on.html h[ps://docs.oracle.com/en/java/javase/14/ docs/api/java.desktop/javax/swing/ AbstractBu[on.html h[ps://docs.oracle.com/en/java/javase/14/ docs/api/java.desktop/java/awt/event/ Ac2onListener.html

47 Observer pa[ern Observable {abstract} # observers:set<observer> + register(o:observer) + unregister(o:observer) + statechanged() <<interface>> Observer + update() public void statechanged() { for (Observer o : observers) { o.update(); } } MyObservable MyObserver - state:state + getstate():state + setstate(state:state) + update() // For the setstate method, use the statechanged method

48 Observer padern: Model and its View(s) Observable {abstract} # observers:set<observer> + register(o:observer) + unregister(o:observer) + statechanged() Model MyObservable - state:state public void statechanged() { for (Observer o : observers) { o.update(); } } <<interface>> Observer + update() View(s) MyObserver + getstate():state + setstate(state:state) + update() // For the setstate method, use the statechanged method

49 Learn from user documenta<on h[ps://docs.oracle.com/en/java/javase/14/docs/api/ java.desktop/java/beans/ PropertyChangeSupport.html (In our case, we ll be using another design pa[ern called Adapter.) h[ps://docs.oracle.com/en/java/javase/14/docs/api/ java.desktop/java/beans/ PropertyChangeListener.html