Databases Reference
In-Depth Information
To summarize, we have now shown
(a) how to mine function models from function source code;
(b) how to turn these into sequential constraints;
(c) how to generalize instances of these constraints into patterns; and
(d) how to discover violations of these patterns.
In the remainder of this chapter, we will detail these steps.
12.3 Creating Function Models
In the first step, each function is transformed into a function model. Why is
this step useful and why are sequential constraints not created directly? Let us
assume we want to abstract a function f() into a set of sequential constraints
that represents it. To keep things more concrete, let us consider the function
shown in Figure 12.2. Some sequential constraints that can be extracted from
this function are \target of
push()
target of
push()
," \retval (return value)
of
Random()
target of
nextInt()
" (representing the fact that creating a
Random
object precedes calling
nextInt()
on it) and \retval of
nextInt()
1st arg(ument) of
push()
." It can easily be seen that source code is not
a representation that is well suited for the purpose of obtaining sequential
constraints.
Let us now take a look at the representation shown in Figure 12.3. We can
easily obtain sequential constraints based on this representation because it
abstracts away a lot of details and contains only the information that is really
needed. Additionally, some information that is implicit in the source code is
explicit here. Consider for example the line
stack.push(random.nextInt
())
. There is an object here that is the return value of a call to
nextInt()
and is passed to
push()
as the first argument. This piece of information is ex-
plicit in the representation shown in Figure 12.2: There is a synthetic variable
(
<temp1>
) introduced in order to achieve this.
How then can we transform a function into a function model We have
indicated already in the overview all steps tn which function models are
programming-language-independent. If we want to be able to apply the whole
approach to an arbitrary programming language, we can in principle create a
different analyzer for it and have it create function models out of functions.
All the remaining steps build on function models and are not dependent on
any specific programming language. However, we can do better.
It turns out that many programming languages share similar syntax. Con-
sider C and Java. Both end statements with semicolons and use curly braces
to mark the beginning and end of a code block. Both use the same types of
loops with the same syntax: for-, while-, do-loops. Both use parentheses to in-
dicate function calls. The list goes on and on. There are differences, of course,
Search WWH ::
Custom Search