Clés d’accès à UML

UML et la maîtrise d’ouvrage
A priori, UML n’est destiné pas à la maîtrise d’ouvrage. Plusieurs raisons conduisent toutefois à préconiser son utilisation pour définir un système d’information et élaborer le cahier des charges correspondant.
La première est sa normalisation par l’OMG. L’histoire des méthodes a montré que la profusion des notations est préjudiciable aux entreprises clientes comme à leurs fournisseurs. Toute norme doit donc être considérée avec le plus grand sérieux.
La seconde raison est l’intérêt montré par les informaticiens pour ce langage de modélisation. Même si l’utilisation qu’ils en font est tournée vers la description de composants logiciels, il est intéressant, pour faciliter le dialogue entre maître d’ouvrage et maître d’œuvre, de disposer de modèles communs.
La troisième raison est la possibilité d’utiliser le même atelier de génie logiciel, depuis l’expression des besoins jusqu’à la génération de tout ou partie du code.
La dernière raison, mais non la moindre, est de s’appuyer sur des principes et concepts objets pour enrichir la démarche d’analyse du système d’information. On en attend des améliorations quant à la richesse, la modularité, la cohérence et la rigueur du système ainsi spécifié.

Que trouve-t-on dans UML ?
UML est un ensemble de modèles. L’emploi du terme «langage» signifie que l’accord a porté sur les modèles, ainsi que sur leur représentation sous forme de diagrammes. Cependant, UML ne propose ni mode d’utilisation de ces modèles, ni démarche.
Les concepts de base sont très larges.
Un objet est un élément matériel ou immatériel dans la réalité étudiée. Ce peut être aussi bien un acteur, un composant logiciel, un élément matériel, un élément informationnel ou la réalisation d’un processus.
Une classe est une abstraction d’un ensemble d’objets sur lesquels on peut reconnaître des similitudes dans le champ de l’étude. Ces similitudes portent sur la façon de les identifier, les types d’états qu’ils peuvent prendre et le rôle qu’ils jouent.
UML comprend sept diagrammes qui peuvent présenter un intérêt pour la maîtrise d’ouvrage.
• Le diagramme d’objets permet de représenter un ensemble d’objets et de mettre en
évidence des liens entre ces objets.
• Le diagramme de classes permet de modéliser un ensemble de classes, de même nature ou de natures différentes, qui sont en relation d’une façon ou d’une autre.
• Le diagramme d’états-transitions est associé à une classe : il permet de représenter tous les
états possibles d’un objet de la classe, ainsi que les événements provoquant un changement d’état.
• Le diagramme d’activités permet de décrire les traitements en schématisant leur déroulement. Il peut comporter des synchronisations pour représenter les déroulements parallèles. Avec la notion de couloir d’activité, on peut décrire la répartition des responsabilités entre acteurs opérationnels.
• Le diagramme de collaboration permet de mettre en évidence les interactions entre différents objets du système étudié, ainsi que les messages qu’ils s’échangent.
• Le diagramme de séquence permet de visualiser une séquence de messages entre des objets qui collaborent.
• Les cas d’utilisation sont une technique de description du système étudié privilégiant le point de vue de l’utilisateur. Un cas d’utilisation est une façon spécifique d’utiliser le système.
Devant cet ensemble de modèles, que doit faire l’analyste chargé d’exprimer les besoins sous la forme d’un cahier des charges précis ? Faut-il utiliser tous les diagrammes ? Dans quel ordre ? Pour représenter quels objets et quelles classes ? Autant de questions qu’il est légitime de se poser.
UML n’apportant pas de réponse, le maître d’ouvrage ne peut pas pour autant se transformer en méthodologue chevronné ! Pour pouvoir utiliser UML efficacement, il doit donc disposer de principes qui guident sa pensée et d’une démarche qui oriente son travail.

Des principes de base
Tout est classe, oui mais… il n’est pas utile d’avoir de la réalité une vision indifférenciée. Au contraire, des typologies qui ordonnent le réel perçu peuvent s’avérer des plus profitables. Ainsi, nous proposons de distinguer dans l’ensemble des classes trois sous-ensembles disjoints :
• Entité
Les classes entités permettent de modéliser toutes les informations que l’on veut gérer.
• Processus
Les classes processus permettent de répertorier les réponses organisées pour accomplir les missions.
• Acteur
Les classes acteurs représentent les rôles attribués.

Les entités
Une entité est un concept global d’information, qui peut être décrit par une structure regroupant les types d’informations élémentaires nécessaires à sa gestion.
De plus, il est utile de distinguer trois sortes d’entité, selon le rôle joué dans un système d’information. Cette distinction apporte une aide à l’analyste et peut économiser des efforts de modélisation inutiles. La typologie est la suivante (Fig. 2) :
• Une entité de gestion est une entité pour laquelle on a choisi de gérer une transformation. Elle passera donc par des états de gestion successifs.
• Une entité de référence est le support d’informations stables, sur lesquelles on s’appuie pour effectuer les activités opérationnelles.
• Une entité de reporting porte des informations, souvent calculées ou agrégées, qui apportent une aide pour le pilotage des activités à court ou moyen terme.