Passer au contenu

La modélisation UML n’offre pas un retour sur investissement rapide

L’évolutivité des logiciels créés avec le langage unifié de modélisation (UML) est réelle, mais n’intervient pas dès les premiers projets.

Le langage UML de description et d’analyse orienté objet est devenu l’un des standards du cycle de développement des logiciels. Indépendant des langages de développement, il est composé de neuf types de diagrammes – cas d’utilisation, classe, objet, collaboration, séquence, activité, états/transition, composant et déploiement. Résultant de la fusion de trois méthodes – OMT, Booch et Oose -, ce langage a été normalisé en 1997 par l’Object Management Group (OMG). Intégrées par de nombreux éditeurs, dont Rational et Embarcadero, les spécifications UML font plus que former un cadre commun à tous les développeurs. “Sans outil de ce type, nous aurions mis moins de temps à développer notre produit, affirme Jean-Christophe Hurpeau, chef de projet d’Ortho Clinical Diagnostics. Mais il contiendrait un code moins lisible et peu documenté.”

Un pari sur la nécéssaire évolution des logiciels

Après avoir bâti sans modèle un logiciel en C++ visant les centres de transfusion, la société lance en 1999 un deuxième projet, destiné aux laboratoires privés et hospitaliers. “Notre première application était peu évolutive et nous n’étions pas à l’abri d’une perte de connaissance due au départ de l’un des membres de l’équipe, explique Jean-Christophe Hurpeau. En prenant un outil de modélisation UML, nous éliminons ce risque et pouvons plus facilement modifier le logiciel.”Louée par les éditeurs, la conformité à la norme UML semble peu importante. “De toute façon, le formalisme est assez mouvant “, estime Denis Kleinberger, chef de projet et utilisateur pilote chez Canal + Technologies. Pour lui, il s’agissait surtout de choisir un outil générant automatiquement du code. “Nous avions un grand nombre de classes à créer. Il fallait donc une génération fiable et personnalisable “, poursuit-il. En cas de modification manuelle du code, les produits de modélisation peuvent transformer en conséquence les diagrammes (reverse engineering). Mais la systématisation de cette fonction n’est pas forcément souhaitable. “Cela marche mieux avec Java. Le langage s’y prête mieux, ajoute Denis Kleinberger. Mais comme nous programmons en C++, ce n’est pas pertinent.” Enfin, parce que les gros développements impliquent de nombreux développeurs, les fonctions de travail collaboratif se multiplient. Dans l’outil Rational Rose, elles sont minimales. “Il suffit de mettre en place une organisation adaptée “, assure Jean-Luc Barrière, chef de projet chez EADS Sycomore. Pour lui, cette carence a un avantage : “La modélisation ne s’appuie pas sur une base de données (contrairement à GDPro – NDLR), mais sur des fichiers Ascii. L’infrastructure est donc moins lourde.”

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Renaud Edouard