Brevet FR2889881A1 — publié le 20070223

La présente invention concerne un système destiné à appliquer des opérations de transformation, de validation ou de simulation à un ensemble de documents constituant le modèle d'un système informatique. Ce modèle est le plus souvent utilisé pour définir différents aspects de ce système informatique; ces aspects incluant les schémas de données, les descriptions de processus, les traitements, les structures de données, les états possibles pour les composants du système, les transitions possibles entre ces états, ces transitions pouvant s'effectuer de manière séquentielle ou parallèle et déterministe ou non déterministe. Chaque document du modèle est associé à un type; ce type spécifiant le format ou le langage informatique fixant les règles syntaxiques devant être respectées par le contenu du document pour que le document soit valide syntaxiquement. Les documents utilisés dans un même modèle peuvent être exprimés dans différents formats ou langages. Enfin, un document peut être destiné à être interprété par des utilisateurs humains ou par des outils informatiques. Une opération de validation consiste à démontrer qu'une propriété logique donnée est vérifiée par un ensemble de documents du modèle. Une opération de simulation consiste à simuler le comportement d'un système informatique défini par un ensemble de documents d'un modèle. Une opération de validation, de simulation ou de transformation consiste à produire un ou plusieurs nouveaux documents à partir d'un ensemble de documents d'un modèle. Un tel système est mis en oeuvre notamment lors de l'analyse, de la conception, de la réalisation et de la maintenance d'un système informatique faisant intervenir plusieurs langages, formats de données et outils de modélisation. Il est connu d'utiliser un système destiné à appliquer des opérations de transformation, de validation ou de simulation utilisant des modules pour définir les traitements (analyse et génération syntaxique, analyse sémantique, transformation, validation, simulation) associés à un langage ou à un format donné. Un tel système permet d'utiliser de nouveaux langages et formats dans le modèle par ajout de nouveaux modules. Il existe deux types de systèmes: - Le plus souvent ces modules prennent la forme de bibliothèques en code objet, les traitements supportés par le module étant mis à la disposition du système par le module au travers d'une interface de programmation. Un système comme Eclipse est représentatif de cette première approche. - D'autres systèmes utilisent un langage unique, indépendant des langages et des formats utilisés dans le modèle, ce langage incluant un langage logique déclaratif permettant de rendre accessible à d'autres modules les définitions formelles relatives au langage ou format supporté par un ensemble de modules donnés (syntaxe concrète, syntaxe abstraite, sémantique, opérations de validation, transformations, simulation). Ces définitions relatives au langage ou format sont alors accessibles par les autres modules d'une part comme des données et d'autre part comme des traitements. En effet, le système est capable d'interpréter ces définitions pour les transformer en traitements. Cette seconde approche est beaucoup plus flexible que la première qui ne permet que d'accéder aux définitions sous forme de traitements. Cette seconde approche permet de réutiliser des fonctionnalités offertes par le système, par exemple les fonctionnalités d'analyse et de génération syntaxique, au lieu de les dupliquer dans chaque module. Cette seconde approche permet également de définir de nouveaux langages ou formats, de nouvelles opérations de transformation, de nouvelles opérations de simulation ou de nouvelles opérations de validation, à partir de modules existants. La première approche permet cependant de réaliser des modules offrant des fonctionnalités de complexité arbitraire, puisque leur implémentation fait appel à un langage de programmation généraliste. A l'inverse, les fonctionnalités offertes par les modules réalisés dans le cadre de la seconde approche sont potentiellement limitées par le pouvoir d'expression du langage logique utilisé pour exprimer les modules. Des systèmes tels que Maude, développé par l'Université de l'Illinois (USA), et ASF+SDF développé par le CWI (NL) sont représentatifs de cette seconde approche. Les problèmes techniques adressés par cette invention sont les suivants: disposer d'un système combinant les avantages des deux approches mentionnées ci-dessus; - doter ce système d'un mécanisme assurant la mise à jour des modules à partir d'un serveur connecté à un réseau; - doter ce système de mécanismes permettant de fournir, à des utilisateurs connectés par réseau au système, un service de transformation, de validation et de simulation de modèles informatiques, tout en assurant aux utilisateurs de ce service la confidentialité de leurs modèles, tout en empêchant les utilisateurs de ce service d'accéder à des données leur permettant de reproduire ce service. Les systèmes connus ne répondent pas à ces caractéristiques: - les systèmes représentatifs de la première approche présentée ci-dessus ne permettent pas de réutiliser des fonctionnalités offertes par le système, par exemple celles d'analyse et de génération syntaxique, ces fonctionnalités étant dupliquées dans chaque module; les systèmes représentatifs de la première approche ne permettent pas non plus de définir de nouveaux langages ou formats, de nouvelles opérations de transformation, de nouvelles opérations de simulation ou de nouvelles opérations de validation, à partir de modules existants; - les systèmes représentatifs de la seconde approche sont généralement limités par certains aspects du langage logique utilisé pour exprimer les modules; par exemple Maude ne peut pas définir la syntaxe de beaucoup de langages et de formats couramment utilisés; de même ASF+SDF ne peut pas être utilisé pour définir la sémantique de certains langages et de formats couramment utilisés; de plus les systèmes représentatifs de la seconde approche ne disposent pas de mécanismes permettant de fournir, à des utilisateurs connectés par réseau au système, un service de transformation, de validation et de simulation de modèles informatiques. Le système selon l'invention permet de remédier à ces inconvénients. Il utilise en effet selon une première caractéristique des modules pour définir la syntaxe concrète des langages et des formats utilisés par les documents du modèle, des modules pour définir leur syntaxe abstraite et des modules pour définir leur sémantique; les syntaxes concrètes correspondant à des grammaires acycliques hors contexte arbitraires, sans restriction sur la nature des lexèmes; les modules étant des documents exprimés sous forme textuelle ou binaire dans un langage unique, appelé langage pivot, indépendant des langages et des formats utilisés dans le modèle; ce langage pivot incluant un langage logique déclaratif permettant de définir des équations et des règles de réécriture; la création de nouveaux modules permettant d'utiliser de nouveaux langages et formats dans le modèle. 2889881 4 Selon les modes particuliers de réalisation: - le système peut utiliser un ensemble de modules pour définir les opérations de transformation, de simulation et de validation; de nouvelles opérations de transformation, de simulation et de validation pouvant être définies par création de nouveaux modules; - chaque module peut inclure d'autres modules dont les éléments constitutifs peuvent être préalablement renommés, ceci permettant notamment de définir des modules définissant de nouveaux langages ou formats, de nouvelles opérations de transformation, de nouvelles opérations de simulation ou de nouvelles opérations de validation, à partir de modules existants; -le système pouvant comprendre un analyseur syntaxique; cet analyseur syntaxique effectuant des opérations d'analyse syntaxique en utilisant des modules de définition de la syntaxe concrète et abstraite pour obtenir la définition de la syntaxe concrète et abstraite des différents langages ou formats utilisés par les documents du modèle; - le système pouvant comprendre un générateur syntaxique; ce générateur syntaxique effectuant des opérations de génération syntaxique en utilisant des modules de définition de la syntaxe concrète et abstraite pour obtenir la définition de la syntaxe concrète et abstraite des différents langages ou formats utilisés par les documents du modèle; - le système pouvant comprendre un moteur de validation, de transformation et de simulation; ce moteur utilisant un analyseur syntaxique pour analyser les documents du modèle; ce moteur utilisant les définitions de syntaxe abstraite, de sémantique, de transformation, de simulation et de validation des modules de définition de la syntaxe abstraite, de la sémantique et des opérations de validation, de simulation et de transformation pour effectuer l'opération de validation, de simulation ou de transformation spécifiée par une commande; ce moteur utilisant un générateur syntaxique pour générer de nouveaux documents à partir du résultat des opérations de validation, de simulation et de transformation; - le système pouvant comprendre un gestionnaire de cartouches, une cartouche étant un document comprenant les informations nécessaires au système pour mettre à jour les modules contenant les définitions de syntaxe concrète, de syntaxe abstraite, de sémantique, et de transformation, de simulation et de validation; la prise en compte d'une nouvelle cartouche par le gestionnaire en réponse à une commande permettant au système de prendre en charge de nouveaux langages ou formats, de nouvelles opérations de transformation, de simulation et de validation, ou de nouvelles versions de langages, de formats ou d'opérations; - le système pouvant comprendre des moyens pour se connecter par un réseau à un serveur permettant au gestionnaire de cartouches s'exécutant sur l'ordinateur de l'utilisateur de recevoir du serveur de nouvelles cartouches; l'utilisateur pouvant avoir à s'authentifier au préalable auprès du serveur afin que celui-ci vérifie si l'utilisateur est autorisé à bénéficier de ce service; -le système pouvant comprendre des moyens pour être mis en oeuvre sur plusieurs ordinateurs pouvant communiquer par le biais d'un réseau informatique; un des ordinateurs, appelé le serveur, contrôlant les opérations d'analyse syntaxique, de génération syntaxique, de validation, de simulation et de transformation pour le compte d'un autre ordinateur, appelé client; l'utilisateur du client pouvant avoir à s'authentifier auprès du serveur afin que celui-ci vérifie si l'utilisateur est autorisé à bénéficier de ce service; le client hébergeant les documents du modèle et exécutant les opérations d'analyse et de génération syntaxique; - la partie du système s'exécutant sur le client pouvant n'envoyer au serveur que des données dont l'interprétation par l'organisation opérant le serveur est rendue impossible grâce à un mécanisme d'obscurcissement; ceci de façon à protéger la confidentialité des documents du modèle; chaque ordinateur client étant capable d'inverser le mécanisme d'obscurcissement pour les données renvoyées par le serveur. - l'ordinateur client pouvant ne pas avoir la possibilité d'accéder aux modules contenant les définitions sémantiques et aux modules contenant les définitions des opérations de transformation, de simulation et de validation; de façon à ce que ces modules ne puissent pas être copiés ou produits par l'utilisateur ou l'organisation opérant l'ordinateur client; empêchant ainsi quiconque de bénéficier des services de validation, de simulation et de transformation du système sans y être autorisé. 2889881 6 D'autres objets et avantages de l'invention apparaîtront au cours de la description qui suit, faite en référence aux dessins annexés, dans lesquels les figures 1, 2, 3 et 4 présentent différents modes de réalisation du système. Dans ces figures les services informatiques responsables des traitements sont représentés par des rectangles, les commandes sont représentées par des losanges, les documents sont représentés par des rectangles arrondis, les modules sont représentés par des rectangles biseautés et les cartouches sont représentés par des cercles. Les flèches indiquent le sens des flux de données, les flèches en pointillés permettent d'indiquer les flux de données transitant par un réseau informatique. Les rectangles en pointillés permettent de regrouper des données et des services informatiques hébergés sur un même ordinateur. En référence à ces figures, le système comporte un ensemble de documents constituant le modèle (1) du système informatique. Dans les exemples de réalisation correspondants aux figures, on représente chaque document par un fichier stocké dans un répertoire du système de fichier local à l'ordinateur de l'utilisateur. On associe un type à chaque document du modèle en utilisant par exemple, l'extension Y du nom de fichier X.Y contenant le document, ce type Y spécifiant le format ou le langage informatique fixant les règles syntaxiques devant être respectées par le contenu du document pour que le document soit valide syntaxiquement. Les documents utilisés dans un même modèle (1) peuvent être exprimés dans différents formats ou langages. Dans cet exemple de réalisation, on fait l'hypothèse que le système d'exploitation utilisé offre un environnement de type ligne de commande et permet à un processus de lancer des sous-processus, puis d'établir une communication avec eux par redirection des entrées-sorties. Les systèmes de type Unix ou Windows offrent ces possibilités. En référence aux figures, le système comporte un ensemble de nouveaux documents (9) résultant des opérations effectuées par le système. Dans cet exemple de réalisation on représente chaque document ainsi produit par un fichier stocké dans un second répertoire du système de fichier local à l'ordinateur de l'utilisateur. 2889881 7 Dans cet exemple de réalisation on fait l'hypothèse qu'il est de la responsabilité de l'utilisateur d'éviter tout conflit de nom pour les fichiers ainsi stockés dans les répertoires de documents (1) et (9). En référence aux figures, le système comporte des modules (2) pour définir la syntaxe concrète des langages et des formats utilisés par les documents du modèle (1), des modules (10) pour définir leur syntaxe abstraite, des modules (3) pour définir leur sémantique et des modules (4) pour définir les opérations de transformation, de simulation et de validation. Dans cet exemple de réalisation on représente chaque module par un fichier stocké dans un troisième répertoire, appelé répertoire des modules, du système de fichier local à l'ordinateur de l'utilisateur. En référence aux figures, le système comporte une commande (8) permettant de spécifier l'opération de validation, de simulation ou de transformation qui doit être exécutée par le système. Dans le cadre de cet exemple de réalisation, la commande (8) sera une série de paramètres de ligne de commande, entrés par l'utilisateur dans un interpréteur du système d'exploitation. En référence aux figures, le système comporte: - un analyseur syntaxique (5); cet analyseur syntaxique effectuant des opérations d'analyse syntaxique en utilisant des modules de définition de la syntaxe concrète (2) et abstraite (10) ; - un générateur syntaxique (6) ; ce générateur syntaxique effectuant des opérations de 25 génération syntaxique en utilisant des modules de définition de la syntaxe concrète (2) et abstraite (10) ; - un moteur de validation, de transformation et de simulation (7) ; ce moteur utilisant l'analyseur syntaxique (5) pour analyser les documents du modèle (1) ; ce moteur utilisant des modules de définition de la syntaxe abstraite (10), de la sémantique (3) et des opérations de validation, simulation et transformation (4) pour effectuer l'opération de validation, de simulation ou de transformation spécifiée par la commande (8) ; ce moteur utilisant un générateur syntaxique (6) pour générer de nouveaux documents (9) à partir du résultat des opérations de validation, de simulation et de transformation. Dans le cadre de cet exemple de réalisation - l'analyseur syntaxique (5) et le générateur syntaxique (6) sont basés sur les outils du système ASF+ SDF dans sa version 1.5; - le moteur de validation, de transformation et de simulation (7) est basé sur le système Core Maude dans sa version 2.1. 1. Cette combinaison permet de surmonter les limitations respectives de chacun de ces systèmes. Par exemple, Maude ne peut pas définir la syntaxe de beaucoup de langages et de formats couramment utilisés et ASF+SDF ne peut pas être utilisé pour définir la sémantique de langages et de formats couramment utilisés ni pour définir certaines opérations de validation. En utilisant ASF+SDF dans (5) et (6) pour les fonctionnalités liées à la syntaxe et Maude dans le moteur de moteur (7) de validation, de transformation et de simulation, il est possible d'obtenir un système disposant des caractéristiques recherchées. Ces deux systèmes utilisent des langages basés sur des langages logiques déclaratifs permettant de définir des équations et des règles de réécriture. Ces deux langages disposent de mécanismes d'inclusion de modules similaires. Du fait de ces caractéristiques communes, dans cet exemple de réalisation, l'union de ces deux langages est retenue comme langage pivot, chaque module en langage pivot étant soit un module SDF contenu dans un fichier X.dxf, soit un module ASF contenu dans un fichier X.asf, soit un Maude contenu dans un fichier X.maude. ASF+SDF permet de construire des analyseurs syntaxiques et des générateurs syntaxiques pour des grammaires acycliques hors contexte arbitraires, sans restriction sur la nature des lexèmes. D'autre part, ASF+SDF dispose de différents mécanismes permettant de résoudre les ambiguïtés résultant de l'utilisation de définitions syntaxiques ambiguës. 2889881 9 La logique de réécriture conditionnelle utilisée par Maude permet la modélisation de systèmes informatiques dans lesquels des activités ont lieu de manière concurrente. D'une part, la logique de réécriture inclut la logique équationnelle d'appartenance. Ce système logique est connu pour permettre la modélisation de structures de données. Il constitue une extension de la logique équationnelle multi-sortée utilisée de longue date pour spécifier les types de données abstraits. D'autre part, la logique de réécriture est connue pour être suffisamment expressive pour modéliser la sémantique de nombreux langages faisant intervenir le parallélisme et le non déterminisme comme les réseaux de Petri, le mécanisme de thread JAVA, les systèmes de transition étiquetés, CCS et LOTOS. Les opérations de transformation s'écrivent de façon naturelle sous la forme d'équations et de règles de réécritures dans des modules Maude. Lorsque l'on dispose d'un module donnant la sémantique opérationnelle d'un langage L en logique de réécriture et d'un interpréteur tel que Maude pour cette logique, alors on dispose également d'un interpréteur pour le langage L permettant ainsi d'effectuer des opérations de simulation. D'autre part, la correction et la complétude de la logique de réécriture sont des propriétés connues, permettant ainsi les opérations de validation. Enfin, le langage logique utilisé par Maude est réflexif, ce qui permet à l'utilisateur du système de développer des modules correspondants aux opérations de validation. Dans cet exemple de réalisation, le langage pivot étant l'union des langages Maude et ASF+SDF, et étant données les caractéristiques présentées ci-dessus de chacun de ces langages, il possible à un utilisateur de construire un modèle (1) par le biais de modules en langage pivot (2), (10) et (3) modélisant différents aspects d'un système informatique tels que: - les schémas de données, - les descriptions de processus, - les traitements, - les structures de données, - les états possibles pour les composants du système, les transitions possibles entre ces états, ces transitions pouvant s'effectuer de manière séquentielle ou parallèle et déterministe ou non déterministe. Il lui est également possible de définir par le biais de modules en langage pivot (4) : - des opérations de validation consistant à démontrer qu'une propriété logique donnée est vérifiée par un ensemble de documents du modèle (1), - des opérations de simulation consistant à simuler le comportement du système ou d'un de ses parties, - des opérations de transformation consistant à produire un ou plusieurs nouveaux 10 documents (9) à partir d'un ensemble de documents du modèle (1). Les choix effectués dans le cadre de cet exemple de réalisation permettent de disposer d'une relation simple entre les noms de fichiers et les modules. On utilise pour chaque langage ou format de nom X: - un module SDF LC-X.sdf pour la définition de la syntaxe concrète et la définition de sa relation avec la syntaxe abstraite, - un module ASF LC-X. asf filtrant les arbres syntaxiques pour résoudre les ambiguïtés résultant de l'utilisation de définitions syntaxiques ambiguës, - un module Maude LA-X.maude pour la définition de la syntaxe abstraite, 20 - un module Maude LS-X.maude pour la définition de la sémantique. De même, dans cet exemple de réalisation on va utiliser un module Maude OX.maude pour chaque opération de validation, de transformation ou de simulation de nom X. L'hypothèse est faite que chaque module stocké dans un fichier X.Y a X comme nom de module ASF+SDF ou Maude. Dans cet exemple de réalisation des informations sur la syntaxe abstraite sont donc dupliquées dans les fichiers LC-X.sdf et LA-X.maude. Une autre réalisation pourrait générer LA-X.maude à partir de LC-X.sdf en utilisant le moteur (7) pour extraire les informations relatives à la syntaxe abstraite de LC-X.sdf. Dans cet exemple de réalisation, le résultat d'une opération d'analyse syntaxique effectué par (5) portant sur un document du modèle (1) dont le type indique qu'il doit respecter le format ou le langage X est soit un arbre syntaxique abstrait si le document est valide, soit une erreur dans le cas contraire. Les arbres syntaxiques sont représentés sous la forme d'un terme sur la signature du langage ou format X défini par LC-X.sdf. Un terme est une structure de donnée indépendante de tout langage; cette structure de donnée représentant un arbre étiqueté dont certains noeuds peuvent être partagés en leur associant plusieurs noeuds pères. La signature d'un langage ou format X est un ensemble de contraintes restreignant les valeurs possibles pour les termes. Les termes sur la signature X sont l'ensemble des termes dont la valeur respecte les contraintes de la signature de X. Dans cet exemple de réalisation, les termes sont implémentés en utilisant la librairie ATerm développée par le CWI (NL). Ces termes constituent le format d'échange entre les différents outils utilisés dans cet exemple de réalisation: les outils ASF+SDF utilisent les ATerm comme format d'entrée-sortie et la syntaxe simple des ATerm permet à Maude de les analyser et de les générer sans difficulté. Le choix de l'utilisation de ASF+SDF et des ATerm implique cependant de n'utiliser dans cet exemple de réalisation que des documents encodés en ASCII. Dans cet exemple de réalisation l'analyseur syntaxique (5) est un script de commande invoquant des commandes ASF+SDF et en faisant communiquer ces commandes par le biais de fichiers intermédiaires. Ce script prend en paramètre le nom X.Y d'un document du modèle, en déduit son langage ou format L à partir de l'extension de fichier Y, vérifie si une table d'analyse syntaxique L.tbl a déjà été générée, si tel est le cas, le script utilise la commande sglr pour produire un arbre d'analyse syntaxique, puis applique à cet arbre les règles de désambiguïsation contenues dans LC-X.asf, ce module ayant été préalablement compilé en C grâce au compilateur ASF2C, l'arbre d'analyse syntaxique résultant est ensuite converti en arbre syntaxique abstrait par le biais de la commande implode-asfix. Tous ces arbres sont représentés sous la forme ATerm. Si une table d'analyse syntaxique L.tbl n'est pas disponible, l'analyseur syntaxique (5) va la générer en invoquant la commande pack-sdf pour le fichier LC-X.sdf, puis la commande sdf2table. Si l'analyse syntaxique échoue, le script (5) se termine en passant un code d'erreur à son environnement. Dans cet exemple de réalisation le générateur syntaxique (6) est un script de commande invoquant des commandes ASF+SDF et en faisant communiquer ces commandes par le biais de fichiers intermédiaires. Ce script prend en paramètre un arbre syntaxique abstrait représenté sous la forme d'un ATerm et le nom X.Y du document à créer dans (9), en déduit son langage ou format L à partir de l'extension de fichier Y, vérifie si une table de formatage L.pp a déjà été générée, si tel est le cas, le script utilise les commandes ast2abox et abox2text pour produire le nouveau document à partir du terme fourni en paramètre. Si une table de formatage L.pp n'est pas disponible, le générateur syntaxique (6) va la générer en invoquant la commande pack-sdf pour le fichier LC- X.sdf, puis la commande ppgen. Si la génération syntaxique échoue, le script (6) se termine en passant un code d'erreur à son environnement. Dans cet exemple de réalisation le moteur de validation, de transformation et de simulation (7) est réalisé en développant un programme de type ligne de commande en langage C. Ce programme prend en paramètre la commande (8) constituée du nom X de l'opération de validation, de transformation ou de simulation à réaliser et d'une liste de paramètres et de documents auxquels doit s'appliquer l'opération. Lors de l'exécution de (7) les étapes suivantes sont effectuées: - Le moteur (7) exécute l'interpréteur Maude comme un sous-processus et dialogue avec cet interpréteur par les descripteurs de fichiers correspondant à son entrée et à sa sortie standard. - Après le démarrage de l'interpréteur Maude, le moteur (7) charge dans l'interpréteur Maude un module de démarrage. Ce module a deux principales fonctions. D'une part, il permet de gérer la communication avec le moteur (7). D'autre part, ce module défini la syntaxe des ATerm ainsi que des opérateurs permettant de transformer de façon générique un ATerm sur une signature définie par le module LC-X.sdf en un terme Maude correspondant à la signature du module LA-X.maude. - Le module O-X.maude définissant l'opération X est chargée dans l'interpréteur Maude par le bais de la commande in. - La liste L de paramètres et de documents auxquels doit s'appliquer la transformation est encodée par le moteur (7) sous la forme d'un ATerm. Le moteur (7) demande ensuite à l'interpréteur Maude de réécrire ce terme dans le module O-X.maude par le biais de la commande rew. - Il arrive que l'interpréteur Maude doive transférer le contrôle au moteur (7) pour que celui-ci effectue une action avant que l'interpréteur Maude ne reprenne le traitement de l'opération. Cette situation se produit par exemple lorsque l'opération en cours d'exécution a besoin que le moteur (7) lui fournisse les ATerm correspondants à des documents du modèle (1), lorsque des modules Maude doivent être chargés dans l'interpréteur (par exemple LA-X.maude ou LS-X.maude), lorsque l'opération en cours d'exécution a besoin que le moteur (7) produise de nouveaux documents (9) ou encore lorsqu'il est nécessaire de changer la stratégiede réécriture. Pour cela le module de démarrage défini pour chacun de ces cas un opérateur de transfert permettant de transférer le contrôle au moteur (7) en lui indiquant la tâche à effectuer par le biais de la sortie standard tout en mémorisant l'état courant de l'opération. Ce transfert de contrôle est implémenté en utilisant le mécanisme LOOP- MODE fourni par Maude est utilisé, l'état courant de l'opération étant représenté par le champ état de l'opérateur de boucle défini par LOOP- MODE et la tâche à effectuer par le moteur étant représentée par le champ flot de sortie de cet opérateur. En réponse aux tâches affectées par l'interpréteur Maude, le moteur (7) a la responsabilité d'exécuter l'analyseur syntaxique et le générateur syntaxique dans des sous processus. Après avoir effectué la tâche qui lui était affectée, le moteur (7) a la responsabilité de demander à l'interpréteur de relancer la réécriture à moins qu'une erreur soit survenue ou que la tâche affectée par l'interpréteur signale une erreur ou une fin d'opération. L'exécution du moteur (7) se termine en passant un code d'erreur ou de succès à son environnement. L'exemple de réalisation décrit jusqu'à ce point correspond à la figure 1. Les figures 2, 3 et 4 décrivent des modes de réalisations offrant des fonctionnalités supplémentaires. En particulier, l'exemple de réalisation présenté dans la figure 2 comprend un gestionnaire de cartouches (11), une cartouche (22) étant un document comprenant les informations nécessaires au système pour mettre à jour les modules contenant les définitions de syntaxe concrète (2), de syntaxe abstraite (10), de sémantique (3), et de transformation, de simulation et de validation (4) ; la prise en compte d'une nouvelle cartouche (22) par le gestionnaire (11) en réponse à une commande (21) permettant au système de prendre en charge de nouveaux langages ou formats, de nouvelles opérations de transformation, de simulation et de validation, ou de nouvelles versions de langages, de formats ou d'opérations. Dans un second exemple de réalisation, il est possible d'utiliser un format de paquetage tel que le format Unix tar pour réaliser la cartouche (11). Un paquetage contient alors les modules permettant de mettre à jour les modules contenant les définitions de syntaxe concrète (2), de syntaxe abstraite (10), de sémantique (3), et de transformation, de simulation et de validation (4). Le gestionnaire de cartouche (11) est réalisé par un script qui prend en paramètre la commande (21) constituée du nom X de la cartouche (22). Lors de l'exécution de (11) les étapes suivantes sont effectuées: - les modules contenus dans le paquetage (11) sont extraits dans un répertoire temporaire en utilisant la commande Unix tar, - pour chaque module ayant un nom de la forme LC-X.sdf, si les modules LC-X.asf, LA-X.maude et LS-X.maude existent, alors ces quatres modules sont déplacés dans le répertoire des modules, - chaque module ayant un nom de la forme O-X.maude est déplacé dans le répertoire des modules, - le répertoire temporaire est effacé. Dans un troisième exemple de réalisation correspondant à la figure 3, il est possible de se connecter par un réseau à un serveur (18) permettant au gestionnaire de cartouches (11) s'exécutant sur l'ordinateur de l'utilisateur (17) de recevoir du serveur (18) de nouvelles cartouches; l'utilisateur pouvant avoir à s'authentifier au préalable auprès du serveur afin que celui-ci vérifie si l'utilisateur est autorisé à bénéficier de ce service. Dans cet exemple de réalisation, le réseau informatique supporte le protocole TCP-IP. Il est alors possible d'utiliser un serveur Web classique (12) tel que Apache de la fondation Apache pour délivrer par le protocole HTTP des cartouches aux utilisateurs identifiés avec succès par la méthode d'authentification standard HTTP digest. Le format de paquetage Unix tar sera utilisé pour réaliser la cartouche délivrée par réseau. Le gestionnaire de cartouche (Il) est réalisé par un script qui prend en paramètre la commande (21) constituée du nom X de la cartouche que l'utilisateur souhaite recevoir, l'adresse IP du serveur (18), le nom de l'utilisateur et un mot de passe. Lors de l'exécution de (11) les étapes suivantes sont effectuées: - la cartouche X est téléchargé à partir du serveur (18) en utilisant la commande wget développée par le projet GNU, le nom de l'utilisateur et le mot de passe étant passés en paramètres, - si l'authentification de l'utilisateur réussi, si la cartouche est disponible et si le transfert réussi, le paquetage correspondant à la cartouche est copié dans un fichier temporaire sur l'ordinateur client (17), - les modules contenus dans le paquetage sont extraits dans un répertoire temporaire, - pour chaque module ayant un nom de la forme LC-X.sdf, si les modules LC-X.asf, LA-X.maude et LS-X.maude existent, alors ces quatres modules sont déplacés dans le répertoire des modules, - chaque module ayant un nom de la forme O-X.maude est déplacé dans le répertoire des modules, - le répertoire et le fichier temporaires sont effacés. Dans un quatrième exemple de réalisation correspondant à la figure 4, le système comprend des moyens pour être mis en oeuvre sur plusieurs ordinateurs pouvant communiquer par le biais d'un réseau informatique; un des ordinateurs, appelé le serveur (18), contrôlant les opérations d'analyse syntaxique, de génération syntaxique, de validation, de simulation et de transformation pour le compte d'un autre ordinateur, appelé client (17). Le système comporte deux passerelles, l'une d'elle (20) étant destinée à s'exécuter sur le client (17) et l'autre (19) sur le serveur (18). Dans cet exemple de réalisation, la passerelle serveur (19) est un programme développé en C dont l'exécutable est disponible sur le serveur (18) sous trois noms différents, ces noms étant respectivement le nom du script d'analyse syntaxique (5), le nom du script de génération syntaxique (6) et le nom d'un script CGI pouvant être invoqué par le serveur Web (12). Ceci permet en particulier d'utiliser le moteur (7) décrit dans les précédents exemples de réalisation sans modification. La passerelle serveur (19) est ainsi exécutée comme sous processus par le moteur (7) qui s'exécute maintenant côté serveur et par le serveur Web (12). La passerelle serveur (19), par le biais de l'argument 0 de sa ligne de commande peut déterminer si elle est exécutée en tant qu'analyseur syntaxique par (7), en tant que générateur syntaxique par (7) ou en tant que script CGI par (12). La communication entre les deux passerelles (20) et (19) se fait par des requêtes HTTPPOST produites par la commande WGET, cette commande étant exécutée par (20), reçue par le serveur Web (12) qui en confie le traitement à une instance de (19). L'authentification est faite comme précédemment par la méthode d'authentification standard HTTP digest. La passerelle client (20) est un programme développé en C qui a pour rôle de traiter la commande (8), d'invoquer (5) et (6) pour le compte de (19) et de gérer la communication avec (19). Les requêtes émise par (20) correspondent aux cas suivants: 15 - envoi initial des éléments de la commande (8), - envoi du résultat d'une analyse syntaxique produite par (5) - envoi vide, cette requête est envoyée lorsque (20) attend une tâche à effectuer de la part de (19), cette requête peut être envoyée à nouveau lorsque le serveur (12) ne produit pas de réponse dans les délais et qu'une erreur de dépassement de délai survient. Le principe est qu'après réception d'une commande (8), lorsque le client (17) n'est pas occupé par une analyse syntaxique de (5) ou une génération syntaxique de (6), sa passerelle (20) est systématiquement en attente d'une réponse du serveur (18) à une requête HTTP-POST, cette réponse devant lui dire quelle tâche d'analyse syntaxique ou de génération à effectuer. (20) réalise ces opération en invoquant (5) et (6), le résultat d'une analyse syntaxique étant renvoyé par WGET. Du côté serveur (18) : - A chaque fois qu'une instance de la passerelle serveur (19) est exécutée comme script 30 CGI par le serveur Web (12), elle vérifie si un segment de mémoire partagé (par exemple de type IPC Unix) existe. - Si ce segment de mémoire partagé n'existe pas, le segment de mémoire partagé est créé et un sous processus clone de (19) du processus père est créé. Le processus père se termine de façon à permettre à la requête HTTP en cours de se terminer. Le processus fils continue en exécutant une instance de (7) en lui passant les paramètres contenus dans la requête HTTP initiée par (8). Le processus fils se termine lorsque (7) se termine et après avoir détruit le segment de mémoire partagé. - Si ce segment de mémoire partagé existe déjà, alors si la requête HTTP contient le résultat d'une analyse syntaxique produite par (5), ce résultat est stocké dans la mémoire partagée et (19) se termine, si la requête HTTP correspond à un envoi vide (19) attend qu'une tâche à effectuer par le client soit disponible dans la mémoire partagé. Une fois cette information disponible, la requête HTTP se termine, sa réponse contenant la tâche à effectuer. - A chaque fois qu'une instance de la passerelle serveur (19) est exécutée comme analyseur syntaxique, elle se connecte au segment de mémoire partagé et y écrit la tâche à effectuer, puis attend que la réponse arrive dans le segment de mémoire partagé. - A chaque fois qu'une instance de la passerelle serveur (19) est exécutée comme générateur syntaxique, elle se connecte au segment de mémoire partagé et y écrit la tâche à effectuer. Dans cet exemple de réalisation, pour des raisons de simplicité d'exposition, un unique utilisateur est pris en charge à un moment donné par le serveur. Des variantes de réalisation utilisant des segments de mémoire partagés dédiées à chaque utilisateur permettent de lever cette limitation. Une variante de réalisation consiste à n'envoyer au serveur (18) que des ATerm dont l'interprétation par l'organisation opérant le serveur (18) est rendue impossible grâce à un mécanisme d'obscurcissement; ceci de façon à protéger la confidentialité des documents du modèle (1) ; chaque passerelle client (20) étant capable d'inverser le mécanisme d'obscurcissement pour les données renvoyées par le serveur (18) . Ceci est réalisé en dotant (20) d'une de deux tables de hachage, l'une d'elles associant à chaque identificateur de chaque ATerm produit par (5) un entier unique produit par une fonction difficilement inversible, une fonction aléatoire par exemple. L'autre table est utilisée pour mémoriser la fonction inverse. Chaque identificateur est alors remplacé par un identificateur construit à partir de cet entier, par exemple en concaténant le préfix ID à chaque entier. Lorsque des ATerm seront renvoyés par la passerelle serveur (19), on inverse ce processus d'obscurcissement en utilisant la seconde table de hachage. Des variantes de réalisation peuvent étendre cette approche à l'obscurcissement des constantes de chaînes, constantes entières et constantes réelles mais cette approche peut rendre impossibles certaines opérations de validation, de simulation ou de transformation. Dans cette variante de réalisation l'ordinateur client (17) n'a pas la possibilité d'accéder aux modules contenant les définitions sémantiques (3) et aux modules contenant les définitions des opérations de transformation, de simulation et de validation (4). Ainsi ces modules ne peuvent pas être copiés ou produits par l'utilisateur ou l'organisation opérant l'ordinateur client (17) ; empêchant ainsi quiconque de bénéficier des services de validation, de simulation et de transformation du système sans y être autorisé. Un tel système est notamment mis en oeuvre lors de l'analyse, de la conception, de la réalisation et de la maintenance d'un système informatique faisant intervenir plusieurs langages, formats de données et outils de modélisations. 2889881 19 REVENDICATIONS 1) Système destiné à appliquer des opérations de transformation, de validation ou de simulation à un ensemble de documents; cet ensemble de documents constituant le modèle (1) d'un système informatique; ce modèle définissant différents aspects de ce système informatique; ces aspects incluant les schémas de données, les descriptions de processus, les traitements, les structures de données, les états possibles pour les composants du système, les transitions possibles entre ces états, ces transitions pouvant s'effectuer de manière séquentielle ou parallèle et déterministe ou non déterministe; une opération de validation consistant à démontrer qu'une propriété logique donnée est vérifiée par un ensemble de documents du modèle (1) ; une opération de simulation consistant à simuler le comportement d'un système informatique défini par un ensemble de documents du modèle (1) ; une opération de validation, de simulation ou de transformation consistant à produire un ou plusieurs nouveaux documents (9) à partir d'un ensemble de documents du modèle (1) ; chaque document du modèle (1) étant associé à un type; ce type spécifiant le format ou le langage informatique fixant les règles syntaxiques devant être respectées par le contenu du document pour que le document soit valide syntaxiquement; les documents utilisés dans un même modèle (1) pouvant être exprimés dans différents formats ou langages; un document étant destiné à être interprété par des utilisateurs humains ou par des outils informatiques; un tel système étant notamment mis en oeuvre lors de l'analyse, de la conception, de la réalisation et de la maintenance d'un système informatique faisant intervenir plusieurs langages, formats de données et outils de modélisations. 2) Système selon la revendication 1 caractérisé en ce qu'il utilise des modules (2) pour définir la syntaxe concrète des langages et des formats utilisés par les documents du modèle (1), des modules (10) pour définir leur syntaxe abstraite et des modules (3) pour définir leur sémantique; les syntaxes concrètes correspondant à des grammaires acycliques hors contexte arbitraires, sans restriction sur la nature des lexèmes; les modules étant des documents exprimés sous forme textuelle ou binaire dans un langage unique, appelé langage pivot, indépendant des langages et des formats utilisés dans le modèle; ce langage pivot incluant un langage logique déclaratif permettant de définir des équations et des règles de réécriture; la création de nouveaux modules (2), (10) et (3) permettant d'utiliser de nouveaux langages et formats dans le modèle (1). 3) Système selon l'une des revendications précédentes caractérisé en ce qu'il utilise un ensemble de modules (4) pour définir les opérations de transformation, de simulation et de validation; de nouvelles opérations de transformation, de simulation et de validation pouvant être définies par création de nouveaux modules (4). 4) Système selon l'une des revendications précédentes caractérisé en ce que chaque module peut inclure d'autres modules dont les éléments constitutifs peuvent être préalablement renommés, ceci permettant notamment de définir des modules définissant de nouveaux langages ou formats, de nouvelles opérations de transformation, de nouvelles opérations de simulation ou de nouvelles opérations de validation, à partir de modules existants. 5) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend un analyseur syntaxique (5); cet analyseur syntaxique effectuant des opérations d'analyse syntaxique en utilisant des modules de définition de la syntaxe concrète (2) et abstraite (10) pour obtenir la définition de la syntaxe concrète et abstraite des différents langages ou formats utilisés par les documents du modèle. 6) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend un générateur syntaxique (6) ; ce générateur syntaxique effectuant des opérations de génération syntaxique en utilisant des modules de définition de la syntaxe concrète (2) et abstraite (10) pour obtenir la définition de la syntaxe concrète et abstraite des différents langages ou formats utilisés par les documents du modèle. 7) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend un moteur de validation, de transformation et de simulation (7) ; ce moteur utilisant un analyseur syntaxique (5) pour analyser les documents du modèle (1) ; ce moteur utilisant les définitions de syntaxe abstraite, de sémantique, de transformation, de simulation et de validation des modules de définition de la syntaxe abstraite (10), de la sémantique (3) et des opérations de validation simulation transformation (4) pour effectuer l'opération de validation, de simulation ou de transformation spécifiée par une commande (8) ; ce moteur utilisant un générateur syntaxique (6) pour générer de nouveaux documents (9) à partir du résultat des opérations de validation, de simulation et de transformation. 8) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend un gestionnaire de cartouches (11), une cartouche (22) étant un document comprenant les informations nécessaires au système pour mettre à jour les modules contenant les - définitions de syntaxe concrète (2), de syntaxe abstraite (10), de sémantique (3), et de transformation, de simulation et de validation (4) ; la prise en compte d'une nouvelle cartouche par le gestionnaire (11) en réponse à une commande (21) permettant au système de prendre en charge de nouveaux langages ou formats, de nouvelles opérations de transformation, de simulation et de validation, ou de nouvelles versions de langages, de formats ou d'opérations. 9) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend des moyens pour se connecter par un réseau à un serveur (18) permettant au gestionnaire de cartouches (11) s'exécutant sur l'ordinateur de l'utilisateur (17) de recevoir du serveur (18) de nouvelles cartouches; l'utilisateur pouvant avoir à s'authentifier au préalable auprès du serveur afin que celui-ci vérifie si l'utilisateur est autorisé à bénéficier de ce service. 10) Système selon l'une des revendications précédentes caractérisé en ce qu'il comprend des moyens pour être mis en oeuvre sur plusieurs ordinateurs pouvant communiquer par le biais d'un réseau informatique; un des ordinateurs, appelé le serveur (18), contrôlant les opérations d'analyse syntaxique, de génération syntaxique, de validation, de simulation et de transformation pour le compte d'un autre ordinateur, appelé client (17) ; l'utilisateur du client (17) pouvant avoir à s'authentifier auprès du serveur (19) afin que celui-ci vérifie si l'utilisateur est autorisé à bénéficier de ce service; le client (17) hébergeant les documents du modèle (1) et exécutant les opérations d'analyse et de génération syntaxique. 2889881 22 11) Système selon l'une des revendications précédentes caractérisé en ce que la partie du système s'exécutant sur le client (17) n'envoie au serveur (18) que des données dont l'interprétation par l'organisation opérant le serveur (18) est rendue impossible grâce à un mécanisme d'obscurcissement; ceci de façon à protéger la confidentialité des documents du modèle (1) ; chaque ordinateur client (17) étant capable d'inverser le mécanisme d'obscurcissement pour les données renvoyées par le serveur (18) . 12) Système selon l'une des revendications précédentes caractérisé en ce que l'ordinateur client (17) n'a pas la possibilité d'accéder aux modules contenant les définitions sémantiques (3) et aux modules contenant les définitions des opérations de transformation, de simulation et de validation (4) ; de façon à ce que ces modules ne puissent pas être copiés ou produits par l'utilisateur ou l'organisation opérant l'ordinateur client (17) ; empêchant ainsi quiconque de bénéficier des services de validation, de simulation et de transformation du système sans y être autorisé.