Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!ncar!gatech!udel!rochester!pt.cs.cmu.edu!ORCRIST.GANDALF.CS.CMU.EDU!cwk From: cwk@ORCRIST.GANDALF.CS.CMU.EDU (Charles Krueger) Newsgroups: comp.software-eng Subject: Re: Reuse, Tolerance, and Tradeoffs (was Re: Tolerance) Message-ID: <11873@pt.cs.cmu.edu> Date: 9 Feb 91 22:14:04 GMT References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <88102@tut.cis.ohio-state.edu> Organization: Carnegie-Mellon University, CS/RI Lines: 44 In article <88102@tut.cis.ohio-state.edu>, weide@elephant.cis.ohio-state.edu (Bruce Weide) writes: > In what sense is a stack design, in which no particular error is > generated when an empty stack is popped, no longer a "pure stack"? > Maybe this just illustrates the difficulty with ambiguous natural > language descriptions of components. Charles thinks "pure stack" > means one thing, I think it means something else. I doubt if there is such a thing as a "pure stack" specification. However, to illustrate how tolerance plays a role in reuse technology, my stack example was intended to show how a stack implementation might have some variance in its specification. That is, that the stack specification might say; "This reusable artifact satisfies the ANSI/Weide Pure Stack Standard postconditions under the following preconditions." I can reuse this artifact in my application if my application can satisfy the preconditions requirements of the artifact and if the postconditions satisfy the requirements of my application. Since the preconditions and postconditions represent a range conditions under which the stack artifact will operate correctly, the preconditions and postconditions correspond to the "tolerance" in the stack implementation. In some reuse technologies it is possible to vary the preconditions and postconditions of an artifact in order to optimize its performance in the application. In these cases the reuser can vary the tolerance. Consider again the stack example that has two variants: one that tests for an empty stack before popping and one that doesn't. 1. Has empty/pop check. Average time of execution: UVW Preconditions: XYZ 2. No empty/pop check. Average time of execution: UVW - 10 Preconditions: XYZ + . If the application provides tighter precondtions, then the artifact can operate faster. In general, a reusable artifact should take advantage of all of the preconditions that the application has to offer, and provide the minimum postconditions required by the application. If I were try and concisely summarize the concept of "tolerance in reusable artifacts", I would say that the preconditions of an artifact correspond to the degree of tolerance that the artifact has for a new application, and that the postconditions of an artifact correspond to the degree of tolerance that the new application must have for the artifact.