The architecture of object-oriented systems

The process of software development has often been compared to the process of constructing buildings, usually in the context of defending a traditional software development method. The argument comes down to the statement that it takes a solid plan and sufficient time to lay the foundations and erect the building. The conclusion, generally, is a plea for a science of software engineering/programming, or an engineering discipline of software design. See for example  [Gries] or  [Potter91] for a similar argument in defense of formal specification methods. The line of reasoning exemplified by the building metaphor is defective in two respects. Firstly, the presupposition of a rigid ordering in time is clearly contradicted by the many attractive old city centers, which have often evolved over time without a plan. Secondly, the presupposition of a fixed method of development is clearly demonstrated to be false by modern building techniques, employing prefabricated components. Hence, neither temporal order nor procedures of construction are as fixed as they at first seem. The view expressed in the building metaphor also fails for the software life-cycle. Both throwaway and incremental prototyping have come to be accepted as viable methods for developing software. Nevertheless, when we speak of design, we think of some architectural blueprint of the system, the layout of its structure. What, we may ask, is the role of the design in the software life-cycle? And what is the function of its product, the design document?

Software Development Process -- transition

Aspects

Alternative styles


slide: Software development process

In  [Jacobs92], a detailed account is given of a method of object-oriented software engineering based on elementary architectural notions, such as (object) components and (use) relations, and strong convictions with respect to design guidelines and process management issues. See slide 3-process. An explicit distinction is made between the {\em architectural concepts}, which provide the means with which to construct various models, the method, which is a bag of guidelines telling us how to employ the architectural notions, the process, which details what steps to take to complete the software life-cycle, and the tools, which provide the software support either for the construction of models or for managing the actual process of software development, or both. In  [Jacobs92], both the method and issues of process development are spelled out in great detail, illustrated by a number of examples. These issues are clearly important in actual production environments (business or industrial), but seem to be dependent to a large extent on non-technological factors. From the perspective of software technology, we are primarily interested in the architectural notions underlying the various methods and, to a lesser extent, in the tool support for these methods. Also, apart from the architectural structure per se, we are interested in what properties a design model must have in order that we may verify that a model satisfies its initial requirements.