![](bg3.png)
This algorithm has the pre-condition n > 0 in step 1,
as n is natural by definition. Looking at the loop in
step 2, we can tell that the loop invariant r =
∑
i−1
j=0
j
holds before every iteration. Since in step 3 we have
exited the loop, we will have i = n + 1, which we can
substitute in the previous loop invariant to formulate
the post-condition for step 3 and the whole algorithm,
r =
∑
n
j=0
j. From this post-condition we can tell that
the algorithm really does what it is intended to do.
Manually generated invariants have been success-
fully used as above to prove the correctness of many
popular algorithms to this day. Nonetheless, their
generation can be automated. Automatic invari-
ant generation has proved to be a successful tech-
nique to test and improve programs written in tra-
ditional structured and object-oriented programming
languages (Ernst et al., 2001).
Invariants generated from a program have many
applications:
Debugging. An unexpected invariant can highlight a
bug in the code which otherwise might have been
missed altogether. This includes, for instance,
function calls with invalid or unexpected param-
eter values.
Program Upgrade Support. Invariants can help de-
velopers while upgrading a program. After check-
ing which invariants should hold in the next ver-
sion of the program and which should not, they
could compare the invariants of the new version
with those of the original one. Any unexpected
difference would indicate that a new bug had been
introduced.
Documentation. Important invariants can be added
to the documentation of the program, so develop-
ers will be able to read them while working on it.
Verification. We can compare the specification of the
program with the actual invariants obtained to see
if they satisfy.
Test Suite Improvement. A wrong likely invariant
dynamically generated, as we’ll see in next sec-
tion, can demonstrate a deficiency in the test suite
used to infer it.
3.2 Automatic Invariant Generation
Basically, we there are two approaches when generat-
ing invariants automatically: static and dynamic.
Static invariant generators (Bjørner et al., 1997)
are most common: invariants are deduced statically,
that is, without running the program. To deduce in-
variants, its source code is analyzed (specially data
and control flows). On one hand, invariants generated
this way are always correct. But, on the other hand,
its number and quality is limited due to the inner lim-
itations of the formal machinery which analyzes the
code, specially in unusual languages like WS-BPEL.
Conversely, a dynamic invariant generator (Ernst
et al., 2001) is a system that reports likely program
invariants observed on a set of execution log files. It
includes formal machinery to analyze the information
in the logs about the values held by variables at differ-
ent program points, such as the entry and exit points
for functions or loops.
The process to generate dynamic invariants is di-
vided into three main steps:
1. An instrumentation step where the original pro-
gram is set up so that, during the later execution
step, it generates the execution log files. This step
is called instrumentation step because the usual
way to do it is by adding, at the desired program
points, logging instructions. These instructions
write to a file the name and value of the variables
that we want to observe at those points and other-
wise have no effect on the control and data flow
of the process. Sometimes it is also necessary to
modify the environment where the program is go-
ing to be executed.
2. An execution step in which the instrumented pro-
gram will be executed under a test suite. During
each test case an execution log is generated with
all the necessary data and program flow informa-
tion for later processing.
3. An analysis step where formal methods tech-
niques are applied to obtain invariants of the vari-
ables logged at the different program points.
Thus, the dynamic generation of invariants does not
analyze the code, but a set of samples of the values
held by variables in certain points of the program.
Wrong invariants do not necessarily mean bugs in the
tested program, but rather they might come from an
incomplete test suite. If the input x is a signed integer
and we only used positive values as test inputs, we
will probably obtain the invariant x > 0 at some pro-
gram point. Upon inspection, we would notice that
invariant and improve our test suite to including cases
with x < 0.
3.3 Dynamic Invariant Generation in
WS-BPEL Compositions
We consider the dynamic generation of invariants to
be a suitable technique to support WS-BPEL compo-
sition white-box testing. If we use a good test suite,
all of the complex internal logic of our BPEL compo-
sition (compensation, dynamic discovery of services,
etc.) will be reflected in the log files of the different
AN ARCHITECTURE FOR DYNAMIC INVARIANT GENERATION IN WS-BPEL WEB SERVICE COMPOSITIONS
39