Brevet FR2864285A1 — publié le 20050624

PROCEDE DE REMONTEE AUTOMATIQUE DES EXIGENCES DE MODELES UML ET DE LEUR MISE A JOUR La présente invention se rapporte à un procédé de remontée automatique des exigences de modèles UML créés par un outil de modélisation, et de leur mise à jour. Lorsque l'on modélise un projet, quel qu'il soit, on utilise actuellement, de façon préférentielle le langage UML, mis en oeuvre dans un outil de modélisation, tel que RHAPSODY de la société I-LOGIX. La modélisation nécessite la prise en compte d'exigences, et à cet effet, on dispose d'un outil de gestion d'exigences tel que DOORS de la société TELELOGIC. Toutefois, il n'existe aucun moyen permettant d'assurer la traçabilité des informations du modèle pour en informer l'outil de gestion d'exigences. La présente invention a pour objet un procédé de remontée automatique des exigences de modèles UML vers un outil de gestion d'exigences pour permettre leur mise à jour, et ce, sans limitation sur la pose d'exigences et leur nombre. Le procédé conforme à l'invention est caractérisé en ce que l'on crée les exigences lors de la création des éléments du modèle UML, qu'une fois le modèle stabilisé, on exporte vers l'outil de gestion d'exigences les exigences saisies dans le modèle et l'on crée automatiquement un module de navigation contenant tous les objets UML pointés par au moins une exigence et un module d'exigences de niveau n. Avantageusement, on lie le module d'exigences de niveau n à un autre module d'exigences amont de niveau n+l défini précédemment. 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 25 le dessin annexé, sur lequel: la figure 1 est un blocdiagramme simplifié d'un exemple de mise en oeuvre du procédé de l'invention, la figure 2 est un diagramme illustrant la première importation d'un modèle UML dans un gestionnaire d'exigences, selon le procédé de 30 l'invention, la figure 3 est un diagramme illustrant une nouvelle importation, dans les mêmes conditions (import niveau 1) qu'en figure 2, la figure 4 est un diagramme illustrant une nouvelle importation d'un modèle UML, mais à un niveau différent (niveau 2) de celui de la figure 3, - la figure 5 est un diagramme illustrant la pose automatique de liens 5 de traçabilité depuis le module vers d'autres modules DOORS selon le procédé de l'invention, la figure 6 est un diagramme en quatre étapes, illustrant les opérations successives intervenant lors d'une nouvelle itération d'import d'un modèle UML dans un gestionnaire d'exigences, selon le procédé de l'invention, et les figures 7 et 8 sont des diagrammes montrant deux états d'un module d'Exigences du gestionnaire d'exigences, respectivement avant et après une nouvelle importation, selon le procédé de l'invention. On a représenté en figure 1 les principaux éléments de l'architecture du système mettant en oeuvre l'invention. Ces éléments sont: un modeleur UML (1), qui est, de préférence, l'outil RHAPSODY , un outil (2) de gestion d'Exigences UML, qui est, dans le cas présent, l'outil DOORS, un atelier d'utilitaires (3), qui est ici DOORS Custom de la société THALES AVIONICS et un connecteur universel de connexion inter-outils (4) PAPEETE (faisant l'objet d'une demande de brevet de la société THALES). L'importation de modèles UML dans l'outil DOORS depuis l'outil RHAPSODY se fait de la manière suivante. Lors de la première importation d'un modèle UML de RHAPSODY vers DOORS (voir figure 2), il y a création de deux modules dans DOORS: Un module (5) d'Exigences UML_DOORS correspondant au niveau de spécification (niveau 1 pour l'exemple représenté). Ce module de DOORS contient l'ensemble des Exigences UML_DOORS qui représentent les Exigences UML stéréotypées avec le niveau de spécification choisi lors de l'importation. Ce module 5 contient ici les exigences de niveau 1 du modèle. Ces exigences sont, pour cet exemple: HLR_0l, LLR 01 et HLR 03. Un Module de navigation UML (Surrogate Module UML) (6) : ce module de DOORS contient une représentation de l'ensemble des éléments UML du modèle créé dans RHAPSODY. Cette représentation est sous forme de référence vers les éléments UML. Ce module a comme objectif de permettre la navigation entre RHAPSODY et DOORS (comme exposé dans le manuel DOORS Custom User Guide ). Les importations suivantes du même modèle UML peuvent être de deux types différents. Soit, comme représenté sur l'exemple de la figure 3, il s'agit du même niveau de spécification que précédemment (niveau 1 en l'occurrence). Dans ce cas, à la fois le Module d'Exigences UML_DOORS et le Module de navigation UML sont mis à jour en fonction des modifications apportées au modèle UML. Soit, comme représenté en figure 4, ils portent sur un niveau de spécification différent (niveau 2 en l'occurrence, pour lequel il s'agit des exigences HLR 02 et LLR 02) . Dans ce cas, il y a création d'un module d'Exigences UML_DOORS correspondant au niveau de spécification sélectionné (niveau 2) lors de l'importation et mise à jour du Module de navigation UML en fonction des modifications apportées au modèle. Les liens entre une Exigence UML-DOORS et sa représentation dans le Module de navigation UML sont créés automatiquement lors de l'importation du modèle UML sous DOORS. Ces liens permettent la navigation entre les deux outils RHAPSODY et DOORS. La création de liens vers d'autres modules d'exigences DOORS est réalisée de la façon suivante. Après avoir effectué une importation d'un modèle RHAPSODY dans DOORS, il est possible de créer automatiquement les liens entre des Exigences du module crée automatiquement et des Exigences d'un autre module DOORS ou celles d'un autre module crée automatiquement antérieurement. Cette création automatique de liens est effectuée avec l'utilitaire DOORS TREK Create links by key... . Ainsi, comme représenté en figure 5, lors de l'importation du niveau de spécification X, on crée des liens de traçabilité entre le module d'Exigences de niveau X et, d'une part, le module d'exigences de niveau X-1, et d'autre part un module de niveau de spécification d'exigences tout à fait autre (SSS dans ce cas) . La gestion des modifications apportées aux exigences relatives au modèle UML est réalisée de la façon suivante. La gestion des modifications des exigences sous-entend la capacité de naviguer entre l'outil RHAPSODY et l'outil DOORS. En effet, il faut être capable d'analyser rapidement l'impact de modifications des exigences amont sur le modèle UML afin d'appliquer les modifications adéquates sur les éléments mis en cause par cet impact et inversement. Pour réaliser la modification d'Exigences UML DOORS, il ne faut pas modifier sous DOORS les attributs des Exigences UML_DOORS spécifiées dans les Exigences UML (comme expliqué dans le Guide de modélisation UML des exigences). Ces modifications ne doivent être effectuées que dans le modèle UML sous RHAPSODY. A la suite d'une modification d'Exigences DOORS, il faut pour chaque Exigence UML-DOORS qui la raffine (comme expliqué dans le Guide DOORS) : 15 1. naviguer, à l'aide de l'outil de navigation DOORS/RHAPSODY, vers l'Exigence UML associée, 2. analyser l'impact sur la modélisation de la modification à effectuer, 3. mettre à jour le modèle 4. mettre à jour l'Exigence UML dans le modèle, 5. importer le modèle modifié sous DOORS, 6. mettre à jour les attributs de gestion des exigences sous DOORS, Toute modification de modèle doit être effectuée en prenant en compte les Exigences UML qui ont une répercussion sur les éléments modifiés de manière à maintenir la cohérence entre les Exigences UML et le modèle UML. Pour ce faire, il faut consulter pour chaque élément UML modifié l'ensemble des Exigences UML qui ont une répercussion sur lui, pour vérifier que ces exigences sont toujours cohérentes avec la modification effectuée sur l'élément. Pour gérer les évolutions d'un modèle se traduisant par des modifications successives, on examine d'abord le mécanisme d'importations successives. L'importation d'un modèle UML sous DOORS est effectuée en plusieurs étapes. Ces étapes sont invisibles pour l'utilisateur, car elles sont effectuées en une seule fois lors de l'importation. On a illustré en figure 6 les principales étapes de ce mécanisme d'importations successives. Cette figure comporte quatre diagrammes (référencés 1 à 4). A l'état initial (1), on a, dans DOORS, un module Exigences UML_DOORS lié à un module de navigation UML (par des liens de navigation), ces modules générés automatiquement lors d'un import antérieur sont qualifiés d Lorsqu'arrive une demande d'importation du modèle UML visant une mise à jour de ces deux modules, les actions suivantes sont engagées: - création de deux nouveaux modules (2): o un Module Exigences UML_DOORS contenant l'ensemble des Exigences UML_DOORS correspondant à toutes les Exigences UML contenues dans le nouveau modèle UML importé, o un module de navigation UML représentant le nouveau modèle UML, suppression de l'ancien module de navigation UML et de tous les éléments 15 DOORS le concernant. (3), - analyse des mises à jour à effectuer entre les deux Modules Exigences UML DOORS, mise à jour de l'ancien Module Exigences UML_DOORS (4), - suppression du nouveau Module Exigences UML_DOORS (4), création des liens de navigation entre l'ancien Module Exigences UML DOORS et le nouveau Module de navigation UML. L'utilisateur doit ensuite mettre à jour les liens de traçabilité avec les exigences amont. Cette étape n'est pas incluse dans l'importation du modèle UML, mais doit être effectuée séparément après chaque importation à l'aide de l'utilitaire DOORS TREK Create links by key... . La gestion des évolutions peut concerner ensuite l'ajout d'exigences. Si l'on ajoute une Exigence UML dans le modèle, il y aura, lors de l'importation suivante, pour un même niveau de spécification, et un même modèle UML, création d'un nouvel objet DOORS dans le Module de navigation UML et dans le Module de navigation UML correspondants. A titre d'exemple simplifié, on a représenté en figure 7 l'état du Module Exigences UML_DOORS avant une nouvelle importation, et qui comporte les Exigences EXI01 à EXI_04 (en version vl). On a représenté en figure 8 l'état de ce Module après une nouvelle importation, EXI_02 étant modifiée (versions vl et v2 coexistantes), et avec une nouvelle Exigence EXI_05 (version v2). De même, si une Exigence UML déjà importée lors d'une précédente importation est supprimée dans le modèle, lors de l'importation suivante, l'Exigence UMLDOORS correspondant à l'Exigence UML, ne sera pas supprimée du Module Exigences UML DOORS, mais prendra le statut OBSOLETE et tous ses liens DOORS seront détruits. Si une Exigence UML déjà importée lors d'une précédente importation est modifiée dans le modèle, il y aura, lors de l'importation suivante, : création d'une nouvelle Exigence UML-DOORS correspondant à l'Exigence UML - création d'un lien entre l'ancienne et la nouvelle Exigence UML-DOORS transfert des liens entrants et sortants de l'ancienne vers la nouvelle Exigence UML-DOORS mise à jour du numéro de version sur la nouvelle Exigence UML-DOORS par rapport à l'ancienne. On obtient ainsi un historique des modifications d'exigences. En conclusion, le procédé de l'invention permet de remonter automatiquement sous DOORS toutes les informations de traçabilité rentrées dans le modèle UML. Il organise automatiquement sous DOORS tout le processus nécessaire à la navigation entre les deux outils via le connecteur PAPEETE ou un lien XML (ou équivalent) . Enfin il organise automatiquement toute la mise à jour des modules lors des différentes évolutions du modèle UML. REVENDICATIONS 1. Procédé de remontée automatique des exigences de modèles UML créées par un outil de modélisation, et de leur mise à jour, caractérisé en ce que l'on crée les exigences lors de la création des éléments du modèle UML, que, lorsque le modèle est stabilisé, on exporte vers l'outil de gestion d'exigences les exigences saisies dans le modèle, et que l'on crée, automatiquement, un module de navigation contenant tous les objets UML pointés par au moins une exigence et un module d'exigences de niveau n. 2. Procédé selon la revendication 1, caractérisé en ce qu'on lie le module d'exigences de niveau n à un autre module d'exigences amont de niveau n+l défini précédemment. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, lors de modifications d'exigences, on effectue ces modifications dans le modèle UML, avec l'outil de modélisation. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'outil de modélisation est RHAPSODY et que l'outil de gestion des exigences est DOORS . 5. Procédé selon la revendication 4, caractérisé en ce que lors d'importations successives, on réalise les étapes suivantes: - création de deux nouveaux modules: ^ un Module Exigences UML_DOORS contenant l'ensemble des Exigences UML DOORS correspondant à toutes les Exigences UML contenues dans le modèle UML importé, ^ un module de navigation UML représentant le nouveau modèle UML, suppression de l'ancien module de navigation UML et de tous les éléments DOORS le concernant, - analyse des mises à jour à effectuer entre les deux Modules Exigences UML DOORS, mise à jour de l'ancien Module Exigences UML DOORS, - suppression du nouveau Module Exigences UML DOORS, - création des liens de navigation entre l'ancien Module Exigences UML DOORS et le nouveau Module de navigation UML. 6. Procédé selon la revendication 4 ou 5, caractérisé en ce que si une Exigence UML déjà importée lors d'une précédente importation est modifiée dans le modèle, il y aura, lors de l'importation suivante, : o création d'une nouvelle Exigence UML-DOORS correspondant à l'Exigence UML o création d'un lien entre l'ancienne et la nouvelle Exigence UMLDOORS o transfert des liens entrants et sortants de l'ancienne vers la nouvelle 15 Exigence UML-DOORS o mise à jour du numéro de version sur la nouvelle Exigence UMLDOORS par rapport à l'ancienne.