1.4 UML langage de modélisation OO
La description de la programmation par objets a fait ressortir
l'étendue du travail conceptuel nécessaire : définition
des classes, de leurs relations, des attributs et méthodes, des
interfaces etc.
Pour programmer une application, il ne convient pas de se
lancer tête baissée dans l'écriture du code: il faut
d'abord organiser ses idées, les documenter, puis organiser la
réalisation en définissant les modules et étapes de la
réalisation. C'est cette démarche antérieure à
l'écriture que l'on appelle modélisation ; son produit est un
modèle.
Les spécifications fournies par la maîtrise
d'ouvrage en programmation impérative étaient souvent floues :
les articulations conceptuelles (structures de données, algorithmes de
traitement) s'exprimant dans le vocabulaire de l'informatique, le modèle
devait souvent être élaboré par Celle-ci. L'approche objet
permet en principe à la maîtrise d'ouvrage de s'exprimer de
façon précise selon un vocabulaire qui, tout en transcrivant les
besoins du métier, pourra être immédiatement compris par
les informaticiens. En principe seulement, car la modélisation demande
aux maîtrises d'ouvrage une compétence et un professionnalisme qui
ne sont pas aujourd'hui répandus [Pascal 2006].
1.4.1 Historique
Les méthodes utilisées dans les années
1980 pour organiser la programmation impérative (notamment Merise)
étaient fondées sur la modélisation séparée
des données et des traitements. Lorsque la programmation par objets
prend de l'importance au début des années 1990, la
nécessité d'une méthode qui lui soit adaptée
devient évidente. Plus de cinquante méthodes apparaissent entre
1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE,
etc.) mais aucune ne parvient à s'imposer. En 1994, le consensus se fait
autour de trois méthodes :
- OMT de James Rumbaugh (General Electric) fournit une
représentation graphique des aspects statique, dynamique et fonctionnel
d'un système ;
- OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la
description des
besoins des utilisateurs (cas d'utilisation, ou use cases).
Chaque méthode avait ses avantages et ses partisans. Le
nombre de méthodes en compétition s'était réduit,
mais le risque d'un éclatement subsistait : la profession pouvait se
diviser entre ces trois méthodes, créant autant de continents
intellectuels qui auraient du mal à communiquer.
Événement considérable et presque
miraculeux, les trois gourous qui régnaient chacun sur l'une des trois
méthodes se mirent d'accord pour définir une méthode
commune qui fédérerait leurs apports respectifs (on les surnomme
depuis « the Amigos »). UML (Unified Modeling Language) est né
de cet effort de convergence. L'adjectif unified est là pour marquer
qu'UML unifie, et donc remplace.
En fait, et comme son nom l'indique, UML n'a pas l'ambition
d'être exactement une méthode : c'est un langage. L'unification a
progressé par étapes. En 1995, Booch et Rumbaugh (et quelques
autres) se sont mis d'accord pour construire une méthode unifiée,
Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9
(notez le remplacement du mot méthode par le mot langage, plus modeste).
Les acteurs les plus importants dans le monde du logiciel s'associent alors
à l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et
UML 1.0 est soumis à l'OMG. L'OMG adopte en novembre 1997 UML 1.1 comme
langage de modélisation des systèmes d'information à
objets. La version d'UML en cours en 2008 est UML 2.1.1 et les travaux
d'amélioration se poursuivent.
UML est donc non seulement un outil intéressant mais
une norme qui s'impose en technologie à objets et à laquelle se
sont rangés tous les grands acteurs du domaine, acteurs qui ont
d'ailleurs contribué à son élaboration.
| 
