Software & Systems

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

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

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

Формально агент (рис. 2) представляется совокупностью

A=,                                                        (1)

где N – имя агента; M – множество сообщений, которые агент использует для взаимодействия с другими агентами; K – БЗ агента A. В свою очередь,

M={M(I), M(O)},                                                     (2)

где M(I) – множество входящих, а M(O) – множество исходящих сообщений агента.

Пользователи для выполнения своих функций могут использовать справочники, нормативные документы, собственные знания и информацию от других работников. Аналогично и агенты могут использовать собственные базы данных (БД) и БЗ, ИС и ответы на запросы к другим агентам.

Логические взаимосвязи агентов представим в виде ориентированного графа

H=,                                                              (3)

где A – множество агентов системы; R=A×A – множество ребер, соединяющих вершины графа. Ребро r=(ai,aj)ÎR показывает, что агенту aj необходимо получать информацию от агента ai.

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

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

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

С другой стороны, агенты взаимодействуют друг с другом, и схема их логического взаимодействия представляется графом H (3), который можно определить матрицей инцидентности N размера n×n, где n – количество агентов в системе.

,                       (4)

где rij – натуральное число, показывающее количество типов сообщений, которые агент i передает агенту j.

По диагонали матрицы располагаются 0, так как сами с собой агенты не обмениваются сообщениями.

Если Mi(I) – подмножество исходящих сообщений агента Ai, Mi(I)ÍM,Mj(O) – подмножество входящих сообщений агента Aj, Mj(O)ÍM, то

|Mi(I)ÇMj(O)|=rij.                                                    (5)

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

Пусть MG={mi} – глобальное множество сообщений, которыми могут обмениваться агенты. Другими словами, это объединение множеств сообщений всех агентов, то есть

M,                                                    (6)

где n – количество агентов в системе; Mi – множество сообщений, которыми обменивается агент Ai.

Описание каждого сообщения не зависит от агента, хотя новые сообщения в едином реестре регистрирует именно агент. Каждое сообщение mi имеет уникальный идентификатор, в качестве которого удобно использовать GUID (global unique identifier). Идентификатор сообщения определяет его формат и семантическую нагрузку. Выходит, если агенту необходима та или иная информация и он знает, в каком сообщении ее можно получить, то он может запросить у менеджера список всех агентов, которые могут предоставить информацию такого типа, а потом взаимодействовать с ними.

Таким образом, множество сообщений MG представляет «словарь» для общения. Каждый агент пользуется частью такого словаря. С развитием системы словарь будет пополняться.

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

Таблица 1

Структура сообщения

Для построения БЗ агента из нескольких моделей представления знаний – логических, сетевых, продукционных, фреймовых [2] – воспользуемся продукционной моделью. Эта модель интуитивно понятна, что может иметь решающее значение при разработке конкретных агентов. К тому же она использует некоторые элементы логических и сетевых моделей. В продукционных моделях процедурная информация выделена явно [2]. Для БЗ агентов это также важно, потому что он должен действовать, реагировать на события.

Для реализации продукционной БЗ используется три модуля: 1) БД, содержащая факты, данные и т.п.; 2) система продукций, записанная на условном языке; 3) интерпретатор, обрабатывающий продукции.

Формально составляющая К агента из (1) может быть представлена как

K=,                                                     (7)

где DB – БД и база фактов, с которой взаимодействует агент; P={pi} – множество продукций; PI – интерпретатор продукций.

Продукции представляют собой выражения вида [2]

(i); Q; P; AÞB; N,                                               (8)

где i – имя продукции; Q – сфера применения продукции, для экономии времени выделения нужной продукции; AÞB – ядро продукции; P – условие применимости ядра продукции; N – описывает постусловия продукции.

Обычное прочтение ядра выглядит так: «ЕСЛИ А то В», но возможны и другие интерпретации [2]. Они актуализируются только в том случае, если ядро продукции реализовалось.

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

if (<условие>)

{

<действие 1>;

<действие 2>;

…

<действие N>;

} ,

где <условие> ‑ некоторое логическое выражение. Для его вычисления могут использоваться факты БЗ, ответы от других агентов или от пользователя. Таким образом, чтобы обработать правило вывода, может потребоваться запрос к другим агентам. Это аналогично тому, как один работник спрашивает другого при решении какого-либо вопроса. То есть в знаниях агента учитывается не только то, какие данные ему необходимы, но и у кого их можно получить. Во время такого вопроса, активируется другой агент.

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

Для выделения активных продукций и их реализации агент должен обладать интерпретатором продукций. Задачами такого интерпретатора является выбор необходимой продукции из множества и ее выполнение. Причиной активизации агента может служить появление новых фактов в БЗ, некоторое событие, например действия пользователя, вопросы от других агентов. Поскольку менеджер агентов – это среда их существования, то на его базе можно реализовать так называемые «доски объявлений» [1,2]. На них будут выноситься события, происходящие в системе. Таким образом, агенты могут уведомлять друг друга о новых фактах и целях. Реализовав необходимые действия, агент «пишет» на доске новое объявление.

Каждый агент отслеживает изменения во внешней среде, действия своего «хозяина», принимает сообщения от других агентов и от менеджера. После наступления определенного события, интерпретатор продукции должен выбрать все возможные продукции, у которых выполняется условие применимости. Таких продукций может  и не быть, а может оказаться одна или несколько. В последнем случае необходимо выбрать одну из них. В [2] приводятся возможные стратегии управления выполнением продукций. Поскольку для агентов, автоматизирующих работу пользователей, предполагается небольшая система продукций, а продукции достаточно независимы, то подходящей оказывается стратегия по принципу стопка книг [2]. При этом наиболее часто выполняемые продукции перемещаются вверх. При актуализации нескольких продукций выбирается та, частота использования которой максимальна.

В качестве примера использования агентов рассмотрим задачу идентификации объектов карты в муниципальной геоинформационной системе (МГИС) [3]. Как известно, учет прав на землю ведет земельный комитет (ЗК). Однако здесь используется только семантическая информация об объекте учета. Географические данные земельного участка хранятся в цифровой карте города, ведением которой занимается отдел архитектуры и градостроительства (ОАиГ). Для объединения семантических и географических данных необходимо установить взаимосвязи для объекта учета ЗК и ОАиГ [3]. Следует учитывать, что эти организации территориально разнесены и их сотрудники не могут свободно между собой общаться. Проблемы, которые возникают при объединении данных о земельном участке, заключаются в определении момента времени, в который данные о земельном участке внесены в обоих отделах, и в сопоставлении новых объектов учета ЗК географическим объектам ОАиГ, поскольку их в системе может находиться одновременно несколько.

С помощью агентно-ориентированного подхода решение выглядит следующим образом. На рабочие места обоих отделов разрабатываются агенты, которые взаимодействуют между собой. При внесении оператором ЗК нового объекта учета в БД его агент на доске объявлений менеджера оставляет соответствующую запись об этом событии. Аналогично действует и агент пользователя в ОАиГ. Далее один из них, например агент ОАиГ, получив уведомления о появлении в системе новых данных, пытается их сопоставить. Если идентификация проведена успешно, то идентификатор земельного участка БД ЗК присваивается в качестве атрибута соответствующего географического объекта [3]. По завершении этих операций с доски объявлений удаляются оставленные записи.

Здесь продукциями будут реакции агентов на новые объявления. В простейшем случае они будут иметь такой вид: ЕСЛИ ПОЯВИЛИСЬ НОВЫЕ СОБЫТИЯ, ТО ИДЕНТИФИЦИРОВАТЬ ОБЪЕКТЫ.

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

Правило будет иметь вид: ЕСЛИ ВЫЧИСЛЕН НАЯ ПЛОЩАДЬ ГЕОГРАФИЧЕСКОГО ОБЪЕКТА НЕ СОВПАДАЕТ С СОХРАНЕННОЙ В ЗК, ТО УВЕДО МИТЬ ОБ ЭТОМ ПОЛЬЗОВАТЕЛЯ.

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

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

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

1.  Швецов А.Н., Яковлев С.А. Распределенные интеллектуальные информационные системы. – СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2003. – 318 с.

2.  Искусственный интеллект. – В 3-х кн. Кн. 2. Модели и методы: Справочник/ Под ред. Д.А. Поспелова – М.: Радио и связь, 1990. – 304 с.: ил.

3.  Садыков С.С., Симаков Р.А. Автоматизированный способ идентификации объектов карты// Геоинформатика. – 2004. - №2. - С.46-51.