BPMN (нотации моделирования бизнес-процессов) используется для моделирования бизнес-процессов с помощью визуализации, благодаря чему нематериальные идеи становятся физически конкретными благодаря выражению диаграмм BPMN. Вопрос в том, , как мне организовать BPMN с UML .
Изначально я подумал о двух способах организации сценариев использования и диаграммы бизнес-процессов:
1 к одному / многим: Путем сопоставления каждого шага (step здесь означает каждый узел на диаграмме BPMN) в диаграмме бизнес-процесса с одним или несколькими вариантами использования. Каждый вариант использования сопоставляется с соответствующими диаграммами классов / диаграммами компонентов (я предпочитаю этот, поскольку вы можете инкапсулировать набор классов в один компонент, который имеет вход и выход), несколько диаграмм последовательности (необязательно). После того, как у вас есть диаграммы классов / диаграммы последовательности, код пишется / генерируется на основе модели.
Много к одному: Путем сопоставления нескольких этапов в одном сценарии использования. Шаги подпоследовательности одинаковы.
Много ко многим: Например, один шаг в бизнес-процессе может быть сопоставлен с двумя или более вариантами использования, а те же два или более вариантов использования могут быть сопоставлены с другими шагами.
Вышеуказанные методы могут быть выполнены с помощью инструмента моделирования, и в моем случае я использую Enterprise Architect из Sparx System. Я обнаружил это недавно, и я использую его пробную версию, но я буду покупать его в будущем. Я могу организовать множество диаграмм вариантов использования с помощью одного шага диаграммы BPMN и щелкнуть, чтобы просмотреть необходимые варианты использования. Тем не менее, я не могу, если он поддерживает много-много случаев.
Подумав о моем собственном методе организации BPMN и вариантов использования, я поискал в Интернете и нашел две другие статьи, каждая из которых предлагает следующий метод:
Превратите каждый сценарий использования в каждый шаг диаграмм BPMN: Чтобы визуализировать, как уточненные сценарии использования вписываются в бизнес-процесс. Мне нравится этот подход, так как бизнес-процесс с шагами можно моделировать, а затем каждый шаг превращается в вариант использования. Один шаг - один вариант использования. Это то же самое с моим отображением один на один выше. Оригинальная презентация здесь: Визуализация наборов вариантов использования в качестве процессов BPMN
Каждый вариант использования - это точно бизнес-процесс: Каждый шаг в сценарии использования - это каждый шаг бизнес-процесса. Оригинал статьи здесь: Описание бизнес-процессов с вариантами использования
Мне кажется, что не существует стандартизированного способа склеивания этих артефактов (BPMN и Use Cases и других биграмм) вместе. Может быть, это проблема управления и больше полагаться на творческое использование, чем на формальные шаги. Как вы оцениваете использование этих диаграмм в процессе разработки программного обеспечения?
Я знаю методологию, подобную XP, которая определяет собственную практику в процессе разработки программного обеспечения. Однако, в отличие от Scrum, где он больше фокусируется на аспектах управления (что означает, что вы все еще можете применять моделирование BPMN / UML в своем рабочем процессе), XP определяет методы работы с программным обеспечением и требует от вас следовать и исключать процесс моделирования, такой как BPMN / UML, и его практика, если не применяется должным образом, приведет к таким проблемам, как в документации, включает в себя недостаточный дизайн программного обеспечения ....
Я предпочитаю управляемый моделью способ, чем XP. Я думаю, это зависит от предпочтений компаний и людей. Одна из целей Agile - «освободить разработчиков от работы с документами». Методология, подобная XP, кажется, легко приводит к недооценке. Я думаю, что для достижения этой цели решение состоит в том, чтобы внедрить инструмент, помогающий разработчику уменьшить нагрузку при написании документа, а не писать меньше документов, собирая информацию из существующих диаграмм и автоматически генерируя отчеты (в RTF, PDF, HTML в случае Предприятия Архитектор Sparx System). Другой пример: люди часто жалуются на то, что рисование диаграмм тратит их время. На мой взгляд, решение состоит не в том, чтобы нарисовать диаграмму, а в использовании инструмента. Сегодня инструменты моделирования поддерживают проектирование в обоих направлениях, где вы можете синхронизировать код и диаграммы, что исключает дополнительные усилия по ручной коррекции диаграмм в случае изменения базы кода (в частности, диаграмм классов). Каково ваше мнение / опыт по этому вопросу?