Pour poster un commentaire

28 décembre 2002

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. 

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. 

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 [1].

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. 

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.   

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).  

Le diagramme d'objet permet d'éclairer un diagramme de classe en l'illustrant par des exemples. 

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. 

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. 

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.).

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. 

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.

Pour lire un peu plus :
- De l'Informatique
- De la programmation fonctionnelle à la technologie objet
- Approche du SI par les processus
- Modélisation des processus
- Pour une validation authentique