В предыдущей статье мы заложили фундамент для анализатора сложности, определив ключевые метрики для оценки сложности моделей процессов. Теперь разберем, как превратить эту теорию в реально работающий инструмент.
От метрик к уровням сложности
Задача — автоматически разделить модели на три категории: низкая, средняя и высокая сложность. Классический кейс для алгоритмов кластеризации (обучение без учителя). Идея простая: модели с похожими значениями метрик сами собой группируются в кластеры. Простые модели обычно имеют низкие NOAJS и CFC, а сложные — высокие значения этих метрик из-за обилия шлюзов. Для решения выбрали алгоритм K-Means — он отлично подходит для такого сценария.
Подготовка датасета
Как разработчик продукта и консалтинговая компания, мы имеем доступ к огромному репозиторию реальных моделей оркестрации. В итоговый датасет вошли реальные кейсы и демо-приложения, созданные опытными аналитиками из самых разных доменов: медицина, инфраструктура, финансы, производство.
Итоговая выборка:
25 приложений
332 BPMN-процесса
54 CMMN-кейса
Быстрый обзор показал крайне разнообразные стили моделирования:
Кейсы, вызывающие множество небольших процессов
Приложения с огромными BPMN-процессами и без CMMN вовсе
Процессы с event-subprocess и call activity, но без CMMN
Большие CMMN-кейсы с кучей event listener-ов
Разнообразие нас полностью устроило, и мы перешли к очистке и подготовке данных для анализа.
Очистка и нормализация данных
Как и в любом пайплайне машинного обучения, очистка данных оказалась критически важной. Поначалу процессы, состоящие всего из одной активности, выглядели как незначащие и мы хотели их выкинуть. Но при ближайшем рассмотрении выяснилось, что это часто осознанные «делегатные» процессы — например, для очистки данных или отправки писем. Их ценность стала очевидна, и мы оставили их в датасете.
Следующий шаг — нормализация метрик, чтобы все измерения вносили равный вклад. Без нормализации метрики вроде NOAJS (которые могут принимать значения от 0 до бесконечности) полностью подавляли бы метрики типа плотности, у которых значения всегда в диапазоне [0;1]. Для решения применили Min-Max нормализацию — все значения привели к диапазону от 0 до 1. Это обеспечило сбалансированный входной сигнал для кластеризации.
Подход к кластеризации K-Means
Для первой кластеризации алгоритм настроили на создание ровно трех кластеров, соответствующих низкой, средней и высокой сложности. K-Means требует заранее задать количество кластеров; хотя методы вроде «локтя» (elbow method) помогают подобрать оптимальное число, мы с самого начала ориентировались именно на три уровня. Важно: алгоритм работал полностью автономно — без какого-либо ручного вмешательства и разметки, чтобы исключить предвзятость.
Пайплайн кластеризации выглядел следующим образом:
Загружаем все BPMN- и CMMN-модели из датасета.
Считаем значения метрик для каждой модели.
Нормализуем метрики методом Min-Max.
Применяем K-Means и разбиваем модели на три кластера.
Проблемы с разметкой кластеров в K-Means
Ограничение K-Means в том, что он не умеет сам назначать кластерам понятные метки («низкая», «средняя», «высокая» сложность). Можно, конечно, задать начальные центроиды вручную, чтобы «подтолкнуть» результат, но это уже нарушает независимость алгоритма. Поэтому интерпретацию и присвоение меток делали уже после кластеризации. Для проверки результата построили график NOAJS ↔ CFC. Эта визуализация сразу показала, как модели распределились по спектру сложности, и дала четкое понимание, насколько кластеры получились осмысленными.
Анализ графика показал три четко различимых кластера:
Модели с CFC = 0 и NOAJS < 18
Модели с CFC < 40 и NOAJS < 50
Все остальные модели
Исходя из начальной гипотезы — модели низкой сложности обычно не содержат шлюзов и имеют мало активностей — первый кластер был отнесен к низкой сложности. Второй и третий кластеры, демонстрирующие более высокие значения обеих метрик, получили метки средней и высокой сложности соответственно. Такая классификация полностью соответствует ожиданию: чем сложнее модель, тем больше в ней шлюзов и активностей, а значит выше CFC и NOAJS.
Интерпретация результатов
После того как кластеры были определены, следующим шагом стало выяснение, какие именно метрики вносят наибольший вклад в сложность моделей.
Вклад CFC (сложности потока управления)
Как и ожидалось, все модели с CFC = 0 попали в группу низкой сложности. Однако две модели с CFC = 0 оказались в средней группе. При детальном разборе выяснилось, что у них очень высокие значения CNC и каждая из них ссылается более чем на десять других моделей. Это показало: сложность может расти не только за счет шлюзов, но и за счет других факторов.CNC как ключевой признак низкой сложности
Коэффициент связности сети (CNC) стал определяющим для моделей низкой сложности. Простые модели почти всегда имеют низкий CNC: чтобы его увеличить, нужно больше потоков на одну вершину, а это обычно делается через шлюзы. Результат полностью совпал с графиком и подтвердил, что CNC — надежный индикатор сложности.Модели с NOAJS > 60 — однозначно очень сложные
Это было ожидаемо. Любой процесс с NOAJS больше 60 кричит: «Разбейте меня на подпроцессы!». Такие значения сильно засоряют диаграмму и делают модель трудной для чтения и поддержки.
Вклад NVAR При анализе NVAR (количество переменных) на графике проявилась интересная закономерность:
Модели, отнесенные к высокой сложности, в основном группировались вдоль кривой в области пересечения NVAR и NOAJS. Как только хотя бы одна из этих метрик приближалась к своему максимуму — модель почти всегда попадала в категорию высокой сложности. Эта закономерность одинаково хорошо прослеживалась как для BPMN, так и для CMMN-моделей, где в метрики сложности входила взвешенная сумма всех элементов моделирования.
5. Роль NRC в сложности модели
NRC (количество вызываемых подпроцессов) играет важную роль как в BPMN, так и в CMMN. Сложные модели обычно содержат множество компонентов или вызывают большое количество подпроцессов и подкейсов.
Однако NRC — не единственный определяющий фактор. Плохо спроектированные модели могут свести все в один огромный процесс без единого вызова подпроцесса. В итоге NRC будет низким, а сложность все равно останется высокой.
Стоит ли учитывать NRP?
NRP (сколько раз модель используется другими процессами) вызвал интересный вопрос. Изначально эту метрику не включали в кластеризацию. Однако в BPMN-моделях некоторые процессы выглядели критически важными на уровне всего приложения, но при этом попадали в категорию низкой или средней сложности. Предположение было простым: действительно важные процессы обычно переиспользуются множеством других процессов или кейсов. С точки зрения поиска кандидатов на рефакторинг включение NRP может быть спорным, но для выявления критически важных моделей добавление этой метрики дало весьма полезные результаты.
При применении к CMMN-моделям метрика NRP, однако, ломала кластеризацию. Это было ожидаемо: CMMN-кейсы часто выступают центральным оркестратором и сами вызывают подпроцессы. В нашем датасете значения NRP почти всегда были низкими (с редкими исключениями), что приводило к высокой энтропии кластеров. В итоге NRP разумно исключили из кластеризации CMMN.
Этот анализ показал ограниченность чисто стандартных метрик. Классические исследования обычно рассматривают отдельные BPMN- или CMMN-модели, а реальные единицы развертывания (как в Flowable) намного сложнее. В них входят кейсы, процессы, формы, DMN и другие компоненты. Добавление метрик NRP (сколько раз модель используется другими процессами), NRC (количество вызываемых подпроцессов) и NVAR (количество переменных) позволило создать гораздо более полную систему оценки реальной сложности.
Исследование начиналось с простого вопроса «насколько сложны наши процессы?» и в итоге дало надежный фреймворк для категоризации и понимания самых разных моделей.
В финальной части серии мы разберем, как Анализатор сложности может вырасти из диагностического инструмента в настоящий катализатор более умного, совместного и дата-ориентированного проектирования процессов.
BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.