cox@stpstn.UUCP (Brad Cox) (07/03/90)
>In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes:
:I reassert that any artifact that we build can provide components for
:later reuse. I also assert that if we have built a component we can
:adequately describe it in a formal or informal notation so that its
:complete behavior is understandable by a human. I also know that
:providing such information for later reuse requires much labor at great
:cost. This is the impediment to software reuse. The issue is "given
:that you can describe a domain, how do build a information repository in
:a cost-effective manner."
:
:As an example, take the domain of data structures. It is a relatively
:simple domain. It is well understood. There are both formal and
:informal methods for describing modeling representations and storage
:structures. We understand the complexity of them all, including special
:cases and programming tricks. Yet to date, there is not one reusable
:data structure depository. Why is that? Because the costs of putting
:all the knowledge contained in existing data structure books and
:articles would be incredible.
Of course, as you're no doubt aware, the costs of the software crisis
are even more incredible, and increasing fast as we bleakly trudge into
the Age of Information. In fact, if the Age of Manufacturing is any
indication, the costs of *not* solving it are likely to be a matter
of not only technical interest or even personal prosperity, but
national prosperity.
I share your enthusiasm for formal/informal methods of specifying
representations and storage structures, as well as your appreciation
for their costs. What you've called a depository, I'd prefer to call
a software components marketplace to emphasize that a successful solution
must be an active place where producers and consumers continually
interact, rather than a stagnant pool, database, repository, etc.
But such a marketplace brings humanity face to face with a problem
we've never faced before; managing a marketplace (i.e. a place of
competing and cooperative interests) in which the products are so
completely intangible, not to mention easy to rip off, as small
granularity software components. Therefore Stepstone has been actively
pursuing formal/informal specification/testing technologies for several
of years as a solution to the intangibility problem, which we view not
merely as a matter of technical or even commercial interest, but a
matter of global/national significance in the Age of Information.
I go into all this in greater detail in an article under review for
IEEE Software magazine, November 1990, titled "Planning the Software
Industrial Revolution; The Impact of OO Technologies". Send a mailing
address if you'd like a draft copy.
--
Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (07/04/90)
In article <5313@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >Stepstone has been actively >pursuing formal/informal specification/testing technologies for several ^^^^^^^^^^^^^^^ >of years as a solution to the intangibility problem, which we view not >merely as a matter of technical or even commercial interest, but a >matter of global/national significance in the Age of Information. > >I go into all this in greater detail in an article under review for >IEEE Software magazine, November 1990, titled "Planning the Software >Industrial Revolution; The Impact of OO Technologies". Send a mailing >address if you'd like a draft copy. Exactly what do you mean by formal in relationship to informal? Are you saying that there are both formal and informal methods used in your specification and testing activities? Is there some guideline as to what is to be done formally and what can be informal? It seems to me that in any case where formal methods are used, there are going to be many areas that are left to informal treatment. My observation has been that methods and tools that allow the requirements to be represented in a concise manner are essential. This implies that there is an accepted "language" that is powerful enough to allow a concise representation of a design. Some methods are more formal (read mathematical) than others. It seems to me that if we are to make the intangibles more tangible, we need to make advances in finding ways to represent our designs in an informal yet concise and precise manner. -- John Dudeck "I always ask them, How well do jdudeck@Polyslo.CalPoly.Edu you want it tested?" ESL: 62013975 Tel: 805-545-9549 -- D. Stearns