2.5.1.2. Создание диаграмм Классов

В среде Rose диаграммы Классов создаются в Логическом представлении модели.

По мере добавления на диаграмму новых классов и связей она постепенно становится все более за­хламленной и трудной для восприятия. Rose способна автоматически приводить в порядок все классы на диаграмме.

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

2.5.1.3. Работа с классами

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

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

2.5.1.3.1. Спецификации классов

Б ольшинство определяемых для класса параметров доступно в окне спецификации класса (см. рис.14). В частности, это окно позволяет указать стереотип класса, а также его видимость и устойчивость (persistence).

Рис.14. Окно спецификации класса

2.5.1.3.2. Именование классов

Каждому классу модели Rose необходимо дать уникальное имя. Большинство организаций имеет собст­венные соглашения по именованию классов. В общем случае используются существительные в единст­венном числе. Обычно имена классов не содержат пробелов. Используемый для именования классов регистр символов определяется обычно организацией. Важно только, чтобы принятый подход применялся ко всем клас­сам модели.

2.5.1.3.3. Назначение стереотипа для класса

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

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

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

Р ис.15. Место нахождения пограничного класса “Форма ввода поручения”

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

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

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

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

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

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

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