в библиотеку

Инструментальная среда разработки интеллектуальных гибридных информационных систем visual event 2.0.

Авторы: Колесников А.В., Чемерис Н.А.

Источник: http://www.swsys.ru/index.php?page=article&id=684

Развитие информатизации общественной деятельности человека заставляет разработчиков создавать сложные информационные системы, в которых доля интеллектуальной составляющей становится более важной и менее формализируемой. Проблемы, связанные с разработкой и реализацией сложных информационно-интеллектуальных систем, заставили ученых искать альтернативные варианты их решения. Развитие кибернетики, информатики, вычислительной техники настолько сильно усложнило системы, что использование старых методов [6] и подходов [7] не удовлетворяет потребности современности. Изучение распределенных [15], многоагентных [17], гибридных [12], интегрирован- ных [15] систем является одной из существующих возможностей борьбы с возрастающей сложностью информационно-интеллектуальных систем. Все эти подходы динамически развиваются и апробируются [12,13]. Методы, изучаемые в рамках каждого подхода, пока еще не имеют устоявшейся терминологии, а также четкой области применимости и однозначной структуры. Часто бывает, что методы одного подхода оказываются частью другой методологии.

Методология гибридных систем нередко оказывается применимой для интегрированных и наоборот. Кроме проблем теоретического характера, они осложнены современным бурным развитием новых информационных технологий. Если еще 10-20 лет назад основной проблемой была формализация и структурирование информации в форме реляционных отношений, то сейчас все острее проявляется проблема анализа и обработки информации, а не просто ее накопление. В сложных системах в ней все более просматривается неоднородность структуры (способов представления и обработки информации, различие в кодах ЦП, типах ОС, инструментальных средств). Современные исследования по преодолению означенной проблематики наметились в нескольких направлениях: универсализация информационных систем, интеллектуализация методов, гибридизация систем. Описываемая среда разработки относится к интегрированно-интеллектуальным гибридам [12-14]. Интегрированно-интеллектуальные гибриды принято подразделять на мелкозернистые и крупнозернистые.

Крупнозернистая гибридизация создается по принципу многомодельных систем, то есть при помощи интеграции гибридов, каждый из которых описывает соответствующий метод целиком (например, экспертную систему, нейронную сеть или нечеткую логическую систему). Методология построения крупнозернистых гибридов уже хорошо изучена и рассматривается в рамках как классических подходов системного анализа [8] (процесс декомпозиции сложной системы на под системы, до уровня соответствующих автономных методов), так и широко развиваемых современных методов построения многоагентных и распределенных систем [15-17] (процесс описания сложной системы языком объектно- ориентированного проектирования (ООП)).

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

Объектно-конвейерное моделирование и ООП

Говоря об использовании Visual Event, необходимо сначала понять новую парадигму подхода к решению задачи. Так как инструментальная среда Visual Event является лишь средством интерпретации описания модели, то вся мощь этого средства проистекает из описательных возможностей "языка", на котором написана модель, и методологии, которая лежит в основе этого "модельного языка". Слово "язык" не случайно взято в кавычки, так как, в отличие от классического понимания языка программирования (языка моделирования), язык описания модели в Visual Event не текстовой, а графический.

С основами ООП и с современной тенденцией в области новых информационных технологий (методология построения распределенных систем) в объектно-компонентном моделировании можно познакомиться в [1-4]. Это важно, поскольку практически любая современная сложная информационная система (а тем более использующая БД, БЗ) требует применения ООП и объектно-компонентного представления.

Перед использованием Visual Event необходимо описать систему через иерархию объектов, каждый из которых имеет абстрактное описание в форме класса. То есть перейти от иерархии объектов системы к иерархии классов (основой ООП является построение не объектной иерархии, а классовой). Полученная иерархия классов (класс - спецификация свойств и методов) предоставляет библиотеку описательных средств. Используя иерархию классов, можно приступать к построению объектной иерархии, заключающейся в уточнении значений свойств, алгоритмов, логики моделей. Если после ООП полученные классы снабдить интерфейсами и выразить их в форме компонентов по технологии СОМ [3], то получится иерархия компонентов (объектная библиотека), которую можно универсально использовать для соответствующего класса задач (разработка библиотеки, например, для автоматизации банка, скорей всего, будет пригодна для любых экономических задач, связанных с банковскими операциями). Особенно важно применение описанного подхода для задач искусственного интеллекта, так как большая часть знаний, правил, методов описывается в декларативной форме, а не посредством какого-либо языка программирования. Поэтому на этапе ООП необходимо использовать различные классы интерпретаторов (виртуальные машины, машины логического вывода, машины обработки модельных описаний и т.д.). Обычно интерпретаторы реализуются через специальные компоненты, применение которых позволяет синтезировать программные и декларативные формы представления. Хотя на практике часто предпочтение отдается процедурному представлению (например, на языке С++ или Object Pascal). Идея объектно-конвейерного [14,19] подхода заключается в описании закономерностей взаимодействия объектов системы через метафору конвейера. Использование конвейерного моделирования заключается в формулировании алгоритма* посредством описания последовательности операций через транспортную сеть. В узлах сети находятся обработчики, входов и выходов может быть несколько. Входы сети (генераторы) вводят в сеть информационные сущности (курьеры). Выходы (терминаторы) снимают с сети эти информационные сущности. По сети перемещаются курьеры (своего рода перемещающийся стек) и служат источниками информации для обработчиков (узлов сети). В рамках объектно-ориентированной парадигмы курьеры - динамические контейнеры, узлы сети (блоки) интерфейсы клас- са [14,19].

Сразу отметим, что среда разработки Visual Event является исследовательским программным продуктом, и поэтому не содержит тех важных компонентов, без которых не обходится ни один коммерческий продукт: полный пакет документации, библиотека для множества класса задач, набор примеров, шаблоны и мастера для удобной интеграции с наиболее популярными средами разработки Visual Studio и Delphi.

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

Для создания конвейерной модели с помощью Visual Event прежде необходимо описать объектные компоненты. Так как среда работает с компонентами согласно технологии СОМ, то создать объектные компоненты можно в любой среде разработки. Авторы использовали для этого среду разработки Del- phi 4.0. В IDE Delphi 4.0 содержится ряд мастеров, которые упрощают процесс создания СОМ-объектов.

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

После создания библиотеки компонентов и ее регистрации в реестре она доступна в среде Visual Event, в которой, используя меню Component, можно указать компоненты, используемые в конвейерной модели. Иконки указанных компонентов появятся в левой части системы. После выбора в левой палитре пиктограммы компонента и вставки ее в модель или форму (ассоциируемой с моделью) в правой палитре изображаются пиктограммы блоков, из которых можно строить конвейерную модель системы (правая палитра содержит три закладки StdBlocks, Generates, Events, то есть стандартные блоки, генераторы и обработчики событий). Конвейерная модель строится в окне редактора в форме транспортной сети (рис. 1). Обычно конвейерная модель начинается с блоков- генераторов (или событийных блоков) и заканчивается блоками-терминаторами.

После создания модели ее можно начать интерпретировать. При желании интерпретация модели может быть скрыта от конченого пользователя, для которого доступны только специально разработанные формы (как в MS Access).

Созданные модели сохраняются в бинарном формате, и, как в MS Access, доступ к сохраненным моделям возможен только из среды.