| |
Pourquoi une profession de foi
Le diagramme UML est la partie visible d'une
modélisation. Pourtant, le diagramme se prend parfois
pour le dieu de cette activité. Cette profession de foi
devrait lui permettre de mieux se comporter, par rapport au
modèle auquel il appartient et aussi par rapport aux
lecteurs qui prennent la peine de s'attarder sur sa - parfois
bien piètre - figure.
La profession de foi du diagramme UML
- A ton modèle tu seras
rattaché
Le modèle, ie la représentation d'un
système selon un certain point de vue est
l'unité de base de l'UML. Un diagramme doit donc
être conçu dans le cadre de ce modèle. De
façon générale, tous les concepts et donc
tous les diagrammes UML peuvent trouver leur place dans tous les
modèles.
- Modèles de systèmes
à forte composante logicielle :
- Modèle selon le Domaine, le Métier
- Modèle selon les Besoins
- Modèle selon l'Analyse
- Modèle selon l'Architecture
- Modèle selon la Conception
- Modèle selon l'Implémentation
- Modèle selon les Tests
- ...
Un modèle est une représentation du
système selon un certain point de vue (les exemples
ci-dessus montrent les points de vue : expression de besoins,
analyse...). Il est, dans UML, constitué - directement -
d'un seul paquetage qui représente le
système lui-même. Ce package est à son tour
constitué :
— d'éléments de
modélisation,
— de paquetages (qui sont donc des sous-paquetages du
"système")
— et de diagrammes reliés à l'un ou
l'autre des paquetages.
Il convient de ne pas confondre tous ces constituants du
modèle.
- A ton lecteur tu penseras,
"Lisibilité" tu chériras
Quel pied de nez à UML... Un outil de communication qui
génère tant de diagrammes illisibles. Ce principe
général d'empathie envers le lecteur est une
condition sine qua non à la lisibilité du
diagramme.
Dans cet ordre d'idée, doter le diagramme d'une
note "guide de lecture" est une solution pertinente. De
même, un diagramme devrait systématiquement
comporter son titre (qui souvent est simplement dans le
navigateur de l'outil). Une activité
régulière dans le projet devrait être :
quid des éléments qui, dans notre contexte, rendent
nos diagrammes plus lisibles ?
- Un seul objectif tu poursuivras
Un seul objectif par diagramme, c'est plus de
lisibilité.
- Parmi ces objectifs :
- général ou détaillé
- uniquement un type d'éléments (par ex
classes persistantes)
- une unité logique (les classes d'un serveur)
- ... et tout discriminant jugé pertinent.
Quelques exemples de styles de diagrammes dans un modèle.
| |
Inter-paquetage |
Intra-paquetage |
| Général |
Les classes participant à une
fonctionnalité |
Toutes les classes et leurs relations (sans les
détails : attributs...) |
| Détaillé |
Une collaboration entre objets |
Quelques classes avec leurs détails |
- Point trop de choses tu ne montreras
Une bonne dizaine d'éléments principaux
constitue déjà une excellente moyenne. On distingue
dans un diagramme (comme dans les concepts) le
général du détaillé. Les classes et
associations (ou états et transitions) sont
"générales". Les attributs et
opérations (ou actions et activités) sont les
détails.
- Les éléments de modélisation tu
partageras
Une classe, un état... peuvent très bien être
visualisés par plusieurs diagrammes, selon l'objectif
poursuivi. D'où la nécessité de
comprendre ce qu'est un modèle au sens UML : un
élément de modélisation n'est pas
réduit à sa représentation graphique dans un
diagramme.
- Les Copier/Coller approximatifs tu
éviteras
Bien entendu, il est pratique de copier/coller depuis le modeleur
UML vers le traitement de texte. Malheureusement, cette
opération se traduit parfois par un diagramme
résultant parfaitement illisible dans le texte. Le
traitement de texte tente quelquefois de modifier la taille et
les paramètres du diagramme pour satisfaire les besoins de
la mise en page. Cela donne... une grande perte de temps ou
encore des problèmes visuels pour le lecteur un peu trop
consciencieux. Un point important est donc de
vérifier systématiquement le résultat
final dans le document et d'imaginer que l'on
découvre ce diagramme pour la première fois.
- À un ou plusieurs diagrammes de "sexe
opposé" tu t'associeras
Un diagramme ne montre qu'une face du système. Une
modélisation objet | |
