Les diagrammes de classes sont les diagrammes les plus utilisés en UML: Il modélisent les notions d’un domaine, ou supportées par un système, avec leurs dépendances et leurs propriétés.
Dans une perspective “haut niveau” (conceptuelle), les classes représentent les concepts supportés par un système cependant que dans une perspective “bas niveau” (physique) elles représentent souvent les classes implémentées par un langage objet. La Figure représente une vue conceptuelle de société humaine. C’est un usage classique des diagrammes de classe. Nous voyons ici des classes, des liens d’héritage (généralisation) des associations et une opération. Par ailleurs, on voit des contraintes associées à des éléments de modèle.

Cet exemple plus complet représente le modèle conceptuel d’une agence de voyage. Nous recommandons que les attributs soient typés par des classes primitives (une classe peut être déclarée “primitive”) ou des types de données (data type). Types de données et énumérations sont représentés sur ce diagramme également. Les propriétés typées par des classes complexes doivent être modélisées via des associations.

Cette Figure présente un diagramme de classe plus orienté sur les aspects “conception”. Il pourrait produire un code Java équivalent par exemple. On voit les notions d’interface, d’opération avec signature, d’exceptions émises.

On présente ici des composants avec ses ports et parts, des interfaces requis et fournis. A partir de ces spécification au niveau du “typage”, on peut faire des modèles détaillés présentant l’assemblage d’instances (parts) dans le contexte d’une classe “container”.

Ce modèle spécifie que pour construire une session Vidéo, nous devons connecter (assembler) un PC à un projecteur vidéo via un port VGA, et les connecter par un “connecteur”. Cette construction s’appelle la structure interne d’une classe.

Ce diagramme représente une architecture SOA utilisant des composants de service qui sont assemblés via les services. Le profile Objecteering EA est utilisé ici pour étendre UML pour la SOA. L’emploi des structure internes de classes, de l’assemblage des composants et de la modélisation des composants s’accroitra énormément avec l’avènement des développement de SI sous architectures SOA.

La Figure représente quelques cas complexes avec associations N-aire, qualifiers sur associations. Cela ajoute une précision utile aux associations pour des modèles plus précis.

Dans cet exemple de diagramme de package, on voit qu’un package peut être développé pour présenter son contenu, qui sera probablement des classes mais aussi une grande variété d’éléments comme des processus (activités) des acteurs, des packages, des interactions, etc.

En UML2, une classe peut avoir beaucoup de types de propriétés. Dans l’exemple Figure 8, nous voyons qu’il y a une zône dédiée aux attributs dans une classe, une zône dédiée aux opérations, une dédiée aux parts, et une zone dédiée aux éléments imbriqués comme des classes, acteurs, activités, interactions, etc.