STD extraction

A user interface is sometimes designed and specified as an STD, in which case there is no need for STD extraction. Otherwise, an STD can be usually extracted from the interface implementation with little difficulty. The STD we extracted for the Qtopia Calculator is shown in Fig. 2.

Figure 2: An STD for Calculator.

Most user interfaces are implemented using objects and event handlers associated with objects. At a given time, a subset of the objects is able to accept certain events. Since an event handler processes user inputs and generates new information for the user, it forces the user interface into a state, which can be the same as or different from the original one. Therefore, event handlers with the corresponding triggering user inputs and events correspond to the transition arcs of the STD. A user delay is incurred as soon as the event is generated. Therefore, the user interface knows when user delays occur. If we assume an event handler transitions the user interface into a unique state, an STD is naturally defined by the event handlers. Such an STD is actually the most detailed STD that can be extracted for the object/event handler based implementation. It provides the complete system-user interaction description. Note that an event handler in the implementation may correspond to more than one transition arc since the same event handler can be activated from different states. Therefore, all the arcs entering a state correspond to the same event handler.

If we only care about some specific user delays during system-user interaction or it is hard to infer the complete STD, we can identify event handlers which lead to important states only. Instead of a complete STD, we will then have a set of its snapshots. Since the user delay of a state is always associated with the corresponding event handler, such a set of snapshots is still useful for knowing when and how long these user delays will be. Moreover, the complete STD can be compacted by clustering similar states into a single state, based on content or profiling. For content-based clustering, let $\Psi(s)$ denote the set of objects for state $s$ which are able to accept events, and $\Omega(o,s)$ denote the set of events that object $o\in\Psi(s)$ is able to accept. We define the content set for state $s$ as

$$\Xi(s)=\{(o,\Omega(o,s))\vert o\in\Psi(s)\}\vspace* {-1mm}$$

Two states can be combined into one if their content sets are the same. For example, the two states in Fig. 2 can be clustered into a single state.