Comment élaborer une conception en utilisant des cartes CRC?
Je me suis toujours demandé comment les gens utilisent les cartes CRC (class responsiblity collaboration). J'ai lu à leur sujet dans des livres, trouvé des informations vagues sur internet, mais je ne l'ai jamais vraiment saisi. Je pense que quelqu'un devrait faire une vidéo youtube montrant une session avec des cartes CRC, car un de mes livres l'a décrite comme très difficile à formuler dans le texte, qu'elle devrait être "enseignée par quelqu'un qui la maîtrise déjà". Malheureusement, je ne connais personne ici qui utilise des cartes CRC et j'aimerais apprendre plus.
Mettre à jour
Tout lien vers des vidéos montrant des personnes travaillant avec cette technique serait apprécié.
6 réponses
Je vais essayer de donner une réponse. Donc, les cartes CRC sont généralement utilisées pour la modélisation dans un environnement orienté objet pour mieux comprendre le système qui doit être développé (mais je pense que vous le saurez déjà). Cartes CRC viennent à la toute fin, quand vous arrivez juste avant la mise en œuvre réelle. Les différentes étapes pour atteindre ce niveau pourraient être les suivantes:
- le point de départ est de faire l'élicitation d'exigence. Impliquer le client tôt et en continu est suggéré ici (jetez un oeil aux approches agiles, C'est-à-dire à la programmation extrême)
- les exigences peuvent ensuite être modélisées soit avec des diagrammes de cas D'utilisation (UML), soit avec des user stories (agile extreme programming approach). Le problème clé ici est de trouver les bons objets impliqués. Cela dépend beaucoup du domaine dans lequel vous êtes, bien sûr. Si vous allez de la manière "dure" , vous pouvez appliquer des techniques comme "extraction de nom". Vous analysez donc le document de spécification et extrayez tous les noms (y compris composite des noms et des personnes avec des adjectifs). Analysez-les tous et jetez-les non pertinents.
- Une fois que vous avez les bons noms - > objets, vous pouvez commencer à créer vos cartes CRC. Alors, que fait-on lors d'une session du CRC? La tâche principale est de trouver et d'attribuer les responsabilités de vos objets (précédemment) trouvés qui sont ensuite déposés sur de petites fiches (nos cartes CRC). Les "responsabilités" sont principalement les fonctionnalités de base d'un objet spécifique et la partie "collaboration" sont les autres objets nécessaires pour remplir certaines fonctionnalités (ce sont les dépendances entre les différents objets de votre modèle). Les points importants pour l'attribution des responsabilités sont que les responsabilités sont bien réparties sur l'ensemble du système d'une manière équilibrée. Un autre point très important est d'éviter toute duplication des responsabilités entre les objets (c'est là que les cartes CRC aident).
une session du CRC devrait commencer par une réunion de remue-méninges, ayant une discussion active entre les les développeurs et il devrait être effectué sur les fiches réelles directement.
J'espère que j'ai pu en quelque sorte vous aider.
Cordialement,
Juri
Il est difficile de résumer dans une réponse SO, mais je vais essayer. L'un des défis de la conception d'objets est d'équilibrer la pensée d'un point de vue global avec la pensée du point de vue d'un objet individuel. Vous avez besoin de la perspective globale pour terminer le calcul, mais vous avez besoin de la perspective d'objet individuel pour subdiviser efficacement la logique et les données.
Le maintien de cet équilibre est l'endroit où les cartes CRC entrent en jeu. Quand ils sont assis là sur la table, vous obtenez de regarder le calcul dans son ensemble. Quand vous prenez une seule carte, cependant, vous êtes physiquement, kinesthétiquement encouragé à prendre le point de vue de cet objet-j'ai ce petit morceau de ce calcul à voir avec des ressources limitées, comment vais-je l'accomplir?
Au fil du temps, la capacité de tenir simultanément les deux perspectives semble s'imprégner dans le cerveau. De moins en moins est écrit sur les cartes. Puis les cartes sont vides. Après un certain temps les gens indiquent simplement où la carte serait être s'ils prennent la peine de prendre un blanc de la pile. Finalement, les gens ont les avantages du style de pensée sans avoir besoin de cartes du tout. Lorsque vous parlez avec quelqu'un qui n'a pas maîtrisé l'équilibre, retirer des cartes réelles peut être une aide à la communication utile, cependant.
La plus grande faiblesse que je trouve avec les cartes est le manque de rétroaction. Vous pouvez vous tromper sur la façon dont le code va tourner. Je suggère d'utiliser des cartes seulement jusqu'à ce qu'une question intéressante se pose, se tourner vers tests / code pour confirmation, puis reprendre la conception.
Ward et moi avons fait une vidéo il y a environ 15 ans d'une session de design, mais je ne la trouve nulle part en ligne et je n'ai pas de copie. Je ne suis pas sûr que ce serait utile comme outil d'enseignement dans tous les cas. Je ne connais pas d'autres vidéos, mais elles pourraient être intéressantes, surtout si vous devez comparer plusieurs styles de designers différents.
Aller la source - Kent Beck, Ward Cunningham, jamais entendu parler d'eux?
Je pense que votre déclaration "Je ne connais personne ici qui utilise des cartes CRC" résume à peu près l'état des cartes CRC en développement. Les cartes CRC, à mon avis, étaient une étape sur la route du développement traditionnel axé sur le plan au développement agile. Le monde a évolué. Au lieu de me concentrer sur l'utilisation des cartes CRC, j'étudierais des techniques comme TDD , qui peuvent utiliser des techniques comme les cartes UML et CRC comme artefacts intermédiaires mais qui se concentrent sur le code, et plus particulièrement sur les tests. C'est la direction que les inventeurs de cartes CRC ont pris et je vous recommande de prendre aussi.
La façon la plus simple de les utiliser à mon avis sans entrer dans un désordre est d'écrire de petites cartes CRC dans vos en-têtes de fichier comme ceci:
///////////////////////
//* CRC CARD
//* Class: UISliderEvent
//* Responsability: Event that holds the value and id of a Slider's movement
//* Collaborators: UISlider, UIEvent
//////////////////////
Ensuite, chaque fois que vous devez ajouter une fonctionnalité, vérifiez votre carte et assurez-vous de ne pas casser les contrats que vous y avez indiqués. Comme tout d'un coup en fonction de UIMouseEvent par exemple, ce n'est nulle part sur la carte, donc c'est un non-non pour l'inclure.
Dans leur livre Object Design: roles, responsibilities, and collaborations publié en 2003 Rebecca Wirfs-Brock et Alan McKean discutent des cartes CRC en détail. Ils soulignent vraiment la différence que cela fait à l'ensemble de la procédure que cela devrait être une expérience très tactile et cela détend la pensée des gens de passer autour d'un objet physique en essayant d'étoffer un design / exigence.
Le sous-titre de ce chapitre suggère que l'utilisation des cartes est un une partie de la phase de "conception exploratoire", donc cela vient probablement avant de faire beaucoup de codage, mais je ne vois aucune raison pour que vous ne continuiez pas à y revenir à chaque itération D'un projet Agile et à vous rappeler où vous pensiez aller et revoir cela si nécessaire (en tant que groupe bien sûr).
Je semble me rappeler qu'ils suggèrent même de passer une balle dans la pièce pour que seule la personne qui a la balle soit autorisée à parler, alors peut-être que ce n'est pas tant les cartes CRC que l'obtention tout le monde dans une pièce parle des rôles et des responsabilités des objets qui comptent?
Si vous souhaitez lire une étude de cas de cartes CRC en action (en plus de L'article original de Kent et Ward bien sûr), jetez un oeil à Le Livre de cartes CRC.