Диссертация (1090633), страница 10
Текст из файла (страница 10)
Поэтомупредставляется разумным (по крайней мере, в теории) унифицировать их длябольших сообществ пользователей. Примером такой общей онтологии являетсякоммерческий проект онтологии CYC [55]. Это база знаний, содержащая всеобщие понятия окружающего мира, которую могут использовать самые разныепрограммные средства. По некоторым данным, в CYC уже представлены 10концептов и 105 аксиом. Для представления знаний в рамках этого проектаразработан специальный язык CYCL [56].Онтология, ориентированная на предметную область. Во многихдисциплинах сейчас разрабатываются стандартные онтологии, которые могутиспользоваться экспертами по предметным областям (доменам) для совместногоиспользования и аннотирования информации в своей области. Например, вобласти медицины созданы большие стандартные, структурированные словари,такие как SNOMED и семантическая сеть Системы УнифицированногоМедицинского Языка (the Unified Medical Language System).Онтология, ориентированная на задачу.
Это онтология, используемаяконкретной прикладной программой и содержащая термины, которыеиспользуются при разработке ПО, выполняющего конкретную задачу. Онаотражает специфику приложения, но может также содержать некоторые общиетермины (например, в графическом редакторе будут и специфические термины —палитра, тип заливки, наложение слоев и т. д., и общие — сохранить и загрузитьфайл).Онтологии ПрО и онтологии задач описывают, соответственно, словари,которые относятся к определенной ПрО (например медицина, дистанционноеобучение, Интернет-технологии) или типичной задаче (например диагностика,продажа). При этом они используют специализацию терминов, представленных вонтологиях верхнего уровня.Прикладная онтология описывает концепты, которые зависят как отонтологии задач, так и от онтологии домена. Примером данной онтологии может41служить онтология для автомобилей, строительных материалов, вычислительнойтехники.
Онтология ПрО обобщает понятия, использующиеся в некоторыхзадачах домена, абстрагируясь от самих задач (так, онтология автомобилейнезависима от любых особенностей конкретных марок машин).Множество возможных применений онтологий требует решения вопроса обих унифицированном представлении в среде СУБЗ, а также о точном определениироли каждой онтологии в многоуровневой онтологической системе.2.2.2. Методы и задачи управления знаниямиНабор возможных действий, обеспечивающих выполнение алгоритма,включает создание, редактирование, удаление понятий, отношений, аксиом ипрочих структурных элементов онтологии. К задачам получения знаний,хранимых в онтологии, относятся задачи поддержки языка запросов (для поисканетривиальных утверждений), анализа целостности, использования механизмалогического вывода, поддержка пользовательского режима — визуализацияонтологии.Операции и инструменты управления онтологиями [57] позволяют найтисходство и различие между исходными онтологиями, создать результирующуюонтологию, содержащую элементы исходных онтологий.
Достижения этой целипредполагает возможность автоматического определения соответствия междуконцептами в исходных онтологиях или наличие инструментальной среды, вкоторой пользователь может легко найти и определить эти соответствия. Этиинструменты известны как инструменты отображения, выравнивания иобъединения онтологий, так как они выполняют сходные операции для процессовотображения, выравнивания и объединения.Понятие «отображение онтологий» (ontology mapping) подразумеваетдеятельность по установлению соответствия между несколькими онтологиямиили, другими словами, нахождение семантических связей подобных элементов изразных онтологий.
С наиболее общей точки зрения важность задачи отображенияонтологий обусловлена тем фактом, что мощность знаний, заключенных вонтологиях, проявляется в полной мере только в том случае, когда удается учестьвзаимосвязи независимых онтологий - установление факта подобия сущностей вразных онтологиях означает извлечение из этих онтологий дополнительныхзнаний.Задача выравнивания онтологий (ontology alignment) заключается в том,чтобы установить различные виды соответствия между двумя онтологиями, азатем сохранить исходные онтологии вместе с информацией о найденныхсоответствиях для того, чтобы в дальнейшем использовать информацию овзаимосвязях онтологий.
Отметим также, что на основе отображения онтологийрешается задача интеграции онтологий (ontology merging) – задача создания новойонтологии или ее фрагментов из двух и более исходных .42Онтология и составляющие ее элементы в СУБЗ представлена двумяспособами как формальная концептуальная модель, управление которой можетбыть описано с помощью средств языка описания модели, и как информационныйресурс, являющийся частью системы хранения данных СУБЗ.
В последнем случаеуправлениеонтологиейобеспечиваетсяоперациямиуправленияинформационными ресурсами программной системы, реализующей СУБЗ.2.2.3. Метод обеспечения целостности описания информационной системыИС в целом и СУБЗ, в частности, является сложной системой, т.е. состоит изнабора подсистем. Очень часто разработчик не участвует в их проектировании,сопровождении или модификации. Эти системы должны восприниматься «какони есть».
В настоящее время описанная ситуация в теории систем определяетсятермином «система систем» [58]. Система систем вид системы, отдельные частикоторых могут существовать автономно, были разработаны независимо друг отдруга, и тем самым представляют собой полноценную целевую систему. Необходима интеграция таких автономных и независимых систем в новую разрабатываемую систему с уникальными свойствами.Общей архитектуры у составляющих систем по определению нет. Для каждой составляющей системы в системе таких систем меняется весь набор заинтересованных сторон и предпочитаемые ими языки описания системы и нотацииэтих языков [59]. Тем самым для описания системы систем нам нужно применятьспецифическое моделирование — мы не можем гарантировать единообразие описания при декомпозиции.
Как ранее отмечалось, объединение и согласований может производиться на уровне описания смыслов путем «семантического» моделирования [60]. Общая модель системы в подходе «система систем» представленана рисунке 11.Рисунок 11. Модель системы в подходе «система систем»Система систем возникает на разных уровнях проектирования. На этапе формулировки технического задания и выбора подходящей системы реализации43СУБЗ последняя должна рассматриваться как внешняя по отношению к СУБЗ система, предоставляющая некоторые возможности.
Оптимальный выбор между несколькими системами реализации может быть произведен на основании некоторой общей для всех них модели. В качестве такой модели часто используют наборнекоторых критериев. Например, рассматривая реализацию требований в рамкахнекоторой CMS приходится производить анализ возможностей использования существующих модулей расширения. В ситуации, когда количество таких модулейисчисляется сотнями, адекватный ручной выбор не может быть произведен. Таким образом, реализация задачи поиска и подбора модулей расширения можетбыть выделена в отдельную, внешнюю по отношению к системе разработки, специализированную систему, изменение которой не доступно для разработчика.Согласование возможностей, внешних по отношению к ИС, программныхсредств, может быть произведено в рамках модели «система систем», реализующей модели согласования, в состав которых должна входить разделяемая системами модель внешнего программного компонента.
На уровне программированияподобная задача возникает при использовании компонентов, библиотек, которыев общем случае программист администрировать не может. Таким образом, главным становится архитектурное описание системы в такой «программистской»группе описаний.Моделирование взаимодействия таких систем обладает рядом специфических особенностей. Требования к системе систем формулируются в терминах возможностей (capabilities), а не functions (функций каких-то систем) [61]. То естьразработчик пытается использовать возможность что-то этим системам совместносделать. Capabilities формулируются как «данная система должна обеспечиватьвозможность…». Таким образом, оказывается возможным формулировать возможности системы, используя понятия «задача системы».2.2.4. Модель обеспечивающей системы в подходе системы системОсобым случаем «системы систем» является обеспечивающая система [62,63] проекта разработки.
Обеспечивающая система понимается как организация,определяемая как совокупность людей, оборудования с понятным разделениемтруда, полномочиями и ответственностью, которая продвигает целевую системупо ее жизненному циклу. Обеспечивающая система является системой систем поопределению. На самом деле там ведь есть люди, которые владеют собой сами,и лишь договариваются работать вместе в организации. Частью эти договоренности являются явными, а частью представляют собой неявные представления о таких договоренностях, находящихся «в культуре» (устной, письменной, в стандартах, а то и в законодательстве — т.е.
не только в договоренностях, но и обычаях,и даже законах). В этом случае от «словарных» взаимодействий ИС придется переходить к семантическим технологиям, позволяющим производить такие согласования.44Используя в качестве основы модель ИС, введенную ранее, рассмотрим модель ИС периода разработки как систему систем и выделим входящие в нее системы с точки зрения их максимальной независимости.
Критерием независимостисистем будем считать независимость групп описаний ИС, присущих разным группам разработчиков (Рисунок 12).Рисунок 12. Декомпозиция системыТогда возможно рассматривать процесс разработки и сопровождения ИС какпоследовательность преобразований модели разрабатываемой (целевой) системыSApp некоторой обеспечивающей системой SОб:SОб=<SApp, SDomain, STask, SInfo, SComp, SGui ,SNav, >,гдеSApp целевая система, в рамках которой производится согласование;SDomain система, управляющая знаниями о предметной области;SInfo система управления информационной моделью;SComp система управления программными компонентами;SGui система управления представлением информации;SNav система управления коммуникациями.Рассматривая деятельность обеспечивающей системы с функциональнойточки зрения, можно сказать, что описание предметной области, включающее в45себя концептуальную модель и модель ее задач, является входной информацией,а модель ИС — результатом выполнения некоторой функции FОбС: ПрО→SApp,преобразующей модели предметной области ПрО в модель ИС M_SApp;Подобное рассмотрение возможно, как на уровне моделирования, когда каждая система имеет свои группы описаний, представленные в соответствующих моделях, так и на уровне реализации каждая система реализуется специфическимидля нее программными компонентами.Строго говоря, этапу эксплуатации ИС должна соответствовать специализированная система обеспечения эксплуатации, в функции которой кроме функцийуправления, характерных для SОб, входят функции управления программно - аппаратным комплексом, персоналом и т.п., но рассмотрение этих функций и систем, их обеспечивающих, выходит за рамки данного исследования.На уровне моделирования концептуальная модель и модель задач предметной области вместе с итоговой моделью ИС должны быть согласованы с понятиями, присущих обеспечивающей системе и задачей обеспечивающей системы является согласование возможностей систем, входящих в ее состав, путем согласования соответствующих архитектурных описаний.Каждая из систем характеризуется уникальным набором моделей, задач, инструментов и исполнителей и ее структура, и функционирование, в общем случае,не может быть изменено извне.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
