FR 2863386 A1 20050610 FR 0314397 A 20031209 PROCEDE DE GENERATION DE CODE C A PARTIR DE SPECIFICATIONS UML La présente invention a pour objet un procédé de génération de code C à partir de spécifications UML. Il existe des générateurs de code C à partir de code UML, tels que celui de la société I-LOGIX, mais le langage C, n'étant pas un code objet, on ne peut pas transcrire directement et automatiquement en code C des concepts objet tels que l'héritage et le polymorphisme. Cette impossibilité limite l'intérêt de l'utilisation de la modélisation en UML pour produire du code C. Les générateurs connus de code C ne produisent que o des squelettes de code ou du code reflétant un usage très limité des concepts UML. La présente invention a pour objet un procédé de génération de code C à partir de spécifications en langage UML d'un modèle, permettant de produire automatiquement la totalité du code C, aussi bien un code statique ( y compris la génération de classes et de relations) qu'un code dynamique (en particulier pour les machines à états), le code produit respectant avantageusement les spécifications Do-178B niveau A. La présente invention a également pour objet un procédé qui garantisse la cohérence complète entre le code C généré et les spécifications écrites dans le modèle UML, qui permette de produire un rapport de génération de code C simultanément avec la génération de ce code, ainsi que des scripts de mise en configuration, avantageusement pour l'outil Clearcase de la société Rational-IBM. Dans le cas de systèmes embarqués, le code C ainsi produit pour de tels systèmes sera directement un logiciel embarqué. Le procédé conforme à l'invention est caractérisé en ce que l'on produit un modèle d'implémentation détaillé en code UML, que l'on structure les données de ce modèle pour les rendre exploitables par l'outil de génération de scripts Mode! In Action (dit MIA et produit par la société Sodifrance), et que l'on fait produire à cet outil des fichiers en langage C, à savoir des fichiers .0 , des fichiers .H , un fichier de rapport de génération, des fichiers batch de gestion de configuration et des fichiers de projet de compilation. Selon une caractéristique avantageuse de l'invention, le code C généré recouvre 100% de la spécification UML du logiciel (le logiciel généré est le logiciel embarqué) à savoir que tout le spectre de génération est traité en statique (relations/classes) comme en dynamique (machines à états). La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: -la figure 1 est un diagramme illustrant les étapes principales du procédé de l'invention, et -la figure 2 est une vue partielle d'un exemple de rapport de génération, correspondant à un fichier de rapport de génération pouvant être produit selon le procédé de l'invention. Dans l'exemple décrit ci-dessous, on établit, de façon classique, un modèle en langage UML à l'aide d'un outil (1) couramment utilisé à cet effet, par exemple l'outil RHAPSODY de la société I-LOGIX. Le modèle ainsi créé est exporté (2) sous forme de fichier (3) en langage XMI. La production du fichier XMI se fait, par exemple, à l'aide d'un outillage d'export tel que le XMI Toolkit de la société I-LOGIX. Le fichier 3 permet d'injecter la structure de données UML dudit modèle dans un moteur de génération de fichiers (4). Ce moteur (4) est ici l'outil Model ln Action (plus simplement dénommé MIA ) de la société SODIFRANCE. Il est associé à une application de paramétrage de scripts (5), dénommée GEN_UML_C, réalisée par le Demandeur. Le moteur (4) met en oeuvre l'application (5) pour produire une série de cinq sortes de fichiers, référencée (6) dans son ensemble, représentant le code C correspondant au modèle de départ. La série 6 de fichiers comprend: des fichiers .0 (7), des fichiers . H (8), un fichier (9) de rapport de génération de code (comme exigé par les spécifications Do précitées), un fichier batch (10) conforme aux spécifications Clearcase et des fichiers (11) de projet de compilation. Les fichiers 7, 8 et 11 étant produits de façon classique, ne seront pas décrits plus en détail. Il est possible de modifier manuellement le corps des méthodes des fichiers .0 générés. Lors des générations suivantes, ces modifications ne seront pas écrasées mais conservées et intégrées dans les nouveaux fichiers générés. Dans une optique MDE (Mode) Driven Engineering) où le modèle et non les fichiers sources sont le coeur du développement, il est préférable de remonter ces modifications manuelles dans le modèle. Il est alors possible d'intégrer ces modifications automatiquement dans le modèle à l'aide de l'outil de roundtrip appelé ReverseC (12). Le fichier de rapport (9) permet de garder l'historique de la génération du code C et de comparer entre elles deux versions de rapports de génération. Dans le cas présent, le rapport est un fichier XML comportant toutes les informations correspondant au modèle UML, les fichiers et packages produits, les scénarios de génération utilisés,.... Un exemple o d'une vue d'écran d'un extrait d'un tel rapport ( Generation report ) est représenté en figure 2. A chaque élément de ce rapport, on associe un ou plusieurs totaux de contrôle ( checksums , par exemple des CRC sur 32 bits) permettant d'effectuer la comparaison entre versions différentes et la détection des modifications entre ces versions, par exemple entre une nouvelle version de génération et une version de référence de génération. A partir des comparaisons ainsi effectuées, on déduit différents états qui fournissent un état de comparaison du fichier examiné. Le tableau ci-dessous fournit ces états de comparaison. Dans ce tableau, les états figurent dans leur version anglaise, c'est-à-dire dans la version dans laquelle ils apparaissent dans le rapport de génération. Etats de Description de l'état de comparaison du fichier comparaison New L'état new est réservé aux fichiers nouveaux par rapport à la version de référence. Unmodified S'applique lorsqu'aucune modification n'a été apportée à un fichier par rapport au fichier de référence. Modified S'applique lorsqu'il y a eu des modifications dues uniquement à des modifications du modèle UML par rapport au fichier de référence. Manually S'applique en cas de modifications manuelles par rapport à modified la version de référence. Modified & S'applique en cas de modifications des deux types d'un manually fichier par rapport à la version de référence. modified Removed S'applique lorsqu'un fichier n'existe plus dans une nouvelle version. Un fichier éliminé n'est plus pris en considération dans les rapports de génération ultérieurs. Comme illustré en figure 2, un rapport de génération conforme à l'invention ("Generation Report") comporte dans des fenêtres en en-tête les 5 deux informations suivantes: Etiquette du numéro de version du rapport de référence ("Reference report label"), Etiquette du numéro de version du rapport courant ("New report label"), provenant d'une version précédente de génération, o Ensuite, le corps du rapport comporte les trois colonnes suivantes: "Item" (désignation des différents éléments constitutifs et chemin d'accès dans leur unité de stockage), "Comparison status" (état de comparaison, conformément au tableau ci-dessus) et "Label" (étiquette, indiquant les numéros de version dans leur catégorie). Les éléments figurant dans la première colonne sont les suivants: Désignation du modèle UML ("Model"). Ici, son état est "modifié" et son numéro de version est 2.0, Désignation des ensembles logiciels ("Packages"). Dans l'exemple décrit ici, ce sont des ensembles Java et Clearcase. Ici, ils sont non modifiés et leur version est 1.0, Désignation des scénarios de génération ("Scenarios"). Dans l'exemple, ce sont des scénarios de génération Java et de "batch" Clearcase. Ici, ils sont non modifiés et leur version est 1.0, Désignation des fichiers générés ("Generated files"). Dans l'exemple, ces fichiers sont au nombre de sept, tous de version 2.0, le premier est nouveau, les statuts des autres étant divers, comme indiqué à la deuxième colonne. Le bas du rapport comporte une fenêtre indiquant le nom du scénario en cours ("batch Clearcase" dans le cas présent), un bouton "Generate" pour lancer la génération du scénario, et une première fenêtre "Files" indiquant les noms des fichiers de texte Clearcase générés dans ce scénario, et une deuxième fenêtre "Generated text" affichant le texte de ces fichiers. Les fichiers "batch" de Clearcase sont générés de façon à mettre à jour automatiquement le tableau Clearcase comportant tous les fichiers de code généré, conformément aux informations figurant dans le rapport de génération La mise à jour du tableau Clearcase est faite en deux phases, avec le lancement des deux fichiers PERL suivants: - "checkout.txt": ce fichier prépare la mise à jour du tableau Clearcase en vérifiant tous les fichiers modifiés, "checkin.txt" : ce fichier représente le tableau Clearcase mis à jour. REVENDICATIONS 1. Procédé de génération de code C à partir de spécifications UML, caractérisé en ce que l'on produit un modèle d'implémentation détaillé en code UML, que l'on structure les données de ce modèle pour les rendre exploitables par l'outil de génération de scripts ModellnAction , et que l'on fait produire à cet outil des fichiers en langage C, à savoir des fichiers .0 , des fichiers .H , un fichier de rapport de génération, des fichiers batch de gestion de configuration et des fichiers de projet de compilation. 2. Procédé selon la revendication 1, caractérisé en ce que le code C généré recouvre 100% de la spécification UML du logiciel, tout le spectre de génération étant traité en statique comme en dynamique 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que le modèle est produit à l'aide d'un outil de modélisation UML 4. Procédé selon la revendication 3, caractérisé en ce que l'outil de modélisation UML est RHAPSODY de la société ILOGIX 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que le fichier de rapport de génération comporte les informations suivantes: - numéro de version du rapport de référence, numéro de version du rapport courant, -désignation du modèle UML avec son état et son numéro de version, - désignation des ensembles logiciels produits avec leur état et leur numéro de version, -désignation des scénarios de génération avec leur état et leur numéro de version, -désignation des fichiers générés avec leur état et leur numéro de version - nom du scénario en cours, - nom des fichiers de texte générés du scénario. 6. Procédé selon la revendication 5, caractérisé en ce que les scénarios sont du type Clearcase . 7. Procédé selon la revendication 5 ou 6, caractérisé en ce que les états des fichiers générés sont des états de comparaison par rapport à ceux d'une génération précédente (génération référence). 8. Procédé selon la revendication 6, caractérisé en ce que l'état de chaque fichier est l'un des suivants: -nouveau, - non modifié - modifié modifié manuellement, -modifié et modifié manuellement, -éliminé.