Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide From: weide@elephant.cis.ohio-state.edu (Bruce Weide) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Message-ID: <88744@tut.cis.ohio-state.edu> Date: 22 Feb 91 19:35:51 GMT References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com> <34464@athertn.Atherton.COM> Sender: news@tut.cis.ohio-state.edu Reply-To: Bruce Weide Organization: Ohio State University Computer and Information Science Lines: 64 In article <34464@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: > >The problem is that even if an independet laboratory offers its seal of >approval, you still have to certify it yourself anyway. There are two >reasons for this. First, the possibility that your intended use would be >regarded as extreme or abberant by the original designers and laboratory >testers, in which case you will have to test just to verify that this >special case is correctly handled by the purchased object code. Second, >there is always the possibility that you the purchaser misunderstood what >the vendor offered, and that the product you purchased won't suit your >needs. Since externally it may seem what you wanted, you may not notice >this until you use it. (E.g. you want a character sort routine that uses >ascii sort order, but the one you bought uses "dictionary rules" that sorts >caps and lowercase the same and sorts Mc* as if written Mac*...). > We must be talking about slightly different things. You're talking about some particular programming language or paradigm that you use in practice (apparently), while I'm talking about how software reuse OUGHT to be done. For example, your remarks further highlight why reusable software components need to have formal specifications of their behavior as ABSTRACT components. The vendor's specification says what the component is supposed to/guaranteed to do; precisely under what conditions it works and precisely what it does under those conditions. What ordering is used by a sort routine, for example, certainly belongs in the specification (or should be a parameter to it). It's not clear why you inherently need source code for the sorting algorithm to determine this. > >So it is not the case that the one's own methods are necessarily better >at determining correctness to specification, but rather that they are >more specific for determining applicability to the situation at hand. >We use an object oriented system to do our development and inherit from >objects created by others. The amount of testing necessary on the INHERITED >CODE boggles people's minds. Not that the inherited code is necessarily >buggy, but rather not well understood in special circumstances. By inheriting >a lot, one might be able to create a complex system with a day's coding and >testing on the new module. But until the developer is completely familiar >with inherited objects there will need to be lots of testing with them! >If no source is available, and no way to determine branch coverage in >the inherited modules, testing is purely black box and may need to be more >intensive than if the developer could see in and use some white box methods. > Now you're getting into a serious problem. Inheritance (of code, at least, which is what you get in most OO languages) causes major technical problems in terms of certifying correctness, either by formal verification or by testing. Code inheritance is inherently a "white box" phenomenon... you'd better have source code for the inherited component if you expect to use code inheritance for much more than name overloading (and you don't really need inheritance for this anyway). Having -- indeed needing -- source code of reused components for subsequent re-testing is no big deal, then, if you assume a paradigm in which you need the source code of reused components in any case. My comments were directed to programming paradigms in which component reuse occurs not as a result of inheritance, but as a result of reuse of encapsulated components without violation of abstraction. -Bruce Brought to you by Super Global Mega Corp .com