Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!mcnc!duke!romeo!crm From: crm@romeo.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: Re: Reuse and Abstraction (was: reu Message-ID: <19820@duke.cs.duke.edu> Date: 25 May 90 18:39:25 GMT References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <80449@tut.cis.ohio-state.edu> <19614@duke.cs.duke.edu> <80685@tut.cis.ohio-state.edu> <19760@duke.cs.duke.edu> <80884@tut.cis.ohio-state.edu> Sender: news@duke.cs.duke.edu Reply-To: crm@romeo.UUCP (Charlie Martin) Organization: Duke University CS Dept.; Durham, NC Lines: 116 In article <80884@tut.cis.ohio-state.edu> Bruce Weide writes: > >Thanks to Charlie Martin for his interesting posting about formal >specification. Among other things, he writes: > Be careful -- it's hard enough for people who *don't* like what I'm saying to shut me up.... >>.... is that one of the major advantages of Z and VDM >>is that they are *not* tied to an implementation language, and are not >>intended to be compiled. Because of this, one can invent terminology >>and new notation on the fly, one can leave out essentially uninteresting >>parts of the specification .... > >One of the primary reasons for formal specification is the inherent >ambiguity of natural language and other informal methods. It's hard >to see how having a "formal" notation that can be augmented "on the >fly" -- whenever the specifier feels a need to say something that the >language wasn't designed for -- can be much better than an informal >specification in this sense. Maybe a little better, but hardly the >ultimate formal specification language. .... One thing that might be worth a couple of beers and a bull-session sometime is to figure out what "formal" means. I recently had the word "rigorous" suggested as an alternative; let's replace the word "formal" with "rigorous" for a few lines and see if it helps any. Then what I'm saying is that I think a rigorous notation can be used which presents many of the advantages of fully-formalized (machine processable, proof-checkable) specification languages. Z and VDM seem like good approaches to this. One argument for these rigorous notations is that we are accustomed to rigorous but not fully formal notations in any case, because that is the way mathematics exposition is usually done. One hardly ever is forced back to considering foundational things (Peano axioms, cardinality of the reals) in doing day to day engineering mathematics. In fact, engineering mathematics often ignores things on a much higher level than these, like whether or not a function is continuous: we just know that most functions in, say, mechanical engineering are continuous. Thus an argument for an engineer will not state certain things that are part of the culture. And engineering math will sometimes use manipulations that are "good enough" but which will not hold if the implicit assumptions are violated. Of course, sometimes this bites a mechanical engineer or an architectural engineer as well. (One could argue that this kind of mistake was what brought done the Kansas City Flyway: on one side, the designer didn't know that it was hard to put a thread and nut in the MIDDLE of a long unthreaded rod; on the other, the people building it didn't realize that resolving this by making the one rod into two rods with a shear between them wouldn't be structurally sound.) > >Charlie also argues: > >>Actually, it's pretty hard to show a library of reusable components that >>are generally agreed to be reusable, and non-trivial. Maybe InterViews. >>But I think we may be instanciating "easy" differently: what I mean is >>"there are no technical difficulties (that I can see), so it should just >>be a matter of applying some time and effort to doing so." It s an >>interesting sort of task, but it's one that academic types are not >>attracted to because a formal specification of a basically uninteresting >>library isn't going to make a good publication, and one which industrial >>types aren't likely to try unless soemone comes up with the money. > >Actually, there are some academic types (e.g., me) who don't think the >exercise is so trivial, and who don't believe that there are "no >technical difficulties" in developing a well-designed library of >reusable components. Even things like stacks, lists, associate search >structures, graphs, etc., ar NOT designed properly for reuse as they >appear in the CS textbooks or in existing component libraries. I think I was clumsily trying to get at the same point: there are not many examples because it's hard to come up with a good library of reusable components. However, I think that if you can propose the collection of operations etc that go with such a library, then "rigorous" specification (avoiding the nasty word again) of the operations is not so big a problem. But there is a more significant, essentially political, problem (at least in my opinion), and another significant technical problem that I'm actually running into in my dissertation (so any suggestions will be welcome, BEELIEVE YOU ME!) Political problem: Let's say I as a researcher determine that I want to build up a really good reusable non-trivial library. I spend a year (maybe that little) developing the specs and implementing it. Where do I publish? How much tenure credit will I get for it? My view is a little parochial, since the only department I've ever been closely associated with is Duke's. But I can tell you that from here it looks like academics are rewarded for theorems, not for programs; theorems can be made into publications very quickly, and therer are many many journals that like to see them. Programs, even with good specifications, take a long time to implement and try out after you've had the idea and worked it out. Then papers on them are acceptable at (it seems to me) many fewer places. The result is that at Duke, it is very much harder for systems people to get tenure. What I hear suggests that this is true elsewhere, perhaps nearly everywhere. I'd love to hear that it is different; I'd even more like to see good evidence that it is different, as someday *I* will be trying to get tenure, I hope. on to the Technical Problem: once you have a library of components that you claim are reusable, how can you demonstrate scientifically that they are more reusable or better for reuse than anyone else's components? What is your measure of "reusability"? > we hope, however, that >it does not turn out to be impossible :-). I'm with you there, brother. Charlie Martin (...!mcnc!duke!crm, crm@summanulla.mc.duke.edu) O: NBSR/One University Place/Suite 250/Durham, NC 27707/919-490-1966 H: 13 Gorham Place/Durham, NC 27705/919-383-2256