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

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

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

Full description

Saved in:
Bibliographic Details
Date:2025
Main Authors: Parasyuk, I.M., Yershov, S.V.
Format: Article
Language:Russian
Published: PROBLEMS IN PROGRAMMING 2025
Online Access:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/809
Tags: Add Tag
No Tags, Be the first to tag this record!
Journal Title:Problems in programming
Download file: Pdf

Institution

Problems in programming
id pp_isofts_kiev_ua-article-809
record_format ojs
resource_txt_mv ppisoftskievua/22/5a7bc214a5e3c2f686bcc9efdc86b222.pdf
spelling pp_isofts_kiev_ua-article-8092025-08-28T20:52:26Z Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей Transformational approach to developing intelligent agents on the basis of fuzzy models Parasyuk, I.M. Yershov, S.V. УДК 681.3.06 UDC 681.3.06 Рассматривается трансформационный подход, применяемый на различных стадиях разработки интеллектуальных агентов, в основе которого находятся модели нечетких правил. Описаны трансформации, по-зволяющие сгенерировать нечеткие платформно-независимые модели внутриагентного управления и связанные с ними ролевые модели. Рассмотрены способы создания в среде Eclipse средств поддержки проблемно-ориентированного графового языка для спецификации нечетких моделей, не зависящих от используемой платформы. Значительное внимание уделяется архитектурным особенностям нечетких агентов, порождаемых в результате трансформации для перспективных платформ. Problems in programming 2011; 2: 62-78 A transformational approach is considered that is applied at different phases of intelligent agents’ development, which are based on the model of underlying fuzzy rules. Transformation to generate a fuzzy platform-independent models of inter-agent control and associated role models are described. Methods of creation of facilities in Eclipse environment to support domain-specific graph-based language for the specification of fuzzy models that do not depend on used platform are considered. Considerable attention is given to architectural features of fuzzy agents that are generated as a result of transformation for advanced platforms.Problems in programming 2011; 2: 62-78 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-08-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/809 PROBLEMS IN PROGRAMMING; No 2 (2011); 62-78 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2011); 62-78 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2011); 62-78 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/809/861 Copyright (c) 2025 PROBLEMS IN PROGRAMMING
institution Problems in programming
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date 2025-08-28T20:52:26Z
collection OJS
language Russian
topic_facet
УДК 681.3.06

UDC 681.3.06
format Article
author Parasyuk, I.M.
Yershov, S.V.
spellingShingle Parasyuk, I.M.
Yershov, S.V.
Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
author_facet Parasyuk, I.M.
Yershov, S.V.
author_sort Parasyuk, I.M.
title Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_short Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_full Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_fullStr Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_full_unstemmed Трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_sort трансформационный поход к разработке интеллектуальных агентов на основе нечетких моделей
title_alt Transformational approach to developing intelligent agents on the basis of fuzzy models
description Рассматривается трансформационный подход, применяемый на различных стадиях разработки интеллектуальных агентов, в основе которого находятся модели нечетких правил. Описаны трансформации, по-зволяющие сгенерировать нечеткие платформно-независимые модели внутриагентного управления и связанные с ними ролевые модели. Рассмотрены способы создания в среде Eclipse средств поддержки проблемно-ориентированного графового языка для спецификации нечетких моделей, не зависящих от используемой платформы. Значительное внимание уделяется архитектурным особенностям нечетких агентов, порождаемых в результате трансформации для перспективных платформ. Problems in programming 2011; 2: 62-78
publisher PROBLEMS IN PROGRAMMING
publishDate 2025
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/809
work_keys_str_mv AT parasyukim transformacionnyjpohodkrazrabotkeintellektualʹnyhagentovnaosnovenečetkihmodelej
AT yershovsv transformacionnyjpohodkrazrabotkeintellektualʹnyhagentovnaosnovenečetkihmodelej
AT parasyukim transformationalapproachtodevelopingintelligentagentsonthebasisoffuzzymodels
AT yershovsv transformationalapproachtodevelopingintelligentagentsonthebasisoffuzzymodels
first_indexed 2025-09-17T09:23:39Z
last_indexed 2025-09-17T09:23:39Z
_version_ 1850410154996006912
fulltext Експертні та інтелектуальні інформаційні системи УДК 681.3.06 И.Н. Парасюк, С.В. Ершов ТРАНСФОРМАЦИОННЫЙ ПОДХОД К РАЗРАБОТКЕ ИНТЕЛЛЕКТУАЛЬНЫХ АГЕНТОВ НА ОСНОВЕ НЕЧЕТКИХ МОДЕЛЕЙ Рассматривается трансформационный подход, применяемый на различных стадиях разработки интеллек- туальных агентов, в основе которого находятся модели нечетких правил. Описаны трансформации, по- зволяющие сгенерировать нечеткие платформно-независимые модели внутриагентного управления и связанные с ними ролевые модели. Рассмотрены способы создания в среде Eclipse средств поддержки проблемно-ориентированного графового языка для спецификации нечетких моделей, не зависящих от используемой платформы. Значительное внимание уделяется архитектурным особенностям нечетких агентов, порождаемых в результате трансформации для перспективных платформ. Введение Наблюдаемый в последнее время рост интереса к возможностям мультиа- гентных интеллектуальных систем в кон- тексте разработки программного обеспе- чения ставит задачу создания методов и средств моделе-ориентированной транс- формационной разработки (Model-Driven Engineering, MDE) таких систем. Хотя, многие известные методологии разработки мультиагентных систем, такие как Tropos [1] и INGENIAS [2] предлагают методы и инструменты для автоматизации транс- формаций моделей, они предназначены для использования только на некоторых этапах разработки и не могут рассматри- ваться как систематические.  62 В настоящее время мультиагентные системы представляют собой один из наи- более сложных видов программного обес- печения, разработка которых затрудняется в связи с: 1) отсутствием единой метамо- дели, в рамках которой описывается функ- ционирование агентов (например, рас- сматриваются делиберативные, реактив- ные и другие виды агентов); 2) существо- ванием агентов и принятием решения агентами в условиях неопределенности, когда каждый агент обладает ограничен- ной информацией; 3) необходимостью рассматривать различные дополнительные аспекты описания, имеющие решающее значение для мультиагентных систем, та- кие как выполняемые роли, принципы и модели обмена сообщениями и координа- ции); 4) отсутствием общепринятых “стан- дартных” платформ и языков реализации – несмотря на предпринимаемые попытки, такие как абстрактная архитектура FIPA [3]. Для решения вышеуказанных проблем требуются новые парадигмы концептуали- зации, новые модели формализации и но- вые архитектуры построения нечетких агентов, что, в свою очередь, требует соз- дания новых технологий проектирования и программной реализации, опирающихся на сквозное использование моделей, пред- ставляющих различные уровни и детали представления мультиагентных систем, и на систематическое использование автома- тизированных трансформаций, позволяю- щих сократить объем работы при переходе между моделями. Их решение возможно в рамках инженерии предметной области [4, 5], включающей в себя создание моделей, метамоделей и спецификации трансфор- маций для разработки нечетких агентов. За счет потраченных при этом усилий, воз- можна значительная экономия ресурсов и улучшение характеристик качества про- граммного обеспечения мультиагентных систем [6] при проведении прикладной инженерии [4]. Моделе-ориентированная разработка включает в себя оба указанных вида деятельности. В основе моделе-ориентированной разработки лежат понятия платформно- независимой и платформно-зависимой мо- делей (ПНМ, PIM, platform-independent и ПЗМ, PSM, platform-specific model). ПНМ определены на высшем уровне абстракции, © Парасюк И.Н., Ершов С.В., 2011 ISSN 1727-4907. Проблеми програмування. 2011. № 2 Експертні та інтелектуальні інформаційні системи   63 чем ПЗМ. Независимая от платформы мо- дель – представление системы с независи- мой от платформы точки зрения [7], в то время как ПЗМ определена как вид систе- мы с точки зрения определенной платфор- мы. Использование этих понятий позволя- ет избавиться от технологических и техни- ческих деталей, которые несущественные для фундаментальной функциональности системы (или ее части). Разделение платформно-зависимой и платформно-независимой моделей обес- печивает ряд преимуществ по сравнению с традиционным подходом. В частности, об- легчается перенос программного обеспе- чения на другую платформу и его модифи- кация, так как при этом можно использо- вать старую платформно-независимую мо- дель и разрабатывать заново только плат- формно-зависимую. Главное преимущество моделе- ориентированного подхода состоит в том, что с его помощью можно ускорить разра- ботку мультиагентных систем, несмотря на то, что нужно создать несколько моделей вместо одной. Это достигается за счёт ав- томатизированной генерации платформно- зависимой модели по платформно- независимой с помощью специально раз- работанных трансформаций (выражаемых чаще всего как набор правил). Поэтому процесс перехода к платформно- зависимым моделям и программному коду мультиагентных систем, основанным на конкретной технологической платформе, может быть в значительной степени фор- мализован с помощью таких трансформа- ций. Цель настоящей работы – исследо- вание и обоснование трансформационного подхода к разработке интеллектуальных агентов с использованием нечетких моде- лей, разработка трансформационной среды для спецификации моделей нечетких аген- тов, не зависящих от платформы реализа- ции, и изучение архитектурных особенно- стей нечетких агентов, порождаемых для перспективных платформ. Перечисленные проблемы тематически вписываются в дальнейшее развитие исследований в на- правлении становления моделе- ориентированного подхода к разработке интеллектуальных программных агентов [8–12]. Основные модели и трансформации Для описания процессов, в рамках которых разрабатываются нечеткие интел- лектуальные агенты, нами использован Eclipse Process Framework (EPF) – инстру- ментальная платформа управления про- цессами и концептуальный фреймворк для создания, адаптации, развертывания разра- ботанных процессов [13]. EPF предостав- ляет готовый каталог процессов для ти- пичных проектных ситуаций, которые мо- гут быть адаптированы для индивидуаль- ных целей. Два основные концепции EPF – это содержимое метода и процесс. Эти две концепции прекрасно иллюстрирует уни- фицированный процесс разработки про- граммного обеспечения [14], включающий как методы, так и процессы – фазы и ите- рации. Содержимое метода описывает как он может быть выполнен, какие требуются навыки, пошаговое описание того, как до- биться требуемых показателей. Процесс описывает сам жизненный цикл разработ- ки и определяет последовательность осу- ществления выполнения работы ролями, и то как производятся и эволюционируют во времени рабочие продукты. В стандартной поставке EPF предлагаются для загрузки процессы для OpenUP, XP и Scrum. Хране- ние и структурирование контента опреде- ляется схемой, это развитие спецификации SPEM [15], ссылающейся на Unified Method Architecture (UMA). Такая органи- зация контента не ограничивается тради- ционным производством ПО и пригодна для поддержки процессов моделе- ориентированной разработки сложных мультиагентных систем. Содержимое раз- работанных методов базируется на рабо- чих продуктах, видах деятельности, ролях и инструментальных средствах. Рабочие продукты производятся инструменталь- ными средствами которые выполняют ро- ли, и имеют рабочие продукты в качестве входов и выходов. В нашем процессе ра- бочие продукты представляют собой как графовые модели (например, модель внут- риагентного управления), так и текстовые документы (табличное представление ро- Експертні та інтелектуальні інформаційні системи левой модели и код программы агента на языке программирования). Конкретные роли выполняют разработчики, вовлечен- ные в процесс создания мультиагентной системы. В качестве инструментальных средств рассматриваются проблемно-ори- ентированные редакторы моделей и нако- нец, сами трансформации между моделя- ми. Такой процесс включает трансформа- ции и виды деятельности, которые изо- бражены на рис. 1 в виде диаграммы EPF. Основные процессы разработки не- четкой мультиагентной системы с исполь- зованием моделе-ориентированного под- хода согласуются с ядром знаний SWEBOK [16], которое является осново- полагающим документом, отображающем мнение многих зарубежных и отечествен- ных специалистов в области программной инженерии и согласующееся с современ- ными регламентированными процессами стандарта ISO/IEC 12207.   Рис. 1. Основные трансформации, виды деятельности и их взаимосвязи при разработке нечетких агентов  64 Експертні та інтелектуальні інформаційні системи   65 Основные рассматриваемые облас- ти-процессы – это разработка (выявление и анализ) требований, проектирование аген- тов и реализация агентов мультиагентной системы. Значение отдельных моделей ин- теллектуальных агентов не одинаково для различных процессов. При этом на этапах разработки требований и проектирования создаются основные платформно-незави- симые модели: начальная модель нечетко- го агента, начальная ролевая модель, уточ- ненная ролевая модель и модель внутри- агентного управления (МВУ). Платформ- но-зависимые модели включают в себя модели нечеткого агента, соответствую- щие всем деталям текстового представле- ния. Естественно, что такие модели явля- ются объектом процессов конструирова- ния и тестирования. В настоящее время такие модели разработаны для таких плат- форм как FCL [17], JADE [18] и для разра- ботанной нами библиотеки классов про- граммирования нечетких агентов в среде суперкомпьютера СКИТ-3 [19]. Основные применяемые трансфор- мации служат как для перехода между процессами разработки, так и для преобра- зования между моделями, применяемыми в одном процессе (например, переход ме- жду уточненной ролевой моделью и моде- лью МВУ). Моделе-ориентированный транс- формационный подход включает разра- ботку метамоделей, определяющих спосо- бы спецификации нечетких моделей. При этом, вначале выбирается единственная метамодель высшего уровня, которая не зависит от точки зрения и определяет спо- собы построения всех остальных метамо- делей (в том числе и самой себя). Моделе-ориентированная разработ- ка мультиагентных систем в значительной степени зависит от последовательной трансформации их моделей [20]. При этом наиболее важными являются способы пре- образований моделей: • преобразования модель-модель (M2M). Этот вид преобразования исполь- зуется для преобразования одного типа графической модели (схемы, диаграммы) к другому типу графической модели. Преоб- разование M2M основано на исходной и целевой метамоделях и определяет преоб- разования элементов исходной модели в элементы целевой модели; • преобразования модель-текст (M2T). Такие преобразования используют- ся для трансформации визуального пред- ставления в код программы; синтаксис це- левого языка определяется вместе с мета- моделью графической модели. Разработка моделей нечетких правил и ролевых моделей агентов Применяемые в процессах моделе- ориентированной разработки нечетких мультиагентных систем метамодели, мо- дели и трансформации описаны на основе фреймворка Eclipse Modeling Framework [21], использующего для построения моде- лей метамодель высшего уровня Ecore. Она определяет, что модель состоит из эк- земпляров типа EClass, которые могут иметь атрибуты (экземпляры типа EAttribute) или ссылки на другие экземп- ляры EClass (через тип EReference). В ре- зультате, атрибуты могут быть различны- ми экземплярами EDataType (например, целыми числами, строками, действитель- ными числами, и т. д.). Средства описания метамоделей Ecore предназначены для поддержки времени выполнения, такой как уведомления об изменениях, средства для сохранения моделей со встроенными сред- ствами сериализации на основе стандарта XMI (XML Metadata Interchange) [22], и эффективный интерфейс программиста для операций над объектами Ecore. Компонент Ecore Tools обеспечивает среду для опера- ций над моделями, в том числе проверку правильности и создание генераторов. Аналогичная технология для пред- ставления и обработки метамоделей – Meta-Object Facility (MOF) [23]. Тем не менее, метамодель EMF проще, чем мета- модель MOF с точки зрения понятий, свойств и внутренней структуры, таким образом, отображение понятий EMF в по- нятия MOF может быть проведено относи- тельно просто. Исходной при трансформационной разработке агентов может служить их платформно-независимая модель нечетких правил. Для представления системы нечет- Експертні та інтелектуальні інформаційні системи ких правил разработана метамодель Ecore нечетких правил, содержащая все необхо- димые понятия для конструирования сис- тем нечетких правил вывода, таких как системы Мамдани или системы Такаги– Сугено [24, 25]. В качестве основных клас- сов (понятий) выбраны FuzzyRule (нечет- кое правило), FuzzyVariable (нечеткая пе- ременная), FuzzyValue (нечеткое значе- ние), FuzzySet и LinguisticTerm (нечеткое множество и связанный с ним лингвисти- ческий терм). Каждое правило включает набор антецедентов и консеквентов, кото- рым соответствует нечеткое значение, свя- занное в свою очередь с нечеткой пере- менной, описывающей набор допустимых лингвистических значений и их функций принадлежности. Различные способы вы- полнения нечетких правил учитываются с помощью конкретных классов FuzzyRule- Executor, например, класс LarsenRule- Executor соответствует системе Ларсена. Это позволяет расширять данную метамо- дель другими видами нечетких систем, описанными в литературе [24], не затраги- вая при этом другие модели. Фрагмент ме- тамодели, относящийся к представлению нечетких правил представлен на рис. 2. Однако, задавать исходную модель правил в текстовом виде или базовыми средствами дерева объектов Ecore было бы не наглядно и затрудняло бы ее воспри- ятие. Для ввода и редактирования таких моделей создан специальный графический редактор со средствами навигации по не- четким правилам и композиции правил за- мены (удаление и добавление нечетких пе- ременных, множеств, функций принад- лежности, включение переменных в анте- цеденты и консеквенты правил и т. д.) На рис. 3 приведен пример начальной модели нечетких правил агента, заданной на про- блемно-ориентированном графовом языке, не зависящем от платформы реализации. FuzzyRule ruleExecutor 1 1 1 1 1 .. * FuzzyRuleExecutor + execute SetPoint x y FuzzyValue + fuzzySum + fuzzyUnion + getAlphaCut + fuzzyMatch inquisticExpression FuzzyVariable + addTerm + findTerm +removeTerm name LingvisticTerm value FuzzySet numPoints simplified toStrongPrecision LRFuzzySet RFuzzySet LFuzzySet TriangleFuzzySet leftBottom moddleTop rightBottom TrapezoidFuzzySet zeroLeftX oneLeftX oneRightX zeroRightX associated fuzzySet set value 1 .. *1 .. * conclusions antecedents Рис. 2. Фрагмент метамодели для представления нечетких правил  66 Експертні та інтелектуальні інформаційні системи Создание такого редактора произ- водилось в рамках методологии предмет- но-ориентированного моделирования (domain-specific modeling), включающей систематическое использование визуаль- ных (чаще всего основанных на графах) предметно-ориентированных языков моде- лирования для представления различных аспектов системы. Такие языки дают воз- можность специфицировать систему на более высоком уровне платформно- независимой абстракции, чем языки моде- лирования общего назначения, такие как UML. Процесс создания предметно- ориентированного языка состоит из трех шагов: определение абстрактного синтак- сиса, определение конкретного синтаксиса и определение правил трансформации. Аб- страктный синтаксис для моделирования нечетких агентов задается метамоделью в системе EMF (формат Ecore), фрагмент которой приведен выше (рис. 2). Для опи- сания конкретного визуального синтаксиса диаграмм использовался фреймворк GMF (Graphical Modeling Framework) [26]. По- строение такого синтаксиса начинается с определения модели графического опреде- ления, включающей галерею графических элементов (фигуры, надписи, линии и т. д.) в виде дерева объектов в формате Ecore. Модель инструментов включает в себя описание элементов для создания палитры, панели инструментов, а также различных меню, используемых при редактировании диаграмм. Наиболее важной из всех моде- лей GMF является модель отображений, связывающая элементы графического оп- ределения и инструменты с вершинами и ребрами графического редактора, и поро- ждающая в результате модель генератора. На основе такой модели порождается пол- ный код программы-редактора диаграмм, работающий в среде Eclipse. Аналогично, существует также возможность задать конкретный текстовый синтаксис, напри- мер, с использованием фреймворка Textual Modeling Framework [27]. Определение правил трансформа- ций, отображающих модели, создаваемые с помощью сгенерированного редактора, осуществлялось с использованием языка Query/View/Transformation (QVT), разра- ботанного под руководством OMG. QVT определяет стандартный способ преобра- зования исходных моделей в целевые мо- дели на основании сопоставления элемен- тов исходной и целевой метамоделей. Хотя стандартное определение QVT предназна- чено для отображений над элементами MOF- совместимых метамоделей, реализа- ция, применяемая в Eclipse, основана на метамоделях Ecore. QVT определяет не   67 0/-30 1/-30 0/-10 Очень низкая 0/-10 0/0 1/0 Значит. закрыть 0/-2.5 1/0 0/2.5 Отсут- ствует 0/0 1/2.5 0/5 Немного открыть 0/75 1/100 0/100 Очень большой 0/50 1/75 0/100 Большой 0/0 1/25 1/50 Малый 0/0 1/0 0/25 Очень малый 0/-10 1/0 0/10 Нулевая 0/-30 1/-10 0/0 Ниже нулевой consumptiontemp value 1 2 3 4 или или или или Рис. 3. Начальная модель нечеткого агента, заданная на проблемно-ориентированном графовом языке, не зависящем от платформы реализации Експертні та інтелектуальні інформаційні системи  68 один, а три предметно-ориентированных языка: реляционный (декларативный) Relations, ядро Core и язык операционных отображений OperationalMappings. Rela- tions и Core – декларативные языки на двух разных уровнях абстракции, с норма- тивными отображениями между ними. QVT/OperationalMappings – императивный язык, охватывающий средства QVT/Core и позволяющий задавать такие конструкции как циклы, условия и т. д. Хотя известно множество других языков, родственных QVT по лежащим в их основе понятиям (например, ATL и Tefkat), в настоящее время именно QVT/OperationalMappings обеспечивает как наибольшую практиче- скую проработанность, так и наибольшую степень совместимости с концепциями, предлагаемыми OMG в рамках моделе- ориентированной архитектуры. В процессе разработки требований также определяется их начальная ролевая модель (РМ). Предполагается что интел- лектуальный агент обязывается выполнить одну или несколько ролей в течении сво- его жизненного цикла. Одной из особенно- стью разработки агентов является то, что виды деятельности агента связаны с ро- лью, а не с системой. Кроме того, после определения возможностей агентов и раз- ложения их на простые деятельности, не- обходимо определить динамическую ком- позицию из этих видов деятельности по каждой роли таким образом, что агент дос- тигает поставленной цели. Метамодель ролевой модели определяет понятие Роль, которое ссылается на понятия: • деятельность, которая включает два атрибута, имя (название) и функцио- нальность (описание того, что эта деятель- ность делает); • возможность, относящаяся к на- правлениям деятельности на которые она ссылается, достигающим высокоуровневой цели; • протоколы и виды деятельности, которым приписываются соответствующие названия. В процессе проектирования генери- руются дополнительные роли агента, уточняющие начальную ролевую модель. В общей ситуации, в соответствии с шаб- лоном проектирования поставщик/потре- битель [28] для каждой нечеткой перемен- ной, входящей в начальную модель пра- вил, порождаются две дополнительные роли. Определенные ранее роли связыва- ются с выбранными типами агентов, со- ставляющими проектируемую мультиа- гентную систему и порождающими от- дельные (типизированные) экземпляры агентов. При необходимости размещения агентов на одной вершине для экономии коммуникационных ресурсов их типы мо- гут быть совмещены, что приводит к сум- мированию (наложению) ролей, которые они должны выполнять. Модели внутриагентного управления В процессе проектирования к уточ- ненной ролевой модели применяются трансформации, позволяющие получить спецификации моделей внутриагентного управления – по одной для каждой сгене- рированной роли. Для разработки таких трансформаций модель-модель (M2M) ис- пользован язык QVT/OperationalMappings. Многие методологии разработки (как Tropos или INGENIAS [1, 2]) навязы- вают специфические ментальные модели агента. В отличие от этого, модель внутри- агентного управления (МВУ) основана на нечетких схемах состояний и не делает ни- каких дополнительных предположений о таких аспектах как модель коммуникации, процесс вывода или ментальные состояния (убеждения-желания-намерения) агентов. Отдельным агентам таких распре- деленных систем открыт доступ только к их собственным состояниям, а не к гло- бальному состоянию всей системы, о ко- тором агент может делать только предпо- ложения. К тому же, любая среда передачи асинхронных сообщений между агентами не является абсолютно надежной и приво- дит к запаздыванию сообщений, что еще больше увеличивает степень неопределен- ности схем состояний агента. Поэтому ра- ботой таких агентов можно управлять только с учетом степени достижимости таких “размытых” состояний, для чего обоснованным представляется исполь- зование нечеткой математики. Експертні та інтелектуальні інформаційні системи Метамодель МВУ, показанная на рис. 4, определяет понятие Модель, кото- рая включает нечеткие состояния, перехо- ды и значения. Имена модели должны удовлетворять современному формату пространства имен пакетов Java или C#. Нечеткие состояния содержат следующие атрибуты: имя узла, тип узла, соответст- вующий типу состояния в схеме состоя- ний, как правило, один из И, ИЛИ, НА- ЧАЛО, КОНЕЦ, метка узла, и деятель- ность, связанная с узлом. Состояния и переходы также ссы- лаются на нечеткие значения, которые в свою очередь включают атрибут “значе- ние” – в диапазоне [0,1]. Следующим по- нятием определенным в этой метамодели является “Переход”, который, кроме ссыл- ки на нечеткое значение, включает также следующие атрибуты: Нечеткое значение + значение Модель + имя Переход + ВП + имя Состояние + тип + имя + метка + деятельность Начальное состояние принадлежность принадлежность исходное целевое состояния переходы 1 0 .. * 1 1 1 0 .. *   Рис. 4. Метамодель внутриагентного управления • имя, обычно в форме <метка ис- ходного узла> <метка целевого узла>; • выражение перехода. Через выра- жения перехода (ВП) определяется основ- ная управляющая информацию в МВУ. Это выражение содержит условия и собы- тия, которые делают переход возможным. Кроме того, может быть использовано по- лучение или передача сообщений между агентами (в случае взаимодействующих агентов); • источник, исходное состояние, и цель, целевое состояние. Таким образом, каждая модель МВУ уточняется, определением условий и события приема/передачи сообщений, ко- торые позволят переходы от одной дея- тельности (задачи) к другой. МВУ задается нечеткой схемой пе- реходов, представленной нечетким муль- тиграфом ),,,( Σ= GTQG μ , где },...,,{ 21 nqqqQ = – множество состояний (вершин графа), где – начальное со- стояние; 1q },...,,{ 21 ntttT = – множество пере- ходов (дуг) графа; ]1,0[: →TGμ – функция принадлежности переходов данной схеме; AT →Σ : – функция разметки переходов событиями из некоторого конечного алфа- вита событий (сообщений) A. Способ представления принадлеж- ностей переходов фактически определяет структура нечеткой схемы переходов. Пусть такая схема включает n состояний, степень принадлежности ее переходов мо- жет быть представлена в виде трехмерной матрицы P= , (1) ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ ⎤ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ ⎡ nnnn n n ppp ppp ppp ,...,, ................... ,...,, ,...,, 21 22221 11211 где – вектор степени принадлежности переходов между верши- нами i и j, размеченных соответственно символами , причем , символы в разметке не повторяются. Ненулевые значения ],...,,[ 21 m ijijijijp μμμ= ka ]1,0[∈k ijμ ijμ соответствует переходам со- стояний , при этом ),,( k ij k ijij aqq μδ= ijμ = 0 означает, что между двумя состояниями перехода нет. Правильная схема переходов должна удовлетворять следующему усло- вию: в одном и том же векторе символы событий отличаются друг от друга ( для всех lk aa ≠ lk ≠ ) и принадлежат конечному алфавиту событий A. Определим нечеткое (размытое) со- стояние как вектор пар ,...,)(,,)(,[ 2211 ><><= qqqqQ μμ ])(, >< nn qq μ , (2)   69 Експертні та інтелектуальні інформаційні системи Одной из интересных возможностей на- стройки нечеткой схемы переходов явля- ется возможность ее обучения на основе представленных примеров и специально разработанной эволюционной стратегии [11]. второй компонент которых )( iqμ – степень принадлежности агента данному состоя- нию. Реакцией (выполнением) схемы пе- реходов в ответ на наступление события является новое состояние ka ],...,)(,,)(,[ 2211 ><><= ⊗⊗⊗ qqqqQ PQPQPQ μμ ])(, >< ⊗ nPQn qq μ Пример разработки агентов на основе нечетких моделей такое, что Рассмотрим процесс моделе- ориентированной разработки нечетких агентов для задачи управления подачей газа конечным потребителем. Управление подачей газа осуществляется путем час- тичного или полного открытия/закрытия вентиля (заслонки), от положения которо- го зависит давление в трубе. Задача – не допустить значительного отклонения дав- ления. Поскольку потребление ресурса может существенно колебаться, принятие решения о положении вентиля не может быть осуществлено только на основании объема потребления. Следует учитывать также другие факторы – например, темпе- ратуру воздуха, время суток. Кроме того, показания датчиков для снижения их стоимости не могут быть абсолютно точ- ными и вносят дополнительную нечет- кость. }*)(max{)( k jiji qq μμμ = ( Qqq jj >∈<∀ )(,μ ). Последовательное выполнение (поведе- ние), задаваемое парой событий , и схемой нечетких переходов соответствует max-* композиции нечетких отношений : ka la PP⊗ },*max{ l rj k irij μμμ = ),...1,,( nrpp rj l rjir k ir =∈∈∀ μμ . Деятельности, задаваемые схемой с n состояниями непосредственно представ- лены вектором: D = [d1,d2, … , dn], Предположим, решение о положе- нии вентиля принимается агентом на осно- вании двух нечетких лингвистических пе- ременных (температуры воздуха и текуще- го объема потребляемого ресурса). В таб- лице 1 показаны допустимые значения лингвистических переменных и соответст- вующих им термов, на основе которых строятся лингвистические правила, на рис. 5 – функции принадлежности нечет- где – деятельность, выполняемая в j-м состоянии. Как правило, выполняется только деятельность, степень принадлеж- ности состояния которой – наибольшая среди всех состояний. jd Таким образом, любая нечеткая схема переходов c n состояниями может быть представлена матрицей принадлеж- ности n*n (1) и вектором состояния (2). Таблица 1. Нечеткие лингвистические переменные для агента-потребителя ресурсов Лингвистическая пере- менная Тип Лингвистические термы Температура Входная Очень низкая (ОН), ниже нулевой (НН), нулевая (Н), выше нулевой (ВН), очень высокая (ОВ) Текущий объем по- требляемого ресурса Входная Очень малый (ОМ), малый (М), средний (СР), большой (Б), очень большой (ОБ) Изменение степени открытия вентиля Выходная Значительно закрыть (ЗЗ), немного закрыть (НЗ), отсутствует (О), немного открыть (НО), значительно открыть (ЗО)  70 Експертні та інтелектуальні інформаційні системи ких множеств, описывающих лингвисти- ческие термы; для простоты используются треугольные функции принадлежности. В таблице 2 представлен набор нечетких правил Мамдани, осуществляющих управ- ление. Для указанной системы правил раз- работана начальная модель нечетких правил агента, заданная на проблемно- ориентированном графовом языке, не за- висящем от платформы реализации (рис. 3). В процессе проектирования генери- руются дополнительные роли агента. В общей ситуации, в соответствии с шабло- ном проектирования поставщик/потреби- тель [28] для каждой нечеткой переменной порождаются две роли. Кроме того, по- ставщики входных переменных должны осуществлять их фузификацию, а потреби- тели выходных переменных – дефузифи- кацию, если система нечетких правил все- го одна. Для вышеприведенной платформ- нонезависимой модели в результате при- менения трансформации автоматически сгенерированы шесть ролей: Поставщик- НечеткогоЗначенияТемпература и По- ставщикНечеткогоЗначенияПотребление, – измерение текущей температуры и уров- ня потребления соответственно и их фузи- фикация; ПотребительНечеткогоЗначе- нияТемпература и ПотребительНечетко- гоЗначенияПотребление – сбор нечетких значений, необходимых для осуществле- ния нечеткого вывода изменения степени открытия, ПоставшикНечеткогоЗначения- 1,0 0,0 -30º +30º0º -10º +10º Температура ОН НН Н ВН ОВ               1,0 0,0 0 1005025 75 Потребление ресурса (% от максимального) ОМ М СР Б ОБ   1,0 0,0 -10 +100-5 +5 Изменение степени открытия вентиля (% от максимального) -2,5 +2,5 ЗЗ НЗ О НО ЗО   Рис. 5. Функции принадлежности для нечеткого агента Таблица 2. База правил для агента Температура Потребление ресурса (% от максимального) ОН НН Н ВН ОВ ОМ ЗЗ М О НЗ СР ЗО НО О НЗ ЗО Б НО О ОБ ЗО   71 Експертні та інтелектуальні інформаційні системи  72 ИзмененияОткрытия, непосредственно осуществляющая нечеткий вывод и выра- батывающая необходимое нечеткое значе- ние, ПотребительНечеткогоЗначенияИз- мененияОткрытия – дефузификация по- лученного значения и его применения для закрытия/открытия вентиля. Описание уточненной ролевой модели, полученной на этапе анализа, частично приведено в табл. 3. Параметры-имена агентов-потре- бителей и поставщиков обозначены как FVC (fuzzy value consumer) и FVS (fuzzy value supplier) соответственно. Следует за- метить, что в такой модели, все взаимо- действия с координатором каталога (КК) – простые действия, так как модели взаимо- действия с КК, поддерживаемые основны- ми целевыми платформами включают со- ответствующие (статические) методы. Координатор каталога – специаль- ный агент, обеспечивающий регистрацию, и поиск предоставляемых прикладных сервисов. В качестве сервисов для порож- даемых ролей рассматриваются уведомле- ния об изменении нечеткого значения (не- четкого числа). Для регистрации использу- ется действие RegisterDF, выполняемое агентом-поставщиком, а для поиска серви- са и “подписки” на уведомления – дейст- вие SearchDF, выполняемое агентом- потребителем. В случае успешного поиска сервиса, агент-потребитель будет получать асинхронные сообщения со значением всякий раз, когда агент-поставщик заменя- ет значение нечеткой величины (получае- мое либо в процессе нечеткого вывода, ли- бо вводимое пользователем, либо снимае- мое с датчиков). Подобная архитектура позволяет создавать иерархические много- уровневые сети, где нечеткий вывод на каждом уровне рассматривается как сово- купность ролей поставщик-потребитель. Применим к уточненной ролевой модели трансформации, позволяющие по- лучить спецификации моделей внутри- агентного управления для каждой выбран- ной роли. На рис. 6 показаны полученные МВУ для ролей ПоставшикНечеткого- ЗначенияИзмененияОткрытия (a) и По- требительНечеткогоЗначенияИзмене- нияОткрытия (б). Рассмотрим, например, ситуацию, когда агент, выполняющий роль Потре- бительНечеткогоЗначенияИзмененияОтк- рытия находится в начальном (четком) состоянии. Выполнение МВУ на рис. 6 в ситуации когда поступает сообщение InformAboutSensedValuе приводит к размы- тому состоянию в котором принадлеж- ность состояния обозначенного Apply- Output составляет 0.6, принадлежность всех остальных состояний равняется нулю. Последовательные сообщения Acquitance- InformAgreement (запоздавшее сообщение об установлении “подписки” на постав- ляемое значение, пришедшее в неверном порядке) и InformAboutSensedValuе порож- дают размытое состояние, при котором наибольшую степень принадлежности имеет состояние Reset (0.39), что свиде- тельствует в пользу возможной ошибки и приводит к необходимости переустановить взаимодействие с агентом-поставщиком. Учет подобной неопределенности в случае четкой модели МВУ либо невозможен в принципе, либо приводит к значительному увеличению количества состояний, отра- жающих степень неопределенности при реакции на приходящие сообщения. В рассматриваемом примере соот- ветствующая модель включает четыре ти- па агентов (рис. 7): ПоставщикТемпера- туры, ПоставщикПотребления, выпол- няющие похожие роли ПоставщикНечет- когоЗначения; ПоставшикИзменениеОт- крытия, выполняющего роли Поставщик- НечеткогоЗначенияИзмененияОткрытия, ПотребительНечеткогоЗначенияТемпе- ратура и ПотребительНечеткогоЗначе- нияПотребление, и РегуляторВентиля, выполяющий одну важную роль – ПотребительНечеткогоЗначенияИзмене- нияОткрытия. Взаимодействие между агентами различных типов приведено в табл. 4. При этом Взаимодействует означает что тип агента, указанный в строке посылает со- общения агенту, тип которого обозначен в столбце таблицы. ПодписанНа обозначает, что тип агента в строке ожидает уведомле- ний об изменившихся нечетких значениях типа агента в столбце, поставщиком кото- рых он является. Експертні та інтелектуальні інформаційні системи   73 Таблица 3. Описание отдельных ролей нечеткого агента Схема роли ПоставщикНечеткогоЗначенияТемпература (ПоставщикНечеткогоЗначения- Потребление) Описание: восприятие входного четкого значения (температуры, уровня потребления), а также извещение об этом всех подписавшихся агентов. Успешная регистрация в КК будет проведена в течение всего времени жизни агента Протоколы и действия: RegisterDF, ReadCrispValue, FuzzifyValue, SensorValueAcquitanceRequest<T, FVS>, RegisterAcquitanceRequest, SensorValueNotification<T, FVS> Доступ: читает измеренное sensedCrispValue<T> // температура (уровень потребле- ния); поставленное consumerAID // идентификатор подписавшегося агента; поставленное conсeptTName Порождает фуззифицированное sensedFuzzyValue<T> // нечеткое значение температуры (уровня потребления) Схема роли ПоставшикНечеткогоЗначенияИзмененияОткрытия Описание: восприятие значения СIn, необходимого, чтобы установить положение венти- ля, а также передача извещения об этом всем подписавшимся агентам. Ус- пешная регистрация в КК будет проведена в течение всего времени жизни агента. Система нечетких правил срабатывает только при получении всех входных значений. Система правил срабатывает снова, если изменяется хотя бы одно входное значение Протоколы и действия: RegisterDF, CheckInputAvailability, FireRuleBase, SensorValueAcquitanceRe- quest<СIn, FVS>, RegisterAcquitanceRequest, SensorValueNotification<СIn, FVS> Доступ: читает поставленное consumerAID // идентификатор подписавшегося агента поставленное conсeptTName. Порождает нечеткое sensedFuzzyValue<T> – нечеткое значение изменения степени открытия, которое необходимо обеспе- чить Схема роли ПотребительНечеткогоЗначенияИзмененияОткрытия Описание: обрабатывает нечеткое значение CIn с целью его дефузификации для обеспе- чения необходимого положения вентиля, также установление взаимодействия с соответствующими агентами-поставщиками. Необходимо, чтобы был осу- ществлен успешный поиск понятия CIn в онтологии КК. Обрабатывает значе- ние sensedFuzzyValue<CIn> когда оно – не пустое Протоколы и действия: SearchDF<CIn>, DefuzyfyValue, ApplyOutput, SensorValueAcquitanceRe- quest<CIn, FVS>, SensorValueNotification<СIn, FVS> Доступ: читает поставленное sensedFuzzyValue<CIn> // нечеткое выходное значение. Порождает и применяет дефузифицированное sensedCrispValue<CIn> // вы- ходное значение, которое необходимо обеспечить Експертні та інтелектуальні інформаційні системи a б Рис. 6. Модели внутриагентного управления для ролей: а – ПоставшикНечеткогоЗначения- ИзмененияОткрытия; б – ПотребительНечеткогоЗначенияИзмененияОткрытия Генерация кода мультиагентной системы Порождение кода мультиагентной системы состоит из двух трансформаций – выполнения ряда преобразований модель- модель с целью получения платформно- специфической модели нечетких агентов и запуска последующих трансформаций “модель-код” для получения текста про- граммы целевого агента. Для тестирования возможностей нечеткой системы одного агента, подхо- дящей целевой платформой также является MATLAB/Simulink [25]. Такая среда по- зволяет моделировать всю систему от- дельного агента с помощью композиции функциональных блоков системы нечетко- го логического вывода. Однако, MATLAB/Simulink – не предназначена для разработки мультиагентных систем и не обладает средствами для разработки таких важных аспектов как распределенность, коммуникация и др. Поскольку нашей задачей является  74 Експертні та інтелектуальні інформаційні системи Поставщик НечеткогоЗначения Температуры Поставщик НечеткогоЗначения ИзмененияОткрытия Потребитель НечеткогоЗначения ИзмененияОткрытия Поставщик НечеткогоЗначения Потребления Поставщик Температуры Поставшик ИзменениеОткрытия Регулятор Вентиля Поставщик Потребления Потребитель НечеткогоЗначения Температура Потребитель НечеткогоЗначения Потребление   Рис. 7. Модель типов агентов Таблица 4. Взаимодействие между типами нечетких агентов Типы нечетких агентов Поставщик- Температуры Поставщик Потребления Поставщик- Изменение- Открытия Регулятор Вентиля ПоставщикТемпературы ----- ----- Взаимодействует ----- ПоставщикПотребления ----- ----- Взаимодействует ----- ПоставщикИзменениеОткры- тия Взаимодействует ПодписанНа Взаимодействует ПодписанНа ----- Взаимодействует РегуляторВентиля ----- ----- Взаимодействует ПодписанНа ----- трансформация нечетких агентов в целе- вую платформу, поддерживающую нечет- кий логический вывод, приведем непо- средственно реализацию системы правил, полученных на языке FCL (Fuzzy Control Language, Язык нечеткого управления) в результате трансформации платформоне- зависимой модели (рис. 8). FCL – единственно стандартизиро- ванный предметно-ориентированной язык для спецификации систем нечеткого логи- ческого вывода [17]. Хотя FCL не позволя- ет описывать императивные операторы, ограничиваясь (как и MATLAB) система- ми логического вывода Мамдани и Така- ги–Сугено [24, 25], его основное преиму- щество – наглядность и простота, а также наличие переносимых реализаций (в виде интерпретаторов) на языках Java и С++. FCL обеспечивает несколько методов фу- зификации и дефузификации переменных и спецификацию лингвистических термов. Однако, его нельзя рассматривать как единственно возможную целевую плат- форму по следующим причинам: 1) уни- фикация и упрощение языка приводит к ограничению способов логического выво- да и отсутствию набора базовых функций принадлежности, которые задаются не па- раметрически, а путем кусочно-линейной аппроксимации; 2) язык предназначен только для написания нечетких контролле- ров (систем управления) и не позволяет описывать иерархические системы харак- терные для сложных интеллектуальных систем. Поскольку FCL не обеспечивает всей функциональности, необходимой для функционирования агентов, порождается код на языке С++ (или на языке Java) для требуемой целевой платформы, который содержит вызовы интерпретатора FCL. В настоящее время известно много платформ для поддержки функционирования мульти-   75 Експертні та інтелектуальні інформаційні системи  76 FUNCTION_BLOCK УправлениеПодачейРесурса VAR_INPUT temp : REAL; consumption : REAL; END_VAR VAR_OUTPUT valve : REAL; END_VAR FUZZIFY temp TERM ОН := (-30, 1) (-10, 0); TERM НН := (-30, 0) (-10, 1) (0, 0); … // другие термы END_FUZZIFY FUZZIFY consumption TERM ОБ := (75, 0) (100, 1); TERM Б:= (50, 0) (75, 1) (100, 0); … // другие термы END_FUZZIFY DEFUZZIFY valve TERM ЗЗ := (-10, 1) (-2.5, 0); TERM НЗ := (-5, 0) (-2.5, 1) (0, 0); … // другие термы ACCU : MAX; METHOD : COGS; DEFAULT := 0; END_DEFUZZIFY RULEBLOCK No1 AND : MIN; RULE 1 : IF temp IS ЗЗ AND consumption IS ОМ THEN valve IS ЗЗ; RULE 2 : IF temp IS НН AND consumption IS М THEN valve IS О; RULE 3 : IF temp IS Н AND consumption IS Б THEN valve IS НО; RULE 4 : IF temp IS Н AND consumption IS ОБ THEN valve IS ЗО; . . . … // другие правила END_RULEBLOCK END_FUNCTION_BLOCK Рис. 8. Реализация системы правил системы нечеткого вывода для агента, управляющего по- дачей ресурса агентных систем – таких как Jason, 3APL, JACK и других [29, 30]. Следует заметить, что большинство этих платформ поддер- живает только архитектуру Убеждение- Желание-Намерение (Belief-Desire- Intention, BDI), которая воплощает один из основных видов делиберативных (“разум- ных” агентов) и содержит явно представ- ленную структуру данных, соответствую- щую этим трем указанным свойствам рас- суждений, применяемых агентом при ре- шении задач [8, 29, 30]. Привлекательность этого BDI- подхода снижается, поскольку был пред- ложен ряд других моделей, позволяющих устранить проблемы BDI-агентов, обзор которых приведен в [8]. Поэтому, в каче- стве целевых платформ выполнения сгене- рированных мультиагентных систем ис- пользуется кластерная система СКИТ-3 [19] и платформа JADE [18]. Последняя представляет собой фреймворк для про- граммирования распределенных открытых мультиагентных систем, взаимодействую- щих в соответствии со стандартами, разра- ботанными FIPA (Foundation for Intelligent Physical Agents, Организацией интеллекту- альных физических агентов) [3]. Поскольку, система СКИТ не со- держит специальной платформы для под- держки взаимодействия агентов, была соз- дана специальная библиотека на языке С++, включающая ряд шаблонов, классов и методов для организации поведения агентов – циклического, одноразового и многократного, а также для обмена раз- личными типами асинхронних сообщений с использованием MPI в качестве носите- ля. Трансформация МВУ в код агента для целевой платформы – автоматизированное преобразование “модель-текст”, создаю- щее класс агента и несколько классов Behaviour (Поведение) для каждой модели МВУ. Особенностью функционирования Експертні та інтелектуальні інформаційні системи   77 порождаемых агентов для СКИТ является то, что в отличие от JADE не используется язык ACL (агенты на кластере не взаимо- действуют с другими открытыми плат- формами), вместо этого генерируется код, выполняющий маршалинг/демаршалинг основных типов сообщений. Также, связы- вание сервисов с агентами-поставщиками выполняется во время компиляции, а не динамически, что позволяет сократить на- кладные расходы на обмен сообщениями. Для генерации текстовых файлов программ-агентов разработаны преобразо- вания “модель-текст” на основе текстовых шаблонов платформы XPand, запускаемых в контексте компонентов EMFT Workflow. Преимущество Xpand то, что он является независимым от исходной модели. Это оз- начает, что любая из программ-парсеров может быть использована для общих мо- делей программного обеспечения, таких как MOF или EMF. Такая трансформация генерирует методы поведения агента для получения и отправки сообщений и компо- зитные поведения нечеткой схемы перехо- дов, которые координируют выполнение простых поведений. Однако, средства представленной выше метамодели находятся достаточно далеко от средств программирования мультиагентной целевой платформы, такой как JADE. Поэтому для интеграции нечет- ких правил в среду выполнения указанных платформ используются преобразования, отображающее нечеткие правила в модель на основе JEM (Java EMF Model), позво- ляющей представить основные конструк- ции классов языка Java и платформы J2EE. Аналогичная промежуточная модель раз- работана и для С++. По сравнению с непо- средственной генерацией кода на основе исходных моделей, использование проме- жуточных моделей значительно упрощает создание текстовых шаблонов. Выводы Таким образом, нами изложен трансформационный подход, применяе- мый на различных стадиях разработки ин- теллектуальных агентов, в основе которого находятся модели нечетких правил. Сле- дуя моделе-ориентированному подходу, разработаны основные преобразования, позволяющие сгенерировать нечеткие платформно-независимые модели внутри- агентного управления и связанные с ними ролевые модели для распределенных ин- теллектуальных систем. Для спецификации нечетких моде- лей, не зависящих от рассматриваемой платформы реализации, создан проблемно- ориентированный графовый язык и сред- ства его инструментальной поддержки на основе среды Eclipse. Хотя нечеткие аген- ты, порождаемые в результате трансфор- мации для таких перспективных плат- форм, как FCL, JADE и среды суперком- пьютера СКИТ-3, имеют ряд отличитель- ных особенностей, трансформационный подход позволяет как учесть все эти вариа- тивные особенности реализации, так и обеспечить перенос разработанных моде- лей мультиагентных систем на вновь раз- рабатываемые агентные платформы и даже среды, не имевшие таких платформ (как в случае системы СКИТ). Важно, что предложенный транс- формационный подход охватывает основ- ные фазы разработки мультиагентных сис- тем (от выявления требований до реализа- ции), переход одной фазы в другую осуще- ствляется с помощью преобразований не- четких моделей. В результате, модели ка- ждой из фаз обогащают информацией, по- степенно приводящей к реализации адап- тивных интеллектуальных агентов. 1. Perini А., Susi A. Automating model trans- formations in agent-oriented modeling // Agent-oriented software engineering VI. Lec- ture notes in computer science. – Springer, 2006. – P. 167–178. 2. Pavon J., Gomez-Sanz J. Agent-oriented software engineering with INGENIAS // Mul- ti-agent system and applications III. Lecture notes in computer science. – Springer, 2003. – P. 8–38. 3. FIPA abstract architecture. – http://www.fipa.org/specs/fipa00001/ 4. Чарнецки К., Айзенкер У. Порождающее программирование: методы, инструменты, применение. – СПб.: Питер, 2005. – 731 c. 5. Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обес- Експертні та інтелектуальні інформаційні системи  78 печения. – М.: Московский физико- технический институт, 2006. – 304 с. 6. Основы инженерии качества программных систем / Ф.И. Андон, Г.И. Коваль, Т.М. Коротун, Е.М. Лаврищева, В.Ю. Су- слов // 2-е изд. – Киев: Академпериодика, 2007. – 672 с. 7. Kleppe A., Warmer J., Bast W. MDA Ex- plained. The model driven architecture: prac- tice and promise. – New York: Addison- Wesley Professional, 2003. – 192 p. 8. Парасюк И.Н., Ершов С.В. Нечеткие моде- ли мультиагентных систем в распределен- ной среде // Проблеми програмування. – 2010. – № 2–3. – C. 330–339. 9. Парасюк И.Н., Ершов С.В. Моделе- ориентированная архитектура нечетких мультиагентных систем // Компьютерная математика. – 2010. – № 2. – C. 62–74. 10. Ершов С.В. Принципы построения нечет- ких мультиагентных систем в распреде- ленной среде // Там же. – 2009. – № 2. – C. 54–61. 11. Ершов С.В. Трансформационный подход к разработке адаптивных интеллектуальных агентов на основе нечетких схем перехо- дов // Компьютерная математика. – 2011. – № 1. – C. 69–78. 12. Парасюк И.Н., Ершов С.В. Теоретико- категорная формализация при проектиро- вании нечетких интеллектуальных систем // Кибернетика и системный анализ. – 2009. – № 6. – C.149–154. 13. Eclipse Process Framework Project (EPF). – http://www.eclipse.org/epf/ 14. Якобсон А., Буч Г., Рамбо Дж. Унифици- рованный процесс разработки программ- ного обеспечения. – СПб.: Питер, 2002. – 496 с. 15. Software and Systems Process Engineering Metamodel specification (SPEM) Version 2.0. - http://www.omg.org/spec/SPEM/2.0/ 16. SWEBOK. – http://www.swebok.org. 17. International Electrotechnical Commission (IEC). Technical Committee No. 65: Indus- trial Process Measurement and Control. IEC 1131 – Programmable Controllers Part 7 – Fuzzy Control Programming. – http://www.fuzzytech.com/binaries/ieccd1.pdf 18. Bellifemine F., Caire G., Greenwood D. De- veloping Multi-Agent Systems with JADE. – Chichester: John Wiley & Sons Inc, 2007. – 303 p. 19. Суперкомпьютеры ИК НАН Украины. – http://icybcluster.org.ua. 20. Sendall S., Kozaczynski W. Model transforma- tion: the heart and soul of model-driven soft- ware development // IEEE Software. – 2003. – Vol. 20, № 5. – P. 42–45. 21. Eclipse Modeling Framework. – http://wiki.eclipse.org/EMF/ 22. MOF 2.0/XMI Mapping. – http://www.omg.org/spec/XMI/2.1.1/ 23. OMG MetaObject Facility. – http://www.omg.org/mof/ 24. Рутковская Д., Пилиньский М., Рутков- ский Л. Нейронные сети, генетические ал- горитмы и нечеткие системы. – М.: Горя- чая линия – Телеком, 2004. – 452 с. 25. Леоненков А.В. Нечеткое моделирование в среде MATLAB и fuzzyTECH. – СПб.: БХВ, 2005. – 736 с. 26. Graphical Modeling Framework. – http://www.eclipse.org/modeling/gmp/ 27. Eclipse Modeling TMF. – http://www.eclipse.org/modeling/tmf/ 28. Application Design Patterns: Producer/Con- sumer. – http://zone.ni.com/devzone/cda/tut/p/id/3023/ 29. Sterling L., Taveter K. The Art of Agent- Oriented Modeling. – Cambridge: MIT Press, 2010. – 367 p. 30. Wooldridge M.J. An Introduction to Multi- agent Systems. – Cambridge: MIT Press, 2002. – 366 p. Получено 03.02.2011 Об авторах: Парасюк Иван Николаевич, член-корреспондент НАН Украины, профессор, заведующий отделом, Ершов Сергей Владимирович, кандидат физико-математических наук, старший научный сотрудник. Место работы авторов: Институт кибернетики имени В.М. Глушкова НАН Украины, 03187, Киев-187, Проспект Академика Глушкова, 40. Тел.: (044) 526 5168 И.Н. Парасюк, С.В. Ершов Рассматривается трансформационный подход, применяемый на различных стадиях разработки интеллектуальных агентов, в основе которого находятся модели нечетких правил. Описаны трансформации, позволяющие сгенерировать нечеткие платформно-независимые модели внутриагентного управления и связанные с ними ролевые модели. Рассмотрены способы создания в среде Eclipse средств поддержки проблемно-ориентированного графового языка для спецификации нечетких моделей, не зависящих от используемой платформы. Значительное внимание уделяется архитектурным особенностям нечетких агентов, порождаемых в результате трансформации для перспективных платформ.

Similar Items