Semi-Automatic Fault Localization and Behavior Verification for
Physical System Simulation Models
Peter Bunus, Peter Fritzson
Department of Computer and Information Science,
Linköping University, SE-581 83, Linköping, Sweden
{petbu,petfr@ida.liu.se}
Abstract
Mathematical modeling and simulation of complex
physical systems are emerging as key technologies in
engineering. Modern approaches to physical system
simulation allow users to specify simulation models with
the help of equation-based languages. Due to the highlevel declarative abstraction of these languages program
errors are extremely hard to find. This paper presents an
algorithmic semi-automated debugging framework for
equation-based modeling languages. We show how
program slicing and dicing performed at the
intermediate code level combined with assertion
checking techniques can automate, to a large extent, the
error finding process and behavior verification for
physical system simulation models.
1. Introduction
Debugging forms a central part of modern software
engineering. This is mostly due to the fact that the
debugging phase of software development takes 60-70%
of the overall development time and debugging is
responsible for 80% of all software project overruns,
according to Parasoft 1997 [10]. Debugging methods
have evolved from manual methods such as deskchecking, dumps, and inserting print statements in the
source code to algorithmic automated methods where a
specification of the correct program behavior is
automatically checked against the program execution.
Algorithmic program debugging was first introduced by
Shapiro 1983 [12] for the Prolog language. Since then,
considerable effort has gone into the design and
implementation of automated debugging tools for various
languages and programming paradigms. However, when
accounting for source code debuggers for modeling and
simulation languages, we note that simulation
professionals have considerably fewer developments tools
at their disposal than normal software developers.
Modern approaches to modeling and simulation are
based on acausal equation-based methodologies and
object-oriented constructs that facilitate reusability of
modeling knowledge. Efficient and flexible modeling of
physical
systems is achieved by combining
implementations of library components written with the
help of declarative equation-based languages. Such
languages have been designed to allow automatic
generation of efficient simulation code from declarative
specifications.
The paper proposes an algorithmic debugging
framework for equation-based languages, based on the
Generalized Algorithmic Debugging and Testing method
(GADT) reported in Fritzson et al. 1992 [8] and
Shahmehri 1991 [11]. GADT is an efficient method for
semi-automatic bug localization for imperative
languages. The algorithmic program debugger in GADT
is invoked by the user after noticing an externally visible
symptom of a bug. The debugger executes the program,
builds a trace execution tree at the procedure level, and
then traverses the execution tree and interacts with the
user by asking questions about the expected behavior of
each analyzed procedure. During this interaction an error
is located inside a procedure if the user has detected that
the procedure behavior is different from the expected
behavior and one of the following conditions holds: the
procedure doesn’t contains any another procedure calls or
all the procedure calls from the body of procedure fulfill
the user’s expectations.
In our debugging framework we assume that the
erroneous program is a small variant of the correct
program. The bug symptom that is addressed in this
paper is the wrong valued output variable. We have
identified two types of errors that will cause output
variables to be wrong valued and make the simulation
models behave differently from the specifications:
• Bugs due to incorrect input parameter values supplied
to the physical simulation model.
• Bugs due to incorrectly specified equations.
Due to the declarative nature of the source code
language, the user does not have any information
regarding the dependencies of the variables or the data
flow in the program. We therefore see the need for a tool
that allows the programmer to quickly acquire some
knowledge about the operational behavior of the
simulation model and automatically isolate data flow
slices that contributed to the incorrectly valued output
variables.
The remainder of the paper is organized as follows. In
Section 2 we briefly describe Modelica, the target
language for our debugger implementation. Section 3
gives a detailed description of the translation process of
the declarative modeling code to imperative code. Section
4 presents the data dependency graph extracted during
the translation process. Section 5 presents our automatic
debugging algorithm based on dynamic slices and dices
of the dynamic data dependency graph. Finally, in
Section 6 we present a summary of the paper and our
conclusions.
2. A Short Introduction to Modelica
Modelica is a new language for hierarchical objectoriented physical modeling which is being developed
through an international effort (Elmqvist et al. 1999 [5],
Fritzson and Bunus 2002 [7], Fritzson 2003 [6]).
A Modelica program is built from classes like in any
other traditional object-oriented language. The main
difference compared to traditional object-oriented
languages is that instead of functions (methods)
equations are used to specify the behavior. A class
declaration contains a list of variable declarations and a
list of equations preceded by the keyword equation. We
illustrate below a class corresponding to a resistor
(Resistor) and an alternative voltage source
(VsourceAC) modeled in Modelica.
model Resistor
extends TwoPin;
parameter Real R;
equation
R*i = v;
end Resistor
model VsourceAC
extends TwoPin;
parameter Real VA = 220;
parameter Real f = 50;
protected constant Real PI = 3.14;
equation
v = VA*(sin(2*PI*f*time));
end VsourceAC
Besides the instantiation of two pin interface objects, also
called ports or connectors some extra equations are
provided that defines the behavior of the objects such as
the voltage drop along the component (v = p.v n.v) or the current inside the component (0 = p.i +
n.i; i= p.i).
Connections between objects can be established
between connectors of equivalent type. A connection
equation form such as connect(pin1,pin2) with
pin1 and pin2 of connector class Pin, connects the two
pins so that they form one node. This is equivalent to,
and is eventually expanded into two equations, namely:
pin1.v = pin2.v; pin1.i + pin2.i = 0;
Now we have all the components that are necessary to
define the following model of a simple electrical circuit
consisting of a sinusoidal voltage source and a resistor
connected together.
AC
model Circuit
Resistor R1(R=10);
VsourceAC AC;
Ground G;
equation
connect(AC.p,R1.p);
connect(R1.n,AC.n);
connect(AC.n,G.p);
end Circuit
R1
G
Figure 1. Simple electrical circuit model
Let us consider a more complicated simulation example,
given in Figure 2, with a rotating inertial mass iner
influenced by an angular acceleration given by an
acceleration component A. An electromechanical
component emf will transform the rotational mechanical
energy into electrical energy that is absorbed by a simple
electrical circuit consisting of an inductor ind and two
resistors, R1 and R2, connected in series.
model TwoPin
Pin p,n;
Real v,i;
equation
v = p.v - n.v; 0 = p.i + n.i; i = p.i;
end TwoPin;
ex
connector Pin
Real v;
flow Real i;
end Pin;
iner
R2
vsen
2
Block
part
Mechanical
part
Electrical
circuit
G
Figure 2. Simulation model corresponding to an
electromechanical device.
A plot of the input signal ex.y, the angular acceleration
of the inertial component iner.w, and the voltage
measured by the voltage sensor vsen.v, are depicted in
Figure 3.
2
The TwoPin class instantiates the class Pin twice. This
is a special kind of class called connector class. Such
connectors declare variables that are part of the
communication interface of an object. Our Pin connector
class uses two Real variables: one for the current (i) and
one for the voltage (v).
A
1
emf
a
It should be also noted that both classes are
specializations through inheritance mechanism of a
special class called TwoPin. The natural inheritance in
the Modelica language works by extending classes with
new equations and variables.
R1
ind
ex.y
vsens.v
1.5
iner.w
1
0.5
t
1
2
3
4
5
6
7
Figure 3. Plots of the simulation results of the
electromechanical circuit.
Now let us assume that a formal specification of the
behavior of this simulation model defines that the voltage
measured by the voltage sensor vsens.v always should
be less that 0.75V after 4 second of simulation time while
the angular acceleration of the inertial component
2
iner.w always should be greater than 1.5 rad/s . For our
particular example the behavior specification is given in
Figure 4.
model Electromechanical
Inertia iner; VoltageSensor vsens;
equation
if (time>4)then
vsens.v < 0.75 and iner.w > 1.5
end Electromechanical
Figure 4. Formal specification of the electromechanical device
behavior.
3. The Translation Process
In order to gain a better understanding of how an
equation-based language compiler works, it is useful to
take a look at the compilation process of the Modelica
language. The Modelica source code is first translated
into a so-called “flat model”. This phase includes type
checking, performing all object-oriented operations such
as inheritance, modifications, etc. The flat model
includes a set of equations declarations and functions,
with all object-oriented structure removed, apart from the
dot notation within the names. This process is called the
“code instantiation” of the model. Figure 6 a) shows an
example of a simple Modelica model C that extends a
model B by inheritance and instantiates a model A. After
the flattening process the model C is translated into the
“flat model” as the one shown in Figure 6 b) that contains
7 equations and 7 variables.
model A
Real s,q,u,w;
model C
parameter Real k3 = 2; parameter Real k2 =
equation
parameter Real a.k3
s + 2*k3*q = 9;
parameter Real k1 =
q - s = 1;
end A;
Real x;
Real y;
model B
Real a.s;
Real x,y;
Real a.q;
parameter Real k2=3.5; Real a.u;
equation
Real a.w;
der(y) = x - k2*y;
Real z;
end B;
equation
model C
der(y) = x-k2*y;
extends B;
a.s+2*a.k3*a.q =
A a;
a.q-a.s = 1;
Real z;
a.q-a.u = 2;
parameter Real k1=10;
z = a.s-y+a.u;
equation
x-2*y = a.w-a.u;
a.q - a.u = 2;
der(x) = k1*z;
z = a.s - y + a.u;
x-2*y = a.w-a.u;
end C;
der(x) = k1*z;
end C;
a)
b)
3.5;
= 2;
10;
9;
When converting declarative equation-based code into
imperative code, one way to achieve sequential code is to
partition the equations at the intermediate code level into
computational blocks. Using this paradigm, computations
carried by one block will often require data calculated in
a previous block. Therefore it is desirable to obtain a
lower triangular form of the permuted incidence matrix.
The lower triangular form guarantees that the equations
can be solved sequentially one at a time by a forward
substitution process. Efficient algorithms exist to
transform matrices to Block Lower Triangular form
(shortly BLT form) as is depicted in Figure 5 (by the
notation X we denote the presence of a non-zero element
in the matrix).
BLT decomposition is a two-stage algorithm. First a
row permutation of the incidence matrix, that finds a
zero-free diagonal, needs to be found (see Figure 5 b).
This problem is also known as the problem of finding the
maximum transversal. The algorithm is described in Duff
and Reid 1981 [4] and a Fortran implementation of the
algorithm can be in Duff and Reid 1981 [3].
⎡X
⎢X
⎢
⎢
⎢
⎢
⎢
⎣
X
X X⎤
X X
X X
X
X
X
X
⎥
⎥
⎥
⎥
⎥
X ⎦⎥
⎡X
⎢
⎢
⎢
⎢
⎢
⎢
⎣X
⎤
⎥
X
X
⎥
X X
⎥
X X
⎥
X
X X⎥
X
X X ⎦⎥
⎡X
⎢
⎢
⎢
⎢
⎢
⎢
⎣X
⎤
⎥
X
X
⎥
X X
⎥
X X
⎥
X
X X⎥
X
X X ⎦⎥
Figure 5. a) The structural incidence matrix. b) Permuted
incidence matrix with a zero-free diagonal. c) BLT form of the
incidence matrix.
After computing the maximum transversal, the rows and
columns of the incidence matrix are permuted again into
the BLT form. The BLT transformation algorithm is
described in Duff and Reid 1978 [2] and a Fortran
implementation can be found in Duff and Reid 1978 [1].
#include <ExternalFunctions.h>
double x,y,a_s,a_q,a_u,a_w,z;
int functionDAE_block3
(double *yd, double *yprime, …){
BLOCK B1
--yd;--yprime;--delta;
Linear System of
delta[1]=yprime[1]-y[3]+3.5*y[1];
Equations
delta[2]=y[2]-a_s+y[1]-a_u;
a.s+2*a.k3*a.q=9;
delta[3]=yprime[3]-10*y[2];
a.q-a.s = 1;
return 0;
}
int main(){
Block B2
for(double it=0;it<=1;it+=0.1){
Single equation
// Solve Linear System of Equations
a.q-a.u = 2;
double A[2][2]={{1,-1},{4,1}},B[2];
DGESV(A,B,....);
Block B3
a_q=B[0]; a_s=B[1];
DAE System
der(y) = x-k2*y
//Single assignement
z = a.s-y+a.u
a_u=a_q-2;
der(x) = k1*z
//Solve DAE
Block B4
double yd[3],yprime[3];
Single equation
DDASSL(functionDAE_block3,
yd,yprime,,...);
x-2*y = a.w-a.u;
y=yd[0]; z=yd[1]; x=yd[2];
//Single assignement
a_w=x-2*y+a_u;
c)
}
}
d)
Figure 6. The Modelica translation process: a) original source code, b) flattened source code, c) intermediate block lower triangular
form, d) imperative language source code (C code)
The BLT decomposition of the simple example from
Figure 6 a) is shown in Figure 6 c). Finally, in the last
phase, the procedural code (in our implementation C
code), is generated based on the previously computed
BLT blocks when each block is linked to a numerical
solver as is illustrated in Figure 6 d).
4. The BLT Dependency Graph
Definition 1: Let V be the set of variables which appear
in a program P and BLT the block lower triangular form
of the flattened program FP. Then for each block
Bk ∈ BLT where 1 ≤ k ≤ n (n being the number of
blocks in the BLT form) we have the following variable
sets:
• IN( Bk ) set of variables whose values are used in Bk .
• COMP( Bk ) the set of variables whose values are
computed in Bk .
• OUT( Bk ) the set of variables that are propagated to
other blocks.
From the BLT form we can derive a BLT dependency
graph (BLTDG).
a_w
x
z
y
a_s
X
X
a_u
a_q
Definition 2: A BLT dependency graph (BLTDG) of a
program P is a graph G=(N,E), whose node set N
represents the collection of equations (obtained after the
BLT decomposition) that can be solved independently.
Each node is labeled with the set of variables
COMP( Bk ) whose values are computed in that particular
node. An edge ( s, k ) ∈ E indicates the data dependence,
between node k and node s and is labeled with the set of
variables that are computed in node s and are used in
node k.
For instance, Figure 7 shows the sparsity pattern
associated to the BLT decomposition of the incidence
matrix corresponding to the flattened form of the
program from Figure 6 a).
X
X
X
⎫
⎬ B1
⎭
} B2
X
X
X
X
X
X
X
⎫
⎪
⎬ B3
⎪
⎭
X
X
X
Block B1
a.s+2*a.k3*a.q = 9;
a.q - a.s = 1;
a_q
Block B2
a.q-a.u = 2
a_u
a_s
Block B3
der(y) = x-k2*y
z = a.s-y+a.u
der(x) = k1*z
a_u
y,z,x
The block lower triangular form of the associated
incidence matrix to a system of equations captures the
notion of data dependency in equation-based language
programs. Therefore it is useful to make a classification
of the set of variables relative to a block unit according to
the following definition:
a.q-a.s = 1
a.s+2*a.k3*a.q = 9
a.q-a.u = 2
der(y) = x-k2*y
z = a.s-y+a.u
der(x) = k1*z
x-2*y = a.w-a.u
a_q
a_s
X
X
X
} B4
Figure 7. The sparsity pattern of the incidence matrix
permuted into BLT form corresponding to the example from
Figure 6 a).
In Figure 8 the derived BLTDG is depicted. As it can be
seen the BLTDG captures the data dependency of the BLT
blocks.
y,x
a_w
a_u
Block B4
x-2*y = a.w-a.u;
Figure 8. The BLTDG associated to the ex. from Figure 6 a).
5. Algorithmic Automated Debugging
Our approach to run-time automatic debugging of models
defined in equation-based languages is to search the
program execution trace for incorrectly computed
variable values. We model the execution trace of the
program as a sequence of states, where each state
represents the value of computed program’s variables
after the solution of all equation blocks at a given
simulation time t. The execution trace is decorated with
the data dependency among the equation blocks given by
the BLTDG.
At each state, the values of the most recently
computed variables are compared with the formal
specification. This is done by automatically inserting
assertions in the generated imperative code for each
variable that has a formal specification. As an example,
let us consider the formal specification of the
electromechanical circuit behavior from Figure 4. At the
imperative source code level these specifications will be
translated into two assertion statements such as:
if (time>4) assert(vsens.v < 0.75)
if (time>4) assert(iner.w > 1.5)
When one of the assert statements is violated, the state of
the program and the variable that has caused the
violation are saved and the program debugger is
automatically called.
At this stage, the task of the automatic debugger is to
find all equations whose computations have propagated
into the current incorrect value of the variable that has
caused the assertion. This can be done by computing a
program slice. The concept of program slicing for
imperative programs was first introduced by Weiser 1984
[13] and is based on the data flow through a program. In
our case the slicing can be performed on the BLTDG with
respect to a variable v and equations block B.
Moreover, in order to further reduce the slice
dimension we employ dicing techniques on the computed
BLTDG. Similar to the techniques proposed in Lyle and
Weiser 1987 [9] we first compute a slice from an
incorrectly computed variable in the BLTDG. If there
exists another variable that has been computed previously
which is correct then the dicing technique can be
employed. The bug is likely to be associated with a slice
on the incorrectly computed variable minus the slice on
the correctly computed variable.
In the next step of the debugging process the
execution trace is traversed backwards starting from the
incorrect valued variable that caused the assertion. The
traversal of the tree is guided by the data dependency
provided by the BLTDG. At each node in the BLDTG,
representing a valid system of equations, the user is
asked about the intended behavior. This process is
usually finished when the user has localized an error
inside a block representing an equation system. Below we
present the steps of the algorithmic semi-automated
debugging method for equation-based languages:
Algorithm: Automatic Debugging for Equations
Input: Formal specification of the behavior FP.
Output: Error location.
begin
- During the program translation save the dependency
graph BLTDG.
- Run the simulation model with a given set of input
values and parameter values.
- while (program running)
Add to the list TV the variables that pass the
assertions from the formal specification FP.
if a variable v fails the assertion then
program running=false; //stop the program
Save the execution trace ET.
end if
- end while
- foreach vark ∈ TV where 1 ≤ k ≤ n , n is the size of
TV
Compute the slice corresponding to
vark : slice(vark )
- end foreach
- Compute the slice of the variable v that failed the
assertion: slice(v) .
- Compute the dice of BLTDG with respect to the
variable that failed the assertion and the variables
that passed the assertion according to the formula:
D = slice(v ) −
∪ slice(var )
n
k
k =1
- Construct a depth-first search tree T in D starting
from the node that represents the wrongly valued
variable v.
- foreach node n ∈ T do
Ask the user the correctness of each equation block
corresponding to node n by using information from
the execution trace ET.
if (error found) then exit ;
- end foreach
end Algorithm.
Let us again consider the simulation of the electromechanical device from Figure 2 and the associated formal
specification of its behavior given in Figure 4. An
execution of the simulation model will cause the
assertion associated to variable vsens.v to fail while the
assertion associated to emf.v will evaluate to true.
During the simulation the execution trace is saved and
decorated with the data dependency given by the BLTDG.
The BLTDG associated to the electromechanical device
simulation example is given in Figure 9 a). The
automatic debugger is automatically invoked when one of
the assertions fails or it can be invoked by the user after
noticing the symptom of a bug.
Program dicing is the first step in narrowing the code
that the automatic debugger needs to show to the user for
validation. The program dice obtained with respect of
the incorrect variable vsens.v and the correct variable
emf.w is shown in Figure 9 b).
In the next step, the remaining execution tree, as the
one shown in Figure 9 b), is traversed backwards with
respect to the dependencies. At each node the algorithmic
debugger will try to complete the missing specification by
asking questions to the user regarding the correctness or
incorrectness of the specified equation and variable
parameters values. Nodes that represent simple
assignments statements (marked by a dashed ellipsis in
Figure 9 b)) are skipped by the debugger. For our
particular example, an interaction session with the
algorithmic debugger is shown in Figure 9 c) (the user
answer is preceded by the << notation). It should be
noticed that the user interaction is performed at the
original declarative source code despite the fact that the
debugger operates on a highly optimized and
symbolically transformed intermediate code level. This is
done by maintaining a mapping between the intermediate
code and the original declarative code. The debugging
session ends when there are no nodes left to be traversed
or when the user has located the error inside a block with
an incorrect behavior. In our particular case the error has
been located inside the block that computes the value for
v= -2.8242 from the equation 2*k*w = v where k =
-0.5 has been supplied as a parameter to the emf model.
The obvious disadvantage of the approach is the large
number of questions that the user needs to answer during
the debugging process. Without any formal specification
of the behavior of the simulation model, the number of
questions is equal to the number of equation blocks that
precedes the computation of the wrongly valued variable.
6. Summary and Conclusions
In this paper we have proposed an algorithmic semiautomated debugging framework for fault localization
and behavior verification of simulation models expressed
in equation-based languages. Analyzing the execution
trace decorated with data dependency graph in the form
of the BLT Dependency Graph (BLTDG), extracted from
the language compiler, is the basis of the debugging
algorithm described in the paper. The implemented
prototype debugger attached to the Modelica language
simulation environment allows the user, via an
interactive session, to detect and repair errors caused by
incorrect parameter values and incorrectly specified
equations.
ex.y
ex.outPort.sign
iner.flange_b.p
hi
A.inPort.signal
emf.flange_b.ph
i
A.a
emf.w
A.w
emf.v
A.phi
emf.p.
R2.n.v
ind.p.v
vsens.n.i
A.flange_b.phi
iner.flange_a.p
hi
iner.ph
emf.w – der(emf.flange_b.phi) = 0
emf.v
G.p.v
emf.v - emf.p.v + emf.n.v = 0
emf.p.
emf.n.
ind.p.v – emf.p.v =
0
ind.p.v
vsens.p.v
ind.i ind.v ind.n.v
R1.p.v R1.i R1.v
R1.n.v R2.p.v R2.v
R2.i R2.p.i R1.n.i
R1.p.i ind.n.i
iner.w
ind.p.i
emf.p.i
iner.a
emf.i
G.p.v
emf.n.
ind.i ind.v ind.n.v
R1.p.v R1.i R1.v
R1.n.v R2.p.v R2.v
R2.i R2.p.i R1.n.i
R1.p.i ind.n.i
R1.n.v
vsens.n.v-R1.n.v = 0
vsens.v - vsens.p.v + vsens.n.v =
0
vsens.n.v
vsens.v
G.p.v = 0
G.p.v-emf.n.v = 0
vsens.p.v
vsens.p.v - emf.n.v = 0
ind.i - ind.p.i = 0
ind.L * der(ind.i) - ind.v = 0
ind.v - ind.p.v + ind.n.v = 0
R1.p.v - ind.n.v = 0
R1.i - R1.p.i = 0
R1.R * R1.i - R1.v = 0
R1.v - R1.p.v + R1.n.v = 0
R2.p.v - R1.n.v = 0
R2.v - R2.p.v + R2.n.v = 0
R2.R * R2.i - R2.v = 0
R2.i - R2.p.i = 0
R1.n.i + R2.p.i + vsens.n.i = 0
-R1.p.i - R1.n.i = 0
ind.n.i + R1.p.i = 0
-ind.p.i - ind.n.i = 0
b)
in: n.v = -1.40748; p.v = 0; out: v = 1.40748
model VoltageSensor equation v = p.v – n.v ?
<< Yes
emf.flange_b.ta
u
out: p.v = 0
model G equation p.v = 0; ?
<< Yes
iner.flange_b.ta
u
in: ind.p.v = -2.8242; out: ind.i …….ind.p.i
model TwoPin equation
v = p.v - n.v;
0 = p.i + n.i;
i = p.i;
model Resistor equation
R * i = v;
model Inductor equation
L*der(i) = v:
model Circuit
connect(ind.n,R1.p);
connect(R1.n,R2.n);
connect(R2.p,vsens.n); ?
<< Yes
iner.flange_a.ta
u
A.flange_b.tau
emf.n.i
R2.n.i
R2.p.i
vsens.p.i
G.p.i
emf.w
2* emf.k * emf.w – emf.v = 0
R1.n.v
in: v = -2.8242; n.v = 0; out: p.v = -2.8242
model EMF equation v = p.v - n.v;?
<< Yes
vsens.n.v
vsens.v
vsens.outport.signa
l
a)
in: w = 1.88272; out: v = -2.8242
model EMF equation 2 * k * w = v; ?
<< No
c)
Figure 9. a) The BLTDG of the electromechanical device from Figure 2 b). The program dice obtained with respect to the incorrectly
valued variable vsens.v and to the correctly valued variable emf.w together with the corresponding equations for each block at
the intermediate code level. c) The user interaction during automated algorithmic debugging.
[6] Fritzson Peter. (2003). Principles of Object-Oriented
References
Modeling and Simulation - with Modelica. In Press. IEEE
Press and John Willey, 2003.
[7] Fritzson Peter and Peter Bunus. (2002). "Modelica, a
[1] Duff Iain S. and J. K. Reid. (1978) "Algorithm 529:
General Object-Oriented Language for Continuous and
Permutations To Block Triangular Form. ACM
Discrete-Event System Modeling and Simulation" In
Transactions on Mathematical Software (TOMS)." ACM
Proceedings of the 35th Annual Simulation Symposium.
Transactions on Mathematical Software (TOMS), vol. 4:
(San Diego, California, April 14-18, 2002).
2, pp. 189-192, 1978.
[8]
Fritzson Peter, Nahid Shahmehri, and Mariam Kamkar.
[2] Duff Iain S. and J. K. Reid. (1978) "An Implementation of
(1992) "Generalized Algorithmic Debugging and Testing"
Tarjan's Algorithm for the Block Triangularization of a
ACM Letters on Programming Languages and Systems,
Matrix." ACM Transactions on Mathematical Software
vol. 1: 4, pp. 303-322, 1992.
(TOMS), vol. 4: 2, pp. 137-147, 1978.
[9]
Lyle J.R. and M. Weiser. (1987). "Automatic Program
[3] Duff Iain S. and J. K. Reid. (1981) "Algorithm 575:
Bug Location by Program Slicing" In Proceedings of the
Permutations for a Zero-Free Diagonal." ACM
The Second International Conference on Computers and
Transactions on Mathematical Software (TOMS), vol. 7:
Applications. (Peking, China, June, 1987).
3, pp. 387-390, 1981.
[10] Parasoft. (1997) "It's a Bug Free World After All."
[4] Duff Iain S. and J. K. Reid. (1981) "On Algorithms for
Technical Paper PS-9710-DV3, 1997.
Obtaining a Maximum Transversal." ACM Transactions
[11] Shahmehri Nahid. (1991). Generalized Algorithmic
on Mathematical Software., vol. 7:3, pp. 315-330, 1981.
Debugging. PhD Thesis, Disertation no. 260. Linköping
[5] Elmqvist Hilding, Sven Erik Mattsson, and Martin Otter.
University, Sweden, 1991.
(1999). "Modelica - A Language for Physical System
[12] Shapiro Ehud. (1983). Algorithmic Program Debugging,
Modeling, Visualization and Interaction." In Proceedings
MIT Press, 1983.
of the IEEE Symposium on Computer-Aided Control
[13]
Weiser M. (1984) "Program Slicing" IEEE Transactions
System Design. (Hawaii, USA, August 22-27, 1999).
on Software Engineering ,vol. SE-16:4, pp. 352-357,
1984.