Software Design 2e - DIM

378Designing with objectsdescribe all the details of this process, and of the documentation issues in particular forwhich the reader is referred to ESA (1989) or Robinson (1992). We will mainly focusour attention on outlining the first two steps, since the key design decisions are madewithin them and the later ones largely elaborate upon these choices.The first activity of the design process in step 1 requires the designer to perform aninitial analysis of the problem. This is really a major task, and ideally would itself beundertaken in an object-oriented fashion, so that the analysis of the problem in termsof its constituent objects could be used to provide guidance to the designer in the nexttask, which is to identify suitable candidates for solution (design) objects.In the absence of suitable analysis techniques, Booch originally recommended theuse of Structured Systems Analysis for this task, while the HOOD developers havesuggested that SADT provides a good alternative form (Marca and McGowan, 1988).Both of these analysis techniques are, of course, based on the use of functional decompositionrather than on a true object-oriented strategy, and indeed, as we observed inSection 16.2, the enforced separation of date storage and data processing is incompatiblewith the object model (Wieringa, 1998).The unsatisfactory form of step 1 (in terms of building an object-oriented modelfrom the beginning) leads to the difficulties of step 2. This step essentially requires thedesigner to ‘rough out’ an initial architectural solution to the problem, which can thenbe analysed to provide a more detailed object-based design model.Step 2 therefore has to act as a ‘bridge’ between the (possibly function-oriented)model produced by the analysis of step 1, and the object-centred needs of the succeedingsteps. Without doubt this remains an inelegant and poorly structured transformation,and one that has probably most inhibited the further development of HOOD.16.4.4 HOOD heuristicsThe relatively weak structure of the HOOD design process might reasonably lead tothe interpretation that this effectively consists almost entirely of heuristics. However,even then, as Buxton and McDermid (1992) have observed ‘the published heuristicsseem a little vague’!These authors observe too that HOOD ‘identifies several classes of object, onlyone of which corresponds to a “real-world” entity’, and summarize these as being:nnnentities from the problem domain;actions, often expressed through active objects;virtual machines that group operations that are all used at some ‘superior level’;although they consider the distinction between the first two forms to be ratherartificial.Despite these limitations though, HOOD (and its notation) has continued to beused for a variety of applications and to attract some interest from researchers.However, there has not been enough of either to have led to any significant furtherevolution or developments in terms of the method itself.