🚀 go-pugleaf

|> jhull@thor.den.mmc.com (Joseph F. -Jeff- Hull) writes:
|> 
|> >What constitutes a "good" object.  What makes one design "better" than
|> >another?  What makes one piece of software more or less reusable than
|> >another?  How _should_ documentation differ for a reusable piece of
|> >software from a project-specific piece?  How _should_ test materials
|> >differ?


In article <BwsItJ.Lx5@cs.uiuc.edu>, 
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.

Clearly, a larger payoff can result from reusing "larger" components.  This
is directly analogous to the increasing scale of integration in the hardware
world. (Remember when we used to build gates by hand from discrete components?
remember how excited we got when HP put 6, count 'em *6*, gates on a single
LS7400?? chip?  Today, of course, no gets excited at anything smaller than
an entire computer on a single chip.)  But remember how many chips fell by
the wayside because their designers did not capture the fancy of the market;
something about their design was inferior to the competition.  Today, software
is in the same place.

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.

Still, this doesn't reduce the utility nor the applicability of "smaller"
components.


|> The thing that makes an integrated circuit so reusable
|> is that it is a member of a family of compatible integrated circuits.
|> There are standard interfaces so that any of them can be mixed with
|> any of the others.  Thus, we really need to be defining abstract interfaces
|> as well as sets of objects that meet them.  

Absolutely!  Standard interfaces were the great enabler of hardware integration
efforts and I believe they will perform the same role for software reuse.  The
followup question is, "What characteristics of interfaces enable reuse?  (-or-
How do we design interfaces to enable their implementing software to be easily
reused?)"  Let's make this question a separate thread.


|> 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?"

Of course, at this point we are flying blind (or at least vision impaired)
inasmuch as we *don't know* what constitutes reusable software, much less
what practices encourage it.  Let's make this issue a separate thread.


|> Documentation for reusable software must tell you have to use it.  This
|> is different from telling you how it works.  It is useful to explain how
|> it works, too, but lots of people just want to solve their problems
|> without learning a lot of theory.  

Exactly.  Let's make this discussion a separate thread.  Can we identify what
characteristics "documentation for reuse" should have?

|> I just presented a paper at OOPSLA
|> called "Documenting Frameworks using Patterns" that shows one way to
|> do this.  A similar way (and one I like) is given by the MacApp Cookbook.

Would you please (re)publish that paper here?  Or at least e-mail me a copy?


-- 
	   _   _
    /_    / ) / ) Jeff Hull           jhull@thor.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>