| A. M. Zaremski and J. M. Wing. Specification matching of software components, Dec. 11 1997. |
.... postimplementation reconfiguration reduces development costs as compared with those methods being used in current software engineering practice that focus on the preimplementation design phase and require reimplementa1 These problems are known as architecture mismatches in software engineering [34]. Fig. 1. Reconfigurable software structure. tion upon reconfiguration. The other contributions of this paper include construction and evaluation of reconfigurable software for a real control system and showing making tradeoffs between flexibility and performance. The rest of this paper is ....
A. M. Zaremski and J. M. Wing, "Specification matching of software components," ACM Trans. Softw. Eng. Method., vol. 6, no. 4, pp. 333--369, Oct. 1997.
....of the component, forming: # ( 0 21 3 4 #5 6 ) 7 8 9 : 28 9 : Several specification based retrieval engines [6, 11] have been developed using automated theorem provers to verify that a component specification matches a problem specification. Zaremski and Wing [16] established a number of match conditions for assessing specification reuse. Figure 2 shows a portion of these match conditions. A problem specification is a DRIO specification that specifies the behavior of a system yet to be implemented. A library exists that contains component specifications. ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, Oct. 1995.
....A common technique for facilitating matching is to associate signatures with components. These signatures can then be used as keys to retrieve relevant components from an existing library of components. Use of finite types as signatures was first proposed by Rittri [19] Zaremski and Wing [23, 24] used a similar approach for retrieving components from an ML like functional library. Moreover, they also emphasized flexibility and support for user defined types. Bridging: In a multi lingual context, bridge code for gluing components written in different languages (such as C, C , and Java) ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In Proceedings of 3rd ACM SIGSOFT Symposium on the Foundation of Software Engineering, pages 6--17, 1995.
....to sort out most of the plumbing issues when putting components together to build applications. However, all parties are starting to recognise that this kind of (signature) interoperability is not sufficient for ensuring the correct development of componentbased applications in open systems [17]. Traditional approaches to overcome this limitation try to add semantic information to interfaces, using different notations (pre post conditions, temporal logic, Petri nets, refinement calculus, etc. and are also concerned about compatibility and substitutability of components (see [11] for a ....
Zaremski, A. M., Wing, J. M.: Specification Matching of Software Components, ACM Trans. on Software Engineering and Methodology, 6(4), October 1997, 333--369.
....library routines strcpy and strcat, and users would be very unhappy if one were substituted for the other. Furthermore, in large software modules many methods have the same signature but very di#erent behaviors. For instance, in the C math library nearly two thirds of the functions are float#float [51]. Another limitation that most current approaches present at this level is that interfaces only describe the services that components o#er (i.e. their supported operations) but not those services that they require from other components during their execution (i.e. their required operations) ....
....but also semantically. The work by America has been followed by many others, which use di#erent notations for specifying the objects behavior and deepen into the intrinsic problems of behavioral subtyping. Along the lines of America, the works by Liskov and Wing [32] Zaremski and Wing [51], and Dhara and Leavens [16] use behavioral specifications based on pre post conditions and invariants for proving partial correctness of object substitutability. Nierstrasz uses his own notation in [40] and Mikhajlova uses a refinement calculus based extension of an object oriented language with ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM Trans. on Software Engineering and Methodology, 6(4):333--369, Oct. 1997.
....services non required, or for adapting their interfaces for compatibility or interoperability) and some glue language can be also used for composing and coordinating component interactions. Traditionally, the search and matching processes of components have been defined on a one to one basis [9, 29, 30]. However, this is not the common case in most real applications: COTS components are coarse grained components that integrate several services and offer many interfaces. For instance, an Internet navigator or a Word processor, apart from their core services, they also offer others, such as web ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM Trans. on Software Engineering and Methodology, 6(4):333--369, Oct. 1997.
....to sort out most of the plumbing issues when putting components together to build applications. However, all parties are starting to recognise that this kind of (signature) interoperability is not sufficient for ensuring the correct development of componentbased applications in open systems [14]. Traditional approaches to overcome this limitation try to add semantic information to interfaces, using different notations (pre post conditions, temporal logic, Petri nets, refinement calculus, etc. and are also concerned about compatibility and substitutability of components (see [8] for a ....
Zaremski, A. M., Wing, J. M.: Specification Matching of Software Components, ACM Trans. on Software Engineering and Methodology, 6(4), October 1997, 333--369.
....to define application components, their interfaces, and interconnections is based on the notation of Interface Definition Language [37] by OMG. The application s non functional properties are formally specified in terms of the first order logic, so the software specification matching mechanism [69] can be used to retrieve the components of the middleware customized to the application needs. Even though connectors are (conceptually) considered as basic architectural elements in Aster, their ultimate goal is to locate a middleware architecture mediating the interaction between application ....
Zaremski, A. M., Wing, J. M.: Specification matching of software components. In Proceedings of the ACM SIGSOFT'95 Symposium on Foundations of Software Engineering, #995. 97 Appendix A: Programming Framework Interfaces
....properties must be gathered and quantified in a stable manner. Researchers have delineated common component properties to produce a representative subset for specific analysis. For instance, specification matching involves comparing component interface definitions for component retrieval [33]. Specification matching is directed toward obtaining components that have the appropriate functionality, without focusing on whether control and data can be properly exchanged. Moreover, architecture definition languages (ADLs) have examined properties for interaction problems among components. ....
....not concur upon all contents within the interface definition, there are many common elements that cover distinct analysis goals. For example, one interface definition for component retrieval from a library is comprised of a component signature, component specification, and protocol specification [33]. Used in the context of component retrieval, the interface definition serves to eliminate components whose signatures and specifications do not correspond. With the goal of supporting CBSE, interface definition frameworks can also be used for interface modeling [16] The component or interface ....
Zaremski, A., Wing, J. Specification Matching of Software Components. TOSEM,16(4): 333-69, 1997.
.... include specification matching, architecture definition languages (ADLs) and interface definition frameworks (IDFs) Specification matching is directed toward obtaining components that have the appropriate functionality, without focusing on whether control and data can be properly exchanged [17]. ADLs have exa mined properties for interaction problems among components [1, 12] These properties are often detailed and specific to the particular analysis goals of the ADL. Research in IDFs focuses on fronting components with representative properties to facilitate their choice, e.g. from a ....
A. Zaremski, J. Wing. Specification Matching of Software Components. TOSEM,16(4): 333-69, 1997.
....technique to provide more complete support. To be reused, a module has to provide behaviors that are needed in the new application environment. In other words, the module must match the other modules with which it will interact. There are a number of definitions of match in the literature. In [18], a number of issues have been raised regarding software reuse: retrieval, reuse, substitution, subtype, and interoperation. In retrieval, we want to retrieve a component from a software library that satisfies a given query. In reuse, we adapt a component from a software library to fit the ....
....one software component with another without affecting the observable behavior of the entire system; a special case of substitution is when a subtype object is the component substituting for the supertype object. In interoperation, we want one component to interact properly with the other [18]. All these issues are related; however, in this paper, we will focus on interoperation. The simplest, and possibly original, technique for organizing reusable software modules is a subroutine library (e.g. a function library in C) The advent of object oriented languages has stimulated higher ....
[Article contains additional citation context not shown here]
A.M. Zaremski and J.M. Wing, "Specification Matching of Software Components," Proc. ACM SIGSOFT Symp. on the Foundations of Software Engineering, October 1995. 13
....LaSSIE are organized into hierarchical, taxonomic categories. It is difficult to construct such systems because they need to formalize expert knowledge that is difficult to elicit, and they are difficult to scale. Formal method based approaches use either signatures [39] or formal specifications [40] to represent components. Signaturebased approaches are easy to use, but suffer from the impreciseness of representation; formal specification approaches are time consuming and cognitively challenging for reusers. CodeBroker is most similar to those systems adopting text based approach. ....
Zaremski, A.M. and J.M. Wing, "Specification Matching of Software Components," ACM Trans. Soft. Eng. Meth., 6(4), 333-369 (1997).
....locate a function f 0 in the library whose signature matches that of f . The hope is that the semantics of function f 0 will be the same as, or at least related to, those of function f , so that f 0 may be reused to implement f . Zaremski and Wing later considered specification matching [76], in which algebraic specifications, rather than signatures, are the criteria used to match pairs of functions. The heart of the Z W model is its notion of relaxed matching. The authors asked the question: how dissimilar can function signatures be, while still being similar enough to be ....
....of type matching (which they term module matching) to be defined in terms of particular kinds of method matching. Also in the spirit of their work, we will differentiate exact matches from relaxed matches. Zaremski and Wing have also extended their approach to encompass specification matching [76], which relies upon formal specifications of program semantics. This area has also been explored in the object oriented domain by Liskov and Wing s work on behavioral subtyping [49] This dissertation considers only signature matching, leaving polylingual specification matching for future work. ....
[Article contains additional citation context not shown here]
Zaremski, Amy Moormann, and Wing, Jeannette M. Specification matching of software components. In Proceedings of the Third ACM SIGSOFT Symposium on Foundations of Software Engineering (Oct. 1995), Gail Kaiser, Ed., pp. 6--17. Also appeared as Carnegie-Mellon technical report CMU-CS-95-127. 274
....it ultimately depends on the kind of reuse which the tool aims at. Most often, deduction based SCR is configured to ensure plug in compatibility of the retrieved components: c matches if it has a weaker precondition and a stronger postcondition than the search key q. This is usually (cf. e.g. [34]) formalized as (pre q ) pre c ) post c ) post q ) 4 . However, this is not adequate for partial functions. If q is a partial function (e.g. tail) and c its total completion (e.g. c(nil) returns nil) then we want c to match q even if its completed result does not fit the original ....
....match q even if its completed result does not fit the original specification. It is thus necessary to restrict the implication between the postconditions on the domain given by pre q . We thus work with proof tasks of the form (pre q ) pre c ) pre q post c ) post q ) 1) which are similar to [34] s guarded plug in match except for our use of the stronger (via the first implication) precondition from the query. Plug in compatibility supports safe reuse. The retrieved components may be considered as black boxes and may be reused as is , without further proviso or modification of the ....
[Article contains additional citation context not shown here]
A. M. Zaremski and J. M. Wing. Specification matching of software components. In [13], pp. 6--17.
....to subtyping as used in object oriented programming. Compatibility of components may be verified at the syntactic or at the behavioral level, the latter approach enforcing software robustness. For instance, behavioral compatibility of components may rely on software specification matching (e.g. [Zaremski Wing 1995]) In the same way, the second issue may be simply addressed at the syntactic level, in which case each component specifies the type of connector that it requires, and two interacting components have to use compatible types of connector. However, enabling to reason about compatibility of ....
A. Zaremski and J. Wing. Specification matching of software components. Proceedings of the ACM SIGSOFT95 Symposium on Foundations of Software Engineering. 1995.
....component implementations in a systematic way. Successors of this proposal then enhanced the practicality of systematic software retrieval. A software retrieval tool that may be used in any development environment is presented in (Rollins and Wing 1991) This capacity is further enhanced in (Zaremski and Wing 1997), which provides a framework to support the definition of various refinement relations. Efficiency of software retrieval is addressed in (Mili et al. 1997) which proposes to organize the software database according to a refinement relation over software specifications. This work and its more ....
Zaremski A. M. and Wing J. M. (1997) Specification Matching of Software Components. ACM Transactions on Software Engineering and Methodology, 6(4):333-369.
....of a middleware service with respect to a transactional property requires a tool based on theorem proving technology. There exist various such tools that have been exploited successfully for the retrieval of software components with respect to functional properties expressed in first order logic [10, 19, 17]. We further have implemented our own in the ASTER project for the retrieval of software components providing non functional properties, still expressed in first order logic [9] Up to now, we have not yet experimented the use of a tool that deals with transactional properties based on temporal ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In Proceedings of the ACM SIGSOFT'95 Symposium on Foundations of Software Engineering, pages 6--17, 1995.
....of services can be modeled. Although this approach covers some semantic aspects of a service it does not provide a full behavioural description. Liskov and Wing use pre and post conditions in addition to signatures to describe the state of a service provider before and after an operation call [ZW95b, LC93]. Conditions are specified as state predicates over the formal parameters of operations. Although this is the most powerful approach for describing the semantics of service types it has several drawbacks. First of all, pre and post conditions for any but the simplest service types tend to be ....
....binary relations. Then a relationship between two service types A and B denotes that an object realizing service type B could be used by an application expecting an object of service type A without affecting the observable behaviour of the entire application. This is called substitution [ZW95b] or subtyping [Lis87] Zaremski and Wing [ZW95a] present a formal framework for relations between modules and functions to be used in the retrieval of software for reuse. As any relation between modules is based on a relation between functions it is truly orthogonal. We have extended this ....
[Article contains additional citation context not shown here]
A.M. Zaremski and J.M. Wing. Specification matching of software components. In Proceedings of the 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, October 1995.
....of a middleware service with respect to a transactional property requires a tool based on theorem proving technology. There exist various such tools that have been exploited successfully for the retrieval of software components with respect to functional properties expressed in first order logic [14, 26, 23]. We further have implemented our own in the Aster project for the retrieval of software components providing non functional properties, still expressed in first order logic [12] Up to now, we have not yet experimented the use of a tool that deals with transactional properties based on temporal ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In Proceedings of the ACM SIGSOFT'95 Symposium on Foundations of Software Engineering, pages 6--17, 1995. 19
....immediately inform the new user. Additionally, such a tool might describe ways in which the usage could be modified to meet the specifications, or modifications to the component to meet the user s needs. This sort of formal component matching is similar to work of Penix Alexander (1997) and Zaremski Wing (1995), as well as that proposed by the IBROW project (Benjamins, et al. 1998) While we have argued that extra technical, informal information can be critical for cost effective reuse, we also recognize that such information about components has a significant drawback simply because of its ....
Zaremski, A. and Wing, J. (1995). Specification Matching of Software Components. Proceedings of the Third ACM SIGSOFT Symposium on Foundations of Software Engineering, Washington, DC, 6-17.
....[18] They prove that (iii) must only be satisfied for those post conditions of a subclass that may become true in the context of the superclass. Zaremski and Wing use a proof theoretic approach to check the conformance and the use of objects for correctness in Larch ML [36] programs [37]. In object oriented languages like Simula [9] C [31] Modula 3 [4, 5] Sather( K) 30, 13] and Java [14] contra covariance (or a stronger condition) is checked only for those predicates that are computable at compile time, namely for the (static) types. This approach was formalized by ....
A.M. Zaremski and J.M. Wing. Specification matching of software components. ACM Trans. Software Engineering and Methodology., 6(4):333 -- 369, 1997. 10
....Invalidate specifications when appropriate. Modifications to a system definition or to the sources of derived information may render individual parts of a specification invalid. Search for components that partially match a partial specification, with an indication of the goodness of fit. ZarWing95] Support checking, both that a component specification and its associated implementation are consistent and that a configuration of components is well formed. Support tools to make minor adaptations when minor mismatches are detected. Support incremental checking for incremental ....
A.M. Zaremski and J.M. Wing, "Specification Matching of Software Components." Proc. of SIGSOFT Foundations of Software Engineering, October 1995. Keywords: software architecture, specification, software analysis, extra-functional properties, incremental specification, credentials
....Problem 1. Querying by class and method name can be performed in many development environments. All the above libraries address Problem 2 by offering name based search facilities which provide rudimentary querying capabilities. Many other search and retrieval strategies have been proposed[19, 4, 17]. Manual browsing of libraries is also a strategy addressing Problem 2. The sizes of the libraries under consideration are not so large as to render browsing infeasible. Pintado[16] suggests another strategy for large libraries, called affinity browsing . Under this scheme, metrics and ....
A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. In Proc. Third Symposium on the Foundations of Software Engineering (FSE3), pages 6--17. ACM SIGSOFT, Oct. 1995. 10
....matching criteria. 2 Position In light of the foregoing observations, one may think that formal methods of software components storage and retrieval are widely used in practice. Yet despite the abundance of such methods, and despite the wide range of cost vs quality that these methods provide [1, 2, 3, 4, 5, 6, 7], they are mostly ignored by industry, in favor of traditional, low tech solutions that are inspired from information retrieval or from library science [8] We submit the position that both kinds of methods are needed to do a satisfactory job in component storage and retrieval: traditional ....
A. M. Zaremski and J. M. Wing, "Specification matching of software components," in Proceedings, SIGSOFT '95: Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, (New York, NY), ACM Press, April 1995.
....and integration system. We also plan to augment a previously developed formal specification based component classification scheme [5] by incorporating component architectural properties. 3 Comparison Several projects have applied formal methods to specifying and retrieving reusable components [5, 6, 7]. The formal specifications used in these projects are limited to functional specifications. The only (implicit) way that the components can be used is data sharing and or function invocation. The UniCon architectural specification language [8] specifies the interface of a component as a set of ....
A. M. Zaremski and J. M. Wing, "Specification matching of software components," in 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, October 1995.
....checking . We have argued that Description Logics are typelike formalisms (concepts are unary predicates after all) where subsumption can be used in ways similar to type signature matching. In fact, DLs seem to form a nice middle ground between signature matching [28] and specification matching [29]. DLs were designed for modeling application domains in the natural world. Many such domains arise from the standardization e#orts of the OMG subcommittees in manufacturing, medicine, etc. where we have observed the need for capturing additional service semantics being met by the stylized use of ....
Zaremski, A., and Wing, J., "Specification matching of software components," ACM TOSEM 6(4), 1997. 10
.... collections of interdependent units) and above: e.g. function suites or monads in functional language programming systems [24] whole theories or theory extensions in theorem proving systems [5] object classes in OOP systems; and whole specifications in formal software development environments [27]. This paper is concerned with extending unit matching to module level and supporting multiple parallel queries. Searches can be narrowed significantly, and instantiations made more specific, by matching two or more units at a time, rather than unit by unit. For example, anyone who has used a web ....
....to the query predicate, as well as predicates that are weaker or stronger. The VCR system [3] uses implicit VDM specifications as queries for retrieval of software components. The search mechanism searches for components with weaker preconditions and stronger postconditions. Zaremski and Wing [27, 25] extend specification matching to the module level. For module matching the user gives a set of type and function specifications as a query. The query matches a module if each query type specification matches a type specification from the module and each query function specification matches a ....
A.M. Zaremski and J.M. Wing. Specification matching of software components. In Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, 1996. 26
.... [Lam79, Ben96, Par98, Jef98] to drive refinements of the specification and generate proof obligations [Car90, Abr96, Dar96] to generate test cases and oracles from the specification [Ber91, Ric92, Roo94, Wey94, Man95] to support formal reuse of components through specification matching [Kat87, Reu91, Mas97, Zar97]. Formal specifications can also be generated from program code as a basis for reverse engineering and software evolution [Gan96, Ern99] Specify. for whom One of the problems with formal specifications is that they may concern different classes of consumers having fairly different ....
....considered are more likely to be similar than solutions. Specification reuse should therefore be even more promising than code reuse. Surprisingly enough, techniques for retrieving, adapting, and consolidating reusable specifications have received relatively little attention so far (see, e.g. [Zar97] for some recent work in this direction) A constructive approach to formal specification should also favor the reuse of specifications that proved to be good and effective for similar systems. Measurability of progress. To be more convincing, the benefits of using formal specifications in ....
A.M. Zaremski and J. Wing "Specification Matching of Software Components", ACM Transactions on Software Engineering and Methodology, Vol. 6 No. 4, October 1997, 333- 369.
....specify the input output constraints of a function. Some formal specification methods such as Larch are used to verify a system s specification. One approach uses Larch to find components in a library according to their functionality which is specified through pre post condition predicates [96]. The approach does not scale to a large library and complex functionality. Informal information such as texts as pre post conditions and comments can help the analyst to understand the functionality of larger components by inspection and composition of the smaller components functions. The ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. Proceedings of SIGSOFT 95 Software Engineering Notes, 20(4):6--17, October 1995. 57
....this is a matching process between a query of the broker (which originally came from the customer) and the characteristics of the PSMs. The first selection of relevant PSMs for the query considers the competence of the PSM. Several types of matches are possible between the query and the PSM Zaremski Wing, 1997, two of which are: The PSM has weaker requirements assumptions and stronger competence than what the query requires (safe retrieval) The PSM has stronger competence than the query asks, regardless of its requirements (unsafe retrieval) Apart from the matching process, additional knowledge is ....
Zaremski & Wing, 1997 Zaremski, A. M. & Wing, J. M. (1997). Specification matching of software components. ACM Transactions on Software Engineering and Methodology, 6(4):333--369.
....it is known that this renders subsumption undecidable. Therefore, we can view DLs as type like formalisms [3] where subsumption can be used in ways similar to type signature matching. In fact, DLs seem to form a nice middle ground between signature matching [30] and specification matching [31]. DLs were designed for modeling application domains in the natural world. Many such domains arise from the standardization e#orts of the OMG subcommittees in manufacturing, medicine, etc. where we have observed the need for capturing additional service semantics being met by the stylized use of ....
Zaremski, A., and Wing, J., "Specification matching of software components," ACM TOSEM 6(4), 1997.
....prototype that is used to perform an evaluation of their approach. The experiment presented is based on 87 C , Smalltalk and Eiffel assets. Formal specifications have been recognized as an important feature of any organized approach to component storage and retrieval for the purpose of reuse [26, 37, 40, 41, 43, 16, 49, 56, 57]. Implicit in most of the retrieval methods of software components is the idea that the retrieval algorithm attempts to identify those components of the library that minimize some measure of distance to the user query. ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In Proceedings, SIGSOFT '95: 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, volume SEN 20(4), pages 6 -- 17, New York, NY: ACM Press, October 1995.
.... Keyword, facet[56] frame[15] descriptor[46] lexical affinity[41] and feature based[10] techniques all seek to find relevant components based upon controlled vocabularies, properties and ontologies external to the component; Static Indices: Type signature[69] and specification matching[32, 57, 22, 70] techniques seek to find relevant components based upon elements of the structure of software components. A external static hybrid approach has been proposed in [21] Dynamic Indices: Behavioural techniques seek to take advantage of the distinguishing property of software executability. ....
A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. In Proc. Third Symposium on the Foundations of Software Engineering (FSE3), pages 6--17. ACM SIGSOFT, October 1995.
....Problem 1. Querying by class and method name can be performed in many development environments. All the above libraries address Problem 2 by offering name based search facilities which provide rudimentary querying capabilities. Many other search and retrieval strategies have been proposed[19, 4, 16]. Manual browsing of libraries is also a strategy addressing Problem 2. The sizes of the libraries under consideration are not so large as to render browsing infeasible. Pintado[15] suggests another strategy for large libraries, called affinity browsing . Under this scheme, metrics and ....
A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. In Proc. Third Symposium on the Foundations of Software Engineering (FSE3), pages 6--17. ACM SIGSOFT, October 1995.
....that processes instances of the types is referred to as polymorphism (e.g. 6] By analogy, we term this interoperability problem the polylingual access problem. 1 Although techniques for determining type equivalence or compatibility are a challenging research topic in their own right (e.g. [23, 24, 25]) for purposes of this paper we presume such determinations can be made, in at least some interesting cases. We discuss this issue further in Section 4. The remainder of this section is organized as follows. Section 2.1 presents a hypothetical interoperability scenario illustrating the ....
....weaker, and therefore probably more prevalent and hence more useful, kinds of compatibilities. Subsequently, we plan to investigate richer forms of type compatibility, based on deeper, semantics based analyses of the relationships between types. Zaremski and Wing s work on specification matching [25] and Blaine and Goldberg s work on axiomatic approaches [3] represent two valuable points of departure for our research in this area. In addition, we are currently exploring augmenting Open OODB with other languages, such as Ada95. The addition of other languages will allow us to continue our ....
A. M. Zaremski and J. M. Wing. Specification matching of software components. In The Third Symposium on the Foundations of Software Engineering, pages 6--17, Washington, D.C., Oct 1995.
....94] However this subject needs further research. We also stepped over the problem that apart from providing the right behaviour, as specified by some object s worldview, the object we want to plug in must be able to communicate with the former in a way that is understandable for both of them. ZW95] mention this problem as well. They define a generic match predicate between components that can be extended with additional predicates like e.g. a protocol match predicate. However they do not delve further into this matter so we would welcome further research here as well. ....
A.M. Zaremski and J.M. Wing. Specification matching of software components. In Proceedings of the 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, October 1995.
....Methods Applied to Software Reuse Software reuse is the process of constructing a software system using existing software components. Jeng and Cheng [18] describe the use of a generality operator as the formal basis for identifying reusable components via specification matching. Zaremski and Wing [19] describe several operators for matching queries to components for software reuse. In addition, Penix and Alexander [20] define the satisfies criterion for component matching. Table 2.3 lists several of the matching operators. 1 When these operators are used for software reuse, A is a query ....
....by requiring that the derived abstraction and the as built specification satisfy a matching relation. 6. 1 Specification Matching and Software Reuse Many approaches have been suggested for the retrieval of components from reusable component libraries, ranging from classification of search criteria [19, 20] to retrieval [31, 32, 33] and library structuring [34] Jeng and Cheng describe the use of analogy and generality [18, 35] as the basis for matching functions. Zaremski and Wing have proposed a technique for signature [21] and specification matching [19] Fischer et al. have described an ....
[Article contains additional citation context not shown here]
A. M. Zaremski and J. M. Wing, "Specification Matching of Software Components," in Proceedings of the 3rd ACM SIGSOFT Symposium on the Foundations of Software Engineering, 1995.
....Each are proposed standards for primitive object models. OSF s OpenDoc [18] uses SOM, while Microsoft s OLE [5] uses COM. Even though each purports to adress object interoperability, their own heterogeneity raises futher interoperability issues. Research on component software at Carnegie Mellon [19, 31] and elsewhere [21] has spurred the development of promising methodologies that apply formal methods. Work in the area of control infrastructures has led to the investigation of composition languages. Nierstrasz and Meijler have described requirements for composition languages that are to be used ....
A. Zaremski and J. Wing. Specification matching of software components. In Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering, 1995.
....to their failure behaviors. Hence, the problem of constructing a customized execution platform is translated to software specification matching of failure behaviors: given the specifications of the failure behaviors declared by application modules, retrieve a set of modules that match them [7]. During the specification matching process, failure behavior specifications are decomposed into simpler ones describing the execution properties that constitute the specific failure behavior. Some of these execution properties will be provided by the neighbor application modules and some other ....
....use of our reasoning is the interconnection of modules according to pre and post conditions. More precisely, based on the rules of consequences and composition described in [8] we can respectively relax the constraints of specification matching from exact match to plug in match [7], and verify the correctness of the failure behavior resulting from the combination of a set of failure related execution properties. We develop our approach in the Aster distributed programming environment, which is capable of reasoning on general module behaviors expressed in predicate logic ....
A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. In Proceedings of the ACM SIGSOFT Symposium on Foundations of Software Engineering, 1995.
....proofs to be done entirely in terms of specifications. In fact, once the theorems corresponding to our subtyping rules are formally stated in Larch, their proofs are almost completely mechanical a matter of symbol manipulation and could be done with the assistance of the Larch Prover[GG89, ZW97] In developing our definition, we were motivated primarily by pragmatics. Our intention is to capture the intuition programmers apply when designing type hierarchies in object oriented languages. However, intuition in the absence of precision can often go astray or lead to confusion. This is why ....
Zaremski, A. and Wing, J. Specification matching of software components. ACM Trans. on Software Engineering and Methodology, 6(4):333--369, October 1997.
No context found.
A. M. Zaremski and J. M. Wing. Specification matching of software components, Dec. 11 1997.
No context found.
ZAREMSKI,A.M.AND WING,J.M. 1997. Specification matching of software components. ACM Trans. Softw. Eng. Methodol. 6,4(Oct), 333--369.
No context found.
Zaremski, A. M. & Wing, J. (1997), `Specification matching of software components', ACM Transactions on Software Engineering 6(4), 333--369.
No context found.
A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM TOSEM, 6(4):333--369, Oct. 1997. 54
No context found.
A. M. Zaremski and J. M. Wing. Specification matching of software components. TOSEM, 6:333--369, 1997. 383
No context found.
Zaremski, A.M., Wing, J.M.: Specification matching of software components. In: Proc. Of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering, ACM Press (1995) 6--17
No context found.
A. M. Zaremski and J. M. Wing. Specification matching of software components. ACM Trans. on Software Engineering and Methodology, 6(4):333--369, Oct. 1997. 9
No context found.
A.M. Zaremski, J.`Wing, "Specification Matching of Software Components", 3rd ACM Symp. on Foundations of Soft. Engg, pp. 6--17, October 1995.
No context found.
A.M. Zaremski and J.M. Wing, "Specification Matching of Software Components," ACM Transactions on Software Engineering and Methodology, October
No context found.
ZAREMSKI,A.AND WING, J. 1997. Specification Matching of Software Components. ACM Transactions on Software Engineering and Methodology 6, 4 (Oct.), 333--369.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC