Now Reading: Полное руководство по детализации вариантов использования: ключевые концепции, методы и примеры

1
  • 01

    Полное руководство по детализации вариантов использования: ключевые концепции, методы и примеры

Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTvizh_CNzh_TW

Полное руководство по детализации вариантов использования: ключевые концепции, методы и примеры

UMLYesterday

Введение

Детализация вариантов использования является критической фазой в жизненном цикле разработки программного обеспечения, особенно в контексте инженерии требований и объектно-ориентального анализа и проектирования. Она устраняет разрыв между высоким уровнем вариантов использования и подробными спецификациями системы, позволяя разработчикам, аналитикам и заинтересованным сторонам понятькаксистема ведет себя в ответ на конкретные цели пользователя.

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

1. Что такое детализация вариантов использования?

Детализация вариантов использования — это процесс уточнения высокого уровня варианта использования до подробного, действенного описания поведения системы. Он преобразует простой рассказ о взаимодействии пользователя в точную, проверяемую и реализуемую спецификацию.

✅ Цель: определитьчтосистема должна делать,каккак она должна это делать, ипри каких условияхс достаточной детализацией для разработки и тестирования.

2. Почему детализация вариантов использования важна

  • Снижает неоднозначность: Предотвращает неправильное толкование требований.

  • Улучшает отслеживаемость: Связывает требования с проектированием, кодом и тестовыми случаями.

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

  • Обеспечивает тестирование: Облегчает создание сценариев тестирования и критериев приемки.

  • Улучшает сотрудничество: Обеспечивает общее понимание между заинтересованными сторонами, разработчиками и тестировщиками.

3. Ключевые понятия в детализации сценариев использования

3.1 Сценарий использования (UC)

Сценарий использования описывает последовательность действий, которые система выполняет для получения ценного результата для актора (пользователя или внешней системы).

Пример: «Снять наличные» с банкомата.

3.2 Актор

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

Пример: Клиент, банкомат, платёжный шлюз.

3.3 Основной и вспомогательный акторы

  • Основной актор: Инициирует сценарий использования.

  • Вспомогательный актор: Поддерживает основного актора (например, сервер банка).

3.4 Предусловия

Условия, которые должны быть истинными до начала сценария использования.

Пример: Пользователь должен иметь действительную карту и правильный PIN.

3.5 Постусловия

Условия, которые должны быть истинными после завершения сценария использования.

Пример: Выданы наличные, баланс счёта обновлён.

3.6 Основной сценарий успеха (основной поток)

Наиболее распространённый путь через сценарий использования, приводящий к успеху.

Пример: Вставить карту → Ввести PIN → Выбрать снятие → Ввести сумму → Получить наличные.

3.7 Альтернативные потоки (потоки исключений)

Ветви в сценарии использования, обрабатывающие исключения, ошибки или вариации.

Пример: Неверный PIN → Повторить или отменить.

3.8 Расширения

Точки в основном потоке, где можно вставить альтернативное поведение (например, с помощью «<>» в UML).

Пример: «<>: Уведомить банк о подозрительной деятельности.»

3.9 Нefункциональные требования (NFRs)

Ограничения поведения системы (например, производительность, безопасность, удобство использования).

Пример: «Транзакция должна быть завершена за 3 секунды.»

4. Процесс детализации вариантов использования (пошагово)

Шаг 1: Определение варианта использования

Начните с высокого уровня варианта использования (например, «Сделать заказ»).

Используйте шаблон:
Название варианта использования: Сделать заказ
Основной участник: Клиент
Заинтересованные стороны: Клиент, система управления заказами, платёжный шлюз

Шаг 2: Определение предварительных условий

Перечислите все условия, которые должны быть выполнены до начала варианта использования.

  • Клиент авторизован.

  • В корзине покупок содержится хотя бы один товар.

  • Способ оплаты сохранён.

Шаг 3: Определение постусловий

Укажите, что должно быть верным после завершения варианта использования.

  • Заказ создан в системе.

  • Инвентарь обновлён.

  • Оплата обработана.

  • Отправлено письмо подтверждения.

Шаг 4: Написание основного сценария успеха (основной поток)

Опишите идеальный, успешный путь.

  1. Клиент выбирает «Оформить заказ» из корзины покупок.

  2. Система отображает сводку заказа.

  3. Клиент подтверждает адрес доставки.

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

  5. Система обрабатывает оплату.

  6. Оплата подтверждена.

  7. Система создает заказ и генерирует подтверждение.

  8. Подтверждение отображается, и отправляется электронное письмо.

Шаг 5: Определение альтернативных потоков (исключительных потоков)

Перечислите возможные отклонения от основного потока.

Альтернативный поток A: Недостаточный остаток на складе

  1. Система проверяет наличие товара.

  2. Товар отсутствует на складе.

  3. Система отображает сообщение: «Товар недоступен».

  4. Покупатель может удалить товар или продолжить без него.

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

  1. Оплата отклонена.

  2. Система отображает ошибку: «Оплата отклонена».

  3. Покупатель может повторить попытку или выбрать другой способ оплаты.

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

  1. Система проверяет адрес.

  2. Адрес недействителен.

  3. Система предлагает покупателю исправить его.

Шаг 6: Определение расширений (связи <>)

Используйте расширения в стиле UML для отображения опционального поведения.

  • <>: Уведомить систему учета запасов

    • Событие: Когда товар отсутствует на складе при оформлении заказа.

    • Цель: Уведомить склад о пополнении запасов.

  • <>: Применить купон на скидку

    • Событие: Покупатель вводит действительный код купона.

    • Цель: Снизить общую стоимость.

Шаг 7: Добавление нефункциональных требований (NFR)

Включить ограничения системы.

  • Заказ должен быть обработан в течение 5 секунд.

  • Оплата должна быть зашифрована с использованием TLS 1.3.

  • Система должна поддерживать 10 000 одновременных пользователей.

Шаг 8: Проверка и подтверждение

Сотрудничайте со заинтересованными сторонами, чтобы обеспечить полноту и точность.

  • Спросите: «Охватывает ли это все цели пользователя?»

  • Спросите: «Рассмотрены ли все крайние случаи?»

  • Спросите: «Может ли разработчик создать на основе этого?»

5. Инструменты и методы детализации

Инструмент/метод Цель
Диаграмма случаев использования (UML) Визуализировать участников и случаи использования.
Диаграмма последовательности Показать поток сообщений между объектами во время использования.
Диаграмма деятельности Моделировать сложные рабочие процессы и точки принятия решений.
Картирование пользовательских историй Связать случаи использования с путем пользователя и приоритетами.
Таблицы решений Уточнить сложную логику (например, правила скидок).

6. Лучшие практики

  1. Сохраняйте пользовательскую направленность случаев использования: Сосредоточьтесь на целях пользователя, а не на функциях системы.

  2. Используйте единообразное наименование: Используйте формат глагол-существительное (например, «Обновить профиль»).

  3. Избегайте технической терминологии: Пишите для не технических заинтересованных сторон.

  4. Используйте простой язык: Будьте ясными и краткими.

  5. Итерировать: Уточняйте случаи использования по мере роста понимания.

  6. Связать с другими артефактами: Связывайте случаи использования с диаграммами классов, тестовыми случаями и пользовательскими историями.

  7. Приоритизировать: Сначала сосредоточьтесь на случаях использования с высокой стоимостью или высоким риском.

7. Реальный пример: Онлайн-банкинг — Перевод денег

Случай использования: Перевод денег

Основной участник: Клиент
Второстепенный участник: Сервер банка, система обнаружения мошенничества

Предусловия

  • Клиент авторизован.

  • На исходном счете достаточно средств.

  • Лимит перевода не превышен.

Постусловия

  • Средства переведены с исходного счета на целевой.

  • Транзакция зафиксирована в обоих счетах.

  • Уведомление отправлено обеим сторонам.

Основной сценарий успеха

  1. Клиент выбирает «Перевод денег» на панели управления.

  2. Система отображает форму перевода.

  3. Клиент вводит целевой счет и сумму.

  4. Система проверяет счет и сумму.

  5. Клиент подтверждает перевод.

  6. Система проверяет правила обнаружения мошенничества.

  7. Транзакция одобрена и выполнена.

  8. Показывается сообщение подтверждения.

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

  • A1: Недостаточно средств
    → Система отображает: «Недостаточно средств.»
    → Клиент может отменить или изменить сумму.

  • A2: Обнаружена мошенничество
    → Система блокирует перевод и отправляет оповещение.
    → Клиент должен подтвердить через двухфакторную аутентификацию или связаться со службой поддержки.

  • A3: Неверный счет получателя
    → Система отображает: «Счет не найден.»
    → Клиент может повторно ввести данные или воспользоваться поиском счета.

Расширения

  • <>: Отправить уведомление получателю

    • Событие: Перевод завершен.

    • Цель: Уведомить получателя.

  • <>: Начислить комиссию за перевод

    • Событие: Сумма перевода > 1000 долларов США.

    • Цель: Списать комиссию в размере 5 долларов.

Нефункциональные требования

  • Все переводы должны быть зафиксированы и подлежать аудиту.

  • Время отклика ≤ 2 секунды.

  • Данные зашифрованы при передаче и в состоянии покоя.

8. Распространенные ошибки и способы их избежать

Ошибки Решение
Слишком общие формулировки (например, «Система должна обрабатывать заказы») Используйте конкретные, измеримые действия.
Избыточно технический язык Используйте естественный язык; избегайте терминов программирования или баз данных.
Отсутствуют альтернативные пути обработки ошибок Используйте альтернативные потоки для покрытия сбоев.
Нет четких критериев успеха Четко определите постусловия.
Отсутствует обзор заинтересованных сторон Привлекайте пользователей, тестировщиков и бизнес-аналитиков.

9. Заключение

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

✅ Последний совет: Рассматривайте разработку сценариев использования как итеративный диалог, а не одноразовую задачу. Уточняйте его по мере того, как вы узнаете больше о системе и ее пользователях.

Приложение: Шаблон для разработки сценариев использования

# Название сценария использования: [например, Обновить профиль]

**Основной участник**: [например, Клиент]  
**Второстепенные участники**: [например, База данных, Сервис электронной почты]  
**Заинтересованные стороны**: [например, Клиент, Команда поддержки]

### Предусловия
- [Список условий]

### Постусловия
- [Список результатов]

### Основной сценарий успеха (основной поток)
1. [Шаг 1]  
2. [Шаг 2]  
...

### Альтернативные потоки
- **A1: [Название]**  
  1. [Шаг]  
  2. [Шаг]  
- **A2: [Название]**  
  ...

### Расширения (<<extend>>)
- **<<extend>>: [Название]**  
  - Триггер: [Когда]  
  - Цель: [Зачем]

### Нefункциональные требования
- [Производительность, безопасность, удобство использования и т.д.]

### Примечания
- [Дополнительный контекст или предположения]

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

Приложение – Описание сценария использования для снятия наличных с банкомата:

Название сценария использования

Снять наличные

Основной участник

Клиент (владелец банковского счета)

Второстепенные участники

  • Банкомат

  • Сервер банка (система основного банковского обслуживания)

  • Платежный шлюз (для обработки транзакций)

  • Система обнаружения мошенничества

  • Принтер (для генерации чека)

Заинтересованные стороны и их интересы

  • Клиент: Хочет снять наличные безопасно и эффективно.

  • Банк: Обеспечивает целостность транзакций, предотвращение мошенничества и точное обновление счетов.

  • Оператор банкомата: Обеспечивает доступность машины и наличие наличных.

  • Группа безопасности: Отслеживает подозрительное поведение и предотвращает мошенничество.

Предварительные условия

  1. У клиента есть действительная банковская карта, вставленная в банкомат.

  2. Клиент успешно прошел аутентификацию (ввел правильный PIN).

  3. Счет клиента активен и не заблокирован.

  4. В банкомате достаточно наличных денег в хранилище.

  5. На счете клиента достаточно доступного остатка.

  6. Дневной лимит снятия не превышен.

Постусловия

  1. Клиенту выдан запрашиваемый объем наличных.

  2. Остаток на счете клиента уменьшается на сумму снятых средств.

  3. В системе банка создается запись о транзакции.

  4. Выдается чек (при необходимости).

  5. Банкомат регистрирует транзакцию для аудита и сверки.

Основной сценарий успеха (основной поток)

Шаг Действие системы Отклик участника
1 Банкомат выводит: «Введите свой PIN». Клиент вводит PIN.
2 Банкомат проверяет PIN на сервере банка. Система подтверждает, что PIN правильный.
3 Банкомат отображает главное меню: «Снять наличные, Проверить баланс, Перевод, Выход». Клиент выбирает «Снять наличные».
4 Банкомат выводит: «Введите сумму для снятия». Клиент вводит сумму (например, 100 $).
5 Банкомат проверяет:

  • Сумма находится в пределах дневного лимита.

  • На счете достаточно средств.

  • В банкомате достаточно наличных. | Система подтверждает действительность. |
    | 6 | Банкомат запрашивает авторизацию у сервера банка. | Сервер банка одобряет транзакцию. |
    | 7 | Банкомат выдает наличные из хранилища. | Клиент получает наличные. |
    | 8 | Банкомат предлагает: «Хотите чек?» | Клиент выбирает «Да» или «Нет». |
    | 9 | Если «Да»: банкомат печатает чек с:

  • Дата/время

  • Сумма снятия

  • Остаток на счете

  • Номер транзакции | Клиент получает чек. |
    | 10 | Банкомат отображает: «Спасибо. Пожалуйста, извлеките карту». | Клиент извлекает карту. |
    | 11 | Банкомат возвращается в режим ожидания. | Система сбрасывается. |

✅ Успешный результат: Клиент получает наличные и (по желанию) чек. Счет обновляется.

Альтернативные потоки (сценарии исключений)

A1: Введен неверный PIN-код (3 попытки)

  • Триггер: Клиент три раза вводит неверный PIN-код.

  • Действие системы: Банкомат блокирует карту и отображает: «Карта заблокирована. Обратитесь в свой банк.»

  • Действие пользователя: Клиент уходит и обращается в банк.

  • Постусловие: Карта временно заблокирована; транзакция зарегистрирована.

⚠️ Примечание: Это мера безопасности, предназначенная для предотвращения несанкционированного доступа.

A2: Недостаточно средств

  • Событие: Клиент вводит сумму, превышающую доступный остаток.

  • Действие системы: ATM отображает: «Недостаточно средств. Текущий остаток: $X».

  • Действие актера: Клиент выбирает «Отмена» или вводит меньшую сумму.

  • Постусловие: Наличные не выданы; изменений в счете нет.

A3: Недостаточно наличных в банкомате

  • Событие: Клиент вводит действительную сумму, но в хранилище банкомата пусто или ниже минимального уровня.

  • Действие системы: ATM отображает: «Наличные недоступны. Пожалуйста, попробуйте позже.»

  • Действие актера: Клиент отменяет операцию или возвращается позже.

  • Постусловие: Операция не обработана; изменений в счете нет.

A4: Сумма снятия превышает дневной лимит

  • Событие: Клиент пытается снять сумму, превышающую дневной лимит (например, 1000 $).

  • Действие системы: ATM отображает: «Превышен дневной лимит снятия. Попробуйте меньшую сумму.»

  • Действие актера: Клиент уменьшает сумму или отменяет операцию.

  • Постусловие: Операция не обработана.

A5: Операция отклонена сервером банка

  • Событие: Банковский сервер отклоняет транзакцию (например, из-за предупреждения о мошенничестве, заморозки счета).

  • Действие системы: ATM отображает: «Транзакция отклонена. Пожалуйста, свяжитесь со своим банком.»

  • Действие участника: Клиент отменяет операцию и обращается в банк.

  • Постусловие: Наличные не выданы; изменений на счете нет.

Расширения (<> отношения)

Расширение Событие Цель
<>: Уведомить систему обнаружения мошенничества Когда снятие средств производится в иностранной стране или превышает типичное поведение Отметить подозрительную активность для проверки
<>: Отправить SMS-оповещение клиенту После успешного снятия средств Уведомить клиента о транзакции (повышенная безопасность)
<>: Начислить комиссию за снятие средств Для неосновных держателей счетов или определенных типов счетов Начислить плату за определенные услуги
<>: Распечатать историю транзакций Если клиент выбирает «Распечатать историю» в меню Предоставить распечатанное резюме последних транзакций

Нефункциональные требования (NFRs)

Категория Требование
Производительность Транзакция должна быть обработана в течение 3 секунд.
Безопасность Все коммуникации зашифрованы (TLS 1.3). PIN никогда не хранится и не передается в открытом виде.
Надежность Банкомат не должен выдавать наличные, если сервер банка не подтвердит авторизацию.
Пользовательский интерфейс Интерфейс должен быть доступным (например, крупные кнопки, голосовое руководство для слабовидящих).
Доступность Банкомат должен быть в рабочем состоянии 99,9% времени.
Аудит и соответствие Все транзакции должны быть зафиксированы и подлежать отслеживанию в течение 7 лет (в соответствии с банковскими регуляторными требованиями).

Примечания

  • Банкомат должен регулярно обслуживаться для обеспечения наличия наличных и надежности оборудования.

  • Если карта не будет извлечена в течение 30 секунд после завершения транзакции, она будет автоматически задержана (функция защиты от краж).

  • Система поддерживает несколько валют и расчеты курсов обмена (при необходимости).

Диаграмма вариантов использования (краткое резюме UML)

[Пользователь] --(Снять наличные)--> [Банкомат]
[Банкомат] --(Проверка PIN)--> [Сервер банка]
[Банкомат] --(Проверка средств)--> [Сервер банка]
[Банкомат] --(Выдача наличных)--> [Сейф с наличными]
[Банкомат] --(Печать чека)--> [Принтер]
[Банкомат] --(Уведомление системы мошенничества)--> [Система обнаружения мошенничества]

(Примечание: в полной диаграмме UML отношения между вариантами использования, такие как <> и <>, будут отображены.)

✅ Резюме

Этоподробный вариант использованиядля «Снятие наличных» предоставляет четкое, структурированное и проверяемое описание, которое:

  • Фиксирует цели пользователя и поведение системы.

  • Обрабатывает реальные исключения.

  • Поддерживает безопасность, соответствие и удобство использования.

  • Является основой для проектирования, тестирования и реализации.

Он подходит для использования в рамках агILE-спринтов, документации по проектированию системы или формальных спецификаций требований.

📘 Следующие шаги:

  • Преобразуйте это вдиаграмму последовательностипоказать взаимодействие объектов.

  • Создатьтестовые случаина основе каждого потока (основного и альтернативного).

  • Ссылка надиаграммы классов (например,Счет, Транзакция, Банкомат, Система обнаружения мошенничества).

Related Posts

Recent Comments

Нет комментариев для просмотра.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...