Практика 10. Типы классов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Назначить стереотип классу можно следующим образом:

• Откройте окно спецификации класса.

• В раскрывающемся списке выберите нужный стереотип или введите его сами.