Как разработать дизайн с использованием CRC-карт?

Мне всегда было интересно, как люди используют карты CRC (class responsiblity collaboration). Я читал о них в книгах, нашел неясную информацию в Интернете, но так и не понял. Я думаю, что кто-то должен сделать видео с YouTube, показывающее сеанс с картами CRC, так как одна из моих книг описала это как очень сложную формулировку в тексте, что ее следует "обучать тому, кто ее уже овладевает". К сожалению, я не знаю никого, кто использует CRC-карты, и я хотел бы узнать больше.

UPDATE

Любые ссылки на видеоролики, показывающие людей, разрабатывающих эту технику, будут оценены.

+28
19 сент. '08 в 2:07
источник поделиться
6 ответов

Я постараюсь дать ответ. Таким образом, карты CRC обычно используются для моделирования в объектно-ориентированной среде, чтобы лучше понять систему, которая должна быть разработана (но я думаю, что вы уже знаете). Карты CRC приходят в самом конце, когда вы приедете непосредственно перед фактической реализацией. Различные шаги для достижения этого уровня могут быть следующими:

  • Отправной точкой является выполнение требования. Привлечение клиента рано и постоянно предлагается здесь (взгляните на подходы Agile, то есть на экстремальное программирование).
  • Затем требования могут быть смоделированы либо с использованием диаграмм Use Case (UML), либо с рассказами пользователей (гибкий подход к экстремальному программированию). Ключевая проблема здесь заключается в том, чтобы найти нужные объекты. Конечно, это зависит от того, в каком домене вы находитесь. Если вы перейдете к "жесткому" пути, вы можете применить такие методы, как "извлечение существительного". Таким образом, вы анализируете документ спецификации и извлекаете все существительные (включая составные имена и имена с прилагательными). Проанализируйте их все и отбросьте нерелевантные.
  • Как только у вас есть правильные существительные → объекты, вы можете начать создавать свои CRC-карты. Итак, что сделано на сессии CRC? Основная задача - найти и назначить обязанности ваших (ранее) найденных объектов, которые затем помещаются на небольшие карточные карты (наши карты CRC). "Обязанности" - это главным образом основные функции конкретного объекта, а часть "сотрудничества" - это необходимые другие объекты для выполнения определенных функций (это зависимости между различными объектами в вашей модели). Важные моменты для определения обязанностей - это то, что обязанности распределяются хорошо на всей системе каким-то сбалансированным образом. Еще один очень важный момент - избегать дублирования ответственности между объектами (это помогает картам CRC).
    Сессия CRC должна начинаться с встречи" мозгового штурма", активно обсуждаемой среди разработчиков, и ее следует выполнять непосредственно на фактических карточках.

Надеюсь, я смог как-то помочь вам.

С уважением,
Juri

+12
27 февр. '09 в 17:34
источник

Трудно суммировать в ответе SO, но я попробую. Одной из задач проектирования объектов является балансирование мышления с общей точки зрения с мышлением с точки зрения отдельного объекта. Вам нужна общая перспектива, чтобы завершить вычисление, но вам нужна индивидуальная перспектива для эффективного разделения логики и данных.

Поддержание этого баланса - это когда появляются карты CRC. Когда они сидят на столе, вы можете посмотреть на вычисления в целом. Однако, когда вы берете одну карту, вы физически, кинестетически поощряетесь взглянуть на этот объект - у меня есть эта небольшая часть этого вычисления, чтобы ограничить ресурсы, как я ее выполню?

Со временем способность одновременно удерживать обе перспективы, кажется, впитывается в мозг. Все меньше и меньше записывается на карточках. Затем карты пустые. Через некоторое время люди просто указывают, где будет карта, если они будут беспокоиться о том, чтобы взять пустую с стека. В конце концов, люди имеют преимущества стиля мышления, не требуя карточек. При разговоре с кем-то, кто не справился с балансом, вытаскивание карт с картами может быть полезной коммуникационной помощью.

Самая большая слабость, которую я нахожу в карточках, - отсутствие обратной связи. Вы можете одурачить себя тем, как будет выглядеть код. Я предлагаю использовать карты только до тех пор, пока не появится интересный вопрос, перейдите к тестам/коду для подтверждения, а затем возобновите проектирование.

Уорд и я сделали видеоролик примерно 15 лет назад о сессии дизайна, но я не нашел его в Интернете нигде, и у меня нет копии. Я не уверен, что это было бы полезно в качестве инструмента обучения в любом случае. Я не знаю других видеороликов, но они могут быть интересными, особенно если вам нужно сравнить несколько разных стилей дизайнера.

+33
27 февр. '09 в 18:11
источник

перейдите в источник - Кент Бек, Уорд Каннингем, когда-либо слышали о них?

+7
19 сент. '08 в 3:15
источник

Я думаю, что ваше выражение "Я не знаю никого, кто использует CRC-карты", в значительной степени подводит итог состоянию CRC-карт в разработке. Карты CRC, на мой взгляд, были шагом на пути от традиционного, ориентированного на планирование развития до гибкого развития. Мир двинулся дальше. Вместо того, чтобы сосредоточиться на использовании карт CRC, я бы исследовал такие методы, как TDD, которые могут использовать такие методы, как UML и CRC-карты, как промежуточные артефактов, но которые концентрируются на коде, и, более конкретно, на тестах. Это направление, которое изобретатели карт CRC взяли, и я бы рекомендовал вам также принять.

+7
28 февр. '09 в 17:33
источник

Самый простой способ использовать их по моему мнению, не впадая в беспорядок, - записать небольшие CRC-карты в заголовки файлов следующим образом:

///////////////////////
//* CRC CARD
//*  Class: UISliderEvent
//*  Responsability: Event that holds the value and id of a Slider movement
//*  Collaborators: UISlider, UIEvent
//////////////////////

Затем каждый раз, когда вам нужно добавить функцию, проверьте свою карточку и убедитесь, что вы не нарушаете никаких контрактов, которые вы указали в ней. Например, внезапно, в зависимости от UIMouseEvent, например, что нигде на Карте, поэтому его нет-нет, чтобы включить его.

+5
19 сент. '08 в 3:45
источник

В своей книге Object Design: роли, обязанности и сотрудничество, опубликованные в 2003 году Ребекка Вирфс-Брок и Алан МакКин обсуждают CRC-карты в деталях. Они действительно подчеркивают разницу, которую он делает для всей процедуры, что это должно быть очень осязаемым опытом, и это ослабляет людей, которые думают, что они проходят вокруг физического объекта, пытаясь выработать дизайн/требование.

Подзаголовок этой главы предполагает, что использование карт является частью фазы "исследовательского проекта", поэтому, вероятно, это происходит до того, как сделать много кодировок, но я не вижу причин, по которым вы не будете возвращаться к ним в каждая итерация Agile-проекта и напоминание о себе, где вы думали, что собираетесь идти и пересматриваете это, если это необходимо (как группа, конечно).

Кажется, я помню, что они даже предлагают пропустить мяч вокруг комнаты, так что только человек, у которого есть мяч, может говорить, поэтому, возможно, это не так много карт CRC, как заставить всех в комнате говорить о ролях и ответственность объектов, которые имеют значение?

Если вы хотите прочитать практическое исследование CRC-карт в действии (в дополнение к оригинальной бумаге Кента и Уорда, конечно), посмотрите Карточка CRC-карты.

+3
13 окт. '09 в 16:24
источник

Посмотрите другие вопросы по меткам или Задайте вопрос