Всем привет!

Занимаюсь разработкой системы построенной на теории, что любые исторические информационные системы (ИИС) построены по одним законам.

Хотел поделится своими теоретическими наработками в этой области. Возможно, я не прав, или глубоко заблуждаюсь, но вдруг мои наработки кому-нибудь пригодятся. Пост может быть очень долгим, выкладки скучными и могут быть непонятны без пояснений. Все что ниже встречается, я реализую на связке Python + Django + Sqlite в своем проекте.

Статус проекта на текущий момент: Proof of concept.

Лицензия - MIT.

Кодовое название: ForTeaToo или 42.

В дневнике разработчика встречается название ForTea (устарело).

Ссылка на проект тут:

https://disk.yandex.ru/d/lzYIPYOAvOu8Sw

Актуальный дневник разработчика тут:

https://disk.yandex.ru/i/cfadjS-DIrcOOA

Поехали...

Любая ИИС основывается на определении самой истории:

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

Посмотрим на это со стороны ИИС:

Объективно описанные факты и установленная последовательность событий приводит к появлению истории.

Нужно учитывать что в ИИС история — это не История, как наука, а моделирование истории.

Моделирование – замещение одного объекта (оригинала) другим (моделью) и фиксация или изучение свойств оригинала путём исследования свойств модели.

И

Модель – представление объекта, системы или понятия (идеи) в некоторой форме, отличной от формы их реального существования.

Для ИИС необходимо учесть не только историю, но и прогнозы.

Прогнозирование поведения модели определено, так как определена планируемая последовательность действий при объективно описанных фактах на текущий момент.

Также необходимо уточнить что моделирование в ИИС основывается на дискретной линии событий. Дискретную линию событий назовем Таймлайн.

Запишем это формулой:

Таймлайн — t = {t_now-n,...t_now-1,t_now,t_now+1,...,t_now+n}, где t_now-n = t_past и t_now+n = t_future

Введем еще определения:

История — State(t_past,t_now)

План — StatePlan(t_now+1,t_future)

Прогноз — StateForecast(t_now+1,t_future)

Незавершенная последовательность событий — Delay(t_past,t_future)

Неопределенная незавершенная последовательность событий — ØDelay(t_past,t_future)

Однако в ИИС при моделировании, попытка решить неопределенность приводит к появлению упрощенной модели использующих внешние факты или приближенной модели определенных событий, требующей контроля системой или внешними источниками. Контроль осуществляем с помощью Задачи (Task).

Lim(ØDelay(t_past,t_future) ) = Task(t_past, t_future, BR(t_past, t_future), LM(t_past, t_future), TR(t_past, t_future) ) — Задача (Task) где (t_past,t_future) — период существования Задачи

BR(t_past, t_future) – Правила контроля целостности Задачи, или просто Правило (BR – business rule)

LM(t_past, t_future) — Ссылки на внутренние связанные факты, события, задачи и другие источники данных существующих в области определения системы, используемые при выполнении задачи. Назовем его Картой ссылок (Link Map).

TR(t_past, t_future) — Триггер (Trigger) — это команда или функция, сигнализирующая системе о наступлении определённого события

Однако, на периоде (t_past, t_future) BR, LM, TR могут изменяться, и из-за этих изменений Задачи (Task) могут становится невалидными. Поэтому эти функции могут быть использованы только на момент t_now. А изменения BR, LM, TR — должны быть ограничены, или приводить к принудительной отмене или завершения Задач.

В итоге — обобщенный Delay выглядит так:

Delay_Σ(t_past,t_future) = Delay(t_past,t_future) + ØDelay(t_past,t_future)

или при моделировании

Delay_Σ(t_past,t_future) = Delay(t_past,t_future) + Task(t_past, t_future, BR(t_now), LM(t_now), TR(t_now) )

Нам понадобятся еще определения:

Установленная последовательность событий — DelayPPA(t_past,t_now-1)

Планируемая последовательность событий — DelayPlan(t_now+1,t_future)

Результат завершенной последовательности событий

Fact(t_now) = Delay(t_now,t_now)

или

объективно описанные факты

Fact(t_now) = ØDelay(t_now,t_now)

Поясню:

Факты в системе появляются из-за завершенной последовательности событий — из-за свершившегося Delay

Fact(t_now) = Delay(t_now,t_now)

или, из-за упрощений моделирования, появляются из-за вырожденного Delay, находящегося вне системы или текущей модели

Fact(t_now) = ØDelay(t_now,t_now)

или с учетом моделирования

Fact(t_now) = Task(t_now, t_now, BR(t_now), LM(t_now), TR(t_now) )

Возвращаясь к формуле Delay

Delay_Σ(t_past,t_future) = Delay(t_past,t_future) + Task(t_past, t_future, BR(t_now), LM(t_now), TR(t_now) )

подставляем указанные выше формулы:

Delay_Σ(t_past,t_future) = Fact(t_now) + DelayPPA(t_past,t_now-1) + DelayPlan(t_now+1,t_future) +

Task(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

что позволяет использовать в незавершенной последовательности событий локализованные и уже описанные факты.

Запишем в общем виде с учетом прогноза и плана:

State(t_past,t_now)+ StatePlan(t_now+1,t_future) + StateForecast(t_now+1,t_future)

=

Fact(t_now) + DelayPPA(t_past,t_now-1) +DelayPlan(t_now+1,t_future)+DelayForecast(t_now+1,t_future)

В зависимости от Таймлайна формула принимает вид

Для прошлого

Fact(t_past) + DelayPPA(t_past) = State(t_past)

DelayPPA(t_past,t_now-1) = const – на диапазоне (t_past,t_now-1)

и не может приводить к изменению Fact(t_past), факты в прошлом не пересматриваются:

DelayPPA(t_now,t_now) = Δ Fact(t_now) и вносят изменения только в текущем времени

Для будущего

Fact(t_future) + DelayPlan(t_now+1,t_future) = State(t_now,t_future)

Fact(t_future) = Еще не известно (не определено).

Но известно, что:

Fact(t_future) = Fact(t_now) + DelayForecast(t_future)

где DelayForecast(t_future) — это прогноз, каким может стать факт и обладает следующими свойствами:

DelayForecast(t_future) = const — значение отражающее прогноз на момент t_future

DelayForecast(t_now) = StateForecast(t_now) – значение получаемое из истории прогноза на момент t_now

DelayForecast(t_past) = StateForecast(t_past) – значение получаемое из истории прогноза на момент t_past

Перепишем

( Fact(t_now) + DelayForecast(t_future) ) + DelayPlan(t_now,t_truture) = StatePlan(t_future)

Для текущего времени

Delay(t_past,t_now) может приводить к изменению Fact(t_now) в случае t_past = t_now, т. е.:

Delay(t_now,t_now) = Δ Fact(t_now)

и следовательно

Fact(t_now) + Δ Fact(t_now) = Fact(t_now) = State(t_now)

Все эти формулы приведены для одиночного кванта системы. Назовем ее value (значением). Значение может быть простым, сложным, составным и т. д. в зависимости от архитектуры.

Для обращения к значению в архитектуре фактов или событий мы используем именование этого значения.

Под именованием понимаем присваивание порядкового номера (ID) и интерфейсное отображение этого порядкового номера в виде строки, архитектурно удовлетворяющую системе фактов и событий, а также допустимый тип.

Именованное значение назовем реквизитом (requisite).

Реквизиты — объединенные в именованные группы, по признаку подобия, архитектурно относящиеся к одной сущности фактов или событий — составляют объект (object).

Объекты — объединенные в именованные группы, по признаку подобия, архитектурно относящиеся к одной сущности — составляют классы (class).

Текущее состояние системы (State) складывается из фактического состояния всех классов системы

(Σ_all Fact_{class_id})

на текущий момент времени t_now и всех событий с классами системы

(Σ_all Delay_{class_event_id})

которые произойдут в будущем (t_future), или произошли в прошлом t_past, но не были учтены в момент t_past, a повлияли на текущее состояние объектов системы в момент t_now

Запишем это формулой

State(t_past,t_now) = Σ_allFact_{class_id}(t_now) + Σ_allDelay_{class_event_id}(t_past , t_future)

Распишем формулу и дадим определение всем элементам системы:

Состояние системы описывается как State(t_past,t_now). Это функция Истории системы или ее логов. У нее два параметра отражающее ее существование на периоде из прошлого в настоящее. Она необходима для контроля изменения фактов в системе и событий с изменениями фактов.

Фактическое состояние класса — Fact_{class_id}(t_now). Это функция, которая в зависимости от параметра t_now принимает вид конкретного объекта системы. Параметр t_now — текущее время системы.

Если параметр t_now — не указан, то формула принимает вид:

Fact_{class_id}() = Σ_{f_id(class_id)} *Fact_{id_requisite}() + Σ_{f_id(class_id)} Delay_{id_requisite}() ; по * см ниже.

Но

Σ_{f_id(class_id)} Delay_{id_requisite}() = 0

так как Delay – не может существовать вне линии времени. И в случае когда t_now = t_past или t_now = t_future — любой Delay = 0

А

Σ_{f_id(class_id)} *Fact_{id_requisite}() = const

Следовательно

Fact_{class_id}() = Σ_{f_id(class_id)} *Fact_{id_requisite}()

Замечание к записи *:

Если полностью расписывать формулу то она должна была принять вид см. ниже. Delay исключаем сразу

Fact_{class_id}() = Σ_{f_id(class_id)} Fact_{id_object}()

где

Fact_{id_object}() = Σ_{f_id(id_object)} Fact_{id_requisite}()

и далее

Fact_{id_requisite}() = const

Но так как функция не зависит от времени, не имеет структуры объекта и соответственно не может его создать на линии времени, то

Σ_{f_id(class_id)} Fact_{id_object}() = *

или

Σ_{f_id(class_id)} Fact_{id_object}() = all

- становится оператором доступа ко всем неизменяемым параметрам системы — назовем ее «ссылкой» или «link» . Еще одно название alias (псевдоним). В формуле используем оператор ссылки «*». В проекте для «*» - используем запись [[all]] – все. Напомню — что все объекты в этом случае вырождены, так как не имеют структуры, и не существуют во времени.

Повторим то что получилось:

Fact_{class_id}() = Σ_{f_id(class_id)} *Fact_{id_requisite}()

где

Fact_{id_requisite}() = const

Результатом этой функции является постоянная. Под постоянной мы понимаем не только какое-то значение, но и алгоритм или результат вычисления функции, не зависящего от t_now.

В системе мы даем этой функции название «Константа» - и вводим класс (тип) данных Константа. Задача такого класса — хранить, вычислять и передавать const данные {значение, набор значений, функцию с параметрами}.

Если параметр t_now — указан, то в общем виде:

Fact_{class_id}(t_now) = Σ_{f_id(class_id)} Fact_{id_object}(t_now) + Σ_{f_id(class_id)} Delay_{id_object}(t_past,t_future)

но

Σ_{f_id(class_id)}Delay_{id_object}(t_past,t_future) = 0

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

Следовательно:

Fact_{class_id}(t_now) = Σ_{f_id(class_id)} Fact_{id_object}(t_now)

Результатом такой функции является набор объектов класса на текущий момент. В системе мы называем это «Справочником» - и вводим класс (тип) данных Справочник. Задача этого класса — хранить, вычислять и передавать данные об объектах, удовлетворяющих f_id(class_id), где f_id – функция логического условия, а

class_id = {id_object₁, id_object₂,... ,id_object_n}

- параметр влияющий на условие {может быть идентификатором класса, может быть идентификатором единичного объекта (id_object), набором объектов {id_object}, функцией возвращающей идентификаторы класса или объекта(ов) }, существует на момент t_now.

Опустимся еще на уровень глубже. Опять запишем в общем виде:

Fact_{id_object}(t_now) = Σ_{f_id(id_object)} Fact_{id_requisite}(t_now) + Σ_{f_id(id_object)} Delay_{id_requisite}(t_past,t_future )

По тем же причинам, что и в случае прошлых и будущих классов мы блокируем существование будущих и прошлых реквизитов объектов, работаем только с текущей реализацией классов и их параметров.

Следовательно:

Fact_{id_object}(t_now) = Σ_{f_id(id_object)} Fact_{id_requisite}(t_now)

Результатом такой функции является набор всех реквизитов объекта на текущий момент. В системе мы называем это «Элемент справочника» или «Объектом класса». Задача этого класса — хранить, вычислять и передавать данные об объектах, удовлетворяющих f_id(id_object), где f_id – функция логического условия, а

id_object = {id_requisite₁, id_requisite₂, ... , id_requisite_n }

- параметр влияющий на условие {может быть идентификатором объекта , может быть идентификатором реквизита (id), набором id, функцией возвращающей id}, актуальные на момент t_now.

Добрались до значений:

Fact_{id_requisite}(t_now) = Σ_{f_id(id_requisite)} Fact_{id_value}(t_now) + Σ_{f_id(id_requisite)}Delay_{id_value}(t_past,t_future)

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

Результатом такой функции является значение реквизита объекта на текущий момент. В системе мы называем это value или «Параметром справочника». Задача этого класса — хранить, вычислять и передавать данные о значении реквизита объекта, на момент t_now.

Fact_{id_value}(t_now) = const

и

Delay_{id_value}(t_past,t_future) = Δ const_f(past,now) + Δ const_{f(future,now)}

Рассмотрим формулу получения значения параметра справочника в общем виде внимательнее:

State_value(t_now) = Fact_{id_value}(t_now) + Delay_{id_value}(t_past,t_future)

тут встречаются параметры t_past,t_future.

t_past – время изменения в прошлом.

t_future – время изменения в будущем.

Как работает функция Delay_{id_value}(t_past,t_future)? Распишем подробнее:

Delay_{id_value}(t_past,t_future) = DelayPPA_{f(id_value, past,now)} + DelayPlan_{f(id_value, future,now)}

где

DelayPPA_{f(id_value, past,now)}

вычисляется как:

Если t_now = t_past, то DelayPPA_{f(id_value, past,now)} = null

Если t_now > t_past, то DelayPPA_{f(id_value, past,now)} = const

и

DelayPlan_{f(id_value, future,now)}

вычисляется как:

Если t_now <= t_future, то DelayPlan_{f(id_value, future, now)} = const

Если t_now > t_future, то DelayPlan_{f(id_value, future, now)} = null

Что находится в const? Там находится Δ значения параметра справочника.

Как это работает? Посмотрим на диаграмму.

Здесь видно что используя функцию DelayPPA_{f(id_value, past,now)} в текущий момент мы отправляем Δ значение параметра справочника в прошлое, изменяя дату его появления с текущего времени, на прошлое.

Аналогично поступаем и с функцией DelayPlan_{f(id_value, future,now)} .

В текущий момент мы отправляем Δ значение параметра справочника в будущее, и когда это будущее время наступит, то функция DelayPlan_{f(id_value, future,now)} добавит Δ к значению Fact_value и обнулится.

И так: У нас появилось еще два определения

Функция DelayPPA_{f(id_value, past,now)} — это функция корректировки значения параметра справочника в прошлом. В системе называется «Корректировка прошлого».

Функция DelayPlan_{f(id_value, future,now) —} это функция подготовки изменения параметра в будущем, с автоматическим применением при достижении назначенного времени. В системе называется «План»

Вернемся к параметрам справочника.

Fact_{id_value}(t_now) = const

и

Delay_{id_value}(t_past,t_future) = Δ const_{f(past,now-1)} + Δ const_{f(now+1,future)}

В Fact_{id_value}(t_now) = const значений параметров могут находится следующие элементы системы, которым тоже нужно дать описание:

Простые типы значений:

string – строка

float – число,

bool — логическое значение

link — ссылка на объект класса «Справочник» (Fact_{class_id}(t_now))

или класса «Контракт» (Delay_{class_event_id}(t_past , t_future))

datetime — Дата и время

date — Дата

enum — Статическое перечисление

eval — Вычисляемая функция (алгоритм)

const — Ссылка на константы

file — Ссылка на файл

Составные типы значений:

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

Массив — типизированная плоская таблица состоящая из простых типов значений. Используется только как подчиненная структура данных в «Справочниках» и «Контрактах»

Вспомогательные структуры:

Каталог — Помогает структурировать классы, выстраивая их иерархию и объединяя по смыслу «Справочники» и «Контракты»

Дерево — Помогает фильтровать «элементы справочника» и обеспечивает иерархическое выполнение формул.

Примеры работы Delay:

В Delay_{id_value}(t_past,t_future) = Δ const_{f(past,now-1)} + Δ const_{f(now+1,future)}

в Δ const могут находится только простые типы данных, но из-за смысла самого Delay работают они немного по-другому

string – строка в delay имеет приоритет в State.

В Fact_{id_value}(t_past) = «Строка»

В Delay_{id_value}(t_past) = «Строка исправленная»

Результат State_{id_value}(t_past) = «Строка исправленная»

Для t_{future –} по наступлению события в будущем t_now = t_future

В Fact_{id_value}(t_future-1) = «Строка»

В Delay_{id_value}(t_future-1) = «Строка исправленная»

Результат State_{id_value}(t_future-1) = «Строка»

В Fact_{id_value}(t_future) = «Строка исправленная»

В Delay_{id_value}(t_future) = null

Результат State_{id_value}(t_future-1) = «Строка исправленная»

float – число,

В Fact_{id_value}(t_past) = «1.0»

В Delay_{id_value}(t_past) = «-1.0»

Результат State_{id_value}(t_past) = «0»

Для t_{future –} по наступлению события в будущем t_now = t_future

В Fact_{id_value}(t_future-1) = «1.0»

В Delay_{id_value}(t_future-1) = «-1.0»

Результат State_{id_value}(t_future-1) = «1.0»

В Fact_{id_value}(t_future) = «0»

В Delay_{id_value}(t_future) = null

Результат State_{id_value}(t_future-1) = «0»

bool — логическое значение

В Fact_{id_value}(t_past) = «True»

В Delay_{id_value}(t_past) = «False»

Результат State_{id_value}(t_past) = «False»

Аналогично и для t_future – по наступлению события в будущем t_now = t_future

link — ссылка на объект класса «Справочник» (Fact_{class_id}(t_now))

или класса «Контракт» (Delay_{class_event_id}(t_past , t_future))

нет функции Delay. Заблокировано в PoC.

datetime — Дата и время

В Fact_{id_value}(t_past) = «15.07.2023 10:50»

В Delay_{id_value}(t_past) = «+00.00.0000 00:10»

Результат State_{id_value}(t_past) = «15.07.2023 11:00»

Аналогично и для t_future – по наступлению события в будущем t_now = t_future

date — Дата

В Fact_{id_value}(t_past) = «15.07.2023»

В Delay_{id_value}(t_past) = «+01.00.0000»

Результат State_{id_value}(t_past) = «16.07.2023»

Аналогично и для t_future – по наступлению события в будущем t_now = t_future

enum — Статическое перечисление

нет функции Delay. Заблокировано.

eval — Вычисляемая функция (алгоритм)

нет функции Delay. Заблокировано.

const — Ссылка на константы

нет функции Delay. Заблокировано.

file — Ссылка на файл

В Fact_{id_value}(t_now) = «Файл»

В Delay_{id_value}(t_future) = «Новый файл»

Результат State_{id_value}(t_now) = «Файл»

Результат State_{id_value}(t_future) = «Новый файл»

По наступлению t_now = t_future

В Fact_{id_value}(t_now) = «Новый файл»

В Delay_{id_value}(t_now) = «»

нет функции для Delay_{id_value}(t_past). Заблокировано.

Вернемся к основной формуле системы:

State = Σ_allFact_{class_id}(t_now) + Σ_allDelay_{class_event_id}(t_past , t_future)

Рассмотрим Delay:

мы помним что в общем виде:

Delay_Σ(t_past,t_future) = Fact(t_now) + DelayPPA(t_past,t_now-1) + DelayPlan(t_now+1,t_future) +

Task(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

следовательно:

Delay_{class_event_id}(t_past , t_future)=Σ_{f_id(class_event_id)} Fact_{id_contract}(t_now) +

Σ_{f_id(class_event_id)}DelayPPA_{id_contract}(t_past,t_now-1) +

Σ_{f_id(class_event_id)}DelayPlan_{id_contract}(t_now+1,t_future) +

Σ_{f_id(class_event_id)}Task_{id_contract}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

но мы сейчас рассматриваем последовательность событий над классами, следовательно

DelayPPA_{id_contract}(t_past,t_now-1) = null

DelayPlan_{id_contract}(t_now+1,t_future) = null

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

Следовательно:

Delay_{class_event_id}(t_past , t_future) = Σ_{f_id(class_event_id)} Fact_{id_contract}(t_now) + Σ_{f_id(class_event_id)}Task_{id_contract}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now)

Результатом такой функции является набор событий над фактами на интервале {t_past , t_future}, с фактическим результатом на t_now, так как существование набора событий не зависит от интервала согласно формуле.

В системе мы называем это «Контракты» - и вводим класс (тип) данных Контракты. Задача этого класса — хранить, вычислять и передавать данные о событиях над объектами, удовлетворяющих f_id(class_event_id), где f_id – функция логического условия, а

class_event_id = {id_contract₁, id_contract₂,... ,id_contract_n}

- параметр влияющий на условие {может быть идентификатором класса, может быть идентификатором единичного контракта (id_contract), набором контрактов {id_contract}, функцией возвращающей идентификаторы класса или объекта(ов) }, существующих на t_now

Отмечу что у класса контрактов есть все свойства Task. Следовательно — при определении класса мы должны это учитывать, и добавить к Контракту BR, LM и TR, как свойство всего класса.

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

Fact_{id_contract}(t_now) = Σ_{f_id(id_contract)} Fact_{id_requisite}(t_now) +

Σ_{f_id(id_contract)}DelayPPA_{id_requisite}(t_past,t_now-1) +

Σ_{f_id(id_contract)}DelayPlan_{id_requisite}(t_now+1,t_future) +

Σ_{f_id(id_contract)}Task_{id_requisite}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

Блокируем Delay:

DelayPPA_{id_requisite}(t_past,t_now-1) = null

DelayPlan_{id_requisite}(t_now+1,t_future) = null

Task_{id_requisite}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) ) = null

На уровне реквизитов контрактов (структура данных контракта) мы не можем допустить, чтобы у нас что-либо изменялось в прошлом и в будущем, при условии существующих (незавершенных) контрактов. А свойство Task наследуем из родительского класса. В следующих релизах это можно включить, для возможности к примеру переопределить поведение конкретных контрактов одного класса, в зависимости от значений контрактов.

Следовательно:

Fact_{id_contract}(t_now) = Σ_{f_id(id_contract)} Fact_{id_requisite}(t_now)

Результатом такой функции является набор всех реквизитов контракта на текущий момент. В системе мы называем это «Объектом контракта». Задача этого класса — хранить, вычислять и передавать данные об объектах, удовлетворяющих f_id(id_object), где f_id – функция логического условия, а

id_сontract = {id_requisite₁, id_requisite₂, ... , id_requisite_n }

- параметр влияющий на условие {может быть идентификатором объекта , может быть идентификатором реквизита (id), набором id, функцией возвращающей id}, актуальные на момент t_now.

Добрались до значений:

Fact_{id_requisite}(t_now) = Σ_{f_id(id_requisite)} Fact_{id_value}(t_now) +

Σ_{f_id(id_requisite)}DelayPPA_{id_value}(t_past,t_now-1)

Σ_{f_id(id_requisite)}DelayPlan_{id_value}(t_now+1,t_future) +

Σ_{f_id(id_requisite)}Task_{id_value}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

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

Результатом такой функции является значение реквизита контрактов на текущий момент. В системе мы называем это value или «Параметром контракта». Задача этого класса — хранить, вычислять и передавать данные о значении реквизита объекта, на момент t_now.

Здесь все аналогично «Справочникам». Отличием является Task. На уровне параметра контракта мы можем определить поведение параметра контракта так, чтобы у нас запускался и выполнялся Task.

Если нужно выполнить группу Task — то мы формируем техпроцесс (TP).

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

Формирование техпроцесов зависит от модели и в общем виде представлен формулой:

TP = Task_{id_value}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) )

где

Task_{id_value}(t_now+1, t_future, BR(t_now), LM(t_now), TR(t_now) ) =

Task_{f(id_value,1)}(t_now+1, t_future, BR₁(t_now), LM₁(t_now), TR₁(t_now) ) +

… +

Task_{f(id_value,n)}(t_now+1, t_future, BR_n(t_now), LM_n(t_now), TR_n(t_now) )

а 1 .. n – это конечное число задач заданных для id_value – ключевого поля.

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

PS :

Замечание не относящееся к общим выкладкам, но являющееся следствием.

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

Запишем в общем виде. Оператор «a.b» является обращением к члену структуры (член b объекта а)

State_value(t_now) = Fact_{class_id}(t_now).Fact_{id_object}(t_now).Fact_{id_requisite}(t_now)

где

class_id = {class_id₁,...,class_id_n}

id_object = {id_object₁,...,id_object_n}

id_requisite = {id_requisite₁,...,id_requisite_n}

и если взять эти параметры за const значения, то формула примет вид:

State_value(t_now) = [[table.123.15.18]]

первый параметр — Fact_{class_id} = «table», Delay_{class_event_id} - «contract»

второй параметр — номер класса

третий параметр — номер объекта

третий параметр — номер реквизита

На текущий момент это пока все, что есть в наработках. Проект потихоньку реализуется. Я стараюсь собирать демоверсии не реже одного раза в месяц.

Спасибо за внимание и обратную связь.