A. Zaremski, and J. Wing. ACM Transactions on Software Engineering and Methodology, 6 (4):
333--369(October 1997)
Abstract
Specification matching is a way to compare two software components,
based on descriptions of the component's behaviors. In the context of
software reuse and library retrieval, it can help determine whether
one component can be substituted for another or how one can be
modified to fit the requirements of the other. In the context of
object-oriented programming, it can help determine when one type is a
behavioral subtype of another. We use formal specifications to
describe the behavior of software components and, hence, to determine
whether two components match. We give precise definitions of not just
exact match, but, more relevantly, various flavors of relaxed match.
These definitions capture the notions of generalization,
specialization, and substitutability of software components. Since our
formal specifications are pre- and postconditions written as
predicates in first-order logic, we rely on theorem proving to
determine match and mismatch. We give examples from our implementation
of specification matching using the Larch Prover.
ACM Transactions on Software Engineering and Methodology
number
4
pages
333--369
volume
6
annote
incomplete
issn
1049-331X
categories
D.2.1 Software, SOFTWARE ENGINEERING, Requirements/Specifications.
D.2.2 Software, SOFTWARE ENGINEERING, Design Tools and Techniques,
Software libraries. D.3.3 Software, PROGRAMMING LANGUAGES, Language
Constructs and Features, Modules, packages. F.3.1 Theory of
Computation, LOGICS AND MEANINGS OF PROGRAMS, Specifying and Verifying
and Reasoning about Programs, Pre- and post-conditions. F.3.1 Theory
of Computation, LOGICS AND MEANINGS OF PROGRAMS, Specifying and
Verifying and Reasoning about Programs, Specification techniques.
H.3.3 Information Systems, INFORMATION STORAGE AND RETRIEVAL,
Information Search and Retrieval, Retrieval models. H.3.3 Information
Systems, INFORMATION STORAGE AND RETRIEVAL, Information Search and
Retrieval, Selection process.
%0 Journal Article
%1 zaremski1997a
%A Zaremski, A. M.
%A Wing, J. M.
%D 1997
%J ACM Transactions on Software Engineering and Methodology
%K imported
%N 4
%P 333--369
%T Specification Matching of Software Components
%U http://www.acm.org/pubs/articles/journals/tosem/1997-6-4/p333-zaremski/p333-zaremski.pdf
%V 6
%X Specification matching is a way to compare two software components,
based on descriptions of the component's behaviors. In the context of
software reuse and library retrieval, it can help determine whether
one component can be substituted for another or how one can be
modified to fit the requirements of the other. In the context of
object-oriented programming, it can help determine when one type is a
behavioral subtype of another. We use formal specifications to
describe the behavior of software components and, hence, to determine
whether two components match. We give precise definitions of not just
exact match, but, more relevantly, various flavors of relaxed match.
These definitions capture the notions of generalization,
specialization, and substitutability of software components. Since our
formal specifications are pre- and postconditions written as
predicates in first-order logic, we rely on theorem proving to
determine match and mismatch. We give examples from our implementation
of specification matching using the Larch Prover.
%Z incomplete
@article{zaremski1997a,
abstract = {Specification matching is a way to compare two software components,
based on descriptions of the component's behaviors. In the context of
software reuse and library retrieval, it can help determine whether
one component can be substituted for another or how one can be
modified to fit the requirements of the other. In the context of
object-oriented programming, it can help determine when one type is a
behavioral subtype of another. We use formal specifications to
describe the behavior of software components and, hence, to determine
whether two components match. We give precise definitions of not just
exact match, but, more relevantly, various flavors of relaxed match.
These definitions capture the notions of generalization,
specialization, and substitutability of software components. Since our
formal specifications are pre- and postconditions written as
predicates in first-order logic, we rely on theorem proving to
determine match and mismatch. We give examples from our implementation
of specification matching using the Larch Prover.},
added-at = {2006-03-09T08:15:35.000+0100},
annote = {incomplete},
author = {Zaremski, A. M. and Wing, J. M.},
biburl = {https://www.bibsonomy.org/bibtex/25ca3ae8fbfa0a9eed29d158bdede4c17/snowball},
categories = {D.2.1 Software, SOFTWARE ENGINEERING, Requirements/Specifications.
D.2.2 Software, SOFTWARE ENGINEERING, Design Tools and Techniques,
Software libraries. D.3.3 Software, PROGRAMMING LANGUAGES, Language
Constructs and Features, Modules, packages. F.3.1 Theory of
Computation, LOGICS AND MEANINGS OF PROGRAMS, Specifying and Verifying
and Reasoning about Programs, Pre- and post-conditions. F.3.1 Theory
of Computation, LOGICS AND MEANINGS OF PROGRAMS, Specifying and
Verifying and Reasoning about Programs, Specification techniques.
H.3.3 Information Systems, INFORMATION STORAGE AND RETRIEVAL,
Information Search and Retrieval, Retrieval models. H.3.3 Information
Systems, INFORMATION STORAGE AND RETRIEVAL, Information Search and
Retrieval, Selection process.},
genterms = {DOCUMENTATION, STANDARDIZATION, THEORY},
interhash = {5b403039784a0c17c4ac0e8cbe6556b7},
intrahash = {5ca3ae8fbfa0a9eed29d158bdede4c17},
issn = {1049-331X},
journal = {ACM Transactions on Software Engineering and Methodology},
keywords = {imported},
month = {October},
number = 4,
pages = {333--369},
publaddr = {New York , NY , USA},
referencedby = {\cite{1999:tosem:damiani}},
timestamp = {2006-03-09T08:15:35.000+0100},
title = {{S}pecification {M}atching of {S}oftware {C}omponents},
url = {http://www.acm.org/pubs/articles/journals/tosem/1997-6-4/p333-zaremski/p333-zaremski.pdf},
volume = 6,
year = 1997
}