Cet article est le premier d'une série consacrée à UML.

Qu'est ce qu'UML?
Unified Modeling Language, dont le développement a commencé en 1994, est un outil de modélisation objet dérivé de méthodes comme Booch ou OMT (Object Modeling Technique). Il s'agit d'une notation standardisée qui facilite la conception de programmes, ainsi que leur description pour des non-informaticiens. Ce mode de conception repose donc sur les principes de la programmation objet: manipuler des classes d'entités, classes constituées d'attributs (des variables) et de méthodes (des fonctions utilisant les attributs). Les classes définissent un type d'objet, l'objet proprement dit étant une instance de la classe correspondante dont l'état est donné par les valeurs instantanées de ses attributs. Les classes, ou types d'objet, sont en relation les unes avec les autres. Il peut s'agir de simples relations de dépendance (une classe à besoin d'une autre), ou de relations de hiérarchie (l'héritage). Définir une hiérarchie permet en particulier d'envisager certains objets comme l'agrégation de sous-objets. Nous verrons plus loin comment modéliser tout cela grâce à l'UML.
L'UML modélise les objets et leurs liens (en ce sens, les objets et leurs liens étant déjà des réprésentations, on peut parler de méta-modèle) au moyen de vues constituées de diagrammes. On distingue les vues statiques, qui représentent "physiquement" le système à modéliser au moyen de diagrammes d'objets, de classes, de cas d'utilisation, de composants et de déploiement; et les vues dynamiques, qui montrent le fonctionnement du système au moyen de diagrammes de séquence, de collaboration, d'états-transitions et d'activités. Au total, UML manipule donc 9 types de diagrammes. Dans ce premier article, nous allons nous intéresser exclusivement aux diagrammes d'objets et de classes, et leurs associations. De futurs articles se pencheront notamment sur les cas d'utilisation, les diagrammes de composants, de déploiement, et enfin les vues dynamiques.

Diagrammes d'objets et diagrammes de classes
Une classe est représentée comme suit en UML:

La spécification des valeurs initiales et par défaut étant facultative. On peut également définir un attribut dont la valeur se déduit de celles d'autres attributs. On fera alors précéder son nom du symbole /.
Ainsi, considérons l'exemple d'une bibliothèque dont la durée de prêt est de 15 jours, on pourra définir la classe livre comme suit (par défaut, un livre est disponible, et sa date de retour se déduit de sa date d'emprunt, en "rajoutant" 15 jours):

Il aurait été plus rigoureux de rajouter un attribut "identifiant" au cas où le livre existe en plusieurs exemplaires...

Notons qu'attributs et fonctions (ou opérations) peuvent être privés (l'élément n'est visible que par sa propre classe), publics (l'élément est visible par toutes les classes) ou protégé (l'élément est visible par sa propre classe et les sous-classes de celles-ci, à l'exclusion de toute autre). En UML, on utilise les symboles - (pour privé), + (pour public) et # (pour protégé) que l'on fait figurer, suivant le cas, devant le nom de l'attribut.
Notons également que le nom de la classe est généralement souligné.

A partir d'une classe, on peut modéliser, si besoin est, un objet (une instance) comme suit:

Ainsi, dans notre exemple:

Une fois encore, on souligne souvent le nom de l'objet.

Associations de classes
Elles sont représentées par des traits continus entre les rectangles modélisant les classes. Le sens de l'association (qu'il s'agisse d'une relation hiérarchique ou de simple dépendance), si celle-ci est unidirectionnelle, peut être précisé par les symboles > ou < apposés au trait. On peut aussi préciser la nature de l'association (sous forme nominale) et sa "multiplicité": dans notre exemple, un lecteur peut emprunter de zéro à, mettons, 6 livres en même temps, tandis qu'un livre ne peut être emprunté que par un lecteur à la fois. Ainsi (en représentant les classes de manière très simplifiée), on pourra modéliser cette relation comme suit:

lecteur

livre

0...1                                emprunt                                 0...6

Nous laissons de côté, pour le moment, les notions de contrainte et de restriction, ou encore de classe abstraite. Notons toutefois qu'il existe des associations particulières désignant une relation asymétrique entre deux ou plusieurs classes, l'une d'entre elles jouant un rôle prépondérant (l'agrégat). Il s'agit de relations d'agrégation (par exemple: une classe faisant partie d'une autre, une action dans une classe impliquant une action dans une autre classe, etc.). L'agrégation est notée par un petit losange du côté de l'agrégat, à l'extrémité de trait d'association. Ce losange est plein quand l'agrégation désigne une composition (l'agrégat contient une ou plusieurs classes). Notons que la composition est bidirectionnelle, tandis que les autres types d'agrégation sont unidirectionnels (par exemple: une action dans l'agrégat implique une action dans la ou les classes liées par agrégation, et non le contraire).