UML 2.

0
INTRODUCTION
L’approche objet est incontournable dans le cadre du développement de systèmes logiciels complexes, capables
de suivre les évolutions incessantes des technologies et des besoins applicatifs. Cependant, la programmation
objet est moins intuitive que la programmation fonctionnelle. En effet, il est plus naturel de décomposer les
problèmes informatiques en termes de fonctions qu’en termes d’ensembles d’objets en interaction. De ce fait,
l’approche objet requiert de modéliser avant de concevoir. La modélisation apporte une grande rigueur, offre une
meilleure compréhension des logiciels, et facilite la comparaison des solutions de conception avant leur
développement. Cette démarche se fonde sur des langages de modélisation, qui permettent de s’affranchir des
contraintes des langages d’implémentation.

Le besoin d’une méthode de description et de développement de systèmes, prenant en compte à la fois les
données et les traitements, a grandi en même temps que la taille des applications objet. Au milieu des années 90,
plusieurs dizaines de méthodes objet sont disponibles, mais aucune ne prédomine. L’unification et la
normalisation des trois méthodes dominantes, à savoir Booch, du nom de son auteur, OOSE (Object Oriented
Software Engineering), d’Ivan Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont à
l’origine de la création du langage UML (Unified Modeling Language).

UML est une notation graphique conçue pour représenter, spécifier, construire et documenter les systèmes
logiciels. Ses deux principaux objectifs sont la modélisation de systèmes utilisant les techniques orientées objet,
depuis la conception jusqu’à la maintenance, et la création d’un langage abstrait compréhensible par l’homme et
interprétable par les machines.

UML s’adresse à toutes les personnes chargées de la production, du déploiement et du suivi de logiciels
(analystes, développeurs, chefs de projets, architectes…), mais peut également servir à la communication avec
les clients et les utilisateurs du logiciel. Il s’adapte à tous les domaines d’application et à tous les supports. Il
permet de construire plusieurs modèles d’un système, chacun mettant en valeur des aspects différents :
fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable dans les
projets de développement.

Une méthode de développement définit à la fois un langage de modélisation et la marche à suivre lors de la
conception. Le langage UML propose uniquement une notation dont l’interprétation est définie par un standard,
mais pas une méthodologie complète. Plusieurs processus de développement complets fondés sur UML existent,
comme le Rational Unified Process (RUP), de Booch, Jacobson et Rumbaugh, ou l’approche MDA (Model
Driven Architecture) proposée par l’OMG, mais ils ne font pas partie du standard UML.

UML intègre de nombreux concepts permettant la génération de programmes. C’est un langage de modélisation
fondé sur des événements ou des messages. Il ne convient pas pour la modélisation de processus continus,
comme la plupart des procédés en physique. Même si la version 2 apporte des avancées significatives au niveau
du formalisme, UML n’a pas encore atteint la rigueur syntaxique et sémantique des langages de programmation.
UML est le résultat d’un large consensus, continuellement enrichi par les avancées en matière de modélisation de
systèmes et de développement de logiciels. C’est le résultat d’un travail d’experts reconnus, issus du terrain. Il
couvre toutes les phases du cycle de vie de développement d’un système et se veut indépendant des langages
d’implémentation et des domaines d’application.
Historique du langage UML
À la fin des années 80, l’industrie commence à utiliser massivement les langages de programmation orientés
objet, tels que C++, Objective C, Eiffel et Smalltalk. De l’industrialisation de ce type de programmation est né le
besoin de « penser objet », indépendamment du langage d’implémentation. Plusieurs équipes proposent alors des
méthodes (OMT, OOSE, Booch, Coad, Odell, CASE…) qui, pour la plupart, modélisent les mêmes concepts
fondamentaux dans différents langages, avec une terminologie, des notations et des définitions différentes.

Les différents protagonistes conviennent rapidement du besoin d’unifier ces langages en un standard unique.
Lors de la conférence OOPSLA d’octobre 1995, Booch et Rumbaugh présentent la version 0.8 de leur méthode
unifiée (Unified Method 0.8). Ils sont rejoints la même année par Jacobson. Les trois auteurs améliorent la
méthode unifiée et proposent en 1996 la version 0.9 du langage UML. Rational Software, qui emploie désormais
le trio, publie en 1997 la documentation de la version 1.0 d’UML et la propose à l’OMG en vue d’une
standardisation. Des modifications sont apportées à la version proposée par Rational, puis l’OMG propose, la
même année, la version UML 1.1, qui devient un standard.

L’OMG constitue ensuite un groupe de révision nommé RTF (Revision Task Force). Entretemps, de très
nombreux utilisateurs industriels adoptent UML et apportent quelques modifications, ce qui conduit à la
proposition de la version 1.2 en 1999. La première révision significative du langage est la version 1.3, proposée
en 1999, dont la spécification complète est publiée en mars 2000. En mars 2003, la version 1.5 voit le jour.

Concrètement, UML 1 est utilisé lors de la phase d’analyse et de conception préliminaire des systèmes. Il sert à
spécifier les fonctionnalités attendues du système (diagrammes de cas d’utilisation et de séquence) et à décrire
l’architecture (diagramme de classes). La description de la partie comportementale (diagrammes d’activités et
d’états) est moins utilisée.
Cela est dû essentiellement à l’insuffisance de la formalisation de la conception détaillée dans UML 1. La plupart
du temps, en matière de spécification des algorithmes et des méthodes de traitement, le seul moyen est de donner
une description textuelle informelle.

Certes, des outils comme les automates et les diagrammes d’activités sont disponibles, mais leur emploi est
limité. Les utilisateurs restent sur le vieux paradigme centré sur le code : ils se contentent de recourir à UML lors
des phases préliminaires et passent à un langage de programmation classique lors des phases de codage et de
tests. L’un des objectifs de l’OMG est de proposer un paradigme guidé par des modèles décrivant à la fois le
codage, la gestion de la qualité, les tests et vérifications, et la production de la documentation. Il s’agit de
recentrer l’activité des informaticiens sur les fonctions que le système doit fournir, en conformité avec les
exigences du client et les standards en vigueur.

UML 2
UML 2 apporte des évolutions majeures par rapport à UML 1.5, sans toutefois être révolutionnaire : les
principales fonctionnalités de base se ressemblent. Au niveau du métamodèle, qui concerne surtout les
développements d’outils, UML 2 se rapproche davantage des standards de modélisation objet proposés par
l’OMG.

En particulier, l’unification du noyau UML et des parties conceptuelles de modélisation MOF (Meta-Object
Facility) permet aux outils MOF de gérer les modèles UML ; l’ajout du principe de profils permet de mieux
définir les extensions du domaine ; enfin, la réorganisation du métamodèle UML élimine les redondances
présentes dans les versions précédentes (voir la fin de l’ouvrage pour plus de détails concernant la structuration
du langage UML).

Du point de vue de l’utilisateur, les changements concernent certaines notations. La notation des diagrammes de
séquence se rapproche de la norme d’échanges de messages MSC
(Message Sequence Chart) de l’IUT (Union Internationale des Télécommunications). Le concept de classeurs
s’inspire des avancées de l’ingénierie temps réel du langage de description et de spécification SDL.
De plus, UML 2 unifie la modélisation des activités et la modélisation des actions introduites dans UML 1.5 et
utilise des notations de modélisation de processus métier. Des éléments de modélisation contextuels améliorent la
souplesse et formalisent mieux le concept d’encapsulation des classes et des collaborations. Afin de formaliser le
modèle utilisateur du langage et de le rapprocher davantage des normes OMG, le langage UML est structuré en
quatre couches (figure 0.1) ; seules les deux couches user model et run time instance sont destinées à l’utilisateur.

Pourquoi modéliser ?
Un modèle est une représentation simplifiée d’une réalité. Il permet de capturer des aspects pertinents pour
répondre à un objectif défini a priori. Par exemple, un astronaute modélisera la Lune comme un corps céleste
ayant une certaine masse et se trouvant à une certaine distance de la Terre, alors qu’un poète la modélisera
comme une dame avec laquelle il peut avoir une conversation.
Le modèle s’exprime sous une forme simple et pratique pour le travail [Rumbaugh2004]. Quand le
modèle devient compliqué, il est souhaitable de le décomposer en plusieurs modèles simples et
manipulables.
L’expression d’un modèle se fait dans un langage compatible avec le système modélisé et les objectifs
attendus. Ainsi, le physicien qui modélise la lune utilisera les mathématiques comme langage de
modélisation.

Dans le cas du logiciel, l’un des langages utilisés pour la modélisation est le langage UML. Il possède
une sémantique propre et une syntaxe composée de graphique et de texte et peut prendre plusieurs
formes (diagrammes).
Les modèles ont différents usages :
Ils servent à circonscrire des systèmes complexes pour les dominer. Par exemple, il est inimaginable de
construire une fusée sans passer par une modélisation permettant de tester les réacteurs, les procédures
de sécurité, l’étanchéité de l’ensemble, etc.
Ils optimisent l’organisation des systèmes. La modélisation da la structure d’une entreprise en divisions,
départements, services, etc. permet d’avoir une vision simplifiée du système et par là même d’en assurer
une meilleure gestion
Ils permettent de se focaliser sur des aspects spécifiques d’un système sans s’embarrasser des données
non pertinentes. Si l’on s’intéresse à la structure d’un système afin de factoriser ses composants, il est
inutile de s’encombrer de ses aspects dynamiques.
En utilisant, par exemple, le langage UML, on s’intéressera à la description statique (via le diagramme
de classes) sans se soucier des autres vues. Ils permettent de décrire avec précision et complétude les
besoins sans forcément connaître les détails du système.

Ils facilitent la conception d’un système, avec notamment la réalisation de maquette

Ils permettent de tester une multitude de solutions à moindre coût et dans des délais
réduits et de sélectionner celle qui résout les problèmes posés.
La modélisation objet produit des modèles discrets permettant de regrouper un ensemble de
configurations possibles du système et pouvant être implémentés dans un langage de
programmation objet. La modélisation objet présente de nombreux avantages à travers un
ensemble de propriétés (classe, encapsulation, héritage et abstraction, paquetage, modularité,
extensibilité, adaptabilité, réutilisation) qui lui confère toute sa puissance et son intérêt.