La conception et la programmation objet se sont imposées ces dernières années. Elles offrent en effet une meilleure évolutivité des systèmes à base de composants, mais aussi une plus grande interopérabilité, et même une distribution en réseau des applications grâce à des technologies comme Corba où D/COM. Avec plus de 70 méthodes et variantes coexistant, il manquait malheureusement une méthodologie standard de développement objet à l’échelle industrielle. C’est dans ce but qu’UML 1. 0 (Unified Modeling Language), a été conçu et publié en janvier 1997. Toutefois, UML n’était pas une méthode, mais une simple notation unifiée pour les modèles objet. Elle a, depuis, subit des révisions précisant les dernières ambiguïtés sémantiques, pour en arriver à sa version actuelle, UML 1. 3 (bientôt UML 2. 0), qui s’est rapidement imposée dans l’industrie comme standard de fait.
UML utilise neuf diagrammes standards
Dans la pratique, UML se présente comme une notation graphique, c’est-à-dire un ensemble de symboles standardisés ou stéréotypes (ou de mots clés), permettant de représenter les notions objet avec une sémantique précise. Parmi les symboles on distingue des formes en deux dimensions (les n?”uds) et différents types de liens qui les relient. En général, la position précise des éléments sur le schéma n’a que peu d’importance (sauf cas particulier du diagramme de temps, qui peu avoir recours à une métrique), seule importe la relation entre les éléments. Leur fonctionnement détaillé est précisé par du texte sur les schémas. UML est une norme ouverte et la liste des stéréotypes est extensible en fonction des besoins.
Ces éléments de base sont combinés de manière à obtenir neuf diagrammes standards : les diagrammes de cas (structure des fonctions nécessaires aux utilisateurs, utilisés en phase de capture des besoins ; les diagrammes de classes (peut-être les plus importants, ils représentent la structure des objets : définition des attributs, relations d’agrégation et d’héritage entre classes, etc. ) ; les diagrammes d’objets (utilisés pour préciser la structure des classes compliquées) ; les diagrammes de composants (concepts connus de l’exploitant : DLL, JAR, bases de données, etc. ) ; les diagrammes de déploiement (distribution de l’application sur le réseau) ; les diagrammes d’état (cycle de vie commun aux objets d’une même classe, notation reprise des systèmes en temps réel) ; les diagrammes d’activité (flux de données entre objets, associé par exemple à un cas d’utilisation) ; enfin, les diagrammes de collaboration et les diagrammes de séquences sont tous deux des diagrammes d’interaction UML, représentant les échanges entre objets.
Un langage commun à tous les intervenants
Certains des diagrammes sont redondants (par exemple un diagramme de séquences contient toutes les informations d’un diagramme d’activité), certains sont plus utiles en phase d’analyse, d’autres en phase de conception. Le choix du diagramme le plus adapté dépend pour beaucoup de l’application et de la méthode suivie. Tel quel, UML est en effet une sorte de fourre-tout. Il n’y a guère qu’au niveau de la représentation des objets du système, c’est-à-dire à la phase de programmation, que ce langage est réellement sans équivalent. Mais dès les phases de conception, on peut l’utiliser aussi bien pour illustrer des méthodes classiques non objet que des méthodes RAD centrées sur les interfaces. Le résultat, c’est de disposer d’un langage commun pour tous les intervenants d’un projet informatique, l’analyse des besoins, l’exploitation, le développement et les tests fonctionnels.
Cette approche graphique, qui aurait pu se révéler lourde, a profité de l’outil informatique. UML s’applique dans des outils spécifiques (le plus connu est Rational Rose 2000, mais il en existe des dizaines), ou s’intègre à des ateliers logiciels de développement C++, Visual Basic ou Java. En utilisant UML, on peut désormais passer de la conception initiale au code exécutable. Mais attention toutefois, UML ne remplace ni une bonne méthode de conduite de projet, ni une compréhension correcte des concepts objet lors du développement. Une notation normalisée pour les plans ne remplace pas un bon architecte.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
