Inferring Models With Rule-Based Expert Systems (SoICT'14)

Many works related to software engineering rely upon formal models, e.g., to perform model-checking or automatic test case generation. Nonetheless, producing such models is usually tedious and error-prone. Model inference is a research field helping in producing models by generating partial models from documentation or execution traces (observed action sequences). This paper presents a new model generation method combining model inference and expert systems. It appears that an engineer is able to recognize the functional behaviors of an application from its traces by applying deduction rules. We propose a framework, applied to Web applications, simulating this reasoning mechanism, with inference rules organized into layers. Each yields partial IOSTSs (Input Output Symbolic Transition Systems), which become more and more abstract and understandable.

Online slides: http://slides.williamdurand.fr/soict14/
Sources: https://github.com/willdurand-slides/soict14

Transcript

1. Inferring Models With Rule-Based Expert Systems William Durand, Sébastien Salva — December 5, 2014 / SoICT'14
3. Background @ Michelin
4. 100+ applications running in production Not (fully) covered by tests Documentation most likely outdated MUST be maintained for ~20 years!
5. The only way to ensure stability while fixing a bug is to learn how the application behaves.
6. A first classic solution to express these behaviours is to model them, e.g. with I nput O utput S ymbolic T ransition S ystems. But writing such models is an heavy task and error prone . vNot suitable for Michelin applications.
7. Hence the need for a model inference approach . v If models don't exist (or are too complicated to write), let's build them!
8. Model Inference
9. Inference is the act or process of reaching a conclusion about something from known facts or evidence.
10. A (human) domain expert can deduce the meaning of an application execution by reading its traces. ì What about doing the same, programmatically?
11. An expert system is a computer system that emulates the decision-making ability of a human expert.
12. Model Inference Framework
13. Model Generator Layers
14. Hypotheses On The Rules A rule can only be applied a limited number of times on the same knowledge base The inference rules are Modus Ponens (soundness) Facts are Horn clauses Modus Ponens + Horn clauses Ű completeness
15. Proof Of Concept Working with Web Applications
16. Layer 1: Trace Filtering 1. Cleaning-up the trace set given as input, removing noise 2. Transforming "raw" traces into structured traces p HTTP requests and responses related to assets (CSS files, JavaScript files, images) are meaningless.
17. Structured HTTP Traces Let t = req1, resp1, ..., reqn, respn be a raw HTTP trace composed of an alternate sequence of HTTP request reqi and HTTP response respi. The structured HTTP trace σ of t is the sequence (a1(p), θ1)...(an(p), θn) where: ai is the HTTP verb used to perform the request in reqi, p is the parameter set {URI, request, response}, θi is a valuation p → Dp which assigns a value to each variables of p. θ is deduced from the values extracted from reqi and respi. The resulting trace set derived from raw traces is denoted ST.
18. Example GET("https://github.com/", req0, resp0) GET("https://github.com/login", ...) POST("https://github.com/session", ...) GET("https://github.com/", ...) GET("https://github.com/willdurand", ...) GET("https://github.com/willdurand/Geocoder", ...) POST("https://github.com/logout", ...) GET("https://github.com/", ...)
19. Layer 2: IOSTS Transformation 1. Translating a structured trace set ST into a run set SR 2. Deriving a first IOSTS tree δ1 from SR … The model is not extrapolated: traces(δ1) = ST
20. Example
21. Layers 3-N: IOSTS Abstraction Composed of rules that emulate the ability of a human expert to simplify transitions , to analyze transition syntax in order to deduce more meaningful information related to the targeted application, and to construct more abstract models . Each layer takes an IOSTS given by the direct lower one . It represents the current base of facts .
22. Layer 3 Layer 3 contains low level, generic rules that can be reused against different applications. rule "Identify Login Page" when $t: Transition( Action == GET, Guard.response.content contains('login-form') ) then modify ($t) { Assign.add("isLoginPage := true") } end
23. Layer 3 - Example
24. Layer 4 Layer 4 allows to infer a more abstract model composed of more expressive actions. rule "Identify Authentication" when $t1: Transition(Action == GET, Assign contains "isLoginPage:= true", $t1final := Lfinal) $t2: Transition(Action == PostRedirection, Linit == $t1lfinal, $t2linit := Linit) not Transition(Linit == $t2linit) then insert(new Transition("Authentication", Guard($t1.Guard,$t2.Guard), Assign($t1.Assign, $t2.Assign), $t1.Linit, $t2.Lfinal )) retract($t1) retract($t2) end
25. Layer 4 - Example
26. Need More?
27. Conclusion
28. Cons Writing (and maintaining) rules is harder than expected Preserving traces(M) = ST leads to rather large models
29. Pros Original approach to derive IOSTS models It Works™
30. Current Status Working on an implementation for Michelin's industrial systems.
31. Future Work Generating test cases for regression testing.
32. Thank You. Questions?