|
Références
sélectives
sur UML
Sur le Web
:
http://www.uml.org
http://uml.free.fr (cours en français)
Bibliographie :
Grady Booch, Ivar Jacobson, James Rumbaugh, Jim Rumbaugh, The Unified
Modeling Language User Guide, Addison-Wesley 1998
Martin Fowler et Kendall Scott, UML distilled second edition,
Addison-Wesley 1999
Pascal
Roques et Franck Vallée, UML en action, Eyrolles 2003
|
Nous avons décrit le
contenu et les avantages de la programmation objet (voir "De
la programmation fonctionnelle à la technologie objet"). Cette description
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. Si l'on a compris l'analogie entre "classe" et "type de dossier",
"objet" et "dossier individuel rempli" etc., on voit que l'énoncé
des choix ci-dessus n'est rien d'autre que la modélisation, ou "spécification",
du programme.
Pour développer une
application, il ne faut pas 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 fonctionnelle étaient souvent
floues car, les articulations conceptuelles (structures de données,
algorithmes de traitement) s'exprimant dans le vocabulaire propre à
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 plus précise en utilisant un vocabulaire qui, tout en transcrivant les
besoins du métier, pourra être immédiatement
compris par les informaticiens. Nous avons dit "en principe" parce
que la mise en oeuvre des méthodes de modélisation demande aux maîtrises d'ouvrage
une compétence, un professionnalisme qui ne sont pas aujourd'hui répandus.
La "technologie
objet" regroupe deux compétences aussi nécessaires l'une que
l'autre : la "modélisation objet" et la "programmation
objet". La première relève pour l'essentiel de la maîtrise d'ouvrage, la
deuxième de la maîtrise d'œuvre.
Historique des modélisations
objet
Les méthodes utilisées
dans les années 80 pour organiser la programmation fonctionnelle (notamment
Merise) étaient fondées sur une modélisation séparée des données et des
traitements.
Lorsque la programmation
objet prend de l'importance au début des années 90, 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 ;
- OOD de Grady Booch, définie pour le Department of Defense, introduit le
concept de package ;
- 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 intellectuel qui auraient eu 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"). C'est de cet effort de convergence qu'est né UML, "Unified
Modeling Language", l'adjectif
"unified" étant là pour bien marquer qu'UML "unifie" et
donc remplace les méthodes antérieures (voir Cris Kobryn, "UML
2001: A Standardization Odyssey" , Communications of the ACM,
octobre 1999.).
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 (noter le remplacement du
mot "méthode" par le mot "langage"). Les acteurs les plus
importants dans le monde du logiciel s'associent à l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational,
Unisys etc.) et UML 1.0 est soumis à l'OMG ("Object Management
Group", organisme international de normalisation en technologie objet qui
rassemble les principales entreprises concernées, www.omg.org).
L'OMG adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes
d'information objet. La version d'UML en cours à la fin 2002 est UML 2.0 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 objet et
à laquelle se sont rangés tous les grands acteurs du domaine (ils ont
d'ailleurs contribué à son élaboration). Chacun est libre de critiquer UML
(et nous formulerons certaines critiques à la fin de cette fiche), mais il
faut respecter le résultat d'un effort de normalisation dans la modélisation,
domaine si difficile à formaliser.
Contenu d'UML
UML n'est pas un méthode, une description normative des étapes
de la modélisation : les auteurs d'UML ont en effet estimé qu'il n'était
pas opportun de définir une telle méthode en raison de la diversité
des cas particuliers. Ils ont préféré être plus modestes, et définir un langage
graphique permettant de représenter, de communiquer les divers aspects d'un
système d'information (aux graphiques sont bien sûr associés des textes qui
expliquent leur contenu). On dit parfois qu'UML est un métalangage car
il fournit les éléments permettant de construire le modèle qui sera, lui, le langage
de l'entreprise.
Un système d'information
est un être organique car son fonctionnement
articule plusieurs logiques qui doivent jouer simultanément et que l'on
peut représenter par un modèle en couches.
Il est impossible de donner une représentation graphique complète d'un être
organique, de même qu'il est impossible de représenter parfaitement une
statue (à trois dimensions) par des photographies (à deux dimensions). Mais il
est possible de représenter un tel être par des "vues" partielles, analogues
chacune à la photographie d'une statue, dont la juxtaposition donnera une idée utilisable
dans l'action sans risque grave d'erreur de raisonnement.
UML comporte 12 diagrammes
standards représentant autant de "vues" d'un système d'information. Ces
diagrammes se répartissent en trois catégories : quatre représentent la
structure statique de l'application (diagrammes de classe, d'objet, de composant
et de déploiement) ; cinq représentent son comportement dynamique
(diagrammes de cas d'utilisation, de séquence, d'activité, de collaboration et
d'état) ; trois représentent la façon dont on peut organiser et gérer
les modules qui composent le programme (diagrammes de packages, sous-systèmes
et modèles).
Ces diagrammes sont d'une
utilité variable selon les cas et ils ne sont pas tous nécessairement
produits à l'occasion de la modélisation. Les plus utiles pour la maîtrise
d'ouvrage sont les diagramme d'activité, de cas d'utilisation, de classe,
d'objet, de séquence et d'état. Les diagrammes de composants, de déploiement
et de collaboration sont surtout utiles pour la maîtrise d'œuvre à qui ils
permettent formaliser les contraintes techniques de la réalisation et la
solution technique retenue
Diagramme d'activité
Le diagramme d'activité
n'est autre que la transcription dans UML de la représentation du processus
telle qu'elle a été élaborée lors du travail qui a préparé la
modélisation (voir "Approche du SI par les processus")
: il montre l'enchaînement des activités qui concourent au processus.
Diagramme de cas
d'utilisation
Le diagramme de cas
d'utilisation décrit la succession des opérations réalisées par un acteur
(personne qui assure l'exécution d'une activité). C'est le diagramme principal
du modèle UML, celui où s'assure la relation entre l'utilisateur et les objets
que le système met en oeuvre.
Diagramme de classe
Le diagramme de classe
représente l'architecture conceptuelle du système : il décrit les classes que
le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage
conceptuel (héritage, marqué par une flèche terminée par un
triangle) ou une relation organique (agrégation, marquée par une flèche
terminée par un diamant).
Diagramme d'objet
Le diagramme d'objet permet
d'éclairer un diagramme de classe en l'illustrant par des exemples.
Diagramme de séquence
Le diagramme de séquence
représente la succession chronologique des opérations réalisées par un
acteur : saisir une donnée, consulter une donnée, lancer un traitement ; il
indique les objets que l'acteur va manipuler, et les opérations qui font passer
d'un objet à l'autre. On peut représenter les mêmes opérations par
un diagramme de collaboration, graphe dont les nœuds sont des
objets et les arcs (numérotés selon la chronologie) les échanges entre objets
: diagramme de séquence et diagramme de collaboration sont deux vues
différentes, mais logiquement équivalentes (on peut construire l'une à partir
de l'autre), d'une même chronologie.
Diagramme d'état
Le diagramme d'état représente
la façon dont évoluent ("cycle de vie") durant le processus les
objets appartenant à une même classe. La modélisation du cycle de vie est
essentielle pour représenter et mettre en forme la dynamique du système.
Présentation du modèle
La présentation d'un modèle
UML se compose de plusieurs documents en langage courant et d’un document
formalisé : elle ne doit en aucun cas se limiter au seul document formalisé
car celui-ci est pratiquement incompréhensible si on le présente seul. Un
expert en UML sera capable dans certains cas de
reconstituer les intentions initiales en lisant le modèle, mais pas toujours ;
et les experts en UML sont encore rares.
1) présentation stratégique
: elle décrit pourquoi l’entreprise a voulu se doter de l’outil considéré,
les buts qu’elle cherche à atteindre, le calendrier de réalisation prévu
etc.
2) présentation des
processus de travail par lesquels la stratégie entend se réaliser : pour
permettre au lecteur de voir comment l’application va fonctionner en pratique,
elle doit être illustrée par une esquisse des écrans qui seront affichés devant
les utilisateurs de terrain.
3) explication des choix qui
ont guidé la modélisation formelle : il s’agit de synthétiser, sous les
yeux du lecteur, les discussions qui ont présidé à ces choix.
4) modèle formel : c'est le document le plus épais et le plus difficile à
lire. Il est préférable de le présenter sur l'Intranet de l'entreprise : les diagrammes
peuvent être alors équipés de liens hypertextes permettant
l’ouverture de diagrammes plus détaillés ou de commentaires explicatifs. On doit présenter en premier le " diagramme
d’activité " qui montre l’enchaînement des cas d'utilisation au
sein du processus, enchaînement immédiatement compréhensible ;
puis le " diagramme de cas d'utilisation ", qui montre le contenu de
chaque activité ; puis le " diagramme de séquence ", qui
montre l’enchaînement chronologique des opérations à l’intérieur de
chaque cas d'utilisation. Enfin, le diagramme de classes, qui est le plus précis
conceptuellement mais aussi le plus difficile à lire : il montre les
relations entre classes (agrégation, héritage, association etc.).
Élaboration du modèle
Le modèle est réalisé par
étapes successives (modèle métier, modèle d'analyse, modèle technique),
chaque étape enrichissant et précisant les résultats de la précédente (voir
modélisation des processus). Lorsque le modèle
technique est disponible, la réalisation peut être lancée. Un outil comme
Rose de Rational permet de produire automatiquement une partie du code à partir
du modèle, celui-ci fournissant en effet les éléments formels tels que la définition
des classes et de leurs relations.
Une difficulté : la
validation du modèle
Le modèle UML, au moins
dans la première étape de son élaboration (modèle métier), transcrit la stratégie de
l'entreprise en vue de l'action. Il importe que les abstractions qu'il comporte
soient celles qui conviennent au métier, et aussi que le métier s'approprie le
modèle. La validation du modèle métier par les dirigeants du métier (MOAS) est donc une étape
importante de la modélisation ; elle doit permettre d'éviter la
versatilité des spécifications qui est la plaie des projets. Il faut pour cela
pouvoir présenter au dirigeant le modèle UML sous une forme qu'il puisse lire,
et comprendre, ce à quoi la présentation formelle ne se prête pas à
l'exception du diagramme d'activités (voir "Pour
une validation authentique").
L'appropriation collective du modèle par l'entreprise passe
par une représentation audiovisuelle du système d'information : on peut ici
recommander l'outil Sicom de la société Nomia (www.nomia.com)
: il permet de présenter le SI selon une mise en scène qui fera comprendre à
chacun (et en tout premier au comité de direction) tout à la fois le processus
de production et la façon dont le SI l'équipe.
