Un guide complet sur la modélisation CRC (Class Responsibility Collaborator)

Basé sur les principes fondamentaux de l’analyse orientée objet (OO), ce guide décrit le processus de modélisation CRC. La modélisation CRC est une méthode très efficace, à faible technicité, conçue pour combler le fossé de communication entre les développeurs et les utilisateurs, en s’assurant que les exigences métiers sont correctement identifiées et comprises avant d’écrire du code.

---

1. Concepts clés : L’anatomie d’une carte CRC

La modélisation CRC repose sur des cartes à index standard divisées en trois sections distinctes. Chaque section représente un concept fondamental de la conception orientée objet.

A. Classe (partie supérieure de la carte)

Une classe représente une collection d’objets similaires. Un objet peut être une personne, un lieu, une chose, un événement, un concept, un écran ou un rapport pertinent pour le système.

• Règle de nommage : Utilisez un ou deux mots au singulier (par exemple, Client, pas Clients).

• Exemple : Dans un système d’expédition/inventaire, les classes incluent Article d’inventaire, Commande, Article de commande, Client, et Adresse de surface.

B. Responsabilité (colonne de gauche)

Une responsabilité est tout ce qu’une classe connaît ou fait.

• Ce qu’il connaît (Données/Attributs) : Exemple : Un Client la classe connaît son nom, son numéro de client et son numéro de téléphone.

• Ce qu’il fait (Comportements/Méthodes) : Exemple : Un Client la classe peut passer des commandes, annuler des commandes et effectuer des paiements.

C. Collaborateur (Colonne de droite)

La collaboration a lieu lorsque une classe a besoin d’informations ou d’aide d’une autre classe pour remplir une responsabilité.

• Exemple : Un Commande un objet a la responsabilité de « calculer le total ». Cependant, il ne connaît pas le prix des articles ni la quantité commandée. Par conséquent, il doit collaborer avec Article de commande (qui connaît la quantité) et Article de stock (qui connaît le prix) pour calculer le total final.

---

2. L’équipe de modélisation CRC

Une session CRC réussie nécessite des rôles spécifiques pour garantir que le processus se déroule sans accroc et capte précisément la logique métier.

1. Experts du domaine métier (EDM) : Les utilisateurs réels du système (généralement 4 à 5 agents de terrain). Ils détiennent les connaissances quotidiennes du métier. Remarque : Les cadres supérieurs ne sont généralement pas idéaux pour les CRC ; ils sont mieux adaptés aux cas d’utilisation de haut niveau.

2. Animateur : Anime la session, explique la technique, pose des questions pertinentes, s’assure que les cartes sont correctement remplies et dirige les tests de scénarios.

3. Rédacteur(s) :1 ou 2 personnes qui s’assoient à l’arrière ou sur les côtés. Elles ne participent pas activement à la modélisation mais enregistrent la logique métier détaillée et les règles qui ne peuvent pas tenir sur les petites fiches.

4. Observateurs :Apprentis ou parties prenantes qui s’assoient à l’arrière et observent sans participer.

---

3. Le processus de modélisation CRC en 6 étapes

Étape 1 : Rassembler l’équipe

Réunissez 4 à 5 BDE de première ligne, un facilitateur et 1 à 2 secrétaires. Assurez-vous du soutien de la direction afin que les participants puissent consacrer le temps nécessaire.

Étape 2 : Organiser la pièce

• Surfaces à écrire :Tableaux blancs ou tableaux de brainstorming pour le cahier des charges et la conception rapide.

• Table de modélisation :Une grande table centrale pour que les BDE puissent poser et déplacer les fiches.

• Postes de secrétaires :Des bureaux placés à l’écart mais avec une vue claire.

• Fournitures :Fiches, marqueurs et uneboule souple et élastique(utilisée plus tard pour le test de scénarios).

Étape 3 : Cerveau-attaque

Générez des idées sans les évaluer. Le facilitateur pose des questions ouvertes pour comprendre les besoins métiers.

• Questions d’exemple :« Pour qui est conçu ce système ? », « Quels besoins métiers soutient-il ? », « Comment pouvons-nous faire cela plus vite/plus économiquement/mieux ? », « Y a-t-il des tâches simples que nous pourrions automatiser ? »

Étape 4 : Expliquer la technique

Le facilitateur passe 10 à 15 minutes à expliquer les concepts CRC, en affichant clairement les définitions sur les murs, et en guidant l’équipe dans la création de quelques cartes d’exemple.

Étape 5 : Modélisation CRC itérative

Les BDE se tiennent debout ou s’assoient autour de la table et construisent itérativement le modèle :

• Trouver les classes :Suivez l’argent, cherchez les rapports/écrans, et identifiez immédiatement les 3 à 5 classes principales.

• Trouver les responsabilités :Demandez ce que la classe connaît et fait.

• Définir les collaborateurs :Identifiez qui détient les informations manquantes nécessaires pour remplir une responsabilité.

• Organisez les cartes : Étape cruciale.Les cartes qui collaborent fréquemment sont placées près les unes des autres sur la table. Les cartes « occupées » sont au centre. Déplacer physiquement les cartes aide l’équipe à visualiser les relations et les associations.

Étape 6 : Test des scénarios d’utilisation (l’exercice du « lancer de balle »)

Il s’agit d’un exercice de validation où l’équipe « joue » les flux du système pour s’assurer que le modèle est exact.

1. Appelez un scénario :Le facilitateur décrit un cas d’utilisation (par exemple, « Le client passe une commande ») et lance la balle molle au BDE tenant la carte initiale de responsabilité (par exemple, Commande).

2. Déterminez la responsabilité :Le groupe confirme que la carte gère la tâche. Sinon, ils mettent à jour ou créent une nouvelle carte.

3. Décrivez la logique :Le BDE tenant la balle décrit la logique métier étape par étape (code pseudo) au sténographe.

4. Collaborez :Si le BDE a besoin d’informations d’une autre classe (par exemple, Article de stock), il lance la balle au BDE tenant cette carte. Ce dernier décrit alors sa partie de la logique.

5. Renvoyez la balle :Une fois une tâche terminée, la balle est renvoyée à la personne précédente, revenant finalement au facilitateur pour commencer le prochain scénario.

---

4. Comment le CRC s’intègre dans le cycle de vie du développement logiciel

La modélisation CRC n’existe pas en vase clos ; elle fait partie d’un processus de modélisation orientée objet plus large qui est séquentiel à grande échelle (passant des exigences à la conception au code) et itératif à petite échelle (allant et venant entre les modèles).

• Niveau de détail :Le CRC se situe au milieu. Vous commencez simplement avec Cas d’utilisation et Prototypes d’interface utilisateur, passez au détail moyen de Modèles CRC, puis terminez par le détail élevé de Diagrammes de classes.

• Les livrables pilotent les livrables :Les diagrammes de cas d’utilisation sont documentés par des cas d’utilisation, qui sont documentés par des diagrammes de séquence, qui conduisent finalement au code source. Les modèles CRC alimentent directement le diagrammage de classes.

---

5. Meilleures pratiques et astuces pour réussir

1. Envoyez un ordre du jour : Distribuez un ordre du jour quelques jours à l’avance afin que les BDE puissent se préparer.

2. Affichez les définitions : Fixez un grand schéma de carte CRC et ses définitions à l’avant de la salle.

3. Utilisez le vocabulaire du domaine : Évitez le jargon technique ; utilisez les mots exacts que les BDE utilisent dans leur travail quotidien.

4. Restez basique : Les outils pour les CRC sont facultatifs. Les cartes à index sont peu coûteuses, pratiques et très efficaces.

5. Prévoyez de prototyper : Faire des croquis d’écrans et de rapports sur des tableaux pendant la session aide les utilisateurs à visualiser le système.

6. Prévoyez plusieurs jours : Les grands systèmes nécessitent plusieurs séances. C’est normal et nécessaire.

7. Obtenez le soutien de la direction : Assurez-vous que la direction comprend la valeur de la modélisation avant la programmation.

8. Ciblez le personnel de terrain : Le CRC est très détaillé et fonctionne le mieux avec les utilisateurs quotidiens, et non avec les cadres supérieurs.

---

6. Avantages et inconvénients

Les avantages

• Les experts réalisent l’analyse : Les personnes qui effectuent réellement le travail construisent le modèle.

• Fort engagement des utilisateurs :Une participation active augmente la satisfaction des utilisateurs et leur sentiment de propriété.

• Fait tomber les barrières :Les utilisateurs et les développeurs travaillent côte à côte.

• Simple et non menaçant :Ce ne sont que des fiches. Les utilisateurs ne sont pas intimidés par des outils logiciels complexes, et ils ne ressentent pas que leurs emplois sont automatisés par une « machine ».

• Peu coûteux et portable :Coûte quelques dollars et tient dans une mallette.

• Transition fluide :S’associe parfaitement à la conception de maquettes et conduit directement aux diagrammes de classes formels.

Les inconvénients

• Menaçant pour certains développeurs :Certains développeurs croient à tort que leurs connaissances techniques dépassent celles des utilisateurs en matière de métier.

• La planification est difficile :Réunir 4 à 5 utilisateurs clés dans la même pièce en même temps nécessite une planification à l’avance.

• Les fiches sont limitées :Une pile de fiches n’est pas un livrable formel acceptable pour la plupart des organisations. Le modèle CRC doit être complété par des cas d’utilisation formels, des maquettes et des diagrammes de classes.

---

Conclusion

Le but ultime du développement d’applications est derésoudre des problèmes métiers, et non pas de satisfaire la curiosité intellectuelle d’un développeur avec de nouvelles technologies. Le modèle CRC oblige les développeurs à travailleravecles utilisateurs plutôt que contre eux. En utilisant un environnement basique et fortement collaboratif, les équipes peuvent capturer, valider et affiner avec précision les exigences métiers avant même d’écrire une seule ligne de code.