Formal Validation of Java/Swing User Interfaces with the Event B Method Alexandre Cortier1, Bruno d’Ausbourg1, and Yamine Aït-Ameur2 1
Centre d’Etudes et de Recherches de Toulouse - ONERA, 2 Avenue E. Belin – BP 4025, 31055 Toulouse, France {cortier,ausbourg}@cert.fr www.cert.fr 2 LISI/ENSMA, Téléport 2, 1 Avenue Clément Ader – BP 40109 31055 Toulouse, 86961 Futuroscope Chasseneuil, France {yamine}@ensma.fr www.lisi.ensma.fr/ihm
Abstract. User Interface (UI) systems are increasingly complex and nowadays assist critical activities. The development of UIs needs empowered validation methodologies in order to ensure the correctness of the developed UI-based applications. This paper investigates the applicability of reverse engineering and formal approaches to the validation of UIs correctness. The approach is the following. An user interface’s abstract model is derived starting from its Java/Swing source code. This formal execution model is then used to prove that the developed interactive system is in accordance with usability requirements expressed in CTT tasks models. Keywords: User Interface, Validation, Formal Methods, Method B, Tasks Model, CTT, Static Analysis.
1 Introduction For the last 20 years, user interfaces became more and more complex due to the increasing size of interactive systems and to the evolution of interaction possibilities (e.g. modalities). Moreover UI assist critical activities such as control interface of avionic systems. In this context, the evaluation of UI correctness becomes essential. Generally speaking, correctness of UI applications may be expressed as satisfying usability. Usability denotes the effectiveness efficiency and satisfaction with which users can use the system to achieve their goal [14]. In other words, the system may be considered as correct if it allows the user to perform the tasks for which this system was designed. So, it is necessary to have at one’s disposal both a representation of the system behavior and a representation of tasks and of their sequencing links. These two representations may be described by two models: a concrete model (system behavior) and an abstract model (user tasks) of the same devised system. But what is actually a model of an interactive system? Various Kinds of models were described, analyzed and deeply studied in the literature. Each of them has a particular point of view about the final system. Some J. Jacko (Ed.): Human-Computer Interaction, Part I, HCII 2007, LNCS 4550, pp. 1062–1071, 2007. © Springer-Verlag Berlin Heidelberg 2007
Formal Validation of Java/Swing User Interfaces with the Event B Method
1063
user-based models describe the tasks the user can achieve by using the final system together with the logical sequences these tasks may follow under user actions [13]. Other models give a description of the software architecture for the system implementation [6]. Some models try also to describe formally the behavior of the interactive system by representing the structure of interactions that are supported by the system [3,4,8,9,12]. More recently, some work and studies tried to build such formal models of the system behavior by analyzing the source code of programs that encodes this behavior. More precisely, for example, some approaches intend to analyze the source code, statically or dynamically according to the intended objective (formal validation or test) [5,10,11,16]. Namely, Silva and al. propose some models for the reverse engineering of Java/Swing applications. These models are obtained by a static analysis of codes [15]. By investigating the Abstract Syntax Tree (AST) of a java program and by using code slicing operations, an abstract behavioral model (in fact and more precisely an interactor model and a state machine) and an abstract structural model (an event flow graph) can be extracted. The approach developed in this paper attempts to contribute to validate interactive systems by suggesting some means to demonstrate that an interactive system behaves as intended and specified. Technically, this approach combines two kinds of models that must be formalized and expressed in the Event B language. Firstly, a given user tasks model can be considered as a possible specification of the system. We make the hypothesis that this task model is described by a CTT (Concur Task Tree) model [13]. This CTT model must be formalized in an Event B model MSp. Secondly, a static analysis of Java/Swing codes permits to extract an abstract model that catches behavioral and structural aspects of the encoded system. This extracted model MSy is also expressed in the Event B language. In this context, demonstrating that the system behaves as intended comes to demonstrate that MSy is a correct refinement of MSp. This paper is organized as follows. Section 2 presents the general principles of the approach. Section 3 focuses on the Event B model extraction and gives a simple example illustrating the approach. A conclusion is provided in section 4.
2 Formal Validation of UI Systems: General Principles This paper suggests using a formal method to contribute to the validation steps in the UI development process. The aim is to maintain experiences and practices of designers in using classical development tools but to reinforce the techniques that are involved in the validation process of user interface systems. Figure 1 sketches the different steps of the approach. These steps are graphically identified by labeled black circles that are named tags in the following. Two main steps are identified. The first one consists in extracting an Event B model from the source code (Fig.1,tag A) and the second is devoted to validate the derived Event B model (Fig.1, tag B) with respect to a user task model.
1064
A. Cortier, B. d’Ausbourg, and Y. Aït-Ameur
Fig. 1. Principles of the approach
2.1 Event B Model Extraction: Principles and Technique The aim is to extract a behavioral formal model of the Java/Swing application. A formal representation of basic interaction components that are involved in the source code is needed to capture properly the UI behavior. This representation cannot be built directly from the Java code because the code of these components is not directly inlined in the application code. These components are defined in the Swing and AWT libraries and are imported in the application code. Moreover, these object components can be shared by all the applications and it can be advantageous to avoid reengineering them each time a program is analyzed. So an Event B abstract model BSwing of the Swing library is built (Fig.1, tag 1). This abstract model is then used as a resource to derive the final Event B application model BApplM by using static analysis techniques (Fig.1, tag 2). 2.2 Formal Validation of CTT Task Models The second step of the approach uses the refinement principle in the Event B method. The objective is to check that the concrete interactive behavior of the application is in accordance with the task model requirements. In other words, the aim is to prove
Formal Validation of Java/Swing User Interfaces with the Event B Method
1065
formally that human-computer interaction scenarii that can be enforced by the encoded application software are a correct refinement of a more abstract scenario that may be derived from CTT task models. CTT is defined as a notation for task model specifications. It permits to describe tasks expressions combining temporal operators and atomic tasks. A CTT task model is based on a hierarchical structure of tasks represented by a tree-like structure. It requires identification of temporal relationships between other subtasks at the same level in the tree. We feel that task models can express a significant part of usability requirements. So, the approach associates a CTT task model that represents possible user actions, with the extracted Event B model that represents the effective reactions of the encoded application in response to the user actions. To achieve this goal, the CTT task model is concretized and then formalized into an Event B model BTask (Fig.1,tag3). This formalization step was already studied by the past and can be mechanically performed [3]. BTask is then refined by introducing new B events and variables that denote the UI reactions (Fig.1, tag 4) that are described in the BApplM model. The correctness of this last refinement BValidAppl can be mathematically demonstrated by proving the proof obligations that are generated by B tools (Fig.1,tag5). It can be concluded that the Java/Swing application behaves in accordance with the requirements expressed in the CTT task model. More information concerning the validation process can be found in [7]. Scope and limitations. The current experiments handle Java source codes that make use of Swing and AWT libraries. This choice is motivated by the gain in popularity of this language in software. However, the same principles and techniques could be developed and applied to other languages. By this time, experiments focus on the analysis and formalization of mono-threaded Java programs and applications. Synchronization constraints are not yet considered and multi threaded synchronized applications are beyond the scope of this paper.
3 Extracting an Event B Model from Java/Swing Codes 3.1 Background: The Event B Method The Event B Method was developed by J.R Abrial and is based on model description [2]. A model is defined as a set of variables that are declared and defined in the VARIABLES clause. These variables evolve thanks to events declared and defined in the EVENTS clause. An Event B model encodes a state transition system where variables represent the state and events represent and describe the transitions from state to another. An INVARIANT clause permits to define typing and safety properties on variables in first order logic. Generalized substitutions. Initialization event and other events are described in a B model using generalized substitutions based on the weakest precondition calculus of Dijkstra . Consider a substitution S and a predicate P expressing a post-condition, then [S]P represents the weakest precondition that establishes P after the execution of S. Substitutions occurring in Event B models are defined by expressions depicted in figure 2.
1066
A. Cortier, B. d’Ausbourg, and Y. Aït-Ameur
⇔P [S1 || S2]P ⇔ [S1]P ∧ [S2]P [ANY v WHERE E THEN S END]P ⇔ ∀ v.(E ⇒ [SELECT E THEN S END]P ⇔ E ⇒ [S]P [BEGIN S END]P ⇔ [S]P [x:=E]P ⇔ P(x/E)
(1)
[SKIP]P
(2) [S]P)
(3) (4) (5) (6)
Fig. 2. Generalized substitutions in Event B models
Substitutions 1,2,5 and 6 represent respectively the empty statement, the parallel substitution expressing that S1 and S2 are concurrent, the block substitution and the affectation. Substitutions 3 and 4 are guarded substitutions. The predicate E represents the guard. Each event guarded by the guard E is fired if the guard is true and when it is fired, the post-condition P is established Semantics of Event B models. The semantics of an Event B model is a trace based semantics with interleaving. A system is characterized by a set of licit traces that correspond to the fired events of the model. In fact these traces denote sequences of states. Properties can be expressed as constraints on the possible structures of these traces. If these traces are in accordance with the constraints, they satisfy the given properties and are then considered as licit. Event based systems like interactive systems can be described and formalized by following this approach [3]. Moreover, the decomposition process, thanks to the refinement operations, permits to gradually build complex systems in an incremental manner. A gluing invariant J(vari,varj) establishes a formal relationship between variables in the abstract model vari and variables in the refined model varj. The B tools generate proof obligations (OP) that must be demonstrated in order to validate the correctness of the refinement. If this correctness is proved, the abstract properties are inherited and satisfied in the refined models. From this description it appears that B is a top-down method using refinement. 3.2 Capturing the Java/Swing Application Behavior Java/Swing application. The Swing library provides the programmer with widgets that permit to program the look and feel of interfaces. User actions on widgets generate event objects inside the system. These events are characterized by a set of attribute variables such as the source of the event (the widget on which the user acts) and the type of the event. Some particular objects, named listeners, can be linked to widgets. A listener is characterized by a set of methods, the body of which is defined by the programmer. When a listener listens to an event and that event occurs, the method that is related to this event is invoked by the Java Virtual Machine (JVM) and executed. The link established at execution time between events and listener methods is enforced by considering the event attributes (source, type). Executing listener methods modifies the internal state of the interactive system. Modifications are of two types: rendering modifications (modification of state and appearance attributes of widgets) and control modifications (modifications on state variables that are not widgets).
Formal Validation of Java/Swing User Interfaces with the Event B Method
1067
Capturing the behavior. The UI behavior can be caught by focusing on rendering aspects of the application and by observing evolutions of these rendering aspects due to interactions. The relevant data that are necessary to catch properly this behavior are: (1) the creation statements of widgets and listeners instances and the links established between these widgets and listeners instances; (2) the implementation code of listener methods because this code defines and describes the UI reactions in response to user actions. Statements that perform creations of widgets or listeners, and links between widgets and listeners, can be found by starting the analysis with the implementation code of the main() method. A static analysis of this method permits to define and build the INITIALISATION clause (a particular event) of the Event B model. The UI reactions are defined in the implementation code of listener methods. These methods are also analyzed and translated in B events. But building in a single step a formal execution model of these methods from the source code is a complex task. In fact, it must be decomposed. A Java program is made up of a set of class declarations. Each class defines a set of attributes and methods. Generally, the body of a method is not only a simple sequence of assignments but it is also a sequence of more complex statements like, in particular, method calls. Moreover, a significant number of classes are imported from libraries and it is not really necessary to represent all the methods and attributes of imported classes in the final execution model. To handle this difficulty, translation of listener methods execution in B events is preceded by the following steps: (1) first, the methods of the functional core of the application are abstracted. Indeed, these methods do not affect UI rendering aspects and then are not really relevant in catching the interactive behavior of the application; (2) secondly, methods of listener are flattened by inlining their internally invoked methods. The resulting code of these methods is a linear code composed by a set of assignments that are scheduled by control structures of the language: conditional statements, sequential compositions and loops. Once these operations are carried out, the effective translation of listener methods execution into B events is actually performed. Each assignment is translated in one B event. In some cases several instructions can be merged in a single B event using parallel substitutions. This merging process requires some careful analysis of data dependencies. Variants are introduced and used to schedule these B events and to reflect the execution order of assignment statements in listener methods. This translation process is based on the translation rules defined by J.R Abrial and used in a reverse mode [1]. Technique. Figure 3 presents the technique that is used to perform the static analysis of Java/Swing applications. First, a Java Abstract Syntax Tree (AST) of the source code (Fig.3,tag1) is built by parsing it. Secondly, some abstract interpretations are performed in order to identify and to catch the only interactive part from the entire Java program (Fig.3,tag 2). Namely, the functional core of the application is strongly abstracted. The resulting Java AST may be viewed as an execution model of the interactive part of the program. Then, it is translated into an Event B AST (Fig.3, tag 3) by using some predefined transformation rules. This third AST is extended and completed by inserting the generic resource BSwing previously translated into an Event B AST (Fig.3,tag 4). The final Event B AST can be pretty-printed into the Event B behavioral and structural model of the application BApplM.
1068
A. Cortier, B. d’Ausbourg, and Y. Aït-Ameur
Fig. 3. Static Analysis of Java/Swing programs : technique
Example : A Money Converter. Figure 4 shows a small program used as an example: a money converter program from French Francs to Euros. The user enters in the left text field (Fig.4,tag 2) widget the value to convert, performs the conversion by pushing either Francs-> Euros button (Fig.4,tag 1) to convert in Euros, or the Euros>Francs button (Fig.4,tag 3) to convert in French Franc. The converted value is displayed in the right text field component (Fig 4, tag 4).
Fig. 4. An example: a money converter
At initial step, the left text field is the only enabled widget. When the user modifies this left text field by entering a value at the keyboard, buttons become enabled: the user can make the choice between two conversions. When the user clicks on a button, the second button becomes disabled and the converted value is displayed on the right text field. Figure 5 gives a part of the converter Java code example. Two buttons EF and FE and one text field output are instantiated. These widgets are instantiated and initialized in the main method P_converter. Buttons EF and FE are associated to a listener ActionListener that catches ActionEvent events emitted when the user pushes one of the two buttons. In this case, the ActionPerformed() listener method is executed. On the right side of figure 5, an overview of the obtained BApplM model is given. The INITIALISATION clause defines widgets and listeners instantiations and initializations. In this model, the total function W_att is used to represent widgets instances attributes. Three attributes are associated to each widget: visible and enabled represent respectively the visibility and enabling state of widgets, and lists encapsulate a set of listener instances associated to the widget.
Formal Validation of Java/Swing User Interfaces with the Event B Method
public class P_converter implements ActionListener { private JButton EF,FE; private JTextField output;
INITIALISATION widgets := {FE,EF,output…} || listeners := {list1,…} || W_att:={output EF
public P_converter(){ … output=new JTextField();
1069
/) (false,false, 0
(false,false,{list1})
FE (false,false,{list1}) …} || UA : ∈ struct(source ∈ widgets,…) || V_aP := 1 || ...
EF= new JButton(“EuroEVENTS >Franc”); FE=new JButton(“Franc->Euro”); Action_Performed_list1_1= SELECT EF.addActionListener(this); V_aP=0 ∧ UA’source=EF ∧ FE.addACtiolistener(this); list1 ∈ w_att(UA’source)’lists ∧ ∧ L_att(list1)’id=ActionListener EF.setEnabled(false); UA’typ=ActionPerformed FE.setEnabled(false); } THEN … V_aP := 0 || W_att(output)’visible := true || public void W_att(FE)’enabled := false || actionPerformed(ActionEvent e) W_att(EF)’enabled := true || Jtf_att(output)’value := result { output.setVisible(true); END; if(e.getSource()==EF){ ActionPerformed_list1_2= EF.setEnabled(false); SELECT FE.setEnabled(true); V_aP=1 ∧ not(UA’source=EF) ∧ result=convert(input.getText() list1 ∈ W_att(Au’source)’lists ∧ ,true); L_att(list1)’id=ActionListener ∧ ouput.setText(result);} UA’typ=ActionPerformed else { THEN EF.setEnabled(false); V_aP := 0 || FE.setEnabled(true); W_att(output)’visible := true || result=convert(input.getText() W_att(EF)’enabled := false || ,true); W_att(FE)’enabled := true || ouput.setText(result);} Jtf_att(output)’value := result } END; }
Fig. 5. A part of the converter source code and its Event B representation
For each widget type a similar function is used to represent specific widget attributes. Namely, Jtf_att associates to text field widget an attribute named value to represent the value typed in the text field. The UA variable models the last emitted events in response to the last user action onto UI. This structure encapsulates the source and the type typ of the emitted event (ActionPerformed, KeyTyped, KeyReleased). All these variables are defined in the generic resource BSwing, the Event B abstraction of the Swing library imported in BApplM. A more precise description of BSwing model can be found in [7].
1070
A. Cortier, B. d’Ausbourg, and Y. Aït-Ameur
The ActionPerformed listener method is described by two events in the EVENTS clause. The conditional statement is expressed in guards definition: the first event is fired when the source attribute of the UA variable is EF (UA’source=EF) and the second when not(UA’source=FE). The other guard conditions are similar to both events and mean that events are fired if and only if: (1) list1 is an ActionListener and is linked to the source of the last emitted event, (2) the type of the last user action is ActionPerformed. A variant V_aP is used to ensure that an event is not fired several times. In this example, there are no dependencies on variables in the sequential composition of assignments statements. So, these assignment statements can be merged in the event bodies using parallel substitutions. The method convert, which belongs to the application functional core, is abstracted by using the constant result.
4 Conclusion This paper presented an approach to contribute to formal validation of UI systems. Starting from Java/Swing source code, a profiled projection of the Java code allows to obtain an Event B model of the application. This model encapsulates UI behaviors by modeling the Swing library and by abstracting listener methods in a set of B events scheduled by variants. The functional core of the application is abstracted. Validation is achieved with respect to a task model that can be viewed as an application specification. This task model can be encoded by using the Event B Method. Once the formalization of the CTT model is obtained, it can be refined by adding variables and events of the B model extracted from the source code. The resulting refinement links user actions (leaves of the CTT task tree) with UI reactions. Assertions ensure that the final model is deadlock free. In this case, they ensure that the interaction scenarii that are encoded in the UI application are defined and accepted by the CTT task model. B tools permitted to discharge all the proof obligations generated by the prover on the example presented in this paper. By using this validation technique, the development of the UI is fully maintained as it is in practice. Moreover, except for the concretization of CTT task models and for interactive proofs, all steps of the approach are automatically performed and can be applied on Java/Swing programs. More precisely, we think that the proposed approach could be used and enforced with other programming languages for UI design. We are currently developing a tool devoted to extract an Event B model from Java/Swing source code and to assist the user in performing the validation steps. The use of this approach to validate multimodal application is also studied. Finally, we would expect to enlarge this approach by defining multiple views of the application: each view would be dedicated to the validation of various UI properties. A particular view of the application consists in performing a particular abstraction of the Event B model of this application. The performed abstraction could be validated by using the proof techniques that are associated with the refinement techniques in the B methods.
Formal Validation of Java/Swing User Interfaces with the Event B Method
1071
References 1. Abrial, J.R.: Event Based Sequential Program Development: Application to Constructing a Pointer Program. In: FME, pp. 51–74 (2003) 2. Abrial, J.R.: The B-Book: Assigning Programs to Meanings. Cambridge University Press, Cambridge (1996) 3. Aït-Ameur, Y., Baron, M., Kamel, N.: Encoding a Process Algebra using the Event B Method. Application to the Validation of User Interfaces. In: ISOLA 2005, Columbia, USA, Springer, Heidelberg (2005) 4. Ausbourd(d’), B.: Using Model Checking fort he Automatic Validation of User Interfaces Systems. In: Markopoulos, P., Johnson, P. (eds.) Proceedings of Design, Specification and Verification of Interactive Systems ’98, Abingdon, UK, Springer, Heidelberg (1998) 5. Ausbourd(d’), B., Durrieu, G., Roché, P.: Deriving a Formal Model of an Interactive System from its UIL Description in order to Verify and Tests its Behaviour. In: DSV-IS, pp. 105–122 (1996) 6. Bass, L., Pellegrino, R., Reed, S., Seacord, R., Sheppard, S., Szcezur, M.R.: The Arch Model: Seeheim Revisited. In: CHI 91 User Interface Developper’s Workshop (1991) 7. Cortier, A., Ausbourg(d’), B., Aït-Ameur, Y.: Using the Event B Method to contribute to the Formal Validation of User Interface Systems. Technical Report, ONERA-CERT (2007) 8. Duke, D.J., Harrison, M.D.: Event Model of Human-System Interaction. Software Engineering Journal, pp. 3–12 (January 1995) 9. Markopoulos, P.: A Compositional Model for the Formal Specification of User Interface. PhD thesis, University of London (1997) 10. Memon, A., Banerjee, I., Nagarajan, A.: GUI Ripping: Reverse Engineering of Graphical User Interfaces for Testing. In: Proceedings of the 10th Working Conference on Reverse Engineering (WCRE’03), Los Alamitos, CA, USA, vol. 0, p. 260. IEEE Computer Society, Washington, DC, USA (2003) 11. Moore, M.: Rule-Based Detection for Reverse Engineering User Interfaces. In: Proceedings of the 3rd Working Conference on Reverse Engineering (WCRE’96), p. 42. IEEE Computer Society Press, Washington, DC, USA (1996) 12. Palanque, P., Bastide, R., Sengès, V.: Validating Interactive System Design through the verification of Formal Task and System Models. In: Bass, L.J., Unger, C. (eds.) Working Conference on Engineering for Human-Computer Interaction (EHCI’95), pp. 189–212. Chapman & Hall, USA (1995) 13. Paternò, F.: Model-Based Design and Evaluation of Interactive Applications. Springer, London,UK (1999) 14. ISO/TC159 Sub-Committee SC4. Draft International ISO DIS 9241-11 Standard (September 1995) 15. Silva, J.C., Campos, J.C., Saraiva, J.: Models for the Reverse Engineering of Java/Swing Applications. In: 3rd International Workshop on Metamodels, Schemas, Grammars, and Ontologies (ateM 2006) for Reverse Engineering, Informatik-Bericht series. Johannes Gutenberg-Universität Mainz, Institut für Informatik – FB 8, October (2006) 16. Systa, T.: Dynamic Reverse Engineering of Java Software. In: Proceedings of the Workshop on Object-Oriented Technology, London, UK, pp. 174–175. Springer, Heidelberg (1999)
