Supporting the CANCEL Command Through Software Architecture

Figure 2 presents the process view of the cancellation pattern. We assume the modules in the module decomposition view map directly onto components in the process view and maintain the same names. The following threads exist in the cancellation pattern:

• the active thread. This is a running thread that the user wishes to cancel. The activities running under its control of are the ones to be cancelled.

• the listener thread. This thread provides the user with a means to indicate what is to be cancelled.

• the cancellation-control thread. This thread manages the cancellation activities. It is independent from the active thread.

• the collaborating-processes thread. This may be a collection of threads, but we model it as a single thread. It manages those processes that collaborate with the active thread.

Figure 2: Process View of Cancellation Pattern  

We explicitly label the processes in Figure 2 with the modules in the module decomposition view that map to them.

We now describe how these two views interact. The user sends a cancel stimulus to the listen-for-cancellation component running in the listener thread. This thread then

• provides feedback to the user that the cancel request has been received

• synchronizes with the cancellation component of the thread to be cancelled. This indicates to the cancellation component that the cancel activity should be carried out.

The cancellation component is executing under control of a thread created to carry out the cancellation. The active thread should not be expected to listen for a CANCEL request since it may be blocked for some reason, or it may be in an infinite loop.

The cancellation component carries out the following basic activities:

1. Terminate the active thread.

2. Inform the user of the progress and results of the cancellation.

3. Return the system to its state prior to the invocation of the active thread. This involves

   • restoring any persistent resources to their state before the invocation of the active thread

   • releasing resources acquired by the active thread

4. Inform threads collaborating with the active thread of the active threads' termination.

The first of these activities is straightforward. Presumably, the thread-control mechanisms of the operating system permit thread termination.

The second activity is also straightforward. The user should be informed about both the progress and the results of the cancellation.

The third activity (returning to the prior state) requires that the cancellation component be aware of the mechanisms for restoring persistent resources to the state before the invocation of the active thread. The cancellation component must also be aware of the resources acquired by the active components. This awareness can be achieved by a variety of mechanisms. The active components can report the acquired resources to the cancellation component, the cancellation component can intercept requests for resources, or the resource managers can provide this information to the cancellation component.

The fourth activity (informing collaborating threads) also requires knowledge on the part of the cancellation component. The cancellation component must be informed of collaboration, either synchronization or data communication, with other threads. It doesn't necessarily need to be informed of the state of the collaboration. The cancellation component can inform each of the collaborating threads of the active thread's termination. Then it becomes the responsibility of the collaborating threads to perform the correct actions, including providing feedback to the user about the progress and results of these cancellation requests, if necessary for completion of the thread's cancellation requests. Providing this information may be complicated, depending on the type of collaboration and the extent to which the collaborating components depend on the completion of the active components. One possible action is to treat the information that the active component is being cancelled as a cancellation request for the collaborating components. In this case, a recursive use of the pattern will achieve the desired results. Other types of collaborations may not require cancellation. In any case, a decision must be made regarding the desired result after the collaboration components have been informed of the active components' cancellation.  

In Section 2.2, we enumerated six measures. The analysis below describes how they can be determined.

3.1   Acknowledgment Time

The system should acknowledge to the user that it has received the CANCEL command. This should be done quickly enough to prevent the user from re-issuing the command (i.e., within 150 ms).⁵  The acknowledgement should be done by the listener module.  

Returning to the original system state depends on three things: (1) the mechanism used by the active modules to provide for returning to the original state, (2) the determination of the resources being used by the active modules, and (3) the notification of collaborators.

To analyze these measures, the correctness of the return to the original system state must be determined using architecture walkthroughs. Their purpose is to determine

• the resources that are being used by the active modules. For each such resource, the mechanism that informs the cancellation module of the use (or freeing) of this resource should be verified.

• whether the cancellation module actually frees the resources used by the active component

• whether the active module has a mechanism to return the system to a desired state and whether the cancellation module has the knowledge to implement this mechanism. The desired state can be either the state prior to initiation of the active module or a subsequent state when the user has indicated a desire to preserve intermediate results (such as a user-initiated "save" during an edit session).

• whether collaborating module are known to the cancellation component and whether they are, in fact, informed of the cancellation

• whether the collaborating module take the correct action when the active module are cancelled. This determination is potentially far reaching, and there must be a clear understanding of the desirable and achievable actions of the collaborating module before the correctness of those actions can be determined.

The performance target for the time to return to the original state should be less than or equal to the amount of time that has passed since the user took the action that was cancelled.⁶  The assignment of threads to processors will have an impact on this measure. Therefore, this needs to be considered in light of a performance model.  

The feedback to the user that the CANCEL operation is indeed being carried out and the results of the cancellation should be, at a minimum, meaningful and accurate. The aspect of meaningfulness is independent of architectural decisions, so it will not be discussed here. (See Usability Engineering by J. Nielsen [Nielsen 93, pp. 123-129] for a discussion of how to "speak the users' language.")

The accuracy of feedback about the degree to which the system has returned to the original state is critical in areas where inaccurate feedback could cause user error. However, it is not critical in areas where the user will not be able to influence anything. This measure should be analyzed using system-specific scenarios. For instance, a scenario for a document-processing system might be that a user mistakenly initiates a global replace on his boss's name, changing it from Mr. Champ to Mr. Chump, detects his error, and cancels the operation. If the system were to restore the body of the prose to Mr. Champ but not the headers or footers, the user could be severely embarrassed, or worse, if he were not informed of the incomplete cancellation and sent the file to a client. Another scenario might not be as severe or immediate, as follows. If the same cancellation failed to release some memory resources, the user could still work and save files, but such a leakage might eventually lead to a degradation of performance. These scenarios can become more complex with the existence of collaborating processes.

With regard to the accuracy of progress feedback in progress bars or dialog boxes, this information is often used as an estimate of the time until the cancellation will be completed, regardless of whether the information is presented as an actual time estimate (e.g., "40 seconds remaining") or as a percent-done indicator (where the user tends to expect a linear process). In either case, the system does not need to be more accurate at predicting the time to completion than people are at perceiving time duration. An exact quantitative specification cannot be pinpointed without knowledge of the specific task and user population. However, without context-dependent information, and erring on the side of over-predicting rather than under-predicting, we believe that most users would find time estimates within 20% of the actual elapsed time acceptable.⁷  If these time estimates are highly variable, consider using a different form of feedback rather than progress bars or percent-done indicators, which both imply certainty.⁸   

The feedback should also be appropriately noticeable, or salient, where appropriateness depends on the amount of delay time and often on the task that the user is doing. Saliency has possible implications for this architectural pattern, so we give examples of analyzing it in this section. Some dimensions that make feedback more salient are the choice between visual and auditory feedback, the size of visual feedback, the volume of auditory feedback, and the preemptive nature of the feedback. The extensive research about alarms in the human-performance literature is relevant to the design of this feedback [Boff 88, Section 11.401].

At a minimum, the type of feedback depends on the amount of time the CANCEL operation will take. According to Nielsen, a percent-done indicator is usually appropriate to indicate delays greater than 10 seconds, but a "busy" cursor (e.g., a watch or hourglass, which is common on personal computers [PCs]) is more appropriate for delays under 10 seconds because it does not present the users with more information than they can comprehend in the time it is displayed [Nielsen 93, pp. 136-137]. (That is, for delays of less than 10 seconds, the CANCEL operation may finish and remove a percent-done indicator from the display before users can understand what the indicator was indicating, making them wonder if they missed some important information.) These recommendations were for generic office-like systems doing operations other than cancellation. However, the CANCEL command has special properties that deserve consideration, and systems other than office-work graphical user interfaces (GUIs) may have special properties as well, which should be explored through scenarios. For instance, consider the following scenarios.

Salience Scenario 1: Long-Duration Cancellation of a Low-Priority Task

The user initiates an operation that will take a relatively long time to complete, say 30 minutes. Assume that about halfway through, the user realizes that he or she set a parameter incorrectly and cancels the operation. The feedback says that the cancellation is estimated to take about 20 minutes to restore the original state. The user has other work to do that is independent of the operation being cancelled, so he or she wants to work in a different application on the same computer. The following questions should be asked about the salience of the feedback:

• Does your architecture ensure that the progress feedback will be seen?

  The feedback must be displayed prominently and long enough for users to read and comprehend it so that they can decide whether to start working on something else. Typically, this means that a preemptive dialog box showing the estimated duration and floating above every other window appears immediately after the cancellation is issued.

• Does your architecture allow the feedback and the cancellation itself to be dismissed from the foreground so that the user can work on something else?

• How is the completion of the cancellation process signaled to the user?

  Since the scenario assumes that this is a low-priority task, the feedback does not need to be preemptive, but instead could appear in a toolbar (e.g., some mail programs wave a small flag on a mailbox when a new message comes in). If so, movement or flashing will attract the users' attention in peripheral vision [Boff 88, Section 11.401-11.421], and an auditory signal could also be used. These attention-getting options should be easy to change if users prefer not to be interrupted but rather want to look deliberately for the feedback when they are finished with the other task.

Salience Scenario 2: Safety-Critical Cancellation

The user initiates an operation and then cancels it. The safety of the system critically depends on the system being in a stable state; therefore the user should not be able to initiate any other operations until the cancellation has been completed, no matter how long it takes. The following questions should be asked about the salience of the feedback:

• Does your architecture ensure that the progress feedback will be seen?

  The feedback must be displayed prominently and long enough for users to read and comprehend it so that they know not to try to do anything else until the cancellation is complete. Typically, this means that a preemptive dialog box showing the estimated duration and floating above every other window appears immediately after the cancellation is issued.

• Does your architecture prohibit the user from doing anything else until the cancellation is complete?

  Unlike the previous scenario, this dialog box should not be dismissible, ensuring that the cancellation is complete before the user proceeds.

• How is the completion of the cancellation process signaled to the user?

  Since the scenario assumes that this is a high-priority task that preempts other computer use, the completion feedback should probably interrupt the user fairly emphatically. Since the user may not have been paying attention to the computer (because the computer couldn't be used until the cancellation was complete), consider using an auditory signal to alert the user. Certainly the preemptive dialog box should display the results of the cancellation and the assurance that other operations are now safe to initiate.

For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html)