There are essentially two high-level states the CD player can be in. The first is when there is no CD in the machine and the second is when there is a CD in the machine. The appli
cation could move from the ‘No CD Loaded’ state to the ‘CD Loaded’ state after the CD drawer has been closed and a CD has been detected in the drawer. To move in the reverse direction, a user would have to click the Eject button in the CD Loaded state. This simple behaviour is captured by the statechart in Figure 5.11.
The basic notation is very much like a state transition diagram with a few obvious differ
ences. The states are represented by rounded rectangles instead of circles. A default starting state is marked with an arrow terminated with a solid circle. The default starting state is the state that the statechart starts in when the application is started. As before arrows are labelled with events and/or conditions.3 To readily distinguish conditions from events,
3. Earlier in the chapter, conditions on event arrows were used to extend the basic STD notation. This concept was taken from the statechart notation.
50 CONCEPTS
Figure 5 .11
conditions are shown in parentheses. The only significant difference between the statechar and a conventional STD is that the event arrows can start and finish inside a state, rathe than at the edge of a slate. The reason lor this is that a state can be an abstract state witl lower-level states contained within it. For instance, consider the ‘No CD Loaded’ stat<
in Figure 5.11: we can zoom into this state and see thal it actually contains a group o substates (see Figure 5.12 and Table 5.8). The ‘CD Drawer Closed’ and ‘CD Drawe Open’ states are self-explanatory. There is a third substatc which the application enter:
when the CD drawer is in the process of closing. The reason for this is that at the poin when the Eject button is clicked in state 2, the CD player has no way of detecting whethe a CD is loaded. Therefore, the next state cannot be determined until the CD drawer ha:
closed and the application can attempt to detect the presence of a CD (there is al assumption here that the application will wait until the CD drawer is closed before i continues to execute the next line of codc). If there is no CD in the drawer then the appli cation stays in the No CD Loaded state, but moves to the CD Drawer Closed substate. I there is a CD in the drawer then the application moves to the CD Loaded state.
As in the state transition diagram, the CD Loaded state has three basic substates: Cl Playing, CD Stopped and CD Paused (see Figure 5.13). When a CD is loaded, the appli cation enters the CD Slopped state which is indicated by the default starting arrow withii Table 5.8
Current state Event Actions Next state
start Application started cd_player.close_drawer; i
I Eject button clicked cd_playeropen_drawer; 2
2 Ejcct button clickcd cd_playerdose_drawer; 3
3 (cd_playercd_loadcd = false) none 1
3 (cd _player.cd_loadcd = true) none CD loaded
A DESIGN NOTATION FOR CONTROL LAYER OBJECTS 5 I
Figure 5 .13
52 CONCEPTS
the CD Loaded state. From this state, a user can choose to start the CD playing by clicking the Play button which will cause a transition to the CD Playing state. From this state a user can choose to leave the CD playing until the end of the CD (in which case it will return lo the CD Stopped state when the CD ends), or ihe CD can be stopped or paused.
As we know from the state transition diagram of this application, the Pause state must cause the values in the Time and Track fields to oscillate repeatedly between visible and invisible.
In ihe STD, this was achieved by using iwo Paused states but this resulted in an extensive duplication of the transitions and states atlachcd to the Paused state. In the statechart version of the application, we will again use two states, but this lime they will be iniemal to the Paused state (see Figure 5.14). The advantage of this approach is that, as far as other states are concerned, there is only one Paused state - not two. And therefore the number of event arrows and states attached to the Paused state do not have to be duplicated as they did in the state transition diagram.
The semantics of the Paused state are as follows. When the state is first entered from the CD Playing stale, state 6 (Time and Track fields not blank) is enlered by default. The transition to the Paused state has an action that causes a one second timer to be created.
When this timer expires the resulting event will cause a transition to state 7 (Time and
Figure 5.14
A DESIGN NOTATION FOR CONTROL LAYER OBJECTS 53
Track fields blank) and an action associated with that transition will cause another one second timer to be created. When this timer expires, state 6 will be entered again and another timer will be created. Thus the process continues until the CD Paused state is exiled by any one of the following events: the Stop button is pressed, the Play button is pressed, or the Pause button is pressed. Notice that the event arrows for all three of these events start at the edge of the CD Paused state. This means that whether the application is in state 6 or state 7, the Play or Pause buttons being clicked will cause a transition to stale 5 and ihe Slop button being clicked will cause a transition to state 4.
We will now extend the statechart to model the behaviour of the Next Track and Previous Track buttons. Recall that, in the state transition diagram, we were forced to add event recently visited of the states in the set will be entered. The use of the history mechanism in the CD application is shown in Figure 5.15. There are three new event arrows which are related to either the Next Track or the Previous Track buttons being clicked. In all three cases, the start of ihe event arrow is attached to the edge of the CD Loaded state and termi
nates on an H enclosed in a circlc (which represents the history mechanism). For example, consider the ‘Next Track & (track <> last)' event and condition. If the statechart is in any of the sub states contained within the CD Loaded state and the user clicks the Nexl Track button and the current track is not the last track on the CD, then the corresponding actions will be executed (moving the CD player to the start of the next track and updating the Track and Time fields) and then the statechart will rcium to the last substatc it was in. Thus, if the CD application was in ihe CD Stopped state, then the CD Stopped state will be entered again. If the application was in the CD Playing state, then this stale will be re-entered. This use of ihe history mechanism is possible because the actions associated with the event are the same for each of the four states within the CD Loaded state.
It is worth pausing at this moment to compare ihe statechart in Figure 5.15 with the equivalent state transition diagram in Figure 5.9. The statechart is less chaotic and is much easier lo read and, importantly, it does not contain duplicate states or events. Bear in mind that at this point in the design of the state transition diagram, an extra eight slates and associated transitions were required in order for the CD player to step forwards and backwards one second at a time using the Forward and Reverse buttons. It was not possible to fit these into a diagram that would fit onto a page of this book. However, the statechart version requires just two extra slates to model this behaviour (see Figure 5.16).
The compete statechart for the CD player, showing the details of bolh the No CD Loaded and the CD Loaded states, along with the event-action table is given in Appendix C.
This chapter has only given an overview of the statechart noiation and a complete description will be presented in Chapter 7. Significantly, something that is not best illus
trated by the CD player example, is how sealable the approach is. A user interface can be decomposed into modules and each module can be specified independently of each other.
This is a very important point and will be addressed later in the book.
54 CONCEPTS
Figure 5.15