Автореферат (Математическое и программное обеспечение для управления базами знаний на основе многоуровневых семантических моделей гетерогенных информационных ресурсов), страница 3

Таким образом, разработанный языкмоделирования абстрактной семантической сети, действительно, позволяетописать любую частную онтологию в виде семантической сети и определитьоперации специфичные для этой частной онтологии.Для организации многоуровневых моделей впервые предложен методпредставления уровней моделирования L в многоуровневой моделиMLevel={L} каждому уровню моделирования ставить в соответствие онтологическую систему OL=< ОТ, ОC, >, где ОТ  онтология, понятия которойзадают метаинформацию для понятий онтологии ОC и между онтологиямисистемы определены классификационных связи «классификатор – классифицируемый класс» Rk:ОТ → ОC. Характер связей определяется соответствующей моделью ограничений связей M_Constrain. Предложено определять типизацию квалификационных связей в модели семантической системы Gмножеством объектов типа ObjectProperty и DataProperty.Впервые предложен метод построения многоуровневой модели, специализирующий метод представления уровней моделирования, отличающийсятем, что в качестве онтологии OТ связей определена онтология системыуправления знаниями OKW, включающая понятия Метатип, Тип, Класс,Подкласс,ЭкземпляриопределентипсвязиПорождает:@.порождает.@, модель ограничения которой определяет способ созданиякласса понятия на основе некоторого класса, определяющего метаинформацию понятия.

Определен набор классов связей, расширяющих ее : метатип.порождает.тип,класс.порождает.подкласс,класс.порождает.экземпляр. Ограничения, накладываемые на связи,11определяют правила создания, расширения и интерпретации классифицируемого класса. Модели ограничений, определяющие способы создания элементов модели на основе метаинформации определены в диссертации.Впервые предложен метод формирования модели ограниченийM_Constrain, обеспечивающей интерпретацию связей узлов семантическойсети, отличающийся тем, что для каждой связи узла f определяется классограничений С_Constrain. Связь f и класс ограничений связаны отношениемSubPropertyOf. Модель ограничений строится как объединение классов ограничений текущей связи и всех классов ограничений связей, входящих виерархию связей, также определяемую отношением SubPropertyOf.Для согласование архитектурных представлений и архитектурные описания, учитывающих интересы (concerns) различных заинтересованных сторон (stakeholders), разработана модель онтологии архитектуры, в которой архитектуры ИС рассматривается как множество архитектурных описанийArch={ADesci}, где ADesci =<Mi, Ai, Ri, Zi >, i=1,…,n, i – аспект, характеризующий некоторую группу интересов через архитектурное описание ADesci,отвечающее способу описания Zi, а также методы согласования описаний моделей, основанные на формировании описаний моделей семантических конструкций, определенных в онтологии жизненного цикла и архитектуры.Для построения и интеграции архитектурных моделей ИС, разработанных в рамках различных методологических подходов, создан объектноориентированный метод адаптации архитектурных описания, отличающийсятем, что для согласования архитектурного описаний ADesci и ADescj создается модель соответствия, включающая классы Архитектура, Группа_описаний, Модель, Модуль онтологии и Адаптер со связями междуними:Архитектура.включает.Группа описанийГруппа описаний.включает.МодельМодель.использует понятия из.Модуль онтологииМодель.включает.Элемент моделиЭлемент модели.использует.ПонятиеАдаптер.адаптируемое понятие.Элемент моделиАдаптер.адаптирующее понятие.Элемент моделиОписанные выше технические решения обеспечивают построение соответствующей Модели в понятиях модуля онтологии (одного или нескольких), определенного для группы описания, а класс Адаптер позволяет задатьспособы согласования архитектурных описаний через правила преобразования, отображения и выравнивания их онтологий.Отметим, что предложенный подход обеспечивает параллельную работунескольких групп разработчиков, использующих собственные средства разработки и представляющие результаты в моделях их группы описаний.

Длясинхронизации изменений в моделях разных уровней разработан автоматический сервис, обеспечивающий соответствие моделей разных уровней в соответствие с правилами согласования. Для каждой группы описаний созданы12модели и соответствующие системы управления для различных групп описаний.Далее в диссертации предложены методы решения задач проектирования, использующие рассмотренные ранее методы и модели.Предложен метод интеграции систем в рамках группы системных описаний, в котором для задания структуры связей между архитектурными описаниями, определения онтологических модулей для каждого архитектурногоописания и адаптеров между архитектурными описаниями разработан классСистема:@Система = {Целевая система, Обеспечивающая система}@Система включает_подсистему.@Система@Целевая система.имеет.@Обеспечивающая систем)@Система.имеет.@АрхитектураЗдесь класс Обеспечивающая система предназначен для описания методов решения задач, представленных соответствующими программнымиэлементами (ПЭ).Для согласования функциональных моделей целевой системы (ЦС) иобеспечивающей системы(ОбС) и интеграции систем разработан класс Задача и класс Модель задач:@Задача.имеет тип=@Тип задачиТип задачи = {Задача пользователя, Задача проекта,Задача системы}@Задача.включает задачу.@Задача@Задача.делегирует задачу.@Задача@Задача.имеет.{@Постановка задачи,@Решатель задачи}@Модель задач.включает.@ЗадачаЗдесь Класс Постановка задачи предусмотрен для хранения входныхпараметров задачи, ее текстового или иных описаний, условий выполнения иограничений, класс Решатель задачи  для описания исполнителя задачи,класс Результат  выходных параметров задачи.

Интеграция систем производится через интеграцию задач интегрируемых систем в модель задач обеспечивающей системы через отношение «делегирует».Для интеграции задач в рамках модели задач предложен метод интеграции задач, состоящий в создании набора адаптеров задач. Для создания аннотаций связей между задачами (условий выполнения подзадач в контекстерешаемой корневой задачи, включая условия согласования входных и выходных параметров задачи, условия выбора подзадачи и условия циклического выполнения и т.д.) разработан класс Адаптер задачи:Адаптер задачи ={Адаптер условной подзадачи,Адаптер циклической подзадачи,Адаптер последовательности подзадач}.Таким образом каждая задача пользователя связывается с задачей обеспечивающей системы, которая делегируется задаче интегрируемой системы.13Множество классов адаптеров, связанных с задачами, задают архитектурное описание Управляющий граф решателя  модель, связывающуювзаимодействующие программные единицы (агенты, отдельные блоки которых настроены на обработку разных типов сообщений), в которой узлы соответствуют блокам (блокам продукций агентов), а связи аннотируются классами передаваемых сообщений и наборами ограничений.

Пример моделирешателя задачи представлен на рисунке 2. Алгоритм решения задачи строится на основе архитектурного представления Управляющий граф решателя. Классы, наследующие класс Сообщение, предназначены для созданиямоделей информационных ресурсов, создаваемых в процессе жизненногоцикла решателя задачи и передаваемых другому решателю задачи для обработки. Класс Сообщение строится как специализация классов онтологии информационных элементов. Класс онтологии информационных элементов икласс сообщений связаны отношением «метакласс – класс».Рисунок 2.

Модель решателя задачиДля построения программных единиц, решающих задачи системы предложена модель агента, представленная на рисунке 3. Агенты строятся на основе модели решателя задач каждый агент является композицией из классовБлок продукций, в которых определяются алгоритмы обработки сообщений,представленные классом Блок сообщений.

Для описания связи формальноймодели агента с ПЭ, представляющим агент, предусмотрено поле (примитив).реализуется, в котором размещается указатель на описание программногоэлемента, представленного классом Component. Множество классов, насле-14дующих класс Component, образуют библиотеку компонентов, предоставляяих внешним системам как решатели задач.Для представления информационных ресурсов различных типов разработана онтология информационных элементов, классы которой позволяютопределять знания различных предметных областей в виде структур данныхопределенных типов, и способах их хранения.

Наряду с классами простыхтипов данных, таких как Numeric, String, Text, Image, File, введены классы,предназначенные для описания хранилищ данных  Контейнер, Репозитарий, База данных и классы источников данных, такие как Решатель, Сервис, Компонент. Конкретные модели информационных элементов представлены в диссертации.Для построения архитектурных описаний графического интерфейсапользователя разработана онтология пользовательского интерфейса, позволяющая создавать базы знаний для описания пользовательского интерфейсаприложения (ПИ). В онтологии пользовательского интерфейса определеныпонятия Абстрактный элемент и Конкретный элемент, используемых для построения моделей пользовательского интерфейса, а также классытипов визуальных элементов, определяющие их геометрические и стилевыехарактеристики.Рисунок 3. Модель абстрактного агента.Предложен метод построения пользовательского интерфейса.