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.
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
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.

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.
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
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. model TwoPin
Pin p,n;
Real v,i; equation v = p.v - n.v; 0 = p.i + n.i; i = p.i; end TwoPin;
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 ). connector Pin
Real v; flow Real i; end Pin;
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 R1 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
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.
1
R1 ind ex a
A iner emf
Block part
Mechanical part
G
Figure 2. Simulation model corresponding to an electromechanical device.
Electrical circuit
2
R2 vsen
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 ex.y
vsens.v
iner.w
1.5
1
0.5
t
1 2 3 4 5 6 7
Figure 3. Plots of the simulation results of the electromechanical circuit.
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.

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
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 be less that 0.75V after 4 second of simulation time while the angular acceleration of the inertial component iner.w
always should be greater than 1.5 rad/s
2
. For our particular example the behavior specification is given in
Figure 4. 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. model Electromechanical
Inertia iner; VoltageSensor vsens; equation
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 if (time>4) then
vsens.v < 0.75 and iner.w > 1.5 end Electromechanical
Figure 4. Formal specification of the electromechanical device behavior.
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
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 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]. 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,





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 

 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
Figure 5. a) The structural incidence matrix. b) Permuted incidence matrix with a zero-free diagonal. c) BLT form of the incidence matrix.
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; parameter model C parameter Real k2 = 3.5; equation parameter Real a.k3 = 2;
s + 2*k3*q = 9; parameter Real k1 = 10;
q - s = 1; end A;
Real x;
Real y; model B
Real x,y; parameter
Real a.s;
Real a.q;
Real a.u; equation
Real a.w; der (y) = x - k2*y;
Real z; end B; model C extends B;
A a;
Real z; parameter Real k1=10; equation
a.q - a.u = 2;
z = a.s - y + a.u;
x-2*y = a.w-a.u; der (x) = k1*z; equation
der (y) = x-k2*y;
a.s+2*a.k3*a.q = 9;
a.q-a.s = 1;
a.q-a.u = 2;
z = a.s-y+a.u;
x-2*y = a.w-a.u;
der (x) = k1*z; end C; end C;
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>
BLOCK B1
Linear System of
Equations a.s+2*a.k3*a.q=9; a.q-a.s = 1;
Block B2
Single equation a.q-a.u = 2;
Block B3
DAE System double x,y,a_s,a_q,a_u,a_w,z; int functionDAE_block3
(double *yd, double *yprime, …){
--yd;--yprime;--delta;
delta[1]=yprime[1]-y[3]+3.5*y[1];
delta[2]=y[2]-a_s+y[1]-a_u;
delta[3]=yprime[3]-10*y[2];
return 0;
} int main(){
for(double it=0;it<=1;it+=0.1){
// Solve Linear System of Equations
double A[2][2]={{1,-1},{4,1}},B[2];
DGESV(A,B,....);
a_q=B[0]; a_s=B[1]; der(y) = x-k2*y z = a.s-y+a.u der(x) = k1*z
Block B4
Single equation x-2*y = a.w-a.u;
//Single assignement
a_u=a_q-2;
//Solve DAE
double yd[3],yprime[3];
DDASSL(functionDAE_block3,
yd,yprime,,...);
y=yd[0]; z=yd[1]; x=yd[2];
//Single assignement
a_w=x-2*y+a_u; a) b) 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)
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.

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).
BLT
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:
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
B k
∈ BLT where 1 k n ( n being the number of blocks in the BLT form) we have the following variable sets:
•
IN( B k
) set of variables whose values are used in B k
.
•
COMP( B k
) the set of variables whose values are computed in B .
k
•
OUT( B k
) the set of variables that are propagated to other blocks.
From the BLT form we can derive a BLT dependency graph ( BLTDG ).
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( B k
) whose values are computed in that particular node. An edge ( , ) ∈ 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). a.q-a.s = 1 X X a.s+2*a.k3*a.q = 9 X X a.q-a.u = 2 X der(y) = x-k2*y z = a.s-y+a.u
der(x) = k1*z x-2*y = a.w-a.u
X
}
B
2
B
1
X X
X X
X
X
X
X
X X
X X
}


B
3
B
4
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. a_s a_q a_s a_u a_q a_u y,z,x y,x a_u a_w
Block B1 a.s+2*a.k3*a.q = 9; a.q - a.s = 1;
Block B2 a.q-a.u = 2
Block B3 der(y) = x-k2*y z = a.s-y+a.u der(x) = k1*z
Block B4 x-2*y = a.w-a.u;
Figure 8. The BLTDG associated to the ex. from Figure 6 a).
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
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.

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 var k
∈
TV where 1 k n
TV
, n
Compute the slice corresponding to
is the size of var k
: slice(var )
end foreach
- Compute the slice of the variable v that failed the assertion: slice( ) .
- 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
= n v
− slice( var 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.
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.
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.

ex.outPort.sign
iner.flange_b.p
hi emf.w – der(emf.flange_b.phi) = 0 emf.w G.p.v
G.p.v = 0
2* emf.k * emf.w – emf.v = 0
G.p.v-emf.n.v = 0 ex.y
A.inPort.signal i emf.flange_b.ph
emf.v emf.n.
A.a
A.w
A.phi
A.flange_b.phi iner.flange_a.p
hi iner.ph
iner.w iner.a emf.w emf.v emf.p.
ind.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 ind.p.i emf.p.i emf.i
G.p.v emf.n.
R2.n.v vsens.n.i vsens.p.v
emf.v - emf.p.v + emf.n.v = 0 emf.p.
vsens.p.v ind.p.v – emf.p.v =
0 ind.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
R1.n.v vsens.n.v-R1.n.v = 0 vsens.n.v ind.i - ind.p.i = 0 vsens.p.v - emf.n.v = 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 vsens.v - vsens.p.v + vsens.n.v =
0 vsens.v in: n.v
= -1.40748; p.v
= 0; out: v = 1.40748 model VoltageSensor equation v = p.v – n.v ?
<< Yes b) emf.flange_b.ta
u out: p.v
= 0 model G equation p.v
= 0; ?
<< Yes iner.flange_b.ta
u iner.flange_a.ta
u
A.flange_b.tau emf.n.i
R2.n.i
R2.p.i vsens.p.i 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
G.p.i
R1.n.v vsens.n.v in: v = -2.8242; n.v = 0; out: p.v = -2.8242 model EMF equation v = p.v - n.v;?
<< Yes vsens.v a) c) in: w = 1.88272; out: v = -2.8242 model EMF equation 2 * k * w = v; ?
<< No l vsens.outport.signa
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
Modeling and Simulation - with Modelica.
In Press. IEEE
[1] Duff Iain S. and J. K. Reid. (1978) "Algorithm 529:
Permutations To Block Triangular Form. ACM
Transactions on Mathematical Software (TOMS)." ACM
Press and John Willey, 2003.
[7] Fritzson Peter and Peter Bunus. (2002). "Modelica, a
General Object-Oriented Language for Continuous and
Discrete-Event System Modeling and Simulation" In
Proceedings of the 35th Annual Simulation Symposium.
Transactions on Mathematical Software (TOMS) , vol. 4:
2, pp. 189-192, 1978.
[2] Duff Iain S. and J. K. Reid. (1978) "An Implementation of
Tarjan's Algorithm for the Block Triangularization of a
Matrix." ACM Transactions on Mathematical Software
(TOMS) , vol. 4: 2, pp. 137-147, 1978.
(San Diego, California, April 14-18, 2002).
[8] Fritzson Peter, Nahid Shahmehri, and Mariam Kamkar.
(1992) "Generalized Algorithmic Debugging and Testing"
ACM Letters on Programming Languages and Systems , vol. 1: 4, pp. 303-322, 1992.
[3] Duff Iain S. and J. K. Reid. (1981) "Algorithm 575:
Permutations for a Zero-Free Diagonal." ACM
[9] Lyle J.R. and M. Weiser. (1987). "Automatic Program
Bug Location by Program Slicing" In Proceedings of the
The Second International Conference on Computers and
Transactions on Mathematical Software (TOMS) , vol. 7:
3, pp. 387-390, 1981.
[4] Duff Iain S. and J. K. Reid. (1981) "On Algorithms for
Applications.
(Peking, China, June, 1987).
[10] Parasoft. (1997) "It's a Bug Free World After All."
Technical Paper PS-9710-DV3 , 1997.
Obtaining a Maximum Transversal." ACM Transactions on Mathematical Software.
, vol. 7:3, pp. 315-330, 1981.
[5] Elmqvist Hilding, Sven Erik Mattsson, and Martin Otter.
(1999). "Modelica - A Language for Physical System
Modeling, Visualization and Interaction." In Proceedings of the IEEE Symposium on Computer-Aided Control
[11] Shahmehri Nahid. (1991). Generalized Algorithmic
Debugging. PhD Thesis, Disertation no. 260. Linköping
University, Sweden, 1991.
[12] Shapiro Ehud. (1983). Algorithmic Program Debugging,
MIT Press, 1983.
System Design.
(Hawaii, USA, August 22-27, 1999). [13] Weiser M. (1984) "Program Slicing" IEEE Transactions on Software Engineering ,vol. SE-16:4, pp. 352-357,
1984.
Proceedings of the 18th IEEE International Conference on Automated Software Engineering (ASE’03)
1527-1366/03 $ 17.00 © 2003 IEEE
Authorized licensed use limited to: Linkoping Universitetsbibliotek. Downloaded on January 6, 2010 at 12:01 from IEEE Xplore. Restrictions apply.