Contributing to Safety and Due Diligence in Safety-critical Interactive Systems Development by Generating and Analyzing Finite State Models

Transcription

1 Contributing to Safety an Due Diligence in Safety-critical Interactive Systems Development by Generating an Analyzing Finite State Moels Harol Thimbleby Future Interaction Technology Lab Swansea University Wales ABSTRACT Interaction programming briges the gap between interaction esign an programming, but it has not yet been relate irectly to mainstream user interface evelopment practice. This paper presents UI moel iscovery tools to enable existing systems an traitional evelopment processes to benefit from interaction programming tools an methos; in particular, to enable checking of safety-critical interaction properties, an to contribute to ue iligence practices in safety-critical interactive systems esign. To kill an error is as goo a service as, an sometimes even better than, the establishing of a new fact. Charles Darwin, Categories an Subject Descriptors H.5.2 [User interfaces (D.2.2, H..2, I.3.6)]: Theory an methos. General Terms Design, Human Factors, Verification. Keywors Discovery tools; interaction programming; moel checking.. INTRODUCTION Interactive systems often have esign efects that cause users problems. It is very ifficult to eliminate such efects because they are impractical to fin using conventional usability evaluation methos. For example, etecting a bug in parsing numeric input requires a potentially vast amount of user testing to ientify the efect, as well as maintaine attention to notice a efect amongst many boring non-efect cases. Defects remain in interactive systems because the costs of fining an fixing efects are too high compare to the benefits, an because politically many esign efects can be re-presente as user problems: users shoul have Permission to make igital or har copies of all or part of this work for personal or classroom use is grante without fee provie that copies are not mae or istribute for profit or commercial avantage an that copies bear this notice an the full citation on the first page. To copy otherwise, to republish, to post on servers or to reistribute to lists, requires prior specific permission an/or a fee. EICS 9, July 5 27, 29, Pittsburgh, Pennsylvania, USA. Copyright 29 ACM /9/7...$5.. known or been traine how to use the evice, rather than the evice shoul have been esigne so that it was easy to use. This paper presents a simple but effective technique to help improve the esign of interactive systems, specifically the programming of interactive systems. The approach coul form part of the ue iligence proceures of safety-critical evice manufacturers or of procurement. The approach is a light-weight formal metho it is trivial (it is inspire by ecae-ol formal methos [4]) but it is intene to be effective, to help etect an manage usability efects in practical environments. We provie some evience in this paper that even this light-weight approach coul be very beneficial, not least because of its accessibility to system programmers. Thimbleby [6] shows that even simple interactive systems are too complex for user evaluation to be able to evaluate an check reliably. A typical interactive evice will have thousans or more states, an there is simply not enough time for a human to check every state, an that every transition in every state behaves as intene; moreover, even if there was time, fatigue an lack of concentration woul ensure that overlooking efects was likely. Thus other methos, not relying on human participants, also have to be use to ensure quality interactive systems. Either there must be processes that generate epenable systems, or there must be processes that reliably analyze systems to ientify efects an rive improvements. It is only necessary to be more reliable or to ientify ifferent types of efects than user or expert evaluation to contribute to improving esigns. Most processes aequate to help esign epenable safetycritical interactive systems have many isavantages: they are embee in platform-specific, often proprietary, tools; they require programmers to learn new languages; they are not compatible with legacy systems... an so on. Worse, rigorous evelopment processes almost all require some mathematical maturity in evelopers, an this in itself limits their use. There are some promising research projects in this area (e.g., [3]), but there are no off-the-shelf solutions for orinary evelopers. For the foreseeable future, evelopers are going to continue builing interactive systems using familiar tools, imprecise programming languages, complex interaction libraries, an uner time pressures an harware an other constraints that limit their choices an the opportunities to invest in improve processes. For the time being, then, fining an fixing user interface efects has to be one by working with conventional inter-

2 active programs that were evelope using conventional evelopment processes. User interface coe is typically messy, involving complex an generally ill-efine APIs. One approach woul be to mine from the existing program (or program uner evelopment) a specification that coul have been use if the program ha been evelope rigorously. We call such an approach a user interface moel iscovery metho, for it iscovers the user interface moel from a working system. One then performs conventional moel checking on the iscovere moel, to test safety an other esign requirements. Since a tool is use to automatically fin the user interface moel, it is straightforwar to repeately re-iscover the user interface moel an repeately check it satisfies requirements as the program esign is iterate or otherwise rifts. In contrast, conventional formal methos invest a lot prior to implementation an thus significantly increase the cost of iterative esign: it is tempting either not to iterate (perhaps not even to evaluate the user interface empirically), or to iterate but ignore the obligation to repeat the formal methos. Often evaluation leas to unertaking important moifications but which are not followe up formally, an soon the system contains unknown efects. Press On: Principles of Interaction programming [5] is a recent book that summarizes problems with user interface esign, provies a programming framework for analyzing interactive systems an avoiing interaction problems, an finally summarizes wier issues: going from programming to facing the real complexities of user requirements in the real worl. In safety-critical user interfaces, such as interactive meical evices, there is a great nee for better interaction programming, as user problems with evices has been wiely implicate in averse clinical outcomes. Although it provies a UI framework, Press On oes not overcome the problems liste above, the iscovery metho introuce in this paper links conventional evelopment techniques with the avantages of interaction programming, as elaborate in Press On. Since the manufacturer must anyway prouce a working program, existing esign processes an methos may be retaine. One gains the avantages an insights of the Press On framework without any rawbacks. Inee, the framework itself coul be hien from evelopers. We have built some user interface moel iscovery tools that automatically construct rigorous moels automatically; they achieve this by effectively simulating a user in software, followe by a stochastic confirmation that the moel is accurate enough. We check the moels using a flexible, lightweight form of moel checking. The metho is well-within the reach of typical evice programmers. The propose metho must be seen in the context of Reason s swiss cheese moel [4]: user interface moel iscovery tools are a new slice of cheese, one more amongst many; they are a efense against errors, but they are not the only efense that shoul form part of the evelopment process. In the future one imagines a iscovery tool presenting a eveloper with a menu to select relevant properties to check, analyze, or auit, or to confirm that properties lie within a specific range of values. Regulatory agencies may then use iscovery to test conformance to appropriate stanars; manufacturers may use it in ue iligence. Jackson [9] introuces the small moel hypothesis, which is clearly relevant in the present context: like him, we believe that small moels quickly ientify important esign faults; inee in user interfaces if a very large moel is require, then a user evaluation metho is very unlikely to encounter efects either. The iscovery approach works with existing interactive programs, an is of particular importance for safety-critical interfaces; it is however not well-suite to continuous interaction (such as gestures or speech), although it can hanle the iscrete UI features (such as menu choices) managing continuous interaction. A conventional way to buil quality software is to specify systems formally, prove specifications satisfy requirements, then rigorously erive working implementations. However, as a working system influences user behavior, requirements cannot be known until users have experience with one. Iterative esign is the preferre way to buil interactive systems, but changing a specification an re-eriving a program are too teious an error-prone to o repeately, so systems rift from their specifications. Soon, many etails of user interfaces become unknown, an systems elivere to users likely have latent efects that lie unetecte inefinitely. Drift can be aresse through source coe analysis [5], where an abstract moel is erive from the program. This gives many of the avantages of conventional formal software evelopment, with the benefit of etermining properties of the actual program being use. However, moern user interfaces are programme in complex ways (e.g., using events, listeners, elegates, moes, etc) an source coe analysis is impractical, abstracts user interaction, or relies on assumptions (e.g., that Java Swing is use). Typically much of the UI etail is implemente in libraries for which source coe may not be available anyway. Another approach is to program in a more formal way: for example, to use a finite state virtual machine as a Java Swing API []. Cognitive methos [], while aressing important complementary esign criteria, have analogous problems to formal software engineering methos. UI moel iscovery tools are relate to previous work, particularly so-calle UI ripping, which has been use for office applications [] an Ajax web sites [2]; Vaquita [2] uses similar techniques to reverse engineer a web site with a view to porting it to another platform. There is a goo review in [3] (which introuces IVY, a source coe analysis approach), an on the Vaquita web site [9]. Ripping can quickly locate major efects (e.g., if the ripping fails) but the iea in the present paper is to iscover moels to analyze etaile UI structures from the actual programs that are being eploye. We o not have space to iscuss the backgroun to the area further, but see QuickCheck [3] for a relate system an review. 2. THE PRESS ON FRAMEWORK No prouction interactive systems have been esigne using the Press On framework: the framework is too recent, an systems continue being implemente with existing tools. There is no easy transition from current methos to better methos, because of the amount of legacy an investment in existing coe. It is usually going to be easier to make incremental changes to a system than to aopt a new approach, a potentially costly ecision that involves refactoring, unless it is an approach that has large benefits an low aoption cost such as moel iscovery tools. Press On represents UIs as finite state machines, an uses the JavaScript Object Notation (JSON) to serialise them.

3 JSON is esigne to represent objects in a well-efine, reaable an portable way. In Press On, JSON represents state machine transition matrices explicitly, an though this has the avantage of making analysis straightforwar, it makes complex interactive systems too large to manage by han. Apart from explaining the techniques in the book, the real point of the framework is to analyze the moels, so their actual size is largely immaterial. The approach use in this paper is compatible with the Press On framework, but it oes not rely on it; alternatives notations inclue SCXML an usixml. Inee there is no requirement for user interface moels ever to be represente explicitly, however if one is then it can be analyze more easily but if it is represente in the Press On JSON framework, then all of the UI analysis tools from Press On become immeiately applicable. The convenient availability of this analysis is one of the avantages of the approach. 3. DISCOVERING AND CHECKING A UI SPECIFICATION What we wish to o inclues: Generate moels automatically, so that they can be easily re-generate when the evice program is moifie, for instance through iterative esign. Formalize the properties we wish to check, so that properties such as inconsistent button use can be etecte. Check moels automatically against pre-programme rules, so that properties can be easily re-checke when programs are iterate. Valiate the moel against the evice up to some criteria (because, as we shall see, obtaining a soun moel is an uncertain process). To be light-weight formal methos to package the approach in a technology familiar to typical programmers. We have evelope an API where the programmer eclares the user operations (such as button press events) an invokes a iscovery process by calling a function. The iscovery process is ynamic: it effectively runs the evice to explore it. (A eveloper may choose to switch off real-worl sie-effects uring the iscovery process.) Currently the process creates an explicit-state evice specification. Obtaining a UI moel from a program is theoretically har, sometimes intractable, particularly if we o not require evelopers to make concessions in the way the program is written. However, if a iscovery tool cannot reliably etermine a UI moel, then the system being evelope must be very har for a user to unerstan. Since the point is to make better UIs, using iscovery tools can only help improve esign! The iscovery process uses a collection of callback functions an options to make the approach efficient an robust. A user, or an expert evaluating a user interface, can only press buttons on a evice an see what happens. A UI iscovery process works essentially the same way, but systematically explores the evice. The iscovery process only requires a software interface to press buttons an to track the PRIME NO YES ENTER Figure : Illustration of the bottom two rows of the keypa on the Abbott ai mplus. Note the combine ecimal point/up arrow button, an the close proximity of the ecimal point an zero. state of the evice. In simple cases it is possible to iscover the UI moel simply by using a stanar state space search algorithm, such as breath-first search. Problems may arise if the evice cannot unertake arbitrary state transitions, an then the state space search has to use uno an other stanar features to explore the state space exactly as a user woul have to. Note that one is typically intereste in a submoel, so the entire evice nee not be explore; for example, the number entry moels shown later in this paper are only concerne with number entry, an other features have been abstracte away. In other wors, in iscovering these moels, the iscovery process ignores user actions that take the search away from the efine subset of states. Having iscovere a UI moel, it is important to check that it is vali (the evice might have hien moes or timeouts). In principle a evice coul have any number of moes an might be eceptive. It is therefore generally only possible to check a moel is vali in a probabilistic sense. In our work to ate, we have constructe moels that are explicit state transition graphs, sets of eges uv a, that a evice transitions from state u to v when action a occurs in state u. To check these, we ranomly shuffle the eges, pick an ege uv a, transition the evice to state u, perform action a, an check the evice terminates in state v. This process is repeate until at least every ege has been checke. (Alternatively if it is not possible to transition to an arbitrary state u, in the current state c, we pick a ranom ege cv a.) Since eges are chosen in a ranom orer, an unlikely in the same orer as the moel was iscovere, this checking is likely to reveal hien moes if any that the iscovery process ignore. Discovering a UI moel requires some sort of software access to the evice being analyze. Interestingly any webstanar conformant program written with DHTML an Javascript can be run in frames an the ocument object moel of the evice is then open to inspection. Using this technique we have iscovere an analyze moels from the calculator introuce in [7]. We iscuss this approach in more etail below, after some introuctory examples. 4. MOTIVATING EXAMPLES Interactive rug elivery systems have user interface efects (which clearly were not etecte by manufacturers) that cause hazars. Ientifying an fixing such efects will lea to saving lives. The US Institute of Meicine of the National Acaemies (IOM) reports more than 7, eaths a year ue to meication errors The US FDA (Foo an Drug Aministration) recommens the Canaian Institute of Safe

4 SELECT mg/ml 2 SELECT µg/ml 3 SELECT ml (a) Menu with three options for continuous infusion. User shoul key, 2, or 3 to select an option. Screen (b) shows help menu isplaye if HELP is presse; screen (c) shows the ose entry screen if 3 is presse. SELECT UNITS OR CONCENTRATIONS.-. mg/ml - µg/ml (b) Help menu invoke from screen (a) oes not show etails of thir (ml) option. SET RATE. ml/hr ENTER WHEN DONE (c) Option 3 (ml) selecte from screen (a) actually asks for ml/hr. (Options an 2 ask for mg/ml an µg/ml respectively.) RATE 5.mL/hr CONTAINER SIZE.5 ml USE FOR MORE () Review screen. The confirmation simply confirms the same numbers as entere..ml INFUSED RATE.mL/hr PRESS START TO INFUSE (e) Screen shown at start of an infusion. Pump oes not ask about priming. ERROR DETECTED 9-NOT PUMPING PRESS START TO RE-TRY (f) Error message. HELP oes not work in this screen; a user must refer to the operator s manual for etails of the error. Figure 2: Screen esigns from the Abbott ai mplus pump. The screens (a) (f) are in orer of a possible sequence of user actions, but not all steps are shown: for example, from screen (c) the user will enter a ose (5 ml in this example) an other ata, then the review screen () is shown, but the user has to review all ata before the pump procees to screen (e). Screen (f) will only appear if there is a problem etecte after an infusion starts though note that it oes not efine what error 9 means. Meication Practices (ISMP) guielines [8], which say The abbreviations, symbols, an ose esignations foun in this table have been reporte to ISMP through the USP-ISMP Meication Error Reporting Program as being frequently misinterprete an involve in harmful meication errors. They shoul NEVER be use when communicating meical information. The guielines state, for example, that it is ba practice to enter rug oses in the form.5 gm or 5. gm, because the ecimal point may be misrea (the patient then gets oses of 5 or 5, in error by a factor of ten). Despite the multinational prominence of such rules, few if any interactive evices enforce them [7]. Avoiing ecimal point problems is a clear an simple application of UI moel iscovery, as we shall see below. The example also contrasts the contribution of UI moel iscovery to conventional user evaluation methos, where it is not feasible to ensure correct ecimal point hanling because there are far too many cases to consier. Every number an every possible error nees checking, an this check is ieal for automation. The Abbott aimplus is a typical portable infusion pump, a rug elivery evice esigne for use by nurses an patients to eliver rugs at controlle rates over a perio of time. Its user interface consists of a numeric keypa, various buttons such as HELP, an a multiline LCD panel (see figure for an illustration of part of the keypa, an figure 2 for example screen shots). The ISMP has publishe a substantial root cause analysis of a fatality involving this pump [7], which inclues human factors stuies of the evice, confirming the evice has efects as escribe in this paper. The evice is in wiesprea use, an will have passe appropriate regulatory approvals such as from the US FDA. Any efects in its esign may therefore be consiere representative of this type of evice. Figure is an example of an ergonomic efect in its esign: it breaks the ISMP rule, Several tenfol osing errors cause by close proximity of the zero an ecimal point keys have been reporte. In each case the nurse inavertently presse the zero instea of the ecimal point key when programming the ose. [6]. This sort of efect can obviously be foun by straight forwar inspection in this case, just by looking at the keypa an an expert evaluation woul be an ieal process to fin it. In contrast, programming efects are much harer to fin an require systematic searching. For example, figure 3 was evise by han by exploring a small part of the aimplus s user interface. Four states ha to be tracke by making notes, an repeately re-visite to work out what each button i in each state. Builing the moel was teious an inee an error-prone exercise. The moel is very small (compare to typical interactive system specifications an compare to the moels we will exhibit later in this paper). However, the finite state machine is informative. As can be seen, the aimplus interpretation of the backup button is inconsistent. Such properties, an many more, are covere in [5], but we nee a better way of obtaining the moel than by oing it manually. Figure 2 shows a sequence of aimplus screens uring a typical user interaction. User interface efects inclue in figure 2b the help isplaye oes not cover all options, an in 2f help covers nothing. In figures 2ab the Greek letter µ is use, contrary to the ISMP guielines [8] (µg may be mistaken for mg). In figures 2abce the / is use instea of the correct per. Figure 2e is isplaye (i.e., showing the pump is reay to start an infusion) without the evice proviing a prior opportunity for the user to prime the line. In figure

5 Backup Infusing Backup Enter Options Options Backup Digit 8 Ajustment Backup Enter Soun level Figure 3: Example of inconsistent transitions for the Backup button from the Abbott ai mplus pump. Sometimes Backup backs up the previous action, sometimes it oesn t. The transitions represente in this iagram were erive manually, an the iagram is at the limits of reliable human generation for example, although Digit 8 oes select an option (the transition shown is correct), I i not check what Digit 8 oes in other states. Note that the iagram is clearly incomplete, as it has no exit. 2 the evice is showing a trailing zero ( 5. ), which guielines forbi as it can be misrea (here, with 5 ) easily. An so on. Presumably the manufacturer has inaequate ue iligence processes in place to check conformance with the recommenations, or perhaps program rift uring iterative esign (or the prouction of new moels) meant that the elivere prouct rather than some prototype that may have been checke accientally broke the rules. It is certainly impractical to check conformance to such rules without tool support. 4. User interfaces with timing issues A very ifferent esign efect is illustrate by the Apple Mac system installation. The user inserts CDs to install the system, an part way through a very lengthy process the system says click continue, but gives no other choices; see figure 4 for a screen shot taken at this moment. Here we have a single state with a single exit, which is pointless, as the only choice the user has is to say when to continue [5]. In this case, the answer is always going to be now rather than waiting! (In contrast, for a fire extinguisher the user chooses to perform the only action when there is a fire.) This problem can be ientifie automatically from a moel, an thus coul be rawn to the attention of esigners. Possibly the pointless state is in the UI because, historically, several floppies were require for installation, an the original UI woul have aske the user to be reay with isc 5, say. What is left now is legacy coe that asks the user if they are reay when there is now nothing to o! User testing is largely impractical to fin this problem: it takes hours to etect an might be misse as the Go back option superficially appears to be available, so the efect may not be notice. Inee, professional evelopment i miss this problem. A iscovery tool coul search the entire UI state Figure 4: At this late point in installing OSX, Continue is the only option the user can choose. The Go back button, although visible, is isable. space, an all such latent problems coul be aresse: although it woul take time, it woul not require any human participant time. Note that as there are negligible costs, multiple analyses can be run concurrently an thus cover the state space faster. 5. WORKED EXAMPLES The previous examples illustrate commercial systems exhibiting esign efects that we argue are eminently amenable to UI iscovery methos. We now provie two fully-worke examples of similar complexity, thus strengthening our case. 5. A hanhel calculator To make this paper more accessible to reaers, rather than use rug elivery interfaces, we first apply UI iscovery to a full emulation of a wiely-available calculator, the Casio HS-8V (see figure 5). Calculators are comparable in UI complexity to typical rug elivery systems, an as calculators are well known the reaer can confirm our results here without unerstaning any etails of rug elivery. Inee, from a computational perspective, calculators are more complex: they hanle a wie range of numeric input to a higher precision than necessary for rug osage (the HS-8V covers 7 to 9 to 8 figures). The coe for the calculator simulation, as well as more analyses than the present paper escribes, are available from the author. The emulation is accurate; its only known problems are in numerical rouning (the simulation performs calculations to arbitrary precision, an rouns them for isplay, whereas the HS-8V certainly uses a ifferent algorithm) an in the implementation of the MU button, which is not efine well enough by Casio s instructions for us to unerstan it. It is also possible that some functions have elaye or moe effects that we have not fully unerstoo; for example on some calculators (but apparently not on the HS-8V), pressing + repeately efines a constant. Although for this paper this first example relies on a reverse engineering of the HS-8V, this is not a limitation of For example, pressing efines 4 as a constant, so a later 5 + = behaves as if 5+4=.

6 the approach. We can imagine that Casio ha a specification of the HS-8V (or one of its precursors) an then implemente it; instea, we ha an actual HS-8V an that serve as our specification. The HS-8V simulation was written in Mathematica in a functional style (i.e., each button is a state state function) an the iscovery tool written in the same program, with irect access to the state an to the button maps. Searching the state space was one using a breath-first algorithm. Implementing the iscovery tool was trivial an involve no moifications to the calculator simulator; however, running the iscovery process ientifie some bugs in the simulator (which were then fixe). Example bugs foun an fixe were that: Although pressing + 3 correctly gave 4, entering, for example,.+3 woul give the result because the 8-igit isplay was fille with the s, an pressing 3 was blocke from upating the isplay, so the + ae the unchange isplay to itself. We ha initially misunerstoo the HS-8V implementation of ecimal points. Initially, pressing ecimal point move the ecimal to the far right of the isplay, so entering 2 3 woul isplay 2.3 but, in fact, it isplays.23 on the HS-8V, as secon an subsequent ecimal points are ignore. Although we etecte bugs relative to the HS-8V itself, one might expect iscovery more generally to help etect efects with respect to conventional specifications. In their initial state, many numeric entry systems isplay. leaving it unclear whether the user has or has not alreay presse a ecimal point. This creates an ambiguity. For example, if the user presses 5 when the isplay shows., the number entere may be either 5. or.5 an the user cannot reliably anticipate which. For rug ose entry a factor of ten uncertainty, as here, in the number entere for the same user action creates an unacceptable risk. Note that the numbers. an 5. have syntax errors, an the evice shoul hanle them istinctively. In any case, the forms. an 5. are forbien by national regulations for rug ose entry. Ieally, then, a numeric isplay woul initially show ; pressing 5 woul always change it to 5 (unsurprisingly), an pressing woul change it to.x (perhaps flashing) as at this point the number entere (. ) is in error until another igit is presse. In other wors, the ambiguity with isplaying. can be avoie. Figure 6 shows the HS-8V s internal evice moel for hanling numeric input; the internal moel istinguishes two separate states for the same isplay of. The specification for the graph was obtaine automatically as escribe above. In practice, visualization tools will be use to allow interactive zoom an scroll, an woul allow easy inspection of the entire moels. With complex interactive systems an the examples illustrate in this paper are on the verge of being too complex to unerstan from visualizations alone the properties of the moels will be checke an explore using tools. In particular, once a esigner or eveloper has establishe a property of concern, it can be checke everywhere with no further work or even any further visualization. In the two states, shown in top an top left of figure 6, the calculator shows. on its isplay. In the top state the Figure 5: Accurate HS-8V simulation written in Mathematica, an use for the generation of moels. The screen shows 2., with a ecimal point even though the user has not presse a ecimal point; the screen will not change if the next key press is ecimal point, though obviously the evice tracks whether the ecimal point has been presse since it influences the interpretation of the next key press. user has not presse the ecimal point, an there are two transitions from this state: if the user presses the ecimal point (moving own an to the left), an if the user presses a igit (moving own an to the right). Note that this is an abstract moel: e.g., represents any igit, 9. To our knowlege, no UI moels of this complexity have been extracte from fully-working programs before, an certainly not from programs where no concessions have been mae to the moel iscovery process. Figure 7 shows the HS-8V s user moel for numeric input: evice states are treate as equivalent if the user cannot istinguish them. Although we know the calculator has istinct internal states isplaying. the user moel treats these as the same, for the user cannot tell them apart. Initially, the calculator isplays., the state shown at the top of the iagram. Pressing the ecimal point oes not change the state so far as the user can tell, however, but pressing a igit key oes change the state in one of two possible ways. The user moel is therefore non-eterministic: if a user presses a igit in the top state, the calculator may go left or right, an the user will not know which. The two moels iffer in many other etails. Eviently the user s moel is ifferent from the evice moel, with the potential problem that users will misunerstan the treatment of numeric input. Probably no esigner notice this problem. Moreover, the efect that causes the non-eterminism can be correcte now the problem is ientifie, then UI moel iscovery can easily check the efect is inee correcte in every moe. Exactly the same esign efect occurs on many rug elivery systems, where we also know that ecimal point errors cause averse events. Infusion pumps, for example, have many moes where numbers can be entere, an moel iscovery can test that

7 Figure 6: Part of the HS-8V numeric input evice moel, rawn as a transition iagram. The complete moel for numeric input to allow numbers of upto 8 igits. Note that the moel was obtaine automatically irectly from the interactive program. Thimbleby [7] introuces a rug ose calculator, making the explicit claim that it is better than alternative methos such a using general purpose calculators. General purpose calculators (like the HS-8V mentione above) allow the user to o any calculation, so they are unable to etect an manage errors where a calculation is wrong. For example, a nurse attempting to calculate a rug ose might fumble an enter + instea of but the calculator, being general purpose has no way of etecting such a wrong formula error. The calculator introuce in [7] is a fixe-purpose calculator an therefore avois this problem as it can only o calculations using the correct formula; it also etects numerous other user errors, such as entering ill-forme numbers, as iscusse above. By way of comparison, IV Rate Calc, MeCalc an Drug Infusion are commercially available iphone ose calculators that all have number entry bugs; Drug Infusion (v.) for example treats.5.9 as.5 without reporting any error. We now show UI moel iscovery significantly increases our confience in such a calculator. The calculator was written as a web application, that is using CSS, DHTML an JavaScript, to run on an Apple iphone. It is therefore easy to run the calculator in one frame on a web browser with a UI iscovery tool running in another frame. The iscovery tool then has access to the ocument object moel of the calculator, an can walk it to extract all possible user actions, moes an so forth. Figure 8 shows a screen shot of the calculator an the iscovery tool running together: both are running in a stanar web browser. The calculator works exactly as it oes on the iphone, an the Figure 7: HS-8V numeric input user moel: here, evice states are treate as equivalent if the user cannot istinguish them from the evice isplays. although not very clear as reprouce in this paper, can be reliably ientifie by using tools. in every moe they behave as intene. Achieving this certainty with conventional usability methos is impractical: the two moels here represent about 9 states (the event iscovery tool monitors it an is able to sen it user events, represents any often igits), which woul take about as if it was a user operating the calculator. button presses to explore systematically far beyon the When the user presses the iscovery tool button Scan time an resources available for conventional usability evaluation! DOM the tool explores the ocument object moel an creates the tables shown in figure 8 (an other items we o not have space to show). If a user operates the calculator, 5.2 A rug ose calculator its state will change; the tool has a button Synchronize to instruct it to extract the current state of the calculator. Note the non-eterminism of the transitions from the top state. The crucial ifferences with figure 6, The table on the left shows user actions, an they are colore re or green epening on whether they are enable in the current state. The table on the right shows state variables foun by the tool from the DOM; these are numeric variables, menu settings, selecte fiels, an moes. In fact, the calculator has four major moes, epening on which tab the user has presse: viz show the calculate rug rate in ml per hour, enter the ose, enter the concentration, an enter the patient weight. It is important to note that the UI iscovery tool was written knowing the structure of the application, an therefore iscovering properties such as moes was not a computationally har task. On the other han the iphone application ha not been written with iscovery in min; it is just a conventional application an was not written in any particular style to make formal methos use easier. The ocument object moel is a very coarse tool for the purposes of moel iscovery, an the knowlege neee about the structure of the iphone application compensates for its flexibility; ha a programming language such as Java been use, a iscovery tool coul have been esigne to work with an application using a specifie API, such as Swing, with virtually no reliance on application-specific knowlege, as we neee here. The table of user actions shows each action together with a checkbox. An analyst can tick selecte actions an state variables, an then click Discover moel. The tool then creates a UI moel starting from the current state by only generating ticke events, an it only tracks the selecte state variables for testing for state equivalence. Figure 9 shows

8 Figure 8: Screen shot of the iphone calculator (left frame) running concurrently with a UI iscovery tool (right frame). a moel generate for number entry; it may be compare to the moels shown in figures 6 an 7, which are simpler primarily because the HS-8V oes no syntax checking. 6. MODEL CHECKING On close inspection, the HS-8V moels shown in figures 6 an 7 look ifferent, so they must have ifferent properties. But it is not goo enough to rely on visual appearance to valiate properties; if a user interface is part of a safetycritical system, looks are not going to be reliable enough! The person looking at the visualizations may miss something important. Certainly if a esign is iterate, it might be necessary to look at many visualizations, which coul be too teious an a recipe for unreliable esign, precisely what we are trying to avoi. Instea, then, the analysis must be one automatically an must not rely on visualization an eyeballing pictures. We now consier the iphone calculator in more etail. There are two sorts of potential esign error that must be etecte. A rug ose is invali if it is not well-forme by ISMP an other regulations. Thus. fails because it ens in a (it may be misrea as ). A rug ose is blocke if it cannot become well-forme except by clearing it (pressing the C key). Thus.. is blocke; whatever the user oes apart from clearing cannot correct the error of having two ecimal points. All blocke numbers must be invali, but some invali numbers are not blocke. Thus. is invali but it is not blocke, as the user entering 5 at this point shoul change it to the vali ose.5 Moel checking the calculator establishe: All invali numbers are etecte as invali. All blocke numbers are etecte as blocke. All blocke numbers are etecte as invali. No vali numbers are blocke. No numbers that are not blocke are blocke. No vali numbers are etecte as invali. Figure 9: Visualization of graph representing number entry for the iphone calculator. The initial state is in the center, an transitions shown are for ecimal point, zero, an any non-zero igit: i.e., covering all syntactic issues. (The iagram is circular because the calculator limits the number of significant igits.) States representing invali oses are rawn as colore hexagons, to be easier to see. Necessarily, this visualization is reprouce in this paper at too small a scale an with no interactive zooming, so it oes little but give an impression of the structure, scale an complexity of the graph. Because of the way the moel is create, we know that it is connecte. (Note for example that figure 3 shows a manually-generate network which accientally fails to be strongly connecte.) Given a moel we can also check an establish generic properties, such as path costs an so on, as iscusse in [5]. Insie the calculator itself, valiity is efine by obscure imperative program coe. As is usual for intricate coe (e.g., many neste if-then-elses), it is both har to ebug an moify correctly. The moel checker instea uses regular expressions to efine vali numbers, an the coe to o so is clear an easily moifie if necessary. The regular conitions use for checking vali oses are shown in figure. Since the regular expressions are JavaScript, they can be combine with arbitrary coe if esire an they thus make a powerful moel checking language. The point is that the person oing the moel checking can choose a notation or form of expression that they feel is clear an precise in the language they alreay know. A programming language like JavaScript provies consierable freeom to o this, unlike most specification languages. When the user taps a igit or ecimal point, the number isplaye shoul be extene by that symbol. For example, if the current number is.2 an the user taps 3, the number shoul change to.23 Moel checking the calculator further establishe: In the initial state, there is no number. In every state, if the user taps a ecimal point or any igit, the number is extene correctly.

9 Regular expression Interpretation /\..*\./ must not have more than one ecimal point /\..*$/ if it has a ecimal point, it can t have a trailing zero /^$ ^[^\.]/ if it has a leaing zero, it must be. something /^\./ can t start with a ecimal /\.$/ can t en with a ecimal /[^-9\.]/ only igits an. allowe Figure : Any matching regular expression implies an invali number. Different rules are require for blocke numbers, for example, a number ening in a ecimal point is invali but is not blocke. These rules prohibit a ose of zero however it is represente: starts with but has no ecimal point, an. has a ecimal point buts ens in. What correctly means here is interesting. The calculator limits numbers to 5 symbols, so a number alreay of 5 symbols cannot be extene, so any 6-igit number must be blocke. The moel checking establishe that any ecimal or igit extens a 5 symbol number to a blocke state. Moel checking initially foun that some 4-symbol numbers were blocke: we then iscovere a property of the calculator we ha not expecte, namely that a 4-symbol number ening in a ecimal point cannot anyway be extene to a vali number, so the calculator blocks these numbers as no igit can be appene after the ecimal point. The moel checker was refine to allow this rule, however we note that in all other cases a blocke number is etecte after the user has entere it, whereas blocking a number because it is 5 symbols long an ens with a ecimal point is etecte by the calculator before the ecimal point has been appene, an the ecimal point is in fact not appene. There are eviently states that break the useful rule If a number is blocke, it may be reviewe an then C must be presse. Thus moel checking has foun a (minor) esign efect, an inconsistency in error hanling: users can make errors an are not require to review or correct them because they are correcte automatically. We o not know a priori that the moel is complete an eterministic. Moel checking the calculator was therefore also use to establish: In all states where a numeric (igit or ecimal) can be tappe, all of them can be tappe. Note that in some blocke states, the only allowe user action is to tap OK, an no numeric can be use. In all states there is exactly one state transition for each possible action, an each action has a transition. The moel checker is esigne to start in efine states (it can save an restore snapshots to repeat moel checking experiments). The moel checker has been run separately to check all of the number entry fiels of the calculator. All of them pass the moel checking. Failure of any property above woul be reporte to the user of the moel checker. If there are no failures, the moel passes; if there are any etecte failures, the moel checking fails after reporting at least one efect. 6. Checking arithmetic The iscovery process makes it possible to enter any state, in particular to enter any set of numbers for a ose calculation. We generate 926 ifferent relations of oses an checke the calculate rate change by the correct factor f = f f 2f 3... to within in the least significant igit (e.g., changing the concentration from grams to milligrams per ml so f =,, changing the perio from ay to hour so f 2 = 24, changing the patient weight by a ranom factor f 3, etc). The initial implementation of the calculator hanle weight incorrectly, an the problem was etecte in 6% of the checks. Conventional usability stuies reveale the efect when the calculator was compare with conventional calculators. 6.2 Improving confience As the calculator passes moel checking, one s confience in the calculator program grows. The very ifferent styles of programming (e.g., imperative versus eclarative regular expressions) are inepenent, so the probability that both are right by chance is low. However it is possible that one s confience is misplace, for example both the program an the moel checker might omit a necessary test. To avoi this, the moel checking an the program construction shoul be one by ifferent teams of programmers, at least. A complimentary approach is to introuce ( see ) ranom errors into the program being teste, an to see if the moel checker ientifies efects. For example, the calculator program inclues the following obscure, uncommente line of coe: if( ec ) igafter++; else ig++; When this line is commente out, the program fails moel checking. 7. DISCUSSION User testing requires humans, an appropriate methos to recor an analyze protocols, as well as appropriate ethical treatment of participants. Although any user testing can be insightful, thorough testing is slow an expensive. For many systems, exhaustive UI testing is infeasible because there is not enough time to try all necessary test cases: user testing rarely covers a esign fully. Systematic testing with human users is also fraught with human error, not just with the system being teste, but with the whole process. Automatic UI iscovery raises no ethical issues, it oes not eman human time for testing, an it can be use repeately with no extra cost as a esign rifts. Once a eveloper has ecie that certain issues or properties nee analysis, tests can be repeate with ease on a range of evice moels or versions. Ieally, conventional user evaluation woul be combine with iscovery tool analysis, an the two approaches woul mutually inform each other. For example, user evaluation woul ientify types of problems, an moel iscovery woul then be set up to ensure that those problems occur nowhere. Just as user evaluation creates ieas for iterative esign, so oes moel checking. We note above the iscovery of a potential esign rule that shoul have been a esign requirement, an which coul now be implemente. During moel checking we iscovere a few program quirks (such as poor naming of moes in the program coe, an reliance on sie-effects to track which number fiel was selecte);as these were correcte, the quality of the program improve further. Just as using the iscovery tool helpe improve the calculator, introucing coe to automatically run the moel

10 checker helpe improve the moel checker itself. In general we woul expect many improvements perhaps more than conventional approaches because the moel checking an original coe are so closely relate an are easy to coevelop. The main alternative to moel iscovery is to use source coe analysis. Aitional avantages of source coe analysis are that it is fast, potentially more complete, an can obtain an abstract moel irectly [5]. Its problems were iscusse above; source coe analysis is only be reliable if an appropriate UI language is use, an to o so woul impose a constraint the iscovery approach avois: the imposition of a particular programming regime on evelopers. But future work will bring these methos closer. Currently the iscovery tool is a research metho, but has shown its value in analyzing a range of systems an simulate systems. The next step woul be to refine it with a prouction system. 8. CONCLUSIONS Interactive systems have transforme life, yet the etails of programming them to interact reliably have not gaine much attention: interaction is har to visualize an har to unerstan. User interfaces are complex, an interaction efects are har to fin. Inee, the prevalent culture is to ignore efects because one is always looking forwar to the next upgrae or latest evice that promises to fix all problems! In the safety-critical omain, this attitue, whatever its full reasons, is unacceptable. Prior to the ieas iscusse in this paper there was very little to help esigners an evelopers explore an iscover any such problems, an certainly no effective way to reliably iscover all UI esign problems of a particular class. Even best practice in software engineering requires a huge manual effort to evelop correct programs, an the initially correct programs rift as they are iterate to improve their UI. Automatic moel iscovery methos are therefore essential esign ais, an coul help raically improve the quality of interactive systems. Discovery tools allow esigners an evelopers to retain their current processes an programming methoologies, but a a powerful form of analysis that is essential in safety-critical areas an beneficial in all other areas. Acknowlegements etc. This work was supporte by the EPSRC grant EP/F23. The author is a Royal Society- Leverhulme Trust Senior Research Fellow an acknowleges this generous support. An outline of this paper was [8]. Mark Davies performe usability stuies of the iphone calculator. Any Gimblett, Michael Harrison an Max Wilson mae many useful comments. The tool is available at harol.thimbleby.net/health/mc 9. REFERENCES [] Appert, C. & Beauouin-Lafon, M. (28) SwingStates: Aing state machines to Java an the Swing toolkit, Software Practice & Experience, 38(): [2] Bouillon L., Vaneronckt, J. & Chieu Chow, K. (24) Flexible Re-engineering of Web Sites, in proceeings of the international conference on Intelligent User Interfaces, IUI 4, pp [3] Claessen, K. & Hughes, J. (2) QuickCheck: A Lightweight Tool for Ranom Testing of Haskell Programs, ACM SIGPLAN Notices, 35(9): [4] Clarke, E. M. & Wing, J. M. (996) Formal methos: State of the art an future irections, ACM Computing Surveys, 28: [5] Holzman, G. J. & Smith, M. H. (2) Software Moel Checking: Extracting Verification Moels from Source Coe, Proc. Software Testing, Verification an Reliability, : [6] Institute of Safe Meication Practices (27) PCA Drug Libraries: Designing, Implementing, an Analyzing CQI Reports to Optimize Patient Safety, PCADrugLibrariesforwebce.pf [7] Institute of Safe Meication Practices (27) Flourouracil incient root cause analysis, 2FB6BC4-7CA-4E58-BDE-E54797BA47D// FluorouracilIncientMay27.pf [8] Institute of Safe Meication Practices (26) List of Error-Prone Abbreviations, Symbols an Dose Designations, [9] Jackson, D. (26) Software Abstractions: Logic, Language, an Analysis, MIT Press. [] John, B. E., Prevas, K., Salvucci, D. D. & Koeinger, K. (24) Preictive Human Performance Moeling Mae Easy, Proc. ACM CHI, [] Memon, A., Banerjee, I. & Nagarajan, A. (23) GUI Ripping: Reverse Engineering of Graphical User Interfaces for Testing, Proc. Working Conf. on Reverse Engineering, WCRE3, [2] Mesbah, A., Bozag, E. & van Deursen, A. (28) Crawling AJAX by Inferring User Interface State Changes, Proc. 8th. Int. Conf. Web Engineering, ICWE8, [3] Silva, J. C., Campos, J. C., & Saraiva, J. (27) Combining formal methos an functional strategies regaring the reverse engineering of interactive applications, Proc. Interactive Systems. Design, Specification, an Verification, Lecture Notes in Computer Science, 4323:37 5. [4] Reason, J. (28) Human error: moels an management, British Meical Journal, 32: [5] Thimbleby, H. (27) Press On: Principles of Interaction Programming, MIT Press, Boston, Mass. USA. [6] Thimbleby, H. (27) User-centere Methos are Insufficient for safety-critical Systems, Proceeings USAB 7 Usability & HCI for Meicine an Health Care, Springer Lecture Notes in Computer Science, 4799: 2. [7] Thimbleby, H. (28) Ignorance of interaction programming is killing people, ACM Interactions, 52 57, September+October. [8] Thimbleby, H. (29) Interaction Programming: Next Steps, Proceeings ACM CHI, pp [9]