• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 03/09/2019

Décrivez votre domaine fonctionnel grâce au diagramme de classes UML

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Jusque-là, nous parlions de classes unitaires, mais un domaine c'est souvent un ensemble de classes liées entre elles. Dans ce chapitre, nous allons aborder plus en détail la façon de relier les classes pour former un tout. Nous verrons comment représenter ceci en UML et comment cela se traduit en termes de base de données relationnelle.

Lors de la modélisation d'un domaine fonctionnel, vous devez tout d'abord comprendre quels sont les différentes entités en jeu (-> les classes) et comment celles-ci forment un système cohérent.

Pour ce faire, dans le cadre d'un système de vente en ligne, vous pouvez poser des questions comme :

  • Qu'est-ce qui est vendu ?

  • Les articles sont-ils classables en plusieurs catégories ?

  • Dois-je prendre en compte le stock des articles ?

  • Un client peut-il avoir des bons d'achat sur son compte ?...

Tout ce questionnement va vous permettre de faire une idée générale du domaine fonctionnel en identifiant les différentes parties qui le composent et les liens qui existe entrent elles (un Article est dans une Categorie, un Client peut détenir des BonAchat...).

Décrivez les relations

Une base de données relationnelle s'appuie sur un modèle relationnel et donc il s'agit d'un système possédant des relations entre ses différentes parties (les tables).

UML fournit un formalisme pour décrire les relations entre les classes ainsi que les contraintes apposées sur ces relations.

Comme nous l'avons déjà vu dans le chapitre précédent, nous avons, de manière générale, une correspondance entre les classes du modèle objet (UML) et les tables de la base de données (MPD).

En UML, la relation entre deux classes s'appelle une association.

Pour modéliser une association entre deux classes, vous tracez simplement un trait entre elles.

Une association entre deux classes est matérialisée par un trait
Une association entre deux classes est matérialisée par un trait

Vous pouvez, si besoin, préciser un nom pour cette association au milieu du trait (généralement un verbe) :

Une association peut avoir un nom
Une association peut avoir un nom

On lit alors la relation comme ceci :

  • « Un musicien forme des groupes »

  • « Un groupe est formé par des musiciens »

Vous pouvez également donner un rôle à chaque classe en le notant du côté des classes concernées :

Il est possible de préciser le rôle de chaque classe dans une association
Il est possible de préciser le rôle de chaque classe dans une association

On interprète alors la relation comme ceci :

  • « Une personne, en tant que conducteur, conduit un véhicule »

  • « Un véhicule, en tant moyen de locomotion, est conduit par une personne »

Imaginez 2 associations entre une classe Personne et une classe Livre :

  • la première indique le/les auteurs d'un livre

  • la deuxième indique le/les traducteurs d'un livre

Voici comment cela peut être représenté avec les noms des associations :

Différencier des associations avec des noms
Différencier des associations avec des noms

Voici comment cela peut être représenté avec les rôles sur les associations :

Différencier des associations avec des rôles
Différencier des associations avec des rôles

Posez des limites avec les multiplicités

Les multiplicités servent à apposer des contraintes numériques sur l'association, ou plus précisément, combien d'instances d'une classe peuvent être liées à une instance de la classe de l'autre côté de l'association. En d'autres termes, elles bornent les cardinalités des instances liées entre elles.

Si on reprend l'exemple du dessus avec les musiciens, il est possible de fixer le nombre de musiciens minimum et maximum qui peuvent jouer dans un groupe. De même il est possible de définir dans combien de groupes différents (min et max) un même musicien peut jouer.

Voici un exemple abstrait montrant comment sont représentées les multiplicités :

Diagramme de classes ‒ Multiplicités des classes A et B
Diagramme de classes ‒ Multiplicités des classes A et B

Cela s'interprète comme ceci :

  • Une instance de la classe A doit être associée à au moins m et au plus n instances de la classe B

  • Une instance de la classe B doit être associée à au moins x et au plus y instances de la classe A

Si je reprends l'exemple des musiciens, voici, ci-dessous, le diagramme correspondant aux règles suivantes :

  • Un musicien joue dans 5 groupes maximum, mais peut aussi ne jouer dans aucun groupe.

  • Un groupe est constitué d'au moins 2 musiciens et 10 au maximum

Diagramme de classes ‒ Exemple de multiplicités entre Musiciens et Groupes
Diagramme de classes ‒ Exemple de multiplicités entre Musiciens et Groupes

Synthèse des multiplicités

Il existe des abréviations pour certaines plages de cardinalités. Voici un tableau de synthèse des multiplicités, avec leur notation, leur abréviation éventuelle et leur signification en termes de cardinalités :

Multiplicité

Abréviation

Cardinalités

0..0

0

Aucune instance

0..1

 

Aucune ou une seule instance

1..1

1

Exactement une instance

0..*

*

Aucune, une ou plusieurs instances (aucune limite)

1..*

 

Au moins une instance (aucune limite maximum)

x..x

x

Exactement x instance(s)

m..n

 

Au moins m et au plus n instances

Les 3 catégories d'association

Les associations sont classées en trois catégories en fonction des multiplicités apposées sur celles-ci :

  1. un à un (one-to-one) :

    • Un conducteur conduit une et une seule voiture à la fois

    • Une voiture n'est pas conduite (en stationnement) ou conduite par un seul conducteur à la fois

  2. un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :

    • Un journal contient aucun (journal en préparation), un ou plusieurs articles

    • Un article est contenu dans aucun (en cours d'écriture) ou un seul journal

  3. plusieurs à plusieurs (many-to-many) :

    • Un musicien fait partie d'aucun, un ou plusieurs groupes

    • Un groupe est constitué de un ou plusieurs musiciens

Dans ce chapitre nous avons vu :

  • comment décrire les relations entre les différentes classes du domaine fonctionnel,

  • comment imposer des limites de cardinalité

  • et les 3 catégories de relations :

    • un à un (one-to-one)

    • un à plusieurs (one-to-many) ou plusieurs à un (many-to-one)

    • plusieurs à plusieurs (many-to-many)

Dans le prochain chapitre, nous verrons comment mettre en œuvre ces relations dans la base de données en commençant par s'assurer que chaque instance d'une classe ait un identifiant unique.

Qu'est-ce que cela signifie ? C'est justement ce que nous allons aborder !

Exemple de certificat de réussite
Exemple de certificat de réussite