SlideShare a Scribd company logo
1 of 34
Диаграмма вариантов 
использования 
(use case diagram)
Визуальное моделирование в UML можно 
представить как некоторый процесс поуровневого 
спуска от наиболее обшей и абстрактной 
концептуальной модели исходной системы к 
логической, а затем и к физической модели 
соответствующей программной системы. Для 
достижения этих целей вначале строится модель в 
форме так называемой диаграммы вариантов 
использования (use case diagram), которая описывает 
функциональное назначение системы или, другими 
словами, то, что система будет делать в процессе 
своего функционирования. Диаграмма вариантов 
использования является исходным концептуальным 
представлением или концептуальной моделью 
системы в процессе ее проектирования и разработки.
Суть use-case диаграммы состоит в следующем: 
проектируемая система представляется в виде 
множества сущностей или актеров, 
взаимодействующих с системой с помощью так 
называемых вариантов использования. 
Актером (actor) или действующим лицом 
называется любая сущность, взаимодействующая 
с системой извне. 
В свою очередь, вариант использования (use case) 
служит для описания сервисов, которые система 
предоставляет актеру. 
При этом ничего не говорится о том, каким 
образом будет реализовано взаимодействие 
актеров с системой.
Варианты использования 
Каждый вариант использования соответствует 
отдельному сервису, который предоставляет 
моделируемую сущность или систему по запросу 
пользователя (актера), т. е. определяет способ 
применения этой сущности. 
Варианты использования описывают не только 
взаимодействия между пользователями и 
сущностью, но также реакции сущности на 
получение отдельных сообщений от 
пользователей и восприятие этих сообщений за 
пределами сущности.
Множество вариантов использования в целом 
должно определять все возможные стороны 
ожидаемого поведения системы. 
Отдельный вариант использования обозначается 
на диаграмме эллипсом, внутри которого 
содержится его краткое название или имя в форме 
глагола с пояснительными словами
Актеры 
Актер представляет собой любую внешнюю по 
отношению к моделируемой системе сущность, 
которая взаимодействует с системой и 
использует ее функциональные возможности 
для достижения определенных целей или 
решения частных задач. Каждый актер может 
рассматриваться как некая отдельная роль 
относительно конкретного варианта 
использования.
Стандартным графическим 
обозначением актера на диаграммах 
является фигурка "человечка", под 
которой записывается конкретное 
имя актера. 
В некоторых случаях актер может 
обозначаться в виде прямоугольника класса с 
ключевым словом "актер" и обычными 
составляющими элементами класса. 
Имена абстрактных актеров, как и других 
абстрактных элементов языка UML, 
рекомендуется обозначать курсивом.
Интерфейсы 
Интерфейсы определяют совокупность 
операций, которые обеспечивают 
необходимый набор сервисов или 
функциональности для актеров. Интерфейсы не 
могут содержать ни атрибутов, ни состояний, 
ни направленных ассоциаций. Они содержат 
только операции без указания особенностей их 
реализации.
На диаграмме вариантов использования 
интерфейс изображается в виде маленького 
круга, рядом с которым записывается его имя. 
Если имя записывается на английском, то оно 
должно начинаться с заглавной буквы I
Графический символ отдельного интерфейса 
может соединяться на диаграмме сплошной 
линией с тем вариантом использования, 
который его поддерживает. Сплошная линия в 
этом случае указывает на тот факт, что 
связанный с интерфейсом вариант 
использования должен реализовывать все 
операции, необходимые для данного 
интерфейса, а возможно и больше.
Кроме этого, интерфейсы могут соединяться с 
вариантами использования пунктирной линией 
со стрелкой, означающей, что вариант 
использования предназначен для спецификации 
только того сервиса, который необходим для 
реализации данного интерфейса.
Примечания 
Примечания (notes) в языке UML предназначены 
для включения в модель произвольной 
текстовой информации, имеющей 
непосредственное отношение к контексту 
разрабатываемого проекта. В качестве такой 
информации могут быть комментарии 
разработчика (например, дата и версия 
разработки диаграммы или ее отдельных 
компонентов), ограничения (например, на 
значения отдельных связей или экземпляры 
сущностей) и помеченные значения.
Графически примечания обозначаются 
прямоугольником с "загнутым" верхним правым 
уголком. Внутри прямоугольника содержится 
текст примечания. Примечание может 
относиться к любому элементу диаграммы, в 
этом случае их соединяет пунктирная линия.
Если в примечании указывается ключевое слово 
"constraint", то данное примечание является 
ограничением, налагаемым на соответствующий 
элемент модели, но не на саму диаграмму.
Отношения на диаграмме вариантов 
использования 
В языке UML имеется несколько стандартных 
видов отношений между актерами и 
вариантами использования: 
- Отношение ассоциации (association 
relationship) 
- Отношение расширения (extend relationship) 
- Отношение обобщения (generalization 
relationship) 
- Отношение включения (include relationship)
Отношение ассоциации 
Применительно к диаграммам вариантов 
использования оно служит для обозначения 
специфической роли актера в отдельном 
варианте использования. Обозначается 
сплошной линией между актером и вариантом 
использования.
Отношение расширения 
Отношение расширения отмечает тот факт, что 
один из вариантов использования может 
присоединять к своему поведению некоторое 
дополнительное поведение, определенное для 
другого варианта использования. 
Если имеет место отношение расширения от 
варианта использования А к варианту 
использования В, то это означает, что свойства 
экземпляра варианта использования В могут 
быть дополнены благодаря наличию свойств у 
расширенного варианта использования А.
Отношение расширения между вариантами 
использования обозначается пунктирной линией 
со стрелкой (вариант отношения зависимости), 
направленной от того варианта использования, 
который является расширением для исходного 
варианта использования. Данная линия со 
стрелкой помечается ключевым словом "extend" 
("расширяет").
Семантика отношения расширения определяется 
следующим образом. Если экземпляр варианта 
использования выполняет некоторую 
последовательность действий, которая 
определяет его поведение, и при этом имеется 
точка расширения на экземпляр другого 
варианта использования, то проверяется условие 
данного отношения. Если условие выполняется, 
исходная последовательность действий 
расширяется посредством включения действий 
экземпляра другого варианта использования.
При оформлении заказа на приобретение 
товара условием расширения является 
запрос от клиента на получение каталога 
товаров.
Отношение обобщения 
Служит для указания того факта, что некоторый 
вариант использования А может быть обобщен 
до варианта использования В. При этом В 
называется предком или родителем по 
отношению А, а вариант А - потомком по 
отношению к варианту использования В (Иногда 
говорят «А являться специализацией варианта 
В»). 
Потомок наследует все свойства и поведение 
своего родителя, а также может быть дополнен 
новыми свойствами и особенностями 
поведения.
Данное отношение обозначается сплошной 
линией со стрелкой в форме незакрашенного 
треугольника, которая указывает на 
родительский вариант использования.
Между отдельными актерами также может 
существовать отношение обобщения. Данное 
отношение является направленным и указывает 
на факт специализации одних актеров 
относительно других. Отношение обобщения от 
актера А к актеру В отмечает тот факт, что 
каждый экземпляр актера А является 
одновременно экземпляром актера В и 
обладает всеми его свойствами.
Отношение включения 
Отношение включения между двумя 
вариантами использования указывает, что 
некоторое заданное поведение для одного 
варианта использования включается в качестве 
составного компонента в последовательность 
поведения другого варианта использования.
Отношение включения 
Отношение включения между двумя 
вариантами использования указывает, что 
некоторое заданное поведение для одного 
варианта использования включается в качестве 
составного компонента в последовательность 
поведения другого варианта использования.
Семантика этого отношения определяется 
следующим образом. Когда экземпляр первого 
варианта использования в процессе своего 
выполнения достигает точки включения в 
последовательность поведения экземпляра 
второго варианта использования, экземпляр 
первого варианта использования выполняет 
последовательность действий, определяющую 
поведение экземпляра второго варианта 
использования, после чего продолжает 
выполнение действий своего поведения.
Пример построения диаграммы вариантов 
использования 
В качестве примера рассмотрим процесс 
моделирования системы продажи товаров по 
каталогу. В качестве актеров данной системы 
могут выступать два субъекта, один из которых 
является продавцом, а другой - покупателем. 
Каждый из этих актеров взаимодействует с 
рассматриваемой системой продажи товаров по 
каталогу и является ее пользователем, т. е. они 
оба обращаются к соответствующему сервису 
"Оформить заказ на покупку товара".
Уточним вариант использования 
"Оформить заказ на покупку товара" 
на основе введения в рассмотрение 
дополнительных вариантов 
использования.
Из более детального анализа процесса продажи 
товаров можно выделить в качестве отдельных 
сервисов такие действия, как «обеспечить 
покупателя информацией о товаре», 
«согласовать условия оплаты товара» и 
«заказать товар со склада». Вполне очевидно, 
что указанные действия раскрывают поведение 
исходного варианта использования в смысле его 
конкретизации, и поэтому между ними будет 
иметь место отношение включения.
С другой стороны, продажа товаров по каталогу 
предполагает наличие самостоятельного 
информационного объекта - каталога товаров, 
который в некотором смысле не зависит от 
реализации сервиса по обслуживанию 
покупателей. Поэтому вполне резонно 
представить самостоятельный сервис 
"Запросить каталог товаров", который может 
запрашиваться покупателем или продавцом при 
необходимости выбора товара и уточнения 
деталей его продажи
Приведенная выше диаграмма вариантов 
использования, может быть детализирована далее 
с целью более глубокого уточнения предъявляемых 
к системе требований и конкретизации деталей ее 
последующей реализации. 
Так, в рамках рассматриваемой системы продажи 
товаров может иметь самостоятельное значение и 
специфические особенности отдельная категория 
товаров - компьютеры. В этом случае диаграмма 
может быть дополнена вариантом использования 
"Оформить заказ на покупку компьютера" и 
актерами "Покупатель компьютера" и "Продавец 
компьютеров", которые связаны с 
соответствующими компонентами диаграммы 
отношением обобщения
Любой из вариантов использования может быть 
подвергнут дальнейшей декомпозиции на 
множество подвариантов использования 
отдельных элементов, которые образуют 
исходную сущность. Рекомендуемое общее 
количество актеров в модели - не более 20, а 
вариантов использования - не более 50.

More Related Content

What's hot

раздел 4 проектирование и использование баз данных
раздел 4  проектирование и использование баз данныхраздел 4  проектирование и использование баз данных
раздел 4 проектирование и использование баз данных
tatianabtt
 
Моделирование как метод познания
Моделирование как метод познанияМоделирование как метод познания
Моделирование как метод познания
student_SSGA
 
0042
00420042
0042
JIuc
 
Presentation pseudo element
Presentation pseudo elementPresentation pseudo element
Presentation pseudo element
Tania Korab
 
0045
00450045
0045
JIuc
 

What's hot (20)

МАПО Лекция 14 UML Use Case
МАПО Лекция 14 UML Use CaseМАПО Лекция 14 UML Use Case
МАПО Лекция 14 UML Use Case
 
Диаграмма классов
Диаграмма классовДиаграмма классов
Диаграмма классов
 
Введення Uml
Введення UmlВведення Uml
Введення Uml
 
Диаграмма последовательности
Диаграмма последовательностиДиаграмма последовательности
Диаграмма последовательности
 
Диаграмма компонентов
Диаграмма компонентовДиаграмма компонентов
Диаграмма компонентов
 
1
11
1
 
Простой подход к проектированию сложной системы
Простой подход к проектированию сложной системыПростой подход к проектированию сложной системы
Простой подход к проектированию сложной системы
 
раздел 4 проектирование и использование баз данных
раздел 4  проектирование и использование баз данныхраздел 4  проектирование и использование баз данных
раздел 4 проектирование и использование баз данных
 
Uml
UmlUml
Uml
 
Моделирование как метод познания
Моделирование как метод познанияМоделирование как метод познания
Моделирование как метод познания
 
лр4 uml
лр4 umlлр4 uml
лр4 uml
 
Архитектурный шаблон MVC
Архитектурный шаблон MVCАрхитектурный шаблон MVC
Архитектурный шаблон MVC
 
Диаграмма вариантов использования
Диаграмма вариантов использованияДиаграмма вариантов использования
Диаграмма вариантов использования
 
Создание графического интерфейса пользователя мобильных Android приложений (ч...
Создание графического интерфейса пользователя мобильных Android приложений (ч...Создание графического интерфейса пользователя мобильных Android приложений (ч...
Создание графического интерфейса пользователя мобильных Android приложений (ч...
 
Нотация UML / UML Notation
Нотация UML / UML NotationНотация UML / UML Notation
Нотация UML / UML Notation
 
Java. Вложенные классы и интерфейсы.
Java. Вложенные классы и интерфейсы.Java. Вложенные классы и интерфейсы.
Java. Вложенные классы и интерфейсы.
 
0042
00420042
0042
 
DBD lection 3. Outer and inner joins, nested queries, user views. In Russian.
DBD lection 3. Outer and inner joins, nested queries, user views. In Russian.DBD lection 3. Outer and inner joins, nested queries, user views. In Russian.
DBD lection 3. Outer and inner joins, nested queries, user views. In Russian.
 
Presentation pseudo element
Presentation pseudo elementPresentation pseudo element
Presentation pseudo element
 
0045
00450045
0045
 

Viewers also liked

Use cases на практике
Use cases на практикеUse cases на практике
Use cases на практике
Softline
 
Управление проектами в Softline
Управление проектами в SoftlineУправление проектами в Softline
Управление проектами в Softline
Softline
 
что такое Zabbiбиxа
что такое Zabbiбиxачто такое Zabbiбиxа
что такое Zabbiбиxа
Softline
 
MySQL для высоконагруженных проектов
MySQL для высоконагруженных проектовMySQL для высоконагруженных проектов
MySQL для высоконагруженных проектов
Softline
 
Voip-телефония.Unified Communications. Биллинг телеком-услуг
Voip-телефония.Unified Communications. Биллинг телеком-услугVoip-телефония.Unified Communications. Биллинг телеком-услуг
Voip-телефония.Unified Communications. Биллинг телеком-услуг
Softline
 
Обзор современного состояния области алгоритмов и структур данных
Обзор современного состояния области алгоритмов и структур данныхОбзор современного состояния области алгоритмов и структур данных
Обзор современного состояния области алгоритмов и структур данных
Softline
 
создание команды тестирования
создание команды тестированиясоздание команды тестирования
создание команды тестирования
Softline
 
как строить небоскрёбы
как строить небоскрёбыкак строить небоскрёбы
как строить небоскрёбы
Softline
 
разработка Mvc приложений на java script
разработка Mvc приложений на java scriptразработка Mvc приложений на java script
разработка Mvc приложений на java script
Softline
 
Silex. Микрофреймворк для микроприложений
Silex. Микрофреймворк для микроприложенийSilex. Микрофреймворк для микроприложений
Silex. Микрофреймворк для микроприложений
Softline
 
инструменты веб разработчика
инструменты веб разработчикаинструменты веб разработчика
инструменты веб разработчика
Softline
 
Learn lean. Технология управления от самураев.
Learn lean. Технология управления от самураев.Learn lean. Технология управления от самураев.
Learn lean. Технология управления от самураев.
Softline
 

Viewers also liked (20)

Use cases на практике
Use cases на практикеUse cases на практике
Use cases на практике
 
Uml for students
Uml for studentsUml for students
Uml for students
 
МАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UMLМАСТЕР-КЛАСС. Моделирование на UML
МАСТЕР-КЛАСС. Моделирование на UML
 
Lev diploma
Lev diplomaLev diploma
Lev diploma
 
Create word template
Create word templateCreate word template
Create word template
 
Сreate word
Сreate wordСreate word
Сreate word
 
Инсталляторы
ИнсталляторыИнсталляторы
Инсталляторы
 
Deployment diagram
Deployment diagramDeployment diagram
Deployment diagram
 
Управление проектами в Softline
Управление проектами в SoftlineУправление проектами в Softline
Управление проектами в Softline
 
Введение в анализ требований
Введение в анализ требованийВведение в анализ требований
Введение в анализ требований
 
что такое Zabbiбиxа
что такое Zabbiбиxачто такое Zabbiбиxа
что такое Zabbiбиxа
 
MySQL для высоконагруженных проектов
MySQL для высоконагруженных проектовMySQL для высоконагруженных проектов
MySQL для высоконагруженных проектов
 
Voip-телефония.Unified Communications. Биллинг телеком-услуг
Voip-телефония.Unified Communications. Биллинг телеком-услугVoip-телефония.Unified Communications. Биллинг телеком-услуг
Voip-телефония.Unified Communications. Биллинг телеком-услуг
 
Обзор современного состояния области алгоритмов и структур данных
Обзор современного состояния области алгоритмов и структур данныхОбзор современного состояния области алгоритмов и структур данных
Обзор современного состояния области алгоритмов и структур данных
 
создание команды тестирования
создание команды тестированиясоздание команды тестирования
создание команды тестирования
 
как строить небоскрёбы
как строить небоскрёбыкак строить небоскрёбы
как строить небоскрёбы
 
разработка Mvc приложений на java script
разработка Mvc приложений на java scriptразработка Mvc приложений на java script
разработка Mvc приложений на java script
 
Silex. Микрофреймворк для микроприложений
Silex. Микрофреймворк для микроприложенийSilex. Микрофреймворк для микроприложений
Silex. Микрофреймворк для микроприложений
 
инструменты веб разработчика
инструменты веб разработчикаинструменты веб разработчика
инструменты веб разработчика
 
Learn lean. Технология управления от самураев.
Learn lean. Технология управления от самураев.Learn lean. Технология управления от самураев.
Learn lean. Технология управления от самураев.
 

Similar to Use-case diagram

язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)
romachka_pole
 
Проектирование программных систем. Занятие 3
Проектирование программных систем. Занятие 3Проектирование программных систем. Занятие 3
Проектирование программных систем. Занятие 3
Dima Dzuba
 
Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UML
Sergey Nemchinsky
 
Классы и объекты в Java
Классы и объекты в JavaКлассы и объекты в Java
Классы и объекты в Java
metaform
 
Тема 3. Модели и закономерности систем
Тема 3. Модели и закономерности системТема 3. Модели и закономерности систем
Тема 3. Модели и закономерности систем
Сергей Солнечный
 
о моделях
о моделяхо моделях
о моделях
serge_luch
 
tema1
tema1tema1
tema1
comp
 
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
7bits
 
Unified modeling language basic-part 1
Unified modeling language basic-part 1Unified modeling language basic-part 1
Unified modeling language basic-part 1
ISsoft
 
лекция 7
лекция 7лекция 7
лекция 7
cezium
 

Similar to Use-case diagram (20)

язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)
 
Uml Glossary
Uml GlossaryUml Glossary
Uml Glossary
 
Проектирование программных систем. Занятие 3
Проектирование программных систем. Занятие 3Проектирование программных систем. Занятие 3
Проектирование программных систем. Занятие 3
 
UML_Yznaika.com.pptx
UML_Yznaika.com.pptxUML_Yznaika.com.pptx
UML_Yznaika.com.pptx
 
Лекция 1. UML (use cases)
Лекция 1. UML (use cases)Лекция 1. UML (use cases)
Лекция 1. UML (use cases)
 
Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UML
 
Лекция 2. UML (static logical model)
Лекция 2. UML (static logical model)Лекция 2. UML (static logical model)
Лекция 2. UML (static logical model)
 
Prez
PrezPrez
Prez
 
UML: Kinds of Diagram
UML:  Kinds of DiagramUML:  Kinds of Diagram
UML: Kinds of Diagram
 
Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"
 
Классы и объекты в Java
Классы и объекты в JavaКлассы и объекты в Java
Классы и объекты в Java
 
Практический анализ по RUP
Практический анализ по RUPПрактический анализ по RUP
Практический анализ по RUP
 
Тема 3. Модели и закономерности систем
Тема 3. Модели и закономерности системТема 3. Модели и закономерности систем
Тема 3. Модели и закономерности систем
 
UML (basics of)
UML (basics of)UML (basics of)
UML (basics of)
 
о моделях
о моделяхо моделях
о моделях
 
tema1
tema1tema1
tema1
 
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
Стажировка-2013, разработчики, занятие 3. Абстракции, контракты, соглашения (...
 
структура языка UML
структура языка UMLструктура языка UML
структура языка UML
 
Unified modeling language basic-part 1
Unified modeling language basic-part 1Unified modeling language basic-part 1
Unified modeling language basic-part 1
 
лекция 7
лекция 7лекция 7
лекция 7
 

More from aepetelin (14)

защита информации 10
защита информации 10защита информации 10
защита информации 10
 
защита информации 9
защита информации 9защита информации 9
защита информации 9
 
информационная безопасность человека
информационная безопасность человекаинформационная безопасность человека
информационная безопасность человека
 
криптография
криптографиякриптография
криптография
 
защита информации 5
защита информации 5защита информации 5
защита информации 5
 
защита информации 4
защита информации 4защита информации 4
защита информации 4
 
защита информации 3
защита информации 3защита информации 3
защита информации 3
 
защита информации 2
защита информации 2защита информации 2
защита информации 2
 
защита информации 1
защита информации 1защита информации 1
защита информации 1
 
Installers
InstallersInstallers
Installers
 
Creating a word file by a template
Creating a word file by a templateCreating a word file by a template
Creating a word file by a template
 
06 still
06 still06 still
06 still
 
исиб
исибисиб
исиб
 
Creating a word file
Creating a word fileCreating a word file
Creating a word file
 

Use-case diagram

  • 2. Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
  • 3. Суть use-case диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
  • 4. Варианты использования Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемую сущность или систему по запросу пользователя (актера), т. е. определяет способ применения этой сущности. Варианты использования описывают не только взаимодействия между пользователями и сущностью, но также реакции сущности на получение отдельных сообщений от пользователей и восприятие этих сообщений за пределами сущности.
  • 5. Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы. Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами
  • 6. Актеры Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования.
  • 7. Стандартным графическим обозначением актера на диаграммах является фигурка "человечка", под которой записывается конкретное имя актера. В некоторых случаях актер может обозначаться в виде прямоугольника класса с ключевым словом "актер" и обычными составляющими элементами класса. Имена абстрактных актеров, как и других абстрактных элементов языка UML, рекомендуется обозначать курсивом.
  • 8. Интерфейсы Интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации.
  • 9. На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя. Если имя записывается на английском, то оно должно начинаться с заглавной буквы I
  • 10. Графический символ отдельного интерфейса может соединяться на диаграмме сплошной линией с тем вариантом использования, который его поддерживает. Сплошная линия в этом случае указывает на тот факт, что связанный с интерфейсом вариант использования должен реализовывать все операции, необходимые для данного интерфейса, а возможно и больше.
  • 11. Кроме этого, интерфейсы могут соединяться с вариантами использования пунктирной линией со стрелкой, означающей, что вариант использования предназначен для спецификации только того сервиса, который необходим для реализации данного интерфейса.
  • 12. Примечания Примечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения.
  • 13. Графически примечания обозначаются прямоугольником с "загнутым" верхним правым уголком. Внутри прямоугольника содержится текст примечания. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия.
  • 14. Если в примечании указывается ключевое слово "constraint", то данное примечание является ограничением, налагаемым на соответствующий элемент модели, но не на саму диаграмму.
  • 15. Отношения на диаграмме вариантов использования В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: - Отношение ассоциации (association relationship) - Отношение расширения (extend relationship) - Отношение обобщения (generalization relationship) - Отношение включения (include relationship)
  • 16. Отношение ассоциации Применительно к диаграммам вариантов использования оно служит для обозначения специфической роли актера в отдельном варианте использования. Обозначается сплошной линией между актером и вариантом использования.
  • 17. Отношение расширения Отношение расширения отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования. Если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.
  • 18. Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет").
  • 19. Семантика отношения расширения определяется следующим образом. Если экземпляр варианта использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, то проверяется условие данного отношения. Если условие выполняется, исходная последовательность действий расширяется посредством включения действий экземпляра другого варианта использования.
  • 20. При оформлении заказа на приобретение товара условием расширения является запрос от клиента на получение каталога товаров.
  • 21. Отношение обобщения Служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В (Иногда говорят «А являться специализацией варианта В»). Потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения.
  • 22. Данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
  • 23. Между отдельными актерами также может существовать отношение обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других. Отношение обобщения от актера А к актеру В отмечает тот факт, что каждый экземпляр актера А является одновременно экземпляром актера В и обладает всеми его свойствами.
  • 24. Отношение включения Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
  • 25. Отношение включения Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
  • 26. Семантика этого отношения определяется следующим образом. Когда экземпляр первого варианта использования в процессе своего выполнения достигает точки включения в последовательность поведения экземпляра второго варианта использования, экземпляр первого варианта использования выполняет последовательность действий, определяющую поведение экземпляра второго варианта использования, после чего продолжает выполнение действий своего поведения.
  • 27. Пример построения диаграммы вариантов использования В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу. В качестве актеров данной системы могут выступать два субъекта, один из которых является продавцом, а другой - покупателем. Каждый из этих актеров взаимодействует с рассматриваемой системой продажи товаров по каталогу и является ее пользователем, т. е. они оба обращаются к соответствующему сервису "Оформить заказ на покупку товара".
  • 28. Уточним вариант использования "Оформить заказ на покупку товара" на основе введения в рассмотрение дополнительных вариантов использования.
  • 29. Из более детального анализа процесса продажи товаров можно выделить в качестве отдельных сервисов такие действия, как «обеспечить покупателя информацией о товаре», «согласовать условия оплаты товара» и «заказать товар со склада». Вполне очевидно, что указанные действия раскрывают поведение исходного варианта использования в смысле его конкретизации, и поэтому между ними будет иметь место отношение включения.
  • 30. С другой стороны, продажа товаров по каталогу предполагает наличие самостоятельного информационного объекта - каталога товаров, который в некотором смысле не зависит от реализации сервиса по обслуживанию покупателей. Поэтому вполне резонно представить самостоятельный сервис "Запросить каталог товаров", который может запрашиваться покупателем или продавцом при необходимости выбора товара и уточнения деталей его продажи
  • 31.
  • 32. Приведенная выше диаграмма вариантов использования, может быть детализирована далее с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров - компьютеры. В этом случае диаграмма может быть дополнена вариантом использования "Оформить заказ на покупку компьютера" и актерами "Покупатель компьютера" и "Продавец компьютеров", которые связаны с соответствующими компонентами диаграммы отношением обобщения
  • 33.
  • 34. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. Рекомендуемое общее количество актеров в модели - не более 20, а вариантов использования - не более 50.

Editor's Notes

  1. Актером может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.
  2. Имя актера должно быть достаточно информативным с точки зрения семантики. Вполне подходят для этой цели наименования должностей в компании (например, продавец, кассир, менеджер, президент). Не рекомендуется давать актерам имена собственные (например, "О.Бендер") или моделей конкретных устройств (например, "маршрутизатор Cisco 3640"), даже если это с очевидностью следует из контекста проекта. Дело в том, что одно и то же лицо может выступать в нескольких ролях и, соответственно, обращаться к различным сервисам системы. Например, посетитель банка может являться как потенциальным клиентом, и тогда он востребует один из его сервисов, а может быть и налоговым инспектором или следователем прокуратуры. Сервис для последнего может быть совершенно исключительным по своему характеру.
  3. Имена интерфейсов подчиняются общим правилам наименования компонентов языка UML, т. е. имя может состоять из любого числа букв, цифр и некоторых знаков препинания, таких как двойное двоеточие "::". Последний символ используется для более сложных имен, включающих в себя не только имя самого интерфейса (после знака), но и имя сущности, которая включает в себя данный интерфейс (перед знаком). Примерами таких имен являются: "Сеть предприятия сервер" для указания на сервер сети предприятия или "Система аутентификации клиентов::форма ввода пароля".
  4. Важность интерфейсов заключается в том, что они определяют стыковочные узлы в проектируемой системе, что совершенно необходимо для организации коллективной работы над проектом. Более того, спецификация интерфейсов способствует "безболезненной" модификации уже существующей системы при переходе на новые технологические решения. В этом случае изменению подвергается только реализация операций, но никак не функциональность самой системы. А это обеспечивает совместимость последующих версий программ с первоначальными при спиральной технологии разработки программных систем.
  5. Кратность (multiplicity) ассоциации указывается рядом с обозначением компонента диаграммы, который является участником данной ассоциации. Кратность характеризует общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Применительно к диаграммам вариантов использования кратность имеет специальное обозначение в форме одной или нескольких цифр и, возможно, специального символа "*" (звездочка). Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1.
  6. Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу