Les MDD sont expliqués en détail dans le chapitre 9 , mais voici des points importants :
- Les classes conceptuelles ne sont pas des classes logicielles. Ainsi, selon la méthodologie de Larman, elles n’ont pas de méthodes.
- Les classes ont des noms commençant avec une lettre majuscule, par exemple
Joueur, et elles ne sont jamais au pluriel ; par exemple, une classe ne peut pas prendre le nomJoueurs
4.1 Classes conceptuelles
Il y a trois stratégies pour identifier les classes conceptuelles :
- Réutiliser ou modifier des modèles existants.
- Utiliser une liste de catégories.
- Identifier des groupes nominaux.
4.1.1 Catégories pour identifier des classes conceptuelles
| 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, Dé, 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
Paysn’a pas un attributjoueur:Joueur(qui contrôle le Pays) ; elle a plutôt une association avec la classeJoueuret un verbecontrô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
JoueuretPays, car il est important de savoir quel joueur contrôle quel pays dans le jeu Risk. - Il n’y a pas d’association entre
JeuRisketAttaque, 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 existe une association entre
- 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.
| 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.
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 Dé, 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.
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.
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.
4.7 Classes d’association
Les classes d’association dans un MDD sont le sujet de la section F26.10/A31.10 .
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.
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ésdans 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 :
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 :
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 ?
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 :
- tutoriel VS Code sur YouTube
- extension PlantUML pour VS Code ;
- PlantUML Gizmo, module supplémentaire Google Docs ;
- PlantText.com.
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).
- Considérez les classes candidates provenant de l’Exercice 4.1 et de l’Exercice 4.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 .
- Faites attention à bien modéliser la classe de « description » dans ce problème.
- Tout attribut doit avoir un type.
- 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).
- Vérifiez les cardinalités.
- 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.
- 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 ».
- Dans l’application Discord, créez un nouveau serveur et envoyez un message qui contient un fichier et du texte dans un salon textuel.
- À 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.
- Proposez les attributs de chaque classe conceptuelle qui sont nécessaires pour réaliser la fonctionnalité.
- Proposez les associations entre les classes conceptuelles ainsi que leurs cardinalités.
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.