13.07.2015 Views

Software Design 2e - DIM

Software Design 2e - DIM

Software Design 2e - DIM

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

444Whither software design?Figure 19.1Evolution of vertical architectural elements.well as the agile methods. <strong>Design</strong> patterns in particular do offer the ability to distilexperience fairly rapidly about structures that work (it is certainly a quicker process towrite a new pattern, once recognized, than to develop a new design method).The same can be considered to apply to descriptive forms too. We have no shortageof notations that can describe the properties embodied in the basic four viewpoints(function, behaviour, data modelling and construction). What may be needed, however,is some adaptation of the interpretation of these forms when being used otherthan with procedural code. Indeed, the question of which elements of a web-based systemneed to be modelled is more the key issue than the choice of forms to use.For a typical web-based client–server system, neither the server structure nor thebrowser form are of major interest to the application designer (although they may constrainthe options of course). Instead it is ‘pages, hyperlinks and dynamic content onthe client and server’ that need to be modelled (Conallen, 1999). Much of this can bequite adequately achieved by using and adapting existing forms.What is less clear perhaps is how extensively such systems are developed by usingany form of systematic design practice, whether methods or patterns. Indeed, the processesof design for such systems are probably very informal (and for smaller systemsat least, this may well be quite adequate).Overall, therefore, we would appear to have the means of coping with designingsystems around most of the variations in the form of software, even if this may requiresome adaptation at times. In the next section we briefly review how well we can captureand codify design knowledge, and ask whether the existing forms and practicesare likely to evolve further and, if so, by what means this might occur.19.2 Codifying design knowledgeSince design knowledge takes many forms and can encompass many ‘levels’ of abstraction,the problems of codifying such knowledge are not confined to the softwaredomain! However, as we have recognized in the early chapters, the unique characteristicsof software do present the designer with additional challenges and opportunities.In this section we begin by briefly considering knowledge about the form of a system,and then knowledge about the processes that might be used to create it.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!