Первой задачей является уточнение спецификации. Как мы уже заметили, исходные спецификации почти всегда двусмысленны и непонятны во всем, кроме наиболее общих положений. На этом этапе ставится несколько целей. Одной из них является лучшее понимание и ощущение того, чем будет конечный продукт(принцип «посмотри и почувствуй» для проектирования системы). Затем эта информация может быть возвращена назад клиенту(в данном случае вашему начальнику), чтобы увидеть, находится ли она в соответствии с исходной концепцией. Вероятно и, возможно, неизбежно то, что спецификации для конечного продукта будут изменяться во время разработки программной системы, и поэтому важно, чтобы проект мог легко включать в себя новые идеи, а также чтобы потенциально возможные исправления были выявлены как можно раньше— см. раздел2.6.2. «Готовность к изменениям». На этом же этапе проводится обсуждение структуры будущей программной системы. В частности, действия, осуществляемые программной системой, разбиваются на компоненты.
2.4.3. Идентификация компонент
Создание сложной физической системы, подобной зданию или двигателю автомобиля, упрощается с помощью разбиения проекта на структурные единицы. Точно так же
разработка программного обеспечения облегчается после выделения отдельных компонент программы. Компонента— это просто абстрактная единица, которая может выполнять определенную работу(то есть иметь определенные обязанности). На этом этапе нет необходимости знать в точности то, как задается компонента или как она будет
выполнять свою работу. Компонента может в конечном итоге быть преобразована в отдельную функцию, структуру или класс, или же в совокупность других компонент(шаблон). На этом уровне разработки имеются две важные особенности:
∙компонента должна иметь небольшой набор четко определенных обязанностей;
∙компонента должна взаимодействовать с другими компонентами настолько слабо, насколько это возможно.
Позднее мы поговорим о второй особенности подробнее. Сейчас мы просто занимаемся определением обязанностей компонент.
2.5. CRC-карточка— способ записи обязанностей
Чтобы выявить отдельные компоненты и определить их обязанности, команда программистов прорабатывает сценарий системы. То есть воспроизводится запуск приложения, как если бы оно было уже готово. Любое действие, которое может произойти, приписывается некоторой компоненте в качестве ее обязанности.
В качестве составной части этого процесса полезно изображать компоненты с помощью небольших индексных карточек. На лицевой стороне карточки написаны имя компоненты, ее обязанности и имена других компонент, с которыми она должна взаимодействовать. Такие карточки иногда называютсяCRC-карточкамиот словComponent, Responsibility, Collaborator (компонента, обязанность, сотрудники) [Beck 1989]. По мере того как для компонент выявляются обязанности, они записываются на лицевой сторонеCRC- карточки.
2.5.1. Дайте компонентам физический образ
При проработке сценария полезно распределить CRC-карточкимежду различными членами проектной группы. Человек, имеющий карточку, которая представляет определенную компоненту, записывает ее обязанности и исполняет функции заменителя программы во время моделирования сценария. Он описывает действия программной системы, передавая «управление» следующему члену команды, когда программная система нуждается в услугах других компонент.
Преимущество CRC-карточекв том, что они широко доступны, недороги и с них можно стирать информацию. Это стимулирует экспериментирование, поскольку альтернативные проекты могут быть испробованы, изучены и отброшены с минимальными затратами.
Физическое разделение карточек стимулирует интуитивное понимание важности логического разделения компонент, что помогает сделать упор на связности внутри модулей и зацеплении между модулями(которые вкратце будут описаны ниже).
Небольшой размер индексной карточки служит хорошей оценкой примерной сложности отдельного фрагмента — компоненты, которой приписывается больше задач, чем может поместиться на ее карточке, вероятно, является излишне сложной, и должно быть найдено более простое решение. Может быть, следует пересмотреть разделение обязанностей или разбить компоненту на две.
2.5.2. Цикл «что/кто»
Как мы заметили в начале нашего обсуждения, выделение компонент производится во время процесса мысленного представления работы системы. Часто это происходит как цикл вопросов «что/кто». Во-первых, команда программистов определяет: что требуется делать? Это немедленно приводит к вопросу: кто будет выполнять действие? Теперь программная система в значительной мере становится похожа на некую организацию, скажем, карточный клуб. Действия, которые должны быть выполнены, приписываются некоторой компоненте в качестве ее обязанностей.