Formal Specifications Guide Development and Testing of Software Components

Transcription

1 Tamkang Journal of Science and Engineering, vol. 2, No. 1 pp (1999) 1 Formal Specifications Guide Development and Testing of Software Components R. E. Davis Computer Engineering Department Santa Clara University Santa Clara, CA 95053, U.S.A. rdavis@scu.edu Abstract Formal specifications provide many benefits to software developers. It has long been recognized that formal methods are required in safety critical applications, where it may even be necessary to perform formal proofs of correctness to increase confidence in the reliability of the system. However, not all uses of formal methods require the same level of detail, or even formality. We can design formal specifications of software components, and then use the specifications in an informal way to guide the development of an implementation as well as to provide a blueprint for testing of the finished component. In this paper we use the Larch Shared Language (LSL) to specify abstract data types, and show how the specification can be used both to guide implementation in Ada95 and to develop a testing plan. This approach increases both the quality of documentation and confidence in the correctness of reusable components providing abstract data structures. Key words: formal methods, formal specification, Larch, LSL, testing, software components, abstract data types, Ada. 1. Introduction Too often the use of formal methods is seen as an alternative to the way software is really developed. At best formal methods are seen to be of value only for safety critical applications; often they are an anomaly studied in a separate course for the express purpose of studying formal methods; at worst they are seen to be only of theoretical interest and no practical value. We believe that use of formal methods is appropriate in most software courses in the computer science/engineering curriculum, although we do not insist on a strictly formal approach to the entire software engineering process. For example, it is reasonable to make use of formal specifications for some but not all parts of a software system. The specifications may be written for a variety of reasons: to enable derivation of programs, to permit verification, to guide implementation, to document interfaces, to provide guidelines for reuse, or simply to clarify the requirements in the minds of designers. The specification, representation and implementation of abstract data structures present the ideal opportunity to introduce formal methods of specification. In addition, the formal specification fits nicely with the separation of interface and implementation required by the encapsulation and object-oriented features of programming languages. These features, in turn, enable the implementation of reliable reusable software components. In this paper we present our approach to the informal, practical use of formal specifications as a guide to implementation and testing of software components, which increases both the quality of documentation and confidence in the correctness of the implementation. Section 2 describes abstract data structures and their formal specification in an enhanced subset of the Larch Shared Language (LSL [7]), the language we use to write algebraic specifications. We note how reuse can be employed in the specification as well as later in the

2 2 Tamkang Journal of Science and Engineering, vol. 2, No. 1 (1999) implementation of abstract data types. In Section 3 we explore the difference between the notions of value and object, and its impact on the implementation of data structures. Section 4 provides a representation for a Table abstract data type. Section 5 shows how the implementation of objects can be guided by the specification of their associated values, and Section 6 describes how the formal specification can be used informally to guide testing and increase one's confidence in the correctness of the implementation. In Section 7 we note that this approach can have a significant effect on the production of high quality reusable software components. 2. Formal Specification of Abstract Data Structures 2.1 Abstract Data Structures There is more to an abstract data structure (or Abstract Data Type, ADT) 1 than a set of elements. A data structure is defined by the elements of its domain together with primitives that describe how these elements are related to each other and to elements of other data structures. We use the following definition to express this more formally. DEFINITION: A data structure is a 4-tuple consisting of a set of domains D, a designated domain d D, a set of functions F, and a set of axioms A. The 4-tuple ( D, d, F, A) denotes the data structure d and is usually abbreviated by writing d. It is important to distinguish between data structures, which are abstract entities, and the storage structures provided in a programming language, even though they may use the same name. A data structure is specified to describe what it is (its elements and the relationships among its elements and those of other data structures). A specification is intended to accurately define the one ADT of interest. It is abstract in that it describes the values and relationships without concern for how they might be represented and implemented. A concrete representation denotes elements of an ADT by combinations of storage structures in a specific programming language. There can be many possible representations for a given data 1 We use the terms abstract data structure and ADT interchangeably. We refer to concrete programmatic representations of ADTs as storage structures. structure. A representation tells us how a given element of the data structure looks so we can recognize it and work with it. An implementation is a set of programs that provide the capabilities of the primitive functions of the data structure while operating on concrete representations. Given a specific representation, there can be many possible implementations using different algorithms to accomplish the same task. An implementation tells us how the primitive operations work with the chosen representation to supply the capabilities of the specified data structure. We refer to the implementation of the capabilities of functions of an ADT to emphasize that one need not implement each function of a specification as a function (returning a value). For example, the capabilities of the functions Top and Pop on an ADT Stack might reasonably be implemented by a single procedure Pop producing two values, or a function returning a top value and having a side-effect on a stack object, or. The strict division of the tasks of specification, representation, and implementation of data structures helps to clarify distinct issues that are raised at each step. Emphasizing this division encourages programmers to address design issues before plunging into coding. 3. An Enhanced Subset of LSL To specify an ADT we need a convention for defining the domain of elements, primitive functions, and the axioms defining constraints that must be satisfied. We use the Larch 2 Shared Language (LSL) [7,8], to describe high-level, programming language independent specifications. The specification of ADTs requires only a small subset of the language. We have added a few category labels to this subset to suggest which primitives may be necessary, and what their purpose is in the ADT. 2 Larch is in fact a family of specification languages and tools (see [7]}) that support a two-tiered approach to specification of software and hardware. The Larch Shared Language is used to write a programming-language independent specification describing mathematical abstractions. The second tier of specification is supported by Larch Interface Languages that have been designed for several programming languages (Ada, C, Modula, CLU, Smalltalk, ML, ), allowing one to specify resource allocation, state changes, and exceptions in a way that depends heavily on the specifics of a particular implementation language. Larch tools include several syntax checkers and the Larch Prover for analyzing semantics of specifications.

3 R. E. Davis: Formal Specifications Guide Development and Testing of Software Components 3 LSL provides a specification unit called a trait that can be used (among other options) to specify abstract data structures. For example, we can specify the data structure Table as an LSL trait. Using the definition above, the elements of the 4-tuple are d = Table, D = {Table, Key, Contents, Boolean}, F = {New, Add, Retrieve, IsEmpty, }, and A is the set of axioms (equations) following the asserts below. Each trait is given a name. The introduces section specifies the set of functions F and provides the types of their arguments and values. The functions F specify the elements of the data domain of the structure being defined as well as the primitive operations and relationships involving those elements. There is no fixed correct set of primitives for a data structure, and there is a tradeoff between the simplicity of a small set and the utility of a larger set of primitives. We use a slight variation on the LSL notation, adding labelled categories of primitives to the introduces section of a trait. These categories, described below, provide a guide to designers in their choice of primitives. 1. Specify the elements of the domain --- often this is an inductive definition. (a) basis element(s) --- the 0-ary function New in the example above. (b) constructors --- Add in the example above. This class of functions generate compound elements of the domain. (c) The external clause of an inductive definition, which states that the only elements of the domain are those that can be generated from a finite number of applications of (a) and (b), can be made explicit by including a generated by axiom in the asserts section of the trait. 2. Selectors are primitives for decomposing compound elements of the domain --- usually one considers providing selectors corresponding to the arguments of the constructor functions. In Table, since a table is constructed by applying Add to a Key, a Contents and an existing Table, we consider providing selectors that produce the parts of such a construction. Above, we chose to provide only the selector Retrieve, which selects the Contents added at a given Key in a Table. (One can imagine another selector, say Find, that locates a Key bound to a given Contents in a Table.) 3. Testers are primitives that test elements of the domain --- for example, testing that an element is a basis element, IsEmpty in the example above. 4. Utilities --- in addition to the constructors, selectors, and testers mentioned above, we may wish to provide a set of primitives expected to be necessary, or just useful, to anyone writing an application using the data structure. For example, we might have chosen to include a function, size, that provided the number of bindings in a table. The equations following the asserts specify constraints or conditions that must be satisfied by any correct implementation of the data structure. The LSL declaration that Table is generated by New, Add states that there are no hidden ways for an element to slip into the domain. If it cannot be generated by the operators given then it is not in the domain. The LSL clause Table partitioned by IsEmpty, Retrieve states that two tables are different if and only if they can be distinguished by some application of these operators. Note that we did not completely specify the selector Retrieve, since we did not say what happens if Retrieve is applied to New. It is left up to the implementor whether this should signal an

4 4 Tamkang Journal of Science and Engineering, vol. 2, No. 1 (1999) error or return some other value. The clause stating that we are exempting specific applications of an operator explicitly points out the fact that the operator is not completely defined on all elements of the domain by the equations in the trait, and thus the implementor is free to choose how to handle these cases. We can reuse specifications in a couple of ways. It is possible to explicitly include information from other traits via the include declaration, which has the effect of treating the new specification as if it contained all of the introduces and asserts clauses of the included trait. Another means of modularizing specifications is the definition of parameterized traits. For example, we can anticipate that the TableSpec trait will be useful for several different Key and Contents types and parameterize the trait as follows: TableSpec(Key, Contents) : trait We might then refer to a trait specifying a symbol table as TableSpec(Symbol, Value). Since we don't always anticipate every way we may later want to parameterize a trait, we can also refer to a trait with an explicit renaming for any of the types and/or functions introduced by the trait. Thus, assuming that we have already specified a StackOfItems trait, which introduced a Stack type and the operators MtStk, Push, Pop, and Top, we might specify the ADT Environment as a stack of symbol tables by: Note that LSL allows us to overload operators, so we can use the same symbol for the operator to check whether a symbol is in an environment or in an individual frame. The syntax we use for LSL specifications of ADTs can be summarized in Appendix A. 3. Objects and Values We use LSL to describe the values of an abstract data structure and how they are related to other values. Most programmers have a preconceived notion of data structures as objects --- things with identity and state that are side-effected by operations. Our formal specifications however, with semantics based on the mathematics of first-order logic, view data structures as values, which can be constructed, viewed, tested, and have their components selected, but have no more claim to identity than does an integer. When writing formal specifications for data structures we take this mathematical view in order to abstract away from our experience with the accidental (and intentional) details of specific implementations. We want to specify the essence of the data structure values. However, before we proceed to represent and implement a data structure we must consider whether it is more appropriately viewed as value or object. The fundamental distinction between the concepts of object and value is the notion of identity. Every object has a value, but two objects are distinguishable even if they have the same value. Many objects are mutable, they can change their values, but they do not lose their identity. Philosophically, the notion of identity is quite complex; however, we take a very simple-minded view. We assume that every object is endowed with identity upon creation, and that identity (whatever it is) never changes. One important question to ask when deciding whether the elements of an ADT are objects or values is whether or not it makes sense to say you can have two different elements of the ADT whose values (at a given time) are equal. For example, it makes no sense to say we have two fours. Numbers are values, there is no need to distinguish between this four and that four; all that is important is its fourness. On the other hand, it makes perfect sense to distinguish between two queues, even when the same items appear in the same order in each queue. (Perhaps one is a list of customers waiting to buy strawberries, and the other is a list of customers waiting to buy steaks. If

5 R. E. Davis: Formal Specifications Guide Development and Testing of Software Components 5 you happen to be vegetarian you might like to enter one queue and not the other.) The choice of value or mutable object has impact on both the representation and the implementation of a data structure. Values can be safely shared, but with objects we must worry about side-effects. There are new primitives to be considered for objects that made no sense for values. Mutators are primitive operations that change the state of an object. Also among the utilities and testers we provide we may need to consider multiple versions; for example, sometimes we want to test equality (of values) and other times we must check identity (of objects). To make this discussion concrete, let us proceed with the ADT Table. Choosing to implement tables as values with no concept of identity would imply that we intend to distinguish tables only by the values we can Retrieve from them. That is, if we had two table variables, A and B, bound to the same table value, it would be immaterial whether or not they were programmatically bound to the same object representing that value. This would complicate our implementation by requiring that we ensure that the values are immutable, and thus we can share without fear of side-effects. However, most people do not think of tables as pure values but as objects that have operations performed on them that change their state. Thus we distinguish this table from that table even though they may have the same retrievable contents for every key. For example, considering the environment example above, we may have a table (frame) associated with a call to a procedure P(x, y), and another table associated with a call to a procedure Q(x, y). If they were called with the same actual arguments, the two tables would initially have the same value, however, in the process of evaluating the respective bodies of the procedures we may change the value of one or both tables. This affects the implementation of operations, since if we consider a table to have an identity, then Add may become a procedure that changes the state of a table instead of a function that produces a new table value from an old value. It also affects the interface to the data structure, since an implementation as objects may require both primitive functions that sample the state of an object (for its value, e.g. Retrieve) and primitive procedures that change the state in specified ways (e.g., Add). Based on this discussion, we choose to implement tables as objects. 4. Representation Once we have specified the values of a data structure, and decided whether its domain of implementation is most naturally populated by objects or values, we can consider alternatives for representing it. That is, we need to establish a convention for denoting elements of the data structure so there is no ambiguity about which element is intended. We can imagine both bounded and unbounded representations for the ADT TableSpec, reflecting whether or not we choose to set a limit on the number of entries a table can hold. If we choose to allow tables to grow dynamically without a predefined limit, we might consider an unbounded\label{unbounded} representation based on linked lists. A table of entries can be represented as a singly linked list, each of whose elements represents a single entry (a binding of a key to contents) and a link to the rest of the table. An empty list (or null pointer) would represent an empty table. Using Ada as an implementation language, we can define such a representation using access and record types as follows. We assume that the Key and Contents types are define elsewhere. type Node; type Table is access Node; type Node is record TheKey : Key; TheContents : Contents; Next : Table; end record This describes the storage structure used to represent a table, but it doesn't implement the table. To accomplish the implementation we need to choose and implement primitive table operations that provide all the functionality specified by the trait TableSpec while operating on the chosen representation. These operations comprise the concrete interface to the ADT. The separation of interface from implementation is reinforced in Ada with the notions of package specification and body. We make the representation and interface to the ADT explicit in the package specification, and provide the details of the implementation in the package body. 5. Implementation Once the representation is chosen, we still have several options for implementation. Two

6 6 Tamkang Journal of Science and Engineering, vol. 2, No. 1 (1999) major considerations when designing components for reuse are the flexibility of the component (range of variations it covers) and the degree of protection it provides. In Ada, flexibility is increased by making appropriate use of generics and discriminants (perhaps making the interface more complex). Safety is provided in varying degrees by limiting access to the representation via private and limited private types. To enhance the modularity and safety of programs using our table module, we do not allow the user access to the representation of the table. Anyone using tables must do so through a well-defined interface of primitive table operations. The first impulse is to treat the introduces section of a trait specification as a rough outline of a package specification providing this interface, and to a large extent it is just that. We must, of course, be careful to satisfy the axioms of the trait specification when providing an implementation of an ADT. However, this does not constrain us to supply each primitive as a function and to implement each as if the axioms provided an operational specification. The implementation decisions we make affect both the mechanism (procedure or function) used to implement a primitive, and which primitives must be provided. For example, we may choose to hide the details of the representation by making the Table an Ada limited private type. This means assignment will not be available from the system and we will not be able to initialize tables outside the implementing package. In order to create a table with the New value we need to provide a primitive operation that will empty a table. We also provide an assignment equivalent --- a Copy operation that can make one table contain a copy of the value of another (thus creating two tables who happen to have the same value). Similarly, we must consider whether representations of objects can be shared, and which primitive procedures (mutators) we will provide to change the state of an object. If sharing is allowed, we must provide another primitive MkSame that will allow one table to share the same value as another (creating two names for the same table). Also, since objects have identity, we may need the ability to test for identity (sameness) as well as for equality of state (value) of objects. Another useful capability provided by Ada is the exception handling mechanism. Whenever we implement a data structure we should consider what might go wrong and decide how to deal with it. For example, the TableSpec trait specification put no constraints on the value of Retrieve(K, New). Even though the trait leaves the behavior unspecified, an implementation cannot. We must decide whether to return a designated null value, signal an error, or allow a client the opportunity to provide the desired behavior. In Ada we define exceptions that can be raised at appropriate times and can be handled by clients of our implementation. We saw how the TableSpec trait could be parameterized by the types Key and Contents that are entered in the table. Ada allows us a similar flexibility in defining generic packages parameterized by types that are required within them. Factoring in all of these considerations leads to the specification of the generic package TableSpec given below. generic type Key is private; type Contents is private; package TableSpec is type Table is limited private; - - exceptional conditions that we wish to recognize - - within the package Overflow, Underflow, EntryNotFound : exception; - - running out of room for a table to grow, - - trying to access parts of a table that don't exist, - - or trying to retrieve the contents for a key - - not bound in the table - - procedures that modify tables procedure MkNew( T : in out Table); - - make the table T the empty table procedure Add(K in Key; C : in Contents; T : in out Table); - - add the entry binding K to C in table T procedure Copy( T1 : in Table; T2 : in out Table); - - make the table T2 a copy of the table T1 procedure MkSame( T1 : in Table; T2 : in out Table); - - make the table T2 the same table as T1 - - functions that select components of, or test, tables function Retrieve( K : in Key; T : in Table) return Contents; - - returns the contents bound to K in table T function IsEmpty( T : in Table) return Boolean; - - checks whether the table T is empty function IsBound( K : in Key; T : in Table)

7 R. E. Davis: Formal Specifications Guide Development and Testing of Software Components 7 return Boolean; - - checks if there is a binding for K in table T function IsSame( T1, T2 : in Table) return Boolean; - - checks if T1 and T2 refer to the same table private type Node; type Table is access Node; type Node is record TheKey : Key; TheContents : Contents; Next : Table; end record; end TableSpec; The package body defines each of the primitives in terms of operations on the chosen representation. We haven't space to present here the details of the package body. 6. Testing the Implementation The TableSpec trait described table values and constraints on operations involving them. Our TableSpec package implements tables as objects whose states represent table values as specified in the trait. We need to provide some way of mapping the constraints on the primitive operations of the trait to constraints on the procedures and functions of the package. We proceed by considering each equation, and translating it into the world of objects by replacing references to values with references to variables whose values should meet the constraint expressed by the equation. Function applications may have to be replaced by variables whose values have been modified by corresponding procedures. The equations, which were stated for all values of the variables used in stating them, become program constraints, which should also be understood to hold for all values of the variables used. 1. The equation constraining Retrieve: Retrieve(x, Add(y,c,t)) = = if x=y then c else Retrieve(x, t) becomes the program constraint: Let Old = Retrieve(K1, T). Then, after executing Add(K2, C, T), the value of Retrieve(K1, T) is: if K1=K2 then C else Old 2. The equations constraining IsEmpty: IsEmpty( New ) = = true; IsEmpty(Add(x, c, t)) = = false become program constraints: After executing MkNew(T), the value of IsEmpty(T) must be TRUE; After executing Add(K, C, T), the value of IsEmpty(T) must be FALSE. 3. The equations constraining : x New = = false x Add(y,c,t) = = (x = y) V ( x t) become program constraints: After executing MkNew(T), the value of IsBound(K,T) is FALSE; Let WasIn = IsBound(K1, T). Then after executing Add(K2, T), the value of IsBound(K1,T) is: WasIn V K1 = K2. We might also note that we have chosen to raise an exception in the case left unspecified by the trait, Retrieve(K, New). These are clearly informal program constraints, and they do not prove that an implementation satisfies a specification. Our intent is simply to provide a guide for moving from the world of values to that of program objects with state in such a way that one can informally argue that an implementation meets the ADT specifications. These constraints can be used to guide the development of test programs. For example, from the first constraint above we would develop a test program fragment that (assuming the appropriate declarations and initializations provide the context): 1. defines a table, T, containing a binding for K1, Add(K1, Old, T); 2. sets Old to the value bound to K1 in T, Old := Retrieve(K1, T); 3. Adds the new binding to the table, Add(K2, C, T); 4. and finally, tests the constraint, if K1=K2 then if C = Retrieve(K1, T) then put ( Retrieve axiom met ); else put ( Retrieve axiom fails ); end if; else if Old = Retrieve(K1, T); then put ( Retrieve axiom met ); else put ( Retrieve axiom fails ); end if; end if; Of course this test should be run for cases

8 8 Tamkang Journal of Science and Engineering, vol. 2, No. 1 (1999) in which K1 and K2 are equal as well as when they are not. 7. Reuse in Software Engineering There are many aspects of reuse worthy of study. The legal, ethical, managerial, economical, and organizational issues are among many that we do not address here. The study of reuse of software artifacts of many kinds is well-described in [11]. We approach only a small part of the problem. Our goal is to provide programmers the ability to design, recognize, and use high quality reusable software components. As pointed out in [2], design reuse has the greatest payoff potential, but code reuse is a reasonable first step. Reuse does not come easily, as documented in [13], where it was found that software designers who were not trained in reuse were unable to accurately assess the value of reusing software components. The programmers were over-influenced by unimportant features (such as size) and under-influenced by important ones (such as amount of modification required). While many of the qualities we look for in reusable components are the same we would require of any well-designed software, reuse requires something more than general program quality. We borrowed our criteria for evaluation of reusable components from Sindre et. al. [12]: portability, flexibility, understandability of interface, and confidence (the subjective probability that a component satisfactorily performs its defined purpose under reuse). These qualities are enhanced by clear separation of concerns in the specification, representation, and implementation of ADTs, and careful testing of implementations, guided by the formal specifications. 8. Conclusion clarify requirements and interface. The transition from specification of values to implementation of objects is dealt with directly; the problems raised by dealing with identity vs. equality and their effect on issues of representation and implementation are illuminated. The formal specifications are used in an informal way to guide design rather than to derive programs. The intention is not to produce formal proofs of correctness, but to demonstrate the value of formal specifications in the software development process. The specifications help describe the desired properties of a data structure, often making explicit the boundary conditions that might otherwise be left to default. Although formal proofs that each implementation satisfies its specification are not required, a specification can still serve as a guide in the testing of an implementation, and provide a framework within which one can argue that a program is correct. The specification also provides valuable documentation of the structure implemented in a package. We use Ada because of the advantages associated with its facilities for hiding details which, while providing protection, also make it easier to read package specifications produced by someone else.. There is a close match between the introduces section of the Larch specification and Ada's package specifications, which helps to bridge the transition from representation-independent formal specification to actual implementation. By emphasizing formal specification as a guide in software design and development we hope to establish a foundation for growth in the use of formal methods, making them less mysterious and more standard as practical techniques at the disposal of software engineers. Data structures provide the ideal context for addressing the creation and use of formal specifications in software development. While large software systems can be built in components in many ways using different design strategies (eg., object-oriented design or functional decomposition), data structures can be very clearly delineated, with interfaces easily understood (even agreed upon) by a large community of users. The production of high quality reusable components requires formal specification, choices of representation and implementation, and actual practice in reuse of ADTs implemented by others. The specifications are a design aid, helping to

9 R. E. Davis: Formal Specifications Guide Development and Testing of Software Components 9 A Grammar for enhanced subset of LSL In the above, the notation Item + indicates a sequence of one or more occurrences of Item, separated by commas. Reference 1. Barnes, J. G. P., Programming in Ada, Addison-Wesley Publishing Company, Menlo Park, CA. (1994). 2. Biggerstaff, T. and Richter, C., Reusability Framework, Assessment, and Directions, IEEE Software, Vol. 4, No. 2, pp (1987). 3. Booch, G., Software Components with Ada. Benjamin/Cummings, Menlo Park, CA. (1987). 4. Davis, R. E. and Danielson, R. L., LSL + Ada Reusable Data Structures, In Proceedings of the Tenth Annual Washington Ada Symposium, pp (1993). 5. Garlan, D., Formal Methods for Software Engineers: Tradeoffs in Curriculum Design, In C. Sledge, editor, Software Engineering Education, volume 640 of Lecture Notes in Computer Science, pp Springer-Verlag (1992). 6. Garland, S. J., Guttag, J. V. and Horning, J. J., Debugging Larch Shared Language Specifications, IEEE Transactions on Software Engineering, Vol. 16, No. 9, pp (1990). 7. Guttag, J. V., Horning, J. J. and Modet, A., Report on the Larch Shared Language, version 2.3. Technical Report DEC/SRC SRC-58, Digital Equipment Corporation Systems Research Center Report, April, (1990). 8. Guttag, J. V. and Horning, J. J. and Wing, J. M., The Larch Family of Specification Languages, IEEE Software, Vol. 2, No. 5, pp (1985). 9. Guttag, J. V. and Modet, A. and Horning, J. J. (eds.) with Garland, S. J. and Jones, K. D. and Wing, J. M., Larch: Languages and Tools for Formal Specification, Texts and Monographs in Computer Science. Springer-Verlag (1993). 10. Jefferson, O. A. and Roland, H. U., Software Reuse in an Educational Perspective, In C. Sledge, editor, Software Engineering Education, volume 640 of Lecture Notes in Computer Science, pp Springer-Verlag (1992). 11. Krueger, C. W., Software Reuse, ACM Computing Surveys, Vol. 24, No. 2, pp (1992). 12. Sindre, G. and Karlsson, E. A. and Stålhane, T., Software Reuse in an Educational Perspective, In C. Sledge, editor, Software Engineering Education, volume 640 of

10 10 Tamkang Journal of Science and Engineering, vol. 2, No. 1 (1999) Lecture Notes in Computer Science, pp Springer-Verlag (1992). 13. Woodfield, S. N., Embley, D. W. and Scott D. T., Can Programmers Reuse Software?, IEEE Software, Vol. 4, No. 4, pp (1987). Manuscript Received: May. 04, 1999 Revision Received: May. 28, 1999 and Accepted: Jun. 21, 1999