Software & Systems

Развитие информатизации общественной деятельности человека заставляет разработчиков создавать сложные информационные системы, в которых доля интеллектуальной составляющей становится более важной и менее формализируемой. Проблемы, связанные с разработкой и реализацией сложных информационно-интеллектуальных систем, заставили ученых искать альтернативные варианты их решения. Развитие кибернетики, информатики, вычислительной техники настолько сильно усложнило системы, что использование старых методов [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 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, доступ к сохраненным моделям возможен только из среды.

Пример решения задачи "Выгрузка судов в порту"

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

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

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

В качестве методов будем рассматривать четкий алгоритм (жесткая схема выделения причалов для судов), нечеткую логическую систему принятия решения (нечеткие логические правила выбора судна для разгрузки краном), экспертную систему выбора управляющего решения (использование эвристических правил для выбора из множества команд управления железнодорожными составами нужных). Объектная структура задачи реализуется в форме СОМ-объектов на Delphi (функционирование нечеткой логической системы возьмем из среды Matlab, для чего напишем на Delphi специальный СОМ-объект, взаимодействующий с Matlab). На Delphi реализуется и ActiveX-компонент для визуализации событий, происходящих в порту.

После подготовки необходимых объектов, компонентов, методов и реализации их в форме динамических библиотек (In-process) все объекты устанавливаются в палитру среды Visual Event и, используя блоки, описывается логика поведения и управления. Так как в задаче три управляемых элемента (кран, судно, состав), то в модели будет три схемы. Внешний вид модели в пиктограммной форме представлен на рисунке 3 (детальное описание см. в [19]).

Схема состоит из трех сегментов. Верхний описывает поведение вагонов (составов), средний – кранов, нижний – судов.

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

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

Рассмотрим первое направление: кодировщик (преобразование информации из свойств объекта, описывающего кран, в серию числовых величин, которые далее будут обрабатываться в нечеткой логической системе). В блок кодировщик курьеры направляются еще из одного блока: событие-изменение-ситуации (генерирует курьеры всякий раз, когда изменяется ситуация в порту – судно причалило, судно отчалило). Из блока кодировщик курьеры идут в блок нечеткая-система (на основе базы правил, вырабатывает решение). Блок декодировщик (переводит решение, выработанное в нечеткой системе, в команды, исполняемые над объектом, описывающим кран). Из декодировщика курьеры или сразу идут в блок регулировщик, или вначале заходят в блок задержка (имитация задержки кранов на время принятия решения).

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

Рассмотрим верхний сегмент модели – логика поведения составов: вызов-вагонов (блок генерирует курьеров, когда требуются составы), инициализатор (создает объект, описывающий состав), диспетчер-вагонов (экспертная система, реализующая управление составами и направляющая курьеры по нескольким путям: 1 – ожидание, реализуется блоком задержка; 2 – движение к конкретному причалу, реализуется блоками диспетчер-порта, задержка, достижение-цели; 3 – выход состава из порта, реализуется блоками выход-из-порта, задержка, достижение-цели; 4 – удаление более ненужных объектов: удаление, терминатор).

Как видно из примера, последовательный порядок операций конвейерной модели немного напоминает алгоритмическую последовательность. Но на конвейере обрабатывается поток элементов (курьеров), а не один конкретный элемент. Если бы в конвейерной модели обрабатывался всего один курьер, то модель была бы полной аналогией классического алгоритмического подхода. Польза от применения конвейера – удобство описания и контроля.

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

Список литературы

1.   Bock C. and Odell J. “A Foundation For Composition,” Journal of Object-oriented Programming, October 1994.

2.   Grady Booch, Jim Rumbaugh and Ivar Jacobson. Unified Modeling Language User Guide, ISBN: 0-201-57168-4, Addison Wesley, est. publication December 1997. See www.awl.com/cp/uml/ uml.html.

3.   David Chappel. Understanding ActiveX and OLE. Microsoft Corporation 1996.

4.   Terry Halpin. Object-Role Modeling (ORM/NIAM). Microsoft Corporation, USA. Сh. 4 of Handbook on Architectures of Information Systems, eds P. Bernus, K. Mertins & G. Schmidt, Springer-Verlag, Berlin, 1998. www.springer.de/cgi-bin/search.

5.   Martin J. and Odell J. Object-oriented Methods, A Foundation, ISBN: 0-13-630856-2, Prentice Hall, 1995.

6.   Бенерджи Р. Теория решения задач. Подход к созданию искусственного интеллекта. - М.: Мир, 1972.

7.   Бирюков Б.В., Гастев Ю.А., Геллерт Е.С. Моделирование - БСЭ. - 1974. - Т.16. - С. 393-395.

8.   Бусленко Н.П. и др. Лекции по теории сложных систем. – М.: Наука, 1973.

9.   Дарахвелидзе П.. Марков Е. Delphi 4 – среда визуального программирования. - СПб. - 1999. - 816 с.

10.Ерофеев А.А., Поляков А.О. Интеллектуальные системы управления. - СПб: Изд-во СПбГТУ, 1999.

11.Забежайло М.И. Data Miming & Knowledge Discovery in Databases: Предметная область, задачи, методы и инструменты// Тр. 6-й нац. конф. по искусствен. интеллекту с междунар. участ. (КИИ-98. Пущино). - 1998. - Т.2. - С. 592-600.

12.Колесников А.В. Гибридные парадигмы автоматизированного проектирования// В сб. тр. междунар. науч.-техн. конф. (БАЛТТЕХМАШ-98.) - Калининград: Изд-во. КГТУ. - 1998. - С.35-36.

13.Колесников А.В., Седов Р.А. Инструментальная среда разработки приложений гибридных интеллектуальных систем для выбора измерительных приборов и первичных преобразователей автоматики морских судов// Сб. докл. междунар. науч.-техн. конф. (БАЛТТЕХМАШ-2000). - Калининград: Изд-во. КГТУ. 2000. - Т. 1. - С.68.

14.Колесников А.В., Чемерис Н.А. Visual Event 2.0: язык программирования гибридных интеллектуальных систем и система неоднородного моделирования// Сб. тр. междунар. науч. конф., посвящ. 70-летию основания КГТУ. - Калининград: Изд-во. КГТУ.- 2000. - С.241-243.

15.Сазонова Л.И., Осипов Г.С. Интегрированные распределенные интеллектуальные системы оценки и прогнозирования состояния природных ресурсов// Тр. междунар. конф.: Интеллектуальное управление: новые интеллектуальные технологии в задачах управления (ICIT'99). - М.: Наука. Физматлит, 1999. - С.80-85.

16.Тарасов В.Б. Предприятия XXI века: проблемы проектирования управления// Автоматизация проектирования. - 1998. - №4. (http://www.osp.ru/ap/1998/04/index.htm)

17.Тарасов В.Б. Агенты, многоагентные системы, виртуальные сообщества: стратегическое направление в информатике и искусственном интеллекте// Новости искусственного интеллекта, 1998. - №2. - С.5-63.

18.Уфимцев С.В. Система поддержки принятия решений диагностической ЭС РВ в условиях неопределенности// Сб. докл. междунар. конф. по мягким вычислениям и измерениям (SCM-98). - СПб. - Т.1. - 1998. - C.199-202.

19.Чемерис Н.А. Новая технология программирования и моделирования гибридных интеллектуальных систем. (Дипломная работа). - КГТУ, 2000.