9 Преобразование объектно-ориентированного анализа в объектно-ориентированное проектирование

В этой главе мы представили преобразование ООА в объектно-ориентированное проектирование. Проектирование представляется в нотации OODLE, которая описана в приложении А. Если Вы незнакомы с концепциями объектно-ориентированного проектирования или с нотацией OODLE, то мы предлагаем Вам сначала прочитать это приложение.

9.1 Введение

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

Принцип проектирования

Более интересным, чем само проектирование, является его принцип . В последующем описании обратите внимание на особую значимость архитектурного домена:

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

• линии поведения и соглашения для создания прикладного проектирования устанавливаются архитектурным доменом. Эти соглашения выражаются как правила преобразования, которые создают компоненты проектирования из компонентов моделей ООА.

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

Терминология

Терминология, используемая сегодня в объектно-ориентированной литературе, во многом зависит от автора, по крайней мере, в той части, которая использует термины, определенные в еще развивающихся объектно-ориентированных языках программирования. В этой главе мы будем использовать следующие не зависимые от языка термины вдобавок к определенным в приложении А:

Объект	абстракция реального предмета; объект, как в ООА; типичный, но неопределенный экземпляр;
Экземпляр	один определяемый экземпляр класса; определенный экземпляр анализируемого объекта;
Конструктор	операция, которая создает экземпляр класса;
Дескриптор	указатель или другая ссылка на структуру данных, содержащую данные, которые описывают экземпляр;
Компонента экземпляра	логическая компонента экземпляра, которая реализуется как отдельный элемент структуры данных экземпляра. Аналог элемента данных члена в C++.

9.2 Краткий обзор проектирования

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

Как показано на рис.9.2.1, каждая программа в системе состоит:

• из основной программы;

• из четырех архитектурных классов;

• из некоторого количества прикладных классов.

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

Рис.9.2.1. Программные компоненты, предписанные данной архитектурой,

Три архитектурных класса - Конечная Модель Состояний, Переход и Активный Экземпляр - обеспечивают механизмы, необходимые для инициализации и выполнения конечных автоматов. Четвертый архитектурный класс - Таймер -обеспечивает механизм, аналогичный объекту Таймер в ООА.

Прикладные классы аналогичны и получаются из объектов и моделей состояний ООА. Каждый класс отвечает за ту же деятельность, которую выполняет его аналог в ООА.