6.1. First principles The process of object-oriented analysis and design

Amateur programmers are forever looking for some magic tool that would make the process of developing software trivial. The mark of professionalism is understanding that no such panacea exists. Amateurs strive to work from a "cookbook"; professionals know that a flawlessly by-the-book approach leads to absurd design decisions. Behind the words "design method" developers try to hide from responsibility for errors in their design decisions. Amateurs either ignore documentation altogether or build the entire project around it, caring more about how the product looks on paper than about its substance. The professional acknowledges that documentation is indispensable, but never sacrifices useful architectural innovation for its sake.

The process of object-oriented analysis and design does not reduce to a set of recipes, yet it is defined well enough to be predictable and reproducible in skilled hands. In this chapter we examine it in detail as an iterative and incremental process, describing the goals, activities, products, and measures of progress characteristic of its various phases.

6.1. First principles

Characteristics of successful projects

We will call a project successful if it satisfied (and where possible exceeded) the customer's expectations, was delivered within its time and budget constraints, and lends itself readily to change and adaptation. Using this criterion, consider the following two traits, which proved common to all the successful projects we have encountered and, remarkably, were absent from those that strike us as unsuccessful:

• A clear vision of the architecture of the system being built;
• A well-organized iterative and incremental process of working on the project.

Architecture. The mark of a sound architecture is its conceptual unity and integrity. As Brooks asserts, "conceptual integrity is the most important consideration in system design" . As shown in Chapters 1 and 5, the architecture of an object-oriented software system contains structures of classes and objects layered both horizontally and vertically. Ordinarily the end user has no concern with the architecture of the system. However, as Stroustrup points out, "a clean internal structure" plays an important role in building a system that will be understandable, testable, resilient, and able to evolve and be restructured . Moreover, it is precisely the clarity of the architecture that makes it possible to identify common abstractions and mechanisms that can be brought together, thereby making the system simpler, smaller, and more reliable.

There is no single correct way to classify abstractions and develop an architecture. In any problem domain there are always plenty of thoroughly foolish design paths, but, if one searches, quite elegant ones can be found as well. How, then, does one tell a good architecture from a bad one?

As a rule, a good architecture tends toward object orientation. This does not mean that every object-oriented architecture turns out to be good, or that only an object-oriented architecture is good. However, as was shown in Chapters 1 and 2, applying the principles of object-oriented decomposition leads to an architecture that possesses the desired properties of organized complexity.

A good architecture has the following properties:

• It constitutes a layered system of abstractions. At each level the abstractions collaborate with one another, have a clear interface to the outside world, and are built upon equally well-considered facilities of the level below.
• At each level the interface of an abstraction is strictly separated from its implementation. The implementation can be changed without affecting the interface. Changing internally, abstractions continue to meet the expectations of external clients.
• The architecture is simple, that is, it contains nothing superfluous: common behavior is achieved through common abstractions and mechanisms.

We distinguish between strategic and tactical decisions. A strategic decision has major architectural significance and is bound up with the high level of the system. Mechanisms for error detection and handling, user interface paradigms, memory management policy, object persistence, synchronization of processes running in real time - these are all strategic architectural decisions. By contrast, a tactical decision has only local architectural significance and is therefore usually bound up with the details of the interface and implementation of abstractions. A class protocol, a method signature, the choice of an algorithm - these are all tactical architectural decisions.

A good architecture always exhibits a balance between strategic and tactical decisions. With a weak strategy, even a very elegantly conceived class will not be able to fulfill its role properly. The most farsighted strategic decisions will be undermined if due attention is not paid to the design of individual classes. In both cases, neglect of architecture breeds the software equivalents of anarchy and confusion.

The iterative and incremental cycle. Consider two extremes - the complete absence of a formalized development life cycle, and very rigid, strictly enforced development rules. In the first case we have anarchy; through hard labor (mostly on the part of a few of its members) the development team may in the end produce something worthwhile, but the state of the project will always be immeasurable and unpredictable. One should expect the team to work quite ineffectively and perhaps to produce nothing at all fit to deliver to the customer. This is an example of a project in free fall [There is a chance that a project in free fall will land safely, but you should not bet your company's future on it]. In the second case we have a dictatorship, in which initiative is punished, experimentation that might bring more elegance to the architecture is discouraged, and the customer's actual requirements never reach the lower-level developers correctly, hidden as they are behind a veritable paper wall erected by bureaucracy.

The successful object-oriented projects we have encountered followed neither an anarchic nor a draconian life cycle. Instead, we have observed that a successful object-oriented architecture is created through an iterative and incremental process. Design is iterative, repetitive, in the sense that the architecture already created is subjected again and again to analysis and design. In doing so, with each analysis-design-evolution cycle the strategic and tactical decisions evolve, coming closer to the end user's requirements (often even the unstated ones), while remaining simple, reliable, and open to further change.

The iterative and incremental process is the antithesis of the traditional "waterfall" and does not reduce to a one-way movement top-down or bottom-up. There are encouraging precedents for this style in the experience of building both hardware and software [3, 4]. For example, suppose one must staff a firm engaged in designing and building complex, one-of-a-kind hardware. One can use a horizontal approach, in which the project cascades like a waterfall, so that the architects hand it off to the designers, and they to the electronics engineers. This is an example of top-down design, in which we bring in narrow (though deep) specialists in their field . One can take a different path, hiring jacks-of-all-trades, each of whom can be entrusted with a vertical slice of the project from beginning to end. This already looks much more like an iterative and incremental process.

In our opinion, the process of object-oriented design does not reduce to a one-way movement top-down or bottom-up. Drook holds that well-structured complex systems can be created by the method of "round-trip gestalt design." In this method the main attention is given to the process of progressive, iterative development by refining various, yet mutually consistent, logical and physical models of the system. We believe that round-trip gestalt design constitutes the necessary foundation of the object-oriented design process.

In individual cases the problem to be solved may already be well studied and programmed many times over. The development process can then be brought into ideal order: the designers of the new system already understand which abstractions are the principal ones; they already know which mechanisms need to be used and what, in broad outline, the system's behavior will be. Creativity is still important in such a process, but here the problem is sufficiently narrowed and most of the strategic decisions are predetermined. Then, since risk has been eliminated, very high productivity figures can be achieved . The more we know about a problem, the easier it is to solve.

Most industrial problems are not like that: they involve balancing unique requirements for functionality and performance and demand the full creative commitment of the entire development team. Moreover, any human activity that requires creativity and innovation proceeds by trial and error, an iterative and incremental process that draws on the experience, competence, and talent of every member of the team [The experiments of Curtis and his colleagues support these observations. They studied the work of professional software developers, recording their actions on video camera and then analyzing their content (analysis, design, implementation, and so on) and the time spent on them. As a result of these studies it was concluded that "software creation appears to be a set of iterative, poorly ordered, and mutually overlapping processes under adaptive control... Development along a balanced top-down scheme appears as a special case, where the design scheme happened to be entirely suitable or the problem is small in size... Good designers work simultaneously at several levels of abstraction and detail" ]. So there are not and will not be standard recipes for designing software systems.

The rational design process

Nevertheless, we cannot do without recipes in describing the mature technology of development promised above, one reproducible in any organization. That is why we have characterized it as a controlled iterative and incremental process - controlled in the sense that it lends itself to verification and measurement, yet leaves sufficient freedom for creativity.

An orderly design process is extremely important for organizations that develop software. Humphrey lists the following five levels of maturity of such processes :

Unfortunately, as Parnas and Clements note: "We will never find a process that would let us design software in a strictly rational manner," since the business is creative and innovative by definition. However, they continue, "the good news is that we can fake it... (Since) developers need guidance, we will come closer to a rational development if we follow a process rather than act at random. When an organization is engaged in many software products, it makes sense to have a standard procedure... If we keep an ideal process in mind, it becomes easier to measure a project's progress" .

As an organization gains experience, the question arises: "How can creativity and innovation be reconciled with increasing manageability?" The answer lies in distinguishing between the macro and micro elements of the design process. The micro process is akin to the spiral model of development proposed by Boehm, and serves as a framework for an iterative approach to development [10]. The macro process is close to the traditional "waterfall" and sets the guiding framework for the micro process. By reconciling these two fundamentally different processes, we fake a fully rational development process and gain the basis for a certain level of maturity in the business of creating software.

We must emphasize that every project is unique, and consequently the developer must himself maintain the balance between the informality of the micro process and the formality of the macro process. For research applications developed by a tightly knit team of highly qualified developers, excessive formality will have a negative effect on innovation; for very complex projects developed by a large body of developers separated from one another in space and time, a lack of formality leads to chaos.

The remainder of this chapter gives an overview and a detailed description of the goals, products, activities, and measurable characteristics that make up the micro and macro processes of development. In the next chapter we will examine the practical manifestations of these processes, primarily from the standpoint of the managers who must oversee the course of an object-oriented project.