Определение вариантов использования на основе бизнес-процесса

Команды разработки могут использовать модель бизнес-процесса для визуального документирования бизнес-процессов и связывать варианты использования с этими бизнес-процессами для моделирования желаемых функций, которые должна обеспечить система. В этом руководстве мы подробно объясним, как использовать функцию Model Transitor для установления взаимосвязи между вариантами использования и бизнес-процессами.

Что такое BPMN и BPD?

BPMN предоставляет бизнес-аналитикам набор графических обозначений для моделирования бизнес-процессов. Он был первоначально разработан Инициатива по управлению бизнес-процессами (BPMI) и в настоящее время поддерживается Группой по управлению объектами (OMG). Одной из причин разработки BPMN является предоставление общего графического языка для людей с разными ролями, из разных стран и/или с разными языками, чтобы они могли понимать один и тот же бизнес-процесс без барьеров.

BPD, сокращение от диаграммы бизнес-процессов, где моделируется бизнес-процесс с использованием BPMN. Это диаграмма, похожая на блок-схему, которая отображает поток процесса, участников и обмен сообщениями между ними. Бизнес-аналитики рисуют BPD для моделирования того, как различные участники взаимодействуют для достижения бизнес-цели. После проверки завершённой модели бизнес-процесса с конечными пользователями системный аналитик может приступить к планированию системы.

Ниже представлена простая BPD процесса регистрации для организации. Она охватывает большинство типичных обозначений моделирования, с которыми вы можете столкнуться. Давайте рассмотрим её.

Обозначение	Описание
	Pool — представляет участника в процессе. В BPMN для представления участников используются как pool, так и lanes. Lane содержится в pool для моделирования подраздела родительского pool.
	Событие начала — начало процесса. Можно определить триггеры, чтобы сообщить читателям, в каких ситуациях будет запущен процесс. Например, когда получен электронное письмо/когда наступает понедельник утром/когда произошла ошибка.
	Задача — атомарная деятельность, которую могут выполнить назначенные участники (моделируемые с помощью pool/lane). Задачи и другие объекты потока соединяются вместе, чтобы образовать полный бизнес-процесс.
	Событие окончания — конец процесса. Можно определить результат, чтобы сообщить читателям, что произойдёт, когда процесс завершится. Например, отправить сигнал/выдать ошибку и т.д.

В этом руководстве мы не будем сильно углубляться в BPD или моделирование бизнес-процессов. Если вы хотите узнать больше о BPMN, BPD или моделировании бизнес-процессов, пожалуйста, прочитайте руководство «Введение в »BPMN Часть I–IV.

Что такое диаграмма вариантов использования?

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

В диаграмме вариантов использования три основных элемента.

Обозначение	Описание
	Случай использования – каждый случай использования представляет цель пользователя, то есть цель, которую пользователь системы хочет достичь. Обратите внимание, что случаи использования можно использовать только для демонстрации того, что хочет сделать пользователь, а не того, что разработчику необходимо разработать, хотя в некоторых случаях это может совпадать. Если вы хотите документировать или моделировать функции, участвующие в случае использования, вы можете использовать инструмент «поток событий» или расширить случай использования с помощьюдиаграмма последовательности/диаграмма деятельности. Помните, что моделирование случаев использования направлено на моделирование того, что пользователь хочет достичь.
	Актор – пользователь системы. Слово «пользователь» здесь не ограничивается людьми. Это может быть система, взаимодействующая с нашей системой для достижения определенной бизнес-цели.
	Связь связи/ассоциация – соединяет актора и случай использования, чтобы показать доступ актора к системе. Каждая связь подразумевает последовательность транзакций между актором и системой.

Переход от BPD и диаграммы случаев использования

Хотя BPD и диаграмма случаев использования не обязательно должны зависеть друг от друга, они могут быть связаны друг с другом в комплементарной манере. Обычно мы разрабатываем программное обеспечение для автоматизации или оптимизации определенных рабочих процессов бизнес-процессов. С помощью BPD вы можете понять, как участники взаимодействуют между собой и кто отвечает за что, а также определить, какие функции им необходимы от системы. Эти функции системы (рабочий процесс или бизнес-процесс), которые хочет пользователь, могут быть смоделированы с помощью случаев использования и затем разработаны командой. В результате можно сказать, что BPD помогает вам выявить случаи использования для разрабатываемой системы.

Visual Paradigm — это инструмент визуального моделирования, который поддерживает от выполнения бизнес-процессов до моделирования случаев использования (от бизнес-требований к требованиям приложения), устанавливая связи отслеживаемости между двумя моделями с помощью функции перехода между моделями. Нам необходима отслеживаемость по следующим причинам:

• Мы можем убедиться, что система соответствует реальному использованию, изучая часть потока процесса, вовлеченного в случай использования.
• Чтобы ответить на вопросы, такие как «Зачем нам нужна эта (системная) функция?», отслеживая часть процесса, из которой произошел переход случая использования.
• Чтобы ответить на вопросы, такие как «Была ли уже реализована конкретная операция?», отслеживая от BPD к диаграмме случаев использования.

BPD против диаграммы случаев использования

Когда вы переходите от BPD к диаграмме случаев использования, вы можете создать актора из линии/пула, а также создать случай использования из задачи/подпроцесса. В следующей таблице показаны характеристики пула, линии, актора, задачи, подпроцесса и случая использования с точки зрения перехода между моделями.

Из	В	Описание
		Пул/Линия в Актор В BPD пул представляет участника бизнес-процесса, а линия — подразделение пула. Любой, кто выполняет деятельность, связанную с процессом, считается участником. В диаграмме случаев использования актор представляет пользователя системы. Помните, что любой человек или роль, не являющийся пользователем системы, не должен рассматриваться как актор.
		Задача/Подпроцесс в Случай использования В BPD задача/подпроцесс (действие) относится к любому действию, которое может выполнить участник для завершения бизнес-процесса. В диаграмме случаев использования случай использования представляет цель, которую пользователь хочет достичь, используя систему. Помните, что действие не обязательно должно быть связано с какой-либо функцией системы, и один случай использования может удовлетворять нескольким действиям.

Некоторые люди могут думать, что диаграмма случаев использования похожа на BPD, но отличается в нотациях и целях. Помните, что BPMN разработан для бизнес-специалистов, а диаграмма случаев использования — для системных аналитиков или разработчиков систем. Они служат разным целям и рассматривают бизнес с двух разных точек зрения. Именно поэтому в предыдущем разделе я резюмировал связь между BPD и диаграммой случаев использования, сказав: «BPD помогает вам выявить случаи использования». BPD может дать вам лишь подсказки при выявлении случаев использования. Нет правила, которое утверждало бы, что каждая задача, существующая в BPD, эквивалентна случаю использования. Однако мы можем расширить бизнес-процесс с помощью случая использования для автоматизации функции целевой системой.

В случае изучения я дам вам некоторые идеи о том, на что следует обращать внимание при переходе от BPD к диаграмме случаев использования. Тогда вы поймете, насколько они различаются.

Кейс-стади: Компания по производству дистиллированной воды True Aqua

Компания по производству дистиллированной воды True Aqua — молодой поставщик дистиллированной воды в городе. Они продают дистиллированную воду для бизнеса и домашнего использования. Ниже приведено текстовое описание их процесса доставки воды.

На основе описания был создан модель бизнес-процесса. Теперь вам необходимо разработать компьютерную систему для оптимизации всего процесса. Первое, что вам нужно сделать, — это разработать модель случая использования. С помощью BPD попробуйте разработать диаграмму случаев использования.

1. СкачатьDelivery.vpp. Вы также можете найти этот файл в конце этого руководства.
2. Откройте загруженный файл .vpp в Visual Paradigm. Чтобы открыть проект, выберитеПроект > Открыть из панели инструментов приложения.
3. Откройте BPDПроцесс заказа дистиллированной воды. Тщательно изучите поток процесса.
   
4. Процесс начинается, когда клиент размещает заказ. Здесь мы можем рассмотреть вариант использования — Разместить заказ. Этот вариант использования поможет автоматизировать процесс, обеспечив интерфейс для размещения заказа клиентом без участия ассистента службы поддержки клиентов, проверить личность клиента и создать учетную запись, если клиент не существует. Щелкните правой кнопкой мыши по «Разместить заказ» и выберитеСвязанные элементы > Перейти к новому варианту использования… из всплывающего меню.
   
5. Это вызывает окноПереход элемента моделиокно, в котором можно выбрать модель для размещения варианта использования и актера, а также переименовать их. В данном случае мы довольны именами варианта использования и актера. Давайте оставим их без изменений. НажмитеОК.
   
   Это создает новый диаграмму вариантов использования в UeXceler.
   
6. Вернитесь к BPD.
7. Рассмотрим задачуСоздать учетную запись клиента. В бизнес-процессе ассистент службы поддержки клиентов должен создавать учетную запись для каждого нового клиента. В новой системе это может быть частью варианта использованияРазместить заказ, или отдельным вариантом использования, который запускается вручную ассистентом службы поддержки клиентов. В реальных условиях вы должны уточнить подобные сомнения с заинтересованным лицом, поскольку неверная модель вариантов использования приведет к разработке функций, не соответствующих ожиданиям пользователя. В этом примере предположим, что пользователь хочет, чтобы задачаСоздать учетную запись клиентавыполнялась ассистентом службы поддержки клиентов. Давайте создадим вариант использования на основе нее. Щелкните правой кнопкой мыши поСоздать учетную запись клиента и выберитеСвязанные элементы > Перейти к новому варианту использования… из всплывающего меню.
   
8. Опять же, нам нравятся имя варианта использования и актера. Оставьте все в окнеПереход элемента моделибез изменений. НажмитеОК. Диаграмма вариантов использования обновлена с новым вариантом использования и актером. Давайте посмотрим.
   
9. Вернитесь к BPD. Перейдем к подпроцессуОрганизовать доставку. Менеджер отдела логистики может использовать систему для планирования и уведомления рабочих о доставке воды. Следовательно, это также вариант использования системы. Щелкните правой кнопкой мыши по подпроцессуОрганизовать доставку и выберитеСвязанные элементы > Перейти к новому варианту использования… из всплывающего меню.
10. Проверьте актера Менеджер в окнеПереход элемента модели окне. Если мы сохраним имя актера какМенеджер, это неоднозначно в модели вариантов использования, поскольку в компании может быть много отделов с разными менеджерами. Следовательно, переименуйте актера вМенеджер отдела логистики.
    
11. НажмитеОК. Диаграмма вариантов использования обновлена.
    
12. Вернитесь к BPD. Последняя задачаДоставить воду— это задача, которую может выполнять только человек, и она не связана с взаимодействием с системой. Следовательно, нам не нужно создавать вариант использования для нее.
13. Предположим, что региональный менеджер хочет, чтобы система поддерживала новую функцию, которая может генерировать отчет, показывающий статистику по заказам. Эта функция может помочь ему проанализировать и улучшить маркетинговую стратегию. Хотя эта функция не была смоделирована в модели бизнес-процесса, мы можем нарисовать ее непосредственно на диаграмме вариантов использования. Откройте диаграмму вариантов использования. Нарисуйте актераРегиональный менеджер. Создайте вариант использованияСоздать отчет по статистике от него с связью между ними.
    
14. Предположим, клиент хочет разрешить клиенту просматривать счета и отменять заказ. Кроме того, клиент хочет разрешить менеджеру отдела логистики печатать отчет по логистике. Нарисуйте соответствующие варианты использования.
    
15. Упорядочьте диаграмму.
    
16. Связь перехода позволяет отслеживать модель бизнес-процесса из модели вариантов использования (и наоборот). Давайте попробуем. Поместите указатель мыши наОформить заказ случаи использования.
    
17. Нажмите на Модель передачи ресурс в нижнем правом углу фигуры. Выберите Переход от > Процесс заказа дистиллированной воды <. Оформить заказ из всплывающего меню.
    
    Это открывает BPD с задачей Оформить заказ выбрано.