Перевод статьи The Gaia Methodology for Agent-Oriented Analysis and Design Wooldridge, Jennings, Kinny

Перевод статьи «The Gaia Methodology for Agent-Oriented

Analysis and Design» Michael Wooldridge, Nicholas R. Jennings, David Kinny

URL: http://citeseer.ist.psu.edu/article/wooldridge00gaia.html

GAIA-МЕТОДОЛОГИЯ ДЛЯ АГЕНТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ

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

Ключевые слова: агенто-ориентированная, инженерное программное обеспечения, методологии, анализ и проектирование

1. Введение

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

Процедурная абстракция, абстрактные типы данных, и, сравнительно недавно появившиеся , объекты и компоненты - это все примеры таких абстракций.

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

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

важный класс комплекса распределенных систем.

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

Существующее техника разработки программного обеспечения (например, объектно-ориентированный анализ и проектирование [2, 6]) не подходят для этого. Существует принцип несоответствия между понятиями, используемыми в объектно-ориентированном программировании (и другими основными направлениями) и агентно-ориентированным типом [32-34].

В частности, неявные подходы не в состоянии соответствующе захватить гибкость агента,

автономное решение поведенческих проблем, большое число взаимодействий агента, и

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

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

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

Gaia. В главе 2 приведены основные понятия, используемые в Gaia.

Агентно-основанный анализ обсуждается в главе 3, и проектирование в главе 4. Использование Gaia иллюстрировано в примере для изучения главе 5, где показано, как можно применять Gaia к проектированию настоящей системы, основанной на агентах для управления бизнес- процессами. Такая же работа обсуждается в главе 6, и некоторые заключения подведены в разделе 7.

Особенности области

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

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

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

· Предполагается, цель - получить систему, которая максимизирует некоторую глобальную качественную меру, но которая может быть sub-оптимальна с точки зрения компонент системы. Gaia не используется для систем, в которых допускается возможность истинного конфликтования

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

· Организация Структуры системы - статична, то есть взаимоотношения между агентами не изменяются во время выполнения.

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

· Полная система содержит сравнительно мало различных типов агентов (менее чем 100).

В Gaia используются понятия макрокоуровня (общество) и микроуровня (агент)

. Это является преимуществом над предыдущими агентно-ориентированными методологиями.

2. Концептуальная структура

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

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

. В применении Gaia, движения аналитика от

Рисунок 1. Взаимоотношения между моделями Gaia

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

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

Главные модели, используемые в Gaia, приведены на Рисунке 1

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

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

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

Главные понятия Gaia можно разделить на две категории: абстрактные и конкретные;

абстрактные и конкретные понятия приведены в Таблице 1. Абстрактные понятия

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

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

3. Анализ

Задача стадии анализа - разработать понимание системы

и ее структуры (без ссылки на любую деталь выполнения). В нашем случае, это

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

Рисунок 2.

Таблица 1. Абстрактные и конкретные понятия в Gaia

Абстрактные понятия	Конкретные понятия
роли	Типы Агентов
разрешения	сервисы
обязанности	знакомства
активность
протоколы
Свойства жизнеспособности
Свойства безопасности

Рисунок 2. Анализ понятий.

Самая абстрактная сущность в иерархии понятия - это система. Хотя термин

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

Это то, что мы думаем об агентно-основанной системе как искусственном обществе или организации

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

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

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

Пример человеческой организации - типичной компании.

Компания имеет роли, как например «президент», «вице-президент» и т.д.

Отметим, что в конкретном представлении компании, эти роли будут подтверждены

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

несколько ролей. С другой стороны, несколько индивидуумов могут взять на себя одну роль, например, «продавец».

Роль определена четырьмя свойствами: обязанности, разрешения, активность и

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

свойствами, связанными с ролью. Пример обязанностей, связанных с ролью:

президент компании может вызывать акционеров на заседание каждый год. Обязанности делятся на два типа: свойства жизнеспособности и свойство безопасности

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

через все состояния выполнения). Пример «гарантия реактора температур всегда остается в пределах 0-100.»

Для того, чтобы выполнять обязанности, роль имеет набор разрешений. Разрешения

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

ресурсами. Например, роль можно связать с такой способностью, как прочитать

специфический элемент информации, или изменить часть информации. Роль может генерировать информацию.

Активность роли - это вычисления, связанные с ролью, которые могут быть

выполнены агентом без взаимодействия с другими агентами. Активность это «частное» действие.

Наконец, роль есть также неопределенный набор протоколов, которые определяют путь

возможного взаимодействия с другими ролями. Например, роль «продавец» может иметь протоколы «голландский аукцион» и «английский аукцион», которые связаны с ним; Контракт

Сетевой Протокол связан с ролями «управляющего» и «подрядчика» [30].

Поэтому, модель организации в Gaia представлена в двух следующих моделях:

ролевая модель (раздел 3.1) и

модель взаимодействия (раздел3.2).

3.1. ролевая модель

Ролевая модель определяет ключевые роли в системе. Здесь роль может рассматриваться

как абстрактное описание ожидаемой функции сущности

Такие роли отличаются двумя типами свойств:

· Разрешения/права, связанные с ролью.

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

· Обязанности роли.

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

Эту функциональность определяется свойством Обязанности роли.

Разрешения. Разрешения, связанные с ролью, имеют два аспекта:

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

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

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

В о, разрешения могут коснуться любого вида ресурса. В человеческой организации

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

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

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

Процедура является простой иллюстрацией разрешений, связанных с ролью

НаполнительКофе:

читать coffeeStatus // полный или пустой

изменять coffeeStock // текущий уровень кофе

Эта спецификация определяет два разрешения для НаполнительКофе: это означает, что агент

исполняя роль, имеет доступ к значению coffeeStatus, и имеет разрешение

на чтение и модификацию значения coffeeStock. Имеется также третий тип

разрешения, генерирует, который указывает, что роль - это производитель

(не показано в примере). Отметьте, что эти разрешения касаются знаний, которые имеет

агент. Это значит, что coffeeStatus является представлением на части агента

некоторое значение в настоящем мире.

Некоторые роли параметризуются определенными значениями. Например, мы можем

роль НаполнительКофе связать с определенной машиной кофе. Это определяется ключевым словом поставляемый.

читать поставляемый coffeeMaker // имя машины, делающей кофе

coffeeStatus // полнее или пустой

изменять coffeeStock // текущий уровень кофе

Обязанности. Функциональность роли определяется ее обязанностями. Эти

обязанности делятся на две категории: жизнеспособности и безопасности.

Обязанности жизнеспособности - это те обязанности, которые, интуитивно, определяют что «что-то хорошее случится». Обязанности названы жизнеспособными также, потому что они стремятся определить что «что-то хорошее будет сделано», и с этого момента, агент, исполняющий роль, будет жить. Обязанности жизнеспособности следуют определенным образцам. Например, гарантированный вид ответа для достижения цели имеет следующую форму: «за запросом всегда следует ответ», другая интерпретация цели: «х происходит неопределенно часто» Эти виды требований широко изучаются в инженерной литературе по программному обеспечению, где они, оказались необходимы для реализации свойств реагирующих систем [27].

Для того чтобы иллюстрировать различные понятия, связанные с ролями, продолжим

пример запуска роли НаполнительКофе. Примеры обязанностей жизнеспособности

для роли НаполнительКофе:

_ когда горшок кофе пуст, наполнить его;

_ когда свежий кофе варится, убедиться, что работники знают об этом.

В Gaia, свойство жизнеспособности конкретизировано через выражение жизнеспособности, которое определяет жизненный цикл роли.

Выражение жизнеспособности подобны выражению жизненного цикла

fusion [6], которая является по существу регулярными выражениями. Наши выражения жизнеспособности

имеют дополнительный оператор «w»,о для бесконечных повторений (см. Таблицу 3.1).

Они поэтому имеют сходство w-regular выражения, которые подходят

для представления свойств бесконечных вычислений [32].

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

общая форма выражения жизнеспособности:

RoleName = Выражение

где RoleName - имя роли, свойства жизнеспособности которой определяются и Выражение – выражение жизнеспособности, определяемое свойствами жизнеспособности RoleName

элементарные компоненты выражения жизнеспособности- это любые активности

или протоколы. Активность – что-то подобное методу в объектно-ориентированных терминах, или

процедуре на pascal-подобном языке. Это соответствует единице действия, выполняемого

Таблица 2. Операторы для выражения жизнеспособности

Интерпретация	Оператора
x ×y	x следует за y
x\|y	x или y реализовывается
x*	х реализовывается 0 или больше раз
х+	х реализовывается 1или больше раз
x^w	х реализовывается бесконечно часто
[х]	х необязателен
x\|\|y	X параллельно y

агентом, не взаимодействуя с любым другим агентом. Протоколы

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

Для большей читаемости имена протоколов обозначаются (ххх), а имена активностей (ууу)

иллюстрация выражения жизнеспособности, с учетом вышеприведенных обозначений для

роли НаполнительКофе:

НаполнительКофе = (Наполнить.Сообщить работникам.Текущий уровень.Ждать пустой)^w

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

Последовательное выполнение этих протоколов и активности является

затем повторяется бесконечно часто. В данный момент мы используем протоколы просто как обозначения (не определяются)

(это будет обсуждаться в разделе3.2)

Комплексные выражения жизнеспособности для также может быть представлено как следующая структура:

НаполнительКофе =(All)^w

All= Наполнить.Сообщить работникам.Текущий уровнь.Ждать пустой

Семантика такого выражения определяется простой текстовой заменой.

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

Это потому что агент, исполняющий роль, будет требовать поддержки

определенных инвариантов во время выполнения. Например, мы можем требовать, чтобы определенный

агент, принимающий участие в электронном приложении торговли, никогда не тратит больше денег

чем это определено. Эти инварианты - это условия безопасности, так как

они обычно определяют отсутствие некоторого нежелательного условия.

Требования безопасности в Gaia конкретизируются с помощью списка предикатов. Эти

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

В роли НаполнительКофе: агент, исполняющий эту роль, будет

в общем, требовать гарантии, что что-то будет всегда. Мы можем определить это

с помощью выражения безопасности:

_ coffeeStock > 0

Схема роли:

имя роли

Описание

Протоколы и Активности

Разрешения

Обязанности

жизнеспособность

безопасность

Краткое е описания роли

Протоколы и Активности, в которых участвует роль

«права», ассоциированные с ролью

обязанность жизнеспособности

обязанность безопасности

Рисунок 3. Шаблон для схемы роли.

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

эти обязанности применяют во всех состояниях выполнения системы. Если роль - неопределенно

длинная продолжительность (как в примере НаполнительКофе), то инварианты

всегда должны соответствовать действительности.

Теперь можно определить роли в Gaia модели. Роли модели – список схем ролей, одна для каждой роли в системе. Schema роли

задается вместе с различными свойствами, описываемыми выше (Рисунок 3).

образец для роли НаполнительКофе на Рисунке 4.

Эта схема показывает, что НаполнительКофе имеет разрешение читать параметры coffeeMaker

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

coffeeStatus (который указывает полна машина или пуста). Кроме того

роль имеет разрешение изменять значения coffeeStock.

3.2. Модель взаимодействия

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

один для каждого вида взаимодействия между ролями. Здесь протокол рассматривается как

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

.Просмотр взаимодействий, в этом случае, означает, что внимание сосредоточивается на

весьма важная целях взаимодействия, чем на точной последовательности обмена сообщений

(cм. диаграммы взаимодействия объектов [6 с. 198-203] или сценарии fusion [6]).

Этот подход означает, что единый определенный протокол обычно порождает

целый ряд обменов сообщениями в системе в ходе выполнения. Например, рассмотрим

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

Схема роли:

НаполнительКофе

Описание:

эта роль гарантирует уверенность, что чайник кофе полон и информирует работников, о том, что кофе готов

Протоколы и Активность:

Наполнить,Сообщить работникам,Проверить уровень,Ждать пустой

Разрешения:

Читать coffeeMake // имя coffeeMaker

coffeeStatus // наполнен или пуст

Изменять coffeeStock //текущий уровень кофе

Обязанности:

жизнеспособность

НаполнительКофе = (Наполнить.Сообщить работникам.Текущий уровень.Ждать пустой)^w

безопасность:

coffeeStock > 0

Рисунок 4 Схема для роли НаполнительКофе.

Однако в стадии анализа, такие точные детали являются ненужными и слишком преждевременными.

Определение протокола состоит из следующих свойств:

· цель: краткое текстовое описание взаимодействия (например, информационный запрос, планируемая активность, назначенное задание);

· инициатор: роль(и), отвечающая за начинание взаимодействия;

· ответчик: роль(и), с которой инициатор взаимодействует;

· входы: информация, используемая инициатором во время задания протокола;

· выводы: информация, поставляемая к ответчику или ответчиком во время взаимодействия;

· обработка: краткое текстовое описание любой обработки протокола инициатором, выполненной во время взаимодействия.

Пример- протокол учета наполняемости в НаполнительКофе

(Рисунок 5). Этот протокол инициируется НаполнительКофе побуждает CoffeeMachine.

Протокол побуждает НаполнительКофе положить кофе в машину coffeeMaker и результаты CoffeeMachine будут информировать о уровне coffeeStock.

3.3. Процесс анализа

Стадии анализа Gaia:

Рисунок 5. определение протокола Наполнения

1. Определить роли в системе. Ролям в системе будут обычно соответствовать:

· индивидуумы, в пределах организации или независимые;

· отделы организации; или

· организации непосредственно.

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

2. Для каждой роли, определить и документировать связанные протоколы. Протоколы -

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

предложением цены другому агенту в роли Торговца.

Вывод: Модель взаимодействия, которая соответствует образцам взаимодействия.

3. Использование модели протокола как основы для детальной разработки модели.

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

происхождение, их разрешения и обязанности, вместе с

протоколами и активностями, в которых они участвуют.

4. Повтор (1)-(3).

4. Проектирование

Цель «классического» процесса проектирования - преобразование абстрактных моделей,

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

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

будет зависеть от специфичности области применения.

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

агента, которые будут созданы из этих типов.

Обслуживания модели определяют основные обслуживания, которые требуются для реализации роли агента.

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

4.1. модель агента

Цель модели агента Gaia - документировать различные типы агента, которые будут

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

Тип агента - это лучшее представление набора ролей агента. По существу - соответствие между ролями и типами агента. Проектировщик может объединить ряд близко связанных ролей в одном и том же типе агента для удобства. Эффективность также будет крупным беспокойством в этой стадии:

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

решение может быть необходимо – «отпечаток» агента (т.е., его время выполнения представленное в терминах процессорной мощности или

пространства памяти) будет такой большой, что

более рационально объединить ряд ролей в едином агенте, чем определить ряд

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

ролям, (также как в определении ролевой модели), другие узлы соответствуют типам агента.

Если агент типа t1 имеет детей t2 и t3, то это означает, что t1 образован

ролями, которые выполнили t2 и t3.

Документируются экземпляры агента, которые появятся в системе с помощью аннотирования

типов агента в модели агента. n означает, что в исполняемой системе будут определены n типов агентов. m..n означает, что будут определены не менее чем m и не более чем n типов агентов в исполняемой системе. * означает, что будут определены 0 или больше случаев в исполняемой системе, и + означает, что будут определены 1 или более состояний.

Отметим, что наследование не играет никакой роли в агентных моделях Gaia.

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

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

(Конечно, когда это становится актуально для конструирования агентов, наследование может быть использовано для достижения большего эффекта)

4.2. Модель обязанностей

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

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

не каждой обязанности будет соответствовать

активность.

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

свойства. А именно, необходимо определить входы, выводы, начальные условия, и

конечные условия для каждой обязанности. Входы и выводы обязанностей будут получены

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

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

Обязанности, которые агент будет выполнять, получены из списка протоколов

активностей, ответственностей и свойства жизнеспособности роли. Например, вернемся

к примеру кофе, имеются четыре активности и протокола, связанные с

этой ролью: Наполнить.Сообщить работникам.Текущий уровень.Ждать пустой

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

Модель обязанностей Gaia не предусматривает выполнение обязанностей.

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

Альтернативно, услуга может быть представлена рядом методов.

4.3. Ознакомительная модель

Окончательная модель Gaia проектирования - вероятно самая простая: ознакомительная модель.

Ознакомительная модель просто определяет связи, которые существуют между

типами агентов.

Они не определяют какие сообщения будут посланы или когда сообщения будут посланы – они просто определяют возможные связи.

В частности

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

которые могут вызвать проблемы во времени выполнения. Это

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

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

таких проблем.

Ознакомительная модель агента - это просто граф, с узлами, соответствующими типам агентов и дугами, соответствующими связям взаимодействия.

Ознакомительные модели агентов - это направленные графы, Следовательно, дуга a -> b, означает, что a отправляет сообщение b, но не обязательно, что b отправит сообщение a.

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

4.4. Процесс проектирования

Стадия проектирования Gaia может быть представлена:

1. Создание агентной модели:

_ выделить роли в типах агента и сформировать иерархию типа агента;

_ выделить экземпляры каждого типа агента, используя примечания примера.

2. Разработать модель обязанностей, с помощью рассмотрения активностей, протоколов и

свойств безопасности и жизнеспособности роли.

3. Разработать ознакомительную модель из модели взаимодействия и модели агента.