Основні теоретичні відомості

Лабораторна робота №2 Візуалізація вимог користувача

Мета роботи

Навчитись розробляти діаграми прецедентів та візуалізувати сценарії за допомогою прототипів інтерфейсу користувача.

Основні теоретичні відомості

Создание Сценариев Использования (Use Cases).Сценарий использования (Use Cases) – это описание системы в терминах последовательности действий. Он должен иметь значимый результат или определенное значение для лица, взаимодействующего с системой (actor – действующее лицо). Некоторые характеристики сценариев использования:

− инициируются действующим лицом;

− являются моделью взаимодействий между действующим лицом и системой;

− описывают последовательность действий;

− содержат в себе функциональные требования;

− должны иметь некоторое значение для действующего лица;

− предоставляют полный, имеющий смысл поток событий.

Назначение сценариев использования – способствовать соглашению между разработчиками, заказчиками и пользователями на тему того, что именно система должна делать. Сценарий использования становится своего рода контрактом между разработчиками и заказчиками. Он также является основой для реализации сценариев использования, которые играют большую роль в проектировании системы. Более того, из сценариев использования Вы можете получать пользовательскую документацию. Сценарии использования могут также быть полезны в планировании формального содержания итераций и позволяют разработчикам системы лучше понять назначение системы.

При разработке сценариев использования мы также будем определять сценарии (алгоритмы, scenarios) – особые пути прохождения сценария использования. Из сценариев использования можно создавать диаграммы последовательностей, диаграммы связей и диаграммы классов. Они также используются как исходные данные для тестовых сценариев (test cases).

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

Действующее лицо (actor) – это некто или нечто, взаимодействующее с системой. Им может быть как человек, так и другая система. Несколько примеров действующих лиц: Пользователи системы; Администраторы; Управление; Лица, предоставляющие информацию для системы; Внешние системы, предоставляющие данные; Внешние системы, получающие уведомления.

Для создания новой диаграммы Use Case необходимо создать новый проект. Для его создания выберем File> New> Project и зададим его основные запрашиваемые параметры (имя, репозиторий, описание, группы доступа).После создания проекта появиться вкладка с основными возможностями для работы над этим проектом (рис. 3.1).

Рисунок 3.1 – Вкладка созданного проекта

Вкладка проекта содержит четыре собственных вкладки: Артефакты, Требования, Коллекции и Администрирования.

Выбираем вкладку Артефакты. В ней нажимаем на кнопку «Создать Артефакт» и выбираем тип создаваемого артефакта (рис. 3.2)

Рисунок 3.2 – Создание нового артефакта

Для начала создадим всех актеров будущих моделей и все их варианты использования (рис. 3.3).

Рисунок 3.3 – Создание артефакта (актера)

Для каждого созданного артефакта создается отдельная вкладка, на которой отображаются свойства артефакта и могут быть заданы атрибуты. Когда будут созданы все необходимые объекты создаем таким же образом новую диаграмму Use Case. В открывшейся вкладке, из меню расположенного слева перетягиваем на рабочее пространство значки объектов (актеров и варианты использования) (рис. 3.4) и выбираем из открывшегося перечня названия уже созданных артефактов (рис 3.5).

Рисунок 3.4 – Выбор типа артефакта для построение диаграммы

Рисунок 3.5 – Выбор артефакта для значка на диаграмме из перечня уже готовых

Прецедент «Регистрация пользователя»

Рисунок 3.6 - Прецедент «Регистрация пользователя»

Прецедент «Регистрация пользователя»:

Основной исполнитель - пользователь;

Заинтересованное лицо - сотрудники;

Предпосылки: наличие формы ввода данных;

Постусловие: нет;

Основной успешный сценарий:

1. Пользователь заходит на регистрацию

2. Пользователь вносит личные данные;

3. Пользователь ознакамливается с договором и принимает его;

4. Выполняется альтернативный поток А1, или альтернативный поток А2.

Альтернативный поток А1: пользователь принимает условие договора;

Альтернативный поток А2: пользователь не принимает условия и выходит с регистрации;

5. Пользователь вводит системные данные

6. Пользователь вводит код подтверждения регистрации

7. Пользователь выходит из регистрации

Прецедент «Выбор товара»:

Рисунок 3.7 - Прецедент «Выбор товара»

Прецедент «Заказ товара»:

Основной исполнитель - клиент;

Заинтересованное лицо - сотрудники;

Предпосылки - наличие форм ввода данных;

Постусловие - нет;

Основной успешный сценарий:

1. Клиент авторизуется;

2. Клиент вводит критерии поиска товара;

3. Клиент получает результаты поиска

4. Клиент выбирает нужный товар

5. Выполняется альтернативный поток А1, или альтернативный поток А2.

Альтернативный поток А1: клиент оформляет покупку товара;

Альтернативный поток А2: клиент откладывает в корзину товар;

Прецедент «Оформление покупки товара»

Рисунок 3.8 - Прецедент «Оформление покупки товара»

Прецедент «Оформление покупки товара»:

Основной исполнитель - клиент;

Заинтересованное лицо - сотрудники;

Предпосылки - наличие формы ввода данных;

Постусловие - нет;

Основной успешный сценарий:

1. Клиент оформляет заказ товара;

2. Выполняется альтернативный поток А1, или альтернативный поток А2.

Альтернативный поток А1: товара нет на складе, клиент выходит из системы;

Альтернативный поток А2: товар есть на складе;

3. Клиент оплачивает товар

Прецедент «Администрирование системы»

Рисунок 3.9 - Прецедент «Администрирование системы»

Прецедент «Администрирование системы»:

Основной исполнитель - администратор;

Заинтересованное лицо - администратор;

Предпосылки - наличие формы ввода данных;

Постусловие – успешная работа системы;

Основной успешный сценарий:

1. Администратор регистрируется;

2. Администратор проверяет корректность работы системы;

3. Администратор обновляет информацию системы;

4. Администратор отслеживает заказы клиентов;

5. Администратор отслеживает доставку

6. Администратор отслеживает оплату товаров

Прецедент «Робота оператора системы»

Рисунок 3.10 - Прецедент «Робота оператора системы»

Прецедент «Работа оператора системы»:

Основной исполнитель - оператор системы;

Заинтересованное лицо - сотрудники;

Предпосылки - наличие формы ввода данных;

Постусловие - нет;

Основной успешный сценарий:

1. Оператор регистрируется;

2. Оператор оформляет клиента;

3. Оператор отвечает на входящие звонки

4. Оператор запрашивает товар со склада;

5. Выполняется альтернативный поток А1, или альтернативный поток А2.

Альтернативный поток А1: оформляет доставку товара, оформляет оплату товара;

Альтернативный поток А2: товара на складе нет, клиенту предлагается

Диаграмма прецедентов «Клиент посещает магазин»

Рисунок 3.11 – Диаграмма прецедентов «Клиент посещает магазин»

Основные актеры: покупатель, оператор

Заинтересованная сторона: владелец интернет магазина

Предусловий нет

Постусловий: нет

Основной успешный сценарий:

1. Регистрация покупателя

2. Оператор регистрирует покупателя.

3. Авторизация покупателя

4. Покупатель смотрит каталог товаров

5. Покупатель помещает товар в корзину

6. Покупатель оформляет заказ.

7. Оператор оформляет заказ

8. Оператор запрашивает товар на складе, если товара нет, выполняется альтернативный поток А1.

9. Покупатель оплачивает заказ

10. Оператор помещает деньги на счет

11. Оператор организовывает доставку.

Альтернативный поток А1:

1. Оператор сообщает покупателю об отсутствии товара на складе

2. Прецедент завершен.