Software Design 2e - DIM

262.1 What is software?The software design processIn the first chapter we examined the characteristics of the general process of design andidentified those features of design that characterize it as being a creative task. In thischapter we will be concerned with examining the ways in which the design of softwarefits into this general pattern, and identifying any ways in which the task of designingsoftware might differ from that of designing any other forms of artifact. So havingbegun the previous chapter by asking the question ‘what is design?’, it is appropriateto begin this chapter by considering the question ‘what is software?’.When people first began to develop computer-based applications that were recognizedas being large enough to merit an explicit design phase, this question was one thatwas unlikely to have been asked by anyone. Until the mid-1970s at least, software wasconsidered to encompass all of the forms that were concerned with generating ‘executablebinary code’ that was intended for execution on a single machine. Indeed, thisassumption was effectively implicit in all early thinking about software design. Thestructure of such systems was largely fixed when the code was compiled (which can bedescribed as ‘compile-time binding’) and so the ideas of the designer(s) were directedtowards producing a single monolithic unit of binary code. Indeed, while the term‘software’ might be used at different times to describe both ‘source code’ and theresulting binary code, the close link between these generally rendered the distinctionunimportant.By the 1970s the idea that computing tasks could be distributed across multiplecomputers had been added, with the further possibility of changing the links betweenthese at run-time. While this development could largely be considered to be a variationin the details of implementation, it did of course influence the thinking of the designersof such systems. Where the eventual system was to be implemented as a distributedone, the designers now had to incorporate additional factors into their decisionmaking,such as how functionality and data were to be partitioned or shared betweenmachines, the form of communication mechanisms to employ, and the likely performanceeffects of these choices.This process of variation in the forms of implementation has continued apace,and in the 1990s in particular, the development of the Internet has added many newparameters. Ideas about distribution have further extended the potential for employingrun-time binding to determine the final structure of a system, as well as extendingideas about distribution (terms such as ‘client–server’ are now widespread, if not particularlywell-defined). At the same time, the addition of ‘scripting’ forms to staticdescription notations such as HTML and XML has further extended our ideas aboutthe forms that ‘software’ might take.In some ways, the effect of these developments upon design thinking has probablybeen less than might be expected (and arguably, somewhat less than might be desirable).At one level, such concepts as architectural style have helped with classifyingthe wealth of implementation forms. However, in some ways this is more a matter ofhaving the question of implementation form considered earlier in the design processrather than being a radical change in the nature of the design process itself.The one factor that these developments have particularly highlighted, and the onethat existing design practices (including many described in this book) have been leastsuccessful in addressing, is the continuing demand for faster delivery of systems. While