FR 2852117 A1 20040910 FR 0302558 A 20030303 PROCEDE DE DEVELOPPEMENT AUTOMATISE AVEC MISE A JOUR La présente invention se rapporte à un procédé de développement automatisé avec mise à jour. Le développement d'un système complexe nécessite différentes étapes de résolution de problèmes et de conception incrémentale. L'objectif est de construire la spécification d'une solution répondant à la spécification 10 d'un problème. Dans le domaine logiciel, la spécification d'un besoin client donne lieu à la réalisation d'un document d'analyse, puis d'un document de conception et se termine par la réalisation du programme attendu. L'analyse, la conception et la réalisation permettent de construire de manière incrémentale une solution en expliquant la démarche de construction. Ces 15 différentes étapes facilitent la maintenance du programme qui résulte des différentes étapes de conception et permettent de faire évoluer le logiciel ainsi produit en fonction des besoins du client. Quel que soit le domaine d'application, il est possible de formaliser, avec les langages appropriés, les étapes de construction ainsi que leurs 20 résultats, qui seront appelées par la suite niveaux de conception. Un niveau de conception peut, par exemple, être exprimé sous forme de modèles UML (Unified Modeling Language). Il est possible de générer partiellement un niveau de conception en fonction du niveau de conception qui le précède à partir de règles de 25 transformation. De nouvelles informations doivent cependant être introduites manuellement pour enrichir le modèle nouvellement créé et raffiner les concepts de manière à converger vers le niveau de détail attendu pour la réalisation de la solution. L'approche incrémentale est illustrée à l'aide d'un exemple très 30 simplifié pris dans le domaine de la simulation du trafic aérien, et schématisé en Fig 1: Premier développement. Cette figure comporte trois niveaux de conception: 1. Le premier niveau de conception est appelé " Spécification du problème ". C'est à ce niveau que le client définit son besoin: chaque avion est caractérisé par un nom (A3XX), un nombre de passagers (600) et un nombre de moteurs (4). 2. Le niveau " Analyse du problème " est réalisé en UML. Cette étape d'analyse est encore très liée au domaine du métier concerné. A l'issue de cette étape, on voit encore apparaître les notions d'" avion ", de " passager ", et de " moteur " (ces informations sont notées entre guillemets. Ce sont les objets signifiants du niveau de 10 conception considéré ). Cette étape d'analyse fait aussi apparaître de nouvelles informations telles que la réservation, le nom et la nationalité des passagers... Ces informations raffinent des concepts du niveau de conception précédent; elles ne peuvent pas être déduites automatiquement: ce sont les choix de réalisation du 15 concepteur. 3. Le niveau " conception d'une solution " est beaucoup plus " technique ". Le langage utilisé n'est plus lié au domaine aérien. On ne s'intéresse plus aux notions d'avion ou de passagers. On met l'accent sur la notion d'acteur (objet informatique déclenchant des 20 traitements) qu'il faut simuler. C'est à ce niveau que sont définies précisément les actions à exécuter dans un langage proche de celui directement compréhensible par l'ordinateur (par exemple le C++). Dans la Fig 1: Premier développement, tous les éléments en trait fin 25 ou en caractères italiques explicitent les informations ajoutées manuellement. Toutes les informations représentés en caractère ou trait gras sont obtenus automatiquement par application des règles de transformation R1 à R9 suivantes: e Création du niveau de conception " Analyse du problème ": R,: Pour tout descriptif d'avion comportant un nom, un nombre de passagers et un nombre de moteurs, l'algorithme consiste à: a. créer un répertoire stéréotypé " projet " au nom de l'avion (nom) comprenant: i. une classe stéréotypée " avion " nommée " nom " (nom faisant référence au nom d'avion), ii. une classe stéréotypée " moteur " ayant pour nom " réaction ", iii. une classe stéréotypée " passager " ayant pour nom "personne ". b. créer une relation (lien de composition UML) nommée 10 " motorisation " entre la classe stéréotypée " avion " et la classe stéréotypée " moteur " avec comme cardinalités (nombre/chiffre) un côté classe stéréotypée " avion ", valeur de nombre de moteurs côté classe stéréotypée " moteur ". c. créer un lien d'association nommé " passager " entre la classe 15 stéréotypée " avion " et la classe stéréotypée " passager " avec comme cardinalités un côté avion, valeur de nombre de passagers côté classe stéréotypée " passager ". * Création du niveau de conception " Conception d'une solution ": R2: Pour tout répertoire stéréotypé " projet " au niveau " analyse du 20 problème " l'algorithme consiste à: a. créer un répertoire stéréotypé " Design " au niveau " conception d'une solution " ayant le même nom que le nom du répertoire stéréotypé " projet " du niveau de conception " analyse du problème "; b. créer une classe " Acteur " stéréotypée " Active "; R3: Pour toute classe stéréotypé " avion " au niveau " analyse du problème " l'algorithme consiste à: a. créer une classe sans stéréotype au niveau " conception d'une solution " ayant le même nom que le nom de la classe 30 stéréotypé " avion " du niveau de conception " analyse du problème "; b. créer une relation d'héritage allant de la classe nouvellement créée à la classe stéréotypée " Active "; R4: Pour toute classe stéréotypé " passager " au niveau " analyse du problème " l'algorithme consiste à: a. créer une classe sans stéréotype au niveau " conception d'une solution " ayant le même nom que le nom de la classe stéréotypé " passager " du niveau de conception " analyse du problème "; b. créer une relation d'héritage allant de la classe nouvellement 10 créée à la classe stéréotypé " Active "; R5: Pour toute classe stéréotypé " moteur " au niveau " analyse du problème " l'algorithme consiste à: a. créer une classe sans stéréotype au niveau " conception d'une solution " ayant le même nom que le nom de la classe 15 stéréotypé " moteur " du niveau de conception " analyse du problème "; b. créer une relation d'héritage allant de la classe nouvellement créée vers la classe stéréotypé " Active "; R6: Pour toute classe non stéréotypé au niveau " analyse du 20 problème " l'algorithme consiste à: a. créer une classe sans stéréotype au niveau " conception d'une solution " ayant le même nom que le nom de la classe du niveau de conception " analyse du problème "; R7: Pour toute association reliant deux classes A et B au niveau 25 " analyse du problème " l'algorithme consiste à: a. créer une association au niveau " conception d'une solution " reliant les classes issues de A et B par l'algorithme de transformation. Les cardinalités (les chiffres) et le rôle (le nom) sont identiques à ceux du niveau de conception " analyse du 30 problème "; R8: Pour toute opération d'une classe A du niveau " analyse du problème " l'algorithme consiste à: a. créer une opération au niveau " conception d'une solution " ayant le même nom que le nom de l'opération du niveau de conception " analyse du problème "; b. associer cette opération à la classe issue de A par l'algorithme de transformation. R9: Pour tout attribut d'une classe A du niveau " analyse du problème " l'algorithme consiste à: a. créer un attribut au niveau " conception d'une solution " ayant le même nom que le nom de l'opération du niveau de conception " analyse du problème "; c. associer cet attribut à la classe issue de A par l'algorithme de transformation. La conception d'un système complexe, telle qu'exposée succinctement cidessus, implique plusieurs étapes de conception et peut nécessiter de nombreuses itérations. A chaque itération, le concepteur remet en cause ses choix. Il effectue des modifications pour améliorer ses modèles. Or, le mécanisme de règles de transformation ne prend pas en 20 compte cet aspect. Lors de la ré-application des règles, les modifications sont prises en compte du point de vue de la construction pour la reconstruction d'un niveau N+1 à partir du niveau N, mais il n'y a pas d'intégration des modifications avec les informations déjà existantes à un niveau N+1 précédemment créé et complété manuellement. Toutes les 25 informations qui avaient été introduites manuellement sont perdues lors de la ré-application des règles. Le problème est de passer de manière automatique ou semiautomatique d'un niveau de conception N à un niveau N+1 (ou plus généralement d'un modèle à un autre) avec les contraintes suivantes: * conserver les informations ajoutées au niveau sous-jacent N+1 lors de la ré-application des règles; * conserver et expliciter toutes les informations utilisées lors de l'application des règles de façon à pouvoir reproduire le processus (ces information seront appelées paramètres de la règle). Leur sauvegarde permet la ré-application des règles sans nouvelle interaction avec le concepteur. * Cette conservation d'informations n'est pas réalisée avec les procédés connus. Elle est essentielle pour maintenir et faire évoluer les niveaux de conception, et ne peut se faire que par le couplage de la transformation avec la traçabilité, ce couplage faisant l'objet de la 10 présente invention, comme détaillé ci-dessous. A titre d'exemple, pour illustrer l'inconvénient principal des procédés connus, on se propose de changer le nom de l'avion A3XX en A380 au niveau " Descriptif spécification du problème ", le nom de A380 ayant été finalement choisi, puis de ré-appliquer les règles précédemment citées. En 15 appliquant le seul mécanisme connu de règles de transformation, on obtient les modèles présentés Fig 2: Transformation non conservative. Toutes les occurrences du nom A3XX ont été correctement remplacées par A380 mais toutes les informations ajoutées manuellement (informations en italique et en trait fin sur les différentes figures), lors de la première itération, au niveau 20 " Analyse du problème " et " Conception d'une solution " sont perdues. Cette solution est inacceptable: pour ne pas perdre tout son travail, le concepteur doit renoncer à l'utilisation des règles de transformation et répercuter manuellement la modification (le nom de l'avion) à tous les niveaux de conception sous-jacents, là o c'est nécessaire et avec tous les 25 risques d'incohérences que cela représente. Pour effectuer ce travail, le concepteur peut, à l'aide des outils qui existent, établir des éléments de traçabilité pour relier toutes les occurrences du nom A3XX. Ces liens lui permettront de localiser toutes les modifications à effectuer lors du changement de nom, mais ces modifications resteront à sa charge. Les 30 mécanismes de transformation et de traçabilité sont gérés de façon indépendante. La présente invention a pour objet un procédé de développement automatisé couplant la traçabilité et la transformation. Le procédé conforme à l'invention est un procédé de développement automatisé avec règles de transformation permettant de passer d'un modèle 5 à un autre, avec mise à jour, et il est caractérisé par le fait que l'on associe à chaque élément de modèle produit automatiquement au moins un lien de traçabilité avec l'ensemble des éléments à partir duquel il est issu selon la règle de transformation. Selon une autre caractéristique de l'invention, les éléments manipulés 10 sont des éléments UML. De façon avantageuse, on utilise une " dependency " UML pour établir le lien de traçabilité, la " dependency " étant telle que définie à l'OMG dans la définition du langage UML. Selon encore une autre caractéristique de l 'invention, le procédé de l'invention est utilisé pour mettre en oeuvre des " Design patterns ". La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel: - la figure 1, citée ci-dessus, est un bloc-diagramme d'un premier développement de programme de simulation de trafic 20 aérien, - la figure 2, également citée ci-dessus, est un bloc-diagramme résultant de celui de la figure 1, tel qu'obtenu après une transformation non conservative, selon l'art antérieur, - la figure 3 est un bloc-diagramme résultant de celui de la figure 25 1, tel qu'obtenu après une transformation conservative, selon le procédé de l'invention, - la figure 4 est un bloc-diagramme illustrant la construction automatique du niveau d'analyse selon le procédé de l'invention (les lignes en pointillées représentent le lien de 30 traçabilité qui a été crée), - la figure 5 est un bloc-diagramme illustrant l'enrichissement manuel du niveau d'analyse par le concepteur (informations en italique et en trait fin). - la figure 6 est un bloc-diagramme illustrant la deuxième itération de l'algorithme de mise en oeuvre du procédé de l'invention. Le concepteur à modifié la spécification du problème en changeant le nom de l'avion puis a ré-appliqué les règles pour mettre à jour son modèle. L'invention propose d'associer aux règles de transformation des éléments de traçabilité. L'application des seules règles de transformation n'assure qu'un lien de traçabilité éphémère entre des éléments d'un niveau de conception source et les éléments 10 correspondants du niveau de conception cible. Cette liaison (éléments sources, éléments cibles, et paramètres de la règle) n'existe que pendant l'application de la règle. L'invention propose de coupler un mécanisme de traçabilité avec un mécanisme de transformation. Pour cela, on ajoute aux règles des 15 éléments qui: * explicitent la traçabilité complète entre éléments d'un niveau de conception source vers les différents éléments d'un niveau de conception cible, * explicitent les paramètres de la règle (informations fournies par le 20 concepteur nécessaire à l'application des règles), * permettent la mise à jour d'un niveau de conception cible à partir d'un niveau de conception source sans impact sur les éléments non issus de l'application d'une règle lors d'une transformation antérieure. Le mécanisme de transformation conservative de l'invention permet de maintenir en cohérence les niveaux de conception par application de règles couplées à des éléments de traçabilité. Avec ce mécanisme, il est possible de renommer l'A3XX en A380 et de répercuter automatiquement cette modification à tous les niveaux sous-jacents sans perdre les informations 30 ajoutées manuellement (Cf. Fig 3: Transformation conservative). Le mécanisme de transformation conservative supporte le développement incrémental et itératif. Il supporte également les transformations endomorphes (au sein d'un unique niveau de conception). Ce mécanisme peut également servir à propager des marques servant à supprimer des éléments via des règles similaires à celles de l'exemple. On va maintenant décrire de façon détaillée un mode de mise en oeuvre du procédé de l'invention. L'invention propose un mécanisme de traçabilité couplé aux règles de transformation, permettant de rendre pérenne le lien entre les éléments produits par la transformation et les éléments à partir desquels ils sont issus, ainsi que les informations appelées paramètres de la règle de transformation. On appelle ce lien, lien de traçabilité. C'est un lien logique, qui relie n 10 éléments source, à m éléments cible. Définitions Soient * R: une règle de transformation * S: un ensemble d'élément(s) du modèle source (niveau N) * C: un ensemble d'éléments du modèle cible (N+1) , issu(s) de S, par application de la règle R, * PARAMS, R: paramètre de la règle R appliquée a S. L'obtention de ces paramètres peut nécessiter un dialogue avec le concepteur. * Lien S,C,R: l'élément de traçabilité entre S, et C qui peut être 20 associé à des paramètres spécifiques (PARAM S, R) à l'application de R sur S. L'algorithme de mise en oeuvre du procédé de l'invention comprend les trois parties suivantes: Algorithme de transformation conservative: Pour tout ensemble S sur lequel s'applique la règle R Si Lien S,C,R existe alors Mise à iour de C et du Liens c R Sinon Création de C, du Lien S C R et de PARAMS R Mise à jour des C, et du Lien[sc, L'ensemble C est obtenu en suivant le Lien SC R issu de S. Pour tout élément de C, on affecte les valeurs calculées à partir de S, de R et éventuellement de PARAMs R. Création de C, du lien SCR et de PARAMsR. Création puis affectation (i.e fixation des valeurs) des éléments C par application de R ainsi que création du lien S,C,R et des paramètres PARAMS, R (éventuellement vide). On va maintenant décrire l'application de l'algorithme du procédé de l'invention à l'exemple précité de la simulation de trafic aérien pour la seule création du niveau " analyse du problème ". Le niveau suivant, non décrit ici 10 pour des raisons de simplification, est obtenu de façon analogue. La première phase est la création du modèle d'analyse par une première itération de l'algorithme (Cf:Figure 4) 1ère application de la règle RI " Spécification du problème " Soient: 1 5 * S, le " Descriptif d'avion " : c'est l'ensemble des éléments source représentant un descriptif d'avion comportant un nom, un nombre de passagers ainsi qu'un nombre de moteurs. * R, la règle Rl de création du niveau de conception 20 " Analyse du problème ". Il n'y a pas de lien issu de S, il faut donc créer les éléments cibles, le Lien SC,R et les paramètres associés. On procède de la façon suivante: * A partir du descriptif d'avion comportant le nom A3)X, un 25 nombre de passagers de 600 et un nombre de moteurs de 4, l'algorithme consiste à: a. créer un répertoire stéréotypé " projet " portant le nom de l'avion du descriptif (soit A3XX) comprenant: i. une classe stéréotypée " avion " nommée A3XX, ii. une classe stéréotypée " moteur " de nom " réaction ", iii. une classe stéréotypée " passager " de nom "personne ". b. créer un lien de composition nommé " motorisation " entre la classe stéréotypée " avion " et la classe 10 stéréotypée " moteur " avec une cardinalité 1 côté classe stéréotypée " avion ", et 4 côté classe stéréotypée " moteur ". c. créer un lien d'association nommé " passager " entre la classe stéréotypée " avion " et la classe stéréotypée 15 " passager " avec une cardinalité 1 côté classe stéréotypée " avion ", 600 côté classe stéréotypée " passager ". * Créer le lien de traçabilité Lien S,C,R (avec S= " Descriptif d'avion ", C = répertoire A3XX stéréotypé " projet ", classe 20 A3XX, classe réaction, classe personne, le lien de composition et le lien d'association précédemment créés avec leurs cardinalités respectives et R = R1). * Il n'y a pas de paramètres à la règle R (le concepteur n'explicite aucun choix, car la règle n'a besoin d'aucune information 25 externe); On suppose maintenant que le concepteur procède au raffinement du modèle d'analyse (Fig 5: Raffinement manuel de l'analyse): Il ajoute deux méthodes " atterrir " et " décoller " à la classe nommée A3XX * Il ajoute un attribut " puissance " à la classe nommée Réaction 30 * Il ajoute deux attributs " nom " et " nationalité " à la classe nommée Personne * Il ajoute une classe " Réservation " comprenant trois attributs " départ ", " arrivée " et " numéro de vol " * Il ajoute un lien de composition entre la classe Passager et la classe Réservation de cardinalité 1. On suppose ensuite que le concepteur procède à la modification d'une information du niveau " spécification du problème " * Il remplace le nom A3XX par A380. On va maintenant exposer la façon dont le procédé de l'invention 1o réalise la mise à jour des modèles, lors d'une deuxième itération de l'algorithme. Le résultat de la mise à jour est illustré (Fig 6: Modification de la spécification et mise à jour automatique): 2ème application de la règle R1 " Spécification du problème " Soient: 1 5 S le " Descriptif d'avion ": c'est un élément source représentant un descriptif d'avion comportant un nom, un nombre de passagers ainsi qu'un nombre de moteurs. R la règle Rl de création du niveau de conception " Analyse du problème ". Il existe un Lien S,C,R issu de S. Il faut donc appeler le sousprogramme Mise à jourde C. du LienSCR à partir du LiensCoR existant. L'algorithme consiste à: 1. Saisir au niveau analyse le répertoire " projet " lié au descriptif d'avion et le mettre à jour si nécessaire selon les 25 caractéristiques de S via R; faire la mise à jour du LienS,C,R: le répertoire A3XX est renommé A380 2. Saisir au niveau analyse la classe stéréotypée " avion " liée au descriptif d'avion et la mettre à jour si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS,C,R: 30 la classe A3XX est renommée A380 3. Saisir au niveau analyse le lien de composition nommé " motorisation " lié au descriptif d'avion et le mettre à jour les cardinalités si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS,Cn: les cardinalités restent inchangées 4. Saisir au niveau analyse le lien d'association nommé " passager " lié au descriptif d'avion et le mettre à jour les cardinalités si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS,C,R: les cardinalités restent 10 inchangées. REVENDICATIONS 1 Procédé de développement automatisé avec règles de transformation permettant de passer d'un modèle à un autre, avec mise à jour, selon lequel on construit la spécification d'une solution répondant à la spécification d'un problème en réalisant un document d'analyse, puis un document de conception, et enfin en réalisant le programme résultant des 10 étapes de conception, caractérisé par le fait que l'on associe à chaque élément de modèle produit automatiquement au moins un lien de traçabilité avec l'ensemble des éléments à partir duquel il est issu selon la règle de transformation, ce lien de traçabilité étant destiné à la prise en compte des nouvelles informations introduites manuellement en cours de 15 développement. 2. Procédé selon la revendication 1, caractérisé par le fait que les éléments manipulés sont des éléments UML. 3. Procédé selon la revendication 2, caractérisé par le fait que l'on utilise une a dependency " UML pour établir le lien de traçabilité. 4. Procédé selon la revendication 2, caractérisé par le fait qu'il est utilisé pour mettre en oeuvre des " design patterns ".