User interfaces are crucial for the success of most software projects. As software grows in complexity there is a similar growth in the user interface com- plexity which leads to bugs which may be difficult to find by means of testing. In this paper we use the method of automated model checking to verify user interfaces with respect to a formal specification. We present an algorithm for the automated abstraction of the user interface model of a given system, which uses asynchronous and interleaving composition of a number of programs. This technique was successful at verifying the user interface of case study and brings us one step forward towards push button verification.peer-reviewe

Cauchi, Abigail

Pace, Gordon J.

Spina, Sandro

Workshop in Information and Communication Technology (WICT 2008)

OAR@UM

Model Checking User InterfacesAbigail CauchiDept of Computer ScienceUniversity of Maltaacau0004@um.edu.mtGordon PaceDept of Computer ScienceUniversity of Maltagordon.pace@um.edu.mtSandro SpinaDept of Computer ScienceUniversity of Maltasandro.spina@um.edu.mtAbstractUser interfaces are crucial for the success of mostsoftware projects. As software grows in complexitythere is a similar growth in the user interface com-plexity which leads to bugs which may be difficult tofind by means of testing. In this paper we use themethod of automated model checking to verify userinterfaces with respect to a formal specification. Wepresent an algorithm for the automated abstractionof the user interface model of a given system, whichuses asynchronous and interleaving composition of anumber of programs. This technique was successful atverifying the user interface of case study and bringsus one step forward towards push button verification.Index TermsModel Checking, User Interfaces, Formal Verifica-tion, Temporal Logic, Human Computer Interaction1. IntroductionThe human component of software systems is oftenoverlooked, but it is an extremely important factor inthe success of a software project. A good number ofsystem failures (60% to 90%) have been attributed thelack of handling of possible erroneous human actionswhich contribute to an unpleasant user experience [1].Catering for avoiding the possibility of erroneous hu-man actions is therefore crucial. One should also checkthe user interface for bugs. As the user interface growslarger, the possibility of introducing bugs, similarlybecomes larger, possibbly becoming more difficult tofind by means of testing.From relevant work such as [2], [3], the missingblock is the automation of the abstraction process;this is the main focus of this paper. In this paper wepresent a technique which can be used to automati-cally abstract the user interface of a given programand modeling user behavior. The resulting model isused for verification by model checking. Since we aredealing with reactive systems, models are built usinga labeled transition system (LTS) and temporal logicis used to for formal specification. We present a toolwhich was implemented using this approach and showhow it can be used in a practical scenario.2. BackgroundTwo main tasks required for model checking arebuilding a formal model of the system to be verifiedand formalizing a specification which the model shouldsatisfy. The model checking problem is whether themodel satisfies the specification. A model checker’soutput indicates whether the specification is satisfied ornot, and possibly generates a diagnostic to demonstratethe result. The diagnostic may then be visualized tohelp tracing a possible bug. The problem with modelchecking is that the process is exponential, however,implementing abstractions on a complex model mightstill render the model checking process to be feasible.This however, may introduce false positives, i.e. themodel checker may verify that the property does nothold when it does.User interfaces are reactive systems; these are de-scribed as systems which continuously interact withtheir environment and often do not terminate [4], [5].Since termination is not guaranteed, we cannot reasonabout the system’s input-output behavior, but we needto reason about the system’s state which captures thevalues of variables at a particular instance of time [4].In order to model our system, we need to describe howthe state of the system changes when a particular actionoccurs. These state transitions may be described bytransition relations between the state before an actionoccurs and the state after the action occurs [4]. Toformalize specifications about user interfaces, temporallogic is ideal since models contain several states and ithas a dynamic notion of truth which allows a formulato hold in some states and not hold in others.The regular alternation free mu-calculus is a tem-poral logic which allows us to specify safety, livenessand fairness properties about labeled transition systems(LTSs) [6]. The regular alternation free mu-calculus ismade up of three types of formulas: action formulas,regular formulas and state formulas; the syntax inBackusNaur form (BNF) of each is given below.Action formulas are made up of action formulas,labels and boolean operators. In the BNF below, Ais an action formula and a is a label in the LTS.The boolean operators have the following semantics:a label is always said to hold, a label satisfies ¬Aiff it does not satisfy A; it satisfies A1 ∨ A2 iff itsatisfies A1 or it satisfies A2; it satisfies A1 ∧ A2 iffit satisfies both A1 and A2; it satisfies A1 ⇒ A2 iffit does not satisfy A1 or it satisfies A2; it satisfies A1≡ A2 iff either it satisfies both A1 and A2, or noneof them.A ::= a | ¬A | A ∨A | A ∧A | A⇒ A | A ≡ AA regular formula R, as described in the BNFbelow, is made up of nil, the empty operator, . theconcatenation operator, | the choice operator, ∗ thetransitive and reflexive closure operator, and + thetransitive closure operator. The semantics of each arethe same as those for regular expressions.R ::= a | nil | R.R | R | R | R ∗ | R+In he BNF below, S is a state formula, < R > Fand [R]F are the possibility and necessity modaloperators, @(R) is the infinite looping operator, µX.Fand νX.F are the minimal and maximal fixed pointoperators, and X is a propositional variable. Thefixed point operators act as binders for the variablesX in a way similar to quantifiers in first-order logic.In each meaningful µX.F or νX.F formula, X issupposed to have free occurrences inside F . Stateformulas are assumed to be syntactically monotonic(i.e., in each fixed point formula µX.F or νX.F ,free occurrences of X in F may appear only underan even number of negations and/or left-hand sidesof implications) and alternation-free (i.e., withoutmutually recursive minimal and maximal fixed pointvariables). Syntactically, all binary operators on stateformulas are left-associative.S ::= true | false | ¬S | S ∨ f | S ∧ S | S ⇒ S |S ≡ S | < R > S | [R]S | @(R) | X | µX.F | νX.F2.1. The Model Checking ProcessWe shall demonstrate the model checking processwith a text processor model. In table 1, the text pro-cessor is modeled and specified, after being verified,the counterexample generated may be seen in the sametable. The text processor is modeled as a labeledtransition system on which a specification written inthe regular alternation free mu-calculus is verified. Thetext processor starts at the Text Processing stateand when a help file is requested, it may either go to theIdle state or to the Help File Display state.From Idle, it may either display the help file, loop inIdle or continue processing. It is required that whenthe user requests a help file, it is always displayed atsome later state. This property is formalized in table 1.From the LTS described, one can see that this propertydoes not hold since the text processor may loop toinfinity in the Idle state. After verifying the model,the model checker may produce a counterexample ora family of counterexamples to show why the propertydoes not hold as shown in table 1.2.2. Dealing with the State Explosion ProblemAs mentioned previously, a problem one needs todeal with when model checking a system is the stateexplosion problem. In order to be able to verify com-plex systems, among other techniques (mentioned in[4]) abstraction may be used. When reasoning aboutreactive systems that involve data paths, the use ofabstraction seems to be essential [4].Given a programming or specification language,abstract interpretation consists in giving several seman-tics linked by relations of abstraction [7]. A semantic isa mathematical characterization of a possible behaviorof a system. A precise abstraction describes the actualexecution of the system very closely; this are calledthe concrete semantics. The concrete semantics of thetype of system we would like to verify is a set ofexecution traces where each state corresponds to aline of code. This type of abstraction is the first steptowards modeling the user interface.Due to the state explosion problem of model check-ing, we are mostly interested in types of abstractionswhich under-approximate the system by removingstates which are irrelevant to the types of propertiesbeing verified. There are several ways of doing this,the simplest way would be by retaining states whichare directly relevant, such as lines of code whichModel CounterexampleProperty: [not ("Idle")*]<any*."Start Processing".any*."Help File"> trueTable 1. The Model Checking Processare directly related to user interfaces. Other under-approximations are described in [2] which include thegrouping of related components and the considerationof independent subsystems which may be verifiedseparately, such as different windows.3. Human-Computer InteractionHCI is the study of interaction between people andcomputers. It is often regarded as the intersection ofcomputer science, behavioral sciences, design and sev-eral other fields of study. Interaction between users andcomputers occurs at the user interface. A sister field ofresearch to HCI is MMI (Man-Machine Interaction) orHMI (Human Machine Interaction). In [8] a definitionis given as follows: “Human-computer interaction is adiscipline concerned with the design, evaluation andimplementation of interactive computing systems forhuman use and with the study of major phenomenasurrounding them.”In HCI we are mostly concerned with usabilityissues. In [9], Nielsen defines usability is as follows:“Usability is a quality attribute that assesses how easyuser interfaces are to use. The word “usability” alsorefers to methods for improving ease-of-use during thedesign process.” Alternatively, in [10], Bevan interpretsusability as “quality of use”. What Bevan points outas a flaw in Nielsen’s definition of usability is thatsoftware can have a user interface which is easyenough to use making the software usable in Nielsen’ssense, but the features the software might have mightbe useless and cannot be used as a utility. Thereforea more refined definition of usability would be howcapable a software package is at helping users achievetheir intended goals, providing a quick way of doingthings by a good user interface design.Common user interface design principles have beenidentified by various papers such as [9] and [11], someof which are listed below:1) Strive for consistency2) Enable frequent users to use shortcuts3) Offer informative feedback4) Design dialog to yield closure5) Offer simple error handling6) Permit easy reversal of actions7) Support internal locus of control8) Reduce short-term memory loadBugs in coding may lead to other situations notmentioned; specifying a good design and implement-ing it make way for different types of errors. Apartfrom the need for assurance that a user interface isdesigned following good principles, one should alsocheck whether it is implemented correctly.4. Model Checking User InterfacesFrom figure 1 we can get a general picture of theprocess of model checking user interfaces. A systemis abstracted to obtain a model of its user interfacewhich is translated and input to the model checker.Subsequently, properties are specified, formalized andinput to the model checker. Finally, the model checkeris run to obtain a result of whether the property holdsor not, and possibly a counterexample is visualized.Here we shall describe the technique for automatingthe process of abstracting the user interface model. Thesystems we are handling are a family of programs,consisting of the Main method and a number of eventhandlers which handle user interaction. To model userbehavior, we use the asynchronous and interleavingcomposition of all these programs. This composition isan automated process handled by the model checker.To abstract the user interface, we build an inter-procedural control flow graph (ICFG) for each programusing standard techniques [12]. At this stage, controlflow issues, such as the handling of recursion andcatering for the object oriented paradigm, should beconsidered. The next step is to discard all nodes whichare irrelevant to the user interface, while retaining thecorrect control flow and anything contributing to thecorrectness of the properties we are verifying, such asloops (for the correctness of liveness properties).Let us look at a method of an event handler andperform the abstraction to get a better idea of thisprocedure. Consider the event handler code in figure2. The concrete graph is the first step towards ab-straction; a complete ICFG of the event handler isbuilt. The abstract graph is the resulting ICFG afterthe abstraction is performed. One can note that theonly control structure retained here is the structurecontaining user interface relevant code, and the onlyline of code retained is the one directly related to theuser interface (by the label).5. Case Study and EvaluationThis technique was used to implement a tool for sys-tems written in C# .NET 1.0 and 2.0 which producesgraphs to be used as input to CADP’s Evaluator [6]model checker. CADP provides tools for representingLTSs in a compact format, reducing and performingmanipulations on them. Evaluator allows us to writeproperties in the regular alternation free mu-calculusdescribed in section 2.A case study was carried out on a system developedusing C# .NET 2.0 consisting of 2, 631 lines of code.This system is a simulator for a fuzzy logic controllerand it is made up of a main window with a mainmenu. Menu items are to be enabled and disabledwhen appropriate, and when selected, a new windowis opened to allow the user to work on the selecteditem. 26 properties were defined which were of thefollowing nature:• Properties related to the behavior of menuitems – Checking that they are enabled when theyshould be and that they behave as necessary.• Window disposal – Since the user interface usesseveral windows, we have checked that when oneis disposed, no others are disposed mistakenly.• Window resizing – This system makes use ofwindow resizing and we make sure that thisbehaves as specified.• Error and warning handling – We checked thaterrors and warnings are displayed when necessary.• Component behavior – General behavior ofcomponents such as buttons and labels were ver-ified.Popular classes of properties include safety(nothing bad ever happens), liveness (somethinggood eventually happens) and fairness properties(considering only fair execution paths). We see anexample of a property from each class.• Safety Property – Two labels are to be enabledin a mutually exclusive fashion.[any*.Label1Enabled.(not label1Disabled)*.Label2Enabled ] false• Liveness Property – When a user closes a win-dow, eventually it is closed.<any*.CloseWindowCommand.(any*.Error)*.any*.WindowClosed> true• Fairness Property – When the Select buttonis clicked and no error occurs, the window isresized.[any*.SelectClicked.(not Error)*]<(not WindowSizeChanged)*.WindowSizeChanged> trueOur model consisted of a total 143 states with 73different labels. The average time taken for proper-ties to be verified is 45s. The property which tooklongest to be verified was the one which generated acounterexample, the time included its verification andcounterexample generation.6. Conclusions and Future WorkIn this paper we presented a technique to automati-cally abstract a system’s user interface for verificationby model checking. The asynchronous and interleavingFigure 1. System ArchitectureFigure 2. Abstraction Processcomposition of a number of programs was used tomodel user behavior, where this process of compositionwas automated. A tool was developed implementingthis technique and used on a case study to demonstratehow automatic user interface abstraction for verifica-tion by model checking may be applied.A number of possibilities for future work have beenidentified. One of the most interesting issues is howabstraction is performed. In this paper we abstractedthe user interface using an under-approximating ab-straction, however one may look into precise approx-imations by program slicing [13]. Due to the pre-cise approximation and concrete semantics of programslicing, this would work well on a system with asmall state space, however, for more complex systems,further abstraction would be necessary. Another formof abstraction is property driven abstraction where ifone wants to verify properties about one variable, allirrelevant details are discarded. Combining propertydriven abstraction with program slicing techniquescould be a step towards a precise abstraction relevant tothe property being verified. Additionally, in [2] a fewpossible abstractions on user interfaces are discussedwhich include grouping fields, considering independentsubsystems and the application state.On another note, web user interfaces also posean interesting problem, their apparent simplicity mayreveal several underlying issues. For example, to modelthe user interface of a simple HTML page, one shouldkeep in mind client-server interaction. The techniquespresented in this paper combined with techniques usedto model check website may lead to an interestinganalysis.References[1] J. Preece and Y. Rogers, Human-Computer Interaction.Addison-Wesley, 1994.[2] M. B. Dwyer, V. Carr, and L. Hines,“Model checking graphical user interfaces usingabstractions,” in Proceedings of the Sixth EuropeanSoftware Engineering Conference (ESEC/FSE 97),M. Jazayeri and H. Schauer, Eds. Springer–Verlag, 1997, pp. 244–261. [Online]. Available:citeseer.ist.psu.edu/20430.html[3] R. E. K. Stirewalt and G. D. Abowd, “Compositionproperty analysis: a new strategy for model checkinguser-interface designs,” Department of Computer Sci-ence, Michigan State University, East Lansing, Michi-gan, Tech. Rep. MSU-CSE-99-30, August 1999.[4] J. Edmund M. Clarke, O. Grumberg, and D. A. Peled,Model checking. Cambridge, MA, USA: MIT Press,1999.[5] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud,“The synchronous data-flow programming languageLUSTRE,” Proceedings of the IEEE, vol. 79, no. 9,pp. 1305–1320, September 1991.[6] H. Garavel, F. Lang, and R. Mateescu, “An overview ofCADP 2001,” European Association for Software Sci-ence and Technology (EASST) Newsletter, vol. Volume4, pp. Pages 13–24, August 2002.[7] P. Cousot and R. Cousot, “Abstract interpretation: aunified lattice model for static analysis of programs byconstruction or approximation of fixpoints,” in POPL’77: Proceedings of the 4th ACM SIGACT-SIGPLANsymposium on Principles of programming languages.New York, NY, USA: ACM, 1977, pp. 238–252.[8] Hewett, B. Card, Carey, Gasen, Mantei, Perlman,Strong, and Verplank, “Curricula for human-computerinteraction,” ACM SIGCHI, New York, NY, USA,Tech. Rep., 1992, chairman-Thomas T. Hewett.[9] J. Nielsen, Usability Engineering. San Francisco, CA,USA: Morgan Kaufmann Publishers Inc., 1995.[10] N. Bevan, “Usability is quality of use,” in Proceed-ings of the Sixth International Conference on Human-Computer Interaction. Elsevier Science, 1995, pp.349–354.[11] B. Shneiderman, Designing the User Interface:Strategies for Effective Human-Computer Interaction.ADDISON-WESLEY, 1998.[12] F. Nielson and H. R. Nielson, “Interproceduralcontrol flow analysis,” in European Symposium onProgramming, 1999, pp. 20–39. [Online]. Available:citeseer.ist.psu.edu/nielson99interprocedural.html[13] S. Horwitz, T. Reps, and D. Binkley, “Interproceduralslicing using dependence graphs,” in Proceedings ofthe ACM SIGPLAN ’88 Conference on ProgrammingLanguage Design and Implementation, vol. 23, Atlanta,GA, June 1988, pp. 35–46. [Online]. Available:citeseer.ist.psu.edu/horwitz90interprocedural.html

Model checking user interfaces

https://www.um.edu.mt/library/oar//bitstream/123456789/27842/3/Model_checking_user_interfaces_2008.pdf

Model checking user interfaces

Abstract

Similar works

Full text

Available Versions

OAR@UM