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

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

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

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

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

Фаза детального проектирования включает также рассмотрение взаимодействия акторов и их поведения. Для их представления можно применить языки взаимодействия агентов FIPA-ACL или KQML, и их механизмы транспортировки сообщений.

Для построения всех представленных выше моделей можно воспользоваться агентным расширением языка UML (Agent UML).

Таким образом, методология Тropos рассматривает АОС в совокупности дополняющих друг друга аспектов: социального, ментального, коммуникативного, процессно-ориентированного, объектно-ориентированного.

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

Методология Тropos на текущем этапе своего развития не предназначена для разработки сложных АОС, требующих особых механизмов рассуждений для построения планов, определения задач и типов взаимодействий.

В последние годы расширяется класс методологий проектирования АОС, комбинирующих объектно-ориентированные и организационные подходы. Методология PASSI расшифровывается как «процесс для спецификации и реализации агентных сообществ» (Process for Agent Societies Specification and Implementation). Она является результатом длительного периода теоретических исследований и экспериментов в области робототехники.

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

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

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

– функциональное описание процесса использования системы в виде диаграмм вариантов использования;

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

– идентификация ролей через серию диаграмм последовательностей;

– спецификация задач каждого агента с использованием диаграмм деятельности.

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

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

– описание ролей: диаграмма классов используется для того, чтоб показать роли, которые играют агенты, возможности для взаимодействия и межагентные зависимости;

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

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

Модель программного кода предусматривает генерацию кода из моделей с использованием инструментария PASSI и повторно используемых фрагменты реализации методов, с возможностью корректировки кода «вручную».

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

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

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

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

– возможность отражения многих аспектов функционирования сложной системы;

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

Авторы методологии работают над улучшением инструментария PASSI и увеличением библиотеки шаблонов кода.

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

Методология Prometheus состоит из трех основных фаз (рис.8).

Рис.8. Фазы проектирования в методологии Prometheus

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

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

Вторая фаза – «Проектирование архитектуры» предусматривает следующие действия:

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

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

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

Третья фаза – «Детальное проектирования» состоит из следующих действий:

– разработка внутренней архитектуры агентов в терминах возможностей, с учетом планов, событий и данных;

– разработка диаграмм обработки информации на основе протоколов взаимодействия.

Методология Prometheus предоставляет два средства автоматизации труда проектировщика МАС. Первое средство – это инструмент проектирования Prometheus (Prometheus Design Tool), который позволяет разрабатывать все виды описанных выше диаграмм и строить по ним отчеты. Функциональность PDT постоянно расширяется, инструмент является свободно распространяемым.

Второй инструмент, поддерживающий методологию Prometheus – это среда разработки Jack (JACK Development Environment), которая предоставляет возможности для рисования обзорных диаграмм в стиле методологии Prometheus. На основе этих диаграмм среда позволяет сгенерировать скелет программного кода и следить за тем, чтоб изменения, произведенные в коде, отображались и на диаграммах.

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

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

Prometheus также не поддерживает мобильность агентов, так как авторы методологии считают, что это свойство не является основным для ИА. Такие фазы разработки как реализация, тестирование и отладка в этой методологии поддерживаются достаточно ограниченно. Еще одна особенность методологии – отсутствие поддержки UML. С одной стороны это хорошо, т.к. не привязывает проектировщика к объектно-ориентированной парадигме, а с другой стороны, это не дает множеству программистов воспользоваться инструментом, с которым они хорошо знакомы.