Brevet FR2821942A1 — publié le 20020913

PROCEDE ET SYSTEME DE SUIVI ET DE CONTROLE D'EXECUTION SIMULTANE D'UNE PLURALITE DE PROCESSUS DISTINCTS EXECUTES INDEPENDAMMENT SUR DES SYSTEMES INFORMATIOUES. La multiplication des échanges de données par des systèmes informatiques distincts, connectés en réseau par exemple, a connu un essor sans précédent, en raison de la mise en place du réseau Internet et de la création de sites d'accès à des informations, des services et/ou des produits disponibles dans le commerce, d'une part, et de l'augmentation, régulière, de la puissance de calcul allouée aux systèmes informatiques précités, d'autre part. Parallèlement, le développement de langages de haut niveau, tels que le langage JAVA a permis la mise à disposition du grand public d'applications spécifiques exécutées par exemple en mode interactif entre terminaux constitutifs des systèmes informatiques distincts précités, ces applications étant exécutées sous forme de processus distincts spécifiques. Alors que le problème de la sécurisation des transactions entre les processus précités a pu être résolu par des solutions satisfaisantes mettant en oeuvre des systèmes informatiques embarqués, tels que des cartes à microprocesseur, munis de moyens cryptographiques, permettant la mise en oeuvre de chiffrement/déchiffrement des données transmises ou reçues, la multiplication des processus distincts spécifiques précités pose en outre le problème de la fiabilité de l'exécution de ces processus, la notion de fiabilité précitée recouvrant, au moins partiellement, la notion de sécurisation des transactions mises en oeuvre entre les parties à ces transactions. A l'heure actuelle, les langages de haut niveau précités, tels que par exemple le langage JAVA, sont susceptibles de permettre la mise en oeuvre de protocoles de suivi et de contrôle d'exécution d'un processus donné exécuté par un système informatique donné, protocole plus communément désigné par protocole de débogage. L'exécution de ce type de protocole met en oeuvre des commandes adressées au processus objet de l'opération de suivi et de contrôle, des réponses adressées par ce même processus et des événements spécifiques à ce processus et permet d'engendrer une représentation abstraite de ce processus et de l'ensemble des tâches de ce dernier, tâches organisées en une hiérarchie de groupes de tâches. La mise en oeuvre de tels protocoles peut être réalisée, lorsque le processus est exécuté par l'intermédiaire d'un programme JAVA, ou correspondant à une sémantique proche du langage JAVA, à partir d'un outil logiciel de suivi et de contrôle de l'exécution, dit outil de débogage, client du protocole JDWP pour JAVA WIRE DEBUG PROTOCOL. Le protocole JDWP est spécifié par la société SUN MICROSYSTEMS. Les spécifications complètes du protocole JDWPO, sont notamment disponibles sur le site WEB http ://java. sun. com/j2se/1. 3/docs/guide/jpda/jdwp-spec. html. Un tel protocole peut être mis en oeuvre, d'une part, par toute machine virtuelle JAVA version 1.2 et 1.3 offrant un mode de débogage et, d'autre part, par tout outil de débogage conforme aux spécifications du protocole JDWP. L'utilisation d'un tel protocole permet, notamment, de séparer fortement l'outil de débogage proprement dit de sa machine cible, c'est à dire du processus exécuté objet du suivi et du contrôle d'exécution ou débogage. Cette forte séparation est rendue possible grâce aux caractéristiques intrinsèques de ce type de protocole selon lesquelles, d'une part, la seule connaissance du processus soumis au débogage dont dispose l'outil de débogage provent du protocole JDWP en tant que tel, l'outil de débogage n'ayant pas à accéder aux fichiers de code objet compilés de l'application exécutée selon le processus à déboguer alors que l'accès par l'outil de débogage aux fichiers du code source de l'application peut être effectué aux seules fins d'affichage de ses derniers en mode texte, en l'absence de toute interprétation, alors que, d'autre part, les commandes du protocole JDWP sont génériques et indépendantes de l'application à déboguer et utilisent notamment des identificateurs d'objets ou de classes numériques de tailles variables, ce qui permet bien entendu une mise en oeuvre adaptée à une grande variété de processus cibles à déboguer. Pour cette raison, chaque processus cible à déboguer, constitué par un serveur JDWPO sur lequel se connecte l'outil de débogage, ne doit pas nécessairement être constitué par une machine virtuelle JAVA mais doit simplement se comporter comme tel. La présente invention a pour objet, la mise en oeuvre d'un procédé et d'un système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts, accessibles par réseau. En particulier un autre objet de la présente invention est la mise en oeuvre d'un procédé et d'un système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés r indépendamment sur des systèmes informatiques distincts à partir d'un protocole de suivi et de contrôle d'exécution, dit protocole de débogage, autorisant une forte séparation de l'outil de débogage proprement dit de chacun des processus soumis au débogage simultané, protocole de débogage tel que le protocole JDWPO. Le système et le procédé de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts, objets de la présente invention, opèrent sur chacun de ces processus contenant un ensemble de tâches organisées en une hiérarchie de groupes de tâches. L'exécution de chacun de ces processus est suivie individuellement et contrôlée par l'intermédiaire d'un protocole de suivi et de contrôle d'exécution indépendant de chacun de ces processus, ce protocole permettant, à partir de commandes adressées à un processus, de réponses adressées par ce processus et d'événements spécifiques de ce processus, d'engendrer une représentation abstraite de ce processus. Ils sont remarquables en ce que ce système permet de et ce procédé consiste à, au moyen d'une liaison unique support du protocole de suivi et de contrôle d'exécution spécifique, engendrer au moins une commande de suivi et de contrôle d'exécution spécifique, conformément à ce protocole de suivi et de contrôle d'exécution spécifique, multiplexer, d'une part, l'ensemble des commandes engendrées conformément au protocole de contrôle et de suivi d'exécution spécifique vers chacun de ces processus, et, d'autre part, assurer la transmission des réponses et événements en provenance de chaque processus. L'ensemble r des commandes de suivi et de contrôle d'exécution, des réponses et des événements multiplexés constituant cette représentation abstraite est configurée par l'opération de multiplexage selon une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés, ce qui permet d'assurer le suivi et le contrôle d'exécution simultané de cette pluralité de processus sur cette liaison unique. Le procédé et le système objets de la présente invention trouvent application au suivi et au contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques, ces systèmes informatiques pouvant être accessibles en réseau. Ces systèmes peuvent être eux-mêmes distincts, et consister en un système embarqué, tel qu'une carte à microprocesseur. L'un au moins de ces processus distincts peut être mis en oeuvre grâce à une suite d'instructions séquentielles interprétées, communément désignées par script en langage anglo-saxon. Le procédé et le système objets de la présente invention seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels : - la figure la représente, à titre illustratif, un organigramme du procédé de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts, conformément à l'objet de l'invention ; - la figure Ib représente, à titre illustratif, un détail de mise en oeuvre de l'opération de multiplexage du r procédé objet de l'invention tel que représenté en figure la ; - la figure le représente, à titre illustratif, un exemple de constitution d'une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus distincts contrôlés ; - la figure 2a représente, à titre illustratif, un schéma synoptique de l'architecture du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques conforme à l'objet de la présente invention ; - la figure 2b représenté, à titre illustratif, un schéma fonctionnel d'un multiplexeur permettant la mise en oeuvre du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques, objet de l'invention, tel que représenté en figure 2a ; - la figure 2c représente, à tire illustratif, un diagramme d'état d'un cycle de vie d'un traitement mis en oeuvre dans le multiplexeur représenté en figure 2b ; - la figure 2d représente, à tire illustratif, un organigramme de la création et de l'exécution de tout traitement, par le module de gestion des traitements inclus dans le multiplexeur illustré en figure 2b ; - la figure 2e représente, à tire illustratif, un diagramme séquentiel d'échange de messages de commande, de messages de réponse entre le module 1 de suivi et de contrôle d'exécution et le module 2 de multiplexage, d'une part, et de messages de sous-commande, de messages de sous-réponse entre le module 2 de multiplexage et r--------------------------------------------------différents processus distincts Pl à P3 correspondant à la configuration de ces processus telle qu'illustrée en figure le, d'autre part ; - la figure 3a représente, à titre illustratif, un exemple de mise en oeuvre d'application du procédé et du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques dans le cas où les processus sont des processus de type GSM, serveur OTA ; - la figure 3b représente, à titre illustratif, un exemple de mise en oeuvre d'application du procédé et du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment lorsque l'un de ces processus est mis en oeuvre par une interprétation d'un langage séquentiel. Le procédé de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques sera maintenant décrit en liaison avec la figure la et les figures suivantes. D'une manière générale, on considère une pluralité de processus distincts chaque processus étant noté Pi, i désignant l'indice identifiant le processus et pouvant à priori être quelconque et compris entre 1 et n. On considère ainsi un ensemble de processus Pi contenant chacun un ensemble de tâches, ces tâches étant organisées en une hiérarchie de groupe de tâches. On considère ainsi la situation de départ ST dans laquelle les groupes de tâches pour tout processus Pi sont notés A [kil et B [k2l les tâches sont notées a [k3l et b [k4l r indépendamment du nombre de tâches et/ou de groupes de tâches considérés et des valeurs de ki, k2, k3 et k4. Les paramètres entre crochets correspondant à des identificateurs locaux particuliers, lesquels seront explicités ultérieurement dans la description. Dans cette situation de départ ST on considère la mise en oeuvre d'un protocole de suivi et de contrôle d'exécution, ce protocole permettant de contrôler chaque processus Pli l'exécution de chacun de ces processus étant suivie individuellement et contrôlée par l'intermédiaire du protocole précité. Le protocole de suivi et de contrôle d'exécution est indépendant de chacun des processus Pi et permet, à partir de commandes Ci adressées à un processus, le processus Pi, de réponses Ri adressées par ce processus à cette commande, ces réponses Ri, et enfin d'événements Ei spécifiques de ce processus, d'engendrer une représentation abstraite de ce processus et de l'ensemble des tâches de ce processus grâce aux réponses et événements précités. A l'étape de départ ST, le protocole est noté P {Ci, Ei, Ri} = P. D'une manière générale, on indique que le procédé, objet de la présente invention, consiste à mettre en oeuvre le protocole précité indépendamment pour chaque processus Pi distinct, et, grâce à cette indépendance et à la représentation abstraite de chacun des processus distincts Pi, d'obtenir un suivi et un contrôle d'exécution simultané de chacun des processus distincts précités. En référence à la figure la, le procédé, objet de la présente invention consiste alors, en une étape A, à engendrer au moins une commande Ci de suivi et de contrôle r d'exécution pour au moins l'un des processus distincts Pi, cette commande étant bien entendu engendrée conformément au protocole de suivi et de contrôle d'exécution choisi. Bien entendu, on comprend que l'étape A peut être réalisée ou répétée pour l'ensemble des processus Pi distincts afin d'assurer le suivi et le contrôle d'exécution simultané de la pluralité des processus distincts précités. L'étape A est alors suivie d'une étape B consistant à multiplexer l'ensemble des commandes Ci, des réponses Ri et des événements Ei engendrés conformément au protocole de contrôle et de suivi d'exécution P précédemment cité. L'opération de multiplexage précitée est notée MUX {Ci, Ri, Vil. L'opération de multiplexage réalisée à l'étape B permet, d'une part, après traitement, la retransmission de chaque commande de suivi et de contrôle d'exécution vers chacun des processus distincts Pi précités, et d'autre part, après traitement, la retransmission des réponses Ri et des événements Ei en provenance des processus Pi précédemment mentionnés vers le processus de suivi et de contrôle d'exécution, l'opération de multiplexage réalisant sensiblement une opération de traduction de l'adressage des commandes et des réponses et des événements, ainsi qu'il sera décrit ci-après. Selon un aspect particulièrement remarquable du procédé, objet de la présente invention, l'ensemble des commandes de suivi et de contrôle d'exécution, des réponses et des événements multiplexés constituant la représentation abstraite est configuré par l'opération de multiplexage selon une combinaison formant un processus r---------------------------------------------------------virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés. A l'étape B de la figure la, la représentation abstraite, selon la combinaison formant processus virtuel unique, est notée RA = UVP {Ci, Ri, Ei}. La notation précédente indique que le processus virtuel unique regroupe l'ensemble des tâches de chacun des processus contrôlés. Ce mode opératoire permet d'assurer le suivi et le contrôle d'exécution simultané de la pluralité des processus Pi précédemment cités, ainsi qu'il sera décrit de manière plus détaillée ultérieurement dans la description. Une description plus détaillée de l'opération de multiplexage B représentée en figure la sera maintenant donné en liaison avec la figure lb. Dans le but de construire par multiplexage la combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés, l'opération de multiplexage précitée peut consister avantageusement, en une étape, B1 à attribuer un identificateur local unique IDL = k [0, 2M[ à chaque élément constitutif d'un processus distinct, élément constitué par exemple par une tâche ou un groupe de tâches. L'opération d'attribution précitée est effectuée conformément au protocole de suivi et de contrôle d'exécution spécifique choisi, dans lequel à chaque tâche ou groupe de tâches est attribué un identificateur numérique unique, au niveau de chaque processus distinct Pi concerné. Ainsi chaque tâche ou groupe de tâches ou tout autre élément d'un processus distinct Pi est r-------------------------------identifié par l'identificateur local distinct qui lui est associé. Toutefois, un tel identificateur local ne permet pas, à lui seul, d'identifier le processus distinct Pi auquel la tâche ou le groupe de tâches précité appartient. Pour cette raison, l'étape Bl est suivie d'une étape B2, consistant à associer à chaque processus distinct contrôlé et au processus virtuel unique une référence de processus spécifique Pur1. Cette opération permet, outre la discrimination et l'identification de chaque processus distinct Pi, d'installer le processus virtuel unique en un processus spécifique différent des processus distincts Pi contrôlés, mais traité, du point de vue du multiplexage et du protocole de suivi et de conduite d'exécution, de manière semblable au traitement de suivi et le contrôle d'exécution de chaque processus distinct Pi par le protocole de suivi et de contrôle d'exécution spécifique choisi. Dans ce but, la référence de processus spécifique PRi peut être définie comme une valeur numérique prise dans un ensemble de valeurs numériques, représentatives de l'ensemble des valeurs de référence de processus spécifique. De manière plus particulière, l'une des valeurs de référence spécifique parmi cet ensemble des valeurs de référence de processus spécifique est réservée pour attribution comme référence de processus virtuel unique. A titre d'exemple non limitatif, la valeur de référence spécifique attribuée comme référence de processus virtuel unique peut être la valeur s=O, à chaque processus distinct contrôlé Pi étant réservé une valeur i 2 1, représentative de chaque processus distinct r contrôlé. Dans ces conditions, le couple formé par un identificateur local IDL = k et une valeur de référence spécifique, constituant une référence de processus spécifique, est représentatif de l'élément de la représentation abstraite du processus distinct contrôlé associé à cet identificateur local, pour i 1, respectivement d'un élément virtuel constitutif de la combinaison formant le processus virtuel unique, pour i=0=8. Ainsi, l'ensemble E des valeurs de référence de processus spécifique peut être défini comme E= [0, n]. Afin de permettre l'identification des couples précités conformément au protocole de suivi et de contrôle d'exécution spécifique retenu, dans lequel à toute tâche ou groupe de tâches est attribué un identificateur numérique unique, l'étape B2 précitée est suivie d'une étape B3 consistant à associer à tout couple formé par un identificateur local IDL = k et par une valeur de référence de processus spécifique un identificateur global distinct IDG. A titre d'exemple non limitatif, chaque identificateur global distinct peut être choisi dans un ensemble G de valeurs numériques spécifiques, défini par G = [0, 2P[ où P est un entier donné. Ainsi, l'ensemble des identificateurs globaux appartenant à l'ensemble G, et qui sont obtenus pour chaque groupe de tâches virtuel constituant la combinaison formant le processus virtuel unique, permet d'assurer l'opération de multiplexage par mise en correspondance entre identificateurs globaux et identificateurs locaux par processus distinct contrôlé. En ce qui concerne la mise en oeuvre de l'étape B3, on indique que, l'obtention d'une valeur numérique unique IDG représentative d'un couple (i, IDL) peut être mise en r oeuvre par calcul de valeurs croissantes dans l'ensemble G des valeurs retenues ou par appel d'une fonction de codage/décodage, laquelle, à un couple (i, IDL), fait correspondre une valeur numérique unique IDG. Le processus de multiplexage permettant la mise en oeuvre du procédé, objet de la présente invention, sera décrit de manière illustrative en liaison avec la figure le. Sur la figure le, on a représenté les différents processus Psi... Pi... Pn. Le processus Pl est réputé, suite à la réception de commandes Ci, transmettre des réponses Ri concernant le groupe de tâches A [14], B [16] comportant la tâche unique a [15] et le groupe de tâches B [16] consistant en un groupe de tâches C [17] lui-même formé les tâches b [18] et c [19]. Le processus Pi, pour i=2, suite à la réception de commandes Ci est réputé transmettre des réponses Ri relative à un groupe de tâches A [0] consistant une tâche unique al. Le processus Pn, pour n=3, suite à des commandes Cn est réputé transmettre des réponses relatives à un groupe de tâches A [10] formé par une tâche a [12] et une tâche b [13] et par un autre groupe de tâches B[ll] comprenant une tâche C [14] et un autre groupe de tâches C [15], lui-même formé par deuxtâchesd [16] ete [17]. Oncomprendbiensûrqu'outre les réponses Ri, l'un des processus distincts Pi ou autre peut également transmettre des événements, noté Ei, Ei ou En respectivement. A chaque groupe de tâches émanant d'un processus distinct contrôlé Pi est attribué un identificateur global r IDG, IDG=O, à IDG=5 dans l'exemple donné, cet identificateur global fédérateur et traducteur permettant d'établir la combinaison précédemment mentionnée dans la description, cette combinaison consistant en une pluralité d'objets virtuels, distincts des objets de représentation abstraite, et formant le processus virtuel unique regroupant l'ensemble des tâches et groupe de tâches de chacun des processus distincts contrôlés. Le mode opératoire séquentiel de l'opération de multiplexage permettant la mise en oeuvre d'une telle combinaison sera décrit ultérieurement dans la description. Une description plus détaillée d'un système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts conformes à l'objet de la présente invention sera maintenant donnée en liaison avec les figures 2a à 2d. D'une manière générale, on indique que le système, objet de la présente invention, sera décrit dans le cas où le protocole P de suivi et de contrôle d'exécution est un 0 protocole JDWP, afin de donner des éléments concrets de mise en oeuvre d'un tel système, et du procédé correspondant. Toutefois, on indique que tout protocole distinct du protocole JDWP peut être mis en oeuvre pour autant que les processus Pi se comportent comme des machines virtuelles répondant au critère d'indépendance stricte du protocole de suivi et de contrôle d'exécution et des processus distincts Pi mis en oeuvre simultanément. Outre le critère d'indépendance stricte précité, le protocole de suivi et de contrôle d'exécution indépendant de chacun des r processus Pi doit permettre la mise en oeuvre d'une représentation abstraite de chaque processus et de l'ensemble des tâches de chacun des processus P mentionnés. Dans ces conditions, ainsi que représenté en figure 2a, le système SY, objet de l'invention, comprend un module 1 de suivi et de contrôle d'exécution permettant la mise en oeuvre du protocole P de suivi et de contrôle d'exécution. Dans le cas de la mise en oeuvre d'un protocole JDWP le module 1 de suivi et de contrôle d'exécution est constitué par un outil de débogage unique et standard normalement disponible dans le commerce par exemple. En outre, le système SY, objet de l'invention comprend un module de multiplexage 2, lequel est interconnecté, d'une part, au module 1 de suivi et de contrôle d'exécution, et d'autre part, à chacun des processus distincts Pi. Les interconnexions précitées sont mises en oeuvre par l'intermédiaire d'une liaison unique, supportant la mise en oeuvre du protocole P de suivi et de contrôle d'exécution. En ce qui concerne l'implantation physique du module 1 de suivi et de contrôle d'exécution et du module 2 de multiplexage, on indique que l'implantation de ces derniers peut être quelconque pourvu que les liaisons entre le module 1 de suivi et de contrôle d'exécution et le module 2 de multiplexage, d'une part, et entre le module 2 de multiplexage et chacun des processus distincts Pi, d'autre part, soient constituées par des liaisons permettant l'application du protocole P de débogage, c'est r à dire dans l'exemple de mise en oeuvre présentement 1 décrit, du protocole JDWP D'une manière plus spécifique, on indique que le module 2 de multiplexage permet, d'une part, après traitement, la retransmission des commandes Ci engendrées par le module 1 de suivi et de contrôle d'exécution vers les processus distincts Pi, et d'autre part, après traitement, la retransmission des réponses Ri ainsi que des événements Ei engendrés et en provenance des processus distincts Pi. Dans ces conditions, la représentation abstraite RA est configurée par le module 2 de multiplexage selon une combinaison formant un processus virtuel unique, le processus UVP {Ci, Ri, Ei} précédemment mentionné dans la description et décrit en liaison avec la figure lc. Un tel agencement issu de la construction par multiplexage permet d'assurer le suivi et le contrôle d'exécution simultané par multiplexage de l'ensemble et de la pluralité des processus distincts Pi. On comprend ainsi, en référence à la figure le, que pour un ensemble de processus distincts Pi comportant au moins un groupe de tâches, la combinaison précitée comprend un groupe de tâches virtuel associé à chacun des processus distincts Pi par le module multiplexeur 2. Chaque groupe de tâches virtuel comprend la hiérarchie des groupes de tâches et des tâches du processus distinct correspondant, constituant la représentation abstraite RA selon le processus virtuel unique UVP {Ci, Ri, Ei}. Dans le cas plus particulier où le protocole P de suivi et de contrôle d'exécution est le protocole JDWP, r le module 1 de suivi et de contrôle d'exécution est configuré en mode client JDWP 0. Chaque système informatique distinct et le processus Pi distinct conduit par ce dernier, constitue alors une machine configurée en mode serveur JDWPO, laquelle peut être identifiée par un nom unnomdemachinearbitraireMNipar exemple. Dans ces conditions, le module 1 de suivi et de contrôle d'exécution configuré en mode client JDWP et chacune des machines configurées en mode serveur JDWP exécutant chaque processus distinct Pi, sont connectés au module de multiplexage 2 par un canal de communication quelconque, dont la seule contrainte est la transmission des commandes, des réponses et des événements selon le 0 protocole JDWP On comprend ainsi, que le système SY, objet e l'invention, permet à partir d'une pluralité de processus distincts Pi de constituer un processus virtuel unique dans lequel, chaque groupe de tâches et bien entendu chaque tâche, associés à chaque processus distinct Pi conserve son individualité et la spécificité de ses réponses, ce qui permet bien entendu d'assurer le suivi et le contrôle d'exécution simultané de l'ensemble des processus distincts Pi. Une description plus détaillée du module multiplexeur 2 dans un mode de mise en oeuvre spécifique non limitatif, sera maintenant donnée en liaison avec la figure 2b. D'une manière générale, on indique que le module 2 de multiplexage comprend au moins un module 20 de gestion r des commandes émises par le module 1 de suivi et de contrôle d'exécution, et un module 21 de gestion des événements transmis par les processus distincts Pi. Le module de gestion des événements 21 est précédé d'un module séparateur 23 permettant d'assurer la séparation des messages de sous-réponse respectivement de sous- événements, engendrés par chaque processus distinct Pi. D'une manière générale, on indique que la désignation de messages de sous-événements, respectivement de sous-réponses ou de sous-commandes, désigne des messages d'événements, de réponses respectivement de commandes conformes au protocole JDWP et transitant entre le module de multiplexage 2 et l'un des processus distincts Pi. De la même manière, on désigne par messages de commande respectivement messages de réponse ou encore messages d'événement, tout message conforme au protocole JDWP transitant entre le module de multiplexage 2 et le module 1 de suivi et de contrôle d'exécution. Dans le cadre de la mise en oeuvre du module de multiplexage 2, représenté en figure 2b, on indique que le module séparateur 23 des messages de sous-réponse/messages de sous-événement peut être constitué par un module classique, le protocole JDWP autorisant la discrimination des messages de réponse et des messages d'événement, c'est à dire des messages de sous-réponse et des messages de sous-événement conformément au système, objet de la présente invention, par simple discrimination d'une valeur de champ introduite dans les messages précités à cet effet. r Enfin, le module 2 de multiplexage comprend un module de gestion des traitements 22, lequel permet, sous le contrôle du module 20 de gestion des commandes, de créer un traitement pour chaque commande reçue. Chaque traitement créé permet, d'une part, d'envoyer des messages de sous-commande vers et de recevoir les messages de sousréponse correspondant à ces messages de sous-commande venant des processus distincts contrôlés, et, d'autre part, d'envoyer le message de réponse correspondant à la commande considérée vers le module 1 de suivi et de contrôle d'exécution. Le module 22 de gestion des traitements permet en outre, sous le contrôle du module 21 de gestion des événements, de créer un traitement pour chaque message de sous-événement reçu d'un des processus contrôlés distinct Pl. Ces derniers traitements permettent, d'une part, d'envoyer des messages de sous-commande vers et de recevoir les messages de sous-réponse correspondant à ces messages de sous-commande venant des processus distincts contrôlés Pi, et, d'autre part d'envoyer des messages d'événement vers le module 1 de suivi et de contrôle d'exécution. D'une manière générale, le module de gestion des traitements 22, lequel crée et exécute les traitements précités, comporte un module 220 de gestion du multiplexage des identificateurs, alors que le module de gestion des événements 21 permet de traiter simultanément une pluralité de sous-événements pour transmettre des sous-commandes aux processus distincts Pi. Le module de gestion des commandes 20 permet, au contraire, de traiter simultanément plusieurs commandes par l'intermédiaire du module de gestion du multiplexage des identificateurs 220 pour engendrer les sous-commandes destinées à chacun des processus distincts Pi. Le fonctionnement global du module 2 de multiplexage représenté en figure 2b, peut être résumé de la manière ci-après. Les messages de commande transmis par le module 1 de suivi et de contrôle d'exécution sont transmis au multiplexeur 2 et en particulier au module 20, de gestion des commandes, lequel, par l'intermédiaire du module 22 de gestion des traitements, engendre un traitement approprié en fonction du contenu du message de commande précité. Ce traitement, une fois exécuté, fournit un paquet JDWP constituant un message de réponse, lequel est bien entendu transmis au module 1 de suivi et de contrôle d'exécution. Au cours de son exécution, le traitement mis en oeuvre par le module 22 de gestion des traitements, est habilité à transmettre des messages de sous-commande, ces messages de sous-commande étant conformes au protocole JDWPO précédemment cité, à certains des processus Pi, ces messages de sous-commande étant bien entendu fonction du message de commande qui a déclenché la création du traitement. En outre, le traitement mis en oeuvre par le module 22 de gestion des traitements peut également recevoir un message de sous-réponse correspondant et continuer le calcul en fonction du contenu du message de sous-réponse précité. D'une manière plus spécifique, on indique que les messages de sous-événement désignent les paquets JDWP e provenant des processus distincts Pi mais qui ne constituent pas des messages de sous-réponse. On rappelle que la discrimination entre messages de sous-événement et r messages de sous-réponse est effectuée au niveau du module 23 séparateur sous-réponse/sous-événement. Sur discrimination d'un message de sous-événement, ce message est transmis au module 21 de gestion des événements, lequel engendre un traitement approprié en fonction du contenu du message de sous-événement précité. On rappelle également, que le traitement précité engendré par le module 21 de gestion des événements peut, si nécessaire, au cours de l'exécution de ces derniers, envoyer des messages de sous-commande à certains des processus distincts Pi, recevoir les messages de sous-réponse correspondants et continuer le calcul en fonction des contenus de ces derniers. Lorsque le traitement est terminé, traitement défini par le module de gestion des événements 21, le module 22 de gestion des traitements, qui a exécuté le traitement précité, fournit un paquet JDWP constitutif d'un message d'événement, lequel est transmis au module 1 de suivi et de contrôle d'exécution. Plusieurs traitements mis en oeuvre dans le module de multiplexage 2, peuvent être exécutés simultanément. En particulier, à un moment donné, plusieurs traitements peuvent être en attente d'un message de sous-réponse à un message de sous-commande envoyé précédemment. Le module 22 de gestion des traitements ordonnance alors l'exécution des différents traitements, gère l'envoi des souscommandes aux différents processus distincts Pi et la réception des sous-réponses correspondantes, ainsi que l'envoi des messages de réponse respectivement messages d'événement au module 1 de suivi et de contrôle d'exécution. r Une description plus détaillée de la mise en oeuvre d'un traitement au niveau du module de multiplexage 2 et en particulier du module 22 de gestion des traitements, sera maintenant donnée en liaison avec les figures 2c et 2d. D'une manière générale, on rappelle que la notion de traitement concerne, au niveau du module 22 de gestion des traitements, la mise en oeuvre des opérations permettant la construction de la représentation abstraite, configurée selon une combinaison formant un processus virtuel unique, composée d'autant de groupes de tâches que de processus contrôlés, conformément à l'objet de la présente invention. Cette notion de traitement est donc spécifique au procédé et au système, objets de la présente invention, chaque traitement T mettant en oeuvre une pluralité d'états, lesquels seront décrits en relation avec la figure 2c précitée. En référence à la figure précitée, on indique que chaque traitement T, suite à sa création sous contrôle soit par le module de gestion des commandes 20, soit par le module de gestion des événements 21, peut se trouver soit dans l'état disponible, soit dans l'état bloqué, soit dans l'état terminé. Ainsi que représenté sur la figure 2c précitée, les différents états de chaque traitement T peuvent avantageusement être gérés de la manière ci-après : - dans l'état disponible, le traitement T peut être exécuté, l'exécution étant représentée par la flèche en boucle fermée sur l'état disponible précité ; - dans l'état bloqué, le traitement T est en attente d'un message de sous-réponse consécutif à un r message de sous-commande. Dans l'état bloqué précité, il est alors possible d'extraire du traitement T un message de sous-commande et un numéro identificateur i de processus Pi, auquel le traitement T a envoyé le message de sous-commande précité ; - dans l'état terminé, le traitement T permet d'extraire un paquet JDWP, lequel constitue un message de réponse ou un message d'événement transmis au module 1 de suivi et de contrôle d'exécution. Une description plus détaillée du mode opératoire global du module 22 de gestion des traitements sera maintenant donnée en liaison avec la figure 2d. La figure 2d représente un organigramme de mise en oeuvre, donné à titre d'exemple non limitatif, de l'ordonnancement de l'exécution des traitements T. Bien entendu, d'autres modes de mise en oeuvre des traitements précités peuvent être envisagés, ou le cas échéant, être confiés au contrôle du système d'exploitation du module multiplexeur 2. Le mode de mise en oeuvre représenté en figure 2d illustre la gestion des traitements, lesquels sont susceptibles d'occuper chacun l'ensemble des états représentés en figure 2c et indique, pour l'ensemble des traitements, la transition d'un état à un autre état, lors de la réception d'une sous-réponse. Le mode opératoire représenté en figure 2d correspond au cas où pour l'un quelconque des processus distincts Pi soumis à un suivi et à un contrôle d'exécution simultané conforme au procédé, objet de la présente invention, ce suivi et ce contrôle d'exécution est générateur d'un message de sous-réponse du processus r distinct Pi considéré, ce message de sous réponse étant transmis au module multiplexeur 2, cette sous-réponse étant attendue par l'un des traitements T bloqué géré par le module 22 de gestion des traitements. Le traitement correspond, par exemple, à la transformation d'un message de commande en une succession de couples de messages de sous-commande et de sous-réponse pour constituer la représentation abstraite selon le processus virtuel unique. Dans ces conditions, le processus de gestion des traitements comprend au moins une étape 1000 de test de disponibilité d'un message de sous-réponse SR en provenance d'un processus distinct contrôlé Pi. Sur réponse positive à l'étape 1000 du test précité, une étape 1001 de test d'existence d'un traitement bloqué en attente de ce message de sous-réponse en provenance du processus distinct Pi considéré est prévue. La réponse négative à l'étape de test 1001 d'existence de traitement bloqué est suivie d'un retour à l'étape de test de disponibilité 1000, l'absence d'un tel traitement bloqué dénotant une erreur de ce processus, cette sous-réponse étant alors ignorée. La réponse positive à l'étape de test d'existence 1001 d'un traitement T bloqué, est suivie d'une étape 1002 de déblocage de ce traitement T bloqué et de communication de la sous-réponse SR à ce traitement. Suite à l'étape de déblocage 1002 ou sur réponse négative à l'étape de test de disponibilité d'une sous-réponse 1000, une étape 1003 de test de disponibilité d'un autre traitement T'est prévue. Au test 1003, le traitement est noté T', ce traitement pouvant être distinct ou non du traitement T. r----------------------------------------------------------. La réponse négative à l'étape de test 1003 de disponibilité d'un autre traitement T', est suivie d'un retour à l'étape de test 1000 de disponibilité d'une sousréponse, tous les traitements étant alors bloqués. La réponse positive à l'étape de test de disponibilité 1003 d'un autre traitement T', est suivie d'une étape d'exécution d'un pas de calcul de cet autre traitement, cette étape d'exécution étant notée 1004. Suite à l'étape d'exécution 1004, une étape 1005 de test d'existence d'un blocage de cet autre traitement T'est prévue. La réponse positive à l'étape 1005 de test de blocage du traitement T', résultant de la demande par ce traitement de l'émission d'une sous-commande SC'à un processus distinct Pi,, est suivie d'une étape 1006 d'envoi de cette sous-commande SC'à cet autre processus Pi.. La commande SC'et i', identificateur de Pi,, sont extraits du traitement T'en fonction des impératifs de ce dernier. Sur réponse négative au test 1005 d'existence d'un blocage du traitement T', une étape de test 1007 de fin de traitement relatif à cet autre traitement T'est prévue. La réponse positive à l'étape de test 1007 de fin de ce traitement T'est suivie d'une étape 1008 de transmission d'un message de réponse ou d'un message d'événement, extraits du traitement T', au module 1 de suivi et de contrôle d'exécution. La réponse négative à l'étape de test 1007 est suivie d'un retour à l'étape de test 1000 de disponibilité d'une sous-réponse en provenance d'un processus distinct contrôlé quelconque. Différents exemples représentatifs des traitements T créés pour répondre à un message de commande en r provenance du module 1 de suivi et de contrôle d'exécution seront maintenant donnés ci-après. Il existe globalement trois types de comportement possible : 1. Le contenu du message de commande est transformé puis envoyé en tant que message de sous-commande à un processus distinct Pi déterminé. Suite à la réception du message de sous-réponse correspondant, le contenu de ce message de sous-réponse est transformé et renvoyé en tant que message de réponse au message de commande initial, vers le module 1 de suivi et de contrôle d'exécution. Le traitement T est alors terminé. 2. Le contenu du message de commande est analysé et une réponse est construite directement par le traitement T et envoyée au module 1 de suivi et de contrôle d'exécution. 3. Le traitement T échange une séquence de messages de sous-commande/messages de sous-réponse avec les différents processus distincts Pi. Plusieurs messages de sous-commande peuvent éventuellement être envoyés au même processus Pi ou à des processus distincts différents. En fonction des messages de sous-réponse correspondants, le traitement T construit la réponse à la commande initiale. Ces trois types de comportement permettent de construire la représentation abstraite RA, configurée par l'opération de multiplexage selon la combinaison formant le processus virtuel unique composé des groupes de tâches correspondant à chaque processus contrôlé, chaque groupe de tâches contenant la hiérarchie de tâches du processus distinct correspondant. r----------------------------------------------------------. Dans le but d'illustrer chacun des trois comportements possibles, un exemple sera donné afin de montrer comment le module de multiplexage 2 transmet au module 1 de suivi et de contrôle d'exécution toutes les tâches de l'ensemble des processus distincts Pi sous la forme d'un processus virtuel unique, en relation avec la figure 2e. En particulier, on rappelle que, dans le cadre du p protocole JDWP, les tâches d'un processus désignées par threads en langage anglo-saxon, sont organisées en groupes de tâches désignés par thread groups. Chaque groupe de tâches contient un ensemble, éventuellement vide de groupe de tâches et un ensemble, éventuellement vide de tâches. La hiérarchie globale des tâches d'un processus Pi est alors définie par un ensemble de groupes de tâches racines. Chaque tâche contient en outre, des informations dynamiques associées à l'exécution de la tâche correspondante, ces informations dynamiques pouvant consister en une pile d'exécution et plus généralement en un état interne de l'exécution de la tâche. Le module 1 de suivi et de contrôle d'exécution peut alors accéder à cet état par l'intermédiaire de commandes JDWP spécifiques mises en oeuvre dans le cas du protocole JDWP Le module 1 de suivi et de contrôle d'exécution peut également contrôler l'exécution de chaque tâche, par exemple, suspendre cette exécution à l'aide d'autres commandes spécifiques. Pour accéder à la hiérarchie des tâches, le protocole de suivi et de contrôle d'exécution spécifique, JDWP utilise, notamment, les commandes suivantes : Cl : VirtualMachine. ToplevelThreadGroups : renvoie la liste des identificateurs des groupes de tâches racines i C2 : ThreadGroupReference. Children : envoie le contenu d'un groupe de tâches ; C3 : ThreadReference. Name et ThreadGroupReference. Name : renvoie le nom associé à une tâche ou à un groupe de tâches donné. Typiquement, le protocole d'exécution JDWP est utilisé pour lancer la commande Cl puis récursivement C2 pour connaître toute la hiérarchie des tâches et groupes de tâches et enfin, la commande C3. Disposant ainsi de l'identificateur, identificateur local, de toutes les tâches, le processus de suivi et de contrôle d'exécution JDWP peut alors utiliser des commandes spécifiques pour accéder à leur état d'exécution et contrôler cette exécution. Les réponses aux commandes précitées seront maintenant décrites ci-après : Commande Cl La commande Cl, en tant que telle, ne contient aucune donnée en dehors des codes qui dénotent le type de commande, code de classe 1, code de commande 5 dans ce cas. Le format de la réponse est donné par le tableau ciaprès : int groups (Number of thread groups that follow) Nombre de groupes qui suivent. (Repeated groups times) Répété groups fois threadGroupID group (A top level thread group) Groupes de tâches de premier niveau (racine) Dans le tableau précité,"threadGroupID"désigne un identificateur de groupe de tâches. Cet identificateur est un nombre entier qui permet de retrouver l'objet de type ThreadGroup associé au groupe de tâches. En effet, en langage JAVA@, le protocole JDWP étant relatif à ce langage, chaque groupe de tâches, respectivement chaque tâche, est représenté par un objet JAVA@, instance de la classe, java. lang. ThreadGroup, respectivement java. lang. Thread ou d'une sous-classe. Les identificateurs de groupe de tâches et de tâches sont donc pris dans le même espace que les identificateurs d'objets que le protocole de suivi et de contrôle d'exécution spécifique JDWP est susceptible de récupérer, par exemple en demandant la valeur d'une variable du processus distinct Pi soumis au suivi et au contrôle d'exécution. Commande C2 La commande C2 contient les informations suivantes : threadGroupID Group Identificateur de groupe de tâches (The thread group object ID). La réponse à cette commande C2, présente alors le format suivant : int ChildThread Nombre de tâches filles s (The number of child threads). Repeated childThreads times : threadID ChildThread Identification de tâche fille (A direct child thread ID). int Chai 1 groups Nombre de groupes de tâches fils (The number of child thread groups). Repeated childGroups times : threadGroup childGroup Identification de groupe de tâches ID fils (A direct child thread group ID). Cette réponse donne la liste des identificateurs de toutes les tâches contenues dans ce groupe de tâches, suivie de la liste de toutes les sous-tâches. Commande C3 La commande C3 comporte en fait 2 commandes distinctes, relatives à la référence du groupe de tâches respectivement à la référence de tâches. Pour la référence de groupe de tâches, le format de la commande est le suivant : threadGroupID group Identification de groupes de tâches (The thread group object ID). La réponse donne le nom du groupe de tâches sous la forme d'une chaîne de caractères selon le format : string groupName Nom du groupe de tâches (The thread group's name) En ce qui concerne la commande de référence de tâches, le contenu de la commande et de la réponse sont sensiblement identiques à ceux de la commande de référence de groupe de tâches, précédemment décrits. A partir des formats des commandes et des réponses précédemment décrits, le comportement du module 2 de multiplexage sur réception d'une de ces commandes transmise par le module 1 de suivi et de contrôle d'exécution, sera maintenant décrit. En d'autres termes, un traitement T, associé à chacune des commandes précitées sera maintenant explicité. On indique en premier lieu que les traitements T ont à leur disposition les fonctions de codage et de décodage des identificateurs. D'une manière générale, les traitement T reçoivent des identificateurs locaux engendrés par les processus distincts Pi, ces identificateurs conformes au protocole JDWP étant constitués par des nombres entiers. Les fonctions de codage permettent, à partir des identificateurs locaux et d'une référence spécifique allouée à chaque processus distinct Pi, de calculer des identificateurs globaux IDG conformes et compatibles au protocole de suivi et de contrôle d'exécution spécifique, JDWP. Réciproquement, les fonctions de décodage permettent, à partir d'identificateurs globaux IDG, de retrouver, d'une part, la référence du processus distinct, et, d'autre part, l'identificateur local à la représentation abstraite de ce dernier. Ces fonctions de codage/décodage sont notées respectivement : 'must (i, IDL), i représentant la référence spécifique de processus distinct, 'demuxt (IDG), t désignant l'un des types d'identificateurs prévus dans le protocole de suivi et de contrôle d'exécution spécifique tel que objectID. On rappelle en outre que la valeur arbitraire de référence spécifique de processus distinct i=e=0 est réservée à la désignation des objets virtuels engendrés par le procédé et le système objets de l'invention pour établir la combinaison formant le processus virtuel unique. Pour représenter les groupes de tâches virtuels associés à chaque processus distinct Pi, le module de multiplexage 2 commence par construire des identificateurs pour référencer les groupes de tâches qu'il a lui-même engendrés. A titre d'exemple non limitatif, on suppose que le module de multiplexage 2 utilise, pour chaque processus distinct contrôlé Pi, les identificateurs locaux IDL, variant de 1 à n, ce qui correspond aux identificateurs globaux IDG, selon la relation : VirtualThreadGroupi = mUXobjectID (E, i) = IDG Dans ces conditions, le module de multiplexage 2 1 peut répondre immédiatement à la commande Cl et la réponse 1 à cette commande est de la forme : groups n Nombre de groupes de tâches qui suivent (Number of thread groups that follow) groupl Virtual Groupe de tâches de premier niveau ThreadGroup, (racine) (A top level thread group) ... group, Virtual Groupe de tâches de premier niveau ThreadGroupn (racine) (A top level thread group) Par cette réponse, le module de multiplexage 2 indique ainsi que les groupes de tâches racines transmis au module 1 de suivi et de contrôle d'exécution, sont les groupes virtuels créés par le module de multiplexage 2, lui-même. Sur réception de la commande C2, contenant l'identificateur de groupe dans le champ group, le module de multiplexage 2 effectue alors le traitement suivant : - décodage de l'identificateur group, inclus dans la commande, à l'aide d'une fonction de démultiplexage ; - si ce décodage produit une erreur, c'est que l'identificateur est mal formé, c'est à dire qu'il n'a pas été précédemment renvoyé dans une réponse du module de multiplexage 2. La réponse à la commande est alors un code d'erreur et le traitement est terminé ; r --------------------------------------------------- - dans le cas contraire, la fonction de démultiplexage renvoie un numéro de processus distinct Pi, en l'occurrence l'indice i, et un identificateur local désigné par IDL=localGroup au processus distinct Pi considéré, selon la relation : demuXobjectID (group) = (i, localGroup) et qui désigne alors le groupe de tâches dans le processus distinct Pi précité. Il existe alors deux possibilités : - si le numéro de processus distinct i vaut la valeur arbitraire s, ainsi que mentionné précédemment dans la description, cela signifie en fait que le groupe de tâches auquel le module 1 de suivi et de contrôle d'exécution fait référence concerne l'un des groupes virtuels créés par le module 2 de multiplexage. L'identificateur local localGroup est alors un nombre j compris entre 1 et n. Les descendants de ce groupe virtuel sont en fait les racines de la hiérarchie des tâches du processus distinct Pj. Pour cette raison, le traitement T associé à la commande C2 transmet la souscommande Cl au processus distinct Pj d'identificateur j. Dans l'attente de la sous-réponse du processus distinct Pj, le module gestionnaire de traitement 22, peut bien entendu faire exécuter d'autres traitements créés pour traiter une autre commande ou un sous-événement en provenance d'un des processus j'distinct de j ou non. Sur réception de la sous-réponse envoyée par le processus Pj en réponse à la sous-commande Cl, le traitement de la commande initiale peut cependant continuer. Cette sousréponse est donnée selon le format suivant : groups m Nombre de groupes de tâches qui suivent groups m Nombre de groupes de tâches qui suivent (Number of thread groups that follow) group, localGrouPl Groupe de tâches de premier niveau (A top level thread group) group, localGroupm Groupe de tâches de premier niveau (A top level thread group) Dans cette sous-réponse, les m identificateurs localGroupl à localGroupm désignent les groupes de tâches racines du processus distinct Pj et sont naturellement des identificateurs locaux au processus précité. Pour construire la réponse à la commande initiale, la commande C2, il convient alors de transformer ces identificateurs locaux en identificateurs globaux par la fonction de multiplexage muXobjectID, cette réponse consistant à lister ces identificateurs comme les groupes descendants du groupe de tâches virtuel et à indiquer que ce groupe de tâches ne contient lui-même aucune tâche. Dans ces conditions, le traitement T construit la réponse au format suivant : childthreads 0 Nombre de tâches filles (The number of child threads). childcroups m Nombre de groupes de tâches fils (The number of child thread groups). childGroup1 muxobjectio Identificateur de groupe de tâches fils (j, localgroup1) (A direct child thread group ID). childGroupm muXobjectID Identificateur de groupe de tâches fils (j, localGroupm) (A direct child thread group ID). Si, au contraire, l'indice i du processus distinct Pi n'a pas pour valeur s, c'est à dire i W g = 0, le numéro précité correspond à un numéro de processus distinct réel compris entre 1 et n. Le module 1 de suivi et de contrôle d'exécution a donc désigné un groupe de tâches réel, appartenant au processus distinct Pi, d'identificateur i, et a demandé ses fils, groupes de tâches et tâches. Pour cette raison, le traitement du module de multiplexage 2, consiste alors à envoyer au processus distinct Pi une sous-commande de type C2 avec le paramètre localGroup puis à transformer la sous-réponse en remplaçant les identificateurs locaux par des identificateurs globaux, obtenus par la fonction de multiplexage précitée. Ainsi, sur réception d'une sous-réponse de la forme ci-après : childthreads m Nombre de tâches filles (The number of child threads). childThreadl LocalThreadl Identificateur de tâche fille (A direct child thread ID). childThreadm Local Threadm Identificateur de tâche fille (A direct child thread ID). childGroups p Nombre de groupes de tâches fils (The number of child thread groups). childGrouPl Local groups Identificateur de groupe de tâches fils (A direct child thread group ID). chUdGroupp LocaJGroupp Identificateur de groupe de tâches fils (A direct child thread group ID). r Le traitement T se termine en renvoyant au module 1 1 de suivi et de contrôle d'exécution la réponse 1 suivante : childThreads m Nombre de tâches filles (The number of child threads). childThread muxobjectID Identificateur de tâche fille (i, local Thread1) (A direct child thread ID). chjJdThreadm muxobjectID Identificateur de tâche fille (i, local Threadm) (A direct child thread ID). childGroups p Nombre de groupes de tâches fils (The number of child thread groups). childGrouPl mUXobjectID Identificateur de groupe de tâches fils (i, localGroupl) (A direct child thread group ID). ... childGroupp muxobjectiD Identificateur de groupe de tâches fils (i, localgroupp) (A direct child thread group ID). r ------------------------------------------------Enfin, le traitement de la commande C3 déclinée en référence de groupe de tâches ou en référence de tâches consiste, de façon similaire, à décoder l'identificateur donné en argument par la fonction de démultiplexage. Si cette fonction renvoie un numéro de processus distinct Pi, index j. différent de la valeur arbitraire e=0, le traitement T continue en envoyant, au processus distinct Pi précité, la même sous-commande en ayant remplacé l'identificateur global par l'identificateur local donné par la fonction de décodage des identificateurs, c'est à dire la fonction de démultiplexage, puis en renvoyant directement comme réponse la sous-réponse à cette sous- r commande qui contient en fait le nom demandé. Si au contraire la fonction de démultiplexage renvoie la valeur arbitraire e=0, et comme identificateur local un numéro de processus j, index du processus distinct Pj, le traitement renvoie directement un nom arbitraire associé au processus distinct Pj précité. Ce nom arbitraire peut avoir été indiqué en paramètre au module 2 de multiplexage lors de son lancement. Il peut s'agir des chaînes de caractères "Pj"par exemple. Le traitement complet des commandes Cl à C3 précitées spécifique au protocole JDWP a été donné en détail. En référence aux commandes précitées, on comprend qu'à l'aide des fonctions de multiplexage des identificateurs, le module de multiplexage 2 permet au module 1 de suivi et de contrôle d'exécution de gérer une liaison JDWPO unique, d'appréhender simultanément les n processus Pl avec i E [1, n] connectés au module de multiplexage 2 et en particulier de voir leur hiérarchie de tâches sous forme d'une hiérarchie unique formant un processus virtuel unique, composé d'autant de groupes de tâches que de processus contrôlés. En ce qui concerne le traitement de chaque commande JDWP ces traitements ne seront pas décrits en détail car les traitements réellement différents au niveau du module de multiplexage 2 sont en fait peu nombreux. Les indications générales ci-après seront toutefois indiquées : La plupart du temps, le contenu d'une commande entrant dans le module de multiplexage 2 contient des identificateurs qui, décodés, permettent d'identifier un r processus distinct Pi, d'indice i. La commande est alors simplement passée au processus distinct considéré en remplaçant les identificateurs globaux par leur identificateur local au niveau du processus Pi. La réponse est transformée de façon réciproque en remplaçant les identificateurs locaux par leur codage global. Les commandes relatives aux tâches et groupes de tâches subissent un traitement particulier spécifique destiné à mélanger les hiérarchies de tâches de chacun des processus distincts comme décrit en détail plus haut. Lorsque la commande concerne des éléments virtuels, créés de toute pièce par le module de multiplexage 2 lui-même comme, par exemple, les groupes de tâches virtuels décrits précédemment dans la description, un traitement spécifique local au module de multiplexage 2 est exécuté. A titre d'exemple, si l'on demande la classe d'un objet groupe de tâches virtuel, le module de multiplexage 2 répond directement"java. lang. ThreadGroup" sans passer par un processus distinct. Les commandes portant sur les références des classes JAVA@ réclament, de même que les tâches, un traitement particulier. En effet, plusieurs classes de même nom peuvent coexister dans des processus différents. Pour distinguer ces différentes versions d'une même classe, il est possible d'utiliser la notion de chargeur de classe, encore désigné"class loader"en langage anglosaxon. De même que les groupes de tâches servent à hiérarchiser les tâches, les"class loaders"servent à hiérarchiser les classes. En langage JAVA, chaque classe est associée à un"class loader"donné et deux classes associées à deux"class loader"différents sont toujours ,--------------------------------------------- : considérées comme différentes même si ces deux classes ont le même nom. De plus, chaque machine virtuelle JAVAS possède un"class loader"système distinct. Pour gérer toutes les classes de tous les processus distincts Pi, le module de multiplexage 2 peut alors procéder de la façon suivante : chaque classe d'un processus distinct Pi, d'indice i associé à un"class loader"différent du"class loader"système de i reste associé à ce"class loader", son identificateur local est simplement convenablement multiplexé avec les identificateurs des objets tels que les"class loaders"des autres processus distincts. En revanche, si une classe est associée au"class loader" système du processus distinct Pi, indice i, alors dans la représentation présentée au module 1 de suivi et de contrôle d'exécution, le module de multiplexage 2 l'associe à un"class loader"virtuel représentant le "class loader"système de ce processus considéré. Enfin, le"class loader"système du processus virtuel unique simulé par le module de multiplexage 2 lui-même est réservé aux classes des objets virtuels créés par le module de multiplexage 2 comme les groupes de tâches virtuels ou les"class loaders"virtuels. De cette manière, il n'existe pas de risque de mélange des classes portant le même nom mais provenant de processus distincts différents. Le cas échéant, le traitement de la commande JDWP 9 peut être plus complexe. C'est par exemple le cas, notamment, pour les commandes du protocole JDWP qui interrogent l'état global du système soumis au suivi et au contrôle d'exécution. A titre d'exemple, la commande VirtualMachine. AllClasses du protocole JDWP renvoie la r liste des identificateurs de toutes les classes couramment chargés dans le processus soumis au suivi et au contrôle d'exécution. Pour traiter une telle commande au niveau du module de multiplexage 2, on comprend que ce dernier doit envoyer cette commande à tous les processus distincts Pi connectés au module de multiplexage 2 puis concaténer toutes les sous-réponses pour former la réponse globale à la commande précitée. Un exemple spécifique de mise en oeuvre du procédé objet de la présente invention, grâce à un jeu d'instructions conformes au protocole JDWP sera maintenant donné en liaison avec la figure 2e, pour une configuration de processus distincts contrôlés Pi correspondant à l'exemple donné et décrit en liaison avec la figure lc, les commandes mises en oeuvre correspondant aux commandes Cl, C2, C3 précédemment décrites. En référence aux figures précitées, le module 1 de suivi et de contrôle d'exécution transmet, au module 2 de multiplexage, une commande Cl ayant pour objet le renvoi par le module 2 de multiplexage de la liste des identificateurs des groupes de tâches racines. On comprend en particulier qu'à partir des couples E = 0 et i = [1, 2, 3] le module 2 de multiplexage associe aux couples (s, l), (8, 2) et (s, 3) les valeurs d'identificateurs globaux IDG = [0, 1, 2] selon le tableau d'association TAB, de la figure 2e. Ce tableau d'association peut être établi par communication préalable au module 2 du paramètre i = [1, 2, 3] permettant d'identifier les processus distincts contrôlés Pi= [Pi, P2, P3]. r Le module 2 de multiplexage répond directement à la commande Cl par l'envoi d'une réponse RI contenant les identificateurs globaux IDG avec IDG EE [0, 1, 2] représentatifs, au moins partiellement, du processus virtuel unique constitué par les processus distincts contrôlés Pi, P2 et P3. L'ensemble des processus distincts contrôlés P1, P2 et P3 étant connu du module 1 de suivi et de contrôle d'exécution par les identificateurs globaux des groupes de tâches virtuels 0,1, 2, celui-ci procède alors à une exploration successive des groupes de tâches et des tâches constitutifs de chaque processus distinct contrôlé. Ainsi, successivement : Pour le processus Pl : IDG=0 Envoi d'une commande C3 au module 2 de multiplexage destinée à obtenir le renvoi du nom associé à un groupe de tâches ou à une tâche. La commande C3 est envoyée au module 2 de multiplexage avec la valeur de l'identificateur global, IDG=0 ; Le module 2 multiplexeur renvoie une réponse R3 à la commande C3 comportant le nom du processus distinct contrôlé"Pi"ou simplement la valeur de i=l, ces éléments étant calculés à partir de la table d'association TAB1. Dans l'hypothèse d'une exploration"largeur d'abord", d'autres commandes C3 et réponses R3, symbolisées sur la figure 2e par des points successifs peuvent être engendrées pour l'obtention du nom du processus distinct associé ou plus simplement de la valeur i=2, i=3 correspondante. r Le module 1 de suivi et de contrôle d'exécution procède ensuite à l'exploration des tâches et groupes de tâches du processus distinct contrôlé Pi par : Envoi d'une commande C2 au module 2 de multiplexage avec la valeur de l'identificateur global IDG=0. Le module 2 de multiplexage envoie au processus distinct contrôlé Pl, discriminé à partir de la table d'association TABU, une sous-commande SC1 correspondant à une commande Cl précédemment décrite. Le processus distinct contrôlé Pl envoie au module 2 de multiplexage une sous-réponse SR1 à cette sous-commande SC1 comprenant les identificateurs locaux IDL=14 et IDL=16 des groupes de tâches A [14] et B [16] du processus distinct contrôlé Pi de la figure le. Le module 2 multiplexeur calcule alors les identificateurs globaux IDG=[3, 4] correspondant aux couples i=l (1,14) et (1,16) selon la table d'association TAB2. Il transmet au module 1 de suivi et de contrôle d'exécution une réponse R2 comprenant les identificateurs globaux IDG= [3, 4] représentatifs de groupes de tâches A [14] et B [16] constitutifs du processus distinct contrôlé Pi. L'exploration des tâches des groupes de tâches peut être différée pour effectuer une exploration"largeur d'abord", le module 1 de suivi et de contrôle d'exécution passant à l'exploration des groupes de tâches et des tâches du processus distinct contrôlé P2. r Pour le processus P2 : IDG=l L'envoi d'une commande C3 pour l'obtention du nom du processus distinct P2 aété suppose exécutée, comme dans le cas du processus distinct Pi précédemment décrit. Envoi d'une commande C2 au module 2 de multiplexage, avec la valeur de l'identificateur global, IDG=1. Le module 2 de multiplexage envoie au processus distinct contrôlé P2, discriminé à partir de la table d'association TAB1, une sous-commande SC2 correspondant à une commande Cl précédemment décrite. Le processus distinct contrôlé P2 envoie au module 2 de multiplexage une sous-réponse SR2 à cette souscommande SC2 comprenant l'identificateur local IDL=0 du groupe de tâches A [0] du processus distinct contrôlé P2 de la figure le. Le module 2 multiplexeur calcule alors l'identificateur global IDG=5 correspondant pour i=2 au couple (2,0) selon la table d'association TABr. Il transmet au module 1 de suivi et de contrôle d'exécution une réponse R2 à la commande C2 comprenant l'identificateur global IDG=5, représentatif du groupe de tâches A [0] élément du processus distinct contrôlé P2. L'exploration"largeur d'abord"peut être poursuivie pour le processus distinct contrôlé P3 mais ne sera pas décrite pour ce dernier. Cette rupture d'exploration"largeur d'abord"est représentée par les traits pointillés. Pour assurer une exploration complète du processus distinct contrôlé P2, il est ensuite nécessaire d'effectuer une exploration en profondeur au moyen d'une commande C2. Le module 1 de suivi et de contrôle d'exécution transmet une commande C2 au module multiplexeur 2 avec l'identificateur global IDG=5. Le module 2 multiplexeur envoie au processus distinct contrôlé P2, discriminé à partir de la table d'association TABr une sous-commande SC2 correspondant à une commande C2 relative au groupe de tâches A[0] visant à obtenir l'identificateur de la ou des tâches filles de ce groupe de tâches et du ou des groupes de tâches fils de ce groupe de tâches. Le processus distinct contrôlé P2 renvoie à cette sous-commande SC2 une sous-réponse SR2 contenant le seul identificateur local IDL=1 de la tâche a [l], aucun groupe de tâches de hiérarchie inférieure au groupe A [0] n'existant. Le multiplexeur 2 calcule l'identificateur global IDG=6 pour le couple i=2 (2,1) selon la table d'association TABr+l'Il transmet au module 1 de suivi et de contrôle d'exécution le message de réponse R2 en réponse à la commande C2 comprenant l'identificateur global IDG=6 représentatif de la tâche a [1] du processus P2. Bien entendu, les différentes tables d'association TAB1, TAB2,..., TABr, TAB,,, sont calculées successivement et mémorisées dans une mémoire par exemple afin de conduire le suivi et le contrôle d'exécution de l'ensemble. Un exemple d'application du procédé et du système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment r sur des systèmes informatiques distincts sera maintenant donné en liaison avec la figure 3. Sur la figure 3 précitée, on a représenté à titre d'exemple non limitatif, une pluralité d'applications distinctes constitutives des processus distincts Pl, P2, P3 et P4, chaque application pouvant être, par l'intermédiaire d'un pilote de débogage, connectée en réseau par l'intermédiaire du réseau Internet par exemple, ce réseau assurant un simple support du protocole JDWP D'une manière plus spécifique, on indique que le processus Pl est par exemple constitué par un système embarqué tel qu'une carte, de type carte bancaire ou carte SIM, à laquelle est associé un lecteur de cartes et un pilote dit de débogage permettant de constituer une machine virtuelle JAVAS autorisant la mise en oeuvre du protocole JDWPO. Le processus P2 est mis enoeuvre par un terminal de téléphonie mobile GSM, lequel est relié au réseau Internet par l'intermédiaire d'un pilote de débogage de même nature que dans le cas du processus distinct Pi et permettant donc également la mise en oeuvre du protocole JDWP. A titre d'exemple non limitatif, on indique que le processus Pi et le processus P2 sont par exemple liés par une liaison ISO 7816, l'application et le processus Pl pouvant consister par exemple, en une application de paiement des unités téléphoniques consommées par le terminal GSM et en particulier par le processus P2 conduit par ce dernier. Le processus distinct P3 est un processus conduit par une station radio SMS reliée par liaison radio SMS au terminal GSM conduisant le processus distinct P2 précité. r La station SMS est elle-même reliée par le réseau Internet à un serveur de type OTA, pour serveur On The Air, ce serveur étant lui-même constitué par une machine virtuelle -JAVA@ reliée au réseau Internet, cette machine permettant 1 &commat; la mise en oeuvre du protocole JDWP. Le processus distinct P4 est un serveur de base de données constitué de même par une machine virtuelle JAVA ce serveur étant relié d'une part, au serveur OTA conduisant le processus distinct P3 et, d'autre part, au réseau Internet. Le système SY de suivi et de contrôle d'exécution simultané, objet de la présente invention, est lui-même interconnecté au réseau Internet afin de permettre la mise en oeuvre du procédé de suivi et de contrôle d'exécution simultané de l'ensemble des processus distincts Pi à P4 précédemment mentionnés. D'une manière plus spécifique, on indique que le module 1 de suivi et de contrôle d'exécution est relié au module 2 multiplexeur par l'intermédiaire d'une liaison unique permettant la conduite du protocole JDWP précédemment cité. Le module 2 multiplexeur est lui-même relié au réseau Internet par une liaison permettant bien entendu la mise en oeuvre du protocole JDWP vis-à-vis de tous les processus distincts. Ainsi, de manière non limitative, le module multiplexeur 2 peut être implanté dans n'importe quelle machine et le module 1 de suivi et de contrôle d'exécution et le module 2 multiplexeur constitutifs du système SY, conformes à l'objet de la présente invention, peuvent alors être implantés de manière délocalisée en un point quelconque du réseau Internet. Enfin, le procédé et le système objets de la présente invention apparaissent particulièrement bien adaptés au suivi et au contrôle d'exécution d'applications dans le cas où l'un des processus distincts contrôlés n'est pas constitué par une machine virtuelle JAVA@ mais simplement par un programme consistant en une suite d'instructions séquentielles interprétées, plus communément désignée par un"script"en langage anglosaxon. Un tel mode de mise en oeuvre sera maintenant décrit en référence à la figure 3b. De manière plus particulière ainsi qu'illustré pour le processus distinct contrôlé Pl de la figure 3b, on utilise assez communément, dans le contexte JAVA CARD@, un "script"pour engendrer des instructions de type APDU à destination de la carte à microprocesseur. Ces instructions sont transmises par un protocole spécifique ISO 7816 par exemple. Ces instructions de type APDU, le plus souvent sous forme de liste, sont envoyées en séquence à la carte mais peuvent comporter quelques structures de contrôle telles que boucles ou tests logiques par exemple. Le processus distinct P2 est mis en oeuvre grâce à l'interprétation du"script". En outre, un pilote de débogage permet d'assurer une liaison conforme au protocole de suivi et de contrôle d'exécution spécifique choisi, en l'occurrence le protocole JDWPO dans l'exemple de la figure 3b. Le pilote de débogage agit sur le processus d'interprétation sous le contrôle du protocole JDWP. 1 r Le procédé objet de la présente invention apparaît particulièrement avantageux dans la mesure où celui-ci permet decontrôler l'envoidesinstructions APDU et de suivre la progression de l'exécution par interprétation du "script" ; la seule condition réside dans le fait que la sémantique du langage du"script"est suffisamment simple et correspond sensiblement à un sous-ensemble de la sémantique du langage JAVA. Dans ce cas, la condition précitée étant satisfaite, le procédé objet de l'invention, pour tout processus distinct mis en oeuvre par une interprétation des instructions d'un langage séquentiel, est tel que la représentation abstraite virtuelle de ce processus comporte au moins une seule tâche, dans un seul groupe de tâches, cette tâche unique étant associée à la séquence d'instructions interprétées. Ainsi, l'exécution de cette interprétation est suivie et contrôlée par l'intermédiaire du protocole spécifique, JDWPO, à partir des commandes, des réponses et des événements relatifs à cette seule tâche. Lorsque, de manière plus particulière, le protocole spécifique choisi est le protocole JDWP la représentation abstraite virtuelle comprend, outre la seule tâche dans un seul groupe de tâches associé à la succession des instruction interprétées, une seule classe et une seule méthode dans cette classe. Dans les conditions précitées, l'ensemble des points de contrôle du"script"constitués par exemple par chaque ligne de ce dernier, peut être représentée par une ligne virtuelle, à laquelle un identificateur global IDG r est associé, dans l'unique méthode de l'unique classe de cette représentation virtuelle. Une adaptation convenable de l'interprète du "script"pour construire la représentation abstraite virtuelle précitée, au moyen de l'introduction d'identificateurs locaux IDL par exemple, permet de suivre et contrôler l'exécution par interprétation de ce dernier conformément au procédé objet de la présente invention, en particulier lorsque le protocole de suivi et de contrôle d'exécution choisi est le protocole JDWP Dans ces conditions, le procédé et le système objets de la présente invention permettent d'effectuer le suivi et le contrôle d'exécution simultané d'une pluralité de processus distincts et d'interprétations d'instructions de langages séquentiels tels que les"scripts". Ainsi et de manière particulièrement avantageuse, ils permettent d'assurer le suivi et le contrôle d'exécution simultané d'un"script"engendrant des instructions APDU et une application, encore appelée appliquette, JAVA CARDs à partir d'une seule interface de contrôle. r REVENDICATIONS 1. Système de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts, chacun de ces processus contenant un ensemble de tâches organisé en une hiérarchie de groupes de tâches, l'exécution de chacun desdits processus étant suivie individuellement et contrôlée par l'intermédiaire d'un protocole de suivi et de contrôle d'exécution spécifique indépendant de chacun desdits processus, ledit protocole permettant une représentation abstraite de chaque processus et de l'ensemble des tâches de chaque processus, caractérisé en ce que ledit système comporte : un module de suivi et de contrôle d'exécution permettant la mise en oeuvre dudit protocole de suivi et de contrôle d'exécution ; des moyens de multiplexage interconnectés, d'une part, audit module de suivi et de contrôle d'exécution, et, d'autre part, à chacun desdits processus distincts, lesdits moyens de multiplexage permettant de configurer ladite représentation abstraite selon une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés, ce qui permet d'assurer le suivi et le contrôle d'exécution simultané par multiplexage de ladite pluralité de processus. 2. Système selon la revendication 1, caractérisé en ce que, pour un ensemble de processus distincts comportant au moins un groupe de tâches, ladite combinaison comprend un groupe de tâches virtuel associé à chacun desdits processus, chaque groupe de tâches virtuel r comprenant la hiérarchie des groupes de tâches du processus correspondant, l'ensemble des groupes de tâches virtuels et desdits groupes de tâches associés à chacun de ces groupes de tâches virtuels constituant ladite représentation abstraite selon un processus virtuel unique. 3. Système selon l'une des revendications 1 ou 2, caractérisé en ce que pour un protocole de suivi et de contrôle d'exécution spécifique et une liaison entre ledit module de suivi et de contrôle d'exécution et lesdits moyens multiplexeurs, d'une part, et entre lesdits moyens multiplexeurs et chaque processus distinct, d'autre part, l'échange d'information entre ledit module de suivi et de contrôle d'exécution et lesdits moyens multiplexeurs consiste en un échange de messages de commande, de messages de réponse et de messages d'événement, et en ce que l'échange d'information entre lesdits moyens multiplexeurs et chaque processus distinct consiste en un échange de messages de sous-commande, de messages de sousréponse respectivement de messages de sous-événement, lesdits moyens multiplexeurs recevant des messages de commande, des messages de sous-réponse et des messages de sous-événement et transmettant des messages de réponse, des messages de sous-commande et des messages d'événement, cette transmission étant effectuée en référence audit regroupement de l'ensemble des tâches de chacun des processus contrôlés constituant ladite représentation abstraite selon un processus virtuel unique. 4. Système selon la revendication 3, caractérisé en ce que lesdits moyens multiplexeurs comprennent au moins : r un module de gestion des commandes émises, par ledit module de suivi et de contrôle d'exécution ; un module de gestion des événements transmis par chaque processus ; - un module de gestion des traitements permettant simultanément : 'sous le contrôle dudit module de gestion des commandes, de créer un traitement pour chaque commande reçue, ledit traitement permettant, d'une part, d'envoyer des messages de sous-commande vers et de recevoir les messages de sous-réponse correspondants venant de ces processus, et, d'autre part, d'envoyer le message de réponse correspondant à cette commande vers ledit module de suivi et de contrôle d'exécution ; 'sous le contrôle dudit module de gestion des événements, de créer un traitement pour chaque message de sous-événement reçu de l'un desdits processus, ledit traitement permettant, d'une part, d'envoyer des messages de sous-commande vers et de recevoir les messages de sous-réponse correspondants venant de ces processus, et, d'autre part, d'envoyer des messages d'événement vers ledit module de suivi et de contrôle d'exécution. 5. Système selon la revendication 4, caractérisé en ce que ladite représentation abstraite étant formée au moyen d'identificateurs, ledit module de gestion des traitements comporte un module de gestion du multiplexage desdits identificateurs, lesdits identificateurs comportant des identificateurs globaux associés à ladite combinaison constituant ledit processus virtuel unique et r des identificateurs locaux associés à la représentation abstraite de chacun des processus distincts contrôlés, ledit module de gestion du multiplexage permettant la mise en correspondance entre identificateurs globaux et identificateurs locaux, et réciproquement. 6. Système selon l'une des revendications 4 ou 5, caractérisé en ce que l'exécution de la gestion des traitements par ledit module de gestion de traitement comprend au moins : une étape de test de disponibilité d'une sous-réponse en provenance de l'un desdits processus distincts, et sur réponse positive à ladite étape de test de disponibilité d'une sous-réponse ; une étape de test d'existence d'un traitement bloqué en attente de cette sous-réponse, la réponse négative à ladite étape de test d'existence d'un traitement bloqué étant suivie d'un retour à ladite étape de test de disponibilité et la réponse positive à ladite étape de test d'existence d'un traitement bloqué étant suivie d'une étape de déblocage dudit traitement bloqué, et suite à ladite étape de déblocage dudit traitement bloqué, et, en outre, sur réponse négative à ladite étape de test de disponibilité d'une sous-réponse ; une étape de test de disponibilité pour exécution d'un traitement, la réponse négative à cette étape de test de disponibilité pour exécution étant suivie d'un retour à ladite étape de test de disponibilité d'une sous-réponse et la réponse positive à cette étape de test de disponibilité pour exécution étant suivie d'une étape d'exécution d'un pas de calcul de ce traitement, et suite à cette étape d'exécution ; r une étape de test d'existence d'un blocage de ce traitement, la réponse positive à cette étape de test d'existence d'un blocage de ce traitement résultant de la demande par ce traitement de l'émission d'une sous- commande à un processus étant suivie d'une étape d'envoi de cette sous-commande à ce processus, et suite à la réponse négative à cette étape de test d'existence d'un blocage de ce traitement ; une étape de test de fin de ce traitement, la réponse positive à cette étape de test de fin de ce traitement étant suivie d'une étape de transmission d'un message de réponse ou d'un message d'événement par lesdits moyens multiplexeurs audit module de suivi et de contrôle d'exécution et la réponse négative à cette étape de test de fin de traitement étant suivie d'un retour à ladite étape de test de disponibilité d'une sous-réponse en provenance d'un processus distinct quelconque. 7. Système selon l'une des revendications 1 à 6, caractérisé en ce que ledit protocole de suivi et de contrôle d'exécution constituant un protocole de suivi et de contrôle d'exécution spécifique est le protocole JDWPO. 8. Procédé de suivi et de contrôle d'exécution simultané d'une pluralité de processus distincts exécutés indépendamment sur des systèmes informatiques distincts, chacun de ces processus contenant un ensemble de tâches organisé en une hiérarchie de groupes de tâches, l'exécution de chacun desdits processus étant suivie individuellement et contrôlée par l'intermédiaire d'un protocole de suivi et de contrôle d'exécution spécifique indépendant de chacun desdits processus, ledit protocole r permettant, à partir de commandes adressées à un processus, de réponses adressées par ce processus et d'événements spécifiques de ce processus, d'engendrer une représentation abstraite de ce processus et de l'ensemble des tâches de ce processus, caractérisé en ce que ce procédé consiste, au moyen d'une liaison unique support dudit protocole de suivi et de contrôle d'exécution spécifique : - à engendrer au moins une commande de suivi et de contrôle d'exécution conformément audit protocole de suivi et de contrôle d'exécution spécifique ; - à multiplexer l'ensemble des commandes, réponses et événements engendrés conformément audit protocole de contrôle et de suivi d'exécution spécifique, l'opération de multiplexage permettant, d'une part, l'aiguillage de chaque commande de suivi et de contrôle d'exécution vers chacun desdits processus, et, d'autre part, la transmission des réponses et événements en provenance de chaque processus, l'ensemble des commandes de suivi et de contrôle d'exécution, des réponses et des événements multiplexés constituant ladite représentation abstraite configurée par ladite opération de multiplexage selon une combinaison formant un processus virtuel unique regroupant l'ensemble des tâches de chacun des processus contrôlés, ce qui permet d'assurer le suivi et le contrôle d'exécution simultané de ladite pluralité de processus sur ladite liaison unique. 9. Procédé selon la revendication 8, caractérisé en ce que la représentation abstraite de chaque processus distinct contrôlé étant formée d'éléments associés chacun r à un identificateur local unique, lesdits éléments comprenant les tâches ou les groupes de tâches dudit processus distinct contrôlé, ladite opération de multiplexage consiste : - à associer à chaque processus distinct contrôlé et au processus virtuel une référence de processus spécifique, l'une des valeurs de référence de processus spécifique parmi l'ensemble des valeurs de référence de processus spécifique étant représentative dudit processus virtuel unique issu de ladite opération de multiplexage, le couple formé par un identificateur local et une valeur de référence de processus spécifique étant représentatif de l'élément de la représentation abstraite du processus distinct contrôlé associé à cet identificateur local, respectivement d'un élément virtuel constitutif de ladite combinaison formant ledit processus virtuel unique ; - à associer à tout couple formé par un identificateur local et une valeur de référence de processus spécifique un identificateur global distinct, l'ensemble des identificateurs globaux distincts obtenus pour chaque groupe de tâches virtuel constituant ladite combinaison formant ledit processus virtuel unique, la mise en correspondance entre identificateurs globaux et identificateurs locaux par processus distincts contrôlés permettant d'assurer ladite opération de multiplexage. 10 Procédé selon l'une des revendications 8 ou 9, caractérisé en ce que ledit protocole de suivi et de contrôle d'exécution spécifique est le protocole JDWP. r--------------------------------------------------- 11. Procédé selon l'une des revendications 8 à 10, caractérisé en ce que, pour tout processus distinct mis en oeuvre par une interprétation des instructions d'un langage séquentiel, ladite représentation abstraite virtuelle dudit processus comporte au moins une seule tâche dans une seul groupe de tâches associé à la séquence d'instructions interprétées, l'exécution de cette interprétation étant suivie et contrôlée par l'intermédiaire dudit protocole spécifique à partir des commandes, des réponses et des événements relatifs à cette seule tâche, ce qui permet d'effectuer le contrôle et le suivi simultané de l'exécution d'une pluralité de processus, l'un au moins de ces processus étant mis en oeuvre par une interprétation d'instructions d'un langage séquentiel.