Книга: Технологии программирования

8.9.2. Начинаем с анализа функционирования. Учебный пример объектно-ориентированного проекта средней сложности

Из-за чего процесс проектирования начинают с анализа функционирования или поведения системы? Простой ответ состоит в том, что поведение системы обычно известно задолго до остальных ее свойств.

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

Представим себе, что вы являетесь главным архитектором программных систем в ведущей компьютерной фирме. Однажды появляется ваш начальник с идеей, которая, как он надеется, будет очередным успехом компании. Вам поручают разработать систему под названием "Интерактивный разумный кухонный помощник" (РКП).

Задача, поставленная перед вашей командой программистов, сформулирована в нескольких скупых словах. Программа "разумный кухонный помощник" (РКП) предназначена для домашних персональных компьютеров. Ее цель — заменить собой набор карточек с рецептами, который можно встретить почти в каждой кухне.

Анализ аналогов выявил, что уже известен ряд программных реализаций электронных поваренных книг с рецептами блюд. В данной области применения новой была бы программа, позволяющая планировать питание на заданный период. План питания на заданный период состоит из ежедневных планов питания с трех- или четырехразовым приемом пищи. Что надо учесть при разработке ежедневных планов питания? Число человек, калорийность питания каждого человека, любимые и нелюбимые блюда, затраты на питание. Ранние, описанные в литературе попытки оптимизации питания с учетом только продуктов, их калорийности и цен привели к решениям вида: оптимальный завтрак — 12 чашек уксуса. Генерация меню обеда с использованием датчика случайных чисел может привести к решениям с несовместимыми блюдами: молочный суп, сельдь с гороховым гарниром, квас. Решение проблемы — использование набора комплексных завтраков, обедов и ужинов. Есть ли в литературе достаточное описание возможных комплексов? Необходимо ли привлечь специалистов по питанию для разработки требуемого количества комплексов? Сколько будет стоить база данных комплексов? Следует ли реализовать функцию автоматической передачи заказа на продукты в магазин? На эти и другие вопросы необходимо дать ответ, чтобы уложиться в отпущенные средства и сроки.

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

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

1. Просмотреть базу данных с рецептами, но без ссылок на какой-то план питания.

2. Добавить новый рецепт в базу данных.

3. Редактировать или добавить комментарий к существующему рецепту.

4. Просмотреть базу данных комплексов.

5. Добавить новый комплекс в базу данных.

6. Редактировать или добавить комментарий к существующему комплексу.

7. Создать новый план питания.

8. Пересмотреть существующий план в отношении некоторых дат, блюд и продуктов.

Более детальное описание функций программы представлено на рис. 8.7.

Рис. 8.7. Детальное описание функций программы

Программа должна обеспечивать ведение базы данных (добавление, удаление и другие действия с отдельным рецептом или набором рецептов). Это, в общем-то, стандартные функции СУБД. Что касается функции планирования, то подразумевается, что программа по запросу пользователя будет составлять план питания на определенный период времени (неделю, месяц, год) для всей семьи или отдельных ее членов, исходя из заданных ограничений (например, ограничение на калорийность). После создания плана пользователю будет предоставлены следующие возможности:

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

— получение списка продуктов, которые необходимо закупить на расчетный период;

— осуществление распечатки данного плана питания или списка требуемых продуктов;

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

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

Первые три действия связаны с базой данных рецептов; следующие три действия связаны с базой данных комплексов, последние два — с планированием питания. В результате команда принимает следующее решение: создать объекты, соответствующие этим двум обязанностям.

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

• стандартные средства по ведению базы данных рецептов (просмотр, добавление, редактирование, удаление записей рецептов);

• стандартные средства по ведению базы данных комплексов (просмотр, добавление, редактирование, удаление записей комплексов);

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

• возможность вывода информации по приготовляемым блюдам в соответствии с планом питания (на экран, принтер) на весь расчетный период или на требуемый день;

• возможность вывода информации о составе продуктов (на экран, на принтер) как за весь период, так и по датам закупок, исходя из сроков хранения.

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

Отложенные действия. В конце концов придется решать, как пользователь станет просматривать базу данных. Например, должен ли он сначала входить в список таких категорий, как "супы", "салаты", "горячие блюда", "десерты"? С другой стороны, может ли пользователь задавать ключевые слова поиска ингредиентов, например "клубника", "сыр". Следует применять полосы прокрутки или закладки в виртуальной книжке?

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

Что такое план питания? План питания это список объектов DateList — дат. Дата это объект Date с включенными кулинарными рецептами, с соблюдением правил комплексов завтраков, обедов и ужинов.

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

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

Вернемся к блоку 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).

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

Оглавление книги