4. Диаграммы языка uml[1/1].

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций – диаграмм.

В терминах языка UML представлены следующие виды диаграмм:

I. Диаграмма вариантов использования (Use case diagram) (*)

II. Диаграмма классов (Class diagram) (*)

III. Диаграмма поведения (Behavior diagram)

Делится на следующие диаграммы:

1) Диаграмма состояния (Statechart diagram) (*)

2) Диаграмма деятельности (Activity diagram) (*)

3) Диаграмма взаимодействия (Interaction diagram)

Делится на следующие диаграммы:

a) Диаграмма последовательности (Sequence diagram) (*)

b) Диаграмма кооперации (Collaboration diagram) (*)

IV. Диаграмма реализации (Implementation diagram)

Делится на следующие диаграммы:

1) Диаграмма компонентов (Component diagram) (*)

2) Диаграмма развертывания (Deployment diagram) (*)

Из всех видов диаграмм некоторые служат для обозначения двух или более других подвидов диаграмм. При этом в качестве самостоятельных, используются только диаграммы обозначенные (*).

5. Диаграмма вариантов использования[1/2].

Use case diagram – это графическое представление взаимодействия пользователя и компьютерной системы. Каждый use case охватывает очевидную для пользователя функцию системы и решает некоторую дискретную задачу пользователя. Список всех use case’ов фактически определяет функциональные требования к системе, с помощью которых может быть сформулировано техническое задание.

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

Use case diagram явл-ся исходным концептуальным представлением и ее разработка преследует след. цели:

1) Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

2) Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

Суть Use case diagram состоит в следующем: проектируемая система представляется в виде множества сущностей (актеров), взаимодействующих с системой с помощью так называемых use case’ов.

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

Актеры позволяют узнать:

1) Кто пользуется системой.

2) Кто отвечает за сопровождение системы.

3) Внешнее аппаратное обеспечение, которое использует система.

4) Другие системы, которые должны взаимодействовать с данной системой.

*5. Диаграмма вариантов использования[2/2].

Use case служит для описания сервисов, которые система предоставляет актеру. Каждый use case определяет некоторый набор действий системы при диалоге с актером. При этом ничего не говорится о том, каким образом будет организовано взаимодействие актеров с системой.

Кроме use case и actor элементами данной диаграммы явл-ся интерфейс (Interface) и примечание (Note).

Interface служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры.

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

Пример:

Система продажи товаров по каталогу.

Любой из use case может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность.

Рекомендуемое общее кол-во актеров ≤ 20, а use case ≤ 50 иначе модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм. Все сервисы системы должны быть явно определены на диаграмме use case и никаких других сервисов, которые отсутствуют на данной диаграмме, система не может выполнить!