4  Modèle du domaine (MDD, modèle conceptuel)

Les MDD sont expliqués en détail dans le chapitre 9 , mais voici des points importants :

4.1 Classes conceptuelles

Il y a trois stratégies pour identifier les classes conceptuelles :

  1. Réutiliser ou modifier des modèles existants.
  2. Utiliser une liste de catégories.
  3. Identifier des groupes nominaux.

4.1.1 Catégories pour identifier des classes conceptuelles

Extrait du tableau 9.1 
Catégorie Exemples
Transactions d’affaires : Elles sont essentielles, commencez l’analyse par les transactions. Vente, Attaque, Réservation, Inscription, EmpruntVélo
Lignes d’une transaction : Éléments compris dans une transaction. LigneArticles, ExemplaireLivre, GroupeCours
Produit ou service lié à une transaction ou à une ligne de transaction : Pour quel concept sont faites des transactions ? Article, Vélo, Vol, Livre, Cours
Où la transaction est-elle enregistrée ? Caisse, GrandLivre, ManifesteDeVol
Rôle des personnes liées à la transaction : Qui sont les parties impliquées dans une transaction ? Caissier, Client, JoueurDeMonopoly, Passager
Organisations liées à la transaction : Quelles sont les organisations impliquées dans une transaction ? Magasin, CompagnieAérienne, Bibliothèque, Université
Lieu de la transaction, lieu du service Magasin, Aéroport, Avion, Siège, LocalCours
Événements notables, à mémoriser Vente, Paiement, JeuMonopoly, Vol
Objets physiques : Importants surtout lorsqu’il s’agit d’un logiciel de contrôle d’équipements ou de simulation. Article, Caisse, Plateau, Pion, , Vélo
Description d’entités : Voir section 9.13  pour plus d’informations. DescriptionProduit, DescriptionVol, Livre (en opposition avec Exemplaire), Cours (en opposition avec CoursGroupe)
Catalogues : Les descriptions se trouvent souvent dans des catalogues. CatalogueProduits, CatalogueVols, CatalogueLivres, CatalogueCours
Conteneurs : Un conteneur peut contenir des objets physiques ou des informations. Magasin, Rayonnage, Plateau, Avion, Bibliothèque
Contenu d’un conteneur Article, Case (sur un Plateau de jeu), Passager, Exemplaire
Autres systèmes externes SystèmeAutorisationPaiementsÀCrédit, SystèmeGestionBordereaux
Documents financiers, contrats, documents légaux Reçus, GrandLivre, JournalDeMaintenance
Instruments financiers Espèces, Chèque, LigneDeCrédit
Plannings, manuels, documents régulièrement consultés pour effectuer un travail MiseÀJourTarifs, PlanningRéparations

4.2 Attributs

Les attributs sont le sujet de la section 9.16 . Comme c’est le cas pour les classes et les associations, on fait figurer les attributs quand les cas d’utilisation suggèrent la nécessité de mémoriser des informations.

Pour l’UML, la syntaxe complète d’un attribut est :

visibilité nom : type multiplicité = défaut {propriété}

Voici des points importants :

  • Le type d’un attribut est important, et il faut le spécifier dans un MDD, même si dans le livre de Larman (2005), il y a plusieurs exemples sans type.
  • Ne vous souciez pas de la visibilité des attributs dans un MDD.
  • Faites attention à la confusion des attributs et des classes. Si l’on ne pense pas un concept X en termes alphanumériques dans le monde réel, alors il s’agit probablement d’une classe conceptuelle. Par exemple, dans le monde réel, une université n’est composée ni de chiffres ni de lettres. Elle doit être une classe conceptuelle. Voir la section 9.12 .
  • De la même manière, faites attention aux informations qui sont mieux modélisées par des associations. Par exemple, sur la figure 4.2, la classe Pays n’a pas un attribut joueur:Joueur (qui contrôle le Pays) ; elle a plutôt une association avec la classe Joueur et un verbe contrôle.

Il est vrai que dans un langage de programmation comme Java, les associations doivent être les attributs dans les classes, car il s’agit des classes logicielles. Cependant, dans un modèle du domaine, on évite des attributs si une association peut mieux décrire la relation. La relation relie visuellement les deux classes conceptuelles et elle est décrite avec un verbe.

4.3 Associations

Les associations dans le MDD sont le sujet de la section 9.14 . Il faut se référer au contenu du livre de Larman pour les détails. Une association est une relation entre des classes (ou des instances de classes). Elle indique une connexion significative ou intéressante. Voici des points importants :

  • Il est facile de trouver beaucoup d’associations, mais il faut se limiter à celles qui doivent être conservées un certain temps. Pensez à la mémorabilité d’une association dans le contexte du logiciel à développer. Par exemple, considérez les associations de la figure 4.2 :
    • Il existe une association entre Joueur et Pays, car il est important de savoir quel joueur contrôle quel pays dans le jeu Risk.
    • Il n’y a pas d’association entre JeuRisk et Attaque, même si les attaques font partie du jeu. Il n’est pas essentiel de mémoriser l’historique de toutes les attaques réalisées dans le jeu.
  • Il y a des associations dérivées de la liste des associations courantes. Voir le tableau 4.1.
  • En UML, les associations sont représentées par des lignes entre les classes.
    • Elles sont nommées (avec un verbe commençant par une lettre majuscule).
    • Des verbes simples comme « A », « Utilise », « Possède », « Contient », etc. sont généralement des choix médiocres, car ils n’aident pas notre compréhension du domaine. Essayez de trouver des verbes plus riches, si possible.
    • Une flèche (triangle) de « sens de lecture » optionnelle indique la direction dans laquelle lire l’association. Si la flèche est absente, on lit l’association de gauche à droite ou de haut en bas.
    • Les extrémités des associations ont une expression de la multiplicité indiquant une relation numérique entre les instances des classes. Vous pouvez en trouver plusieurs exemples sur la figure 4.2.
  • Les associations ne doivent pas être représentées avec des attributs. Les associations servent à représenter les relations purement conceptuelles afin de documenter le domaine. Elles ne visent pas à documenter la structure des données ou les instances de variables qu’on retrouve dans le logiciel. Contrairement aux associations des diagrammes de classes logicielles, ce ne sont pas toutes les associations conceptuelles qui seront implémentées dans le logiciel.
Tableau 4.1: Extrait du tableau 9.2  (liste d’associations courantes)
Catégorie Exemples
A est une transaction liée à une transaction B PaiementEnEspèces – Vente
Réservation – Annulation
A est un élément d’une transaction B LigneArticles – Vente
A est un produit pour une transaction (ou un élément de transaction) B Article – LigneArticles (ou Vente)
Vol – Réservation
A est un rôle lié à une transaction B Client – Paiement
Passager – Billet
A est une partie logique ou physique de B Tiroir – Registre
Case – Plateau
Siège – Avion
A est physiquement ou logiquement contenu dans B Registre – Magasin
Joueur – Monopoly
Passager – Avion
A est une description de B DescriptionProduit – Article
DescriptionVol – Vol
A est connu/consigné/enregistré/saisi dans B Vente – Registre
Pion – Case
Réservation – ManifesteDeVol
A est un membre de B Caissier – Magasin
Joueur – Monopoly
Pilote – CompagnieAérienne
A est une sous-unité organisationnelle de B Rayon – Magasin
Maintenance – CompagnieAérienne
A utilise, gère ou possède B Caissier – Registre
Joueur – Pion
Pilote – Avion
A est voisin de B Article – Article
Case – Case
Ville – Ville

4.4 Attributs dérivés

Les attributs dérivés sont expliqués en détail dans la section 9.16 . Il s’agit des attributs qui sont calculés à partir d’autres informations reliées à la classe. Ils sont indiqués par le symbole / devant leur nom.

L’exemple à la figure 4.1 s’applique à la règle du jeu Risk spécifiant qu’un joueur reçoit un certain nombre de renforts selon le nombre de pays occupés. La classe Joueur pourrait avoir un attribut dérivé /nbPaysOccupés qui est calculé selon le nombre de Pays contrôlés par le joueur.

Joueurnom : String/nbPaysOccupés : intPaysnom : StringContrôle11..*

Figure 4.1: nbPaysOccupés est un attribut dérivé. Sa valeur sera calculée selon le nombre de pays de l’association. (PlantUML)

4.5 Exemple de MDD pour le jeu Risk

La figure 4.2 est un MDD pour le jeu Risk, selon l’exemple mentionné dans le chapitre sur les cas d’utilisation. Commençons par la classe JeuRisk, qui est l’objet racine du modèle. Il est relié à la classe Joueur, puisqu’un joueur « joue » à JeuRisk (notez le triangle pour le sens de lecture). Selon les cardinalités de l’association entre ces deux classes, il peut y avoir entre deux (2) et six (6) personnes qui jouent au jeu. Le jeu « inclut » cinq objets de la classe , mais un Joueur jette un, deux ou trois dés (selon la règle du jeu Risk). L’association entre Joueur et Pays a un verbe « contrôle », qui est un exemple de verbe plus riche que « possède » ou « a ». L’association entre Continent et Pays représente la composition des territoires (un synonyme pour pays) des différents continents, soit 4 (pour l’Amérique du sud et l’Océanie), 6 (pour l’Afrique), 7 (pour l’Europe), 9 (pour l’Amérique du nord) et 12 (pour l’Asie). Si vous regardez tout le modèle, vous verrez qu’il représente visuellement beaucoup d’éléments du jeu.

Joueurnom : String/nbPaysOccupés : intvaleur : intJeuRiskPlateauRiskPaysnom : StringAttaquenbAttaquant : intnbDéfenseur : intOccupationnbRégiments : intContinentContient142Est-divisé-en16Groupe14, 6,7, 9,12Est-voisin-de11..*Est-joué-sur11Inclut15Joue12:6Contrôle11..*Lance1..*1Défend-contre11..* Jette11,2,3

Figure 4.2: Modèle du domaine du jeu Risk. (PlantUML)

4.6 Classes de « description » et classes de catalogue

Deux catégories de classes conceptuelles qui vont de pair sont les descriptions d’entités et les catalogues qui agrègent les descriptions. Elles sont expliquées en détail dans la section 9.13 . Voici des conditions pour utiliser correctement une classe de description d’une autre classe « X » :

  • Il faut disposer de la description d’un produit ou d’un service « X » indépendamment de l’existence actuelle des « X ». Par exemple, il pourrait y avoir une rupture de stock d’un Produit (aucune instance actuelle), mais on a besoin de connaître son prix. La classe DescriptionProduit permet d’avoir cette information, même s’il n’y a plus d’instances de Produit. Un autre exemple est un trimestre où un cours LOG711 ne se donne pas (il n’y a pas de GroupeCours de LOG711 dans le trimestre actuel). Alors, une classe Cours (qui joue le rôle de description) sert pour spécifier le nombre de crédits, les cours préalables, etc.
  • La suppression d’instances de la classe « X » entraîne la perte de l’information qui doit être mémorisée, mais qui a été incorrectement associée à l’entité en question.
  • La classe de description réduit la duplication des informations.

La figure 4.3 présente une classe de description pour le contexte de cours et de groupe-cours.

GroupeCoursnuméro : inttrimestre : Trimestre...Coursnom : TextenbCrédits : int...CatalogueCoursClasse de « description ». Une instance de Cours peut existerindépendamment de l'existence d'un GroupeCours qu'elle décrit(par exemple, avant qu'un cours soit donné la première fois).Elle réduit également la duplication des informations (le nom etle nombre de crédits ne sont pas stockés dans chaque GroupeCours).Décrit1*Est-préalable-à1*Répertorie1*

Figure 4.3: La classe Cours joue le rôle de description d’entités (les groupes-cours). (PlantUML)

Avertissement

Attention de ne pas faire l’erreur naïve d’utiliser une classe de description simplement pour « décrire » une autre classe. Voir la figure 4.4 pour un exemple.

ClientDescriptionClientnom : Texteidentifiant : IDClient...CatalogueClientsMauvaise classe de « description ». Il n'est pas nécessaired'avoir cette classe, car les clients sont décrits dans leurpropre classe Client. Si un client n'existe pas, il n'a pas desens dans le MDD. Les informations ne seraient pas dupliquéess'il n'y avait pas cette classe (chaque client a un nom et unidentifiant unique).Décrit11Répertorie1*

Figure 4.4: Illustration d’une erreur fréquente : utiliser une classe de description sans justification. (PlantUML)

4.7 Classes d’association

Les classes d’association dans un MDD sont le sujet de la section F26.10/A31.10 .

Une classe d’association permet de traiter une association comme une classe et de la modéliser avec des attributs.

Il pourrait être utile d’avoir une classe d’association dans un MDD :

  • si un attribut est lié à une association ;
  • si la durée de vie des instances de la classe d’association dépend de l’association ;
  • s’il y a une association N-N entre deux concepts et des informations liées à l’association elle-même.

L’exemple illustré sur la figure 4.5 explique la nécessité d’une classe d’association Occupation. Lorsqu’un Joueur contrôle un Pays, il doit déployer des armées dans ce dernier. Le MDD pourrait avoir un attribut nbRégiments dans la classe Pays. Cependant, l’attribut nbRégiments est lié à l’association entre le Joueur et le Pays qu’il contrôle, alors on décide d’utiliser une classe d’association.

Si un Joueur envahit un Pays, la nouvelle instance de la classe d’association Occupation sera créée (avec la nouvelle association). Pourtant, cette instance d’Occupation sera détruite si un autre Joueur arrive à prendre le contrôle du Pays. Alors, la durée de vie de cette instance dépend de l’association.

Voir le livre de Larman (2005) pour plus d’exemples.

Joueurnom : String/nbPaysOccupés : intPaysnom : StringOccupationnbRégiments : intContrôle11..*

Figure 4.5: Classe d’association dans le MDD Jeu Risk. (PlantUML)

4.8 Affinement du MDD

Lorsqu’on modélise un domaine, il est normal de commencer par un modèle simple (à partir d’un ou de deux cas d’utilisation) et ensuite de l’affiner dans les itérations suivantes, où l’on y intègre d’autres éléments plus subtils ou complexes du problème qu’on étudie. Les détails de cette approche sont présentés dans le chapitre F26/A31 . Bien que la matière soit présentée plus tard dans le livre, ce sont des choses à savoir pour la modélisation d’un domaine, même dans une première itération.

Voici un résumé des points importants traités dans ce chapitre, dont quelques-uns ont déjà été présentés plus haut :

  • Composition, par exemple la classe Continent qui groupe les Pays sur la figure 4.2. Larman propose d’utiliser la composition lorsque :
    • la durée de vie du composant est limitée à celle du composite (lorsqu’un objet Continent est instancié, ça doit grouper des instances de Pays pour être cohérent), il existe une dépendance création-suppression de la partie avec le tout (ça ne fait pas de sens de supprimer un objet Pays d’une instance de Continent dans le jeu Risk) ;
    • il existe un assemblage logique ou physique évident entre le tout et les parties (on ne peut construire un Continent sans les Pays) ;
    • certaines propriétés du composite, comme son emplacement, s’étendent aux composants ;
    • les opérations que l’on peut appliquer au composite, telles que destruction, déplacement et enregistrement, se propagent aux composants.
  • Généralisation/spécialisation (voir Larman, 2005 pour les exemples et les directives), notamment la règle des 100 % (conformité à la définition) et la règle « est-un » (appartenance à l’ensemble).
  • Attribut dérivé, par exemple, /nbPaysOccupés dans la classe Joueur est un attribut dérivé de l’association entre Joueur et Pays (figure 4.1).
  • Hiérarchies dans un MDD et héritage dans l’implémentation.
  • Noms de rôles.
  • Organisation des classes conceptuelles en packages (surtout lorsque le MDD contient un nombre important de classes conceptuelles).

4.9 FAQ MDD

4.9.1 Y a-t-il un MDD pour chaque cas d’utilisation ?

Selon la méthodologie de ce manuel, bien qu’une application ait souvent plusieurs fonctionnalités (cas d’utilisation), il n’y a qu’un seul MDD.

Cela dit, le MDD est comme un fichier de code source, puisque sa version peut évoluer avec le projet. Le MDD évoluera normalement après chaque itération, car on fait une nouvelle analyse pour les nouvelles fonctionnalités visées dans l’itération. Au début du projet, le MDD est plus simple, puisqu’il porte sur seulement les cas d’utilisation ciblés à la première itération. Le MDD devient plus riche au fur et à mesure qu’on avance dans les itérations, parce qu’il modélise davantage de concepts reliés aux problèmes traités par les nouvelles fonctionnalités à réaliser.

Par exemple, la version initiale du MDD (chapitre 9 ) ne traite pas la fonctionnalité de paiement par carte de crédit. Les classes conceptuelles modélisant la problématique de paiement par carte de crédit sont absentes dans le MDD initial. Plus tard (après plusieurs itérations, dans le chapitre sur le raffinement du MDD), on voit un MDD beaucoup plus riche qui reflète la modélisation des concepts reliés à des fonctionnalités comme les paiements par carte de crédit, les demandes d’autorisation de paiement, etc.

4.9.2 Un modèle du domaine est-il la même chose qu’un modèle de données ?

Voici la réponse de Craig Larman (2005) dans la section 9.2  :

Un modèle du domaine n’est pas un modèle de données ([ce dernier] représente par définition des objets persistants stockés quelque part).

Il peut y avoir des concepts dans un domaine qui ne sont pas dans la base de données. Considérez l’exemple de la carte de crédit utilisée pour payer, mais qui n’est jamais stockée pour des raisons de sécurité. Avec seulement un modèle de données, cette classe conceptuelle ne serait jamais modélisée. Larman précise :

N’excluez donc pas une classe simplement parce que les spécifications n’indiquent pas un besoin évident de mémoriser les informations la concernant (un critère courant pour la modélisation des données quand on conçoit des bases de données relationnelles, mais qui n’a pas cours en modélisation d’un domaine), ou parce que la classe conceptuelle ne possède pas d’attributs. Il est légal d’avoir une classe conceptuelle sans attribut, ou une classe conceptuelle qui joue un rôle exclusivement comportemental dans le domaine.

Vous pouvez aussi lire cette question .

4.10 Exercices

Exercice 4.1 (Trouver des classes conceptuelles par catégorie) À partir du cas d’utilisation Réserver un livre de la bibliothèque, trouvez des classes conceptuelles candidates en utilisant une liste de catégories de classes. Vous pouvez remplir un tableau comme ceci :

Catégorie de classes conceptuelles Classes candidates selon le cas d’utilisation
Transaction d’affaires (métier) Réservation (Ceci est un exemple.)
(Continuez avec d’autres catégories.)
(Certaines catégories ne s’appliqueront pas.)
(Certaines classes candidates seront découvertes par plusieurs catégories.)

Exercice 4.2 (Classes conceptuelles trouvées à l’aide de groupes nominaux) Cette fois-ci, utilisez les groupes nominaux pour trouver des classes conceptuelles candidates. Commencez par souligner ou par mettre en surbrillance les noms et les groupes nominaux dans le cas d’utilisation Réserver un livre de la bibliothèque. Les groupes nominaux peuvent être des classes ou des attributs, ou peuvent ne pas s’appliquer du tout. Faites une liste de classes conceptuelles candidates (sans doublons).

Exercice 4.3 (Comparaison des approches) Comparez la liste des classes trouvées dans l’Exercice 4.2 avec les classes trouvées dans l’Exercice 4.1. Quelles sont les différences ?

Note

Vous pouvez dessiner les diagrammes à la main et en prendre une photo avec une application comme Microsoft Lens (Android, iOS).

Vous pouvez également utiliser PlantUML. Voici des ressources à ce propos :

Méfiez-vous des outils comme Lucidchart ayant seulement des profils superficiels (sans règles) pour l’UML. Voir la figure 13.5 pour plus de détails.

Exercice 4.4 (Diagramme de classes conceptuelles) À partir du cas d’utilisation Réserver un livre de la bibliothèque, esquissez le modèle du domaine correspondant au domaine de l’application (cela comprend des classes, des attributs et des associations).

  1. Considérez les classes candidates provenant de l’Exercice 4.1 et de l’Exercice 4.2.
  2. Notez que les classes candidates dénichées ne sont pas toujours importantes. Certains concepts sont des attributs. D’autres (surtout avec l’approche linguistique) n’ont rien à voir avec le problème du domaine. Vous devez appliquer les directives vues dans le chapitre 9 .
  3. Faites attention à bien modéliser la classe de « description » dans ce problème.
  4. Tout attribut doit avoir un type.
  5. Limitez-vous à des associations « mémorisables » dans le contexte de l’application du logiciel (ne pas faire des associations hors de la portée du cas d’utilisation).
  6. Vérifiez les cardinalités.
  7. Vérifiez les verbes sur les associations ainsi que le sens de lecture.

Exercice 4.5 (Création du MDD du logiciel Discord par rétro-ingénierie) Par rétro-ingénierie, réalisez le modèle du domaine pour une fonctionnalité du logiciel Discord.

  1. Connectez-vous au logiciel Discord. Si vous n’avez pas de compte Discord, vous pouvez en créer un temporairement. Sur le site web de Discord, cliquez sur « Ouvrir Discord dans ton navigateur ».
  2. Dans l’application Discord, créez un nouveau serveur et envoyez un message qui contient un fichier et du texte dans un salon textuel.
  3. À l’aide de la liste de catégories de classes conceptuelles, proposez les classes conceptuelles qui sont nécessaires pour réaliser la fonctionnalité de l’étape précédente.
Catégorie Classes conceptuelles
Transactions d’affaires Message
Rôle des personnes liées à la transaction Utilisateur
Lieu de la transaction, lieu du service Salon textuel, Salon
Conteneurs Serveur, Profil, Fichier
  1. Proposez les attributs de chaque classe conceptuelle qui sont nécessaires pour réaliser la fonctionnalité.

Voici une solution possible qui est cohérente avec l’étape précédente :

Messagecontenu : Stringhorodatage : DateHeureUtilisateurcourriel : StringnomUtilisateur : StringnomAffichage : StringSalonnom : StringSalonTextuelsujet : StringServeurnom : StringProfilavatar : FileFichierurl : String

Figure 4.6: Attributs des classes conceptuelles proposées dans l’exercice. (PlantUML)

  1. Proposez les associations entre les classes conceptuelles ainsi que leurs cardinalités.

Voici une solution possible qui est cohérente avec l’étape précédente :

Utilisateurcourriel : StringnomUtilisateur : StringnomAffichage : StringMessagecontenu : Stringhorodatage : DateHeureSalonTextuelsujet : StringProfilavatar : FileServeurnom : StringFichierurl : StringSalonnom : StringRédige1*Publie1*Représente11Est-membre-de1..**Est-propriétaire-de1*Héberge1*Est-joint-à1*Est-membre-de1..**

Figure 4.7: Associations et cardinalités des classes conceptuelles proposées dans l’exercice. (PlantUML)

Exercice 4.6 (Utiliser des verbes plus riches pour décrire les associations) La figure 4.8 présente une modèle du domaine partiel pour le logiciel YouTube. Toutefois, les associations du MDD utilisent des verbes ternes qui n’aident pas à comprendre le domaine. Remplacez les verbes des associations par des verbes plus riches. Vous pouvez inverser le sens des associations.

UtilisateurnomUtilisateur : Stringcourriel : StringChaînedescription : StringVidéotitre : Stringdescription : Stringurl : StringListeDeLecturenom : Stringdescription : Stringvisibilite : StringSousTitrelangue : StringStatistiquevisionnements : intdureeVisionnement : floatimpressions : intPossède1*Contient1*Possède1*Contient**A1*Possède11

Figure 4.8: Modèle du domaine partiel pour le logiciel YouTube. (PlantUML)

UtilisateurnomUtilisateur : Stringcourriel : StringChaînedescription : StringVidéotitre : Stringdescription : Stringurl : StringListeDeLecturenom : Stringdescription : Stringvisibilite : StringSousTitrelangue : StringStatistiquevisionnements : intdureeVisionnement : floatimpressions : intGère1*Publie1*Administre1*Enregistre**Est-plus-accessible-avec1*Mesure-visualisation-de11

Figure 4.9: Modèle du domaine partiel pour le logiciel YouTube avec des verbes d’association plus riches. (PlantUML)