Диссертация (1090633), страница 16
Текст из файла (страница 16)
Структура наследования и связейонтологических классов онтологии архитектуры, представленная в окнеспециально разработанного редактора онтологий, показана на рисунке 34.Рисунок 34. Онтология архитектурыКласс архитектура задает структуру архитектурных описаний, определяетонтологические модули для каждого архитектурного описания, определяетадаптеры между архитектурными описаниями, согласующие их понятия:@архитектура.имеет.{@группа описаний, @Адаптер}группа_описаний.включает.@модельгруппа_описаний.использует.@модуль онтологииРисунок 35. Архитектура системы80Каждая отдельно взятая модель строится в понятиях модуля онтологии(одного или нескольких), определенного для группы описания.
Примермоделирования архитектуры для интеллектуальной системы управления учебнымпроцессом представлен на рисунке 35. Архитектура ИС включает в себянесколько архитектурных описаний, представленных моделями. Для каждогоархитектурного описания создана специальная онтология, использующая вкачестве метаонтологии одну из ранее разработанных частных онтологий.Отображение информационных моделей является необходимым шагом прирешении задач над неоднородными информационными ресурсами. Моделиинформационных ресурсов приводятся к однородному представлению,называемому канонической информационной моделью, в котором будутпроизводиться дальнейшие манипуляции информацией из разных ресурсов.Модели информационных ресурсов при этом называются исходными, аканоническая модель – целевой. Задача унификации множества исходныхинформационных моделей становится особенно актуальной при необходимостимасштабирования по количеству неоднородных информационных ресурсов [87].Для того, чтобы знания из одной базы знаний можно было использовать вдругой необходимо произвести адаптацию знаний.
Необходимо соглашение обинтерпретации онтологических понятий, которое должно позволить предотвратить неоднородности на уровне понятийной семантики при работе в рамках одной онтологии [88].В [89] отмечено, что для представления знаний о проблемной областитребуются средства трех моделей – онтологической, продукционной иимперативной.
При интеграция знаний на основе объектно-ориентированногоподхода понятия и отношения описываемых программных элементов ипредметных областей предлагается представлять классами объектов и отношенийонтологий, инкапсулирующих в себе семантические свойства и ограничения насвои атрибуты и аргументы, а все необходимые процессы вывода и обработкиинформации (реализующие процесс решения задачи) представлять множествомпродукционных правил, управляемым соответствующей системой управленияправилами.Моделирование ограничений и продукционных правил ппредлагаетсяпроводить с использованием класса Адаптер описаний, с помощью которогозадаются способы согласования архитектурных описаний через правилапреобразования, отображения и выравнивания их онтологий.
Схема,демонстрирующая такое согласование представлена на рисунке 36, а структуракласса и наследующих его классов на рисунке 37.81Рисунок 36. Адаптация семантик онтологий.Рисунок 37. Класс «Адаптер описаний»Все общающиеся между собой базы знаний, предоставляют друг другу своиадаптеры. Так, например, ManOntoToInfoAdapter.SubClsOf (Adapter) адаптер,согласующий понятие OntoMan онтологии предметной области и понятие InfoManонтологии информационных элементов. Аналогичным образом можно82определить отображение класса предметной области в компонентпользовательского интерфейса.В онтологии введено понятие Проект, понимаемое как деятельность порешению некоторой задачи.
Класс Проект аннотируется классом Рабочийпродукт метаонтологии и определяется семантической моделью:@Проект.включает. @Элемент проекта@Элемент проекта={Требование, Среда выполнения, Процесс выполнения,Архитектура, Архитектурное описание}Класс Среда выполнения задается системами, участвующих в разработкецелевой системы:@ Среда выполнения.включает.{@Система}@Роль_системы = {целевая система, обеспечивающая система}@Система.включает_подсистему.@ система@Система.использует.@Среда выполненияПроект характеризуется типом проекта, в котором фиксируется целевая иобеспечивающая системы и хранилище моделей. В проект могут быть включеныподпроекты, для которых также проводится управление конфигурацией.
Так,разработка программного компонента может быть рассмотрено как отдельныйпроект в составе общего проекта разработки ИС. Пример конфигурации проектаприведен на рисунке 38.Рисунок 38. Структура класса Project.Для разработки ИС создается семантическая модель проектаинформационной системы, в которой разрабатываемая система определена какцелевая, а в качестве обеспечивающей системы указана система разработки вебприложений, предоставляющая все ресурсы входящих в нее подсистем дляобеспечения процесса разработки.
Пример моделирования системы управленияучебным процессом приведен на рисунке 39.83Рисунок 39. Системная модельСогласование целевой системы и обеспечивающей системы в рамках проектатребует построения моделей их задач с последующим согласованием.2.4.3. Методы и алгоритмы построения функционального представленияПервым шагом в проектировании ИС является моделирование её задач иопределении способов ее решения.
Решение задачи в рамках используемого висследовании системного подхода состоит в делегировании задачи системызадаче обеспечивающей системы или в принятии решения о необходимостиразработки метода решения, в рамках которого такое делегирование станетвозможным.Результатом этой деятельности должны стать несколькоархитектурных описаний, например структура задач, определяющаядекомпозицию задачи на множество частных задач обеспечивающей системы,схема решаемых задач – модель, упорядочивающая последовательностьвыполнения задач (поток задач).Структура задач ИС может быть достаточно сложной и изменяться впроцессе проектирования и реализации системы.
Требования к информационнойсистеме строятся как семантическая сеть классов задач, используя классы Модельзадач и Задача. Структура класса Задача онтологии ISO 24744:@Задача.имеет тип.@Вид задачи@Задача.включает задачу.@Задача@Задача.делегирует задачу.@Задача@Задача.решатель задачи.@Producer@Задача.данные задачи.@Параметр задачи@Задача.имеет метод решения.@Метод@Задача.
класс предметной области.@Class84@Вид задачи = {Вид задача пользователя, Вид задача проекта, Вид задачасистемы}Класс Описание задачи предусмотрен для хранения входных параметровзадачи, ее текстового или иных описаний, условий выполнения и ограничений.Класс Producer в метамодели ISO 24744 опрелеяет участика процессажизненного цикла системы, обладающего способностью проводить актыдеятельности над элементами системы.В рамках рассмотрения задачпроектирования в дальнейшем будем использовать класс Решатель задачи,понимая его как компонент систем, решающий задачу, без уточнения еготехнологической реализации.
Класс Результатпредставляетвыходныепараметров задачи.Специализируя класс задачи и вида задачи можно получить разветвленнуюсистему типов и классов задач, распределенных по разным онтологическиммодулям. Так, например, класс Требование, имеющий в качестве метатипа классЗадача и класс Вид требования с подклассами Функциональное требование иНефункциональное требование позволяет создавать модель требований ксистеме.Аналогичным образом, класс Задача системы и класс Вид системы сподклассами Вид задача целевой системы и Вид задача обеспечивающейсистемы позволяют формировать модель задач целевой и обеспечивающейсистемы с соответствующими классификаторами в рамках онтологии проектаразработки целевой системы.Ограничения на область определения связей на уровне определения типовметамодели задают структуру и области определений связей классов и объектовна всех нижележащих уровнях моделирования.
Так отношение:@Вид задача целевой системы.делегирует=@Вид задачаобеспечивающей системызадает ограничение на область определения связи, ограничивая её классами задачцелевой системы.Формулировка задачи системы проводится после определения множествапараметров задачи, включающее классы и объекты онтологии предметнойобласти, запросы к онтологиям и адаптеры понятий.
На основе сформированногомножества создается онтология информационной модели задачи. В классахзапросов и адаптеров определяются онтологические соглашения междуинформационными объектами различных предметных областей. Методформирования информационной модели представлены в разделах исследования.Класс Модель задач аккумулирует частные задачи связанные с реализациейобщей задачи системы в контексте ее использования некоторой системой болеевысокого уровня@Модель задач.включает.@Задача85Модель задач системы управления учебным процессом показана на рисунке40.Рисунок 40. Модель задач системы управления учебным процессомПостановка задачи содержит метод решения задачи. Для класса методаопределен тип решаемой задачи.
Так выбор типа задачи «сложная задача»приведет к методу «декомпозиция задачи» [90].Пример метода декомпозиции: перебор всех классов задач системы; для каждой задачи системы выполняется построение подмножества задачсистемы, не содержащее текущей задачи; указание построенного множества в качестве области определение связивключает подзадачу активного класса задачи;Класс Метод определен в онтологии архитектуры и строиться каккомпозиция специализаций класса Элемент методологии онтологии ISO 24744:@Метод.включает элемент метода= @Элемент методологииМетод.реализуется агентом.@Агент.Выбранный метод определяет дальнейшую специализацию класса задачи.Задачи, имеющий общий характер, группируются в библиотеки задач.Возможность переводить метод решения задачи в библиотеку методов позволяетхранить знания о решении и повторно их использовать. Пример частиразработанной справочной библиотеки задач для системы проектированияпредставлен на рисунке 41.86Рисунок 41.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
