Coding or comprehension? The essence of software system design

Abstract

Throughout the disciplines of engineering, modelling and simulation are generally considered as important components of any modern designer's tool kit. They allow the powerful mechanisms of abstraction, decomposition and formalisation to be brought to bear in tangible ways, creating platforms for the analysis, discussion and communication of ideas. Many traditional engineering design disciplines have developed well-integrated and highly successful procedures for using these tools, with the result that there is no need for individual designers to reflect on the status of the tools or on their clearly separable from that of the artefact being designed. There is little danger, for example, of the civil engineer confusing the plaster model of the dam, or the partial differential equations capturing stress in the structure with the dam itself. The designer of software, however, is faced with a rather more complex scenario. The artefact to be constructed is, itself, an abstract representation of some perceived reality, and it is often not clear how modelling and simulation relate to this abstract domain. is the artefact itself a model and , if so, what is it exactly that is being modelled? Is a software simulation of the finished system a model of the system and, if so, is the system a model of itself? Questions such as these may seem contrived and esoteric and most software designers can function quite satisfactorily without ever discussing them - indeed many designers feel distinctly uncomfortable when such issues are raised. It is important, however, that such issues are directly addressed by those individuals who are proposing methods and CASE tools as frameworks for system design. Underlying assumptions about the role of modelling and simulation in the system development process play a central part in all methods and tools; it is important that such assumptions are explicitly recognised, both by the designer of the tool and by the system developer who is to use it. If the views of the tool designer on such fundamental issues are not fully understood and shared by practitioners, effective use of the tool may be seriously impaired. This paper discusses the role of modelling in software design, and puts forward the view that software engineers use models, not in the same way as traditional engineers, but more like scientists. The latter construct models to give substance to a theoretical understanding of some domain that does not yet possess a clearly defined structure. The model and theory are developed hand in hand, and can often be understood only in conjunction. We consider two important implications of this view of the software development process. The first of these is that it is not obvious what comprises the artefact: the theory or the model. A further implication is that the traditional system life cycle may well be placing the emphasis of the development process in the wrong place, by stressing the central role of the lines of code being developed, rather than the theoretical comprehension of the system.