[перевод «Quick Tip 76: How to write use cases for batch processes» By Maria Amuchastegui, IIBA.org]
Перевод выполнил: Соколовский Николай (sokolovskynik@gmail.com).
Если вы работаете хоть какое-то время в качестве БА, вас вероятно уже просили написать спецификацию случаев использования (use case specification, далее use case). И на это есть причины. Use cases — это мощная техника для описания функций системы, понимаемая заинтересованными сторонами со стороны бизнеса и полезная для IT специалистов.
Но написание use cases может быть трудным. В лучшем случае вы описываете веб-приложение, где взаимодействие пользователя и системы предельно ясно. В худшем случае вас просят написать use cases для пакетного взаимодействия двух или более систем, взаимодействующих друг с другом и без видимого участия человека. Вы работаете с процессом, который выдает данные, но без очевидного пользователя.
Use case популярны, поскольку описывают интерфейсы. Заинтересованные лица со стороны бизнеса любят use case поскольку они описывают то, что нужно пользователю на каждом шаге и что система на каждом шаге будет отвечать. В конце концов, use case часто сопровождаются моками, показывающими то, как система будет отвечать на каждом шаге. Разработчики любят use case поскольку они определяют входные и выходные данные, без ограничения на то, как система будет спроектирована «под капотом». И на конец, тестеры любят use case поскольку из них прямо вытекают сценарии тестирования. Для каждого набора входных данных заранее определен результат.
Contents
Следует ли писать use case для пакетной обработки?
Существуют аргументы за то, чтобы никогда не писать use case для обработки пакетов. Они не очень полезны, поскольку если БА попросят написать use case для обработки пакетов, он все равно должен это сделать и сделать это правильно. Есть способ написать use case для обработки пакетов, как бы теоретизированно это не звучало.
Думайте о use case как о виде спецификаций интерфейса, которая описывает, что будет на входе и выходе каждого шага. Это будет выглядеть, как будто вы используете поток use case. После чего описание обработки пакетов может не иметь пользователей, но будет иметь входы и выходы.
Какой тип диаграмм лучше всего подходит для анализа обработки пакетов?
Обычно диаграмма use case отображает взаимодействие с пользователем. Use case model показывает границу между пользователем и системой. UML диаграмма активности (uml activity diagram) по частям отображает взаимодействие между системой и пользователем (ее также называют «скользящей (swim lane)» диаграммой)
Для описания обработки пакетов с помощью use case в любом случае вам потребуется создать диаграмму потока (flow diagram) или uml activity diagram без участников. Диаграмма потока должна отображать все возможные входные данные и ветки процесса обработки пакета. Каждая ветка должна быть отдельным потоком в use case
Как много шагов должен включать в себя каждый поток?
Обычно use case диаграммы описывают взаимодействия между пользователем и системой в множеством шагов таких как: регистрация, навигация по секциям сайта и т.п. Но для обработки пакета каждый поток должен содержать только два шага: (1) система получает данные на вход, (2) система подает данные на выход. И ничего больше!
Как это может выглядеть?
Рассмотрим пример. Предположим, у вас есть процесс обработки пакетов, запускаемый периодически, который выдает список клиентов, которым запрещено использовать ATM систему (банкомат). Когда люди пытаются использовать банкомат, система перед выдачей доступа проверяет этот список.
Блок схема может выглядеть как-то так:
Как вы можете видеть, диаграмма имеет три ветки, каждая из которых может стать потоком в use case. Обратите внимание, что на ней четыре возможных потока которые не отображены в блок-схеме, но которые должны быть отражены в таблице решений. (Например, банковский грабитель (bank robber) = ДА, отмыватель денег (money launderer) = ДА)
Спецификация use case может выглядеть так:
Use Case ID: UC-01
Use Case Name: Создание списка забаненых пользователей
Use Case Description: Данный use case описывает шаги системы для создания списка забаненых пользователей банкомата.
System: Банкомат
Actor(s): Системный таймер
Trigger: Время получения пакета для обработки
Preconditions: Обработка пакета еще не начата
Postconditions: Обработка пакета завершена
Основной поток:
Система проверяет каждого пользователя в системе и проверяет их на следующие критерии:
Bank Robber = нет
Money Launderer = нет. Система записывает сообщение «вы зашли!» в лог.
Альтернативный поток 1
Система проверяет каждого пользователя в системе и проверяет их на следующие критерии:
Bank Robber = да
Money Launderer = нет. Система добавляет пользователя в список забаненых ATM системой.
Альтернативный поток 2
Система проверяет каждого пользователя в системе и проверяет их на следующие критерии:
Bank Robber = нет
Money Launderer = да. Система добавляет пользователя в список забаненых ATM системой.
Альтернативный поток 3
Система проверяет каждого пользователя в системе и проверяет их на следующие критерии:
Bank Robber = да
Money Launderer = да. Система добавляет пользователя в список забаненых ATM системой.
За дополнительной информацией обращайтесь к руководству BABOK v3 — 10.47 use case и сценарии.