FR 2868566 A1 20051007 FR 0403431 A 20040401 PROCEDE ET DISPOSITIF D'ENREGISTREMENT ET DE LECTURE DE FLOTS D'INVOCATIONS DE METHODES. La présente invention concerne un procédé et un dispositif d'enregistrement et de lecture de flots d'invocations de méthodes. La présente invention est, en particulier, relative à la vie, à la persistance des objets, librairies, composants et logiciels. Elle s'applique, en particulier, à l'enregistrement de suites chronologiques d'invocations de méthodes d'un objet en vue de rejouer ces suites, par exemple dans le domaine du test et du traitement d'images. La présente invention permet ainsi, par exemple, d'appliquer successivement les mêmes séquences de filtres successifs sur différentes images. Java (marque déposée) permet de développer des applications modulaires et réutilisables à base de composants dans des environnements distribués. Dans ce cadre, la possibilité de sauvegarder un graphe d'objets (états des objets, relations entre eux, etc..) sur un support volatile ou non est intéressante et importante. Cette fonction, appelée "sérialisation", permet de reconstituer ultérieurement le graphe des objets dans un état donné. Cette sérialisation, qui peut être qualifiée de statique, n'est pas suffisante dans de nombreux cas. On rappelle que la sérialisation statique consiste à sauvegarder l'état d'un système à un instant t. Elle ne donne pas d'indication sur les actions ayant menées à cet état. Ce type de sérialisation n'est pas suffisant dans les exemples suivants: - test: la sérialisation statique permet de sauvegarder l'état du système, mais ne permet pas de rejouer les traitements ayant conduit à un dysfonctionnement. - traitement d'image: il n'est pas possible de capturer les traitements appliqués à une image pendant une séance de travail pour les appliquer ultérieurement à une autre image; la sérialisation statique ne peut que sauver l'état du système; Une application est bien plus que les objets qui la composent. Les objets communiquent entre eux par le biais des méthodes qui s'appellent tout au long de l'exécution de l'application. Les procédures de test de logiciel en cours de programmation actuellement connues consistent à mettre des points d'arrêt en différents endroits du code source. Ces procédures ne permettent pas de rejouer l'ensemble des invocations de méthodes mises en oeuvre jusqu'au point d'arrêt, ce qui entraîne des tâtonnements successifs et empiriques nuisibles à la productivité du programmeur. La présente invention vise à remédier à ces inconvénients. À cet effet, la présente invention vise un procédé d'enregistrement d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - une étape de création et de sauvegarde d'un graphe d'au moins une invocation de méthode et - une étape de sauvegarde d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode. Grâce à ces dispositions, l'enregistrement conserve la séquence d'invocations de méthodes et peut être relu ou ré-exécuté sur le même objet ou sur un objet différent mais compatible. L'intérêt d'enregistrer l'historique des invocations et leur contexte est que la relecture (c'est-à-dire la ré-exécution) des invocations de méthodes de cet enregistrement permet de faire revivre les objets dans leur contexte, à tout moment ou de ré-appliquer les mêmes invocations de méthodes à des objets similaires aux objets sur lesquels étaient appliquées les invocations de méthodes enregistrées. Par exemple, dans le cas des boîtes noires des avions, la présente invention permet de connaître la totalité des interventions sur le système informatique de l'avion de chaque application pour laquelle la présente invention est mise en oeuvre. Il est ainsi possible de savoir ce qui s'est passé. De plus, la présente invention permet de procéder à l'enregistrement des invocations de méthodes sans demande spécifique de la part de chaque application. On peut alors certifier ce qui s'est passé jusqu'à une panne, par exemple, et permettre une amélioration de la programmation du système informatique. Selon des caractéristiques particulières, au cours de l'étape de sauvegarde d'informations de structure, les informations de structure du graphe comportent des informations de temporalité des invocations de méthode. Grâce à ces dispositions, l'enregistrement conserve la séquence d'invocations de méthodes de chaque objet dans le temps et rend compte de la vie de l'objet concerné. Selon des caractéristiques particulières, au cours de l'étape de sauvegarde d'informations de structure, les informations de structure du graphe comportent des informations d'édition et/ou ajout de branches dudit graphe. Grâce à ces dispositions, le graphe peut être modifié au cours de sauvegardes successives. Selon des caractéristiques particulières, au cours de l'étape de création et de sauvegarde de graphe, on sauvegarde, pour chaque enregistrement d'une invocation de méthode, au moins le nom de la méthode en question, le type et la valeur de ses paramètres, sa signature comportant une liste ordonnée des classes des paramètres de la méthode et une liste ordonnée des paramètres de la méthode. Dans le cadre d'une application objet, par exemple une application java (marque déposée), chaque objet, ou l'application elle-même, peut enregistrer des invocations de méthodes accompagnées de la valeur des paramètres de la méthode et de la durée écoulée depuis la création de l'enregistrement. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de positionnement d'un pointeur dans le graphe. Selon des caractéristiques particulières, au cours de l'étape de création et de sauvegarde de graphe, on insère au moins une invocation de méthode dans le graphe, à partir de la position dudit pointeur, sans effacement des invocations de méthode déjà enregistrées (mode "préservé"). Selon des caractéristiques particulières, au cours de l'étape de création et de sauvegarde de graphe, on remplace, dans le graphe, à partir de la position dudit pointeur, au moins une invocation de méthode déjà enregistrée par au moins une nouvelle invocation de méthode (mode "normal"). Selon un deuxième aspect, la présente invention vise un procédé de lecture d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte: - au moins une étape de lecture d'au moins une partie d'un graphe d'au moins une invocation de méthode et d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode et - une étape d'exécution de chaque invocation de méthode lue. Selon des caractéristiques particulières, au cours de l'étape de lecture, on lit des informations de structure du graphe comportant des informations de temporalité des 25 invocations de méthode. Selon des caractéristiques particulières, au cours de l'étape de lecture, on lit des informations de structure du graphe comportant des informations d'édition et/ou ajout de branches dudit graphe. Selon des caractéristiques particulières, au cours de l'étape de lecture, on lit, pour chaque enregistrement d'une invocation de méthode lu, au moins le nom de la méthode en question, le type et la valeur de ses paramètres, sa signature comportant une liste ordonnée des classes des paramètres de la méthode et une liste ordonnée des paramètres de la méthode. Selon des caractéristiques particulières, le procédé de lecture tel que succinctement exposé ci-dessus comporte une étape de sélection d'un mode de lecture entre un premier mode de lecture, dit "normal", dans lequel on lit seulement une partie des noeuds du graphe et un deuxième mode de lecture, dit "préservé", dans lequel on lit l'intégralité des noeuds du graphe. Selon un troisième aspect, la présente invention vise un procédé d'enregistrement et de lecture d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte: - au moins une étape de création et de sauvegarde d'un graphe d'au moins une invocation de méthode et d'informations de structure du graphe représentatif d'un enchaînement des dites invocations de méthode; - au moins une étape de lecture d'au moins une partie dudit graphe et d'informations de structure du graphe représentatif d'un enchaînement des dites invocations de méthode et, - une étape d'exécution de chaque invocation de méthode lue. Selon des caractéristiques particulières, au cours de chaque étape de création et de sauvegarde, les invocations de méthode sont effectuées sur au moins un premier objet et en ce que, au cours de l'étape d'exécution, les invocations de méthode sont effectuées sur au moins un deuxième objet différent ou non de chaque premier objet. Selon des caractéristiques particulières, chacun des procédés d'enregistrement (premier aspect) et d'enregistrement et de lecture (troisième aspect), comporte une étape de modification du graphe ou d'au moins un noeud. Selon un quatrième aspect, la présente invention vise un dispositif d'enregistrement d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - un moyen de création et de sauvegarde d'un graphe d'au moins une invocation 25 de méthode et - un moyen de sauvegarde d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode. Selon un cinquième aspect, la présente invention vise un dispositif de lecture d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - un moyen de lecture d'au moins une partie d'un graphe d'au moins une invocation de méthode et d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode et - un moyen d'exécution de chaque invocation de méthode lue. Les avantages, buts et caractéristiques des deuxième à cinquième aspects de la présente invention étant similaires à ceux du premier aspect, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite en regard des dessins annexés dans lesquels: - la figure 1 représente, schématiquement, le fonctionnement d'un mode de réalisation particulier d'un composant enregistreur de séquences d'invocations de méthodes conforme à la présente invention; - la figure 2 représente, schématiquement, une succession d'étapes mises en oeuvre dans un mode particulier de réalisation d'un procédé d'enregistrements d'objets conforme à la présente invention; - la figure 3 représente, schématiquement, une mise en oeuvre des procédés et dispositifs d'enregistrement et de lecture objets de la présente invention appliquée au traitement d'images à distance et - la figure 4 représente, schématiquement, un graphe et son parcours, en fonction du mode d'enregistrement et de lecture mis en oeuvre. Avant de décrire différents modes de réalisation de la présente invention, on donne, ci-après, les définitions suivantes: - "système" (en anglais "system") : il s'agit du système objet de la présente invention comportant un composant "enregistreur" et un composant "lecteur", ainsi que les enregistrements logiciels créés par le composant enregistreur et lu par le composant lecteur; - "objet" (en anglais "object") : un objet est un ensemble d'attributs et de méthodes représentant une entité logique instanciée en mémoire vive. La représentation de l'objet dépend du langage utilisé pour l'implémentation du système, par exemple en langages java, C++ (marque déposée), SmallTalk, est un objet, en langage C, c'est une structure; "méthode" (en anglais "method") : une méthode associée à un objet dont l'appel (ou invocation) peut être enregistré par le composant enregistreur du système avec ses paramètres. Suivant le langage informatique considéré, la méthode peut être une fonction, une procédure, une macro,... ; "sérialisation" (en anglais "serialisation" ou "serialization") : la sérialisation est la sauvegarde d'un objet présent en mémoire vive sur un support volatile ou non, sous une forme persistante; - "séquence d'invocations de méthodes" (en anglais "Method Invocation sequence") ou "session d'enregistrement" : c'est un graphe ordonné d'appels de méthode. Une séquence d'invocations de méthodes est une suite ordonnée d'enregistrements de noeuds d'invocation de méthode (voir ci- dessous) : dans sa forme la plus simple, ce graphe est une liste ordonnée; - "enregistreur" d'invocations de méthodes (en anglais "Method Invocation Recorder") : c'est le composant du système qui permet d'enregistrer effectivement des séquences d'invocations de méthodes. Il gère aussi la sérialisation de celles-ci; - "lecteur" d'invocations de méthodes (en anglais "Method Invocation Player") : c'est le composant du système qui permet de rejouer le contenu d'une séquence d'invocations de méthodes; - "noeud d'invocation de méthode" (en anglais "Method Invocation Node") : il contient une unité d'invocation de méthode (voir ci-dessous) ainsi que des données de gestion de la structure du graphe (notamment les liens vers le père et les enfants du noeud dans son graphe) et un code de temps relatif au début de l'enregistrement; le noeud d'invocation de méthode sert à la structuration du graphe et à la gestion des informations temporelles; - "unité d'invocation de méthode" (en anglais "Method Invocation Item") : c'est un enregistrement unitaire d'un appel de méthode de l'objet; - "mode" (en particulier mode d'enregistrement et de lecture) : c'est le mode d'enregistrement ou le mode de lecture d'une séquence d'invocations de méthodes; "options" (d'enregistreur ou de lecteur) : ce sont des variantes de lecture des noeuds d'invocation de méthodes d'une séquence d'invocations de méthodes. Les options prennent en compte le temps, etc; "tête" (de lecture du lecteur d'invocation de méthode et d'enregistrement de l'enregistreur d'invocation de méthode) : c'est le positionnement (par exemple par un pointeur) à partir duquel est effectué une lecture ou un enregistrement de noeuds d'invocation de méthodes d'une séquence d'invocations de méthodes: c'est la position à partir de laquelle un enregistrement ou une lecture de noeuds d'invocations de méthode s'effectue; "code de temps" (en anglais "time code" ou, en abrégé "TC") : le TC est la durée écoulée depuis le début d'une session d'enregistrement dans une séquence d'invocations de méthodes; "cassette d'invocation de méthodes" (en anglais "Method Invocation Cartridge") : c'est une liste ordonnée (dans le temps) de sessions nommées. Ainsi: - une cassette d'invocations de méthodes contient des séquences d'invocation de méthodes; - une séquence d'invocations de méthodes contient des noeuds d'invocation de méthodes; un noeud d'invocations de méthodes contient une unité d'invocation de méthode ainsi que des données de gestion de la structure du graphe (notamment les liens vers le père et les enfants du noeud dans son graphe) et un code de temps relatif au début de l'enregistrement. La figure 1 représente, schématiquement, le fonctionnement d'un mode de réalisation particulier de l'enregistreur de séquences d'invocations de méthodes. Ce composant enregistreur permet de manipuler et d'enregistrer des séquences d'invocations de méthodes. Une séquence d'invocations de méthodes est constituée d'un objet sérialisable, comportant une interface publique (une interface publique est l'ensemble des attributs et des méthodes utilisables de l'extérieur sur des objets d'une même classe) de manipulation, d'écriture et de lecture des noeuds d'invocation de méthode. Une séquence d'invocations de méthodes contient un graphe ordonné de noeuds d'invocation de méthode. La sérialisation de la séquence d'invocations de méthodes permet de sauvegarder les enregistrements de noeuds d'invocation de méthode sans langage intermédiaire. L'enregistreur d'invocation de méthode permet de: - créer un objet "séquence d'invocations de méthodes" en mémoire vive; - sauvegarder une séquence d'invocations de méthodes, en sérialisant l'objet "séquence d'invocations de méthodes" à un instant donné ; - charger une séquence d'invocations de méthodes en créant un objet "séquence d'invocations de méthodes" en mémoire à partir d'une sérialisation. On observe que cette fonction se retrouve aussi dans le composant lecteur d'invocation de méthode; - enregistrer un noeud d'invocation de méthode; L'enregistrement d'un noeud d'invocation de méthode comporte les étapes suivantes: - créer un objet "séquence d'invocations de méthodes" ou charger une "séquence d'invocations de méthodes", étape 100; - dans le cas ou l'objet "séquence d'invocations de méthodes" est créé, ajouter la date et heure universelle qui sert d'indicateur de début de session, étape 105: le code de temps absolu TCA (date et heure universelle) n'est enregistré qu'une fois au début de la session; - choisir le mode d'enregistrement, étape 110, parmi les suivants: mode d'enregistrement "normal" : dans ce cas, le comportement du composant enregistreur est similaire à celui d'un magnétophone audio numérique, c'est-à-dire que l'enregistrement se fait à l'emplacement de la tête. La tête est avancée d'une position. Les éventuels enregistrements qui se trouvaient à cette position sont effacés; 10. mode d'enregistrement "préservé" (en anglais "preserve") : l'enregistrement du nouveau noeud d'invocation de méthode ne provoque pas l'effacement du noeud qui se trouvaient éventuellement en cette position: l'enregistrement crée une nouvelle branche à l'emplacement de la tête. Le noeud initial n'est pas détruit. Ils resteront accessibles à la lecture via un mode particulier (voir plus loin le fonctionnement du composant lecteur) ; - positionner la tête (en cas de création d'un enregistrement, la tête est automatiquement positionnée en début d'enregistrement), étape 115: l'enregistreur d'invocation de méthode permet de revenir au début de la séquence, d'aller en fin de séquence ou de positionner la tête dans la séquence entre le premier et le dernier noeud d'invocation de méthode (il s'agit d'un positionnement de la tête sans lecture, seul le lecteur permettant la relecture des enregistrements. Il appartient donc à l'application d'utiliser le lecteur si elle désire rejouer les enregistrements et synchroniser ainsi l'état de l'objet et l'enregistrement dans le cas d'un déplacement de la tête.) ; - pour chaque enregistrement d'une invocation de méthode à effectuer, les informations sur cette invocation de méthode sont regroupées dans une unité d'invocation de méthode, étape 120, y compris: le nom de la méthode en question, le type et la valeur de ses paramètres ou arguments, la signature et, éventuellement, une référence à l'objet concerné par la méthode et d'autres informations utiles; les informations définissant une unité d'invocation de méthode sont: - sa signature: c'est ce qui permet de définir et donc différencier les méthodes au sein d'une classe. La signature est constituée de: o nom de la méthode, o liste ordonnée des classes des paramètres de la méthode; - une liste ordonnée des paramètres de la méthode; un objet (facultatif) sur lequel sera invoquée la méthode. Cet objet est utile dans le cas où chaque unité d'invocation de méthode pourrait avoir un objet cible propre; et, un commentaire textuel (facultatif). Les informations indispensables sont la signature et les paramètres. Il est à noter que la liste des paramètres et la liste des classes des paramètres seront vides dans le cas d'une méthode sans paramètres. - création d'un noeud d'invocation de méthode, étape 121; - intégration de l'unité d'invocation de méthode dans le noeud d'invocation de méthode, étape 122; - ajout des informations de structure du graphe au noeud d'invocation de méthode, étape 123; - ajout des informations temporelles au noeud d'invocation de méthode, étape 124; - le noeud d'invocation de méthode ainsi que la durée écoulée depuis le début de la session sont enregistrées, étape 125, sous forme de code de temps dans la séquence d'invocations de méthodes, en fonction du mode sélectionné ; ces indications temporelles (par exemple celles liées à l'enregistrement d'un noeud d'invocation de méthode) sont des codes de temps relatifs (TCR) qui sont obtenus par la formule TCR=TCA TCAC où TCAC est le code de temps absolu courant au moment de l'enregistrement; Au cours d'une étape 130, il est déterminé si l'enregistrement est achevé. Sinon, on retourne à l'étape 120. La fin de l'enregistrement est déterminée par le programme. Cette fin peut-être définie par l'utilisateur si l'application le permet ou suivant une règle quelconque dans le cas de systèmes automatisés. Par exemple un système peut enregistrer, sur une base quotidienne, tout ou partie des actions effectuées sur un objet. À la fin de l'enregistrement des noeuds d'invocation de méthode, au cours d'une étape 135, la séquence d'invocations de méthodes est sauvegardée. On observe qu'à cette étape, on est en cours de construction du graphe, le parcours de l'ensemble du graphe étant effectué par le lecteur de séquence d'invocations de méthodes (voir figure 2). La figure 2 représente, schématiquement, le fonctionnement d'un mode de réalisation particulier du lecteur de séquences d'invocations de méthodes. Ce composant lecteur permet de relire des séquences d'invocations de méthodes et d'exécuter de différentes manières le contenu des séquences d'invocations de méthodes déjà enregistrées. Après avoir chargé une séquence d'invocations de méthodes, étape 200, l'objet sur lequel on veut rejouer le contenu de la cassette est spécifié, au cours d'une étape 202. Cet objet peut être différent de l'objet qui est à l'origine de l'enregistrement de la séquence d'invocations de méthodes mais doit être compatible avec celui qui est à l'origine de l'enregistrement: il faut les mêmes méthodes et les mêmes types de paramètres (même signature). Au cours d'une étape 205, on choisit un mode de lecture, c'est-à-dire de ré- exécution, de la séquence d'invocations de méthodes, parmi - mode Normal : le comportement est similaire à celui d'un magnétophone audio numérique: les unités d'invocation de méthodes des noeuds d'invocation de méthodes sont exécutées dans l'ordre de leurs positions dans l'enregistrement jusqu'à la fin de l'enregistrement. Si la séquence d'invocations de méthodes a été enregistrée en mode preserve les noeuds d'invocation de méthode inutiles sont ignorés; - mode préservé : la lecture commence à l'emplacement de la tête. Les enregistrements des noeuds d'invocation de méthode sont exécutés dans l'ordre jusqu'à la fin. Si la cassette a été enregistrée en mode préservé , les noeuds d'invocation de méthode inutiles sont pris en compte et rejoués dans le bon ordre: - lors de l'enregistrement si le mode était preservé , quand la tête d'écriture revenait en arrière et recommençait à écrire, l'enregistreur au lieu d'effacer la branche se trouvant après la tête, en faisant la branche gauche du noeud du graphe courant et créait une branche droite qui devenait la branche principale; - à la lecture, si ce graphe est lu en mode normal, le parcours du graphe se fait exclusivement le long des sous arbres droits de chaque noeud du graphe; - en lecture en mode preserve , l'ensemble du graphe est parcouru en "parcours préfixe", c'est à dire que l'on part du sommet, pour chaque noeud du graphe, on parcourt successivement les sous-arbres de la gauche vers la droite. Le parcours d'un sous-arbre est terminé quand on atteint une feuille (noeud sans enfant). Ce mode permet de faire passer l'objet sur lequel est jouée la cassette par les mêmes états intermédiaires que l'objet à l'origine de l'enregistrement. Au cours d'une étape 210, la tête peut être positionnée (par défaut, elle est positionnée en début de séquence d'invocations de méthodes) : le lecteur permet de revenir au début, d'aller en fin ou de positionner la tête sur la cassette. Au cours d'une étape 215, on spécifie un type d'exécution temporelle parmi les suivants: - libre (valeur par défaut): le lecteur rejoue les séquences d'invocations de méthodes à la suite les unes des autres; - temporisé : le lecteur rejoue les séquences d'invocation de méthodes en tentant de respecter les codes de temps TC; Au cours d'une étape 220, la lecture de la séquence d'invocation de méthodes, appliquée à l'objet "compatible" sélectionnée au cours de l'étape 202 est déclenchée et effectuée. Au cours d'une étape 225, on détermine si la lecture est achevée. Sinon, on retourne à l'étape 220. Si oui, on arrête le fonctionne du lecteur, étape 230. Les modes de réalisation décrits en regard des figures 1 et 2 peuvent, en variante, fonctionner en "Multi pistes" : la séquence d'invocations de méthodes exposée ci-dessus ne permet d'enregistrer l'invocation des méthodes que d'un seul objet à la fois. En variante, on ajoute une propriété de piste à la séquence d'invocations de méthodes: une piste est associée à un objet, et elle contient l'enregistrement des invocations de méthodes de cet objet. La création de plusieurs pistes associées à des objets différents permet alors l'enregistrement contextuel et synchronisé des comportements des objets associés. Les fonctions manipulant la position de la tête sont alors étendues pour permettre un positionnement synchro, dans le temps, de l'ensemble des pistes. On observe qu'au moment de la lecture, on peut ne relire qu'une partie des pistes de l'enregistrement. On donne, ci-dessous, des exemples d'applications de la présente invention: - dans le cadre d'une session applicative, conservation de l'historique des traitements effectués qui permet d'annuler des traitements en revenant en arrière ou de les répéter (voir description de la figure 3) ; - dans le cadre d'une application distribuée, l'enregistrement en local de traitements à effectuer permet une exécution déportée, différée et/ou répétitive (voir description de la figure 3) ; - dans le cadre du test et de l'optimisation de code, l'enregistrement automatique en continu de la vie d'objets sélectionnés permet de nombreuses utilisations à posteriori, parmi lesquelles: analyser pas à pas le résultat d'exécution; exécuter sur un serveur différent pour comparaison en tenant compte ou 35 non des temps; créer des jeux de tests en changeant la valeur des paramètres des invocations enregistrées avant exécution; supprimer ou ajouter des invocations à des fins de simulation; simuler la charge en exécutant en parallèle la même séquence sur plusieurs objets; - dans le cadre de l'automatisation d'applications ou de traitements, l'enregistrement de lots de traitements à effectuer et leur exécution sur un ensemble d'objets à traiter permettent d'effectuer les mêmes services qu'un moteur de macro sans nécessiter pour cela un langage intermédiaire et un interpréteur; les appels aux lecteur et enregistreur peuvent être introduits automatiquement dans le pseudo code, dans le cadre de pré-traitement (preprocessing), à la compilation ou à l'exécution de l'application. La figure 3 représente, schématiquement, une mise en oeuvre des procédés et dispositifs d'enregistrement et de lecture objets de la présente invention. La partie "client" 300 illustrée en figure 3 comporte un moteur (ou bloc applicatif) 330. La partie client est, dans le mode de réalisation représenté en figure 3, est une applet (en français "appliquette") javaqui met en oeuvre une interface utilisateur 310 qui permet à l'utilisateur d'appliquer des filtres sur des images et de les annuler ou de les répéter et de rejouer les filtres appliqués en local (sur des images basses résolution) sur des images distantes de plus hautes résolutions. La partie client comporte un enregistreur 305, qui met en oeuvre le procédé objet de la présente invention. La partie client comporte aussi une bibliothèques 315 de fonctions ou méthodes de filtrage ou de traitement d'image. Sous le contrôle de l'utilisateur et sur appel du moteur 330 qui applique des méthodes de la bibliothèque 315 à une image 320 de basse résolution (par exemple 320 x 200 pixels en 256 couleurs), les invocations de méthodes du moteur 330 sont automatiquement enregistrées par l'enregistreur 305 pour former un enregistrement 325 d'une séquence d'invocations de méthodes comme exposé en regard de la figure 1. Puis, sous le contrôle de l'utilisateur, l'enregistrement 325 est transmis au serveur 350 qui comporte un lecteur 355 de lecture de séquences d'invocations de méthodes. Un moteur 375, similaire au moteur 330, met en oeuvre une bibliothèque 365 identique à la bibliothèque 315 et effectue les appels du lecteur 355. Le serveur 350 de retouche d'images numériques en ligne (avec OPI, acronyme de "Open Prepress Interface" : système permettant de travailler sur une image basse résolution et de répercuter les actions sur la version haute résolution de cette même image) répercute les actions ou invocations de méthodes définies par la séquence d'invocations de méthodes 325 transmise à partir du client, sur une image 370 haute définition (par exemple 3.200 x 2.000 pixels en 16 millions de couleurs) conservée ou chargée par le serveur. Ainsi, la mise en oeuvre de la présente invention permet de ne faire transiter que des séquences d'invocations de méthodes représentant des traitements d'image, séquences extrêmement légères en terme d'utilisation de bande-passante, par rapport à la bande passante qui serait nécessaire pour faire transiter des images haute ou très haute résolution. On observe, en figure 4, un graphe d'invocations de méthodes enregistrées successivement, en mode "préservé". Lors d'une lecture en mode normal, les noeuds du graphe (qui correspondent à des invocations de méthode) qui sont successivement lus sont 401, 405 et 407. Lors d'une lecture en mode "préservé", les noeuds du graphe qui sont successivement lus sont 401, 402, 403, 404, 405, 406 et 407. Dans un mode particulier de réalisation adapté à la programmation d'un logiciel, on insert à chaque demande d'invocation de méthode une demande enregistrement de noeud (on peut, à la compilation d'un code, en mode "débug" ou non, ajouter les appels correspondants à l'enregistreur). Ainsi, dans une étape de pré-processing, au code source, on ajoute à chaque morceau de code correspondant à une invocation de méthode, un appel de l'enregistreur. D'une manière générale, l'invention permet de conserver les transformations d'états dans une machine à états. Grâce à la présente invention, dans le cadre d'une application objet, par exemple une application java, chaque objet, ou l'application elle-même, peut enregistrer des invocations de méthodes accompagnées de la valeur des paramètres et de la durée écoulée depuis la création de l'enregistrement. L'utilisateur peut changer la position de la tête d'enregistrement et choisir d'enregistrer d'autres invocations, revenir en arrière, insérer des invocations, avec ou sans effacer des invocations précédemment présentes dans l'enregistrement logiciel. Il peut ainsi former un historique exhaustif, ou non, de la vie de l'objet, c'est-à-dire des invocations de méthodes. Une fois qu'un enregistrement d'une séquence d'invocation de méthodes est achevé, il est possible de le sauvegarder dans une bibliothèque logicielle. Du fait que cet enregistrement logiciel est très compact, par rapport aux objets invoqués, cet enregistrement logiciel peut être transmis au sein d'un système distribué. Le contenu de l'enregistrement logiciel peut être rejoué à volonté par le système sur lequel fonctionne l'application objet, par le composant logiciel appelé "composant lecteur". Plusieurs modes de lecture permettent de rejouer les appels ou invocations de méthodes de différentes manières, en tenant compte du temps, selon l'historique complet, ... L'enregistrement logiciel étant indépendant de l'objet à l'origine de l'enregistrement logiciel, il peut être rejoué sur des objets différents de l'objet à l'origine de l'enregistrement, moyennant une compatibilité entre les objets considérés. La sérialisation dynamique mise en oeuvre conformément à la présente invention permet d'enregistrer ces traitements et de les rejouer de différentes manières: o en pas à pas pour effectuer une correction d'erreur de code informatique sur l'application, o en changeant le contexte d'exécution (plate-forme, objet cible, etc.), o en modifiant le contenu de la séquence d'invocation de méthode ou des noeuds d'invocation de méthode pour tester différents comportements. Ainsi, grâce à la mise en oeuvre de la présente invention, plusieurs manipulations de flots d'invocations de méthodes peuvent être effectuées: le contenu d'une cassette d'invocations de méthodes peut être modifié en vue de son exécution. Cette modification peut porter sur les éléments suivants: - la cassette elle même par ajout, retrait de séquences d'invocation de méthode, la séquence d'invocation de méthode, par modification du graphe, c'est-à-dire ajout, retrait, déplacement de noeuds ou sous-arbres du graphe, - le noeud d'invocation de méthode, par exemple par la modification des données temporelles, - l'unité d'invocation de méthode, par modification de la méthode, par modification de la signature ou des paramètres de la méthode. Ces différentes modifications peuvent être réalisées par programmation ou édition du contenu d'une cassette. La manipulation de flots d'invocations de méthodes peut intervenir par exemple dans un environnement de test. Par exemple, des modifications automatiques du graphe peuvent: - détecter où se situe une erreur de programmation, par modifications successives du graphe et confinement des causes de l'erreur, - permettre d'augmenter la tolérance aux pannes. Un premier exemple concerne la modification de la séquence. Une séquence 35 d'invocations de méthodes SI est issue d'une première exécution de méthodes d'un objet A. On veut rejouer cette séquence sur un objet B tout en notifiant chaque exécution d'une méthode de la séquence à un objet C. La mise en oeuvre de la présente invention permet d'analyser la séquence Si et de générer une séquence S2 contenant outre les noeuds de la séquence S1, des noeuds de notification contenant l'appel à la méthode de notification de l'objet C. Un deuxième exemple concerne la modification du noeud. Dans cet exemple, on veut exécuter une séquence d'invocations de méthodes en accélérant ou en ralentissant certaines parties de cette séquence. La mise en oeuvre de la présente invention permet l'analyse puis la modification des données temporelles contenues dans les noeuds de la séquence. Un troisième exemple concerne la modification de la méthode. Dans cet exemple, une séquence d'invocation de méthodes Si est issue d'une première exécution de méthodes d'un objet A instance d'une classe Cl. Le source de la classe Cl est modifiée, puis recompilée pour donner une classe C2. Si on veut rejouer la séquence Si sur un objet B instance de la classe C2. Cela provoquera des erreurs si les signatures des méthodes de C2 sont différentes de celles de Cl. Sous certaines conditions, on définit alors une traduction de la séquence Si vers une séquence S2, adaptant les signatures des méthodes et les paramètres enregistrés dans la séquence Si pour rendre ces méthodes exécutables sur l'objet B. Un quatrième exemple concerne la modification de la méthode par modification des paramètres. Dans cet exemple, dans un environnement de test, on veut exécuter une séquence d'invocations de méthodes Si en faisant varier certains paramètres des méthodes enregistrées dans S1. Grâce à la mise en oeuvre de la présente invention, ceci peut être obtenu par l'analyse puis la modification des paramètres des méthodes contenues dans les noeuds de la séquence. On obtient ainsi un jeu de test constitué des séquence modifiées S2, S3,...,Sn. REVENDICATIONS 1 - Procédé d'enregistrement d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - une étape de création et de sauvegarde (110 à 122, 125) d'un graphe d'au moins une invocation de méthode et - une étape de sauvegarde d'informations de structure du graphe (123, 124) représentatives d'un enchaînement des dites invocations de méthode. 2 - Procédé d'enregistrement selon la revendication 1, caractérisé en ce que, au cours de l'étape de sauvegarde d'informations de structure (123, 124), les informations de structure du graphe comportent des informations de temporalité des invocations de méthode. 3 - Procédé d'enregistrement selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que, au cours de l'étape de sauvegarde d'informations de structure (123, 124), les informations de structure du graphe comportent des informations d'édition et/ou ajout de branches dudit graphe. 4 - Procédé d'enregistrement selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape de création et de sauvegarde de graphe (110 à 122, 125), on sauvegarde, pour chaque enregistrement d'une invocation de méthode, au moins le nom de la méthode en question, le type et la valeur de ses paramètres, sa signature comportant une liste ordonnée des classes des paramètres de la méthode et une liste ordonnée des paramètres de la méthode. - Procédé d'enregistrement selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte une étape de positionnement d'un pointeur (115) dans le graphe. 6 - Procédé d'enregistrement selon la revendication 5, caractérisé en ce que, au cours de l'étape de création et de sauvegarde de graphe (110 à 122, 125), on insère au moins une invocation de méthode dans le graphe, à partir de la position dudit pointeur, sans effacement des invocations de méthode déjà enregistrées (mode "préservé"). 7 - Procédé d'enregistrement selon l'une quelconque des revendications 5 ou 6, caractérisé en ce que, au cours de l'étape de création et de sauvegarde de graphe, on remplace, dans le graphe, à partir de la position dudit pointeur, au moins une invocation de méthode déjà enregistrée par au moins une nouvelle invocation de méthode (mode "normal"). 8 - Procédé d'enregistrement selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comporte: - au moins une étape de lecture (205 à 220) d'au moins une partie dudit graphe et d'informations de structure du graphe représentatif d'un enchaînement des dites invocations de méthode et - une étape d'exécution (225) des invocations de méthodes lues. 9 - Procédé d'enregistrement selon la revendication 8, caractérisé en ce que, au cours de l'étape d'exécution (225), les invocations de méthode sont effectuées sur au moins un objet différent ou non de chaque objet sur lequel les invocations de méthode ont agit au cours de chaque étape de création et de sauvegarde. - Procédé de lecture d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte: - au moins une étape de lecture (205 à 220) d'au moins une partie d'un graphe d'au moins une invocation de méthode et d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode et - une étape d'exécution (225) de chaque invocation de méthode lue. 11 - Procédé de lecture selon la revendication 10, caractérisé en ce que, au cours de l'étape de lecture (205 à 220), on lit des informations de structure du graphe comportant des informations de temporalité des invocations de méthode. 12 - Procédé de lecture selon l'une quelconque des revendications 10 ou 11, caractérisé en ce que, au cours de l'étape de lecture (205 à 220), on lit des informations de structure du graphe comportant des informations d'édition et/ou ajout de branches dudit graphe. 13 - Procédé de lecture selon l'une quelconque des revendications 10 à 12, caractérisé en ce que, au cours de l'étape de lecture (205 à 220), on lit, pour chaque enregistrement d'une invocation de méthode lu, au moins le nom de la méthode en question, le type et la valeur de ses paramètres, sa signature comportant une liste ordonnée des classes des paramètres de la méthode et une liste ordonnée des paramètres de la méthode. 14 - Procédé de lecture selon l'une quelconque des revendications 10 à 13, caractérisé en ce qu'il comporte une étape de sélection d'un mode de lecture (205) entre un premier mode de lecture, dit "normal", dans lequel on lit seulement une partie des noeuds du graphe et un deuxième mode de lecture, dit "préservé", dans lequel on lit l'intégralité des noeuds du graphe. - Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce qu'il comporte une étape de modification du graphe ou d'au moins un noeud. 16 - Dispositif d'enregistrement d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - un moyen de création et de sauvegarde d'un graphe d'au moins une invocation de méthode et - un moyen de sauvegarde d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode. 17 - Dispositif de lecture d'au moins un flot d'invocation d'au moins une méthode, caractérisé en ce qu'il comporte au moins: - un moyen de lecture d'au moins une partie d'un graphe d'au moins une invocation de méthode et d'informations de structure du graphe représentatives d'un enchaînement des dites invocations de méthode et - un moyen d'exécution de chaque invocation de méthode lue.