Software Design 2e - DIM

Key observationsThe entry for this study in Table 16.1 indicates the set of methods that were mostfamiliar to the respondents. (The three most familiar with experienced developers werethose of Booch, Rumbaugh and Jacobson, which have subsequently been broughttogether in the Unified Process that we examine in Section 16.5.)If we again select those observations most relevant to our themes, these include thefollowing.nnnThe relatively large proportion of time spent on analysis and design of objects relativeto the time spent on coding/testing when compared to ‘normal’ expectationsfor software development. It was thought that this might be because creating thedesign for an object is more time-consuming than the equivalent task for otherarchitectural styles.The steep learning curve required for object-oriented methods (although therespondents did view them as useful once the knowledge had been acquired). Thisis consistent with the findings from the earlier study on learning different forms ofanalysis and design methods described in Vessey and Conger (1994).The limited expectations about code reuse. Here the authors observe that ‘one ofthe most advertised benefits of OO is reuse, yet developers rated this lower thantrainees’. Their conclusion was that ‘this is perhaps a case of trainees believing thehype about reuse and developers actually realising the difficulty in creating reusablecode’.Overall, the study found high levels of satisfaction with object-oriented methods, bothfor analysis and design. However, as the authors caution, this may be partly an artifactcaused by the self-selection of subjects, since developers and trainees who have apositive view of object-orientation may well be more likely to have responded to asurvey of this type.Having looked briefly at these four surveys, we now address two other issuesrelated to object-oriented design practices. The first (size of objects) was not an issuethat specifically arose from these surveys, although it is of importance for objectorienteddesign practices. The second (reuse) did get mentioned in two of the surveys,and raised an equally important set of issues in terms of design practice.365Design processes for the object-oriented paradigm16.2.5 How large should an object be?This question is one that has been discussed quite extensively in terms of objectorienteddevelopment practices. Obviously, when viewed from a constructional aspect,objects can be as small or as large as the developer wishes. What, however, is at issuehere, is the question of quality, and of whether this is more readily achieved throughthe use of many smaller, but simple, objects, or fewer larger, but more complex, ones.When considered in terms of the cognitive aspects of understanding and managingthe design of objects, then clearly we might reasonably expect that larger objects arelikely to be more difficult to develop and deploy (and to reuse). On the other hand, theaggregated behaviour of many small objects may also be difficult to model and deployeffectively.