Each A level subject field has a status field associated with it. If the subject field is null then it would not make sense to allow a user to set values in the corresponding status field.
Therefore, if the subject field is set to null, then the application should set the status field to null and disable it. If a user then selects a subject in the subject field, then the status field should be enabled. Figure 12.12 shows a simple statechart that models this behaviour.
A user may enter the Details screen either to create a new student record or to edit an existing one. If a new student record is being created then state 11 will be entered because the subject and status fields will both be null. If an existing record is being edited then the software may enter state 11 or state 12, depending on whether the subject field contains a value after the data for the student has been fetched from the database. A transient state is required, to allow the data to be fetched before entering state 11 or 12 (see Figure 12.13 and Table 12.4). The default start arrow indicates that state 10 is entered regardless of whether the Edit or New button is clicked in the Summary screen. If the Edit button is clicked in the Summary screen then the student record is fetched from the database before state 10 is entered. Alternatively, if the New button is clicked in the Summary screen then the fields in the Details scrcen are cleared before state 10 is entered.1 If the subject 1 field is null then state 11 is entered, otherwise state 12 is entered.
There are four A level subject fields and a similar statechart is required for each of them. The fields do not have to work together and so each statechart can be an
1. The actions that will cause the data to be fetched or the screen items to be cleared are associated with the Edit and New buttons being clicked. These events will be modelled in another part of the statechart.
162 CASE STUDIES
Table 12.4 The event-action table for the statechart in Figure 12.13
Current state Event Actions Next State
10 (Subject 1 field = null) 1 1 subject fields determine the next states.
The GCSEs tab-card
The GCSEs tab-card contains two lists: a list of all the possible GCSE subjects and a list of the GCSEs that the student has studied. A user can type the grade achieved by the student in each of the subjects in a column to the right of the subject name in the second list.
Four buttons are provided for moving subjects from one list to the other. At any given time, a subject can appear in only one of the lists. Hence, as one list fills up, the other gradually becomes empty. When one list is empty the buttons that allow a user to move GCSEs from that list should be disabled. For instance, if the list on the left of the screen becomes empty, then the Add and Add All buttons should be disabled. Similarly, if the list on the right of the screen becomes empty, then the Remove and Remove All buttons should be disabled.
From the above description of the buttons, it is clear that the state of the lists determines the state of the buttons. Figure 12.15 shows the four states the two lists can be in and the corresponding state of the buttons (‘e ’ for enabled and ‘d ’ for disabled). Note that the diagram refers to the list on the left of the screen as the ‘available’ list and the list on the right of the screen as the ‘selected’ list.
The diagram shows that if there are no GCSEs in either list then all four buttons are disabled (state 22). If there are GCSEs in both lists then all four buttons are enabled (state 25). If there are GCSEs in the available list and none in the selected list, then the Add and Add All buttons are enabled and the Remove and Remove All buttons are disabled (state 23). Finally, if there are no GCSEs in the available list but some in the
CASE STUDY 3: A STUDENT DATABASE 163
[a Level Subjects
selected list, then the Add and Add All buttons are disabled and the Remove and Remove All buttons are enabled (state 24).
As a user interacts with the buttons and moves GCSEs from one list to the other, the appli
cation may move from one state to another. The shift from one state to another occurs either when a list becomes empty or when an empty list receives a GCSE. The conditions that will cause such transitions are captured in Figure 12.16. Notice that state 22 is isolated from the other states - there are no transitions entering or exiting it. If there are no GCSEs in either list then the software will always be in state 22. If there are GCSEs in the lists, then it is not possible to remove GCSEs from both lists and so state 22 will not be reached.
164 CASE STUDIES
When the Details screen is entered, the appropriate state needs to be entered. The initial state could be any one of the four states and therefore a transient state is required (see Figure 12.17). Although this statechart models the required behaviour of the four buttons in the GCSEs tab-card, it is not particularly easy to understand. The events and conditions clutter the diagram unnecessarily.
A more elegant solution is given in Figure 12.18. With this design, the software initially enters state 26 - a transient state. The conditions on the arrows exiting this state test whether the lists are empty or not. The results of these tests determine the next state. Each
CASE STUDY 3: A STUDENT DATABASE 165
time a user clicks one of the four buttons for moving GCSEs between the lists, the software enters the transient state 26 before immediately moving on to the next state. For instance, if the software is in state 25 and the user clicks the Remove button then this event causes the currently selected GCSE subject in the selected list to be moved to the available list.
The software then moves to state 26. If the user has just removed the last GCSE from the selected list, then the selected list will be empty and state 23 will be entered. This design is superior because it easy to understand through using a smaller number of event arrows with simpler conditions on the arrows.
Notice that many of the entries in the event-action table for this statechart are very similar.
For example, the ‘Add button clicked’ events which cause transitions 23 to 26 and 25 to 26, both have the same actions and the same end state. An important principle of the technique is to keep such transitions separate from each other - even though it means duplicating code. It is vital that individual events can be identified and changed in isolation from other events if the software is to be maintainable in the long term.
166 CASE STUDIES
V____________________________________________ J
Figure 12.18