Подтип-Супертип

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

Если класс подтипа или супертипа имеет модель состояний, она также должна быть унаследована от Активного Экземпляра. Таким образом, структура наследования, включающая подтипы и супертипы, может принимать любую из четырех форм, показанных на рис.9.6.1.

Рис.9.6.1. Связи наследования для классов подтипа и супертипа.

Сервисные домены

Если экземплярам прикладного класса необходим экземпляр двойника класса из сервисного домена, связь наследования может быть установлена между классом в сервисном домене (предок) и классом в прикладном домене (потомок). Это может привести к структуре, подобной той, которая показана на рис.9.6.2.

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

Рис.9.6.2. Структура наследования использована для установления двойника в экземплярах сервисного домена.

9.7 Схемы структуры класса для прикладных классов

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

Схема структуры класса для пассивного класса

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

Рис.9.7.1. Вид завершенной схемы структуры класса.

Рис.9.7.2. Образец схемы структуры класса пассивного класса.

Схема структуры класса для активного класса

Активный класс имеет довольно сложную схему структуры, которая лучше всего может быть описана в четырех частях:

• инициализация;

• аксессоры;

• тейкеры событий;

• действия.

Инициализация. Две общедоступные операции предоставлены для инициализации активного класса: Установить и Загрузить КМС. Часть схемы структуры класса, которая описывает операции инициализации, показана на рис.9.7.3. Обратите внимание на использование данных класса: myfsm - переменная, используемая для сохранения дескриптора КМС класса. Также считается, что переходы являются данными класса, поскольку они применяются одинаково ко всем экземплярам класса.

Рис.9.7.3. Образец раздела инициализации схемы структуры класса для активного класса.

Аксессоры. Часть схемы структуры класса, содержащая аксессоры для активного класса, получается механически из диаграммы класса таким же образом, как и для пассивного класса.

Тейкеры событий. Часть схемы структуры класса для операции Затребовать Событие показана на рис.9.7.4. Эта операция находит дескриптор для КМС, принадлежащей классу, и вызывает Активным Экземпляр.Совершить Событие, который возвращает новое состояние. Затем она выполняет соответствующее действие, данное новым состоянием. Не забудьте, что если номер состояния, возвращенный из операции Совершить Событие, - нуль, то это значит, что не должно выполняться никакое действие, если номер состояния меньше чем нуль, то это значит, что встретилось событие, которое не может произойти.

Операция Затребовать и Создать заставляет новый экземпляр создаваться из данных события. Из-за того что эта работа выполняется в действии состояния создания, операция Затребовать и Создать просто передает управление действию состояния создания. Часть схемы структуры класса для операции Затребовать и Создать показана на рис.9.7.4.

Действия. Часть схемы структуры класса, имеющей дело с действием, создается довольно-таки механически из ДПДД. Сначала создают необщедоступную операцию, именованную <объект>.Действие <k>, где k - номер состояния, с которым связано действие. Эта операция вызывается только из тейкеров событий того же класса, и поэтому необщедоступна.

Операция Действие <k> (модуль) получает как ввод все данные события, которые обеспечиваются как ввод для тейкера события. Затем модуль выполняется для вызова модулей, соответствующих аксессорам, проверкам, преобразованиям и генераторам событий, показанным на ДПДД. Цель модуля Действие <k> состоит в том, чтобы вызывать эти отдельные модули в требуемом порядке, брать вывод одного модуля и использовать его как ввод для следующего. В этом смысле модуль Действие <k> выполняется, как установлено на ДПДД. Это легко заметить сравнением рис.9.7.5 и соответствующей ДПДД на рис.б.2.6.

Для создания модулей, соответствующих процессам на ДПДД, соблюдают следующие соглашения:

• Если процесс является аксессором, назначенным к другому классу, то это показывают с помощью символа -пятиугольника-козырька. Аксессор уже будет определен как общедоступная операция на диаграмме класса другого класса.

• Если процесс является общедоступным аксессором, предназначенным для этого класса, рисуют, при возможности графического размещения, линию вызова от модуля Действия <k> к модулю аксессора на этой схеме структуры класса. В противном случае повторяют модуль аксессора в сегменте действия схемы структуры класса и аннотируют его для указания того, что это -общедоступная операция, описанная в другом месте на той же схеме структуры класса.

• Если процесс является проверкой или преобразованием, соответствующий модуль - необщедоступная операция этого класса. Определите входные и выходные параметры модуля, соответствующие вводам и выводам данных, показанным на ДПДД.

• Если процесс является проверкой, определите дополнительный выходной параметр; который передает данные, сообщающие результат проверки. Это является переприведением вывода управления ДПДД в данных. Модуль действия <k> будет использовать дополнительный .выходной параметр для определения того, какие модули вызывались во время выполнения действия.

• Если процесс - генератор событий, показывают вызов соответствующего общедоступного тейкера события либо в этом, либо другом классе.

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

Схема структуры для определительного класса

Схема структуры класса определительного класса очень подобна схеме для активного класса. Она составляется из трех разделов:

• инициализации;

• тейкеров событий;

• действий.

Инициализация. Образец раздела инициализации схемы структуры класса показан на рис.9.7.6. Обратите внимание, что дескриптор для одиночного экземпляра класса сохраняется как данные класса.

Рис.9.7.4. Образец операций Затребовать и Создать и Создать для активного класса.

Рис.9.7.5. Часть схемы структуры класса для класса Изменение Температуры. Сравните с соответствующей ДПДД, показанной на рис. 6.2.6.

Тейкеры событий. Образец тейкера события определительного класса дан на рис.9.7.7.

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