Описание полной системы

Для завершения проекта следует заняться управлением сессией. При функциональной декомпозиции эту задачу выполняла процедура execute_session - главная программа. Но мы знаем, как сделать это лучшим образом. Как ранее говорилось (см.лекцию 5 курса "Основы объектно-ориентированного программирования") главная функция системы, позиционируемая как верхняя функция в проектировании сверху вниз, - это нечто мифическое. Большие программные системы выполняют множество одинаково важных функций. И здесь основанный на АТД подход является предпочтительным. Вся система в целом рассматривается как множество абстрактных объектов, способных выполнять ряд служб ( services ).

Ранее мы рассмотрели одну ключевую абстракцию - STATE. Какая же абстракция в нашем рассмотрении осталась пропущенной? Ответ очевиден: центральным в нашей системе является понятие APPLICATION, описывающее специфическую интерактивную систему, подобную системе резервирования билетов. Это приводит нас к следующему классу.

Рис. 2.8.Компоненты классов State и Application

Заметьте, все не вошедшие в класс STATE программы функциональной декомпозиции стали теперь компонентами классаAPPLICATION:

· Execute_session - описывает, как выполнять сессию, ее имя теперь разумно упростить и называть просто execute, так как дальнейшую квалификацию обеспечивает имя класса.

· Initial и is_final - указывают, какие состояния имеют специальный статус в приложении. Конечно же, их разумно включить именно в класс APPLICATION, а не в класс STATE, поскольку они описывают свойства приложения, а не состояния, которое является заключительным или начальным только по отношению к приложению, а не само по себе. При повторном использовании состояние, бывшее заключительным в одном приложении вполне может не быть таковым для другого приложения.

· Transition - описывает переходы между состояниями приложения.

Все компоненты функциональной декомпозиции нашли свое место в ОО-декомпозиции: одни в классе STATE, другие вAPPLICATION. Это не должно нас удивлять. Объектная технология, о чем многократно говорится в этой книге, является прежде всего архитектурным механизмом, в первую очередь предназначенным для организации программных элементов в согласованные структуры. Сами элементы, возможно, нижнего уровня, те же самые или похожие на элементы необъектных решений. Объектные механизмы: абстракция данных, скрытие информации, утверждения, наследование, полиморфизм, динамическое связываниепозволяют сделать задачу проектирования более простой, общей и мощной.

Системе управления панелями, изучаемой в данной лекции, всегда необходимы: процедура обхода графа приложения (execute_session, теперь просто execute ), чтение ввода пользователя ( read ), обнаружение заключительного состояния (is_final ). Погружаясь в структуру, можно найти одни и те же элементы, независимо от выбранного подхода к проектированию. Что же меняется? - способ группирования элементов, создающий модульную архитектуру.

Конечно, нет необходимости ограничивать себя элементами, пришедшими из предыдущих решений. То, что для функционального решения было завершением процесса - построение функции execute и всего необходимого для ее работы - теперь становится только началом. Существует много других вещей, которые хотелось бы выполнять для подобных приложений:

· добавить новое состояние;

· добавить новый переход;

· построить приложение (Многократно повторяя комбинацию предшествующих двух операций);

· удалить состояние, переход;

· сохранить законченное приложение, его состояние и переходы в базе данных;

· промоделировать работу приложения (например, с заглушками для программ, проверяя работу только переходов);

· мониторинг использования приложения.

Все эти операции и другие будут в равной степени являться компонентами класса APPLICATION. Здесь нет более или менее важных программ, чем наша бывшая "главная программа", - процедура execute, ставшая теперь обычным компонентом класса, равная среди других, но не первая. Устраняя понятие вершины, мы подготавливаем систему к эволюции и повторному использованию.