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

В статье не рассматриваются вопросы технической реализации типа: REST/SPA‑подход или long polling / WebSocket / server‑side session / event sourcing.

Сценарии использования поиска решений управляемого данными и масштабируемость

Вот типичные варианты архитектур, которые могут быть использованы для доступа к системе поиска решений:

1.      Локально. База знаний клонируется (реплицируется) и каждый пользователь работает обособленно со своей копией.

2.      В локальной сети. Толстый клиент. База знаний находится на сервере, а на рабочих станциях установлены клиенты, которые постоянно взаимодействуют с базой знаний для  получения доступа к информационным блокам и словарю. Механизм поиска решений работает на локальных рабочих местах.

3.      На локальных рабочих местах работают тонкие клиенты. Вся обработка данных выполняется на сервере.

Преимуществом варианта 1 является автономность. Но возникает необходимость постоянно поддерживать базу знаний в актуальном состоянии. Если вносятся изменения, они должны оперативно распространяться на все копии базы знаний, что неизбежно приведёт к разного рода коллизиям. Этот вариант удобен для разработки и отладки. Или для приложения созданного исключительно для себя и тогда необходимость делиться базой знаний не возникает.

Вариант 2 снимает необходимость актуализировать базу знаний между клиентами. К проблемам может приводить, как и в варианте 1, необходимость разрешать коллизии при внесении изменений в информационное наполнение от разных клиентов.

Вариант 3 не требователен к ресурсам локальных рабочих мест. С возможным возникновением коллизий аналогичная ситуация, как и в вариантах 1 и 2.

Взаимодействие с базой знаний в интернете возможно через браузер или через WEB-клиента. И чисто браузер и WEB-клиент теоретически могут эмулировать все три варианта, но с существенными оговорками.

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

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

1.      Браузер передаёт данные и запускает серверный процесс.

2.      Браузер периодически проверяет готовность ответа от сервера.

3.      Серверный процесс выполняется до момента, когда потребуются дополнительные данные или решение будет найдено.

4.      Если решение найдено, формируется итоговый отчёт для браузера.

5.      Если поиск продолжается. Состояние процесса замораживается: сохраняется состояние репозиториев информационных блоков, очереди параметров, текущие флаги событий, состояние отчётов и тому подобная информация, накопившаяся в процессе поиска решений.

6.      Серверный процесс завершается и устанавливается флаг ожидания ответа от браузера.

7.      Браузер обнаруживает готовность данных и забирает информацию с сервера.

8.      Браузер анализирует информацию, поступившую от сервера. В том числе управляющие сигналы. Возможны варианты: 1 - процесс завершен; 2 - требуется дополнительная информация.

9.      Если запрашивается дополнительная информация, браузер передаёт данные и перезапускает серверный процесс.

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

11.   Если ожидается продолжение процесса, всё повторяется с пункта 3.

12.   Если  от браузера поступило требование прекращения поиска, процесс завершается с формированием итоговой информации для браузера.

13.   Браузер завершает сеанс работы с сервером.

ПРИМЕЧАНИЕ. Во время прерывания процесса на сессию браузера пользователь может запросить дополнительную справочную информацию. Тогда взаимодействие через область обмена данными продолжится, но цикл поиска запущен не будет.

Предотвращение и разрешение коллизий

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

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

Влияние изменений в информационных блоках требуют специальных техник.

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

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

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

Правило 2. Внесение любых изменений в одном информационном блоке должно запускать механизм проверки других информационных блоков и становиться сигналом к восстановлению целостности информационного наполнения. До полной синхронизации информационного наполнения внесение, каких бы то ни было других изменений, будет только усугублять ситуацию неопределённости. Что имеется ввиду. Например, в блоке А изменён диапазон допустимых значений входного параметра необходима проверка на пересечение диапазонов для этого параметра во всех других блоках, где этот параметр так же используется для получения аналогичных результатов (определения одного и того же параметра). Другими словами, во избежание неопределённости, всегда необходимо проверять пересечение диапазонов допустимых значений для информационных блоков использующихся для определения одного и того же параметра.

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

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

Заключение

Автономная работа с экспертной системой удобна при создании информационного наполнения, отладки и тестирования приложений.

Так же автономное использование экспертной системы удобно, если не требуется коллективная работа.

Во всех остальных случаях предпочтение следует отдавать клиент-серверным архитектурам. Будь то доступ через интернет или коллективная работа в локальной сети.

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