\documentclass[a4paper]{article}

\input{../common-preamble}
\input{../bmstu-preamble}
\input{../fancy-listings-preamble}

\numerationTop

\begin{document}
\fontsize{14pt}{14pt}\selectfont % Вполне очевидно, что мы хотим 14й шрифт, все его хотят
\thispagestyle{empty}
\makeBMSTUHeader

\makeReportTitle{домашней}{}{Методология проектирования МАС}{Мультиагентные интеллектуальные системы}{}{В.Э. Большаков}
\newpage
\thispagestyle{empty}
\tableofcontents
\newpage
\pagestyle{fancy}
\sloppy
\begin{center}
  \Huge MaSE methodology
\end{center}

\section*{Кратко}
MaSE предлагает подробный подход к анализу и разработке мультиагентных систем. MaSE объединяет несколько устоявшихся моделей в комплексную методологию и предоставляет набор шагов, которые показывают, как получить новые модели из существующих. Таким образом, MaSE направляет разработчика в процессе анализа и проектирования. Будущая работа над MaSE будет сосредоточена на его специализации для использования в адаптивных мультиагентных и кооперативных роботизированных системах на основе теоретико-организационного подхода. В настоящее время мы разрабатываем организационную модель, которая предоставит знания, необходимые команде программных или аппаратных агентов для автоматической адаптации к изменениям в их среде, а также для организации и реорганизации для достижения командных целей.

\section{Введение}
В этой главе представлено введение в разработку многоагентных систем (Multiagent Systems Engineering, MaSE), которая представляет собой методологию полного жизненного цикла для анализа, проектирования и разработки гетерогенных МАС (Multi Agent System, MAS). Для этого MaSE использует ряд графических моделей, полученных из стандартных моделей UML, для описания типов агентов в системе и их интерфейсов с другими агентами, а также независимое от архитектуры подробное определение внутренней структуры агента. Основное внимание в MaSE уделяется руководству проектировщиком от первоначального набора требований к анализу, проектированию и внедрению работающей МАС.

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

Авторы статьи также предлагают инструмент agentTool. AgentTool можно бесплатно загрузить с веб-страницы agentTool по адресу http://www.cis.ksu. edu/~sdeloach. AgentTool -- это полностью интерактивный инструмент разработки программного обеспечения с графическим интерфейсом, который полностью поддерживает каждый этап анализа и проектирования MaSE.

\section{Методология}
Методология MaSE является специализацией более традиционных методологий разработки программного обеспечения. Общая работа MaSE следует фазам и шагам, показанным ниже, и использует связанные с этими шагами модели.

Фазы/Модели
\begin{enumerate}
\item Фаза анализа
  \begin{enumerate}
  \item Фиксация целей / Иерархия целей
  \item Применение вариантов использования / Вариантов использования, диаграмма последовательности
  \item Уточнение ролей / Параллельных задач, ролевая
  \end{enumerate}
\item Этап проектирования
  \begin{enumerate}
  \item Создание классов агентов / Диаграммы классов агентов
  \item Построение разговоров / Диаграммы разговоров
  \item Сборка классов агентов / Диаграммы архитектуры агентов
  \item Схемы проектирования / развертывания
  \end{enumerate}
\end{enumerate}
Хотя методология представлена последовательно, на практике она является итеративной. Цель состоит в том, чтобы проектировщик мог свободно перемещаться между шагами и фазами, чтобы с каждым последующим проходом добавлялись дополнительные детали и, в конце концов, создавался полный и непротиворечивый проект системы. Одной из сильных сторон MaSE является возможность отслеживать изменения в течение всего процесса. Каждый объект, созданный на этапах анализа и проектирования, можно проследить вперед или назад по различным этапам до других связанных объектов.

\section{Фаза анализа}
На этапе анализа MaSE создается набор ролей и задач, которые описывают, как система достигает своих общих целей. \textbf{Цели} являются абстракцией подробных требований и достигаются ролями. Как правило, система имеет общую цель и набор подцелей, которые должны быть достигнуты для достижения цели системы. Цели используются в MaSE, потому что они фиксируют то, чего пытается достичь система, и имеют тенденцию быть более стабильными во времени, чем функции, процессы или информационные структуры.

\textbf{Роль} описывает объект, который выполняет некоторую функцию в системе. В MaSE каждая роль отвечает за достижение или помощь в достижении определенных системных целей или подцелей.

Общий подход на этапе анализа MaSE прост: определить системные цели из набора требований, а затем определить роли, необходимые для достижения этих целей. Чтобы помочь в определении ролей для достижения конкретных целей, MaSE использует диаграммы «вариантов использования» и диаграммы последовательности.

\subsection{Постановка целей}
Первым шагом на этапе анализа MaSE является определение целей, в рамках которого происходит преобразование исходной спецификации системы в набор структурированных системных целей. В постановке целей есть два подэтапа: определение целей и структурирование целей.

\textbf{Определение целей}. Цель шага под названием «Определение целей» состоит в том, чтобы уловить суть начального набора требований. Этот процесс начинается с извлечения сценариев из исходной спецификации и описания цели этого сценария. Все подробности того, как выполнять системные функции, не включены в качестве целей.

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

\textbf{Структурирование целей}. Последним шагом в определении целей является структурирование целей в виде диаграммы иерархии целей. Диаграмма иерархии целей представляет собой направленный ациклический граф, в котором узлы представляют цели, а дуги определяют отношения подцелей. Иерархия целей не обязательно представляет собой дерево, поскольку цель может быть подцелью более чем одной родительской цели.
Чтобы разработать иерархию целей, аналитик изучает цели на предмет их важности и взаимосвязей. Несмотря на то, что цели были зафиксированы, они имеют различную важность, размер и уровень детализации. Диаграмма иерархии целей сохраняет такие отношения и делит цели на подцели, которыми легче управлять и понимать.
Каждая подцель должна поддерживать свою родительскую цель в иерархии и определять, что необходимо сделать для достижения родительской цели. \textit{Декомпозиция цели продолжается до тех пор, пока любая дальнейшая декомпозиция не приведет к функциям вместо целей} (т. е. Аналитик предписывает, как цель должна быть достигнута).

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

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

\subsection{Применение вариантов использования}
Шаг «Применение вариантов использования» имеет решающее значение для преобразования целей в роли и связанные с ними задачи. Сценарии использования взяты из системных требований и описывают последовательности событий, которые определяют желаемое поведение системы; они являются примерами того, как должна вести себя система. Чтобы помочь определить фактическую связь в МАС, варианты использования преобразуются в диаграммы последовательности. Диаграммы последовательности MaSE аналогичны стандартным диаграммам последовательности UML, за исключением того, что они используются для отображения последовательности событий между ролями и для определения связи между агентами, которые будут играть эти роли. Определённые здесь роли формируют начальный набор ролей, используемых на следующем этапе, а события также используются позже для определения задач и диалогов.

Первым шагом в применении вариантов использования является извлечение вариантов использования из исходного системного контекста, который должен включать как положительные, так и отрицательные варианты использования. \textbf{Положительный вариант использования} описывает, что должно происходить при нормальной работе системы. Однако \textbf{отрицательный вариант использования} определяет поломку или ошибку. Хотя варианты использования не могут использоваться для охвата всех возможных требований, они помогают определить пути и роли коммуникации. Перекрестная проверка окончательного анализа по набору производных целей и вариантов использования обеспечивает избыточный метод для определения поведения системы.

\subsection{Уточнение ролей}
Цель шага -- преобразовать диаграмму иерархии целей и диаграмм последовательности в роли и связанные с ними задачи, формы, более подходящие для разработки МАС. Роли формируют основу для классов агентов и соответствуют целям системы на этапе проектирования. Авторы статьи утверждают, что цели системы будут удовлетворены, если каждая цель связана с ролью и каждая роль исполняется классом агентов. В общем случае преобразование целей в роли происходит взаимно-однозначно, при этом каждая цель сопоставляется с ролью. Однако бывают ситуации, когда полезно иметь одну роль, отвечающую за несколько целей, включая удобство или эффективность. Объединение целей усложняет роль, но может упростить общий дизайн. Как правило, для взаимодействия с внешними или внутренними ресурсами требуется отдельная роль, выступающая в качестве интерфейса для остальной части системы.

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

Задачи обычно выводятся из целей, за которые отвечает задача. Роли не должны разделять или дублировать задачи. Разделение задач -- признак неправильного разделения ролей.

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

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

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

Как только переход разрешен, он выполняется мгновенно. Если разрешено несколько переходов, используется схема приоритетов.

\section{Этап проектирования}

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

Первым шагом является назначение ролей каждому классу агентов. Если назначено несколько ролей, классы агентов могут играть их одновременно или последовательно. Чтобы обеспечить учет системных целей, каждая роль должна быть назначена по крайней мере одному классу агентов. На этом этапе также определяются диалоги, в которых должны участвовать разные классы агентов. Разговоры агента являются производными от внешних коммуникаций назначенных агенту ролей. Классы агентов и диалоги документируются с помощью диаграмм классов агентов, которые аналогичны объектно-ориентированным диаграммам классов с двумя основными отличиями. Во-первых, классы агентов определяются ролями, которые они играют, а не атрибутами и методами. Во-вторых, все отношения между классами агентов фиксируются как диалоги.

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

\subsection{Построение бесед}
К этому моменту, дизайнер только идентифицировал разговоры, цель этого шага -- определить детали этих диалогов на основе внутренних деталей параллельных задач. Разговор определяет протокол координации между двумя агентами и документируется с использованием двух диаграмм классов связи, по одной для инициатора и ответчика.

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

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

\subsection{Сборка агентов}
Этап «Сборка агентов» включает два подэтапа: определение архитектуры агентов и определение компонентов архитектуры. Разработчики могут либо разработать собственную архитектуру, либо использовать предопределенные архитектуры, такие как BDI. Точно так же дизайнер может использовать предопределенные компоненты или разрабатывать их с нуля. Компоненты состоят из набора атрибутов, методов и, возможно, подархитектуры.

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

\subsection{Проектирование системы}
Проектирование системы является последним этапом методологии MaSE и использует диаграммы развертывания для отображения количества, типов и местоположений экземпляров агентов в системе. Проектирование системы на самом деле является самым простым этапом MaSE, так как большая часть работы была проделана на предыдущих этапах.

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

\section{Инструмент agentTool}
Система \code{agentTool} была разработана для поддержки и обеспечения соблюдения MaSE. В настоящее время реализует все семь шагов MaSE, а также поддержку автоматизированного проектирования.

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

Система \code{agentTool} также обеспечивает автоматическую проверку разговоров. Процесс проверки начинается с полностью автоматизированного перевода системных диалогов на язык моделирования \code{Promela}.

\section{Применение}
MaSE успешно применяется во многих проектах для выпускников, а также в нескольких исследовательских проектах. Проект Multiagent Distributed Goal Satisfaction использовал MaSE для разработки совместной среды агентов для интеграции различных систем удовлетворения ограничений и планирования. В проекте «The Multiagent Distributed Goal Satisfaction» MaSE также использовался для разработки МАС, ориентированной на распределенное планирование людей и машин. MaSE успешно использовался для разработки гетерогенной системы баз данных на основе агентов, а также мультиагентного подхода к биологической иммунной системе компьютерных вирусов. MaSE также обеспечил высокоуровневый нисходящий подход, отсутствующий во многих приложениях для совместной работы роботов.

\section{Сравнение с другими методологиями}
Для разработки МАС было предложено несколько методологий. Однако мы сравниваем MaSE только с двумя другими методологиями: Gaia и Tropos.

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

Tropos, использует подход, существенно отличающийся от MaSE. Tropos фокусируется на раннем определении требований, на что не влияет MaSE. Tropos использует фреймворк i* (Yu, 2001), который обеспечивает хороший внешний интерфейс для Tropos. Фактически подход ранних требований Tropos можно использовать с MaSE, поскольку целевая модель каждой методологии практически одинакова.

\end{document}