An Object-Oriented Toolkit for Constructing Speci ... - Semantic Scholar

Proc. of IEEE Comp. Soft. & Applications Conf. (COMPSAC), pp. 149-154, Sept. 1991

An Object-Oriented Toolkit for Constructing Speci cation Editorsy Robert H. Bourdeau and Betty H.C. Cheng

z

Department of Computer Science Michigan State University A714 Wells Hall East Lansing, Michigan 48824 ph: (517) 355-8344; fax: (517) 336-1061 email: fbourd,[email protected]

Abstract

of such a language. The following is a simple speci cation for a function called Max that returns the largest of its two arguments:

Formal software development techniques facilitate the design and implementation of more reliable computer systems, which is particularly important for the development of safety-critical systems. In particular, formal speci cation languages provide a means for precisely characterizing the behavior of a computer system and its components, and facilitates the determination of correct implementation using automated reasoning techniques. While formal speci cations can be created using a word processor or typesetter, the process is neither easy nor suitable for large scale software speci cation. Tools supporting the application of formal methods are needed to make these activities easier, and thus more practical to use. This paper discusses Spectacle, an object-oriented library of software components designed for constructing formal speci cation editing tools; prototype speci cation editors built from this library are presented.

precondition: statement:

postcondition:

fInteger(x) ^ Integer(y)g f((x  y) ^ (res = x)) _ ((x < y) ^ (res = y))g

res:= Max(x,y)

The precondition states what must be true before executing the statement, speci cally that both x and y must be integer values; the postcondition states what will be true after executing the statement, namely, that res is equal to the larger of the two values x and y. There are two methods in which a speci cation can be used, program veri cation and program development ; both of these applications involve the manipulation of the speci cation according to a set of inference rules, the formal reasoning procedure. In the speci cation example above, one might look at the actual implementation of the function Max, consider the semantics of each instruction used to implement the function, and verify that the postcondition is indeed a consequence of these semantics when given the assumptions of the precondition. A more interesting property of such a speci cation is as a goal for program development [11, 17]. If the statement portion had not yet been determined but pre- and postconditions were known, it is sometimes possible to mechanically \compute" the statement needed to satisfy the speci cation; this development process is known as program synthesis [8, 7, 18, 19]. It is easy to understand that the use of formal methods is largely a problem of manipulating formal speci cations. In order to make software development environments that incorporate the use of formal speci cations more complete and user-friendly, they should provide a subsystem for the acquisition of the speci cations, that is, provide an editing subsystem. Since many special characters like `^' and `9' are often used in speci cation languages [9, 12, 20], it is desirable to allow the input of such characters directly , that is, without typesetting or contrived substitutions such as `n/' and `Exists,' respectively. Typesetting languages such as TEX and LaTEX [21] are

1 Introduction

The number of applications to which the reliability of software is critical continues to increase [1, 2]. Software errors have been the cause of a wide variety of problems from telephone network failures [3, 4, 5] to aircraft disasters [6]. Many rigorous mathematical techniques are being developed to determine software correctness [7, 8, 9, 10, 11, 12]; these techniques are collectively referred to as formal methods [13, 14, 15, 16]. A formal method is typically characterized by a speci cation language and a formal reasoning procedure [13]. A speci cation language is a formal language that is used to describe the behavior of a program; predicate logic is one of the simplest examples  This work is supported in part by National Science Foundation grant, CCR-9209873. y A preliminary version of this paper appeared in the Proc. of IEEE 16th Annual International Computer Software and Applications Conference, September 1992. z Please address all correspondences to this author.

1

structure of the library and examines each software component separately; the user-interface model provided by Spectacle is also described. Two example prototype editors are presented in Section 3. Section 4 gives concluding remarks and presents potential enhancements to the library for future investigations. 2 Structure of Spectacle Spectacle is a small, C++ class library from which an editing tool is constructed by inheritance from two classes, Specification and Formatter, where a class is an abstract data type, and inheritance is a technique for reusing existing software modules to construct new classes [24]. The class Specification supplies a set of routines for de ning the basic userinterface of an editor including the identi cation of the speci cation languages involved and the physical layout of the editing tool. A Spectacle editor is an object whose type has been derived from the class Specification, where an object is a datum whose type is some class, and a derived class is a class that has been created by inheritance from one or more classes.5 The Formatter class provides the programmer with facilities to implement a custom text-formatting algorithm for each speci cation language supported by the editor. For expressions that exceed the width of the display window, text-formatting is necessary in order for the entire expression to be visible at all times. In the remainder of this section, the design issues that were important to the development of this project are presented and the classes of the Spectacle library are then examined individually, exploring their contribution to the library as a whole.

non-graphical languages1 that can be used to describe mathematical formulae, and non-graphical speci cation languages similar to that used by Gries [17] can also be used. Consider the following equivalent assertions for mapping a function f from a set D onto a setDesired: R: (8y )(y 2 R ) (9x)(x 2 D ^ f (x) = y )) TEX:

Gries-like:

(nforall y)(y nin R nRightarrow ( nexists x)(x nin D nwedge f(x)=y)) (All y : y in R : (Exists x : x in D : f(x) = y))

The latter two assertions are non-graphical equivalents of the rst. All unambiguously express the same statement, but the rst statement might be preferable due to our intuitive understanding of the symbols. A conventional text editor, typically not graphics-based (e.g. vi2 and GNU Emacs3), can be used to create the latter two formulae while a specialized editor would be needed to create the rst formula directly. In order to provide the user with an editor that can be used to directly manipulate an expression of the rst sort and integrated into other application frameworks, we developed the Spectacle library. This paper discusses Spectacle, an object-oriented library of software components designed for constructing languagebased, graphical, speci cation editors. Spectacle provides the programmer with a basic toolkit for building an X-Window [22] editor; minimal knowledge of both C++ and X-Window is assumed. The editing tools that are derived from Spectacle can be implemented as stand-alone editors or integrated into larger-scale software development environments. While Spectacle is intended to be used in conjunction with formal speci cation languages, it is exible enough to provide the framework to develop editors for any context-free, text-based4 formal language. In addition, Spectacle editors are syntaxdirected and menu driven. The Synthesizer Generator (SG) developed by Reps [23] is a system used to create language-based environments for program development, speci cally editors. SG editors can support simple text-based languages that do not make use of unusual mathematical symbols. The user of SG is able to build an editor based on a user-supplied grammar, but the editor generated is a stand-alone tool whose interface is predetermined by the SG itself. In contrast, one of the fundamental design issues of Spectacle was speci cally to handle special symbols. Also, Spectacle provides facilities for the developer to customize the interface and to control the editing tool from another application. The object-oriented architecture of Spectacle allows the library to be extended to incorporate future enhancements, thus adding greater functionality to its editors. The remainder of this paper discusses Spectacle from several aspects. Section 2 outlines the basic

2.1

Design Issues

2.2

The Classes and Their Interrelationships

Because we have many projects, involving formal methods, that require the construction and manipulation of formal speci cations [26, 27, 28, 29, 30, 31, 32], we need a variety of speci cation editors that can be embedded into systems or act as stand-alone systems. As a result, we designed the Spectacle library, whose components will be used to build editors, to be independent of a particular speci cation language, reusable in a variety of application environments, and extensible. In addition to the above requirements, we wanted the editors to have features that would enforce a correct syntactic construction of speci cations and allow aspects of the user-interface of the tool to be easily tailorable to meet the user's needs.

The structure of the complete Spectacle library is shown in Figure 1; several types of relationships among the classes are identi ed, where inheritance and containment are the most important. (An object A contains an object B if the implementation of A uses the object B.) A closer examination of these classes

1 Non-graphical in this context refers to the T X and LaT X E E languages themselves, not the documents generated by these typesetters. 2 `vi' is a product of AT&T. 3 GNU Emacs is a product of the Free Software Foundation. 4 Here the term text-based means \organized into rows of characters."

5 The terms `derived from' and `inherits' are the same, conceptually [25].

2

2.2.2 The Display and Construction of Expressions

is provided in the remainder of this section. For clarity purposes, we have grouped the class descriptions according to those that manage the grammar, display and construct expressions, build editors, and manage X-Window events. Token

ParseTreeNode Formatter

Rule GrammarBase Grammar

The construction of the various parts of a speci cation proceeds as an incremental top-down parse, beginning with the start symbol of a grammar. As the user builds a formula, the text items displayed on the editing surfaces of the speci cation tool appear to be manipulated directly; while this is theoretically correct at an abstract level, in actuality, the user is manipulating a parse tree that contains the selected portion of the speci cation, and only the leaf nodes of the parse tree are displayed. The construction and display of a formula is a process that involves several classes: ParseTree, ParseTreeNode, BoundingBox, Mapping, and Formatter. The ParseTree class stores the currently visible expression in its leaf nodes; the grammar rules used to create the current expression are represented implicitly in the arrangement of its internal nodes. Figure 2 shows a parse tree for the expression m = p  q+r. By scanning the leaf nodes from the left to the right, we are able to determine the expression immediately; furthermore, by looking at the root of the parse tree, we know that the nonterminal symbol Boolean was the start symbol used and that a rule of the form hBooleani ::= hValuei = hValuei was the rst production rule applied in the construction of this expression. Every node in this gure (such as Value ) is stored in a ParseTreeNode object; this class is the unit of storage used by the ParseTree class.

BoundingBox

YourFormatter

XIM

ParseTree Mapping

SpecificationComponent Legend

Specification YourEditingTool

a pseudo-class

A A A italics

B B B

A is derived from B A contains B types A uses services of B but neither contains nor is derived from B code written by toolmaker

Application

Figure 1: : Relationships between the classes

Spectacle

2.2.1 The Grammar Management Components

Several speci cation languages may be used by a single editing tool, each one determined by a grammar le. A grammar le is parsed, converted to an internal representation, and managed by the classes GrammarBase, Grammar, Rule, and Token. The GrammarBase class provides a small set of services for translating the names of special symbols such as nexists to the correct symbol font character (9 in this case). This translation depends on the font le used for the mathematical symbol graphics; as available font les can vary for dierent installations of X-Window, the programmer must provide the font names and translations of the special characters if they dier from those used in the current con guration of the library. The symbolic names and graphical symbols provided by the current instantiation of the GrammarBase are given in Appendix ??. A Spectacle grammar is a context-free grammar that is stored in a text le using the BackusNaur form notation6 [33]. The Grammar class contains two sub-parts, a parser that reads in the grammar and a simple database of production rules indexed by the nonterminals of the grammar. The Grammar class acts as a production-rule server to the class SpecificationComponent by providing it with a list of replacements, that is, the right-hand-side of all production rules, when given a nonterminal symbol. More speci cally, the Grammar stores lists of Rules, one list for each nonterminal in the grammar. The Rule and Token classes are used to store production rules. A Token is a single symbol from a rule, such as hBooleani, and a Rule is the sequence of the tokens that form the production rule.

Boolean Value

=

Value

Name m

Value

Value

*

+

Value

Value Name r

Name p

Name q

Figure 2: : A parse tree for the expression m = pq+r. For a given symbol, the ParseTreeNode class stores information such as the symbol's font, an index key for retrieval purposes, and the symbol itself. If the node is in the frontier of the parse tree (the left-toright sequence of leaf nodes), then information such as the left and right nodes are also stored to be used for ecient retrieval purposes; this retrieval process will be described in further detail later.

6 The exception is that no repetition operation, i.e., Kleenestar -type operation, and no alternation operations is permitted. Kleene-star rules must be presented recursively,and alternatives must be presented separately.

3

are supported by the class Formatter. In addition, the Formatter class provides services such as locating subexpressions in the parse tree, computing the length of an expression in pixels, setting the location of a token, and performing keyword searches through the parse tree. In order to de ne a custom formatting algorithm, the programmer must derive a new class, say MyFormatter, from the class Formatter and implement the algorithm as a method (function), say format, of MyFormatter. The new class MyFormatter can then be \installed" into the editing tool that will then use it transparently, calling the method format whenever the service is needed.

The display area is implemented as a bitmap, that is, a 2-dimensional array of pixels onto which the text is literally drawn, where a pixel corresponds to a single point on the screen. The BoundingBox class is the abstraction for a bounding box that establishes the relationship between a group of pixels in the display area of the editor and a frontier node of the parse tree. From the user's perspective, a bounding box is used to display the speci cation quickly and to determine which parse tree node should be selected when the user \clicks" in a display area of the speci cation editor. For example, in Figure 2, the symbol m would be displayed for the user at some location in the display area that, for simplicity, is represented internally by a rectangular box; note that the size of the font used to display the character determines the dimensions of this rectangular box. If the box for m were bounded by the pixel coordinates (0; 0), (0; 5);(8,0), and (8; 5), then the bounding box attached to the parse tree node m would store the coordinates7 . The Mapping class represents an abstract function from the (x; y) coordinates of a display area of the editor onto the frontier of the parse tree; the function is de ned by the list of bounding boxes described above. Given an (x; y) coordinate, the Mapping object can compute to which bounding box and thus to which parse tree node the (x; y) coordinate corresponds; this property of Mapping is used to determine which item is selected when the user clicks the mouse on the display area. The Mapping class is also responsible for displaying the frontier of a parse tree in a display area of the editing tool by scanning the list of bounding boxes from left to right and drawing the contents of each corresponding parse tree node onto the display bitmap. Finally, this class is responsible for drawing the contents of the popup menus that are used by Spectacle. Formatting plays an important role in the display of text in a window. Often the text of a portion of the speci cation being edited, say the precondition or statement of the speci cation example given in Section 1, cannot or should not be placed on a single line of the display area. In such a case, a decision must be made as to how the text should be laid out in the display area in order to make it visually comprehensible. One approach is to truncate the text to the width of the display window, known as clipping; the user can manually adjust the size of the window in order to view more of the text, resulting in a non-userfriendly interface. Another brute force approach is to break the text into the smallest number of consecutive rows such that the length of every row does not exceed the width of the display window. This heuristic is known as word-wrap formatting; this formatting technique is applied if the user does not supply a custom formatting algorithm. More elegant heuristics might break lines at speci c keywords or operators and use indentation to emphasize structure. The implementation of heuristic text formatting algorithms like these

2.2.3 The Major Tool-Building Classes

The classes discussed earlier are the building blocks of the library used to implement the high level classes SpecificationComponent and Specification. These two classes are the major abstractions provided by Spectacle for de ning an editing tool. The SpecificationComponent class is used indirectly by the programmer, while the Specification class is used directly. As we mentioned earlier, a speci cation may consist of several separate, logical components such as a precondition , a postcondition , and a statement, or it may be a single logical unit such as a trait in the Larch speci cation language [34]. While any speci cation can be thought of as a single composite entity, features of Spectacle are better exploited if separate logical components of a speci cation are identi ed. The class SpecificationComponent encapsulates this concept of a speci cation component. A SpecificationComponent manages three major objects, a Grammar that de nes the language used by the component, a ParseTree for storing the expression, and a Mapping for managing the user-interface portion of the component (such as the display area) and displaying the expression in the ParseTree. This class primarily handles the movement of information between the three objects just described and is used by the client programmer indirectly through the class Specification. Every tool developed from Spectacle is derived from the abstract class Specification, as it provides all of the control services needed by an editing tool. The programmer can use the services of this class to create new SpecificationComponents, instantiate them with grammars, and install text formatters. Specification provides a set of standard public services that can enable an application to control the behavior of an editing tool.

2.2.4 Event Handling with X-Window - The XIM \class"

The X-Window system has a multi-layered architecture. The lower layer is Xlib [22], which provides primitives for low-level graphics, window manipula-

Actually, only two opposing coordinates are stored as this is sucient to specify a rectangle. 7

4

tion, event handling,8 and other basic operations. The upper layer comprise the widget sets , which are essentially class libraries that provide user-interface items such as buttons , scroll-bars , and bitmaps . The Intrinsics is the middle layer, which provides eventhandling models, window management models, and operations that typically involve widget management. These event handling features were a particular problem in the implementation of Spectacle; we discuss the diculties in detail and the solutions below. The Spectacle library tries to hide much of the X-Window programming responsibilities from the tool developer, thus requiring events to be routed directly to speci c Spectacle objects such as a Mapper; the services provided by the Instrinsics do not allow objects to be named as event handlers, thus, requiring another event handling scheme to be created, namely the XIM. The XIM is a 9non-C++ class written in the style of a widget class . It is primarily used for any task involving events that must be intercepted and for standard services such as popup menus and popup dialog boxes. The XIM also has standard routines for initializing the X-Window environment, further relieving the programmer from X-Window concerns. The application developer may use this class to link the X-window environment of an application to one used by Spectacle. 2.3

Figure 3: : The Hoare-specs interface cation by following the procedure given in Figure 4; the response of the tool is described in italics. If in Step 1 a nonterminal N is selected, and the grammar contains a set of productions, fN ! B1 ; N ! B2 ; :::; N ! Bn g, then after the expansion decision is made in Step 2, a menu is displayed containing items B1 ; :::; Bn as its entries. In Step 4, when no more nonterminals exist, the user may save the speci cation or invoke any other action, such as saving a speci cation, that has been included in the user interface by the tool developer. 1. Select a nonterminal symbol from one of the SpecificationComponents (the left mouse button). The tool highlights the selected item. 2. Select the Expand operation (the right mouse button). The tool presents the user with a menu of possible replacements. 3. Select one item from the list of possible replacements (the left mouse button). The tool substitutes the selected nonterminal with the chosen replacement. 4. Repeat steps 1 and 2 until there are no more nonterminals. Speci cation is complete. Figure 4: Procedure for constructing speci cations

The User-Interface Model

The appearance and behavior of the interface for every Spectacle tool is essentially the same; Figures 3 and 7 show two such tools, these tools will be discussed in more detail in Section 3, but the common and some of the more super cial features are discussed below. Most obviously, there is a set of editing surfaces (display areas) with title bars, corresponding to each logical component of the speci cation, that responds to the workstation's mouse; the Precondition in Figure 3 is an example of an editing surface. These editing surfaces are a visual attribute of all objects of type SpecificationComponent. Next, we consider the contents of the editing surfaces. Every grammar le has a designated unique nonterminal as its start symbol, and it is this symbol that is initially visible on the editing surface of a SpecificationComponent. Nonterminal symbols, displayed in an italics font, can be replaced (referred to as expansion herein) by applying a production rule from the grammar; terminal symbols (such as variable names and operators), displayed in a Roman font, cannot be expanded. The user constructs the speci-

In Figure 3, most of the speci cation has been built, but one nonterminal, Range, is still present and is currently selected (this is indicated by the highlighting); on the right hand side of the screen, a menu of selections is displayed in response to the users request for expansion of the nonterminal symbol Range, where each selection corresponds to the right-hand-side of a production rule. Obviously it is likely that the user will make a mistake at some point during the editing process and will want to undo earlier rule applications. In order to make the modi cation, the user selects a subtree of the parse tree for removal, and then deletes it by \clicking" the middle button of the mouse. More speci -

8 There are many X-Window events including mouse movement, keyboard entry, and the depression of a mouse button. X-Window can notify processes of events, invoke user-de ned functions in response to events, and so on. These types of services are referred to as event handling services. 9 A widget is implemented with at least three les: a public header le providing names of public methods, a private header le containing internal structural information about the widget, and an implementation le containing the body of all functions named in both the public and private headers.

5

A class PredicateLogicFormatter was created by deriving it from the Spectacle class Formatter. The formatting heuristic of this class is to break a formula into reasonably long segments, where each segment is a separate line of text and to indent each piece according to its nesting level. When the Hoare-specs tool begins execution, a dynamic object-structure is established to operate the editor; this structure is shown in Figure 5 and uses the same legend given in Figure 1. If Figures 1 and 5 are compared, then one can easily determine that the hierarchy of Figure 5 is built from duplications of the SpecificationComponent sub-hierarchy, with dierent grammars in each component.

cally, the selection of a subtree is graphically made by having the user select a single token in the expression to be deleted, and then repeatedly \click" on the same token until the expression is completely highlighted. Each successive \click" highlights a larger portion of the expression (in the reverse order that the expansions were made), until eventually, the entire expression is highlighted and a subsequent selection results in only the original token being selected. The rest of the user interface is largely determined by the application within which the editing tool is embedded. In the example given in Figure 3, we have de ned the buttons labeled Save and Quit to save a speci cation and to exit from the tool, respectively. The tools in Figures 3 and 7 utilize the same interface setup and thus look very similar, however this need not be the case. 3 Prototype Stand-Alone Spectacle

Formatter

Editors

Grammar Mapping

Two prototype editors were constructed from the Spectacle library in order to demonstrate its usage; each tool illustrates a dierent type of speci cation model and language. The rst tool to be discussed is based on a model of program speci cation that was rst proposed by Hoare [35], the Hoare-triple , and the second tool provides an editor for the Larch Shared Language [34]. 3.1

Formatter

PredicateLogicFormatter ParseTree

SpecificationComponent (Precondition)

Formatter

WordWrap Grammar Mapping

PredicateLogicFormatter ParseTree

SpecificationComponent (Statement)

Grammar Mapping

ParseTree

SpecificationComponent (Postcondition)

Specification Hoare S/Hoare

Figure 5: : among objects

The Hoare-specs Tool

A Hoare-triple consists of a precondition, postcondition, and a statement in some programming language (for example, a procedure call); the rst two components are predicate logic expressions while the last is a program statement. A Hoare-triple is often written in the form fPrecondition g Statement fPostcondition g, indicating that Precondition is true before executing Statement, and Postcondition is true after executing Statement. An editor that supports such a speci cation must provide editing capabilities for all three components ; note that the Statement component will have a completely dierent grammar as compared to that of the other two components. As an application of the Spectacle library we built the prototype tool, Hoare-specs, shown in Figure 3, which supports this type of speci cation model. Following the library structure given in Figure 1, we developed the prototype by deriving the class Hoare from the class Specification. The constructor 10 of this derived class creates each of the three components needed to implement the speci cation model described above. When a SpecificationComponent object is created, the grammar le is used to de ne the speci cation language for the component; see Appendix ?? for the grammar le used to con gure Hoare-specs.

3.2

Hoare-specs

run-time \hierarchy"

The LSL-trait Editing Tool

Larch is a family of speci cation languages [34] composed of two parts: Larch Interface Languages and the Larch Shared Language (LSL). An interface language is similar in spirit to the model proposed by Hoare allowing a procedure/function call to be speci ed using pre- and postconditions. For each programming language, there is a language-based interface language with which programs can be speci ed. For example, the LCL is the Larch C interface Language [34], and Larch/CLU provides constructs for the speci cation of CLU programs [34]. The terms used in the pre- and postconditions of an interface speci cation, such as predicates, abstract data types (ADTs), and special operators, are given meaning through the Larch Shared Language. The LSL is an algebraic speci cation language used to de ne speci cation items called traits . Loosely stated, a trait describes an ADT comprising assertions that constrain predicates, functions, and identi ers. An example trait for the ADT Stack is shown in Figure 6. A trait speci cation has two components: the keyword introduces identi es the beginning of the type definition section, and the keyword asserts begins the section containing the constraints on all the operations named in the introduces section. There are several keywords used by the LSL, including those mentioned above and generatedby which de nes constructors for the type, where constructors in this context refer to the most basic operations of an ADT in which all other operations are de ned [36]. Dummy variables such as S and E also appear in a trait speci cation, to be replaced later by speci c data types.

10 The constructor for a class A is a procedure that is called when an object of type A is rst created. It performs any initialization necessary for the object.

6

to the acceptance and application of formal methods in the software development community. The Spectacle project provides a basis for the development of graphical editors that are appropriate for formal development environments. Spectacle does not attempt to address all the problems related to editing graphical-languages. Spectacle has one major objective, that is, to provide a general purpose, con gurable toolkit for the task of speci cation editing. Several potential areas exist for future investigations. For example, the LSL-specs editor can be integrated with the Larch Browsing Environment (LBE) [38], a graphical browser for LSL speci cations to facilitate the construction of large speci cations derived from existing speci cations. Currently, we are investigating the extension of the Spectacle library to handle subscripting capabilities and inclusion of graphical objects such as enclosing boxes in order to support languages such as Z [20]. Potential future work with Spectacle includes investigating methods for sophisticated parse tree traversal to support both sophisticated formatting heuristics based on semantics and semantic analysis of the speci cations. More editing features such as graphical cut-and-paste operations would provide more exibility during an editing session.

The LSL-specs editing tool is a single component editor con gured to edit LSL traits. Traits can be much larger than that shown in Figure 6 and can incorporate mathematical symbols such as () and _, which are easier to read and more intuitive in their graphical form than in a contrived form such as and n/, thus the tool LSL-specs provides a set of mathematical symbols improving the readability of the trait. In constructing the LSL-specs tool, a class LarchTrait was derived from Specification and a class LarchTraitFormatter was derived from Formatter. The LSL-specs tool is shown in Figure 7; a nonterminal Term has been selected and a menu is displayed that shows the possible replacements. Stack: trait introduces new: S isempty: S bool push: S,E S pop: S S top: S E asserts S generatedby new, push e:E, s:S pop(push(e,s)) == s top(push(e,s)) == e isempty(new) == true isempty(push(e,s)) == false endtrait

!

! !

! !

8

References

[1] Mark Moriconi, editor. International Workshop on Formal Methods in Software Development, Napa, California, May 1990. ACM SIGSOFT. [2] Nancy G. Leveson. Formal Methods in Software Engineering. IEEE Transactions on Software Engineering, 16(9):929{930, September 1990. [3] Victoria Slid Flor. Ruling's Dicta Causes Uproar. The National Law Journal, July 1991. [4] Mary Lu Carnevale. DSC Communications says Modi cation of Software led to Phone Disruptions. The Wall Street Journal, July 1991. [5] Peter G. Neumann. Inside RISKS: Some Re ections on a Telephone Switching Problem. Communications of the ACM, 33(7):154, July 1990. [6] Peter G. Neumann. Inside RISKS: Expecting the Unexpected Mayday. Communications of the ACM, 34(5):128, May 1991. [7] Zohar Manna and Richard Waldinger. Fundamentals of deductive program synthesis. IEEE Transactions on Software Engineering, 18(8):674{704, August 1992. [8] D. R. Smith. KIDS: A Semi-automatic Program Development System. IEEE Transactions on Software Engineering, 16(9):1024{1043, September 1990. [9] Cli B. Jones. Systematic Software Development Using VDM. Prentice Hall International Series in Computer Science. Prentice Hall International (UK) Ltd., second edition, 1990.

Figure 6: : A simple LSL trait

Figure 7: : The beginning of a LSL-specs session

4 Concluding Remarks and Future Investigations

Formal methods oers a rigorous approach to many tasks of software development [1, 13, 14, 15, 16], including automated program development [26, 28], software reuse [32, 37] and reverse engineering [29]. However, due to the need for preciseness and rigor, the use of formal methods can often be dicult and cumbersome at best. Graphical interfaces to software development environments, those that provide the user with concise visual aids suggesting the meaning or purpose of information being displayed, may be essential 7

[29] 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. [30] D.R. Chesney and B. H. C. Cheng. A formal Approach to Automatic Source Code Translation for Parallel Architectures. In Proceedings of Minnowbrook Workshop on Software for Parallel Computing, pages 29{34, August 1992. [31] Betty H. C. Cheng. Constructing formal speci cations from informal descriptions. In Proceedings of Fourteenth Minnowbrook Software Engineering Workshop, pages 22{23, July 1991. [32] 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. [33] John E. Hopcroft and Jerey D. Ullman. Introduction to Automata Theory, Languages and Computation. Addison-Wesley Publishing Company, Inc., 1979. [34] John V. Guttag, James J. Horning, K.D. Jones S.J. Garland, A. Modet, and J.M. Wing. Larch: Languages and tools for formal speci cation. Texts and Monographs in Computer Science. Springer-Verlag, 1993. [35] C.A.R. Hoare. An Axiomatic Basis for Computer Programming. Communications of the ACM, 12(10):576{ 581, 1969. [36] D. Kapur, P. Narendran, D. Rosenkrantz, and H. Zhang. Sucient-completeness, quasi-reducibility and their complexity. Technical report, Dept. of Computer Science, State University of New York at Albany, Albany, NY, 1987. A preliminary version appeared in the Proc. of Sixth Conf. on Foundations of Software Technology and Theoretical Computer Science, New Dehli, India, LNCS 241,Springer Verlag, 426-422. [37] Betty H. C. Cheng and Jun-jang Jeng. Formal methods applied to reuse. In Proceedings of the Fifth Workshop in Software Reuse, 1992. [38] Michael R. Laux, Robert H. Bourdeau, and Betty H. C. Cheng. An integrated development environment for formal speci cations. In Proc. of IEEE International Conference on Software Engineering and Knowledge Engineering, pages 681{688, San Francisco, California, July 1993.

[10] Nachum Dershowitz. Program Abstraction and Instantiation. ACM Transactions on Programming Languages and Systems, 7(3):446{477, July 1985. [11] Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Clis, New Jersey, 1976. [12] David Gries. The Science of Programming. SpringerVerlag, 1981. [13] Jeannette M. Wing. A Speci er's Introduction to Formal Methods. IEEE Computer, 23(9):8{24, September 1990. [14] Anthony Hall. Seven myths of formal methods. IEEE Software, pages 11{19, September 1990. [15] Susan L. Gerhart. Applications of formal methods: Developing virtuoso software. IEEE Software, 7(5):7{ 10, September 1990. [16] Richard A. Kemmerer. Integrating Formal Methods into the Development Process. IEEE Software, pages 37{50, September 1990. [17] David Gries. The Science of Programming. SpringerVerlag New York, Inc., 1981. [18] Mehdi T. Harandi and Sanjay Bhansali. Program derivation using analogy. In IJCAI, pages 389{394, Detroit, August 1989. [19] Betty Hsiao-Chih Cheng. Synthesis of Procedural and Data Abstractions. PhD thesis, University of Illinois at Urbana-Champaign, August 1990. [20] J.M. Spivey. The Z Notation, A Reference Manual. Prentice-Hall International (UK) Ltd., 1989. [21] Leslie Lamport. LaTEX, A Document Preparation System. Addision-Wesley Publishing Company, 1986. [22] Oliver Jones. Introduction to the X-Window System. Prentice-Hall, Inc., 1989. [23] Thomas W. Reps. Generating Language-Based Environments. The MIT Press, 1984. [24] Ann L. Winblad, Samuel D. Edwards, and David R. King. Object-Oriented Software. Addison-Wesley, Publishing Company Inc., 1990. [25] Keith E. Gorlen, Sanford M. Orlow, and Perry S. Plexico. Data Abstraction and Object-oriented Programming in C++. John Wiley & Sons, 1990. [26] Betty Hsiao-Chih Cheng. Synthesis of Procedural and Data Abstractions. PhD thesis, University of Illinois at Urbana-Champaign, 1990. Tech Report UIUCDCS-R-90-1631. [27] Betty H. C. Cheng. Synthesis of Procedural Abstractions from Formal Speci cations. In Proc. of COMPSAC'91, pages 149{154, September 1991. [28] Betty H. C. Cheng. Automated Synthesis of Data Abstractions. In Proc. of Irvine Software Symposium, pages 161{176, June 1991.

8