Популярная наклейка от жевательной резинки утверждает, что время от времени может и должно спонтанно происходить необъяснимое. (Наклейка от жевательной резинки использует чуть более короткую фразу.) Мы знаем, однако, что в реальной жизни это вряд ли справедливо. Если происходит некоторое действие, должен быть и агент, которому предписано выполнять это действие. Точно так же как в карточном клубе каждое действие приписано определенным индивидуумам, при организации объектно-ориентированнойпрограммы каждое действие является обязанностью некоторой компоненты. Секрет хорошего объектно-ориентированногопроекта состоит в том, чтобы установить агента для каждого действия.
2.5.3. Документирование
На этом этапе следует начать разработку документации. Два документа должны являться существенными составными частями любой программной системы: руководство пользователя и проектная документация системы. Работа над каждым из них может начинаться до того, как написана первая строчка программного кода.
Руководство пользователя описывает взаимодействие с системой с точки зрения пользователя. Это— отличное средство проверки того, что концепция командыпрограммистов-разработчиковсоответствует мнению клиента. Поскольку решения, принятые в процессе проработки сценария, соответствуют действиям, которые потребуются от пользователя при использовании программы, то написание руководства пользователя естественным образом увязывается с процессом проработки сценария.
Перед тем как написан какой-либокусок кода, мышление команды программистов во многом похоже на сознание конечных пользователей. То есть именно на этом этапе разработчики могут наиболее легко предугадать те вопросы, на которые новичку- пользователю понадобятся ответы.
Второй существенный документ — проектная документация. Она протоколирует основные решения, принятые при планировании программы, и, следовательно, должна создаваться в тот момент, когда эти решения еще свежи в памяти создателей, а не годом позже. Зачастую много проще написать общее глобальное описание программной системы в начале разработки. Затем, естественно, совершается переход к уровню отдельных компонент или модулей.
Хотя в равной мере важно документировать программу на уровне модулей, слишком
большое внимание к деталям организации каждого фрагмента сделает сложным для последующих программистов, осуществляющих сопровождение программной системы, формирование общей картины приложения.
CRC-карточкиявляются одним из видов проектной документации, но многие другие важные решения не отражены в них. Аргументы за и против каждой важной альтернативы при проектировании должны записываться, равно как и факторы, которые повлияли на конечное решение. Должен вестись протокол или дневник хода проекта. Как руководство пользователя, так и проектная документация уточняются и изменяются в процессе работы в точном соответствии с тем, как модифицируется собственно программа.
2.6. Компоненты и поведение
Вернемся к программе IIKH. Команда разработчиков решает, что когда система начинает работу, пользователь видит привлекательное информационное окно(см. рис. 2.1). Ответственность за его отображение приписана компоненте, названнойGreeter. Некоторым, пока еще не определенным образом(с помощью всплывающих меню, кнопок, нажатия на клавиши клавиатуры или использования сенсорного экрана) пользователь выбирает одно из нескольких действий.
Первоначально планируется только пять действий:
1.Просмотреть базы данных с рецептами, но без ссылок накакой-токонкретный план питания.
2.Добавить новый рецепт в базу данных.
3.Редактировать или добавить комментарии к существующему рецепту.
4.Пересмотреть существующий план в отношении некоторых продуктов.
5.Создать новый план питания.
Эти действия естественным образом разбиваются на две группы. Первые три действия связаны с базой данных рецептов, последние два— с планированием питания. В результате команда принимает следующее решение: создать компоненты, соответствующие этим двум обязанностям. Продолжая прорабатывать сценарий, планирование питания на время игнорируем и переходим к уточнению действий, связанных с компонентойRecipe Database. На рис. 2.2 показан
Рис. 2.2. CRC-карточкадля класса заставкиGreeter
первоначальный вид CRC-карточкидля компонентыGreeter.
В широком смысле обязанность компоненты, работающей с базой данных, — просто поддерживать записи с рецептами.
Мы уже выделили три аспекта этой компоненты: Recipe Database должна обеспечивать просмотр библиотеки существующих рецептов, редактирование рецептов, включение новых рецептов в базу данных.
2.6.1. Отложенные решения
В конце концов придется решить, как пользователь станет просматривать базу данных. Например, должен ли он сначала входить в список категорий таких, как «супы», «салаты», «горячие блюда», «десерты»?