автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.17, диссертация на тему:Методы адаптивной сборки программного продукта

На правах рукописи

□034504Ы1з

Гурьянов Василий Иванович

МЕТОДЫ АДАПТИВНОЙ СБОРКИ ПРОГРАММНОГО ПРОДУКТА

Специальность 05.13.17 - Теоретические основы информатики

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

з о ОлТ^-З

Чебоксары - 2008

003450486

Работа выполнена в Негосударственном образовательном учреждении высшего профессионального образования «Региональный институт психологии и гуманитарных наук»

Научный руководитель:

Официальные оппоненты:

доктор технических наук, профессор Утробин Владимир Александрович

доктор технических наук, доцент Хранилов Валерий Павлович

кандидат технических наук, доцент Бельчусов Анатолий Александрович

Ведущая организация:

Институт автоматизации проектирования РАН, Центр информационных технологий в проектировании, г.Москва

Защита диссертации состоится «<$» ftftytVta 2008 года в _НГ^Счасов на заседании диссертационного советаД212.165.05 в Нижегородском государственном техническом университете им. P.E. Алексеева по адресу: 603950, ГСП-41, Н.Новгород, ул. Минина, 24.

С диссертацией можно ознакомиться в библиотеке Нижегородского государственного технического университета им. P.E. Алексеева.

Автореферат разослан « /Ц » 2008 г.

Ученый секретарь диссертационного совета канд.техн.наук,доцент А.С.Суркова

Общая характеристика работы

Актуальность темы

Решение проблемы адаптивности программного обеспечения, возможно, является центральным звеном в создании программных продуктов нового поколения. Адаптивные программные системы (adaptive software) могут открыть новую страницу в развитии информационных технологий. Многие компании, прежде всего IBM, Hewlett-Packard и Microsoft, уже осознали необходимость в системах с элементами саморегулирования и объявили о своих программах по созданию адаптируемых и адаптивных систем. Это индуцирует развитие теоретической базы методологий поддержки жизненного цикла программных продуктов.

В настоящее время применяется ряд методов рекомпозиционной адаптации программных систем. Однако целостная методология проектирования таких систем отсутствует.

Концептуальная основа методологии проектирования адаптивных программных систем должна следовать из некоторых общих принципов, таких как принципы программной кибернетики {software cybernetics) и теории развития сложных систем. Можно ожидать, что исходной точкой может стать парадигма порождающего программирования (generative programming).

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

Цель работы

Цель диссертационного исследования состоит в разработке методологии проектирования модельных адаптивных программных систем.

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

Задачи исследования

В диссертационной работе решаются следующие задачи:

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

анализ программных архитектур, допускающих реструктуризацию программой-сборщиком;

поиск способов формального описания процесса адаптации и развития программных систем;

разработка методов проектирования адаптивных программных систем;

анализ требований к системе сопровождения;

разработка программного обеспечения;

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

Методы исследования

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

Научная новизна

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

1. интерфейсная модель адаптации программных систем;

2. лингвистическая модель развития системы со слоистой структурой;

3. метод расслоения класса по элементам интерфейса и методы эмуляции множественного интерфейса и множественного наследования;

4. методология проектирования модельных адаптивных программных систем;

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

Личный творческий вклад автора

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

Достоверность научных результатов

Новые результаты, полученные в диссертационном исследовании, являются развитием идей предложенных рядом исследователей. Наиболее важное значение имеет паттерн Generation Gap, предложенный Д.Влисидесом. Использованы также работы Э. Дейкстры, М.В. Ксензова и др. по выделению слоев. Предложенная методология апробирована на

ряде прикладных задач и проверена методами имитационного моделирования. Модель среды существования программного продукта исследована методами теории динамических систем.

Практическая ценность

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

Полученные результаты исследования используются для поддержки ряда программных продуктов, предназначенных для контроля успеваемости студентов ВУЗов п учащихся средних школ, а также при выполнении дипломных работ студентами, обучающихся по направлению подготовки 351400 - Прикладная информатика (в экономике), что подтверждается актами о внедрении.

Апробация работы и публикации

По материалам диссертации опубликовано 11 печатных работ. Основные положения работы докладывались на следующих конференциях п семинарах:

• Всероссийская научно-методическая конференция "Наука и образование: тенденции и перспективы их развития". Тверь, 2003 г.

• Межвузовский семинар «Математическое моделирование и прикладные задачи». Чебоксары, 2006, 2008 гг.

• Межрегиональная научно-практическая конференция молодых ученых, аспирантов и студентов "Молодые ученые в решении актуальных проблем современной науки", Чебоксары, 2006.

• Всероссийская научно-практическая конференция «Математика, информатика, естествознание в экономике и обществе, Московская финансово-юридическая академия, Москва», 21-22 ноября 2007 года.

• Региональный семинар «Математическое и компьютерное моделирование в сложных системах», математический факультет, Оренбургский государственный университет, 2007.

• Тринадцатая международная открытая научная конференция "Современные проблемы информатизации", с 01 октября 2007 г. по 31 января 2008 г. http://www.sbook.ru

• Международная научно-практическая конференция "Проблемы развития и внедрения информационных технологий", г. Чебоксары, 26-27 января 2007.

• II Международная научно-практическая конференция "Проблемы развития и внедрения информационных технологий", г. Чебоксары,

25 января 2008.

• Заочная электронная конференция «Математическое моделирование» на http://www.rae.ru, 2007.

• VI Научно-практическая конференция «Современные информационные технологии в науке, образовании и практике», Оренбургский государственный университет, Оренбург 2007.

• V международная научно-практическая конференция «Исследование, разработка и применение высоких технологий в промышленности» 28-30 апреля 2008 г. Санкт-Петербург.

• Четвертая всероссийская научно-техническая конференция «Информационные системы и модели в научных исследованиях, промышленности и экологии», 28 апреля 2008, г.Тула.

Структура и объем диссертации

Работа состоит из введения, пяти глав, заключения, приложений и списка литературы. Общий объем диссертации составляет 176 страниц, в том числе основной текст - 140 страниц, 18 рисунков, 4 таблицы. Список литературы насчитывает 129 наименований.

Краткое содержание работы

Во введении обоснована актуальность решения проблемы адаптивности программных систем.

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

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

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

Механизм адаптивности программной системы может быть реализован на основе ряда технологий программной инженерии — выделение задач, вычислительной рефлексии и компонентного дизайна. Структурная адаптация программной системы получила название композицио]шой адаптации программ. Рассмотрены типовые методы

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

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

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

2-я глава посвящена описанию предлагаемой модели адаптации и модели развития программных систем.

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

Обозначим адаптационную пару как S(m,s). Соотнесем т с бизнес-процессом, ase программной системой. Комплекс будем рассматривать как систему, взаимодействующую с окружающей средой. Предметом исследования является изучение процесса адаптации ¿-элемента в паре S(m,s). В рамках данного исследования »/-элемент будем рассматривать как заданный и неизменный. Напротив, s-элемент может изменять свою структуру и состав.

Интерфейсная модель процесса адаптации. Взаимодействие в паре осуществляется посредством обмена сообщениями. Под интерфейсом подсистем будем понимать кортеж / = (f0 , f\ , ... ,/„), f, - отдельные интерфейсы. Под отдельным интерфейсом будем понимать, набор функций подсистемы, предназначенных для решения одной задачи. Интерфейсы, которые реализуют основную функцию программной системы, обозначим идентификатором^. Вариантами рассматриваемого бизнес-процесса будем называть бизнес-процессы, имеющие интерфейс f0 и отличающиеся прочими интерфейсами. Каждому интерфейсу / сопоставим идентификатор, и будем обозначать его той же буквой. Всюду, где не указано обратное, будем понимать / как идентификатор интерфейса.

Определим спецификацию, выданную «¡-элементом пары, как Z= Vo.fi. ... ,f„), причем Z = /('"). Рассмотрим три аспекта связи т и s: прагматический, семантический и синтаксический. Согласно принципу подчиненности процесс адаптации начинается с прагматического аспекта. Сделаем следующее предположение: развитие системы обусловлено

прагматическим аспектом интерфейса, т.е. составом и последовательностью появления элементов в спецификации 2 = (/о,, /¡, ... , /„). Под структурной адаптацией будем понимать процесс реструктуризации программного обеспечения таким образом, чтобы его интерфейс соответствовал заданному, т.е. 2 = / (и>). В частности, развитие информационной системы можно рассматривать как структурную адаптацию. Далее допустим, что адаптация в семантическом и синтаксическом аспектах происходит мгновенно.

Допустимые конфигурации системы. Под структурой системы обычно понимают совокупность компонентов и внутренних связей системы. В дальнейшем ограничимся только слоистыми структурами. Особенность слоистых структур состоит в направленности связей со слоя / на слой ЛИ, но не наоборот. Слоистые структуры изоморфны словам некоторого формального языка Ьи. Сопоставим слоям буквы алфавита Ьи.

Определение 2.1. Композиция системы - это слово IV некоторого формального языка Ьи с алфавитом Уг = {а0, а\, ... , а„}. Между буквами зададим направленные связи. Тогда под структурой системы будем понимать композицию системы с совокупностью наложенных на нее связей.

Сопоставим каждой букве алфавита УТ = {а0, аь ... , а,,} некоторый идентификатор интерфейса / еР и обозначим множество пар (а„ £) как Г, фактор-множество как У^Р = а2, ... ак}, /\\{Ь\, Ь2, ... 6/},... ,

гг, ... !„,}}, где ар Ьр..., еУу Если некоторой букве сопоставлен идентификатор^,, то будем говорить, что ак является ядром системы.

Далее, сопоставим каждой букве а, е УТ упорядоченную пару Ь, = ({/),...,/№}, {Г),...,гЛ/,}), где /- левые (входные), г- правые (выходные) связи. Левые связи можно соединять с идентичными правыми связями любой буквы стоящими слева от текущей. Аналогично определяется соединение для правых связей. Если для данной буквы левые связи имеют соединение в слове и7, то будем говорить, что связи насыщены. Обозначим алфавит связей как Уь, а множество пар £,как Ь.

Каждому слову и> = а0а\...аК е Ьи соответствует некоторый интерфейс /(и») = (/0Л -М,

Определение 2.2. Под адаптированной структурой и^ будем понимать такое слово в Ьи, для которого имеет место 2 = /(н>0), где 2 = /(и>о)=(/"о '.—/ы') и /V' = N. Равенство идентификаторов/, =

следует понимать как равенство атрибутных множеств элементов интерфейса.

Определение 2.3. В совершенной адаптированной структуре для заданного интерфейса 2 = (/о,/\,...,/ы) в адаптированной структуре м>а должны быть насыщены все актуальные связи. В противном случае адаптированная структура будет называться несовершенной.

Определение 2.4. Показатели слова. Пусть задан интерфейс /(от) =

(/-о/ь-./Д слово м> = а0аь..ак еЬи, и буквы а) имеет Л^ левых связей,у = 0,1 ,...,К. 1. Мера адаптации Е/- степень покрытия заданного интерфейса. Меру адаптации определим формулой = (АГ-К)Ш. Мера адаптации имеет много общего с понятием эффективности системы. 2. Качество Рг — показатель отсутствия некорректных связей. Качество слова можно

к к

определить формулой Р1{м/) = 1 - )/ Ь , ¿ = , где -

1=1 1=1

количество актуальных связен, Ь'¡- количество насыщенных связей в слове.

Пятерка ЛУъ Уц, Р, Е, Ь) определяет конфигурационное множество системы л1.

Закон развития слоистых структур. Программная система стремится к адаптированной совершенной структуре. Приведенная выше пятерка Уь, Р, Е, Ь) определяет только множество Ьи допустимых структур и ничего не говорит о том, в каком порядке следует производить сборку слов. Допустимые изменения структуры задаются законом развития системы. В случае слоистых структур закон развит™ может быть задан порождающими грамматиками Хомского. В дальнейшем ограничимся узким классом грамматик Хомского, определяющих процесс адаптации как ориентированное дерево вариантов сборки.

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

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

Основные результаты главы опубликованы в [4, 10].

В 3-й главе описана методика проектирования адаптивных программных продуктов, архитектура которых построена с использованием паттерна «выделение слоев».

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

В предлагаемой методологии используется два взаимосвязанных метода: (а) метод декомпозиции интерфейса подсистемы на

последовательность интерфейсов и (б) метод расслоения класса по идентификаторам спецификации.

1. Характеристическая модель. Определение прикладной программной системы. На этой фазе уточняется понятие программной системы и задается ее модель.

Характеристики. Для определения характеристик предлагается метод делегирования информационных функций. Элементы интерфейса можно получить на основе анализа Use Cases. Для этого необходимо рассмотреть процесс развития пары S(m,s) как процесс делегирования информационных функций от бизнес-процесса к информационной системе. Декомпозиция начинается с выделения основных информационных функций в бизнес-процессе и заканчивается анализом единичных функций. Каждый этап процесса будет определять несколько Use Case. Use Cases могут быть объединены в доменную модель.

Можно сопоставить интерфейсы f е Р с функциональными характеристиками (functional features) в методологии FeatuRSEB. Отсюда следует, что начальная характеристическая модель задается множеством Р.

Объектная модель. Расширим характеристическую модель за счет архитектурных характеристик (architectural features в FeatuRSEB) и определить механизм изменчивости. В предлагаемой модели используется слоистая архитектура. Для определения механизма изменчивости предложен следующий метод стратификации программной системы (объектно-ориентированный аналог метода расширения ядра в модульном программирование).

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

Пусть Т 0 - класс для ядра системы, реализующий интерфейс f0. Пусть новый класс является потомком Tk+1 = Ч' (Тк), где - операция наследования, и расширяется набором свойств и методов следующего интерфейса fk+l е Z = (fo,fh ..., f„). Применив итерацию, построим класс Т, состоящий из слоев, причем с каждым слоем будет связан один интерфейс.

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

Проектная модель. Создается после добавления в характеристическую модель характеристик реализации (implementation features в FeatuRSEB).

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

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

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

Методология прикладной инженерии (создание конкретных прикладных программ) сводится к определению процессов регенерации программной системы. Концепция метода, условно названым как автоинжиниринг, предполагает использование опыта сборки посредством специального объекта — базы конфигураций системы. Объект «база конфигураций» содержит информацию о верифицированных способах сборки классов и управляет процессом регенерации.

Для описания ориентированных деревьев сборки удобна следующая реляционная запись. Пусть класс Т продукта ^ имеет множественный интерфейс 1(Т) = ^ — множество индексов,

множество спецификаций обозначим как В(/0). Определение такого класса для программной системы ограничено немногими частными задачами. В случае, когда выполнено расслоение класса по идентификаторам 2= (/о, /[, ... возможна динамическая адаптивная сборка класса.

Введем для 4еДГ), Л.= (/"о.,/\,-,/д) кортеж вида = ((/о, а\ ), (Л/, Ьх ), (/ц, гЛ )), /, еР, ах, Ьх,- , гх е Ут (далее сегмент) и составим множество Б = {с1{, с12,...,с}м} из всех ^Де/- Будем называть его базой конфигураций объекта 5. Тогда можно говорить об отображении X: Б 1(Т). Пусть Я = Х](2). Таким образом, задача адаптации продукта л(7) будет решена, если задано отображение X и правило выбора й е/?. О сегменте с1 будем говорить как об активном сегменте В. С точки зрения объектного программирования имеет место динамическое порождение класса Т' с единственным интерфейсом 1{Т) = 2. Тем самым, база конфигураций - это физическая реализация порождающей модели домена.

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

Самосборка как шаблон проектирования. Классифицировать системы с самосборкой можно по двум признакам. Во-первых, по типу подсистемы проектирования - активной (с участием инженера) или

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

Название: самосборка - шаблон поведения объектов.

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

Применимость.

• Ситуация. Можно рассмотреть, по меньшей мере, три ситуации, когда применение самосборки (в т.ч. автоинжиниринга) является оправданным.

Случай I. В результате воздействия внешних и внутренних причин состав требований /л-элемента к i-элементу в паре S(m,s) испытывают определенные колебания за время, большее, чем характерное время рефакторинга s-элемента. Необходимо обеспечить соответствующее изменение функциональности s-элемента за счет изменения его структуры.

Случай И. На множестве Е(/0) пар ц еН , задано множество

спецификаций B(f0), где f0 - интерфейс ядра. Пары SÇm^s^) различаются между собой прочими интерфейсами спецификации Js= (f0, /ь ... , fn). Необходимо произвести внедрение программного продукта 5 на множестве заказчиков Е(f0) и, кроме того, обеспечить возможность обновления версий s после внедрения и адаптации.

Случай III. Подчиненная подсистема s оказывает обратное воздействие на подсистему т. Необходимо обеспечить автоматическую реорганизацию подсистемы s в процессе развития взаимодействия в паре S(m,s).

• Пример проектирования. Проект системы для программного обеспечения со слоистой структурой, описанный выше. Пятерка J(Vr, VL,, ISg, F, L) определяет множество конфигураций системы s. Автоинжиниринг определяется как тройка: база конфигураций D = (с/ь d2,...Aù, выборка R =X\Z,D) и правило выбора шаблона сборки г &R.

• Распознание ситуации. Самосборка имеет место только в том случае, когда механизм сборки полностью или частично интегрирован в продукт. К автоижинирингу следует прибегать тогда, когда технологический процесс самосборки на / + 1 фазе связан с выбором альтернатив, а значения критериев выбора до начала сборки неизвестны и могут быть определены только по результатам испытания продукта, собранного на г-ой фазе.

Структура. На диаграмме кооперации (рис.1) показаны основные участники процесса самосборки (используется синтаксис Smalltalk).

• Участники. Объект a: IsPair определяет пару S(m,s). Бизнес-

процесс т представлен объектом m: IsMaster, подчиненная система - как кооперация объектов aSoft: Informatory и s: IsSlave (футляр aSoft). Непосредственно процессом регенерации управляет объект aMeta: MetaCode. Объект aMem используется для хранения актуального состояния объекта aSoft (паттерн Memento).

• Отношения. В штатном режиме объект m обменивается сообщениями с объектом aSoft. Объект s управляет процессом создания и перезагрузки aSoft. При отправке сообщения connectlnfSys объекту s объект aSoñ выступает как параметр; метод возвращает новый экземпляр объекта.

1 2 designSoft aSp

Рис.1. Диаграмма кооперации объектов пары 8{т,5) при самосборке

По завершению периода опытной эксплуатации объект т асинхронно получает сообщение шакеБрес и возвращает объект аЗр (новая спецификация). Это вызывает посылку сообщения designSoft объекту б с параметром аБр, который генерирует сообщение для объекта aMeta и вызывает его метод Биа^сИОп. В результате выполнения последнего становится активным некоторый сегмент базы конфигураций. При посылке сообщения БирроЛБой производится атомарная операция перезагрузки классов аБой под управлением объекта аМйа.

Все три процесса - штатный режим, регенерация и проектирование - выполняются параллельно. Объект а обеспечивает также сопряжение интерфейсов ш и аБой.

Результаты. Футляр з:1581ауе представляет собой универсальную оболочку для программных систем. Линейка продуктов для конкретного домена Е(/0) формируется на основе выбора определенной базы

конфигураций D.

Родственные паттерны. Шаблон «Самосборка» похож на порождающий шаблон «Строитель», но в отличие от последнего относится к паттернам поведения и инкапсулирует характерные для самосборки взаимодействия между объектами системы. Шаблон имеет много общего с моделью гомеостатических сетей.

Основные результаты главы опубликованы в [2, 5, 6, 8, 9].

В 4-й главе рассмотрены варианты организации среды поддержки программного продукта и исследована динамика сред подобного рода.

В настоящее время предполагается, что адаптивные программы могут быть реализованы локально, в рамках отдельных бизнес-процессов. Анализ модели позволяет сформулировать альтернативное утверждение. Адаптивные программные системы должны проектироваться и эксплуатироваться как распределенные системы поддержки инжиниринга. Рассмотренная выше генеративная модель домена адаптивной системы будет не полной, если не рассмотреть способ формирования базы конфигураций D = {du d2,...,dM}.

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

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

Проектирование многоагентной системы (далее MAC) для среды существования продукта имеет ряд особенностей. Рассмотрим ключевые отличия.

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

Будем выделять онтологию требований (структура и смысл элементов интерфейса и онтологию конфигурагщй. Выделяют

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

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

Обозначим множество пар ц еН (Я - множество индексов),

имеющих один и тот же интерфейс /0 , как Е. Пусть на множестве Н существует некоторое подмножество активных пользователей, т.е. таких, которые могут вносить изменения либо в базу конфигураций О системы, либо в ее компоненты а е . Допустим, что между элементами Н существует возможность пересылки баз конфигураций и может быть определена некоторая операция объединения баз. Обозначим обновляемую базу конфигураций как Оп\ а некоторую другую - как О^.

Рис.2. Схема коммуникаций

В случае слоистых структур можно ввести специальную операцию соединения К: (£>ц+, ДГ) (£>/', ДГ' ). Данная операция эмулирует множественное наследование. Регенерация системы по О^ О.У)

приведет к обновлению модулей системы, причем интерфейс системы, определяющий адаптацию, сохранится. По £>/' = ХгСАЛ ¿V) регенерация системы невозможна, этот вариант базы конфигураций удобен для транспортировки (и, тем самым, обеспечивает самодостаточность системы).

Итак, можно определить следующий шаблон проектирования многоагентной системы (см. рис.2). Зададим четыре основных типа агентов: два реактивных агента О * и £> ~ и два интеллектуальных интенциональных агента 5(т, я) и Я'(т, х) в роли заказчика и в роли

исполнителя соответственно. Будем рассматривать многоагентные системы с одноуровневой (полностью децентрализованной) архитектурой. Взаимодействие агентов D + и D~ определяется операцией соединения и поддерживается языком типа KIF (Knowledge Interchange Format).

Протокол исполнителя S' (т, s) предполагает: (а) сбор сведений посредством стандартного сервиса сети о множестве Е, (б) рассылка предложений и (в) протокол рассылки D ~ . Протокол заказчика S (т, s) -протокол ведения переговоров для модели контрактных сетей. В этом случае S (т, s) выступает в роли агента-менеджера. Цена определяется в первую очередь уровнем соответствия I(s) = Z Возможно также использование других протоколов. Язык коммуникации для агентов S(m, s) и S'(m, s) может быть KQML (Knowledge Query and Manipulation Language).

Отдельным вопросом является проблема существенности предметной онтологии. Именно достижение существенности и является целью MAC. Можно ожидать, что эволюция MAC приведет к выработке некоторой «универсальной» базы конфигураций, который обеспечит существенность предметной онтологии. С тем, чтобы исследовать возможные варианты эволюции, составим математическую модель MAC. Будем придерживаться подхода, используемого в теории самоорганизации и впервые предложенный в работах Ж.Фербе.

Рассмотрим все возможные варианты базы конфигураций, которые могут появиться на множестве пользователей S. Данное множество обозначим как Q. Пусть в каждой паре Sim^s^) реализуется один из интерфейсов {7*}^, Х-множество индексов. Обозначим соответствующее фактор-множество как {S4: к еК}, Л^ - количество пар в

Пусть и^ количество s - элементов имеющих базу конфигураций вида / еА и входящих в Ек. Допустим, что Л^ = const, У к еК. Для описания эволюции среды запишем динамическую систему в виде (v,w =

= ^[-Lfn-ьГ + V'] - (IV4)/,Л + Z«//,(«/4>

1*1 at к М, j j j

=1 ,\/keK,

j

где верхний индекс при переменных указывает на индекс фактормножества {Ek: к eK},J[ui) ~ и,2. Система уравнений разбивается на блоки по индексу группы Е/, / gK. В каждом блоке / используются переменные для V ; е Л.

Смысл коэффициентов следующий. Пусть некоторая пара S(ma,sa) с базой конфигураций /' получает базу конфигураций j от некоторой пары S(mp,Sp) и возможна замена базы конфигураций i на j. Интенсивность этого

процесса ¿(/w , / = к (матрица предпочтений). Возможна диффузия баз конфигураций за границы Е к. Интенсивность диффузии из Ек в Е, определяется значениями b,jk) , I Ф к. С другой стороны, если текущая структура s-элемента не соответствует требованиям бизнес-процесса, возможна модификация базы конфигураций / -» j. Этот процесс определяется матрицей модификаций а,г

Универсальная база конфигураций Du = {d\, d2,...,dM} соответствует устойчивому стационарному состоянию динамической системы. Таким образом, можно говорить, что требуемое состояние в многоагентной системе, по крайней мере, существует.

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

Основные результаты главы опубликованы в [1, 3].

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

° Дана формулировка методологии проектирования программной системы уровня офисных приложений и представлена архитектура платформы EAS. Платформа EAS (рис.3) синхронизирует выполнение трех процессов: (а) рекомпозицию прикладной программы aSoft, (б) определение спецификаций в aSpShell и (в) обмен сообщениями с MAC в aMASShell.

Рис. 3. Кооперация объектов приложения EAS

Дано объяснение основным моделям жизненного цикла программного продукта. Предложена методология имитационного моделирования развития программных систем, имеющих слоистую программную архитектуру;

Представлена формализация известных методологий FeatuRSEB, Software Factories и Darwin Reference Architecture. Приведен прогноз возможного развития этих методологий;

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

Рассмотрен вопрос о перспективах обобщения предложенной методологии для платформ промежуточного слоя и многоагентных корпоративных систем. Основные результаты главы опубликованы в [7, 9, 11].

Заключение

В соответствии с целями исследований получены следующие основные результаты:

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

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

3.Разработаны метод анализа требований, метод выделения слоев по интерфейсам и метод регенерации системы. Предложен и конструктивно проработан шаблон с условным названием «Самосборка».

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

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

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

7.Произведена разработка платформы поддержки адаптивных программных систем для среды программирования ЗтаЫк. Выполнена разработка нескольких адаптивных программных систем.

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

Публикации

Статьи в журналах, периодических изданиях, включенных в список ВАК РФ

1. Гурьянов В.И. Многоагентная модель среды поддержки программного продукта для систем со слоистой архитектурой / В.И. Гурьянов // Управление большими системами. - М.: ИПУ РАН, 2008.

- №22- С.101-118.

2. Гурьянов В.И. Самосборка программного обеспечения как паттерн проектирования / В.И. Гурьянов // Программные продукты и системы.

- Тверь, 2008,- №1(81)- С.62-64.

Статьи и материалы конференций

3. Гурьянов В.И. Модель эволюции программного продукта по теории адаптации Холланда / В.И. Гурьянов // Сборник научных трудов Межрегиональной научно-практической конференции молодых ученых, аспирантов и студентов "Молодые ученые в решении актуальных проблем современной науки". - Чебоксары: ООО "Полиграф", 2006. - С. 300-303.

4. Гурьянов В.И. Программирование, основанное на стратификации семантики / В.И. Гурьянов // Проблрмы развития и внедрения информационных технологий: материалы Междунар. науч.-прак. конф. - Чебоксары: Изд-во Чуваш. Ун-та, 2007. - С 76-79.

5. Гурьянов В.И. Адаптивная сборка класса. / В.И. Гурьянов // Современные информационные технологии в науке, образовании и практике. Материалы IV всероссийской конференции. - Оренбург: Изд-во ИПК ГОУ ОГУ, 2007. - С. 31-32.

6. Гурьянов В.И. Адаптивная информационная система для модельной задачи управления стеком / В.И. Гурьянов // Информационные технологии моделирования и управления. - Воронеж: Изд-во «Научная книга», 2008. - № 1 (44). - С. 52-61.

7. Гурьянов В.И. Адаптивная программная система как фабрика приложений / В.И. Гурьянов // Материалы VI научно-практической конференции «Проблемы информатизации социальных систем: региональный аспект». - Чебоксары: ГОУ ВПО ЧГПУ, 2008. - С. 253254.

8. Гурьянов В.И. Объектная реализация порождающей модели домена адаптивной программной системы / В.И. Гурьянов // Проблемы развития и внедрения информационных технологий: материалы Междунар. науч.-прак. конф. - Чебоксары: Изд-во Чуваш. Ун-та, 2008. - С. 56-58.

9. Гурьянов В.И. Платформа для модельных адаптивных программных систем / В.И. Гурьянов // Информационные системы и модели в

научных исследованиях, промышленности и экологии: доклады IV Всероссийская науч.-техн. конф. - Тула: Изд-во ТулГУ, 2008 - С. 8485.

10. Гурьянов В.И. Процесс адаптации слоистых структур и законы развития сложных систем. / В.И. Гурьянов // Математическое и компьютерное моделирование в сложных системах. Сборник научных трудов регионального научно-практического семинара. - Оренбург: ИПК ГОУ ОГУ, 2007. - С. 53-56.

11. Гурьянов В.И. Структурная адаптация системы управления стеком / В.И. Гурьянов // Современные проблемы информатизации в анализе и синтезе технологических и программно - телекоммуникационных систем: Сб. трудов. - Воронеж: Изд-во «Научная книга», 2008. -Вып.13. - С.343-345.

Гурьянов Василий Иванович

Методы адаптивной сборки программного продукта

Автореферат

Подписано в печать 25.09.2008 Формат 60 х 84 1/16 Объем 1,5 п.л.

Тираж 100 экз. Заказ № 8

Участок оперативной полиграфии

РИПиГН 119334 Чебоксары, Энгельса., 12