Software Design 2e - DIM

19.2.3 Using design toolsCASE tools (Computer Assisted Software Engineering) formed one of the ‘silver bullets’of the 1980s, but somehow never quite achieved the impact that was hoped for. Thereare probably many reasons for this, but a major one must be their relative rigidity andlack of flexibility, coupled with steep learning curves (Budgen et al., 1993). Certainly,tools are useful for recording the form of a design, but of questionable use for the creativeelements of its development. Even where such a tool contains analytical elementsto help check a design for consistency and completeness, these can only address syntacticaspects, while the key need is for assessing a design against the requirements ofthe problem that it is intended to address.CASE tools are also constrained by the notations that they use. Even if we considerour diagrams to be ‘projections’ from a single abstract design model, it is quite difficultto record that in a systematic and usable manner (Reeves et al., 1995).Another class of tool that may offer some real help with developing design solutionsis the ‘broker’ that we mentioned when discussing CBSE developments. A brokercan help with locating patterns, frameworks and components and has the potentialto form a ‘design catalogue’ if provided with suitable forms of interface. Indeed, if abroker could be combined with a suitable flexible form of CASE tool of the ‘traditional’type, then this might greatly extend the scope of tools in terms of being able toprovide really useful support for designers.447Improving knowledge transfer19.3 Improving knowledge transferA key theme that we keep returning to throughout this book is the idea of transferringknowledge about how to design software and, indeed, all of the chapters deal withsome aspect of this task. However, as befits an academic text, the focus has beenlargely on those practices that are in reasonably widespread use. In this final sectionthough, we briefly consider what other techniques might have the potential to providenew ways of transferring knowledge.We have already discussed one of the possible ways forward at the end of the precedingsection, namely making fuller use of tools to assist the process. As we recognizedthere, while tools are limited in what they can do because of the strongly creativeaspects of the design process, there may well be scope for them to do more. However,such developments may need a better understanding of notations as well as of howsoftware design models can be described.In terms of techniques rather than tools, one possible route is to seek ideas fromother branches of computing. One of the more promising of these is that of Case-BasedReasoning (CBR), as discussed in Grupe et al. (1998). CBR has long been used in theartificial intelligence domain, and is part predicated upon the premise that softwareobjects and components embody reusable experience, since a CBR system needs to bebuilt around a variety of previously successful design solutions. However, while thismay prove a valuable concept for future use (and is not wholly unrelated to the idea ofa design pattern), its development needs a much richer basis of established and welldocumenteddesign examples than is currently available.