No approach to software development is likely to survive unless it solves some of the real problems encountered in software engineering practice. In this section we will examine how the object-oriented approach is related to the conceptions of the life-cycle of software and what factors may motivate the adoption of an object-oriented approach to software development. Despite some variations in terminology, there is a generally agreed-on conception of the various phases in the development of a software product. Roughly, a distinction can be made between a phase of analysis, which aims at specifying the requirements a product must meet, a phase of design, which must result in a conceptual view of the architecture of the intended system, and a phase of implementation, covering coding, testing and, to some extent, also maintenance activities. See slide 1-lifecycle. No such consensus exists with respect to the exact relation between these phases. More specifically, there is a considerable variation in methods and guidelines describing how to make the transition from one phase to another. Another important issue is to determine what the products are exactly, in terms of software and documentation, that must result from each phase.

The software life-cycle

With an increase in the number of software products not satisfying user needs, prototyping has become quite popular!


slide: The software life-cycle

The traditional conception of the software life-cycle is known as the waterfall model, which prescribes a strictly sequential transition between the successive phases, possibly in an iterative manner. Strict regulations with respect to validation of the products resulting from each phase may be imposed to avoid the risk of backtracking. Such a rigid approach, however, may cause severe problems, since it does not easily allow for modifying decisions taken earlier. One important problem in this respect is that the needs of the users of a system may change over time, invalidating the requirements laid down in an earlier phase. To some extent this problem may be avoided by better techniques of evoking the user requirements in the analysis phase, for instance by developing a prototype. Unfortunately, the problem of accommodating changing user needs and adapting to changing circumstances (such as hardware) seems to be of a more persistent nature, which provides good reason to look at alternative software development models.

Software development models

The software engineering literature abounds with descriptions of failing software projects and remedies proposed to solve the problem of software not meeting user expectations. User expectations may be succinctly characterized by the RAMP requirements listed in slide 1-requirements. Reliability, adaptability, maintainability and performance are not unreasonable demands in themselves. However, opinions on how to satisfy these criteria clearly diverge.

Requirements -- user needs are constantly evolving


slide: Requirements -- RAMP

 [Bersoff91] and  [Davis88] explain how the choice of a particular software development model may influence the chances of successfully completing a software project. As already mentioned, rapid throwaway prototyping may help to evoke user needs at an early stage, but does not help much in adapting to evolving user requirements. A better solution in this respect is to adopt a method of evolutionary prototyping. Dependent on the technology used, however, this may cause severe problems in maintaining the integrity and robustness of the system. Less flexible, but more reliable is an approach of incremental development, which proceeds by realizing those parts of a system for which the user requirements can be clearly specified. Another means of adapting to changing user requirements is to use a technique of automated software synthesis. However, such an approach works only if the user requirements can be formalized easily. This is not always very likely, unless the application domain is sufficiently restricted. A similar constraint adheres to the reuse of software. Only in familiar application domains is it possible to anticipate how user requirements may change and how to adapt the system appropriately. Nevertheless, the reuse of software seems a very promising technique with which to reduce the cost and time involved in software products without (in principle) sacrificing reliability and performance. See slide 1-development.

Software Development Models

  • rapid throwaway prototyping -- quick and dirty
  • incremental development -- slowly evolving
  • evolutionary prototyping -- evolving requirements
  • reusable software -- reduces cost and time
  • automated software synthesis -- one level of abstraction higher

slide: Software development models

Two of the principal advocates of object-oriented technology, Cox and Meyer, regard the reuse of software as the ultimate solution to the software crisis. However, the true solution is in my opinion not so straightforward. One problem is that tools and technologies are needed to store and retrieve reusable components. That simple solutions do not suffice is illustrated by an anecdote reported by Alan Kay telling how difficult it was to find his way in the Smalltalk class structure after a significant change, despite the browsing facilities offered by the Smalltalk system. Another problem lies in the area of human factors. The incentives for programmer productivity have too long been directed at the number of lines of code to make software reuse attractive. This attitude is also encouraged in universities. Moreover, the reuse of other student's work is usually (not unjustifiably) punished instead of encouraged. However, having a sufficiently large store of reusable software at our disposal will allow us to build software meeting the RAMP requirements stated above, only if we have arrived at sufficiently stable abstractions of the application domain. In the following, we will explore how object-oriented technology is motivated by problems occurring in the respective phases of the software life-cycle and how it contributes to solving these problems.