Brevet FR2864284A1 — publié le 20050624

PROCEDE DE VERIFICATION DE REGLES SUR LES MODELES UML La présente invention a pour objet un procédé de vérification de règles sur les modèles UML. Pour vérifier le respect des règles d'établissement de modèles UML, il n'existe actuellement aucun outil. Des outils, dénommés "Logiscope" et Rules Checker , ne permettent de vérifier que le code produit à partir du modèle, et non pas la spécification du modèle UML elle-même. La présente invention a pour objet un procédé qui permette de vérifier la qualité d'un modèle UML par vérification du respect de toutes les règles de modélisation. Le procédé de l'invention est caractérisé en ce qu'après avoir établi un modèle, on structure les données du modèle pour les rendre exploitables par l'outil "Model ln Action", on fait produire par cet outil un fichier de vérification et on produit à partir de ce fichier un rapport de vérification lisible par un utilisateur. 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 UML de cas d'utilisation illustrant les différents acteurs et cas d'utilisation du procédé de l'invention, - la figure 2 est un bloc-diagramme illustrant l'architecture du procédé de l'invention, - la figure 3 est une vue d'une interface de vérification produite selon le procédé de l'invention, - la figure 4 est une vue partielle d'un exemple de rapport de vérification, tel que pouvant être produit par le procédé de l'invention, et - la figure 5 est un exemple d'extrait type du rapport de vérification pour une règle telle que vérifiée par le procédé de l'invention. Sur le diagramme de la figure 1, on a représenté les deux principaux types d'utilisateurs susceptibles d'utiliser le procédé de vérification de l'invention, à savoir un modeleur UML (1) et un chef de projet (2). Dans un cadre (3), délimitant le périmètre des possibilités du procédé de l'invention, on a figuré les différentes actions permises par ce procédé. Ces actions sont: vérification des règles de génération de code (4), vérification de la cohérence du modèle (5), vérification de la cohérence du code (6), vérification des règles de modélisation (7), vérification de la qualité du modèle (8), récupération des métriques d'avancement de modélisation (9) et récupération des métriques dimensionnantes du modèle UML (10). La vérification des règles de modélisation se subdivise en deux vérifications, qui sont: la vérification des règles basiques de modélisation (11) et la vérification des règles paramétrables (12). La supervision des actions 4 à 6 est généralement dévolue au modeleur 1, tandis que celle des actions 8 à 10 est généralement dévolue au chef de projet 2, seule l'action 7 (y compris ses deux composantes 11 et 12) pouvant être supervisée par les deux opérateurs 1 et 2. Sur le diagramme de la figure 2, on a représenté, après l'étape de modélisation d'un projet (13), par exemple à l'aide d'un outil tel que RHAPSODY , et l'exportation d'un fichier au format XMI (14), les principales étapes du procédé de l'invention, mises en oeuvre par un outil dénommé UML CHECKER (15) et qui sont: l'écriture de scripts (16) pour un moteur de génération de fichiers (17), qui est ici l'outil Model ln Action (plus simplement dénommé MIA , et réalisé par la société SODIFRANCE). Les fichiers produits par l'outil (17) sont au format XML (18), puis par conversion XSLT (19) transformés au format HTML pour obtenir un rapport de vérification du modèle (20) au format HTML. L'outil MIA (17) reçoit un fichier de paramétrage des règles de vérification (21) (dénommé ici parameter.ini ), constitué par l'utilisateur modeleur. De façon avantageuse, l'outil UML-Checker (15) comporte également des procédures (22), au format JAVA pour générer des graphiques (abaques) de vérification de la qualité du modèle ou des scripts VB (23) permettant, le cas échéant, de traiter des vérifications sur les graphiques des modèles UML(impossible via la sortie XMI -14). La sélection des règles de vérifications est commandée par l'intermédiaire d'une interface graphique en java (24) implémentée dans l'outil de vérification UML-Checker (15) et représentée en figure 3. De façon plus détaillée, le procédé de l'invention se déroule de la façon suivante: - l'utilisateur lance le logiciel RHAPSODY , - il ouvre un modèle depuis ce logiciel, - il sélectionne depuis ce même logiciel l'outil de vérification de l'invention (dénommé, comme on le voit sur l'interface représentée sur la figure 3, UML CHECKER ). Par l'intermédiaire de cette interface, l'utilisateur choisit: - le fichier contenant le modèle UML désiré (au format XMI), dans la fenêtre "Select a model file", le fichier de paramétrage, utile pour certaines règles (fichier "parameter.ini" référencé (21) en figure 2), dans la fenêtre "Select o a parameter file", - les règles à vérifier, dans la fenêtre "Select the rules to check" - le chemin et le nom du fichier de résultat (au format XML), dans la fenêtre "Select a result file". Le fichier de paramétrage (parameter.ini) permet à l'utilisateur de choisir les paramètres à prendre en compte pour la vérification de certaines règles. Par exemple, une règle vérifie le nombre de caractères des attributs d'une classe. Si le nombre de caractères d'un attribut dépasse le nombre qui se trouve dans le fichier de paramétrage, une erreur est signalée dans le rapport de vérification. L'utilisateur doit choisir les règles de vérification qu'il souhaite appliquer à son modèle. Les règles sont présentées sous la forme d'un arbre classant chaque règle par catégorie, comme on peut le voir sur la figure 3. Ces catégories sont celles mentionnées en référence à la figure 1 et sont détaillées ci-dessous. La sélection se fait grâce à des cases à cocher. Plusieurs règles peuvent être sélectionnées en même temps. II est aussi possible de sélectionner toutes les règles d'une même catégorie en cochant dans l'arborescence des règles le noeud du groupe de règles de cette catégorie. Lorsqu'un utilisateur sélectionne une règle, sa description apparaît dans une fenêtre située juste sous la fenêtre de sélection Select the rules to check de la figure 3. Les règles que peut sélectionner l'utilisateur sont de sept catégories différentes (on a mis entre parenthèses les références numériques correspondant à celles de la figure 1) : règles de spécification de l'implémentation du modèle pour le générateur de code GEN_UML_C (4) règles sur la cohérence du modèle (par exemple pour éviter les relations fantômes pouvant être induites par une mauvaise réalisation des graphiques UML sous RHAPSODY ) (5), règles sur la cohérence du code (par exemple pour vérifier que l'accès aux méthodes de toutes les classes est correct) (6), règles sur la modélisation (pour vérifier, par exemple, si l'interdiction d'héritage multiple est respectée) (7), - calcul de métriques (nombre de classes abstraites par exemple) (10), calcul de métriques d'avancement de la modélisation, pour les responsables de projet (9), mesure de la qualité du modèle (vérification des métriques comme la complexité d'une classe par exemple) (8). Enfin, l'utilisateur choisit un nom de fichier résultat au format XML. L'utilisateur peut sélectionner un fichier déjà existant ou en créer un nouveau. On a représenté en figure 4 un exemple partiel d'un tel fichier, qui est dénommé Rapport de vérification sur cette figure. Pour l'outil de vérification de l'invention, l'outil XSLT est utilisé pour 20 transformer le fichier de résultat, qui est en format XML, en document HTML. En effet, cet outil permet de transformer des documents XML en d'autres documents au format XML ou en un autre format approprié, tel que HTML. On a représenté en figures 4 et 5 un exemple partiel d'un document au format HTML pouvant ainsi être produit. Ce document est facilement 25 exploitable par les utilisateurs. Le document représenté en figures 4 et 5 se compose de trois parties principales: la première partie (représentée en haut de la figure 4) est l'index des règles qui ont été vérifiées. Sur l'exemple de la figure 4, deux règles liées au générateur de code ont été vérifiées: règle sur les agrégations et règle sur les DataTypes (types de données), la deuxième partie (représentée en bas de la figure 4) représente la structure du modèle UML. Elle permet d'obtenir une vue d'ensemble du modèle et de faire des vérifications visuelles sur sa structure directement dans le rapport sans avoir à ouvrir un éditeur de modèle UML. La troisième partie (figure 5) constitue le rapport de vérification proprement dit. Pour chaque règle, un paragraphe correspondant est créé. Il est possible, depuis l'index des règles, d'accéder directement au paragraphe lié à cette règle grâce à des hyperliens. A la fin de chaque règle, un lien hypertexte permet de revenir en haut de la page. Dans l'exemple de la figure 5, le rapport de vérification concerne les règles de génération de code ( Règle Gen_UML_C ), et les deux erreurs relevées se rapportent aux agrégations. S'il n'y a pas d'erreur pour une règle examinée, une simple phrase stipule qu'il n'y a pas d'erreur pour cette règle et remplace le paragraphe de commentaires et le tableau (figure 5) qui n'apparaissent plus dans le rapport. 20 REVENDICATIONS 1. Procédé de vérification de règles sur les modèles UML, caractérisé en ce qu'après avoir établi un modèle, on structure les données du modèle pour les rendre exploitables par l'outil "Model ln Action" ( MIA ) , on fait produire par cet outil un fichier de vérification et on produit à partir de ce fichier un rapport de vérification lisible par un utilisateur. 2. Procédé selon la revendication 1, caractérisé en ce que les règles vérifiées sont l'une au moins des règles relatives: ^ au générateur de code (4) ^ à la cohérence du modèle (5), ^ à la cohérence du code (6), ^ à la modélisation correcte (7), ^ aux mesures de dimensionnement (10), ^ aux mesures d'avancement de modélisation (9), ^ à la qualité du modèle (8). 10. Procédé selon la revendication 1 ou 2, caractérisé en ce que le fichier du modèle, établi au format UML, est exporté au format XMI vers l'outil MIA . 11. Procédé selon l'une des revendications précédentes, caractérisé en ce que le fichier de rapport produit par l'outil MIA est au format XML. 12. Procédé selon la revendication 4, caractérisé en ce que le fichier au format XML produit par l'outil MIA est converti au format XSLT pour être transformé en un fichier de document d'un autre format approprié.