Я смотрел на моделирование бизнес-процессов и немного озадачен связями между различными целями (поддержка стратегии, документирование процессов, автоматизированное выполнение …), аудиторией (LOB, бизнес-аналитики, разработчики …) и инструментами (редактор процессов, реестр, симуляционный стенд, IDE…). Я вижу, как было бы хорошо, чтобы все они хорошо играли вместе. Что я не совсем понимаю, так это то, как нынешние инструменты достигают этого.
Одним из примеров является цель улучшения взаимодействия между бизнес-аналитиками и разработчиками, позволяя аналитикам захватывать как можно большую часть намеченного процесса таким образом, чтобы его могли легко использовать разработчики. Это достойная цель, и она должна быть в конечном итоге достижимой (хотя, возможно, в переформулированной форме), основанной на тенденциях в отрасли (которые могли бы подумать, что когда-нибудь деловые люди будут использовать свои собственные компьютеры для извлечения бизнес-данных вместо того, чтобы оператор печатал документы для их). Но это все еще очень трудная цель, для которой необходимо преодолеть многие врожденные барьеры (с точки зрения общего словарного запаса, навыков и мышления). Я обеспокоен тем, что нынешние подходы добавляют много искусственных барьеров тем, кто присущ этой проблеме.
Одним из источников таких искусственных барьеров является то, что в игру вступают несовместимые языки описания бизнес-процессов. Одним из распространенных примеров является использование BPMN для моделирования на уровне аналитиков с последующим переводом в BPEL для задач разработки. Я столкнулся с примером несовместимости между этими двумя очень рано в моих экспериментах с BPMN, в форме «включающего ИЛИ» (ромб с кругом внутри в BPMN).
Это позволяет вам выразить что-то вроде этого: «Предложение клиента может быть просмотрено региональным менеджером, региональным менеджером или вице-президентом по продажам. По крайней мере, один из них должен просмотреть цитату. Больше чем один может рассмотреть цитату ». Моя первая мысль при встрече с этой конструкцией была «как это сопоставить с BPEL», поскольку не существует эквивалентной конструкции BPEL. Почесав голову, я мог придумать два способа сделать это, ни один из которых не очень красив. Один из них состоит в том, чтобы превратить это в грубое перечисление всех юридических комбинаций («1», «1 и 2», «1, 2 и 3», «2», «2 и 3», «3»), которые может выйти из-под контроля довольно быстро, если у вас более трех веток. Другой полагается на обработчики событий, В обоих случаях вы получите определение процесса BPEL, которое должно правильно интерпретироваться механизмом выполнения BPEL, но его трудно прочитать разработчикам и почти невозможно вернуться к хорошему описанию BPMN.
Несколько подобных угловых случаев в переводах BPMN в BPEL описаны в этой статье , в которой авторам также приходится прибегать к обработчикам событий BPEL. Вы можете найти подходы для улучшения отображения BPMN в BPEL в этой статье (также посмотрите список ссылок, включая эту статью , для более подробного исследования проблемы).
Из любопытства я выполнил перевод BPMN «включающее ИЛИ» с помощью инструмента Aris для Oracle, и вот получившийся фрагмент BPEL в JDeveloper (нажмите на картинку для полноразмерной версии):
Вот очищенное представление результирующего BPEL (необязательные задачи представлены только «пустыми» элементами, потому что они ожидают заполнения реальными инструкциями по обработке):
<flow name="OR__inclusive_">
<sequence>
<switch name="OR__inclusive_">
<case>
<sequence>
<scope name="Optional_task_3">
<sequence>
<empty name="Optional_task_3"/>
</sequence>
</scope>
</sequence>
</case>
<case>
<sequence>
<empty name="Empty"/>
</sequence>
</case>
</switch>
</sequence>
<sequence>
<switch name="OR__inclusive_">
<case>
<sequence>
<scope name="Optional_task_1">
<sequence>
<empty name="Optional_task_1"/>
</sequence>
</scope>
</sequence>
</case>
<case>
<sequence>
<empty name="Empty"/>
</sequence>
</case>
</switch>
</sequence>
<sequence>
<switch name="OR__inclusive_">
<case>
<sequence>
<empty name="Empty"/>
</sequence>
</case>
<case>
<sequence>
<scope name="Optional_task_2">
<sequence>
<empty name="Optional_task_2"/>
</sequence>
</scope>
</sequence>
</case>
</switch>
</sequence>
</flow>
Этот инструмент делает выбор в пользу читабельности BPEL за счет точности. BPEL гораздо приятнее, но в нем не учитывается тот факт, что должна быть выполнена хотя бы одна из дополнительных задач (механизм выполнения BPEL позволит экземпляру пройти через все три «пустые» конструкции, минуя все дополнительные задачи). В нашем примере это означает, что предложение клиента может остаться без какого-либо анализа со стороны руководства, даже если бизнес-требование должно иметь хотя бы один.
Это потенциально хуже, чем не позволить аналитику указать «по крайней мере одно» бизнес-требование: аналитик предполагает, что требование зафиксировано (поскольку оно передается в потоке BPMN), но разработчик никогда не видит его (предположим, что разработчик получает только удержание сгенерированного BPEL). Если аналитик не сможет ввести требование в BPMN, он / она, по крайней мере, с большей вероятностью добавит это в качестве автономного комментария, который разработчик должен принять во внимание.
Как иллюстрируют все исследовательские работы, на которые я ранее ссылался, это несоответствие между BPMN и BPEL является известной проблемой, которую люди потратили много усилий, пытаясь ее исправить. Но в отсутствие удовлетворительного решения я продолжаю спрашивать себя, лучше ли обойти эту проблему, чем решить.
Я не тот, кто избегает модельных переводов (в противном случае я был бы не в том деле), но я вижу модельный перевод как инструмент, который можно злоупотреблять. В текущем состоянии, ставя себя на место разработчика BPEL, я предпочел бы получить хороший поток BPMN, чем странный процесс BPEL, который был сгенерирован автоматически.
У меня нет решения проблемы. Может быть, это определить реализуемое подмножество BPMN (или дружественное к аналитику подмножество BPEL, которое может быть по существу тем же самым). Или, возможно, не все проходит через явное моделирование бизнес-процессов. В любом случае разработчику понадобятся контрольные примеры, поэтому, возможно, правильный подход — предоставить общий обзор процесса, сопровождаемого кучей тестов. Я вижу систему, в которой механизм моделирования бизнес-процессов будет использоваться для генерации тестовых сообщений, и аналитик будет шаг за шагом сообщать, что происходит с каждым сообщением. Пользовательский интерфейс может быть спроектирован таким образом, чтобы инструмент мог знать, какой элемент сообщения / контекста наблюдает аналитик, чтобы выбрать следующий шаг. И поток реализации соломенного человека может даже генерироваться на основе того, как аналитик отправляет сообщения.По крайней мере, сообщения могут быть использованы для запуска модульных тестов. Инструменты анализа бизнес-процессов уже знают, как запускать симуляции процессов (за исключением того, что они основаны на статистических правилах, определяющих, какие ветви выбираются, а не взаимодействуют с аналитиком).
Просто интересуюсь.