Of course, a CCS is a specialized product and it might reasonably be argued that most developers would not expect to tackle the production of such an application without having previous experience in the automotive area. However, similar problems arise if in the simplest of embedded applications.
Assume, for example, that you have been asked to develop an alarm clock applica- tion that operates as follows:
● Time is displayed on an LED display.
● The time may be adjusted by the user.
● An (optional) alarm will sound at a time determined by the user. A sketch of the required user interface is given in Figure 2.6.
To create the design for such an application in a ‘traditional’ manner, we might begin by drawing a context diagram (Figure 2.7).
INTRODUCTION 20
To design many embedded systems successfully, including this cruise control system, requires not just knowledge of software engineering and microcontroller hardware, but also contributions from related technical and engineering fields, often including instru- mentation, digital signal processing, artificial intelligence and control theory. In our experience, such contributions are often essential to the success of real-time software projects, yet they are not part of the formal training of the majority of software engi- neers and are frequently ignored in books and papers on real-time software design.
As with the CCS, the notation can only assist us in recording design decisions: it cannot assist in making those decisions. For example, in this type of application, a basic require- ment is to display information on the LED display. In most cases, to reduce costs, a multi- plexed display will be used. As we discuss in Chapter 21, in a multiplexed, 4-digit, LED dis- play, we need to refresh the display approximately every 5 ms. The need to update this display at this frequency will have implications for the software architecture of the whole application and must be taken into account very early in the design process. If the design- er of the system is unaware of this basic requirement, then many of the assumptions that underlie the design will be wrong, and a large amount of expensive and time-consuming redesign will be required when the project reaches the implementation phase.
DESIGNING EMBEDDED SYSTEMS USING PATTERNS 21
FIGURE 2.6 The required user interface. [a] The normal (current time) display when the alarm is not set. [b] The normal (current time) display when the alarm is set to ring. [c] The alarm time display when the A button is pressed
[Note: Pressing The A + H buttons will let the user change the alarm time (hours): the A + M buttons will similarly change the alarm time (minutes). The same procedure, using the T button will be used to change the displayed time. Pressing the A button when the alarm sounds will stop the alarm.]
T H M (c) A T H M (a) A T H M (b) A
FIGURE 2.7 A possible context diagram for an alarm clock application
LED Display Buzzer Alarm Clock Hours Switch Alarm Switch Time Switch Minutes Switch
2.3 Patterns
We can sum up the conclusions from these two examples by saying that – for those developers with experience of control system design, or the use of LED displays – the tasks are straightforward: however, for those without such experience, even the small- est of decisions can have unexpected repercussions. Unfortunately, the standard design notations that have been developed do not provide any means of substituting for the lack of experience on the part of a particular designer. The consequence is not difficult to predict, and is summarized succinctly in this quotation from an experienced devel- oper of embedded applications: ‘It’s ludicrous the way we software people reinvent the wheel with every project’ (Ganssle, 1992).
To address these problems use of ‘objects’, ‘agents’ or any new form of software building block or design notation will not greatly help. Instead, what is needed is a means of what we might call ‘recycling design experience’: specifically, we would like to find a way of incorporating techniques for reusing successful design solutions into the design process.
Recently, many developers have found that software patterns offer a way of achiev- ing this. Current work on software patterns has been inspired by the work of Christopher Alexander and his colleagues (for example Alexander et al., 1977; Alexander, 1979). Alexander is an architect who first described what he called ‘a pat- tern language’ relating various architectural problems (in buildings) to good design solutions. He defines patterns as ‘a three-part rule, which expresses a relation between a certain context, a problem, and a solution’ (Alexander, 1979, p.247).
For example, consider Alexander’s W I N D O W P L A C E pattern, summarized briefly in Figure 2.8. This takes the form of a recognizable problem, linked to a corresponding solution. More specifically, like all good patterns, W I N D O W P L A C E does the following:
● It describes, clearly and concisely, a successful solution to a significant and well- defined problem.
● It describes the circumstances in which it is appropriate to apply this solution.
● It provides a rationale for this solution.
● It describes the consequences of applying the solution.
● It gives the solution a name.
This basic concept of descriptive problem–solution mappings was adopted by Ward Cunningham and Kent Beck who used some of Alexander’s techniques as the basis for a small ‘pattern language’ intended to provide guidance to novice Smalltalk program- mers (Cunningham and Beck, 1987). This work was subsequently built upon by Erich Gamma and colleagues who, in 1995, published an influential book on general- purpose object-oriented software patterns (Gamma et al., 1995).
For example, consider the O B S E R V E R pattern (Gamma et al., 1995), illustrated in
Figure 2.9. This describes how to link the components in a multi-component applica- tion, so that when the state of one part of the system is altered, all other related parts are notified and, if necessary, updated. This pattern successfully solves the problem, while leaving the various system components loosely coupled, so that they may be more easily altered or reused in subsequent projects.
INTRODUCTION 22
DESIGNING EMBEDDED SYSTEMS USING PATTERNS 23
FIGURE 2.8 A summary of theW I N D O W P L A C Earchitectural pattern (adapted from Alexander et al., 1977)
W I N D O W P L A C E
Context
W I N D O W P L A C E is an architectural pattern. It is most frequently applied in the design of hotels,