Основные диаграммы UML прецеденты Use Case МКД 03

Основные диаграммы UML: прецеденты (Use Case) МКД 03. 01 «Технология разработки программного обеспечения»

Виды диаграмм UML Что делает система? 1. Диаграмма использования / Use case diagram Из чего состоит система? 1. 2. 3. 4. 5. Диаграмма классов / Class diagram Диаграмма компонентов / Component diagram Диаграмма размещения / Deployment diagram Диаграмма объектов / Object diagram Диаграмма внутренней структуры / Composite structure diagram Как работает система? 1. 2. 3. 4. 5. 6. Диаграмма деятельности / Activity diagram Диаграмма коммуникации / Communication diagram Диаграмма последовательности / Sequence diagram Диаграмма автомата / State machine diagram Обзорная диаграмма взаимодействия / Interaction overview diagram Диаграмма синхронизации / Timing diagram Как управлять сложностью модели ? 1. Диаграмма пакетов / Package diagram

Спецификации: зачем? ? ?

User Stories & Use Cases User Story – это пользовательскоориентированное описание целей, которые люди смогут достичь, используя ваш продукт, написанное повседневным языком. Формат: Я как ______, хочу ______, для того чтобы _______ Как <пользователь>, я могу <действие>, для того, чтобы <цель>

Основные вопросы User Stories КТО хочет? ЧТО хочет? ЗАЧЕМ хочет?

Пример пользовательского сценария № 1 Я, , хочу чтоб в сочинениях по русскому языку исправлять ошибки орфографии!

Пример пользовательского сценария № 2 Как администратор компании, а хочу иметь возможность устанавливать заданные программы на удаленные рабочие столы, для того чтобы не тратить время на перемещение по офису и не отвлекать сотрудников от работы.

User Stories & Use Cases -представляют собой документированное описание того, как продукт будет использован. Их написание сопровождается соблюдением определенных «церемоний» , но они описывают все варианты того, какой-либо человек будет выполнять некоторые действия (или их вариации)

Иерархия понятий

Вариант использования. Что это? Вариант использования (Use case, прецедент) - описание поведения системы при ее взаимодействии с окружающим миром. Use case описывает то, как действующее лицо пытается достичь некой цели, используя систему. Use case четко показывает, что именно должна выполнить система, причем ничего не говорит о том, как она это делает.

Пример прецедента: кассовый аппарат Пробить товар: 1. Кассир проводит товар над сканером; сканер считывает штрих-код. 2. Описание и цена товара вместе с текущим подитогом отображаются на дисплее, обращенном к покупателю. Описание и цена товара появляются также на экране кассового терминала. 3. Описание и цена товара печатаются в чеке. 4. Система издает звуковой сигнал, подтверждающий, что штрих-код успешно прочитан.

Что такое действующее лицо? Действующее лицо – некто или нечто внешнее по отношению к системе и взаимодействующее с системой для достижения определенной цели. n «Представитель» внешней среды, который взаимодействует с системой n. Роль, исполняемая сущностью из внешней среды Виды действующих лиц n. Пользователь n. Внешняя система n. Внешнее устройство n. Время

Для чего нужны варианты использования?

Подход на основе вариантов использования Кассир выбирает функцию бронирования и печати билета. Система запрашивает параметры брони. Пользователь выбирает название представления из списка, дату и время представления, выбирает место и подтверждает бронь. Система регистрирует бронь и распечатывает билет с указанием цены. Функциональные требования: n. Система должна позволять бронировать билеты на представление. n. Система должна позволять распечатывать забронированные билеты. n. Система должна регистрировать забронированное место, присваивая брони уникальный идентификатор. Класс-сущность: Бронь

Подход на основе вариантов использования Кассир выбирает функцию бронирования и печати билета. Система запрашивает параметры брони. Пользователь выбирает название представления из списка, дату и время представления, выбирает место и подтверждает бронь. Система регистрирует бронь и распечатывает билет с указанием цены. Пользовательский интерфейс: Представление – Тестовое поле (100 символов) Дата и время – Дата в формате ЧЧ : ММ ДД. ММ. ГГГГ Место – Числовое значение (01 -100) Цена – Числовое значение ( xxxx. xx ) Кнопки: Отмена и Печать

Описание функции: Зарегистрироваться на сайте Сайт должен предоставлять пользователю возможность зарегистрироваться. Для регистрации пользователь должен заполнить форму. После регистрации сайт должен отправить на e-mail пользователя подтверждение о регистрации.

Use Case: Зарегистрироваться на сайт UC. Зарегистрироваться на сайте Действующее лицо: пользователь сайта Предусловия: пользователь находится на главной странице сайта Основной сценарий: 1. Пользователь нажимает кнопку «Зарегистрироваться» 2. Сайт отображает форму регистрации 3. Пользователь заполняет поля формы и подтверждает регистрацию 4. Сайт подтверждает правильность заполнения формы 5. Сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации Альтернативные сценарии: …

Пример прецедента: кассовый аппарат Пробить товар: 1. Кассир проводит товар над сканером; сканер считывает штрих-код. 2. Описание и цена товара вместе с текущим подитогом отображаются на дисплее, обращенном к покупателю. Описание и цена товара появляются также на экране кассового терминала. 3. Описание и цена товара печатаются в чеке. 4. Система издает звуковой сигнал, подтверждающий, что штрих-код успешно прочитан.

Пример прецедента: кассовый аппарат Штрих-код не считался: Если сканер не смог считать штрих-код, то система должна подать сигнал «просканировать повторно» , извещающий кассира о необходимости повторить попытку. Если после трех попыток сканер так и не сумел считать штрих-код, кассир должен ввести его вручную. Штрих-код отсутствует: Если на товаре нет штрих-кода, то кассир должен ввести цену вручную.

Нехороший пример Пользователь нажимает кнопку «Зарегистрироваться» . Сайт отображает форму регистрации. Пользователь заполняет поля формы и подтверждает регистрацию. Сайт проверяет правильность заполнения формы. Если поля заполнены неверно, то сайт сообщает пользователю об ошибках заполнения формы. Если поля заполнены верно, то сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации.

Нехороший пример (продолжение) Пользователь нажимает кнопку «Зарегистрироваться» . Сайт отображает форму регистрации. Пользователь заполняет поля формы и подтверждает регистрацию. Сайт проверяет правильность заполнения формы. Если поля заполнены неверно, то сайт сообщает пользователю об ошибках заполнения формы. Если в базе уже есть пользователь с таким же e-mail , то сайт сообщает пользователю о том, что пользователь с таким e-mail уже зарегистрирован. Если поля заполнены верно, то сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации.

Исправленный вариант использования Основной сценарий: 1. Пользователь нажимает кнопку «Зарегистрироваться» 2. Сайт отображает форму регистрации 3. Пользователь заполняет поля формы и подтверждает регистрацию 4. Сайт подтверждает правильность заполнения формы 5. Сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации

Исправленный вариант использования Основной сценарий: 1. Пользователь нажимает кнопку «Зарегистрироваться» 2. Сайт отображает форму регистрации 3. Пользователь заполняет поля формы и подтверждает регистрацию 4. Сайт подтверждает правильность заполнения формы 5. Сайт регистрирует пользователя и отправляет на его e-mail письмо с подтверждением регистрации Альтернативные сценарии: 4 а. Есть ошибки заполнения формы: 4 а 1. Сайт сообщает об ошибках заполнения формы 4 а 2. Переход на шаг 3 4 б. Пользователь с таким e-mail уже зарегистрирован: 4 б 1. Сайт сообщает о том, что пользователь с таким e-mail уже зарегистрирован 4 б 2. Переход на шаг 3.

Шаблон описания Use Case 1. 2. 3. 4. 5. 6. 7. Идентификатор Название Цель, краткое описание Действующие лица Предусловие Постусловие Потоки событий: n Основной поток событий {basic} n Альтернативные потоки событий {alt} n Ошибки и исключения {err} n Подпотоки {sub} 8. Точки расширения 9. Примечания и допущения 10. Правила и дополнительные требования

Шаблон описания Use Case: Название и идентификатор Название варианта использования n. Глагол + существительное n. Отражает цель действующего лица n. Уникальное в рамках системы (подсистемы) Уникальный идентификатор n. В документе перед названием варианта использования n. Уникальный в рамках всей системы (документации) n. Упрощает поиск требований в документации n. Используется при трассировке требований Примеры: n. UC 134 Создать документ с требованиями n. UC. 07. 09. 14 Оплатить банковский счет n. ВИ-23 Оформить покупку товара n. ВИ 15_12 Зарегистрировать пользователя

Шаблон описания Use Case: Краткое описание nнесколько предложений nотражает назначение данного варианта использования nотражает цель пользователя nкраткое описании основного потока событий. Пример: Данный вариант использования позволяет кладовщику создавать и сохранять в системе новый документ с описанием товара. Каждому документу в системе присваивается уникальный идентификатор, и для документа устанавливается связь с товаром на складе

Шаблон описания Use Case: предусловие и постусловие Предусловие: Состояние или событие, которое должно быть истинно для того, чтобы вариант использования начался. Постусловие: Состояния или данные, которые появляются в результате выполнения варианта использования. Примеры: n. Пользователь должен быть авторизирован в системе n. Документ должен иметь статус черновика n. Документ разнесен на лицевой счет n. Создана новая учетная запись пользователя

Шаблон описания Use Case: потоки событий Поток событий – последовательность действий пользователя и откликов системы Рекомендации: n. Пишите КТО совершает действие – пользователь или система n. Отделяйте шаги друг от друга n. Давайте названия потокам событий Шаблон: Шаг 1. [Действующее лицо] совершает [Действие] Шаг 2. [Система] отвечает [Откликом]

Потоки событий. Примеры оформления Пример 1: 1. Пользователь задает параметры документа и подтверждает сохранение данных 2. Система сохраняет новый документ, присваивая ему уникальный идентификатор. 3. Пользователь … Пример 2: Пользователь задает параметры документа и подтверждает их сохранение. Система сохраняет новый документ с новым номером. Пользователь … Пример 3: О 1 Основной поток событий – Создание нового документа: О 1. 1 Пользователь задает параметры документа и подтверждает сохранение данных О 1. 2 Система сохраняет новый документ, присваивая ему уникальный идентификатор. О 1. 3 Пользователь …

Основной поток событий n. Наикратчайший путь для достижения цели пользователя n. Всегда удачное завершение n. Всегда имеет точку старта и точку выхода n. Содержит 7 -9 шагов n. В варианте использования может быть несколько основных потоков

Основной поток событий. Примеры Одна точка старта Вариант использования начинается, когда пользователь решает создать новый документ 1. Пользователь инициирует создание нового документа 2. Система запрашивает у пользователя параметры нового документа: n. Название n. Номер счета-фактуры n. Код товара n… 3. Пользователь задает необходимые параметры и подтверждает сохранение документа 4. …

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

Основной поток событий. Примеры Точка выхода 3 … 4. Пользователь вводит название учетной записи (логин) и пароль и подтверждает вход в систему 5. Система проверяет наличие учетной записи, ее статус (заблокирована или нет) , корректность и срок действия пароля. 6. Система настраивает пользовательский интерфейс в соответствии с настройками пользователя и его правами. 7. Пользователь входит в систему и получает доступ к необходимой функциональности клиента НИ. Вариант использования завершается удачно. 9 … 10. Система сообщает пользователю о том, что учетная запись заблокирована и необходимо обратится к администратору системы. Вариант использования завершается неудачно.

Шаблон описания Use Case: потоки событий Альтернативные потоки событий и ошибки Отклонения от основного потока событий, которые приводят к nдостижению цели действующего лица nчастичному достижению цели nне достижению цели Рекомендации: n. Идентифицируйте и описывайте обработки ВСЕХ ошибок n. Ищите альтернативные пути достижения цели действующего лица n. Всегда указывайте точку старта и точку выхода n. Присваивайте наименования альтернативным потокам событий

Расширения Альтернативные сценарии: 2 -4 а. Условие… : 2 -4 а 1. Действие… 2 -4 а 2. Действие… *а. Условие… : *а 1. Действие… *а 2. Действие…

Альтернативный поток событий. Примеры Пример 1: [Шаг 3 Основного потока] Отмена создания документа 3. Пользователь отменяет создание документа. 4. Система запрашивает подтверждение на отмену и сообщает о том, что новый документ не будет создан. 5. Пользователь подтверждает отмену Вариант использования завершается неудачно Пример 2: [Шаг 2 Основного потока] Прикрепить файл к письму 10. Пользователь выбирает присоединение файла к письму. 11. Система запрашивает путь к файлу. 12. Пользователь выбирает файл и подтверждает его загрузку 13. Система сохраняет файл, присоединив его к письму Переход к шагу 4 основного потока событий

UC 13: Организовать последовательный доступ к ресурсу Основное действующее лицо: объект клиента Область действия: система параллельного обслуживания (CSF) Уровень: цель пользователя Основной сценарий: 1. Клиент CSF запрашивает блокировку ресурса, чтобы обеспечить к нему определенный доступ 2. Программа блокировки ресурса (БР) возвращает управление клиенту CSF, чтобы он мог использовать этот ресурс 3. Клиент CSF использует ресурс 4. Клиент CSF информирует программу БР о завершении работы с ресурсом 5. По завершении работы клиента CSF программа БР восстанавливает прежнее состояние ресурса

UC 13: Организовать последовательный доступ к ресурсу - 2 Расширение: 2 а. Программа БР обнаруживает, что клиент CSF уже имеет доступ к этому ресурсу: 2 а 1. Программа БР применяет к запросу политику преобразования запроса (UC 14) 2 б. Программа БР обнаруживает, что ресурс уже используется: 2 б 1. Программа БР применяет к запросу политику совместимости (UC 15), чтобы обеспечить доступ клиенту CSF 2 в. Время блокировки ресурса не истекло: 2 в 1. Программа БР запускает таймер занятости.

UC 13: Организовать последовательный доступ к ресурсу - 3 Расширение: 3 а. Заданный таймером занятости интервал истекает, прежде чем клиент информирует программу БР, что он закончил работу: 3 а 1. Программа БР посылает процессу клиента сообщение об исключительной ситуации 3 а 2. Отказ! 4 а. Программа БР обнаруживает ненулевое значение счетчика блокировок у клиента CSF: 4 а 1. Программа БР уменьшает значение счетчика обращений для запроса 4 а 2. Отказ!

UC 13: Организовать последовательный доступ к ресурсу - 3 Расширение: 5 а. Программа БР обнаруживает, что ресурс в настоящий момент не используется: 5 а 1. Программа БР применяет политику выбора доступа (UC 16) для предоставления доступа одному из стоящих в очереди клиентов.

Шаблон описания Use Case: подпотоки n. Детализация действий системы n. Сокращение описания потоков событий n. Вынесенное отдельно описание повторяющихся шагов потоков событий Пример: О. 1. Система выполняет проверки учетной записи пользователя П. 1 Система проверяет наличие учетной записи пользователя П. 2 Система проверяет корректность и срок действия пароля пользователя П. 3 Система проверяет наличие и срок действия сертификата безопасности О. 2. В случае удачного выполнения проверок система открывает рабочее пространство пользователя.

Шаблон описания Use Case: точки расширения Точка расширения - место для введения нового поведения в потоки событий варианта использования Точки расширения могут быть: Внутренними (ссылки на шаги) Внешними (зависимость «extend» ) Точка расширения имеет: Название Условие Идентификатор положения в потоке событий

Точки расширения. Примеры Пример 1: Внутренняя точка расширения [Шаг 3 Основного потока] Отмена создания документа 3. Пользователь отменяет создание документа. 4. Система запрашивает подтверждение на отмену и сообщает о том, что новый документ не будет создан. 5. Пользователь подтверждает отмену Вариант использования завершается неудачно Пример 2: Внешняя точка расширения [На любом шаге основного потока] Получить справочную информацию 11. Вызов «UC 231 Просмотреть справочную информацию» Возврат обратно к шагу вызова

Дополнительные требования n. Ограничения и бизнес-правила n. Атрибуты качества n. Требования к форматам данных n. Требования к пользовательскому интерфейсу n. Другие Пример: RQ 21. Атрибуты учетной записи имя пользователя, пароль, контактный телефон должны быть обязательны для заполнения, остальные – опциональны и могут заполняться по желанию пользователя BRUL 23. Срок действия пароля в соответствии с политикой безопасности компании (пункт 3. 2. 4 ) устанавливается равным трем месяцам с момента его создания/смены.

В чем преимущество описания Use Case? n. Дают представление о поведении системы Сравните с функцией: Сайт должен предоставить пользователю возможность зарегистрироваться n. Понятны заказчикам и разработчикам n. Позволяют описать множество альтернатив (исключений) n. Список вариантов использования – перечень функциональности системы n. Позволяют описывать функционал итеративно (перечень Use Cases - > Краткие описания - > Основные потоки -> Расширения)

Use Case и User Story • User Story это один из сценариев, тогда как Use Case это набор сценариев • Use Case объединяет несколько сценариев и показывает отношения между ними

Когда не стоит использовать Use Case n. Когда требуется описать сложный алгоритм n. Для описания пользовательского интерфейса (никаких кнопок ОК, полей ввода и выбора, окон и последовательности их появления)

Рекомендации n. Основной сценарий не больше 3 - 9 шагов n. Исключите элементы дизайна (если в них есть необходимость опишите в другом месте) n. Используйте один уровень детализации на всех шагах n. Избегайте формализма (используйте тот шаблон, который необходим в данный момент) n. Не пытайтесь описать все расширения сразу n. Не используйте «если» n. Следите за тем, на чьей стороне мяч

Рекомендации Ищем ответ на вопросы: n. Что пользователи ждут от системы? n. Что система должна сделать для конкретного пользователя? Такой подход позволяет искать функции, которые нужны многим пользователям и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.

Диаграмма вариантов использования (Use Case Diagram) Действующее лицо Actor Обобщения Вариант использования Use Case Зависимости include и extented Ассоциации Пакеты и границы системы

Вариант использования и действующее лицо Действующие лица n. Основные – инициируют вариант использования n. Вспомогательные - участвуют в варианте использования n. Всегда ВНЕ границ системы Вариант использования nсвязан с действующим лицом ассоциацией nвсегда ВНУТРИ границ системы

Обобщение вариантов использования и действующих лиц n. Абстрактный вариант использования описывает общее поведение системы n. Абстрактное действующее лицо описывает общую роль в системе n. Абстрактный вариант использования и абстрактное действующее лицо не могут иметь экземпляров

Обобщение действующих лиц. Пример «Получить доступ к мониторингу» ДЛ: Участник мониторинга платежей (далее Пользователь) Основной поток событий : 7. Пользователь запускает приложение. 8. Система запрашивает данные для аутентификации 9. Пользователь вводит логин и пароль 10. Система проверяет данные…… 11. …….

Абстрактный вариант использования. Схема

Абстрактный вариант использования. Пример

• Создать форму

Абстрактный вариант использования. Пример

• UC. 07. 01 Создать описание ФНО

• код ФНО,

• наименование ФНО,

• тип ФНО

• номер приказа,

• дату утверждения

• дата начала применения

• дата окончания применения

• информация , описывающая ФНО

• 3. Пользователь задает параметры описания ФНО

Зависимость «include» n. Общее поведение выносится во включаемый вариант использования n. Экземпляр базового варианта использования не может существовать без шагов включаемого варианта использования n. Включаемый вариант использования, который не инициируется самостоятельно не может иметь экземпляров

Зависимость «include» . Схема

Зависимость «extend» n. Вводит новое поведение в базовый вариант использования n. Точки расширения = точки входа n. Базовый вариант использования «не знает» про расширяющий вариант использования

Зависимость «extend» . Схема

Пакеты: nструктурируют модель nочерчивают границы системы n «черновики» для компонентов Рекомендации: n. Группируйте варианты использования по пакетам n. Группируйте действующих лиц по пакетам n 1 пакет – 3 -9 вариантов использования

Спасибо за внимание! Основные диаграммы UML: прецеденты (Use Case)