Содержание к диссертации
Введение
Глава 1. Анализ современного состояния методов проектирования и разработки информационных систем. Постановка задач исследования 10
1.1. Моделеориентированные методы анализа систем 10
1.2. Онтологическая модель информационной системы 10
1.3. Интеллектуальная информационная система 11
1.4. Предметное пространство ИС 12
1.5. Архитектурные описания информационной системы 15
1.6. Жизненный цикл информационной системы 16
1.7. Метамодель стандарта ISO 24744
1.3. Особенности проектирования и разработки систем управления базами знаний 20
1.4. Постановка задач исследования 22
ГЛАВА 2. Разработка математического обеспечения для управления базами знаний на основе многоуровневых семантических моделей гетерогеннных информационныхресурсов 24
2.1. Обоснование выбора математических методов представления и обработки семантических
моделей 24
2.1.1. Многоуровневые семантические модели 24
2.1.2. Разработка языка формального описания 26
2.1.3. Объектно-ориентированное представление семантических моделей 31
2.1.4. Методы многоуровневого объектно-ориентированного моделирования 34
2.1.5. Метод семантического согласования для многоуровневой семантической модели 37
2.2. Обоснование моделей и алгоритмов обработки информации 38
2.2.1. Классификация онтологий 40
2.2.2. Методы и задачи управления знаниями 42
2.2.3. Метод обеспечения целостности описания информационной системы
2.2.6. Разработка модели данных для хранения объектно-ориентированных баз знаний 49
2.2.7. Модель абстрактной семантической сети 56
2.2.8. Модель данных абстрактной семантической сети 58
2.2.9. Управление семантической сетью
2.2.10. Методы управления информационными моделями 64
2.2.11. Онтология информационных элементов 64
2.2.12. Построение информационной модели 67
2.2.13. Метод согласования моделей 67
2.2.14. Методы и алгоритмы поиска 70
2.4. Разработка моделей, методов и алгоритмов проектирования программных систем 74
2.4.1. Разработка онтологии ISO 24744 74
2.4.2. Методы и алгоритмы моделирования архитектуры информационной системы 77
2.4.3. Методы и алгоритмы построения функционального представления
2.4.4. Методы разработки интерфейса пользователя 93
2.4.5. Методы разработки и управления программными компонентами 100
Выводы по главе 2 104
Глава 3. Разработка программного обеспечения для управления БЗ на основе многоуровневых семантических моделей гетерогенных информационных ресурсов 106
3.1. Платформа PloneModeler 106
3.2. Выбор среды разработки 107
3.3. Разработка компонентов инструментальной среды
3.3.1. Агент запросов 108
3.3.2. Конфигуратор команд 109
3.3.3. Агент визуализации 111
3.3.4. Автоматическое создание формы по структуре данных 112
3.3.5. Сервис трансформации 113
3.3.6. Пакеты системы управления 114
3.3.7. Компонент управления базами знаний OntoEditor . 115
3.3.8. Формальная модель редактора предметной области 121
3.3.9. Редактор компонентов 122
3.3.10. Редактор визуальных элементов 124
Выводы по главе 3 127
Заключение 129
Список литературы 130
- Интеллектуальная информационная система
- Разработка языка формального описания
- Разработка моделей, методов и алгоритмов проектирования программных систем
- Компонент управления базами знаний OntoEditor
Введение к работе
Актуальность исследования. Особенностью современных веб-ориентированных информационных систем (ИС) является широкое использование разнородных, в том числе, распределённых, объектов, сервисов и инфраструктур (например, технологии облачных вычислений). В результате современная веб-ИС представляет собой сложную систему, отдельные подсистемы которой (программные модули ИС) разрабатываются независимо друг от друга и функционируют автономно, то есть, по сути, являются независимыми системами.
В этой ситуации одной из наиболее важных становится проблема сохранения целостности описания ИС. Различные подходы к решению частных задач разработки веб-ИС исследовались в работах Д.Г. Колб, В.В. Грибовой, Ю.А. Загорулько и др. Анализ известных подходов к решению данной проблемы показывает, что одним из наиболее перспективных является подход, основанный на использовании семантические моделей (СМ) - декларативных описаний данных, средств их обработки и конфигураций, который упрощает интеграцию различных информационных ресурсов. Однако для широкого практического использования СМ в практике проектирования, разработки и сопровождения веб-ИС необходима научно обоснованная комплексная технология компонентного проектирования семантически совместимых ИС различного назначения и разработка соответствующих программных инструментов.
Степень разработанности. Универсальные СМ представления и обработки знаний, варианты их технической реализации семантических моделей были исследованы в работах А.С. Клещевым, И.Л. Артемьевой, В.В. Голенкова, В.Ф. Хорошевского, Т.А. Гавриловой. и др. Однако по-прежнему остается нерешенным целый ряд проблем, связанных с практическим использованием СМ, которые обусловлены отсутствием: методов представления, хранения и управления многоуровневыми СМ, обеспечивающих единообразное управление разнородными информационными ресурсами; методов построения и интеграции архитектурных моделей ИС, разработанных в рамках различных методологических подходов; инструментальных средств, обеспечивающих использование СМ при проектировании и реализации ИС.
Целью исследования является разработка научно-обоснованных моделей, методов и языков, позволяющих согласовывать проектные описания ИС, представленные в виде СМ, с помощью единой формальной объектно-ориентированной модели.
Задачи исследования: 1. Анализ существующих методов анализа и проектирования ИС, способов обеспечения целостности описания ИС, выявление областей применения методов семантической формализации и СМ для управления ИС на каждом этапе ее жизненного цикла .
-
Теоретическое обоснование методов использования СМ при проектировании ИС.
-
Разработка инструментальных средств, обеспечивающих использование СМ при проектировании и реализации ИС (глава 3).
Объектом исследования являются методы разработки информационных систем.
Предметом исследования являются семантические методы разработки информационных систем.
Методы исследования. В работе использовались дескриптивная логика, методологии объектно-ориентированного анализа и моделирования информационных систем, онтологический анализ, методы системной инженерии.
Научная новизна.
-
Предложен объектно-ориентированный метод представления, хранения и управления многоуровневыми СМ, позволяющий организовать единообразное управление разнородными информационными ресурсами.
-
Предложен объектно-ориентированный метод построения и интеграции архитектурных моделей ИС, разработанных в рамках различных методологических подходов, основанный на адаптации СМ целевой системы к семантическим моделям обеспечивающей системы.
-
Разработаны формальные модели, методы и алгоритмы разработки сложных инструментальных средств (ИнС), образующих инструментальную среду ИнС, на основе их формальных моделей.
Практическая значимость исследования.
На основе предложенной научной концепции автором разработаны:
-
Формальные модели, обеспечивающие процесс проектирования веб-ориентированных ИС, и соответствующий редактор концептуальных моделей.
-
Агенты: запросов к базе знаний, формирования инструментальной среды, визуализации баз знаний.
-
Веб-информационная система управления знаниями OntoEditor.
-
Веб информационная система проектирования PloneModeler.
-
Предложен способ интеграции разработанных программных средств с существующими ИС, обеспечивающий их адаптацию к изменяющимся в процессе эксплуатации требованиям.
Разработанные программные продукты использованы при создании и внедрении «Интеллектуальной системы проектирования веб-приложений» и «Интеллектуальной система управления учебным процессом» и подтверждены актами о внедрения результатов диссертационной работы.
Теоретическая значимость исследования состоит в разработке формальных моделей целевой и обеспечивающих систем и обосновании методов адаптации семантических моделей целевой системы к семантическим моделям обеспечивающей системы, обеспечивающие процесс проектирования веб-ориентированных ИС и их адаптацию к изменяющимся в процессе эксплуатации требованиям на стадии эксплуатации.
Положения, выносимые на защиту:
-
Методология и технология построения веб-ориентированных ИС на основе адаптации семантических моделей целевой системы к семантическим моделям обеспечивающей системы, позволяющие единым образом организовать сетевой доступ к разнородным информационным ресурсам (соответствует п. 1 паспорта специальности «Модели, методы и алгоритмы проектирования …программ и программных систем…»; п. 3 «Модели, методы, алгоритмы, языки и программные инструменты для организации взаимодействия программ и программных систем»).
-
Методы, модели и программные реализации инструментальных средств, обеспечивающие создание и управление объектно-ориентированными базами знаний, объединенных в веб-приложение инструментальной среды проектирования OntoEditor (соответствует п. 1 паспорта специальности «Модели, методы и алгоритмы проектирования …программ и программных систем…»; п. 3 «Модели, методы, алгоритмы, языки и программные инструменты для организации взаимодействия программ и программных систем»; п. 4 «Системы управления базами данных и знаний»).
Внедрение результатов диссертационного исследования. Результаты диссертационного исследования используются в ФГАОУ ВПО «Уральский федеральный университет им. первого Президента России Б.Н. Ельцина» в учебных курсах «Теория информационных процессов и систем» и «Методы и средства проектирования информационных систем» в качестве виртуальных лабораторий разработки информационных систем.
Апробация работы диссертации. Результаты работы докладывались и обсуждались на следующих научных конференциях и семинарах: Международная научно-методической конференция «Новые образовательные технологии в вузе», Екатеринбург, февраль 2010 г.; Всероссийская научно-практическая конференция «Актуальные вопросы использования инновационных технологий в образовательном процессе», Нижний Тагил, январь, 2010г.; Международная научно-практическая конференция «Объектные системы – 2010», Ростов-на-Дону, май, 2010 г.; Региональная научно-практическая конференция «Молодежь и наука», Нижний Тагил, май, 2010 г.; VIII Международная научно-методическая конференция «Новые образовательные технологии в вузе». Екатеринбург, февраль, 2011г.; III Международная научно-практическая конференция «Объектные системы – 2011», Ростов-на-Дону, май 2011 г.; V Международная научно-практическая конференция «Объектные системы – 2011(Зимняя сессия)», Ростов-на-Дону, декабрь, 2011 г.; VI Международная научно-практическая конференция «Объектные системы – 2012», Ростов-на-Дону, май 2012 г.; VII Международная научно-практическая конференция «Объектные системы – 2013», Ростов-на-Дону, май 2013 г.; Региональная научно-практическая конференция «Молодежь и наука», Нижний Тагил, май, 2014 г.; VIII Международная научно-практическая конференция «Объектные системы – 2014», Ростов-на-Дону,
май 2014 г.; X Международная научно-практическая конференция «Объектные системы - 2015», Ростов-на-Дону, май 2015 г.
Структура и объём диссертации. Диссертация состоит из введения, трех глав, заключения, списка литературы из 106 наименований, списка сокращений и условных обозначений, 1 приложения, содержит 71 рисунок и 3 таблицы. Основной текст работы составляет 140 страниц, общий объем 143 страницы.
Интеллектуальная информационная система
Стандарт ISO 42010 Никакой одной профессиональной точки зрения недостаточно, чтобы получить более или менее полное реализационное описание ИС. Для ИС должны быть получены различные группы взаимосвязанных описаний, часто получаемые в междисциплинарном рассмотрении. Стандарт предписывает, что у любой системы есть одна или несколько заинтересованных сторон (stakeholders). Каждая из них имеет набор интересов (concerns), связанных с системой, и стремится их удовлетворить. Для удовлетворения каждого из интересов создаются отдельные группы описаний (views) системы. Группа описаний (ГО) раскрывает отдельный аспект системы, а набор групп образует ее полное описание. Соглашения, по которым ГО создается, отображается и анализируется, устанавливаются методом описания (viewpoint). Каждая ГО создается в соответствии со своим методом описания.
Таким образом, в стандарте система рассматривается как группа архитектурных описаний, каждое из которых является специфично определяемой точкой зрения различных заинтересованных лиц, выраженной в некоторой нотации языка описания. Для согласования требований и архитектурных описаний ISO 42010 рекомендует использовать специальные архитектурные языки и подходы (framework) к архитектурному описанию.
Подход ISO 42010 прописывает необходимость множества представлений и групп описания для системы, формирующих архитектурное описание системы. С этой точки зрения концепт предметной области является центральной, интегрирующей точкой всех описаний системы, в том смысле, что: - он является элементом реального мира, взятым во всей его полноте. - полнота описания определяется полнотой описаний в рамках различных групп описаний, характеризуемых своими способами представления— семантикой, нотациями, языками и т.п.
В свою очередь, организация систематизированного хранения моделей в виде информационных объектов и структуры, определяющей связи между ними, а также изменения в структуре знаний, связанные с изменениями в предметной области, усложняют процесс проектирования систем хранения онтологий, требуя разработки устойчивой к таким изменениям структуры данных, методов проектирования логических схем данных и определения релевантных этим задачам способов формального описания и хранения онтологий знаний и данных [29].
Сложная ИС рассматривается как взаимодействие различных модулей, требования к которым определяются в процессе декомпозиции. Построение этих модулей, как правило, не производится на базе какой-то общей системы понятий: каждому модулю соответствует своя (по типу) деятельность и используется специфическая терминология. Жизненный цикл (ЖЦ) ИС предполагает решение задач, не только напрямую связанных с выбранной предметной областью, но также характеризующих деятельность и ее технологические аспекты в период разработки.
Каждый этапов разработки ИС имеет сложную структуру, определяемую видами деятельности, характерными для каждой группы описаний. Для каждого из этапов может потребоваться создание специфических методов и моделей. Деятельность, как сложная система, тоже может иметь несколько ГО, удовлетворяющих интересы разных сторон. Так, например, одни заинтересованных стороны требуют создания моделей проектов, другие моделей процессов. Часть моделей может носить глобальный характер с точки зрения их типизации и примитивов моделирования, но быть специфичными для каждого из этапов и группы описания. Так, модель задач, фиксирующая задачи и процессы, компонентная модель, определяющая программную реализацию компонентов, а также модель данных, определяющая способы хранения данных для каждого компонента, задачи или процесса строятся для каждого из этапов из специфичных для него примитивов моделирования.
Для создания этих ГО применяются разнородные инструменты и языки моделирования. В результате отсутствует совместимость получаемых описаний, требуемая для решения поставленной проблемы. Кроме того, существующие языки обладают рядом недостатков, ограничивающих возможность выражения реального мира в моделях.
В стандарте ISO 42010 определено, что должно быть проведено согласование различных моделей, но не определен способ согласования. В моделеориентированном подходе способом согласования является метамодель. Метамодель, должна обеспечивать общую методологическую базу для описания всех моделей. При этом необходимо обеспечить описание методов, применяемых на протяжении ЖЦ (что делать), а также описание их синхронизации в конкретную форму ЖЦ (когда делать). Метод – это зафиксированный, распространяемый способ выполнить определенную работу. Это микропроцесс, который может включать в себя ряд шагов, но не несет информации о том, когда он будет использован в конкретном ЖЦ. Для выражения темпорального аспекта описывается форма ЖЦ (макропроцесс), которая представляет собой использование методов во времени (в течение стадий ЖЦ). Эти аспекты должны быть интегрированы в ГО деятельности, но зачастую они описываются раздельно с помощью инструментов управления процессами и проектами соответственно. Одновременно с этим, часть методов, используемых для построения этих моделей, будут общими для всех этапов разработки. Примитивы моделирования, используемые методами, ориентированы на акты деятельности, на рабочие продукты, и на исполнителей, т.е. строятся в рамках словаря, определяемого метаонтологией, но специализируют ее семантику для каждой группы описаний.
Главное преимущество такого подхода состоит в возможности создания наборов методов, которые включают описание множества различных аспектов, в поддержке различных уровней описания. Имеющиеся описания методов позволяют собирать и настраивать новые, более крупные методы в рамках ЖЦ информационной системы. Известен ряд метамоделей, часть из которых стандартизирована и повсеместно применяется. Среди них: OMG SPEM 2.0, ISO 24744, а также работы инициативы SEMAT [30]. Эти продукты могут использоваться для моделирования ЖЦ.
Стандарт ISO 24744 [31] определяет способы согласования различных групп описаний в процессах описания жизненного цикла приложения и предоставляет метамодель для обеспечения такого согласования. Так, в стандарте определено понятие методологии, как спецификация процесса, которому нужно следовать в ходе рассмотрения предметной области. Методология специфицируется продуктами работы, которые будут использованы и созданы вовлекаемыми в процессы людьми с использованием инструментов, определенных в методологии. Методология обычно специфицирует тот процесс, который будет выполняться, как набор взаимосвязанных деятельностей, дел и/или способов работы, вместе с продуктами работы, которыми кто-то манипулирует (создаёт, использует, или изменяет) в каждый момент, возможно включая модели, документы и другие входы и выходы. В свою очередь, спецификация моделей, с которыми нужно иметь дело, включает основные строительные блоки, из которых их нужно будет конструировать. Часть UML-представления стандарта представлена на рисунке (Рисунок 6).
Разработка языка формального описания
Для уточнения семантики объектно-ориентированной модели данных будем рассматривать семантическую сеть G={{Ci}, {Rj}} как множество узлов С и связей R. Определим для узлов и связей множества типов узлов: TC={Onto, ОСЬ, Ontolnd} и множество типов связей: TR={DatProp, ObjProp, ClsDatProp, ClsObjProp, IndDatProp, IndObjProp}. Определим семантику узлов и связей и их множеств: Onto - множество онтологических модулей О, представляющих сети более низкого уровня DP - множество элементов типа DatProp, определяющих сорта описания данных; ОР - множество элементов типа ObjProp, определяющих сорта связей; ОСЬ - множество элементов типа OntoCls; OI - множество элементов типа Ontolnd; 0= title, id, ОС, DP, OP, OI , где title - наименование узла, / -идентификатор узла; OntoCls= title,id,subClassOf,hasKindOf,rootclass,ClsDP,ClsOP - элемент сети, представляющий класс онтологии, здесь subClassOf - множество классов, являющихся родительскими для элемента, hasKindOf - множество классов и объектов, аннотирующих класс семантическим описанием, rootclass - атрибут, указывающий на уровень в иерархии классов в модуле;
DatProp= title,id,range\XMLSchemeDatetype тип связи, определяющий характер представления элемента сети простым типом данных, где range - множество классов, наследующих класс XMLSchemeDatetype, представляющий семейство простых типов, определяет верхний уровень в иерархии элементов типа ClsDP;
ObjProp= title,id,range:NotXMLSchemeDatetype - тип связи, определяющий характер связи элемента сети с элементами, не принадлежащими множеству простых типов данных, определяет верхний уровень в иерархии элементов типа ClsOP;
ClsDP= title,id,parent,dataProperty:DProp,range -элемент, представляющий множество значений атрибута класса parent, здесь dataProperty указатель на элемент в частной иерархии элементов ClsDP, range - ограничение, дополнительно накладываемое на множество ограничений на тип простых значений, определяемое иерархией dataProperty ;
ClsOP= title,id,parent,SubPropertyOf,range - элемент, представляющий множество допустимых связей атрибута с именем title класса parent, здесь Sub-PropertyOf указатель на элемент в частной иерархии элементов ClsOProp, range ограничение, дополнительно накладываемое на множество ограничений на тип связываемых элементов, определяемое иерархией SubPropertyOf
OntoInd= title, id, sourceClass, IndDP, IndOP - экземпляр класса онтологии, где sourceClass - родительский класс для экземпляра;
IndDP= title, id, parent, dataProperty, range - элемент, представляющий множество значений атрибута класса parent, dataProperty указывает на элемент в частной иерархии элементов ClsDP, range - ограничение, дополнительно накладываемое на множество ограничений на тип простых значений, определяемое иерархией dataProperty ;
IndOP= title, id, parent, SubPropertyOf, range — элемент, представляющий множество допустимых связей атрибута с именем title класса parent, здесь SubPropertyOf указывает на элемент в частной иерархии элементов ClsOProp, range - ограничение, дополнительно накладываемое на множество ограничений на тип связываемых элементов, определяемое иерархией SubPropertyOf.
В соответствии с предложенной моделью определим набор компонентов хранения баз знаний [69]:
CADT={Ontology,OntoClass ataProperty,ObjectProperty,ClasssDataProperty, ClassObjectProperty,OntoIndividual,IndDataProperty,ndObjectProperty}, обеспечивающий отображение высказываний, представленных в семантической сети в сеть объектов:
Ontology = ОСЫрР,ОР,ОГ - онтологический модуль, представляющий семантическую сеть и агрегирующий множество элементов DP - множество элементов типа DataProperty, определяющих сорта описания данных; Р -множество элементов типа ObjProperty, определяющих сорта связей; ОСЬ— множество элементов типа OntoClass; OI — множество элементов типа Ontolndividual;
OntoClass= ClsDP,ClsOP - компонент, представляющий класс онтологии, и агрегирующий множества элементов, где ClsDP и ClsOP -множество элементов ClassDataProperty и ClassObjectProperty, соответственно, определяющие связи класса с узлами сети;
DataProperty - компонент, определяющий характер связи элемента сети с элементом сети, представляющим простой тип данных, определяет верхний уровень в иерархии элементов типа ClassDataProperty;
ObjectProperty - компонент, определяющий тип связи элемента сети с элементами, не принадлежащими множеству простых типов данных, определяет верхний уровень в иерархии элементов типа ClassObjectProperty;
ClassDataProperty - компонент, определяющий связь элемента сети, с типом компонента OntoClass с элементами, принадлежащими множеству простых типов данных; ClassObjectProperty - компонент, определяющий связь элемента сети типом компонента OntoClass с элементами, не принадлежащими множеству простых типов данных;
Ontolndividual = IndDP, IndOP - компонент, представляющий экземпляр класса онтологии и агрегирующий множество элементов IndOP - множество элементов IndDataProperty и IndOP - множество элементов IndObjectProperty соответственно, определяющие связи экземпляра класса с узлами сети; IndDataProperty - элемент сети, определяющий связь элемента сети типом Ontolndividual с элементами, принадлежащими множеству простых типов данных; IndObjectProperty - компонент, определяющий связь элемента сети типом Ontolndividual с элементами, не принадлежащими множеству простых типов данных.
Разработка моделей, методов и алгоритмов проектирования программных систем
Первым шагом в проектировании ИС является моделирование её задач и определении способов ее решения. Решение задачи в рамках используемого в исследовании системного подхода состоит в делегировании задачи системы задаче обеспечивающей системы или в принятии решения о необходимости разработки метода решения, в рамках которого такое делегирование станет возможным. Результатом этой деятельности должны стать несколько архитектурных описаний, например структура задач, определяющая декомпозицию задачи на множество частных задач обеспечивающей системы, схема решаемых задач – модель, упорядочивающая последовательность выполнения задач (поток задач).
Структура задач ИС может быть достаточно сложной и изменяться в процессе проектирования и реализации системы. Требования к информационной системе строятся как семантическая сеть классов задач, используя классы Модель задач и Задача. Структура класса Задача онтологии ISO 24744: Класс Описание задачи предусмотрен для хранения входных параметров задачи, ее текстового или иных описаний, условий выполнения и ограничений. Класс Producer в метамодели ISO 24744 опрелеяет участика процесса жизненного цикла системы, обладающего способностью проводить акты деятельности над элементами системы. В рамках рассмотрения задач проектирования в дальнейшем будем использовать класс Решатель задачи, понимая его как компонент систем, решающий задачу, без уточнения его технологической реализации. Класс Результат представляет выходные параметров задачи. Специализируя класс задачи и вида задачи можно получить разветвленную систему типов и классов задач, распределенных по разным онтологическим модулям. Так, например, класс Требование, имеющий в качестве метатипа класс Задача и класс Вид требования с подклассами Функциональное требование и Нефункциональное требование позволяет создавать модель требований к системе.
Аналогичным образом, класс Задача системы и класс Вид системы с подклассами Вид задача целевой системы и Вид задача обеспечивающей системы позволяют формировать модель задач целевой и обеспечивающей системы с соответствующими классификаторами в рамках онтологии проекта разработки целевой системы.
Ограничения на область определения связей на уровне определения типов метамодели задают структуру и области определений связей классов и объектов на всех нижележащих уровнях моделирования. Так отношение: обеспечивающей системы задает ограничение на область определения связи, ограничивая её классами задач целевой системы.
Формулировка задачи системы проводится после определения множества параметров задачи, включающее классы и объекты онтологии предметной области, запросы к онтологиям и адаптеры понятий. На основе сформированного множества создается онтология информационной модели задачи. В классах запросов и адаптеров определяются онтологические соглашения между информационными объектами различных предметных областей. Метод формирования информационной модели представлены в разделах исследования.
Класс Модель задач аккумулирует частные задачи связанные с реализацией общей задачи системы в контексте ее использования некоторой системой более высокого уровня
Модель задач системы управления учебным процессом показана на рисунке Рисунок 40. Модель задач системы управления учебным процессом Постановка задачи содержит метод решения задачи. Для класса метода определен тип решаемой задачи. Так выбор типа задачи «сложная задача» приведет к методу «декомпозиция задачи» [90]. Пример метода декомпозиции: - перебор всех классов задач системы; - для каждой задачи системы выполняется построение подмножества задач системы, не содержащее текущей задачи; - указание построенного множества в качестве области определение связи включает подзадачу активного класса задачи; Класс Метод определен в онтологии архитектуры и строиться как композиция специализаций класса Элемент методологии онтологии ISO 24744: @Метод.включает элемент метода= @Элемент методологии Метод.реализуется агентом.@Агент.
Выбранный метод определяет дальнейшую специализацию класса задачи. Задачи, имеющий общий характер, группируются в библиотеки задач. Возможность переводить метод решения задачи в библиотеку методов позволяет хранить знания о решении и повторно их использовать. Пример части разработанной справочной библиотеки задач для системы проектирования представлен на рисунке 41.
Компонент управления базами знаний OntoEditor
Из рисунка 65 видно, что в левой части размещена панель элементов, совмещенная с панелью вкладок. В центральной части расположена панель информации. Она содержит в себе полную информацию о выбранном объекте. Вся информация логически разбита на группы.
На панели элементов представлены объекты онтологии разных типов, сгруппированные в отдельные вкладки. Сами элементы выстроены в иерархические списки. В панели информации отображено большое число объектов онтологии различного типа. Каждый объект в панели информации является ссылкой. Это значит, что пользователь всегда может узнать более подробную информацию о каждом встретившемся объекте, просто щелкнув по нему мышкой. Одновременно с этим объект будет выбран на панели элементов, что позволит сразу же увидеть его место в иерархии объектов
Задача разработки специализированных редакторов, позволяющих строить модели в концептах специальных онтологий, решена в предположении о том, что в дальнейшем возникнет необходимость добавления новых редакторов. Несмотря на то, что редактор метаонтологии и позволяет решать практически все задачи проектирования в терминах АСС, его использование будет затруднено для членов групп разработчиков, напрямую не связанных с использованием онтологий. Для упрощения интерфейса пользователя каждый редактор рассматривается как отдельный раздел портала. Исходя из требований CMS Plone, это требует построения редактора как специфического компонента CMS. На рисунке (Рисунок 66) представлена обобщенная диаграмма классов редактора, специализация которой позволяет создавать редакторы для различных предметных областей.
В соответствии с этой моделью каждый редактор включает класс Model, который реализует интерфейс IContainer из API CMS Plone и определяет поведение контейнера элементов с операциями управления этими элементами, представленными объектами компонента Command. Каждому редактору сопоставляется некоторая онтология, реализуемая внешним по отношению к редактору классом. Модель включает в себя элементы, тип которых определяется связанной с редактором онтологией. Кроме того, элементы модели могут быть связаны между собой ссылками, при этом элементы могут принадлежать разным моделям. Таким образом, редактор представляет собой некоторый виртуальный контейнер, определенный на подграфе объектно-ориентированной семантической сети. Над этой сетью может быть определено неограниченное количество виртуальных редакторов различных типов. Все типы редакторов могут быть систематизированы в специальную онтологию редакторов, рассмотрение которой выходит за рамки обсуждаемой темы.
Редактор компонентов предназначен для моделирования схемы компонентов портала на основе онтологии схемы и онтологии предметной области. Для создания схемы используется набор компонентов, представляющих классы онтологии схемы и компоненты отображения классов метаонтологии, в терминах которой строится онтология предметной области. С помощью редактора производится моделирование схемы программного компонента на основе класса онтологии предметной области. В таблице (Таблица 3) приведен пример создания схемы программного компонент, реализующего класс Учебный курс онтологии предметной области. В данном случае модель состоит из шести полей, два из которых - «наименование курса» (cursename) и «описание курса» {curse description) представлены экземплярами компонента StringField, представляющего одноименный класс онтологии схемы, а остальные — экземплярами компонента ReferenceField. элемент предметной онтологии элемент онтологии схемы cursename:ClassDataProperty cursename:StringField curse description:ClassDataProperty cursedescription: StringField hasCreator: ClassObjectProperty creator: ReferenceField has assosiatedDisciplines:ClassObjectProperty disciplines: ReferenceField has assosiatedGroup:ClassObjectProperty groups: ReferenceField has assosiatedStorage:ClassObjectProperty storage: ReferenceField hasLearnProgram: ClassObjectProperty learn_program: ReferenceField Таблица 3. Сопоставление онтологического класса и модели его компонента. Пользовательский интерфейс редактора схемы аналогичен интерфейсу редактора навигационной модели. Окно редактирования схемы компонента «Учебный курс», предназначенного для представления класса «Учебный курс» онтологии предметной области, представлено на рисунке 59. Каждый компонент поля обладает атрибутами, значения которых устанавливаются в соответствующей форме редактирования. форма редактирования поля компонента «StringField» представлена на рисунке 67.
Таким образом каждому классу онтологии предметной области может быть поставлена в соответствии схема компонента на основе которой соответствующий интерпретатор может генерировать код компонента.
Редактор визуальных элементов является специализированным инструментальным средством, предлагающим ряд функций и уровней автоматизации при разработке модели пользовательского интерфейса приложения[107]. Редактор позволяет в визуальном режиме представлять высказывания на языке моделирования шаблонов TAL, используемом в CMS Plone для спецификации всех шаблонов веб-страниц. Примитивы языка представлены в онтологии пользовательского интерфейса (рисунок 69). J- _J_ объемлющий тег Рисунок 69. Формальная модель языка Таї