UML (pour Unified Modeling Language) est-il “limité” à un langage unifié pour la modélisation ? Ou bien, comme certains éditeurs ?” tels Rational, Telelogic ou TogetherSoft ?” le présentent, est-ce une technologie servant également à d’autres fins : la génération automatique de code à partir de modèles ou de diagrammes (le reverse engineering permettant de passer du code aux diagrammes) ou encore la modélisation de processus métier (Business Process Modeling) ?Pour Jacques Mercey, vice-président de la recherche & développement de l’éditeur Mega, “UML n’a pas obtenu la réussite escomptée “. Notamment pour une raison financière : “Les équipes de développement doivent faire face à un problème d’urgence aujourd’hui incompatible avec la technologie UML : les bonus de fin d’année des développeurs sont généralement calculés sur les projets en cours et non pas sur les projets sur deux ans “.Pour David Duquenne, directeur technique projets et méthodes de la société Improve, “UML nécessite une certaine culture pour en comprendre la finalité. Notamment sur le plan des compétences et de la charge de travail induite “. Et d’ajouter : “Quand il n’y a pas d’interlocuteurs sur un projet de développement, UML n’est pas adapté “. C’est fréquemment le cas sur les petits projets. Pour preuve, il n’y a qu’une minorité de projets de développement qui ont recours à la technologie UML.
Une technologie adaptée aux grands projets
D’après Gartner, moins de 15 % des projets de développement (toutes tailles confondues) sont conduits avec un outil UML. A tel point que selon Jacques Mercey, “le premier outil employé pour faire de l’UML est le traitement de texte Word “. Même constat pour David Duquenne, d’Improve, qui précise : “Word présente l’avantage d’être lisible par tout le monde, y compris des clients, et cela apporte une certaine souplesse “.Mais, pour les projets importants, UML remplit convenablement deux impératifs : la communication et la documentation technique. Plus précisément, il est très satisfaisant lorsque l’entreprise a pour objectif de favoriser la communication entre les interlocuteurs d’un projet qui n’ont pas la même compétence. “Typiquement, la maîtrise d’ouvrage n’a pas de compétence technique mais elle dispose d’une expérience. Alors que la maîtrise d’?”uvre a une expertise technique mais elle est dépourvue d’expérience métier. Depuis l’arrivée d’UML, un pont s’est créé entre ces deux équipes”, résume David Duquenne. Plus récemment, les technologies d’internet ont contribué encore plus à développer l’usage d’UML. Le directeur technique projets et méthodes d’Improve le souligne : “Avec les projets web et intranet, un fossé s’était creusé entre la maîtrise d’ouvrage et la maîtrise d’?”uvre, ni l’une ni l’autre ne sachant évaluer les potentiels de ces projets pas plus qu’elles ne savaient tenir compte des caractéristiques d’internet telles que la lenteur d’accès et les problèmes d’ergonomie. La maîtrise d’ouvrage a compris qu’il fallait utiliser un langage de technicien. UML répond bien à cet impératif “.
Des qualités de documentation appréciées
“La modélisation est un moyen de formaliser et de comprendre un problème”, souligne Jacques Mercey. Et cette formalisation prend la forme d’une documentation. Ainsi, UML permet-il d’établir une documentation technique ?” diagrammes, design patterns, etc. ?” à destination des développeurs. Ces qualités de documentation, Didier Bary, responsable de projet au sein d’Aga Médical, la filiale pharmaceutique française du Groupe Linde, les a largement appréciées. “Notre activité de fabrication et de distribution de gaz médicaux nous assujettit à une réglementation forte en matière de traçabilité. Nous avons dû concevoir et développer un projet documentaire, informatique et organisationnel de traçabilité qui réponde à un objectif de documentation très important pour déposer les demandes d’autorisation sur le marché. Sur ce point, le recours à un langage unifié tel que UML est d’un très grand secours.” Cette société, qui ne dispose pas de service informatique, a dû confier ses développements à l’extérieur. Là aussi, souligne Didier Bary, “UML est d’un grand intérêt dans la mesure où la rigueur du langage permet d’établir une communication dirigée. Ainsi, est-ce tout à fait viable d’externaliser un projet UML”, conclut-il.
Une génération de code inefficace
Les éditeurs historiques d’outils UML tentent de séduire un public plus large que celui des seuls spécialistes. Ils s’adressent notamment aux développeurs, en mettant en avant des fonctionnalités telles que la génération automatique de codes à partir de diagrammes UML. En théorie, cela permet d’être plus productif en épargnant aux développeurs une partie de la charge de travail d’écriture de code. Mais cette fonctionnalité n’est pas satisfaisante.A tel point que la génération automatique de code peut devenir contre-productive, selon David Duquenne. “Il n’y a pas d’outil UML de type presse-bouton, explique-t-il. Les raisons : le code généré n’est pas forcément adapté au modèle de développement en vigueur et les générateurs, tel celui intégré dans Rose de Rational, ajoutent des lignes de code qui polluent la lecture et perturbent les développeurs “. Il souligne néanmoins que XDE, le nouvel outil UML, de Rational, a fait des progrès importants. Notamment en design patterns (applicables à telle ou telle classe utilisateur) ainsi qu’en capacité de génération de diagrammes et de code. Sur ce point, Jacques Mercey est plus radical : “Ce qui fait la qualité du code, c’est la qualité du développeur “. Sauf dans un cas particulier : “Celui de la déclaration des interfaces entre les spécifications et la réalisation “.Peu d’entreprises utilisent la fonctionnalité, de plus en plus souvent mise en avant par les éditeurs, de reverse engineering des outils UML ?” c’est-à-dire la possibilité de mettre à jour les diagrammes à partir du code. La première raison est culturelle : les développeurs n’ont pas pour habitude de toucher aux diagrammes après être intervenus sur le code. David Duquenne ajoute : “Le recours au reverse engineering signifie qu’il y a un problème, une dérive dans le projet initial. Le seul intérêt de cette fonctionnalité est de réaliser un audit du projet “. La possibilité de modéliser les processus métier, également appelée Business Process Modeling (BPM) n’a pas davantage de succès. Pour Jacques Mercey, “UML n’est pas conçu pour faire du BPM. Il est bâti pour modéliser les applications. Si on l’optimise pour faire du BPM, cela devient contre-productif car on créé une ambiguïté en mélangeant ce dernier et la modélisation d’applications “. Pour Rational, l’un des pères fondateurs du langage unifié de modélisation, c’est l’inadaptation des outils qui est en cause. On se demande alors pourquoi les outils n’ont toujours pas résolu ce décalage.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
