Tentative de définition d’une classe association

Une « classe association », qu’est-ce que c’est ?

Si vous avez été amené à modéliser des concepts métier (un diagramme de classe au sens UML) ou plus simplement à devoir lire un diagramme de classe, alors la représentation ci-dessus ne vous est peut-être pas inconnue.

Mais que signifie-t-elle réellement ? Comment la lire et quand l’utiliser à bon escient ? Tel est l’objet de cet article qui, je l’espère, vous aidera à mieux comprendre la technique de la classe association.

En modélisation UML des données, une « classe association » est une classe à la jonction de deux autres classes. Elle porte des informations, que l’on appelle « attributs », qui sont en dépendance directe des deux autres classes et qui ne pourraient se mettre ni dans l’une, ni dans l’autre.

Bon, vous me direz qu’avec cela, on n’est pas beaucoup plus avancé. Je vais donc illustrer par des exemples. Je préciserais quand même que cet article s’adresse plutôt à des gens qui savent déjà un peu modéliser. A la fin, je vous donnerai une astuce pour vous passer de l’utilisation d’une classe association. Cela permettra aux plus néophytes de se sortir des situations complexes.

Quand peut-il y avoir une classe association ?

Il ne peut y avoir une classe association que si l’association entre les deux autres classes a de part et d’autre une multiplicité maximum égale à « plusieurs », représentée par le symbole « * ».

Dans l’exemple ci-dessus, il y a bien « * » du côté du concept A et du concept B, il est donc possible de mettre une classe association. Dans tous les autres cas, cela constituerait une erreur de modélisation. Pour information, la valeur de la multiplicité minimum (0 ou 1) n’entre pas en ligne de compte.

En synthèse, voici la liste des cas envisageables :

• Concept A 0 ou 1..1 —————- 0 ou 1..* Concept B : pas de classe association possible
• Concept A 0 ou 1..* —————– 0 ou 1..1 Concept B : pas de classe association possible
• Concept A 0 ou 1..* —————– 0 ou 1..* Concept B : classe association possible

Y a-t-il toujours une classe association ?

Exemple de cas sans classe association

On pourrait penser que dès lors qu’il y a une association entre deux classes avec « * » en multiplicité maximum, alors il y a forcément une classe association. Cela est vrai si l’on se place du point de vue d’un développeur fabriquant sa base de données. Mais lorsqu’on travaille à un niveau conceptuel métier, ce qui est le cas lorsqu’on rédige un cahier des charges, alors cela n’est plus du tout systématique.

Pour illustrer cela, je vais prendre un exemple simple. Imaginons que vous deviez rédiger un cahier des charges pour gérer les traducteurs d’une maison d’édition. Un traducteur peut traduire une à plusieurs (*) langues et une même langue peut être traduite par un à plusieurs (*) traducteurs. Le système à implémenter devra donc permettre de renseigner cela et de dire précisément quel traducteur traduit quelle(s) langue(s).

Dit plus clairement, le traducteur François traduit l’anglais et l’espagnol et la traductrice Claire traduit l’anglais et l’allemand. Un traducteur se caractérise par son nom et sa date d’entrée dans la maison d’éditions (ce sont ses attributs) et une langue se caractérise par son nom. Souvenez-vous ce que j’ai écrit plus haut : « une classe association vient porter des informations, que l’on appellera « attributs », qui sont en dépendance directe des deux autres classes« . Dans le cas exposé ici, aucun attribut n’est en dépendance à la fois du traducteur et de la langue : nul besoin de représenter une classe association dans la vision « métier » des choses.

Exemple de cas avec une classe association

Toujours dans le cadre de notre maison d’édition, vous devez à présent gérer le fait qu’un traducteur n’a pas le même niveau de maîtrise pour chacune des langues qu’il pratique. François a l’anglais pour langue maternelle et a un niveau courant en espagnol. Quant à Claire, elle est bilingue sur l’anglais et l’allemand.

Où mettre cette nouvelle information qu’est le « niveau » et qui est très importante pour le métier ? Comment représenter graphiquement le fait que pour chaque occurrence de couple « traducteur – langue », je dois pouvoir indiquer le niveau de maîtrise ?

Option 1

Option 1 : je dis que le niveau est un nouvel attribut du traducteur. Problème : le niveau que j’attribuerai au traducteur sera le même pour toutes les langues qu’il traite. Pourquoi ? Parce que l’attribut « niveau » du concept « Traducteur » ne peut prendre qu’une seule valeur à un instant T, donc si je dis que François a un niveau « langue maternelle », cette valeur vaudra pour toutes les langues auxquelles il est rattaché : l’anglais et l’espagnol. Or, au regard de l’énoncé, on sait que cela est faux.

Option 2

Option 2 : je mets le niveau sur la langue. Quelques secondes de réflexion suffisent à comprendre que cela n’est pas non plus un choix pertinent.

Option 3

Option 3 : je fais appel à la classe association, que je pourrais appeler « Niveau » et sur laquelle je mettrai l’attribut « libellé », la valeur de ce niveau dépendant à la fois du traducteur et de la langue.

Une fois traduit en termes métier, cette représentation graphique signifie bien que pour chaque couple « Traducteur – Langue », je pourrai renseigner le niveau adéquat.

Ainsi :

• François – Anglais – Langue maternelle
• François – Espagnol – Courant
• Claire – Anglais – Bilingue
• Claire – Allemand – Bilingue

Le piège derrière la classe association

On pourrait avoir le réflexe de systématiquement utiliser la classe association dès lors que les principes précédents sont respectés : association entre deux classes avec « * » de chaque côté et présence d’au moins un attribut en dépendance directe des deux classes. Ce serait cependant une erreur de ne pas prendre un temps de réflexion pour bien approfondir le sujet.

En effet, la classe association a un signification bien précise et est porteuse d’une contrainte forte que je vais illustrer via un deuxième exemple.

Cas concret

Problématique à résoudre

Vous devez rédiger un cahier des charges pour une plateforme permettant à des écoliers de faire des exercices en ligne. Un écolier peut passer plusieurs exercices et un même exercice peut bien sûr être passé par plusieurs écoliers, ceux d’une même classe par exemple.

Pour chaque passage d’un exercice, le métier a besoin de pouvoir consulter la date de passage ainsi que le score obtenu par l’écolier.

La classe association comme solution « réflexe »

Premier réflexe, naturel : je crée une classe association « Passage » où je vais stocker les deux attributs « date » et « score ».

Cela pourrait donc donner :

• Nadia – Exercice 1 – 20/05/2021 10h05 – 78%
• Nadia – Exercice 2 – 20/05/2021 11h01 – 95%
• Adrien – Exercice 1 – 21/05/2021 08h33 – 80%
• Adrien – Exercice 2 – 20/05/2021 08h45 – 63%
• Etc.

A priori, tout va bien. J’enregistre les informations souhaitées et mon système fonctionne. J’ai cependant oublier de poser une question primordiale à mon interlocuteur métier : un écolier peut-il passer plusieurs fois le même exercice ? Par exemple pour le refaire s’il a obtenu un score insuffisant au premier passage.

Ne tombez pas dans le piège de la classe association systématique

Car c’est là le piège de la classe association : cette représentation implique qu’il ne peut pas y avoir deux occurrences d’un même couple de classes ou, pour illustrer avec l’exemple, cela signifie que Nadia ne pourra pas passer plus d’une fois chacun des exercices mis à sa disposition. Un seul passage autorisé pour l’exercice 1, l’exercice 2, etc.

Pour bien comprendre cela, il faut se plonger un instant dans la base de données. Que va-t-il se passer lorsque Nadia va réaliser l’exercice 1 ? Le système va automatiquement créer une occurrence de classe association dont l’identifiant sera composé de celui de Nadia (écolière n° 345) et de celui de l’exercice (n° 61). Et comme il ne peut pas exister en base de données deux occurrences de classe ayant le même identifiant, cela signifie bien que le couple « Nadia – Exercice 1 » ne pourra pas être enregistré deux fois.

L’impact métier dans ce cas précis est donc que l’écolier ne peut pas refaire plusieurs fois un même exercice en vue de s’améliorer.

Conséquence du piège

L’une des première choses à faire lorsque vous pensez représenter une classe association, c’est de bien s’assurer auprès du métier qu’il ne peut pas y avoir de répétition (plusieurs occurrences) d’un même couple de classes.

Dans l’exemple de la maison d’édition et des traducteurs, une fois que l’on a indiqué que l’anglais est la langue maternelle de François, cela n’aurait pas de sens de faire ensuite une deuxième occurrence pour dire qu’il est bilingue sur cette même langue. Donc, dans ce cas, la classe association est parfaitement utilisée.

En revanche, dans le cas des écoliers et des exercices, si le métier vous dit qu’il s’agit d’exercices :

• à passage unique, alors la classe association se justifie pleinement,
• pouvant être passés plusieurs fois afin de s’entraîner et de progresser, alors la classe association n’est pas la bonne représentation graphique.

Si l’on ne clarifie pas cela au plus tôt avec le métier, l’impact sur le système développé peut être énorme, et surtout très coûteux. En effet, imaginons que vous donniez votre modèle avec la classe association au développeur. Lui comprend normalement très bien la problématique exposée ci-dessus et les fonctionnalités qu’il développera répondront au besoin exprimé par votre schéma.

Je vous laisse réfléchir à la déconvenue du  métier lorsqu’il effectuera la recette et qu’il essaiera de passer une seconde fois un exercice… C’est tout votre système qu’il faudra revoir : modifier le cahier des charges, réécrire le code, refaire les tests unitaires, re livrer en environnement de recette, refaire les tests métier, cela entraînant bien sûr une dérive de délai et de coûts !

Comment éviter le piège ?

Une fois que l’on a posé la question au métier et que l’on a compris qu’un même exercice doit pouvoir être fait plusieurs fois par un même écolier, que faire ? En effet, la classe association ne pouvant pas être utilisée, où mettre les informations de date de passage et de score ?

C’est très simple : le « Passage » reste bel et bien une classe mais :

• elle sera rattachée à écolier et à exercice,
• l’association entre écolier et exercice saute.

Cela donnera donc :

• Un écolier fait aucun ou plusieurs passages et un passage est réalisé par un seul écolier.
• Un exercice fait l’objet d’aucun ou plusieurs passages et un passage porte sur un seul exercice.

Autrement dit, j’ai cassé la relation avec multiplicité « * » entre écolier et exercice pour faire deux associations et cela exprime parfaitement le fait qu’un écolier puisse passer plusieurs fois le même exercice.

Pourquoi ? Vous demandez-vous peut-être…

Tout simplement parce que dans le cas initial, l’identifiant de la classe association était composé des identifiants de l’écolier et de l’exercice, ce qui interdisait les doublons. Alors que dans le cas final, « Passage » étant une classe à part entière, elle a son propre identifiant, complètement indépendant de ceux de l’écolier et de l’exercice. Par conséquent, on peut en créer autant qu’on veut, Nadia peut passer 50 fois l’exercice 1 si elle le souhaite.

Une classe association peut-elle être rattachée à une autre classe ?

Si jamais vous vous posez la question, sachez que la réponse est oui. Au même titre que les autres classes de votre modèle, une classe association peut elle aussi être rattachée à une ou plusieurs autres classes.

Conclusion

Sur le principe, la technique de la classe association est assez simple à acquérir dès lors qu’on a compris la logique qui la sous-tend. Cependant, un usage trop systématique peut être fortement préjudiciable à la solution qui sera développée, aussi je vous recommande fortement de bien toujours penser à poser cette question de « peut-il y en avoir plusieurs ? »

Outre le fait que c’est un questionnement très pertinent pour comprendre le fonctionnement d’un métier et clarifier une attente, il vous permettra de modéliser puis de décrire de façon très précise l’attendu et ainsi éviter une incompréhension qui s’avèrera toujours coûteuse !

Pour en apprendre davantage sur la modélisation des données, vous pouvez également parcourir ces articles : 

https://soscahierdescharges.fr/modeliser-les-donnees-dans-un-cahier-des-charges/

https://soscahierdescharges.fr/diagramme-de-classe-les-bonnes-multiplicites/

https://soscahierdescharges.fr/diagramme-de-classe-7-clefs-pour-etre-compris/

N’hésitez pas à vous abonner à notre newsletter en bas de cette article. Postez un commentaire et venez partager votre expérience sur les sujets en lien avec les cahier des charges !

Tentative de définition d’une classe association

Une « classe association », qu’est-ce que c’est ?

Si vous avez été amené à modéliser des concepts métier (un diagramme de classe au sens UML) ou plus simplement à devoir lire un diagramme de classe, alors la représentation ci-dessus ne vous est peut-être pas inconnue.

Mais que signifie-t-elle réellement ? Comment la lire et quand l’utiliser à bon escient ? Tel est l’objet de cet article qui, je l’espère, vous aidera à mieux comprendre la technique de la classe association.

En modélisation UML des données, une « classe association » est une classe à la jonction de deux autres classes. Elle porte des informations, que l’on appelle « attributs », qui sont en dépendance directe des deux autres classes et qui ne pourraient se mettre ni dans l’une, ni dans l’autre.

Bon, vous me direz qu’avec cela, on n’est pas beaucoup plus avancé. Je vais donc illustrer par des exemples. Je préciserais quand même que cet article s’adresse plutôt à des gens qui savent déjà un peu modéliser. A la fin, je vous donnerai une astuce pour vous passer de l’utilisation d’une classe association. Cela permettra aux plus néophytes de se sortir des situations complexes.

Quand peut-il y avoir une classe association ?

Il ne peut y avoir une classe association que si l’association entre les deux autres classes a de part et d’autre une multiplicité maximum égale à « plusieurs », représentée par le symbole « * ».

Dans l’exemple ci-dessus, il y a bien « * » du côté du concept A et du concept B, il est donc possible de mettre une classe association. Dans tous les autres cas, cela constituerait une erreur de modélisation. Pour information, la valeur de la multiplicité minimum (0 ou 1) n’entre pas en ligne de compte.

En synthèse, voici la liste des cas envisageables :

• Concept A 0 ou 1..1 —————- 0 ou 1..* Concept B : pas de classe association possible
• Concept A 0 ou 1..* —————– 0 ou 1..1 Concept B : pas de classe association possible
• Concept A 0 ou 1..* —————– 0 ou 1..* Concept B : classe association possible

Y a-t-il toujours une classe association ?

Exemple de cas sans classe association

On pourrait penser que dès lors qu’il y a une association entre deux classes avec « * » en multiplicité maximum, alors il y a forcément une classe association. Cela est vrai si l’on se place du point de vue d’un développeur fabriquant sa base de données. Mais lorsqu’on travaille à un niveau conceptuel métier, ce qui est le cas lorsqu’on rédige un cahier des charges, alors cela n’est plus du tout systématique.

Pour illustrer cela, je vais prendre un exemple simple. Imaginons que vous deviez rédiger un cahier des charges pour gérer les traducteurs d’une maison d’édition. Un traducteur peut traduire une à plusieurs (*) langues et une même langue peut être traduite par un à plusieurs (*) traducteurs. Le système à implémenter devra donc permettre de renseigner cela et de dire précisément quel traducteur traduit quelle(s) langue(s).

Dit plus clairement, le traducteur François traduit l’anglais et l’espagnol et la traductrice Claire traduit l’anglais et l’allemand. Un traducteur se caractérise par son nom et sa date d’entrée dans la maison d’éditions (ce sont ses attributs) et une langue se caractérise par son nom. Souvenez-vous ce que j’ai écrit plus haut : « une classe association vient porter des informations, que l’on appellera « attributs », qui sont en dépendance directe des deux autres classes« . Dans le cas exposé ici, aucun attribut n’est en dépendance à la fois du traducteur et de la langue : nul besoin de représenter une classe association dans la vision « métier » des choses.

Exemple de cas avec une classe association

Toujours dans le cadre de notre maison d’édition, vous devez à présent gérer le fait qu’un traducteur n’a pas le même niveau de maîtrise pour chacune des langues qu’il pratique. François a l’anglais pour langue maternelle et a un niveau courant en espagnol. Quant à Claire, elle est bilingue sur l’anglais et l’allemand.

Où mettre cette nouvelle information qu’est le « niveau » et qui est très importante pour le métier ? Comment représenter graphiquement le fait que pour chaque occurrence de couple « traducteur – langue », je dois pouvoir indiquer le niveau de maîtrise ?

Option 1

Option 1 : je dis que le niveau est un nouvel attribut du traducteur. Problème : le niveau que j’attribuerai au traducteur sera le même pour toutes les langues qu’il traite. Pourquoi ? Parce que l’attribut « niveau » du concept « Traducteur » ne peut prendre qu’une seule valeur à un instant T, donc si je dis que François a un niveau « langue maternelle », cette valeur vaudra pour toutes les langues auxquelles il est rattaché : l’anglais et l’espagnol. Or, au regard de l’énoncé, on sait que cela est faux.

Option 2

Option 2 : je mets le niveau sur la langue. Quelques secondes de réflexion suffisent à comprendre que cela n’est pas non plus un choix pertinent.

Option 3

Option 3 : je fais appel à la classe association, que je pourrais appeler « Niveau » et sur laquelle je mettrai l’attribut « libellé », la valeur de ce niveau dépendant à la fois du traducteur et de la langue.

Une fois traduit en termes métier, cette représentation graphique signifie bien que pour chaque couple « Traducteur – Langue », je pourrai renseigner le niveau adéquat.

Ainsi :

• François – Anglais – Langue maternelle
• François – Espagnol – Courant
• Claire – Anglais – Bilingue
• Claire – Allemand – Bilingue

Le piège derrière la classe association

On pourrait avoir le réflexe de systématiquement utiliser la classe association dès lors que les principes précédents sont respectés : association entre deux classes avec « * » de chaque côté et présence d’au moins un attribut en dépendance directe des deux classes. Ce serait cependant une erreur de ne pas prendre un temps de réflexion pour bien approfondir le sujet.

En effet, la classe association a un signification bien précise et est porteuse d’une contrainte forte que je vais illustrer via un deuxième exemple.

Cas concret

Problématique à résoudre

Vous devez rédiger un cahier des charges pour une plateforme permettant à des écoliers de faire des exercices en ligne. Un écolier peut passer plusieurs exercices et un même exercice peut bien sûr être passé par plusieurs écoliers, ceux d’une même classe par exemple.

Pour chaque passage d’un exercice, le métier a besoin de pouvoir consulter la date de passage ainsi que le score obtenu par l’écolier.

La classe association comme solution « réflexe »

Premier réflexe, naturel : je crée une classe association « Passage » où je vais stocker les deux attributs « date » et « score ».

Cela pourrait donc donner :

• Nadia – Exercice 1 – 20/05/2021 10h05 – 78%
• Nadia – Exercice 2 – 20/05/2021 11h01 – 95%
• Adrien – Exercice 1 – 21/05/2021 08h33 – 80%
• Adrien – Exercice 2 – 20/05/2021 08h45 – 63%
• Etc.

A priori, tout va bien. J’enregistre les informations souhaitées et mon système fonctionne. J’ai cependant oublier de poser une question primordiale à mon interlocuteur métier : un écolier peut-il passer plusieurs fois le même exercice ? Par exemple pour le refaire s’il a obtenu un score insuffisant au premier passage.

Ne tombez pas dans le piège de la classe association systématique

Car c’est là le piège de la classe association : cette représentation implique qu’il ne peut pas y avoir deux occurrences d’un même couple de classes ou, pour illustrer avec l’exemple, cela signifie que Nadia ne pourra pas passer plus d’une fois chacun des exercices mis à sa disposition. Un seul passage autorisé pour l’exercice 1, l’exercice 2, etc.

Pour bien comprendre cela, il faut se plonger un instant dans la base de données. Que va-t-il se passer lorsque Nadia va réaliser l’exercice 1 ? Le système va automatiquement créer une occurrence de classe association dont l’identifiant sera composé de celui de Nadia (écolière n° 345) et de celui de l’exercice (n° 61). Et comme il ne peut pas exister en base de données deux occurrences de classe ayant le même identifiant, cela signifie bien que le couple « Nadia – Exercice 1 » ne pourra pas être enregistré deux fois.

L’impact métier dans ce cas précis est donc que l’écolier ne peut pas refaire plusieurs fois un même exercice en vue de s’améliorer.

Conséquence du piège

L’une des première choses à faire lorsque vous pensez représenter une classe association, c’est de bien s’assurer auprès du métier qu’il ne peut pas y avoir de répétition (plusieurs occurrences) d’un même couple de classes.

Dans l’exemple de la maison d’édition et des traducteurs, une fois que l’on a indiqué que l’anglais est la langue maternelle de François, cela n’aurait pas de sens de faire ensuite une deuxième occurrence pour dire qu’il est bilingue sur cette même langue. Donc, dans ce cas, la classe association est parfaitement utilisée.

En revanche, dans le cas des écoliers et des exercices, si le métier vous dit qu’il s’agit d’exercices :

• à passage unique, alors la classe association se justifie pleinement,
• pouvant être passés plusieurs fois afin de s’entraîner et de progresser, alors la classe association n’est pas la bonne représentation graphique.

Si l’on ne clarifie pas cela au plus tôt avec le métier, l’impact sur le système développé peut être énorme, et surtout très coûteux. En effet, imaginons que vous donniez votre modèle avec la classe association au développeur. Lui comprend normalement très bien la problématique exposée ci-dessus et les fonctionnalités qu’il développera répondront au besoin exprimé par votre schéma.

Je vous laisse réfléchir à la déconvenue du  métier lorsqu’il effectuera la recette et qu’il essaiera de passer une seconde fois un exercice… C’est tout votre système qu’il faudra revoir : modifier le cahier des charges, réécrire le code, refaire les tests unitaires, re livrer en environnement de recette, refaire les tests métier, cela entraînant bien sûr une dérive de délai et de coûts !

Comment éviter le piège ?

Une fois que l’on a posé la question au métier et que l’on a compris qu’un même exercice doit pouvoir être fait plusieurs fois par un même écolier, que faire ? En effet, la classe association ne pouvant pas être utilisée, où mettre les informations de date de passage et de score ?

C’est très simple : le « Passage » reste bel et bien une classe mais :

• elle sera rattachée à écolier et à exercice,
• l’association entre écolier et exercice saute.

Cela donnera donc :

• Un écolier fait aucun ou plusieurs passages et un passage est réalisé par un seul écolier.
• Un exercice fait l’objet d’aucun ou plusieurs passages et un passage porte sur un seul exercice.

Autrement dit, j’ai cassé la relation avec multiplicité « * » entre écolier et exercice pour faire deux associations et cela exprime parfaitement le fait qu’un écolier puisse passer plusieurs fois le même exercice.

Pourquoi ? Vous demandez-vous peut-être…

Tout simplement parce que dans le cas initial, l’identifiant de la classe association était composé des identifiants de l’écolier et de l’exercice, ce qui interdisait les doublons. Alors que dans le cas final, « Passage » étant une classe à part entière, elle a son propre identifiant, complètement indépendant de ceux de l’écolier et de l’exercice. Par conséquent, on peut en créer autant qu’on veut, Nadia peut passer 50 fois l’exercice 1 si elle le souhaite.

Une classe association peut-elle être rattachée à une autre classe ?

Si jamais vous vous posez la question, sachez que la réponse est oui. Au même titre que les autres classes de votre modèle, une classe association peut elle aussi être rattachée à une ou plusieurs autres classes.

Conclusion

Sur le principe, la technique de la classe association est assez simple à acquérir dès lors qu’on a compris la logique qui la sous-tend. Cependant, un usage trop systématique peut être fortement préjudiciable à la solution qui sera développée, aussi je vous recommande fortement de bien toujours penser à poser cette question de « peut-il y en avoir plusieurs ? »

Outre le fait que c’est un questionnement très pertinent pour comprendre le fonctionnement d’un métier et clarifier une attente, il vous permettra de modéliser puis de décrire de façon très précise l’attendu et ainsi éviter une incompréhension qui s’avèrera toujours coûteuse !

Pour en apprendre davantage sur la modélisation des données, vous pouvez également parcourir ces articles : 

https://soscahierdescharges.fr/modeliser-les-donnees-dans-un-cahier-des-charges/

https://soscahierdescharges.fr/diagramme-de-classe-les-bonnes-multiplicites/

https://soscahierdescharges.fr/diagramme-de-classe-7-clefs-pour-etre-compris/

N’hésitez pas à vous abonner à notre newsletter en bas de cette article. Postez un commentaire et venez partager votre expérience sur les sujets en lien avec les cahier des charges !