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

Характеристики организма:

a. Состав. Организмы состоят из совокупности типизированных элементов. Для того, чтобы АИС функционировала с заданным качеством необходима строгая типизация объектов обработки, методов обработки, потоков обработки, сигналов и других элементов среды. Существует гипотеза, что подобная типизация должна существовать в явном для среды виде, т.е. система должна иметь то или иное представление о своих типах. Далее, состав АИС мы станем именовать АЛФАВИТОМ.

b. Организация. Организмы состоят из особых функциональных единиц, специализированных по строению и специализирующихся функционально. Организация есть центральный аспект существования информационной среды. Элементы алфавита связаны операционными отношениями, которые задают правила работы с системой. Организацию системы мы станем называть встроенной СЕМАНТИЧЕСКОЙ СЕТЬЮ.

c. Обменные процессы (веществом и энергией). Организмы представляют собой открытые системы, совершающие постоянный обмен веществом и энергией с окружающей средой. Для информационных организмов - это использование ресурсов, входные (генерация фактов) и выходные потоки (генерация отчетов (решения)). На текущем уровне реализации нет достаточных инструментов для реализации возможности активного существования системы в некоторой вычислительной среде, поэтому мы ограничим проектирование АИС только входными и выходными потоками. Мы станем именовать их подсистемами ГЕНЕРАЦИИ ФАКТОВ (напоминаю, что объекты системы - это структурированные факты) и ГЕНЕРАЦИИ РЕШЕНИЙ.

d. Раздражимость и психические функции. Организмы имеют способность отвечать на определенные внешние воздействия специфическими проявлениями (реакциями). Сочетания раздражитель-реакция могут накапливаться в виде памяти. Под раздражимостью информационных систем можно понимать очень многие вещи. Имеет полное право взгляд на информационную систему как на некоторую функцию, очень сложно организованную и имеющую механизмы управления. И в качестве «реакции» на «раздражители» оказываются способности реагировать заданным образом на запросы пользователей, импликативные модули обработки, реализующие ветвления потоков в зависимости от тех или иных условий, обработка событий. А в широком смысле - любой диалог, любой интерфейс, любая процедура или модуль. Отдельно выделим экспертные системы, семантические и нейронные сети, в которых делаются попытки имитировать накопление «знания» о каких-то предметных областях, реализуя способность системы к развитию своих «психических» функций. Совокупность средств системы обработки своих элементов мы станем именовать ОПЕРАЦИОННЫМ ПРОСТРАНСТВОМ.

e. Гомеостаз (регуляторные системы). Организм поддерживает свое динамическое равновесие с окружающей средой, он ведет себя так, словно желает сохранить свое существование и уникальность. Проблема целостности (integrity) является центральной в существовании информационных систем. На сегодняшний день не создано технологий, которые позволяют системе автоматически поддерживать свою целостность, напротив, большинство систем рождаются крайне неустойчивыми. Разработка механизмов поддержания системы в работоспособном состоянии так, чтобы ни одно воздействие не приводило к разрушению системы, есть важнейшая задача при проектировании и разработке. Классическое представление о целостности определяет ее на уровне данных (особенно в реляционных СУБД), но клиент-серверные технологии распространяют это свойство выше, включая целостность бизнес-логики в корпоративных системах. Реализация гомеостатических способностей АИС есть реализация МЕХАНИЗМОВ ЦЕЛОСТНОСТИ, которые описываются МЕТАПРАВИЛАМИ. Эти правила существуют вне системы и касаются жизненных циклов проектирования, разработки, отладки, внедрения и эксплуатации. Возможно, часть метаправил для оптимизации могут быть реализованы в машинно-человеческих механизмов, поскольку полная автоматизация поддержки целостности требует очень значительного ресурса.

f. Онтогенез (индивидуальное развитие). Новый организм возникает в ходе процессов индивидуального развития, при котором специализация элементов приводит к образованию различных по функциональности органов. Должны существовать механизмы, позволяющие развитие системы до полнофункционального в условиях ее непрерывной эксплуатации, а также дальнейшую модернизацию. Мы станем именовать эти механизмы ТЕХНОЛОГИЕЙ РАЗРАБОТКИ.

g. Филогенез (эволюционное развитие). Организмы представляют собой сущности, возникающие путем естественного отбора своих предшественников и дающие новые виды потомков. Существенным механизмом филогенеза является наследование, когда отдельные признаки (свойства) организма передаются с помощью специальных носителей. В широком смысле под наследованием можно понимать закрепление удачных решений при версионном обновлении программ. Для нас это означает наличие механизмов оценки удачных решений (как в области эффективности обработки задач, так и в области самой технологии обработки). При этом критериями отбора являются объективные условия эксплуатации системы. Мы станем именовать эти механизмы ЖИЗНЕННЫМ ЦИКЛОМ.

Наверное, вы обратили внимание, что сравнительный анализ был восходящим, если строить зависимости компонент АИС, то мы получаем инвертированную схему:

h. Существует жизненный цикл системы, определяющий технологию разработки;

i. Для системы существуют метаправила, реализованные через механизмы целостности;

j. Система обладает операционным пространством, включающие себя механизмы целостности, генерацию фактов и решений, а также обработки всех объектов системы, определяемых алфавитом системы;

k. Совокупность отношений между элементами системы определяются семантической сетью.

Таким образом, самая общая схема АИС будет выглядеть следующим образом:

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

С этой точки зрения можно рассматривать МОД как модель «ветвящейся вселенной».

Активность МОД может быть реализована несколькими способами, из которых следует выбрать генерацию сигналов к прочим программным модулям, участвующим в обработке. Этот способ самый дешевый по ресурсу и позволяет более легкую расширяемость, но накладывает ряд ограничений на любые программы, работающие в среде. Среди этих ограничений следует отметить:

o. Любой программный модуль при инициализации считывает МОД, которая является конфигурацией его работы;

p. Любой программный модуль должен уметь обрабатывать СЕРВЕР СОБЫТИЙ, который принимает изменения состояния экземпляров МОД и оповещает все прочие программные модули об этом изменении.

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

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

r. Создание формального языка (СКРИПТ) описание процесса рода деятельности;

s. Ведение логов каждым программным модулем в рамках Скрипта;

t. Фильтрация событий МОД на соответствие Правилам среды;

u. (необязательная возможность) Автоматическая обработка Скриптов с целью генерации правил;

v. (необязательная возможность) Реализация возможности выполнения Скриптов с помощью ВИРТУАЛЬНОЙ МАШИНЫ, в качестве макрокоманд.

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

Зафиксируем на рассмотрении примеров тот результат, который мы получили.

Подведем промежуточные итоги. Концепция МОД может быть непротиворечиво реализована на уровне описания и обработки событий в среде, где операции рассматриваются как неделимый элемент обработки каких-то неделимых данных. Эта неделимость на уровне обработки событий (ЕЕ - Eventual Engine) имеет принципиальное значение, ибо позволяет модифицировать логику жизненного цикла среды, а проецирование этой логики на уровень модулей даст нам сквозное, непротиворечивое, интегрированное описание процессов обработки.

Ради интереса исключительно познавательного вернемся к началу и дадим интерпретацию АИС как информационного организма в рамках метафоры ЕЕ:

ee. Состав: Алфавит: События, Входные и Выходные, Операции, Родовые Признаки.

ff. Организация: МОД - событийная модель как сеть (граф) последовательностей запуска операций для обработки.

gg. Обменные процессы: ЕЕ как конечный автомат с реализацией правила «ветвящейся вселенной».

hh. Раздражимость: логическая совокупность выходных событий порождают событие входное, активизирующее выполнение операций.

ii. Гомеостаз: модель непротиворечива, есть возможность отслеживать «зависшие события».

jj. Отногенез: модель расширяема с любой точки до любой глубины.

kk. Филогенез: существует возможности оптимизации как среды, так и жизненного цикла рода деятельности, который она поддерживает.

Но двинемся дальше. Мы имеем целую совокупность проблем, связанных с тем, что мы не можем рассматривать данные как условно-элементарные объекты, а операции как непараметрические.

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

Изначально, наши данные разделены на два типа: объекты баз данных, где экземпляр есть запись в таблице, описывающей класс объекта и файлы, где данные представляют некоторый структурированный объект согласно формату файла. С другой стороны мы имеем актуальные данные, находящиеся в обработке непосредственно и архивные данные, доступ к которым представляет собой отдельную задачу, иногда - нетривиальную. Такое деление необходимо оставить, априорных ограничений на его использование в Активной Интегрированной Среде не существует.

Операции, обрабатывающие массивы данных также неоднородны с точки зрения АИС. Существуют операции, ведение логов которых приведет к неоправданному увеличению данных (а значит не подлежащие описанию в рамках ЕЕ), существует операции, необратимо изменяющие объект обработки, когда не существует «отката», но только повторный запуск обработки по восстановленным данным из бэкапированного источника. Существуют операции, выполняющиеся в неопределенном цикле и имеющие неопределенные критерии запуска и качества результата (таковые в огромном количестве присутствуют в работе экспертов). Тем не менее, частичная логика (которую можно и должно отразить в Семантической сети) может присутствовать в полном объеме, и очень жесткая, например, связи (точнее - корреляции) данных по разным типам пропусков по одному участку. Эти корреляции должны иметь сигнальную природу, но быть существенно параметризированными.

Мы приходим к необходимости задания в Алфавите и Семантической сети репозитария всех классов объектов и всех классов значимых операций. При этом мы должны сохранить принцип экземплярности и наследования «родовых признаков». Данная задача решается с необходимой полнотой обработкой МОДЕЛИ ПОТОКОВ ДАННЫХ (МПД), которая очень похожа на сигнальную модель, но не тождественна ей. Внимание! В связи с тем, что наша МОД расщепилась, нам необходимо начать именовать ранее описанную часть МОД как СИГНАЛЬНУЮ МОДЕЛЬ (СМ), что мы и станет делать.

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

Наверное, вы уже обратили внимание на то, что СМ и МПД имеет общие элементы - операции. Именно через операции реализуется поддержка общей целостности и верификация МОД. Для автоматически запускаемых операций (где нет сигналов, генерируемых пользователями, администраторами или технологами системы) мы должны наложить определенные требования к реализации, которые мы не станем рассматривать в настоящем документе.

И так, на текущем этапе концептуального проектирования, мы имеем только два не проработанных аспекта - описание МОД в программных модулях предназначенных для интерактивной работы (например, обработка экспертами данных полученных в результате автоматического анализа) и синхронизация данных, полученных из различных источников. В рамках сформулированных нами принципов названная задача является тривиальной. 

Следует отметить, что операционное задание целостности есть только один из вариантов. Существует универсальное решение, когда мы добавляем в МОД соответствующие разделы по описанию законов отношения между объектами и их параметрами. Такое решение бесконечно дорого по отношению к текущему ресурсу, хотя, безусловно, красиво, но мы не станем его прорабатывать. Поэтому нам придется оставить Семантическую модель как комментарий к МОД, расшифровывающую значение тех или иных областей данных, их отношений, операций и прочих программных компонент среды.

Собственно, на этом наше проектирование концептуального уровня закончено, поскольку мы получили ответы на все интересующие нас вопросы. Мы не стали прорабатывать очевидные вещи, такие как использование логов для восстановления данных как макрокоманды и пр., что вызвано нехваткой времени проектирования. Не стали мы прорабатывать концептуальные вещи универсализации хранения данных согласно модели BHC («Be, Have, Can»), что вызвано жесткими условиями производительности. Все технические вопросы могут быть решены в оперативном порядке. Все концептуальные вопросы могут получить разрешение в дальнейшей детализации проекта.

В качестве закрепления результатов опишем получившуюся среду:

ll. Существует пространство данных, которое состоит из следующих областей:

i. Реестр или репозитарий, или алфавит, в котором описаны все имена сигналов, объектов, операций;

ii. МОД, состоящую из СМ и МПД, где зафиксированы операционные отношения между элементами алфавита, где СМ - это сеть вида: (Логическое условие генерации входного сигнала) Имя Операции (Имя выходного сигнала), а МПД - это сеть вида: (Коллекция Имен Входных Объектов) Имя Операции (Коллекция Имен Выходных Объектов);

iii. Текущее состояние МОД, где каждый объект имеет коллекцию экземпляров (в зависимости от произведенных ветвлений) и ссылку на область хранения объекта (файл или таблицу БД);

iv. Состояние МОД, где описано текущее состояние сигналов, ссылка на область данных, где хранится информация о «родовых признаках» (история обработки);

v. Экземпляры объектов базы данных как записи регулярных таблиц;

vi. Экземпляры данных как файлы, включая файлы, доступные для непосредственной обработки и файлы архивов;

mm. Существует совокупность процессов среды, которая состоит из следующих серверов:

i. Eventual Engine - общий сервер обработки МОД, предоставляющий доступ к данным, регламентирующий права и контекст совершения операций, генерирующий ветвления модели, уникальные имена экземпляров данных, формирующий текущее состояние МОД, запускающий демонов, осуществляющий сигналинг для интерактивной обработки, выполняющий синхронизацию локальных и глобальной версий МОД при удаленной несинхронной работе, ведущий и обрабатывающий логи;

ii. Автоматические процессы - демоны, управляемые ЕЕ;

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

iv. Интерактивные программные модули обработки данных (редакторы), обладающие интерфейсом доступа к ЕЕ, умеющие обрабатывать события, генерируемые ЕЕ, могущие иметь «инкапсулированные», локальные данные и логи, не влияющие на целостность среды;

nn. Существует Семантическая сеть как описание проблемной области среды, где закомментированы правила, не нашедшие явного формального описания в МОД, а реализованы косвенно или некоторой совокупностью правил;

oo. Существует Технология разработки среды, в которой зафиксированы стандарты реализации программных модулей, расширение базовых мета-объектов среды, таких как Алфавит и т.п., а также требования поддержки жизненного цикла. Первым стандартом Технологии можно считать настоящий документ, определяющий общую методологию АИС;