🚀 go-pugleaf

By the way, if you *really* want to start separate threads, you
will have to do it yourself, since I am too lazy, and my baudrate
is too slow, for me to do it myself.

jhull@thor.NoSubdomain.NoDomain (Joseph F. (Jeff) Hull) writes:

>johnson@cs.uiuc.edu (Ralph Johnson) writes:

>|> First of all, when it comes to reuse, "object" is too small a level of
>|> granularity.  

>One of the basic ideas that we are working with right now is that reuse
>needs to occur at several levels of granularity rather than just one.

>The lowest level of granularity that seems appropriate is represented by
>Grady Booch's Reusable Ada Components (as discussed in Software Components
>With Ada, Grady Booch, 1987, Benjamin/Cummings Publishing).  These include
>reusable stacks and queues, for example.  We refer to this as the "nuts and
>bolts" level of reusable software.

I come from the Smalltalk world.  Booch's components are a take-off from
the Smalltalk Collection classes.  The Collection classes are certainly
useful, and they provide a low level of reuse, but they don't provide 
anything like the reuse that you get from Model/View/Controller.  MVC is
a framework, not just a set of components, so you can not only reuse the
components that come with it, but you can easily extend it with new
components.  The cases that I've heard about with 80-90% reuse are ones
in which 

>DoD is urging the concept of "Domain-directed Reuse," by which they mean
>analyzing some particular applications domain, e.g., Command, Control,
>Communication and Intelligence (aka C3I); developing a generic architecture
>and vocabulary for the domain; and developing reusable software based on
>"standard elements" of the domain as defined by that architecture and 
>vocabulary.

DOD is urging it, but other people have been doing it for many years.
That is what user interface frameworks like MVC or MacApp or InterViews
are.  Except that they have really got it backward.  In my experience,
you find the architecture and vocabulary IN THE PROCESS OF building the
reusable software.  This is the waterfall fallacy all over again.

Small components are the easy part.  In the Smalltalk world, saying that
we should reuse data structure classes is about as novel as saying that
we should use higher-level languages.  The hard part is making the larger
scale frameworks.

>|> The best way to measure the reusability of something is to try to reuse
>|> it.  ...

>I'm afraid I didn't communicate my question well enough.  What I was trying 
>to ask was, "What criteria can we observe and measure to determine that one 
>piece of software is better than another?" and also, "What techniques, 
>practices and behaviors should/must we encourage on the part of software 
>developers so the components they develop will be more reusable?"

I understood your (first)  question perfectly.  I realize that you don't
like my answer.  Everybody wants some simple metric by which they can
tell whether software is good, but no such metric exists.  If it ever 
does exist, it will have to be validated by comparing it against the
true measure of reusability.  If you want to tell whether one piece of
software is more reusable than another, reuse it and see.  At least there
is *some* way to measure reusability, even though it is pretty expensive.

My paper on "Documenting Frameworks using Patterns" is in the OOPSLA
proceedings which is the latest SIGPLAN Notices issue, or you can ftp
it from st.cs.uiuc.edu as /pub/st80_r41/hotdraw/HotDraw-documentation.ps,
which is a Postscript file.

Ralph Johnson -- University of Illinois at Urbana-Champaign