CC BY
94
УДК 004.42.02 + 004.4 ББК 32.973-018
МНОГОАГЕНТНАЯ МОДЕЛЬ СРЕДЫ ПОДДЕРЖКИ ПРОГРАММНОГО ПРОДУКТА ДЛЯ СИСТЕМ СО СЛОИСТОЙ АРХИТЕКТУРОЙ
Гурьянов В. И. 1
(Региональный институт психологии и гуманитарных наук, Чебоксары)
Рассмотрена проблема адаптивности программных продуктов. Изучено решение, использующее композиционную адаптацию и метод расширения ядра. Рассмотрена среда поддержки продукта как многоагентная система с одноуровневой архитектурой.
Ключевые слова: адаптивная программная система, композиционная адаптация, слоистая архитектура, многоагентная система, социотехническая система.
1. Введение
Большинство специалистов сходятся в том, что программные системы следующего поколения будут адаптивными. За последние 3-4 года рядом ведущих исследовательских центров предложены разнообразные методы создания адаптивных программных систем (adaptive software) [8]. Несмотря на это, целостная методология проектирования подобных систем пока находится в стадии зарождения.
Концептуальной основой новых методологий могут стать кибернетика и теория развития сложных систем. В частности, начиная с 2004 года, сформировалось направление, известное
1 Гурьянов Василий Иванович, соискатель (vg2007sns@rambler.ru).
как программная кибернетика, которое ставит цель решить эти проблемы [11]. На текущем этапе развития этого направления большой интерес представляют модели эволюции программного продукта, допускающие строгое математическое описание.
Перспективным в этом отношении может оказаться изучение программных систем, архитектура которых определяется паттерном «выделение слоев» [3]. В [2] предложена методология проектирования модельных адаптивных программных систем, основанная на методе расслоения класса системы по интерфейсам (метод расширения ядра) в рамках парадигмы порождающего программирования [5]. За пределами этого исследования остался вопрос о способах формирования базы конфигураций программной системы.
В данной работе показано, что адаптивные программные системы не могут рассматриваться в отрыве от среды своего существования. База конфигураций есть результат развития среды поддержки продукта. Предложена методика проектирования среды поддержки адаптивного программного продукта как многоагентной системы.
2. Интерфейсная модель адаптации
Приведем некоторые понятия, необходимые для дальнейшего изложения [2].
С тем чтобы формализовать взаимодействие информационной системы с бизнес-процессом, будем исходить из интерфейсной модели обмена сообщениями между подсистемами. В UML для моделирования стыковочных узлов в системе используются интерфейсы (см. рис. 1).
Рассмотрим процесс адаптации 5-элемента в паре S(m, 5). Соотнесем т с бизнес-процессом, а 5 - с информационной системой. Комплекс будем рассматривать как систему, взаимодействующую с окружающей средой. В рамках данного исследования т-элемент будем рассматривать как заданный и
неизменный. Напротив, 5-элемент может изменять свою структуру и состав.
Определение 1. Рассмотрим интерфейс подсистемы с точки зрения задач, решаемых программной системой. Под отдельным интерфейсом f будем понимать набор функций подсистемы, предназначенных для решения одной задачи (что, собственно говоря, совпадает с понятием интерфейса в UML). Под интерфейсом подсистемы в данной статье будем понимать кортеж I = (f,f1, ...,f), f - отдельные интерфейсы. Каждому интерфейсу f сопоставим идентификатор и будем обозначать его той же буквой. Всюду, где не указано обратное, будем понимать f как идентификатор интерфейса.
Приведенное выше определение интерфейса отражает прагматический аспект взаимодействия. Вместо бизнес-процесса можно рассматривать варианты использования (Use case). В этом случае интерфейс соединяется с тем Use case, который его поддерживает.
Определим способ выделения интерфейсов. Предлагается метод, который можно назвать методом делегирования инфор-
мационных функций от бизнес-процесса к информационной системе. Концепция метода состоит в том, что пара S(m, s) рассматривается как эволюционирующая система, направление развития которой определяется возрастанием степени специализации элементов m и s. Делегирование осуществляется дискретным образом как передача информационных функций. Допустим, что s-элемент пары специализируется на обработке информации, а m-элемент - на функциях производства. Начальное состояние - все информационные функции считаются интегрированными в бизнес-процесс и входят в состав его бизнес-функций. Таким образом, важна последовательность появления интерфейсов в I = f),fb ...,fn), что отражено в определении. Интерфейсы образуют иерархическую структуру, для описания которой будем использовать онтологический подход (т. е. f будем определять так, чтобы идентификаторы могли быть обработаны программной системой; например на базе DSL).
Пример 1. На рис. 1. представлены два варианта одного бизнес-процесса, которые обозначены как Shemel и Sheme2. Интерфейсы I21 и I22 находятся в отношении обобщения с I1. Бизнес-процессы не детализированы, напротив, программная система s представлена в виде диаграммы классов.
Определение 2. Интерфейсы, которые реализуют основную функцию программной системы, обозначим идентификатором f). Будем говорить, что два бизнес-процесса являются схожими (с точки зрения программной системы), если в интерфейсе бизнес-процесса I(m) присутствует один и тот же идентификатор f). Схожие бизнес-процессы, отличающиеся составом интерфейсов, будем называть вариантами рассматриваемого бизнес-процесса. В примере 1 это Shemel и Sheme2.
Пример 2. Для бизнес-процесса «Хранение» идентификатор f) будет обозначать интерфейс, который обрабатывает сообщения ПОСТУПЛЕНИЕ, ВЫДАЧА, ХРАНИМОЕ_КОЛИ-ЧЕСТВО и запрос СООБЩИТЬ ХРАНИМОЕ_КОЛИЧЕСТВО. Решаемая бизнес-процессом задача - задача управления, т. е. выдача команд на выполнение функций ПРИНЯТЬ, ВЫДАТЬ.
Вариант использования (Use case) можно определить как «Учет». Прочие интерфейсы появляются на второй и последующих итерациях делегирования информационных функций. Интерфейсом может быть совокупность методов обработки сообщений для задач снабжения, сбыта, планирования или отчетности (Use cases: «Закупка», «Анализ спроса», «Эффективность использования склада» и др.), так как необходимость решения этих задач определяется особенностями бизнес-процесса.
Информационная система предназначена для обслуживания бизнес-процесса и должна соответствовать некоторому набору требований, который обозначим как Z и будем в дальнейшем называть спецификацией программной системы. Определим спецификацию, выданную m-элементом пары, как Z = (/о,/1, . ., fn), причем Z = I(m). Рассмотрим три аспекта связи m и s: прагматический, семантический и синтаксический. Согласно принципу подчиненности процесс адаптации начинается с прагматического аспекта. Сделаем следующее предположение: адаптация системы обусловлена прагматическим аспектом интерфейса подсистемы, т. е. составом и последовательностью появления элементов в I(m) = f),f1, ...,f,). Далее допустим, что адаптация в семантическом и синтаксическом аспектах происходит мгновенно (по сравнению со временем реорганизации s-элемента).
Под структурной адаптацией будем понимать процесс реструктуризации программного обеспечения w таким образом, чтобы его интерфейс соответствовал заданному, т. е. I(w) = Z. Будем также полагать, что после адаптации сохраняется соотношение I(m) = Z. В частности, развитие информационной системы можно рассматривать как структурную адаптацию. Следует различать программное обеспечение w и s-элемент пары.
Для управления сборкой необходимо определить связь интерфейса объекта I(s) с его структурой. Во многих случаях описание этой связи вызывает значительные трудности и явля-
ется основным препятствием для построения модели системы. Данная проблема может быть решена для слоистых структур.
Особенность слоистых структур состоит в направленности связей со слоя i на слой i + 1, но не наоборот [3]. Для определения слоев предложен метод расслоения класса по идентификаторам спецификации Z = (f0,f1, ...,fn). Метод основан на последовательном применении наследования к классу продукта T, причем с каждым слоем будем связывать один интерфейс с идентификатором f е Z. Пример такой архитектуры (классы Nulcleus, FirstLayer и т. д.) приведен на рис. 1.
Фактически данный метод представляет собой объектноориентированное обобщение метода расширения ядра. В качестве аналога метода можно рассматривать итерационную процедуру построения структуры организации посредством делегирования обязанностей. Метод расширения ядра достаточно эффективен в процессе проектирования небольших офисных приложений. Предлагаемое решение позволяет создавать адаптивные программные системы, удобные для теоретического анализа. В [2] приведен пример такого приложения для среды динамического программирования Smalltalk.
Обозначим слои буквами алфавита VT = {a0, a1, ..., an} некоторого формального языка Lu, множество идентификаторов интерфейсов обозначим как P. Сопоставим каждой букве алфавита ai е VT идентификатор f е P и обозначим множество пар (ai,f) как F, а фактор-множество как VT/F = {f0|{a1, a2, ..., ak}, /1|{Ьь *2, ., M, .,fN{z1, Z2, ., Zm}}, где a;, bj, ., Zj е Vt. Далее, сопоставим каждой букве ai е VT упорядоченную пару Li = ({lb ..., In}, {Г1, ..., rMi}), где l - левые (входные), r - правые (выходные) связи. Обозначим алфавит связей как VL, а множество пар Li как L. Пятерка J(VT, VL, P, F, L) определяет механизм сборки системы s.
Рассмотрим характерный частный случай, когда процесс формирования архитектуры программной системы может быть представлен орграфами. Для описания ориентированного дерева сборки удобна следующая реляционная запись.
Определение 3. Проблема адаптации может быть решена, если класс Т продукта 5 имеет множественный интерфейс
1(Т) = {1х}1е3, 3 - множество индексов. Адаптация сводится к выбору одного из интерфейсов. Далеко не все языки программирования поддерживают множественные интерфейсы. Более того, создать такой класс для программной системы можно только в некоторых частных случаях. Для систем динамического программирования может быть выполнена эмуляция множественного интерфейса.
Введем для I. е 1(Т), I. = (/0,/1, ...,/д) кортеж вида <х = ((/0, а.), (/.ь Ь.), ., (/д, г.)), / е Р, а., Ь., ., г. е Ут (далее -сегмент) и составим множество О = {<1, <2, • ••, <м} из всех <х, 1 е 3. Будем называть его базой конфигураций объекта 5. Можно говорить об отображении X: О ® 1(Т). Пусть Я = Х1^. Таким образом, задача адаптации продукта 5(Т) будет решена, если задано отображение X и правило выбора < е Я. О сегменте < будем говорить как об активном сегменте О. С точки зрения объектно-ориентированного программирования имеет место динамическое порождение класса Т'с единственным интерфейсом ДТ') = 2.
Когда 5-элемент пары получает спецификацию 2 от т-элемента, инициируется субпроцесс «проектирование», который сводится к выполнению отображения Я = Хг(2 и, если необходимо, выбору < е Я. Затем проект системы < = ((/0, а.), (/х1, Ьх), ., (/хд, •£.)), X е Л, передается в субпроцесс «рекомпозиция», который синтезирует класс Т' программной системы с интерфейсом 1(м>) = (/0,/х1, ...,/хд), X е 3. По завершению процесса сборки классов производится перезагрузка программной системы с сохранением актуального состояния («регенерация»). В итоге, изменение спецификации 2 приводит к изменению структуры w так, что равенство I(м>) = 2 будет выполнено, что и позволяет говорить об адаптивности 5.
Реляционная запись процесса сборки классов позволяет свести процесс адаптации к выполнению автоматических процедур.
3. Среда существования продукта как многоагентная система
Поставим теперь вопрос о формировании базы конфигураций программной системы.
Отдельный бизнес-процесс, как правило, может поддерживать разработку только одного сегмента О. С другой стороны описанная выше модель адаптивности эффективна только при условии, что О имеет более одного сегмента. Рассмотренная выше модель адаптивной системы будет не полной, если не рассмотреть способ формирования базы конфигураций О = {<1, <2, ..., <м}. Каждый сегмент <х должен соответствовать одной ветви сборки и ветвь должна быть верифицирована.
Определение 4. Предположим, что в общем случае производство базы конфигураций должно быть результатом кооперации всех пользователей системы 5. Тогда централизованная и децентрализованная разработка программного обеспечения будет частным случаем такой кооперации. Множество всех пользователей одной и той же адаптивной программной системы будем называть средой существования программного продукта. Если среда существования продукта рассматривается в контексте обеспечения инжиниринга, то будем говорить о среде поддержки продукта.
Несмотря на множество работ в области программной кибернетики, модель среды существования адаптивной программной системы как самостоятельная проблема еще не рассматривалась [11].
Методология проектирования такой системы будет определяться парадигмой агентного программирования [10]. Проектирование многоагентной системы (далее МАС) для среды существования продукта имеет ряд особенностей. Рассмотрим ключевые отличия.
Разработку МАС начнем с того, что в роли агентов будем рассматривать объекты адаптивной программной системы.
Согласно определению, онтология должна обеспечивать формирование словаря терминов, допускающих интерпретацию программной системой. Будем выделять онтологию требований (спецификация и смысл идентификаторов интерфейсов fi) и онтологию конфигураций. Онтология конфигураций зафиксирована в базе конфигураций D.
Онтологический инжиниринг (например, методология системы Protege) предполагает формирование законченной базы знаний, которая затем только используется агентами. Напротив, в рассматриваемом случае формирование онтологий - это основная функция многоагентной системы. Поэтому часть средств разработки онтологий должна быть включена в функциональность агентов. Отметим, что эта особенность сближает рассматриваемую многоагентную систему с системами распределенного искусственного интеллекта.Таким образом, ключевым вопросом проектирования многоагентной системы следует считать уточнение онтологического инжиниринга. Выделяют следующие значимые свойства онтологии: существенность (охват предметной области), непротиворечивость, независимость от реализации, декларативность, расширяемость, ясность.
Поддержание корректности и целостности, непротиворечивости и расширяемости онтологий можно обеспечить путем жесткого (неизменяемого) определения обязательств агентов.
Обозначим множество пар S(mm, sm), /те H (H - множество индексов), имеющих общий интерфейс /о, как X. Пусть на множестве X существует некоторое подмножество активных пользователей, т. е. таких, которые могут вносить изменения либо в базу конфигураций D системы, либо в ее компоненты a е VT. Допустим, что между элементами X существует возможность передачи базы конфигураций и может быть определена некоторая операция объединения баз. Обозначим обновляемую базу конфигураций как Dm+, а некоторую другую - как Dv-. В случае слоистых структур можно ввести специальную операцию соединения К: (Dm+, D— ® (D+, Dy') [1]. Данная операция эмулирует множественное наследование. Регенерация системы по
Dm+' = K1(Dm+, Dy) приведет к обновлению модулей системы, причем интерфейс системы, определяющий адаптацию, сохранится. По Dy' = K2(Dm+, DjT) регенерация системы невозможна, этот вариант базы конфигураций удобен для транспортировки (и тем самым операция К обеспечивает самодостаточность системы).
Итак, можно определить следующий шаблон проектирования многоагентной системы. Зададим четыре основных типа агентов: два реактивных агента D+ и D- и два интеллектуальных агента S(m, s) и S (m, s) в роли заказчика и в роли исполнителя соответственно. Взаимодействие агентов D+ и D- определяется операцией соединения. Агенты S(m, s) и S'(m, s) должны иметь некоторые ментальные свойства. Будем рассматривать многоагентные системы с одноуровневой (полностью децентрализованной) архитектурой.
Протокол исполнителя S (m, s) предполагает: а) сбор сведений посредством стандартного сервиса сети о множестве X; б) рассылку предложений; в) протокол рассылки D-.
Протокол заказчика S(m, s) - протокол ведения переговоров для модели контрактных сетей [9]. В основе модели лежит простейшая идея рыночных торгов. В этом случае S(m, s) выступает в роли агента-менеджера, а S (m, s) - как агент-исполнитель. Агент-менеджер отбирает самые выгодные для него предложения (по ожидаемой степени соответствия I(w) = Z) и заключает соглашение с выбранными агентами-исполнителями на поставку D-.
Язык коммуникации для агентов S(m, s) и S '(m, s) может быть KQML (Knowledge Query and Manipulation Language).
Отдельным вопросом является проблема существенности предметной онтологии. Именно достижение существенности и является целью МАС. Можно ожидать, что эволюция МАС приведет к выработке некоторой «универсальной» базы конфигураций, которая обеспечит существенность предметной онтологии. С тем чтобы исследовать возможные варианты эволюции,
составим математическую модель МАС. Будем придерживаться подхода, использованного в [б, 7].
Рассмотрим все возможные варианты баз конфигураций, которые могут появиться на множестве пользователей X. Данное множество обозначим как W. Пусть в каждой паре S(mu, su) реализуется один из интерфейсов {Ik}k,=K, K - множество индексов. Обозначим соответствующее фактор-множество как {Xk: k є K}, Nk - количество пар в Xk.
Зададим отображение множества индексов Л = {0, 1, ..., N} на W. В W выделим некоторые подмножества. Ситуацию, когда база конфигураций пустая, будем отмечать индексом 0 и обозначим символом D0 є W. Если база конфигураций D = (dl) определяет слово из одной буквы dl = {(/0, a)}, соотнесенной с интерфейсом /0, то положим, что D є Wdist и индексируются элементами подмножества Л^ Первые два случая соответствуют начальным состояниям среды. Если Wdist содержит более одного элемента, то программные продукты имеют одинаковые функции, но отличаются ядром системы.
Пусть u/k) - количество s-элементов, имеющих базу конфигураций вида І є Л и входящих в Xk. Допустим, что Nk = const, k є K. Для описания эволюции среды запишем динамическую систему в виде (v/k) = u.(k)/Nk, u/k) = Vi(k)Nk, Vi(k) ® u/k)), du (l) N
-----1— = u.(l)[2 —-Z(-b..(k) + b ..(k))u (k)]-
Ы1 Ж 1 к Ы1 . 1} }1
- (2а..V))/(и.V)) + 2а..V)/(и .(1)),
11 ї ї 11 I 1
2 и ,(к) = 1, "к є К,
..
где верхний индекс при переменных указывает на индекс фактор-множества {Хк: к є К}, /(и.) ~ иСистема уравнений разбивается на блоки по индексу группы Хї, ї є К. В каждом блоке ї используются переменные и®, ї є Л.
Смысл коэффициентов следующий. Пусть некоторая пара £(та, 5а) с базой конфигураций / получает базу конфигураций у от некоторой пары £(т^, 5д) и возможна замена базы конфигураций / на у. Интенсивность этого процесса Ь*/к), I = к (матрица предпочтений). Возможна диффузия баз конфигураций за границы хк. Интенсивность диффузии из хк в X определяется значениями 6г/к), I Ф к. С другой стороны, если текущая структура 5-элемента не соответствует требованиям бизнес-процесса, возможна модификация базы конфигураций / ® у. Этот процесс опишем матрицей модификаций а^.
Универсальная база конфигураций Би = (Оь О2, ..., Ом} соответствует устойчивому стационарному состоянию динамической системы. Таким образом, можно говорить, что требуемое состояние в многоагентной системе, по крайней мере, существует.
Итак, описанная выше многоагентная модель среды существования продукта обеспечивает механизм формирования онтологий и может служить шаблоном проектирования МАС.
4. Методология проектирования
В настоящее время предполагается, что адаптивные программы могут быть реализованы локально, в рамках отдельных бизнес-процессов. Анализ модели позволяет сформулировать альтернативное утверждение. Адаптивные программные системы должны проектироваться и эксплуатироваться как распределенные системы поддержки инжиниринга.
Таким образом, методология проектирования адаптивных систем, наряду с традиционными для порождающего программирования разделами инженерии, должна включать также методологию проектирования многоагентной системы.
Уточним задачу проектирования. Вернемся к динамической системе, описывающую эволюцию онтологий в МАС. Конечное состояние среды определяется набором устойчивых стационарных состояний. Однако их достижение может потребовать
значительного времени. Время достижения состояния - это один из показателей среды поддержки продукта; его значение должно быть минимальным.
Введем пространство визуализации для множества х как декартово произведение К х Л. Потребуем, чтобы конечное состояние и/к) Ф 0, / е Лк, для каждой группы хк, к е К, было единственным. В подпространстве решений возможно два предельных случая: а) «мозаика» - общая база конфигураций в границах хк и разная для разных к е К; б) «полоса» - общая для всех хк универсальная база конфигураций Ви. И в том и в другом случае базы конфигураций равноценны с точки зрения интерфейса. Однако последний вариант базы конфигураций предпочтительнее по следующим двум причинам: а) для поддержки программного обеспечения используются ресурсы всех х пользователей; б) при колебаниях интерфейса бизнес-процесса (/ ®/) адаптация системы не потребует повторного расхода ресурса. Можно также сказать, что универсальная база конфигураций задает всю линейку продукта.
Проектируемая среда поддержки продукта будет находиться между этими двумя крайними случаями. Шаблон обеспечивает кооперацию агентов МАС для решения одной задачи - формирование онтологий множества х. С другой стороны внешние факторы - организационные структуры, финансовые отношения, технические ограничения и др. - формируют свои сообщества. Параметрами проектирования выступают внешние факторы МАС, которые накладывают разного рода ограничения на характер обмена базами конфигураций. Для проектирования вторичного сообщества можно использовать методологию нисходящего проектирования [4]. В качестве социальных критериев достаточно выбрать базовые типы взаимодействия агентов [7].
Пример. Пусть УТ = {а, Ь, с}, Р = {/0,/1,/2}, Ут& = {/0|{а}, /1|{Ь},/2|{с}}. Множество интерфейсов на множестве пользователей х будет {/1, /2}, / = (/0, /1), 12 = (/0, /2). Распределим пары по
группам согласно их интерфейсам, фактор-множество будет
{/1|хЬ /2|х2}.
Множество баз конфигураций О = {£0, £ь £2, £3}, где £0 -символ пустой базы конфигураций, £ = {((/0, а))} - база конфигураций неадаптированной системы, £2 = {((/0, а), (/1, Ь))} и £3 = {((/0, а), (/2, с))} - база конфигураций для слов аЬ и ас (причем /(аЬ) = /1, /(ас) = /2), £>4 = {((/0, а), (/1, Ь)), ((/0, а), (/1, с))} -универсальная база конфигураций. Динамическая система будет иметь восемь уравнений - по четыре для каждой из групп х1, Х2.
Пусть в начальном состоянии все пары имеют базу конфигураций £1. Проследим за изменением базы конфигураций одной пары Б(тм, 5т), входящей, например, в группу Х1. Если в х1 уже существуют адаптированные системы и их база конфигураций доступна (переменная и2(1) > 0 или и4(1) > 0), то возможна замена £1 ® £2 и £1 ® £4, т. е. Ь12(1), Ь14(1) > 0, Ь21(1) = Ь41(1) = 0.
Развитие программного обеспечения может быть выполнено непосредственно в 8(тт, 5т), т. е. £1 ® £2, значение а12 > 0, а21 = 0. С другой стороны, 8(тм, 5т) может получить базу конфигураций £3 (переменная из(1) > 0) из группы Х2 (переменная и3(2) > 0) и выполнить его модернизацию до £4 (а14 > 0, а14 » а12). Последний случай наиболее интересен, так как он демонстрирует способ возникновения универсальной базы конфигураций £4.
Требуемое конечное состояние системы есть и0 = и1 = и2 = = и3 = 0, и4 = 1, причем время достижения этого состояния должно быть меньше характерного времени изменения бизнес-среды.
Пусть количество пользователей достаточно велико (техническое ограничение). Другие какие-либо внешние ограничения на множестве X отсутствуют. В качестве типа сообщества можно выбрать эгалитарную структуру в форме координируемого сотрудничества. Обмен словарями спецификаций и базами конфигураций будет организован через доски объявлений.
На том же множестве X могут формироваться и другие сообщества. Например, корпорация, имеющая множество филиалов и заинтересованная в создании универсальной базы конфи-114
гураций, может создать свое сообщество в форме простого сотрудничества.
В заключение приведем эталонную модель проектирования. Адаптивная программная система представляет собой систему с распределенной средой поддержки продукта. Экземпляры системы расположены в узлах сети. Программная система функционирует в системе динамического программирования типа CLOS, Python, Open Java. Инсталляция программной системы имеет место при загрузке соответствующей базы конфигураций в оболочку s программной системы и ее активизацию при выборе начальной спецификации Z. Адаптивная система в режиме эксплуатации производит модификацию своей архитектуры таким образом, чтобы ее функции соответствовали меняющейся спецификации Z.
Адаптивная система может выступать как в роли эксплуатируемой системы, так и в роли системы разработки. Роли могут изменяться. Жизненный цикл эксплуатируемой системы соответствует спиральной модели и включает следующие этапы: разработка требований, проектирование, конструирование, тестирование, сопровождение. Все этапы, кроме разработки требований, носят автоматический характер. Разработка требований - единственный процесс, требующий присутствия инженера.
Разработка требований состоит из сбора требований и анализа требований. Сбор требований выполняется согласно общей методологии (например, методом А. Джекобсона). Анализ требований (определение объектов системы), напротив, автоматичен. Точка соприкосновения лежит на соответствии Use cases (неформальное описание) с их спецификацией (формальное описание). Спецификация Use cases осуществляется инженером на основе словаря онтологии требований. Обновление и расширение словаря онтологии требований - функция среды поддержки продукта.
Сопровождение включает: а) коммуникации посредством МАС (в том числе формирование вторичных сообществ); б)
получение другой базы конфигураций и выполнение операции соединения (при необходимости); в) контроль регенерации системы. Сопровождение выполняется в автоматическом режиме.
Жизненный цикл системы как системы разработки продукта соответствует спиральной модели. Кроме того, включает процесс рассылки обновления для словаря онтологии требований. Этот процесс можно назвать презентацией решения. Подчеркнем, что внесение изменений в словарь онтологии требований допускается только при модификации базы конфигураций.
Весь процесс адаптации предполагает минимальное участие человеческого фактора, что обеспечивает надежность и низкие стоимостные показатели модификации программной системы.
5. Выводы
В статье рассмотрена методология проектирования адаптивных программных систем, архитектура которых основана на методе расширения ядра. Показано, что адаптивный программный продукт должен рассматриваться только вместе с распределенной системой поддержки продукта. Таким образом, адаптивная программная система представляет собой социотехническую систему, целостность которой поддерживается агентными технологиями.
Приведенная выше методология может быть применена для разработки приложений на основе языков, допускающих динамическую рекомпозицию. Рассмотренная методология имеет много общего с методологией, известной как «фабрики приложений» (Software Factories). Концептуальные отличия следующие: а) фиксированный архитектурный каркас; б) использование онтологий вместо базы рекомендаций; в) определение архитектуры фабрики в контексте среды существования продукта.
Следующим шагом развития методологии может стать перенос методов в сферу проектирования «больших» программ-
ных систем. Очевидный путь - формулировка методов для программ, использующих платформу промежуточного слоя. Однако более продуктивным и более естественным обобщением методологии вероятнее всего будет определение методов для платформ агентного программирования.
Литература
1. ГУРЬЯНОВ В. И., Адаптивная сборка класса / Современные информационные технологии в науке, образовании и практике. Материалы IV всероссийской конференции. -Оренбург: ИПК ГОУ ОГУ, 2007. - С. 31-32.
2. ГУРЬЯНОВ В. И., Адаптивная информационная система для модельной задачи управления стеком / Информационные технологии моделирования и управления. - Воронеж: Изд-во «Научная книга», 2008. - № 1(44). -С. 52-61.
3. КСЕНЗОВ М. В. Рефакторинг архитектуры программного обеспечения // Препринт 4. - М.: ИСП РАН, 2004
4. ТАРАСОВ В. Б. От многоагентных систем к интеллектуальным организациям: философия, психология, информатика. - М.: Эдиториал УРСС, 2002. - 352 с.
5. ЧЕРНЕЦКИ К. Порождающее программирование: методы, инструменты, применение / К. Чернецки, У. Айзенекер; Пер. с англ. - СПб: Питер, 2005. - 736 с.
6. FERBER J. The Framework of Eco-Problem Solving / J.Ferber, E. Jacopin // Decentralized Artificial Intelligence II; Ed. by Y. Demazeau, J.-P. Muller. - Amsterdam: Elsevier North-Holland, 1991. - P. 181-194.
7. FERBER J. Les systemes multi-agents. Vers une intelligence collective. - Paris: InterEditions, 1995. - 522 p.
8. MCKINLEY P. Composing Adaptive Software / P. McKinley, S. M. Sadjadi, E. Kasten, B. Cheng // IEEE Computer Society. -2004. - Vol. 37, № 7. - P.27-30.
9. SMITH R. G. The Contract Net Protocol: High Level Communication and Control in a Distrubuted Problem Solver // IEEE Transactions on Computers. - 1980. - Vol. 29, №12. - P.1104-1113.
10. SHOHAM Y. Agent-oriented programming // Artif.Intell. -1993. - Vol.60, №1. - P.51-92.
11. The Third IEEE International Workshop on Software Cybernetics // IWSC 2006. Chicago, 2006; The Fourth IEEE International Workshop on Software Cybernetics // IWSC 2007 Beijing, China, 2007. URL: http://paris.utdallas.edu/
MULTIAGENT SYSTEM MODEL OF THE ENVIRONMENT OF SUPPORT OF SOFTWARE FOR SYSTEMS WITH LAYERED ARCHITECTURE
Vasiliy Gurianov, Regional institute of psychology and the humanities, Cheboksary (vg2007sns@rambler.ru).
Abstract: The problem of adaptability of the software is considered. The solution using structural adapting and a method of the extension of a kernel is studied. The environment of support of a product as multiagent system with the single-level architecture is considered
Keywords: adaptive software, structural adapting, layered architecture, multiagent system, socially-technical system.
Статья представлена к публикации членом редакционной коллегии Г.Н. Каляновым
