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

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

обновление

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

29
crc-cards ooad oop

6 ответов

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

  1. отправная точка сделать требование elicitation. Привлечение клиента на ранней стадии и непрерывно предлагается здесь (взгляните на гибкие подходы, т. е. Экстремальное программирование)
  2. затем требования могут быть смоделированы либо с помощью диаграмм прецедентов (UML), либо с помощью пользовательских историй (agile extreme programming approach). Ключевая проблема здесь состоит в том, чтобы найти правильные вовлеченные объекты. Это очень сильно зависит от домена ты, конечно. Если вы идете "трудным" путем, вы можете применить такие методы, как "извлечение существительных". Таким образом, вы анализируете документ спецификации и извлекаете все существительные (включая составные имена и имена с прилагательными). Проанализируйте их все и отбросьте ненужные.
  3. как только у вас есть правильные существительные -> объекты, вы можете начать создавать свои CRC-карты. Итак, что делается в сеансе CRC? Основная задача-найти и назначить обязанности ваших (ранее) найденных объектов, которые затем проставляются на небольших индексных картах (наших CRC-картах). "Обязанности" - это в основном основные функциональные возможности конкретного объекта и часть " сотрудничество необходимы ли другие объекты для выполнения определенных функций (это зависимости между различными объектами в вашей модели). Важным моментом при распределении обязанностей является то, что обязанности распределяются в рамках всей системы сбалансированным образом. Еще один очень важный момент заключается в том, чтобы избежать дублирования обязанностей между объектами (здесь помогают CRC-карты).
    сеанс CRC должен начинаться с мозгового штурма, имеющего активное обсуждение среди разработчиков и его следует проводить непосредственно на реальных индексных картах.

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

с уважением,
Дзюри

13

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

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

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

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

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

33
7

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

7

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

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

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

5

в своей книге проектирование объектов: роли, обязанности и сотрудничество опубликовано в 2003 году От Rebecca Wirfs-Брок & Alan McKean обсудить CRC карты в некоторых деталях. Они действительно подчеркивают разницу, которую это делает для всей процедуры, что это должно быть очень тактильным опытом, и это ослабляет мышление людей, чтобы передавать физический объект, пытаясь конкретизировать дизайн / требование.

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

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

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

3