Spe

i ations from Sour e Code|

Al hemists' Dream or Pra ti al Reality?
M.P. Ward

Computer S ien e Department

S ien e Labs
South Rd
Durham DH1 3LE

Abstra t
We des ribe a method for extra ting high-level spe i ations from unstru tured sour e ode. The method
is based on a theory of program renement and transformation, whi h is used as the bases for the development of a atalogue of powerful semanti s-preserving
transformations. Ea h transformation is an operation on a program whi h has a me hani ally- he kable
orre tness ondition, and whi h has been rigorously
proved to produ e a semanti ally equivalent result. The
transformations are arried out in a wide spe trum
programming language ( alled WSL). This language
in ludes high-level spe i ations as well as low-level
programming onstru ts. As a result, the formal reverse engineering pro ess (from sour e ode to equivalent spe i ations) and the redevelopment pro ess (renement of spe i ations into sour e ode) an both be
arried out within a single language and transformation theory.
We also dis uss a tool (FermaT) whi h has been
developed to support this approa h to reengineering.
The tool is a program transformation system, largely
written in an extension to WSL alled METAWSL.
Thus it is possible to use the tool in the maintenan e
of its own sour e ode, and this is starting to be the
ase.

1 Introdu tion
This paper des ribes the appli ation of formal program transformations to un over spe i ations from
sour e ode. We take as an example a small report
writing program. Due to errors in the original design,
this program had several bugs whi h were gradually
un overed and xed in the usual way (pat hes, rsttime-through swit hes, dupli ated ode et . et .). The
resulting program appears to work, but has a omplex

and messy stru ture whi h makes it extremely di ult

to maintain.
The aim of our ase study is to restru ture the program and extra t its spe i ation (a on ise, high-level
des ription of what the program does whi h ignores
the low-level details of how this result is a hieved). It
should be noted that our aim is emphati ally NOT
that of \Design Re overy" in the sense of \Re overing
the original design"|the original design is full of bugs
and not worth re overing! Instead we aim to transform
the \base metal" of unstru tured ode into the \gold"
of a high-level spe i ation. (Stri tly speaking, this is
really a mining operation, rather than a transmutation
of elements, sin e the \gold" is already there|it just
needs to be extra ted!)
The approa h is based on a \Wide Spe trum
Language" ( alled WSL) whi h in ludes both highlevel abstra t spe i ations and low-level programming onstru ts within the same language. The language has been developed over the last ten years in
parallel with the development of the transformation
theory: the atalogue of proven transformations and
transformation te hniques whi h form the basis for
both renement and reverse engineering. All the
transformations have been proved orre t and have
me hani ally he kable appli ability onditions. This
makes it possible to \en apsulate" the mathemati s
in a transformation system: the user does not need to
understand how to prove the orre tness of a transformation, he or she only needs to be able to read WSL
and know the sorts of operations that an be applied
to it. Sin e ea h step in the reverse engineering pro ess
onsists of the appli ation of a proven transformation,
whose appli ability ondition has been me hani ally
he ked, the extra ted spe i ation is guaranteed to
be a orre t representation of the original program.
Fundamental to our approa h is the use of innitary
rst order logi (see [11) both to express the weakest

pre onditions of programs [6 and to dene assertions

and guards in the kernel language. Engeler [7 was
the rst to use innitary logi to des ribe properties
of programs; Ba k [1 used su h a logi to express the
weakest pre ondition of a program as a logi al formula.
His kernel language was limited to simple iterative
programs. We use a dierent kernel language whi h in ludes re ursion and guards, so that Ba k's language is
a subset of ours. We show that the introdu tion of innitary logi as part of the language (rather than just
the metalanguage of weakest pre onditions), together
with a ombination of proof methods using both denotational semanti s and weakest pre onditions, is a
powerful theoreti al tool whi h allows us to prove some
general transformations and representation theorems.
The denotational semanti s of the kernel language
is based on the semanti s of innitary rst order logi .
Kernel language statements are interpreted as fun tions whi h map an initial state to a set of nal states
(the set of nal states models the nondetermina y in
the language: for a deterministi program this set will
ontain a single state). A program S1 is a renement
of S2 if, for ea h initial state, the set of nal states
for S1 is a subset of the nal states for S2 . Ba k
and von Wright [2 note that the renement relation
an be hara terised using weakest pre onditions in
higher order logi (where quanti ation over formulae is allowed). For any two programs S1 and S2 ,
the program S2 is a renement of S1 if the formula
8R: WP(S1 ; R)
WP(S2 ; R). This approa h to
renement has two problems:

1. It has not been proved that for all programs S and

formulae R, there exists a nite formula WP(S; R)
whi h expresses the weakest pre ondition of S for
post ondition R. Can proof rules justied by an
appeal to WP in nitary logi be justiably applied
to arbitrary programs, for whi h the appropriate
nite WP(S; R) may not exist? This problem does
not o ur with innitary logi , sin e WP(S; R)
has a simple denition for all programs S and all
(innitary logi ) formulae R;
2. Se ond order logi is in omplete in the sense that
not all true statements are provable. So even if the
renement is true, there may not exist a proof of it.
Our approa h to program renement and equivalen e
solves both of these problems. Using innitary logi
allows us to give a simple denition of the weakest
pre ondition of any statement (in luding an arbitrary
loop) for any post ondition. In addition, we have
proved that for ea h pair of statements S1 and S2
there is a single post ondition R su h that S1 is a
renement of S2 i WP(S1 ; R)
WP(S2 ; R) and

WP(S1 ; true) WP(S2 ; true) (see [19). Another advantage is that the innitary logi we use is omplete,
so if there is a renement then there is also guaranteed
to be a proof of the orresponding formula|although
the proof may be innitely long! However, it is
perfe tly pra ti al to onstru t innitely long proofs:
in fa t the proofs of many transformations involving
re ursion or iteration are innite proofs onstru ted by
indu tion. Thus innitary logi is both ne essary and
su ient for proving renements and transformations.
We onsider the following riteria to be important
for any pra ti al wide-spe trum language and transformation theory:
1. General spe i ations in any \su iently pre ise"
notation should be in luded in the language. For
su iently pre ise we will mean anything whi h an
be expressed in terms of mathemati al logi with
suitable notation. This will allow a wide range
of forms of spe i ation, for example Z spe i ations [8 and VDM [10 both use the language
of mathemati al logi and set theory (in dierent
notations) to dene spe i ations. The \Representation Theorem" [19 proves that our spe i ation
statement is su ient to spe ify any WSL program
(and therefore any omputable fun tion, sin e WSL
is ertainly Turing omplete);
2. Nondeterministi programs. Sin e we do not want
to have to spe ify everything about the program
we are working with ( ertainly not in the rst
versions) we need some way of spe ifying that some
exe utions will not ne essarily result in a parti ular
out ome but one of an allowed range of out omes.
The implementor an then use this latitude to
provide a more e ient implementation whi h still
satises the spe i ation;
3. A well-developed atalogue of proven transformations whi h do not require the user to dis harge
omplex proof obligations before they an be applied. In parti ular, it should be possible to introdu e, analyse and reason about imperative and
re ursive onstru ts without requiring loop invariants;
4. Te hniques to bridge the \abstra tion gap" between
spe i ations and programs. See [23,30 for examples;
5. Appli able to real programs|not just those in a
\toy" programming language with few onstru ts.
This is a hieved by the (programming) language
independen e and extendibility of the notation via
\denitional transformations". See [15,17,24 for
examples;

6. S alable to large programs: this implies a language

whi h is expressive enough to allow automati
translation from existing programming languages,
together with the ability to ope with unstru tured
programs and a high degree of omplexity. See [25
for example.
A system whi h meets all these requirements would
have immense pra ti al importan e in the following
areas:
 Improving the maintainability (and hen e extending the lifetime) of existing mission- riti al software
systems;
 Translating programs to modern programming languages, for example from obsolete Assembler languages to modern high-level languages;
 Developing and maintaining safety- riti al appli ations. Su h systems an be developed by transforming high-level spe i ations down to e ient
low level ode with a very high degree of onden e
that the ode orre tly implements every part of the
spe i ation. When enhan ements or modi ations
are required, these an be arried out on the appropriate spe i ation, followed by \re-running" as
mu h of the formal development as possible. Alternatively, the hanges ould be made at a lower level,
with formal inverse engineering used to determine
the impa t on the formal spe i ation;
 Extra ting reusable omponents from urrent systems, deriving their spe i ations and storing
the spe i ation, implementation and development
strategy in a repository for subsequent reuse. The
use of the join onstru t as an indexing me hanism
is dis ussed in [22.

2 The Example Program

Our example program was sele ted to illustrate
how design errors and poor design, leads to a buggy
program with a poor stru ture. Fixing the bugs
in the usual way (pat hes, \ha ks", \programming
tri ks" et .) further degrades the stru ture until the
program be omes extremely di ult to understand,
despite its short length. We aim to demonstrate the results a hievable by applying program transformations,
based on formal logi , to su h unpromising material.
The program is a simple report printer whi h prints
a management report showing the net hanges of sto k
items in a warehouse. It reads a sorted transa tion le,
onsisting of a list of re ords, ea h of whi h ontains
the name of the sto k item, and the amount brought in
or taken out of the warehouse. Re eipts are denoted by
positive numbers and dispat hes by negative numbers.

The program should print the name and net hange

for ea h item whi h has experien ed a net hange in
sto k, and also note the number of items whose sto k
levels have hanged.
The ( tional) history of this program, from the
initial impressive-looking ve-level hierar hi al fun tional de omposition, through four \qui k xes" in luding a rst-time-through swit h, a pat h on top of
a pat h, and an example of \defensive programming"
(set the swit h twi e in a row, just to be sure it is
really set) is eloquently des ribed in [3, so we will
only present the nal version:
pro Management Report 
var SW1 := 0; SW2 := 0 :
Produ e Heading;
read(stu );
while NOT eof (stu ) do
if First Re ord In Group
then if SW1 = 1
then Pro ess End Of Prev Group
;
SW1 := 1;
Pro ess Start Of New Group;
Pro ess Re ord;
SW2 := 1
else
Pro ess Re ord; SW2 := 1
;
read(stu )
od;
if SW2 = 1 then Pro ess End Of Last Group
;
Produ e Summary
end.
Although this program is quite small, it is extremely
di ult to follow the logi and onvin e yourself that
it is orre t. In the next se tion we introdu e our
approa h to this sort of problem, whi h is based on
Inverse Engineering.

3 Program Renement
and Transformation
The WSL language in ludes both spe i ation onstru ts, su h as the general assignment, and programming onstru ts. One aim of our program transformation work is to develop programs by rening a
spe i ation, expressed in rst order logi and set
theory, into an e ient algorithm. This is similar to
the \renement al ulus" approa h of Morgan et al
[9,12; however, our wide spe trum language has been
extended to in lude general a tion systems and loops

with multiple exits. These extensions are essential for

our se ond, and equally important aim, whi h is to use
program transformations for reverse engineering from
programs to spe i ations.
Renement is dened in terms of the denotational
semanti s of the language: the semanti s of a program
S is a fun tion whi h maps from an initial state to a
nal set of states. The set of nal states represents all
the possible output states of the program for the given
input state. Using a set of states enables us to model
nondeterministi programs and partially dened (or
in omplete) spe i ations. For programs S1 and S2
we say S1 is rened by S2 (or S2 is a renement
of S1 ), and write S1  S2 , if S2 is more dened
and more deterministi than S1 . If S1  S2 and
S2  S1 then we say S1 is equivalent to S2 and
write S1  S2 . Equivalen e is thus dened in terms
of the external \bla k box" behaviour of the program.
A transformation is an operation whi h maps any
program satisfying the appli ability onditions of the
transformation to an equivalent program. See [14
and [16 for a des ription of the semanti s of WSL
and the methods used for proving the orre tness of
renements and transformations. We use the term
abstra tion to denote the opposite of renement: for
example the \most abstra t" program is the nonterminating program abort, sin e any program is a
renement of abort.
A transformation is an operation whi h maps any
program satisfying the appli ability onditions of the
transformation to an equivalent program. See [14
and [16 for a des ription of the semanti s of WSL
and the methods used for proving the orre tness of
renements and transformations.

4 Inverse Engineering
Inverse engineering is the pro ess of extra ting
high-level abstra t spe i ations from sour e ode using program transformations. By developing our program transformation theory in a wide spe trum language, we are able to use transformations not only for
restru turing at the same abstra tion level, but also
for rossing levels of abstra tion: transforming from
low-level ode to high-level abstra t spe i ations (see
[23). Be ause the transformations are proved to be
orre t, they an be applied without needing to understand the program rst, and with a very high degree
of onden e that the resulting spe i ations orre tly
represent the initial program. Similar transformations
an be used to rene the spe i ations (either immediately or after modi ations and enhan ements) ba k
to exe utable sour e ode, whi h may be in a dierent

programming language. It is therefore possible to use

this method to migrate ode between programming
languages: in luding migrating from Assembler ode
to a high-level language (see [25). The renement
of extra ted spe i ations ba k to exe utable ode
an be made largely automati , and this means it
is possible to maintain the spe i ations rather than
the sour e ode. Changes and enhan ements an be
applied at the right level of abstra tion, without diving
into details of the implementation.

5 FermaT: A tool for

Inverse Engineering
FermaT is a program transformation system based
on the theory of program renement and equivalen e
developed in [14,19 and applied to software development in [13,24 and to reverse engineering in [23,25.
The transformation system is intended as a pra ti al
tool for software maintenan e, program omprehension, reverse engineering and program development.
The rst prototype transformation system, alled
the \Maintainer's Assistant", was written in LISP [5,
28. It in luded a large number of transformations,
but was vey mu h an \a ademi prototype" whose aim
was to test the ideas rather than be a pra ti al tool.
In parti ular, little attention was paid to the time and
spa e e ien y of the implementation. Despite these
drawba ks, the tool proved to be highly su essful
and apable of reverse-engineering moderately sized
assembler modules (up to 80,000 lines) into equivalent
high-level language programs.
The system is based on semanti preserving transformations in a wide spe trum language ( alled WSL).
The language in ludes both low-level programming
onstru ts and high-level non-exe utable spe i ations. This means that renement from a spe i ation to an implementation, and reverse-engineering to
determine the behaviour of an existing program an
both be arried out by means of semanti -preserving
transformations within a single language.
For the next version of the tool (i.e. FermaT itself)
we de ided to extend WSL to add domain-spe i
onstru ts, reating a language for writing program
transformations. This was alled METAWSL. The
extensions in lude an abstra t data type for representing programs as tree stru tures and onstru ts for
pattern mat hing, pattern lling and iterating over
omponents of a program stru ture. The \transformation engine" of FermaT is implemented entirely
in METAWSL. The implementation of METAWSL involves a parser for METAWSL (written in rdp, a
publi domain re ursive des ent parser pa kage), an

interpreter for METAWSL written in C, a translator

from METAWSL to C (written in METAWSL and interpreted to translate itself), a small C runtime library
(for the main abstra t data types) and a WSL runtime
library (for the high-level METAWSL onstru ts su h
as ifmat h, forea h, ll et .). One aim was so that the
tool ould be used to maintain its own sour e ode:
and this has already proved possible, with transformations being applied to simplify the sour e ode for
other transformations! Another aim was to test our
theories on language oriented programming (see [18):
we expe ted to see a redu tion in the total amount
of sour e ode required to implement a more e ient,
more powerful and more rugged system. We also anti ipated noti eable improvements in maintainability and
portability. These expe tations have been fullled,
and we are a hieving a high degree of fun tionality
from a small total amount of easily maintainable ode:
the urrent prototype onsists of around 16,000 lines
of METAWSL and C ode, while the previous version
required over 100,000 lines of LISP.
The FermaT design is based on a re ursive appli ation of language oriented programming, involving two
\layers" of domain-spe i languages. These are:
1. A fairly high-level, general purpose language, based
on the exe utable onstru ts of WSL [14,19 together with an abstra t data type (ADT) for re ording, analysing and manipulating programs and fragments of programs. This is implemented in LISP,
using a WSL to LISP translator together with a
\LISP runtime library" of fun tions and pro edures
to implement the ADT. The ADT in ludes fa ilities
for loading and saving programs, moving around (it
re ords the \ urrent sele tion" within the urrent
program), and editing operations. This onsists
of less than 2000 lines of LISP: the entire rest of
the transformation engine is written in WSL and
METAWSL ode. Hen e porting the system to another language (and a C version is urrently under
development) would entail writing at the most a
few thousand lines of ode;
2. On top of the \base" WSL language we have implemented a very high-level, domain-spe i language for writing program transformations, alled
METAWSL. This in ludes high level onstru ts
whi h do most of the work involved in writing transformations: see below for an example. METAWSL
is implemented almost entirely in WSL; there are a
few extensions to the WSL to LISP translator and
a number of WSL libraries whi h are ompiled into
LISP and linked to the translated METAWSL.

METAWSL en apsulates mu h of the expertise developed over the last 10 years of resear h in program
transformation theory and transformation systems.
As a result, this expertise is readily available to the
programmers, some of whom have only re ently joined
the proje t. Working in METAWSL, it takes only
a small amount of training before new programmers
be ome ee tive at implementing transformations and
enhan ing the fun tionality of existing transformations.

6 Inverse Engineering
the Example Program
In this se tion we show how FermaT opes with the
example program of Se tion 2. The rst three stages
were arried out on a prototype of FermaT, starting with the original program and applying generalpurpose transformations. The nal stage (going to
an abstra t spe i ation) was arried out manually
be ause the ne essary transformations are still being
implemented in the tool.

6.1 First Stage:

Restru ture and Simplify
The rst stage involves applying some generalpurpose restru turing and simpli ation transformations. The sele tion of the transformations by the
user is based on some simple heuristi s, developed
from our experien e of using the tool. It is likely
that these heuristi s ould be largely automated in
the future: in fa t it is a feature of the development
of the various prototypes whi h led up to FermaT
that experien e with ea h version enabled us to eli it
more knowledge about the pro ess of restru turing and
reverse engineering through formal transformations.
This knowledge was then in orporated in the next
version of the tool, in the form of more powerful
transformations and program manipulation fun tions.
In the rst stage we are able to remove both
swit hes and re-express the onvoluted ontrol ow
as a simple double-nested loop. It is an important
feature of our method that the user of the system
does not need to understand the purpose of a blo k
of ode before transforming it. The system takes
are of all orre tness onditions and leri al details of
applying the transformation, as well as automati ally
pretty-printing the result. The system and supporting theoreti al work together guarantee the semanti
equivalen e of ea h version of the program: thus, on e
an understandable version has been produ ed, the
user an understand that version of the program, and

be ondent that the original program has the same

semanti s.
pro Management Report 
Produ e Heading;
read(stu );
while NOT eof (stu ) do
Pro ess Start Of New Group;
do Pro ess Re ord;
read(stu );
if eof (stu ) OR First Re ord In Group
then exit

od;
Pro ess End Of Prev Group
od;
Produ e Summary.

6.2 Se ond Stage:

Abstra t Data Types
The se ond stage, after restru turing, is to examine
the low-level pro edures and data stru tures and reexpress them at a higher level of abstra tion, making
use of abstra t data types where appropriate. This
step an also be arried out via formal transformations: some human input is required in sele ting the
abstra t equivalents, though the simpler ases (sta ks,
sequential and random a ess les et .) an be automated. The next version of the program repla es
ea h pro edure all with the abstra t spe i ation of
the pro edure body. This version is therefore more
omplete than the previous one (the \missing" ode
in the pro edure bodies is now in luded):
pro Management Report 
var i := 0; last := \"; re ord := \"; hanged := 0 :
write(\Management Report : : : ");
last := re ord; i := i + 1; re ord := re ords[i;
while i 6 `(re ords) do
total := 0;
do total := total + re ord:number;
last := re ord;
i := i + 1; re ord := re ords[i;
if i > `(re ords) OR
last:name 6= re ord:name
then exit

od;
if total 6= 0
then write(last:name; total);
hanged := hanged + 1


od;
write(\Changed items:"; hanged);
end.

6.3 Third Stage:

Restru ture and Simplify
Having moved to a higher level of abstra tion, some
further simpli ation and restru turing be omes possible. We an get rid of another lo al variable, and
onvert both loops to while loops. This version is at a
intermediate level of abstra tion, it uses a higher level
data stru ture than the original sour e ode, but still
arries out roughly the same operations.
pro Management Report 
var i := 0; hanged := 0 :
write(\Management Report : : : ");
while i 6 `(re ords) do
total := re ords[i:number;
i := i + 1;
while i 6 `(re ords) AND
re ords[i - 1:name = re ords[i:name do
total := total + re ords[i:number;
i := i + 1

od;
if total 6= 0
then write(re ords[i - 1:name; total);
hanged := hanged + 1

od;
write(\Changed items:"; hanged);
end.

6.4 Fourth Stage:

Spe i ation Level
For the nal step, we repla e the loops by higherlevel operators whi h des ribe the ee t of the double
loop more learly. Our notation for list operations is
based on [4.  is a \map" operator whi h takes a
unary fun tion and applies it to ea h element of a list.
= is a \redu e" operator whi h takes a binary fun tion
and applies it to a list, for example +=l returns the
sum of the elements of list l. The split fun tion takes
a list and a binary ondition and returns a list of lists,
formed by splitting the original list into non-empty
se tions at the points where the ondition is false.
pro Management Report 
begin
var q := split(re ords; same name?) :
q := summarise  q;
q := lter(q; hange?);
write(\Management Report : : : ");

write  q;
write(\Changed items:"; `(q))
end
where
fun t same name?(x; y) 
x:name = y:name.
fun t summarise(g) 
hg[1:name; +=(:number  g)i.
fun t hange?(g) 
g[2 6= 0.

end
Our spe i ation may therefore be written informally
as follows:
1. First split the list of re ords into se tions, where
the re ords in ea h se tion all have the same name;
2. Then summarise ea h se tion to produ e a list of
summary pairs. The summarise fun tion returns a
pair onsisting of the name ( ommon to all re ords
in the se tion) and the sum of all the number
omponents of the re ords;
3. Then lter out the summaries with zero totals
(these should not appear on the report);
4. The print a report onsisting of a header, the list
of summaries (one per line) and the number of
summaries listed.
This spe i ation illustrates very learly the relationship between the input data and the nal report. It
also shows expli itly that the \Changed items" number is pre isely the number of summaries listed, whi h
in turn is the number of items whose sto k has hanged
sin e the last report. This fa t would require a areful
analysis of the program plus some indu tive reasoning
if it was to be dedu ed from the original version of the
program.

7 Con lusions
Our approa h to reengineering, based on inverse
engineering followed by formal renement, has proved
very su essful with a number of hallenging smalls ale ase study programs [13,20,21,23,24. The theoreti al work has been developed further to a ommodate real time and parallel programs with some
su ess [29,30. More re ently, the development of
industrial-strength tool support has allowed us to
ta kle large JOVIAL restru turing proje ts, IBM 370
Assembler restru turing proje ts for modules of up
to 20,000 lines, and Assembler to COBOL migration
proje ts [26,27. Durham Software Engineering Ltd
and Durham University are a tively developing the
tool with translators to and from various languages

(in luding C and COBOL) whi h will extend the migration and reengineering apabilities of the tool. For
the Assembler restru turing and migration proje ts we
have developed te hniques for uns rambling the (often
onvoluted) ontrol ow between subroutines: this has
to ope with subroutines whi h overwrite or modify
the stored return address, routines whi h all other
subroutines dire tly (without storing a return address)
and so on. In addition, we have developed te hniques
for hanging the data model from a monolithi blo k
of memory, a essed via pointers (whi h is essentially
how assembler ode treats its data) to the equivalent
high-level data stru tures and operations.

Referen es
[1 R. J. R. Ba k, Corre tness Preserving Program Renements , Mathemati al Centre Tra ts #131, Mathematis h Centrum, Amsterdam, 1980.
[2 R. J. R. Ba k & J. von Wright, \Renement Con epts
Formalised in Higher-Order Logi ," Formal Aspe ts of
Computing 2 (1990), 247{272.
[3 G. D. Bergland, \A Guided Tour of Program Design
Methodologies," Computer 14, 18{37.
[4 R. Bird, \Le tures on Constru tive Fun tional Programming," Oxford University, Te hni al Monograph
PRG-69, Sept., 1988.
[5 T. Bull, \An Introdu tion to the WSL Program Transformer," Conferen e on Software Maintenan e 26th{
29th November 1990, San Diego (Nov., 1990).
[6 E. W. Dijkstra, A Dis ipline of Programming , Prenti e-Hall, Englewood Clis, NJ, 1976.
[7 E. Engeler, Formal Languages: Automata and Stru tures , Markham, Chi ago, 1968.
[8 I. J. Hayes, Spe i ation Case Studies , Prenti e-Hall,
Englewood Clis, NJ, 1987.
[9 C. A. R. Hoare, I. J. Hayes, H. E. Jifeng, C. C. Morgan, A. W. Ros oe, J. W. Sanders, I. H. Srensen, J.
M. Spivey & B. A. Sufrin, \Laws of Programming,"
Comm. ACM 30 (Aug., 1987), 672{686.
[10 C. B. Jones, Systemati Software Development using
VDM , Prenti e-Hall, Englewood Clis, NJ, 1986.
[11 C. R. Karp, Languages with Expressions of Innite
Length, North-Holland, Amsterdam, 1964.
[12 C. C. Morgan, Programming from Spe i ations , Prenti e-Hall, Englewood Clis, NJ, 1994, Se ond Edition.
[13 H. A. Priestley & M. Ward, \A Multipurpose Ba ktra king Algorithm," J. Symb. Comput. 18 (1994), 1{
40, hhttp: // www. dur. a . uk/ d s0mpw/ martin/
papers/ ba ktr-t.ps.gzi.
[14 M. Ward, \Proving Program Renements and Transformations," Oxford University, DPhil Thesis, 1989.
[15 M. Ward, \Derivation of a Sorting Algorithm,"
Durham University, Te hni al Report, 1990, hhttp:
// www. dur. a . uk/ d s0mpw/ martin/ papers/
sorting-t.ps.gzi.

[16 M. Ward, \Spe i ations and Programs in a Wide

Spe trum Language," Submitted to J. Asso . Comput.
Ma h., 1991.
[17 M. Ward, \A Re ursion Removal Theorem," SpringerVerlag, Pro eedings of the 5th Renement Workshop,
London, 8th{11th January, New York{Heidelberg{
Berlin, 1992, hhttp: // www. dur. a . uk/ d s0mpw/
martin/ papers/ ref-ws-5.ps.gzi.
[18 M. Ward, \Language Oriented Programming,"
Software|Con epts and Tools 15 (1994), 147{161,
hhttp://www.dur.a .uk/ d s0mpw/ martin/ papers/
middle-out-t.ps.gzi.
[19 M. Ward, \Foundations for a Pra ti al Theory of
Program Renement and Transformation," Durham
University, Te hni al Report, 1994.
[20 M. Ward, \Reverse Engineering through Formal Transformation Knuths \Polynomial Addition" Algorithm,"
Comput. J. 37 (1994), 795{813, hhttp://www.dur.a .
uk/ d s0mpw/ martin/ papers/ poly-t.ps.gzi.
[21 M. Ward, \Program Analysis by Formal Transformation," Comput. J. 39 (1996).
[22 M. Ward, \Using Formal Transformations to Constru t a Component Repository," in Software Reuse:
the European Approa h, Springer-Verlag, New York{
Heidelberg{Berlin, Feb., 1991, hhttp: // www. dur. a .
uk/ d s0mpw/ martin/ papers/ reuse.ps.gzi.
[23 M. Ward, \Abstra ting a Spe i ation from Code," J.
Software Maintenan e: Resear h and Pra ti e 5 (June,
1993), 101{122, hhttp: // www. dur. a . uk/ d s0mpw/
martin/ papers/ prog-spe .ps.gzi.

[24 M. Ward, \Derivation of Data Intensive Algorithms by

Formal Transformation," IEEE Trans. Software Eng.
22 (Sept., 1996), 665{686, hhttp: // www. dur. a . uk/
d s0mpw/ martin/ papers/ sw-alg.ps.gzi.
[25 M. Ward & K. H. Bennett, \A Pra ti al Program
Transformation System For Reverse Engineering,"
Working Conferen e on Reverse Engineering, May 21{
23, 1993 , Baltimore MA (1993), hhttp://www.dur.a .
uk/ d s0mpw/ martin/ papers/ i se.ps.gzi.

[26 M. Ward & K. H. Bennett, \Formal Methods to Aid the

Evolution of Software," International Journal of Software Engineering and Knowledge Engineering 5 (1995),
25{47, hhttp: // www. dur. a . uk/ d s0mpw/ martin/
papers/ evolution-t.ps.gzi.
[27 M. Ward & K. H. Bennett, \Formal Methods
for Lega y Systems," J. Software Maintenan e: Resear h and Pra ti e 7 (May, 1995), 203{219, hhttp:
// www. dur. a . uk/ d s0mpw/ martin/ papers/
lega y-t.ps.gzi.
[28 M. Ward, F. W. Calliss & M. Munro, \The Maintainer's Assistant," Conferen e on Software Maintenan e 16th{19th O tober 1989, Miami Florida (1989),
hhttp://www.dur.a .uk/ d s0mpw/ martin/ papers/
MA-89.ps.gzi.
[29 E. J. Younger & M. Ward, \Understanding Con urrent
Programs using Program Transformations," Pro eedings of the 1993 2nd Workshop on Program Comprehension, 8th-9th July , Capri, Italy (1993), hhttp:
// www. dur. a . uk/ d s0mpw/ martin/ papers/

ap.ps.gzi.
[30 E. J. Younger & M. Ward, \Inverse Engineering a
simple Real Time program," J. Software Maintenan e:
Resear h and Pra ti e 6 (1993), 197{234.

Sour e

Translator

File

Transformation
Library

Internal
Representation
of WSL ode

Stru ture
Editor

Program
Transformer
Sele t

Edit

View

The
Maintainer

ASCII
X-Windows
Front End

Browser
Interfa e

Blo k Diagram of the FermaT tool.

High-Level
WSL to
Z

Low-Level
WSL to
Sour e