REMARQUES SUR LE DIAGRAMME DE CLASSES DE UML

Partie C - DIVERS

Bons et mauvais exemples de représentation graphiques de classes:

Tableau des horreurs de la modélisation (Hall of Shame):

Exemple 1 : classe explosée. Les classes apparaissent sous forme de boîtes; les attributs sont des cercles rattachés au boîte. Un des plus mauvais exemple de modélisation objet. Le diagramme devient vite surchargé, et rend la lecture impossible.

Source: Document du cours La Conception par Objet, centre de recherche informatique de Montréal, Michel Barbeau, Université de Sherbrooke, Mai 1992.

Exemple 2:
Voici un autre exemple de modélisation de classes particulièrement mauvais. Tout d'abord, on utilise la couleur pour discriminer entre les diverses sortes de classes, ce qui contrevient au principe 2 (pensons à un daltonien qui essaierait de lire le diagramme). Ensuite, il n'y a pas de direction sur les liens d'héritage (quelle est la superclasse et quelle est la sous-classe?). Un petit point positif par contre: la visibilité package est modélisé, contrairement à UML.

On voit ici un exemple tiré du package java.awt.datatransfer. On voit qu'il y a un lien d'héritage entre Object et Clipboard, mais le diagramme ne nous dit pas si c'est Object qui hérite de Clipboard ou le contraire. Bien sûr un programmeur Java sait bien qu'Object ne peut hériter d'aucune classe, mais le but de la modélisation n'est-il pas de communiquer une information non-ambigue (on ne doit pas prendre pour acquis que le lecteur du diagramme est un expert du domaime).

3-example Java in a Nutshell

Un des plus mauvais exemple de modélisation objet nous vient de Booch, un des trois auteurs de UML. Les classes sont représentés sous forme de nuage! Le seule dessinage (drawing) du lien d'association représente tout un défi de programmation. En effet, il faut tracer une ligne entre (x1,y1) et (y1, y2), ces points étant les points d'intersections entre une ligne imaginaire reliant les centres des nuages au contours du nuage; lorsque la classe est sous forme d'une boîte, on applique la formule du point d'intersection de deux droites, la chose est plus difficile avec un nuage! Formalisme quie semble avoir été fait pour emmerder les programmeurs..

Il faut aussi ajouter que c'est Booch qui a ajouté l'affichage de la visibilté à la modélisation objet (ce concept était absent dans OMT, et aurait du le rester dans UML).

Au fait, pourquoi Booch a-t-il choisi de représenter les classes sous forme de nuages? Au dire de l'auteur, c'est parce que les objets représentent ''un concept floue''. Que l'objet soit un concept floue pour Booch n'étonnera personne; mais pourquoi fallait-il représenter ce concept de façon floue pour tout le monde?

Tableau des honneurs (Hall of Fame)

Pour terminer, examinons un exemple de modélisation particulièrement innovatrice et ingénieuse. Selon ce formalisme, on place toutes les classes à gauche et toutes les interfaces à droite. Comme il n'y a pas d'héritage multiple sur les classes, on peut représenter celles-ci sous la forme d'un exploreur (ou d'un arbre graphique). Ainsi, on peut y lire que MulticastSocket hérite de DatagramSocket, qui hérite lui-même de Object.

Les cercles vides indiquent l'abstraction d'une classe (et suggère qu'une classe abstraite est incomplète), les cercles pleins indiquent la finalité d'une classe (et suggèrent qu'une classe finale est complète). Ces deux concepts, l'abstraction et la finalité, s'opposant, ils ne peuvent être modélisés en même temps (ce qui est ingénieux). Les interfaces étant à droite, les cercles pleins ou vides ne s'appliquent pas à eux. Les points d'intersections indiquent une réalisation (ainsi, InetAddress réalise l'interface Serializable).

Un classifier suivi d'un icône indique que ce classifier n'appartient pas au package courant (package java.net). L'icône indique le package auquel le classifier appartient (une toile pour java.net; une étoile pour java.lang; une disquette pour java.io; un cadenas pour java.security, etc.). Ce formalisme est à la fois très concis et très informatif, il gagnerait à être implanté dans un outil de génie logiciel.