Model-Driven Reverse Engineering

Spencer Rugaber ([email protected])

Georgia Institute of Technology
Kurt Stirewalt ([email protected])
Michigan State University
Managing software maintenance projects applies them differently to address the mainte-
is difficult. A manager typically has to deal nance manager’s problems.
with a backlog of outstanding problems, a staff
battling numerous concurrent fires, and a cor- Adequate reverse engineering
porate profile in which failures have high visi-
The maintenance manager’s uncertainty
bility and success is greeted by a deafening
arises from the fact that we do not really
silence. And when a project being managed
understand when a reverse engineering effort
includes programs that were written by a dif-
is adequate. The idea of adequacy comes from
ferent group or possibly a different company,
the world of software testing where an ade-
there is the additional problem of trying to
quate test set is one that, when successfully
understand obscure foreign code.
executed, indicates that the testing phase of
Reverse engineering is the process of com-
development is complete [13]. Testers use var-
prehending software and producing a model of
ious adequacy criteria, such as ensuring that
it at a high level of abstraction, suitable for
tests exist to demonstrate that all requirements
documentation, maintenance or reengineering.
have been exercised or that all program state-
How can reverse engineering be used to help
ments have been executed. These criteria
solve the problem of foreign code? Reverse
derive their benefit from being deterministic
engineering technology has, in fact, proven
and measurable.
useful on many projects in helping a mainte-
If adequacy criteria existed for reverse
nance team obtain a better understanding of
engineering, then software engineers could
the structure and functioning of a software sys-
start collecting experience reports and building
tem. But, from a manager’s point of view,
databases of project statistics to help predict
there are two painful problems: it is difficult or
reverse engineering time and effort.
impossible to predict how much time a reverse
For an adequacy criterion to be useful, it
engineering effort will require, and there are
must be objectively measurable. This implies
no standards for how to evaluate the quality of
that there must be an artifact that is the subject
the reverse engineering work the maintenance
of the measurement. In the case of testing, the
staff performs.
artifact is the test suite. An adequate test suite
Model-driven reverse engineering (MDRE)
is designed to overcome these difficulties. A is one that provides confidence in the quality
model is a high-level representation of some of the testing it directs. In the case of MDRE,
adequacy is measured using the high-level
aspect of a software system. One popular use
model produced by the software engineers
of models by software engineers is to precisely
undertaking the reverse engineering.
specify systems before they are built. In some
What might adequacy criteria for a reverse
cases, modeling tools can even generate part or
engineering model comprise? Two characteris-
all of the code without having to resort to
tics seem essential: thoroughness and lucidity.
explicit and error-prone programming. MDRE
Thoroughness is the extent to which the
uses these features of modeling technology but
reverse engineering effort covers the entire
system being examined. By lucidity, we mean close-enough version may not run as fast or
the extent to which the reverse engineering use the same amount of memory, but it does
sheds light on the purpose of the system and compute the same values. This is the target we
how that purpose is accomplished by the code. have used in our model-driven reverse engi-
neering efforts.
Reverse reverse engineering
How can models help with measuring the
Model-driven reverse engineering
thoroughness and lucidity of a reverse engi- What sort of models can support reverse
neering effort? The answer comes from the reverse engineering? MDRE uses two sorts, a
idea of reversing the reverse engineering pro- program model and an application-domain
cess—taking the result of the reverse engineer- model, which roughly correspond to our target
ing and using it to produce a second version of adequacy criteria for thoroughness and lucid-
the original system. In other words, reverse ity. In the example below, we describe both
engineering produces a high-level model of the models using an algebraic specification lan-
system being studied. If the model is expressed guage called SLANG. SLANG is part of a tool
in a formal specification language and if the called Specware [7], developed by the Kestrel
formal specification language is supported by Institute, that includes a code generator capa-
a code generation tool, then the code generator ble of producing executable code from high-
can be used to produce another version of the level models.
original system. If the generated version The program model provides a high-level
proves close enough to the original, then we rendering of the functions computed by the
can have confidence that we have done an ade- program. That is, it provides a precise state-
quate job in our reverse engineering. ment of the values computed by the program
What does close enough mean? Several but at a higher level of abstraction than obtains
definitions possible definitions come to mind, in the program source code. Algebraic specifi-
corresponding to different degrees of ade- cations have proven popular precisely because
quacy. At one extreme would be a stub genera- they support programming at a high level of
tor that produced a compilable version of the abstraction, thereby reducing effort at the pos-
program including stubs for all of the subpro- sible expense of execution speed. And because
grams and external data structures, but that algebraic specifications are precise enough to
produced no results when executed. Such tools serve as a basis for code generation, they
currently exist, but they provide only superfi- enable the thoroughness of reverse engineering
cial insight into the workings of a program. to be measured.
At the other extreme would be a generator In contrast with a program model, an
that reproduced the original program on a line- application-domain model expresses domain
by-line basis. While this version may be ulti- concepts, their relationships, and their mean-
mately desirable, its seems unrealistic given ings in a program-independent way. An appli-
the current state of specification technology cation domain is a set of related problems that
and the allowable time available for reverse have engendered software solutions [1]. An
engineering. example is desktop publishing for which
A middle ground that addresses these con- numerous competing products have been
cerns obtains if we can generate a program developed. When a program is a member of an
capable of duplicating the output of the origi- application domain, its users can expect a cer-
nal program on identical input without neces- tain context, behavior, and terminology. More-
sarily generating the same code. That is, the over, if the constructs in the program can be
 problems making use of alternative tool sup-
R o o t fin d e rs
port. UML (the Unified Modeling Language)
[8], provides an industry standard, semi-formal
design notation, which, although requiring
extra training and effort to use, has proved
P o ly n o m ia l N o n -p o ly n o m ia l popular. UML provides a variety of notations
ro o t fin d e rs ro o t fin d e rs
that can be used for modeling domains. Its
graphical orientation, tool support, and early
detection of certain classes of errors, together
with the increasing popularity of the object-
M u ltip le S in g le ro o t
ro o t fin d e rs fin d e rs oriented methods it supports, suggest that it
will provide some of the advantages claimed
by proponents of formal methods. Moreover, a
relatively recent addition to UML, OCL (the
B ra ck e te d Open Object Constraint Language), complements
UML's ability to describe structure with the
ro o t fin d e rs ro o t fin d e rs

ability to formally model program functional-

ity. Together, these technologies provide
developers a path to more rigorous software
ZBRENT development practices. UML is frequently used
in the design of information systems and e-
Figure 1. Lineage for ZBRENT commerce software. To apply MDRE in this
context requires substituting a UML-refinement
related to corresponding aspects of the domain tool, such as UMLaut [6], for Specware and a
model, then the roles these constructs play in UML compatible language, such as OCL, for
achieving application domain goals can be SLANG.
determined. In MDRE, because both the pro-
gram model and the domain model are present, Example
explicit connections between program con- To illustrate the issue of adequate models,
structs and the corresponding domain concepts we reverse engineered a numeric application
can be made. In this way, an application called ZBRENT, written in the C programming
domain model enables lucidity to be assessed. language [11]. The application domain was
Applicability of MDRE to other domains. numerical computation, specifically, finding
There are two prerequisites for using MDRE—a the root of a real-valued function. A domain
mature domain and a code-generation tool model was constructed by collecting material
capable of compiling domain-specific applica- from textbooks on numerical analysis. Then
tion specifications. An example of such a SLANG was used to model both the domain and
domain is scheduling, for example, the sched- the program. We made use of the SLANG code
uling of airline crews. The domain is mature generator in Specware to produce an execut-
and circumscribed. Moreover, Specware has able version from our model of ZBRENT, which
been used to generate efficient scheduling was then compared with the original program
algorithms from schedule constraints on a set of test functions.
expressed in SLANG [12]. Root finding. Finding the root of a nonlinear
One recent technology, UML, suggest that equation is a well-understood problem in
MDRE could be applied to a broader class of
numerical analysis [4][5]. That is, there is a
 y root; creating a new, refined interval using the
f(x) chosen piece; and iterating. In the figure, inter-
val end points are indicated with dashed lines.
Increasing subscripts on interval names denote
the order of refinement. For example, interval
i2 is refined by the smaller interval i3. Brack-
x eted root-finding algorithms have the property
i3 that the interval gets smaller on every iteration.
i2 Moreover, a stopping criterion determines
i1 whether sufficient progress has been made to
i0
warrant continuing the process.
Algorithms of this kind can be categorized
Figure 2. Iterative Interval Shrinkage in two ways: first, by specifying the method in
which a refined interval is chosen and, second,
by the choice of stopping criterion. Variations
sufficiently large collection of programs for of the former sort include bisection (Bolzano's
finding roots that we can identify common method), linear interpolation (Regula Falsi),
characteristics and use them as expectations to inverse quadratic interpolation (Mueller's
guide the reverse engineering process. method), Aiken's Delta Squared, Newton-
As illustrated in Figure 1, at the top level, Raphson, and secant. Variations of the latter
the root-finding application domain can be sort include stopping when the functional
partitioned into polynomial and non-polyno- value is sufficiently close to zero, stopping
mial families of algorithms. Within the latter, a when the interval width is sufficiently narrow,
further distinction exists between algorithms and stopping after a fixed number of iterations.
capable of finding multiple roots and those Of course, multiple methods can be combined
capable of dealing with a single root only. For to improve robustness or efficiency.
the purposes of this example, we are con-
cerned with the latter class. Within single-root ZBRENT. ZBRENT is production software that
finders, a final distinction is made between has been in use for many years. It combines
those guaranteed to converge—bracketed root several of the variations described above to
finders—and those presumably more efficient improve efficiency and robustness. We chose
ones that do not—open root finders. the Brent variation, taken from [9], as the sub-
Single-root, non-polynomial root finders ject of our case study for several reasons.
work in the following way, as illustrated in • It features several choices of stopping cri-
Figure 2. Input consists of a subprogram (f), teria.
capable of computing a functional value at a • It features three interval shrinkage meth-
given real value (x), and an initial estimate of ods: bisection, secant, and inverse qua-
the root in the form of a containing subinterval dratic interpolation.
of the real line, denoted by its end points. • A variant of ZBRENT was used in an influ-
Functional evaluation is typically expensive, ential case study by Basili and Mills [2].
so root-finding algorithms try to reduce the This allows us to more closely compare
number of calls to f. our work with theirs.
Root finding normally proceeds by select- As a consequence of the number of variations,
ing a trial point within the current interval, the code is complex and difficult to follow,
thereby partitioning the interval into two making it a good candidate for reverse engi-
pieces; determining the piece containing the neering.
( 1) spec INTERVAL is defined with a sort axiom (line 4) as being the
( 2) import EXTENDED-REAL Cartesian product of two Reals.
( 3) sort Interval
( 4) sort-axiom Interval = Real, Real
In INTERVAL, two operations are defined
( 5) (mid-point and make-interval). Operation defini-
( 6) op mid-point : Interval -> Real tions consist of a signature and one or more
( 7) definition of mid-point is axioms. For example, the signature for mid-
( 8) axiom mid-point(a, b) =
point (line 6) indicates that it takes as input an
( 9) half(plus(a, b))
(10) end-definition Interval and produces as output a Real. The sin-
(11) gle axiom defining mid-point (lines 8-9) asserts
(12) op make-interval : Real, Real -> that the output value it produces—when given
(13) Interval as input the Interval constructed from values a
(14) definition of make-interval is
(15) axiom make-interval(a,b) = (a,b) and b—is equal to the value produced when
(16) end-definition the half operation is applied to the results of
(17) applying the plus operation to a and b. In a sim-
(18) constructors { make-interval } ilar manner, the make-interval operation is
(19) construct Interval
(20) end-spec
defined on lines 12-16. Finally, lines 18-19
indicate that the make-interval operation pro-
Figure 3. SLANG INTERVAL Specification vides a way in which new Intervals may be con-
structed.
Algebraic specification. Algebraic specifica-
tions are composed using sorts (data types) SLANG support for adequate models. In
and the operations that manipulate them. Specware, specifications are actual data values
Operations are in turn defined via axioms (sets that can be manipulated by high-level opera-
of equations). Each axiom indicates how the tors called morphisms. In particular, SLANG
value computed by one sequence of operations provides three kinds of morphisms: import, for
equates to that computed by another. including one specification inside another;
The equations that comprise an axiom can translate, for renaming the sorts and opera-
also be thought of as rewrite rules; that is, tions of a specification; and colimit, for com-
occurrences of the left hand side of an equation bining specifications in a structured way. By
can be replaced by the right hand side, possi- writing atomic specifications and then using
bly including parameter substitution. In morphisms to operate on them, complex sys-
Specware, the substitution can be automated in tems can be cleanly modeled.
such a way that code can be generated that We employed one other Specware feature
implements the operation in a programming called an interpretation, which Specware uses
language. to formalize design refinements. Refinements
As an example of an algebraic specifica- relate abstract domain-model concepts to exe-
tion, the SLANG code shown in Figure 3 pre- cutable code. Operationally, an interpretation
sents the specification of an interval suitable demonstrates how the sorts and operations in
for use in building a domain model for root one model are implemented using sorts and
finders. This specification for INTERVAL (lines operations in another model at a lower level of
1-20) describes a sort called an Interval (line 3) abstraction. Interpretations enable a reverse
making use of a previously defined sort Real engineer to directly relate application-domain
that models x-axis values. Real is provided by concepts to program constructs. MDRE assesses
an imported specification called EXTENDED- lucidity by requiring the use of interpretations
REAL (line 2). The structure of an Interval is to connect domain and implementation.
 REAL

EXTENDED-
REAL

ROOT-
INTERVAL CONVERGENCE- MACHINEEPS
TEST

BRACKETED-
INTERVAL
EQUALS-ZERO

CANDIDATE-
POINT-
GENERATION NARROW

OPEN BRACKETED

SECANT INVERSEQ BISECT ROOT-FINDER

Figure 4. Root Finding Domain Model

MDRE process. The reverse engineering of concepts. During the third step, we engaged in
ZBRENT consisted of three steps. In the first an iterative process of defining SLANG inter-
step, we constructed a domain model by read- pretations to connect the program-model oper-
ing descriptions in books and papers on root ations to domain concepts. After a set of
finding and articulating them in SLANG. The connections are made, the Specware code gen-
domain model provides a set of expectations erator is executed, producing an approximation
for concepts that might be realized in root find- to ZBRENT. If the generated program produces
ing programs. In the second step, we con- results identical to the original, then the
structed a program model by expressing the reverse engineering is thorough; if all the pro-
ZBRENT source code as a specification com- gram constructs have been connected with
prising a set of SLANG operation definitions. domain concepts, the reverse engineering is
This step produces an abstract but comprehen- lucid.
sive representation of the program without Often, introducing an interpretation
providing any insight into how the program- required refactoring the implementation
ming constructs relate to application-domain model. We only allowed changes that main-
tained thoroughness; that is, ones for which ending in a small circle. A colimit is a shared
Specware could generate a program that was union of the two source specifications. It is
testing equivalent to the original code for particularly valuable because it allows inde-
ZBRENT. We stopped this process when we pendent concepts to be separately modeled and
were able to connect every implementation then explicitly combined. For example, in Fig-
specification to the appropriate domain speci- ure 4, the ROOT-CONVERGENCE-TEST and
fication. MACHINEEPS specifications are combined
using a colimit to produce the NARROW speci-
The root-finding domain model. Figure 4
fication. ROOT-CONVERGENCE-TEST defines
depicts the root-finding domain model as a set
properties of all mechanisms for terminating
of related Specware specifications. Boxes in
root-finding iterations; MACHINEEPS describes
the figure denote specifications that represent
specific properties of floating point numbers.
different concepts and relationships in the
NARROW then describes a test for termination
domain. Filled boxes are not part of the root-
when the current interval has gotten so small
finding domain but provide resources to it
that no further progress can be made using
from other domains. For example, REAL is the
available floating-point operations.
specification for real numbers.
The root finding domain model proper The ZBRENT program model. In addition to
consists of twelve specifications, which can be the root-finding domain model, a specification
organized into three groups: the iterative root must be given for the ZBRENT algorithm itself.
finding algorithm (ROOT-FINDER), termination The intent is to render the details of the algo-
condition checks (ROOT-CONVERGENCE- rithm into SLANG so that interpretations can
TEST, NARROW and EQUALS-ZERO), and then be used to relate them to the domain
methods for interval shrinking (the remaining model. To illustrate how this step works, we
unfilled boxes). make use of the flow-chart shown in Figure 5.
In addition to the twelve domain specifica- BEG IN
ZBRENT

tions, Figure 4 also illustrates several kinds of

morphisms. An unadorned line in the figure root found Yes
END
ZBRENT

denotes an import morphism, indicating the No

textual inclusion of one specification within

com pute
refined
interval

another. This normally signifies a new specifi- END

Yes
cation that builds on the features of an old one.
converged
ZBRENT

No
For example, the INTERVAL specification needs possible to
Yes
to import from the REAL specification because interpolate

the interval end points are real numbers.

choose
No m ethod

The bold lines in the figure correspond to

inverse
secant quadratic
interpolation

translate morphisms in which one or more

imported specification elements have been bisect
attem pt
interpolation

renamed. In the root-finding domain model,

the renaming enables the ROOT-FINDER speci- No
check
interpolation Yes

fication to be written using an abstract conver- bisect

accept
interpolation

gence test which, in the ZBRENT algorithm, is

refined by the disjunction of the two concrete
tests specified in the figure (EQUALS-ZERO update
interval

and NARROW).
Finally, and most interestingly, are the two Figure 5. Abstract Flow Chart for ZBRENT
colimit morphisms denoted by dashed lines
 Figure 5 contains a high-level flow chart computation of q. In Figure 6b, the (embold-
for ZBRENT. Although the box labels in the fig- ened) phrase div(fa1,pToNZReal(fc1)) describes
ure are expressed in terms of domain concepts, the earlier computation of q on line (1) of Fig-
no such labels occur in the source code. Con- ure 6a; the (emboldened) phrase r(fb1,fc1)
nections between source code constructs and describes the specification of (the program
domain concepts only emerge through signifi- variable) r on line (2) as an operation (also
cant iterative reverse engineering. The outer named) r applied to two parameters, fb1 and
loop of the source code wraps the shrinking fc1.
process and ensures termination by counting (1) q = fa / fc;
(2) r = fb / fc;
iterations. Within this loop, it is possible to ter-
(3) q = (q-1.0) * (r-1.0) * (s-1.0);
minate successfully if either the root has been
found (node labeled root found) or the inter-
val itself has grown too narrow (converged). Figure 6a. Source Code Fragment for Inverse
If termination is not warranted, a check is Quadratic Interpolation Computation
made to see whether interpolation is promising
(possible to interpolate). In this case, either
op q : Real, Real, Real, Real -> Real
secant or inverse quadratic interpolation is definition of q is
chosen. If neither of these methods produces a axiom q(s,fa1,fb1,fc1) =
bracketed value, then bisection is used. Finally, times(minus(div(fa1,
the interval is updated with the appropriately pToNZReal(fc1)),one),
chosen subinterval. times(minus(r(fb1,fc1),
one), minus(s,one)))
The SLANG specification of the ZBRENT
end-definition
algorithm consists of a rendering of the flow
chart boxes with axioms. In essence, this com-
prises the following activities:
Figure 6b. SLANG Specification for Inverse
• Define operations corresponding to the
Quadratic Interpolation
various computations performed, nesting
operation invocations where appropriate.
• Make use of a built-in SLANG construct for
rendering conditional statements. Interpretations. Once the program model is
• Use recursion to model iteration. constructed for the ZBRENT algorithm, inter-
• Render assignments by passing the result- pretations can be defined to indicate how
ing state to subsequent operations. domain concepts are mapped to program con-
During the course of performing these structs. For the fragment shown in Figure 6, an
steps, a software engineer is forced to pay interpretation must be defined that maps the
attention to each of the program constructs, domain specification of INVERSEQ to the set
thereby increasing thoroughness. Moreover, of operations that realize it in the program
the various operations and axioms produced model.
become the targets of the interpretations The SLANG model of the ZBRENT algorithm
devised during the third step of the reverse is thorough in the sense that a program equiva-
engineering process. lent to the original can be generated from it.
Figure 6a contains a segment of the origi- However, by itself, it sheds no light on how the
nal program text for the box labeled inverse algorithm accomplishes the goal of finding a
quadratic interpolation in Figure 5. Figure 6b root. The SLANG interpretations are used for
contains the corresponding SLANG operation this purpose. In particular, an interpretation
definition for line (3) of Figure 6a, the second indicates precisely how an abstract domain
concept is manifested in the program. For adequate testing to provide an objective and
example, an interpretation between the domain deterministic standard.
specification EQUALS-ZERO and the program Amortizing the cost of domain modeling.
model construct corresponding to the box The process of reverse engineering ZBRENT
labeled root found gives a precise indication included the construction of a domain model
of the purpose of the program construct (pro- for root finding, requiring significant back-
gram termination check). To the extent that ground research. Fortunately, this activity only
each aspect of the algorithm specification is has to be done once regardless of how long the
tied to an application-domain concept, the program is maintained. And if other root find-
combined domain and program models are ing programs are being maintained, it is likely
judged lucid. that they can share the domain model. In other
words, domain modeling has a value that goes
Applying model-driven reverse engi- beyond the reverse engineering of a single pro-
neering gram—its cost can be amortized across subse-
A fixed standard for thoroughness and quent maintenance activities for the same and
lucidity would enable the maintenance man- related programs.
ager to better control the reverse engineering
process. An analogy exists with tools like We have described a particular approach to
COCOMO [3] and SLIM [10] that are used to Model-Driven Reverse Engineering. The
estimate project schedules. These tools use a approach uses a formal specification model
database of past experiences as a standard and code generator to reverse the reverse engi-
against which current projects can be mea- neering process. Models are used to describe
sured. Similar projects predict similar sched- both the application domain and the program
ules. Likewise, if adequacy standards for being reverse engineered. Interpretations are
reverse engineering efforts existed, then expe- used to annotate the connections between the
rience data could be collected and used to pre- two. Being able to generate a similar version
dict reverse engineering effort. of a program allows managers to have a fixed
An additional benefit accrues to adequacy target for a reverse engineering effort. This, in
standards. Currently, a variety of reverse engi- turn, can enable better effort prediction and
neering tools exist in the commercial market- quality evaluation, thereby reducing develop-
place. But their benefits are hard to judge ment risk.
because there is no agreed-upon standard for
the quality of the representations they produce. Acknowledgement
An adequacy standard would allow direct Part of the work described here was sup-
comparisons to be made, indicating, for exam- ported by the National Science Foundation
ple, that one tool provides a more thorough under grants CCR-9708913, EIA-0000433 and
description than another. CCR-9984726. We also appreciate the contri-
Relative adequacy. The adequacy criteria pre- butions of Terry Shikano to the development
sented above were relative rather than absolute of the example presented in this paper.
standards. For example, lucidity is relative to
the level of abstraction required of the reverse References
engineering. Thoroughness is also relative to [1] Guillermo Arango and Rubén Prieto-Díaz.
the suite of tests used to determine equiva- Domain Analysis and Software Systems Model-
lence. Here, we leverage what is known about ing. IEEE Computer Society Press, 1991.
[2] Victor R. Basili and Harlan D. Mills. “Under- [8] Object Management Group. “Unified Modeling
standing and Documenting Programs.” IEEE Language, Version 1.4.” OMG Document Num-
Transactions on Software Engineering, SE- ber 01-09-67, http://www.omg.org/cgi-bin/apps/
8(3):270-283, May 1982. doc?formal/01-09-67.pdf.
[3] Barry W. Boehm, Bradford Clark, Ellis Horowitz, [9] W. H. Press, S. A. Teukolsky, W. T. Vetterling,
J. Christopher Westland, Raymond J. Madachy and B. P. Flannery. “Root Finding and Nonlinear
and Richard W. Selby. “Cost Models for Future Sets of Equations.” Numerical Recipes in C,
Software Life Cycle Processes: COCOMO 2.0." The Art of Scientific Computing, Second Edi-
Annals of Software Engineering, 1, pp. 57-94, tion, Chapter 9, Cambridge University Press,
1995. 1992.
[4] G. Dalhquist and Å. Björck. “Nonlinear Equa- [10] L. H. Putnam. “A General Empirical Solution to
tions.” Numerical Methods, Chapter 6, Prentice- the Macro Software Sizing and Estimation
Hall, 1974. Problem.” IEEE Transaction on Software Engi-
neering, Volume SE-4, Number 4, July 1978.
[5] G. E. Forsythe, M. A. Malcolm, and C. B. Moler.
“Solution of Nonlinear Equations.” Computer [11] Spencer Rugaber, Terry Shikano, and Kurt
Methods for Mathematical Computations. Stirewalt. “Adequate Reverse Engineering.”
Chapter 8, Prentice-Hall, 1977. Proceedings of the Conference on Automated
Software Engineering, San Diego California,
[6] Wai Ming Ho, J.-M. Jezequel, A. Le Guennec 2001.
and F. Pennaneac'h. “UMLAUT: An Extendible
UML Transformation Framework.” 14th IEEE [12] Douglas R. Smith and Subbarao Kambham-
International Conference on Automated Soft- pati. “Automated Synthesis of Planners and
ware Engineering, 1999, October 1999, pp. Schedulers.” http://www.kestrel.edu/HTML/
275-278. projects/arpa-plan2/index.html.
[7] Kestrel Institute. Specware User Guide, Version [13] Elaine J. Weyuker. “Axiomatizing Software
2.0.3. March 1998. Test Data Adequacy.” IEEE Transactions on
Software Engineering, SE-12(12): 1128-1138,
December 1986.