Руководство по разработке решателя

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

Содержание

Этап 1. Проектирование

Общие сведения

Порядок действий

  1. Сформулировать решаемую решателем задачу (описание назначения решателя) и убедиться в отсутствии в фонде решателей, решающих её.
  2. Разработать требования к решателю.
  3. Разработать проектную документацию решателя, включающую:

При этом

  1. Этап проектирования выполняется без использования сервисов платформы.
  2. Необходимо проанализировать содержимое фонда на предмет наличия в нем онтологий, агентов, шаблонов сообщений, и др. ресурсов, используя которые, можно решить определенные подзадачи в рамках решаемой задачи, и в случае обнаружения таких сущностей их необходимо повторно использовать.
  3. В каждом решателе должен присутствовать Инициализирующий агент - агент, содержащий блок продукций, инициируемый системным сообщением, создаваемым платформой по шаблону Ииициализирующее сообщение при запуске сервиса с данным решателем, — это точка входа в поток управления решателя.
  4. Различают решатели двух типов: с пользовательским интерфейсом и без такового. Решатель первого типа должен иметь специализированный агент — Интерфейсный контроллер, а также стартовую страницу на сайте проекта. В решателях без пользовательского интерфейса также должен быть агент, содержащий блок продукций, в процессе выполнения которого должно быть создано системное сообщение по шаблону Финализирующее сообщение (для решателей с пользовательским интерфейсом это не рекомендуется - они должны завершаться пользователем вручную исключительно с помощью интерфейсных возможностей платформы).
  5. Интеллектуальный решатель должен работать как минимум с одним входным или одним выходным инфоресурсом (то есть должен иметь как минимум один формальный параметр). Неинтеллектуальным считается решатель, который работает без обработки инфоресурсов (например, калькулятор).
  6. Собственные инфоресурсы содержат информацию, управляющую работой всех сервисов, построенных с использованием данного решателя. Зачастую (как минимум, когда такая информация не меняется), такая информация может быть заложена в исходный код и использование собственных инфоресурсов не требуется.

Интерфейс

Порядок взаимодействий при запуске

Начало работы решателя с интерфейсом происходит следующим образом: при запуске платформа (помимо отправки сообщения по Инициирующему шаблону корневому агенту решателя) выполняет "переход" на стартовую страницу — открывает модальное окно решателя, в котором отображаются все предыдущие вкладки для сервисов с этим решателем и присутствует новая (активированная) вкладка, соответствующая запускаемому сервису, и выполняет отображение стартовой страницы в этой вкладке. Отображение происходит по следюущим правилам: всё содержимое страницы, не являющееся ui-тегом отображается как есть, а на месте каждого ui-тега выполняется запрос в решатель, по получении результата которого он (результат) помещается в место расположения ui-тега (сам ui-тег не отображается). Можно сказать, что это вторая, третья и т.д. точки входя в поток управления решателя (число зависит от количество ui-тегов на стартовой странице).
Если в полученном интерфейсе (на стартовой и других страницах решателя) выполнить командное действие пользователя, которое опять же приводит к передаче ui-запроса, то его результат (ответ) заместит всё предыдущее содержимое, сгенерированное для предыдущего ui-запроса.
При выполнении перехода между страницами решателя отображение новой страницы и её дальнейшая работа подчиняется уже описанной схеме (для стартовой страницы).

Взаимодействие агентов Интерфейсный контроллер и Вид

При проектировании решателей с интерфейсом важно понимать, как сопрягаются пользовательский интерфейс (отображенный в браузере) и программная логика решателя (код блоков продукций агентов). В рамках такого взаимодействия данные от интерфейса проходят через двух агентов: Вид (агент платформы) и Интерфейсный контроллер (агент решателя), при этом между ними они помещаются в сообщение, формируемое по шаблону Запрос от агента Вид (UiParams) (отправителем считается агент "Вид"). А в обратную сторону - как минимум через агент Вид (далее для простоты изложения они будут исходить от агента Интерфейсный контроллер, хотя это не обязательно). Таким образом, задача агента Интерфейсный контроллер - получить сообщение по шаблону Запорс от агента Вид, а затем задача решателя (то есть какого-либо из его агентов, в простейшем случае - того же интерфейсного контроллера) состоит в обязательной отправке ответа агенту Вид.
Типичная схема потока данных (и в том числе — взаимодействия агентов Вид и Интерфейсный контроллер, обеспечивающего поддержку пользовательского Web-интерфейса в решателях с пользовательским интерфейсом), выглядит следующим образом:

Описание схемы:
  1. Внешне-системная часть агента Вид:
    1. получает запрос (2) от Web-сервера;
    2. формирует сообщение по шаблону "Запрос от агента Вид" (3), помещая в него параметры запроса, и отправляет его агенту Интерфейсный контроллер решателя;
    3. переходит в режим ожидания ответа (4) — уведомления (6) об окончании обработки ответного сообщения (5), которое придёт в Агентную часть агента Вид.
  2. Агентная часть агента Вид:
    1. принимает ответное сообщение (5), сформированное по одному из перечисленных на схеме шаблонов, которое содержит сформированный агентом Интерфейсный контроллер результат — в зависимости от шаблона сообщения это может быть одно из следующего:
      • ссылка на инфоресурс, сформированный по онтологии "Структура интерфейса" и представляющий собой описание фрагмента интерфейса
      • строка произвольного вида
      • ссылка на инфоресурс произвольного вида;
    2. обрабатывает полученное сообщение (5), формируя результат (7) для внешнесистемной части, который может представлять собой одно из следующего:
      • html-код (фрагмент интерфейса)
      • строка произвольного вида
      • JSON-представление;
    3. уведомляет (6) Внешне-системную часть агента Вид об окончании обработки сообщения (5) и отправляет ей результат (7).
  3. Внешне-системная часть агента Вид:
    1. получив увдомление (6), выходит из режима ожидания ответа (4)
    2. принимает сформированный в блоке продукций Агентной части агента Вид фрагмент интерфейса (7) (или строку, или JSON-представление инфоресурса) и передаёт его Web-серверу (8);
    3. переходит в режим ожидания нового запроса (2) от Web-сервера.

Примечания

  1. Сообщения (5), пришедшие к Агентной части агента Вид в период времени, когда Внешне-системная часть не находится в режиме ожидания ответа, будут обработаны соответствующими блоками продукций Агентной части, но не приведут к отрисовке пользовательского интерфейса (передачи данных (6), (7), (8), (9) не будут выполнены.
  2. Агент Вид всегда посылает сообщения только агенту Интерфейсный контроллер решателя.
  3. Интерфейсный контроллер, получив сообщение по шаблону "Запрос от агента Вид" (3), может сформировать сообщение некоторому другому агенту решателя, который, выполнив свою работу, может самостоятельно сформировать и отправить сообщение (5) агенту Вид для отрисовки интерфейса (минуя Интерфейсный контроллер). Однако рекомендуется придерживаться представленной схемы, в которой агенту Вид посылает сообщения (5) только агент Интерфейсный контроллер решателя.
  4. Агент Интерфейсный контроллер или некоторый другой агент решателя всегда должен посылать ответное сообщение (5), сформированное по одному из перечисленных на схеме шаблонов, Агентной части агента Вид для того, чтобы Внешне-системная часть агента Вид могла выйти из режима ожидания ответа и реагировать на новые запросы (2) от Web-сервера; Внешне-системная часть агента Вид работает в нескольких потоках, число которых ограничено, так что во избежания полной потери отклика платформы каждый такой поток ожидает ответ в течение максимум 30 секунд.

Этап 2. Разработка компонентов решателя задач

Разработка информационных компонент

В общем случае разработка решателя предполагает разработку следующих инфоресурсов, представляющих информационные компоненты:
  1. онтологий входных инфоресурсов;
  2. онтологий выходных инфоресурсов;
  3. онтологий собственных инфоресурсов;
  4. собственных инфоресурсов;
  5. онтологий временных инфоресурсов.
Для создания каждого из этих инфоресурсов необходимо выполнить следующее:
  1. создать новый инфоресурс в Фонде пользователя стандартные действия по созданию ЕХ (при этом для собственных инфоресурсов необходимо указать соответствующие онтологии);
  2. сформировать содержимое инфоресурсов, созданных на предыдущем шаге (причём вначале наполняеются онтологии, а затем — созданные по ним инфоресурсы) - см. статью.

Разработка программных компонент

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

Этап 3. Разработка (сборка) решателя задач

Разработка решателя состоит в формировании инфоресурса его представляющего.
Для этого необходимо создать инфоресурс решателя (название инфоресура есть название решателя, присвоенное ему на этапе проектирования) и сформировать его содержимое (см. статью) следующим образом:
Примечание: последовательность задания имён параметров не важна.

Пример содержимого web-страницы: 
Здравствуй, пользователь!
<ui action="навигация"/>
{{#css: .bad-error {color: red;} }}

Если в проектной документации решателя явно описана схема взаимодействия агентов, то:
Примечание
При формировании инфоресурса запрещается создавать понятие "логи".