Приложение 1. ОПИСАНИЕ СРЕДСТВ ПРЕДСТАВЛЕНИЯ МУЛЬТИАГЕНТНОЙ МОДЕЛИ ПОВЕДЕНИЯ СОЦИАЛЬНЫХ ГРУПП Мультиагентная (многоагентная) система (МАС, англ. Multi-agent system) — это система, образованная несколькими взаимодействующими интеллектуальными агентами. Мультиагентные системы могут быть использованы для решения таких проблем, которые сложно или невозможно решить с помощью одного агента или монолитной системы. Примерами таких задач являются, ликвидация чрезвычайных ситуаций1 и моделирование социальных структур2 и др. В мультиагентной системе агенты имеют несколько важных характеристик3: Автономность: агенты, хотя бы частично, независимы. Ограниченность представления: ни у одного из агентов нет представления о всей системе, или система слишком сложна, чтобы знание о ней имело практическое применение для агента. Децентрализация: нет агентов, управляющих всей системой4. MAC можно рассматривать организацию агентов (по аналогии с человеческой организацией) в качестве некоторого искусственного сообщества. Составляющими мультиагентной системы могут быть роботы, люди или команды людей. Также, мультиагентные системы могут содержать и смешанные команды. 1 Nathan Schurr and Janusz Marecki and Milind Tambe and Paul Scerri et.al. The Future of Disaster Response: Humans Working with Multiagent Teams using DEFACTO, 2005. 2 Ron Sun and Isaac Naveh. Simulating Organizational Decision-Making Using a Cognitively Realistic Agent Model, Journal of Artificial Societies and Social Simulation. 3 Michael Wooldridge, An Introduction to MultiAgent Systems, John Wiley & Sons Ltd, 2002, paperback, 366 pages, ISBN 0-471-49691-X. 4 Liviu Panait, Sean Luke: Cooperative Multi-Agent Learning: The State of the Art. Autonomous Agents and Multi-Agent Systems 11(3): 387—434 (2005) В мультиагентных системах может проявляться самоорганизация и сложное поведение, даже если стратегия поведения каждого агента достаточно проста. Агент представляет собой открытую систему, помещенную в некоторую среду, причем агенты обладают собственным поведением, удовлетворяющим определенным правилам. Агенты взаимодействуют, используя некоторый специальный язык и подчиняясь установленным правилам «общения» - регламентам (протоколам). Агенты MAC характеризуются процессами, которые происходят во время их работы и определяются описанием их потенциального поведения. Взаимодействие агентов предполагает обмен сообщениями между ними. Множество взаимосвязанных сообщений образует переговоры в MAC, которые определяются регламентами взаимодействия, определяющих все возможные течения переговоров. Регламент - это совокупность правил, определяющих порядок взаимодействия агентов. Процессный подход к описанию регламентов взаимодействия агентов ориентирован, в первую очередь, не на организационную структуру, а на деловые процессы (далее - процессы) мультиагентной системы. Под процессом будем понимать цепочку действий (операций, функций), результатом которой является изменение свойств агента (группы агентов или внешней среды) при взаимодействии с другими агентами системы или внешней средой. Процессный подход описанию взаимодействия агентов направлен на реализацию так называемой ресурсосберегающей организационной структуры (Lean production), основными чертами которой являются: • широкое делегирование полномочий и ответственности отдельным агентам (группам агентов); • высокая возможность автоматизации технологий выполнения процессов. Когда агенты вовлечены во взаимодействие, где нет необходимости в параллелизме, их взаимодействия традиционно задаются детерминированными 3 конечными автоматами, либо диаграммами потоков сообщений языков класса FIPA's Agent Communication Language (ACL). Для сложных взаимодействий более адекватным представлением является набором диаграмм такого языка, как UML (Unified Modeling Language - универсальный язык моделирования). UML - это язык объектно- ориентированного моделирования, который является результатом унификации существующих языков моделирования. UML можно охарактеризовать как формальный искусственный язык. Как формальный искусственный язык UML имеет: 1) синтаксис, то есть определение правил конструирования выражений языка; 2) семантику, то есть определение правил приписывания смысла выражениям языка; 3) прагматику, то есть определение правил использования выражений языка для достижения определенных целей. В состав UML входят набор диаграмм и нотаций различных видов. Стандартный набор UML диаграмм для моделирования включает: • диаграммы прецедентов (use case diagrams) - для моделирования бизнес-процессов организации и требований к создаваемой системе); • диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними; • диаграммы поведения системы (behavior diagrams): - диаграммы взаимодействия (interaction diagrams): диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами; - диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое; 4 диаграммы деятельностей (activity diagrams) - для моделирования деятельностей, также поведения системы в рамках различных вариантов использования; диаграммы реализации (implementation diagrams): - диаграммы компонентов (component diagrams) – для – для моделирования иерархии компонентов (подсистем) системы; - диаграммы размещения (deployment diagrams) моделирования физической архитектуры системы. В качестве основного типа диаграмм для описания взаимодействия агентов (визуального моделирования) предлагается использовать диаграммы деятельности (activity diagram) – диаграммы, на которых показаны разложение некоторой деятельности на её составные части. Диаграммы деятельности могут быть использованы не только при спецификации алгоритмов вычислений или потоков управления для описания реализации коммуникаций агентов в информационной среде, но и для описания процессов более высокого уровня абстракции – таких как поведение агентов. Немаловажным фактором в пользу данного вида диаграмм языка UML, реализующих процессный подход, является то, что, регламенты и построенные на их основе сценарии взаимодействия агентов, описанные с использованием данного вида диаграмм, вполне адекватно воспринимаются экспертам различных предметных областей без специальной дополнительной подготовки. Под деятельностью (activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов - вложенных видов деятельности и отдельных действий (action), соединённых между собой потоками, которые идут отвыходов одного узла ко входам другого Основным элементом диаграммы деятельности является деятельность (activity). Этот объект может быть интерпретирован по-разному в зависимости от той точки зрения, с которой строится данный аспект модели. Деятельность может быть записана на естественном языке, некотором псевдокоде или языке 5 программирования. Никаких дополнительных или неявных ограничений на её запись не накладывается, но рекомендуется в качестве имени деятельности использовать глагол с пояснительными словами. Если же деятельность может быть представлена в некотором формальном виде, то во многих случаях может оказаться целесообразно записать её на том языке программирования, на котором предполагается реализовывать конкретный проект. Каждая диаграмма деятельности имеет начальное и конечное состояния. Выходить из конечного состояния и входить в начальное стрелка не может. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное в нижней. При построении диаграммы деятельности используются только нетриггерные переходы, то есть такие переходы, которые выполняются сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой. Если из деятельности выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то выполняться может только один из них. В этом случае для каждого из таких переходов должно быть явно записано сторожевое условие в прямых скобках. Условие же истинности должно выполняться только одного из них. Данный случай встречается тогда, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. Такая ситуация называется ветвлением, а для ее обозначения применяется специальный графический символ: небольшой ромб, внутри которого нет никакого текста. В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Принято входящую стрелку присоединять к верхней или левой вершине символа 6 ветвления. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее сторожевое условие в форме булевского выражения. Один из недостатков семантических конструкций других языков, рассмотренных выше, связан с проблемой изображения параллельных ветвей отдельных процессов. В то время как диаграммы деятельности могут быть использованы не только для спецификации алгоритмов последовательных, но и параллельных процессов. Поскольку распараллеливание процессов на практике встречается очень часто - необходимы графические примитивы для представления параллельных процессов. В языке UML для этой цели используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Таким символом является прямая черточка. Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы деятельности. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих, а слияние (concurrent join) имеет несколько входящих переходов и один выходящий. Любая сложная деятельность по достижению определённой цели в соответствии с одним из основополагающим принципом системного анализа – принципом декомпозиции – может быть представлена в виде совокупности отдельных действий, направленных на достижение требуемого результата. Но, более того, на практике дополнительно возникает потребность в том, чтобы ассоциировать выполнение отдельного действия с конкретным агентом. В этом случае конкретный агент «несёт ответственность» за реализацию отдельных действий, а сам процесс представляется в виде переходов действий из одного агента к другому. Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). Все состояния действия на диаграмме деятельности делятся на отдельные группы, которые 7 отделяются друг от друга вертикальными линиями. Две соседние линии образуют дорожку, а группа состояний между этими линиями выполняется отдельным участниками процесса. Назначение ответственности» дорожек за состоит выполнения в том, отдельных чтобы указать деятельностей в «зоны рамках моделируемого процесса. В качестве имен основных дорожек используются наименования агентов. Названия дорожек явно указываются в верхней части дорожки. Порядок следования дорожек не несет какой-либо семантической информации и определяется соображениями эргономичности. В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Таким образом, объекты либо инициируют выполнение действий, либо определяют некоторый их результат. Действия специфицируют вызовы, которые передаются от одного объекта графа диаграммы деятельности к другому. Поскольку в таком ракурсе объекты играют определенную роль в понимании процесса деятельности, часто возникает необходимость явно указать их на диаграмме. Объекты на диаграмме деятельности могут обозначать сообщения, отдельных агентов. Тогда, например, поток объектов, может служить дополнительным аспектом модели взаимодействия конкретного агента с другими агентами или окружающей средой. На диаграмме деятельности с дорожками расположение объекта может иметь дополнительный смысл: если объект расположен на границе двух дорожек, то это может означать, что переход к следующему состоянию действия в соседней дорожке ассоциирован с готовностью некоторого объекта (объект в некотором состоянии). Если же объект целиком расположен внутри дорожки, то и состояние этого объекта целиком определяется действиями данной дорожки. Разработка диаграмм деятельности занимает центральное место при создании моделей с использованием нотации UML существующих процессов, а также при выполнении проектов по реинжинирингу и оптимизации последних. 8 Несмотря на то что диаграмма деятельности не является непосредственно необходимой для генерации программного кода, диаграммы именно этого типа имеют ключевое значение для моделирования и визуального представления процессов и их последующей сертификации по международному стандарту ISO 9000. Также в случае необходимости при разработке или внедрении программной реализации модели мультиагентной системы дополнительно могут быть построены диаграммы вариантов использования, диаграммы взаимодействия, диаграммы компонентов и др. Так, например, в качестве вспомогательного типа диаграмм для описания структуры отдельных сущностей или объектов могут применяться диаграммы классов (class diagram) - диаграммы на которых показаны множество классов, их атрибутов, операторов и взаимосвязи (особый тип логических отношений) между этими сущностями. Резюмируя вышесказанное, отметим что для решения задачи представления модели мультиагентной системы, включая взаимодействия агентов отдельных социальных групп, а также сценарии их реализации, в данном случае является оптимальным использование процессного подхода, реализованного с моделирования UML. использованием диаграмм унифицированного языка