Lecture
In practice every engineering discipline, be it civil, mechanical, chemical, electrical, or software engineering, contains elements both of science and of art. Petroski eloquently argues: "The design of new structures involves both flights of imagination and the synthesis of experience and knowledge: everything that an artist needs in order to realize his conception on canvas or paper. Once this conception has taken shape in the mind of the engineer-artist, it must without fail be analyzed from the standpoint of the applicability of the given scientific method by the engineer-scientist with all the rigor proper to a true scientist" [38]. Similarly, Dijkstra notes that "The formulation of a problem in software is an exercise in the application of abstraction and demands the abilities both of a formal mathematician and of a competent engineer" [39].
When a completely new system is being developed, the engineer's role as artist comes to the fore. This happens constantly in the design of programs. All the more so when working with systems that have feedback, and especially in the case of command and control systems, when we have to write software whose requirements are nonstandard and, on top of that, for a specially built processor. In other cases, for example in creating scientific applications, tools for research in artificial intelligence, or even information processing systems, the requirements for the system may be well and precisely defined, but defined in such a way that the technical level of development they call for goes beyond the limits of existing technology. We may, for instance, be asked to build a system with greater speed, greater capacity, or far more powerful functional capabilities than those that already exist. In all these cases we shall try to use familiar abstractions and mechanisms ("stable intermediate forms" in Simon's terms) as the basis of the new system. Given a large library of reusable software components, the software engineer must recombine them in new ways so as to satisfy all the explicit and implicit requirements of the system, just as an artist or a musician finds new possibilities in his instrument. But since such rich libraries hardly exist in practice, the software engineer can usually make use, unfortunately, of only a relatively short list of ready-made modules.
In any engineering discipline, design is usually understood to mean a certain unified approach by which we look for ways of solving a particular problem while ensuring that the task set is carried out. In the context of engineering design, Mostow defined the goal of design as the creation of a system that
In Stroustrup's view: "The goal of design is to identify a clear and relatively simple internal structure, sometimes called the architecture... The design is the final product of the design process" [41]. Design implies taking conflicting requirements into account. Its products are models that allow us to understand the structure of the future system, to balance requirements, and to sketch out a scheme of implementation.
The importance of building a model. Modeling is widespread in all engineering disciplines, largely because it embodies the principles of decomposition, abstraction, and hierarchy [42]. Each model describes a certain part of the system under consideration, and we in turn build new models on the basis of old ones in which we are more or less confident. Models allow us to control our failures. We evaluate the behavior of each model in ordinary and extraordinary situations, and then make the appropriate revisions if something does not satisfy us.
As we have already said, in order to understand the behavior of a complex system in all its subtleties, one has to use more than one model. For example, in designing a single-board computer, the electronics engineer must consider the system both at the level of the individual circuit elements (the chips) and at the level of the board layout. The layout helps the engineer make sense of the joint behavior of the chips. The layout is a plan for the physical implementation of the system of chips, in which the size of the board, the power consumption, and the types of integrated circuits available have been taken into account. From this point of view the engineer can independently evaluate such parameters of the system as heat distribution and manufacturability. The board designer can also consider the dynamic and static aspects of the system. Similarly, the electronics engineer uses diagrams illustrating the static connections among the various chips, and timing diagrams reflecting the behavior of the elements over time. The engineer can then apply an oscilloscope or a logic analyzer to verify the correctness of both the static and the dynamic models.
The elements of software design. Clearly, there is no universal method, no "silver bullet" [43], that would lead the software engineer along the path from the requirements for a complex software system to their fulfillment. Designing a complex software system is by no means a matter of blindly following some set of recipes. Rather it is an incremental and iterative process. Nevertheless, the use of a design methodology brings a certain organization to the development process. Software engineers have developed dozens of different methods, which we can classify into three categories. Despite their differences, these methods have something in common. In particular, they share the following:
A good design method rests on a solid theoretical foundation and at the same time gives the programmer a certain degree of freedom of expression.
Object-oriented models. Is there a best design method? There is no unequivocal answer to this question. In essence it is the previous question in disguise: "Is there a best way of decomposing a complex system?" If there is, it is not yet known to anyone. The question can be put as follows: "How is a complex system best divided into subsystems?" Let us note once more that it is most useful to build models that focus attention on the objects found in the problem domain itself and that form what we have called object-oriented decomposition.
Object-oriented analysis and design is a method that logically leads us to object-oriented decomposition. By applying object-oriented design, we create flexible programs written with economical means. By partitioning the state space sensibly, we achieve greater confidence in the correctness of our program. In the end, we reduce the risk of developing complex software systems.
Since model building is extremely important in designing complex systems, object-oriented design offers a rich choice of models, which are presented in Figure 1-4. Object-oriented design models reflect the hierarchy both of classes and of objects in the system. These models cover the whole spectrum of the most important design decisions that have to be considered in developing a complex system, and thus inspire us to create designs possessing all five attributes of well-organized complex systems.
Chapter 5 examines each of the four kinds of model in detail. Chapter 6 describes the process of object-oriented design, which is a chain of successive steps for creating and evolving the models. Chapter 7 considers the practice of managing the object-oriented design process.
In this chapter we have set out the arguments in favor of applying object-oriented analysis and design to overcome the complexity involved in developing software systems. In addition, we have identified a number of fundamental advantages achieved as a result of applying such an approach. Before we present the notation and the design process, we must study the principles on which this design process is based: abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence.
Figure 1-4. Object-oriented models.
Conclusions
Comments