Идея визуального программирования «для секретарш» вызывает сомнения. Блок-схема любого алгоритма «из жизни» — почти всегда громоздкая и неуправляемая конструкция. Любой структурный язык программирования или псевдокод справляется с задачей записи логики гораздо эффективнее и лаконичнее.

Применение теории графов или другой математики для формальной «оптимизации» схемы приведет, скорее всего, к нелогичной пространственной и хронологической близости элементов. Да и вручную подобные паутинообразные схемы редко можно привести в читабельный вид.

Как я понял, процесс на вашей схеме описан как последовательность состояний. Названия функций — условий переходов (eventDrivenActivity) не несут никакой смысловой нагрузки, поэтому я предлагаю их исключить из рассмотрения.

Линейная последовательность промежуточных состояний может быть естественно представлена в виде списка:

Такой список однозначно читается сверху вниз и не требует дополнительной визуализации переходов. Поскольку рабочие процессы состоят, как правило, из нескольких цепочек последовательных состояний, такая запись существенно сэкономит «чернила».

Разветвления переходов отображаются явно:

Переходы вверх по цепочке можно интерпретировать как отдаление от конечной цели и показывать с другой стороны:

Разделение «нисходящих» и «восходящих» переходов облегчит чтение схемы. Разумеется, все «восходящие» переходы отображаются всегда явно стрелками.

В процессе могут быть исключительные состояния, в которые он сбрасывается из любого другого состояния при наступлении определенных условий. В исходном примере это состояние Rejection. Чтобы сэкономить на паутине, свяжем состояния цветом:

Так можно записать процесс, показанный на исходной картинке:

Обратите внимание на пометку END у конечных состояний.

Втяжками обозначены подчиненные альтернативные состояния, в которые процесс переходит только из «родительских» состояний.

Если бы в нашем процессе существовали «обратные» переходы, схема выглядела бы так:

Это только черновик, предлагаю советчикам подумать над форматом. Например, если сверху стоит состояние- исключение, первоначальное состояние становится плохо видно. Кроме того, при отсутствии стрелок появляются неоднозначности: например, существует ли переход из состояния Bank decline request в состояние Bank approve request?

Комментарии

Артем, полностью поддерживаю ваш подход, администратору будет гораздо привычнее и удобнее конфигурировать систему подобным образом.

Подозреваю, что eventDrivenActivity имеют большое значение в системе, чтобы упускать их из виду. Вероятно, это триггеры, условные переходы, которые редактируются в других окнах. Поэтому их тоже стоит включить в синтаксис конфигуратора.

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

Синтаксис можно позаимствовать из широко известных языков программирования: C, Java, JavaScript, PHP. Описание процедур в этих языках простое и легко читается с первых минут знакомства.

Например:
PreparingQuestionnaireData // Комментарии в конфигурационном файле
{
if Questionnaire is empty call Rejection
call WaitingForBackward
}

WaitingForBackward
{
if Connection is empty call End
if ProgrammMatch is empty call End
call Sorting
}

и т. д.

Злую шутку сыграл с нами прогресс. Найти программиста, который может сделать визульные блоки, которые можно связывать и редактировать, теперь гораздо проще, чем того, кто сможет написать синтаксический анализатор.

Максим!

Как я понял, процедурный подход больше подходит для описания процесса в терминах sequential workflow (см. статью Дейва Грина).

Триггеры eventDrivenActivity можно показать и редактировать в соседней панели при выборе состояния на схеме, например, мышкой. Вся информация, кроме ненужного названия триггера, на схеме уже присутствует

Процедурный подход

Последние три недели я мучаю IBM WebSphere ProcessServer. Монстровая софтина используется для управления бизнес-процессами и задачами.

Создатели сервера предлагают разработчикам BusinessProcessExplorer. Этот «эксплорер» обладает наикривейшим AJAX-интерфейсом. Еще он гененрирует SVG-картинку по метаданным процесса (ProcessTemplate) или задачи (HumanTask). Картинка масштабируется прямо в браузере, причем мучительно долго, т. к. она огромная, при наведении на различные элементы диаграммы всплывают подсказки. Читать xml-файл намного удобнее, чем разглядывать «автогенерированного» монстра.

Посмотрите на картинку, Эдуард, у вас не все так плохо.

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

Диаграмма на 10-15 пакетов с 60-70 классами (на самом деле, небольшой проектик-то) похожа на взорванного паука, который лопнул и запачкал весь экран паутиной и прямоугольниками с буковками размером в 2,05 пункта (я утрирую). Кроме того, вышеозвученная тулза пытается влепить в диаграмму схему из «java.*», что в вышей мере выглядит странно.

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

По формату схемы:
«EventDrivenActivity» выкидывать нельзя, их называть по-человечески нужно. Если их добавить к предложенной вами, Артем, схеме, то она превратится в столбик слов, опутанный красными и серыми стрелочками.

«Блок-схема любого алгоритма «из жизни» — почти всегда громоздкая и неуправляемая конструкция. Любой структурный язык программирования или псевдокод справляется с задачей записи логики гораздо эффективнее и лаконичнее». Ага, это как облако тегов, вроде и «прикольно», и «модно», а применимо в очень редких ситуациях. Рисование схем — не универсальный подход.

Выделить стартовый блок можно точно также, как и конечный — текстовой меткой, только не END, а START.

А на линиях переходов явно не хватает условий, при которых эти переходы выполняются. Чтобы на занимать место, можно разместить на линиях символы, а сами условия выводить при наведении курсора. Можно и ссылку на документацию туда же добавить.

Условия сброса можно обозначить аналогичным образом.

Спасибо большое, Артем — ваш совет оказался очень ценным и предложенные решения представились мне достаточно прочной основой для старта. Также хочу заметить, что вы правильно рассудили насчет незначительности EventDrivenActivity в моем вопросе, просто схема представлена из редактора workflow, встроенного в microsoft visual studio, и описания этих активностей обязательно, а скрыть их не представлялось возможным.

Так же спасибо Солоницыну Юрию за совет с tooltip'ами.

Итак, демонстрирую взорванного паука UML-диаграммы. Это «зареверсенный» проект (reverse engineering) из примеров для NetBeans.

Было б неплохо придумать более-менее универсальную форму представления диаграмм, которые бы при этом читались. Да, нужно, чтобы диаграмма обладала хорошей интерактивностью.

Хочу отметить, что прямоугольники классов (грязно-желтый градиент) и пакетов (грязно-зеленый) не сворачиваются, т. е. если вам неинтересны в данный момент поля класса, его методы, или все классы пакета, вам не удастся их свернуть, оставив, например, только название класса. Есть вариант убрать весь пакет с классами или отдельный класс. При этом целостность диаграммы нарушается — отдельные классы, пакеты с классами просто исчезают с диаграммы.

Ну и кому тогда нужна такая диаграмма, если на ней пропадает пакет с парой подпакетов и десятком-другим классов?