Question

Je me suis toujours demandé comment les gens utilisent les cartes CRC (collaboration de responsabilité de classe). J'ai lu des ouvrages à ce sujet dans des livres, j'ai trouvé de vagues informations sur Internet, mais je ne les ai jamais vraiment comprises. Je pense que quelqu'un devrait faire une vidéo youtube montrant une session avec des cartes CRC, puisqu'un de mes livres l'a décrite comme étant très difficile à formuler dans un texte, qu'elle devrait être "enseignée par quelqu'un qui la maîtrise déjà". Malheureusement, je ne connais personne ici qui utilise les cartes CRC et j'aimerais en savoir plus.

UPDATE

Tous les liens vers des vidéos montrant des personnes développant cette technique seraient appréciés.

Était-ce utile?

La solution

Je vais essayer de donner une réponse. Les cartes CRC sont donc généralement utilisées pour la modélisation dans un environnement orienté objet afin de mieux comprendre le système à développer (mais je pense que vous le saurez déjà). Les cartes CRC arrivent à la toute fin, lorsque vous arrivez juste avant la mise en œuvre effective. Les différentes étapes pour atteindre ce niveau pourraient être les suivantes:

  1. Le point de départ est de déterminer les besoins. Nous vous suggérons d’impliquer le client tôt et de manière continue (jetez un coup d’œil aux approches agiles, c’est-à-dire à la programmation extrême)
  2. Les exigences peuvent ensuite être modélisées soit avec des diagrammes de cas d’utilisation (UML), soit avec des user stories (approche de programmation extrême agile). Le problème clé ici est de trouver les bons objets impliqués. Cela dépend bien entendu du domaine dans lequel vous vous trouvez. Si vous allez le "dur" & Ainsi, vous pouvez appliquer des techniques telles que "extraction de noms". Vous analysez donc le document de spécification et extrayez tous les noms (y compris les noms composites et ceux avec des adjectifs). Analysez-les tous et éliminez ceux qui ne sont pas pertinents.
  3. Une fois que vous avez les bons noms - > objets que vous pouvez commencer à créer vos cartes CRC. Alors, que fait-on dans 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 inscrites sur de petites fiches (nos cartes CRC). "Responsabilités" sont principalement les fonctionnalités de base d’un objet spécifique et de la "collaboration". partie 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 est que les responsabilités sont bien réparties dans l'ensemble du système de manière équilibrée. Un autre point très important consiste à éviter toute duplication de responsabilités entre les objets (c’est là que les cartes CRC aident).
    Une session du CRC doit commencer par une séance de brainstorming, une discussion active entre les développeurs et une discussion à réaliser. les fiches réelles directement.

J'espère que j'ai pu vous aider d'une manière ou d'une autre.

Cordialement,
Juri

Autres conseils

Il est difficile de résumer une telle réponse, mais je vais essayer. L'un des défis de la conception d'objets consiste à é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. Lorsqu'elles sont assises sur la table, vous devez regarder le calcul dans son ensemble. Quand vous prenez une seule carte, cependant, vous êtes physiquement, kinesthésiquement encouragé à prendre le point de vue de cet objet - j'ai ce petit morceau de ce calcul à faire 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. Ensuite, les cartes sont vierges. Après un certain temps, les gens indiquent simplement où se trouverait la carte s'ils voulaient en prendre une vierge de la pile. Finalement, les gens bénéficient du style de pensée sans avoir besoin de cartes. Lorsque vous parlez à quelqu'un qui ne maîtrise pas bien l'équilibre, il peut être utile de sortir des cartes réelles.

La plus grande faiblesse que je trouve avec les cartes est le manque de feedback. Vous pouvez vous tromper sur la façon dont le code va tourner. Je suggérerais d’utiliser les cartes uniquement jusqu’à ce qu’une question intéressante soit posée, puis de passer aux tests / au code pour confirmation, puis de reprendre la conception.

Ward et moi avons réalisé une vidéo d’une session de création il ya une quinzaine d’années, mais je ne la trouve en ligne nulle part et je n’en ai pas de copie. Je ne suis pas sûr que ce serait utile comme outil pédagogique 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 concepteurs.

aller à la source - Kent Beck, Ward Cunningham, en a-t-il déjà entendu parler?

Je pense que votre déclaration "Je ne connais personne ici qui utilise des cartes CRC" résume assez bien l'état des cartes CRC en développement. Les cartes CRC, à mon avis, ont été un pas en avant entre le développement traditionnel basé sur un plan et le développement agile. Le monde a évolué. Au lieu de me concentrer sur l'utilisation des cartes CRC, j'étudierais des techniques telles que TDD , qui peut utiliser des techniques telles que les cartes UML et CRC comme artefacts intermédiaires mais se concentrant sur le code, et plus particulièrement sur les tests. C’est la direction que les inventeurs des cartes CRC ont prise et je vous recommande de suivre également.

La meilleure façon de les utiliser, à mon avis, sans se fourvoyer, est d'écrire de petites cartes CRC dans les 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 aurez besoin d'ajouter une fonctionnalité, vérifiez votre carte et assurez-vous de ne pas rompre les contrats que vous avez indiqués. Comme tout à coup, selon UIMouseEvent par exemple, il n’ya nulle part sur la carte, c’est donc un non-non à l’inclure.

Dans leur livre Conception d’objet: rôles, responsabilités et collaborations publiée en 2003 Rebecca Wirfs-Brock & amp; Alan McKean discute des cartes CRC en détail. Ils soulignent vraiment la différence que cela fait dans toute la procédure que ce soit une expérience très tactile et que cela affaiblisse la pensée des gens de passer autour d’un objet physique en essayant d’étoffer un design / une exigence.

Le sous-titre de ce chapitre suggère que l’utilisation des cartes fait partie de la phase de "conception exploratoire", elle intervient donc probablement avant de beaucoup coder, mais je ne vois aucune raison pour que vous ne reveniez pas là-dedans chaque itération d’un projet Agile et en vous rappelant où vous pensiez aller et en révisant le cas échéant (en groupe bien sûr).

Il semble que je me souvienne qu'ils suggèrent même de passer une balle dans la pièce pour que seule la personne qui a la balle puisse parler, alors peut-être que ce n'est pas tant les cartes CRC que de faire en sorte que tout le monde parle de rôles et les responsabilités des objets qui comptent?

Si vous souhaitez lire une étude de cas sur les cartes CRC en action (en plus du document original de Kent et Ward, bien sûr), consultez Le livre de cartes CRC .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top