Здесь на форуме VladZharinov представил незнакомый мне ранее язык Amber для описания бизнес-процессов (здесь, гл.8). Также есть ещё публикации:

— здесь материалы от авторов языка;
— здесь небольшой учебник;
— здесь кроме Amber есть пару слов и о NEML — близкий к нему язык (также в документе встречаются и др. технологии);
— здесь ещё один пример интеграции Amber c Promela для верификации моделей и пр.

Есть в инете и ещё материалы. Я выкладываю здесь идею, как можно по мотивам Amber и используя ряд принципов из ДРАКОНа описать попроще (надеюсь) выполнение действий, с учётом их возможного совместного протекания. Возможно, кто-то увидит для себя что-то полезное из тех, кому необходимо подрисовывать всякие процессики и нет приколачивания гвоздями к стандартам UML, IDEF... и пр. Кстати, здесь можно познать небольшое сравнение "ынтырпрайза".

Язык, на мой непрофессиональный взгляд, представляет собой переработанные диаграммы активностей UML (скорее всего, и ещё что-то повлияло, я не спец). Выглядит так:



Это простейшая схема с циклом. Здесь посерьёзнее:



Короче говоря, в Amber всякого хватает. Ключевой момент — это использование блоков разветвления и слияния процессов, на манер типовых перекрёстков как в IDEF3 и ряда других языков для workflow, или признаков переходов/соединения в YAWL. Но здесь есть вполне адекватное упрощение: вместо трёх типов — AND, OR, XOR — которые взрывают моск у обычных ни в чём неповинных людей, используется только два вида — AND и OR. Имхо, их должно хватать, XOR можно выразить косвенно, к тому же их и проще зарисовать.

В общем, в языке описания процессов предлагается следующее:

— "кружочки" — действия, операции и пр., т.е. аналог квадратиков из ДРАКОНа и блок-схем;

— "растянутые кружочки" — те же действия, но "растянуты" из-за надписи внутри, похожи на заголовки в ДРАКОНе;

— "полукружочки" или "разорванные кружочки" — могут указывать на действия участников процесса как логическая связь между ними, можно выразить цикл "ДЛЯ", реализовать аналог "выбора" и "варианта" — "переключатель" в ДРАКОНе;

— "кружочки с картинкой" и пр. символами + надпись — в качестве альтернативы для таких композитных икон вида:



Такие иконы наглядны, но требуют больше места, в т.ч. и вокруг себя. Хотя вполне тоже можно использовать сложные иконы;

— "линии" — дуги графа как в ДРАКОНе, с небольшим исключением (см. ниже). Как и в ДРАКОНе, в отличие от Amber, UML и пр., лучше не использовать надписи на линиях кроме вида "да/нет";

— "закрашенный квадратик" — соединитель "И": процесс продолжится, когда все запущенные входные действия будут завершены;

— "пустой квадратик" — соединитель "ИЛИ": процесс продолжится, когда хотя бы одно из входных действий будет завершено;

— "закрашенный ромбик" — разветвитель "И": все выходные действия выполняются;

— "пустой ромбик" — разветвитель "ИЛИ": запускается хотя бы одно из выходных действий;

— "усеченный ромб" с надписью — аналог "вопроса" из ДРАКОНа, это частный случай "пустого ромбика", когда условие вписано в сам разветвитель. Вполне возможно, что лучше не использовать этот "вопрос", чтобы схемы были в одном стиле. Если необходимо иметь рядом много вопросов, то можно использовать "переключатель", который располагается и горизонтально и можно вывернуть его и вертикально.

Для "кружочка" возможен только один выход на другое действие или как петля цикла, но необходим отдельный выход на каждый требуемый соединитель. В этом случае, фактически, не избежать пересечений линий, и лучше разрешить пересечение (на входах соединителей). Необходимы отдельные выходы и для разветвителей. Лучше также разрешить и наклонные линии для разветвителей/соединителей;

— из ДРАКОНа используются ветки (шампура) и силуэт. Например, здесь есть несколько сравнений диаграмм в различной нотации с аналогичными ДРАКОН-схемами, можно заметить, что попытка упорядочить/разделить элементы схемы даёт эффект.

Короче говоря, схематично язык выглядит так (сорри за ручную мазню, но так проще и быстрее):



Возможна горизонтальная направленность:



Можем использовать акторов/сущностей модели как-то так:



Кружочки, полукружочки, квадратики и ромбики — просты и хорошо различимы, ими можно вертеть в разные стороны. В каком-нибудь редакторе схем можно реализовать режим, когда "растянутые кружочки" сжимаются, т.е. убирается надпись, внутри можно оставить лишь идентификатор иконы, можно кратко подписать вершины, т.е. привести схему к компактному виду (как первый рисунок в этом эпосе). И как-то легче воспринимается рисунок, когда много кружочков чуть разбавлены квадратиками и ромбиками, чем когда имеем много маленьких квадратиков (как действия) и кружочки-переходы. Такие символы из Amber и ДРАКОНа можно использовать и для построения других диаграмм, как диаграмма последовательности и пр.
http://files.rsdn.ru/91237/diagram_actor.PNG
Имхо, получился модифицированный ДРАКОН, не же ли развитие Amber. Пока нет чётких формальных правил для обеспечения полноценности, непротиворечивости, работоспособности и т.д. И неизвестно пока, будут ли практические разработки для реальной работы.


По поводу способа рисования схем. Я лично не нашёл удобного и практичного инструмента. Типовые графические редакторы годятся для использования сотрудниками всяких отделов маркетинга, которые только и занимаются рисованием креативных диаграмм (организовывают важные совещания, где долго решают, каким же цветом рисовать свои квадратики, а через полгода делают "прорыв": те же квадратики теперь рисуют новым гламурным цветом).

Здесь на форуме VladZharinov давал ссылку на "Ракетный дизайнер кода" (ролик). Да, это самый эффективный способ, особенно если это адекватный плагин для уже используемой IDE (редактора). Текстовый язык позволяет как-то всё увязать: основной программный код (в моём случае кружочки с линиями не превращаются в программу на Обероне и не "прошиваются" в контроллер, всё размазывается на кучу софта — базы данных, серверный и клиентский код и пр.), систему контроля версий, сборки, баг-трекинг, вики и т.д. К тому же "программирование" полезно, если задействована реальная технология, т.е. схемы не с потолка рисуют с произвольным текстом про рыбалку, а манипулируют объектами из какого-нибудь "флокса".
Но есть проблема с форматом этого языка. Структурные описания как XML, json, s-выражения и пр. проблематичны для ручной правки, особенно при многих уровнях вложения. Программный псевдо-язык или DSL на основе ключевых слов "если", "цикл", "конец" и т.д. (или англ. слова) трудновато воспринимается, особенно когда необходимо быстро сопоставить видимый текст на экране с рисуемым рядом куском схемы.

Есть мысли использовать текстовый DSL как линейный список команд для манипулирования объектами диаграммы, некий "ассемблер" для схем, что-то по мотивам:

д   Запуск проц. 23 \ Запускаем процедуру 23
ври 12.4

Здесь две команды:

— первая: "д" — действие, т.е. добавляем кружок для текущей позиции, до "\" — текст действия, после — комментарий (хинт) кружочка;
— вторая: "ври" — вставить разветвитель "И" в позицию "12.4".

Тогда можем работать глядя на схему, для ввода текста достаточно небольшого окошка консоли. Схема сохраняется как прямой список команд для её построения (т.е. не так как мы вводим в процессе работы). Здесь автокомплит и всякие сниппеты помогут.

К тому же подобный язык поможет реализовать что-то вроде вимператора для графического редактора, для тех же доступных ДРАКОН-редакторов, например. Кто не в курсе: вимператор — это плагин для FireFox, который реализует управление броузером как в виме (можно демки глянуть, есть его форк, популярен и эмакс для FireFox). Такое расширение даст и удобную быструю работу через клавиатуру, и быстрый выбор/выделение объектов в схеме и выполнение операций над ними через так называемый "following links", быстрый ввод команд через комстроку с автокомплитом и пр. плюшками и т.д. В общем, это отдельная тема.


Вот такая беда с "ДРАКОНо-строением".