Диссертация (1090633), страница 20
Текст из файла (страница 20)
Она позволяет: создавать и хранить онтологии для различных предметных областей; создавать и сопровождать базы знаний путем интеграцию знаний изонтологий разных разделов области в рамках единого информационногопространства; проектировать системы управление БЗ, а также обеспечиватьиспользование при решении задач тех информационных компонентов, которые вэтом случае необходимы, то есть.3.2. Выбор среды разработкиТаким образом, следуя подходу, изложенному в Главе 2, удается перейти отзадачи последовательной разработки нескольких связанных моделей (моделиданных, модели приложения, навигационной модели и модели интерфейсапользователя), присущей методологии разработки на основе модели предметнойобласти, к задаче отображения единой онтологической модели в разныхсемантиках (задаче реализации пучка семантик над онтологией).При этом ппредставляется естественным создавать инструментальнуюоболочку именно на основе той системы реализации, для которой ипредполагается использовать данное веб-приложение, т.е.
на основе системыуправления содержимым (CMS) Plone [98]. Данная мистема позволяет создаватьвеб-приложения самых различных типов от простых сайтов-визиток докорпоративных порталов. Рассматриваемая система использует серверприложений ZOPE (ZObjectPublishingEnvironment) и объектную базу ZODB [99].Отличительными особенностей Plone является:1. Использование компонентной архитектуры, позволяющей разрабатыватьновые и интегрировать существующие компоненты хранении и обработки данныхи компоненты реализации пользовательского интерфейса.2. Использованием объектной базы данных и объектно-ориентированнойсреды реализации.Способ хранения онтологических моделей в объектной базе данных обладаетрядом преимуществ по сравнению с использованием реляционных баз данных.
Вобъектной базе ZODB, входящей в состав Plone, хранение данных организовано в107виде разветвленного дерева объектов, реализующих различные типы (контенттипы), как поставляемых в составе Plone, так и дополнительно разработанных.Выбор архитектуры ИИС определен выбором системы реализации вприложении реализуется клиент-серверная архитектура с использованиемкомпонентного подхода и реализацией хранения данных в объектной базе данных.Основным паттерном управления в Plone является организация объектовразличных контент-типов (типов информационных объектов) в иерархическиедеревья объектов. Функционирование серверной части обеспечиваетсявзаимодействием двухуровней приложения уровнем обработки онтологии иуровнем, реализующим обычную функциональность Plone.
Компонентнаяархитектура, развитая система визуального программирования позволяет строитьразличные инструментальные оболочки над наборами специализированныхкомпонент используя стандартные средства Plone и при необходимостирасширять их возможностями дополнительных плагинов. Построение системыуправления онтологическими моделями требует создания специальных типовкомпонент и разработке специального интерфейса пользователя. Выполнениеинструментальной оболочки в виде веб-приложения позволяет обеспечитьсовместный удаленный доступ членам различных групп разработчиков,участвующих в проекте, причем распределение прав доступа в этом случаеобеспечивается средствами CMS.И наконец, встраивание разрабатываемого комплекса в любой портал, такжереализованный на Plone, предоставляет возможность управления порталом черезредактирование соответствующих онтологий, а расширение возможностейпортала как через введение новых понятий в указанные онтологии, так и путемсоздания и подключения новых онтологических моделей.3.3.
Разработка компонентов инструментальной средыСистема управления включает в себя четыре компонента. Семантическаясеть, представляющая компонентную модель системы управления представленана рисунке (Рисунок 55).Все агенты системы формально представлены как подклассы класса агентасистемы управления знаниями Агент СУЗ. Рассмотрим функции каждогокомпонента.3.3.1.
Агент запросовНаряду с задачами управления знаниями актуальна разработка методовдоступа к знаниям и данным их представляющим. Для этого были выделенызадачи, связанные с запросами к базе знаний и созданы программные агенты дляих решения.108Агент запросов получает спецификацию запроса к семантической сети в видесемантической сети, специфицирующей запрос или в виде программного вызоваи преобразует их в запрос к объектной базе данных.
После выполнения запросапредставляет результат в формате, определяемом входной спецификациейзапроса.Рисунок 55. Компонентная модель системы3.3.2. Конфигуратор командВсе задачи, решаемых системой могут быть реализованы только в том случае,если каждая из них может быть декомпозировано до задач управления объектноориентированной семантической сетью.Основной цикл работы системыуправления состоит в последовательном выполнении заданий, поступающих отподсистемы пользовательского интерфейса.
Каждое задание содержит некоторуюпоследовательность операций управления АСС. При выполнении любого заданияпользователь управляет объектом, реализующим один из компонентов хранениязнаний, визуальное представление которого определяется решаемой задачей.109Для типовых задач предоставляется модель решения задачи в виде дереваподзадач и действий обеспечивающей системы и пользователь с помощьюредактора задач может настроить модель задач под свои требованияКонфигуратор команд выполняет анализ выполняемой задачи и планируетпроцесс ее решения.
Запрос пользователя на решении задачи начинается с анализавозможности выполнения задачи.Рисунок 56. Модель задач управления базой знаний.Задача считается известной конфигуратору, если ее описание представлено вонтологии задач системы управления. Конфигуратор анализирует задание,извлекает из него очередную задачу, представляет ее в формате, заданномонтологией задач. Если задача имеет тип «задача системы», то производится110вызов соответствующего сервиса системы реализации, в противном случаепроисходит переход на следующий уровень дерева декомпозиции задачи.Модель задач системы управления знаниями, связанных с управлением базойзнаний с указанием разработанных программных элементов, показана на рисунке56.Конфигуратор используется также для предоставления агенту визуализацииинформации об операциях, доступных пользователю в процессе решения задач.
Вкаждый момент времени система находится в состоянии обработки некоторогосвоего компонента. Используя отношение Задача.связана с классом=@OntoClassконфигуратор строит список программных агентов для всех задач, решениекоторых возможно в контексте активного компонента системы. После передачисписка команд агенту визуализации последний создает некоторый элементинтерфейса пользователя.Пример интерфейса для управления онтологией, созданный автоматическина основе результатов, предоставляемых конфигуратором команд, представлен нарисунке 57.Рисунок 57.
Интерфейс управления онтологиейСостав команд, входящих в панель управления определяется динамически,исходя из текущего контекста управления. Система автоматически определяетвозможные действия на контекстом и строит необходимое количествогиперссылок вызова инструментов управления.3.3.3. Агент визуализацииАгент визуализации создает структуру интерфейсного элемента как деревосперва абстрактных, а затем конкретных визуальных элементов. Данная структураактуализирует некоторое знание, формализуя его в терминах онтологиивизуальных элементов и визуализируется через набор элементов представления.Набор элементов визуализации определяется отношениями классов онтологии111ISO24744. Каждая экранная форма, предоставляемая пользователю аннотируетсяклассом Документ онтологии ISO24744, который представляет класс Модель.Введение класс ВидВизуальнойМодели и определение для него классВизуальнаяНотация и ПримитивВизуалнойНотации позволяет создавать ихранить или динамически формировать различные визуальные модели, отображаяих пользователю.3.3.4.
Автоматическое создание формы по структуре данныхРисунок 58. Концептуальная модель построителя форм112Для эффективного сопровождения изменений, вносимых в семантическуюмодель агент визуализации должен позволять каждому термину моделиавтоматически сопоставляться интерфейсные элементы, нужные дляпредставления модели и заполнения. При этом в случае изменения моделионтологии не будет возникать необходимость вносить изменения впользовательский интерфейс, так как они производятся автоматически.
Длярешения поставленной задачи в состав агента визуализации входит построительформ, концептуальная модель которого, включающая модель задач и моделькоммуникаций с компонентами системы управления, представлена на рисунке 58.Пример автоматически созданной формы для создания объекта класса«Задача системы» представлен на рисунке 59. Здесь для каждой связи классаопределяется набор элементов, с которыми может быть установлена связь. Вданном случае семантическая модель, по которой строится форма, являетсянеобогащенной, т.е не полностью определены все связи между концептами — вданном случае для имеющихся связей не определены связываемые классы и несозданы объекты для некоторых классов, связанных с классом «Задача системы».Рисунок 59. Пример автоматически генерируемой формы3.3.5.
Сервис трансформацииСогласование моделей и компонентов на уровне семантической сетипроизводится путем создания классов, наследующих класс Адаптер онтологииархитектуры. Для автоматизации создания адаптеров и их настройки разработансервис трансформации, позволяющий в визуальной форме создавать классыонтологии, наследующих класс Адаптер. Окно сервиса для случая создания113адаптера, отображающего атрибуты класса онтологии на схему компонента,представлено на рисунке 60.Рисунок 60. Окно сервиса трансформацииВ представленном примере сервис трансформации считывает список связейвыбранного пользователем онтологического класса и позволяет сопоставлятькаждой связи идентификатор поля схемы компонента и его тип поля. Списоквозможных типов полей строится на основе запроса в онтологии схемы.
Длякаждого онтологического класса создается экземпляр модели компонента ссоответствующими полями. Настройка каждого отдельного поля производится вредакторе компонентов.3.3.6. Пакеты системы управленияРисунок 61. Программные пакеты системы114Все компоненты системы управления реализована в виде нескольких,схема связей между которыми, изображенных на рисунке (Рисунок 61).Пакет Products.OntoEditor — содержит компоненты для представленияонтологии, экземпляры которых хранятся в объектно-ориентированной базеданных, набор методов обеспечения поиска в объектной базе и запросов кбазам знаний.Пакеты onto.tasktypes, onto.schematypes, onto.navtypes, onto.infotypesсодержат компоненты и утилиты, реализующие визуальные редакторы дляразличных предметных областей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
