4. Методика выделения компонент на основе CRC-карточек
После уточнения спецификации системы команда программистов прорабатывает сценарий системы, чтобы выявить отдельные компоненты и определить их обязанности. Т.е. воспроизводится запуск программы, как если бы она была уже готова. Любое действие, которое может произойти, приписывается некоторой компоненте в качестве ее обязанности. В целом, компонента должна удовлетворять двум важным требованиям:
-
компонента должна иметь небольшой набор четко определенных обязанностей;
-
компонента должна взаимодействовать с другими компонентами настолько слабо, насколько это возможно.
Выделение компонент производится во время мысленного представления работы системы. Часто это происходит как цикл вопросов "что/кто". Разработчики определяют: что требуется делать? Это немедленно приводит к вопросу: кто будет выполнять действие? Действия, которые должны быть выполнены, приписываются некоторой компоненте в качестве ее обязанностей. В ОО-проекте для каждого действия обязательно должна быть установлена выполняющая это действие компонента.
Для выделения обязанностей компонент удобно изображать компоненты с помощью небольших карточек. На лицевой стороне карточки написаны имя компоненты, ее обязанности и имена других компонент, с которыми она должна взаимодействовать (рис. 2.1). Такие карточки обычно называются CRC-карточками от слов Component, Responsibility, Collaborator (компонента, обязанность, сотрудники).
Компонента (название)
|
Сотрудничающие с ней компоненты
|
Описание обязанностей,
приписанных данной
компоненте
|
Список компонент
|
Рис. 2.1. Структура CRC-карточки
CRC-карточки недороги и доступны, поэтому с минимальными затратами можно изучить несколько альтернативных проектов. Физическое разделение карточек стимулирует понимание важности логического разделения компонент. Небольшой размер карточки служит оценкой примерной сложности отдельного фрагмента – компонента, которой приписывается больше задач, чем может поместиться на карточке, вероятно, является излишне сложной, и должно быть найдено более простое решение (например, можно разбить компоненту на две или пересмотреть разделение обязанностей между различными компонентами).
5. Учебный пример: проектирование электронного ежедневника
5.1 Идентификация компонент
Рассмотрим начало проектирования ежедневника. Будем считать, что после запуска система показывает привлекательное информационное окно. Ответственность за его отображение приписана компоненте, названной MainWin. Некоторым образом (с помощью меню, клавиатуры, или мыши) пользователь выбирает одно из нескольких действий:
-
Просмотр дел на заданную дату.
-
Создание нового дела.
-
Редактирование существующего дела.
-
Поиск времени, на которое назначена встреча с заданным человеком.
-
Просмотр базы данных о людях.
-
Добавление сведений о новом человеке.
-
Редактирование данных о человеке.
Эти действия разбиваются на три группы. Первые три связаны с базой данных дел, одно – с базой данных дел и с базой данных людей, последние три – с базой данных людей. В результате принимается решение: нужны по крайней мере две компоненты – база данных дел и база данных людей.
Компоненты, работающие с базами данных, должны обеспечивать просмотр существующих данных, редактирование и добавление новых записей. Т.е. их назначение – поддержка однотипных записей. Но создание нового дела осложняется тем, что надо следить, чтобы не было пересекающихся дел и при необходимости выполнять поиск свободных временных промежутков. Поэтому для создания нового дела требуется отдельная компонента – менеджер планирования. Таким образом, учитывая наличие трех компонент, можно сформировать первый вариант CRC-карточки для компоненты MainWin (рис. 2.2).
MainWin (главное окно программы)
|
Сотрудничающие
компоненты
|
Вывести на экран заставку
Предложить пользователю выбрать параметры
Передать управление другой компоненте:
базе данных дел
базе данных людей
менеджеру планирования
|
База данных дел
База данных людей
Менеджер планирования
|
Рис. 2.2. CRC-карточка компоненты MainWin.
На данном этапе часть решений, касающихся отдельных компонент, можно отложить. Например, как пользователь станет просматривать базу данных дел? Возможны несколько вариантов: по дням, или задавая имя человека, или по теме встречи. В каком виде отображать перечень дел на один день? Стоит ли имитировать страницы ежедневника? Все эти решения влияют только на отдельные компоненты и не затрагивают функционирование остальных частей системы.
Однако при разработке компонент следует учитывать, что в будущем неизбежны изменения. Они связаны как с неточностью исходной спецификации, так и с изменением желаний и потребностей пользователей. Потому разработчики должны по возможности планировать свои действия с учетом нескольких соображений:
-
Главная цель состоит в том, что изменения должны затрагивать как можно меньше компонент.
-
Старайтесь предсказывать наиболее вероятные источники изменений и по возможности изолируйте их от других компонент (обычно это пользовательский интерфейс, форматы обмена информацией, вид выходных данных).
-
Уменьшайте зависимость программы от аппаратуры. Например, ежедневник впоследствии может потребоваться переработать для карманного компьютера.
5.2 Взаимосвязь компонент
Каждое назначенное дело будет связано с конкретной программной компонентой Deal. При просмотре дел удобен режим, когда они показываются по дням. Поэтому дела, относящиеся к одному дню, будут связаны с отдельной компонентой (Date). При выборе конкретного дела управление передается объекту, связанному с этим делом.
Дело содержит некоторую информацию: это время, на которое назначено дело, примерная продолжительность, с кем назначена встреча и краткое содержание дела. Компонента Deal умеет отображать себя на экране.
При выборе дела для редактирования управление передается этой компоненте: возможно изменение времени, содержания дела и других данных. С другой стороны, пользователь может попросить распечатать дела, относящиеся к определенному дню. Это является обязанностью компоненты Date. Пока мы рассматриваем компоненты Date и Deal как отдельно взятые объекты, хотя на самом деле это прототипы многочисленных объектов.
Предположим, пользователь хочет добавить в базу данных людей нового человека. В блоке управления БД некоторым образом (пока не конкретизируется, как именно) определяется, в какой раздел поместить человека (деловые контакты, личные и т.п.), запрашивается его имя, характеристики (например, день рождения и место работы), телефон и выводится окно для набора текста комментария. Эту задачу естественно отнести к компоненте Person, которая отвечает за хранение и редактирование данных о людях.
При просмотре дел должна быть возможность просмотра информации о человеке, с которым назначена встреча.
Теперь рассмотрим, как выполняется планирование дел. Редактирование сведения о деле выполняется компонентой Deal. Но при создании нового дела или изменении времени существующего дела надо проверить, свободно ли первоначально предполагаемое время или выбрать подходящее время. Это выполняет менеджер планирования – Plan Manager. Он подбирает корректную дату для дела и передает ему управление для редактирования.
Вообще, компонента Plan Manager может запускаться или для просмотра существующих дел по дням, или при создании нового дела.
Каждая дата ассоциируется с компонентой типа Date. Она может показывать и распечатывать список дел, относящихся к этому дню. В компоненте Date хранится значение даты, некоторый комментарий к этому дню (какие-либо напоминания, информация о днях рождения и др.).
В конечном счете можно сказать, что все действия можно надлежащим образом распределить между семью компонентами (рис. 2.3). На рис. 2.3 отрезками показано, какие компоненты с какими взаимодействуют. Например, компонента Date обращается к компонентам Deal только через посредство базы данных Deal Database.
Рис. 2.3. Взаимосвязь между компонентами электронного
ежедневника по отношению "доступ".
5.3 Диаграммы взаимодействия
Схема, показанная на рис. 2.3, хорошо подходит для отображения статических связей между компонентами. Она не годится для описания динамического взаимодействия во время выполнения программы. Для этого применяются диаграммы взаимодействия (рис. 2.4). На рис. 2.4 по вертикальной оси в направлении сверху-вниз откладывается время. Каждая компонента представлена вертикальной линией. Сообщение от одной компоненты другой изображается горизонтальной стрелкой между вертикальными линиями. Возврат управления (и, возможно, результата) в компоненту представлен пунктирной стрелкой.
-
|
MainWin
|
Plan
Manager
|
Date
|
Person
Database
|
Комментарии
|
|
|
|
|
|
|
|
|
Сообщение browse()
|
|
|
|
|
|
|
|
|
Сообщение display()
|
|
|
|
|
|
|
|
|
Возврат из display()
|
|
|
|
|
|
|
|
|
Возврат из browse()
|
t (время)
|
|
|
|
|
|
|
|
Сообщение newPerson()
|
Рис. 2.4. Фрагмент диаграммы взаимодействия для программы электронного ежедневника.
|
