Диаграмма вариантов использования

Содержание

Слайд 2

Actor Актер (actor) — согласованное множество ролей, которые играют внешние сущности

Actor

Актер (actor) — согласованное множество ролей, которые играют внешние сущности по

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

В некоторых случаях актер может обозначаться в виде прямоугольника класса со стереотипом <> и обычными составляющими элементами класса. Имена актеров должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели. При этом символ отдельного актера связывает соответствующее описание актера с конкретным именем.

Слайд 3

Вариант использования Вариант использования (use case) — внешняя спецификация последовательности действий,

Вариант использования

Вариант использования (use case) — внешняя спецификация последовательности действий, которые

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

Отношения Отношение (relationship) — семантическая связь между отдельными элементами модели. Между

Отношения

Отношение (relationship) — семантическая связь между отдельными элементами модели.
Между элементами

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

ассоциации (association relationship)
включения (include relationship)
расширения (extend relationship)
обобщения (generalization relationship)

Слайд 5

Ассоциация Отношение ассоциации – одно из фундаментальных понятий в языке UML

Ассоциация

Отношение ассоциации – одно из фундаментальных понятий в языке UML и

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

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

Слайд 6

Включение Включение (include) в языке UML — это разновидность отношения зависимости

Включение

Включение (include) в языке UML — это разновидность отношения зависимости между

базовым вариантом использования и его специальным случаем. При этом отношением зависимости является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования. Так, например, отношение включения, направленное от варианта использования "Предоставление кредита в банке" к варианту использования "Проверка платежеспособности клиента", указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом <>:
Слайд 7

Расширение Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим

Расширение

Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом

использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. Это означает, что свойства поведения первого варианта использования в некоторых случаях могут быть дополнены функциональностью второго варианта использования.
В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом <>:
Слайд 8

Обобщение Два и более актера могут иметь общие свойства, т. е.

Обобщение

Два и более актера могут иметь общие свойства, т. е. взаимодействовать

с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей.
Графически отношение обобщения обозначается сплошной линией со стрелкой в форме не закрашенного треугольника, которая указывает на родительский вариант использования. Эта линия со стрелкой имеет специальное название — стрелка-обобщение.

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

Слайд 9

Дополнительные обозначения языка UML для бизнес-моделирования Бизнес-актер (business actor) – индивидуум,

Дополнительные обозначения языка UML для бизнес-моделирования

Бизнес-актер (business actor) – индивидуум, группа,

организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью системы. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы.
Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.
Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса.
Слайд 10

Пример бизнес-модели Диаграмма вариантов использования для системы продажи товаров по каталогу

Пример бизнес-модели

Диаграмма вариантов использования для системы продажи товаров по каталогу в

общих обозначениях языка UML

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

Слайд 11

Требования Требование (requirement) - желательное свойство, характеристика или условие, которым должна

Требования

Требование (requirement) - желательное свойство, характеристика или условие, которым должна удовлетворять

система в процессе своей эксплуатации.
Применительно к программным системам предложена следующая классификация требований, которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке:
функциональные требования (Functionality)
требования удобства использования (Usability)
требования надежности (Reliability)
требования производительности (Performance)
требования возможности сопровождения (Supportability)
При этом символом "+" обозначены дополнительные условия, к которым относятся:
проектные ограничения
требования управления системой
требования к графическому интерфейсу пользователя
физические требования
юридические требования
Слайд 12

Сценарии Центральное место среди указанных требований занимают функциональные, которые специфицируют особенности

Сценарии

Центральное место среди указанных требований занимают функциональные, которые специфицируют особенности реализации

отдельных бизнес-процессов моделируемой системы. В контексте моделей языка UML именно функциональные требования должны служить исходной информацией для построения диаграмм вариантов использования. Однако большинство разработчиков и экспертов согласны с тем, что изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования.
Сценарий (scenario) - определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста. В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования.
Слайд 13

Диаграмма вариантов использования для модели банкомата

Диаграмма вариантов использования для модели банкомата

Слайд 14

Сценарий "Снятие наличных по кредитной карточке"

Сценарий "Снятие наличных по кредитной карточке"

Слайд 15

Типичный ход событий сценария "Снятие наличных по кредитной карточке"

Типичный ход событий сценария "Снятие наличных по кредитной карточке"

Слайд 16

Исключения сценария "Снятие наличных по кредитной карточке"

Исключения сценария "Снятие наличных по кредитной карточке"

Слайд 17

Примечание Отдельные небольшие по своему объему сценарии могут быть размещены на

Примечание

Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме

в форме примечаний.
Примечание (note) предназначено для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.
Графически примечания на всех типах диаграмм обозначаются прямоугольником с "загнутым" верхним правым уголком. Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия.
Слайд 18

Рекомендации Определить главных или первичных и второстепенных актеров Определить цели главных

Рекомендации

Определить главных или первичных и второстепенных актеров
Определить цели главных актеров по

отношению к системе
Сформулировать основные варианты использования, которые специфицируют функциональные требования к системе
Упорядочить варианты использования по степени убывания риска их реализации
Рассмотреть все базовые варианты использования в порядке убывания их степени риска
Выделить участников, интересы, предусловия и постусловия выполнения выбранного варианта использования
Написать успешный сценарий реализации выбранного варианта использования
Определить исключения или неуспех в выполнении сценария варианта использования
Написать сценарии для всех исключений
Выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом <>
Выделить варианты использования для исключений и изобразить их взаимосвязи с базовыми со стереотипом <>
Проверить диаграмму на отсутствие дублирования вариантов использования и актеров

Для разработки диаграммы вариантов использования рекомендуется некоторая последовательность действий: