In this second introductory chapter, we consider why ‘traditional’ software design techniques provide only limited support for the developers of embedded applications and argue that software patterns can provide a useful adjunct to such techniques.
Introduction
Most branches of engineering have a long history. Work in the area of control systems, for example, might be said to have begun with the seminal studies by James Watt on the flywheel governor in the 1760s, while work in electrical engineering can be dated back to the work of Michael Faraday, who is generally credited with the invention of the elec- tric motor in 1821. It can be argued that the practice of civil engineering has the longest history of all, originating, perhaps, with the building of the Egyptian pyramids, or to Greek or Roman times: certainly the Institution of Civil Engineers was founded in England (UK) in 1818 and is the oldest professional engineering institution in the world.
For the software engineer, a different situation applies. The first mass-produced minicomputer, the PDP-8, was launched only in 1965 and the first microprocessor only in 1971. As a result of the comparatively late introduction, and subsequent rapid evolution, of small programmable computer systems, the field of software engineering has had little opportunity to mature. In the limited time available, much work on soft- ware engineering has focused on the design process and, in particular, on the development and use of various graphical notations, including process-oriented notations, such as dataflow diagrams (Yourdon, 1989: see Figure 2.1), and object-oriented notations, such as the ‘Unified Modelling Language’ (Fowler and Scott, 2000). The use of such notations is supported by ‘methodologies’: these are collections of ‘recipes’ for
[Note: that in this example, and throughout most of this book, we have used a process-oriented (dataflow) notation1 to record the design solutions: this remains the most popular approach for embedded applications, in part because process-oriented languages (notably ‘C’) are popular in this area. Although object-oriented languages (like C++) are comparatively uncommon in microcontroller- based embedded projects at the present time, object-oriented design notations could equally well be used to record the design pre- sented here.]
1. Please refer to Appendix A for details of this notation.
software design, detailing how and when particular notations should be used in a proj- ect (see, for example, Pont, 1996). The designs that result from the application of these techniques consist of a set of linked diagrams, each following a standard notation, and accompanied by appropriate supporting documentation (Yourdon, 1989; Booch, 1994; Pont, 1996; Fowler and Scott, 2000).
As the title suggests, we are concerned in this book with the development of soft-
ware for embedded systems. In the past, despite the ubiquitous nature of embedded applications, the design of such systems has not been a major focus of attention with- in the software field. Indeed, in almost all cases, software design techniques have been developed first to meet the needs of the developers of desktop business systems (DeMarco, 1978; Rumbaugh et al., 1991; Coleman et al., 1994), and then subsequent- ly ‘adapted’ in an attempt to meet the needs of developers of real-time and / or embed- ded applications (Hatley and Pirbhai, 1987; Selic et al., 1994; Awad et al., 1996; Douglass, 1998). We will argue (in Section 2.2) that the resulting software design tech- niques, although not without merit, cannot presently meet the needs of the designers of embedded systems. We then go on to propose (Sections 2.2 and 2.4) that the use of software patterns as an adjunct to existing techniques represents a promising way to alleviate some of the current problems.