Диссертация (1090633), страница 22
Текст из файла (страница 22)
Несмотряна то, что редактор метаонтологии и позволяет решать практически все задачипроектирования в терминах АСС, его использование будет затруднено для членовгрупп разработчиков, напрямую не связанных с использованием онтологий. Дляупрощения интерфейса пользователя каждый редактор рассматривается какотдельный раздел портала.
Исходя из требований CMS Plone, это требуетпостроения редактора как специфического компонента CMS. На рисунке(Рисунок 66) представлена обобщенная диаграмма классов редактора,специализация которой позволяет создавать редакторы для различныхпредметных областей.Рисунок 66. Диаграмма классов модели редактораВ соответствии с этой моделью каждый редактор включает класс Model,который реализует интерфейс IContainer из API CMS Plone и определяетповедение контейнера элементов с операциями управления этими элементами,представленными объектами компонента Command.
Каждому редакторусопоставляется некоторая онтология, реализуемая внешним по отношению к121редактору классом. Модель включает в себя элементы, тип которых определяетсясвязанной с редактором онтологией. Кроме того, элементы модели могут бытьсвязаны между собой ссылками, при этом элементы могут принадлежать разныммоделям. Таким образом, редактор представляет собой некоторый виртуальныйконтейнер, определенный на подграфе объектно-ориентированной семантическойсети. Над этой сетью может быть определено неограниченное количествовиртуальных редакторов различных типов.
Все типы редакторов могут бытьсистематизированы в специальную онтологию редакторов, рассмотрение которойвыходит за рамки обсуждаемой темы.3.3.9. Редактор компонентовРедактор компонентов предназначен для моделирования схемы компонентовпортала на основе онтологии схемы и онтологии предметной области. Длясоздания схемы используется набор компонентов, представляющих классыонтологии схемы и компоненты отображения классов метаонтологии, в терминахкоторой строится онтология предметной области. С помощью редакторапроизводится моделирование схемы программного компонента на основе классаонтологии предметной области. В таблице (Таблица 3) приведен пример созданиясхемы программного компонент, реализующего класс Учебный курс онтологиипредметной области.
В данном случае модель состоит из шести полей, два изкоторых «наименование курса» (cursename) и «описание курса»(curse_description) представлены экземплярами компонента StringField,представляющего одноименный класс онтологии схемы, а остальные —экземплярами компонента ReferenceField.элемент предметной онтологииэлемент онтологии схемыcursename:ClassDataPropertycursename:StringFieldcurse_description:ClassDataPropertycurse_description: StringFieldhasCreator: ClassObjectPropertycreator: ReferenceFieldhas_assosiatedDisciplines:ClassObjectPropertydisciplines: ReferenceFieldhas_assosiatedGroup:ClassObjectPropertygroups: ReferenceFieldhas_assosiatedStorage:ClassObjectPropertystorage: ReferenceFieldhasLearnProgram:ClassObjectPropertylearn_program: ReferenceFieldТаблица 3.
Сопоставление онтологического класса и модели его компонента.Пользовательский интерфейс редактора схемы аналогичен интерфейсуредактора навигационной модели. Окно редактирования схемы компонента«Учебный курс», предназначенного для представления класса «Учебный курс»онтологии предметной области, представлено на рисунке 59.
Каждый компонентполя обладает атрибутами, значения которых устанавливаются всоответствующей форме редактирования. форма редактирования полякомпонента «StringField» представлена на рисунке 67.122Рисунок 67. Форма редактирования поля компонента «StringField».форма редактирования поля типа RelationField. представлена на рисунке 68.Рисунок 68. Форма редактирования поля типа RelationField123Таким образом каждому классу онтологии предметной области может бытьпоставлена в соответствии схема компонента на основе которой соответствующийинтерпретатор может генерировать код компонента.3.3.10. Редактор визуальных элементовРедакторвизуальныхэлементовявляетсяспециализированныминструментальным средством, предлагающим ряд функций и уровнейавтоматизации при разработке модели пользовательского интерфейсаприложения[107].
Редактор позволяет в визуальном режиме представлятьвысказывания на языке моделирования шаблонов TAL, используемом в CMSPlone для спецификации всех шаблонов веб-страниц. Примитивы языкапредставлены в онтологии пользовательского интерфейса (рисунок 69).Рисунок 69. Формальная модель языка Tal124Модели, созданные с использованием редактора, могут быть преобразованыв выполнимую спецификацию. Функции редактора формально можно разделитьна две группы: Связанные с построением логической структуры пользовательскогоинтерфейса. Связанные с проектированием разметки отдельных визуальныхкомпонентов.Редактор позволяет строить модели в двух нотациях — в нотации понятийвизуальных компонентов, представленных компонентами GUI_компонент, и внотации языковых описаний визуальных компонентов, представляющихвыражения языка TAL—TAL_компонент.
Компоненты GUI_компонентпредназначены для моделирования статичных визуальных элементов и разметкистраниц, компоненты TAL_компонент позволяют моделировать процессыгенерации визуальных интерфейсов. Семантическая модель редакторапредставлена на рисунке 70.Рисунок 70. Семантическая модель редактора интерфейса.125Классы MetalContainer и TalContainerслужат для организации структурыhtml-контейнеров, содержащихт команды языка TAL.
Свойство tagnameопределяет значение html-тега, обрамляющего команды TAL, а свойство tagvalueопределяет значение соответствующего тега, обычно это строковая величина.Аналогичный смысл имеют одноименные свойства и у всех других классовданного редактора. Набор классов с префиксом «tal»представляет команды языкаописания шаблонов.Класс talcontent позволяет определять в качестве значение тега,используемого для описания команды данные, получаемые из источника,связанного с объектом этого класса. Свойство pathvalue служит для хранениязначения «переменной пути» строкового выражения, определяющегонахождение источника данных для соответствующей команды.
В качествеисточника может выступать свойство связанного объекта, результат выполненияметода объекта, выражение на языке Python и т.п.В данной реализации редакторапредполагается ручной ввод выражения, в дальнейшем возможно созданиеспециального построителя выражений в соответствии со спецификацией языкаописания шаблонов. Кроме такого указания источника данных можно указатьисточник данных непосредственной ссылкой на объект базы данных.Класс talreplace позволяет определять способы замены html-блока,определяемым текущим обрамляющим тегом объекта команды блоком,получаемым из источника данных.Класс talrepeat предназначен для организации итерационной обработкиданных внешнего источника, например, для организации списка гиперссылок,значения для атрибутов которых хранятся в структуре внешнего источника.Класс talattributes позволяет определять источники данных для атрибутовобрамляющего тега объекта класса.Класс taldefine позволяет определять внутренние переменные шаблона,значения которых получены или из атрибутов связанного источника данных илиявляются результатом выполнения внешних программных элементов.Класс talcondition определяет проверку некоторого условия, источникомкоторого служит связанный объект.Визуальная модель создается как иерархическая структура объектовкомпонентов GUI_компонент, включающих в себя объекты компонентов,представляющих команды языка.
Пример абстрактной модели для формыпросмотра учебного курса, представленной в окне редактора, показан на рисунке71.126Рисунок 71. Модель формы просмотра класса «Учебный курс»Каждый абстрактный элемент интерфейса может быть связан с конкретнымпредставлением несколькими способами: указанием класса онтологии, наследующего класс ConcreteInterfaceElement; указанием класса, наследующего TAL_компонент; указанием на выражение языка TAL.Генерация визуальных компонент производится на основании моделипользовательского интерфейса, представленной экземплярами класса AbstractInterfaceElement. Модель получается программным способом, путемотображения моделей интерфейса, созданных в среде редактора, в выраженияязыка TAL.
Полученное языковое представление средствами CMS Ploneинтерпретируется в код на языке HTMLи отправляется клиенту системы.Процесс генерации итерационен. Первоначально анализируется разметкакомпонента, получаемая из экземпляра ConcreteInterfaceElement, связанного ссамым верхним абстрактным элементом в иерархии, и полученная логическаяструктура преобразуется в код на языке разметки со ссылками на объекты –источники данных. На втором этапе используются методы экземпляров ConcreteInterfaceElement, которые "знают", какие элементы есть в их логическойструктуре и как визуализировать каждый из этих элементов. Таким образом,система с множеством экранов может быть трансформирована в код HTML путемединственного прохождения второго этапа, благодаря чему решение о вариантепреобразования в HTMLпринимается в одном месте.
Разумеется, воспользоватьсятаким преимуществом удастся только в том случае, когда логические экраныкомпонуются по одному принципу.Выводы по главе 31. Разработанные инструментальные средства решают задачи, выявленныедля различных групп пользователей разработчиков информационной системы.2. Каждый из представленных редакторов позволяет редактировать одну изонтологий верхнего уровня, определяющую словарь предметной области.3.
Единое информационное пространство реализовано как объектноориентированная семантическая сеть объектов компонент, моделирующих127примитивы метаонтологии. Благодаря этому отсутствует необходимость вадаптерах между объектами, представляющими классы и их экземпляры вразличных онтологий.4. Разработанные редакторы определяют различные семантики, в то времякак хранение данных, и их обработка проводится над классами, объектами иотношениями метаонтологии.5. Каждая отдельно взятая онтология представляет собой объектопределенного компонента и, поэтому может быть многократно использована,скопирована, переименована и т.д.6.
Разработанные инструментальные средства можно использовать, в томчисле, в период эксплуатации системы, что позволяет изменять возможностисистемы путем декларативного представления требований с последующимавтоматическим изменением пользовательского интерфейса и конфигурациисервисов обработки.128ЗАКЛЮЧЕНИЕПроведен анализ существующих методов анализа и проектирования ИС,способы обеспечения целостности описания ИС, методы семантической формализации и СМ, используемые для управления ИИС на этапах ее ЖЦ, и обоснованацелесообразность представления процесса разработки ИИС как последовательноезаполнение базы знаний, строящейся как надсистема над независимыми базамизнаний, в которых хранятся знания о предметной области, методах, задачах и инструментах ИИС.2. Научно обоснованы математические методы, модели и алгоритмы обработки информации для управления БЗ на основе многоуровневых математическихмоделей гетерогенных информационных ресурсов.3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
