Александр Болдачев - Философия и цифровые технологии. Сборник статей

В формате события его семантическое содержание записывается кортежем. Семантическое содержание такого триплета трактуется как фиксация значения Value, имеющего тип ValueType (свойство или акт), на сущности, определенной событием BasicEvent. Поскольку все данные в EventFlow записываются в виде событий, то следует говорить, что любое событие (и приписывание значения свойства, и совершение акта) фиксируется на некотором предшествующем событии. Например, все свойства индивида (сотрудника компании) записываются как события фиксации их значений в предметной области.

Принципиальное отличие событийной семантики от объектной (в том числе имеющей темпоральные расширения) – введение между событиями обусловливающих связей, задающих отношения логического или причинного следования. События A и B считаются обусловливающими для события C, если констатируется обязательность их существования для выполнения C. Обусловливающие связи записываются в специальном поле формата события Condition, содержащем идентификаторы событий, послуживших условиями для совершения текущего события (C, Condition: A and B). Таким образом, онтология деятельности представляется в событийной семантике не только графом, устанавливающим связи между индивидами сущностей и значениями их свойств, но и темпоральным ориентированным ациклическим графом, фиксирующим временные последовательности обусловливающих друг друга событий.

Другим отличием событийной семантики от объектной является ее субъектность – обязательность указания актора, зафиксировавшего событие. В общем случае событием считается не изменение как таковое, а исключительно факт различения этого изменения участником деятельности – актором, в качестве которого может выступать человек, программный агент, датчик. Это требование важно не только с точки зрения смысла, вкладываемого в событие актором, но и с технологической точки зрения, поскольку значение события Value фиксируется конкретным актором (человеком или датчиком), а следовательно, зависит от состояния актора. Включение актора в формат события позволяет учитывать несогласованные, а порой и противоречивые утверждения, отражающие различные точки зрения, что существенно во многих предметных областях. Кроме того, наличие в формате события ссылки на актора позволяет одним запросом к событийному графу получать полное описание актора как участника конкретной деятельности.

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

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

Архитектуру EventFlow, по сути, следует рассматривать как событийный вариант шаблона DataFlow: соответствующие программы обычно представляются в виде направленного графа, в узлах которого расположены операторы, а ребра указывают на зависимости узлов по данным. Оператор очередного узла начинает выполняться сразу по получении всех необходимых данных от предшествующих узлов. Данные по ходу вычислений передаются от узла к узлу в виде токенов (рис. 1). Первые варианты DataFlow-компьютеров появились более полувека назад, но не получили широкого распространения из-за ряда нерешенных проблем, проявившихся как на уровне архитектуры, так и при создании языков программирования.

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

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