Материал: 4970

61

вый сценарий должен описывать достижение основной, главной цели. Такой сценарий является «ядром» моделируемой программной системы. Все последующие сценарии должны быть уточняющими и расширяющими функциональность ядра системы. Принцип последовательного наращивания функциональности применяется в итерационном и RUP проектировании, а метод сценариев хорошо дополняет этот принцип. Исполнителями ролей в таких сценариях могут быть как пользователи, так и компьютерные системы. Напомним, что на основании сценариев выполняется построение диаграмм вариантов использования, основанных на прецедентах.

Назначение диаграммы вариантов использования:

–формирование требований к проектируемой системе;

–осмысление и осознание поведения системы проектировщиком;

–проверка правильности и полноты созданного ранее перечня сущностей

(каждая сущность должна в том или ином виде присутствовать в описании прецедентов, т.е. быть «задействована» в одном из сценариев).

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

При составлении диаграммы вариантов использования применяются следующие структурные элементы языка UML:

1)аннотационные сущности – пояснительные части к элементам диаграмм модели UML, иначе, комментарии для дополнительного описания (рисунок 12);

2)прецеденты (действия) – изображаются в виде овала с надписью, содержание надписи соответствует наименованию функции, выявленной на этапе декомпозиции, при этом надпись должна иметь форму глагола или отглагольного существительного (см. рисунок 13);

3)роли – инициаторы выполнения прецедентов, роли играют внешние сущности по отношению к вариантам использования при взаимодействии с ними, при этом графическим обозначением роли на диаграммах является метафора фигуры человека, под которой записывается имя роли;

4)отношения – отображают характер связи между структурными элементами диаграммы.

Рисунок 13 – Пример фрагмента диаграммы вариантов использования

На рисунке 13 изображён элемент в виде папки, который относится к структурным элементам языка UML и называется «пакет». Наименование пакета «Идентификация клиента». Пакеты предназначены для визуализации систем и подсистем с целью обзорности структуры и разумной ограниченности рассматриваемых моделей (например, сценариями удачных выполнений действий). Пакеты могут включать в себя другие, вложенные, пакеты (рекомендуется не более трёх уровней вложенности). Между пакетами могут иметь место стандартные отношения (см. далее). Пример визуализации систем при помощи пакетов приведён на рисунке 14. На рисунке 15 не указана принадлежность прецедентов к пакетам с целью акцентирования внимания читателя на применении отношений, тем не менее пакеты подразумеваются по умолчанию, т.к. сами диаграммы не могут «висеть в воздухе» и не принадлежать какой-либо модели.

Вид системы с точки зрения реализации

Сценарий 1 Сценарий 2

Рисунок 14 – Пример визуализации систем при помощи пакетов

В языке UML имеется несколько стандартных видов отношений, которые применяются для построения диаграмм вариантов использования:

63

1)ассоциации (association relationship);

2)включения (include relationship);

3)расширения (extend relationship);

4)обобщения (generalization relationship) .

Отношение ассоциации – это одно из основных понятий в языке UML. Применительно к диаграммам вариантов использования ассоциация служит для обозначения связи роли с действием (т.е. отдельным вариантом использования или прецедентом). Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, возможно, посылая или принимая сообщения. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между ролью и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность (количество результатов). Пример отношений ассоциации приведён на рисунке 15.

Отношение включения – это разновидность отношения зависимости между базовым вариантом использования и его специальным частным случаем. Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента при выполнении другого варианта использования. В этом смысле поведение первого варианта использования является частью поведения второго варианта использования. Отношение ассоциации обозначается пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия имеет пояснение в виде наименования <<include>>. Такие специальные наименования называются стереотипами. Таким образом, выполнение базового (включающего) варианта использования включает в себя последовательность действий, которая определена для включаемого варианта использования. При этом выполнение включаемой последовательности действий происходит всегда при инициировании базового варианта использования. Один вариант использования может входить в несколько других вариантов использования, а также содержать в себе другие варианты. Включаемый вариант использования является независимым от базового варианта. Пример отношения <<include>> приведён на рисунке 15.

Отношение расширения определяет взаимосвязь базового варианта использования с другим вариантом использования, функционал которого используется не всегда, а только при выполнении дополнительных условий. Отношение расши-

64

рения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <<extend>>. Пример отношения <<extend>> приведён на рисунке 15.

Отношение обобщения определяет взаимосвязь базового варианта использования с другим вариантом использования, который является разновидностью базового варианта использования. Иными словами, имеет место отношение «предок − потомок». Пример подобных отношений мы приводили при обсуждении виртуальных функций («оплата кредита»  «клерк банка принимает оплату наличными»). Графически отношение обобщения обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования. Пример отношения обобщения приведён на рисунке 15.

Обращаем внимание читателя на то, что количество элементов диаграмм должно соответствовать текущей итерационной стадии разработки проекта. Иными словами, не следует пытаться объять всю предметную область за одну попытку, так как при этом диаграмма UML потеряет свою значимость с точки зрения достижения понятности и визуальной ясности. Необходимо строить модели подсистем исходя из границ, описанных в сценариях, а сами модели изображать в виде пакетов. Пакеты моделей подсистем, в свою очередь, следует связывать отношениями (ассоциации, включения; расширения; обобщения).

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