Brevet FR2887348A1 — publié le 20061222

La présente invention concerne une structure de données compatible avec un formalisme de modélisation d'objets, par exemple la notation UML, ainsi qu'un procédé de traitement de données pour créer un modèle UML ou générer du code. Dans la présente description, les termes suivants sont employés avec le sens indiqué, sauf mention contraire: - application informatique : désigne tout programme ou tout ensemble de programmes prévus pour fonctionner conjointement, dont le but est de rendre des services à leurs utilisateurs. - classe : désigne la notion de classe communément manipulée dans les formalismes de modélisation et langages de programmation orientés objet et notamment l'agrégation de données et de traitements (ou attributs et méthodes, respectivement) destinés à fonctionner ensemble dans une application informatique. Dans les langages orientés objet, chaque type d'objet est définie par sa classe. Une classe représente l'ensemble des objets partageant les mêmes attributs, opérations, méthodes, relations et sémantiques. - ligne : une expression ou suite d'expressions d'un langage symbolique fournissant un renseignement déterminé à un programme de destination, par exemple au compilateur. - conteneur : en programmation orientée objet, un objet comprenant d'autres objets, tel qu'un dictionnaire, et qui fournit les opérations pour accéder à son contenu. Il peut aussi s'agir d'un composant comprenant d'autres composants. - code source : texte écrit dans un langage de programmation ou de description qui est ensuite compilé en langage machine afin d'être exécuté par une plate-forme informatique matérielle, ou interprété par un environnement logiciel ou matériel d'interprétation. - code : désigne indifféremment du code source ou du code compilé. - compilation : action de traduction d'une description exprimée dans un langage de programmation vers le langage natif d'une plate-forme informatique matérielle, avant son exécution par cette plate-forme informatique matérielle. - déclaratif : se dit de données réunies sans que soit indiqué ni nécessaire l'ordre dans lequel elles doivent être utilisées. Lorsque cet ordre est indiqué, la représentation n'est plus déclarative mais procédurale. Les deux notions se recouvrent généralement, au sens ou un langage peut comprendre des parties déclaratives et d'autres parties procédurales. - DTD : (pour document type definition ou définition de type de document), désigne un modèle de structure logique d'un document, permettant de fixer les éléments devant composer le document ainsi que la nature des liens devant relier ces éléments. On utilise également le mot anglais schema . - génération de code : désigne ici la production automatique ou semiautomatique de code source pour une application informatique, au moyen d'un générateur. Elle se fait à partir d'une description abstraite d'une d'application logicielle fournie au générateur et servant à piloter cette génération. Celui-ci, après analyse de cette description, construit le code attendu en sortie. Cette description est généralement exprimée dans un langage de plus haut niveau que celui dans lequel le code sera produit. Ainsi on fait souvent le choix d'un langage le plus proche possible de l'expression naturelle humaine, soit sous forme graphique soit sous forme textuelle. Ainsi on peut exploiter le générateur sans avoir à connaître le formalisme du langage de programmation utilisé dans le code généré. - héritage : relation attachant deux classes dans laquelle une classe de base hérite des propriétés (attributs et méthodes) d'une classe-mère , et permettant à la première d'enrichir sa propre définition avec celle de la seconde, tout en conservant toutes ses caractéristiques d'origine. Un héritage est enrichissant (on ajoute à la classe qui hérite les propriétés de la classe héritée) et pas appauvrissant (on ne peut pas ne pas hériter de toutes les propriétés de la classe-mère). - HUTN (pour Human-Usable Textual Notation), désigne un standard de I'OMG (Object Management Group) qui permet de créer et modifier des modèles au format texte avec une syntaxe lisible pour l'homme. Cette syntaxe a été conçue dans le but d'être générique, automatisable et compréhensible par l'utilisateur. HUTN est reconnu comme étant plus simple et manifestement plus lisible que XMI car orienté utilisateur , il se rapproche de langages connus tels que Java, C++. - Instance , désigne une occurrence, un exemplaire, un membre individuel 30 d'un type ou d'une classe. Un membre d'une classe est couramment désigné par les termes synonymes d'objet ou d'instance. - langage de programmation : formalisme permettant de décrire des actions destinées à être exécutées par un ordinateur. Ces descriptions sont exécutées par l'ordinateur après compilation ou interprétation. Une application informatique est décrite en utilisant un ou plusieurs langages de programmation. Par le terme langage , on entend tous les formats de représentation permettant de décrire tout ou partie des logiciels afin de contribuer directement ou indirectement à leur construction effective. - métalangage désigne un langage prend pour objet un autre langage et qui le formalise. - métamodélisation renvoi à la spécification d'un langage de modélisation grâce à un autre langage de modélisation (métalangage), un métamodèle étant un modèle représentant la syntaxe d'un langage.- modélisation désigne la représentation abstraite d'un énoncé, d'un problème ou d'un système, réalisée d'une part dans un but de compréhension et de communication de cette compréhension, et d'autre part dans un but de résolution du problème ou d'implémentation concrète du système. - modélisation orientée objet désigne un type particulier de modélisation dans laquelle les éléments de modélisation sont des classes, objets, attributs, méthodes, associations, etc. par opposition à "modélisation fonctionnelle" dans laquelle les éléments de modélisation sont des fonctions de traitement et des flux de données. Voir aussi UML . - MOF (pour Meta Object Facility) est un langage de métamodélisation proposé par l'OMG et utilisé pour spécifier la syntaxe d'UML et d'autres langages de 20 modélisation. - OMG (pour Object Management Group ), désigne une organisation dont l'un des buts est de définir des standards afin de garantir la compatibilité entre des applications programmées à l'aide de langages orientés objet (cf. http://www.omg.org). - objet : désigne, en modélisation ou en programmation orientée objet, une instance de classe, constitué d'un ensemble de données (les propres données définitoires de la classe) et des procédures utiles à leur manipulation. - orienté objet , se dit par exemple d'un modèle, d'un langage, d'une application ou d'éléments d'applications dont les constituants sont des classes et des objets. Par exemple un langage orienté objet est un langage de programmation dans lequel les composants de base sont des classes, dont les instances les objets vivent dynamiquement dans le programme informatique qui les utilise. - paquetage (de l'anglais Package, ce dernier étant le plus couramment usité dans l'art) : désigne tout d'abord un ensemble d'éléments de modélisation (classes ou autres paquetages...) qui sont regroupés afin d'être réutilisés ou de mieux organiser un modèle. Une fois le modèle codé dans le langage de programmation, le paquetage désigne un répertoire (un dossier) de l'ordinateur qui contient des classes ou d'autres paquetages. - programmation orientée objet : type particulier de programmation dans lequel on utilise un langage orienté objet (par exemple Java, C++, C# ou Eiffel) manipulant des classes et des objets par opposition à "programmation classique" non objet dans laquelle on ne manipule que des structures de données simples et des "fonctions" de traitement séparées (par exemple C, COBOL, FORTRAN). - SGML : un langage normalisé permettant de décrire les relations entre le contenu d'un document informatique et sa structure. - stéréotype (stereotype), désigne un type d'élément de modélisation qui étend la sémantique du métamodèle. Les stéréotypes doivent être basés sur certains types ou classes existants dans le métamodèle. Les stéréotypes peuvent étendre la sémantique, mais pas la structure des types et des classes préexistants. Certains stéréotypes sont prédéfinis dans le langage UML, d'autres peuvent être définis par l'utilisateur. Les stéréotypes constituent, avec les "tagged values" et les "annotations", un des trois mécanismes d'extension du langage UML. - UML (Unified Modeling Language, que l'on peut traduire par langage de modélisation unifié) : désigne une notation (plutôt qu'un langage) de modélisation par objets, permettant de déterminer et de présenter les composants d'un système objet lors de son développement, ainsi que, le cas échéant, d'en générer la documentation. UML est actuellement la norme OMG. Il résulte de la fusion des travaux de Jim Rumbaugh, Grady Booch et Ivar Jacobson et connaît de nombreuses évolutions. - XMI (pour XML Model Interchange), permet de spécifier des règles de correspondances entre métamodèle et "schema". XMI est le standard de l'OMG qui fait la jonction entre le monde des modèles et le monde XML du World Wide Web Consortium (W3C). Il est utilisé pour représenter des modèles UML sous la forme de fichiers XML. - XML : une évolution du langage SGML, laquelle permet notamment aux concepteurs de documents HTML de définir leurs propres marqueurs, dans le but de personnaliser la structure des données. On connaît la modélisation dite modélisation objet , qui consiste à créer une représentation d'éléments du monde réel en termes de classes et d'objets, indépendamment de tout langage de programmation. Par exemple, des classes d'objets sont déterminées, leurs données propres et les fonctions qui les utilisent sont isolées. Divers formalismes existent. UML est l'un de ces formalismes (il s'agît en fait plutôt d'un catalogue de notations). Les langages orientés objet constituent chacun une manière spécifique d'implémenter le concept de classe. En particulier, un formalisme ou une méthode objet permet de définir un problème à haut niveau d'abstraction sans rentrer dans les spécificités d'un langage donné. Il offre également, via UML, un outil permettant aisément de représenter un problème de façon graphique, le rendant plus accessible aux différents acteurs intervenant dans sa résolution. Typiquement, il est tout d'abord procédé à une conception abstraite d'un modèle objet, par exemple en vue de la résolution d'un problème donné. Ensuite, il est procédé à l'implémentation du modèle à l'aide d'un langage orienté objet (tel que le langage C# ou Java). Il est donc préférable qu'un formalisme objet soit défini le plus rigoureusement possible, de préférence qu'il soit unique et ce, afin de restreindre au maximum les ambiguïtés. Parmi les différentes notations qui ont été développées, UML s'est imposé dans le courant des années 90, en tant que norme de l'OMG. On connaît par ailleurs des outils permettant d'effectuer une analyse grammaticale d'un texte, par exemple Grammatica, qui est un vérificateur grammatical et orthographique de textes français et anglais. Outre des suggestions, il fournit des explications. Grammatica analyse la fonction des mots (texte et liens grammaticaux, homophones et homographes, synonymes et définition en français). Le lecteur peut consulter le site www.zdnet.fr. Autre exemple, les outils de Lexiquest, qui font de l'analyse de texte et du "text mining" : www.lexiquest.com. On connaît aussi des outils permettant de générer du code, à partir d'une représentation interne propriétaire, non publiée et non accessible à l'utilisateur (par exemple Rational Rose de IBM, Objecteering de Softeam, Rhapsody de i-Logix). Pour effectuer une génération de code, les générateurs de code existants se fondent sur des descriptions de plus haut niveau que le niveau du code à produire. Elles reposent souvent sur des modélisations telles qu'UML et ces générateurs permettent d'en générer le code dans un langage de programmation donné. A titre d'exemple, l'outil Rational Rose est l'un des outils permettant de réaliser une modélisation abstraite d'une application informatique en utilisant UML. La notation UML, telle qu'elle est actuellement normalisée, ne dispose d'aucune notation textuelle permettant de représenter les modèles objets; seule une représentation graphique est proposée dans la norme pour les différents diagrammes d'UML (diagramme de classes, d'interactions, d'états-transitions, etc.) mais aucune contrepartie textuelle de cette représentation graphique n'est proposée dans la norme UML. XMI n'a pas été conçu pour être lisible , c'est-à-dire qu'il n'est pas compréhensible par un utilisateur. Par ailleurs, il n'est pas autosuffisant. La syntaxe HUTN a été conçue dans le but d'être compréhensible par l'utilisateur. II reste que HUTN est un langage procédural, c'est-à-dire que l'ordre des lignes est d'une importance critique pour l'interprétation de ce langage. Dans ce contexte, il serait particulièrement souhaitable de disposer d'une structure de données, exploitable informatiquement qui permette de représenter des modèles UML ainsi qu'une génération facilitée de programmes sources, dans un langage objet quelconque. Il serait également souhaitable que cette structure de données soit simple et légère à manipuler et, une fois réifiée, compréhensible par l'utilisateur. A cette fin, l'invention propose une structure de données compatible avec un formalisme de modélisation d'objets, ce formalisme comprenant une pluralité d'éléments de modélisation, dans laquelle: la structure de données comprend une pluralité de clauses, chacune de ces clauses est associée à un ou plusieurs élément de modélisation du formalisme, et chacune de ces clauses est entièrement déclarative. Dans des modes de réalisation préférés, la structure de données selon l'invention comprend une ou plusieurs des caractéristiques suivantes: chacune desdites clauses se rapporte à un seul élément de modélisation; chacune desdites clauses comprend un code relatif à l'élément de 30 modélisation auquel elle se rapporte et des caractéristiques relatives à cet élément de modélisation; - certaines desdites clauses comprennent des caractéristiques relatives à un conteneur de l'élément de modélisation auquel elle se rapporte; le formalisme de modélisation d'objets est la notation UML; - l'un des élément de modélisation du formalisme est: un package, un use case ou cas d'utilisateur, une classe, un attribut, une association, ou un héritage. L'invention concerne également un produit de programme d'ordinateur adapté 10 à valoriser, à accéder et/ou à manipuler la structure de données selon l'invention. L'invention concerne en outre un fichier lisible par ordinateur, comprenant une représentation de la structure de données selon l'invention. L'invention propose en outre un procédé de traitement de données comprenant: une étape de valorisation de la structure de données selon l'invention. Dans des modes de réalisation préférés, le procédé selon l'invention comprend une ou plusieurs des caractéristiques suivantes: le procédé comprend, en préalable à l'étape de valorisation, une étape de décomposition de données en éléments de modélisation du formalisme; et un élément de modélisation du formalisme est représenté comme une clause de la structure de données, lors de l'étape de valorisation de la structure de données; l'étape de décomposition de données comprend une analyse grammaticale d'un texte; l'analyse grammaticale à l'étape de décomposition comprend chacune des sous étapes suivantes: découpage du texte en phrases, résolution d'énumérations, par exemple des énumérations introduites par et , ou , ainsi que ou soit... soit , résolution de subordonnées, par exemple des subordonnées introduites par qui , que , dont , où , à ou aux , élimination de certains mots selon des critères donnés, à l'issue de la sous étape de résolution de subordonnées, résolution de formes canoniques de noms, résolution de cardinalités de noms et résolution d'attributs; 25 30 le procédé comprend, après l'étape de valorisation: une étape de création d'un modèle XMI via un générateur XMI à partir de la structure de données; le procédé comprend, après l'étape de création du modèle XMI une étape de production d'un modèle UML à partir du modèle XMI créé ; et le procédé comprend, après l'étape de valorisation: une étape d'accession à la structure de données et une étape de génération d'un code. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit des modes de réalisation de l'invention, donnés à titre d'exemple uniquement et en références à des exemples, ainsi qu'aux schémas annexés, qui montrent: Figure 1: un exemple de représentation d'un modèle UML; Figure 2: un diagramme représentant schématiquement certaines étapes d'un procédé de traitement de données selon un mode de réalisation de l'invention; et Figure 3: un exemple de représentation d'un modèle UML obtenu par la mise en oeuvre du procédé de traitement de données selon un mode de réalisation de 20 l'invention, à partir d'un texte de référence. L'invention propose une structure de données. Par structure de données , on entend tout d'abord la structure effective des données telles qu'elles sont manipulées dans la représentation interne d'un programme qui les exploite. On entend cependant également par structure de données la structure des informations présentes dans un fichier, telle qu'elle apparaîtrait lors de l'édition de ce fichier ou lors de son impression. Ce fichier pourrait par exemple être un fichier de réification de la structure de données ci-dessus, telle qu'entendue dans son premier sens. Cette structure de données est la représentation interne d'un formalisme de modélisation d'objets comprenant une pluralité d'éléments de modélisation. Par représentation d'une notation de modélisation d'objets , on entend que l'exploitation de la structure de données permet notamment une représentation graphique selon ce formalisme notation. Ce dernier pourrait par exemple se restreindre à la notation UML, auquel cas les éléments de modélisation sont les éléments classiquement manipulés par UML, c'est-à-dire des paquetages, classes, attributs, opérations, associations, cardinalités, héritages, etc. La structure de données selon l'invention comprend une pluralité de clauses, par exemple des clauses logiques vaforisables ou manipulables par un programme. Chacune de ces clauses est associée à un ou plusieurs élément(s) de modélisation du formalisme et chacune de ces clauses est entièrement déclarative. Cette structure de données est simple. Une fois la structure de données réifiée, par exemple dans un fichier, chaque clause devient une ligne de ce fichier, utilisant une notation formelle. Or, étant donné que chaque clause est entièrement déclarative, l'ordre de ces clauses et par conséquent l'ordre des lignes du fichier, n'affecte pas leur interprétation. La compréhension du fichier par un utilisateur s'en trouve simplifiée. De préférence, chaque clause correspond à un seul élément de modélisation, ce qui simplifie à la fois le traitement algorithmique de la structure de données ainsi que la compréhension par l'utilisateur d'un fichier construit à partir de cette structure de données. En outre, chaque clause est de préférence autosuffisante, de sorte à en permettre l'interprétation sans devoir accéder pour cela à une autre clause. La structure de données selon l'invention se représente par une notation formelle de haut niveau. Ceci permet la mise en oeuvre de procédés de traitement de données à la fois simples et intégrés. Il peut s'agir par exemple de procédés pour transcrire et représenter des modèles UML, lesquels sont habituellement décrits sous la forme de diagrammes et de schémas graphiques auxquels sont associés des textes non formels et dont la structure n'est pas normalisée. La structure de données selon l'invention permet en fait, via des traitements informatiques appropriés, de produire facilement aussi bien des modèles objets conformes à UML, que des programmes sources, dans un langage objet quelconque (Java, C++, C#, Ada, etc.). Ceci sera détaillé plus loin dans la description. Cette structure de données se substitue ainsi avantageusement aux alternatives actuellement proposées, qui, s'appuyant sur XMI/XML ou sur HUTN, n'offrent pas d'outil 30 qui soit à la fois simple, léger et apte à générer facilement du code. Dans ce qui suit, la notation formelle évoquée plus haut est dénotée par l'acronyme FIL (pour format interchange language ou encore Format Internai modeling Language ). En outre, la structure de données selon l'invention est décrite en référence à un fichier de réification de cette structure de données, pour des raisons d'intelligibilité. Il n'en demeure pas moins qu'à une ligne de ce fichier peut correspondre une clause logique, interprétable par un programme informatique. Dans un mode de réalisation, chaque ligne FIL du fichier comprend un code relatif à l'élément de modélisation auquel elle se rapporte, le cas échéant un simple caractère précisant le type d'élément décrit. On pourra par exemple utiliser le caractère a pour un attribut, c pour classe, h pour héritage, r pour relation, etc. Chaque ligne comprend en outre un corps comprenant des caractéristiques relatives à cet élément. Ceci permet de disposer d'une structure apte à une exploitation de la ligne par une application informatique. Le repérage de l'élément par l'utilisateur est en outre facilité par la présence du code correspondant. Considérons par exemple la phrase suivante: un chat mange des souris . Cette phrase établi une relation entre un chat et des souris . Cette relation peut être codée, selon la notation FIL, dans la ligne suivante: r: chat (1..1) manger (1..n) souris où le caractère r précise que l'élément de modélisation en question est une relation, (1..1) et (1..n) renvoient aux cardinalités correspondant respectivement à (un) chat et (des) souris. D'autres exemples seront largement détaillés par la suite. De préférence, le corps de certaines lignes FIL comprend deux parties, la première comprenant des caractéristiques intrinsèques à l'élément de modélisation (par exemple une valeur de type pour un attribut) et la deuxième partie comprenant des caractéristiques relatives à un conteneur de l'élément de modélisation. On déclare ainsi un élément, directement en liaison avec son conteneur. Cependant, la déclaration a trait principalement audit élément de modélisation, le conteneur pouvant faire l'objet d'une déclaration indépendante. Ainsi, les déclarations correspondantes (c'est-à-dire des clauses ou des lignes de fichier) restent indépendantes. De la sorte, on met en place une structure de fichier permettant ultérieurement à une application de reconstruire des hiérarchies entre les divers éléments. Les exemples détaillés qui suivent entrent dans le cadre d'un mode de réalisation particulier, dans lequel les lignes FIL sont triées par type, pour des raisons de lisibilité, par exemple dans l'ordre indicatif suivant: packages, classes, attributs, opérations, associations, héritages. Ceci permet d'appréhender plus facilement les éléments ainsi que leurs relations. Il convient néanmoins de garder à l'esprit que ces lignes peuvent être déclarées ou stockées en mémoire dans un ordre quelconque. De préférence, les codes précisant les éléments se réduisent à une lettre, minuscule, en première position sur la ligne. Un caractère : (deux points) figure immédiatement après, suivi d'un espace, comme illustré dans l'exemple ci-dessus. En outre, une virgule (s'il y en a une) est toujours suivie d'un espace. D'autres règles de syntaxe peuvent en outre être observées, comme il apparaîtra dans ces exemples. Le cas échéant, un outil informatique d'exploitation, i.e. de production et/ou de traitement d'une structure de données selon l'invention, est utilisé. Cet outil peut être adapté à valoriser la structure de données, c'est-à-dire à affecter des valeurs correspondant aux données. Il peut en outre être adapté à accéder cette structure, c'est-à-dire à pouvoir en extraire des valeurs et/ou à manipuler la structure de données (soit en remplacer les valeurs). En particulier, cet outil est adapté à interpréter les lignes FIL d'un fichier. Le cas échéant, il peut être muni de routines chargées de corriger ou d'interpréter des défauts de syntaxe ou des syntaxes incomplètes. Les lignes peuvent être stockées en mémoire dans un ordre quelconque. Exemple 1 La déclaration d'un attribut se fait comme suit: a: nom attribut, nom de classe où nom attribut et nom de classe renvoient logiquement au nom de l'attribut et de la classe à laquelle appartient l'attribut, la virgule faisant office de séparateur. Exemple 2 a: nom attribut:type, nom de classe Dans cet exemple, un attribut est déclaré avec son type. De préférence, il n'y a pas d'espace, ni avant, ni après :type . Les types standard sont par exemple String , boolean , int ou integer , Date , comme il est usuel dans l'art. D'autres types peuvent être utilisés, y compris les noms des classes décrites dans la notation elle-même. On aura alors par exemple: a: nom attribut:classe un, classe deux Exemple 3 a: attribut=valeur, nom de classe Ici, une valeur initiale est affectée à l'attribut. Il n'y a de préférence pas d'espace, ni avant ni après le signe égal. On peut noter qu'une syntaxe incomplète (à l'instar de l'exemple ci-dessus où il manque le type de l'attribut) pourra avantageusement être interprétée par outil informatique d'exploitation. Par exemple, l'outil en question peut être conçu de sorte à interpréter et trouver automatiquement le type qui convient en tenant compte de plusieurs critères. Ces critères peuvent par exemple se baser sur le nom de l'attribut lui-même, tel que "numéro", "montant", "compteur", etc., l'outil d'exploitation proposant alors par défaut le type "integer". Ils peuvent par ailleurs se baser sur la valeur associée à l'attribut. Par exemple, si la valeur est "vrai , "faux", "true" ou "false", le type proposé est "boolean"; si la valeur est numérique, le type proposé est "integer" ou "real" selon qu'elle contient ou non des décimales; si la valeur est entourée de doubles quotes " ", le type proposé est "String" (pour chaîne de caractères), etc. Ainsi, dans de nombreux cas, la mention du type peut être superflue, car le type peut être rétabli par l'outil. Exemple 4 a: attribut:type=valeur, nom classe Dans cet exemple, la syntaxe est complète. Exemple 5 c: nom de classe[, nom de package] Ici, une classe est déclarée, ainsi que [, son package d'appartenance]. Les crochets indiquent ici le caractère optionnel de la mention du nom de package. Par exemple, si le package n'est pas mentionné et s'il n'y a pas de package précédemment rencontré,la classe pourra être rangée systématiquement dans un package donné, par exemple le package "p_système", qui sera alors considéré comme le package de plus haut niveau. Ce package peut par exemple exister par défaut et n'être utilisé que si une classe n'a pas de package destinataire. Le cas échéant, si le nom de package n'est pas mentionné, la classe peut être rangée dans le dernier package p: rencontré dans le fichier FIL, par l'outil informatique d'exploitation. Notons que la notion d'ordre intervient ici uniquement pour suppléer à un défaut de syntaxe de la part de l'utilisateur. De même, la déclaration explicite d'une classe avec c: peut être omise, en adaptant l'outil informatique d'exploitation de sorte à ce que les classes soient reconnues et déclarées automatiquement à partir d'attributs, d'opérations, d'associations et d'héritages. Le code c: est cependant utilisé par l'outil informatique d'exploitation pour le fichier FIL généré en sortie. En revanche, on pourra avantageusement utiliser explicitement le code c: pour déclarer une classe avec stéréotype (voir ci-dessous) ou pour forcer l'appartenance d'une classe à un package. Exemple 6 c: > nom de classe[, nom de package] Ici, une classe est déclarée avec un stéréotype [, et son package d'appartenance]. On peut également associer, si nécessaire, un stéréotype aux packages, aux attributs, aux opérations et aux associations. Exemple 7 h: nom de classe 1 est-un nom de classe 2 Dans ce nouvel exemple, un héritage est déclaré, à l'aide d'un mot-clé. Le mot-clé utilisé, nécessaire à la déclaration de l'héritage, est est-un . Il convient de noter que le code h: peut être omis. S'il n'est pas présent, le code peut être automatiquement ajouté par l'outil informatique d'exploitation, lequel interprète la ligne FIL comme se rapportant à un élément d'héritage, du fait de la présence du mot-clé correspondant. La ligne peut donc être entrée simplement comme dans l'exemple suivant: carré est-un élément graphique . Exemple 8 o: nom opération, nom de classe Ici, une opération est déclarée. Une seule virgule est nécessaire, suivie d'un espace. Exemple 9 p: nom de package[, package englobant] Ici, un package est déclaré, comme appartenant au package englobant nommé package englobant . La mention du package englobant est optionnelle. Exemple 10 r: nom de classe 1 (1..1) nom d'association (1..n) nom de classe 2 Cet exemple illustre une manière de préciser la cardinalité. Deux nombres sont utilisés, à chaque bout de l'association et entre parenthèses. Selon le cas, l'instruction commence par (1 , (0 , (m ou (n et se termine par 1) ou n) . Un espace est prévu avant et après. En ce qui concerne le nom de l'association ou de la classe, celui-ci peut être quelconque, composé par exemple de un ou plusieurs mots. Là encore, un espace est prévu avant et après ce nom. En outre, si le nom d'association est estcomposé-de ou contient , une agrégation pourra automatiquement être générée dans un outil UML utilisé ultérieurement. De plus, de même que le code h: , le code r: n'est pas obligatoire, l'outil informatique d'exploitation étant au besoin adapté à interpréter une association comme telle, en repérant une codification de cardinalité. Par exemple, la ligne système (1..1) est-composé-de (1..n) sous-système pourrait directement être interprétée comme décrivant une association est-composé-de (agrégation). Exemple 11 u: nom de cas d'utilisation, nom de package La déclaration d'un cas d'utilisation (ou use case ), permet aussi de déclarer 20 une fonction du système, pouvant correspondre à un ou plusieurs cas d'utilisation. La figure 1 montre un exemple de représentation d'un modèle UML. En référence à cette figure, considérons l'exemple suivant c: chat, exemple c: souris, exemple r: chat (1..1) manger (1..n) souris Selon la notation UML, les clauses cidessus se représentent comme illustré sur la figure 1. Dans cette figure, les classes chat et souris sont symbolisées par des étiquettes 10, 20. Les cardinalités 12, 22 correspondantes figurent à proximité. La relation ci-dessus (r: chat (1..1) manger (1..n) souris) est symbolisée par la flèche 30. La figure 2 montre un diagramme représentant schématiquement certaines étapes d'un procédé de traitement de données selon un mode de réalisation de l'invention. En préalable à la description détaillée de cette figure sont résumées les idées directrices ayant conduit à l'élaboration du procédé de traitement de données selon l'invention. La simplicité de la notation FIL permet d'envisager de créer une structure de données ou un fichier reflétant cette notation et ce, directement à partir de l'analyse d'un texte écrit en langage naturel. Le fichier créé pourra ainsi servir de base à la création d'un objet UML ou à la génération d'un programme source, comme illustré dans la chaîne suivante: (1) texte -> (2) structure de données au format FIL -> (3) modèle objet UML ou 10 code source. Cette idée s'appuie sur la conjecture suivante: les phrases d'un texte - à condition qu'elles soient construites selon le canon sujet-verbecomplément - expriment des relations entre des objets au sens de l'approche objet. Par exemple, les substantifs représentent des objets et les verbes expriment une relation entre ces objets. On peut se référer à un exemple traité ci-dessus: un chat mange des souris . Les objets étant des instances de classes, il est possible de déduire une relation liant des classes entre elles à partir de la relation qui lie ces objets, en particulier si les articles utilisés sont indéfinis ( un ou des à la place de le ou les ). Dans l'exemple le chat bleu mange la souris verte , il est fait référence, dans les deux cas ( chat bleu et souris verte ) à une instance particulière des classes génériques chat et souris . Ainsi, dans l'exemple un chat mange des souris , il est fait référence à des classes; la relation a donc un sens dans le monde objet . Il convient de noter, en corollaire à la conjecture ci-dessus, que la sémantique d'un texte décrit à l'aide de phrases selon le type sujetverbe-complément est contenue dans la syntaxe du texte lui-même. En outre, la sémantique du modèle que l'on souhaite obtenir à partir d'un texte est contenue dans la syntaxe du langage dans lequel ce texte est écrit. Ainsi, on conçoit qu'il est possible, à partir d'un texte, de formaliser de manière simple, en utilisant le texte des phrases elles-mêmes, les relations entre les objets du 30 modèle. Autre conséquence: un traitement approprié (automatique ou semiautomatique) de chaque phrase d'un texte permet de formaliser les relations entre les objets, et de les représenter de manière formelle et simple à l'aide de la notation FIL utilisée pour une structure de données selon l'invention. A cet égard, l'invention propose un procédé de traitement de données, mis en oeuvre au moins partiellement par ordinateur. Ce procédé comprend une étape centrale de valorisation 110 de la structure de données 60 selon l'invention. On entend par valorisation que des valeurs correspondant à des données sont stockées (par exemple dans la mémoire vive de l'ordinateur ou sur un support de mémoire de masse). Une structure de données 60 selon l'invention peut de la sorte être exploitée informatiquement. En particulier, la valorisation 110 de la structure de données 60 peut s'effectuer en deux temps. Il peut tout d'abord être procédé à une étape de décomposition 100 de données en éléments de modélisation du formalisme. Ensuite, un élément de modélisation peut être représenté (c'est-à-dire transformé informatiquement) en une clause correspondante de la structure de données 60. Notons que différentes variantes algorithmiques peuvent être envisagées. Par exemple, dès qu'un élément de modélisation est isolé, il est transformé en clause correspondante. En variante, les éléments peuvent être transformés en clauses après que chacun d'eux ait été identifié. Un mode de réalisation préféré du procédé selon l'invention est décrit dans ce qui suit. Dans ce mode de réalisation, l'étape de décomposition 100 de données comprend une analyse grammaticale d'un texte 50 de référence, par exemple le texte exposant un problème donné ou la spécification d'un système ou d'une application. L'analyse elle-même peut être décomposée en sept étapes principales, lesquelles permettent d'aboutir à un fichier 50 tel que décrit précédemment. 1) Tout d'abord, l'analyse du texte comprend le découpage du texte en phrases (la fin d'une phrase étant indiquée par un point, un pointvirgule ou une marque de fin de paragraphe. 2) Ensuite, il est procédé à une résolution, des énumérations (traitement des terminologies et , ou , ainsi que , soit... soit , etc.). 3) Les subordonnées sont alors résolues (introduites par qui , que , dont 30 , ou , à , aux ,etc.). A ce stade, des phrases simples ont été isolées. 4) Ensuite, il est éventuellement procédé à l'élimination des mots à ignorer dans chaque phrase simple, comme il sera illustré ci-après. 5) Les formes canoniques sont résolues (noms au singulier, verbes à l'infinitif, etc.) 6) Les cardinalités sont alors caractérisées, en tant que marque du singulier (1..1) ou du pluriel (1..n), ceci en vue de la transformation des phrases en lignes FIL. 7) On procède ensuite à la résolution des valeurs d'attributs ou de types d'attributs dans les phrases élémentaires obtenues précédemment et à la finition du modèle. Au final, sont obtenues des phrases élémentaires comprenant deux objets (avec leurs cardinalités respectives) séparés par un groupe verbal; ces phrases sont transformables en clauses FIL pour une exploitation informatique ultérieure. Les étapes précédentes pourront être mieux comprises à travers l'exemple suivant, décrit en référence à la figure 3, qui montre un exemple de représentation d'un modèle UML obtenu par la mise en oeuvre du procédé de traitement de données, selon un mode de réalisation de l'invention, à partir d'un texte de référence. Cet exemple (exemple 12) se base sur le texte de référence suivant: Une application permet d'invoquer des services élémentaires, des composants de services ou une autre application que l'on peut télécharger depuis un serveur distant. Un composant de service comprend plusieurs services élémentaires. 1) Découpage du texte en phrases d'origine Le texte comprend deux phrases d'origine, qui sont identifiées: (i) Une application permet d'invoquer des services élémentaires, des composants de services ou une autre application qui peuvent être téléchargés depuis un serveur distant. (ii) Un composant de service comprend plusieurs services élémentaires. 2) Résolution des énumérations Ce traitement est basé sur les résultats d'une analyse grammaticale de la phrase, effectuée à l'aide d'un analyseur grammatical. A l'issue de l'analyse grammaticale, une subordonnée introduite par la conjonction "qui" est détectée. Le traitement subséquent du texte, prenant en compte dans un premier temps la résolution des énumérations mais pas celle des subordonnées, permet de construire et de disposer désormais des trois phrases suivantes: (i) Une application permet d'invoquer des services élémentaires qui peuvent être téléchargés depuis un serveur distant. (ii) Une application permet d'invoquer des composants de services qui peuvent être téléchargés depuis un serveur distant. (iii) Une application permet d'invoquer une autre application qui peut être téléchargé(e) depuis un serveur distant. (iv) Un composant de service comprend plusieurs services élémentaires. 3) Résolution des subordonnées Ce traitement est également basé sur les résultats d'une analyse grammaticale de chacune de ces nouvelles phrases. Lors de cette étape, chacune des phrases précédentes est à nouveau passée dans l'analyseur grammatical, afin de résoudre les subordonnées. Deux phrases simples sont identifiées en lieu et place de chaque phrase comportant une subordonnée. Le sens premier du texte n'est pas trahi (il y a conservation sémantique ), mais la structure de chaque phrase devient plus simple: on s'approche ainsi peu à peu d'un texte modélisable. Le résultat de cette étape est le suivant: (i) Une application permet d'invoquer des services élémentaires. (ii) Des services élémentaires peuvent être téléchargés depuis un serveur distant. (iii) Une application permet d'invoquer des composants de services. (iv) Des composants de services peuvent être téléchargés depuis un serveur distant. (v) Une application permet d'invoquer une autre application. (vi) Une autre application peut être téléchargé(e) depuis un serveur distant. (vii) Un composant de service comprend plusieurs services élémentaires. Le résultat de l'analyse grammaticale de chaque phrase peut être stocké par l'outil informatique d'exploitation évoqué plus haut. 4) Elimination des mots non signifiants Chacune des phrases simples ainsi obtenues est, à présent, éventuellement passé par un filtre permettant d'éliminer des mots non signifiants, qui sont repérés par l'examen d'un dictionnaire spécifique, le cas échéant paramétrable. Ces mots sont supprimés dans un but de simplification des phrases, car ils n'apportent aucune information pertinente. Ici par exemple, le mot autre sera supprimé dans les cinquième et sixième phrases. (i) Une application permet d'invoquer des services élémentaires. (ii) Des services élémentaires peuvent être téléchargés depuis un serveur distant. (iii) Une application permet d'invoquer des composants de services. (iv) Des composants de services peuvent être téléchargés depuis un serveur distant. (v) Une application permet d'invoquer une application. (vi) Une application peut être téléchargé(e) depuis un serveur distant. (vii) Un composant de service comprend plusieurs services élémentaires. 5) Résolution des formes canoniques Le résultat de l'analyse grammaticale de chaque phrase simple est conservé en mémoire. L'examen de ces résultats permet de déterminer les formes canoniques des substantifs et des verbes (noms au singulier, verbes à l'infinitif). Lors de cette étape intermédiaire, on conserve également, pour chaque substantif, une marque associée au nombre correspondant dans la phrase. Par exemple, (sing) pour dénoter le singulier, peut être placé après le substantif, et (plusieurs) pour dénoter le pluriel, placé avant. Ce choix de disposition répond à un double objectif: d'abord, permettre de faciliter l'étape suivante, lors de laquelle les cardinalités seront identifiées, ensuite, aider à l'identification des associations; en effet, une association sera constituée à partir du membre de phrase (souvent un verbe) qui sera situé entre les deux marques de cardinalité. Les phrases obtenues sont les suivantes. (i) application (sing) permettre d'invoquer (plusieurs) service élémentaire (ii) service élémentaire (plusieurs) pouvoir être téléchargé depuis (sing) serveur distant (iii) application (sing) permettre d'invoquer (plusieurs) composant de services (iv) composant de services (plusieurs) pouvoir être téléchargé depuis (sing) serveur distant (v) application (sing) permettre d'invoquer (sing) application (vi) application (sing) pouvoir être téléchargé depuis (sing) serveur distant (vii) composant de service (sing) comprend (plusieurs) service élémentaire 6) Pose des cardinalités Un traitement simple permet à présent de remplacer les marques (sing) et (plusieurs) par les cardinalités correspondantes: (1..1) et (1..n). Chacune des 5 phrases précédentes devient ainsi une clause FIL: (i) application (1..1) permettre d'invoquer (1..n) service élémentaire (ii) service élémentaire (1.. n) pouvoir être téléchargé depuis (7..1) serveur distant (iii) application (1..1) permettre d'invoquer (1..n) composant de services 10 (iv) composant de services (1..n) pouvoir être téléchargé depuis (1.. 7) serveur distant (v) application (7..1) permettre d'invoquer (1..1) application (vi) application (1.. 1) pouvoir être téléchargé depuis (1..1) serveur distant (vii) composant de service (7.. 7) comprend (1..n) service élémentaire Bien entendu, les deux étapes (5) et (6) peuvent être vues comme une seule étape. 7) Valeurs des attributs et finition du modèle Cette étape peut regrouper trois traitements distincts. Tout d'abord, des adjectifs associés aux substantifs sont recherchés et positionnés en tant qu'attributs de classe (c'est-à-dire en tant que caractéristiques spécifiques de cette classe). Ceci donne lieu à l'attribution des codes a pour attribut . En outre, l'attribut pourra être associé à la classe correspondante. Ensuite, des déclarations de classe sont créées automatiquement pour chaque substantif, d'où l'apparition de code FIL c pour classe . Enfin, un package pourra être associé à chaque classe. Le code FIL r (pour relation ) est alors associé à chacune des clauses FIL décrivant une relation. Les clauses FIL peuvent ensuite être triées par type, pour des raisons de lisibilité 30 et de présentation, bien que cela n'ait rien d'obligatoire. On obtient ainsi le modèle FIL final: p: exemple c: application, exemple c: service, exemple c: composant de services, exemple c: serveur, exemple a: élémentaire=VRAI, service a: distant=VRAI, serveur r: application (1.. 1) permettre d'invoquer (1..n) service r: service (Ln) pouvoir être téléchargé depuis (1..1) serveur r: application (1..1) permettre d'invoquer (1..n) composant de services r: composant de services (1..n) pouvoir être téléchargé depuis (1..1) serveur r: application (1..1) permettre d'invoquer (1..1) application r: application (1..1) pouvoir être téléchargé depuis (1..1) serveur r: composant de services (1..1) estcomposé-de (1..n) service Sur la figure 3, les éléments ci-dessus sont représentés sous la forme d'un 15 modèle UML. Dans ce modèle, la classe application fait l'objet de la référence 200. La classe application est impliquée dans les relations 210, 220, 230 et 240, selon les éléments r évoqués ci-dessus. Ces relations relient la classe application à la classe application elle- même, ainsi qu'aux classes composant de service 300, service 400 et serveur 500, qui sont à leur tour impliquées dans les relations 305, 310 et 410. En ce qui concerne les classes composant de service 300 et service , on peut noter la relation particulière: est-composé-de 305, soit une "agrégation" en UML et qui se distingue graphiquement des autres relations par la présence d'un losange à la base de la flèche correspondante, comme il est usuel dans l'art. En ce qui concerne les classes service 400 et serveur , il convient également de noter les attributs, types et valeurs de types représentés dans les étiquettes respectives 402 et 502, reflétant la décomposition décrite ci-dessus. En se référant à présent de nouveau à la figure 2, le procédé de traitement de données selon l'invention peut comprendre, après l'étape de valorisation 110, une étape de création 120 d'un modèle XMI 70, à partir de la structure de données 60, via un générateur XMI. Ce générateur XMI pourrait par exemple fonctionner selon le même principe que le générateur de code évoqué ci-après: après avoir accédé au contenu de la structure de données, le générateur stocke cette structure dans sa propre mémoire interne puis transforme son contenu selon des règles de transformation qui lui sont propres, qui sont paramétrables et qui ne dépendent que des seules correspondances que l'on veut établir entre deux métamodèles: d'une part le métamodèle de la structure de données FIL elle-même (structure d'entrée), et d'autre part le métamodèle de la structure de données XMI, Java, C# ou C++ par exemple (structure attendue en sortie). Ainsi, l'outil de génération applique, sur une structure de données stockée en interne, des règles de transformation mettant en correspondance un élément de modélisation d'un métamodèle donné avec un élément de modélisation d'un autre métamodèle. A cet égard, il existe des outils, tels que Model-In-Action de Sodifrance (voir le site www. miasoftware.com), qui permettent de construire de tels générateurs: on décrit les deux métamodèles à l'aide d'UML, puis les règles de transformation en utilisant un langage de haut niveau, et on obtient ainsi très rapidement des transformateurs-générateurs de langage. Grâce à de tels outils, la création d'un modèle XMI via un générateur XMI est possible. Dans le cas présent, le modèle 70 est généré à partir de la structure de données 60 précédemment valorisée. Ensuite, un modèle UML 75 graphique peut être produit à partir du modèle XMI 70 précédent, lors d'une étape de production 130 de modèle. La production d'un modèle UML graphique à partir d'un modèle XMI est, en tant que telle, connue de l'art (on pourra par exemple utiliser des outils tels qu'Objecteering ou Rhapsody, mentionnés plus haut). Par ailleurs, le procédé de traitement de données selon l'invention peut comprendre, après l'étape de valorisation 110, une étape d'accession à la structure de données suivie d'une étape de génération 140 d'un code 80. Lors de cette étape, la structure de données est stockée puis son contenu est transformé selon des règles de transformation paramétrables, qui dépendent des correspondances souhaitées entre deux métamodèles, à l'instar de ce qui a été décrit en référence au générateur XMI. Des principes de transformation sont par exemple décrits dans le livre Design Patterns , Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley Professional, première édition, 1995. A l'issue de cette étape, des Classes Java ou C# sont générées. Celles-ci peuvent avantageusement être exploitée dans un environnement de services 85 intégré. Un environnement de services est un environnement de développement d'applications objet, qui sait lire directement des classes sources Java ou C# par exemple. L'étape 150 est, à cet égard, une simple étape d'import de ces classes 80, correctement générées dans un format lisible directement par l'environnement 85. L'invention n'est cependant pas limitée aux variantes décrites ci avant mais est susceptible de nombreuses autres variations aisément accessibles à l'homme du métier. A titre d'exemple, il est possible d'omettre certaines étapes de l'analyse grammaticale ou de les combiner différemment. REVENDICATIONS 1. Structure de données (60) compatible avec un formalisme de modélisation d'objets, ce formalisme comprenant une pluralité d'éléments de modélisation, dans laquelle: - la structure de données (60) comprend une pluralité de clauses; chacune de ces clauses est associée à un ou plusieurs élément de modélisation du formalisme; et - chacune de ces clauses est entièrement déclarative. 2. La structure de données (60) selon la revendication 1, dans laquelle chacune desdites clauses se rapporte à un seul élément de modélisation. 3. La structure de données (60) selon la revendication 1 ou 2, dans laquelle chacune desdites clauses comprend un code relatif à l'élément de modélisation auquel elle se rapporte et des caractéristiques relatives à cet élément de modélisation. 4. La structure de données (60) selon la revendication 1, 2 ou 3, dans laquelle certaines desdites clauses comprennent des caractéristiques relatives à un conteneur de l'élément de modélisation auquel elle se rapporte. 5. La structure de données (60) selon l'une quelconque des revendications 1 à 5, dans laquelle le formalisme de modélisation d'objets est la notation UML. 6. La structure de données (60) selon l'une quelconque des revendications 1 à 5, dans lequel l'un des élément de modélisation du formalisme est: un package; - un use case ou cas d'utilisateur; une classe; - un attribut; une association; ou un héritage. 7. Produit de programme d'ordinateur, adapté à valoriser, à accéder et/ou à manipuler la structure de données (60) selon l'une quelconque des revendications 1 à 6. 8. Fichier lisible par ordinateur, comprenant une représentation de la structure de données (60) selon l'une quelconque des revendications 1 à 6. 9. Procédé de traitement de données comprenant: - une étape de valorisation (110) de la structure de données (60) selon l'une quelconque des revendications 1 à 6. 10. Le procédé de traitement de données selon la revendication 9, comprenant, en préalable à l'étape de valorisation (110): - une étape de décomposition (100) de données en éléments de modélisation du formalisme; et dans lequel un élément de modélisation du formalisme est représenté comme une clause de la structure de données (60), lors de l'étape de valorisation (110) de la structure de données (60). 11. Le procédé de traitement de données selon la revendication 10, dans lequel l'étape de décomposition (100) de données comprend une analyse grammaticale d'un texte (50). 12. Le procédé de traitement de données selon la revendication 11, dans lequel l'analyse grammaticale à l'étape de décomposition (100) comprend chacune des sous étapes suivantes: - découpage du texte (50) en phrases; résolution d'énumérations, par exemple des énumérations introduites par et , ou , ainsi que ou soit... soit ; -résolution de subordonnées, par exemple des subordonnées introduites par qui , que , dont , où , à ou aux ; - élimination de certains mots selon des critères donnés, à l'issue de la sous étape de résolution de subordonnées; - résolution de formes canoniques de noms; - résolution de cardinalités de noms; et - résolution d'attributs. 13. Le procédé de traitement de données selon l'une quelconque des revendications 9 à 12, comprenant, après l'étape de valorisation (110) : une étape de création (120) d'un modèle XMI (70) via un générateur XMI à partir de la structure de données (60). 14. Le procédé de traitement de données selon la revendication 13, comprenant, après l'étape de création (120) du modèle XMI: - une étape de production (130) d'un modèle UML (75) à partir du modèle XMI (70) créé. 15. Le procédé de traitement de données selon l'une quelconque des revendications 9 à 12, comprenant, après l'étape de valorisation (110) : une étape d'accession à la structure de données (60) ; et - une étape de génération (140) d'un code (80).