Our field of research is the application of automated reasoning techniques during interactor based interactive systems development. The aim being to ensure that the developed systems embody appropriate properties and principles. In this report we identify some of the pitfalls of current approaches and propose a new way to integrate verification into interactive systems development.Fundação para a Ciência e a Tecnologia - PRAXIS XXI/BD/9562/96

Campos, J. Creissac

Universidade do Minho: RepositoriUM

Integrating Automated Verification into Interactive Systems Development Jose´ C. CamposyHCI Group, Department of Computer Science, University of York, York, UKJose.Campos@cs.york.ac.ukAbstractOur field of research is the application of automated rea-soning techniques during interactor based interactive sys-tems development. The aim being to ensure that the de-veloped systems embody appropriate properties and princi-ples. In this report we identify some of the pitfalls of currentapproaches and propose a new way to integrate verificationinto interactive systems development.1. IntroductionThe widespread use of computers puts increasing de-mands on user interfaces. On the one hand, systems mustbe intuitive and easy to use, on the other hand they mustensure safety and avoid risk. Due to their increasing com-plexity, reasoning about systems behaviour has become in-creasingly hard. This raises the question of how to ensurequality during development.The use of formal methods has long since been proposedas a solution to this problem. The advantages are two-fold:they enable better design understanding and communica-tion; and mathematical reasoning can be used to validate thedesign. This last point is especially useful when we think ofensuring system quality, as it allows us to assess the systemfrom early stages in the development process.Because reasoning about specifications of complex sys-tems will be a complex and error prone exercise in itself,ways of automating the reasoning process have been sought.Two well established approaches to automated reasoningare model checking [7] and theorem proving. While thesetechniques have been used mainly in the field of hardwareverification [8], their application to the verification of reac-tive systems in general is also being studied [18]. Published In 13th IEEE International Conference: Automated Soft-ware Engineering — Doctoral Symposium Proceedings, pages 13–15. Oc-tober 1998.yJose´ Campos is supported by Fundac¸a˜o para a Cieˆncia e a Tecnologia(FCT, Portugal) under grant PRAXIS XXI/BD/9562/96.Despite being a particular case of reactive systems, in-teractive systems have specific concepts and concerns. So,novel approaches have been sought. In this context, the no-tion of Interactor [12, 20] has been introduced as a way tostructure specifications of interactive systems.Our field of research is the application of automated rea-soning techniques during interactor based interactive sys-tems development. The aim being to ensure that the devel-oped systems embody appropriate properties and principles.2. ReviewFour major approaches to the formal (automated) veri-fication of interactive systems have been identified so far[4, 6]. Three use model checking: Abowd, Wang & Monk[1] use SMV [19], Paterno´ [20] uses the Lite tool-set [17],d’Ausbourg, Durrieu & Roche [9] use a model checkingrelated technique based on Lustre; and one uses theoremproving: Bumbulis [3] uses the HOL theorem prover.In order to better compare these approaches we have de-fined a framework with which to compare them [6]. It iden-tifies three entities involved in interaction: User, User In-terface, and an Underlying System. Interaction proceedsthrough interaction mechanisms: Events and Status Phe-nomena are atomic, Task, and Mode are used to structurethe user interface. The framework identifies also three ba-sic types of properties to be verified: Visibility, Reachabil-ity, and Reliability. Table 1 summarises the results of thereview in terms of what each approach addresses (X), par-tially addresses (), or does not address ().The conclusions drawn from the review are two-fold. Atthe technological level, it was seen that both model check-ing and theorem proving have difficulties when dealing withthe added complexity introduced by interactive systems.At the methodological level, there is a need to further in-vestigate what should/can be proved of interactive systemsusing automated reasoning tools. Previous approaches havetried to map what could be expressed in traditional verifi-cation tools into the interactive systems space. In order tomake the most of automated reasoning we must try to do theopposite: identify what properties are interesting and mapTable 1. Summary of the comparisonSMV Lotos Lustre HOLEntities Users        User Interf.  X X XUnderl. Sys.       Inter. Events  X X Mech. Stat. phenom.    X Modality   X    Task      Mode        Prop. Visibility   X X  Reachability X X X  Reliability X   them into automated verification tools.If we combine the above two concerns, we can identifya third issue that needs addressing: when should we do theproofs? — i.e., at what level of abstraction, and at whatstage of development should we be working? Tradition-ally, verification has been used to assess design against ab-solute measures of quality. Regarding HCI, matters are notso clear cut. Furthermore, if we are using principled design,it would be useful to test the design decisions against theappropriate principles as soon as possible.The challenge, then, is trying to make the best of theavailable verification technology by means of defining anappropriate methodological framework which will allow usto identify how and when verification should be applied.3. The ThesisIn view of the complexity of the systems, and of the lim-itations of the available technology, the best approach toachieve the goals set forth above is to allow for a flexiblescheme of verification. With this in mind we establishedthe following objectives: non commitment to a specific technique — we want tobe able to use model checking and theorem proving asappropriate, and not to be tied to a particular verifica-tion strategy. use of partial models — models that try to addressall relevant aspects of an interactive system are toocomplex; instead, we want to use partial models, eachmodel focusing on different design aspects (cf. [13]).These two points, together with the observation thatidentifying (let alone proving) interesting properties in “fin-ished” models becomes difficult, lead us to the realizationthat instead of being used as a post facto check on the qual-ity of the specification, verification should be used to informdesign decisions during development [5]. This can be doneby using partial models that highlight the design featuresunder consideration, and allows us to use the most appro-priate verification technique for each model.All the above leads to the definition of four lines of work: verification as a support to design — verificationshould be used to inform design decisions rather thanto check the final design; understanding properties — we need to establish aframework that enables us to reason about how to gofrom design principles to verifiable properties; model checking for interactor specifications — weneed to determine how model checking can be appliedto interactor based specifications; theorem proving for interactor specifications — simi-larly, we need to determine how theorem proving canbe applied to interactor based specifications;and the definition of the central proposition of the thesis as:Formal verification techniques (automated reasoning toolsin particular) can be used to inform design decisions duringinteractive systems development.A novel approach to the integration of automated veri-fication into interactive systems development will be pro-posed, and it will be shown how model checking and theo-rem proving can be used in the context of the approach.4. ProgressIn this section, we briefly describe the work done so far.4.1. The role of formal verificationWe propose that verification should be used to informdesign choices during development, and not only as a checkon the correctness of the specified system. The completerationale behind this proposal is presented in [5]. Some ofthe points that are made are: that the role properties playdepends not only on the system under consideration, butalso on the particular specification that is adopted; that itis difficult to base design decisions on prescriptive theoriesalone, so the possibility of early assessment of design de-cisions would be useful; that seeing the verification step asa final step in the development process, and trying to useoff the shelf properties, might lead us to end up looking atproperties of the specification instead of the system; andfinally, that the particular specification style adopted influ-ences which verification tools can be used.The use of verification to inform design can be achievedby using, not a monolithic specification which tries to en-compass all of the system, but a set of models each focusingon particular features of the system. This type of approachhas a number of benefits. Namely: we use verification tovalidate the choices that are made in relation to what is im-portant of the system, not its specification; we are able toapply the most appropriate verification technique in eachcase; conversely, we can develop each model in the mostsuitable way, regarding the tool that will be used; also, us-ing models that focus on properties means we will be ableto verify properties that otherwise would be too difficult tocheck; finally, we might be able to reuse the proofs whenthinking of related properties of different systems.4.2. Using model checkingWe are exploring the use of model checking in the verifi-cation of interactor based specifications. This is being doneat two levels: using a traditional model checker (SMV [19]),and using the  -calculus model checker in PVS.4.2.1 SMVA compiler has been developed (see [5]) that enables us toanalyse Interactors specifications in SMV. For an introduc-tion to Interactors see [12]. In short, interactors are objectswhich allow their state to be perceived through some pre-sentation (cf. visible clause below). Interactors provide aframework for specification and do not prescribe a particu-lar notation.In the present case, we are using Modal Action Logic(MAL) [21] to specify interactors behaviour. In the inputlanguage accepted by the compiler, an interactor describingwhether a window is mapped on the screen looks like this:interactor windowattributesmapped   booleanvisiblemappedactionsmap  unmapaxioms1.  mapped2.  mapped mapnextmapped3. mapped unmap nextmappedBesides the clauses shown in the example, the interactornotation allows for three additional clauses: importing (al-lows inheritance), fairness (allows the definition of a fair-ness expression to be used by SMV), and define (enable usto give names to expressions as can be done in SMV). Mul-tiple interactor specifications can be written by organisinginteractors in a hierarchy. In order to translate these hierar-chies of interactors into SMV, we use the notion of module.So, each interactor will be a module in SMV.To test properties of the specification, a further clausewas introduced in the language: test. It is used to specify aCTL formula whose validity is to be verified by SMV.In [5] it is shown how the compiler and SMV can be usedto reason about different design possibilities in the develop-ment of an e-mail client.4.2.2 PVSPVS comes with a theory that defines the CTL operators interms of the  -calculus. Alternatively we can define tempo-ral operators for other logics. In [6, Appendix C] we havedefined the operators for ACTL.In order to use the model checker, the specification needsto be structured as a predicate over pairs of states, wherethe state type must be finite. We can then use the temporaloperators to write putative theorems. PVS performs BDDsimplification over the finite-state machine defined by thepredicate over pairs of states, rewrites the temporal opera-tors in terms of  -calculus, and runs the resulting state ma-chine and  -calculus predicate in the model checker.The present approach to model interactors and propertiesin this way is still tentative. We plan to expand on it inorder to explore how the combination of theorem provingand model checking can be used to enhance the analyticpower of both techniques.4.3. Using theorem provingWhile theorem provers do not have facilities to performtemporal reasoning, they are better than model checkerswhen it comes to reasoning over more information orientedfeatures of systems. At the moment, three possible uses fortheorem proving are envisaged: the validation of the ade-quacy of perceptual operators as suggested in [11] (see be-low), using it as an additional layer over model checking,and embedding a temporal logic in PVS (c.f. [16]).4.3.1 Perceptual operatorsThe type of analysis described in [11] has to do mainly withsymbolic manipulation of expressions in order to prove theirequality. The basic idea is that properties that are proved ofan abstract specification must also be shown to held at thelevel of the concrete presentation of the system. To do thiswe represent both a model of the abstract specification ofthe system and a model of the concrete presentation that isproposed as PVS theories, and then use PVS to determineif predicates over the abstract model are equivalent to cor-responding predicates over the presentation model.In [10] we apply this line of reasoning to the analysisof an aircraft air speed indicator, regarding its fitness to as-sist the pilot in the task of maintaining the correct aircraftconfiguration during landing (cf. [15]). Three PVS theo-ries were developed. One to specify the logical model ofthe air speed indicator as well as the logical operators thatsupport the task; another to specify the concrete circular airspeed indicator, with its needle and speed bugs (which in-dicate at which air speeds the aircraft configuration shouldbe changed), and the mapping from the logical to the per-ceptual level; and finally a third theory which introduces theconjectures to be verified. As an example we present hereone of the conjectures which is analysed in [10]:configuration change task   CONJECTUREconfigChangeCheckabs asi asiConfigCheckabs asiWhat this conjecture expresses is that checking for theneed to change the aircraft configuration should yield thesame result regardless of the check being done at the log-ical level (configChangeCheck) or at the perceptual level(asiConfigCheck).  is the mapping from the logical to theperceptual level.In [10] we show how performing this type of consistencycheck improves our understanding of the specification, andallows us to identify assumptions about the system whichare embedded in the representation but not made explicitlyrepresented anywhere. As an example, during the proof ofthe conjecture above, we were led to realize how, at the pre-sentation level, the speed bugs implicitly acquire the func-tion of indicating the aircraft current configuration.5. ConclusionWe have motivated the field of formal (automated) ver-ification of interactive systems, and identified the main ap-proaches to the area (see [4] for a more detailed review).We have identified some of the pitfalls of the current ap-proaches and proposed a new way to integrate verificationinto interactive systems development.We have also briefly described the work done so far (seealso [6, 5, 10] for more details).References[1] Gregory D. Abowd, Hung-Ming Wang, and Andrew F.Monk. A formal technique for automated dialogue develop-ment. In Proceedings of the First Symposium of DesigningInteractive Systems - DIS’95, pages 219–226. ACM Press,August 1995.[2] F. Bodart and J. Vanderdonckt, editors. Design, Specificationand Verification of Interactive Systems ’96, Springer Com-puter Science. Springer-Verlag/Vien, June 1996.[3] Peter Bumbulis. Combining Formal Techniques and Proto-typing in User Interface Construction and Verification. PhDthesis, University of Waterloo, 1996.[4] Jose´ C. Campos and Michael D. Harrison. Formal verifica-tion of interactive systems: A review. In Harrison and Torres[14], pages 109–124.[5] Jose´ C. Campos and Michael D. Harrison. The role of ver-ification in interactive systems design. In Design, Specifi-cation and Verification of Interactive Systems ’98, SpringerComputer Science, pages 155–170. Eurographics, Springer-Verlag/Wien, 1998.[6] Jose´ Creissac Campos. Formal verification of interactive sys-tens. 1st year qualifying dissertation, Department of Com-puter Science, University of York, June 1997.[7] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automaticverification of finite-state concurrent systems using tempo-ral logic specifications. ACM Transactions on ProgrammingLanguages and Systems, 8(2):244–263, April 1986.[8] Edmund M. Clarke and Jeannette M. Wing. Formal meth-ods: state of the art and future directions. ACM ComputingSurveys, 28(4):626–643, December 1996.[9] Bruno d’Ausbourg, Guy Durrieu, and Pierre Roche. Deriv-ing a formal model of an interactive system from its UILdescription in order to verify and to test its behaviour. InBodart and Vanderdonckt [2], pages 105–122.[10] G. Doherty, J. C. Campos, and M. D. Harrison. Represen-tational reasoning and verification. In Proceedings of theBCS-FACS Workshop: Formal Aspects of the Human Com-puter Interaction, pages 193–212. Computing Research Cen-tre, Sheffield Hallam University, September 1998.[11] Gavin Doherty and Michael D. Harrison. A representationalapproach to the specification of presentations. In Harrisonand Torres [14], pages 273–290.[12] David J. Duke and Michael D. Harrison. Abstract interactionobjects. Computer Graphics Forum, 12(3):25–36, 1993.[13] Bob Fields, Nick Merriam, and Andy Dearden. DMVIS:Design, modelling and validation of interactive systems. InHarrison and Torres [14], pages 29–44.[14] M. D. Harrison and J. C. Torres, editors. Design, Specifi-cation and Verification of Interactive Systems ’97, SpringerComputer Science. Springer-Verlag/Vien, June 1997.[15] E. Hutchins. How a cockpit remembers its speed. CognitiveScience, 19:265–288, 1995.[16] Pertti Kelloma¨ki. Mechanical Verification of Invariant Prop-erties of DisCo Specifications. PhD thesis, Tampere Univer-sity of Technology, 1997.[17] Jose´ A. Man˜as et al. Lite User Manual. LOTOSPHEREconsortium, March 1992. Ref. Lo/WP2/N0034/V08.[18] Zohar Manna and Amir Pnueli. Temporal Verification of Re-active Systems: Safety. Springer, 1995.[19] K. L. McMillan. The SMV system. Carnegie-Mellon Univer-sity, draft edition, February 1992.[20] Fabio Paterno´. A Method for Formal Specification and Ver-ification of Interactive Systems. PhD thesis, Department ofComputer Science, University of York, 1995.[21] Mark Ryan, Jose´ Fiadeiro, and Tom Maibaum. Sharing ac-tions and attributes in modal action logic. In T. Ito and A. R.Meyer, editors, Theoretical Aspects of Computer Software,volume 526 of Lecture Notes in Computer Science, pages569–593. Springer-Verlag, 1991.

Integrating automated verification into interactive systems development

http://repositorium.sdum.uminho.pt/bitstream/1822/759/3/ase98.pdf

Integrating automated verification into interactive systems development

Abstract

Similar works

Full text

Available Versions

Universidade do Minho: RepositoriUM

Universidade do Minho: RepositoriUM