книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода

Интерфейсом (interface) называется набор операций, используе­ мый для специфицирования услуг, предоставляемых классом. Интер­ фейс определяет видимые извне операции без указания их реализации.

Интерфейсы именуются так же, как и классы. Графически интер­ фейс изображается в виде кружка, рядом с которым указывается его имя (рис. 5.4).

Оо

Рис. 5.4. Изображение интерфейса

Отношения между классами, интерфейсами. Между классами, интерфейсами могут существовать следующие отношения: зависимо­ сти, ассоциации, обобщения и реализации.

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

Рис. 5.5. Пример зависимости

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

Возможные варианты кратности представлены ниже: 0..0 ноль; 0..1 ноль или один;

0..и ноль или много; 1..1 один; \..п один или много;

п неопределенное (любое) число; <число> точное число (например, 5);

<число>..и точное число или больше (например, 5..п означает 5

или больше); <число>..<число> определяет диапазон (например, 5.. 15);

<число>. .<число>, <число> определяет диапазон или точное чис­

ло (например, 5.. 15,25); <число>..<число>, <число>..<число> определение ряда диапазо­

нов (например, 5.. 15,25..30).

Если кратность отношения ассоциации не указана, то по умолча­ нию принимается ее значение, равное 1. Графически ассоциация изо­ бражается в виде линии, соединяющей класс сам с собой или с дру­ гими классами или интерфейсами. На рис. 5.6 представлен пример

ассоциации.

Рис. 5.6. Пример ассоциации

Ассоциации может быть присвоено имя, описывающее природу отношения. На рис. 5.6 представлена бинарная ассоциация, т.е. со­ единяющая два класса. Ассоциации, связывающие более двух клас­ сов, называются и-арными.

Рис. 5.7. Пример агрегирования

Частным случаем ассоциации является отношение агрегации,

в котором один из классов имеет более высокий ранг (целое) и состо­ ит из нескольких меньших по рангу (частей). Агрегация причислена к отношениям типа «имеет» (с учетом того, что объект-целое имеет

Обобщение - это отношение между общей сущностью (родителем или предком) и ее конкретным воплощением (потомком). Обобщения иногда называют отношениями типа «является», имея в виду, что одна сущность (например, класс «Преподаватель») является частным выра­

жением другой, более общей (скажем, класса «Работник вуза»).

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

стрелкой, направленной на родителя (рис. 5.9).

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

ей с большой незакрашенной стрелкой (рис. 5.10).

Рис. 5.10. Пример реализации

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

Стереотипы классов. Выделяют три стереотипа классов [4].

1.Граничные классы (boundary classes). Служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каж­ дой пары актер/прецедент определяется один граничный класс.

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

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

5.2. Реализация в Rational Rose

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

Исходя из предметной области разрабатываемой системы, сразу можно выделить следующие классы сущностей: «Пользователь», «Преподаватель», «Студент», «Сотрудник деканата», «Дисциплина»

и«Предложение дисциплины».

Всистеме Rational Rose диаграмма классов является основой для генерации кода программы, поэтому названия классов, атрибутов, операций необходимо вводить на английском языке (в противном случае при генерации кода символы кириллицы будут заменены восьмеричным кодом).

Втабл. 5.1 представлены соответствующие английские названия вышеперечисленных классов.

Создадим классы, представленные в таблице. Для этого в окне браузера выделим элемент «Logical View», вызовем контекстное ме­ ню и выберем пункт «New», а затем «Class». В результате этого будет создан новый класс. Назовем его «SysUser». Так как этот и все пере­ численные в таблице классы являются классами сущностей, то сразу укажем соответствующий стереотип для созданного класса, открыв окно спецификации класса и выбрав стереотип «entity» (рис. 5.11).