Le diagramme de classes

Auteur: Jérôme Forget. Publié le 11 septembre 2006.

Le diagramme de classe est un élément important dans une démarche de conception orientée objet. Il représente les différentes entités (les classes d'objet) intervenant dans le système.

En identifiant les concepts importants de l'application, nous avons réalisé un premier diagramme de classes pour représenter ces concepts et leurs associations.

Réalisons maintenant le diagramme de classes final qui servira de base au codage de l'application. La grande partie du travail a déjà été fait sur le modèle conceptuel.

Identifier les classes d'analyse

Pour améliorer le modèle conceptuel, nous devons identifier les classes d'analyse qui vont participer à la réalisation de chaque cas d'utilisation. Ces classes seront de trois types :

• Les entités représentent les informations persistantes de l'application, comme celles stockées dans une base de données. Les entités vont seulement posséder des attributs. Elles proviennent directement du modèle conceptuel.
• Les dialogues vont représenter l'interface utilisateur, les écrans proposés à l'utilisateur pour qu'il interagisse avec l'application. Les dialogues vont posséder des attributs et des opérations. Ils sont issues de la maquette.
• Les contrôles correspondent à la logique interne de l'application. Ils font la transition entre les dialogues et les données. Les contrôles vont seulement posséder des opérations.

On ajoutera aussi des associations entre les classes d'analyse, mais avec des règles strictes :

• Les dialogues ne peuvent être reliés qu'à des contrôles ou d'autres dialogues. En général, les associations sont unidirectionnelles, de dialogue vers contrôle.
• Les entités ne peuvent être reliées qu'aux contrôles ou à d'autres entitées. Toujours unidirectionnelles et dans le sens de contrôle vers entité.
• Les contrôles ont accès à tout type de classe, y compris d'autres contrôles.

Les acteurs peuvent aussi être rajoutés à ces diagrammes, un acteur ne pouvant être relié qu'à un dialogue.

Ajouter les opérations

L'attribution des bonnes responsabilités aux bonnes classes est l'un des problèmes les plus délicats de la conception orientée objet. Il convient alors de faire appel à son jugement et de se fier à quelques règles de base.

En consultant la description textuelle d'un cas d'utilisation et le diagramme de séquences, nous pouvons déjà identifier les principaux messages circulant entre l'utilisateur et le système.

Généralement, on dira qu'un message entre deux objets constitue une opération sur la classe de l'objet récepteur. Ainsi, si un objet A envoie un message op à un objet B, op() sera une opération de la classe B.

Le diagramme de classes de Chercher des documents

Notes sur le diagramme de classes

L'Internaute veut trouver le plus rapidement possible un document précis dans l'ensemble du catalogue. Il veut également pouvoir consulter la fiche détaillée d'un document particulier avant de le réserver.

Nous supposons que la maquette nous a montré trois écrans principaux :

• les écrans de recherche simple et intermédiaire 
• le résultat de recherche, sur une ou plusieurs pages, qui permet d'accéder à la fiche détaillée d'un ouvrage particulier.

Les comportements correspondant à ces fonctionnalités ont été séparés en deux classes contrôles afin de distinguer ce qui relève de la recherche au niveau global du catalogue et ce qui concerne l'obtention d'informations détaillées sur un ouvrage particulier.

Le dialogue RésultatsRecherche est relié à la classe contrôle CtrLivre, car l'opération afficherDetailLivre va invoquer l'opération getInfosLivre du contrôle.

L'action réserverDocument de la classe RésultatsRecherche permet d'accéder au cas d'utilisation Réserver un document.

• Modélisation d'applications Web avec UML