Базовая технология разработки сервисов на платформе IACPaaS

Дата последней модификации документа: 20 мая 2022.

Содержание

1 Введение
2 Сборка интеллектуального сервиса из компонентов
3 Разработка информационных ресурсов
4 Разработка решателя задач интеллектуального сервиса
- 4.1 Общие сведения
- 4.2 Связывание решателя задач с формальными параметрами и интерфейсом интеллектуального сервиса
5 Разработка агентов решателя задач
6 Разработка шаблонов сообщений
7 Разработка интерфейса
8 Примечания

Введение

Технологические принципы разработки, сопровождения и использования облачных ИС на облачной платформе IACPaaS:

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

Платформа IACPaaS поддерживает:

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

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

Базовая технология разработки прикладных и специализированных инструментальных облачных мультиагентных сервисов и их компонентов в общем случае включает следующие процессы:

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

Сборка интеллектуального сервиса из компонентов

Интеллектуальный сервис есть пара: service = <app, <<in₁, …, in_k>, <out₁, …, out_p>>>, k ≥ 0, p ≥ 0, где:

app – интегрированный с формальными параметрами и пользовательским интерфейсом решатель задач (его устройство описано в разделе Разработка решателя задач интеллектуального сервиса);
<in₁, …, in_k> – возможно пустой кортеж пар вида <имя параметра - значение параметра>, где значение параметра есть информационный ресурс Фонда (база знаний, данных), доступный решателю задач только для чтения;
<out₁, …, out_p> – возможно пустой кортеж пар вида <имя параметра - значение параметра>, где значение параметра есть информационный ресурс Фонда (база знаний, данных), доступных решателю задач, как для чтения, так и для модификации (вплоть до полного формирования всего содержимого)^[1].

Разделение информационных и программных компонентов сервиса преследует следующие цели:

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

В обоих случаях совместимость обеспечивается на уровне входных и выходных формальных параметров решателей задач. Таким образом, для того, чтобы разработать сервис, в Фонде, во-первых, должен присутствовать подходящий решатель задач – app*, а во-вторых, если <in₁, …, in_k> ∪ <out₁, …, out_p> ≠ ∅, то для каждого входного и выходного формального параметра этого решателя задач должен присутствовать хотя бы один информационный ресурс, принадлежащий области допустимых значений этого формального параметра – фактический параметр.

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

Сборка интеллектуального сервиса service* выполняется следующим образом:

В Фонде (общем или личном) выбирается подходящий для решения задачи интегрированный решатель задач – app*.
Если <in₁, …, in_k> ∪ <out₁, …, out_p> ≠ ∅, то для каждого входного и выходного формального параметра решателя задач app* в Фонде выбирается подходящий для решения задачи фактический параметр, принадлежащий области допустимых значений этого формального параметра. Таким образом устанавливается соответствие между входными и выходными формальными и фактическими параметрами.
Если <in₁, …, in_k> ∪ <out₁, …, out_p> ≠ ∅, то средствами Административной системы выполняется связывание интегрированного решателя задач app* с выбранными фактическими параметрами, поставленными в соответствие его входными и выходными формальным параметрам, и создание на их основе сервиса service*. Если же <in₁, …, in_k> ∪ <out₁, …, out_p> = ∅ (т.е. решение сервисом service* задачи не подразумевает обработку информационных ресурсов, за исключением, возможно, собственных информационных ресурсов app*), то средствами Административной системы выполняется создание сервиса service* только на основе интегрированного решателя задач app*.

Собранный таким образом сервис service* может быть запущен пользователем через Административную систему.

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

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

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

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

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

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

Разработка информационных ресурсов, представляющих информацию

При разработке некоторого информационного ресурса, представляющего информацию – ig*, информационный ресурс, представляющий его метаинформацию – mg* должен присутствовать в Фонде. В противном случае mg* необходимо разработать по технологии, описанной в разделе Разработка информационных ресурсов, представляющих метаинформацию.

Разработка информационного ресурса ig* состоит из двух этапов:

Создание с использованием Административной системы в разделе некоторой предметной области Фонда нового информационного ресурса ig* с пустым содержимым (орграф представлен единственной корневой вершиной), с указанием в качестве метаинформации mg* – информационного ресурса, представляющего метаинформацию и описывающего область допустимых значений (множество информационных ресурсов) некоторых формальных параметров интегрированных решателей задач.
Формирование пользователем содержимого информационного ресурса ig* с использованием Редактора орграфов информации^[2], в котором процесс редактирования ig* управляется орграфом метаинформации mg*.

В процессе работы Редактор орграфов информации формирует и поддерживает соответствие между дугами орграфов ig* и mg*. Формирование орграфа ig* осуществляется пользователем “сверху-вниз”: от вершин, представляющих сложносоставные понятия – к атомарным, начиная с корневой вершины орграфа ig*. Преимущество данного подхода над подходом к формированию орграфовой структуры “снизу-вверх” состоит в том, что первый является более естественным для человека: орграф информации “разворачивается” пользователем строго в соответствии со структурой (шаблоном), заданной в орграфе метаинформации. Во втором случае, напротив, пользователю необходимо четко представлять и постоянно держать в уме всю структуру (связи между вершинами) формируемого орграфа (от чего в первом случае он полностью избавлен).

Web-интерфейс Редактора орграфов информации отображает уже сформированную часть подграфа ig* и набор интерфейсных элементов для выполнения возможных действий пользователя по редактированию значений полей активных вершин подграфа ig* и порождению исходящих из них дуг, который формируется Редактором орграфов информации на основе вершин орграфа mg*, соответствующих активным вершинам ig*, и множества выходящих из них дуг в орграфе mg* (если таковые имеются). Если порождаются дуги, исходящие из активной вершины ig*, то их концы становятся активными вершинами. Редактирование ig* возможно лишь в тех пределах, которые не нарушают соответствие между орграфами ig* и mg*.

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

Разработка информационных ресурсов, представляющих метаинформацию

Разработка информационного ресурса mg* также состоит из двух этапов:

Создание с использованием Административной системы в разделе некоторой предметной области Фонда нового информационного ресурса mg* с пустым содержимым (орграф представлен единственной корневой вершиной), с указанием в качестве метаинформации информационного ресурса, содержащего описание языка представления орграфов метаинформации (присутствующем в Фонде платформы IACPaaS априори).
Формирование содержимого информационного ресурса mg* “сверху-вниз” (начиная с корневой вершины орграфа) с использованием Редактора орграфов метаинформации в терминах языка представления орграфов метаинформации.

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

Разработка решателя задач интеллектуального сервиса

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

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

Корневой агент – агент, посылая инициализирующее сообщение которому при запуске сервиса, процессор решателей задач платформы IACPaaS инициирует работу сервиса (т.е. среди множества агентов решателя задач данный агент всегда начинает работать первым).
Интерфейсный контроллер – агент, взаимодействие которого с системным агентом платформы Вид обеспечивает сопряжение пользовательского интерфейса с решателем задач (в случае разработки сервиса с пользовательским интерфейсом). Агент Вид создает и посылает сообщения Интерфейсному контроллеру (и только ему) в ответ на события, генерируемые в пользовательском интерфейсе (см. также Общие сведения о разработке интерфейса интеллектуального сервиса).

В процессе работы сервиса агенты, входящие в состав решателя задач, связываются друг с другом динамически, начиная с Корневого агента или Интерфейсного контроллера (при обработке событий, генерируемые в пользовательском интерфейсе). При этом агент отправитель (sender) может послать сообщения множеству агентов {receiver₁, …, receiver_n}, где receiver_i (i = 1, …, n) может быть одним из следующих агентов:

агент, от которого sender получил сообщение (за исключением случая посылки процессором решателей задач инициализирующего сообщения Корневому агенту);
агент, указанный в принимаемом агентом sender сообщении;
агент, название или указатель на которого задается в коде агента sender, т.е. получатель однозначно определяется на этапе разработки агента sender.

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

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

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

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

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

Интегрированный с формальными параметрами и пользовательским интерфейсом решатель задач может быть представлен кортежем вида (необязательные компоненты здесь и далее заключены в скобки “[” и “]”): app = <name, descr, a_root, [a_ui], [web_page], <IN₁, …, IN_k>, <OUT₁, …, OUT_p>, <own₁, …, own_q>, <log₁, …, log_s>>, k ≥ 0, p ≥ 0, q ≥ 0, s ≥ 0, где:

name – название интегрированного решателя задач на естественном языке, отображаемое всем авторизованным пользователям платформы IACPaaS при просмотре содержимого Фонда через Административную систему.
descr – содержательное описание назначения решателя задач на есте-ственном языке, включающее описание решаемой задачи или класса задач, а также входных и выходных данных, и доступное всем авторизованным пользователям платформы IACPaaS при просмотре содержимого Фонда через Административную систему.
a_root – Корневой агент решателя задач.
a_ui – агент Интерфейсный контроллер.
web_page – стартовая web-страница решателя задач на web-сайте платформы – web-страница, на которую выполняется перенаправление при запуске сервиса через Административную систему.
<IN₁, …, IN_k> – возможно пустой кортеж входных формальных параметров решателя задач. Каждый IN_i (i = 1, …, k) есть пара <имя параметра - значение параметра>, где значение параметра есть информационный ресурс Фонда, представляющий метаинформацию и определяющий множество информационных ресурсов представляющих информацию, которому должен принадлежать значение одноименного фактического параметра in_i (в сервисе).
<OUT₁, …, OUT_p> – возможно пустой кортеж выходных формальных параметров решателя задач. Каждый OUT_j (j = 1, …, p) есть пара <имя параметра - значение параметра>, где значение параметра есть информационный ресурс Фонда, представляющий метаинформацию и определяющий множество информационных ресурсов представляющих информацию, которому должен принадлежать знчение одноименного фактического параметр out_j (в сервисе).
<own₁, …, own_q> – возможно пустой кортеж собственных информационных ресурсов решателя задач, представляющих информацию и доступных ему как для чтения, так и для модификации. Собственные информационные ресурсы используются для хранения собственных данных и настроек решателя задач, управляющих логикой его работы, и т.п., а также являются разделяемыми для всех сервисов, в состав которых входит данный решатель задач.
<ownR₁, …, ownR_r> – возможно пустой кортеж собственных информационных ресурсов решателя задач, представляющих информацию и доступных ему только для чтения.
<log₁, …, log_s> – возможно пустой кортеж информационных ресурсов, каждый из которых представляет собой журнал работы агентов решателя задач, формируемый при запуске некоторого сервиса, в состав которого входит данный решатель, и заполняемый вплоть до завершения его работы.

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

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

В Фонде присутствовал агент, являющийся Корневым агентом решателя задач – a_root.
В случае разработки сервиса с пользовательским интерфейсом – на web-сайте платформы IACPaaS была создана стартовая web-страница для интегрируемого решателя задач, а в Фонде присутствовал агент, являющийся его Интерфейсным контроллером – a_ui (данный агент может быть повторно используемым и, таким образом, входить в состав различных решателей задач).
Если <IN₁, …, IN_k> ≠ ∅, то в Фонде присутствовали все информационные ресурсы IN_i (i = 1, …, k).
Если <OUT₁, …, OUT_p> ≠ ∅, то в Фонде присутствовали все информационные ресурсы OUT_j (j = 1, …, p).
Если <own₁, …, own_q> ≠ ∅, то в Фонде присутствовали все информационные ресурсы own_l (l = 1, …, q).

Если некоторый информационный ресурс IN_i (OUT_j) отсутствует в Фонде, то его необходимо разработать по технологии, описанной в разделе Разработка информационных ресурсов, представляющих метаинформацию. Если некоторый информационный ресурс own_l отсутствует в Фонде, то его необходимо разработать по технологии, описанной в разделе Разработка информационных ресурсов, представляющих информацию. Если агенты a_root и/или a_ui отсутствуют в Фонде, то их необходимо разработать по технологии, описанной во второй части данного цикла работ. Декларативная спецификация интегрированного решателя задач формируется в два этапа:

Создание с использованием Административной системы в Фонде платформы IACPaaS нового информационного ресурса (с названием, совпадающим с названием интегрированного решателя задач, и пустым содержимым) по хранящейся в Фонде метаинформации Структура решателя задач, описывающей онтологию декларативных спецификаций интегрированных решателей задач платформы.
Формирование содержимого созданного информационного ресурса с использованием Редактора решателей задач, в котором процесс редактирования управляется метаинформацией Структура решателя задач.

Специфицирование решателя задач состоит в задании:

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

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

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

Разработка агентов решателя задач

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

Агент состоит из двух частей – декларативной и процедурной – и представлен кортежем вида: agent = <name, internal_name, descr, [local_structure], {production_block₁, …, production_block_n}, src_code, code, {processed_irs}>, n ≥ 1, где:

name – название агента на естественном языке, отображаемое всем авторизованным пользователям платформы IACPaaS при просмотре содержимого Фонда через Административную систему.
internal_name – внутреннее имя агента, которое используется в качестве имени класса-заготовки агента (в частности, при генерации заготовки его исходного кода) и в качестве префикса в имени класса-реализации агента.
descr – содержательное описание назначения агента на естественном языке, включающее описание решаемой задачи или класса задач, шаблонов входных и выходных сообщений, посредством которых он взаимодействует с другими агентами, а также, возможно, единиц хранения Фонда, которые он обрабатывает. При генерации заготовки его исходного кода данное описание помещается в исходный код класса агента в качестве комментария к нему и ориентировано на разработчиков решателей задач и сопровождающих агента. Вместе с тем, это описание доступно, также, всем авторизованным пользователям платформы IACPaaS при просмотре содержимого Фонда через Административную систему.
local_structure – локальная структура данных – описывает структуру информации, доступной в каждом блоке продукций агента (при каждом обращении к экземпляру агента^[3] во время работы сервиса) и используемой для хранения собственных данных, настроек агента, управляющих логикой его работы и т.п. (может отсутствовать, если все нужные данные доступны через сообщения и/или информационные ресурсы).
productions_blocks – непустое множество блоков продукций агента {production_block₁, …, production_block_n} и общее для них всех (возможно, пустое) множество адресуемых агентов addressed_agents_psbs.
src_code – исходный код агента (java-код), входящий в состав его процедурной части, и состоящий из множества {src_code_v1, ... src_code_vN} - множества версий, одна из которых является текущей.
code – исполняемый код агента (байт-код), входящий в состав его процедурной части (отсутствует до тех пор, пока исходный код агента не разработан, не выбрана его текущая версия).
processed_irs – возможно-пустое множество онтологий обрабатываемых ресурсов, разделённое на три (возможно пустых) подмножества - "только чтение", "полный доступ", "временные".

Каждый блок продукций production_block_i (i = 1, …, n) есть тройка вида: production_block = <descr, inMsgTemplate, {outMsgSending₁, …, outMsgSending_m}>, m ≥ 0, т.е. каждый блок продукций декларативно представлен следующими компонентами:

descr – содержательное описание назначения блока продукций на естественном языке, включающее описание решаемой им задачи, а также, возможно, краткое описание метода ее решения. Данное описание помещается в исходный код класса агента в качестве комментария к методу, соответствующему данному блоку продукций, и ориентировано на разработчиков решателей задач и сопровождающих агента.
inMsgTemplate – шаблон входных сообщений – сообщений, инициирующих выполнение данного блока продукций агента (устройство шаблонов сообщений описано в разделе Разработка шаблонов сообщений).
{outMsgSending₁, …, outMsgSending_m} – возможно пустое множество отправок выходных сообщений, где каждый элемент содержит сылку на определенный шаблон ссобщений, создаваемых в процессе выполнения данного блока продукций агента, и (возможно, пустое) множество адресуемых агентов addressed_agents_pbs (данный компонент может отсутствовать, если после выполнения блока продукций не требуется посылка каких-либо сообщений).
addressed_agents_pb – общее для блока продукций (возможно, пустое) множество адресуемых агентов.

Декларативный компонент состоит, по существу, из двух частей – документации к агенту, которая представлена совокупностью содержательных описаний, как самого агента, так и всех его блоков продукций на естественном языке, и формальной спецификации множества блоков продукций, из которых агент состоит. На основе декларативного компонента средствами платформы IACPaaS поддерживается автоматизация процесса разработки и сопровождения документированного исходного кода агента. Орграфовая связная двухуровневая модель информационных ресурсов и ее соответствующая поддержка процессором информационных ресурсов платформы IACPaaS позволяют хранить декларативную спецификацию, исходный и исполняемый код агента (получаемый в результате компиляции "текущей версии" его исходного кода) в одной единице хранения Фонда, представляющей данный агент. Для создания и обработки таких единиц хранения платформа предоставляет инструментальный сервис Расширенный редактор агентов (автоматически запускается при открытии инфоресурса типа Агент).

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

Для разработки агента необходимо чтобы для каждого его блока продукций production_block_i (i = 1, …, n) в Фонде (общем или у некоторого пользователя) присутствовали inMsgTemplate_i – шаблон входных сообщений и, если {outMsgSending₁, …, outMsgSending_m} ≠ ∅, то все соответсвующие шаблоны выходных сообщений – outMsgTemplate_ij (j = 1, …, m).

Если некоторый шаблон сообщений inMsgTemplate_i или outMsgTemplate_ij отсутствует в Фонде, то его необходимо разработать по технологии, описанной в разделе Разработка шаблонов сообщений.

Описание подмождеств "только чтение", "полный доступ", "временные" (входящих в processed_irs есть спецификация инфоресурсов-параметров, обрабатываемых агентом, то есть:

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

Разработка агента состоит в:

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

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

Формирование информационного ресурса агента

Формирование на платформе информационного ресурса, представляющего декларативную спецификацию агента, выполняется по следующей схеме:

Создание с использованием Административной системы в Фонде пользователя платформы IACPaaS нового информационного ресурса (с названием, совпадающим с названием агента, и пустым содержимым), представляющего декларативную спецификацию разрабатываемого агента (указывается тип ЕХ - Агент).
Формирование содержимого созданного информационного ресурса с использованием Редактора агентов, в котором процесс редактирования управляется метаинформацией Структура агента.

Специфицирование агента состоит в задании:

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

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

Описывая блоки продукций, необходимо следовать положениям:

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

Создание версии исходного кода агента

После того, как декларативная часть разрабатываемого агента описана (или модифицирована), средствами Расширенного редактора агентов можно приступить к формированию версии его исходного кода (на языке Java) одним из 2 способов:

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

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

Написание исходного кода агента

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

При написании исходного кода (и далее при создании исполняемого) можно выполнять проверку кода агента и используемых в нем внутренних классов (если они есть) на корректность^[4] и безопасность ^[5] с точки зрения его выполнения на виртуальной машине платформы. Если код не корректен или не безопасен, то разработчик оповещается сообщением о найденной ошибке. Подготовка исходного кода агента может вестись не только онлайн в рамках Расширенного редактора агентов (на сайте платформы), но и на оборудовании разработчика с применением некоторой Java 11 IDE. Для этого в данной IDE создаётся проект, куда включается исходный собственный и системный код агента, API платформы и, возможно, байткод повторно используемый пользовательских шаблонов сообщений.

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

Создание исполняемого кода агента

Средствами Редактора агентов необходимо выполнить компиляцию исходного кода текущей версии агента в байт-код (исполняемый код). (Для этого необходимо начать формирование вершины по метавершине "исполняемый код".) С момента успешного формирования исполняемого кода виртуальная машина платформы IACPaaS может активировать данный агент и выполнять код его блоков продукций.

Тестирование и отладка агента

Для функционального тестирования разработанного агента используется Тестировщик агентов, который обеспечивает многократный запуск и выполнение множества блоков продукций агента на заданном множестве тестов, а также формирование и сохранение отчетов о результатах испытаний. Множество тестов для агента формируется с помощью Редактора орграфов информации по метаинформации Структура тестов агента. Тест для агента, в общем случае, есть четверка: test = <inMsg, {testOutMsg₁, …, testOutMsg_k}, {modifIr₁, …, modifIr_n}, {testModifIr₁, …, testModifIr_n}>, k ≥ 0, n ≥ 0, где:

inMsg – входное сообщение для некоторого блока продукций тестируемого агента;
{testOutMsg₁, …, testOutMsg_k} – возможно пустое множество ожидаемых от тестируемого агента выходных сообщений в ответ на входное сообщение inMsg (отсутствуют, если от агента не ожидается никаких сообщений);
readIrs = {readIr₁, …, readIr_l} – возможно пустое упорядоченное множество информационных ресурсов, представляющих читаемые в процессе работы блока продукций тестируемого агента информационные ресурсы (отсутствуют, если агент не читает никаких информационных ресурсов);
modifIrs:
- {modifIr₁, …, modifIr_n} – возможно пустое множество информационных ресурсов, представляющих начальные состояния соответствующих изменяемых тестируемым агентом информационных ресурсов в процессе работы блока его продукций (отсутствуют, если агент не модифицирует никаких информационных ресурсов);
- {testModifIr₁, …, testModifIr_n} – возможно пустое упорядоченное множество информационных ресурсов, представляющих ожидаемые конечные состояния, в которых окажутся соответствующие изменяемые информационные ресурсы в результате работы блока продукций тестируемого агента (отсутствуют, если агент не модифицирует никаких информационных ресурсов).
readOwnIrs = {readOwnIr₁, …, readOwnIr_m} – возможно пустое упорядоченное множество информационных ресурсов, представляющих собственные читаемые в процессе работы блока продукций тестируемого агента информационные ресурсы (отсутствуют, если агент не читает никаких собственных информационных ресурсов);
modifOwnIrs:
- {modifOwnIr₁, …, modifOwnIr_o} – возможно пустое множество информационных ресурсов, представляющих начальные состояния соответствующих собственных изменяемых тестируемым агентом информационных ресурсов в процессе работы блока его продукций (отсутствуют, если агент не модифицирует никаких собственных информационных ресурсов);
- {testModifOwnIr₁, …, testModifOwnIr_o} – возможно пустое упорядоченное множество информационных ресурсов, представляющих ожидаемые конечные состояния, в которых окажутся соответствующие изменяемые собственные информационные ресурсы в результате работы блока продукций тестируемого агента (отсутствуют, если агент не модифицирует никаких собственных информационных ресурсов).
tempIrs:
- {tempIr₁, …, tempIr_p} – возможно пустое множество информационных ресурсов, представляющих начальные состояния соответствующих временных тестируемым агентом информационных ресурсов в процессе работы блока его продукций (отсутствуют, если агент не работает с временными информационными ресурсами);
- {testTempIr₁, …, testTempIr_o} – возможно пустое упорядоченное множество информационных ресурсов, представляющих ожидаемые конечные состояния, в которых окажутся соответствующие временные информационные ресурсы в результате работы блока продукций тестируемого агента (отсутствуют, если агент не работает с временными информационными ресурсами).

Тест считается успешно пройденным, если:

количество и содержимое ожидаемых сообщений testOutMsg_i (i = 1, …, k) совпало с количеством и содержимым соответствующих сообщений, которые тестируемый агент послал в результате работы блока продукций – outMsg_i (i = 1, …, m), k = m;
содержимое изменяемых в процессе работы блока продукций информационных ресурсов совпало с ожидаемым содержимым соответствующих информационных ресурсов.

Для просмотра отчетов о результатах испытаний и журналов используется Редактор орграфов информации (в режиме просмотра). Журнал работы агента на конкретном тесте присоединяется к отчету и также доступен для просмотра. Журналирование применяется для получения информации о том, какие события и в какой последовательности происходят во время работы блоков продукций агента, а также для того, чтобы локализовать место возникновения ошибки. Сформированные наборы тестов могут использоваться для регрессионного тестирования в процессе сопровождения агента.

Ввод агента в эксплуатацию

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

Разработка шаблонов сообщений

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

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

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

По аналогии с агентом, шаблон сообщений состоит из двух частей – декларативной и процедурной и представляет собой кортеж: msgTemplate = <name, internal_name, descr, [message_structure], src_code, code>, где:

name – название шаблона сообщений на естественном языке, отображаемое всем авторизованным пользователям платформы IACPaaS при просмотре ими содержимого Фонда через Административную систему.
internal_name – внутреннее имя шаблона сообщений, которое используется в качестве префикса в имени класса шаблона сообщений при генерации заготовки его исходного кода.
descr – содержательное описание назначения шаблона сообщений на естественном языке, включающее, возможно, описание семантики содержательной информации, передаваемой в сообщениях по данному шаблону, а также, возможно, перечисление единиц хранения Фонда, ссылки на которые (как на фрагменты повторно используемой информации) могут в таких сообщениях содержаться. Данное описание помещается в исходный код класса шаблона сообщений в качестве комментария к нему и ориентировано на разработчиков агентов и сопровождающих шаблона сообщений. Также это описание доступно всем авторизованным пользователям платформы IACPaaS при просмотре содержимого Фонда через Административную систему.
message_structure – описание структуры (синтаксиса языка представления) содержательной информации, передаваемой в сообщениях, формируемых по данному шаблону (содержимого сообщений) – в случае, когда шаблон сообщений описывает не просто сообщения-команды, а сообщения, которые должны содержать некоторые данные.
src_code – исходный код шаблона сообщений (java-код), входящий в состав его процедурной части, и состоящий из множества {src_code_v1, ... src_code_vN} - множества версий, одна из которых является текущей. В случае, когда шаблон сообщений описывает сообщения, которые должны содержать некоторые данные, этот код содержит методы обработки содержимого сообщений, которые реализуют семантику языка его представления.
code – исполняемый код шаблона сообщений (байт-код), входящий в состав его процедурной части (отсутствует до тех пор, пока исходный код шаблона сообщений не разработан, не выбрана и не скомпилирована его еткущая версия).

В существующих передовых стандартах построения мультиагентных систем, предлагаемых такими организациями как FIPA, KAoS и OMG, языки коммуникации агентов (ACL, KQML) обладают плоской (горизонтальной) структурой. Они позволяют описывать сообщения, посредством которых агенты взаимодействуют между собой, в виде множества пар имя параметра = значение параметра. Значением параметра при этом может быть объект со сколь угодно сложной структурой (описываемый на языке представления этого объекта). Расширение этих языков состоит в наращивании числа используемых параметров, многие из которых объявляются необязательными к использованию при описании сообщений. Таким образом, разработчики стандартов пошли по пути создания и совершенствования одного универсального языка, в котором предпринимаются попытки учесть всевозможные ситуации взаимодействия агентов. Однако такой подход ведет к повышению избыточности языка и вместе с тем – к снижению его выразительности ввиду того, что параметры, равно как и их значения, рассматриваются независимо друг от друга.

Вместе с тем практика разработки и развития формальных языков показывает, что:

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

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

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

Агенты взаимодействуют между собой на разных языках, количество которых расширяемо (за счет добавления в агенты новых блоков продукций) и ограничено лишь общим количеством шаблонов сообщений в Фонде платформы IACPaaS. Конкретные языки взаимодействия агентов (шаблоны сообщений) фиксируются на уровне отдельных блоков продукций. Таким образом, множество языков, на которых описаны сообщения, которые агент может принимать, определяется множеством шаблонов входных сообщений для всех его блоков продукций, а множество языков, на которых описаны сообщения, которые агент может отправлять – множеством, в которое включаются разные шаблоны выходных сообщений для всех его блоков продукций. Интеграция языков выполняется динамически – средствами виртуальной машины платформы IACPaaS в процессе взаимодействия агентов друг с другом.

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

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

Формирование информационного ресурса шаблона сообщений

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

Создание с использованием Административной системы в фонде пользователя платформы IACPaaS нового информационного ресурса (с названием, совпадающим с названием шаблона сообщений, и пустым содержимым), представляющего декларативную спецификацию разрабатываемого шаблона сообщений (указывается тип ЕХ Шаблон сообщений).
Формирование содержимого созданного информационного ресурса с использованием сервиса Редактор шаблонов сообщений, в котором процесс редактирования управляется метаинформацией Структура шаблона сообщений.

Специфицирование шаблона сообщений состоит в задании:

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

Создание версии исходного кода шаблона сообщений

После того, как декларативная часть разрабатываемого шаблона сообщений описана (или модифицирована), средствами Редактора шаблонов сообщений можно приступить к формированию версии его исходного кода (на языке Java) одним из 2 способов:

генерация исходного кода версии на основе заготовки, формируемой по декларации ШС (формируется заготовка собственного кода);
генерация исходного кода версии на основе кода иной версии ШС.

При генерации заготовок исходного кода проверяется полнота декларативного описания ШС. Если декларативное описание не полно, то разработчику отображается сообщение, локализующее соответствующее место в описании.

Написание исходного кода шаблона сообщений

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

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

При написании исходного кода (и далее при создании исполняемого) можно выполнять проверку кода ШС и используемых в нем внутренних классов (если они есть) на корректность с точки зрения его выполнения на виртуальной машине платформы. Если код не корректен или не безопасен, то разработчик оповещается сообщением о найденной ошибке. Отметим, что код ШС может только образаться к содержимому инфоресурса сообщения, если в качестве параметра caller будет указано this - объект, представляющий сообщение.

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

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

Создание исполняемого кода шаблона сообщений в Фонд

Средствами Редактора шаблонов сообщений необходимо выполнить компиляцию исходного кода текущей версии ШС в байт-код (исполняемый код). (Для этого необходимо начать формирование вершины по метавершине "исполняемый код".) С этого момента виртуальная машина платформы IACPaaS может создавать сообщения по данному шаблону, осуществлять их диспетчеризацию и своевременное удаление.

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

Ввод шаблона сообщений в эксплуатацию

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

Разработка интерфейса

Общие сведения о разработке интерфейса интеллектуального сервиса

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

web-страница интерфейса, служит для группового размещения различных визуальных объектов (текст с гиперссылками, изображения, таблицы, и т.п.), а также дополнительно подключаемых модулей (JavaScript файлов). Процессор пользовательского интерфейса (ППИ) платформы IACPaaS интегрирован в web-сайт платформы.

Пользовательский web-интерфейс сервиса может быть представлен тройкой вида: UI = <a_ui, {web_page₁, …, web_page_n}, {resource₁, …, resource_m}>, n ≥ 1, m ≥ 0, где:

a_ui – агент Интерфейсный контроллер;
{web_page₁, …, web_page_n} – множество web-страниц на web-сайте платформы IACPaaS, одна из которых должна быть указана в качестве стартовой при интеграции решателя задач с пользовательским интерфейсом;
{resource₁, …, resource_m} – множество ресурсов (изображений, js-скриптов), используемых на web-страницах web_page₁, …, web_page_p, p ∈ [0, n], где web_page_j ∈ {web_page₁, …, web_page_n}, j ∈ [0, p] (данный компонент может отсутствовать, если разработка пользовательского интерфейса не предполагает использование ресурсов).

Каждая web-страница web_page_i (i = 1, …, n) есть тройка вида <content_descr, {ui_request₁, …, ui_request_k}, [CSS]>, k ≥ 1, где:

content_descr – описание содержательной части интерфейса сервиса на языке разметки HTML.
{ui_request₁, …, ui_request_k} – непустое множество ui-запросов к агенту Интерфейсный контроллер (a_ui) интегрированного решателя задач разрабатываемого сервиса. Каждый запрос ui_request_j (j = 1, …, k) есть множество пар параметр = значение, среди которых обязательно должна присутствовать пара вида service = "предметная область/раздел/название решателя задач", идентифицирующая интегрированный решатель задач, к агенту Интерфейсный контроллер которого выполняется запрос. Каждый такой запрос с помощью специального тега <ui ... /> встраивается в описание content_descr. Данный тег указывает транслятору языка разметки на то, что необходимо обратиться к ППИ платформы IACPaaS, передав ему параметры запроса, дождаться от него результата (обычно это описание фрагмента содержательной части интерфейса, формируемой соответствующим агентом Интерфейсный контроллер) и поместить его в место расположения данного тега.
CSS – описание таблицы стилей CSS (множества правил CSS), определяющей внешний вид web-страницы – дизайнерскую часть интерфейса сервиса (может отсутствовать, если разработчик решил использовать стандартые стили HTML, или, например, дизайн целиком задаётся в java-скрипте).

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

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

Устройство web-интерфейса сервиса согласуется с моделью представления пользовательского интерфейса сервисов платформы IACPaaS, в основу которой положена концепция “MVC” (Модель-Представление-Контроллер). Ее основополагающий принцип состоит в разделении данных, логики их обработки и способа их представления с целью обеспечения возможности независимого изменения каждого из компонентов. Проекция данной концепции на модель интерфейса сервисов платформы IACPaaS представлена следующим образом.

Модель. Данный компонент включает в себя:
- Модель абстрактного пользовательского интерфейса – информационный ресурс Фонда, представляющий метаинформацию и содержащий описание структуры стандартных интерфейсных элементов (простых и интерфейсных элементов-контейнеров) WIMP-интерфейсов и способа их рекурсивной организации в единую вложенную структуру. Множество информационных ресурсов, представляющих информацию (метаинформацией которых является информационный ресурс Модель абстрактного пользовательского интерфейса) содержательно являются, таким образом, описаниями абстрактных пользовательских интерфейсов.
- Программный интерфейс для формирования абстрактных интерфейсов – набор высокоуровневых функций для создания фрагментов абстрактных интерфейсов. Посредством вызовов этих функций с соответствующими аргументами значительно повышается уровень абстракции, на котором формируется информационный ресурс, представляющий собой описание некоторого абстрактного интерфейса: формирование выполняется не в терминах отдельных вершин и дуг соответствующего орграфа, а в терминах конструирования орграфа из подграфов, каждый из которых есть описание соответствующего интерфейсного элемента или его атрибута. Таким образом, формирование описания нужного (фрагмента) абстрактного интерфейса состоит в построении соответствующей суперпозиции вызовов функций данного программного интерфейса.
Представление. Данный компонент представлен системным агентом платформы Вид, который является составной частью ППИ платформы IACPaaS. Данный агент (точнее, множество его экземпляров) является гибридным и служит посредником между частью ППИ, реализованной в виде модуля сайта платформы (установленного на web-сервере, который обрабатывает запросы от web-браузера пользователя), с которой взаимодействует Внешне-системная часть агента Вид, и множеством агентов платформы, являющихся Интерфейсными контроллерами в составе решателей задач (посредством посылки им сообщений по шаблону Запрос от агента Вид), с которыми взаимодействует Агентная часть агента Вид. Помимо функции сопряжения сайта платформы и остальной части виртуальной машины платформы IACPaaS в его задачи входит:
- формирование описания конкретного интерфейса (HTML-код) на основе описания абстрактного интерфейса и правил отображения представлений интерфейсных элементов и их атрибутов в терминах модели абстрактного пользовательского интерфейса в их представления на языке HTML;
- обеспечение возможности запуска Java-скриптов^[6] на web-страницах (посредством их подгрузки и исполнения при отображении HTML кода страниц);
- формирование представления информационных ресурсов Фонда (представляющих информацию) в формате JSON для последующей их обработки (в частности Java-скриптами);
- загрузка и выгрузка бинарных данных на web-сервер.
Контроллер. Данный компонент представлен агентами, играющими роль Интерфейсного контроллера в составе различных решателей задач. Эти агенты взаимодействуют с агентом Вид посредством обмена сообщениями по определенным шаблонам и реализуют (взаимодействуя, возможно, с другими агентами решателя задач) логику обработки:
- ui-запросов, размещенных на web-страницах и выполняемых в процессе преобразования описания content_descrв чистый HTML-код (где вместо таких запросов вставлены полученные фрагменты HTML кода);
- событий, генерируемых интерфейсными элементами в ответ на действия пользователей;
- POST-запросов из Java-скриптов.

Результатом обработки является один из трёх возможных объектов:

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

При разработке пользовательского интерфейса сервиса в Фонде должен присутствовать агент Интерфейсный контроллер, который реализует логику обработки следующего:

всех ui-запросов для множества тех web-страниц сервиса {web_page₁, …, web_page_s}, s ∈ [1, n], на которых они присутствуют ({web_page₁, …, web_page_s} ⊆ {web_page₁, …, web_page_n});
событий, генерируемых интерфейсными элементами (если таковые присутствуют на web-страницах web_page₁, …, web_page_s);
запросов из Java-скриптов, выполняемых на web-страницах web_page₁, …, web_page_p, p ∈ [0, n] (если разработка пользовательского интерфейса предполагает разработку Java-скриптов).

Агент Интерфейсный контроллер может быть повторно используемым, например, в том случае, если у сервисов одинаковые с точки зрения структуры и поведения интерфейсы, но различный дизайн. Для этого на web-страницах решателя необходимо использовать разные таблицы стилей CSS (с одноименными CSS-классами).

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

Порядок разработки интерфейса интеллектуального сервиса

Разработка пользовательского интерфейса состоит из следующих шагов.

Создание с помощью редактора решателей задач в инфоресурсе, представляющем решатель, множества web-страниц {web_page1, …, web_pagen}, n ≥ 1 и формирование содержимого каждой web_pagei (i = 1, …, n) страницы следующим, в общем случае, образом:
- задать имя web-страницы;
- описать её содержимое на языке разметки HTML с размещением в нужных местах ui-тегов вида <ui параметр₁ = значение₁ … параметр_m = значение_m />;
- если необходимо определить собственные стили оформления элементов интерфейса, то внутрь блока {{#css: ...}} поместить описание таблицы стилей CSS, определяющей внешний вид web-страниц – дизайнерскую часть интерфейса сервиса.(Возможно также выполнить описание такого блока целиком на отдельной web-странице имя_css_страницы, а затем использовать его в рамках некоторых web-страниц с помощью помощения в их содержимое выражения {{имя_css_страницы}}).
Разработка по технологии, описанной в разделе Разработка агентов решателя задач, агента Интерфейсный контроллер (если в Фонде отсутствует подходящий для этого агент), процедуржная часть которого содержит:
- Java код, отвечающий за обработку размещенных на web-страницах ui-запросов и событий, генерируемых интерфейсными элементами;
- Java-скрипты {js₁, …, js_m}, выполняемые на web-страницах web_page₁, …, web_page_p, где p ∈ [0, n] и web_page_j ∈ {web_page₁, …, web_page_n}, j ∈ [0, p] – если разработка пользовательского интерфейса предполагает разработку Java-скриптов.

Исходный код Java-скрипта сохраняется в *.js файле. Такой файл, а также используемые им ресурсы (графические файлы и т.п.) в начале необходимо поместить в архив zip, а затем загрузить его в платформу (с помощью редактора агентов), где они размещается по заданному пути на web-сервере. При построении интерфейса агентом эти файлы будут закружены в браузер из этой локации.

Расширение набора интерфейсных элементов платформы

Набор интерфейсных элементов в модели интерфейса сервисов платформы IACPaaS является расширяемым. Добавление нового элемента состоит в добавлении:

в Модель абстрактного пользовательского интерфейса – декларативного описания (в виде орграфа метаинформации) структуры интерфейсного элемента;
в Программный интерфейс для формирования абстрактных интерфейсов – функции, формирующей декларативное представление (в виде орграфа информации) интерфейсного элемента – как фрагмента информационного ресурса, представляющего описание абстрактного интерфейса;
в агент Вид – реализации правила отображения декларативного представления интерфейсного элемента в его представление на языке HTML.

Выделение в структуре web-страниц содержательной и дизайнерской частей интерфейса позволяет:

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

Примечания

↑ содержимое выходных информационных ресурсов может быть пустым (см. раздел Разработка информационных ресурсов)
↑ Если содержимое информационного ресурса ig* должно формироваться (по метаинформации mg*) другим сервисом, у которого ig* должен быть указан в качестве выходного фактического параметра, то данный этап пропускается
↑ Агент, у которого присутствует локальная структура данных “рассматривается” процессором решателей задач как агент-экземпляр. Аналогами понятий “агент” и “агент-экземпляр” являются соответственно понятия “класс” и “объект” в объектно-ориентированной парадигме программирования
↑ Среди классов в jar- или zip-архиве присутствует единственный класс-наследник от главного класса заготовки с именем <внутреннее имя агента>, в этом единственном классе-наследнике переопределены все методы void runProduction(…), соответствующие блокам продукций агента и т.п.
↑ Среди импортируемых классов отсутствуют те, используя которые, можно получить доступ к внешним по отношению к платформе IACPaaS сущностям – ОС, файловой системе, СУБД, сокетам и т.п.
↑ Под запуском Java-скриптов понимается исполнение js-файлов, URL которых на web-сервере указываются в формируемом HTML-коде.