Design

In an object-oriented approach, the distinction between analysis and design is primarily one of emphasis; emphasis on modeling the reality of the problem domain versus emphasis on providing an architectural model of a system that lends itself to implementation. One of the attractive features of such an approach is the opportunity of a seamless transition between the respective phases of the software product in development. The classical waterfall model can no longer be considered as appropriate for such an approach. An alternative model, the fountain model, is proposed by  [Hend92]. This model allows for a more autonomous development of software components, within the constraints of a unifying framework. The end goal of such a development process may be viewed as a repository of reusable components. A similar viewpoint has originally been proposed by  [Cox86] and  [Meyer88]. In examining the primary goals of design,  [Meyer88] distinguishes between reusability, quality and ease of maintenance. Naturally, reusable software presupposes quality, hence both quality and maintainability are important design goals. See slide 1-design.

Object-Oriented Design

The software life-cycle

  		Traditional Object Oriented
  
  Requirements        20         20
  Design              30         50 
  Implementation      35         20 
  Testing             15         10 
  

slide: Object-oriented design

In  [Meyer88] a rough estimate is given of the shift in effort between the phases of the software life-cycle, brought about by an object-oriented approach. Essentially, these figures show an increase in the effort needed for design. This is an immediate consequence of the observation that the development of reusable code is intrinsically more difficult. To my mind, there is yet another reason for the extra effort involved in design. In practice it appears to be difficult and time consuming to arrive at the appropriate abstract data types for a given application. The implementation of these structures, on the other hand, is usually straightforward. This is another indication that the unit of reuse should perhaps not be small pieces of code, but rather (the design of) components that fit into a larger framework.

Software quality

From the perspective of software quality and maintenance, these mechanisms of encapsulation and inheritance may be characterized as powerful means to control the complexity of the code needed to realize a system. See slide 1-quality.

Software quality

Maintenance -- 70\% of costs

  Requirements change --  41.8% 
  Data format change --  17.4% 
  Emergency fixes --  12.4% 
  Routine debugging --  9% 
  Hardware changes --  6.2%
  Documentation --  5.5% 
  Efficiency improvements -- 4%
  

slide: Software quality

In  [Meyer88] it is estimated that maintenance accounts for 70 % of the actual cost of software. Moreover, adaptive maintenance, which is the adaptation to changing requirements, accounts for a disproportionately large part of the cost. Of primary importance for maintenance, in the sense of the correction of errors, is the principle of locality supported by encapsulation, data abstraction and hiding. In contrast, inheritance is a feature that may interfere with maintenance, since it often breaks down the protection offered by encapsulation. However, to cope with changing requirements, inheritance provides both a convenient and relatively safe mechanism.