Automated Component Retrieval and Adaptation ... - Semantic Scholar

21 downloads 49004 Views 52KB Size Report
cations. At the same time, reusing a specification can lead to reusing aspects of the ... support a high degree of automation to ensure high levels of productivity.
Automated Component Retrieval and Adaptation Using Formal Specifications John Penix Department of Electrical & Computer Engineering and Computer Science University of Cincinnati Cincinnati, Ohio 45221-0030, USA 1 513 556 0267 [email protected] ABSTRACT This paper describes a method for applying formal specifications to automate a system design process based on reusable components and architectures. The focus is on identification and retrieval of components pertinent to a problem, and selection and application of architectures available for adapting these components. Component retrieval is facilitated by a heuristic based on specification semantics for approximating specification matches that indicate component reusability. To support adaptation, a formal model of architectures is developed that uses algebraic theories to specify relationships between the system and component specifications. Adaptation is performed by placing or replacing components within an architecture theory.

support a high degree of automation to ensure high levels of productivity. This paper describes part of an effort to use formal specifications to assist and automate a system design process based on reusable components and architectures. Specifically, our methodology focuses on automated support for two reuse-related design activities at the specification level: 1) identification and retrieval of library components pertinent to the problem at hand, and 2) identification and application of architectures available for adapting these components. APPROACH We propose to integrate specification-based component retrieval with a formal architecture representation to support component retrieval and adaptation. The flow of design information within the proposed system is shown in Figure 1. In the diagram, boxes represent data stores, ovals represent computations and arrows represent data flow into computations and references between data stores.

Keywords Software reuse, specification-based retrieval, software architecture formalisms. INTRODUCTION As software systems are becoming larger and more complex, the demand for high levels of reliability and productivity is also increasing. New techniques and tools will be necessary to enable design methodologies to meet these demands.

In the system, formal specifications are used to model the problem requirements and the function of the library components. The specifications are based on abstract data types defined in an algebraic domain theory. Component retrieval is made efficient by layering a faceted classification scheme above the specifications. The classification scheme consists of a collection of formal definitions representing possible component features in the domain. The formalization of the scheme permits automated classification of the specifications. The retrieval mechanism is based on syntactic comparison of features sets. The components returned by the retrieval mechanism are passed on to a more detailed evaluation that uses specification matching (proving a logical relationship holds between two specifications [22, 21]) to determine reusability.

Formal specification and component reuse are two areas of software engineering research that show high potential impact on design productivity and reliability. Furthermore, the two can be mutually beneficial. Formal specifications provide precise descriptions of component behavior that can be used to determine reusability. In addition, they are described in terms of a domain model that can be reused across applications. At the same time, reusing a specification can lead to reusing aspects of the associated design and implementation. However, adoption of these technologies requires significant investment in building libraries, educating designers and constructing domain models. Therefore, successful development methodologies based on formal specification and reuse must

The results of specification matching determine the relationship that exists between each of the retrieved components and the requirements specification. The adaptation phase uses these results along with the available architecture theories (formal representations of software architectures) to determine whether a mechanism exists to adapt or combine the retrieved components to solve the problem. It is possible that subproblems will be generated while attempting to place components into an architecture. Each architecture theory

1

Domain Modeler

Designer

Domain

Requirements

Theory

Specification

Sub-Problem

Architecture Classification Scheme

Classification Feature Set

Component Retrieval Subsystem

Retrieval

Specification

Architecture

Architecture

Selection

Instantiation

Matching Components

Desired System

Components

Matching Component Adaptation Subsystem

Architecture Theories

Similar Components

Component

Architecture

Library

Library

Design Library

Figure 1: Overview of Component Retrieval and Adaptation Activities has a corresponding schema in the architecture library that implement the problem decomposition specified by the theory. Once an architecture theory is selected that correctly combines components to solve the problem, the corresponding architecture is selected from the library and instantiated with the components. The result is a system with the desired properties. Efficient Component Retrieval There is evidence that specification matching to determine component reusability can be carried out using automated theorem proving [21]. However, attempting specification matching over a large library of components is not a practical retrieval mechanism. Therefore, specification matching must be restricted to a small subset of the database. We have developed a heuristic for determining a set of components to which specification matching can be applied, based on the semantics provided by formal component interface specifications. This heuristic is embodied in a prototype retrieval system, REBOUND [13]. The method works by classifying components in a way that components likely to match for reusability will be assigned similar features. By formally defining the classification features and the feature assignment process, classification can be fully automated. Classification A lattice of specification matches used for determining reusability is shown in Figure 2 [21, 12]. Inspection of these specification matches reveals that in the cases of interest for reuse part of one specification logically implies part of another specification. These situations can be identified by the

Stronger

?

Weaker (IP

(IP

(IP

Plug-in ) IC ) ^ (OC ) OP )

? ? Weak Plug-in

@ R @

) IC ) ^ (IC ^ OC ) OP )

??

Satisfies ) IC ) ^ (IP ^ OC ) OP )

Plug-in Post OC ) O P

@@R ?? Weak Post

I

C ^ OC ) OP

Figure 2: A Lattice of Specification Matches Used to Evaluating Reusability

use of necessary conditions. A necessary condition for a predicate P is another predicate Φ logically weaker than P , i.e. P ) Φ. For two predicates P and Q such that P ) Q, every necessary condition of Q will be a necessary condition of P . Our heuristic uses necessary conditions to eliminating invalid solutions during heuristic search. Specifications are classified based on a given set of necessary condition-feature pairs. A feature is assigned to a component if the feature’s associated necessary condition is logically implied by the component’s specification. Therefore, component specifications that match for reuse will have similar feature sets. Testing this implication can be done using automated reason-

ing, making the classification process automatic. Component matching during retrieval can then be accomplished by simply comparing feature sets. Classification Scheme The classification process is controlled by a collection of feature definitions that determine the set of necessary condition/feature pairs used. The feature definitions replace the knowledge that a domain expert would use to classify components by hand. A feature is an attribute-value pair where the attribute is the name of the feature and the value represents the data type(s) used to instantiate the type parameters of the formal necessary condition definition. Type parameters are instantiated by types from the domain and range of the specification as constrained by predicates (isI nput() or isOutput()) in the feature definition and type compatibility with operators used to specify the necessary condition. For example, the Select feature: 1; T 2) , 9x : T 1; y : T 2  isI nput(x) ^ isOutput(y) ^ y 2 x

Select(T

represents the case where an output is an element of an input variable. Because the definition is parameterized on the types of the data, Select is a possible feature whenever the containment operator exists between an input and output type. We will evaluate both the theoretical and pragmatic aspects of the component classification and retrieval system. We have competed an initial investigation that developed a theoretical foundation for our method based on specification matching for reuse [10] that will be further developed as part of the doctoral work. In addition, we plan to evaluate the methodology using a large component library. The evaluation will involve experimentation with different classification schemes and empirical measurement of retrieval recall and precision. Component Adaptation It is naive to assume that component retrieval will always result in a component that satisfies a problem specification. It is most likely that the component will require adaptation, or that multiple components will be combined to solve the problem. Providing automated support for component adaptation can be achieved using a mechanism for combining components together and tactics for applying these structures to achieve the desired behavioral alteration. Architecture Theories Software architectures describe systems as collections of interconnected components [15]. There are various aspects which distinguish an architecture, such as the level at which the components are implemented (function, object, package, process, etc..) and the style of the components and interconnections (client/server, pipeline, blackboard, etc.). When specifying systems at the architectural level, the goal is to capture the precise component behavior that is required

to guarantee correct system-level behavior. In addition, there should be some traceability between the system and component level functionality. Reasoning efficiently about this relationship requires an architecture representation that abstracts out the operational details and provides a declarative specification of an architecture. With this in mind, we have extended Smith and Lowry’s work on using algorithm theories to specify the structure of algorithms [16, 19] to specify the structure of architectures. An architecture theory constrains the behavior of a system in terms of the behavior of its subcomponents via a collection of axioms [11]. This relationship is specified declaratively, abstracting away implementation concerns. Formally, an architecture theory is a parameterized theory [2]. The parameters permit the system and subcomponent interface specifications to be “plugged-in” to the architecture. The axioms of an architecture theory place constraints on the relationship between the system and component interfaces. The axioms may describe component interconnections and bind components to the system level interface. There are two ways in which architectures can be applied to component adaptation: augmentation and subcomponent replacement. In the first case, a component is treated as black box and its behavior is modified by placing it into an architecture with other components. In the second case, the component to be adapted is an architectural component. The behavior of the architecture can be modified by replacing one of its subcomponents. Because the axiomatic constraints in an architecture theory can be used to reason in both a topdown and a bottom-up manner, they can be used to support both types of adaptation. Guiding Component Adaptation Specification matching and architecture theories provide a formal foundation for component identification and adaptation, respectively. However, in order to provide automated support for the entire reuse process, there must be a mechanism for controlling adaptation. This includes adaptation strategies, and heuristics for selecting adaptation strategies based on the available components and architectures. As stated in the system overview, the results of specification matching determine the relationship that exists between each of the retrieved components and the requirements specification. The relationships will be one of the matches in the lattice from Figure 2. The goal of adaptation is to construct a component that matches the problem specification under Satisfies (or a stronger) match. Adaptation can be guided by associating architectures with positions on the lattice such that the application of the architecture makes the adapted component match under Satisfies [12]. The proposed dissertation work will investigate architectures and heuristics for selecting among architectures. Tradeoffs that must be considered while selecting an adaptation tactic may include performance requirements, limits on parallelism and constraints on the tar-

get language. The goal is to have an adequate collection of architectures to allow multiple adaptation possibilities for any of the reuse matches. To evaluate the practicality and utility of the entire methodology, we will demonstrate the development of several systems within an interactive design environment. The sample problems will come from the Rapid prototyping of Application Specific Signal Processors (RASSP) Program, by which this research is partially funded, the Model Problems for Software Architecture archive at Carnegie Mellon University [15], and the NASA New Melennium Project Remote Agent Architecture. Practicality will be demonstrated by providing automated support with existing specification and theorem proving tools. We are currently planning to use a combination of the Larch Shared Language [5], SRI International’s Prototype Verification System [9], and SNARK [20], an automated theorem prover also developed at SRI. CONTRIBUTIONS This work will make the following contributions in the application of formal methods to software reuse and software architecture: 1. A detailed evaluation of the application of interface specifications to determining component reusability. 2. A method for efficient specification matching to enable practical specification-based component retrieval. 3. Developing the use of algebraic theories to model the requirement decomposition aspects of software architectures. 4. Integrating existing tools to demonstrate that automated support for high-level designs activities is feasible and practical with existing technologies. RELATED WORK There is a large body of work dedicated to using formal specifications to aid component retrieval and reuse. Most of the approaches provide a mechanism to limit the application of specification matching by arranging the library in a hierarchy [6] or a lattice [1, 7] based on specification generality. However, the foremost concern in these systems remains the effect of the theorem proving on the scalability of retrieval [7]. The VDM-based Component Retrieval tool (VCR) [3] uses a series of filters to identify reusable components. This tool is novel in its use of model checking as one of the search filters. To reduce the search space during specification matching, the matching conditions are broken up and linked with an appropriate set of axioms. The prototype VCR implementation confirms that specification matching can be made more efficient. However, the recall (retrieved components/useful components) of the prototype was limited by signature matching. A specification-based classification scheme could re-

place signature matching and widen the search to increase recall. The Inquire retrieval mechanism [14] within the Inscape environment is superficially similar to REBOUND due to its use of predicates. Inscape components are specified in terms of a given set of formally defined logical predicates. An inference mechanism is used during the retrieval process to retrieve components that provide the various predicates. The prototype implementation was reported to work very well, but used a restricted specification language to reduce the inference necessary for component retrieval. Our system uses a reversed approach from Inscape. In REBOUND the predicates are not the complete specification of the component, but represent various aspects of the component’s function. Because classification predicates do not have to be useful as specification predicates, they can be more abstract, allowing flexibility in the types of similarity that can be represented. In addition, using a more expressive specification language allows precise evaluation of reusability. Formalisms have recently been introduced to make software architecture a more rigorous activity [15, 8, 4]. Most efforts in formalizing architecture are targeted at specific architectural styles (pipe-filer, client-server, etc), and not with the problem decomposition aspects of architecture. Therefore, these representations are too operational to represent the types of relationships that we are interested in. However, formal models of architectural styles do provide an important link between a general architecture theory and a specific architecture schema which implements the theory. For example, Marconi et. al. [8] use theory-based architecture representations to support architecture refinement. A refinement maps and abstract architecture description in one style to a concrete architecture (an implementation) in a potentially different style. This allows program development by incremental refinements at the architectural level. Axioms are used to describe style constraints and form the basis for correctness proof of the refinement mappings. This work would be an ideal mechanism to specify links between architecture theories and architecture implementations. Our chosen methodology is an extension of the work done on Kestrel’s Interactive Development System (KIDS) [16, 17, 18, 19]. In KIDS, the structure of specific algorithms such as global search or divide and conquer are represented as algebraic theories. The construction of algorithms is directed by a hierarchical arrangement of the algorithm theories [17] as well as special design tactics [19]. Currently, the program schemes that are used to implement algorithms theories result in functional programs. Architecture theories generalize algorithm theories by specifying structure in terms of subcomponent problem theories rather than operators. This allows the implementation of the structure to be independant of the specification and scales the KIDS methodology beyond the construction of functional architectures. We are currently exploring tactics for applying architecture theories

for component adaptation based on the results of specification matching [12]. ACKNOWLEDGMENTS I would like to thank Perry Alexander for collaboration and guidance throughout the development of this work and Amy Moormann Zaremski, Karen Davis, Phillip Wilsey, Michael Lowry, and several anonymous referees for helpful suggestions. Support for this work was provided in part by the Advanced Research Projects Agency and monitored by Wright Labs under contract F33615-93-C-1316 and F33615-93-C4304 and NASA Ames Research Center Contract NAS213605. REFERENCES [1] Noureddine Boudriga, Fathi Elloumi, and Ali Mili. On the lattice of specifications: Applications to a specification methodology. Formal Aspects of Computing, 4:544–571, 1992. [2] H. Ehrig and B. Mahr. Fundamentals of Algebraic Specifications 1: Equations and Initial Semantics. EATCS Mongraphs on Theoretical Computer Science. Springer–Verlag, Berlin, 1985. [3] B. Fischer, M. Kievernagel, and W. Struckmann. VCR: A VDM-based software component retrieval tool. In Proc. ICSE-17 Workshop on Formal Methods Application in Software Engineering Practice, 1995. [4] Mark J. Gerkin. Formal Foundations for the Specification of Software Architecture. PhD thesis, Air Force Institute of Technology, mar 1995. [5] John V. Guttag and James J. Horning. Larch: Languages and Tools for Formal Specification. SpringerVerlag, New York, NY, 1993. [6] Jun-Jang Jeng and Betty H. C. Cheng. Using formal methods to construct a software library. In Proceedings of 4th European Software Engineering Conference, Lecture Notes in Computer Science, volume 717, pages 397–417, September 1993. [7] A. Mili, R. Mili, and R.Mittermeir. Storing and retrieving software components: A refinement based system. In Proc. 16th Int’l Conf. on Software Engineering, pages 91–100, Sorrento, Italy, May 1994. [8] Mark Moriconi, Xiaolei Qian, and Bob Riemenschneider. Correct architecture refinement. IEEE Transactions on Software Engineering, 21(4):356–372, April 1995. [9] S. Ower, J. Rushby, and N. Shankar. PVS: A Prototype Verification System. In D. Kapur, editor, Proc. of 11th International Conference on Automated Deduction, volume 607 of Lecture Notes in Artificial Intelligence, pages 748–752, Saratoga, NY, June 1992. Springer–Verlag.

[10] John Penix and Perry Alexander. Efficient specification matching. Submitted for publication, http://www. ece.uc.edu/˜kbse/, July 1996. [11] John Penix and Perry Alexander. Architecture theories: Declatarative specification of software architectures. Submitted for publication, http://www.ece. uc.edu/˜kbse/, January 1997. [12] John Penix and Perry Alexander. Toward automated component adaptation. In Proceedings of the Ninth International Conference on Software Engineering and Knowledge Engineering, June 1997. To Appear. [13] John Penix, Phillip Baraona, and Perry Alexander. Classification and retrieval of reusable components using semantic features. In Proceedings of the 10th KnowledgeBased Software Engineering Conference, pages 131– 138, November 1995. [14] Dewayne E. Perry and Steven S. Popovitch. Inquire: Predicate-based use and reuse. In Proceedings of the 8th Knowledge-Based Software Engineering Conference, pages 144–151, September 1993. [15] Mary Shaw and David Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996. [16] Douglas R. Smith. KIDS: A Semiautomatic Program Development System. IEEE Transactions on Software Engineering, 16(9):1024–1043, 1990. [17] Douglas R. Smith. Classification approach to design. Technical Report KES.U.93.4, Kestrel Institute, 3260 Hillview Avenue, Palo Alto, CA, November 1993. [18] Douglas R. Smith. Constructing specification morphisms. Journal of Symbolic Computation,15:571–606, 1993. [19] Douglas R. Smith and Micheal R. Lowry. Algorithm Theories and Design Tactics. Science of Computer Programming, 14:305–321, 1990. [20] Mark Stickel, Richard Waldinger, Michael Lowry, Thomas Pressburger, and Ian Underwood. Deductive composition of astronomical software from subroutine libraries. In Alan Bundy, editor, CADE 12, 12th International Conference on Automated Decudtion, volume 814 of LNCS, pages 340–55, Nancy, France, June/July 1994. Springer-Verlag. [21] Amy Moormann Zaremski. Signature and Specification Matching. PhD thesis, Carnegie Mellon University, January 1996. [22] Amy Moormann Zaremski and Jeannette M. Wing. Specification matching of software components. In 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, October 1995.