$30 off During Our Annual Pro Sale. View Details »

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

William Durand

July 22, 2014
Tweet

More Decks by William Durand

Other Decks in Research

Transcript

  1. Domain-­Driven Model
    Inference Applied To
    Web Applications
    Sébastien Salva, William Durand — July 22, 2014 / SERP'14
    0

    View Slide

  2. View Slide

  3. Context
    100+ applications running in production
    Not (fully) covered by tests
    Documentation may be outdated
    MUST be maintained!

    View Slide

  4. The only way to ensure stability while fixing a bug
    is to learn how the application behaves.

    View Slide

  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.

    View Slide

  6. Hence the need for a model inference approach.

    View Slide

  7. Model Inference

    View Slide

  8. Inference is the act or process of reaching a conclusion
    about something from known facts or evidence.

    View Slide

  9. What about doing the same, programmatically?
    A (human) domain expert can deduce the meaning of an
    application execution by reading its traces.

    View Slide

  10. An expert system is a computer system that
    emulates the decision-making ability of a human expert.

    View Slide

  11. Model Inference Framework

    View Slide

  12. Model Generator Layers

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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/", ...)

    View Slide

  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

    View Slide

  18. Example

    View Slide

  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.

    View Slide

  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

    View Slide

  21. Layer 3 -­ Example

    View Slide

  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

    View Slide

  23. Layer 4 -­ Example

    View Slide

  24. Need More?

    View Slide

  25. Conclusion

    View Slide

  26. Cons
    Writing (and maintaining) rules is harder than expected
    Preserving traces(M) = ST is not easy

    View Slide

  27. Pros
    Original approach to derive IOSTS models
    It Works™

    View Slide

  28. Future Work
    Applying such a framework on industrial systems (WIP)
    Generating test cases for regression testing
    Finding a better way to write rules

    View Slide

  29. Thank You.
    Questions?

    View Slide