Larch uses a two-tiered approach to formal speci cations. One tier, the Larch Shared Language (LSL), is ..... 17] John V. Guttag, James J. Horning, and Andres.
Proc. of IEEE Int’l Conf. on Soft. Eng. & Know. Eng., pp. 681-688, June 1993.
An Integrated Development Environment for Formal Speci cations Michael R. Laux, Robert H. Bourdeau, and Betty H. C. Cheng
Department of Computer Science Michigan State University East Lansing, Michigan 48824
Abstract As software is increasingly used to control critical systems, program correctness becomes paramount. A small change in the implementation of software can have a large and perhaps disastrous impact on its behavior. Formal methods focus a software development e ort on an accurate and precise speci cation of what a software system or component is to achieve. This type of speci cation, when expressed in a precise mathematical notation, is referred to as a formal speci cation. Using formal speci cation languages facilitates the early evaluation of a software design and veri cation of its implementation through the use of formal reasoning techniques. Larch uses a two-tiered approach to formal speci cations. One tier, the Larch Shared Language (LSL), is common to all programming languages. This paper describes a development environment that facilitates the construction of LSL speci cations, including a graphical interface to theorem proving and syntax checking tools.
1 Introduction
As software is increasingly used to control critical systems, program correctness becomes paramount [1, 2, 3, 4, 5, 6, 7]. A small change in the implementation of software can have a large and perhaps disastrous impact on its behavior [8]. Formal methods focus a software development e ort on an accurate and precise speci cation of what a software system or component is to achieve. This type of speci cation, when expressed in a precise mathematical notation, is referred to as a formal speci cation. Using formal speci cation languages facilitates the early evaluation of a software design and veri cation of its implementation through the use of formal reasoning techniques [7, 9, 10, 11]. A formal speci cation can be mathematically manipulated to allow the designer to assess the consistency, completeness, and robustness of a design This work is supported in part by NSF Grant CCR-9209873.
before it is implemented. More speci cally, there exist formal methods for systematically developing a program from a speci cation such that the correctness of the resulting program, with respect to its speci cation, is inherent in the development process itself [12, 13, 14, 15]. The Larch family of speci cation languages [16] uses a two-tiered approach to formal speci cations in which one tier, the Larch Interface Language (LIL), speci es program behavior and procedure (function) interfaces for a particular programming language. The second tier, the Larch Shared Language (LSL), is used to specify properties that are independent of a particular programming language. The basic unit of speci cation in LSL is the trait, which axiomatizes theories about functions and data types that are used in programs. A collection of general purpose traits that are designed for constructing application-speci c traits is called a trait handbook [16]. This paper describes a development environment that facilitates the construction of LSL speci cations. The tool, LBE (Larch Browsing Environment ), provides simpli ed access to trait handbooks, editing facilities for traits, graphical interfaces to the LSL syntax checker [16, 17] and the Larch theorem prover (LP) [18], and a graphical rendering of trait hierarchies based on trait inclusion. The Larch/Smalltalk Browser is a speci cation tool for the Larch/Smalltalk interface language [19]. The Larch/Smalltalk Browser groups traits into categories to facilitate browsing, provides capabilities for developing speci cations speci c to the Smalltalk programming language, and can be used only within the Smalltalk environment. In contrast to LBE, the Larch/Smalltalk Browser does not base access to traits on compositional structure, nor does it integrate the LSL syntax checker and theorem prover into a single framework. The remainder of this paper is organized as follows. Section 2 brie y describes the LSL speci cation language. Section 3 describes the features of LBE and illustrates its application through an example speci cation problem. Finally, in Section 4 concluding
remarks are given with a brief discussion of current and future investigations.
2 Formal Speci cations with LSL
In the abstract approach to data speci cation, data are treated as abstract objects, and the semantics of functions operating on data are described by a set of constraints, or axioms. When axioms are given in the form of equations, a speci cation is said to be algebraic [20]. Each abstract data object has a type, called its sort . Associated with each sort is a nite set of operators and constants called the constructors or generators of the sort [21, 22]. The objects of a given sort C are the terms formed from the constructors of C. LSL is an algebraic speci cation language in which modularity is fundamental to its use. Speci cation modularity serves two major purposes: to improve human comprehension of speci cations, and to facilitate the development of sophisticated speci cations from simpler ones. LSL supports modular speci cation by allowing the speci er to group related axioms into a parameterizable module called a trait . The simplest trait is of the form
TraitName : trait introduces signatures asserts axioms where the trait's signature identi es sort names and speci es the syntax of all operators acting on those sorts, and its axioms specify the semantics of the operators. Figure 1 gives a trait that speci es the informal notion of an abstract container ; that is,
a container is an object that stores objects. The signature of this trait describes two operators, new and insert. The notation insert : E, C -> C is the signature of the insert operator and speci es two facts: the correct syntax for the insert operator is of the form insert(x, y), where x and y have sorts E and C, respectively, and the \value" of such an expression is of sort C. The signature of a trait de nes that which constitutes a well-formed expression. For example, the expression insert(insert(x,y),x), where x and y are as above is not well-formed, since the rst argument of the outer insert is of sort C, rather than E, while insert(x,insert(x,y)) and insert(x,new) are well-formed. The Container trait has one axiom, namely C generated by new, insert, which states that the objects of sort C are the terms that can be formed from the operators insert and new; that is, insert and new are the constructors of the sort C. For example, if e1, e2, and e3 are of sort E, then each of new, insert(e1,new), and insert(e1, insert(e2, insert(e3, new)))
Container : trait introduces new : -> C insert : E, C -> C asserts C generated by new, insert
Figure 1: A simple trait. represent containers (objects of sort C). More sophisticated traits are constructed by combining and extending existing traits. This paper illustrates such reuse of traits via the LSL includes statement. The includes statement is an LSL language mechanism for importing traits. If a trait T includes a trait S, then the signature and axioms of S implicitly become a part of the speci cation for T. Consider, for example, the trait given in Figure 2. By including the trait Container, the trait OrderedContainer inherits the operators new and insert as well as the generated by axiom. This trait extends the expressiveness of the container speci cation by adding a test for emptiness (isEmpty), allowing some elements of the container to be observed (via head and tail), and providing a rule for testing the equivalence of two containers (the partitioned by clause). OrderedContainer : trait includes Container introduces isEmpty : C -> Bool head : C -> E tail : C -> C asserts C partitioned by head, tail, isEmpty \forall c : C, e : E isEmpty(new) == true; not(isEmpty(insert(e,c))) == true; head(insert(e,new)) == e; tail(insert(e,new)) == new
Figure 2: A trait that includes a simpler trait. The semantics of the operators in a trait are constrained by equations constructed from well-formed expressions. Equations are expressions of the form expression1 == expression2 where all variables in the given expressions are of a declared sort and are universally quanti ed. The equation ;
head(insert(e,new)) == e
can be loosely interpreted as asserting that, for any object e of sort E, if any container has e as its only element, then e is the head of that container. The equation isEmpty(tail(insert(e,new))) == true
can be deduced from the rst and last equations in the trait OrderedContainer. The partitioned by clause names the operators that can be used to de ne an equality operator (=) for the named sort. For example, in Figure 2, if c1 and c2 are objects of sort C, then c1=c2 if and only if head(c1)=head(c2), tail(c1)=tail(c2) and isEmpty(c1)=isEmpty(c2), where `=' denotes semantic equivalence, and `==' denotes the substitution properties of two terms, where A can be substituted for B when A == B.
3 Environment for LSL Speci cations
This section presents an example that illustrates the application of LBE to trait development but does not necessarily advocate a particular speci cation methodology. The development of traits is viewed as an experimental task [23] in which the speci er discovers an axiomatization of the problem domain that is sucient to formally specify the functional requirements of a software component. During this discovery process, the speci er develops traits, formally determines whether certain conjectures follow from the axioms in the traits, and modi es the traits (or conjectures) accordingly. The development of traits is greatly facilitated by reusing existing traits, typically from a trait handbook. It is signi cantly more bene cial to use formal speci cations to perform such experimentation and investigation to re ne the software requirements, rather than during the implementation of software. The remainder of this section describes the speci cation of a simple, computer-based dictionary. First, an informal description of the dictionary and a starting point of the speci cation process is described. Next, the discussion guides the reader through the use of LBE in the development of this speci cation.
3.1 A Simple Problem
On-line dictionaries can be useful software applications, providing assistance in determining proper spelling and usage of words and phrases, for example. A formal speci cation of the properties of a dictionary facilitates the development of such an application and assists the development of client applications that make use of an on-line dictionary. The following is an informal description of the term dictionary in the context outlined above. Informal Description: A dictionary consists of a collection of words and their corresponding de nitions. A dictionary can be searched to determine the de nition(s) of a given word, checked for containment of a word, and searched for all words with a given pre x. Additionally, new words and their de nitions can be added to the dictionary. An obvious starting point in the formalization of a dictionary is to decide exactly what is meant
Figure 3: The Larch Browser Environment interface. by the terms word and de nition . Asserting that a word is a string of characters is tempting, but unless there is an appropriate axiomatic theory for strings and characters available, the new respective theories would need to be developed before continuing the speci cation process. Existing traits should be consulted to determine whether they provide the needed theories or can be used to construct such theories.
3.2 Trait Browsing and Construction
A trait handbook is a collection of general, axiomatic speci cations for common operator and data type theories. Each trait is stored in a separate le, and the trait les from which a handbook is composed may be stored in one or more directories. Additionally, multiple handbooks may be available for the speci er's use, thereby increasing the number of locations that must be searched for traits. Manually browsing handbooks can be a tedious task that requires switching between directories and trait les until an appropriate trait is found. Figure 3 shows the opening screen of LBE that provides access to several basic facilities that greatly simplify the browsing and construction of traits. The speci er creates new traits by entering text in the editing area shown below the row of buttons; a trait can be loaded into this area by selecting Edit from the File menu and selecting a trait from the Known Traits window. Each user con gures LBE as to which directories are searched in determining the list of accessible traits shown in the Known Traits window. For example, in Figure 4, highlighting the word \String" in the Larch Trait Browser window and selecting the Lookup Selection option displays the String trait in a Trait Reference Window; alternatively, selecting Browse displays the Known Traits list, where \Sequence" can be selected to display the Sequence trait in another Trait Reference Window. As shown in Figure 4, multiple Trait Reference Windows can be displayed concurrently; however, the display area in a Trait Reference Window cannot be edited, unlike the edit area in the Larch Trait Browser.
Figure 4: Example browsing facilities. The hierarchical organization of trait handbooks hides much of the important information needed to make use of a trait for speci cation, such as inherited operators and sorts. Therefore, simply displaying trait les is not sucient for the speci er to determine trait reusability. For example, the String trait shown in Figure 4 inherits a concatenation operator, `||', from the trait Sequence, which in turn inherits this operator from the trait List. To determine all operators of a trait T, all traits referenced directly or indirectly by includes may need to be examined. (A trait S is indirectly referenced by a trait T, if T includes a trait R that includes S, for example). Operators and sorts may be renamed when traits are included by other traits, thus posing another diculty since the speci er may need to remember several levels of operator and sort renamings for complex traits. LBE supports a facility for generating a dependency graph that graphically depicts the entire tree of dependencies for a trait T as determined by the traits that T directly or indirectly includes. This graph, shown in Figure 5, is produced when the user selects the button labeled Dependencies in a Trait Reference Window (Figure 4). The top region of this window displays a node for the current trait and all predecessors of the current trait, and the middle region displays the immediate descendents of the current trait. Trait nodes within these two windows can be selected to either display a trait in a new Trait Reference Window or to choose a new current trait. The bottom region of this window displays the graph generated from the String trait and graphically depicts the complex structure of that trait. The graph's root is always the current trait. It is also possible for the user to directly load a trait displayed in the graph by clicking on the appropriate node. The operators and sorts can be displayed in a separate window by selecting the respective buttons in the Trait Reference Window (see Figure 4). These
Figure 5: The dependency graph for the String trait. buttons invoke the LSL syntax checker in order to extract the sorts and operators, respectively, that comprise the signature of a given trait. Figure 6 shows the output that results from pressing the Operators button for the String trait; each operator of the trait and its signature is displayed, including those that are inherited (the concatenation operator `||', for example). The Sorts and Operators buttons only give the signature information of the trait, but axioms are also inherited by inclusion. The Expand Trait button attens the trait's inclusion hierarchy by removing includes statements and replacing them with the text of the included traits, thus allowing the speci er to view the complete signature and axioms that comprise the trait.
3.3 Continuing the Example Speci cation
Words and de nitions are naturally speci ed as strings, but the constraints on the dictionary require the capability to check words for equality and pre xes. The trait String, shown in Figure 4, contains the operator isPrefix, whose name suggests that it might provide the test for pre xes. Careful examination of the axioms for isPrefix may be sucient to convince the speci er that the semantics of this operator is appropriate; however, it would be of dubious value to assume that intuition is correct. A more rigorous approach would be to formally prove that the needed
must have the sort STRING. This inconsistency is explained in the Type-Check Information window in Figure 7 by the line of text ./DictionaryEntry.lsl:16,21: declared...
Figure 6: The operators that are part of the String trait structure. properties of isPrefix are satis ed by the axioms in the String trait. For example, the lemma Lemma 1: Let w1, w2:STRING. (8 1 2 : STRING )(isPre x ( 1 1jj 2)) characterizes what is meant by the assertion that a string 1 is a pre x of another string 2 ; to be completely thorough, it should be proved that this lemma follows from the axioms of the String trait (the proof may be found in [24]). The properties of the String trait are satisfactory for purposes of this discussion, and as such, words and de nitions are speci ed to be objects of the sort STRING. In the informal speci cation, the concept of a dictionary containing words and de nitions is ambiguous; a more precise interpretation of this concept is that a dictionary consists of a collection of dictionary entries, where a dictionary entry is an ordered pair consisting of the word being de ned and its corresponding de nition. Figure 7 shows the trait DictionaryEntry under construction in the editing window of LBE. The trait String is included to allow the use of the sort STRING to represent words and de nitions. This trait speci es a dictionary entry as an object that has sort ENTRY and is constructed by the operator entry whose rst argument is the word and second argument its de nition. This assertion is speci ed by the expression w ;w
w ;w
w
s
s
ENTRY generated by entry
in the trait. For example, if the word w has de nition d, then the expression entry(w, d) is a dictionary ENTRY object. The operators word and def are provided to extract the corresponding attributes from the entry. At any time, the trait in the edit window can be checked for syntax errors by pressing the button labeled Type-Check Trait, which invokes the LSL checker. Type checking the example in Figure 7 reveals that the equation word(entry(e,df)) == w
is erroneous because the sort for e is ENTRY, but the signature for entry speci es that its rst argument
`entry' not
, which gives the trait le, the location of the error (the row and column number), and a description of the error. A correct equation is word(entry(w,df)) == w. With this correction, the trait DictionaryEntry is syntactically correct and is sucient for the purposes of this discussion. Continuing the speci cation process, the characteristics of the dictionary must be speci ed. A dictionary can now be represented as a collection of ENTRY objects, where the notion of a collection must be clari ed. LBE can be used in the same manner as described previously when reviewing existing traits for possible use in construction of a speci cation for a dictionary. For discussion purposes, it is assumed that after studying the available traits, the user determines that the trait OrderedContainer, shown in Figure 2, is a suitable starting point. OrderedContainer is a speci cation for containers that can be tested for emptiness, and have a speci c rst element; the sort name C is used to represent the type of such containers. This trait does not completely specify the semantics of the two operators head and tail. For example, if c 6= new, there is no constraint on the value of the expression head(insert(e,c)), where e and c are of sorts E and C, respectively, other than that it must have sort E. To specify the semantics of the lookup operation described in the informal description of a dictionary, it is necessary to de ne the properties of these operators for a container. Figure 8 shows the completed trait for the dictionary. The trait DictionaryEntry is included since the speci cation of the dictionary makes use of the sort ENTRY. As described above, the trait OrderedContainer is included to provide a foundation for the speci cation of the dictionary. By renaming the sort E to ENTRY, the theories de ned by the two traits, OrderedContainer and DictionaryEntry, are combined. That is, the included generic container theory is now a theory about containers that store dictionary entries. The trait Set is included to specify the sort DEFSET, a set of de nitions, that is used by the lookup operator as its range. The signature of the Dictionary trait incorporates the signatures of the included traits and also adds three operators, lookup, prefixlookup, and nin, as required in the informal speci cation of dictionary. It is interesting to note that the semantics of these operators are completely speci ed for any instance of a DICTIONARY object, including an empty dictionary, even though the operations head and tail are not. This observation is recorded in the trait by the implies statement. The converts keyword identi es those operators are suciently complete [21], and the exempts keyword identi es cases for operators that are intentionally incomplete (e.g. head and tail).
Dictionary : trait includes DictionaryEntry, OrderedContainer (DICTIONARY for C, ENTRY for E, add for insert), Set (STRING for E, DEFSET for C) introduces lookup prefixlookup __ \in __
Figure 7: Construction and syntax checking of DictionaryEntry
3.4 Semantic Analysis of Traits
The features of LBE that have been discussed thus far address the construction of syntactically correct speci cations; the semantics of the speci cations have not yet been considered formally. That is, even though a trait is syntactically correct, it may contain logically inconsistent constraints or may not be as complete as the speci er intends. To check the semantics of a trait, it should be veri ed that all (and only) desirable properties properties follow formallyfrom the speci cation. The speci er veri es a \property", by stating it formally and constructing its proof. A simple example of such a property and its formal expression was given in Lemma 1 for the isPrefix operator of strings. For the purposes of determining semantic correctness of the Dictionary trait, there are several theorems that the speci er would want to verify. For example, the lookup operator should be speci ed to compute the exact set of de nitions for a given word. That is, every de nition for a given word should be in the result set (a completeness property), and every de nition in the result set should be a de nition of the given word (a soundness property). These two properties can be stated formally as follows: Theorem (Completeness): Let wrd,dfn:STRING and dict:DICTIONARY. entry (wrd dfn ) 2 dict ) dfn 2 lookup (wrd dict ) Theorem (Soundness): Let wrd,dfn:STRING and dict:DICTIONARY. dfn 2 lookup (wrd dict ) ) entry (wrd dfn ) 2 dict In order to conclude that the speci cation for dictionaries is sucient, the speci er should formally prove these two theorems, as well as similar theorems w
w
;
;
;
;
: STRING, DICTIONARY -> DEFSET : STRING, DICTIONARY -> DICTIONARY : ENTRY, DICTIONARY -> Bool
asserts \forall e : ENTRY, w,df : STRING, c, d : DICTIONARY head(add(e,c)) == e; tail(add(e,c)) == c; \not (e \in new); e \in c == (e=head(c)) \or (e \in tail(c)); lookup(w,new) == {}; lookup(w,d) == if w=word(head(d)) then insert(def(head(d)), lookup(w,tail(d))) else lookup(w,tail(d)); prefixlookup(w,new) == new; prefixlookup(w,d) == if isPrefix(w,word(head(d))) then add(head(d), prefixlookup(w,tail(d))) else prefixlookup(w,tail(d)); implies converts __ \in __ : ENTRY, DICTIONARY -> Bool, lookup, prefixlookup exempting head(new), tail(new)
Figure 8: The trait speci cation for DICTIONARY. for the prefixlookup and nin operators. LBE provides the speci er with access to LP [18], the Larch theorem prover, for carrying out such proofs. Traits cannot be loaded directly into LP but must, instead, be transformed into the LP input format, a signi cantly complex and tedious task. Fortunately, the LSL checker provides an LP conversion option. By pressing the Debug Trait button (see Figure 9), the LSL checker is invoked to check the syntactic
correctness of the trait and to transform the trait to LP form. LP is then loaded and initialized with the trait speci cations that were generated by the LSL checker. LP has only a simple text-based interface but, as shown in Figure 9, LBE provides a graphical interface to LP that may facilitate interaction with LP. In Figure 9, LBE has loaded the Dictionary trait, and the user is ready to initiate a proof of the completeness theorem for the lookup operator (given above). The Proof Request Window contains a conjecture speci cation option and a list of proof methods, including parameter settings, from which Induction is selected. The Apply button in the Proof Request Window sends a command to LP to attempt to prove the conjecture given in the window, using the selected proof method. LP is a proof assistant, that is, it does not carry out proofs automatically, but it does have the ability to manage the proof and perform some of the more tedious steps. To use LP e ectively, the user should have a plan for the proof and use LP to actually perform the steps and manipulations rigorously. Details on the use of LP can be found in Garland and Guttag [18]. The user interface currently provided for LP is preliminary. The user literally constructs LP commands, with assistance from the graphical interface, that are supplied as input to LP. The experienced user can also interact with LP directly by entering commands into the text window.
4 Conclusions
The initial reaction to LBE from students using LBE at Michigan State University has been favorable. Most users appreciate the simpli ed access to handbooks provided by LBE and nd that the
integration of the LSL syntax checker into the environment is tremendously helpful. While LP is an extremely important part of the LSL speci cation life cycle, many still nd LP dicult to use. This diculty is probably due, in part, to the lack of experience of the users with interactive theorem provers, and not necessarily to any de ciencies in the theorem prover. There are a wide variety of possible enhancements to LBE that are currently being investigated. Improved trait le management is a concern, and tighter coupling between the error output from the LSL checker and LBE is an important goal. Another type of dependency graph is also planned, which will allow the user to nd all traits that include a given trait. This type of graph corresponds more closely to class browsers that are used in objectoriented programmingenvironments. The LP interface is a very important component that is still in a preliminary stage of development; future investigations will improve the graphical interface between LBE and LP to provide more sophisticated support for proof construction. Finally, LBE will be integrated into a larger framework that supports the application of formal methods to many di erent phases of software development, including reuse [25] and reverse engineering [26].
References
[1] Mary Lu Carnevale. DSC Communications says Modi cation of Software led to Phone Disruptions. The Wall Street Journal, July 1991. [2] Victoria Slid Flor. Ruling's Dicta Causes Uproar. The National Law Journal, July 1991. [3] Mark Moriconi, editor. International Workshop on Formal Methods in Software Development, Napa, California, May 1990. ACM SIGSOFT. [4] Susan L. Gerhart. Applications of formal methods: Developing virtuoso software. IEEE Software, pages 7{10, September 1990. [5] Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929{930, September 1990. [6] P.G. Neumann and Contributors. Risks to the Public. In P.G. Neumann, editor, Software Engineering Notes. ACM Press, July 1991. [7] Jeannette M. Wing. A Speci er's Introduction to Formal Methods. IEEE Computer, 23(9):8{24, September 1990. [8] Bev Littlewood and Lorenzo Strigini. The Risks of Software. Scienti c American, pages 62{75, November 1992. [9] Betty H.C. Cheng. Synthesis of Procedural Abstractions from Formal Speci cations. In Proceedings of COMPSAC'91: Computer Software and Applications Conference, September 1991. [10] Betty H.C. Cheng. Automated Synthesis of Data Abstractions. In Proceedings of Irvine Software Symposium, pages 161{176, University of California, Irvine, June 1991. [11] Robert H. Bourdeau and Betty H.C. Cheng. An object-oriented toolkit for constructing speci cation editors. In Proceedings of COMPSAC'92: Computer Software and Applications Conference, pages 239{244, September 1992. [12] Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli s, New Jersey, 1976. [13] Cli B. Jones. Systematic Software Development Using VDM. Prentice Hall International Series in Computer Science. Prentice Hall International (UK) Ltd., second edition, 1990. [14] D. R. Smith. KIDS: A semiautomatic program development system. IEEE Transactions on Software Engineering, 16(9):1024{1043, September 1990. [15] Betty Hsiao-Chih Cheng. Synthesis of Procedural and Data Abstractions. PhD thesis, University of Illinois at Urbana-Champaign, 1304 West Spring eld, Urbana, Illinois 61801, August 1990. Tech Report UIUCDCS-R-90-1631.
Figure 9: Accessing the LP theorem prover. [16] J.V. Guttag, J. J. Horning, and J. M. Wing. Larch in Five Easy Pieces. Technical report, Digital Equipment Corporation, Systems Research Center, Palo Alto, California, July 1985. [17] John V. Guttag, James J. Horning, and Andres Modet. Report on the Larch Shared Language: Version 2.3. Technical Report 58, Digital Systems Research Center, April 1990. [18] Stephen J. Garland and John V. Guttag. A Guide to LP, The Larch Prover. Technical report, Massachusetts Institute of Technology, 1991. [19] Yoonsik Cheon. Larch/Smalltalk: A Speci cation Language for Smalltalk. Technical report, Iowa State University, Ames, Iowa, 1991. Master's Thesis. [20] J. V. Guttag and J. J. Horning. The Algebraic Speci cation of Abstract Data Types. Acta Informatica, 10:27{52, 1978. [21] Nachum Dershowitz and Jean-Pierre Jouannaud. Rewrite systems. In J. van Leeuwen, editor, Handbook of Theoretical Computer Science, chapter 6. North-Holland, Amsterdam, 1990. In press; available as Rapport 478, LRI,Univ. ParisSud,France.
[22] Barbara Liskov and John Guttag. Abstraction and Speci cation in Program Development. MIT Press and McGraw-Hill, Cambridge, 1986. [23] Manfred Broy. Experiences with Software Speci cation and Veri cation Using LP, the Larch Proof Assistant. Technical Report 93, Digital Systems Research Center, November 1992. [24] Michael R. Laux, Robert H. Bourdeau, and Betty H.C. Cheng. An Integrated Development Environment for Formal Speci cations. Technical Report CPS-93-4, Michigan State University, Department of Computer Science, January 1993. [25] Jun jang Jeng and Betty H.C. Cheng. Using Automated Reasoning to Determine Software Reuse. International Journal of Software Engineering and Knowledge Engineering, 2(4):523{ 546, December 1992. [26] Betty H.C. Cheng and Gerald C. Gannod. Constructing formal speci cations from program code. In Proc. of Third International Conference on Tools in Arti cial Intelligence, pages 125{128, November 1991.
