Читаем Технологии программирования полностью

Вернемся к блоку Greeter (см. рис. 8.6). Планирование меню, как вы помните, было поручено объекту PlanManager. Пользователь должен иметь возможность сохранить существующий план. Следовательно, объект PlanManager может запускаться либо в результате открытия уже существующего плана питания, либо при создании нового. В последнем случае пользователя необходимо попросить ввести интервалы времени (список дат) для нового плана. Каждая дата ассоциируется с отдельным объектом типа Date. Пользователь может выбрать конкретную дату для детального исследования. В этом случае управление передается соответствующему объекту Date. Объект PlanManager должен уметь распечатывать меню питания на планируемый период. Наконец, пользователь может попросить объект PlanManager сгенерировать список продуктов на указанный период.

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

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

Рис. 8.8. Схема статических связей между объектами программы РКП

Далее команда разработчиков продолжает исследовать все возможные сценарии. Необходимо предусмотреть обработку исключительных ситуаций. Например, что происходит, если пользователь задает ключевое слово для поиска рецепта, а подходящий рецепт не найден? Как пользователь сможет прервать действие (например, ввод нового рецепта), если он не хочет продолжать дальше? Все это должно быть изучено. Ответственность за разработку подобных ситуаций следует распределить между объектами.

Изучив различные сценарии, команда разработчиков в конце решает, что все действия надлежащим образом могут быть распределены между семью объектами (рис. 8.8). Объект Greeter взаимодействует только с PlanManager и Recipe Database. Объект PlanManager "зацепляется" только с DateList, DateList с Date, a Date, в свою очередь, — с Meal. Объект Meal обращается к RecipeManager и через посредство этого объекта к конкретным рецептам (см. рис. 8.8).

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

8.9.3. Динамическая модель системы

Объектная модель представляет статическую структуру проектируемой системы (подсистемы). Однако знания статической структуры недостаточно, чтобы понять и оценить работу подсистемы. Схема, изображенная на рис. 8.8, не годится для описания динамического взаимодействия во время выполнения программы.

Динамическая модель подсистемы строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена.

Динамическая модель системы представляется диаграммой последовательности и диаграммой состояний объектов.

На рис. 8.9 показана часть диаграммы последовательности для РКП. Время изменяется сверху вниз. Каждый объект представлен вертикальной линией. Сообщение от одного объекта к другому изображается горизонтальной стрелкой между вертикальными линиями. Возврат управления (и, возможно, результата) в объект представлен стрелкой в обратном направлении. Некоторые авторы используют для этих целей пунктирную стрелку. Комментарий справа от рисунка более подробно объясняет взаимодействие.

Благодаря наличию оси времени диаграмма последовательности лучше описывает последовательность событий в процессе работы программы. Поэтому диаграммы последовательности являются полезным средством документирования для сложных программных систем.