Composants de base d'un diagramme de classes
Selon le contexte, les classes d'un diagramme de classes peuvent représenter les objets principaux, les interactions dans l'application ou les classes à programmer. Pour répondre à la question "Qu'est-ce qu'un diagramme de classes en UML ?", vous devez d'abord comprendre sa composition de base.
- Classes : un modèle pour créer des objets et implémenter un comportement dans un système. En UML, une classe représente un objet ou un ensemble d'objets qui partagent une structure et un comportement communs. Elles sont représentées par un rectangle qui comprend les lignes du nom de la classe, de ses attributs et de ses opérations. Lorsque vous dessinez une classe dans un diagramme de classes, vous n'êtes tenu de remplir que la ligne supérieure, les autres étant facultatives si vous souhaitez fournir plus de détails.
- Signaux : symboles qui représentent des communications asynchrones unidirectionnelles entre des objets actifs.
- Types de données : classificateurs qui définissent des valeurs de données. Les types de données peuvent modéliser à la fois des types primitifs et des énumérations.
- Packages : formes conçues pour organiser les classificateurs associés dans un diagramme. Ils sont symbolisés par une grande forme de rectangle à onglet.
- Interfaces : ensemble de signatures d'opérations et/ou de définitions d'attributs qui définissent un ensemble cohérent de comportements. Les interfaces sont similaires aux classes, à ceci près qu'une classe peut avoir une instance de son type, et qu'une interface doit avoir au moins une classe pour l'implémenter.
- Énumérations : représentations de types de données définis par l'utilisateur. Une énumération comprend des groupes d'identifiants qui représentent les valeurs de l'énumération.
- Objets : instances d'une ou plusieurs classes. Des objets peuvent être ajoutés à un diagramme de classes pour représenter des instances concrètes ou prototypes.
- Artéfacts : éléments de modèle qui représentent les entités concrètes dans un système logiciel, telles que des documents, des bases de données, des fichiers exécutables, des composants logiciels, etc.
Sections au sein d'une classe
La classe standard est composée de trois sections :
Section supérieure
Contient le nom de la classe. Cette section est toujours requise, que vous parliez du classificateur ou d'un objet. Le nom de la classe doit :
- Commencer par une majuscule.
- Être formaté en gras.
- Être centré dans la section supérieure.
- Être descriptif.
Section centrale
Contient les attributs de la classe. Utilisez cette section pour décrire les qualités de la classe. Cela n'est nécessaire que lors de la description d'une instance spécifique d'une classe.
Section inférieure
Comprend les opérations de classe (méthodes). Affichée sous forme de liste, chaque opération occupe sa propre ligne. Les opérations décrivent la manière dont une classe interagit avec les données. Le texte des deux sections inférieures est généralement aligné à gauche et commence par une lettre minuscule.
Modificateurs d'accès aux membres
Toutes les classes ont des niveaux d'accès différents selon le modificateur d'accès (visibilité). Voici les niveaux d'accès avec leurs symboles correspondants :
- Public (+)
- Privé (-)
- Protégé (#)
- Package (~)
- Dérivé (/)
- Statique (souligné)
Portées des membres
Il existe deux portées pour les membres : les classificateurs et les instances.
Les classificateurs sont souvent reconnus comme statiques, ce qui signifie que les valeurs des attributs restent les mêmes dans toutes les instances et que l'appel d'une méthode n'affecte pas l'état de l'instance. En comparaison, les instances contiennent des méthodes qui peuvent modifier l'état de l'instance et des valeurs d'attributs qui peuvent varier d'une instance à l'autre. Pour indiquer un classificateur, il suffit de souligner son nom ; laissez le texte tel quel pour indiquer une instance.
Interactions
Le terme "interactions" fait référence aux différentes relations et liens qui peuvent exister dans les diagrammes de classes et d'objets. Parmi les interactions les plus courantes, on peut citer :
Héritage : processus par lequel une classe enfant ou une sous-classe reprend les fonctionnalités d'une classe parent ou d'une super-classe, également appelé généralisation. Il est symbolisé par une ligne droite reliée par une flèche fermée pointant vers la super-classe.

Dans cet exemple, l'objet "Car" hériterait de tous les attributs (vitesse, nombre de passagers, carburant) et méthodes (go(), stop(), changeDirection()) de la classe parent ("Vehicle") en plus des attributs spécifiques (type de modèle, nombre de portes, constructeur automobile) et méthodes de sa propre classe (Radio(), windshieldWiper(), ac/heat()). L'héritage est représenté dans un diagramme de classes par une ligne pleine avec une flèche fermée et vide.
Association bidirectionnelle : la relation par défaut entre deux classes. Les deux classes ont connaissance l'une de l'autre et de leur relation mutuelle. Cette association est représentée par une ligne droite entre deux classes.

Dans l'exemple ci-dessus, la classe Car et la classe RoadTrip sont interdépendantes. À l'une des extrémités de la ligne, Car prend l'association de "assignedCar" avec la valeur de multiplicité de 0..1, de sorte que lorsque l'instance de RoadTrip exists, elle peut avoir soit une instance de Car qui lui est associée, soit aucune voiture. Dans ce cas, une classe Caravan distincte avec une valeur de multiplicité de 0..* est nécessaire pour démontrer qu'un RoadTrip pourrait avoir plusieurs instances de Cars associées. Étant donné qu'une instance de Car pourrait avoir plusieurs associations "getRoadTrip" — en d'autres termes, une voiture pourrait faire plusieurs voyages — la valeur de multiplicité est définie sur 0..*
Association unidirectionnelle : une relation un peu moins fréquente entre deux classes. Une classe a connaissance de l'autre et interagit avec elle. L'association unidirectionnelle est modélisée par une ligne de connexion droite qui pointe une flèche ouverte de la classe qui connaît vers la classe connue.

Par exemple, lors de votre voyage en Arizona, vous risquez de tomber sur un radar automatique qui enregistre votre activité de conduite, mais vous ne le saurez pas avant de recevoir une notification par courrier. Cela n'est pas représenté sur l'image, mais dans ce cas, la valeur de multiplicité serait de 0..* selon le nombre de fois où vous passez devant le radar.