FR2901378A1 - Determination de nombres d'appels de methode critique dans une application en langage objet - Google Patents

Abstract

Pour déterminer une borne supérieure des nombres d'appels d'une méthode critique d'une application en langage orienté objet entre deux interactions entre l'application et un utilisateur, l'application s'exécutant dans un environnement d'exécution appelant des méthodes de rappel en réponse à un évènement externe ou un évènement interne lié à un appel de méthode d'enregistrement d'action, un graphe d'appels est construit tel que chaque arc reliant une méthode appelante à une méthode appelée de l'application et ayant une méthode d'enregistrement d'action comme méthode appelée soit remplacé par un ensemble d'arcs reliant la méthode appelante à différentes méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action.La borne supérieure est déterminée comme la valeur maximale des nombres d'appels estimés de la méthode critique pour chaque méthode de rappel identifiée dans le graphe d'appels.

Description

terminal mobile et moins de messages de validation seront présentés à

l'utilisateur. En général, les applications sont développées par une société de service et l'opérateur de réseau doit valider et signer ces applications avant de les mettre à disposition des utilisateurs clients de l'opérateur. Par exemple, un utilisateur peut être désorienté par le nombre de messages de validation ou par le nombre d'opérations qu'il a déjà engagées, et peut accepter sans réfléchir une action de l'application utilisant une fonctionnalité critique du terminal mobile. L'utilisateur peut en outre retirer par mégarde une protection installée dans le terminal mobile, permettant alors l'exécution en boucle d'une fonctionnalité dangereuse. La validation a priori et la signature d'application contribuent ainsi à éliminer des applications potentiellement dangereuses en raison de ces aspects psychologiques. En outre, puisque la signature d'une application limite le nombre de messages de validation que verra l'utilisateur, l'opérateur s'engage donc à ce que l'application ne fasse aucune action à laquelle l'utilisateur n'aurait pas consenti s'il avait eu un message de validation. L'utilisateur ne protégeant que ses intérêts, l'opérateur peut néanmoins refuser une application qui porte atteinte à son réseau, par exemple une application déclenchant des tentatives de dénis de service.

Des systèmes de validation d'applications connus identifient seulement des appels aux méthodes critiques d'une application lors d'une phase de dévirtualisation (le mot "dévirtualisation" est défini ci-après), sans calculer les nombres d'appels

des méthodes sur toutes les exécutions possibles du pseudo-code de l'application. Par ailleurs, des outils de calcul du pire temps d'exécution WCET (initiales des mots anglais "Worst- Case Execution Time"), tels que les outils aiT de la société ABSINT, qui sont utilisés pour vérifier des propriétés en temps réel de systèmes embarqués, peuvent calculer le nombre d'appels de méthodes par exemple en considérant comme nul le temps d'exécution d'autres fonctions et en donnant arbitrairement une valeur unitaire pour l'appel de l'une des méthodes. Le nombre d'appels des méthodes est calculé pour le temps global d'exécution du pseudo-code d'une application, mais pas pour le temps d'exécution du pseudo-code entre deux interactions entre l'application et l'utilisateur. Par conséquent, bien que plusieurs messages courts puissent être envoyés au cours de l'exécution de l'application, celle-ci n'est pas considérée comme dangereuse puisque les envois de ces messages courts peuvent faire partie de transactions indépendantes dont chacune a pu être autorisée par l'utilisateur. Les systèmes de validation d'applications actuels ne garantissent aucun nombre maximal d'appels ou d'exécution d'une méthode critique entre deux interactions entre l'application et l'utilisateur, et assurent tout au plus une borne inférieure du nombre d'appel.

Pour remédier à ces inconvénients, l'invention propose un procédé pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s'exécutant dans

un environnement d'exécution appelant des méthodes de rappel de l'application en réponse soit à un évènement interne à l'environnement lié à un appel de méthode d'enregistrement d'action de l'environnement, soit à un évènement externe, ledit procédé comprenant une construction d'un graphe d'appels dont chaque arc relie une méthode appelante à une méthode appelée de l'application. Le procédé est caractérisé en ce qu'il comprend les étapes de : remplacer dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action, identifier dans le graphe d'appels des méthodes de rappel appelées en réponse à des évènements externes à l'environnement, estimer des nombres d'appels de la méthode critique identifiée dans le graphe d'appels respectivement pour les méthodes de rappel identifiées, et déterminer la borne supérieure des nombres d'appels estimés de la méthode critique.

L'invention prend avantageusement en compte toutes les méthodes de rappel qui réagissent indirectement à des évènements externes et qui sont appelées par l'environnement d'exécution. Un évènement externe est par exemple une action de l'utilisateur sur le terminal mobile, telle qu'une validation d'une opération, ou une réception de données par le terminal mobile. Un évènement interne est par exemple une temporisation (c'est-à-dire une exécution retardée d'une méthode appelée), ou le lancement d'un "thread".

En effet, entre deux interactions entre l'application et un utilisateur, des méthodes de rappel peuvent être déclenchées aussi bien en réponse à des appels de méthode d'enregistrement d'action qu'en réponse à des évènements externes. Par conséquent, tous les appels de méthodes critiques considérées comme potentiellement dangereuses sont prises en compte par le procédé selon l'invention. Grâce à l'invention, on détermine, pour une application à installer dans un terminal d'utilisateur, une borne supérieure des nombres d'appels de méthodes critiques considérées comme potentiellement dangereuses pendant un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application. Le procédé selon l'invention peut être effectué lors d'une phase de validation de l'application avant le téléchargement de celle-ci par des utilisateurs clients de l'opérateur mettant à disposition l'application, l'application étant par exemple une application Java (marque déposée) téléchargeable sur un terminal mobile. Ainsi, l'opérateur est incité à valider l'application en la signant numériquement lorsque la borne supérieure est inférieure ou égale à un seuil prédéterminé. Par ailleurs, la phase de validation réalisée suivant le procédé selon l'invention peut être directement introduite dans des règles de programmation établies par l'opérateur et imposées à des sociétés de service fournissant l'opérateur. L'invention a également pour objet un dispositif de traitement de données pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, l'application étant

écrite dans un langage orienté objet s'exécutant dans un environnement d'exécution appelant des méthodes de rappel de l'application en réponse soit à un évènement interne à l'environnement lié à un appel de méthode d'enregistrement d'action de l'environnement, soit à un évènement externe, ledit dispositif comprenant un moyen pour construire un graphe d'appels dont chaque arc relie une méthode appelante à une méthode appelée de l'application. Le dispositif est caractérisé en ce qu'il comprend : un moyen pour remplacer dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action, un moyen pour identifier dans le graphe d'appels des méthodes de rappel appelées en réponse à des évènements externes à l'environnement, un moyen pour estimer des nombres d'appels de la méthode critique identifiée dans le graphe d'appels respectivement pour les méthodes de rappel identifiées, et un moyen pour déterminer la borne supérieure des nombres d'appels estimés de la méthode critique. Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, ledit programme comprenant des instructions qui, lorsque le programme est exécuté sur ledit dispositif de traitement de données, réalisent les étapes selon le procédé de l'invention.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique d'une plate-forme Java gérant des appels d'une méthode critique d'une application ; - la figure 2 est un graphe d'appels reliant des méthodes d'une application ; - la figure 3 est un bloc-diagramme schématique d'un dispositif de traitement de données pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application selon l'invention ; et - la figure 4 est un algorithme d'un procédé de détermination d'une borne supérieure de nombres d'appels d'une méthode critique d'une application selon l'invention.

Dans la suite de la description, on se référera en tant que langage de programmation à un langage orienté objet, comme le langage de programmation Java, disposant d'un environnement d'exécution et graphique, tel que des bibliothèques pour profil de terminal mobile MIDP ("Mobile Information Device Profile" en anglais). Toutefois, l'invention est applicable à d'autres langages tels que le langage de programmation ". net" (marque déposée) et d'autres environnements d'exécution et graphiques reposant sur la description de l'interface homme-machine par des objets graphiques et des gestionnaires d'évènements, tels que la bibliothèque ("package" en anglais) Java

AWT (initiales des mots anglais "Abstract Window Toolkit"). Toutefois, l'environnement d'exécution et graphique peut être destiné à des terminaux autres que des terminaux mobiles, comme des ordinateurs personnels ou des terminaux de point de vente.

Préalablement, quelques termes et concepts utiles à la compréhension de l'invention sont définis ci-après.

Une plate-forme Java peut être installée dans un microcontrôleur doté d'un environnement d'exécution susceptible d'héberger des applications ayant été développées dans le langage de programmation Java en tant que langage source. En particulier, le microcontrôleur peut être celui d'un terminal mobile pour réseau de radiocommunications cellulaire et la plate-forme peut être une plate-forme J2ME (initiales des mots anglais "Java 2, Micro Edition"). En variante, le microcontrôleur peut être celui d'une carte à puce, par exemple une carte SIM ou USIM. Un programme écrit en Java n'est pas compilé en code natif, mais sous la forme d'un langage intermédiaire indépendant de la plate-forme, appelé pseudo-langage. Le pseudo-langage est composé d'instructions codées sur un octet appelées pseudo- codes ("bytecodes" en anglais). L'environnement d'exécution d'une plate-forme Java comprend alors un interpréteur constitué par une machine virtuelle et des bibliothèques de méthodes pour ces programmes mis en oeuvre dans les mémoires du microcontrôleur. La machine virtuelle interprète des programmes exécutables Java qui ont été compilés en le pseudolangage afin qu'un processeur du microcontrôleur exécute en code natif les programmes compilés.

En particulier, les pseudo-codes sont typés statiquement, c'est-à-dire la machine virtuelle vérifie avant l'exécution du programme si une exécution d'une partie du programme peut devenir incontrôlée et si l'ensemble des données manipulées respecte certaines règles de bonne formation. Par exemple, les données ne peuvent être utilisées comme code de l'application. Un programme Java comprend un ensemble de définitions de classes. Chaque classe peut être instanciée à l'exécution en des objets qui sont des structures dynamiques contenant des variables locales propres aux objets et des méthodes propres à la classe. Par ailleurs, les classes utilisent un mécanisme d'héritage, c'est-à-dire des classes descendantes acquièrent les propriétés de classes ascendantes. En particulier, des processus légers, appelés "threads" en anglais et ci-après, composés de flots d'instructions séquentielles de pseudo-codes, sont exécutables de façon concurrente simultanément. A chaque thread correspond une classe contenant une méthode de rappel qui est appelée à la création du thread. Pour lancer un thread, un objet de ladite classe est créé et placé en argument d'une méthode lançant l'exécution du thread.

L'environnement d'exécution selon l'invention comprend par exemple la bibliothèque MIDP spécialisée pour l'utilisation de la plate-forme J2ME sur des terminaux mobiles. La bibliothèque MIDP fournit des interfaces au terminal mobile telles qu'un gestionnaire de connexions au réseau de radiocommunications cellulaire, une interface

homme/machine et un accès permanent à un espace mémoire de données prédéterminé. L'environnement d'exécution peut être tout autre environnement d'exécution figé, afin qu'un programme n'utilise pas des possibilités d'extension de bibliothèques disponibles dans l'environnement d'exécution et que des résultats rendus par des techniques d'analyse statique soient exhaustifs, c'est-à-dire que toutes les exécutions possibles de l'application aient été analysées. En particulier, l'environnement d'exécution doit refuser tout chargement dynamique de nouvelles bibliothèques et tout accès à des mécanismes de réflexivité sur le pseudo-code de l'application permettant de construire dynamiquement des appels de méthodes. L'exécution d'une application utilisant la bibliothèque MIDP est commandée par un gestionnaire d'évènements inclus dans la plate-forme Java. Le gestionnaire d'évènements gère une file d'évènements externes ou internes à l'application. Le gestionnaire d'évènements active différentes parties du pseudo-code de l'application suivant les évènements survenus et respecte des règles de priorité entre les évènements survenus. Par ailleurs, le gestionnaire d'exécution commande l'arrêt de l'exécution de l'application. L'application est codée selon un modèle à évènements prédéterminés en réaction desquels des parties de code de l'application sont respectivement exécutées. A chaque affichage sur l'écran du terminal mobile est enregistrée dans l'environnement d'exécution une méthode de rappel gérant des évènements liés à l'affichage. Lorsque la méthode de rappel est exécutée, une nouvelle méthode de rappel

est appelée et enregistrée, commandant un nouvel affichage. En particulier, l'application commande un affichage sur l'écran du terminal mobile au moyen d'un objet-afficheur. Le contenu de l'affichage peut être associé à des objets spécialisés au moyen de méthodes particulières à l'objet-afficheur. Des objets spécialisés sont par exemples des commandes qui définissent des boutons logiciels affichés sur l'écran du terminal mobile et qui sont sélectionnées au moyen de touches du terminal mobile, déclenchant alors un évènement externe. D'autres objets spécialisés sont des objets d'écoute d'évènement contenant chacun une méthode de rappel qui est appelée à chaque évènement externe ou interne. Par exemple, lorsqu'un bouton logiciel affiché sur l'écran est sélectionné par l'utilisateur, une méthode de rappel incluse dans l'un des objets d'écoute d'évènement est appelée en ayant comme arguments l'objet-afficheur de l'affichage courant et la commande représentant le bouton générateur de l'évènement. La méthode de rappel contient des parties de codes à exécuter, par exemple relatives à des appels d'autres méthodes dont certaines peuvent être critiques, et un appel de méthode pour exécuter l'affichage suivant. Dans la suite de la description, une interaction entre l'utilisateur et l'application correspond à une action de l'utilisateur sur le terminal mobile, déclenchant un évènement externe, et l'intervalle de temps entre deux interactions correspond à un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application et pendant lequel une méthode critique peut être exécutée plusieurs fois.35

Comme montré à la figure 1, des appels d'une méthode critique MC qui commande un envoi de message court depuis un terminal mobile sont lancés suite à différents évènements survenus au cours du temps représenté par une flèche verticale dirigée vers le bas. La plate-forme Java PFJ pouvant être exécutée par le microcontrôleur dans le terminal mobile inclut un environnement d'exécution EE comprenant des bibliothèques MIDP, un gestionnaire d'évènement GE et différents processus légers, tels qu'un thread auxiliaire TA et un thread temporisé TT. Initialement, une application est lancée par l'utilisateur du terminal mobile. Suite à un évènement externe, tel que l'appui sur une touche du terminal mobile par l'utilisateur, l'environnement d'exécution EE appelle, à un instant tl, une méthode de rappel MR qui appelle la méthode critique MC à l'instant tl' ; la méthode critique MC est exécutée par la machine virtuelle de la plate-forme PFJ sous le contrôle du gestionnaire d'évènement GE. La méthode de rappel appelle ensuite à un instant t2 une méthode d'enregistrement d'action MEA de l'environnement d'exécution EE qui est une temporisation d'un thread qui sera donc exécuté, après un temps prédéterminé, à un instant t5. La méthode de rappel MR appelle en outre à un instant t3 une méthode de création MCTA d'un thread auxiliaire TA qui exécute automatiquement la méthode critique MC. A un instant t4, le gestionnaire d'évènement GE arrête l'exécution de la méthode de rappel MR pour traiter par exemple un nouvel évènement externe. A l'expiration du temps prédéterminé, l'environnement d'exécution appelle, à un instant t5,

un thread temporisé TT qui exécute automatiquement la méthode critique MC. La figure 1 illustre non seulement l'appel de la méthode critique MC à l'instant tl' pour commander l'envoi d'un message court selon l'exécution du pseudo-code par le gestionnaire d'évènement, mais aussi les envois de deux messages courts indirectement générés par l'évènement externe aux instants t3 et t5.

Ainsi, pendant un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application, par exemple entre les instants tl et t4, l'envoi de trois messages courts a été commandé. Dans cet exemple, la méthode de rappel MR appelée à l'instant tl déclenche deux évènements internes liés au thread auxiliaire et au thread temporisé pour envoyer deux autres messages courts. Par conséquent, une estimation des différents appels à des méthodes critiques requiert une analyse du code de l'application pour chaque segment d'exécution de celle-ci qui s'étend entre deux interactions successives entre l'utilisateur et l'application, en accord avec l'objectif de l'invention.

La figure 2 représente un graphe d'appels d'une partie de code d'une application telle que celle décrite précédemment en référence à la figure 1. Le graphe d'appels comprend des noeuds correspondant respectivement aux différentes méthodes relatives à l'application et des arcs reliant chacun une méthode appelante à une méthode appelée. Chaque arc peut être annoté par l'instruction d'appel dans le code de la méthode appelante utilisée pour appeler la méthode appelée.

Par exemple, la méthode de rappel MR est reliée directement à la méthode critique MC puisqu'elle appelle cette dernière. De même, la méthode de rappel MR est reliée directement à la méthode d'enregistrement d'action MEA et à la méthode de création de thread auxiliaire MCTA. La méthode d'enregistrement d'action MEA déclenchera par la suite un appel à une méthode de création de thread temporisé TT de manière indirecte par un mécanisme interne à l'environnement d'exécution. Par conséquent, il n'existe pas de lien dans le graphe d'appels entre la méthode d'enregistrement d'action MEA et la méthode de création de thread temporisé TT. En outre, la méthode de rappel MR peut être reliée à une première méthode appelée MAI qui appelle une deuxième méthode MA2. Eventuellement, la deuxième méthode appelée MA2 peut appeler la méthode de rappel MR, créant ainsi une boucle d'appels dans le graphe d'appels due à des appels récursifs de la méthode de rappel MR.

En référence à la figure 3, un dispositif de traitement de données DTD pour déterminer une borne supérieure du nombre d'appels d'une méthode critique d'une application entre deux interactions entre un utilisateur et l'application selon une réalisation préférée de l'invention comprend une unité centrale UC, un module de construction de graphe d'appels MGA, un module d'identification MI, un module d'évaluation ME et au moins un fichier de classes FC. Le dispositif de traitement de données DTD selon l'invention est un ordinateur du type ordinateur personnel, ou serveur, ou terminal, ou une combinaison de ces derniers.

Les fichiers de classe FC comprennent des informations définissant des classes de l'application à tester et sont mis à disposition de l'unité centrale UC et du module de construction de graphe d'appels MGA dans le dispositif DTD pour effectuer une analyse statique du code de l'application. L'analyse statique est un ensemble d'opérations pour obtenir des propriétés sur les exécutions possibles du code sans effectuer la moindre exécution réelle.

En particulier, une analyse statique peut être une "dévirtualisation" qui détermine pour chaque appel d'une méthode sur un objet les mises en oeuvre possibles de la méthode qui pourraient être utilisées lors de l'appel de la méthode. En d'autres termes, la dévirtualisation détermine les classes qui répondent au cours de l'exécution à un appel de méthode, c'est-à-dire les classes contenant une méthode susceptible de répondre à l'appel de méthode. Lors de l'exécution réelle du code, seulement l'une de ces classes sera activée en réponse à l'appel de méthode. Le module de construction de graphe d'appels MGA construit et mémorise un graphe d'appels GA relatif à l'application à tester, dont des parties peuvent être analogues au graphe simple montré à titre d'exemple à la figure 2. A partir du graphe d'appels GA, le module d'identification MI identifie au moins une méthode critique MC et des méthodes de rappel MR de l'application et le module d'évaluation ME détermine une borne sur le nombre d'appels de la méthode critique MC.

En référence à la figure 4, le procédé selon l'invention pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre

l'application et un utilisateur comprend des étapes El à E7 exécutées sous le contrôle de l'unité centrale UC dans le dispositif de traitement de données DTD et mises en oeuvre par des instructions d'un programme d'ordinateur enregistré sur un support d'enregistrement lisible par le dispositif de traitements de données. Initialement, l'application développée par une société de service est fournie à un opérateur de réseau de radiocommunications sous forme de fichiers de classe FC qui sont mémorisés dans le dispositif de traitement de données DTD pour valider l'application. A l'étape El, le module de construction de graphe d'appels MGA construit à partir des fichiers de classe FC un graphe d'appels GA relatif à l'application à valider. Chaque arc relie une méthode appelante à une méthode appelée et est annoté par une instruction d'appel de la méthode appelée. Le graphe d'appels GA est par exemple construit au moyen d'une opération de dévirtualisation, puisque des méthodes sont appelées indirectement à travers des objets dont la classe n'est pas nécessairement connue avant l'exécution. A l'étape E2, le module de construction de graphe d'appels MGA modifie le graphe d'appels en remplaçant chaque arc annoté par une instruction d'appel reliant une méthode appelante à une méthode d'enregistrement d'action MEA comme méthode appelée, par un ensemble d'arcs annotés par la même instruction d'appel reliant la méthode appelante aux différentes méthodes de rappel MR susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action MEA. L'intérêt de cette modification dans le graphe d'appels est d'y inclure toutes les méthodes de

rappel qui réagissent à des évènements internes et qui sont indirectement appelées par l'environnement d'exécution. En effet, comme illustré à la figure 1, une méthode d'enregistrement d'action MEA appelée peut activer une méthode intermédiaire lançant un thread temporisé dont la création est gérée par l'environnement d'exécution, et le thread temporisé peut exécuter une méthode de rappel appelant une méthode critique. La méthode source initialement reliée à la méthode d'enregistrement d'action MEA est alors reliée à la méthode de rappel qui est elle-même reliée à la méthode critique. A l'étape E3, le module d'identification MI identifie dans le graphe d'appels la méthode critique MC et des méthodes de rappel MR appelées en réponse à des évènements externes, tels qu'une sollicitation d'un bouton logiciel par l'utilisateur.

A l'étape E4, le module d'évaluation ME estime dans le graphe d'appels GA un nombre d'appels NA de la méthode critique identifiée MC pour chaque méthode de rappel identifiée MR selon une approximation sur les nombres d'appels de méthode décrite ci-après dans les étapes E41 à E44.

A l'étape E41, le module d'évaluation ME détermine des boucles d'appels dans le graphe d'appels GA, par exemple en utilisant "l'algorithme de Tarjan" (cf. l'article de R.E. Tarjan intitulé "Depth First Search and Linear Graph Algorithms", SIAM Journal on Computing 1(2), pages 146 à 160, 1972) pour le calcul des composantes fortement connexes d'un graphe. Le module d'évaluation ME annote par une étoile "*" toutes les méthodes du graphe d'appels faisant partie d'une boucle déterminée dans le graphe d'appels.

A l'étape E42, le module d'évaluation ME construit un graphe de flot de contrôle GFC pour chaque méthode appelante. Le "graphe de flot de contrôle" d'une méthode appelante est un graphe dont les noeuds représentent les instructions de la méthode appelante et les arcs représentent l'exécution fictive d'une instruction de destination immédiatement après une instruction de source, au cours d'une exécution de la méthode appelante. Le module d'évaluation ME détermine des boucles dans le graphe de flot de contrôle GFC de la méthode appelante. Puis le module d'évaluation ME annote par une étoile "*" toutes les instructions d'appels relatives à la méthode appelante et associées en tant qu'étiquettes aux arcs du graphe d'appels, qui appartiennent à une boucle du graphe de flot de contrôle de la méthode appelante. A l'étape E43, le module d'évaluation ME repère tous les chemins sans boucle dans le graphe d'appels GA. Pour chaque chemin reliant une méthode de rappel dite "source" à la méthode critique dite "cible", le chemin est pondéré par un coefficient égal à "1" si aucune méthode ou instruction appartenant au chemin n'est annotée par une étoile. Dans le cas contraire, le chemin est pondéré par un coefficient égal à "*", qui est une valeur fictive. A l'étape E44, pour chaque paire constituée d'une méthode de rappel identifiée MR et de la méthode critique MC, le module d'évaluation ME estime la somme des coefficients des chemins reliant la méthode de rappel à la méthode critique. En particulier, le module d'évaluation ME utilise l'approximation suivante : Vn, * + n = *, où n est un entier naturelcorrespondant à la somme partielle des coefficients des chemins. Dès qu'un chemin comporte

une étoile, le nombre d'appels de la méthode critique n'est plus borné ; le nombre d'appels est représenté par la valeur fictive "*", et l'estimation de la somme est alors interrompue. Chaque somme représente une estimation de la borne supérieure sur le nombre d'appels NA d'une méthode critique MC lors de l'exécution d'une méthode de rappel MR donnée.

A l'étape E5, le module d'évaluation ME compare tous les nombres d'appels estimés NA respectivement attribués aux méthodes de rappel identifiées et détermine une borne supérieure BS comme la valeur maximale des nombres d'appels estimés NA de la méthode critique MC.

Si l'un des nombres d'appels estimés a la valeur fictive "*", alors la borne supérieure est l'infini. A une étape optionnelle E6, le dispositif de traitement de données DTD invalide l'application si la borne supérieure BS excède un seuil prédéterminé SP. Le seuil prédéterminé SP peut être fixé par l'opérateur et vaut par exemple "3" pour une méthode critique relative à un envoi de message court. Dans ce cas, l'application est refusée et renvoyée à la société de service ayant développé l'application.

Si en revanche la borne supérieure BS est inférieure ou égale au seuil prédéterminé SP, le dispositif de traitement de données DTD peut valider l'application ; celle-ci peut alors être mise à disposition, par exemple dans un serveur, afin de pouvoir être téléchargée dans des terminaux mobiles d'utilisateurs clients de l'opérateur.

L'invention décrite ici concerne un procédé et un dispositif pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une

application. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un dispositif de traitement de données tel que le dispositif DTD. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur sur ou dans un support d'informations, adapté à mettre en oeuvre l'invention. 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 pour implémenter le procédé selon l'invention. 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 ou support d'enregistrement sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) 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é selon l'invention.

Claims (8)

REVENDICATIONS

1 - Procédé pour déterminer une borne supérieure (BS) de nombres d'appels d'une méthode critique (MC) d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s'exécutant dans un environnement d'exécution appelant des méthodes de rappel (MR) de l'application en réponse soit à un évènement interne à l'environnement lié à un appel de méthode d'enregistrement d'action (MEA) de l'environnement, soit à un évènement externe, ledit procédé comprenant une construction (El) d'un graphe d'appels (GA) dont chaque arc relie une méthode appelante à une méthode appelée de l'application, caractérisé en ce qu'il comprend les étapes de : remplacer (E2) dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action (MEA) comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel (MR) susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action (MEA), identifier (E3) dans le graphe d'appels (GA) des méthodes de rappel (MR) appelées en réponse à des évènements externes à l'environnement, estimer (E4) des nombres d'appels (NA) de la méthode critique identifiée (MC) dans le graphe d'appels (GA) respectivement pour les méthodes de rappel (MR) identifiées, et déterminer (E5) la borne supérieure (BS) des nombres d'appels estimés (NA) de la méthode critique.

2 - Procédé conforme à la revendication 1, comprenant en outre des étapes de : déterminer (E41) des boucles d' appels dans le graphe d'appels (GA), pour chaque méthode appelante, déterminer (E42) des boucles dans un graphe de flot de contrôle (GFC) contenant des instructions d'appel de la méthode appelante, pondérer (E43) des chemins reliant une méthode de rappel identifiée (MR) à la méthode critique (MC) dans le graphe d'appels (GA) respectivement par des coefficients en fonction des boucles déterminées dans le graphe d'appels et dans le graphe de flot de contrôle (GFC) de chaque méthode appelante, et pour chaque méthode de rappel identifiée, estimer (E44) le nombre d'appels (NA) de la méthode critique (MC) en calculant la somme des coefficients des chemins.

3 - Procédé conforme à la revendication 1 ou à la revendication 2, comprenant une invalidation de l'application si la borne supérieure (BS) excède un seuil prédéterminé (SP).

4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel l'environnement d'exécution du dispositif comprend des bibliothèques pour profil de terminal.

5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel l'application est téléchargeable dans un terminal.

6 - Dispositif de traitement de données pour déterminer une borne supérieure (BS) de nombres d'appels d'une méthode critique (MC) d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s'exécutant dans un environnement d'exécution appelant des méthodes de rappel (MR) de l'application en réponse soit à un évènement interne à l'environnement lié à un appel de méthode d'enregistrement d'action (MEA) de l'environnement, soit à un évènement externe, ledit dispositif comprenant un moyen (MGA) pour construire un graphe d'appels (GA) dont chaque arc relie une méthode appelante à une méthode appelée de l'application, caractérisé en ce qu'il comprend : un moyen (MGA) pour remplacer dans le graphe d'appels (GA) chaque arc ayant une méthode d'enregistrement d'action (MEA) comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel (MR) susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action (MEA), un moyen (MI) pour identifier dans le graphe d'appels (GA) des méthodes de rappel (MR) appelées en réponse à des évènements externes à l'environnement, un moyen (ME) pour estimer des nombres d'appels (NA) de la méthode critique identifiée (MC) dans le graphe d'appels (GA) respectivement pour les méthodes de rappel (MR) identifiées, et un moyen (ME) pour déterminer la borne supérieure (BS) des nombres d'appels estimés (NA) de la méthode critique.

7 - Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par un dispositif de traitements de données.35

8 - Support d'enregistrement lisible par un dispositif de traitement de données sur lequel est enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5.