Choisir un outil de modélisation UML
|
Les critères suivants peuvent être utilisés quand vous évaluez un outil de modélisation UML. Il y a plusieurs produits sur le marché qui répondent à ces critères. Puisque vous voulez le meilleur, d'entre eux prenez le temps d'évaluer les produits que vous testez en suivant cette liste. Si vous avez un critère particulier auquel vous tenez et qui ne se trouve pas dans cette liste, s'il vous plaît prévenez-nous.
Pour un grand projet, un répertoire est nécessaire pour le partage de composants de dessins entre développeurs. Deux développeurs ou plus, peuvent partager les composants d'un modèle ou même collaborer au développement d'un composant seul par la définition de la propriété et le partage de droits au niveau approprié. Un répertoire est construit, en général, sur une base de données qui fournit les fonctions de partage de données et de contrôle concourant. Par un système de fermeture sécurisée et un accès en lecture seule, le répertoire autorise qu'un seul concepteur possède le modèle tout en permettant aux autres de lire le modèle et ses composants et aussi d'incorporer ces composants dans leurs propres dessins. Important : L'outil doit vous permettre de sélectionner seulement les composants que vous voulez d'un autre modèle, sans avoir besoin d'importer le modèle entier. Une autre façon intéressante de construire le répertoire est de le construire au-dessus du code source pour un projet, en utilisant un système du contrôle de code source pour fournir le contrôle concourant. L'avantage de cette approche est que vous obtenez un degré de synchronisation plus haut entre le code et le modèle. Un autre avantage est l'élimination d'une source de données supplémentaire. N'oubliez pas que si vous utilisez une base de données pour un répertoire, il faut créer une sauvegarde des données entreposées séparément. En plus il faut exécuter une synchronisation a trois entre le modèle, le répertoire et le code source, au lieu de faire simplement une synchronisation bilatérale entre le code et le modèle. Avec les outils de modélisation qui supportent un répertoire, les changements à tout composant doivent être propagés automatiquement à tout dessin qui importe le composant.
La capacité d'appliquer l'ingénierie et la rétroingénierie au code source (Java, C++, CORBA IDL) est une exigence complexe. Elle est supportée par les vendeurs, avec des degrés variables de succès. La bonne combinaison de ces deux fonctions, ingénierie et rétroingénierie, est définie comme Round-Trip Engineering, 'Le génie aller-retour'. L'ingénierie est très utile la première fois que le code est généré à partir d'un modèle. Cela vous évite beaucoup de travail de saisie banal dans les classes, les attributs et les méthodes. La rétroingénierie est très utile aussi bien pour transformer le code dans un modèle quand aucun modèle n'a existé précédemment, que pour synchroniser de nouveau un modèle avec le code à la fin d'une itération. Une fois un modèle mis à jour comme partie de l'itération pendant un cycle du développement de l'itérative, une nouvelle étape d'ingénierie doit permettre au code d'être rafraîchi avec toutes les nouvelles classes, méthodes ou attributs qui ont été ajoutés au modèle. Cette étape est moins communément adoptée par les développeurs parce que beaucoup d'outils peuvent détruire le code source durant le processus. Le problème est que le code source contient beaucoup plus que le modèle ; les outils doivent être très habiles à reconstruire le code source qui a existé antérieurement à la nouvelle étape d'ingénierie. Au minimum, l'outil de modélisation doit supporter avec succès l'ingénierie la première fois et la rétroingénierie pendant tout le processus. En plus, l'outil ne doit avoir aucun problème à appliquer le principe de rétroingénierie à tout le langage Java. Assurez-vous de vérifier que cette fonction existe pour votre propre code source, nous avons constaté que des outils bien établis ont échoué sur la rétroingénierie appliquée aux fonctions de Java telles que les classes intérieures. Chaque fois que vous utiliserez la rétroingénierie vous serez forcé de créer un code pour détruire le code offensif — vraiment pénible !
L'outil de modélisation d'objet doit générer en continu la documentation HTML pour un modèle d'objet et ses composants. La documentation HTML fournit une vue statique du modèle d'objet, que tout développeur qui utilise le modèle peut repérer rapidement dans un navigateur, sans avoir besoin de lancer l'outil de modélisation lui-même. De cette façon, en produisant la documentation HTML, vous réduisez le nombre de licences exigées pour l'outil de modélisation, nombre de personnes n'ayant besoin que d'un accès en lecture seule à l'information du modèle. La documentation HTML doit inclure une image bitmap de chacun des diagrammes du modèle et permettre la navigation partout dans le modèle grâce à des liens hypertexte. Le temps nécessaire pour produire l'HTML doit être raisonnable. Plusieurs produits disponibles aujourd'hui supportent ces fonctions avec des niveaux de succès variables. À nouveau, prenez soin de vérifier ces fonctions vous-même. Une case cochée sur un tableau de fonctions n'est pas une garantie de succès.
Beaucoup d'outils prétendent être compatibles complètement avec UML 1.3, en réalité c'est une exigence complexe et certains outils peuvent ne pas être à la hauteur de leurs prétentions publicitaires de compatibilité totale. Au minimum, les diagrammes qui doivent être supportés sont les diagrammes de Cas d'Usage, de Classe, de Collaboration, de Séquence, de Paquet et d'État.
L'outil de modélisation doit fournir des listes de sélection dans plusieurs interfaces clés : Collaboration et Diagrammes de Séquence - L'outil doit permettre à un objet d'être assigné à une classe à partir d'une liste des classes dans le modèle. Il doit permettre que les messages envoyés entre objets soient choisis dans une liste valide de méthodes pour l'objet (classe) qui reçoit le message. Diagramme de classe - L'outil doit autoriser l'importation de classes à partir d'autres paquets ou modèles basés sur la sélection de classe qui se trouve dans une liste de classes dans le paquet. La fonction liste de sélection contribue considérablement à l'intuition de l'outil de modélisation et pourrait être considérée comme une fonction essentielle. Le développement de diagrammes de séquence et de collaboration est facilité par la capacité de sélectionner le message rapidement quand vous voulez l'envoyer d'un objet à un autre.
L'outil de modélisation d'objet doit permettre l'intégration avec des fonctionnalités de modélisation des données. Il y a beaucoup de façons de fournir ces fonctionnalités. L'une des possibilités est que l'outil UML comprenne une fonction qui permet au modèle d'objet d'être transformé en DDL. DDL est le SQL nécessaire à la création de tables pour les classes. L' outil UML peut également exporter les métadata vers l'outil de modélisation des données qui peut les importer et les utiliser comme base d'un modèle de données. Un ensemble d'outils intégré avancé doit permettre la synchronisation des modèles de données et des modèles d'objet après chaque itération du dessin.
L'outil de modélisation doit permettre la sauvegarde des versions pour qu'une fois les itérations subséquentes commencées, la version antérieure soit disponible pour la restitution ou conservation du code existant qui s'appuie sur cette version.
L'outil de modélisation doit fournir un support de navigation fort pour permettre à un développeur de naviguer à travers tous les diagrammes et classes dans le modèle. Un répertoire ou liste de sélection de classes assorties par nom est une façon de permettre à un dessinateur de sauter directement à la classe désirée sur un diagramme. Pour les grands diagrammes, l'outil doit fournir une facilité de navigation pendant la vue zoom et la vue panoramique. L'outil doit autoriser également une facilité de navigation au code source pour une classe quand le Round-Trip Engineering est utilisé.
L'outil de modélisation doit fournir des interprétations exactes de grands diagrammes qui vont être produits par l'impression de pages multiples. Les fonctions d'aperçu avant impression et vue de l'échelle doivent être supportées pour permettre de proportionner facilement le diagramme au nombre désiré de pages. La capacité de proportionner un diagramme à une seule page est prioritaire sur cette liste. Malheureusement, nous nous sommes rendus compte que beaucoup d'outils ont des difficultés à exécuter cette tâche importante en continu.
L'outil de modélisation doit faciliter la customisation de la vue d'une classe et ses détails. Par exemple, il doit être possible d'exclure toutes les méthodes du get/set du diagramme puisqu'ils ont tendance à encombrer, plutôt que clarifier un diagramme. La signature complète de méthodes doit permettre d'être montrée ou cachée facilement, selon le niveau de détail désiré. La visibilité d'attributs et méthodes (privé, protégé, public) doit être un autre procédé utilisé pour sélectionner ce qu'il faut montrer ou cacher sur le diagramme.
Une fonction clé qui est souvent négligée est la capacité d'exporter les diagrammes dans un format qui peut être importé dans ou un document du traitement de texte ou une page web. Les formats graphiques les plus populaires pour l'exportation sont le GIF et le JPEG. Pendant l'exportation, l'outil doit vous permettre de définir la résolution et les dimensions préférées du graphique qui est produit. Cette fonctionnalité est exigée par des auteurs ambitieux, désireux d'écrire un livre UML comprenant des diagrammes ou souhaitant afficher leur travail sur un site web (clin d'œil !).
Le scripting est une autre fonction puissante qui doit être supportée par un outil de modélisation. Avec le scripting, l'utilisateur de puissance peut créer des scripts qui peuvent accéder directement au modèle d'objet dans l'outil de modélisation pour le but de créer d'autres objets. Les exemples de ces objets sont les feuilles de calcul de la gestion du projet pour le projet en cours de conception, la documentation personnalisée, le code personnalisé, les rapports et le comptage. Un code personnalisé est, par exemple, celui des signatures pour les classes de collection et les méthodes du get/set utilisé pour accéder aux classes de collection. Pour faciliter le scripting, l'outil de modélisation doit exposer des interfaces internes au modèle d'objet pour permettre l'accès aux composants du modèle d'objet en cours de conception. (Si vous avez l'impression que ça tourne en rond, relisez !) Par exemple, l'écrivain de script doit pouvoir accéder à la collection de classes dans un diagramme de classe par une itération et ensuite aux propriétés des classes grâce aux méthodes d'accès à l'objet de classe. Bien sûr, le langage du scripting doit lui-même être basé sur l'objet; le langage Java est l'un des choix évidents, de même que le langage de scripting de Python.
Vous voulez un outil UML très fiable, qui évite que les utilisateurs perdent le résultat d'heures de productivité à cause d'un outil qui se plante au milieu d'une session de dessin ou qui corrompt un modèle non sauvegardé. Nous avons vu plusieurs outils majeurs causer la perte d'heures de travail par un plantage ou une corruption du dossier. Si vous êtes développeur, vous n'avez que mépris pour les applications dites « de productivité » qui sont moins productives que les outils de codage brut. Si vous êtes directeur, vous avez vu la rancune montrée par les développeurs obligés à utiliser un outil peu fiable. Aujourd'hui la robustesse peut être trouvée souvent dans les applications exécutées en Java (JVM, phase d'exécution protection) ou comme projets de source ouverte (Internet, déboguer en parallèle). La façon la plus rapide de déterminer si un outil UML particulier est robuste c'est d'en parler avec un newsgroup tel que comp.object. Vous êtes sûr d'en prendre plein les oreilles ! Nous recommandons aux vendeurs de l'outil d'adopter ici une autre stratégie empruntée aux applications de productivité en bureautique. Cette stratégie est de demander à un outil UML de sauvegarder automatiquement un modèle UML en arrière plan à intervalles réguliers.
Afin d'optimiser votre investissement dans un outil de modélisation, considérez attentivement les plates-formes sur lesquelles s'exécutera cet outil. Allez-vous développer des produits pour Windows, pour Unix ou pour les deux ? Sur quelle plate-forme développerez-vous ? Des événements récents ont contribué à faire exploser le mythe que d'excellentes interfaces graphiques utilisateur multi plates-formes ne fonctionneraient jamais ou n'auraient qu'un faible dénominateur commun pour ce qui est de l'apparence ou du comportement. Pendant un long moment, ce fut vrai (à part pour les applications basées sur le format HTML) jusqu'à la récente apparition de l'interface utilisateur Swing de Java. Cependant, les outils multi plates-formes doivent être supportés par des plates-formes générales comme Linux pour obtenir une large adhésion par les programmeurs. A l'origine, Sun n'a pas énormément promu Java sur Linux. Mais de récentes initiatives industrielles, principalement de la part d'IBM, qui s'est engagé à fournir un large support pour Linux sur toutes ses plates-formes matérielles et soutient le projet Apache/Jakarta, contribuent à rendre Java rapidement utilisable sous Linux. Peut-être parce qu'IBM s'est mis à distribuer sa version du JDK 1.1.8 aux principaux éditeurs Linux, Sun a été contraint de fournir une version pleinement fonctionnelle du JDK 1.2 (Java 2 avec Swing) sous Linux. Le portage de Java sous Linux a été très largement accompli grâce aux efforts du « Blackdown Group ». Aussi loin que nous ayons testés des outils UML basés sur Swing, les résultats sont excellents mais il faut noter que 128 Mo de mémoire est un plus appréciable.
Vous voulez probablement choisir un outil qui continuera à être amélioré avec des corrections de bogues, une amélioration des performances et l'addition de nouvelles fonctionnalités. Après tout, vous êtes en train de réaliser un gros investissement en temps et en argent et il n'est pas évident de changer d'outil de modélisation. Faites attention aux produits qui ont été achetés par de grosses compagnies. Très souvent, les développeurs à l'origine du produit ont quitté depuis longtemps l'entreprise (après avoir revendu leurs actions dans l'affaire) pour suivre une autre opportunité importante. Il est très difficile de trouver des développeurs talentueux qui peuvent comprendre une partie complexe d'un logiciel et qui veulent bien l'entretenir s'ils n'en ont pas écrit le code original. Ce scénario peut aussi bien se présenter pour un projet en « open source ». Comment pouvez-vous déterminer si un produit évolue ? Demandez au vendeur du produit un historique des versions récentes et le plan d'amélioration du produit dans l'avenir. Regardez attentivement la fréquence de réalisation des améliorations et des fonctionnalités. Quand le produit sera-t-il planifié pour supporter UML 1.3 ? L'interface graphique utilisateur est-elle compatible avec les dernières conventions de styles ? Vous pouvez également consulter le site Internet de la société : si les annonces du produit et les critiques externes sont anciennes, soyez suspicieux.
Et maintenant, nos souhaits pour le futur. La maturité actuelle des outils de modélisation indique que les vendeurs de ces outils sont prêts à les mener à un niveau supérieur de sophistication. Nous espérons voir quelques-unes des fonctions suivantes apparaître dans les produits de la prochaine génération.
Pendant le développement de l'itérative d'un modèle, c'est très productif de regarder le diagramme UML et son code source assorti dans les fenêtres adjacentes. Les produits qui supportent cette coordination de vues pourraient ajouter une dimension de pouvoir à la boîte à outils d'options du dessinateur de modèles en ajoutant des fonctions puissantes d'édition de code source directement à l'outil de modélisation. Même si l'outil de modélisation n'est pas nécessairement l'éditeur principal du dessinateur, il est assez utile de pouvoir changer le nom ou la signature d'une méthode directement dans le code pour que le changement soit immédiatement reproduit dans le modèle. En tête de la liste des fonctions souhaitables nous mettons l'émulation de claviers d'éditeurs populaires tels que les emacs. Une autre fonction poussée est la couleur dans le codage du code pour mettre en valeur des mots clés de le langage, des commentaires, etc. Cette fonction faciliterait la lisibilité du code. Une fonction essentielle est la capacité de sauter directement à la ligne assortie de code quand une classe, attribut ou méthode sur un diagramme de classe est sélectionnée. Par-dessus tout, l'éditeur doit être rapide et facile à utiliser. En variation sur ce thème, une autre solution est de permettre à l'outil de modélisation de communiquer avec l'éditeur favori du développeur. Par exemple, une touche personnalisée pourrait permettre à l'outil de modélisation de passer de la fenêtre active à celle de l'éditeur compagnon, avec la mémoire tampon placée sur la ligne de code assortie.
Une fonction que nous aimerions voir dans le futur proche est la capacité des outils de modélisation à assister dans la génération de diagrammes d'interaction et d'état. C'est comme ceci qu'il doit marcher : l'outil de modélisation doit faciliter la création d'un dossier de suivi pendant l'exécution d'un programme existant. Le but de ce dossier de suivi serait de capter l'interaction entre objets pendant qu'ils se transmettent des messages. Une fois le dossier de suivi créé, l'outil de modélisation serait utilisé pour analyser le suivi pour trouver les tendances d'interactions de l'objet. L'outil de modélisation doit permettre à l'utilisateur de sélectionner d'un groupe de classes à analyser. Alors, l'outil pourrait présenter chaque ensemble unique d'interactions qui ont été enregistrées par le dossier de suivi pour ces classes et permettre à l'utilisateur de sélectionner quelles interactions modeler. En fin, l'outil doit être capable de produire un diagramme de séquence ou de collaboration basé sur les interactions de l'objet réelles, enregistrées. Cool hein ! Cela ne devrait pas vous paraître trop futuriste, la technique du suivi a déjà été utilisée efficacement par des outils qui aident les développeurs à localiser les goulets d'étranglement de la performance dans leurs programmes. Un exemple agréable de produits dans cette catégorie est JProbe du KL Group qui est utilisé pour analyser la performance de programmes Java. Ce doit être aussi possible d'auto produire des diagrammes d'état en utilisant la même technique; une modification à la séquence précédemment décrite serait de permettre à l'utilisateur de spécifier le nom d'une classe de base pour les états dans la machine d'état. L'outil de modélisation suivrait des interactions entre les classes dérivées de la classe de base. De ce suivi, l'outil de modélisation pourrait créer un diagramme d'état par la création d'un diagramme de chacune des transitions d'état enregistrées.
Si vous êtes le directeur de projet type, vous désirez certainement pouvoir mesurer la progression de votre projet O-O. Une fonction sympa qui devrait être intégrée dans les outils de modélisation est la capacité d'exporter l'information dans un outil qui vous permettra de suivre le progrès du dessin et la mise en œuvre de votre projet. La feuille de calcul est un outil idéal à appliquer à cette solution à cause de sa familiarité et sa flexibilité. Les outils de gestion du projet sont aussi des applications idéales. Comment est-ce que cette fonction marcherait ? À haut niveau, typiquement ce que vous aimeriez suivre seront les classes dans le modèle et les personnes qui sont assignées pour y travailler. Vous voulez savoir quand quelqu'un a commencé à travailler sur la classe et quel est le niveau d'achèvement atteint. Au prochain niveau de détail, vous voulez avoir des renseignements au sujet des méthodes pour chaque classe. À ce niveau vous vouliez savoir quelles méthodes ont été incluses dans les diagrammes de l'interaction ou, pendant la phase de la mise en œuvre, combien de code a été complété pour chaque méthode. Pour que cette fonction soit efficace, vous aurez besoin d'une mise à jour « smart » de votre information sur la gestion du projet. Contrairement aux outils de rapport qui produisent à chaque fois un nouveau rapport, toujours à partir de zéro, vous voulez tout exporter uniquement la première fois. Après l'exportation initiale, votre outil de modélisation doit simplement mettre à jour votre outil de gestion avec la nouvelle information. Selon le niveau de contrôle désiré par l'utilisateur, l'outil de modélisation pourrait présenter à l'utilisateur une liste de mises à jour avant d'exporter. Un des dividendes agréables qu'un lien avec la gestion du projet doit fournir est la capacité de viser des dates d'achèvement pour l'analyse et phases du dessin d'un projet. Cela devrait fonctionner en calculant le taux de progression et en utilisant ce taux pour calculer les dates prévues d'achèvement en se basant sur les tâches restant à effectuer pour terminer le modèle.
Quand votre projet commence à mûrir, il se peut que vous désiriez avoir accès au comptage de votre modèle. Le comptage peut donner quelques renseignements immédiats à l'architecte O-O sur la viabilité d'un modèle particulier. Certains traits intéressants du comptage sont : le nombre de super classes dans une hiérarchie de classe, le nombre de méthodes par classe, le nombre d'attributs par classe, le nombre de méthodes get/set, le nombre de méthodes court-circuitées, les lignes de code pour chaque méthode, le pourcentage de méthodes de types public, privé et protégé, le degré de couplage par classe (le nombre de classes différentes sur lesquelles cette classe est renseignée), et le pourcentage de méthodes commentées. Le comptage pourrait être fourni à travers une interface de rapport ou, encore mieux, à travers un lien vers une feuille de calcul semblable au lien à la gestion du projet décrit auparavant.
Pour proposer une véritable fonctionnalité d'importation / exportation de graphiques basés sur un standard vectoriel, les éditeurs d'outils UML ont une option. Les recommandations du W3C (World Wide Web Consortium) pour des graphiques vectoriels à échelle variable, (SVG pour Scalable Vector Graphics) sont une grammaire XML pour des graphismes, grammaire qui est arrivée à maturité avec les spécifications de la version 1.0 dans la dernière révision du 3 mars 2000. Une fois que ce standard sera pleinement approuvé, vous pourrez vous tourner vers les vendeurs de navigateurs HTML pour que leur prochaine version de navigateurs supporte ce format. Pourquoi SVG ? Parce qu'un ensemble de diagrammes UML exporté en utilisant la technologie des graphiques vectoriels peut être lié à des pages web. Un lecteur d'un tel document de modélisation UML mis en ligne serait à même d'employer des techniques graphiques tel que le zoom et la vue d'ensemble au sein même du navigateur pour explorer plus facilement un large diagramme UML. En outre, ce format améliorerait nettement la rapidité avec laquelle un large diagramme pourrait être chargé sur le web en comparaison avec les diagrammes au format GIF. Pour preuve, regardez avec quelle rapidité sont chargées aujourd'hui les présentations Macromedia Flash dans les navigateurs. Pour souligner l'importante différence entre les images GIF et les graphiques vectoriels dans un environnement d'édition, nous avons préparé une simulation en créant un fichier au format PDF d'Adobe qui inclus deux représentations d'un diagramme de classes, l'un est un diagramme importé au format GIF et l'autre une image vectorielle. Vous pouvez télécharger ce document PDF et le visionner dans Adobe Acrobat Reader. Essayez d'agrandir à un niveau tel que 800 % ou 1600 % et comparez les résultats entre les deux diagrammes. Cette expérience n'est pas irréaliste : vous pouvez vouloir réaliser une représentation murale qui est agrandie à un niveau suffisant pour offrir une bonne lisibilité. Téléchargez le fichier PDF avec les deux diagrammes (GIF vs SVG). Pour voir un aperçu du futur d'UML et SVG, nous avons également préparé une démonstration utilisant SVG pour afficher un diagramme de classe dans un navigateur. Pour voir cette démonstration, vous devez d'abord vous procurer un outil permettant l'affichage de graphiques SVG dans votre navigateur. Nous vous recommandons l'extension de l'aperçu de la technologie SVG chez Adobe. Ensuite, vous pourrez voir les modèles de graphiques dans la démonstration SVG.
Le XMI standard de Groupe de gestion d'objets (OMG) est l'un des développements récents les plus passionnant pour la communauté des développeurs de l'UML. XMI est un format d'échange qui a la capacité d'autoriser le partage en continu des modèles entre les outils de développement les meilleurs de la nouvelle génération. Par exemple, plutôt que d'écrire les scripts dans un outil de modélisation UML pour créer des rapports, un utilisateur pourrait exporter le modèle en cours de conception en utilisant XMI et simplement importer le modèle dans un outil spécialisé en écriture de rapports. En effet ce paradigme s'appliquerait bien à toutes les fonctions discutées précédemment ; le suivi de comptage O-O et la gestion de projet. De plus, puisque XMI utilise XML pour représenter l'information du modèle, une famille de solutions XML est disponible immédiatement, telles que les feuilles de style XSL pour la présentation basée sur le navigateur et les outils d'interrogation XQL pour les fonctions de recherche.
Le standard XMI est complexe et la résolution des nombreux problèmes de compatibilité inévitables prendra du temps (qui a dit que les standards ne sont pas ouverts à l'interprétation ?) avant que son déploiement ne se fasse sur une large échelle. Cependant, depuis que XMI est développé par les poids lourds de l'industrie IBM et Unisys, entre autres entreprises de pointe, on prévoit que les produits sortiront bientôt. C'est à la communauté des utilisateurs d'exiger que les outils UML supportent XMI en plaçant cette fonction en haut des listes de contrôle. Pour information supplémentaire sur XMI, voyez la page web IBM qui est excellente. Si vous voulez voir un exemple d'utilisation possible de XMI, voyez notre projet : Transformation de XMI en HTML. Le projet montre comment des feuilles de style XSL peuvent être utilisées pour produire une représentation HTML d'un modèle UML. Critères du lecteur Si vous avez des idées de nouvelles fonctions pour les outils de modélisations UML non incluses dans cette liste, contactez-nous. Nous remercions les lecteurs qui nous ont envoyé par courrier électronique les critères des outils UML qu'ils apprécieraient. Jetez un coup d'œil à leurs suggestions originales. |
|
|
Copyright © 1999-2005 Objects by Design, Inc. Tout droits réservés.
