ELSEVIER Information and Software Technology 38 (1996) 419-434
An executable specification language for specification understanding in
object-oriented specification reuse
Shih-Chien Chou, Jen-Yen Chen*, Chyan-Goei Chug
Department of Computer Science and Information Engineering, National Chiao Tung University, 1001 Ta Hsueh Road, Hsinchu. 30050 Taiwan
Received 26 January 1995; revised 23 August 1995; accepted 21 September 1995
Abstract
System analysis time can be reduced through specification reuse which, however, requires specification understanding. This paper presents an object-oriented executable specification language which reduces understanding time through executing specifications. In addition to being executable, the specification language hides as many classes as possible within subsystems, and explicitly specifies relationships between specification components. This facilitates specification modification. Moreover, the language explicitly specifies interface parameters of specification components. This facilitates specification composition.
Keywords: Specification reuse; Specification behavior; Executable specification language
1. Introduction
Software reuse can tremendously improve software development productivity and software quality [l-3]. Currently, many program code reuse techniques [4- 1 l] are available. With these techniques, however, software developers must specify a system’s specification and design document before they can reuse program code. To enhance the power of software reuse, some techni- ques for reusing design documents [ 12- 171, and for reus- ing specifications [19-211 have been developed. Techniques for reusing specifications, for reusing design documents, and for reusing program code can be inte- grated to support a reuse-based software development paradigm which will substantially reduce software devel- opment time.
The object-oriented (00) software development approach enhances software reusability through infor- mation hiding (encapsulation), modularity, abstraction, inheritance, and so on [22]. Reusability is thus one of the most important promises of the 00 approach [23-251. Despite the fact that many 00 software reuse techniques have been developed [8-9,16,24,26-271, few successful techniques for reusing 00 specifications are available. * Corresponding author. Phone: 886-35-712121 Ext. 54726 Fax: 886- 35-724176 email:[email protected].
0950-5849/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved SSDI 0950-5849(95)01080-7
This prompted us to work on an 00 specification reuse technique.
A specification primarily specifies functions, data, and behavior of a software system [28], where the system behavior is shown by the system’s state changes. Since executing a system’s functions will change its states, a system’s behavior can be exhibited by executing its func- tions. Functions and data are thus major components in a specification. According to this, specifications with functions and data similar to those of an intended system are reusable. On the other hand, specifications with simi- lar functions but different data may still be reusable. This reuse can be accomplished by changing data. However, specifications with different functions cannot be reused. In this sense, specifications with functions similar to those of the intended system are reusable. As the execu- tion of a specification’s functions exhibits the specifica- tion’s behavior, specifications with similar functions have similar behaviors, and specifications with totally different behaviors have no similar functions. Therefore, specifications with behaviors similar to that of an intended system may have functions similar to those of the system and hence may be reusable. Such specifica- tions are thus considered candidates for reuse.
Existent specifications are retrieved from a repository for reuse. In a retrieval, there may be many specifications retrieved, where some are reusable and others not. An
420 S.-C. Chou et al./Information and Software Technology 38 (1996) 419-434
analyst should understand the retrieved specifications before he or she can identify the reusable ones. Nor- mally, the analyst browses and reads the retrieved speci- fications in detail for the understanding. To save the understanding time, the retrieved specifications which are unreusable should be neither browsed nor read. They should be filtered out before the browsing and reading. As specifications with behaviors similar to that of an intended system are considered candidates for reuse, the retrieved ones with behaviors dissimilar to that of the intended system can be filtered out. Behaviors of the retrieved specifications should thus be understood for the filtering.
Normally, a system’s behavior can be understood by observing the system’s state changes. Understanding a system’s behaviour by observing all its state changes, however, may be difficult, because the system’s states may be complex. Since behavior understanding in our technique is just for filtering out unreusable specifica- tions, understanding detailed behaviors is not necces- sary. Thus, in this paper, ‘behavior’ refers to the input/ output data transformations and object state changes during execution of a specification’s functions. In under- standing this behavior, an executable specification lang- uage is needed. This paper presents a specification language for the understanding.
In addition to being executable, our specification lang- uage facilitates modification and composition of specifi- cations, because specifications may need to be modified before being reused, and the reused specifications should be properly composed to form a specification for the intended system. In the remainder of this paper, the pro- cess and issues of our 00 specification reuse technique are described first. Next, the model of the executable specification language and the language itself are respec- tively described. Then, an example is used to illustrate the usage of the language. Finally, conclusions are given.
2. Process and issues of our 00 specification reuse
technique
Our 00 specification reuse technique is based on the following considerations:
(1) Specifications with behaviors similar to that of an intended system are considered candidates for reuse. As mentioned above, systems with similar behav- iors may have similar functions. Specifications with behaviors similar to that of an intended system may thus be reusable. Accordingly, in a specification retrieval, retrieved specifications with dissimilar behaviors are not reusable and hence should be fil- tered out. Note that in this paper, a specijication’s behavior denotes the behavior of the system specified by the specification.
(2) In addition to classes, subspecifications, or even entire specifications, are considered candidates for reuse.
Most 00 software reuse techniques [8-9, 24,261 reuse only classes, which are usually primitive units in software systems. Applying such techniques is often time-consuming because they tend to compose existent classes to form subsystems and then compose subsystems to form a software system. To remedy that, our technique reuses classes as well as subspeci- fications, or even entire specifications. As an 00 specification or subspecification is composed of sev- eral classes and their relationships, reusing it corre- sponds to reusing all those classes and relationships. As classes in the same (sub)specification seem closely related and related information tends to be reused together [23], reusing (sub)specifications is more efficient than reusing classes alone. Moreover, reus- ing relationships among classes reduces the time for structuring classes, because classes should be struc- tured by their relationships. According to the above description, reusing classes as well as (sub)specifica- tions makes our technique more time-saving than those that reuse classes alone.
(3) A software system may be specified by reusing var- ious existent (sub)specifications.
Normally, a software system can be partitioned into several subsystems. There is a possibility that some subsystems of a software system are similar to those of some existent (sub)specifications, and other subsystems are similar to those of other existent (sub)- specifications. A software system may thus be speci- fied by reusing various existent (sub)specifications. Existent 00 specifications should be classified and stored in a repository before being retrieved for reuse. They can be classified by facets [29], features [30], seman- tic networks [31] and so on. According to the considera- tions given above, our 00 specification reuse process is outlined below.
(1) When an analyst wants to specify a (sub)system (or a class), he or she describes its requirements in a query. The query format should be the same as those for classifying specifications. For example, if specifica- tions are classified by semantic networks, the query should be a semantic network.
(2) A reuse support tool retrieves (sub)specifications (or classes) from the repository according to the query. The retrieved ones are candidate reusable (sub)speci- Jications (or classes).
(3) The analyst executes the retrieved candidates and fil- ters out those with behaviors dissimilar to that of the intended (sub)system (or class). He or she then browses and reads the details of the other candidates and selects some for reuse. Normally, those with the most similar behaviors are selected. If the selected
ones do not exactly fit the intended (sub)system (or class), they should be modified.
(4) If no candidates are retrieved in step (2) or no retrieved candidates are selected for reuse, the intended (sub)system (or class) cannot reuse any exis- tent (sub)specification (or class). The analyst should thus specify the (sub)system (or class) from scratch. (5) After specifying all subsystems and classes of the
intended system, the analyst composes the reused (sub)specifications and classes into a specification for the intended system
According to the process outlined above, major issues for our 00 specification reuse technique are:
(1) classification and retrieval of specifications; (2) understanding of specification behaviors; and (3) modification and composition of specifications.
The classification and retrieval technique for our 00 specification reuse technique has been described elsewhere [32]. This paper presents an 00 executable specification language which facilitates the understanding of specifica- tion behaviors and facilitates the modification and com- position of specifications.
3. Model of the specification language
The specification language is based on an object- oriented analysis (OOA) model. The following subsec- tions respectively describe the design philosophy of the model, the model itself, and a specification example represented in the model.
3.1. Design philosophy of the model
A software system responds to a set of stimuli, or
events, which occur in the external environment or in
the internal of the system [33,34]. An external event can be a user command, an interrupt from another sys- tem, etc. For example, a library system responds to such external event as ‘A borrower wants to borrow a book’. An internal event may occur periodically inside the sys- tem. For example, a supermarket system may periodi- cally check and print the stock levels of its selling items. The response of an event corresponds to a part of the system’s behavior. For example, suppose that a library system responds to the event ‘A borrower wants to borrow a book’ by lending the book to the borrower. Then, one will know that the library system will lend books to borrowers, which is a part of the system’s behavior. In this sense, a system’s behavior can be observed by checking its event responses. A system’s event responses are referred to as its system functions in this paper. Under this circumstance, executing a system’s system functions exhibits the system’s behavior. As
existent specifications with behaviors similar to that of an intended system are considered candidates for reuse, the reusability of a specification can be determined by checking its system functions.
Major components in an 00 specification are classes and their relationships [22]. Classes are domain-oriented. They encapsulate attributes and operations, and instan- tiate objects that exhibit specific behaviors. A class operation is referred to as a class service in this paper. Class services can be separated into two types: (1) query services (Qservices), which retrieve attribute values from objects, and (2) state transition services (STservices), which change object states. This separation will reduce the couplings among class services and hence makes classes easier to modify. The relationships among classes include association, inheritance, aggregation, using (invocation) relationships, and so on [22].
In an 00 specification, objects instantiated from classes and the instantiated objects’ class services are used by system functions, which are outside the classes. When a system function is executed, some objects are triggered. The triggered object(s) may trigger still other object(s), and the triggering continues until the system function is completed. For example, when executing the system function ‘Borrow a book’, -- the library system triggers the object ‘Book’ to change its status from ‘In-library’ to ‘Borrowed’, and triggers the object ‘Borrower’ to increase his or her borrowed amount. The triggered objects will execute their class services. This in turn will accomplish a system function. There- fore, in an 00 specification, system functions can be identified by tracing class services and invocation rela- tionships among the services.
Some OOA methods [35] do not explicitly specify sys- tem functions in specifications. Anyone who wants to understand the behaviors of such specifications may need to trace class services and invocation relationships among the services in order to identify and check system functions, because a specification’s behavior is exhibited by executing its system functions. Behaviors of such 00 specifications are thus not easy to understand. On the other hand, if an 00 specification explicitly specifies system functions, and describes how the system functions are accomplished by class services, the specification’s behavior would be easier to understand. Since our specification language must facilitate the understanding of specification behaviors, it should be based on an OOA model that explicitly specifies system functions. The next subsection describes our OOA model. Only the model is described, but not the OOA process.
3.2. The OOA model
Our OOA model is composed of two sub-models: (1) the class sub-model that specifies classes and relation- ships among classes, and (2) the function sub-model
422 S.-C. Chou et aLlInformation and Software Technology 38 (1996) 419-434
Name (instance limit)
Attribute (value limit)
[NY [tyPeI j
Type of services = ‘ST for STservices ‘Q’ for Qservices
Fig. 1. Notation for a class.
that specifies system functions. In the class sub-model, a class encapsulates attributes and services, and instan- tiates objects that exhibit specific behavior. Class services are separated into Qservices and STservices. Relation- ships among classes specified in our model include asso- ciation, inheritance, aggregation, and invocation (using) relationships.
Fig. 1 shows the notation for representing a class which is divided into three fields. The first field specifies the name and instance limit of the class, where the instance limit limits the number of objects instantiated from the class. The second field specifies class attributes and their value limits. And the last field specifies class services. Each class service is associated with a mini-spec that describes its detailed operations. To prevent information overload, class service mini-specs are not
Y \
Generalization class
shown in the notation, but described in the specification document instead. As for the relationships among classes, they are represented by the notations shown in Fig. 2. Classes and their relationships constitute the class sub-model of our OOA model. Fig. 3 illustrates an exam- ple of a class sub-model for a simplified library system which will be described shortly.
In the function sub-model, system functions are explicitly specified. Each system function is associated with a mini-spec that describes its detailed operations. Since system functions are accomplished by invoking class services, their mini-specs are described by class ser- vice invocations which are structured by these control structures: sequences, selections, and iterations. For example, the mini-spec of the system function ‘Borrow_a_book’ can be described in pseudo code as shown in Fig. 4.
When there are quite a few system functions, the list of system functions is so long that it may jeopardize read- ability of the specification: Thus, several system func- tions should be grouped into a subsystem. System functions which invoke services of the same classes are candidates to be grouped together. System functions are not specified alone in the function sub-model. Instead, they are listed in the subsystems to which they belong. System functions in a subsystem will invoke classes for services (i.e. invoke their class services). The invoked classes show the relationships between the system func- tions and the classes. Those classes are thus listed in the subsystem to which those system functions belong. Fig. 5
Whole
#
Fig. 2. Notations for relationships among classes: (a) Notation for an inheritance relationship; (b) Notation for an aggregation relationship; (c) Notation for an invocation relationship; (d) Notation for an association relationship.
S.-C. Chou et al./Information and Software Technology 38 (1996) 419-434 Book \ Status Title Identifier Author Create[STj Rernove[ST] Borrow(STj Retum[ST) Reserve[S_rl Get_status[Q] c / I Borrower Identifier Borrowed-amount Borrowing-right Amount-limit Create[Sq Remove[STj ) Increase_borrowed_amount[STl Decrease_borrowed_arnount[ST Suspend_borrowing_rigM[STJ Resume_borrowing_rigMtST] Get_borrowing_right[Q] /
Fig. 3. Class sub-model for a simplified library system
shows the notation for representing a subsystem which is divided into three fields. The first field specifies the sub- system name. The second field specifies classes invoked by the subsystem (actually, they are invoked by the sub- system’s system functions). And the last field specifies the subsystem’s system functions. Again, to prevent infor- mation overload, system function mini-specs are not shown in the notation, but described in the specification document instead.
After grouping system functions into subsystems, further grouping of those subsystems into even larger subsystems may be needed if there are many subsystems. Thus, the grouping activity will result in a hierarchy structure, called a system-subsystem hierarchy in this paper. The grouping ends when there is only one node (i.e. the system) in the root of the hierarchy. The hierar- chy constitutes the function sub-model of our OOA model. Fig. 6 illustrates an example of a function sub- model for a simplified library system which will be described shortly.
In a system-subsystem hierarchy, the system or some of its subsystems may not directly contain system func- tions and classes (e.g. the root node in Fig. 6), because they are obtained by grouping subsystems. In this case, the (sub)systems indirectly contain all the system functions and classes of their subsystems. For example,
in Fig. 6, the root node (i.e. the library system) indirectly contains all the classes and system functions that are in its two subsystems.
The system-subsystem hierarchy (i.e. the function sub- model) is used as a structure for large-scale model partitioning [36], and hence is a guidance for reading or checking the specification. When someone reads a specification, he or she first browses through its system- subsystem hierarchy to identify system functions. Then he or she checks each system function mini-spec and each class invoked by the system function.
Note that in Fig. 6, a class with the annotation ‘[PI’ means it is a private class for the subsystem. That is, the class is invoked by no subsystems other than that sub- system. Conversely, a class with the annotation ‘[S]’ means it is shared (or invoked) by several subsystems. These annotations are used for information hiding, which will be described in the next subsection.
3.3. Information hiding in the model
Modification is necessary when the reused (sub)speci- fications (or classes) do not exactly fit the intended (sub)- system (or class). As most software engineers agree, information hiding is a good feature to improve modi- fiability [37]. In our technique, classes, subsystems and
IF the book is in library, the borrower’s borrowing right is YES’, and the borrower’s borrowed amount is not over limit THEN
Invoke the service ‘Borrow’ of the class Book’ to borrow the book to the borrower.
Invoke the service ‘Increase borrowed_amount’ of the class Borrower’ to increase the borrowe?s borrowed amount.
ENDIF
424 S.-C. Chou et al./lnformation and Software Technology 38 (1996) 419-434
Name Class
System function
Fig. 5. Notation for a (sub)system.
even entire system specifications are subjected to reuse, classes and subsystem specifications (including system specifications) should thus possess the information hid- ing feature.
Classes in our model possess information hiding feature, but not subsystems. We thus rearrange subsys- tems’ contents, hoping that they will possess this feature. Basic considerations for this rearrangement are to: (1) hide the classes invoked by a subsystem within it, and (2) access those classes by means of the subsystem’s sys- tem functions. However, this rearrangement will fail when several subsystems invoke the same classes, because the shared classes cannot be hidden within any subsystem. For example, in Fig. 6, the class ‘Borrower’ are invoked by both the subsystems ‘Book-management’ and ‘Borrower-management’. To remedy that, we loosen the requirements for information hiding in subsystems so
Library-system
F
that classes can be either hidden within subsystems or shared by several subsystems. If a class is invoked by only one subsystem, the class is hidden. Conversely, if a classes is invoked by several subsystems, it is considered shared and cannot be hidden. With this rearrangement, subsystems can possess partial information hiding feature, and hence improve their modifiability.
3.4. An example
A simplified library system is used as an example here. Its functional requirements are described in brief below: A library system should manage both book and borrower status. Books in the library can be borrowed by borrowers. Borrowed books can be returned. If necessary, books can be reserved. Reserved books can- not be borrowed. When a borrower borrows books, his or her borrowed amount should be increased by the number borrowed. On the other hand, when the borrower returns books, the borrowed amount should be decreased. Borrowed amounts are limited. New books can be added and obsolete books can be discarded.
A borrower’s borrowing right can be suspended. A suspended right can be resumed. New borrowers can be added and current borrowers can be removed. Fig. 3 shows the class sub-model of the system’s specification where two classes, ‘Book’ and ‘Borrower’, are specified. An association relationship between those classes connects a borrower and the books he or she
Book-management Book[P] Borrower[S] Borrow_a_book Return-a-book Add-a-book Remove_a_book Reserve-a-book Borrower-management Borrower[S] Add_a_borrower Remove_a_borrower Suspend_a_borrowing_rigM Resume_a_borrowing_right
borrows. Moreover, there is an invocation relationship The analyst then executes system functions of the between the two classes, because when books are bor- subsystem. If the subsystem contains other subsys- rowed or returned by a borrower, the borrower’s bor- tem(s), system functions of the subsystem(s) should rowed amount should be increased or decreased. That is, also be executed, because the subsystem indirectly the services ‘Borrow’ and ‘Return’ of the class ‘Book’ contains all system functions of its subsystem(s). invoke the services ‘Increase_borrowed_amount’ and After system functions of all the specification’s sub- ‘Decrease_borrowed_amount’ of the class ‘Borrower’, systems are executed, the specification has been
respectively. executed.
Fig. 6 shows the function sub-model of the system specification. Here we partition the library system into two subsystems: one is ‘Book-management’ and the other is ‘Borrower-management’. The former sub- system’s system functions are: ‘Borrow_a_book’, ‘Return a book’, -- and so on. They are accomplished by invoking services of the classes ‘Book’ and ‘Borrower’. For example, the system function ‘Borrow a book’ is accomplished by invoking the service ‘Borrow’ of the class ‘Book’ and the service ‘Increase_borrowed_ amount’ of the class ‘Borrower’. The latter subsystem’s system functions are: ‘Add_a_borrower’, ‘Remove-a_ borrower’, and so on. They are accomplished by invok- ing services of the class ‘Borrower’. Each system function is associated with a mini-spec. For example, the mini- spec of the system function ‘Borrow a book’ is shown -- in Fig. 4. Note that in Fig. 6, the library system indirectly contains all the system functions and classes of its two subsystems.
(2) It should facilitate specification modification.
Our OOA model allows subsystems to hide as many classes as possible so that modifiability of specifications can be improved. Our specification language further enhances this modifiability by pro- viding statements to explicitly declare the relation- ships among classes and for declaring the classes invoked by subsystems. With this declarations, the dependency relationships among classes and those between system functions and classes can be con- structed. From these dependency relationships, one can identify the system functions and classes that should be modified accordingly when some classes are modified. For example, in Fig. 3, the class ‘Book’ depends on the class ‘Borrower’, because the former’s services invokes the latter’s. Thus, when the latter is modified, the former may need to be modified.
4. The specification language
This specification language provides statements to specify (sub)systems (including their system functions) and classes in an 00 specification. A (sub)system or class specified in this language is partitioned into two parts: (1) its declaration which primarily specifies inter- faces, and (2) its body which specifies specification details. In the following subsections, basic considerations of this language are first described. Then, (sub)system specifications and class specifications are respectively described. Furthermore, Appendix A specifies the simplified library system in this language.
(3) It should facilitate specification composition.
Composing software components into software systems can be facilitated by clear component inter- faces. Composing (sub)specifications is not an excep- tion. This language thus provides statements for explicitly declaring the interfaces of class services and those of system functions in order to facilitate specification composition.
4.2. (Sub)system spec$cations
4.1. Basic considerations of the language
As shown in Fig. 7, a (sub)system’s specification starts with a ‘SUBSYSTEM’ statement which specifies its name. Its declaration and body are then respectively specified. The declaration delcares classes hidden in the (sub)system, shared classes, the (sub)system’s subsystems and system functions, and interfaces of the system func- tions. The body specifies the detailed operations of the system functions.
The specification language is based on the following considerations:
In a (sub)system declaration (see Fig. 8) the following statements are used:
(1) It should facilitate specification behavior understand- ing.
As mentioned above, a specification’s behavior can be understood by executing its system functions. Sys- tem functions are thus executable units in our speci- fication language. When executing a specification, an analyst follows the specification’s system-subsystem hierarchy to locate a subsystem for the execution.
(1) ‘PRIVATE_CLASSES’ statement for declaring classes hidden in the (sub)system.
(2) ‘SHARED-CLASSES’ statement for declaring shared classes.
(3) ‘DOMINATED_SUBSYSTEMS’ statement. This statement declares the (sub)system’s subsystems, hence it can be used to declare the system-subsystem hierarchy of a specification.
426 S.-C. Chou et al./Information and Software Technology 38 (1996) 419-434
SUBSYSTEM subsystem-name
SUBSYSTEM_DECLARATION
P subsystem declaration is here *I END_SUBSYSTEM_DECLARATlON
SUBSYSTEM-BODY
/’ subsystem body is here “I END_SUBSYSTEM_BODY
END-SUBSYSTEM
Fig. 7. (Sub)system specification template.
(4) ‘SYSTEM_FUNCTIONS’ statement.
This statement is used to declare the (sub) system’s system functions and their input/ output parameters. It thus facilitates specification composition.
Parameter types are also declared here.
A (sub)system’s body (see Fig. 9) specifies detailed operations of the (sub)system’s system functions. Refer- ring to Fig. 4, system functions’ detailed operations are described by class service invocations, which are struc- tured by these control structures: sequences, selections, and iterations. Thus, service invocation statements, con- dition statements, and loop statements are needed for specifying system functions. Major statements for speci- fying system functions are described below:
(1) Service invoking statements.
A service invoking statement has the following syntax:
class name.service_name(parameter, . . . , parameter); If theinvoked service is an STservice (state transition service), no values will be returned. If the invoked service is a Qservice (query service), attribute values will be returned by means of the parameters.
A service invoking statement invokes a class ser- vice. Since a class may instantiate many objects, invoking the class’s services may affect more than one of its objects. For example, suppose that the class ‘Book’ has instantiated two objects with the same title ‘Software engineering’. .And, the service ‘Borrow’ of the class ‘Book’ lends books with a cer- tain title to a borrower. Then, if a borrower wants to borrow a book with the title ‘Software engineering’, the service ‘Borrow’ will lend both books to the bor- rower. However, the invocation of a class service should normally affect only one of the class’s objects. Thus, a class should have attribute(s) that can be used as a key so that the class’s objects can be uniquely identified by their key values. Such attribute(s) are called key attribute(s). Key attributes should be passed as parameters to class services so that invok- ing a class service will affect only one of the class’s objects.
END_SUBSYSTEM_DECLARATlON SUBSYSTEM_DECLARATlON
PRIVATE_ClASSES class-name, class_name, . . . ; SHARED-CLASSES class_name, class_name, . . . ; DOMINATED-SUBSYSTEMS subsystem_name, . . . ; SYSTEM-FUNCTIONS {
system_function_name ( parameter[l or 0 or IO]:typa, . . . );
1
Fig. 8. (Sub)system declaration.
(2) Condition statement.
A condition statement has one of the following syntax: IF condition THEN statements ELSE statements ENDIF
IF condition THEN statements ENDIF where ‘statements’ is a sequence of statements. (3) Loop statement.
A loop statement has the following syntax: WHILE condition DO statements ENDDO (4) Object retrieving statement.
Sometimes system functions must access objects. For example, to create/dissolve aggregation relationships among objects (see below), system functions must access objects. Objects must be retrieved before being accessed. Their key attributes are used to retrieve them. The following statement is used to retrieve an object from a class:
RETRIEVE object name FROM class-name WITH-KEY key-attributes;
The retrieved object is assigned to the variable ‘object-name’, which can then be used to access the object.
(5) Relationship creating/dissolving statement.
During runtime, an object of a component class can exist without being attached to an aggregated object. An aggregated object can also be created without its component objects. Moreover, an object can exist without associating with any other objects. There- fore, aggregation and association relationships are dynamic relationships during runtime, hence state- ments are needed for creating and dissolving these relationships. An aggregation relationship between two objects is created by this statement:
object-1 PART-OF object_2;
where ‘object-l’ and ‘object_2’ are objects retrieved by the object retrieving statement as described above. An association relationship between two objects is
SUBSYSTEM-BODY system-function-name ( parameter, . . . ) 1 statement; statement; (3) ‘ASSOCIATED_CLASSES’ statement.
This statement is used to declare association relation- hips among classes. Cardinalities of such relationships are also declared. For example, in the class declara- tion of the class ‘Book’, the statement ‘ASSOCIA- TED-CLASSES Borrower (0 : 1, 0 : 10)’ declares that there is an association relationship between the classes ‘Book’ and ‘Borrower’, and a borrower can borrow at most 10 books and a book can be bor- rowed by a borrower at a time.
system-function-name ( parameter, . . . ) 1
END_SUBSYSTEM_BODY
Fig. 9. (Sub)system body.
created by the statement
object-1 ASSOCIATION_OF object_2;
A relationship between two objects are dissolved by this statement
DISCONNECT object-l, object_2;
(4) ‘INVOKED_CLASSES’ statement.
This statement declares the classes whose services are invoked by the class being specified. It can thus be used to declare invocation relationships among classes. (5) ‘ATTRIBUTES’ statement.
This statement is used to declare class attributes, their value limits, and their types. For example, the state- ment ‘ATTRIBUTES Status (‘Y’,‘N’) : CHAR’ declares that the class being specified has the attribute ‘Status’ with the type ‘CHAR’, and the attribute value must be either ‘Y’ or ‘N’.
(6) ‘KEY-ATTRIBUTES’ statement for declaring the class’s key attributes.
4.3. Class specijkations
As shown in Fig. 10, a class’s specification starts with a ‘CLASS’ statement that specifies its name and instance limit. Its declaration and body are then respectively specified. The declaration declares class attributes, class services, class service interfaces, and the relationships between the class and other classes. The body specifies the detailed operations of the class’s STservices. Qservices do not need to be specified in the body, because the only operation of such services is to retrieve attribute values.
(7) ‘PROVIDED_STSERVICES’ statement.
This statement is used to declare the class’s STservices and their parameters (interfaces). Key attributes should be included in the parameters to uniquely identify objects. Parameter types should also be declared. All the parameters are for input, because STservices return no values.
(8) ‘PROVIDED_QSERVICES’ statement.
This statement is used to declare the class’s Qservices and their parameters. Parameter types should also be declared. Key attributes should be included in the parameters. They are solely for input. Other param- eters are for retrieving attribute values. They are for output.
(9) ‘REQUIRED_SERVICES’ statement for declaring class services invoked by the class being specified. In a class declaration (see Fig. 1 l), the following state-
ments are used:
(1) ‘SUPER_CLASSES’ statement.
This statement declares the class’s super-classes. It can thus be used to declare inheritance relationships among classes.
(2) ‘PART-CLASSES’ statement
The last three statements are used to explicitly specify class interfaces, hence facilitate specification composition.
A class body (see Fig. 12) specifies detailed operations of the class’s STservices. STservices of a class change states of the class’s objects. They are thus specified according to the objects’ state transitions. That is, the detailed operations of an STservice is composed of sev- eral state transitions. A state transition has this syntax: This statement declares the class’s part classes. It can
thus be used to declare aggregation relationships among classes. Cardinalities of those relationships are also declared. For example, in the class declara- tion of the class ‘Car’, the statement ‘PART_ CLASSES Wheel(O.4)’ declares that the class ‘Wheel’ is a part class of the class ‘Car’, and a car can have at most four wheels.
current-state: statements;
where ‘current-state’ denotes the state of the class’s objects whose states will be changed after the STservice is executed, and ‘statements’ is a sequence of statements that specifies the operations of the state transition. When an STservice of a class is executed, states of the class’s
428 S.-C. Chou et aLlInformation and Software Technology 38 (19%) 419-434
CLASS class_name(instance_limit) CLASS_DECM?ATlON
p class declaration is here l / END_CLASS_DECLARATION CLASS-BODY
F class body is here *I END_CLASS_BODY END-CLASS
Fig. 10. Class specification template.
objects are checked. The object with the same state as that specified in a state transition’s current state (i.e. ‘current-state’ above) are first identified. The statements specified in the state transition are then executed to change the identified object’s state.
The current state in a state transition (i.e. ‘current-state’ as described above) takes the form:
(expression_l,expression_2, . . .)
where the values of ‘expression-l’, ‘expression_2’, etc. correspond to the values of the first, second, etc. attri- butes of the object, respectively. In general, the values of all attributes constitute an object state. However, in some STservices, not all attributes are needed to specify the state transitions. The ‘USED-ATTRIBUTES statement
is used to define the attributes used in an STservice. Attributes that can be used by a class’s STservices include attributes of its own and those of its super- classes. To ensure that the invocation of a class service will change the state of only one of the class’s objects, key attributes should be included in the used attributes.
There is a special current state used in STservice specifications: ‘( )‘. It means null state. That is, the object is not existent. This state is used to specify the STservices that create or remove an object.
A state transition is composed of a state change opera- tion and some other operations (e.g. operations to invoke other services). Thus, to specify state transitions in STservices, all the statements for specifying system functions mentioned above can be used. Moreover, this language provides a state change statement for STservices. It has the following syntax:
NEW-STATE-IS new-state;
where ‘new-state’ takes the same form as ‘current-state’ described above.
5. Usage of the specikation language
The process to specify a car rental system by reusing existent specifications is used to illustrate the usage of the specification language. Functional requirements of the
CLASS_DECLARATION
SUPER-CLASSES class_nama, class_name, . . . ;
PART-CLASSES class_name(cardinality), class_name(cardinality), . . . ; ASSOClATED_CLASSES class_name(cardinalii), class_name(cardinality), . . . ; INVOKED_ClASSES class-name, class_name,...;
ATTRIBUTES attribute_name(value_limit): type, attribute_name(value_limit): type, . . . ; KEY-ATTRIBUTES attribute_name,atbibute_name,...;
PROVIDED_STSERVICES {
STservice_name(parameter: type, parameter: type, . ..). STservice_name( . . . )
PROVIDED_QSERVICES {
Qservice_name(parameter@ or 01: type, paratneterfl or 0): type, . ..). Qservice_name( . . . )
REQUlRED_SERVlCES (
class_name.service_name, class_name.serviae_name,...; )
END_CLASS_DECLARATlON
CLASS-BODY
STservice_name(parameter, . ..) 1
USED_ATfRIBUTES: sttribute_name, attribute-name, . . . .
current_stat_l: statements;
current_state_2: statements;
Chou and Technology 38 (1996) 419-434
‘Borrow_a_book’ is shown in the figure. After the execution of this system function, the state of the object ‘Book’ with identifier ‘1001’ is changed from ‘(1001, :‘In_library”)’ to ‘(1001, “Borrowed”)’ and the state of the object ‘Borrower’ with identifier ‘1001’ is changed from ‘(1001,O)’ to ‘(1001,l)‘. After observing the output data and state changes due to the execution of all the specification’s system functions, the analyst can under- stand the specification’s behavior to a certain degree of detail.
STsenrice_name(paramster,...) (
END_CLASS_BODY
Fig. 12. Class body.
car rental system are described in brief below:
The car rental system manages both car and custo- mer status. Cars in the system can be rented by custo- mers. Rented cars can be returned. Moreover, cars can be sold. When a customer rents cars, his or her rental amount should be increased by the number rented. On the other hand, when the customer returns cars, the rental amount should be decreased. New cars can be added and obsolete cars can be discarded.
A customer’s renting right can be suspended. A sus- pended right can be resumed. New customers can be added and current customers can be removed. The system also manages its employee’s status, such as sal- aries and work times. New employees can be added and current employees can be removed.
After understanding the behaviors of the retrieved candidates and filtering out the unreusable ones, the analyst reads the other candidates and selects some for reuse. If the reused ones do not exactly fit the intended system, they should be modified. For example, suppose that the library system specification is reused for the car rental system. Then, the following modifications should be performed: (1) the class ‘Borrower’ of the library sys- tem should be renamed to be ‘Customer’, (2) the class ‘Book’ should be renamed to be ‘Car’, (3) attributes of the reused classes should be modified, for example, the attribute ‘Author’ should not be an attribute of the class ‘Car’ and hence should be deleted from the reused class ‘Book’, (4) services of the reused classes should be modified, for example, the service ‘Sell’ should be a service of the class ‘Car’ and hence should be added, and (5) system functions should be modified, for example, a new system function ‘Sell_a_car’ should be added.
In the reuse process, suppose that after specification retrieval, the library system specification (see Figs. 3 and 6, and Appendix A) and some other specifications are retrieved as candidate reusable specifications. For these candidates, the analyst executes them to observe their behaviors so that the unreusable ones can be filtered out. When executing a specification, the analyst first follows the system-subsystem hierarchy to select a subsystem. He or she then executes the subsystem’s system functions. When executing a system function, the analyst first keys in its input data, then observes the output data and object state changes after the execution. Fig. 13 shows the execution of the library system specification (as specified in Appendix A) where the subsystem ‘Book-management’ is selected to execute. The execution of the subsystem’s system function
After specifying all subsystems of the car rental sys- tem, the analyst composes the subsystems to form a com- plete specification for the system. The composition can be accomplished by defining relationships among classes and constructing the system-subsystem hierarchy. For example, suppose that the analyst reuses the library sys- tem and an employee management subsystem of a par- ticular specification to specify the car rental system, where the employee management subsystem contains the class ‘Employee’. Then, the specification of the car rental system is depicted in’Figs. 14 and 15, where the former figure shows the class sub-model and the latter shows the function sub-model.
6. Conclusions
Techniques for specification reuse, design document reuse, and program code reuse can be integrated to sup- port a reuse-based software development paradigm, which can tremendously improve software development productivity and software quality. Object-oriented devel- opment further fosters software reuse.
In specification reuse, candidate reusable specifica- tions are retrieved from a repository, where some are reusable and others not. The unreusable ones should be filtered out before an analyst reads the candidates to
430 S.-C. Chou et al./Information and Sojiware Technology 38 (1996) 419-434
ir
c
se1 Cusr/choulX LengInt
Specification to be executed: Library-system
i Th e specification ‘Library-system has these subsystems:
I
I Book_management Borrower-management
j Select a subsystem to execute: Book-management
The subsystem ‘Book_management’ has these system functions:
Borrow_a_book Bdd_a_book Reserve_a_book
Return-a-book Rerove_a_book
i Select a system function to execute: Borrow_a_book
Key in input data:
Book-identifier: 1001
Borrower-identifier: 1001
Execution results: 1 Output data:
/ Object state changes:
I Book: <1001.“In_library”> -> <lOOl.“Borrowed”> Borrower: <lOOl.O> -> <lOOl,l>
The subsystem ‘Book_management’ has these system functions:
Borrow_a_book Rdd_a_book Reserve-a-book
Return-a-book Rerove_a_book
Select a system function to execute: 0
i -_- - v_-. -
Fig. 13. Execution of the library system specification.
understand them. This filtering can be accomplished by observing the candidates’ behaviors, because specifica- tions with behaviors dissimilar to that of the intended system cannot be reused and hence can be filtered out. A specification’s behavior can be easily observed by executing the specification. To make specifications executable, an executable specification language is
needed. This paper presents an executable specification language for specification behavior understanding in 00 specification reuse. Since a specification’s behavior can be understood by executing its system functions, this language is based on an OOA model that, in addition to classes, explicitly specifies system functions, which are further grouped into subsystems.
/car Customer f Employee Status Identifier Rental-amount identifier Model Identifier Renting-right Salary Work-time Owner Create[Sq Remove[ST] Create[STj
Create[STl Increase_rental_arnount[Sq Remove[STl
Rernove[Sq
d Decrease_rental_amount]S~ Increase_salary[Sq
Rent[ST] Suspend_renting_right[STj Uecrease_salary[ST]
Return[STJ Update_work_time[ST)
Sell[ST] Get_renting_right[Q] Resume_renting_right[ST] Get_satary[Q] Get_status[Q]
\ t_rental_amount[Q]
Get_work_time[Q]
S.-C. Chou et al./Information and Software Technology 38 (1996) 419-434 Car_rental_systern Car-management Car[P] Customer[S] Rent-a-car Return-a-car Add-a-car Remove-a-car Sell-a-car I Customer_management 1 Customer[S] Add-a-customer Remove_a_customer Suspend-a-renting-right Resume-a-renting-right Employee-management Employee[P] Add-an-employee Remove-an-employee Update-salary Update_work_time
Fig. 15. Function sub-model for a car rental system.
This language offers the following features: Council, ROC, under project number NSCSl-040% 1009-542.
(1) It facilitates specification behavior understanding.
This language provides executable statements for specifying system functions. A specification’s behav- ior can thus be understood by executing its system functions. Since system functions will invoke class services during execution, this language also provide executable statements for specifying class services.
Appendix A
The simplified library system’s specification written in the proposed specification language is listed below.
(2) It facilitates specification modification.
To facilitate specification modification, this language hides as many classes as possible within subsystems so that they possess partial information hiding fea- ture. In addition, this language provides statements for explicitly declaring the relationships among classes and for declaring the classes invoked by sub- systems. This allows the language interpreter to con- struct dependency relationships both among classes and between system functions and classes. From the dependency relationships, one can identify the system functions and classes that should be modified accord- ingly when some classes are modified.
(3) It facilitates specification composition.
Composing software components into software sys- tems can be facilitated by clear component interfaces. Composing(sub)specifications is not an exception. This language thus provides statements for explicitly declaring the interfaces of class services and those of system functions to facilitate specification composition.
Acknowledgment SUBSYSTEM Library-system SUBSYSTEM_DECLARATION DOMINATED_SUBSYSTEMS Book-management, Borrower-management; END_SUBSY STEM-DECLARATION END-SUBSYSTEM SUBSYSTEM Book-management SUBSYSTEM_DECLARATION PRIVATE-CLASSES Book; SHARED-CLASSES Borrower; SYSTEM_FUNCTIONS { Borrow_a_book (Book_identifier[I]:INTEGER, Borrower_identifier[I]:INTEGER); Return-a-book (Book_identifier[I]:INTEGER, Borrower_identifier[I]:INTEGER); Reserve_a_book(Identifier[I]:INTEGER); Add_a_book(Identifier[I]:INTEGER, Status[I]:STRING, Title[I]:STRING, Author[I]:STRING); Remove_a_book(Identifier[I]:INTEGER);
I
432 S.-C. Chou et aLlInformation and Software Technology 38 (1996) 419-434 SUBSYSTEM-BODY Borrow_a_book(Book_identifier, Borrower-identifier) { Borrower.Get_borrowed_amount (Borrower_identifier,amount); Borrower.Get_amount_limit (Borrower_identifier,limit); Borrower.Get_borrowing_right (Borrower_identifieqright); Book.Get_status(Book_identifier,status); IF((status = = “In-library”) AND
(amount < limit) AND (right = = ‘Y’))THEN Book.Borrow(Book_identifier,
Borrower-identifier);
RETRIEVE book FROM Book WITH-KEY Book-identifier;
RETRIEVE borrower FROM Borrow& WITH-KEY Borrower-identifier;
book ASSOCIATION_OF borrower; ENDIF > Return_a_book(Book_identifier, Borrower-identifier) { Book. Return(Book_identifier, Borrower-identifier);
RETRIEVE book FROM Book WITH-KEY Book-identifier;
RETRIEVE borrower FROM Borrower WITH-KEY Borrower-identifier; DISCONNECT book,borrower; > Reserve_a_book(Identifier) { Book.Reserve(Identifier); 1 Add_a_book(Identifier,Status,Title,Author) { Book.Create(Identifier,Status,Title,Author); > Remove_a_book(Identifier) { Book.Remove(Identifier); 1 END_SUBSY STEM-BODY END_SUBSY STEM SUBSYSTEM Borrower-management SUBSYSTEM_DECLARATION SHARED_CLASSSES Borrower; SY STEM_FUNCTIONS { Add_a_borrower(Identifier[I]:INTEGER, Borro- wed_amount[I]:INTEGER, Borrowing_right[Ij:CHAR, Amount_limit[I]:INTEGER); Remove_a_borrower (Identifier[I]:INTEGER); Suspend_a_borrowing_right (Borrower_identifier[I]:INTEGER); Resume_a_borrowing_right (Borrower_identifier[I]:INTEGER); > END_SUBSY STEM-DECLARATION SUBSYSTEM-BODY Add-a-borrower (Identifier,Borrowed_amount, Borrowing_right,Amount_limit) { Borrower.Create(Identer,
Borrowed amount, Borrowing-right, Amount-limit); > Remove_a_borrower(Identifier) { Borrower.Remove(Identifier); 1 Suspend_a_borrowing_right (Borrower-identifier) ( Borrower.Suspend_borrowing_right (Borrower-identifier); 1 Resume_a_borrowing_right (Borrower-identifier) { Borrower.Resume_borrowing_right (Borrower-identifier); 1 END_SUBSYSTEM_BODY END-SUBSYSTEM CLASS Book CLASS_DECLARATION ASSOCIATED_CLASSES Borrower(0: 1 ,O: 10); ATTRIBUTES IdentifierINTEGER, Status:STRING,Title:STRING, Author:STRING; KEY-ATTRIBUTES Identifier; PROVIDED_STSERVICES { Create(Id:INTEGER,Sta:STRING, Tit:STRING,Aut:STRING); Remove(Id:INTEGER); Borrower(Book_id:INTEGER, Borrower_id:INTEGER); Return(Book_id:INTEGER, Borrower_id:INTEGER); Reserve(Id:INTEGER); > PROVIDED_QSERVICES { Get_status(Identifier[Ij:INTEGER, Status[O];STRING);
S.-C. Chou et al./Information and Software Technology 38 (1996) 419-434
1
REQUIRED_SERVICES { Borrower.Increase_borrowed_amount, Borrower.Decrease_borrowed_amount; 1 END_CLASS_DECLARATION CLASS-BODY Create(Id,Sta,Tit,Aut) { USED-ATTRIBUTES IdentifierStatus, Title,Author; <>: NEW_STATE_IS(Id,Sta,Tit,Aut); > Remove(Id) { USED-ATTRIBUTES Identifier; (Id): NEW-STATE-IS<>; > Borrow(Book_id,Borrower_id) { USED-ATTRIBUTES IdentifierStatus; (Book_id,Status): Borrower.Increase_borrowed_amount (Borrower-id); NEW_STATE_IS(Book_id,“Borrowed”); > Return(Book_id,Borrower_id) { USED-ATTRIBUTES IdentifierStatus; (Book_id,Status): Borrower.Decrease_borrowed_amount (Borrower-id); NEW_STATE_IS(Book_id,“In_library”);I
Reserve(Id) { USED-ATTRIBUTES IdentifierStatus; (Id,Status):NEW_STATE_IS (Id,“Reserved”) ; 1 END-CLASS-BODY END-CLASS CLASS Borrower CLASS_DECLARATIONASSOCIATED_CLASSES Book(0: 10,O: 1); ATTRIBUTES Identifier:INTEGER, Borrowed_amount:INTEGER, Borrowing_right:CHAR, Amount_limit:INTEGER; KEY-ATTRIBUTES Identifier; PROVIDED_STSERVICES { Create(Id:INTEGER,B_amount:INTEGER, B_right:CHAR,A_limit:INTEGER); Remove(Id:INTEGER); Increase_borrowed_amount (B_id:INTEGER); Decrease_borrowed_amount (B_id:INTEGER); Suspend_borrowing_right (B_id:INTEGER); Resume_borrowing_right (B_id:INTEGER); > PROVIDED_QSERVICES { Get_borrowed_amount (Identifier[I]:INTEGER, Borrowed_amount[O]:INTEGER); Get-borrowing-right (Identifier[I]:INTEGER, Borrowing_right[O]:CHAR); Get_amount_limit(Identifier[I]:INTEGER, Amount_limit[O];INTEGER); > END_CLASS_DECLARATION CLASS-BODY Create(Id,B_amount,B_;_ight,A_limit) { USED-ATTRIBUTES Identifier, Borrowed amount,Borrowing_right, Amount_limit; <>: NEW-STATE-IS (Id,B_amount,B_right,A_limit);
I
Remove(Id) { USED-ATTRIBUTES Identifier; (Id): NEW-STATE-IS< >; 1 Increase_borrowed_amount(B_id) { USED-ATTRIBUTES Identifier, Borrowed_amount; (B_id,Borrowed_amount): NEW-STATE-IS (B_id,Borrowed_amount+l); Decrease_borrowed_amount(B_id) { USED-ATTRIBUTES Identifier, Borrowed_amount; (B_id,Borrowed_amount) : NEW-STATE-IS (B_id,Borrowed_amount-1);I
Suspend_borrowing_right(B_id) { USED-ATTRIBUTES Identifier, Borrowing-right;434 S.-C. Chou et aLlInformation and Software Technology 38 (1996) 419-434 (B_id,Borrowing_right); NEW_STATE_IS(B_id,‘N’); > Resume_borrowing_right(B_id) { USED-ATTRIBUTES Identifier, Borrowing-right; (B_id,Borrowing_right): NEW_STATE_IS(B_id,‘Y’); END-CLASS-BODY END-CLASS References PI PI [31 [41 [51 [61 [71 [81 [91 HOI 1111 [121 [131 [141 [151
T. Biggerstaff and C. Richter, Reusability framework assessment, and directions, IEEE Software, 4 (March 1987) 41-49.
V.R. Basili and H.D. Rombach, Support for comprehensive reuse, Software Eng. J., 6 (1991) 303-316.
WC. Lim, Effects of reuse on quality, productivity, and eco- nomics, IEEE Software, 11 (September 1994) 23-30.
G. Fischer, S. Henninger and D. Redmiles, Cognitive tools for locating and comprehending software objects for reuse, in Proc. 13th Int. Conf. on Soft. Eng., 1991, pp. 318-328.
B.A. Burton, R.W. Aragon, S.A. Bailey, K.D. Koehler and L.A. Mayes, The reusable software library, IEEE Software, 4 (July 1987) 25-33.
M. Lenz, H.A. S&mid and P.F. Wolf, Software reuse through building blocks, IEEE Software, 4 (July 1987) 34-42.
D.-J. Chen and P.J. Lee, On the study of software reuse using reusable C++ components, J. Syst. Software, 20 (1993) 19-36. B.M. Kennedy, Design for object-oriented reuse in the OATH library, J. Object-Oriented Progr., 5 (July/August 1992) 51-57. P. Johnson and C. Rees, Reusability through fine-grain inheri- tance, Software Pratt. Experi., 22 (1992) 1049-1068.
A. Podgurski and L. Pierce, Retrieving reusable software by sampling behavior, ACM Trans. Softw. Eng. Methodol., 2 (1993) 286-303.
S. Henninger Using iterative refinement to find reusable software, IEEE Software, 11 (September 1994) 48-59.
M.D. Lubars, The IDeA design environment, in Proc. 1 lth Int. Conf. on Soft. Eng., 1989, pp. 23-32.
M.D. Lubars and M.T. Harandi, Knowledge-based software design using design schemas, in Proc. 9th Int. Conf. on Soft. Eng., 1987, pp. 253-262.
S. Katz, CA. Richter and K.-S. The, PARIS: a system for reusing partially interpreted schemas, in Proc. 9th Int. Conf. on Soft. Eng.,
1987, pp. 377-385.
G. Arango, E. Schoen and R. Pettengill, A process for consolidat- ing and reusing design knowledge, in Proc. 15th Int. Conf. on Soft. Eng., 1993, pp. 231-242. M [171 [181 [191 [201 [211 [221 [231 [241 v51 PI [271 PI PI [301 [311 1321 [331 [341 [351 [361 [371
D.J. Chen and D.T.K. Chen, An experimental study of using reusable software design frameworks to achieve software reuse, J. Object-Oriented Progr., 7 (1994) 56-67.
S. Khajenoori, D.G. Linton and CA. Morris, Enhancing software reusability through effective use of the essential modelling approach, Inf. and Soft. Technol., 36 (1994) 495-501.
N. Maiden, Analogy as a paradigm for specification reuse, Software Eng. J., 6 (1991) 3-15.
A. Finkelstein, Reuse of formatted requirements specifications, Software Eng. J., 3 (1988) 186-197.
N.A.M. Maiden, Saving reuse from the noose: reuse of analogous specifications through human involvement in reuse process, Inf. and Soft. Technol., 33 (1991) 780-790.
N.A. Maiden and A.G. Sutcliffe, Exploiting reusable specifica- tions through analogy, Comm. ACM, 35 (1992) 55-64. G. Booth, Object Oriented Analysis and Design with Applica- tions, 2nd edn., Benjamin/Cummings, 1994.
B. Meyer, Object-Oriented Software Construction, Prentice-Hall, Englewood Cliffs, NJ, 1988.
B. Meyer, Reusability: the case for object-oriented design, IEEE Software, 4 (March 1987) 50-64.
J.A. Lewis, S.M. Henry, D.G. Kafura and R.S. Schulman, An empirical study of the object-oriented paradigm and software reuse, in Proc. OOPSAL’91, 1991, pp. 184-196.
R. Helm and Y.S. Maarek, Integrating information retrieval and domain specific approaches for browsing and retrieval in object-oriented class libraries, in Proc. OOPSAL’91, 1991, pp. 47-61.
P. Coad, Object-oriented patterns, Comm. ACM, 35 (1992) 152- 159.
R.S. Pressman, Software Engineering: A Practitioner’s Approach, 3rd edn, McGraw-Hill, 1992.
R.P. Diaz and P. Freeman, Classifying software for reusability, IEEE Software, 4 (January 1987) 6-16.
E. Ostertag, J. Hendler, R.P. Diaz and C. Braun, Computing similarity in a reuse library system: an AI-based approach, ACM Trans. Soft. Eng. Methodol., 1 (1992) 205-228.
P. Devanbu, R.J. Brachman, P.G. Selfridge and B.W. Ballard, LaSSIE: a knowledge-based software information system, in Proc. 12th Int. Conf. on Soft. Eng., 1990, pp. 249-261.
S.-C. Chou and J.-Y. Chen, A behavior-based classification and retrieval technique for object-oriented specification reuse, sub- mitted to Software Pratt. Exper. for publication.
S.M. McMenamin and J.F. Palmer, Essential Systems Analysis, Yourdon Press, New York, 1984.
E. Yourdon, Modern Structured Analysis, Prentice-Hall, Engle- wood Cliffs, NJ, 1989.
P. Coad and E. Yourdon, Object-Oriented Analysis, 2nd edn, Prentice-Hall, Englewood Cliffs, NJ, 1991.
R.G, Fichman and C.F. Kemerer, Object-oriented and conven- tional analysis and design methodologies, comparison and critique, IEEE Comput., 25 (1992) 22-39.
D.L. Parnas, On the criteria to be used in decomposing systems into modules, Comm. ACM, 15 (1972) 1053-1058.
