Основные определения
Немного истории
Диаграмма вариантов использования
Определение варианта использования
Кто такие актёры?
Виды отношений в сценариях использования
Виды отношений в сценариях использования
Виды отношений в сценариях использования
Виды отношений в сценариях использования
Виды отношений в сценариях использования
Интернет Банк-Клиент
Контекст использования Системы
Моделирование контекста Системы
Моделирование контекста Системы
Документирование сценариев использования
Шаблон UC
Начальные и конечные события
Пример описания UC
Потоки событий UC
Выход альтернативного потока из основного
Пример описания UC
Пример описания UC
Правила и ограничения сценариев использования
Правила текстового описания вариантов использования
Ограничения сценариев использования
Домашка
1.65M
Категории: ИнтернетИнтернет ФинансыФинансы

Сценарии использования Системы

1.

Background Image
Сценарии использования Системы
logo
Основные определения.
Правила моделирования сценариев использования
Юлия Карелина
Сентябрь, 2016

2. Основные определения

ОСНОВНЫЕ ОПРЕДЕЛЕНИЯ
CONFIDENTIAL
2

3. Немного истории

НЕМНОГО ИСТОРИИ
Ивар Якобсон – в 1986 году впервые
сформулировал методику визуального
моделирования для описания сценариев
использования.
Соавтор Унифицированного Языка
моделирования UML и Рационального
Унифицированного Процесса (RUP)
CONFIDENTIAL
4
3

4.

Зачем нужны UC
BP
CONFIDENTIAL
UC
FR
4
4

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

ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
Диаграмма вариантов использования (Use Case diagram) – диаграмма, на которой изображаются
отношения между действующими лицами и вариантами использования
Диаграммы вариантов использования помогают представить систему с
точки зрения вариантов ее использования, т.е. описать как действующие
лица (пользователи, внешние системы, сервисы) взаимодействуют с
системой
Диаграмма вариантов использования
включает в себя:
Варианты использования (Use Cases)
Актеров (Actors)
Отношения зависимости, обобщения и
ассоциации (Association, Extend, Include)
CONFIDENTIAL
5
5

6. Определение варианта использования

ОПРЕДЕЛЕНИЕ ВАРИАНТА ИСПОЛЬЗОВАНИЯ
Вариант использования, сценарий использования, прецедент (англ. Use Case) – это
спецификации набора действий, выполняемых системой, который дает заметный результат, и,
как правило, значимый для одного или нескольких субъектов или других заинтересованных
сторон системы (UML 2).
Прецедент
CONFIDENTIAL
Вариант использования (Use Case) - описание множества последовательностей
действий (включая их варианты), которые выполняются системой для того, чтобы
актер(действующее лицо) мог получить определенный результат
6
6

7. Кто такие актёры?

КТО ТАКИЕ АКТЁРЫ?
Актер (Actor) - логически связанное множество ролей, которые играют пользователи вариантов
использования во время взаимодействия с ними
Актерами могут быть как люди, так и внешние (по отношению к проектируемой системе) системы
или аппаратные устройства
Обычно актер представляет собой роль, которую в данной системе играет человек, аппаратное
устройство или другая система
Актер
CONFIDENTIAL
С точки зрения актера вариант использования делает нечто представляющее для него
определенную ценность, например вычисляет результат, создает новый объект или изменяет
состояние другого объекта
7
7

8. Виды отношений в сценариях использования

ВИДЫ ОТНОШЕНИЙ
В СЦЕНАРИЯХ ИСПОЛЬЗОВАНИЯ

9. Виды отношений в сценариях использования

Ассоциация (англ. Association) — может указывать на то, что актер инициирует соответствующий вариант
использования. Актер с вариантом использования может связываться только отношением ассоциации.

10. Виды отношений в сценариях использования

Расширение (англ. Extend) — Отношение расширения используются для моделирования частей варианта
использования, которые пользователь воспринимает как необязательное поведение системы (выполняемых лишь при
определенных обстоятельствах)
Включение (англ. Include) — определяет
взаимосвязь базового варианта использования с
другим вариантом использования. В некоторой точке
один вариант использования содержит поведение,
определенное в другом варианте использования.
Включаемый вариант использования никогда не
существует автономно, а является частью базового
варианта использования

11. Виды отношений в сценариях использования

Еще один пример отношений прецедентов – расширение, включение:

12. Виды отношений в сценариях использования

Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей (означает, что вариант
использования - потомок наследует поведение и семантику своего базового варианта использования, может замещать или дополнять его
поведение, а кроме того, может быть подставлен всюду, где появляется вариант использования - предок)

13. Интернет Банк-Клиент

14. Контекст использования Системы

КОНТЕКСТ ИСПОЛЬЗОВАНИЯ
СИСТЕМЫ
CONFIDENTIAL
14

15. Моделирование контекста Системы

МОДЕЛИРОВАНИЕ КОНТЕКСТА СИСТЕМЫ
Диаграммы вариантов
использования применяют
также для моделирования
контекста использования
системы и её окружения
uc UC03
Order control system
Place orde r
Custome r
Моделирование контекста
подразумевает, что мы
обводим систему
воображаемой линией и
выявляем актеров, которые
находятся за этой линией и
взаимодействуют с системой.
Check ex ecution of
oder
Order department
Payment by cash
Render an account
Indiv idual customer
Pay an account
Cashless payment
Accounting department
Corporativ e customer
Enterpris e
Reporting
Ship orde r
Controlling uni t
Deliv ery department
CONFIDENTIAL
15
15

16. Моделирование контекста Системы

МОДЕЛИРОВАНИЕ КОНТЕКСТА СИСТЕМЫ
• Идентифицируйте окружающие систему актеров. Найдите группы, которым для выполнения задач
требуется участие системы; группы, которые необходимы системе для выполнения ее функций;
группы, взаимодействующие с внешними программными и аппаратными средствами; группы,
выполняющие вспомогательные функции администрирования и поддержки
• Организуйте похожих актеров с помощью отношений обобщения/специализации
• Поместите актеров на диаграмму вариантов использования и определите способы их связи с
вариантами использования системы
CONFIDENTIAL
16
16

17. Документирование сценариев использования

ДОКУМЕНТИРОВАНИЕ
СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ
CONFIDENTIAL
17

18. Шаблон UC

ШАБЛОН UC
Номер UC:
Название:
Актеры:
Краткое описание:
Предусловия:
Постусловия:
Основной поток:
Альтернативный поток:
Исключения:
Приоритет (Критично/Важно/Желательно):
CONFIDENTIAL
Частота использования
(Всегда/Часто/Иногда/Редко/Один раз):
18
18

19. Начальные и конечные события

НАЧАЛЬНЫЕ И КОНЕЧНЫЕ СОБЫТИЯ
CONFIDENTIAL
19
19

20. Пример описания UC

ПРИМЕР ОПИСАНИЯ UC
№ (код):
Наименование:
Действующие лица:
Краткое описание:
Предусловия:
Постусловия:
 UC-02.05
Создание заказа
Покупатель
Покупатель выбирает необходимые ему товары из каталога
и включает их в Заказ. Покупатель вводит дополнительные
условия заказа (адрес доставки, способ оплаты и др.).
Закончив формирование заказа, Покупатель передает Заказ
на исполнение.
Перечень условий, которые всегда выполнены (истинны) до
начала сценария: Покупатель идентифицирован и
аутентифицирован.
Перечень условий, которые всегда выполнены (истинны) в
случае успешного выполнения сценария: Покупатель
разместил Заказ в Системе.
 …
 …
Основной поток:
Альтернативный поток
1:
Приоритет:
(Критично | Важно | Желательно)
Частота использования : (Всегда | Часто | Иногда | Редко | Один раз)
CONFIDENTIAL
20
20

21. Потоки событий UC

ПОТОКИ СОБЫТИЙ UC
Событие
Событие
Основной поток
Событие
Событие
Альтернативный
поток
Исключительный
поток
CONFIDENTIAL
21
21

22. Выход альтернативного потока из основного

ВЫХОД АЛЬТЕРНАТИВНОГО ПОТОКА ИЗ ОСНОВНОГО
Основной поток
Действие
1.1
Событие
Событие
1.1
1.1
На рисунке показана схема потоков некоторого
варианта использования, в соответствии с
которой после Действия 1.1 основного потока
возможно достижение двух событий: либо
События 1.1, либо События 2.1
Альтернативный поток
Событие
Событие
2.1
2.1
Действие
2.1
Достижение
События
1.1
продолжению основного потока
приводит
к
Достижение События 2.1 приводит к тому, что
движение по основному потоку прекращается и
взаимодействие актера с системой продолжается
по альтернативному потоку
CONFIDENTIAL
22
22

23. Пример описания UC

ПРИМЕР ОПИСАНИЯ UC
Номер сценария использования:
Наименование сценария
использования:
Роли:
Описание:
Предусловия:
Постусловия:
Основной поток
UC 4.1.1.0:
Альтернативный поток
UC 4.1.1.1:
Исключение
UC 4.1.1.0.Е.1
Исключение
UC 4.1.1.1.Е.1
Приоритет (Критично | Важно |
Желательно):
Частота использования
(Постоянно | Часто | Иногда |
Редко | Единично):
CONFIDENTIAL
UC 4.1.1
Выбрать заказ в Системе
Диспетчер по отчетам
Диспетчер по отчетам при помощи штрих-кода на сопроводительной документации или
путем ввода номера заказа открывает в Системе форму заказа
Диспетчер по отчетам получил сопроводительную документацию с
напечатанным штрих-кодом;
На сопроводительной документации указан номер заказа.
Форма заказа открыта в Системе
1.
Диспетчер по отчетам при помощи сканера считывает штрих код на
сопроводительной документации.
2.
Система находит соответствующий заказ и открывает форму заказа
1.
Диспетчер использует функцию поиска заказа по номеру заказа, который указан на
сопроводительной документации.
2.
Система находит соответствующий заказ и открывает форму заказа.
1.
Диспетчер по отчетам при помощи сканера считывает штрих код на
сопроводительной документации.
2.
Система не находит заказ, соответствующий штрих-коду и выводит соответствующее
сообщение.
3.
Диспетчер использует функцию поиска заказа по номеру заказа, который указан на
сопроводительной документации.
4.
Система находит соответствующий заказ и открывает форму заказа.
1.
Диспетчер использует функцию поиска заказа по номеру заказа, который указан на
сопроводительной документации.
2.
Система не находит заказ, соответствующий введенному номеру заказа и выводит
соответствующее сообщение.
3.
Диспетчер использует функцию поиска заказа по другим параметрам заказа (ФИО
клиента, адрес доставки и пр.).
4.
Система находит соответствующий заказ и открывает форму заказа.
Критично
Постоянно
23
23

24. Пример описания UC

ПРИМЕР ОПИСАНИЯ UC
CONFIDENTIAL
Номер UC:
UC 1.0.
Название:
Оплатить мобильную связь
Актеры:
Клиент Банка
Краткое описание:
Клиент Банка вводит данные мобильного телефона, указывает сумму платежа, номер счета и
подтверждает платеж. Система производит платеж
Предусловия:
Клиент Банка выбрал опцию оплаты мобильной связи
Постусловия:
Платеж произведен
Основной поток
UC 1.0.0
1.
2.
3.
4.
5.
6.
7.
Клиент инициирует оплату мобильной связи
Клиент указывает данные мобильного телефона (Название оператора, номер телефона)
Клиент указывает сумму платежа
Клиент указывает номер счета, с которого необходимо списать средства
Клиент подтверждает проведение платежа
Система производит платеж: списывает указанную сумму с указанного счета
Система выводит пользователю уведомление об успешном совершении платежа
Альтернативный поток
UC 1.0.1
1.
2.
3.
4.
5.
Клиент решает использовать готовый шаблон платежа
Клиент выбирает шаблон
Клиент подтверждает проведение платежа
Система производит платеж
Система выводит пользователю уведомление об успешном совершении платежа
Исключения:
UC 1.0.0.E1
1.
2.
3.
4.
Клиент подтверждает проведение платежа
Система определяет, что на счете клиента не хватает средств для совершения платежа
Система не производит платеж
Система выводит Клиенту уведомление о невозможности совершения платежа
Исключения:
UC 1.0.0.E2
1.
2.
3.
4.
Клиент подтверждает проведение платежа
Система определяет, что телефонные данные введены некорректно
Система не производит платеж
Система выводит уведомление о некорректно заполненных данных
Приоритет
Важно
Частота использования
Часто
24
24

25. Правила и ограничения сценариев использования

ПРАВИЛА И ОГРАНИЧЕНИЯ
СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ

26. Правила текстового описания вариантов использования

Вариант использования должен:
Описывать, что именно система должна сделать, чтобы актер достиг своей цели
Не затрагивать деталей реализации (например, названия процедур, функций)
Иметь достаточный уровень детализации
Не описывать пользовательские интерфейсы и экраны. Это делается во время
дизайна пользовательского интерфейса

27. Ограничения сценариев использования

Сценарии использования плохо подходят для документирования требований не основанных на
взаимодействии с системой (таких как алгоритм или математические требования) или
нефункциональных требований (такие как платформа, производительность, синхронизация,
безопасность)
Создателям сценариев часто сложно определить на каком уровне следует описывать
пользовательский интерфейс (UI). Хоть теория сценариев использования и предлагает, чтобы
пользовательские интерфейсы не описывались в сценариях, часто достаточно трудно описать
сценарий не затрагивая описания пользовательского интерфейса
Сторонники гибких методологий разработки часто считают сценарии использования слишком
формальными документами, предпочитая использовать более простой подход пользовательских
историй.
Литература, рекомендуемая к прочтению:
«Современные методы описания функциональных требований к Системам» (Автор: Алистер Коберн)

28. Домашка

Создать диаграмму сценариев использования интернетмагазина. Описать 2-3 основных сценария в виде таблиц

29.

Спасибо за внимание
[email protected]
CONFIDENTIAL
29
English     Русский Правила