An environment for specification reuse - CiteSeerX

An environment for specification reuse Roberto Bellinzona*, Maria Grazia Fugini1**, Barbara Pernici*

* Politecnico di Milano ** Universita' di Pavia

Abstract Reuse in the early development phases of an application can reduce the effort of producing specifications and improve their quality. The paper presents the requirement specification phase for object-oriented applications under a reuse approach. Object-oriented specifications are reused by accessing a repository of reusable components and by adapting them to the application requirements. A model for specifications reuse based on the composition approach is presented; the model is also used to encode development knowledge guiding in the specification activity. Specification reuse is supported by a tool to select reusable components and to guide the developer in tailoring the components to the needs of a specific application. The RECAST tool (REquirement Composition And Specification Tool) presented in the paper has functionalities for retrieving reusable components from a repository and functionalities driving the composition and tailoring activities, on the basis of knowledge about the development process stored in the repository.

1. Introduction In this paper, we address the problem of applying the reuse approach to software development to the early phases of application development, reusing software specifications. The proposal considers a model both for reusable specifications and for the reuse process, and an environment for application development based on reuse; the environment consists of a repository of reusable components and of tools to support reuse of components contained in the repository. The premise is that the reuse process can mean more than simply code reuse and can involve also reuse of development information, according to the growing trend towards reuse of all artifacts related to application development, starting from specifications [Krue92]. The framework of our approach is an environment for development of object-oriented applications; coherently, the development process is object-oriented, with correspondence links between classes at the specification, design, and code levels. The development system, centered on a 1. mailing address: M. G. Fugini Politecnico di Milano Piazza Leonardo da Vinci, 32 I-20133 Milano MI, Italy ph. +39-2-2399.3526 fax +39-2-2399.3411 e-mail [email protected]

2

An environment for specification reuse

repository of software artifacts, supports a coherent reuse along the various phases of application development. In particular, the paper describes the object-oriented specification phase and its support tool. The organization of software artifacts in libraries (or repositories) for reuse purposes has been a common approach since a few years; library functionalities support the designer in storing and retrieving reusable components. [Prie91] presents a reuse library where software components are classified using a facet classification schema; the adaptation effort is evaluated via a fuzzy logic approach applied to the facets schema. More generally, the problem of classifying in a meaningful way, and to find reusable components within a library, or a software repository, is recognized as basic for the effectiveness of reuse [Krue92]. Software component classification is mainly manually executed via keywords, facets, functional descriptions, and so on; alternatively, automatic classification schemas [Maar91], typical of document retrieval systems, seem to be useful only in presence of a great amount of documentation associated with software components. Querying and browsing functionalities are usually supported by software library systems. In [Deva91], development knowledge is stored in a knowledge base where software components are organized in a semantic network; software descriptions are grouped in frames, and automatically classified. Reuse can also affect the specification phase of an application. Under this consideration, specification components can be stored and reused analogously to code components. [Fink88] and [Maid92] present an analogy-based paradigm providing different types of selection strategies for reusable components. Rules and knowledge representation mechanisms guide the reuse task and tools support the reuse process. Domain knowledge is at the basis of the reuse approach described in [Reub91], centered on requirement acquisition based on artificial intelligence techniques. Templates, named cliche', are stored in a cliche' library and represent the commonly occurring structures of one domain; application analysis is accomplished via cliche' instantiation. The focus is on incompleteness, detection and resolution of contradictions, disambiguation. The RA (Requirements Apprentice) tool assists the analyst by maintaining a list of analysis issues to be resolved. In this paper, we describe the approach to specification reuse developed in the ITHACA Project1 [Fugi92]: a repository stores all artifacts related to specification, detailed design and implementation and a set of tools support application development under reuse via access to the repository. The Software Information Base (SIB) [Cons93], in which software artifacts are described using a knowledge representation language and can be explored via browsing and querying tools, is employed. The paper presents the model for reusable specification components, whose concepts extend object-orientation to comprehend application behaviour aspects useful at the specification stage. According to this model, specification components are defined and stored as reusable classes in the repository and the specification process, that is, development knowledge, in form of reuse suggestion classes. Development by reuse defined in reuse sugges1. ESPRIT II Project "Integrated Toolkit for Highly Advanced Computer Applications" 1989-1992.

R. Bellinzona, M. G. Fugini, B. Pernici

3

tion classes is based on the development method, called IOOM (Ithaca Object-Oriented Methodology), defined in [DeAn91]. The method guides the developer in performing some design operations to compose reusable components in an application specification. Reuse suggestions contain also directions for retrieval of reusable components from the repository, based on descriptions of components and on browsing tools. The main contribution of the paper is to present the definition of an environment to guide the developer in reusing specifications and of a model to represent reusable components in a structured way. First, the approach to reuse of specifications is presented in Sect. 2. The specification model for the definition of reusable components and reuse suggestions, and the organization of reuse information are illustrated in Sect. 3. In Sect. 4, the RECAST (Requirements Composition and Specification Tool) tool is illustrated, supporting reuse of specifications in the ITHACA approach. Retrieval functionalities of RECAST, supporting the user in searching for useful classes in the repository, and composition functionalities of RECAST, providing active assistance in reusing the classes, i.e., in adapting them into the current specifications according to the ITHACA method, are illustrated. Finally, examples of specification development with RECAST are given, discussing the achieved results.

2. The Approach Specification reuse is performed according to an overall paradigm which traces the specification-design-implementation phases, describing how a set of specification components can be mapped into a set of detailed design components and eventually into a set of implementation components. The mapping of components obtained at each phase is described by correspondence links between components, stored in the SIB repository [Bell93]. In the present paper, we center the discussion on tools to support the development of specifications based on reuse; therefore, the subsequent phases are not illustrated in this paper. The interested reader can refer to [Cons93] and [Bell93] for references to technical details. The approach to reusable specifications consists of providing a formal model [DeAn91] of object-oriented reusable specifications targeted at object-oriented applications and explicitly at reuse. The first characteristic of the approach is that reuse is assumed to occur by composition of reusable classes. Reusable components are modeled as classes with structural and behavioral properties. Such properties are organized in so called "roles", to facilitate the selection of appropriate properties according to the requirements of the application being developed. The second characteristic of the approach is that knowledge on the specification process is encoded using the same formal model used for reusable specifications. This knowledge is coded in reuse suggestion classes that assist the designer in adapting the component to the specific application needs. These suggestions describe the operations that may be performed to tailor components, to compose specifications, to partition a specification into sub-parts to perform a more focused and more detailed development, and to retrieve related components useful for the completion of

4


the specification. Relevance is given to the process of finding useful components from the repository, using a method based on keywords describing the component behaviour, and on the concept of "similar" components. Fig. 1 shows the information flow characterizing the specification phase; also the tools supporting the different steps are indicated; they will be illustrated in the following paragraph.

REPOSITORY OF REUSABLE COMPONENTS

Analysis of Reuse

reqs

Requirement Analysis

reqs + selected components

Specification specs + additional info

additional info

• IOOM (OO analysis part)

• Tours and selection from repository

SPECIFICATION PHASE Figure 1

Detailed Design

request for modification

• Composition and tailoring of reusable specifications

• Suggestions according to correspondence links stored in the SIB

• Recast

• Vista (Visual Scripting)

• Recast • SIB

specs

• SIB • IOOM (OO conceptual design part)

• SIB

Diagram of the information flow in the specification phase. Shadowed boxes denote support tools. Once an analysis step over the target system has been performed, the captured requirements are the basis for a search in the repository to formally specify them. The specification phase is followed/interleaved with detailed design occurring via visual scripting.

First, a requirement analysis step is performed aimed at identifying procedures performed in the organization, their goals, information/documents supporting them, and agents performing them. The phase is driven by the IOOM method (object-oriented analysis part). An analysis of reuse step is subsequently accomplished in order to identify reusable specifications suitable for the application being developed. To this purpose, the repository content is searched and browsed and the documentation associated with reusable components is examined. The reusable specifications suitable for the current application are selected from the repository. During the specification step, selected reusable components are composed and tailored, based on requirements of the application being developed. The links to detailed design components stored in the SIB support the mapping of specifications during the detailed design phase, following the specification phase.


5

The steps illustrated in Fig. 1 are not performed sequentially, but rather, steps are reiterated, due, for instance, to further information provided while performing the composition and tailoring activities which may result in the selection of new reusable components.

2.1 Architecture of the development environment The tools supporting reuse of specifications are part of the development environment realized during the ITHACA project, which focuses on reuse of object-oriented components in all the development phases of object-oriented applications. The overall architecture of the environment is depicted in Fig. 2. The environment is composed of tools for high level specification, for detailed design, for implementation of object-oriented code, and for long-term storage of reusable components [Fugi92]. In the present paper, we focus on RECAST assisting the application developer in the specification phase. A companion tool, called VISTA [Bell93], assists in the construction of detailed designs on the basis of visual scripting of executable components. The technique used by both tools is the composition respectively of specification and design components extracted from the repository [Bell93]. Code-related tools allow the implementors to extract reusable code from the repository and to adapt it according to the specifications and design. Recast

Vista

o-o code implementation tools

Selection Tools

Repository of reusable components (Software Information Base)

Figure 2

Architecture for application development. The application developer employs the tools to find reusable components from the repository and to compose and adapt them. Reusable specification composition is supported by RECAST; VISTA supports the detailed design of components; tools for programming objectoriented code support the implementation step. The Selection Tools browse and query the repository on behalf of the tools; the Software Information Base repository describes reusable software artifacts.

Long-term storage of components and of related reuse information is provided by the Repository of reusable components, for which the Software Information Base (SIB) [Cons93] is used. The repository is organized as a semantic network whose nodes are specification classes, design classes and implementation classes; each class is an engineered description of a devel-

6


opment product extracted from previous applications. Access to the repository occurs via Selection Tools composed of browsing and querying functionalities. The purpose of RECAST is to assist the designer in finding specification components in the repository with the support of the Selection Tools, in composing them to form the specification of an application schema, and in providing suggestions for elements to be selected for the following detailed design phase. Access to the SIB by RECAST occurs via Selection Tools, which have been expanded to allow browsing of both the repository and the specifications being composed, and to pose queries using both components specification features (e.g. roles) and using keywords describing components functionalities.

3. Reuse based specification Once the requirement analysis step has identified the agents, procedures and information involved in the application being developed, these elements are formally represented in the specification step. Object-orientation is used in the specification phase to improve the effectiveness of the development cycle, for two reasons. First, object orientation facilitates the composition approach at the basis of our reuse approach; second, it is convenient to use a uniform modeling approach in all the development phases [Hend90]. In the present section, we illustrate the elements at the basis of the approach: the basic elements of the model for requirement specification, the information associated with reusable components to facilitate their reuse, and the organization of reuse information in the repository.

3.1 Specification model We adopt F-ORM (Functionality in Objects with Roles Model [DeAn91]) as the specification model. The main characteristic of the F-ORM model is to enrich the class concept used at the specification modeling level with that of role, to represent different concurrent behaviours of an object in its life-cycle. A role provides a view on the behavior of an object limited to a particular context of use of the object. For instance, in Fig. 3, the role "check" associated to OrderProcessing contains all information relevant for checking an order. Roles are a useful element during specification development, since they may constitute a unit of reuse. For instance, the developer may decide that a "check" role is not needed during order processing since orders have already been checked in another department of the organization and they can be considered always correct in the application currently being developed. A state transition diagram is associated with the role to specify the typical sequences of messages received and sent within a given role. For instance, in Fig. 3, the state-transition diagram of role "receive" is illustrated, showing how the messages involved in the receipt of an order are sequenced.


7

F-ORM classes are divided into process classes and resource classes; the former are used to represent the tasks of procedures, the latter define agents and information involved in procedure execution.

OrderAdmin.

start/stop

OrderProcessing

Order base-role

Client

order-info no-more-info

check

check

Account Processing

base-role order-info

checking

execute-info

executing

regret-info execute

compiling

check-info

execute

check

Warehouse Processing

receive

rejecting

reject

state/transition diagram of role receive send add-role(check)

send create-object(Order) receive start

starting

receive order-info

compiling order

receive no-more-info

order receive

receive order-info

Figure 3

Example of a F-ORM specification related to order processing. The specification includes: the OrderProcessing class that defines the tasks of the procedure for order processing; the OrderAdministrator class that activates the order procedure; the Order class that represents a description of the order information (it has various roles according to the processing status of the order); a Client class representing the source of information about the order; a set of services related to Warehouse and Account processing. Message exchange is represented via links among class roles. The behaviour of the 'receive' role of OrderProcessing is detailed in a state/transition diagram.

A reusable unit, called component, is either a F-ORM class or a role. Specifications are built out of components retrieved from the repository. The retrieval and composition functions are based on reuse suggestions associated with F-ORM classes stored in the repository, as shown in the following paragraphs.

3.2 Reuse suggestions Reuse suggestions provide guidelines to application developers to select, compose, and tailor reusable components. Reuse suggestions are also modeled as F-ORM classes ("suggestion classes"), describing elements useful for supporting the reuse of a (set of) components.

8


In the following, we assume that a reuse suggestion class is associated with each reusable component, and it is the basis for retrieving and adapting the component. In Fig. 4, we show a template for reuse suggestion classes, as they are internally stored. Suggestions are presented by RECAST in form of "suggestion cards", as discussed in the following sections. Examples are illustrated in the appendix. Information needed to select reusable components is static in nature, since it indicates different features typical of the component. Therefore, class properties are used to represent this structural information. Structural information includes structural links to other classes, and keywords associated to a reusable class to allow retrieval of the class based on its characteristics. Structural links represent links to ancestor classes, referenced classes, and component classes for a given specification class. Structural links are subdivided in necessary and possible links. Necessary links indicate components to be selected or defined to keep the specifications consistent. Possible links indicate optional components, which might be useful in completing the specifications. Keywords are associated to classes in the form of Functional Descriptions. A Functional Description represents synthetically the services that can be provided by the class in different application domains and is the mechanism supporting the search of "similar" components. In fact, a basic problem in specification reuse is to identify in the repository the components that best match the characteristics of the components needed to specify the target application. Often, the desired component is not in the repository; however, the user can find components that are "close to" the desired one. Functional Descriptions allow the developer to explore the repository about the functionalities of reusable components, in particular, searching for "similar" or "functionally" close specifications. Functional Descriptions are stored in the SIB as part of the component description. They are sets of features which are combinations of two keywords and a weight. Features are entered by expert users or abstracted automatically from the component roles and in/out message set. A controlled vocabulary (thesaurus) is used for keywords; the thesaurus is a semantic network of related terms connected via "related-to", "narrower-than", "broader-than", "synonym-of", "composed-of" links. The weight in a feature represents the attitude of the feature to describe the component behaviour. The weights values belong to a set of 5 fuzzy values ranging from 'very high' to 'very low' on which comparison criteria have been defined for the derivation of similarity values [Faus93]. The 'very high', 'high', 'medium' values are used for describing components; in addition, 'low' and 'very low' can also be used when querying the repository In Fig. 8, the Functional Description of OrderProcessing is given, partitioned by application domains which act as search environments in the repository. The "base" domain assigns "veryhigh" to the behaviour of managing order requests (the basic task provided by the class). The two remaining features are weighted as "high", because preliminary searches on the repository usually employ broad-scope terms like "check" a "request", and "check" some "client_information". The terms provided in sales-system are more specific (e.g., "request" becomes "order"), and more precise weights are


9

assigned to the class services (e.g., "receive", check", and "execute" are weighted as "veryhigh"). Marginal services provided by a class are given "medium" weight (e.g., the "compile,order" pair) denoting features characterizing additional services selectable on the developer's discretion. The second type of information associated with reusable classes is that used by the application developer once a useful class has been selected for a given application, to compose and tailor it to the characteristics of the particular application. This type of information is more dynamic in nature, since it has to provide indications of sequences of design operations to be performed to adapt the class. Design operations include predefined queries on the repository, indications to refine reusable components, and indications to modify the component adding new elements or modifying some of its parts in a consistent way. Modifications can be suggested on properties, on messages, and on the sequence of invocation of messages provided by the role state/transition diagrams. Design operations can also suggest to split the class into two or more classes providing globally the same set of services (the same type of operation applies to roles), therefore guiding the application developer in the refinement of the specifications. Since these types of suggestions have a dynamic nature, roles are used to group design operations related to each suggestion. Suggested sequences of queries and design operations are expressed through state/transition diagrams, in the same way as shown in Fig. 3. class-name is-a suggestion-class properties : structural links (is-a links, part-of links,references, and roles) (subdivided in necessary and possible) functional descriptions roles : base-role basic rules to indicate dependences of design operations transformation roles (for targeted sequences of design operations) properties : structural links messages : list of design operations (subdivided in necessary and possible) rules : to represent possible sequences of operations (equivalent to state-transition diagram) Figure 4

General template for reuse suggestion classes.

10


3.3 Organization of reuse information The whole design process is modeled in an object-oriented way; therefore, design operations are messages exchanged between the developer, the SIB and the specification being produced. The SIB software system is used for the realization of the reuse repository. Therefore, both components and the associated reuse suggestions are stored in the reuse repository according to the SIB internal model, Telos [Cons93]. In Telos, knowledge (a set of classes) can be organized at various meta levels (M1 classes, M2 classes, ..., Mi classes); classes at the j-th level are instances of classes at the j+1th level. The reuse repository is organized in two levels: 1. the description of the reuse suggestion structure on which the reuse development process is based; 2. the reuse repository contents, containing suggestion classes. Fig. 5 shows the reuse repository structure and elements of the suggestion classes associated with the OrderProcessing component. With reference to Fig. 5, the topmost level of the SIB describes the repository structure. According to the terminology of data and knowledge bases and information systems, this is a meta level, where meta classes describe the SIB contents structure. In Fig. 5, a meta suggestion class denotes a F-ORM class with meta roles each describing (sets of) operations on the repository components that can be reused together because conceptually related. Design messages associated with meta roles describe a (set of) design operation(s) of the IOOM method. More precisely, a design message describes the operations to be performed on classes, roles, and set of classes in order to tailor them to the application under development. In Fig. 5, the OrderProcessing suggestion class has roles which correspond to a set of design operations that can be performed to derive an OrderProcessing class. Examples are the Service_Request and Public_Organization meta roles describing respectively how to develop an application centered around service delivering tasks, and how to derive the functionalities of managing orders in public organizations. A meta suggestion class is linked to application domains, in order to describe possible reuse strategies which are domain-dependent; it is also linked to other meta suggestion classes via links expressing necessary and possible (optional) dependences among repository components (depending on the link types, as described above). In Fig. 5, some instances of design operations are shown (select-class, specialize, select-role). Two application domains are suggested for reuse of OrderProcessing: Sales-System and Public-Administration. Since they are instances (boxes in Fig. 5), they can be queried, have values, and have available keywords for retrieval. The necessary dependence with a Client component is instantiated in the Client suggestion class: suggestions become available to derive a Client class, which is reported as a necessary interface to OrderProcessing.


11

Reuse Repository Contents Description

has-necessary-dependence has-possible-dependence has-meta-role

has-message

Meta_suggestion_ class

design_operation

meta_role

has-appl-domain

application_domain instance-of

instance-of

instance-of

instance-of

Reuse Repository Contents select-class

Sales-System

Public-Administration

ServiceScheduling

has-appl-domain

service request

has-message

specialize-into ServiceManagement

has-meta-role

OrderProcessing suggestion_class

has-meta-role

has-necessarydependence

select-role receive

publ-org

has-message

Client suggestion_class

instance-of

select-role check-authorization instance-of

instance-of

instance-of

Specification Process Support Client Suggestions.0 has-necessarydependence

Instance of publ-org

OrderProcessing Suggestions.0

suggested-msg

Instance of select-role receive

suggested-role

has-class-structure

Specifications

has-role

MyOrderProcessing

instance-of

R E P O S I T O R Y

MyReceive

instance-of

W RO ER CK AS SP TA C E

APPLICATION DATA MyOrderProcessing.1

Legend: Figure 5

classes,

MyOrderProcessing.2

instances

Example showing the meta levels in the repository used to describe the reuse of the OrderProcessing class.

Fig. 5 shows also how reusable components are managed in the RECAST workspace, where reusable elements are composed and tailored according to suggestions. Within RECAST workspace, suggestion classes are instantiated and drive the creation of a specification containing the application class elements. The Workspace comprises two parts:

12


1. the portion containing information driving the design process (Specification Process Support); 2. the portion containing selected components which become part of the specification (Specifications ). The level of Application Data is also shown; eventually, it will contain instances of OrderProcessing with actual data; this level is obviously out of RECAST purpose since RECAST assists in producing a specification.

4. RECAST The overall architecture of RECAST is depicted in Fig. 6, where the contents of the SIB is also briefly summarized. The functionalities provided by RECAST support access to the repository to retrieve specifications, and graphical composition and tailoring of reusable specifications in the workspace suggested design operations provided as reuse suggestions. These functionalities support the analysis of reuse phase of Fig. 1, leading to an application specification, as illustrated in the following of this section. Requirements Composition and Specification Tool (Recast)

• • • •

Workspace Suggestion Cards Suggestion Windows

Retrieve specifications from repository Compose and tailor specifications Suggest design operations Guide analysis of reuse Software Information Base

• • • •

Figure 6

Specification classes Design classes Implementation classes Development information (reuse suggestion classes)

The REquirement Composition And Specification Tool (RECAST) accesses specification classes and development information in the Software Information Base; it drives the application developer in composing and adapting specifications for the current project. The Software Information Base contains all the information regarding the reusable classes and the development process.


13

Retrieval functionalities (Sect. 4.1) allow the developer to search the SIB using a Selection Window: specifications matching given conditions can be searched (query functions), or the SIB contents can be browsed. RECAST composition and tailoring functionalities (Sect. 4.2) are based on the IOOM method and exploit graphical facilities. Upon selection of one component Ci, RECAST automatically selects a set of reuse suggestion classes which are proposed to the developer in the form of Suggestion Cards. A suggestion card contains indications on which components should be selected with Ci, because of existing structural links (message exchange, Is-a links, etc.), and which ones could be composed with Ci, because the development method suggests to reuse a certain cluster of components, for example, according to the application domain in which the developer is operating.

4.1 Retrieval of reusable specifications Retrieval mechanisms for accessing the network of components in the SIB are at the basis of the retrieval functionalities of RECAST. The repository is browsed and queried incrementally, moving from generic to more specific searches, assuming that the designer uses more and more detailed and appropriate terms. Fig. 7 shows the retrieval functionalities of RECAST, composed of a browser and of a query manager; these are obtained by extending the SIB Selection Tools basic retrieval functions to adapt them to the specification phase. The browser provides a visual interface of hypertext type on the SIB. Given the name of an initial component, it shows the components related to the selected one via the following link types: 1. structural links expressing relationships typical of object-orientation (Is-A, Part-Of, and message exchange); 2. method links deriving from development knowledge stored in suggestions according to the IOOM design operations (e.g., tailoring operations applicable to components within a certain application domain, or transformation links allowing to refine components and to map them into components at a finer level of detail, or links to design components). Each link type can be filtered, i.e., a link type can be chosen and the corresponding subnetwork is visualized. A history window provides a navigation trace of traversed components; jumps to previously explored components are possible by selecting them from the history list. Browsed components can be marked as relevant, or saved in a component pool that can be queried and browsed again. Queries are based on the correspondences among classes deriving from links typical of object-orientation, from the method links, and on similarities between components. Query formulation can involve directly component attributes (F-ORM elements such as roles, properties, messages) and evaluation of similarities between components. A simple conventional type of

14


retrieval is shown in the class attribute part of the query presented in Fig. 9. Components are retrieved on the basis of their static (type, property types) and dynamic (messages) characteristics. Retrieval based on Functional Descriptions is shown in the second part of the query.

Query Manager

Browser uses

Structural Links

Figure 7

classes

Method Links

Is-A

refine/abstract

Part-Of

partition/aggregate

message flow

tailor

correspondences similarities

link to design components

The browser displays relations between components according to various criteria: structural links that represent functional dependences (message flow) and object-oriented relationships; method links about design actions defined in the method, such as refinements, abstractions, partitioning and aggregations of components. The query manager retrieves similar classes and object correspondences according to queries formulated by the application developer.

OrderProcessing_Suggestion_class is-a suggestion-class properties: structural links ... functional descriptions appl-domain base ( manage, request, veryhigh ) ( check, request, high ) ( check, client_info, high) appl-domain sales-system ( receive, order, veryhigh ) ( check, order, veryhigh) ( execute, order, veryhigh ) ( compile, order, medium ) Figure 8

Example of Functional Descriptions related to an "order processing" specification component. Features related to all the application domains are specified in the base application domain. Features relating to specific domains are provided to describe the class services in these domains.

In the class Features part, weights are assigned considering the relevance of a feature for the developer. For instance, in Fig. 9, the developer is designing an information system dealing with sales orders. Supposing he is driven by the thesaurus in using terms of the "sales-systems"


15

context, he is looking for a reusable component "managing orders"; he is also interested in a class that checks the inventory. Finally, a useful functionality is "order rejection": the query considers the "reject" functionality as of marginal interest, although useful to restrict the set of returned candidate classes. retrieve component where/* class attribute part */ class-type = 'process-class' has-role = 'receive' has-property-domain='big-client' /*an application for Industrial Clients is being designed */ incoming-message start from OrderAdministrator /*the initiator */ where /* Class Features part */ ( manage, order, veryhigh ), ( check, inventory, high ), ( reject, order, medium ),/* this feature is of marginal interest */ Figure 9

Querying the repository to search for a process class providing the services of an order processing procedure related to big clients and started by the OrderAdministrator class. The candidate class should manage orders requests and should include tasks related to order checking, rejecting, and archiving. Different weights express different degrees of interest in the functionalities.

In query processing, two components are considered 'similar' if they provide compatible services, i.e., if the specifications can be satisfied by both. A confidence value associated to a retrieved component describes how precise the component is with respect to the desired functionality. An algorithm has been defined for comparing classes on the basis of the fuzzy weights [Faus93]. The returned set of candidate classes can be restricted incrementally by refining the query with further parameters and/or more precise keywords.

4.2 Composition and tailoring: specification method The specification process according to the IOOM method is an interleaved process of top-down/ bottom-up development, guided by suggestions; specifications are organized in a set of related specification documents, describing the application specification at different abstraction levels. Top-down refinement can split a class in a set of classes providing the same services, described at a more detailed level. Transformations in suggestions can guide the developer to produce a set of classes at a level i+1 that represent a refinement of the initial class set. Bottom-up development is typical of the reuse approach. In fact, in general a set of related classes is retrieved. In order to provide a more abstract description of the functionalities of the set of classes, a more abstract specification can be produced, describing the functionalities provided by the set of classes as a whole.

16


The production of a complete specification involves the construction of a consistent set of specifications at different levels of abstraction. The development method, supported by the RECAST tool, guides composition and tailoring of reusable components at a given level of abstraction, and provides suggestions and methodological indications for refining a specification (top-down development) and for abstracting a specification (bottom-up development). A mapping between specifications at different abstraction levels is maintained by the tool to check consistency. Each specification document is composed of a set of classes, constructed according to the following steps: 1. accessing the reuse repository to retrieve components; 2. moving useful components into RECAST workspace (see Fig. 5) thus incrementally composing a specification; 3. tailoring components for the specific application. The specification process starts from the analysis of requirements to identify the most important reusable components. For instance, in an order processing application the first components to be selected are the ones related to orders and clients (analysis of reuse step). Starting from the components initially selected through RECAST support, based on browsing and suggestions, related components are identified and, if they correspond to requirements collected in the first requirement analysis step, they are selected by the developer. The developer has full control on the insertion of selected components in the specification documents at the different levels of abstraction. Note that also reusable components are organized according to abstraction levels: e.g. OrderProcessing.1 is a refinement of the specification of OrderProcessing. An example of application specification at various abstraction levels is provided in Fig. 10. Here, we can suppose that the OrderProcessing class has been reached using the query described in Fig. 9, or that the developer reaches this class by first performing a tour of the repository, finding RequestProcessing, and that later he is guided in refining this class from level 1 to level 2 thus obtaining OrderProcessing. In both cases, the developer is guided in composing OrderProcessing with other classes relevant for the application at the same level of detail (e.g., WarehouseProcessing and/or AccountProcessing in Fig. 10). A snapshot of RECAST showing an instance of OrderProcessing selected in the workspace is reported in Fig. 11. Specifications are graphically represented in the workspace and graphically interconnected and tailored. Each specification class is represented as a graphical component. MyOrderProcessing is the instance of the specification, obtained by copying the component OrderProcessing.1 (shown in the COMPONENT POOL window). The shadowed roles of MyOrderProcessing are those selected by the designer as meaningful for the current application. This screen dump shows also the query interface of RECAST. The query is labeled (can be


17

added to a query pool and its result queried again or browsed). The retrieved components are shown on the right-hand side of the window as F-ORM classes. A class attribute and a class features window appear inside the Query Manager window, to indicate the two parts of a query (cfr. Fig. 9). Filters allow the developer to enter optional characterizations of the query (here, the features specified in the query are expanded by considering terms which are defined as 'narrow' in the thesaurus). In the figure, the 5 fuzzy values are all enabled, hence the search considers all the possible similarity values.

OrderManagement System

Request Processing

OrderProcessing

Level 0

Factory System

Warehouse Procesing

Level 1

Account Precessing

Level 2

Level 3 Stock Management

Invoicing

Billing

Figure 10 Example of a multilevel application specification related to order processing. Each box in the figure represents a component; links represent transformations of the component into more detailed components. A specification of the Order Management System exists; components related to request processing and to the factory system are then provided via transformations.

Suggestions for the reuse of retrieved classes are displayed by a CARD MANAGER. In Fig. 11 a card, suggesting the retrieval of dependences of the Execute role, is shown in the "conceptual design suggestions" window. Suggestions for the execution of detailed design are also provided. When selected, design operations are directly applied to graphical components and cause changes in the component presentations and interconnections. The final specification document produced with assistance from RECAST contains the set of specification graphical representations, the component documentation, and a trace of the steps that lead to obtain the specification.

18 An environment for specification reuse

Figure 11 Screen dump related to Recast workspace for class composition. The MyOrderProcessing class is shown in the workspace; it is a version of the OrderProcessing class contained in the repository. Some roles of the MyOrderProcessing class are selected for the application being developed and some dependencies shown. A Card Manager window contains new composition suggestions. The query that allowed the retrieval of the OrderProcessing class is also presented: two OrderProcessing classes are shown in the result, corresponding to two different detail levels.


19

6. Concluding remarks In the paper, an approach to reuse of specifications and the RECAST tool supporting this approach have been described. The tool accesses a repository called Software Information Base, where reusable components and suggestions for the reuse process are stored. Specifications are modeled using an object-oriented model and method, coherently with the whole ITHACA approach; in fact the target applications are assumed to be object-oriented and a whole development cycle based on object-orientation provides a uniform approach, encourages development traceability, and application engineering for later reuse. RECAST has retrieval and component inter-connection functionalities based on an objectoriented specification method (IHACA Object-Oriented Method -IOOM) and highly relying on graphical facilities. The paper has illustrated both the model and method, the RECAST retrieval and composition functionalities, and the assistance in reusing specifications provided by the tool via suggestion classes. A prototype of RECAST has been developed at Politecnico di Milano within the EEC-Esprit-II ITHACA project. It runs on a SUN/4 workstation under SunOs, C++ and X-Motif. The tool interacts with other ITHACA tools [Bell93]; the SIB is accessed via a programmatic interface and via the Selection Tools. Experiments with the proposed approach have been performed with office applications (see the example in the appendix), and with a banking workbench application provided by the project industrial partners. The tests on the banking workbench have been conducted proceeding as follows. First, the repository has been populated with classes derived manually from examples in the literature about Loan Granting procedures; a set of reuse strategies has been specified by defining parameters, alternatives, and design options coded as reuse suggestions. Then, the approach has been tried out by collecting the requirements of a Loan Management application provided by industrial partners, by defining the basic specification of the test bench (level 0), and by specifying a more detailed specification (levels 1 and 2) reusing classes from the repository referring to the first example. The approach has proved successful especially for process classes, aimed at defining possible alternative steps in the execution of an office task. As a result, process classes are reusable in an almost straightforward manner; the reason is that many reusable process classes can be created which are able to describe a variety of applications through some basic roles such as "receive", "execute", "archive", "communicate-with-client". These classes are easily adaptable to a number of applications. Instead, reuse of resource classes, especially in the case of documents, is difficult because of the variety of possible formats and information contents which vary substantially in different applications. Therefore, the effort of reusing documents seems rather high compared with the expected benefits. More efficient reuse strategies can be defined for example by defining clusters of components which can be reused as a group, with the possibility of defining a single reuse suggestion class for the cluster, which brings about a set of design operations for the whole cluster.

20


Finally, a repository of a meaningful size has been identified as essential to test the reuse approach and the effectiveness of the retrieval functionalities. Therefore, population efforts are among our future goals. The population and maintenance (engineering) of the repository are also topics under investigation.

Acknowledgments The research and development of the environment were sponsored in part by the ITHACA Project in the framework of the European Strategic Programme for Research and Information Technology of the Commission of the European Communities, and in part by the Italian Research Council Project 'Informatica e Calcolo Parallelo', LRC 'Infokit'. The partners of both projects are acknowledged for common ideas and work.

References [Bell93] R. Bellinzona, M. G. Fugini, V. de Mey, "Reuse of Specifications and Designs in a Development Information System", in Information System Development Process, N. Prakash, C. Rolland, B. Pernici (eds.), North-Holland, pp.79-96 [Cons93] P. Constantopoulos, M. Doerr, Y. Vassiliou, "Repositories for Software Reuse: the Software Information Base", in Information System Development Process, N. Prakash, C. Rolland, B. Pernici (eds.), North-Holland, pp. 285-310 [DeAn91] V. De Antonellis, B. Pernici, P. Samarati, "F-ORM METHOD: A F-ORM Methodology for Reusing Specifications", Proc. IFIP WG 8.1 Working Conf. on Object Oriented Aspects in Information Systems, North-Holland, 1991 [Deva91] P. Devanbu, R. J. Brachman, P. G. Selfridge, B. W. Ballard, "LaSSIE: A KnowledgeBased Software Information System", Communications of the ACM, Vol. 34, No. 5, May 1991 [Fink88] A. Finkelstein, "Reuse of Formatted Requirements Specifications", Soft. Eng. Journal, Sept. 1988, pp. 186-197 [Faus93] S: Faustle, M.G. Fugini, "Retrieval of Reusable Components in a Development Information System", Proc. 2nd IEEE Workshop on Software Reuse, Lucca, March 1993, pp.89-98 [Fugi92] M. G. Fugini, O. Nierstrasz, B. Pernici, "Application Development through Reuse: the Ithaca Tools Environment", ACM SIG-OIS Bulletin, August 1992, pp. 235-252[Hend90] B: Henderson-Sellers, J.M. Edwards, "The Object-Oriented Systems Life Cycle", Comm. of the ACM, Vol. 33, No. 9, Sept. 1990, pp. 142-159 [Krue92] C. W. Krueger, "Software Reuse", ACM Comp. Surveys, Vol. 24, No. 2, June 1992 [Maar91] Y. S. Maarek, D. B. Berry, G. E. Kaiser, "An Information Retrieval Approach for Automatically Constructing Software Libraries", IEEE Trans. on Soft. Engineering, Vol. 17, No. 8, August 1991


21

[Maid92] N. Maiden, A. G. Sutcliffe, "Exploiting Reusable Specification Through Analogy", Communications of the ACM, Vol. 35, No. 4, April 1992, pp. 55-64 [Prie91] R. Prieto-Diaz, "Implementing Faceted Classification for Software Reuse", Communications of the ACM, Vol. 34, No. 5, May 1991 [Reub91] H. B. Reubenstein, R. C. Waters, "The Specifications Apprentice: Automated Assistance for Specifications Acquisition", IEEE Trans. on Software Engineering, Vol. 17, No. 3, March 1991

Appendix: An example of specification reuse An example of design session with RECAST regarding the specification of an "order processing" application is provided here. Case Study: Order Processing The application considered in the following is related to the automation of order processing. It comprises the various phases of order management: the client request arrival, the evaluation of the request for goods availability, the management of a credit, the execution of the order by goods shipment, and the issue of various documents. The repository contains components that can be reused at various detail levels; reuse suggestions guide the application developer in finding and in reusing the repository classes according to the specific needs of the application being developed. Some reusable components of the repository are shown in Fig. A1. They are organized in four detail levels: Fig. A1 provides a schematic description of levels 0 to 2; message names are reported only for levels 0 and 1 for simplicity. Level 0 classes are abstract and suitable for various office environments; they have been derived directly by considering office domain knowledge. In level 1, the basic issues related to a sales office environment are introduced, including the sales organization, the various employee positions involved in order management, the client issuing the order, and the order information. Level 2 classes allow a more detailed description of the order processing activity; the relationships between the activity of "order processing" and the order tasks of the sales office are considered. In Fig. A2, the three roles group related design operations for OrderProcessing according to different domains and design needs. The selection of a role instantiates the corresponding role and therefore proposes design operations in the form of messages. For example, in the servicerequest role, a transformation of the role OrderProcessing.Execute into more detailed classes is shown (message m5), depending on the needed services. The role drives in the specification within commercial organizations. OrderProcessing can also be specialized into the classes Serv-

22


ice Management and ScheduleManagement. The rules specify that the two design alternatives are

exclusive. Level 0

Person

Organization_0

Archive Folder

Employee_0

OrderManagementSystem

activates

compiles

Document

compiles

Request_0 transformation-of

transformation-of

Level 1 Organization_1

Client

provides-info

RequestProcessing

activates

compiles

Order_1

Secretary

Vendor

activates

Manager Employee_1

FactorySystem activates

receives / sends

transformation-of

transformation-of

Level 2 AccountProcessing

OrderProcessing

WarehouseProcessing

ProductionProcessing Inventory AccountClerk

InventoryClerk

Account-info

Order_2

Client-info

Vendor

OrderAdmin

Client

Legend: message dependence

specialize-into

transformation-of

part-of

Process class Resource class

Transformations 0 → 1

Transformations 1 → 2

Organization_0 → Organization_1 Employee_0 → Employee_1 OrderManagementSystem → FactorySystem + RequestProcessing Request_0 specializes into Order_1

FactorySystem → AccountProcessing, ProductionProcessing, WarehouseProcessing OrderProcessing specialization of RequestProcessing_1 Order_1 specializes into Order_2

Figure A1 Example of levels of reusable components contained in the repository.


23

Interaction with RECAST Referring to the example described above, some steps of user interaction with RECAST are given. Fig. A3 shows a sequence of activations of reuse suggestions. Suggestions are presented to the application developer in the form of suggestion cards containing description text, lists of design operations to be necessarily or optionally executed, queries against the SIB, links to other cards. The application developer decides which of the suggested operations are to be executed, can select the optional design operations, or retrieve components, thus choosing among the proposed reuse suggestions. The consequences of card evaluation are also displayed in Fig. A3. The execution of a card occurs via a 'commit card/options' command. Options allow the developer to select some of the suggestions from the card; the selected elements are executed by RECAST; embedded queries retrieve both reusable components and suggestion classes thus presenting further cards.

OrderProcessing_Suggestion_class is-a suggestion class properties : structural links ( is-a : Necessary : { OfficeTask } Possible : { } ) ( part-of : Necessary : { } Possible : { Production_Mgmt } ) ( references : Necessary : { Request, Client, Vendor } Possible : { WarehouseProcessing, AccountProcessing, Account_Info } ) (roles: Necessary: { receive, execute } Possible: {check, reject }) functional descriptions appl-domain base ( manage, request, veryhigh ) (check, request,high ) (check, client_info, high) appl-domain sales-system (receive, order, veryhigh) (check, order, veryhigh) (execute, order, veryhigh) (compile, order, medium) appl-domain: publ-org (receive, order_note, veryhigh) /* in public organizations Order Notes are processed by special bureaucratic procedures */ (authorize, order_note, veryhigh) (check_archive, authorization_letter, high)

24


roles base-role /* coordinates activation of meta-roles */ properties : options : { goods-request, service-request, public-organization } messages : Necessary : { m1: retrieve component where ( manage, order, veryhigh ) and class-type = agent-class m2: select-class agent from m1.result } /* an agent is necessary and can be chosen from query return set */ rules : r1: if select-option goods-request then start-role goods-request /* select-option is message inherited and defined for all suggestion classes */ r2: if select-option service-request then start-role service-request r3: if select-option public-organization then start-role publ-org

goods-request /* transformation role */ /* text to appear in card */ "The check of goods availability involves request to InventoryClerk" messages : Necessary : { m1:select-class InventoryClerk m2: select-class WarehouseServices } /* cfr. Fig.A1 */ Possible : { m3: select-role Data.Inventory m4: class-to-classes OrderProcessing --> ( OrderProcessing, WarehouseProcessing, InventoryManagement) m5: role-to-roles OrderProcessing.Check --> ( OrderProcessing.InventoryCheck, OrderProcessing.ArchiveCheck ) } service-request /* transformation role */ /* text to appear in card */ "Check of a service request includes check on possibility to execute service within client-requested schedule" messages : Necessary : { m1: select-class ServiceScheduling } Possible: { m2: select-class ScheduleData m3: specialize-into ServiceManagement m4: specialize-into ScheduleManagement m5: role-to-roles OrderProcessing.Execute --> ( OrderProcessing.Accept, OrderProcessing.Modify, OrderProcessing.Reject ) } rules : r1: if m3 then forbid m4 and m5; r2: if m5 then forbid m3 and m4 /* transformations m3 and m5 are in ex-or */ publ-org

/* transformation role */ /* text to appear in card */ "Public Organizations require a call-for-contract and a set of authorizations"


properties : structural links ( references: Necessary { Order_note, Contract } ) messages : Necessary: { m1: select-class PublicOrganization } Possible: { m2: select-class AccountServices /* cfr. Fig. A1 */ m3: retrieve component where ( authorize, order_note, veryhigh ) ( require-from-client, warranties, high ) ( check, contract, veryhigh )/* embedded query */ m4: select-role receive, execute, check_authorization m5: specialize-into PublAdmOrdProc } )

Figure A2 Reuse suggestion of the OrderProcessing component.

25

“The class OrderProcessing needs an agent. You can retrieve one via the query:” retrieve component where (manage, order, veryhigh) and class-type = agent-class

26

suggestion card corresponding to m1 of base-role of OrderProcessing suggestion class

select-class OrderProcessing

Retrieved F-ORM classes

commit-card

OrderAdmin Secretary Manager

suggestion card corresponding to mi of OrderAdmin suggestion class

OrderAdmin

select-class OrderAdmin

order-statist.

OrderAdmin

“The order related tasks are activated by the ‘receive’ role”. N select-role order-receive

select-option public-organization OrderAdmin

“You can specialize the class OrderProcessing to manage orders coming from public organizations” P specialize OrderProcessing into PublAdmOrdProc

start

OrderProc. base-role receive check execute reject

base-role order-receive

commit-card

start

OrderProc. base-role receive check execute reject Is-A PublAdmOrdProc

Legend: design action

suggestion card (SC)

Recast workspace snapshot

Figure A3. Example of reuse suggestions and design operations related to the specification of the “order processing” application. The selection of the OrderProcessing class produces suggestions about the selection of class roles, the retrieval of dependent (or related) classes (OrderAdmin, Client, Order) and the specialization of OrderProcessing in the Public Administration domain. The workspace snapshots depict the consequences of the execution of suggested design actions.


suggestion card corresponding to m5 of role publ_org of OrderProcessing suggestion class


commit-card


OrderProc. base-role receive check execute reject