Brevet FR2863743A1 — publié le 20050617

PROCEDE DE TRACABILITE DES EXIGENCES A PARTIR D'UN MODELE UML La présente invention se rapporte à un procédé de traçabilité des exigences à 5 partir d'un modèle UML. Il existe de nombreuses méthodes de traçabilité des exigences à partir d'un modèle, mais il n'en existe pas pour les modèles en langage UML. De plus, ces méthodes connues sont limitées au seul code, donc elles ne sont pas transposables au langage UML. La présente invention a pour objet un procédé de traçabilité des exigences à partir d'un modèle, qui puisse s'appliquer à la modélisation UML. Le procédé conforme à l'invention est caractérisé en ce que lors de la modélisation, lorsque l'on crée un élément d'un modèle, on pose aussitôt une exigence sur cet élément, et on renseigne systématiquement l'exigence amont qui a provoqué la création de cet élément. 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 est une vue d'une interface graphique d'un outil 20 RHAPSODY montrant une exigence d'un modèle UML, telle qu'utilisée par la présente invention, la figure 2 est une vue de l'interface graphique de la figure 1, montrant un exemple de rattachement de contrainte, conformément au procédé de l'invention, la figure 3 est une vue de l'interface graphique de la figure 1, montrant un exemple de rattachement d'exigence UML, conformément au procédé de l'invention, et la figure 4 est un diagramme montrant un exemple d'enchaînement d'activités entre les outils RHAPSODY et DOORS , 30 conformément au procédé de l'invention. On sait que la création d'une exigence UML suit toujours une activité de modélisation, mais il ne faut surtout pas créer les exigences, puis modéliser ce qui est spécifié dans ces exigences, car cela conduirait inévitablement à une mauvaise utilisation d'UML et de la notion d'objet. Il est conseillé, à chaque fois que l'on crée une exigence qui raffine une ou plusieurs exigences amont, de renseigner systématiquement la balise UpwardReq: avec l'identificateur de ces exigences amont. Ainsi, on gère la traçabilité des exigences au moment de leur création et non a posteriori sur l'ensemble des exigences. Une exigence est représentée dans le modèle UML (avec l'outil de modélisation RHAPSODY de la société I-LOGIX) par une contrainte UML 10 appelée Exigence UML . Un exemple en a été représenté en figure 1. Toutes les Exigences UML doivent être définies de la même manière selon le modèle ( template en anglais) suivant: le champ Name (nom de l'Exigence UML) doit contenir l'identificateur de l'exigence. Cet identificateur doit permettre d'identifier le niveau de l'exigence. Si l'exigence est de haut niveau, l'identificateur doit commencer par HLR , et si l'exigence est de bas niveau, l'identificateur doit commencer par LLR_ . le champ Stereotype (stéréotype) doit contenir le niveau de spécification de l'exigence (SSS, SRS... ). En effet, les exigences définies pour ces différents niveaux de spécification sont toutes présentes dans le même modèle UML. Renseigner ce champ stéréotype est donc le seul moyen de différencier les exigences en fonction de leur niveau de spécification et donc d'identifier vers quel module DOORS (l'outil DOORS est un outil de gestion d'exigences de la société TELELOGIC) elle doivent être redirigées. - le champ Description (description de l'Exigence UML) doit contenir les balises suivantes: - Title: (titre), suivie du titre de l'exigence, - Content: (contenu), suivie du texte de l'exigence, Upward Req: (requête amont), suivie de la liste des identificateurs des 30 exigences amont à l'origine de cette exigence. Les identificateurs doivent être séparés par une virgule ( , ). On remarquera que l'ensemble des attributs de gestion d'exigences, tels que définis dans le processus DOORS, ne font pas partie du modèle UML. L'activité qui consiste à renseigner ces attributs s'effectue directement sous DOORS, suite à la remontée des exigences UML sous DOORS. Le rattachement des Exigences se fait de la manière suivante. Dans l'outil Rhapsody, le seul moyen d'associer une Exigence UML) à un élément du modèle est de la rattacher à cet élément en utilisant la fonction Add New / Constraint , comme représenté sur l'exemple de la figure 2 (pour l'exigence Solution ). Cette fonction de rattachement est disponible sur tous les éléments d'un modèle ( Package , Classe, Opération, Acteur, Cas d'utilisation, Machine à états, Etat... ). Actuellement, la norme UML 1.4 définit qu'une contrainte (une Exigence UML) peut être rattachée à plusieurs éléments UML, or RHAPSODY ne le permet pas. Par conséquent, lorsque l'on crée une Exigence UML) qui se répercute sur plusieurs éléments du modèle, on la rattache à l'élément commun contenant l'ensemble des éléments sur lesquels l'exigence se répercute. On décrit ci-dessous de façon non limitative deux exemples d'un tel rattachement: si deux classes d'un même package sont concernées par la même Exigence UML, alors cette Exigence UML sera rattachée au package contenant les deux classes, si une Exigence UML) se répercute sur trois méthodes d'une même classe, alors cette Exigence UML) sera rattachée à la classe. On a représenté en figure 3 un exemple d'un tel rattachement d'Exigence UML (Exigence de haut niveau HLR 01 à deux classes 3MyClass et MyOtherClass ). Selon une autre caractéristique de l'invention se rapportant à l'incidence sur la persistance des Exigences UML, lorsque l'on supprime un élément du modèle, toutes les Exigences UML rattachées à cet élément (et à tous les éléments rattachés à cet élément) sont supprimées elles aussi. Selon encore une autre caractéristique de l'invention, on exporte les Exigences UML sous DOORS, Suite à une étape de modélisation UML, qui correspond en général à un niveau de spécification donné, on obtient un modèle contenant un ensemble d'éléments UML et d'Exigences UML, stéréotypées avec le niveau de spécification correspondant. Quand le modèle UML a atteint un état stable, on peut alors importer le modèle UML sous DOORS afin d'effectuer les activités de gestion et de traçabilité d'exigences. On a schématiquement représenté en figure 4 un exemple d'enchaînement d'activités d'exportation de RHAPSODY vers DOORS. Sur cette figure, on a représenté côte-à-côte les outils RHAPSODY et DOORS. Pour le premier, on a représenté l'arborescence d'un modèle UML et trois étapes successives de développement ayant atteint chacune un état stable de modélisation, ces étapes étant respectivement référencées Niveau 1 à Niveau 3. Au fur et à mesure du développement, les modèles successifs sont importés dans DOORS et aussitôt on procède dans DOORS à la gestion et à la traçabilité de leurs exigences conformément au procédé de l'invention, tel qu'exposé ci-dessus. REVENDICATIONS 1. Procédé de de traçabilité des exigences à partir d'un modèle UML, caractérisé en ce que lors de la modélisation, on utilise une interface graphique lorsque l'on crée un élément d'un modèle, on pose aussitôt une exigence sur cet élément, dans cette interface graphique et on y renseigne systématiquement l'exigence amont qui a provoqué la création de cet élément. 2. Procédé selon la revendication 1, caractérisé en ce que lorsque l'on crée une Exigence UML) qui se répercute sur plusieurs éléments du modèle, on la rattache à l'élément commun contenant l'ensemble des éléments sur lesquels l'exigence se répercute. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que lorsque l'on supprime un élément du modèle, toutes les Exigences UML rattachées à cet élément sont supprimées elles aussi. 4. Procédé selon la revendication 3, caractérisé en ce que toutes les Exigences UML rattachées à tous les éléments rattachés au dit élément sont supprimées elles aussi. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que les Exigences UML sont exportées vers l'outil de gestion d'exigences DOORS pour y assurer leur gestion et leur traçabilité. 6. Procédé selon la revendication 5, caractérisé en ce que les Exigences UML sont exportées vers DOORS, au cours du développement du modèle, à chaque fois que ce modèle a atteint un état stable.