Методика создания модулей знаний с использованием технологии MATRIX

О.И. Смирнов,

МАИ, г. Москва

Портал знаний предметной области технологической подготовки производства – ТПП - www.rpm-novation.com разрабатывается по инициативе Министерства образования и науки Российской Федерации. При разработке портала возникла потребность в представлении и обмене знаниями о новых технологических процессах быстрого прототипирования.

Данная работа посвящена созданию прототипа CASE (MATRIX) – средства для проектирования, редактирования и просмотра модулей знаний по технологиям быстрого прототипирования (Rapid Prototyping and Manufacturing – RPM), которые размещены на информационном web – портале. Предполагается, что используя данное средство разработки, зарегистрированные пользователи портала смогут создавать собственные модели технологических процессов и размещать их на портале для дальнейшего обсуждения, развития, и коммерциализации.

На первом этапе рассматривались методы представления знаний, которые используются в системах искусственного интеллекта - ИИ и системах управлении знаний (СУЗ), чтобы выбрать метод, наиболее подходящий для решения поставленной задачи. Были рассмотрены следующие методы: 1) Продукционные правила; 2) Семантические сети; 3) Фреймы; 4) Формальные логические модели; 5) Гиперкомплексные динамические системы - ГДС. В итоге были выбраны методы ГДС (гиперграфы и структурные матрицы), потому, что: 1) построив, с их помощью, модель технологического процесса мы получаем не только функциональную модель (схему), но и легкий переход к макету системы (модулю знаний). 2) при использовании ГДС вместо специального процессора вывода, используется динамический запуск внешних приложений, что выгодно отличает этот подход от других методов.

Здесь используются два взаимодополняющих представления ГДС: в виде гиперграфов и структурных матриц. При описании ГДС в виде графа: элементы системы соответствуют вершинам графа, а связи представляются дугам, между соответствующими вершинами (рис. 1).

При описании ГДС в виде структурной матрицы (табл. 1) элементы системы располагаются на главной диагонали матрицы, а связи в клетках по обе стороны от главной диагонали. Когда связь между элементами отсутствует, то соответствующая клетка матрицы обозначается пустой или обозначается “0”.

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

Ниже представлен пример разработки модели технологического процесса RPM с помощью гиперграфов и гиперматриц:

Описание объектов гиперматрицы:

- CAD – модель; - Система автоматического проектирования (автоматизированное рабочее место технолога); - Изготовление “зелёного” прототипа; - Перевод “зелёного” прототипа в готовый форм блок; - CAD – файл, представленный заказчиком; - CAD – файл, обработанный экспертами фирмы; - Технологическая модель; - Информация о корректности, полученной технологической модели; - “Зелёный” прототип; - Готовый форм блок. - Преобразование CAD – модели в конструкционную модель; - Преобразование конструкционной модели в технологическую: - Конструкторская модель; - Информация о корректности, полученной конструкторской модели.

Рис. 1. Гиперграф описывающий технологический процесса изготовления форм-блока по технологии ЧЧЧ.

Таблица 1.

Структурная матрица процесса изготовления форм-блока

			0			0
						0
0					0
			0	0
	0		0
						0

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

Требования к системе проектирования модулей знаний (СПЗ) были разбиты на: функциональные и нефункциональные.

1. Функциональные требования

1.1. Сбор данных: Ввод формализованных и неформализованных данных

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

1.3. Доступ к данным: Средства доступа к ресурсам, информация о которых хранится в проектном файле модуля знаний (Интернет ресурс, локальный ресурс, подуровень гиперкомплексной системы).

1.4. Обработка данных: Классификация данных по группам принадлежности; Интегрируемость с внешними приложениями и сервисами; Средства для быстрой разработки собственных моделей знаний в легко воспринимаемой форме; Средство анализа модуля знаний (построение гиперкомплексной матрицы с целью восприятия вложенности многоуровневой системы, а так же связей между ее элементами).

2. Не функциональные требования

2.1. Интерфейс Удобство и простота использования; Возможность быстрой навигации по структуре модели.

2.2. Комплектация Документация на систему; Концепция; Удобство использования системы.

На основе требований разработана архитектура системы (рис. 2), из следующих основных компонент: Клиент, Web сервер, Сервер приложений, Сервер БД.

Рис. 2. Логическая схема архитектуры

Описание элементов проектируемой системы:

1. Пользователь системы через Web сервер получает доступ к сервису регистрации, расположенному на сервере приложений, который создает новые записи пользователей системы с правами авторов и заносит данные пользователей в БД пользователей системы.

2. Клиент включает в себя:

2.1. Конфигурация “Автор” – включает в себя средства создания моделей знаний, используя метод представления в виде ГДС. После создания локальной версии модуля знаний клиент отсылает созданный проект на web портал в копилку проектов автора, помечая его датой создания.

2.2. Конфигурация “Аналитик” – включает в себя средства просмотра модулей знаний, размещенных авторами на web портале и систему контроля версий.

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

4. Сервис контроля версий на клиенте, при подключении аналитика к системе, производит анализ последних версий проектов и выдает предупреждения об изменениях аналитику.

Сценарий создания модуля знаний:

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

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

Если возникает необходимость исправления модуля знаний, размещенного на портале, то автор с помощью клиентского ПО осуществляет изменение проекта локальной версии и осуществляет его замену на портале.

Клиентская часть программного обеспечения написана на языке программирования Java, в результате чего получается легко переносимое (кросс платформенное) приложение.

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