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

дисциплине» включают прецедент «Регистрация преподавателя

в системе». Поэтому, разместив все три прецедента на дополнитель­ ной диаграмме, мы должны установить между ними включающее от­ ношение. Для этого необходимо на панели инструментов щелкнуть на пиктограмму «Dependency or instantiates», провести связи анало­ гично тому, как это было сделано на основной диаграмме, и опреде­ лить стереотип «include».

Окончательный вид дополнительной диаграммы представлен на рис. 4.16.

4.3. Подведение итогов

Построение диаграммы прецедентов является самым первым этапом процесса проектирования информационной системы, цель ко­ торого - представить совокупность требований к поведению проек­ тируемой системы. Спецификация требований к проектируемой сис­ теме в форме диаграммы прецедентов представляет собой самостоя­ тельную модель, которая в языке UML получила название модели прецедентов (вариантов использования) и имеет свое специальное стандартное имя или стереотип «UseCaseModel».

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

Перед именем атрибута может быть указан квантор видимости. Квантор видимости принимает одно из трех возможных значений и, со­ ответственно, отображается при помощи специальных символов [2]:

-символ «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости досту­ пен или виден из любого другого класса пакета, в котором определе­ на диаграмма;

-символ «#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недос­ тупен или не виден для всех классов, за исключением подклассов данного класса;

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

Квантор видимости может быть опущен. В этом случае его отсут­ ствие просто означает, что видимость атрибута не указывается. До­ пускается вместо графических символов указывать стереотип: «public», «protected», «private».

Операцией (operation) называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на пове­ дение. Иными словами, операция - это абстракция того, что позволе­ но делать с объектом [1]. У всех объектов класса имеется общий на­ бор операций. Класс может содержать любое число операций или не содержать их вовсе. Операции указываются после перечисления атрибутов (рис. 5.3).

Датчик

Тип

Марка

Расположение Мин. уровень Макс, уровень Ед. измерения

Сбросить

Операции

Опросить

Рис. 5.3. Операции класса

Совокупность операций характеризует функциональный аспект поведения класса. Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным и его имя записывается курсивом.

Интерфейсом (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). Обеспечивают координа­ цию поведения объектов в системе. На ранних стадиях жизненного цикла системы для каждой пары актер/прецедент создается по одно­ му классу управления, на который возлагаются обязанности по кон­ тролю над потоком событий, происходящих по мере выполнения это­ го прецедента.