Агентно-ориентированные системы искусственного интеллекта

где Parai, Parbi – значения признака для агентов a и b соответственно, а индекс i – пробегает множество { S1 S2 M1 M2 M3 M4 T1 T2 T3 }. 

Для примера вычислим интеллектуальное расстояние между амебой и традиционным конечным автоматом с несколькими входами и выходами. Для амебы кодовая комбинация принимает вид: a = 100000000, а для конечного автомата – b = 111000000, тогда ID(a, b) = 2.

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

определяемый суммой значений параметров от S1 до T3. Соответственно, для мобильного транспортного интеллектуального робота мы получим IW = 6 (a = 1110100101), а для человека – IW = 12 (b = 112111122). Интеллектуальное расстояние между ними равно ID(a, b) = 6, что и отражает интеллектуальное превосходство человека.

Таблица 3

Сенсорика (чувства)	S1	0	С одним чувством
		1	С несколькими чувствами
	S2	0	Только одно из многих чувств в данной ситуации
		1	Множественные чувства на единичный объект, событие или ситуацию
Память	M1	0	Без памяти
		1	С памятью на прошедшие события (конечной)
		2	С потенциально неограниченной или бесконечной памятью
	M2	0	Только с кратковременной памятью
		1	С кратковременной и долговременной памятью
	M3	0	Не может обучаться (не наращивает долговременную память)
		1	Может обучаться (наращивает долговременную память)
	M4	0	Хранит сенсорную информацию по некоторому чувству
		1	Хранит сенсорную информацию по всем чувствам
Моторика (действия во времени)	T1	0	Действует только в реальном времени
		1	Может планировать действия
	T2	0	Не может визуализировать чувства
		1	Может визуализировать некоторые чувства
		2	Может визуализировать все чувства
	T3	0	Не имеет модели среды существования
		1	Имеет предопределенную модель
		2	Может создавать ментальные модели среды

 

Для агентно-ориентированных систем может быть введено понятие среднего веса ИА в системе где n – число ИА в МАС, а IWi – вес i-го ИА.

 

Рис. 2. Классификация МАС

2. Методы построения агентно-ориентированных систем.

Методологии проектирования АОС все еще находятся в начальной стадии развития. Известные подходы можно разделить на четыре основных класса:

– базирующиеся на объектно-ориентированных методах и технологиях с использованием соответствующих расширений;

– использующие традиционные методы инженерии знаний;

– основанные на организационно-ориентированных представлениях;

– комбинирующие в различной степени методы трех первых классов.

На рисунке 3 показано взаимное влияние наиболее известных на данный момент агентно-ориентированных методологий.

Рис.3. Взаимное влияние АОМ

В методологиях первого класса разрабатываются расширения объектно-ориентированных методологий и технологий для проектирования АОС.

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

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

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

Рис. 4. Дополнительные обозначения для АОС

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

В рамках методологии определены следующие модели (рис. 5).

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

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

Рис. 5. Взаимодействие моделей в методологии MAS-CommonKADS

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

Основным отличием этой методологии от других является то, что разрабатываемая АОС рассматривается с различных точек зрения. Разработчик получает описание, позволяющее выполнять реализацию на различных программных платформах. Сильной стороной методологии принято считать использование стандартных методов инженерии программного обеспечения, которые расширяются естественным способом. MAS-CommonKADS создавалась в расчете на многоразовое использование материалов, полученных на каждом уровне проектирования, что дает возможность использования данных из других проектов. Главный недостаток этой методологии – слабая поддержка этапов проектирования, тестирования и кодирования.

Gaia– это методология агентно-ориентированного анализа и проектирования, явно использующая организационную точку зрения (рис.6). Наиболее абстрактной сущностью в иерархии концептов Gaia является «система». Хотя термин «система» используется в стандартном смысле, он также означает «сообщество» или «организацию».

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

Рис. 6. Базовые концепты методологии Gaia

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

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

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

Ограничения и недостатки методологии Gaia проявляются в следующем:

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

- трудно  выразить реальную иерархическую  структуру корпоративных и производственных систем, «роли» как бы предполагают однородность функционального или задачного пространства;

- нет градации  агентов по уровням интеллектуальной иерархии, что предполагает интеллектуальную однородность агентов, а это далеко не так в сложных системах;

- организационная  структура системы статична, т.е. ни число агентов, ни их отношения не изменяются в текущем времени;

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

Достаточно оригинальная методология проектирования МАС, основанная на концепции М-архитектуры, развивается в работах коллектива польских ученых во главе с K. Cetnarowicz.

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

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

- модель  усложняется и дополняется новыми  свойствами по мере продвижения  от верхних уровней к нижним, новые свойства вводятся в  рассмотрение;

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

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

Анализ требований в Тropos делится на две стадии – ранний анализ и поздний анализ. Ранний анализ сосредоточен на изучении среды, в которой АОС будет функционировать. Поздний анализ описывает функциональные и нефункциональные требования к системе.

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

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