marick@m.cs.uiuc.edu (08/10/90)
> Yet the largest number of > problems in a software system seem to be traceable back to requirements and > design flaws. Just a quick note. I surveyed 17 published descriptions of error data from commercial/government projects. The percentage of errors attributable to requirements/design varied from 17% to 74%. There are all sorts of possible reasons for the variation, not the least of which is classification error. However, I suspect that the novelty of the product has a lot to do with it. Different circumstances require different tools. OO will be more appropriate in some cases than in others. Ditto for rapid prototyping. Ditto for software ICs. Ditto for different approaches to the implementation of that idea. It's a huge world out there, with lots of room for niches and not much chance of a grand unifying approach.
johnson@m.cs.uiuc.edu (08/10/90)
I agree with Chuck Plinta (cpp@sei.cmu.edu), who said: >Also, products such as nuts and bolts (stacks and queues) are not >the products I'm talking about. Engineers designing a car, a bridge, >or the next generation fighter, do not start with nuts and bolts. They >have higher level concepts/components available to them. These concepts >are present in the "standard" architecture, and this tends to be their >starting point. For example, cars are not designed from scratch each year. >A basic architecture is chosen, and some aspects of the car are enhanced >or changed. However, I think that that is also the opinion of the Smalltalk community. The important part of a design is not the class, it is the interface. The most important kind of reuse does not happen one class at a time, it happens with entire application frameworks. Model/View/Controller is not just a set of classes, it is a way of thinking, a reusable design. There are a few domains where computer science has produced standard, reusable designs. In particular, there are classes on the design of compilers, operating systems, and database systems. However, we seem to think that it is beneath our dignity to worry about building standard designs for other kinds of applications. These reusable designs are tremendously successful. Compare the complexity/power ratio of Unix with OS/360. Building OS/360 cost a tremendous amount of money, while it is pretty easy to make a Unix clone. Most of us would rather use Unix. The difference is that the designers of OS/360 were inventing operating systems as they went along, while Unix clone makers have a couple of decades of research and experimentation to rely upon. Perhaps the most important strength of object-oriented programming is its ability to represent these abstract designs. At the University of Illinois we are building frameworks for operating systems (Choices) and for optimizing compilers (TS). It is hard enough to design frameworks for application domains that have seen a lot of research, but it is going to be a lot harder to build them for domains in which computer scientists have little experience. Nevertheless, I think that frameworks for particular application domains are where we will find pay-offs of several orders of magnitude, and am very interested in projects to build frameworks for different kinds of applications. I am very interested in learning more about the C3 project that Chuck Plinta mentioned. Ralph Johnson - Univerisity of Illinois at Urbana-Champaign