Inferring Extended Finite State Machine models from software executions

Abstract

The ability to reverse-engineer models of software behaviour is valuable for a wide range of software maintenance, validation and verification tasks. Current reverse-engineering techniques focus either on control-specific behaviour (e.g., in the form of Finite State Machines), or data-specific behaviour (e.g., as pre / post-conditions or invariants). However, typical software behaviour is usually a product of the two; models must combine both aspects to fully represent the software's operation. Extended Finite State Machines (EFSMs) provide such a model. Although attempts have been made to infer EFSMs, these have been problematic. The models inferred by these techniques can be non-deterministic, the inference algorithms can be inflexible, and only applicable to traces with specific characteristics. This paper presentsWe thank Ivo Krka at the University of Southern California for providing us with some of the traces for the evaluation. Ramsay Taylor and John Derrick are supported by the EU FP7 PROWESS projects. Neil Walkinshaw is grateful for the support provided by the UK Ministry of Defence (MOD) through the BATS and HASTE projects. Information contained in this document should not be interpreted as representing the views of the MOD, nor should it be assumed that it reflects any current or future MOD policy. The information cannot supersede any statutory or contractual requirements or liabilities and is offered without prejudice or commitment.

Inferring extended finite state machine models from software executions

“…Whereas this is reasonably straightforward for Java systems and the Erlang systems used in our case studies, there are classes of system for which obtaining such a trace can be difficult. As an example, for the PoolBoy system used in our initial evaluation [51], the variables are recorded as Strings, but actually correspond to nested lists or fixed tuples of process identifiers. To enable the inference of models from such systems, it is invariably necessary to re-code the traces to a more suitable abstraction (as discussed in Section 2.1.1).…”

“…One approach which we adopted in our initial experiments [51] involved introducing small code changes (mutations) to the program code to change its behaviour. The approach we have subsequently adopted for the experiments in this paper involved the provision of a manually selected set of trace mutations, and applying them to the sets of traces to yield negative traces.…”

“…We used this approach to generate negative traces for a preliminary study of our work [51], using the MAJOR mutation framework [27] for Java classes, and a custom mutation tool based on Wrangler [33] for the Erlang programs.…”

Model extraction and test generation from JUnit test suites

“…There is also been more recent work on software reverseengineering using regular inference [5] and even EFSM inference with help of machine learning [14].…”

Using contexts to extract models from code

“…This analysis guarantees that, when we merge two states, they represent the same context and, therefore, any paths from these states, however long they might be, are always valid at the defined level of abstraction. The work presented in [58] describes an iterative approach to build EFSMs from a combination of names of events (function calls or I/O events) and values of some variables. They use a data classifier technique to classify each event according to a class of values.…”