Domain-Driven Model Inference Applied To Web Applications

Domain-Driven Model Inference Applied To Web Applications

Model inference methods are attracting increased attention from industrials and researchers since they can be used to generate models for software comprehension, for test case generation, or for helping devise a complete model (or documentation). In this context, this paper presents an original inference model approach which recovers models from Web application HTTP traces. This approach combines formal model inference with domain-driven expert systems. Our framework, whose purpose is to simulate this human behaviour, is composed of inference rules, translating the domain expert knowledge, organised into layers. Each yields partial IOSTSs (Input Output Symbolic Transition System), which become more and more abstract and intelligible.

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

F59d2f1ed66b8d9c6ceebea5a748494b?s=128

William Durand

July 22, 2014
Tweet

Transcript

  1. Domain-­Driven Model Inference Applied To Web Applications Sébastien Salva, William

    Durand — July 22, 2014 / SERP'14 0
  2. None
  3. Context 100+ applications running in production Not (fully) covered by

    tests Documentation may be outdated MUST be maintained!
  4. The only way to ensure stability while fixing a bug

    is to learn how the application behaves.
  5. But writing such models is an heavy task and error

    prone. A first classic solution is to express these behaviours with formal models, e.g. Input Output Symbolic Transition Systems.
  6. Hence the need for a model inference approach.

  7. Model Inference

  8. Inference is the act or process of reaching a conclusion

    about something from known facts or evidence.
  9. What about doing the same, programmatically? A (human) domain expert

    can deduce the meaning of an application execution by reading its traces.
  10. An expert system is a computer system that emulates the

    decision-making ability of a human expert.
  11. Model Inference Framework

  12. Model Generator Layers

  13. Rules a rule can only be applied a limited number

    of times on the same knowledge base the inference rules are Modus Ponens no implicit knowledge elimination
  14. Layer 1: Trace Filtering 1. Cleaning-up the trace set given

    as input, removing noise, a.k.a. irrelevant traces 2. Transforming "raw" traces into structured traces p HTTP requests and responses related to assets (CSS files, JavaScript files, images) are meaningless.
  15. 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.
  16. 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/", ...)
  17. Layer 2: Transformation Of The Traces Into IOSTSs 1. Translating

    a structured trace set ST into a run set SR 2. Deriving a first IOSTS δ1 from SR Based on δ1, it should be possible to generate a different model M, but we must preserve the following relation: traces(M) = ST
  18. Example

  19. 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.
  20. Layer 3 Layer 3 contains low level, generic rules that

    can be reused against different applications. Example rule "Identify Login Page" when $t: Transition( Action == GET, Guard.response.content contains('login-form') ) then modify ($t) { Assign.add("isLoginPage := true") } end
  21. Layer 3 -­ Example

  22. Layer 4 Layer 4 allows to infer a more abstract

    model composed of more expressive actions. Example 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
  23. Layer 4 -­ Example

  24. Need More?

  25. Conclusion

  26. Cons Writing (and maintaining) rules is harder than expected Preserving

    traces(M) = ST is not easy
  27. Pros Original approach to derive IOSTS models It Works™

  28. Future Work Applying such a framework on industrial systems (WIP)

    Generating test cases for regression testing Finding a better way to write rules
  29. Thank You. Questions?