FR 2852125 A1 20040910 FR 0302592 A 20030304 - 1 Système et procédé de modélisation d'un projet informatique." La présente invention se rapporte à un système et un procédé de modélisation d'un projet informatique. Elle trouve une application particulièrement intéressante, mais non exclusivement, lors de développement de très grands projets notamment dans le domaine de l'aéronautique et de l'espace. 10 Toutefois, l'invention peut également s'appliquer à des projets de toutes tailles dans des domaines tels que l'automobile, les télécommunications ou la banque. Dans la suite, on entend par Modèle: une représentation simplifiée d'un problème dans le domaine de la programmation objet. Un ensemble de classes regroupées dans une hiérarchie de paquetage, chaque classe étant notamment définie par des attributs et des opérations. Modèle spécifique: partition d'un modèle de projet global. Pour des projets de grande taille, il est nécessaire de 20 présenter les informations du projet par l'intermédiaire de plusieurs hiérarchies de paquetages autonomes mais dont les éléments peuvent être en relation. A chaque hiérarchie de paquetage correspond un modèle spécifique du modèle du projet Modélisation objet: une représentation abstraite sous forme 25 d'objets, d'entités ayant une existence matérielle (un avion) ou virtuelle (une réservation, un compte bancaire). Classes: description d'un ensemble d'objets qui partagent les mêmes attributs, les mêmes opérations, les mêmes relations et la même sémantique. Architecture: l'organisation d'un système logiciel et de ses différents composants. Exigences: Caractéristique, propriété ou comportement d'un système défini selon les besoins du client. Stéréotype: extension du métamodèle (modèle de haut niveau définissant les éléments d'UML et leur sémantique). Diagramme: représentation pour visualiser des briques de base classes, interfaces, composants... les diagrammes représentent un ensemble d'éléments, le plus souvent sous la forme de graphes connectés de sommets (éléments - 2 structurels) et d'arcs (relations) et servent à visualiser un système sous différents angles. UML Langage de modélisation unifié, "Unified Modeling Language" en langue anglaise, est la notation standard 5 utilisée pour la modélisation des systèmes informatiques. UML s'applique aussi bien pour les systèmes d'information que pour les systèmes techniques ou temps réel, et couvre tout le processus de développement, depuis l'expression de besoins et l'analyse jusqu'aux phases de conception et de 10 réalisation. UML apporte la garantie d'un langage universel, compris par tous les informaticiens et leurs clients. L'UML est normalisé par l'OMG (Object Management Group). UP: (Unified Process) L'Unified Process a pour but d'assurer 15 la production d'un logiciel de qualité qui réponde aux besoins des utilisateurs finaux, dans le respect des coûts et des délais. XML: (eXtended Modeling Language) XML, initialement langage de description de documents structurés, dédié aux échanges de 20 documents notamment sur l'Internet, fait désormais figure de brique majeure dans la mise en 'place des nouvelles architectures des systèmes d'information de la nouvelle économie. Un document XML permet de décrire les données échangées par une application et aussi la façon d'exploiter 25 ces données par l'application réceptrice. XML est normalisé par le W3C. XML Schema: XML est un format de description de fichiers XML. XML Schema est normalisé par le W3C. D'une manière générale, le développement d'un projet fait intervenir une suite d'étapes de réflexion et de construction. Les grands projets sont de plus en plus complexes à traiter et une grande partie du travail consiste à décomposer les problèmes en éléments plus simples à traiter. La représentation graphique 35 est d'une grande importance dans ce processus, car elle supporte plus facilement la réflexion. Des modèles peuvent être présents à chaque étape de cette réflexion, de la définition du besoin de l'utilisateur aux tests de vérification finale du système. Chaque modèle est constitué d'une série de représentations graphiques, chacune présentant une partie du problème de manière suffisamment simple pour que la réflexion puisse avancer. On connaît le standard UML tend à s'imposer comme langage de représentation graphique, car: - il n'est pas nécessaire de le décrire avant le projet puisque c'est un standard, - il peut être supporté par un grand nombre de produits commerciaux, car son marché n'est pas limité. - il possède plusieurs types de schémas différents, chacun étant adapté à un type de réflexion. Les outils existants permettent l'élaboration de modèles par saisie graphique. Cependant, lors de grands projets en particulier, le nombre de diagrammes grandit avec la taille des 15 projets. Des modèles de plusieurs milliers de diagrammes deviennent relativement courants avec pour conséquences: - un travail de saisie et de mise à jour de plus en plus fastidieux, - des utilisateurs ne modélisant qu'une partie du projet, 20 celle qui est le plus utile à leur travail de réflexion, et - certains modèles mal structurés deviennent illisibles. Ce qui entraine des modèles partiels sur beaucoup de projets, ou alors des modèles illisibles et difficilement exploitables. Lorsque les modèles sont partiels, il devient 25 impossible de mener complètement des analyses indispensables dans la vie du projet: - Recherche de liens entre éléments (ou gestion de la traçabilité), - Vérification de la cohérence, ou Mesure de l'avancement et mise en évidence de métriques. Par ailleurs, les processus de développement d'un projet définissent les tâches à réaliser depuis la définition du concept jusqu'à la vérification finale du projet. Sur les grands projets, le nombre de tâches est très élevé et ces tâches sont 35 interdépendantes et forment un réseau complexe. Le problème des grands projets est qu'il est difficile, voire impossible de finir complètement une tâche avant le début de la tâche suivante. Par exemple, le client a parfois des - 4 difficultés à exprimer complètement ses exigences alors qu'il ne peut pas connaître le contexte exact d'utilisation, car le système n'est pas construit. Son besoin se précise au fur et à mesure de l'avancement, et les impacts de ses précisions doivent 5 impérativement être évalués avant de répercuter les demandes d'évolution dans le projet. Pour répondre à ce problème, les méthodes objets ont été développées pour limiter les impacts des évolutions, puis des processus itératifs et incrémentaux ont été mis en place. Dans un 10 processus itératif et incrémental, le produit est créé en plusieurs itérations, chaque itération étant validée avant de passer à la suivante. On parle souvent de processus agiles dans ce cas. La difficulté des processus itératifs et incrémentaux est 15 le besoin croissant de gestion et de traçabilité. Chaque itération doit être définie avec précision depuis la définition du projet jusqu'aux tests. Dans une approche classique, la documentation contient l'ensemble de la référence du projet, mais le cycle de vie de la 20 documentation peut devenir plus long que le cycle de vie du projet. La plupart des opérations de gestion de documentation sont encore manuelles alors que l'informatique est utilisée pour le développement du système. Il en découle que la documentation est rarement cohérente à la fin du projet, car les itérations ne 25 prennent pas en compte la totalité du cycle de développement. Le client ne sait plus exactement ce qui est réalisé et pour quels besoins et des incohérences apparaissent au moment de la vérification finale. En outre, les grands projets font intervenir un grand 30 nombre de personnes et de sociétés, ce qui pose de nombreux problèmes d'intégration. Ces équipes sont constituées la plupart du temps de représentants des différentes professions concernées par le projet: - des managers chargés de faire avancer le projet en 35 respectant les objectifs donnés au départ, - des spécialistes des métiers du client capable de comprendre et de traduire le besoin des utilisateurs et des clients, - 5 - des spécialistes des technologies utilisées dans le projet oeuvrant comme architecte du système à construire et chargés de la communication avec les sous-traitants, - des spécialistes méthodes, - des spécialistes de la planification, - des qualiticiens, et - des personnels administratifs chargés de la gestion du projet et des mesures de l'avancement. Chaque intervenant sur le projet a donc une vision 10 différente du projet. Il doit donc enrichir le projet par des informations liées à sa compétence et il doit lier ses informations avec des informations en provenance entre autres des autres utilisateurs. Or, sa vision du projet est parfois brouillée par la multiplicité des informations. La présente invention a pour but de remédier aux inconvénients précités en proposant un nouvel outil de modélisation qui permet de couvrir l'ensemble du cycle de vie du système ou du logiciel devant être élaborée à l'issue du développement. En particulier, la présente invention a pour but 20 de couvrir les phases suivantes: - phases amonts recueil des exigences, conception de l'architecture, spécification des composants. - phases avales: intégration, vérification, validation. - phases du cycle de vie évolutif: maintenance, extension, 25 évolutions. Un autre but de l'invention est de proposer un outil de modélisation souple d'utilisation qui est capable de s'adapter à chaque utilisateur. En particulier l'invention vise à simplifier et accélérer la construction et la modification du modèle du 30 projet. La présente invention a encore pour but de permettre, lors du développement d'un projet, l'édition d'une documentation fiable, optimisée, cohérente avec les modèles et régulièrement mise à jour. La présente invention a aussi pour but la réalisation d'un outil de modélisation adaptatif et capable de s'adresser à différents acteurs du projet quel que soit leur niveau de compétence informatique. - 6 On atteint au moins l'un des buts précités avec un nouvel outil ou système de modélisation d'un projet informatique comprenant une base de données, et un éditeur de profils permettant de: - construire un modèle du projet sous forme d'une pluralité de modèles spécifiques destinés à être sauvegardés dans la base de données, - définir différents types de profil utilisateur, et - construire, pour chaque type de profil utilisateur, un 10 éditeur de modèles permettant de spécifier des éléments desdits modèles spécifiques et de représenter ces modèles spécifiques sous forme de diagrammes selon le standard UML. Les représentations graphiques peuvent être générées de façon automatique ou à la demande de l'utilisateur. Par projet informatique, on entend tout système modélisable en UML, tout système pouvant être représenté par des modèles UML (un métamodèle exprimé en UML). Ces systèmes peuvent par exemple être: un système de gestion de fichiers du personnel, un système de gestion de flux (Workflow) d'entreprise, un système de gestion 20 de changement ou encore un système de préparation d'une simulation. Avec le système selon l'invention, on crée une multitude d'éditeurs de modèles, chacun adapté à un type d'utilisateur donné. L'éditeur de profils permet de construire le modèle du 25 projet qui est en fait l'ossature, l'enveloppe du projet, ou plutôt une multitude d'enveloppes (modèles spécifiques) dont le contenu (les instances) sera introduit au moyen des éditeurs de modèles. Avec l'éditeur de profils on construit le modèle du projet en définissant les éléments contextuels de ce projet et 30 leur organisation: l'organisation du projet, le vocabulaire utilisé et les plans types des documents à générer. En d'autres termes, l'utilisateur définit les modèles spécifiques qui lui sont utiles, les plans types des documents associés à chaque modèle spécifique ainsi que le vocabulaire utilisé pour définir 35 ses modèles spécifiques; la documentation, notamment générée automatiquement et en temps réel au format HTML, permettant de visualiser directement les effets de son travail. La liste des modèles spécifiques peut être paramétrée en fonction des exigences du client (destinataire de l'application informatique devant être élaborée) ou de l'utilisateur. Au lieu de construire complètement un modèle du projet, on peut prévoir un modèle prédéfini à partir duquel est construit ledit modèle du projet. De préférence, on désignera un ingénieur méthode spécialisé pour la gestion de l'éditeur de profils. Chaque éditeur de modèles créé sera ensuite apte à représenter les modèles spécifiques selon le profil défini avec l'éditeur de profils; par exemple, pour un modèle spécifique donné, le profil peut avoir les conséquences suivantes: seuls 10 quelques éléments seront représentés, certains liens ne seront pas accessibles, et seuls un nombre prédéterminé d'éléments pourront être modifiés. Le profil peut également spécifier le langage utilisé par l'utilisateur concerné. Ainsi, l'éditeur de profils permet d'adapter l'outil aux différents acteurs du projet - les informations présentées sont filtrées en fonction du profil de l'utilisateur et des limites de sa prestation; pour ce faire, on peut disposer un module de filtrage apte à filtrer les données sortant de la base de données, - la présentation de ces informations est adaptée au métier et à la culture de l'utilisateur ainsi qu'à son vocabulaire, - l'utilisateur peut programmer lui-même de nouvelles fonctionnalités du produit pour l'adapter à une situation 25 particulière (par exemple, ajouter une interface avec un outil particulier ou présenter sous une autre forme des informations présentes dans les modèles spécifiques). La présente invention permet une formulation plus précise des informations du projet, par exemple des exigences, de façon à 30 mieux suivre les évolutions et à mieux lier ces informations avec le développement du projet. On peut aisément intégrer la phase de définition des exigences dans le processus itératif. A titre d'exemple avantageux, pour un qualiticien, le présent système présente l'information de la même manière que 35 pour les autres intervenants. Celui-ci peut donc utiliser tour à tour toutes les interfaces des différents profils utilisateurs. Il peut donc avoir la vision du client, du chef de projet, de l'architecte... - 8 Selon une caractéristique avantageuse de l'invention, chaque éditeur de modèles comporte des moyens d'interface aptes à recevoir des informations textuelles pour l'affectation des instances aux modèles spécifiques. L'éditeur de profils peut 5 également comporter des moyens d'interface aptes à recevoir des informations textuelles pour la construction dudit modèle du projet. Avantageusement, ces moyens d'interface peuvent comprendre une interface homme-machine autorisant la saisie d'informations de manière textuelle par les utilisateurs. Cette 10 saisie peut s'effectuer dans des trames adaptées au problème en cours. La présente invention permet ainsi une saisie rapide non graphique. L'utilisateur introduit ces instances simplement en saisissant du texte dans un langage qui lui est le plus approprié, ce langage étant prédéfini lors de la création de 15 l'éditeur de modèles. Ce dernier est conçu de façon à conformer les instances saisies avec le standard UML. Le système selon l'invention est notamment ainsi remarquable par le fait qu'on a séparé le modèle du projet de la représentation graphique. Toutefois, si un utilisateur désire saisir sous la forme 20 graphique, il est possible d'interfacer un éditeur graphique indépendant avec le présent système. Par conséquent, les moyens d'interface sont de préférence aptes à recevoir des informations graphiques. Par ailleurs, les moyens d'interface peuvent également 25 comprendre une interface machine-machine apte à recevoir des informations textuelles ou graphiques provenant d'un fichier informatique. Selon un mode de réalisation préféré de l'invention, le modèle du projet est conçu de façon à se conformer au standard UML. 30 En outre, l'éditeur de profils, les éditeurs de modèles et la base de données sont conçus de façon à échanger des données selon le standard XML. Plus précisément, pour gérer l'information dans la base de données, on utilise le langage de modélisation UML, le langage de représentation XML, la méthode de processus unifié "UP" 35 ("Unified Process" en langue anglaise) ainsi que l'approche MDA ("Model Driven Architecture" en langue anglaise). UML et UP présentent l'avantage de pouvoir être étendus au fur et à mesure des avancées de la technologie. Ces technologies permettent d'assurer une totale compatibilité du présent système avec les outils existants. Elles permettent également l'accès aux informations depuis des sites distants et la protection contre des accès non autorisés. Avantageusement, à chaque éditeur de modèles est associé un 5 module de génération de documentation. L'éditeur de modèles peut ainsi présenter une interface homme-machine dotée au moins d'une fenêtre de saisie textuelle et d'une fenêtre apte à afficher une documentation de manière synchrone avec la saisie. Contrairement aux systèmes actuels qui comportent une documentation unifiée, 10 autonome, la présente invention propose d'activer en même temps un modèle spécifique et la partie de la documentation qui lui est associée. Les modifications de cette documentation peuvent alors s'effectuer en temps réel et selon le standard de l'utilisateur. Selon un mode de réalisation avantageux de l'invention, 15 l'ensemble des données utiles est renfermé dans une unique base de données. Chaque duplication d'information étant souvent une source potentielle d'erreurs, la présente invention permet de disposer la totalité de l'information sur un référentiel unique utilisé 20 par la totalité des intervenants du projet. On maintient ainsi en cohérence l'ensemble des informations du projet au sein d'une base de données, et des vérifications automatiques peuvent avoir lieu de façon efficace (vérification de la cohérence, recherche de liens morts ou obsolètes...) De préférence, le système selon l'invention peut consister en un réseau de communication de type client/serveur pour lequel la base de données est disposée dans un serveur, l'éditeur de profils est disposé dans un poste administrateur, et chaque éditeur de modèles est disposé dans un poste client. Suivant un autre aspect de l'invention, il est proposé un procédé de modélisation d'un projet informatique dont les données sont sauvegardées dans une base de données; dans lequel procédé, au moyen d'un éditeur de profils: - on construit un modèle du projet sous forme d'une pluralité 35 de modèles spécifiques destinés à être sauvegardés dans la base de données, - on définit différents types de profil utilisateur, et - on construit pour chaque type de profil utilisateur, un éditeur de modèles permettant de spécifier des éléments - 10 desdits modèles spécifiques et de représenter ces modèles spécifiques sous forme de diagrammes selon le standard UML. Selon l'invention, on spécifie des éléments desdits modèles spécifiques à partir des informations saisies textuellement ou 5 graphiquement. Pour chaque type de profil utilisateur, on construit l'éditeur de modèles de façon à n'autoriser l'accès qu'à certains éléments prédéterminés dans chaque modèle spécifique. On associe à chaque éditeur de modèles un module de génération de documentation apte à afficher sur une fenêtre de 10 l'interface homme-machine de l'éditeur de modèles une documentation évoluant de façon synchrone avec la saisie d'information, cette saisie d'information étant réalisée dans une fenêtre de saisie de ladite interface homme-machine. Avantageusement, lorsqu'un utilisateur édite un modèle spécifique 15 dans l'éditeur de modèles, on affiche un diagramme de type UML du modèle spécifique dans une fenêtre graphique d'une interface homme-machine de l'éditeur de modèles. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de 20 mise en òuvre nullement limitatif, et des dessins annexés, sur lesquels: - La figure 1 est une vue schématique générale des principaux modules du système selon l'invention; - La figure 2 est un exemple d'implémentation du système selon 25 l'invention, - La figure 3 est une représentation schématique d'un ensemble de modèles spécifiques selon l'invention, et - La figure 4 est une vue de l'interface d'affichage de l'éditeur de modèles. Sur la figure 1 est représentée une vue générale des principaux modules constitutifs du système selon l'invention. On distingue un éditeur de profils 1 qui est une application informatique présentant une interface homme-machine adaptée à la saisie d'information. L'éditeur de profils 1 peut communiquer 35 avec une base de données 6 renfermant la totalité des données utiles du système. Pour la mise en òuvre de l'invention, un utilisateur, tel qu'un ingénieur méthode, édite un modèle de projet standard prédéfini dans la base de données 6. L'interface - 11 hommemachine de l'éditeur de profils lui permet de personnaliser ce modèle de projet standard en fonction des données contextuelles de son propre projet. Il définit ainsi une pluralité de modèles spécifiques tels que représentés sur la 5 figure 3. Pour chaque modèle spécifique, on définit un regroupement de classes sans leurs données d'instance, on crée des enveloppes sans contenus. Ces modèles spécifiques sont stockés dans la base de données 6. On construit également plusieurs éditeurs de modèles 2 à 4. 10 Chaque éditeur de modèles 2,4 est construit en fonction du profil d'un type d'utilisateur donné. Par exemple, lorsque l'utilisateur de l'éditeur de modèles 2 appelle un modèle spécifique de la base des données 6, seul un nombre prédéterminé d'informations lui seront accessibles. L'utilisateur sait ainsi quels sont les 15 champs qu'il doit renseigner, il n'est pas submergé par des informations non utiles pour lui, il peut ainsi créer ou modifier sereinement son modèle spécifique. L'utilisateur est donc guidé dans sa conception. Il ne peut faire que ce qui lui est autorisé en fonction de son profil défini depuis l'éditeur de profil. On 20 minimise ainsi les erreurs. Ce filtrage d'information est obtenu au moyen d'un module de filtrage disposé entre la base de données et chaque éditeur de modèles 2-4. Comme on le verra plus en détail sur la figure 4, chaque éditeur de modèles comporte des moyens 2a, 2b, 2c (figure 1) pour 25 permettre respectivement une saisie textuelle, une représentation graphique UML des modèles spécifiques, et un affichage de la documentation. En fait, chaque éditeur de modèles est associé à un module de génération de documentation 3,5 créé par l'éditeur de profil. Chaque module de génération de documentation 3,5 30 permet de créer une documentation liée à l'éditeur de modèles associé en fonction du profil de l'utilisateur concerné. Ces modules de génération de documentation communiquent également avec la base de données o est stockée la documentation intégrale. Par ailleurs on prévoit des moyens d'interface 8 pour communiquer avec des outils externes tels que des outils de gestion de projet ou encore de génération de code. Sur la figure 2, on voit un exemple d'implémentation du système selon l'invention sous forme d'un réseau client/serveur. - 12 La base de données 6 et le filtre 7 sont disposés dans un serveur 12 communiquant avec un micro-ordinateur 9 logeant l'éditeur de profils 1, et plusieurs micro-ordinateurs clients 10, 11 logeant chacun un éditeur de modèles 2,4. Plus précisément, en ce qui concerne l'éditeur de profil, les informations délivrées à son entrée peuvent être telles que 1. Le découpage en modèles spécifiques. 2. L'organisation hiérarchique des paquetages de chaque modèle spécifique. 3. Les paquetages qui seront créés automatiquement dès la création du modèle. 4. Les stéréotypes autorisés dans chaque modèle spécifique. 5. Les caractéristiques des classes d'élément en fonction de leurs stéréotypes -attributs, -rôles, -relations avec les autres classes (agrégation, association, héritage, dépendances) -états, transitions, actions -opérations (en particulier constructeurs et destructeurs) qui correspondent à des boutons dans les fenêtres de propriétés -la documentation utilisée dans l'aide en ligne de l'éditeur de projet. 6. Les règles fixant les relations entre les classes des 25 différents modèles. 7. Les règles décrivant les diagrammes qui doivent être construits et mis à jour automatiquement. 8. Les menus et les commandes spécifiques au projet qui sont ajoutés à la barre de menu de l'Editeur de modèles. 9. Les références vers des séquences de code utilisateur qui sont déclenchées par des événements standard par l'éditeur de modèles tels que - la création, le chargement ou la sauvegarde d'un modèle, - la création, la modification ou la suppression d'un 35 élément de modèle, - une requête de visualisation de la documentation d'un élément de modèle, - 13 - une action déclenchée par un changement d'état d'un élément de modèle, - le déclenchement d'une commande d'un menu utilisateur. 10. le format de la documentation des modèles qui sera générée par l'éditeur de modèles. D'une façon générale, le rôle de l'éditeur de profils est de: 1. spécifier les modèles spécifiques du modèle du projet et les éléments de chaque modèle spécifique, 2. construire l'éditeur de modèles conforme à la spécification. 3. intégrer les traitements associés à la manipulation des modèles spécifiques: -création, suppression ou modification d'éléments, 15 -sauvegarde, restauration d'un modèle, -création de la documentation. Pour construire un éditeur de modèles, on peut réaliser les étapes suivantes: 1. Création d'un modèle de profil (chaque profil étant 20 conçu sous forme d'un modèle) à partir d'un éditeur spécifique ou à partir d'une représentation textuelle, 2. Transformation du modèle de profil créé en XML 3. Lancement de l'éditeur de profils par une commande fournissant les paramètres et les options de génération: un 25 fichier contenant le méta modèle au format XML et un répertoire o les fichiers produits par l'éditeur de profils sont stockés. 4. Compilation des fichiers sources générés par l'éditeur de profils. 5. Intégration et compilation des séquences de code 30 utilisateur. 6. Édition de liens des fichiers binaires obtenus avec la bibliothèque de l'éditeur de profils (DLL) en utilisant un fichier de type " makefile " 7. Production de l'éditeur de modèles. 8. Construction de l'aide en ligne de l'éditeur de modèles. Et les éléments à la sortie de l'éditeur de profil sont typiquement: - 14 - un schéma XML de chaque éditeur de modèles nécessaire à la sauvegarde et à la restauration du modèle dans le format XML ainsi qu'à la création de la Base de Données, - des fichiers exécutables des éditeurs de modèles capables 5 d'éditer et de construire des modèles spécifiques conformes et aux profils, - la documentation et l'aide en ligne de chaque éditeur de modèles constituées à partir des informations fournies dans les profils utilisateur. Sur la figure 3, on voit que le modèle du projet peut être divisé en plusieurs modèles spécifiques tels que par exemple: - Le Modèle de Processus qui présente l'organisation du projet (rôles, étapes, activités, résultats...) - Le Modèle des Exigences qui décrit les exigences et les cas 15 d'utilisation de haut niveau, le glossaire ou le modèle du domaine. - Le Modèle d'Architecture qui représente les exigences d'architecture, les composants de l'application et les exigences allouées à chaque composant. - Le Modèle des Composants qui détaille chaque composant de l'application. - Le Modèle d'Intégration qui décrit l'architecture d'exécution de l'application - Le Modèle de Validation qui détaille l'environnement et les 25 tests de validation Chaque modèle spécifique possède une organisation en paquetage et des stéréotypes qui lui sont propres. On définit le profil utilisateur pour un modèle donné en spécifiant les éléments de modèle et les stéréotypes de ce modèle spécifique. 30 Les relations entre les différents éléments spécifiques de chaque modèle sont fixées par des règles strictes. Par exemple, les éléments du Modèle des Exigences ne doivent pas être liés à des éléments du modèle d'architecture, mais peuvent être liés à des éléments du modèle de Validation. Sur la figure 4, on voit un éditeur de modèles sous forme d'éditeur multifenêtres constitué par un ensemble de fenêtres de type: - Navigation - Propriété - Documentation - Diagramme UML - Résultat - Annotation - Aide En particulier, on distingue sur la figure 4, une fenêtre de navigation 13, une fenêtre 14 de saisie textuelle, une fenêtre 15 de diagramme et une un onglet 16 pour la fenêtre de 10 documentation. Fenêtre de navigation Les fenêtres de navigation sont organisées à partir de la hiérarchie des modèles spécifiques et des paquetages prédéfinis dans les profils. A chaque élément représenté dans la fenêtre de 15 navigation correspond un menu contextuel qui décrit les actions réalisables sur cet élément. A chaque type d'élément, il est possible d'associer une icône spécifique. A partir de la fenêtre de navigation, il est possible de sélectionner un élément et par l'intermédiaire de 20 menus contextuels: - d'ouvrir la fenêtre de propriété associée à l'élément - d'afficher la fenêtre de documentation associée à l'élément, - de supprimer un élément, - d'ajouter un élément à l'élément sélectionné, 25 - d'ajouter un diagramme UML, - de supprimer un diagramme UML, - de déplacer un élément dans l'arborescence. Un bouton de synchronisation permet de synchroniser l'arbre de navigation avec une fenêtre de propriété ou de documentation. 30 Un même élément peut être référencé à plusieurs endroits dans l'arbre de navigation. Fenêtre de propriétés L'ensemble des éléments du modèle est accessible par 35 l'intermédiaire de la fenêtre de propriétés. - La fenêtre de propriétés d'un élément représente la liste de ses attributs et propriétés - Les fenêtres de propriétés permettent d'afficher et d'éditer l'ensemble des propriétés d'un élément au moyen de champ, de liste déroutante, de la fenêtre d'édition de texte. A chaque attribut et à chaque relation correspond une fenêtre qui 5 contient la valeur ou le lien vers l'instance associée. Les opérations sans paramètres sont représentées comme des boutons. La sélection d'un bouton permet d'exécuter une action dans le langage de script. La disposition générale de la fenêtre de propriété peut 10 être reprise par l'utilisateur en utilisant un " masque " qui lui permet de modifier la disposition de chaque champ. Edition des attributs Les attributs des éléments sont présentés dans des champs simples dont la forme dépend du type de l'élément. 15 Edition des liens Les relations entre les éléments sont présentées dans des listes. La sélection d'une entrée dans la liste permet d'afficher la fenêtre de propriété de l'élément. La création d'un lien entre deux éléments se fait par un 20 " Déplacer / Lâcher " à partir de la fenêtre de navigation. Boutons Par défaut chaque fenêtre de propriété possède un bouton de validation qui permet de valider les modifications réalisées dans la fenêtre de propriété. Ce bouton devient actif, chaque 25 fois qu'une modification est réalisée. Des boutons complémentaires associés à des séquences de code utilisateur attachées à l'élément peuvent figurer dans la fenêtre. Les interfaces des séquences de code utilisateur sont définies dans le profil. Fenêtre documentation La documentation des éléments est présentée dans des fenêtres de documentation. La documentation présente dans cette fenêtre est différente 35 de la documentation générée par l'outil. Le but de cette fenêtre est de présenter une documentation instantanée (c'est-à-dire qui se construit automatiquement à partir des informations du modèle en cours de saisie) afin de permettre à l'utilisateur de: - 17 - Voir immédiatement l'effet de sa saisie sur la documentation, - Naviguer simplement dans l'ensemble du modèle, - Choisir les éléments de présentation (fontes, styles), - Mettre en ouvre une correction orthographique. La représentation des informations dans cette fenêtre se fait dans un format qui permet une navigation aisée (HTML par exemple). La navigation dans le modèle se fait par des liens cliquables. Pour chaque élément du modèle, la documentation comprend les attributs et caractéristiques de l'élément ainsi que tous les liens de tous types attachés à cet élément (les liens multiples pouvant être présentés dans un tableau). Alors que dans la fenêtre de navigation, la représentation 15 des modèles est purement arborescente, dans cette fenêtre de documentation, la navigation se fait au gré de l'utilisateur qui peut choisir un lien parmi tous ceux qui ont été créés de et vers l'élément présenté. Cette navigation est également différente de celle qui est possible dans un diagramme (cf. fenêtre diagramme) 20 car dans un diagramme UML, seuls quelques types de liens sont représentés et il est alors nécessaire de trouver préalablement le diagramme qui contient le lien cherché. Fenêtre diagramme Les fenêtres de diagramme permettent à l'utilisateur de présenter les informations du modèle dans des diagrammes UML. A partir de l'arbre de navigation, l'utilisateur peut créer un diagramme en l'associant à un élément de modèle. La construction d'un diagramme peut se faire en deux 30 modes: le mode manuel ou le mode automatique. Mode manuel Dans le mode manuel, l'utilisateur sélectionne un élément dans l'arbre de navigation et par un " Déplacer/Lâcher " le positionne dans le diagramme UML. Les relations entre les 35 éléments présents dans les diagrammes sont représentées. L'utilisateur peut modifier la disposition et la forme (fonte, couleur, taille) des éléments présentés et ajouter de nouveaux éléments par l'intermédiaire d'une palette. - 18 Mode automatique Dans le mode automatique, l'utilisateur peut lancer une requête de création de diagramme en spécifiant les caractéristiques du diagramme comme - le type du diagramme (UML), - la liste des éléments présentés. La requête peut être spécifique ou être systématiquement appliqué à un type d'élément. Sélection d'un élément La sélection d'un élément de présentation dans un diagramme provoque l'affichage de la fenêtre de propriété de l'élément de modèle correspondant. Fenêtre résultat L'utilisateur dispose de commandes de recherche lui permettant de réaliser une recherche sous la totalité ou une partie du modèle à partir d'un ou plusieurs critères. La recherche peut se faire à partir d'un index crée 20 automatiquement à partir de directives contenues dans le profil. La fenêtre de recherche contient les résultats d'une recherche déclenchée par l'utilisateur. La fenêtre de recherche est navigable, la sélection d'une entrée de la fenêtre permet d'afficher la fenêtre de propriété ou la fenêtre de documentation 25 de l'élément de modèle associé. Fenêtre d'aide Une fenêtre d'aide peut être associée à chaque type d'élément. L'aide en ligne est construite à partir des 30 indications. Fenêtre d'annotation Les fenêtres d'annotation permettent à l'utilisateur d'associer des informations temporaires à un élément. Une 35 annotation réalisée dans une fenêtre documentation est reportée sur la ou les fenêtres Propriété correspondantes. GESTION DES ELEMENTS: - 19 Création d'un élément La création des éléments de modèle se fait à partir de menus contextuels dans la fenêtre de navigation. La sélection d'un élément fait apparaître un menu contextuel qui spécifie les sous-éléments qui peuvent être créés. Un élément peut être créé à partir du menu principal de l'éditeur, de la fenêtre de propriété du paquetage ou de la fenêtre de propriété de la classe. Lorsqu'un élément a été créé, il apparaît dans la fenêtre de navigation dans le sous-arbre de 10 l'élément dans lequel il a été défini. Un identificateur unique lui est attribué. L'identificateur unique d'un élément est un attribut implicite de cet élément. La création d'un élément fait apparaître la fenêtre de propriété de cet élément. La création d'un élément peut 15 s'accompagner de l'exécution d'une action décrite dans un langage de script. Edition d'un élément L'édition d'un élément se fait à partir de la propriété de l'élément. L'éditeur de profil fournit une organisation des 20 champs d'édition par défaut. L'utilisateur peut utiliser un mode " masque " qui lui permet de déplacer, de réorganiser la disposition ou de masquer certains champs d'édition. L'édition de la fenêtre de propriété peut être totalement surchargée par l'utilisateur à condition de se conformer aux 25 interfaces de l'éditeur La modification d'un attribut peut s'accompagner de l'exécution d'une action décrite dans un langage de script. Destruction d'un élément La destruction d'une instance se fait à partir 30 - d'un bouton de la fenêtre de propriété - d'un menu contextuel de la fenêtre de navigation associé à l'instance. La destruction d'un élément de modèle peut s'accompagner de l'exécution d'une action décrite dans un langage de script. 35 GESTION DE LA DOCUMENTATION L'éditeur de modèles fournit des commandes de génération de documentation qui permettent de présenter les éléments du modèle de projet. - A chaque élément de modèle est associée une page HTML qui présente les propriétés de cet élément suivant un format défini par l'intermédiaire de feuilles. ENTREES DE L'EDITEUR DE MODELES L'éditeur de modèle utilise en entrée les fichiers XML de l'utilisateur ou provenant de la Base de Données ou d'un autre projet. Il peut également utiliser un fichier XML construit dans les modules d'interface: - avec un éditeur UML externe. Les informations contenues dans ces éditeurs externes peuvent être transformées en XML pour insertion dans les modèles du projet. Cela permet la réutilisation de modèles existants ou la mise en òuvre de moyens de rétro-ingénierie. - avec un éditeur de texte. La structuration des informations est utilisée pour créer un fichier XML exploitable. Des éléments UML peuvent être automatiquement créés à partir du texte. - avec un gestionnaire de projet. - avec un outil de "gestion des changements" SORTIES DE L'EDITEUR DE MODELES Les sorties de l'éditeur de modèle se font d'une part dans un format XML vers: - la Base de données pour un archivage ou une exploitation par d'autres utilisateurs, ou - un intervenant externe (sous-traitant, client) - D'autre part, les sorties de l'éditeur de modèles se font également vers la documentation du projet (format HTML, 30 XHTML, Microsoft WordTM). - Les sorties se font enfin via des modules d'interfaces vers des outils externes: - outils de modélisation pour continuer le travail vers la production de code, - outils de gestion de projet pour la mise à jour des tâches et des évaluations de reste à faire. - 21 Ci-dessous, un exemple d'utilisation illustratif non limitatif du procédé selon l'invention. On considère un projet faisant intervenir trois personnes: - un utilisateur du système (appelé client dans la suite du texte), - un analyste, - un responsable méthode. Le client souhaite créer des exigences, des cas d'utilisation, consulter le modèle fonctionnel de l'analyste et y ajouter des 10 notes. Il souhaite également voir les composants créés par l'analyste ainsi que les tests qui seront exécutés pour vérifier ses exigences et ses cas d'utilisation. Il demande que les exigences soient représentées par - un titre, - un texte libre, - un numéro, - un niveau de priorité, - un numéro de version. Il demande que les cas d'utilisation soient représentés par 20 - Un texte libre, - Un numéro, - Les acteurs concernés, L'analyste peut lire les exigences et les cas d'utilisation du client. Il peut créer des modèles de classes ainsi que d'autres 25 diagrammes nécessaires à son travail d'analyste. Il crée également le modèle de tests permettant de valider le système. Le responsable méthode crée les profils des deux autres sur le poste " éditeur de profils ". Sur l'éditeur de profils Le responsable méthode définit l'ensemble des objets manipulables par le client et l'analyste avec les liens possibles. Pour le poste client, il crée les stéréotypes pour les acteurs, les exigences avec les attributs demandés. Il crée de même les stéréotypes pour les cas d'utilisation et définit l'ensemble des 35 liens que peut parcourir le client. Il ajoute les modèles créés pour l'analyste (sans droits de modification) auquel il ajoute une seule classe modifiable: les notes. - 22 Il crée une arborescence permettant au client de structurer ses informations (par exemple: tous les acteurs ensembles avec une possibilité de hiérarchiser les acteurs) . L'arborescence peut également être créée en regroupant les acteurs par sous-système. Pour le poste analyste, il crée de même les stéréotypes des différents modèles, les liens possibles et ajoute les stéréotypes du client avec la possibilité également de créer des notes. Il ajoute également les modèles de documentation en utilisant les classes qu'il a créé. Sur l'éditeur de modèles du client Le client dispose de l'arborescence dans la partie gauche de sa fenêtre. Cette arborescence contient déjà les zones suivantes - Exigences, - Acteur, - Cas d'utilisation, - Modèle fonctionnel, - Modèle de test, - Index. Il ne peut créer ses instances uniquement dans les parties 20 prévues. Il ne peut créer un acteur que dans la ou les parties de l'arborescence prévues pour contenir les acteurs. Par exemple, les arborescences Modèle fonctionnel et Modèle de test ne sont pas modifiables, sauf pour l'ajout de notes. Quand un utilisateur se place sur l'arborescence, un menu 25 contextuel lui propose uniquement la liste des actions possibles à cet endroit. S'il veut créer une exigence, le système lui propose un cadre contenant le libellé " exigence " avec des champs à remplir - numéro, - titre libellé, - niveau de priorité, - numéro de version, - un cadre pouvant contenir une liste avec le titre " exigences 35 détaillées " - un cadre pouvant contenir une liste avec le titre " cas d'utilisation associés " 23 - un cadre pouvant contenir une liste avec le titre " implémenté par " - un cadre pouvant contenir une liste avec le titre " testé par " Il n'y a pas plus de cadres qu'il n'est nécessaire pour ce projet. Le cadre des exigences détaillées permet de créer une arborescence d'exigences. Les cadres " implémenté par " et " testé par " seront remplis lorsque l'analyste aura créé les éléments correspondants dans ses 10 modèles. Ils ne sont pas modifiables par le client, mais permettent une navigation instantanée vers ces éléments. Il est à noter que les libellés des champs sont donnés à titre indicatif, le libellé est entré sur le poste " éditeur de profils " Pour la création des acteurs, on retrouvera une présentation 15 similaire. Un libellé " acteur " avec les champs - nom, - un cadre pouvant contenir une liste avec le titre " cas d'utilisation associés " un cadre pouvant contenir une liste avec le titre " référencé 20 par " Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. 25 - 24 REVENDICATIONS 1. Système de modélisation d'un projet informatique comprenant une base de données, et un éditeur de profils permettant de: - construire un modèle du projet sous forme d'une pluralité de 5 modèles spécifiques destinés à être sauvegardés dans la base de données, - définir différents types de profil utilisateur, et - construire, pour chaque type de profil utilisateur, un éditeur de modèles permettant de spécifier des éléments 10 desdits modèles spécifiques et de représenter ces modèles spécifiques sous forme de diagrammes selon le standard UML. 2. Système selon la revendication 1, caractérisé en ce que chaque éditeur de modèles comporte des moyens d'interface aptes à recevoir des informations textuelles pour spécifier des éléments 15 desdits modèles spécifiques. 3. Système selon la revendication l ou 2, caractérisé en ce que l'éditeur de profils comporte des moyens d'interface aptes à recevoir des informations textuelles pour la construction dudit modèle du projet. 4. Système selon la revendication 2 ou 3, caractérisé en ce que lesdites moyens d'interface comprennent une interface hommemachine autorisant la saisie d'informations de manière textuelle par les utilisateurs. 5. Système selon l'une quelconque des revendications 2 à 4, 25 caractérisé en ce que lesdites moyens d'interface comprennent une interface machine-machine apte à recevoir des informations textuelles provenant d'un fichier informatique. 6. Système selon l'une quelconque des revendications 2 à 5, caractérisé en ce que lesdites moyens d'interface sont aptes à 30 recevoir des informations graphiques. 7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend un modèle prédéfini à partir duquel est construit ledit modèle du projet. 8. Système selon l'une quelconque des revendications précédentes, 35 caractérisé en ce que le modèle du projet est construit selon le standard UML. 9. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que l'éditeur de profils, les éditeurs de - 25 modèles et la base de données sont conçus de façon à échanger des données selon le standard XML. 10. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'à chaque éditeur de modèles est associé un module de génération de documentation. 11. Système selon la revendication 10, caractérisé en ce que l'éditeur de modèles présente une interface homme-machine dotée au moins d'une fenêtre de saisie textuelle et d'une fenêtre apte à afficher une documentation de manière synchrone avec la saisie. 10 12. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que l'ensemble des données utiles est renfermé dans une unique base de données. 13. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il consiste en un réseau de 15 communication de type client/serveur pour lequel la base de données est disposée dans un serveur, l'éditeur de profil est disposé dans un poste administrateur, et chaque éditeur de modèles est disposé dans un poste client. 14. Système selon l'une quelconque des revendications 20 précédentes, caractérisé en ce qu'il comprend un module de filtrage apte à filtrer les données sortant de la base de données en fonction du profil de l'utilisateur désirant obtenir lesdites données. 15. Procédé de modélisation d'un projet informatique dont les 25 données sont sauvegardées dans une base de données; dans lequel procédé, au moyen d'un éditeur de profils: - on construit un modèle du projet sous forme d'une pluralité de modèles spécifiques destinés à être sauvegardés dans la base de données, - on définit différents types de profil utilisateur, et on construit pour chaque type de profil utilisateur, un éditeur de modèles permettant de spécifier des éléments desdits modèles spécifiques et de représenter ces modèles spécifiques sous forme de diagrammes selon le standard 35 UML. 16. Procédé selon la revendication 15, caractérisé en ce qu'on définit ledit modèle du projet à partir de données contextuelles dudit projet. 26 17. Procédé selon la revendication 15 ou 16, caractérisé en ce qu'on spécifie des éléments desdits modèles spécifiques à partir des informations textuelles. 18. Procédé selon l'une quelconque des revendications 15 à 17, 5 caractérisé en ce que pour chaque type de profil utilisateur, on construit l'éditeur de modèles de façon à n'autoriser l'accès qu'à certains éléments prédéterminés dans chaque modèle spécifique. 19. Procédé selon l'une quelconque des revendications 15 à 18, 10 caractérisé en ce qu'on associe à chaque éditeur de modèles un module de génération de documentation apte à afficher sur une fenêtre de l'interface homme-machine de l'éditeur de modèles une documentation évoluant de façon synchrone avec la saisie d'information, cette saisie d'information étant réalisée dans une 15 fenêtre de saisie de ladite interface homme-machine. 20. Procédé selon l'une quelconque des revendications 15 à 19, caractérisé en ce que lorsqu'un utilisateur édite un modèle spécifique dans l'éditeur de modèles, on affiche un diagramme de type UML dudit modèle spécifique dans une fenêtre graphique d'une 20 interface homme- machine dudit éditeur de modèles.