EP1960870A1 - Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application - Google Patents

Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application

Info

Publication number
EP1960870A1
EP1960870A1 EP06842060A EP06842060A EP1960870A1 EP 1960870 A1 EP1960870 A1 EP 1960870A1 EP 06842060 A EP06842060 A EP 06842060A EP 06842060 A EP06842060 A EP 06842060A EP 1960870 A1 EP1960870 A1 EP 1960870A1
Authority
EP
European Patent Office
Prior art keywords
screen
representative
cmdlistenerl
application
manager
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06842060A
Other languages
German (de)
English (en)
Inventor
Pierre Cregut
Cuihtlauac Alvarado
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1960870A1 publication Critical patent/EP1960870A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present invention relates to a method for creating an approximation graph of the behaviors of the human-machine interface of an application.
  • the method according to the invention makes it possible, from a compiled application J2ME / MIDP (Java application for the mobile telephone), to extract an approximation graph of the behaviors of the interface presented by this application, that is to say, an automaton whose states are an approximation of the different screens that the application will present when it is executed and whose transitions are the events that move from one screen to another.
  • This graph is a finite approximation of the ideal graph of the behaviors of the application which is infinite.
  • the invention will thus find a preferred use by downloadable application validation teams.
  • the purpose of the method is to provide these evaluators with a specification embryo extracted directly from the compiled code. In particular, it allows to know all available screens and activatable transitions.
  • This graph can serve as a basis for other tools that will increase by other analyzes.
  • the technical field of the invention is that of the automatic analysis of programs and more particularly the human-machine interfaces, these programs being written in object-oriented languages with "bytecode” typed (a "bytecode” is a compiled code, see below). It is recalled that a typed language is a language used to verify, before execution, that all the data manipulated respects rules of good training so that said execution can not become uncontrolled.
  • the invention will apply to the evaluation of applications written in the Java programming language that uses the MIDP libraries.
  • the invention also applies to other typed bytecodes
  • the invention applies mainly to application tests for which the executable code is not available.
  • Java language is an object oriented language.
  • a Java program consists of a definition set of "classes”. Each class can be instantiated at runtime into "objects” that are dynamic structures containing "fields” that are local variables specific to the object and "methods” that are class-specific procedures.
  • a new object is created by a special language statement that takes the name of the class that serves as a template.
  • Java bytecode Java bytecode
  • Java bytecode is a typed language.
  • MIDP Mobile information device profile
  • MIDP provides in particular the interfaces with the terminal: the management of network connections, the human-machine interface and the access to a persistent data space.
  • MIDP relies on the J2ME / CLDC version of the Java language as defined in the Java Specification Request entitled “Connected! Limited device configuration (CLDC)", version 1.1, Java Community Process, 2002. This is a lighter version of the language, in which, in particular:
  • reflexivity APIs API allowing to directly manipulate the code of the application and contained in the java.lang.reflect package
  • MIDP is defined by the content of a "screen" object of the javax class. desktop publishing. Icdui.Screen in MIDP.
  • This content can be specialized by saving other objects (for example, items in a form) using methods specific to that object.
  • objects for example, items in a form
  • Event will be understood any action of the user or the environment that triggers a code execution in the application, for example the pressing of a button by the user or the end of a timer.
  • the method of listening to the current screen is called, with the parameters describing the object describing the current screen and the object describing the software button.
  • This method normally contains both the calculation code of the action to perform and a method call setting up the next screen.
  • reverse engineering methods are known that start from the source code of an application to reconstruct elements of a specification and allow code reengineering.
  • An example is Lexient's suite of tools available on
  • the unit handled is the piece of code and there is no notion of instance or instance class attached.
  • the tool allows to visualize where the different pieces of code are used but not to recreate a dynamic structure.
  • a method for creating an approximation graph of the behaviors of the human-machine interface of an application the application being written in an object oriented language with classes.
  • typed bytecode executing in the execution environment of a terminal with a display device, the application manipulating screen objects representing the content at a given moment of the display device, each screen object being associated by an association method to an event handler object having a callback method defined for the class of the event handler object and called directly by the runtime environment.
  • This process comprises: a step during which at least one screen representative is defined at each instruction of the application in which a screen object is instantiated;
  • a step of creation of a graph comprising nodes each illustrating a representative of screens, and arcs each connecting a node called "origin” to a node called “destination” if and only if there exists a representative of managers such as :
  • this manager representative was identified during the first phase for the screen representative illustrated by the "origin” node; and - the screen representative illustrated by the "destination" node has been identified during the second phase for this manager representative.
  • the method for creating a graph according to the invention makes it possible, by a succession of totally automatic steps, to obtain an approximation of the graph of the behaviors comprising all the transitions that make it pass from one screen to another
  • the object-oriented language to classes can be the Java language, the environment environment MIDP environment, and the terminal a mobile phone.
  • the invention can also be applied to mobile phone applications in WINDOWS ME complying with the. NET standard proposed by MICROSOFT.
  • the behavior approximation graph can be defined as follows:
  • the nodes of the graph represent sets of screen objects encoding screens to be displayed during the execution of the application and characterized by a common property.
  • a screen object can only be represented by one node; the oriented arcs of the graph connecting an "origin" node to a "destination" node illustrate the possibility of a transition from a screen described by an object-origin to a screen described by a destination object following the occurrence of Event.
  • the invention therefore advantageously makes it possible to automate the creation of an approximation of the ideal graph, without having to execute the application.
  • the invention also makes it possible to provide a graph of the behaviors illustrating the exhaustive operation of an application, whereas in the known methods of the state of the art there is always a risk that certain functionalities of the application have not been tested.
  • the instructions of the application where the association method is used are determined, and for each call to this method is determined: the screen representatives that have been defined for the instantiation of screen objects that can be passed as an argument in this call, and - managers' representatives who have been defined for the instantiation of event-manager-objects that can be passed as argument in this call.
  • the variables declared in the application that can contain an event-manager object for the instantiation of which this manager representative has been defined are determined beforehand for each manager representative.
  • This operation is known in the Anglo-Saxon literature under the name of "points-to analyzed, that can be translated by” analysis of pointing. "For the Java language, this operation can be implemented directly on the bytecode.
  • the result of this analysis can be represented by a "point analysis graph" connecting each point of the code where objects are created at the points of the code where these objects are used.
  • the graph of approximation of the behaviors of the application correspond to two quite distinct notions, more precisely, one extracts information from the first to build the second, and in a preferred and similar way, it is determined in advance, for each screen representative, the variables declared in the application may contain a screen object for the instantiation of which this screen representative has been defined.
  • the various steps of the method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program comprising instructions adapted to the implementation of the graph creation process mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD
  • ROM read-only memory
  • a microelectronic circuit ROM or a magnetic recording means, for example a floppy disk or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also relates to a computer comprising the recording medium mentioned briefly above.
  • Appendix 1 is an example source code of a computer program for coding the behavior of the human-machine interface of an application
  • FIG. 1 to 3 show, in flowchart form, the main steps of a graph creation method according to the invention in a particular embodiment
  • FIG. 4 represents a computer 10 according to the invention.
  • FIG. 5 represents the approximation graph of the behaviors corresponding to the source code given as an example in appendix 1.
  • Figures 1 to 3 represent in the form of flow charts the main steps of a method of creating a behavior approximation graph according to the invention in a particular embodiment.
  • a "suite" of "midlets” is constituted by a set of classes compiled and stored together in an archived file.
  • references in parentheses for example (II), identify points in the code. They are placed immediately after the instruction they are labeling (usually a method call or comparison).
  • variables screenl, screen2, screen3 are declared which are screen contents of form type (Form) and which will contain information to be displayed.
  • the Test2 method is the constructor of the Test2 class. It is called at launch of the midlet to create an instance.
  • the "display" variable is updated and each message is added to each screen by wrapping it in an object inheriting from the specialized Item class for the display of strings (Stringltem). The various buttons are then recorded in screens.
  • Event handler objects (CmdListenerl and CmdListener2) are then created at instructions 113 and 114, and one of these event handler objects is associated with each of the forms.
  • the screen objects are associated with the event handler objects in instructions 115 to 117 by a setCommandListener association method.
  • startApp pauseApp
  • destroyApp define the actions performed during the transitions between the different states of the life cycle of a midlet, the midlet being controlled by a manager inside the terminal (for example a telephone).
  • the startApp function sets up the first visible form, the screenl screen (statement 118).
  • the classes defining the event handlers are then declared. These classes implement the CommandListener interface, which means that they contain a commandAction method that respects the type given below, that is, taking a command and a screen content (for example a form) as argument. and not returning any information. These methods are called when a key is pressed. The first argument is then the name of the activated virtual button and the second argument is the screen content that was on the display. The chosen behavior is selected using these two pieces of information.
  • the button is "exit"
  • the midlet is stopped by a standard stopping procedure (instructions 119 and 126).
  • the button is "help” (instructions 120 and 127), the help
  • the screen screen is always displayed.
  • FIG. 4 represents a computer (or evaluator) according to the invention. It comprises a recording medium (a memory) on which is recorded a computer program comprising instructions for implementing the graph method according to the invention, the main stages of which are given in FIGS. 1 to 3 in this mode. preferred embodiment.
  • Evaluator 10 does not receive the source code from Appendix 1, but a compiled version consisting of two files:
  • test2.jad a text file describing the midlet, this file being also called JAD file (for Java Descriptor);
  • - a file containing the compiled midlet code. It is a Java archive containing the code of each class. In the example described here, its name is test2.jar.
  • this application manipulates three screen objects screenl, screen2, screen3 representing the content at a given moment of this display device.
  • Each screen object is associated by the setCommandListener association method with a CmdListenerl or CmdListener2 event handler object.
  • CmdListenerl, CmdListener2 event handler objects include a callback method
  • CmdListenerl. commandAction and CmdListener2.commandAction these methods being defined for the class of the event handler object.
  • a screen representative is defined for each instruction of the application in which a screen object is instantiated.
  • three screen representatives respectively II,
  • step ElO is followed by a step E20 during which a manager representative is defined at each instruction of the application in which an event management object is instantiated.
  • these manager representatives are respectively 113 and 114 corresponding to instructions 113 and 114 for instantiating the event handler objects CmdListenerl and CmdListener2.
  • This step E20 is followed by a step E21 in which is determined by a scoring analysis, all the instructions of the application where it is appealed to the association method.
  • these instructions are instructions 115, 116 and 117 using the setCommandListener association method.
  • This step E21 is followed by a loop consisting of steps E22 to E28, the loop being implemented for each instruction 115, 116 and 117 identified in the previous step E21.
  • this loop comprises a first step E23 in which it is determined, for each screen representative
  • This step E23 is followed by a step E24 during which the screen objects contained in these variables are searched.
  • the screen object arguments are respectively screenl, screen2 and screen3 for the instructions 115, 116 and 117 calling the setCommandListener association method.
  • This step E24 is followed by a step E25 during which the screen representatives defined for the instantiation of the screen objects identified in the previous step E24 are identified.
  • This step E25 is followed by a step E26 during which the variables declared in the application that can contain an event manager object are identified, these variables being explicit in the bytecode.
  • This step E26 is followed by a step E27 during which the event management objects contained in these variables are identified.
  • these event handler objects are respectively CmdListenerl, CmdListener2 and CmdListenerl for instructions 115, 116 and 117.
  • step E27 is followed by a step E28 during which the managers' representatives who have been defined by the instantiation of the event management objects identified in the previous step E27 are identified. These management representatives are respectively 113 and
  • the loop constituted by the steps E22 to E28 stops after the processing of the three call instructions to the association method. This loop makes it possible to implement a first phase
  • This first phase E30 consists of a loop of steps E301 to E304.
  • This loop is implemented for each call to the setCommandListener association method 115, 116, 117. It comprises a first step E302 during which the screen representatives associated with this call are identified.
  • step E302 the screen representatives identified in step E302 are respectively II, 12 and 13.
  • step E303 the event handler representatives associated with this call are identified, namely in this example 113 for 115 and 117 and 114 for 116.
  • Step E303 is followed by a step E304 in which each of the screen representatives identified in step E302 is associated with each of the manager representatives identified in step E303.
  • the first phase E30 is followed by a second phase E40 which will now be described with reference to FIG.
  • this second phase E40 is constituted by a loop E31 to E39 implemented for each callback method CmdListenerl.commandAction and CmdListener2.commandAction.
  • This loop comprises a first step E32 during which all the event handler objects comprising this callback method are identified. So, in the example described here, for the callback methods CmdListenerl.commandAction and CmdListener2.commandAction, these event handler objects are CmdListenerl and Cmdl_istener2, respectively.
  • Step E32 is followed by a step E33 during which the instructions are identified where these objects of the event manager are instantiated.
  • these instructions are respectively 113 and 114 for the event handler objects CmdListenerl and CmdListener2.
  • This step E33 is followed by a step E34 in which the manager representatives defined for the instantiation of these event managers are identified.
  • the representatives are respectively the instructions 113 and 114.
  • the step E34 is followed by a step E36 during which the instructions for calling the screen change method (setCurrent) which can intervene during the execution of these callback methods.
  • the setCurrent instructions that can occur during the execution of the CmdListenerl.commandAction method are the instructions 118, 121, 124 and 125 (respectively 128 and 129).
  • step E36 is followed by a step E38 during which the screen objects that can be passed as argument in each of these calls to the setCurrent screen change method are determined.
  • this object is screenl
  • this object is screen3; for the call of line 124, this object is screenl;
  • this object is screen2;
  • this object is screen3;
  • this object is screenl.
  • Step E38 is followed by a step E39 during which the screen representatives defined for the instantiation of this screen object are identified.
  • the screenl, screen2 and screen3 screen representatives are instructions II, 12 and 13, respectively.
  • This loop E31 to E39 ends when each callback method has been processed.
  • the second phase E40 is followed by a step E50 during which the behavior approximation graph of the human-machine interface of the application is created.
  • N1, N2, N3 each illustrating a screen representative II, 12, 13.
  • This graph also comprises arcs each connecting a so-called “origin” node to a so-called “destination” node if and only if there exists a manager representative 113, 114, such that:
  • the manager representative has been identified during the first phase E30 for the screen representative illustrated by the origin node, and
  • This graph comprises for example an arc ⁇ originating from the node N1 illustrating the screen representative II and destination node N3 illustrating the screen representative 13, because there is a manager representative 113 identified during the first phase E30 for representing the screen II (2nd column of "Tableaul”); and the representative of screen 13 shown by the destination node N3 has been identified during the second phase E40 for the manager representative 113 (4 th line "Table2").

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Le graphe d'approximation des comportements de l'interface homme-machine d'une application, qui est obtenu de manière automatique par ce procédé, peut être défini de la façon suivante : les noeds (Nl, N2, N3) du graphe représentant des ensembles d'objets écrans codant des écrans pour être affichés lors de l'exécution de l'application et caractérisés par une propriété commune. Un objet écran ne peut être représenté que par un seul noed ; les arcs (a) orientés du graphe reliant un noed "origine" (Nl) à un noed "destination" (N3) illustrent la possibilité d'une transition d'un écran décrit par un objet d'une origine à un écran décrit par un objet d'une destination suite à la survenance d'un événement.

Description

Procédé de création d'un graphe d'approximation des comportements de l'interface homme-machine d'une application.
Arrière-plan de l'invention
La présente invention se rapporte à un procédé de création d'un graphe d'approximation des comportements de l'interface homme- machine d'une application.
Elle se rapporte également à un ordinateur mettant en œuvre ce procédé.
De façon privilégiée, le procédé selon l'invention permet, à partir d'une application compilée J2ME/MIDP (application Java pour le téléphone mobile), d'extraire un graphe d'approximation des comportements de l'interface présentée par cette application, c'est-à-dire un automate dont les états sont une approximation des différents écrans que présentera l'application lors de son exécution et dont les transitions sont les événements qui font passer d'un écran à un autre. Ce graphe est une approximation finie du graphe idéal des comportements de l'application qui est infini. L'invention trouvera ainsi une utilisation privilégiée par les équipes de validation d'applications téléchargeables.
En effet, les développeurs de telles applications transmettent généralement les applications sous forme de code fermé sans la moindre spécification de leur fonctionnement.
Le procédé a pour but de fournir à ces évaluateurs un embryon de spécification extrait directement du code compilé. Elle permet en particulier de connaître l'ensemble des écrans disponibles et des transitions activables.
Ce graphe peut servir de base à d'autres outils qui renchériront par d'autres analyses. Le domaine technique de l'invention est celui de l'analyse automatique de programmes et plus particulièrement des interfaces homme-machine, ces programmes étant écrits dans des langages orientés objet à "bytecode" typé (un "bytecode" est un code compilé, voir ci- dessous). On rappelle qu'un langage typé est un langage permettant de vérifier, avant exécution, que l'ensemble des données manipulées respecte des règles de bonne formation de telle sorte que ladite exécution ne pourra devenir incontrôlée.
L'invention s'appliquera à l'évaluation d'applications écrites dans le langage de programmation Java qui utilise les bibliothèques MIDP. L'invention s'applique également à d'autres bytecodes typés
(.net en particulier) et à d'autres environnements graphiques reposant sur la description de l'interface homme-machine par des objets graphiques et des gestionnaires d'événements (Java AWT par exemple).
L'invention s'applique principalement aux tests d'applications pour lesquelles on ne dispose pas du code exécutable.
Elle peut aussi s'appliquer aux tests d'applications pour lesquelles on dispose du code source mais pas d'une spécification.
On rappellera tout d'abord que le langage Java est un langage orienté objet. Un programme Java est constitué d'un ensemble de définition de "classes". Chaque classe peut être instanciée à l'exécution en des "objets" qui sont des structures dynamiques contenant des "champs" qui sont des variables locales propres à l'objet et des "méthodes" qui sont des procédures propres à la classe.
Un nouvel objet est créé par une instruction spéciale du langage qui prend en paramètre le nom de la classe qui sert de modèle.
La compilation d'un programme Java génère un pseudo-langage machine appelé "bytecode Java" exécutable efficacement par un environnement d'exécution appelé "machine virtuelle".
Comme le langage source, le bytecode Java est un langage typé.
La vérification du bytecode par la machine virtuelle avant son exécution est la base des mécanismes de sécurité. Ceci repose en effet sur des invariants de la forme : tel morceau de code ne pourra être exécuté que si tel autre morceau de contrôle l'a été auparavant. On rappelle également que le profil MIDP est un ensemble de bibliothèques spécialisées pour l'utilisation de la plate-forme J2ME sur les téléphones portables. Pour plus d'informations, l'homme du métier pourra se reporter à la spécification (Java Spécification Request) intitulée "Mobile information device profile (MIDP)", version 2.0, Java Community Process, novembre 2002. MIDP fournit en particulier les interfaces avec le terminal : la gestion des connexions réseau, l'interface homme-machine et l'accès à un espace de données persistant. MIDP s'appuie sur la version J2ME/CLDC du langage Java, telle que définie dans la spécification (Java Spécification Request) intitulée" Connectée! limited device configuration (CLDC)", version 1.1, Java Community Process, 2002. Il s'agit d'une version allégée du langage, dans laquelle, en particulier :
- il n'est pas possible de charger de nouvelles bibliothèques dynamiquement : l'application est définie dans son intégralité par le code chargé, et
- il n'y a pas d'accès à des API de réflexivité (API permettant de manipuler directement le code de l'application et contenues dans le package java.lang.reflect) sur le code permettant de construire dynamiquement des appels de méthodes. De façon connue, le contenu d'un écran dans une application
MIDP est défini par le contenu d'un objet "écran" de la classe javax. microédition. Icdui.Screen en MIDP.
Ce contenu peut être spécialisé en enregistrant d'autres objets (par exemple des items dans un formulaire) à l'aide de méthodes particulières à cet objet. Parmi ces objets, on identifie :
- les "commandes" qui définissent des boutons logiciels affichés sur l'écran. L'utilisateur peut les sélectionner via les boutons réels du clavier. L'appui sur un bouton logiciel déclenche un événement,
- les "objets de gestion" ou "d'écoute d'événement" ("//stener"' en anglais) qui contiennent une méthode appelée à chaque événement. par "événement" on comprendra toute action de l'utilisateur ou de l'environnement qui déclenche une exécution de code dans l'application, par exemple la pression d'un bouton par l'utilisateur ou la fin d'une temporisation. Lorsque l'utilisateur sélectionne un des boutons logiciels affichés à l'écran, la méthode d'écoute de l'écran courant est appelée, avec pour paramètres l'objet décrivant l'écran courant et l'objet décrivant le bouton logiciel.
Cette méthode contient normalement à la fois le code du calcul de l'action à effectuer et un appel de méthode mettant en place l'écran suivant. Pour l'analyse de code source, on connaît des méthodes dites de "reverse engineering" qui partent du code source d'une application pour reconstruire des éléments d'une spécification et permettre le "reengineering" du code. Un exemple est la suite d'outils de Lexient accessible sur
Internet à l'adresse http://www.lexientcorp.com/, 2004 qui permet d'extraire des informations de programme C, C++ et Java.
Selon cette méthode, l'unité manipulée est le morceau de code et il n'y a pas de notion d'instance ou de classe d'instance attachée. L'outil permet donc de visualiser où sont utilisés les différents morceaux de code mais pas de recréer une structure dynamique.
D'autres méthodes, par exemple celle décrite dans l'article de N. Mansurov et R. Probert intitulé "Dynamic scenario-based approach to reengineering of legacy télécommunication software' in R. Dssouli, G. V. Bochmann, et Y. Lahav, éditeurs, 9ème SDL Forum, Montréal, juin 1999, Elsevier Science Publishers B.V. (North-Holland), reposent sur le développement d'outils extrayant des automates représentant une spécification d'un système à partir d'un ensemble de traces d'exécutions.
De tels outils nécessitent des traces et donc d'exécuter des tests. Ils ne sont pas utilisables préalablement à une campagne de tests. L'invention permet de résoudre les problèmes précédents.
Objet et résumé de l'invention
A cet effet, elle vise, selon un premier aspect, un procédé de création d'un graphe d'approximation des comportements de l'interface homme-machine d'une application, l'application étant écrite dans un langage orienté objet à classes avec bytecode typé s'exécutant dans l'environnement d'exécution d'un terminal muni d'un dispositif d'affichage, l'application manipulant des objets-écran représentant le contenu à un instant donné du dispositif d'affichage, chaque objet-écran étant associé par une méthode d'association à un objet-gestionnaire-d'événement comportant une méthode de rappel définie pour la classe de l'objet- gestionnaire-d'événement et appelée directement par l'environnement d'exécution. Ce procédé comprend : - une étape au cours de laquelle on définit au moins un représentant d'écrans à chaque instruction de l'application dans laquelle un objet-écran est instancié ;
- une étape au cours de laquelle on définit au moins un représentant de gestionnaires à chaque instruction de l'application dans laquelle un objet- gestionnaire-d'évènement est instancié ;
- une première phase au cours de laquelle on identifie, pour chaque représentant d'écrans, les représentants de gestionnaires qui ont été définis pour l'instanciation d'un objet-gestionnaire-d'évènement associé à un objet-écran pour l'instanciatîon duquel ce représentant d'écrans a été défini ;
- une deuxième phase au cours de laquelle on identifie, pour chaque groupe de représentants de gestionnaires qui ont été définis pour l'instanciation d'objets-gestionnaire-d'événement comportant une même méthode de rappel, les représentants d'écrans qui ont été définis pour les objets-écran qui sont mis en place lors de l'exécution de cette méthode de rappel, et
- une étape de création d'un graphe comprenant des nœuds illustrant chacun un représentant d'écrans, et des arcs reliant chacun un nœud dit "origine" à un nœud dit "destination" si et seulement si il existe un représentant de gestionnaires tel que :
- ce représentant de gestionnaires a été identifié au cours de la première phase pour le représentant d'écran illustré par le nœud "origine" ; et - le représentant d'écran illustré par le nœud "destination" a été identifié au cours de la deuxième phase pour ce représentant de gestionnaires.
En conséquence, le procédé de création de graphe selon l'invention permet d'obtenir, par une succession d'étapes totalement automatique, une approximation du graphe des comportements comportant toutes les transitions qui font passer d'un écran à un autre
(une telle approximation est dite "conservatrice").
Ce résultat est particulièrement avantageux car les méthodes manuelles connues à ce jour, et par lesquelles les développeurs opèrent par tâtonnement, en partant d'un point d'entrée et en remontant d'une manière ou d'une autre dans le code, ne permettent pas de garantir l'exhaustivité du graphe, cette exhaustivité étant en pratique très difficile à obtenir pour une application complexe.
Dans un mode de réalisation particulier, le langage orienté objet à classes peut être le langage Java, l'environnement d'exécution l'environnement MIDP, et le terminal un téléphone portable.
L'invention peut également s'appliquer aux applications pour téléphones portables dans WINDOWS ME conforme au standard .NET proposé par la société MICROSOFT.
Le graphe d'approximation des comportements peut être défini de la façon suivante :
- les nœuds du graphe représentent des ensembles d'objets écrans codant des écrans pour être affichés lors de l'exécution de l'application et caractérisés par une propriété commune. Un objet écran ne peut être représenté que par un seul nœud ; - les arcs orientés du graphe reliant un nœud "origine" à un nœud "destination" illustrent la possibilité d'une transition d'un écran décrit par un objet-origine à un écran décrit par un objet-destination suite à la survenance d'un événement.
Dans l'art antérieur, les seules approximations du graphe des comportements connues sont construites "à la main" lors de tests d'exécution de l'application et en observant les actions qui ont été exécutées lors de chaque test.
L'invention permet donc avantageusement d'automatiser la création d'une approximation du graphe idéal, et ce sans avoir à exécuter l'application.
L'invention permet également de fournir un graphe des comportements illustrant le fonctionnement exhaustif d'une application, alors que dans les méthodes connues de l'état de la technique il existe toujours un risque que certaines fonctionnalités de l'application n'aient pas été testées.
Préférentiellement, pour mettre en œuvre la première phase, on détermine les instructions de l'application où il est fait appel à la méthode d'association, et on détermine pour chaque appel à cette méthode : - les représentants d'écrans qui ont été définis pour l'instanciation des objets-écran qui peuvent être passés en argument dans cet appel, et - les représentants de gestionnaires qui ont été définis pour l'instanciation des objets-gestionnaire-d'événement qui peuvent être passés en argument dans cet appel.
Dans un mode préféré de réalisation de l'invention, au cours de la deuxième phase, on détermine au préalable pour chaque méthode de rappel :
- les instructions de l'application où est instancié un objet-gestionnaire- d'évènement comportant cette méthode de rappel ;
- les représentants de gestionnaires qui ont été définis pour l'instanciation de ces objets-gestionnaire-d'évènement ;
- les appels à la méthode de changement d'écran pouvant intervenir lors de l'exécution de cette méthode de rappel, et
- les représentants d'écrans qui ont été définis pour l'instanciation des objets-écran qui peuvent être passés en argument dans chacun de ces appels à la méthode de changement d'écran.
Préférentiellement, on détermine au préalable, pour chaque représentant de gestionnaires, les variables déclarées dans l'application pouvant contenir un objet-gestionnaire-d'évènement pour l'instanciation duquel ce représentant de gestionnaires a été défini. Cette opération est connue dans la littérature anglo-saxonne sous le nom de "points-to analysé, que l'on peut traduire par "analyse de pointage". Pour le langage Java, cette opération peut être mise en œuvre directement sur le bytecode. Le résultat de cette analyse peut être représenté par un "graphe d'analyse de pointage" reliant chacun des points du code où sont créés des objets aux points du code où ces objets sont utilisés. On notera que le graphe d'analyse de pointage et le graphe d'approximation des comportements de l'application correspondent à deux notions bien distinctes ; plus précisément, on extrait des informations du premier pour construire le second. De façon préférée et similaire, on détermine au préalable, pour chaque représentant d'écrans, les variables déclarées dans l'application pouvant contenir un objet-écran pour l'instanciation duquel ce représentant d'écrans a été défini.
Selon une implémentation préférée, les différentes étapes du procédé sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme comportant des instructions adaptées à la mise en œuvre du procédé de création de graphe mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD
ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise aussi un ordinateur comportant le support d'enregistrement mentionné brièvement ci-dessus.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence à l'annexe et aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif, et dans lesquels : - l'annexe 1 est un exemple de code source d'un programme d'ordinateur pour le codage du comportement de l'interface homme- machine d'une application ;
- les figures 1 à 3 représentent, sous forme d'organigrammes, les principales étapes d'un procédé de création de graphe conforme à l'invention dans un mode particulier de réalisation ;
- la figure 4 représente un ordinateur 10 conforme à l'invention ; et
- la figure 5 représente le graphe d'approximation des comportements correspondant au code source donné en exemple à l'annexe 1.
Description détaillée d'un mode de réalisation
Les figures 1 à 3 représentent sous forme d'organigrammes les principales étapes d'un procédé de création d'un graphe d'approximation des comportements conforme à l'invention dans un mode particulier de réalisation.
Dans l'exemple décrit ici, nous construirons le graphe d'approximation des comportements pour le code source donné à l'annexe 1.
De façon connue, une "suite" de "midlets" est constituée par un ensemble de classes compilées et stockées ensemble dans un fichier d'archivé.
Une "midlet" est un point d'entrée dans cet ensemble. Dans cet exemple, les références entre parenthèses, par exemple (II), identifient des points dans le code. Ils sont placés immédiatement après l'instruction qu'ils étiquettent (en général un appel de méthode ou une comparaison).
Dans un premier temps (instructions II, 12, 13), on déclare des variables screenl, screen2, screen3 qui sont des contenus d'écran de type formulaire (Form) et qui contiendront des informations à afficher.
On déclare ensuite (instructions 14, 15, 16) trois commandes qui représentent des boutons permettant de passer d'un écran à l'autre de l'affichage. Chaque commande est caractérisée par le texte qui s'affiche sur le bouton. On déclare ensuite une variable "display" qui contient un pointeur sur l'objet représentant l'écran. C'est cet objet dont on modifie le contenu pour changer l'affichage.
La méthode Test2 est le constructeur de la classe Test2. Elle est appelée au lancement de la midlet pour créer une instance.
On met à jour la variable "display" et on ajoute à chacun des écrans leur message en enrobant celui-ci dans un objet héritant de la classe Item spécialisée pour l'affichage des chaînes de caractères (Stringltem). On enregistre ensuite les différents boutons dans des écrans.
Ainsi, l'homme du métier reconnaîtra aux instructions 17, 18 et 19 que le bouton "ok" est disponible dans les trois écrans screenl, screen2, screen3.
On crée ensuite, aux instructions 113 et 114, des objets gestionnaires d'événement (CmdListenerl et CmdListener2), et on associe un de ces objets gestionnaires d'événement à chacun des formulaires.
A chaque fois que l'utilisateur pressera un bouton, l'objet gestionnaire d'événement associé au formulaire concerné sera appelé.
Les objets écran sont associés aux objets gestionnaires d'événement aux instructions 115 à 117, par une méthode d'association setCommandListener.
Les trois fonctions suivantes startApp, pauseApp et destroyApp définissent les actions réalisées lors des transitions entre les différents états du cycle de vie d'une midlet, la midlet étant contrôlée par un gestionnaire à l'intérieur du terminal (par exemple un téléphone).
La fonction startApp met en place le premier formulaire visible, à savoir l'écran screenl (instruction 118).
On déclare ensuite les classes définissant les gestionnaires d'événement. Ces classes implémentent l'interface CommandListener, ce qui signifie qu'elles contiennent une méthode commandAction respectant le type donné ci-dessous, c'est-à-dire prenant en argument une commande et un contenu d'écran (par exemple un formulaire) et ne retournant aucune information. Ces méthodes sont appelées lorsqu'une touche est pressée. Le premier argument est alors le nom du bouton virtuel activé et le deuxième argument le contenu d'écran qui était à l'affichage. Le comportement choisi est sélectionné en utilisant ces deux informations.
Ainsi, si le bouton est "exit", on arrête la midlet par une procédure d'arrêt standard (instructions 119 et 126). Si le bouton est "help" (instructions 120 et 127), on affiche l'aide
(instructions 121 et 128).
Enfin si le bouton est "ok" :
- dans le premier objet-gestionnaire (instruction 122), on affiche l'écran screenl (instruction 124) ou l'écran screen2 (instruction 125) en fonction de l'écran dont on vient (instruction 123) ;
- dans le second objet-gestionnaire (instruction 129), on affiche systématiquement l'écran screenl.
La figure 4 représente un ordinateur (ou évaluateur) conforme à l'invention. Il comporte un support d'enregistrement (une mémoire) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour mettre en œuvre le procédé de graphe selon l'invention, dont les principales étapes sont données aux figures 1 à 3 dans ce mode préféré de réalisation.
L'évaluateur 10 ne reçoit pas le code source de l'annexe 1, mais une version compilée constituée de deux fichiers :
- un fichier texte (test2.jad) décrivant la midlet, ce fichier étant aussi appelé fichier JAD (pour Java Descriptor) ; et
- un fichier contenant le code compilé de midlet. Il s'agit d'une archive Java contenant le code de chacune des classes. Dans l'exemple décrit ici, son nom est test2.jar.
On va maintenant décrire les principales étapes du procédé de création selon l'invention pour construire le graphe d'approximation des comportements de l'interface homme-machine de l'application dont le code source est donné à l'annexe 1. Cette application est écrite dans un langage orienté objet à classe qui s'exécute dans l'environnement d'exécution d'un terminal muni d'un dispositif d'affichage, par exemple un téléphone mobile.
Comme décrit précédemment, cette application manipule trois objets écran screenl, screen2, screen3 représentant le contenu à un instant donné de ce dispositif d'affichage. Chaque objet écran est associé par la méthode d'association setCommandListener à un objet gestionnaire d'événement CmdListenerl ou CmdListener2.
Ces objets gestionnaires d'événement CmdListenerl, CmdListener2 comportent une méthode de rappel
CmdListenerl. commandAction et CmdListener2.commandAction, ces méthodes étant définies pour la classe de l'objet gestionnaire d'événement.
Ces méthodes de rappel sont appelées directement par l'environnement d'exécution, à savoir MIDP dans l'exemple de réalisation décrit ici.
Au cours d'une première étape ElO, on définit un représentant d'écran à chaque instruction de l'application dans laquelle un objet écran est instancié. Ainsi, on définit trois représentants d'écran, respectivement II,
12, 13, correspondant aux instructions de l'application dans lesquelles les objets écran screenl, screen2, screen3 sont respectivement instanciés.
Cette étape ElO est suivie par une étape E20 au cours de laquelle on définit un représentant de gestionnaire à chaque instruction de l'application dans laquelle un objet gestionnaire d'événement est instancié.
Dans l'exemple décrit ici, ces représentants de gestionnaire sont respectivement 113 et 114 correspondant aux instructions 113 et 114 d'instanciation des objets gestionnaires d'événement CmdListenerl et CmdListener2. Cette étape E20 est suivie par une étape E21 au cours de laquelle on détermine, par une analyse de pointage, toutes les instructions de l'application où il est fait appel à la méthode d'association.
Dans l'exemple décrit ici, ces instructions sont les instructions 115, 116 et 117 faisant appel à la méthode d'association setCommandListener.
Cette étape E21 est suivie par une boucle constituée par les étapes E22 à E28, la boucle étant mise en œuvre pour chaque instruction 115, 116 et 117 identifiée à l'étape précédente E21.
Plus précisément, cette boucle comporte une première étape E23 au cours de laquelle on détermine, pour chaque représentant d'écran
II, 12, 13, toutes les variables déclarées dans l'application pouvant contenir un objet écran screenl, screen2, screen3 pour l'instanciation duquel son représentant d'écran a été défini.
L'homme du métier comprendra que ces variables qui sont implicites dans le code source de l'annexe 1 sont en effet avantageusement explicitées dans le bytecode précompilé.
Cette étape E23 est suivie par une étape E24 au cours de laquelle on recherche les objets écran contenus dans ces variables.
Dans l'exemple décrit ici, les arguments objet écran sont respectivement screenl, screen2 et screen3 pour les instructions 115, 116 et 117 d'appel à la méthode d'association setCommandListener.
Cette étape E24 est suivie par une étape E25 au cours de laquelle on identifie les représentants d'écran définis pour l'instanciation des objets d'écran identifiés à l'étape précédente E24.
Ces représentants d'écran sont respectivement II, 12 et 13 pour les arguments objet écran screenl, screen2 et screen3.
Cette étape E25 est suivie par une étape E26 au cours de laquelle on identifie les variables déclarées dans l'application qui peuvent contenir un objet gestionnaire d'événement, ces variables étant explicites dans le bytecode. Cette étape E26 est suivie par une étape E27 au cours de laquelle on identifie les objets gestionnaires d'événement contenus dans ces variables.
Dans l'exemple décrit ici, ces objets gestionnaires d'événement sont respectivement CmdListenerl, CmdListener2 et CmdListenerl pour les instructions 115, 116 et 117.
L'étape E27 est suivie par une étape E28 au cours de laquelle on identifie les représentants de gestionnaires qui ont été définis par l'instanciation des objets gestionnaires d'événement identifiés à l'étape précédente E27. Ces représentants de gestionnaires sont respectivement 113 et
114 pour les arguments objets gestionnaires CmdListenerl et CmdListener2.
La boucle constituée par les étapes E22 à E28 s'arrête après le traitement des trois instructions d'appel à la méthode d'association. Cette boucle permet de mettre en œuvre une première phase
E30 qui va maintenant être décrite en référence à la figure 2. Cette première phase E30 est constituée par une boucle d'étapes E301 à E304.
Cette boucle est mise en œuvre pour chaque appel à la méthode d'association setCommandListener 115, 116, 117. Elle comporte une première étape E302 au cours de laquelle on identifie les représentants d'écran associés à cet appel.
Dans l'exemple décrit ici, pour les appels 115, 116 et 117 respectivement, les représentants d'écran identifiés à l'étape E302 sont respectivement II, 12 et 13. L'étape E302 est suivie par une étape E303 au cours de laquelle on identifie les représentants de gestionnaire d'événement associé à cet appel, à savoir dans cet exemple 113 pour 115 et 117 et 114 pour 116.
L'étape E303 est suivie par une étape E304 au cours de laquelle on associe chacun des représentants d'écran identifié à l'étape E302 à chacun des représentant de gestionnaire identifié à l'étape E303.
Dans cet exemple, on associe :
• II et 113 dans l'itération correspondant à 115 ;
• 12 et 114 dans l'itération correspondant à 116 ; et
• 13 et 113 dans l'itération correspondant à 117. Le "Tableaul" ci-dessous résume le résultat de la première phase E30.
Tableaul
La première phase E30 est suivie par une deuxième phase E40 qui va maintenant être décrite en référence à la figure 3.
Dans le mode préféré de réalisation décrit ici, cette deuxième phase E40 est constituée par une boucle E31 à E39 mise en œuvre pour chaque méthode de rappel CmdListenerl.commandAction et CmdListener2.commandAction.
Cette boucle comporte une première étape E32 au cours de laquelle on identifie tous les objets gestionnaires d'événement comportant cette méthode de rappel. Ainsi, dans l'exemple décrit ici, pour les méthodes de rappel CmdListenerl.commandAction et CmdListener2.commandAction, ces objets gestionnaires d'événement sont respectivement CmdListenerl et Cmdl_istener2.
L'étape E32 est suivie par une étape E33 au cours de laquelle on identifie les instructions où sont instanciés ces objets du gestionnaire d'événement.
Dans l'exemple décrit ici, ces instructions sont respectivement 113 et 114 pour les objets gestionnaires d'événement CmdListenerl et CmdListener2. Cette étape E33 est suivie par une étape E34 au cours de laquelle on identifie les représentants de gestionnaire définis pour l'instanciation de ces gestionnaires d'événement.
Dans cet exemple, les représentants sont respectivement les instructions 113 et 114. L'étape E34 est suivie par une étape E36 au cours de laquelle on identifie les instructions d'appel à la méthode de changement d'écran (setCurrent) qui peuvent intervenir lors de l'exécution de ces méthodes de rappel.
Dans l'exemple décrit ici, les instructions setCurrent pouvant intervenir lors de l'exécution de la méthode CmdListenerl.commandAction (respectivement CmdListener2.commandAction) sont les instructions 118, 121, 124 et 125 (respectivement 128 et 129).
Cette étape E36 est suivie par une étape E38 au cours de laquelle on détermine les objets écran qui peuvent être passés en argument dans chacun de ces appels à la méthode de changement d'écran setCurrent.
Dans cet exemple :
- pour l'appel de l'instruction 118, cet objet est screenl ;
- pour l'appel de la ligne 121 cet objet est screen3 ; - pour l'appel de la ligne 124, cet objet est screenl ;
- pour l'appel de la ligne 125, cet objet est screen2 ;
- pour l'appel de la ligne 128, cet objet est screen3 ;
- pour l'appel de la ligne 129, cet objet est screenl.
L'étape E38 est suivie par une étape E39 au cours de laquelle on identifie les représentants d'écran définis pour l'instanciation de cet objet d'écran. Comme précisé plusieurs fois ci-dessus, les représentants des écrans screenl, screen2 et screen3 sont respectivement les instructions II, 12 et 13.
Cette boucle E31 à E39 se termine lorsque chaque méthode de rappel a été traitée.
Le "Tableau2" résume le résultat de cette deuxième phase E40.
Tableau2
La deuxième phase E40 est suivie par une étape E50 au cours de laquelle on crée le graphe d'approximation des comportements de l'interface homme-machine de l'application.
Le graphe se déduit directement à partir des "Tableaul" et "Tableau2". Ce graphe est représenté à la figure 5.
Il comporte un certain nombre de nœuds Nl, N2, N3 illustrant chacun un représentant d'écran II, 12, 13.
Ce graphe comporte également des arcs reliant chacun un nœud dit "origine" à un nœud dit "destination" si et seulement si il existe un représentant de gestionnaire 113, 114, tel que :
- le représentant de gestionnaire a été identifié au cours de la première phase E30 pour le représentant d'écran illustré par le nœud origine, et
- le représentant d'écran illustré par le nœud destination a été identifié au cours de la deuxième phase E40 pour le représentant de gestionnaire. Ce graphe comporte par exemple un arc α ayant pour origine le nœud Nl illustrant le représentant d'écran II et pour destination le nœud N3 illustrant le représentant d'écran 13, car il existe un représentant gestionnaire 113 identifié au cours de la première phase E30 pour le représentant d'écran II (2eme colonne du "Tableaul") ; et le représentant d'écran 13 illustré par le nœud destination N3 a été identifié au cours de la deuxième phase E40 pour le représentant de gestionnaire 113 (4eme ligne du "Tableau2").
ANNEXE 1
import javax.microedition.midlet.*; import javax.microedition.lcdui.*;
public class Test2 extends MIDIet { static Form screenl = new Form("Ecran 1"),(I1) screen2 = new Form("Ecran 2"),(I2) screen3 = new Form("Aide");(I3) static Command exitCmd = new Command("Exit", Command.EXIT, 2);(I4) static Command okCmd = new Command("OK", Command.OK, 1);(I5) static Command helpCmd = new Command("Help", Command.OK, 1);(I6)
private String infolMsg = "Pressez OK pour passer a l'écran 2 ou Help"; private String info2Msg =" Choix : boucler, lire l'aide et sortir"; private String info3Msg = "L'aide. Pressez sur OK";
Display display;
public Test2() { display = Display.getDisplay(this); screenl. append(new StringItem("",infolMsg)); screen2.append(new StringItem("",info2Msg)); screen3.append(new StringItem("",info3Msg));
screenl. addCommand(okCmd);(I7) screen2.addCommand(okCmd);(I8) screen3.addCommand(okCmd);(I9)
screenl. addCommand(helpCmd);(I10) screen2.addCommand(helpCmd);(Ill)
screen2.addCommand(exitCmd);(I12)
CommandListener cmdListenerl = new CmdListenerl();(I13) CommandListener cmdListener2 = new CmdListener2();(I14) screenl.setCommandListener(cmdListenerl);(I15) screen2.setCommandListener(cmdListener2);(I16) screen3.setCommandListener(cmdListenerl);(I17)
public void startApp() { display.setCurrent(screenl);(I18) }
public void pauseApp() {}
public void destroyApp(boolean unconditional) {}
class CmdListenerl implements CommandListener { public void commandAction(Command crnd, Displayable d) { if (cmd == exitCmd)(I19) { destroyApp(true); notifyDestroyed(); } else if (cmd == helpCmd)(I20) display.setCurrent(screen3);(I21) else if ((cmd= =okCmd)(I22) && (d==screen3)(I23)) display.setCurrent(screeniχi24); else display.setCurrent(screen2);(I25) } } class CmdListener2 implements CommandListener { public void commandAction(Command cmd, Displayable d) { if (cmd == exitCmd)(I26) { destroyApp(true); notifyDestroyed(); } else if (cmd == helpCmd)(I27) display.setCurrent(screen3)(I28); else display.setCurrent(screenl)(I29); } } }

Claims

REVENDICATIONS
1. Procédé de création d'un graphe d'approximation des comportements de l'interface homme-machine d'une application, ladite application étant écrite dans un langage orienté objet à classes avec bytecode typé s'exécutant dans l'environnement d'exécution d'un terminal muni d'un dispositif d'affichage, ladite application manipulant des objets- écran (screenl, screen2, screen3) représentant le contenu à un instant donné du dispositif d'affichage, chaque objet-écran étant associé par une méthode d'association (setCommandListener) à un objet-gestionnaire- d'événement (cmdListenerl, cmdListener2) comportant une méthode de rappel (CmdListenerl. commandAction, CmdListener2.commandAction) définie pour la classe dudit objet-gestionnaire-d'événement et appelée directement par l'environnement d'exécution (MIDP), ledit procédé étant caractérisé en ce qu'il comprend :
- une étape (ElO) au cours de laquelle on définit au moins un représentant d'écrans (II, 12, 13) à chaque instruction de l'application dans laquelle un objet-écran (screenl, screen2, screen3) est instancié ;
- une étape (E20) au cours de laquelle on définit au moins un représentant de gestionnaires (113, 114) à chaque instruction de l'application dans laquelle un objet-gestionnaire-d'évènement (cmdListenerl, cmdListener2) est instancié ;
- une première phase (E30) au cours de laquelle on identifie, pour chaque représentant d'écrans (II, 12, 13), les représentants de gestionnaires (113, 114) qui ont été définis (E20) pour l'instanciation d'un objet-gestionnaire- d'évènement (cmdListenerl, cmdListener2) associé à un objet-écran (screenl, screen2, screen3) pour l'instanciation duquel ce représentant d'écrans (II, 12, 13) a été défini ;
- une deuxième phase (E40) au cours de laquelle on identifie, pour chaque groupe de représentants de gestionnaires (113, 114) qui ont été définis pour l'instanciation d'objets-gestionnaire-d'évènement (cmdListenerl, cmdListener2) comportant une même méthode de rappel (CmdListenerl.commandAction, CmdListener2.commandAction), les représentants d'écrans (II, 12, 13) qui ont été définis pour les objets-écran (screenl, screen2, screen3) qui sont mis en place (setCurrent) lors de l'exécution de cette méthode de rappel (CmdListenerl.commandAction, CmdL.istener2.commandAction), et
- une étape (E50) de création d'un graphe comprenant des nœuds (Nl, N2, N3) illustrant chacun un représentant d'écrans (II, 12, 13), et des arcs reliant chacun un nœud dit "origine" à un nœud dit "destination" si et seulement si il existe un représentant de gestionnaires (113, 114) tel que : - ce représentant de gestionnaires (113, 114) a été identifié au cours de ladite première phase (E30) pour le représentant d'écran (II, 12, 13) illustré par ledit nœud "origine" ; et - le représentant d'écran (II, 12, 13) illustré par le nœud
"destination" a été identifié au cours de ladite deuxième phase pour ce représentant de gestionnaires (113, 114).
2. Procédé selon la revendication 1, caractérisé en ce que, pour pouvoir mettre en œuvre ladite première phase (E30), on détermine (E21) les instructions de l'application où il est fait appel à ladite méthode d'association (setCommandListener), et on détermine pour chaque appel à cette méthode :
- les représentants d'écrans (II, 12, 13) qui ont été définis pour Pinstanciation des objets-écran (screenl, screen2, screen3) qui peuvent être passés en argument dans cet appel (E24, E25) ; et
- les représentants de gestionnaires (113, 114) qui ont été définis pour l'instanciation des objets-gestionnaire-d'évènement (113, 114) qui peuvent être passés en argument dans cet appel (E27, E28).
3. Procédé selon la revendication 1, caractérisé en ce que, au cours de ladite deuxième phase (E40), on détermine au préalable (E31) pour chaque méthode de rappel (CmdListenerl.commandAction, Cmdl_istener2.commandAction) : - (E32, E33) les instructions de l'application où est instancié un objet- gestionnaire-d'évènement (cmdListenerl, cmdl_istener2) comportant cette méthode de rappel (CmdListenerl.commandAction,
CmdListener2.commandAction) ;
- (E34) les représentants de gestionnaires (113, 114) qui ont été définis pour l'instanciation de ces objets-gestionnaire-d'évènement
(cmdListenerl, cmdListener2) ; - (E36) les appels à la méthode de changement d'écran (setCurrent) pouvant intervenir lors de l'exécution de cette méthode de rappel (CmdListenerl.commandAction, CmdListener2.commandAction); et
- (E38, E39) les représentants d'écrans (II, 12, 13) qui ont été définis pour l'instanciation des objets-écran qui peuvent être passés en argument dans chacun de ces appels à la méthode de changement d'écran (setCurrent).
4. Procédé selon la revendication 2, caractérisé en ce que l'on détermine (E26) au préalable, pour chaque représentant de gestionnaires (113, 114), les variables déclarées dans l'application pouvant contenir un objet-gestionnaire-d'événement (cmdListenerl, cmdl_istener2) pour l'instanciation duquel ce représentant de gestionnaires (113, 114), a été défini.
5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que l'on détermine (E23) au préalable, pour chaque représentant d'écrans (II, 12, 13), les variables déclarées dans l'application pouvant contenir un objet-écran (screenl, screen2, screen3) pour l'instanciation duquel ce représentant d'écrans (II, 12, 13) a été défini.
6. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de création de graphe selon l'une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par un ordinateur.
7. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de création de graphe selon l'une quelconque des revendications 1 à 5
8. Ordinateur caractérisé en ce qu'il comporte un support d'enregistrement selon la revendication 7.
EP06842060A 2005-11-30 2006-11-29 Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application Withdrawn EP1960870A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0512124 2005-11-30
PCT/FR2006/051249 WO2007063248A1 (fr) 2005-11-30 2006-11-29 Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application

Publications (1)

Publication Number Publication Date
EP1960870A1 true EP1960870A1 (fr) 2008-08-27

Family

ID=36716928

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06842060A Withdrawn EP1960870A1 (fr) 2005-11-30 2006-11-29 Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application

Country Status (3)

Country Link
US (1) US20090158252A1 (fr)
EP (1) EP1960870A1 (fr)
WO (1) WO2007063248A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11297075B2 (en) * 2019-07-03 2022-04-05 Microsoft Technology Licensing, Llc Determine suspicious user events using grouped activities

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2134059C (fr) * 1993-10-29 2009-01-13 Charles Simonyi Methode et systeme de generation de programmes informatiques
US6654951B1 (en) * 1998-12-14 2003-11-25 International Business Machines Corporation Removal of unreachable methods in object-oriented applications based on program interface analysis
US6587844B1 (en) * 2000-02-01 2003-07-01 At&T Corp. System and methods for optimizing networks of weighted unweighted directed graphs
US6665863B1 (en) * 2000-05-31 2003-12-16 Microsoft Corporation Data referencing within a database graph
US7003507B2 (en) * 2000-09-18 2006-02-21 International Business Machines Corporation Scalable propagation-based methods for call graph construction
US7174536B1 (en) * 2001-02-12 2007-02-06 Iowa State University Research Foundation, Inc. Integrated interactive software visualization environment
US7426716B2 (en) * 2003-07-11 2008-09-16 Board Of Regents, The University Of Texas System Recovery and representation of object interaction in an object oriented program
US7669193B1 (en) * 2003-09-25 2010-02-23 Lantronix, Inc. Program transformation using flow-sensitive type constraint analysis
US8108826B2 (en) * 2004-09-29 2012-01-31 Avaya Inc. Code-coverage guided prioritized test generation
US7962497B2 (en) * 2005-02-18 2011-06-14 Microsoft Corporation Relationship modeling

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007063248A1 *

Also Published As

Publication number Publication date
US20090158252A1 (en) 2009-06-18
WO2007063248A1 (fr) 2007-06-07

Similar Documents

Publication Publication Date Title
CA2091546C (fr) Utilisation d'un langage dont le typage porte sur le contenu des variables et permettant de manipuler des constructions complexes
EP0580509B1 (fr) Utilisation d'un langage à interprète embarqué pour la réalisation d'un outil interactif de définition d'interface utilisateurs
Komatineni et al. Pro Android 4
US8001519B2 (en) Model driven development including aspect integration tool
US20120005650A1 (en) Hardware specific code generation
FR2821193A1 (fr) Dispositif de conception d'interface d'utilisateur
FR2723221A1 (fr) Procede pour identifier les objets dans un systemed'exploitation reposant sur une interface utilisateur graphique sur un ordinateur
US20120110444A1 (en) Help Document Animated Visualization
EP1387261A1 (fr) Logiciel de generation de code d'application informatique et langage de description de logiciel
US20200301679A1 (en) System for creating mobile and web applications from a graphical workflow specification
EP0793171A1 (fr) Système de configuration de logiciels préconfigurés sur des systèmes ouverts en réseau dans un environnement distribué et procédé mis en oeuvre par un tel système
WO2010009996A1 (fr) Procede de compilation de programme informatique
FR2798204A1 (fr) Points d'interruption classes et methode de debogage des programmes informatiques
FR2826753A1 (fr) Procede et dispositif de traitement d'un document informatique dans un systeme informatique
FR2730327A1 (fr) Outil de generation et d'execution de commandes a interface graphique
US20070061780A1 (en) Enterprise resource planning system test framework
WO2006136565A1 (fr) Procede de traitement de donnees compatible avec un formalisme de modelisation d'objets
US5721929A (en) Method for extending a fourth generation programming language
FR2658933A1 (fr) Systeme de commande du deroulement de sequences de tests dans un appareil de traitement de l'information.
EP1960870A1 (fr) Procede de creation d'un graphe d'approximation des comportements de l'interface homme-machine d'une application
EP0631675B1 (fr) Utilisation d'un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee
FR3118815A1 (fr) Estimation de la progression de l'exécution d'une tâche logicielle
Goldman Smiley-an interactive tool for monitoring inter-module function calls
FR2976373A1 (fr) Procede de developpement d'un portail web, systeme de mise en oeuvre et produit programme d'ordinateur correspondant
Mikkonen et al. Towards a uniform web application platform for desktop computers and mobile devices

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080625

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ALVARADO, CUIHTLAUAC

Inventor name: CREGUT, PIERRE

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130601