Comments 8
Есть понятие BPM, т.е. наука по процессам. Может быть «событийная семантика» = «событийная онтология» = BPM?
Под «изменением» понимается как создание нового индивида
Может «изменение» - это просто результат процесса или сам процесс?
Так покраска забора может быть описана и как действие, состоящее из множества актов: «подготовил кисть», «смешал краску», «нанес первый слой», «нанес второй слой».
Может это просто нарезка процесса на подпроцессы? Это хорошо визуализируется VAD диаграммой как сквозной процесс.
На примере ЕРС (ARIS), т.е. самой что не наесть "событийной" нотации. Есть функция (процедура), ее выполняет исполнитель (как тут называют актор), для выполнения процедуры требуются инструменты. Есть входы (заготовки) и выходы (продукты).
Это рисуется, а связи так и называют: Исполнитель > связь типа «исполняет» > функция №1.
Подробнее типы связей см. Требования к использованию типов соединений (стр. 85)
https://cssrzd.ru/news/BusinesProcess_RZD.pdf
Есть связи для входных документов (заготовок) в функцию, и выходных (продукт функции).
Жизненный цикл документов описывается через их стадии (docflow): шаблон заявления – переход – заявление «согласовано» - переход - заявление «утверждено» и т.д.
Однако, если обратить внимание на содержание происходящего - действие принятия решения, – то для его моделирования целесообразнее, конечно же, использовать событийную семантику и вместо атрибута фиксировать один из актов: «утвердил» или «отклонил». В этом случае принятие решения будет записано с помощью одного утверждения «Иванов отклонил документ».
Это же и есть "просто" моделирование процессов. В терминах BPM это укладывается во многие нотации, начиная с ЕРС, и в них также присутствуют семантические связи, которые явно указаны прямо в редакторе типа ARIS.
Это все к тому, что может велосипед уже изобретен и он называется BPM (EPC, ARIS)? Там также все основано на семантике, только не пишутся триплеты в явном виде. Причем это не только для алгоритмов (workflow), но и для описания структур (иерархий), включая орг-структуру и связь с ролевой моделью (роль в процессе), и для описания иерархий ИТ-систем и продуктов.
Или в статье про что-то иное, совсем не на тему BPM?
Если все же на тему BPM, то почему не использовать понятийный аппарат BPM?
Или в статье про что-то иное, совсем не на тему BPM?
Да, этот текст совсем не на тему BMP, не про нотации. И поэтому он в разделе "семантика". Хотя на базе событийной семантики действительно можно сделать workflow-движок. Но он работает совсем иначе, чем все, что связано с BMP (см. https://www.osp.ru/os/2021/03/13055996).
Да, этот текст совсем не на тему BMP, не про нотации. И поэтому он в разделе "семантика".
Хотелось бы пояснить разницу «этого текста» и BPM на простом примере. Полагаю, что процессы, (алгоритмы, логика), события, действия (функции), исполнители (акторы) и артефакты (предметы, документы и т.п.) – они что в «этом тексте», что в BPM имеют одни и те же понятия, впрочем, как и связи (семантические связи) между ними. Или «событие» - тут это что-то иное?
Для примера возьмем простенькую схемку процесса в EPC, что есть базовая нотация ARIS, который в свою очередь классический пример классического BPM (это тот, который неисполняемый):
В ней (EPC) полагаю, что присутствуют: событийные семантики, Базовые семантические примитивы в событийной онтологии, семантически определенные отношения, базовые семантические примитивы и т.п.
Ровно также в BPM «В событийной семантике деятельность описывается последовательностью актов» или нет?
По аналогии с:
:john :hasMother :helga— У Джона есть мама и её зовут Хельга.
:john :hasFather :henrich— а отца Джона зовут Генрих
https://habr.com/ru/post/17946/
Составляем EPC-триплеты:
Workflow – триплеты (черные стрелки):
:Функция 1 :hasParent :Событие 1.
:Функция 2 :hasParent :Функция 1.
...
Триплеты, детализирующие объект «Функция», например, Функцию 1:
:Роль 1 :Исполняет функцию :Функция 1.
:Функция 1 :Имеет результат :Артефакт 1.
…
Если в EPC все объекты представить в виде кружка (вершина графа), то получится «настоящий» (привычный) семантический граф, т.е. фактически в нотациях BPM для каждого типа объекта указан свой графический примитив, типа:
:Функция 1 :есть объект типа :Функция.
:Функция :имеет примитив :Скругленный зеленый прямоугольник.
Т.е. это такой же граф связей (Linked Data и т.п.). Изначально (начало 90-х, ARIS\EPC) именно этот подход вроде как был заложен в классический BPM.
Вопрос: в чем отличие приведённого «триплетного BPM \ EPC» от событийной семантики и как приведенный алгоритм (цветная картинка) в нотации EPC будет представлен событийной семантикой, EventFlow, DataFlow и прочей «Архитектурой на основе событийной семантики» (графически + триплетами)?
Понятно, что в представлении EventFlow \ DataFlow никакие объекты и связи не должны «выпасть» (по отношению к EPC), иначе не будет однозначно воспроизведен приведённый алгоритм.
Спасибо. Я прекрасно знаю, что такое BMP, и мне даже как-то неудобно, что вы потратили столько времени на изложение общеизвестного.
Или «событие» - тут это что-то иное?
Да, действительно, нечто другое. В событийной семантике нет ни процессов, ни артефактов, ни функций... а есть только (!) события. Все данные о предметной области записываются с помощью унифицировано событийного формата. На вашей ARIS-схемке за каждым прямоугольником стоит либо множество действий пользователя, либо исполняемый код, написанный программистом. То есть это именно схематичное описание процесса с помощью графических фигур. А теперь если вы посмотрите на картинку в шапке моей статьи, то увидите там рабочую модель действия "голосования", на которой каждый прямоугольник - это событие. Вот как это выглядит в псевдокоде:
Voting: Model: @Voting
@Voting: Attribute: Status
Status: Permission: Admin
Status: Default: Preparation # автоматически записывается событие по умолчанию
Status: Mutable: 1
@Voting: Attribute: Point, [Status=Preparation]
Point: Permission: Admin
Point: Cardinality: 0 # любое количество пунктов
Point: Act: Accepted, [Status=Start]
Accepted: Label: Yes # отображаемый текст
Accepted: Permission: Voter
Accepted: SetValue: $Actor # системная переменная "текущий актор"
Accepted: Cardinality: -1
Accepted: Mutable: 1
Point: Act: Rejected, [Status=Start]
Rejected: Label: No # отображаемый текст
Rejected: Permission: Voter
Rejected: SetValue: $Actor
Rejected: Cardinality: -1
Rejected: Mutable: 1
И в отличие от ARIS - это не схематическое описание процесса, а рабочий исполняемый код (не компилируемый в байт-код, а именно исполняемый Event Flow движком). То есть событийная семантика - это не про рисование картинок, а про создание исполняемых моделей бизнес процессов. При этом семантика не абстрактная типа :Функция :имеет примитив :Скругленный прямоугольник , а самая низкоуровневая, то есть описывающая индивиды сущностей, их свойства, совершаемые акты (как в примере Accepted, Rejected), согласно установленным словарям. Ну и принцип моделирования процессов благодаря использованию dataflow архитектуры исполнения алгоритмов принципиально отличается от того, что мы имеем в стандартных BMP-инструментах.
Понятно, что в представлении EventFlow \ DataFlow никакие объекты и связи не должны «выпасть» (по отношению к EPC), иначе не будет однозначно воспроизведен приведённый алгоритм.
Итак, никакие связи не только не выпадают, а все, что вы нарисуете (именно нарисуете) на EPC-диаграмме, в EventFlow движке можно декомпозировать до исполняемых событий и свойств артефактов и без программирования создать семантическую модель процесса и выполнить ее с генерацией экземпляров (данные о которых будут сохраняться в семантическом графе).
Движок сейчас в разработке (где-то альфа-версия): возможно исполнение любой бизнес логики, но пока в админском интерфейсе и с некоторыми плясками. К весне планируется бета, которую уже можно будет давать тестить.
Итак, никакие связи не только не выпадают, а все, что вы нарисуете (именно нарисуете) на EPC-диаграмме, в EventFlow движке можно декомпозировать до исполняемых событий и свойств артефактов и без программирования создать семантическую модель процесса
Так я и прошу просто "нарисовать" такую "семантическую модель процесса" (про отпуск). Собственно, мой вопрос остаётся прежним.
Кроме того, когда читаю "Событийная онтология vs объектная" создаётся впечатление, что речь идет об обычных BPM и EA (архитектура предприятия), которые "по определению" включают в себя как Событийную онтологию (архитектура процессов, динамика), так и объектную (структуры, включая орг-структуру и ролевую).
Ваша "событийная семантика" как то связана с S-BPM (в S-BPM не dataflow архитектура)? https://ekonomika.snauka.ru/2014/11/6316
А "шапшную" картинку лучше включать в состав статьи. Я про нее и не догадался:
Шапочная картинка не имеет прямого отношения к тексту, в котором обсуждается только особенности событийной семантики, а не ее реализация в конкретной архитектуре. Добавлена для красоты. И упомянул я ее только потому, что вы сменили тему - стали обсуждать нотации бизнес процессов.
Так я и прошу просто "нарисовать" такую "семантическую модель процесса" (про отпуск). Собственно, мой вопрос остаётся прежним.
Это как просить программиста "нарисовать" схему процесса на том или ином языке программирования. Или еще круче, просить нарисовать эту схему на RDF/OWL. Событийная семантика не про рисование схем, а про их реализацию в виде исполняемых событийных моделей. То есть вы приходите ко мне с EPC-диаграммой, а я в редакторе строю событийную семантическую модель, которую будут исполнять в интерфейсе сотрудники и босс (создание демо-модели займет минут десять - сейчас попробовал). В коде упрощенно будет как-то так :
Action: Instance: Заявка
Заявка: Model: @Заявка
@Заявка: Attribute: Status # допустимо ли для $Actor подать заявку
Status: Permission: Сотрудник
Status: SetValue: $Actor.ДатаОтпуска > $DateDay - 30 # осталось 30 дней до отпуска
Status: Mutable: 1
@Заявка: Attribute: ТекстЗаявки, [Status==True] # ввод текста заявки
ТекстЗаявки: Permission: Сотрудник
ТекстЗаявки: Cardinality: 1
ТекстЗаявки: Mutable: 1
@Заявка: Act: Accepted, [IS $ТекстЗаявки] # утвреждение, если есть текст
Accepted: Label: Yes # отображаемый текст
Accepted: Permission: Босс
Accepted: SetValue: $Actor # системная переменная "текущий актор"
Accepted: Cardinality: -1 # задает радио-конпку
Accepted: Mutable: 1
@Заявка: Act: Rejected, [IS $ТекстЗаявки]
Rejected: Label: No # отображаемый текст
Rejected: Permission: Босс
Rejected: SetValue: $Actor
Rejected: Cardinality: -1
Rejected: Mutable: 1
Если делать правильно, надо еще добавлять в модель сроки, условия и сохраненные данные экземпляра Заявки загружать в PDF-шаблон (если нет электронного документооборота).
Ваша "событийная семантика" как то связана с S-BPM (в S-BPM не dataflow архитектура)?
Cобытийная семантика, как и любая другая семантика про описание предметной области, про построение онтологии предметной области. Правда, событийная семантика отличается от существующих объектно-ориентированных семантик (типа RDF) тем, что она моделирует не только статичную структуру, но деятельность. Поэтому вы и перевели разговор на BMP. По поводу S-BPM я писал в первой статье, посвященной субъектно-событийному подходу https://habr.com/ru/post/256607/ (тогда еще не было ясного представления о семантике и архитектуре движка).
Action: Instance: Заявка
Насколько понял: нарисовать аналогичную (заявка на отпуск) шапшной картинки (голосование) - большая сложность. Я полагал, что в нотации "событийная семантика" (как на рисунке в шапке) схема алгоритма будет более понятной, чем RDF - граф.
Или еще круче, просить нарисовать эту схему на RDF
Вроде как есть инструменты автогенерации схемы (графа) по скрипту (RDF), типа:
https://www.ldf.fi/service/rdf-grapher
Часть скрипта мной же и показана. Конечно такой grapher нарисует мало похожее на "стройную" ЕРС, но все связи передаст в точности.
Кстати, есть ли LD-инструменты, которые могли бы "уложить" RDF в нечто похожее на ЕРС, т.е. поток workflow уложить вертикально, а окружение функции - горизонтально (хотя бы как кластер в dot)? Конечно, вместо "кругов - овалов" - использовать набор примитивов: шестиугольник для событий, скругленный прямоугольник для функций и т.п.
Меня пугает, что вместо BPM упорно упоминаете BMP. Мы точно говорим про Business Process Management?
В продолжение: "Сравнение субъектно-событийного подхода с существующими BPM системами" как "событийная семантика" vs BPM, подскажите, чем она лучше BPMN?
"субъектно-событийный подход" = "событийная семантика"?
Насколько понял: нарисовать аналогичную (заявка на отпуск) шапшной картинки (голосование) - большая сложность.
Ну что вы? )) В этом просто нет никакой необходимости. Обведите прямоугольниками модельные события (которые начинаются с имени модели @Завяка) и пририсуйте стрелки согласно ссылкам в Condition (в квадратных скобках). Надписи в прямоугольниках соответствуют значениям ограничивающих свойств (cardinality и пр). Я и не подумал рисовать, поскольку это тривиально. (Сравните шапочную картинку и псевдокод модели голосования - нарисовано именно то, что написано).
Вроде как есть инструменты автогенерации схемы (графа) по скрипту (RDF)
Да, конечно, в готовом продукте будет возможность и представления кода в виде диаграммы событий, и обратная функция - генерация кода по рисуемой диаграмме. Это тривиальная задача, поскольку тут у нас однозначное соответствие кода и диаграммы, которые просто являются разными формами представления направленного ациклического графа.
Меня пугает, что вместо BPM упорно упоминаете BMP
Извините. Не всегда внимателен. Опечатки)
"субъектно-событийный подход" = "событийная семантика"?
Первое - общий подход к моделированию сложных систем, второе - конкретная спецификация семантики, на базе которой реализуется подход.
Акты, классы и семантический сахар