Table 2 Model Checking on the User - Chocolate Machine Interaction Fig. 1. Event Generator Hierarchy Tree We can also use the hierarchy trees to guide a refinement based on this idea of specialisation. For example, we may start off by describing an abstract control, which the user interacts with to choose a value. This is described in the formal model of our early design as an Event Generator. At the next step, this could be refined to a Selection Control, then subsequently as a Value Selection Control, and finally be implemented as a Single Value Selection Control (e.g. a drop down menu or slider). In this way we already have a process for reducing abstraction by simply following the hierarchy trees. Fig. 2. Design UI, and Ulg One way in which we can test for maintenance of usability is by examining some of the conditions we can test for using PIMs, such as reachability and lack of deadlock. If we have a UI which produces a PIM with strong reachability (by which we mean any state can be reached from any other state) and no deadlock, then we expect that these properties will be preserved in the PIM of the new UI, or we say that usability has not been maintained. Fig. 4. PIMs for Ul, and Ulces Fig. 5. Composed Chart for Shape Application Returning to our earlier example of the simple shape application, we now show how we would model this along with related parts of the underlying system as a composed pchart. In Figure 2 we presented a UI design for a simple shape application, UIA. We now give the composed pchart for the PIM of this UI, along with the underlying system, in Figure 5. Returning again to our simple shape application and the possible UI designs for that system we will give an example of using trace refinement. In Figure 2 we gave two possible UI designs for the shape application, UIA and UIC1. In Figure 6 we give the charts for the PIMs of these designs. filtering or restriction taking place. So the respective interfaces for these two charts Fig. 1. Example of Alloy’s visualisation output firstly when the ATM is waiting for a bank card to be inserted and then second after a bank card has been inserted and the ATM is waiting for the PIN to be entered. We define the state beforehand (AwaitCard) and afterwards (AwaitPin). The entercard predicate is as follows: Figure 2. Light switch (i) physical device (ii) logical states Figure 3. (i) On/Off control with bounce back - is it on or off now? (ii) On/Off button with indicator light This mapping may be partial as not every transition will cause an event and the u ‘no event’ has been added to explicitly mark this. Also it is typically the case that only user-controlled transitions cause events (dom trigger C range action), because once you have pressed a switch you are committed. However, there are exceptions such as the ‘drop’ (release the button) when you drag and drop with a mouse. £ five vy Vest PAM eee ww Spe Vetoes VUilty VS Uy 14M VE Oe MY sl SESSA ete eee MLV teMei tw In fact to model this completely we would need to include degrees of pressure and the fact that there is no just one half pressed-down state, but a whole series requiring increasing pressure. This is not captured by a finite state diagram or description and would require a full status-event description as we are talking here about interstitial behaviour (the interaction between events) and _ status-sta mapping (more pressed = more down) [4]. This is also reminiscent of Buxton’s three- state model for pointing devices, where the degree of finger pressure is one of critical distinctions between abstract states [2]. LUS the some slight give is felt until the switch eventually yields and flips to the new state. Figure 6.1 shows this with transitory states for when the switch is up and just being pushed down. If you release before putting sufficient pressure on it snaps back to UP, but if the pressure is sufficient the switch yields and goes to the new state. Our next level of complexity includes tuning controls on car radios where th been in a state. Figure 7.1 shows a mi pulled in or out turned to the left o transition diagram of the device. This would probably be better described usin STNs one for in-out and one for left-right, but as they are coupled in a single c devices such as keyboards with auto-repeat or, r right. Figure 7.ii shows this physical ings happen depending on how long you have ni-disk controller. The knob at the end can be we are showing all the transitions to gi a simple thing as one knob! ve an idea of the total complexity of eve shall focus on the left-right twists and their time behaviour. To do this fi ‘out’ condition) ram for the logical e two. However, for this device we have had to augment the device state diag actions. states, but usability point abels to match th transitions with additional timed tran gure 8.1 shows just the left-right part of the diagram (actually in the for when it user’s acti user iS aware sometl of view these For example, a ve hing slight is controlling track selection and figure 8.ii shows the system, the selected track. Like figure 5 we use event sitions. Figure 8.i is thus not the raw device y different as it also includes implicit events. From a have a different status as the user is not performing clear ons. However we ry easy ‘undo’ is more critical than for more deliberate have still treated these timed events in the device as the that they are holding the device in tension - while the exact times when Figure 8. minidisk (i) time augmented device (ii) logical states events are triggered is not totally under the user’s control (unless they have a millisecond clock in their heads!), still the fact that it is being held is readily apparent. eee ane EEE EEE RAR ere Yat ee a I CERN E SNe Ne een ee eT ee “In fact both systems also exhibit ‘compliant interaction [9] where the system control of the physical device operates in a compatible way to the user control: with the kettle the user can turn the switch off or the system can. Of course there are usually limits to compliant interaction: the kettle does not turn itself on and the user turing the knob to the end of the wash cycle does not magically wash the clothes! th th from the water's BOILIN iggers the system action ‘system down’. Like user actions in the physical world this is protracted and lasts as long as the kettle is boiling, it is oment boiling is first sensed. This possibility of an auton ri S m th Figure 10 shows the state diagram for the kettle switch and also the state of the power and water. Strictly there are two sub-systems e POWER-ON state. T he arrows between the device at in the kettle the power ON/OFF) influencing the water temperature (continuous scale), but for simplicity we have shown the water state as simply boiling vs. not boiling and only as sub-states of nd logical state show that ere is an exposed state for the electrical power system. The little lightening arrow G state shows that simply bei ing in the state, by itself, not simply an event at the omous action is shown by the dashed transition on the state diagram for the physical switch. Figure 10. electric kettle (i) kettle switch (ii) power and water switch up (usually simply releasing a catch) so it is possible to boil the kettle when dry. Y ou could imagine a kettle design where the power was switch off by the system when the water was boiling irrespective of whether the user allows the switch to go down, in this case we would have similar device states, but a different logical state transitions and no exposed state mapping. Down). It is assumed that the hand-held device of the visitor could be used to adjust direction to the orientation of the visitor. This aspect of the design is not considered in more detail in these models. The implemented version of GAUDI differs from these models in that each sensor/display holds the whole route so that if the display is moved to a new location it picks up the new direction and adjusts itself accordingly. Maintaining multiple copies of arrays of directions is not an option using the sort of modelling technique described. Because the time to distribute all the messages for the space is insignificant, this can be seen as practically equivalent. Fig. 3. The combined sensor and display Fig. 6. The visitor who can elect to receive a direction Fig. 3. ‘Fire Engine Despatch’ interface of this research work is to make the GUI models used for model-based testing more abstract (when compared to, for example, [11]), and diminish the effort in their construction. We propose to achieve this by adopting task models as oracles. Once the oracle was ready, test cases were generated automatically and ex- ecuted over the GUI under test using the framework in [11]. For this particular sub-set of the task model Notepad was found to provide adequate support. This was to be expected both because Notepad is a stable commercial tool, and because we were only testing a small subset of its functionality. However, there is no reason to believe that errors already detected by larger models of the Notepad [12] would not be found by this approach when the functionality taken into account in the task model is extended. Fig. 1. (a) The basic AB effect for letter stimuli [23]. Here, the blink condition (un- filled squares) is shown as T2 accuracy conditional on T1 report, reflecting the effect on T2 report of successfully attending to T1. Baseline (filled diamonds) represents a person’s ability to report the presence of T2 when T1 was absent. (b) The atten- tional capture by meaning effect in humans [4] and model simulations [26], target report accuracy by lag of target relative to the position of the key-distractor. (c) Task schema for the key-distractor blink; adapted from [4]. (d) Top-level structure of the two subsystems model with implicational subsystem attended. since multiple events/stimuli can arrive simultaneously. Thus, we assume that SRRIs have a buffer? , which stores all events and presents them to the user serially. This assumption ensures stimuli appear in RSVP fashion, restricting our research to the area of temporal attention. The total number of items background and targets) to be presented is 2”, where n is a parameter in the b-model, called the aggregation level. Intuitively speaking, the aggregation evel determines the length of the traffic, i.e. aggregation level 2 generates 4 items; aggregation level 6 generates 64 items, which contains both targets and background items. An example of such stimuli is shown in Figure 2(a). Note, the interface outputs blanks when all items have been presented. Thie interface wae eamMNnncead with the 1eer model degerihed in the nrevwioniuie Fig. 3. (a,b) Performance (measured as probability of detecting the targets) of AB-unaware and AB-aware systems by varying the number of targets, the aggre- gation level, and the burstiness (i.e. the b value, with burstiness increasing as decreases). (c) Performance of SRRIs with different window sizes of the stimuli. AB-unaware system is a special case of AB-aware system with a window size of 0. Fig. 1. A simple device with four states and two buttons, A and B. Placing the buttons A and B sufficiently close ensures the fastest way in terms of time to get from state 1 to state i would be by pressing A 3 tines thus taking 3 state transitions. However, the fastest in terms of counting state transitions is to press A then press B, which requires only 2 transitions. The state machine in Figure 1 merely has the property that AB and AAA are alternative paths connecting state 1 to state 4. Clearly, AB is a better way to get rom 1 to 4, measured in terms of counting user actions. However, AAA may be aster in terms of time: the state machine says nothing about where A and B are nor how hard they are to do for the user. In particular, if A and B are typical buttons, then AAA is done by the user as “locate A, press, press, press,” but AB is done by “locate A, press, locate B, press.” The initial location of A by the user can be assumed to take the same time in both cases, as will the pressing of an already- ocated button, whether A or B. Thus if the time to press button A a second time is faster than the time to locate B after locating A, then AAA will be faster than AB — other things being equal. Fig. 2. The same device as shown in figure 1, but with an extra edge, labeled X, which ensures it is strongly connected. This device has the same “paradoxical” behaviour as the device of figure 1 regardless of the location of action X, in particular whether it is A or B. Fig. 3. Button layout of the PVR. aaa a ee ae Ve Se ee If arcs of the form (u,t) “> v occur in a shortest path, then assumptions have to be made about the user’s position prior to their action a in order to estimate the time to perform and complete action a; of course, if some of the timeouts are very fast, we may need to “expand” vertices (u,7,) to include their incident actions, just as G’ expands the vertices of G. In a device with many timeouts, and the possibility of consecutive timeouts, this procedure may need to be pushed back. We do not consider this possibility further here. The Mathematica defintion is a list of rules, here shown defining button names and locations, a FSM, and an initial state. The last line, for instance, is to be read as saying the device is initially in state 2. To implement the FSM as a working physical device, many further rules would be required; for the sake of brevity in this paper, we have not provided the state names, display content, indicator light status and other details that are of no further relevance. Fig. 4. The PVR FSM drawn as a directed graph (self-loops, vertex and edge names are omitted for clarity). The diagram merely visualises the level of complexity of the example and serves no other purpose for this paper! Fig. 5. A plot of the Fitts Law timings (vertically) against button press or action counts (horizontally) for all possible state changes on a PVR. The graph shows a best-fit line 0.21+0.16z (R? = 0.85). Points are drawn as crosses, but any points close enough to overlap when drawn are rotated 45°, 22.5°, 67.5°, 11.25°, 33.75° etc — so the more points near the same coordinates, the darker the blob is rendered. Fig. 1. Methodology. Fig. 2. Four transition systems. (c) is a synchronisation of (a) and (b), (d) is equal to (c) except that its states and transitions have been renamed. Fig. 3. Visualisations as transitions systems. to s with an internal event added to the process t. The synchronisation used is equality. Using this visualisation directly on the model in Fig. 2(a), we can obtain the two leftmost visualisations in Fig. 4, the leftmost MSC, (a), corresponds to the occurrence sequence s1 > s2 + s4 and the middle MSC, (b), corresponds to s1 “ 52 8 53. The MSCs are updated as the model is executed. The MSCs shown here are snapshots when no more transitions are enabled. To make the visualisation more useful, we parametrise it with a function mapping transitions to process names and event labels so we can rename events and show “similar” events on a single process. Say the TS in Fig. 2(a) models a runner on a track (like the system in Fig. 3). The runner starts at the beginning of the track and runs towards the end. Optionally, the runner refuses to run any further halfway through the track, but sits down and rests. If we map the transition a to the process “Runner” and the event label “run” and b to “Runner” and “rest”, we would obtain a visualisation as shown in Fig. 4(c) for the occurrence sequence s1 -* 52 , 53. This visualisation makes it easier to see what was intended by the model than Figs. 4(a) and (b). Synchronising visualisations with formal models using this technique is very useful and allows us to observe what happens in the model, but it does not allow Fig. 6. Visualisations used in an industrial project. to have a winning strategy, so we let the domain expert assume the role of the modelled system and let him try out ideas for winning strategies. At the same time we let a computer tool take charge of the uncontrollable actions according to the counter example that has been calculated. The user is urged to reach a winning state while the tool executes uncontrollable transitions to prevent that (by ensuring that the user is not allowed the ability to execute a transition leading to a good state). We can do this using the formal model, but often the formal methods expert does not have enough domain knowledge to have understand why the system should have winning strategy, so the domain expert, who has little knowledge of the modelling language, has to find out whether the error is in the model or in the specification. Instead we let the domain expert control the controllable transitions of the model using a visualisation (the computer tool is able to let the visualisation assume control of either the controllable or uncontrollable transitions, as described in Sect. 4.1). We let the user stimulate the model in any way seen fit (according to the supposed winning strategy), and eventually the model will perform an unforeseen move (error in the specification) or the model will perform a disallowed move (error in the model).
![£ five vy Vest PAM eee ww Spe Vetoes VUilty VS Uy 14M VE Oe MY sl SESSA ete eee MLV teMei tw In fact to model this completely we would need to include degrees of pressure and the fact that there is no just one half pressed-down state, but a whole series requiring increasing pressure. This is not captured by a finite state diagram or description and would require a full status-event description as we are talking here about interstitial behaviour (the interaction between events) and _ status-sta mapping (more pressed = more down) [4]. This is also reminiscent of Buxton’s three- state model for pointing devices, where the degree of finger pressure is one of critical distinctions between abstract states [2]. LUS the some slight give is felt until the switch eventually yields and flips to the new state. Figure 6.1 shows this with transitory states for when the switch is up and just being pushed down. If you release before putting sufficient pressure on it snaps back to UP, but if the pressure is sufficient the switch yields and goes to the new state.](https://figures.academia-assets.com/70281856/figure_018.jpg)
![eee ane EEE EEE RAR ere Yat ee a I CERN E SNe Ne een ee eT ee “In fact both systems also exhibit ‘compliant interaction [9] where the system control of the physical device operates in a compatible way to the user control: with the kettle the user can turn the switch off or the system can. Of course there are usually limits to compliant interaction: the kettle does not turn itself on and the user turing the knob to the end of the wash cycle does not magically wash the clothes! th th from the water's BOILIN iggers the system action ‘system down’. Like user actions in the physical world this is protracted and lasts as long as the kettle is boiling, it is oment boiling is first sensed. This possibility of an auton ri S m th Figure 10 shows the state diagram for the kettle switch and also the state of the power and water. Strictly there are two sub-systems e POWER-ON state. T he arrows between the device at in the kettle the power ON/OFF) influencing the water temperature (continuous scale), but for simplicity we have shown the water state as simply boiling vs. not boiling and only as sub-states of nd logical state show that ere is an exposed state for the electrical power system. The little lightening arrow G state shows that simply bei ing in the state, by itself, not simply an event at the omous action is shown by the dashed transition on the state diagram for the physical switch.](https://figures.academia-assets.com/70281856/figure_021.jpg)
![of this research work is to make the GUI models used for model-based testing more abstract (when compared to, for example, [11]), and diminish the effort in their construction. We propose to achieve this by adopting task models as oracles.](https://figures.academia-assets.com/70281856/figure_029.jpg)
![Once the oracle was ready, test cases were generated automatically and ex- ecuted over the GUI under test using the framework in [11]. For this particular sub-set of the task model Notepad was found to provide adequate support. This was to be expected both because Notepad is a stable commercial tool, and because we were only testing a small subset of its functionality. However, there is no reason to believe that errors already detected by larger models of the Notepad [12] would not be found by this approach when the functionality taken into account in the task model is extended.](https://figures.academia-assets.com/70281856/figure_031.jpg)
![Fig. 1. (a) The basic AB effect for letter stimuli [23]. Here, the blink condition (un- filled squares) is shown as T2 accuracy conditional on T1 report, reflecting the effect on T2 report of successfully attending to T1. Baseline (filled diamonds) represents a person’s ability to report the presence of T2 when T1 was absent. (b) The atten- tional capture by meaning effect in humans [4] and model simulations [26], target report accuracy by lag of target relative to the position of the key-distractor. (c) Task schema for the key-distractor blink; adapted from [4]. (d) Top-level structure of the two subsystems model with implicational subsystem attended.](https://figures.academia-assets.com/70281856/figure_032.jpg)
