5.9. Назначение стереотипа класса

5.9.1. Общие сведения

Стереотип - это механизм, позволяющий категоризировать классы. Допустим, стоит задача найти все формы в модели. Для этого можно создать стереотип Form (Форма) и назначить его всем окнам приложения. В дальнейшем при поиске форм нужно только искать классы с этим стереотипом. На языке UML определены три основных стереотипа: Boundary (Граница), Entity (Объект) и Cont­rol (Управление). В среде Rational Rose их значительно больше.

5.9.2. Пограничные классы

Пограничными классами (Boundary Classes) называются такие классы, которые расположены на границе системы со всем остальным миром. Они включают в себя формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. Обозначение пограничного класса, принятое в UML приведено на рис 5.5.

Рисунок 5.5. Обозначение пограничного класса.

Для выявления пограничных классов необходимо исследовать диаграммы прецедентов. Для каждого взаимодействия между актером и прецедентом должен су­ществовать хотя бы один пограничный класс (рис. 5.6). Именно он позволяет актеру взаимодействовать с системой.

Рисунок 5.6. Актер, взаимодействующий с системой посредством пограничного класса.

Необязательно создавать уникальные пограничные классы для каждой пары "актер — прецедент". Например, если два актера иниции­руют один и тот же прецедент, они могут использовать общий пограничный класс для взаимодействия с системой (рис. 5.7).

Изучение диаграмм прецедентов помогает обнаружить пограничные классы.

Рисунок 5.7. Два актера, взаимодействующие с системой посредством одного пограничного класса.

5.9.3. Классы-сущности

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

Рисунок 5.8. Обозначение класса-сущности.

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

5.9.4.Управляющие классы

Управляющие классы (control classes) отвечают за координацию действий других классов. Часто у прецедента имеется один управляющий класс, контролирующий последователь­ность событий этого прецедента.

Такой класс не несет в себе никакой функциональности - остальные классы посылают ему мало сообщений. Но сам он посылает множество сообщений. Управ­ляющий класс делегирует ответственность другим классам. По этой причине управляющий класс час­то называют классом-менеджером. Внешний вид управляющего класса приведен на рис. 5.9.

Рисунок 5.9. Обозначение управляющего класса.

В системе могут применяться управляющие классы, общие для нескольких прецедентов. Например, класс SecurityManager (Менеджер безопасности) может отвечать за конт­роль событий, связанных с безопасностью, а класс TransactionManager (Менеджер транзакций) - заниматься координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и дру­гие менеджеры для работы с такими элементами функционирования системы, как разделение ресур­сов, распределенная обработка данных и обработка ошибок.

С помощью управляющих классов можно изолировать функциональность системы. Инкапсуляция в один класс, например, координации безопасности минимизирует последствия вносимых измене­ний. Любые изменения отвечающей за безопасность логики системы затронут только менеджера бе­зопасности.

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

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

Для вывода имени стереотипа на диаграмму щёлкните правой кнопкой мыши на классе диаграммы классов. В открывшемся меню выберите пункт Options > Stereotype Display > Label (Параметры > По­каз стереотипа > Метка). Над именем этого класса появится имя стереотипа, заключенное в двойные угловые скобки (« »).

Если нужно показать пиктограмму стереотипа на диаграмме, щелкните правой кнопкой мыши на классе диаграммы классов. В открывшемся меню выберите пункт Options > Stereotype Display > Icon (Параметры > Показ стереотипа > Пиктограмма). Представление класса на диаграмме изменится в соответствии с используемой пиктограммой.

Не у всех стереотипов есть пиктограммы. Если у стереотипа нет значка, появится только его имя.

Отключить показ стереотипов на диаграмме можно следующим образом. Щелкните правой кнопкой мыши на классе диаграммы классов. В открывшемся меню выберите пункт Options > Stereotype Display > None (Параметры > По­каз стереотипа > Ничего). У класса по-прежнему будет стереотип, видимый в окне специфика­ции, но не отображаемый на диаграмме.

В среде Rational Rose существует возможность назначать собственные стереотипы и определять для них пиктограммы, посредством модификации *.ini файла.