Диссертация (1090633), страница 19
Текст из файла (страница 19)
Для одного и того же набораданных может быть определено множество элементов пользовательскогоинтерфейса, композиция которых и будет определять интерфейс решенияконкретной задачи. На рисунке 52 представлена часть модели пользовательскогоинтерфейса для представления задач, связанных с классом Учебный курс.Рисунок 52. Модель пользовательского интерфейсаВ модели представлены только классы, наследующие класс АбстрактныйИнтерфейс онтологии пользовательского интерфейса без указания конкретныхинтерфейсных элементов. Исключение составляет абстрактный пользовательский99интерфейс logo_guiview, предназначенный для представления логотипа портала,для которого представлено его связь с конкретными элементами интерфейса.Система разработки пользовательского интерфейса решает ряд задач, методы решения которых предоставляются системой управления знаниями.
Семантическая модель части задач системы разработки пользовательского интерфейсапредставлена на рисунке 53.Рисунок 53. Модель задач системы разработки пользовательского интерфейса.2.4.5. Методы разработки и управления программными компонентамиДля эффективной работы с онтологиями необходимо иметь как средства дляпредставления знаний о мире, так и средства для эффективных вычислений.Знания о процедурных средствах — процедурные знания должны быть как-тоотражены в вычислительных моделях и реализованы посредством программныхкомпонентов. Разработка баз процедурных знаний и сопровождение программныхкомпонентов производится в системе управления программными компонентами,построенной как система управления знаниями над онтологией программныхкомпонентов, классы которой позволяют определять структуры программныхкомпонентов и алгоритмы выполнения (рисунок 54).Программные элементы рассматриваются как агенты, преобразующиймодель задач, передаваемую им в качестве параметра.
Онтология представленаклассами:Класс Shema отображает логическую модели, с примитивами моделированияFieldКлассы Компонент (Component) предназначен для моделированиякомпонентов. Компонент представлен функциональной моделью@Компонент.имеет.@МодельЗадачКомпонента,а также декларативной моделью:@Компонент.имеет.@Схема компонентаПримитивы Схема компонента, Элемент схемы, связанны с классамионтологии информационных элементов. Классы Атрибут, Метод, Функцияспециализируют класс Элемент схемы.100Процесс проектирования в качестве своего контекста имеет сеть различныхонтологий и пакеты решателей задач над нею.
Использование решателей,ориентированных на управление абстрактной семантической сетью (АСС)предполагает первоначальное формирование метастуктуры или онтологии, наоснове которой может быть создан класс различных баз знаний либо другойсложно-структурированной информации, ей соответствующий.Рисунок 54.
Онтология компонентовОсновным преимуществом такой технологии является то, что процедурныезнания отделены от декларативных, решатель задач является повторноиспользуемым для класса задач с общей онтологией обрабатываемой информациив различных интеллектуальных системах. Решатель задач состоит из трехосновных компонентов: описания алгоритма решения задачи, спецификацииформатов входных и выходных данных, а также непосредственно программногокода, реализующего метод.101Для возможности выявления процедурных знаний все атрибуты задач,входящих в модель задач, необходимо представить в виде информационныхобъектов:@Информационная модель задачи=Преобразовать({@Параметр задачи})={@Информационный элемент}Внешняя система производит Запрос, посылая Модель Задач или Задачу какпараметр запроса.
При поступлении запроса ищутся компоненты с моделямизадач семантически эквивалентными элементам запроса. При успешном поискевнешней системе предоставляется идентификатор решателя задач. В противномслучае создается МодельЗадачКомпонента с состоянием «ожидает решения».Решение задач системы управления компонентами обеспечиваютсяметодами, предоставляемыми системой управления знаниями. Семантическаямодель задач системы управления компонентами представлена на рисунке 55.Рисунок 55.
Модель задач системы управления компонентами.При моделировании портала устанавливается соответствие междуэлементами онтологии предметной области и элементами онтологиикомпонентов. Классы компонентов связаны с классами предметной областикосвенно через класс ClassSchema и класс TaskModel, каждый из которыхопределяется непосредственной связью с классом предметной области. По графукомпонента может быть построен программный компонент как в ручном режиме,102в этом случае модель компонента используется как техническое задание, либо вавтоматическом режиме с помощью специализированного преобразователя.Генерация компонентов Plone является частным случаем, применимымтолько к указанной CMS. Для каждого вида программных компонент и вида CMS,их использующих, существуют свои особенности.
Так, для CMS Django генерациядолжна проводиться в два этапа. На первом этапе на основе декларативногоописания генерируются объектно-ориентированные классы. На втором этапе спомощью инструментов, интегрированных в CMS, генерируются таблицыреляционной базы данных. Разработка общей методики, учитывающей всеособенности различных средств разработки порталов, вряд ли возможна.Рисунок 54. Xml-представление компонентаГенерация производится на основе модели схемы компонента.
Генерацияпроисходит в два этапа. На первом этапе производится обход элементов схемы игенерируются два файла в формате XML — файл модели компонента и файл103конфигурации. Файл модели определяет типы всех полей компонента и на основеэтих данных программа paster генерирует код компонента. Конфигурационныйфайл определяет способ установки компонента. Пример xml-модели длярассматриваемого ранее модели онтологического класса представлен на рисунке(Рисунок 56).На втором этапе используется внешняя программа paster, позволяющаягенерировать «скелеты» различных программных компонентов для CMS Plone.Полученные на первом этапе xml-файлы включаются в состав «скелета»программного компонента, после чего компонент может быть интегрирован вCMS Plone или быть передан на дальнейшую программную модификацию.Вопросы программного вызова и управления paster в данной реализациигенератора компонентов не рассматриваются.Выводы по главе 21.
Разработанная модель абстрактной семантической сети вместе с языкомформального описания семантической сети обеспечивает возможность созданияформальных многоуровневых семантических моделей.2. Введеный механизма семантических аннотаций позволяет устанавливатьмежду моделями разных уровней отношение «метаинформация – информация» итранслировать структурные особенности и модели поведения с метауровня нанижележащие уровни.3. Подход «системы систем» позволил разработать методологиюпроектирования, которая позволяет объединять различные группы описаний ИСи, соответственно, их модели в общее информационное пространство проектаразработки ИС. Взаимодействие между моделями обеспечивается адаптерами,позволяющей представлять все модели в терминах языка описания абстрактнойсемантической сети.4. Разработаная онтология архитектуры позволяет в рамках конфигурациипроекта определять целевую и обеспечивающую системы.
Выделениеобеспечивающей системы позволяет разрабатывать обобщенные моделиподсистем ИС основываясь на модели предметной области и модели задач ИС. Вдальнейшем эти обобщенные модели конкретизируются элементами и библиотексправочных данных обеспечивающей системы. Процесс пополнение библиотексправочных данных отделен от процесса проектирования ИС, пополнениепроизводится независимо от разработчиков ИС, наличие таких библиотекпозволяет повторно использовать артефакты проектирования.5. Предложенный формализм объектно-ориентированного представлениясемантической модели позволяет моделировать структуры храненияинформационных ресурсов в терминах, определенных в разработанной онтологииинформационных элементов.1046.
Обеспечена семантическая интероперабельность в рамках типов,объявленных в метаонтологии ISO 24744.7. Предложенное отнесение каждого онтологического класса к некоторомутипу метаонтологии позволяет создавать запросы, проводить поиск иинтерпретировать знания, используя общий словарь, разделяемый всемионтологиями, определять шаблоны семантической сети, релевантные для частныхонтологий, позволяет представить все классы, объекты и отношенияунифицировано, в единой модели данных.8. Созданная метаонтология позволяет создать единое информационноепространство и инструментальные оболочки над ним, обеспечивая вертикальнуюинтеграцию и согласование моделей между собой и с уровнем хранениягетерогенных информационных ресурсов.9.
Предложенная горизонтальная интеграция между моделями одногоуровня обеспечивается созданием онтологий связи, элементами которыхвыступают специальные семантические структуры адаптеры.10. Предложенный подход позволяет производить проектирование СУБЗдекларативно на каждом этапе жизненного цикла системы и обеспечиваеттрансформацию одних моделей в другие на основе правил адаптации моделей.При этом генерация программных элементов может производиться для разныхсистем реализации приложения. Для этого создаются онтологии для каждой изсистем реализации, производится слияние онтологии ИС с выбранной онтологиейреализации и на основе полученной общей онтологии генерируются программныекомпоненты.11.
Для рреализации всех перечисленных выше возможностей необходимаразработка специальных инструментальных средств обеспечения процессапроектирования и реализации ИС..105ГЛАВА 3. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯУПРАВЛЕНИЯ БЗ НА ОСНОВЕ МНОГОУРОВНЕВЫХСЕМАНТИЧЕСКИХ МОДЕЛЕЙ ГЕТЕРОГЕННЫХИНФОРМАЦИОННЫХ РЕСУРСОВВзаимосвязанность всех ранее обсуждаемых семантических моделейприводит к необходимости наличия интегральной оболочки, связывающейразличные инструментальные средства управления этими моделями,позволяющую создавать единое рабочее пространство для всех разработчиков,независимо от их профессиональных особенностей, и предоставляющуюинструментарий, учитывающий специфические профессиональные требования. Кзадачам, решаемым такой оболочкой, в дальнейшем будем называть ее «Системойпроектирования портала» (СПП) следует отнести организацию общего слояхранения для всех моделей, предоставление сервисов поиска, трансформации ипредставления, единых для всех моделей, а также организациюунифицированного пользовательского интерфейса.3.1.
Платформа PloneModelerСистема проектирования портала платформа [95][96][97] представляет собойпрограммно-информационный интернет-комплекс «PloneModeler», реализующийсистему управления базами знаний, контролируемый доступ и единую системуадминистрирования для создания и использования интеллектуальных сервисов иих компонентов, представленных семантическими сетями, поддержкуфункционирования агентов (через передачу и обработку сообщений, запускметодов).Интернет-комплекс «PloneModeler» обеспечивает удаленный доступконечным пользователям к интеллектуальным системам, как входящим в егосостав, так и к внешним системам, после их соответствующей регистрации. Дляразработчиков и управляющих комплекс предоставляет возможности доступа ксредствам создания интеллектуальных систем и управления ими.В настоящее время комплекс является развитием системы управлениясодержимым (CMS Plone), дополненной интеллектуальной системой создания иуправления базами знаний и системой управления гетерогеннымиинформационнымиресурсами.Системауправлениягетерогеннымиинформационными ресурсами позволяет создавать их семантическиепредставления, и управлять информационными ресурсами декларативно,посредством управления представляющими их семантическими сетями.Основными архитектурными компонентами интернет-комплекса являются:объектно-ориентированное семантическое хранилище, система управлениябазами знаний и виртуальная машина.106Объектно-ориентированное семантическое хранилище позволяет хранитьпрограммные и информационные ресурсов различных типов, как традиционнопредставленные в CMS файлы, медийные ресурсы, базы данных, так исемантические онтологии, базы знаний и прикладные (в частности,интеллектуальные сервисы) и инструментальные средства (средства разработки иуправления).Система управления базами знаний (СУБЗ) представляет собойинтеллектуальную систему проектирования, являющейся инструментальнойоболочкой над объектно-ориентированным хранилищем.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
