В предыдущей статье «Событийная онтология vs объектная» были введены основные положения событийной семантики, описаны ее отличия от объектно-ориентированных подходов к моделированию предметной области. В данном тексте на конкретных примерах демонстрируются особенности событийного описания по сравнению с субстанциональным и релятивным. Вводится новое понятие «семантический сахар» и переосмысливается роль иерархических отношений свойств. 

Акты

Базовым семантическим примитивом в событийной онтологии является акт, который определяется как изменение индивида, совершаемое актором и фиксируемое в онтологии в виде единичного элементарного события. Под «изменением» понимается как создание нового индивида («отлил деталь», «создал документ»), так и изменение  свойств существующего («покрасил забор», «поступил в ВУЗ», «одобрил решение»). Констатация элементарности акта, то есть фиксация его как единичного события, не  исключает того, что в другом контексте этот же акт может быть представлен как сложное действие, то есть в виде последовательности событий, приводящей к определенному результату. Так покраска забора может быть описана и как действие, состоящее из множества актов: «подготовил кисть», «смешал краску», «нанес первый слой», «нанес второй слой».

Для фиксации акта необходимо указать: (1) индивид, с которым совершается акт, (2) тип акта, задаваемый глаголом совершенного вида в прошедшем времени (создал, одобрил, смешал), (3) актор. Хотя следует отметить, что не всегда целесообразно, да и не всегда возможно фиксировать актора, в результате действия которого у индивида появилось или изменилось значение свойства. Если в таких актах, как «одобрил», «поступил» принципиально важно, кто именно их совершил, то во многих других ситуациях либо упоминание актора не существенно (как, например, в случае с покраской забора), либо актора как такового вообще не было (например, при фиксации цвета травы). Поэтому в событийной онтологии не все события являются актами, многие события просто фиксируют наличие у индивида значения свойства («трава зеленого цвета»).  

Акт, класс, отношение

Событийная семантика создается как альтернативная объектно-ориентрованной семантике, представленной в двух вариантах (часто смешиваемых): (1) субстанциональная, базирующаяся на представлении о существовании обособленных вещей и их свойств и опирающаяся на формализм иерархии классов, и (2) реляционная, исходящая из примата отношений.  Рассмотрим отличия семантик на примере действия «обучение Иванова в МГУ». 

При субстанциональном подходе факт обучения Иванова фиксируется включением его в класс «студенты МГУ». По окончании обучения Иванов исключается из этого класса. Здесь следует отметить, что отнесение к какому-либо классу  само по себе не несет никакой семантической нагрузки - смысловая составляющая содержится только в названии класса. Реляционное описание имеет дело не с классами и их элементами, а с индивидами, устанавливая между ними семантически определенные отношения, в нашем примере - «Вася является студентом МГУ».  Фиксация отношения между индивидами намного содержательнее, чем отнесение к классу, особенно с учетом того, что отношение («является студентом») может иметь как область определения, так и область значений («человек» и «учебное заведение» соответственно). Для фиксации времени начала и окончания учебы в субстанциональном и реляционном описаниях необходимы дополнительные записи.

В событийной семантике деятельность описывается последовательностью актов, в нашем примере: «Иванов принят в МГУ» и «Иванов отчислен/выпущен МГУ». Очевидно, что фиксация пары актов, ограничивающих во времени деятельность «учеба в МГУ»,  смыслово содержательнее, чем лишь указание типа отношения «является студентом» и уж подавно, чем отнесение к классу (поименованному множеству). К тому же,  использование специализирующих вариантов актов – «отчислен» и «выпущен» – позволяет сделать исчерпывающее по содержанию описание причины завершения действия, не увеличивая количество утверждений. При этом понятно, что каждый из перечисленных актов однозначно предопределяет установление или снятие отношения «является студентом», чего нельзя сделать в обратном порядке: завершение отношения ничего не говорит об акте, в результате которого это произошло («отчислен» или «выпущен»). Ну и конечно, при необходимости сделать утверждение обо всех студентах МГУ легко создать множество/группу из индивидов, участвующих в акте «принят в МГУ» и еще не имеющих записи об актах «отчислен/выпущен». 

Проиллюстрируем преимущества описания через акты еще на одном примере – отношении «Петров имеет в собственности машину». В событийной онтологии вместо этого отношения следует зафиксировать один из актов: «купил», «принял в дар», «получил по наследству» и т.п. Прекращение отношения собственности также должно быть зафиксировано одним из актов: «разбил», «подарил»,  «продал» и т.п. При этом понятно, что тип отношения всегда логически следует из акта: акт «принял в дар» однозначно устанавливает отношение «имеет в собственности». Обратное не всегда очевидно: из указания отношения в редких случаях возможно выявить тип акта, который послужил причиной начала или разрыва этого отношения (учиться в МГУ можно и после перевода, а не только при поступлении).

Здесь же следует отметить, что для инициации индивидов «Иванов» и «МГУ» в событийной онтологии не требуется относить их к каким-либо классам. Иванов является человеком, а МГУ –  высшим учебным заведением исключительно благодаря актам: «мама-Иванова родила Иванова-сына», «Министерство образования зарегистрировало МГУ». И эти акты являются обуславливающими для появления новых индивидов сущностей: Иванова – индивида сущности «человек» и  МГУ – индивида сущности «ВУЗ» (тип сущности задается моделями действий «рождение» и «регистрация»).  При этом надо подчеркнуть, что сущность в событийной семантике не является классом: создание индивида сущности нельзя трактовать, как включение его в некоторое множество, речь идет только об отнесении его к некоторому типу объектов.

Акты и атрибуты

Показательно также и соотношение актов и атрибутов, то есть свойств, значения которых фиксируются на самом индивиде безотносительно других индивидов (в отличие от отношений).  Допустим, необходимо зафиксировать факт принятия или отклонения Ивановым некоторого документа. Простейший вариант, который реализуется в объектно-ориентированном подходе – это ввести атрибут «решение» с двумя фиксированными строковыми значениями «утвержден» и «отклонен» и присвоить одно из значений документу. Но кроме этого, надо еще добавить запись, что присвоил это значение именно Иванов. Однако, если обратить внимание на содержание происходящего - действие принятия  решения, – то для его моделирования целесообразнее, конечно же, использовать событийную семантику и вместо атрибута фиксировать один из актов: «утвердил» или «отклонил». В этом случае принятие решения будет записано с помощью одного утверждения «Иванов отклонил документ».

Семантический сахар

Как показали примеры, событийное описание предметной области предлагает совсем другой взгляд на природу и семантическую роль отношений между индивидами. Если в качестве базового семантического примитива принят акт, то отношения могут рассматриваться лишь как лингвистические уточнения, контекстные поименования ролей или функций, которые эти индивиды приобретают в результате выполнения актов. К примеру, если в некоторой пространственной области А выделена область В (акт «выделена»), то из этого однозначно следует, что В и А находятся в отношении «часть – целое». Если кубик С помещен в коробку D (акт «помещен»), то между кубиком и коробкой установится отношение «находится в». По сути, можно сказать, что в событийной онтологии отношения должны трактоваться как «семантический сахар» (по аналогии с синтаксическим сахаром в программировании), то есть как нечто, расширяющее вариативность языка, необходимое лишь для удобства общения, не обладающее самостоятельным содержанием. То есть можно утверждать, что для исчерпывающего описание деятельности достаточно только фиксации актов, а любое отношение есть лишь поименование индивида или его состояния, порождаемое и отменяемое актами.

Например, акт «Маша родила Сашу» автоматически порождает отношения между его участниками: «Маша мама Саши» и «Саша сын Маши». Если же принять во внимание предшествующие три акта «Даша родила Машу», "Даша родила Гришу» и «Паша женился на Маше», то акт рождения Саши инициирует появление целого букета отношений: «Паша папа Саши», «Саша внук Даши», «Саша племянник Гриши» и т.п. Все эти отношения («мама», «сын», «папа», «внук», «племянник») следует считать семантическим сахаром, поскольку они не вносят дополнительного содержания, а только упрощают общение посредством добавления новых поименований. То есть весь этот семантический сахар нужен для того, чтобы можно было просто поинтересоваться «есть ли у Гриши племянник?», а не строить вопрос типа «есть ли у Гриши «индивид мужского пола, которого родила Маша, которую, как и Гришу, родила Даша?».

Введение представления о «семантическом сахаре» важно, прежде всего, для понимания принципиального отличия событийной семантики от реляционной. Ведь именно акты порождают отношения, а не наоборот: ведь из наличия отношения «Гриша дядя Саши» не следует обязательность наличия акта «Маша родила Сашу», поскольку Саша вполне может быть приемным сыном. Выделение семантического сахара также акцентирует внимание на бессмысленности установления иерархического соподчинения между производными от акта отношениями, такими как «родитель → мама» или «бабушка → внук», поскольку эти отношения порождаются одним актом и имеют только лексическое значение, не обладая каким-либо онтологическим содержанием.

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

Акты и иерархия свойств

Событийная семантика предлагает отказаться и от иерархии свойств. Вообще не так часто можно столкнуться с ситуацией, когда одно свойство требуется представить как родительское по отношению к другим свойствам. Иногда для свойств «домашний адрес» и «рабочий адрес» предлагают вести в качестве родительского специальное свойство «адрес». Здесь прежде всего следует обратить внимание на отсутствие в данной ситуации особого акта, который мог бы зафиксировать свойство «адрес». Мы имеем дело только с двумя актами: «Иванов поселился по адресу А1» и «Иванов принят на работу по адресу А2». Более того, саму попытку ввести свойство «адрес» как родительское для конкретных адресов (с названием улиц и номеров домов) необходимо расценить как концептуальную ошибку, поскольку у родительского свойства «адрес» либо вообще нет никакого значения, либо в качестве этого значения предлагается признать множество адресов (А1 и А2), что недопустимо, поскольку родительское и дочерние свойства должны иметь одинаковый тип данных. Хотя, конечно, понятно, откуда появилась сама идея ввода специального родительского свойства для нескольких адресов – надо же как-то поименовывать этот список в анкетах. Вот и получается, что здесь мы имеем дело не со свойствами человека, а со свойством анкеты, значением которого является список адресов. То есть в данном случае нет никакой иерархии свойств, а мы имеем дело только с поименованным списком. Также, к примеру, у человека невозможно выделить и такое свойство, как «физические параметры», которое можно было бы представить как родительское для свойств «рост», «вес», «охват груди» и т.п. И в этом случае мы имеем дело не с иерархией свойств, а с поименованным их списком.

Интересен также пример установления иерархических отношений между свойством «клиент» и свойствами «пациент», «покупатель», «студент» и т.п. В объектно-ориентированной онтологии вполне естественным выглядит представление свойств из приведенного списка как дочерних относительно свойства «клиент». Но с позиции событийной семантики мы опять же должны задать вопрос: а возможно ли рассматривать пары отношений «клиент» и «пациент», «клиент» и «покупатель», «клиент» и «студент» как пары разных свойства? По сути, здесь мы имеем дело с одним актом «стал пользоваться услугами организации» (больницы, магазина, ВУЗа), который автоматически порождает между человеком и организацией отношение «клиент», и это отношение в разных контекстах (для разных организаций) имеет специализированные поименования: «пациент», «покупатель», «студент». То есть мы опять приходим к выводу, что для описания деятельности достаточно фиксации актов, реализуемых участниками этой деятельности, а порождаемые при этом особенные отношения акторов и объектов, а по сути, их поименования, следует трактовать как семантический сахар, который необходим на уровне языкового описания, классификации, поиска.

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

Инвариант и варианты актов

Но не только свойства, но и акты, к примеру, такие, как «купил», «получил в дар», «унаследовал», можно рассматривать как производные (дочерние) относительно акта «получил в собственность». Однако при ближайшем рассмотрении между предположительно «родительским» и «дочерними» актами трудно выявить отношение иерархического соподчинения – их семантика, по сути, неразличима, все они устанавливают одно отношение – отношение собственности. Следовательно, и в данном случае корректнее говорить не о наличии разных актов, а о том, что акты «купил», «получил в дар», «унаследовал» являются вариантами одного акта «получил в собственность», который в данном случае можно рассматривать как инвариант. Использование того или иного варианта акта зависит от действия, в котором он реализуется: «покупка», «дарение», «наследование». Формально это может выглядеть как использование в моделях действий одного и того же акта «получил в собственность» с указанием соответствующего действию имени «купил», «получил в дар», «унаследовал». По сути, мы просто фиксируем, как должен в разных действиях называться акт, инициирующий отношение собственности.

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

*

Итак, при построении онтологии предметной области предельно важно сформулировать требования: (1) стоит ли задача моделирования деятельности или (2) необходимо составить тезаурус и установить отношения между терминами. Построение классификаций понятий и установление иерархических отношений между свойствами – это про слова, а точнее, про поиск по словам и аналитику. Для описания деятельности достаточно фиксации актов: актов создания и изменения индивидов, то есть событий, обуславливающих совершение последующих актов. При необходимости реализации поиска по онтологии можно либо по актам создавать слой (или слои) отношений и классификаций, либо на лету трансформировать запросы, содержащие имена отношений, в запросы к актам.   

Комментарии (8)


  1. itGuevara
    27.12.2022 23:37

    Есть понятие BPM, т.е. наука по процессам. Может быть «событийная семантика» = «событийная онтология» = BPM?

    Под «изменением» понимается как создание нового индивида 

    Может «изменение» - это просто результат процесса или сам процесс?

    Так покраска забора может быть описана и как действие, состоящее из множества актов: «подготовил кисть», «смешал краску», «нанес первый слой», «нанес второй слой».

    Может это просто нарезка процесса на подпроцессы? Это хорошо визуализируется VAD диаграммой как сквозной процесс.

    На примере ЕРС (ARIS), т.е. самой что не наесть "событийной" нотации. Есть функция (процедура), ее выполняет исполнитель (как тут называют актор), для выполнения процедуры требуются инструменты. Есть входы (заготовки) и выходы (продукты).

    Это рисуется, а связи так и называют: Исполнитель > связь типа «исполняет» > функция №1.

    Подробнее типы связей см. Требования к использованию типов соединений (стр. 85)

    https://cssrzd.ru/news/BusinesProcess_RZD.pdf

    Есть связи для входных документов (заготовок) в функцию, и выходных (продукт функции).

    Жизненный цикл документов описывается через их стадии (docflow): шаблон заявления – переход – заявление «согласовано» - переход - заявление «утверждено» и т.д.

    Однако, если обратить внимание на содержание происходящего - действие принятия  решения, – то для его моделирования целесообразнее, конечно же, использовать событийную семантику и вместо атрибута фиксировать один из актов: «утвердил» или «отклонил». В этом случае принятие решения будет записано с помощью одного утверждения «Иванов отклонил документ».

    Это же и есть "просто" моделирование процессов. В терминах BPM это укладывается во многие нотации, начиная с ЕРС, и в них также присутствуют семантические связи, которые явно указаны прямо в редакторе типа ARIS.

    Это все к тому, что может велосипед уже изобретен и он называется BPM (EPC, ARIS)? Там также все основано на семантике, только не пишутся триплеты в явном виде. Причем это не только для алгоритмов (workflow), но и для описания структур (иерархий), включая орг-структуру и связь с ролевой моделью (роль в процессе), и для описания иерархий ИТ-систем и продуктов.

    Или в статье про что-то иное, совсем не на тему BPM?

    Если все же на тему BPM, то почему не использовать понятийный аппарат BPM?


    1. boldachev Автор
      28.12.2022 00:22

      Или в статье про что-то иное, совсем не на тему BPM?

      Да, этот текст совсем не на тему BMP, не про нотации. И поэтому он в разделе "семантика". Хотя на базе событийной семантики действительно можно сделать workflow-движок. Но он работает совсем иначе, чем все, что связано с BMP (см. https://www.osp.ru/os/2021/03/13055996).


      1. itGuevara
        28.12.2022 10:43

        Да, этот текст совсем не на тему 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), иначе не будет однозначно воспроизведен приведённый алгоритм.


        1. boldachev Автор
          28.12.2022 11:57

          Спасибо. Я прекрасно знаю, что такое 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 движке можно декомпозировать до исполняемых событий и свойств артефактов и без программирования создать семантическую модель процесса и выполнить ее с генерацией экземпляров (данные о которых будут сохраняться в семантическом графе).

          Движок сейчас в разработке (где-то альфа-версия): возможно исполнение любой бизнес логики, но пока в админском интерфейсе и с некоторыми плясками. К весне планируется бета, которую уже можно будет давать тестить.


          1. itGuevara
            28.12.2022 12:58

            Итак, никакие связи не только не выпадают, а все, что вы нарисуете (именно нарисуете) на EPC-диаграмме, в EventFlow движке можно декомпозировать до исполняемых событий и свойств артефактов и без программирования создать семантическую модель процесса 

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

            Кроме того, когда читаю "Событийная онтология vs объектная" создаётся впечатление, что речь идет об обычных BPM и EA (архитектура предприятия), которые "по определению" включают в себя как Событийную онтологию (архитектура процессов, динамика), так и объектную (структуры, включая орг-структуру и ролевую).

            Ваша "событийная семантика" как то связана с S-BPM (в S-BPM не dataflow архитектура)? https://ekonomika.snauka.ru/2014/11/6316

            А "шапшную" картинку лучше включать в состав статьи. Я про нее и не догадался:


            1. boldachev Автор
              28.12.2022 15:31

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

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

              Это как просить программиста "нарисовать" схему процесса на том или ином языке программирования. Или еще круче, просить нарисовать эту схему на 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/ (тогда еще не было ясного представления о семантике и архитектуре движка).


              1. itGuevara
                28.12.2022 16:51

                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?

                "субъектно-событийный подход" =  "событийная семантика"?


                1. boldachev Автор
                  28.12.2022 17:15

                  Насколько понял: нарисовать аналогичную (заявка на отпуск) шапшной картинки (голосование) - большая сложность.

                  Ну что вы? )) В этом просто нет никакой необходимости. Обведите прямоугольниками модельные события (которые начинаются с имени модели @Завяка) и пририсуйте стрелки согласно ссылкам в Condition (в квадратных скобках). Надписи в прямоугольниках соответствуют значениям ограничивающих свойств (cardinality и пр). Я и не подумал рисовать, поскольку это тривиально. (Сравните шапочную картинку и псевдокод модели голосования - нарисовано именно то, что написано).

                  Вроде как есть инструменты автогенерации схемы (графа) по скрипту (RDF)

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

                  Меня пугает, что вместо BPM упорно упоминаете BMP

                  Извините. Не всегда внимателен. Опечатки)

                  "субъектно-событийный подход" = "событийная семантика"?

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