Полное руководство по моделированию CRC (класс, ответственность, сотрудничество)

Основываясь на фундаментальных принципах объектно-ориентированного (OO) анализа, это руководство описывает процесс моделирования CRC. Моделирование CRC — это высокоэффективная, простая методология, разработанная для преодоления разрыва в коммуникации между разработчиками и пользователями, обеспечивая точное выявление и понимание бизнес-требований до написания кода.

---

1. Ключевые понятия: Анатомия карточки CRC

Моделирование CRC основано на стандартных карточках, разделённых на три отдельных раздела. Каждый раздел представляет собой основное понятие объектно-ориентированного проектирования.

А. Класс (верхняя часть карточки)

Класс представляет собой совокупность похожих объектов. Объектом может быть человек, место, предмет, событие, понятие, экран или отчёт, относящийся к системе.

• Правило именования: Используйте одно или два слово в единственном числе (например, Клиент, а не Клиенты).

• Пример: В системе доставки/учёта товаров классы включают Товар на складе, Заказ, Позиция заказа, Клиент, и Поверхностный адрес.

Б. Ответственность (левый столбец)

Ответственность — это всё, что класс знает или делает.

• Что он знает (данные/атрибуты): Пример: Один Клиент класс знает свое имя, номер клиента и номер телефона.

• Что он делает (поведение/методы): Пример: Один Клиент класс может заказывать товары, отменять заказы и совершать платежи.

C. Партнер (правый столбец)

Сотрудничество происходит, когда классу требуется информация или помощь от другого класса для выполнения обязанности.

• Пример: Объект Заказ объект несет ответственность за «расчет общей суммы». Однако он не знает цену товаров или количество заказанных единиц. Следовательно, он должен сотрудничать с Товар заказа (который знает количество) и Товар на складе (который знает цену), чтобы рассчитать итоговую сумму.

---

2. Команда моделирования CRC

Успешная сессия CRC требует определенных ролей, чтобы процесс проходил гладко и точно отражал бизнес-логику.

1. Эксперты по бизнес-области (BDE): Фактические пользователи системы (обычно 4–5 сотрудников непосредственно на линии фронта). У них есть повседневные знания в области бизнеса. Примечание: Руководители обычно не подходят для CRC; им больше подходит анализ высокого уровня Use Cases.

2. Модератор: Ведет сессию, объясняет методику, задает актуальные вопросы, обеспечивает правильное заполнение карточек и руководит тестированием сценариев.

3. Записывающий(ие): 1 или 2 человека, сидящие сзади/по бокам. Они не участвуют в моделировании, но фиксируют подробную бизнес-логику и правила, которые не помещаются на маленьких карточках.

4. Наблюдатели: Стажеры или заинтересованные стороны, которые сидят сзади и наблюдают, не участвуя.

---

3. Процесс моделирования CRC из шести этапов

Шаг 1: Сформируйте команду

Соберите 4–5 операционных BDE, одного модератора и 1–2 секретарей. Убедитесь, что руководство поддерживает процесс, чтобы участники могли выделить необходимое время.

Шаг 2: Организуйте помещение

• Поверхности для письма: Флипчарты или белые доски для мозгового штурма и прототипирования.

• Стол для моделирования: Большой центральный стол, на котором BDE могут размещать и перемещать карточки.

• Места для секретарей: Столы, установленные в стороне, но с хорошей видимостью.

• Материалы: Карточки, маркеры и мячмягкий, пористый мяч (используется позже для тестирования сценариев).

Шаг 3: Мозговой штурм

Генерируйте идеи, не оценивая их. Модератор задает открытые вопросы, чтобы понять бизнес-потребности.

• Примеры вопросов: «Для кого эта система?», «Какие бизнес-потребности она поддерживает?», «Как мы можем сделать это быстрее/дешевле/лучше?», «Есть ли простые задачи, которые можно автоматизировать?»

Шаг 4: Объясните методику

Модератор тратит 10–15 минут на объяснение концепций CRC, ярко вывешивая определения на стенах и сопровождая команду при создании нескольких примеров карточек.

Шаг 5: Итеративное моделирование CRC

BDE стоят или сидят вокруг стола и итеративно строят модель:

• Найдите классы: Следуйте за денежными потоками, ищите отчеты/экраны и сразу определите 3–5 основных классов.

• Найдите ответственности: Спрашивайте, что класс знает и что он делает.

• Определите сотрудников:Определите, кто обладает недостающей информацией, необходимой для выполнения обязанности.

• Расположите карты: Ключевой шаг.Карты, которые часто взаимодействуют, располагаются близко друг к другу на столе. «Загруженные» карты помещаются в центр. Физическое перемещение карт помогает команде визуализировать взаимосвязи и ассоциации.

Шаг 6: Тестирование сценариев использования (упражнение «Передача мяча»)

Это упражнение по проверке, при котором команда «разыгрывает» рабочие процессы системы, чтобы убедиться в точности модели.

1. Назовите сценарий:Ведущий описывает сценарий использования (например, «Клиент размещает заказ») и бросает мягкий мяч сотруднику, отвечающему за начальную ответственную карту (например, Заказ).

2. Определите ответственность:Группа подтверждает, что карта справляется с задачей. Если нет, они обновляют или создают новую карту.

3. Опишите логику:Сотрудник, держащий мяч, описывает пошаговую бизнес-логику (псевдокод) секретарю.

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

5. Верните мяч назад:Как только задача выполнена, мяч возвращается к предыдущему человеку, в конечном итоге возвращаясь к ведущему, чтобы начать следующий сценарий.

---

4. Как CRC вписывается в жизненный цикл разработки программного обеспечения

Моделирование CRC не существует в вакууме; оно является частью более широкого процесса объектно-ориентированного моделирования, который является последовательным на крупном масштабе (переход от требований к проектированию к коду) и итеративным на небольшом масштабе (переход между моделями).

• Уровень детализации: CRC находится посередине. Вы начинаете просто с Сценарии использования и Прототипы пользовательского интерфейса, перейдите к среднему уровню детализации Модели CRC, и завершите высокой детализацией Диаграммы классов.

• Результаты определяют результаты: Диаграммы вариантов использования документируются вариантами использования, которые документируются диаграммами последовательности, которые в конечном итоге формируют исходный код. Модели CRC напрямую используются при создании диаграмм классов.

---

5. Лучшие практики и советы по успеху

1. Отправьте повестку дня: Распространите повестку дня за несколько дней до встречи, чтобы BDE могли подготовиться.

2. Представьте определения: Прикрепите крупную схему карточек CRC и их определения к передней части комнаты.

3. Используйте терминологию предметной области: Избегайте технического жаргона; используйте точные слова, которые BDE используют в повседневной работе.

4. Оставайтесь на низком уровне технологий: Инструменты для CRC являются только опциональными. Карточки дешевы, удобны для переноски и чрезвычайно эффективны.

5. Ожидайте прототипирования: Чертежи экранов и отчетов на флипчартах во время сессии помогают пользователям визуализировать систему.

6. Планируйте на несколько дней: Большие системы требуют нескольких сессий. Это нормально и необходимо.

7. Получите поддержку руководства: Убедитесь, что руководство понимает ценность моделирования до написания кода.

8. Направлено на линейных сотрудников: Модели CRC чрезвычайно детализированы и лучше всего работают с повседневными пользователями, а не с высокопоставленными руководителями.

---

6. Преимущества и недостатки

Преимущества

• Эксперты проводят анализ: Люди, которые на самом деле выполняют работу, создают модель.

• Высокая вовлеченность пользователей:Активное участие повышает удовлетворенность пользователей и чувство собственности.

• Снижает барьеры:Пользователи и разработчики работают бок о бок.

• Простота и ненавязчивость:Это просто карточки. Пользователи не испытывают страха перед сложными программными инструментами, и они не чувствуют, что их работа будет автоматизирована «машиной».

• Недорого и переносимо:Стоит несколько долларов и помещается в портфель.

• Безупречный переход:Идеально сочетается с прототипированием и напрямую переходит к формальным диаграммам классов.

Недостатки

• Угрожающе для некоторых разработчиков:Некоторые разработчики ошибочно считают, что их технические знания превосходят деловые знания пользователей.

• Сложности с планированием:Собрать 4–5 ключевых пользователей в одной комнате одновременно требует продуманного планирования.

• Ограничения карточек:Стопка карточек не является приемлемым формальным результатом для большинства организаций. CRC необходимо дополнить формальными сценариями использования, прототипами и диаграммами классов.

---

Заключение

Конечная цель разработки приложений — эторешение бизнес-задач, а не удовлетворять интеллектуальный любопытство разработчика новыми технологиями. Моделирование CRC заставляет разработчиков работатьспользователями, а не против них. Используя низкотехнологичную, высококоллаборативную среду, команды могут точно захватывать, проверять и уточнять бизнес-требования до того, как будет написано первое строка кода.