Software Design 2e - DIM

42018.1 The case for rigourA formal approach to designThe role of so-called ‘formal methods’ in the software development process is a largetopic, and one that is still developing and evolving. This chapter will chiefly be concernedwith describing the forms of notation and the procedures that they employ, andwith considering how their application fits within the framework for the softwaredesign process that was developed in Chapter 9. Taken together, these will allow us tomake some comparisons with the properties of the systematic methods that weredescribed in the previous chapters.The systematic software design methods, such as those described and analysed inthe preceding chapters, all make use of graphical representation forms, supported tovarying degrees by structured text and free text. One problem with these notations isthat they generally lack any rigorous syntactic and semantic foundations, and so it isdifficult to reason about them in any ‘formal’ manner. In particular, to understand themeaning of any diagram we may well need to resolve ambiguities of interpretation byconsulting the textual components. (This is not to say that all diagrams have no welldefinedsyntax and semantics. Jackson’s Structure Diagram form has a very welldefinedsyntax, together with some semantic content, while the Statechart described inChapter 7 can certainly be regarded as more rigorous, since it is based on mathematicalformalisms and therefore unambiguous in nature.)The problems caused by this lack of a firm syntax and well-defined semantics formany of the diagrammatical notations used in systematic design practices can easily beseen when we consider issues such as design verification. In many of the forms consideredso far, it is virtually impossible to perform any kind of verification operationto make a comparison between the eventual design and the initial requirement. This isbecause the design transformations have so changed the forms of description (or theirinterpretation), that there is little or no scope to perform such checks in a rigorousmanner, or to reason analytically about the properties of the design itself. As a resultof these transformations, the design virtual machine that is used in the early stagesof the design process is unlikely to be compatible with that which is used in a laterstage.Formal methods seek to overcome this problem through the use of formalspecification languages, based on mathematical structures. The use of such formspermits the application of mathematical techniques in reasoning about a design andits properties. In return, there is of course a corresponding reduction in terms of thepowers of abstraction that are offered by such notations when compared with thesystematic forms of diagram. In seeking to remove ambiguity, the penalty incurred isto reduce abstraction and enforce a greater attention to detail than may always bedesirable in terms of the needs of the design process.The role of formal methods can therefore be summarized as being to providemathematically based techniques that can be used for describing system properties –remembering, though, that the notations can still be diagrammatical in form, as in theexample of the Statechart.In terms of the framework for describing a ‘method’ used in this book, the formalmethods are skewed in a very different manner to the systematic methods, in that theyhave: