Las instituciones en el territorio del noroccidente de Popayán

User interface objects with constant behaviour

• The scrolling list has constant behaviour. A user can click a student record and that student will be highlighted. Only one row in the list can be selected at a time. The default behaviour of a scrolling list does not need to be modified for the application.

• The New button causes the Details screen to be displayed and allows a student record to be created. The button is enabled all the time and its behaviour docs not vary.

User interface objects with varying behaviour

• When the Edit button is clicked the Details screen is displayed and details of the student highlighted in the Summary screen are displayed in il. The Edit button is enabled when student records are displayed in the Summary screen scrolling list and is disabled when there are no student records in the scrolling list.

Note: this rule is based on the assumption that a record will always be highlighted if there are one or more records in the scrolling list. In other words, it relics on the default behaviour of the scrolling list object which ensures that a record is always highlighted when there are records in the list.

150 CASE STUDIES

• The Delete button deletes the student record that is currently highlighted in the scrolling list. The Delete button is enabled when student records arc displayed in the scrolling list and is disabled when there are no student records in the scrolling list.

• The Save button is used to commit changes made to the student records by a user. The Save button is disabled when the application is first started. The button becomes enabled when the Delete button is clicked or the OK button is clicked in the Details screen. After the user clicks the Save button, the button is disabled again.

• The Close button is used to exit the application. If the user has not made any changes to the student records, or changes have been made but they have been saved to the database, then the application is closed immediately when the Close button is clicked. If the user has made changcs to the student records but has not clicked the Save button, then when the Close button is clicked a modal alert message will be displayed reading: ‘Do you want to save the work you have done?’ along with three buttons: Yes. No and Cancel.

Entry and exit events

• The screen is entered when the application is started.

• The screen is entered when the OK or Canccl buttons in the Details screen are clicked.

• The screen can be exited when the Close button is clicked.

• The screen is exited when the New button is clicked.

• The screen is exited when the Edit button is clickcd.

Screen modes

Screen modes are concerned with the screen behaving in different ways depending on some condition such as the type of data displayed, the privilege of the user using the screen and so on. There are no such modes associated with the Summary screen.

Statechart design

Having identified the screen rules the next step is to start designing a statechart. The best starting point is to consider the modes that the screen can be in. However, in the case of the Summary screen, there are no such modes, so we will move on to consider the objects with varying behaviour.

From the screen rules, it is clear that the behaviour of the Edit and Delete buttons is deter­

mined by whether a student is selected in the scrolling list or not. If a student is selected, then both buttons are enabled. If a student is not selected then both buttons are disabled.

Before this behaviour is specified in a statechart, it is necessary to understand the default behaviour of a scrolling list object. After data is first fetched into the list, the first record is highlighted by default. As the user clicks records, the scrolling list object ensures that one and only one record is highlighted at a time. It is not possible to highlight a blank row if there are records in the list. If there are no records in the list, then the first (blank) row is highlighted and the user cannot highlight any other row.

When the application is started and the Summary screen is entered, all the student records will be fetched from the database and displayed in the scrolling list. If there are no student

CASE STUDY 3: A STUD EN T DATABASE 15 I

records in the database, then the Delete and Edit buttons should be disabled. If there are records in the database then the Delete and Edit buttons should be enabled. This behaviour can be modelled by using a transient state as shown in Figure 12.4. On starting the appli­

cation, the data is fetchcd from the database into the scrolling list and then state 1 is entered. The conditions on the arrows leaving state 1 are used to determine whether records are displayed in the scrolling list or not. If no student records are fetchcd from the database then state 2 is entered. If one or more student records are fetched from the database then state 3 is entered. In state 2 the Edit and Delete buttons arc disabled and in state 3 the Edit and Delete buttons are enabled. (Note: this is indicated in the diagram by labels such as

‘Edit (e)’ which indicates the Edit button is enabled and ‘Edit (d)’ which indicates the Edit button is disabled.)

The statechart in Figure 12.4 also models what happens when the Delete button is clicked.

The Delete button is enabled in state 3 and when it is clicked by a user the currently highlighted record in the scrolling list is deleted both from the screcn and the database. The deleted record may have been the only record in the scrolling list. If it was the only record in the list, then the application would have to enter state 2, otherwise it would stay in state 3. The easiest way to model this behaviour is to cause the application to enter the transient state again (state 1) when the Delete button is clicked. The action associated with the Delete event causcs the student record to be deleted and the conditions associated with state 1 then determine whether there arc any student records left in the scrolling list. The statcchart will enter either state 2 or state 3 as appropriate. The event-action table for the statechart is given in Tabic 12.1.

Note that it is possible for the Delete event not to make use of the transient state 1. Instead, two event arrows could be added. The first would be from state 3 to state 2 and would have a condition checking whether the current record is the only record in the list. That is, the label would be: Delete & (1 student in the scrolling list). The second event arrow would start and end at state 3 and would have a condition checking whether there is more than one record in the list. That is, the label would be: Delete & (> 1 student in the scrolling list).

Two event arrows are necessary bccausc both would have the action to delete the record associated with them.

We now return to the screen rules for objccts with varying behaviour. It is apparent that the Save button is enabled and disabled based on whether the user has made changes to the student

152 CASE STUDIES

Table 12 .1 The event-aclion table for the statechart in Figure 12.4.

Current state

records. This can be modelled with two states: a state in which changes have been made to the student records and a state in which changes have not been made to the student records.

The application will enter the ‘Changes have been made to the student records’ state when either the Delete button in the Summary screen is clicked, or the OK button in the Details screen is clicked. When the Save button is clicked, the changes made to the student records will be committed in the database and the application will return to the ‘Changes have not been made to the student records’ state. This behaviour is modelled by the statechart in Figure 12.5. The statechart starts in state 4, because a user will not have modified any student records when the application is first started.

Notice that the Delete event in this statechart is not intended to cause the highlighted student record to be deleted. The event that causes the record to be deleted is in the previous

Save (d)

Save (e)

Figure 12.5

CASE STUD Y 3: A STUD EN T DATABASE 153

Table 12.2 The event-action tabic for the statechart in Figure 12.5.

Current state Event Actions Next state

5 Save button clicked Commit changes to the database; 4

4 Delete button clicked 5

I Summary I

statechart in Figure 12.4. The Delete event in Figure 12.5 is a concurrent transition with no actions associated with it (see Table 12.2). It is used to signal that changes have been made to the student records and so the Save button should be enabled.

We now have two statecharts that need to be combined into a single statechart for the summary screen. The two statecharts operate almost independently of each other and so they are best kept separated in concurrent parts of the same statechart (see Figure 12.6).

154 CASE STUDIES

Notice that events that cause entry to and exit from the Details screen have been included.