Диссертация (1090633), страница 11
Текст из файла (страница 11)
В общем случае совокупность таких элементов иопределяют систему, образуя ее архитектурное описание:ADesci=< Mi, Ai, Ri, Zi >, i=1,…,n,где i – аспект, характеризующий некоторую группу описаний, который отвечаетспособу описания Zi, связывающему множество элементов Mi, определенных намножестве характеристических признаков Ai и связанных отношениями RiТаким образом, все выделенные системы, исключая систему представленияпредметной области и представление разрабатываемой ИС, составляют обеспечивающую систему периода разработки и периода эксплуатации ИС.
В соответствиис ранее принятыми определениями, такая обеспечивающая система является системой систем.Системообразующим фактором является решение задач, зафиксированныхдля целевой системы. Если решение задачи целевой системы достигается черезиспользование возможностей некоторых подсистем, то эти возможности должныбыть согласованы как на уровне каждой отдельной системы, так и на уровне всейобеспечивающей системы. Согласование проводится как согласование функций задачи целевой системы декомпозируются до функций, обеспеченных возможностями подсистем, так и согласованием взаимодействия компонентов систем, реализующих функции.
На этапе проектирования это выражается в согласовании спецификаций компонентов, а на этапе реализации – во взаимодействии программных и аппаратных элементов.46Возможности подсистем рассматриваются как внешние ресурсы, и удачнаяконфигурация этих ресурсов определяет способ достижения заявленной цели. Реализация такого подхода зависит от точки зрения (аспекта) на результат этапа разработки. Карта знаний, отображающая эти аспекты, представлена на рисунке (Рисунок 13).Рисунок 13. Аспекты рассмотрения моделиНа первом этапе разработки в качестве результата определяется построениеединого информационного пространства данных, создание которого позволитунифицировать язык описания данных и способы их получения и обеспечит возможности интеграции подсистем обеспечивающей системы на уровне данных.На втором этапе в качестве результата предполагается получить создание общего для подсистем и групп разработчиков пространства проекта, обеспечивающего мониторинг изменений в примитивах моделирования подсистем и оповещение об этих изменениях трассировка изменений, а также методологию проектирования, обеспечивающую общее информационное пространство проекта, в котором обеспечена интеграция архитектурных описаний с возможностями аналитической обработки данных и автоматической генерацией программных компонентов.Третий этап рассмотрения в качестве результата декларирует создание инструментальной среды для моделирования и реализации информационной системы.Таким образом, проектирование ИС, представленное как функционированиенекоторой обеспечивающей системы, можно рассматривать с точки зрения создания единой информационной модели с соответствующей схемой хранения и обладающей возможностью порождающего проектирования.
Создание информационной модели и поддержка ее в актуальном состоянии требует наличия специфического инструментального средства системы проектирования. Порождающеепроектирование предполагает возможность автоматической генерации программных элементов результирующей ИС на основе ее информационной модели, созданной в среде системы проектирования.472.2.5. Формальная модель интеллектуальной информационной системыЦелью построения единого информационного пространства являетсясогласование точек зрения различных групп разработчиков, что требуетпредварительного формирования специализированных форм представления этихточек зрения, отображающих «срезы» онтологической модели соответствующейпредметной области. Процесс выделения онтологических моделей (базовыхонтологий) в общем случае состоит в декомпозиции предметной области наподсистемы объектов и подсистему задач, выявление онтологий и ихсогласования.В качестве формальной модели интеллектуальной системы используемопределение онтологической системы [64]:∑О = <Ometa, {Od&t}, ∑inf>,гдеOmeta — онтология верхнего уровня (метаонтология);{Od&t} — множество предметных онтологий и онтологий задач предметнойобласти;∑inf — модель машины вывода, ассоциированной с онтологической системой∑О.Представим модель результирующей информационной системы как сетьонтологий, включающую метаонтологию и набор частных онтологий, множествосвязей между ними и машину вывода.
Будем рассматривать в качестве наборачастных онтологий онтологии предметных областей, связанных с разработкойвеб-приложений:ONetwork=<Meta,ODomain,OTask,ONav,OInfo,OComp,OGui,OAppRО,F>гдеMeta метаонтология, определяющая общий словарь;OApp онтология приложения, являющаяся результатом разработки;ODomain онтология предметной области;OTask онтология задач;ONav онтология навигации;OInfo онтология информационных элементов;OComp онтология компонентов;OGui онтология пользовательского интерфейса;RО множество бинарных отношений между концептами и индивидуаламионтологий;F машина вывода, позволяющая интерпретировать сеть онтологий.Сеть онтологий представляет собой семантическую сеть (мультиграф),узлами которой являются онтологии, каждая из которых также являетсясемантической сетью с формальным описанием своих структурных частей.48Интероперабельность этих онтологий обеспечивается наличием общейметаонтологии.
Схема взаимодействия онтологий представлена на рисунке 14.Рисунок 14. Схема взаимодействия онтологийВ качестве метаонтологии различными исследователями предлагаетсяиспользовать какую-либо из высших онтологий, таких как Gelish [65], ISO15926[66]. В рамках решения задач разработки программных систем представляетсяцелесообразным использовать метаонтологию, построенную в соответствии спонятиями метамодели ISO 24744 и понятиями стандарта ISO 42010, дающих, какуказывалось ранее, способ определения методов, групп описаний, применимых кпредметной области или к ее части, вплоть до отдельного концепта и методов ихсогласования. Метаонтология специфицирует специальные группы описаниймира группы описаний разработчиков программного обеспечения.
С этой точкизрения можно полагать, что существует отдельная группа описаний группаописаний предметной области, представленная в терминах модели, примитивовмоделирования, языка описания, т.е. в концептах метаонтологии. Следуетотметить, что использование паттерна метаонтология-онтология можетиспользоваться и на других уровнях декомпозиции, подобно рассматриваемомувыше примеру представления онтологии предметной области.2.2.6. Разработка модели данных для хранения объектно-ориентированных баз знанийПри разработке систем управления знаниями возникают проблемы,вызванные принципиально различными подходами к построению БД и БЗ.
Этиразличия определяются выбранным формализмом представления БЗ. Дляпредставления знаний с использованием языка OWL более естественным являетсяиспользование объектной модели, характерной для OWL. Для представления базы49знаний с использованием нотаций языка RDF характерным являетсяпредставление знаний в виде наборов триплетов. Однородная структура наборовтриплетов позволяет достаточно эффективно использовать для их хранениявозможности реляционных баз данных и, соответственно, реляционной модели.Проблема проявляется в сложности преобразования данных из реляционнойформы в объектно-ориентированную форму, актуальную при практическомиспользовании онтологий в прикладных программах. Таким образом, ключевымявляется противоречие реляционной и объектно-ориентированной схемыпредставления.С другой стороны, объектно-ориентированное представление онтологиипозволяет создавать любые базы знаний, используя для представления разныхконцептов предметной области унифицированные компоненты, используя их какдля хранения в объектной базе данных, так и для реализации прикладныхпрограмм.
Это позволяет использовать объектно-ориентированное представлениеонтологических моделей как промежуточное, позволяющую в дальнейшемтрансформировать ее в представления схем хранения, спецификацийпрограммных компонентов с их последующей генерацией [67].Для реализации такой возможности предлагается рассмотреть возможностьобъектно-ориентированного представления абстрактной семантической сети,выбрав в качестве объектной модели объектную модель языка описанияабстрактной семантической сети. В качестве основы для построения такогопредставления используем объектно-ориентированную модель онтологии,предложенную в [68].
Формальная объектно-ориентированная модель данных,может быть рассмотрена как объектная база данных и представлена набором из 8ми элементов:<ADT, O, P, SuperTypes, TypeOf, PropDomain, PropRange. Value>,гдеADT множество доступных абстрактных типов, представленных какатомарными типами, такими как Int, String, Boolean, так и глобальным супертипомObject и различными абстрактными типами, определяемыми пользователем;O множество объектов, хранимых в базе данных или конструируемымичерез соответствующие запросы и имеющие уникальные идентификаторы;P множество свойств, используемых для описания состояния каждогообъектаt;SuperTypes : → 2 — функция, отображающая ассоциации междусупертипами и абстрактными типами.
Эта функция определяет структуру типов,их наследование и взаимозаменяемость.TypeOf: → сопоставляет каждому объекту его тип;PropDomain: → устанавливает область определения для свойств;PropRange: → устанавливает область значений для свойств;50: × → значение свойства объекта. Свойство в качестве значенияможет иметь тип данных.Для уточнения семантики объектно-ориентированной модели данных будемрассматривать семантическую сеть G={{Сi}, {Rj}} как множество узлов С исвязей R.
Определим для узлов и связей множества типов узлов:TC={Onto, OCls, OntoInd}и множество типов связей:TR={DatProp, ObjProp, ClsDatProp, ClsObjProp, IndDatProp, IndObjProp}.Определим семантику узлов и связей и их множеств:Onto множество онтологических модулей O, представляющих сети болеенизкого уровняDP множество элементов типа DatProp, определяющих сорта описанияданных;OP множество элементов типа ObjProp, определяющих сорта связей;OCls множество элементов типа OntoCls;OI множество элементов типа OntoInd;O=<title, id, OC, DP, OP, OI>,где title – наименование узла, id-идентификатор узла;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, здесь SubPropertyOf указатель на элемент в частной иерархии элементов ClsOProp, range 51ограничение, дополнительно накладываемое на множество ограничений на типсвязываемых элементов, определяемое иерархией 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,DataProperty,ObjectProperty,ClasssDataProperty,ClassObjectProperty,OntoIndividual,IndDataProperty,ndObjectProperty},обеспечивающий отображение высказываний, представленных в семантическойсети в сеть объектов:Ontology =<OCls,DP,OP,OI> онтологический модуль, представляющийсемантическую сеть и агрегирующий множество элементов DP множествоэлементов типа DataProperty, определяющих сорта описания данных; P множество элементов типа ObjProperty, определяющих сорта связей; OCls—множество элементов типа OntoClass; OI — множество элементов типаOntoIndividual;OntoClass=<ClsDP,ClsOP> компонент, представляющий класс онтологии,и агрегирующий множества элементов, где ClsDP и ClsOP множество элементовClassDataProperty и ClassObjectProperty, соответственно, определяющие связикласса с узлами сети;DataProperty компонент, определяющий характер связи элемента сети сэлементом сети, представляющим простой тип данных, определяет верхнийуровень в иерархии элементов типа ClassDataProperty;ObjectProperty компонент, определяющий тип связи элемента сети сэлементами, не принадлежащими множеству простых типов данных, определяетверхний уровень в иерархии элементов типа ClassObjectProperty;ClassDataProperty компонент, определяющий связь элемента сети, с типомкомпонента OntoClass с элементами, принадлежащими множеству простых типовданных;52ClassObjectProperty компонент, определяющий связь элемента сети типомкомпонента OntoClass с элементами, не принадлежащими множеству простыхтипов данных;OntoIndividual =<IndDP, IndOP> компонент, представляющий экземпляркласса онтологии и агрегирующий множество элементов IndOP множествоэлементов IndDataProperty и IndOP множество элементов IndObjectPropertyсоответственно, определяющие связи экземпляра класса с узлами сети;IndDataProperty элемент сети, определяющий связь элемента сети типомOntoIndividual с элементами, принадлежащими множеству простых типовданных;IndObjectProperty компонент, определяющий связь элемента сети типомOntoIndividual с элементами, не принадлежащими множеству простых типовданных.На рисунке 15 представлена диаграмма классов для разработанного наборакомпонентов.Рисунок 15 Диаграмма классов набора компонентовРассмотрим последовательность [Ci1,Ci2,…Cin] классов, наследующих другдруга и расположенных различных уровнях моделирования, то есть Cik.SubClassOf→Cik1.53Для разделения уровней моделирования предлагается локализовать их вотдельные модули, а для связи классов вводится дополнительный атрибут hasMetaСlass, определяющий наследование между классами, находящимися в разныхонтологических модулях, то есть атрибуты SubClassOf и hasMetaClassсемантически эквивалентны, но не могут быть использованы одновременно.Классу Cik сопоставлено множество {Rij}k связей, представленных элементамитипа ClassObjectProperty и ClassDataProperty.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
