- онтологии верхнего уровня (Generic или Upper), специфицирующие общие знания о мире и применимые в различных ПрО;
- онтологии представления (Representational) сущностей без привязки к определённой ПрО;
- предметные (Domain) онтологии, где специфицируются знания из заданной ПрО;
- онтологии методов и задач (Method & Task).
В работе [41] предложена расширенная классификация онтологий на основе предмета концептуализации:
- онтологии представления знаний (Knowledge representation ontologies), которые используются для спецификации знаний в рамках конкретной парадигмы их представления;
- общие онтологии (Common or generic ontologies) представляют повторно используемые знания здравого смысла (common-sense knowledge);
- онтологии высшего уровня (High-level ontologies) описывают общие понятия;
- предметные онтологии (Domain ontologies), предлагающие словари для понятий в определенной ПрО;
- онтологии задач (Task ontologies), где специфицируются словари базовых (общих) активностей;
- онтологии задач ПрО (Domain task ontologies), повторно используемые в некоторой ПрО;
- онтологии методов (Method ontologies), которые применяются для спецификации процессов вывода при выполнении частных задач;
- прикладные онтологии (Application ontologies) зависят от приложений и часто являются специализацией предметных или задачных онтологий.
Работа специалистов из Юго-Восточной Азии [29] посвящена созданию и использованию онтологии процессов ПО (Software Process Ontology), фрагмент которой приведён на рисунке 1. Как утверждают авторы, разработанная ими онтологическая модель отвечает требованиям ISO/IEC 15504.
Рисунок 1 - Фрагмент онтологии процессов ПО [29]
В работе [42] для поддержки процессов сопровождения ПО описан комплекс онтологий сопровождения ПО, включающий онтологию ПО, где представлены такие концепты, как ПО, пользователи и документация; онтология знаний и умений в области computer science с концептами компьютерные технологии и языки моделирования; онтология процессов модификации с концептами запрос на модификации и обслуживание; онтология организационных структур с такими понятиями, как организационная единица и директива; прикладная онтология, которая связывает понятия ПрО с задачами, которые должны в ней быть выполнены. С использованием метода извлечения знаний в области создания систем ПО (Post-Mortem Analysis') [43] разработана методология, которая обеспечивает точное представление знаний о разных стадиях процесса сопровождения ПО согласно ISO/IEC 14764 [44] на базе использования собственного комплекса онтологий сопровождения ПО.
Многолетние исследования и разработки в области онтологий ведутся и в департаменте Компьютерной науки и Информационных систем (Department of Computer Science and Information Systems) университета Яаваскила (University of Jyvaskyla) в Финляндии. Одной из базовых публикаций этого исследовательского коллектива является работа его руководителя М. Леппанена (M. Leppanen) [45], в которой обсуждается методология проектирования многоуровневых онтологий на базе контекстов (рисунок 2).
Рисунок 2 - Структура системы онтологий, основанной на контекстах [45]
В подходе финской школы выделяются семь контекстных областей, из которых «получают» концепты для уточнения и интерпретации контекстных явлений: цель, лицо, действие, объект, возможность, место и время. Структурирование понятий внутри и между областями осуществляется по схеме 7S: for Some purpose, Somebody does Something for Someone, with Some means, Sometimes and Somewhere (с какой целью кто-то делает что-то для кого-то с помощью некоторых средств время от времени и в некотором месте).
Что представляется важным в подходе финской школы? Во-первых, это спецификация онтологий на основе теории контекстов. Во-вторых, спецификация отдельных контекстных областей с их «внутренними» отношениями, а также введение в рассмотрение «внешних» связей между объектами разных контекстных областей. В-третьих, подход может быть использован для интеграции разноуровневых по семантике и целям проектирования онтологий.
Из приведённого обзора можно видеть, что в настоящее время общепризнанной классификации онтологических моделей не существует. Имеющиеся классификации являются либо слишком общими, чтобы использоваться непосредственно в качестве основы для построения системы онтологических моделей процессов проектирования ПО, либо настолько частными, что их использование в данной ПрО представляется затруднительным.
Практически значимая онтологическая модель процессов проектирования систем ПО должна отвечать следующим требованиям:
- адекватное онтологическое представление проектируемых систем ПО, включая их архитектуру, спецификацию отдельных компонент и связей между ними;
- эффективная генерация исходных кодов разрабатываемого ПО под управлением системы сбалансированных онтологий;
правильное отражение процессов проектирования ПО.
Структурно такая система онтологий должна быть многоуровневой. И здесь, по нашему мнению, может быть использован подход 7S М. Леппанена [45].
Семантические модели прикладных систем ПО
Наряду с исследованиями и разработками по онтологическому моделированию процессов проектирования ПО в рамках направления OBSE-ODSE активно ведутся работы по созданию инструментов онтологического инжиниринга в данной ПрО, см. например, работы [32, 34, 37-39]. При этом характерна ориентация на комплексное решение существующих в данной области проблем.
Хорошим примером является европейский проект MOST (Marrying Ontology and Software Technology) [46], ориентированный на повышение качества разработок ПО на основе использования семантических технологий и методов логического вывода. В рамках проекта реализована бесшовная интеграция семантических технологий в разработку ПО на основе моделей (MDSD - Model Driven Software Development), что привело к созданию методов и средств разработки ПО на основе онтологий (ODSD - Ontology-Driven Software Development). Интеграция касается, прежде всего, языков моделирования, что обеспечивает возможности преобразования интегрированных моделей с использованием унифицированных метамоделей. Онтологии и модели интегрируются таким образом, чтобы онтологии можно было использовать в моделях и наоборот. Запросы на основе онтологий интегрированы на уровне преобразований MDA (Model Driven Architecture) и помогают разработчику выполнять требования и принимать решения по моделированию. Программный комплекс, основанный на онтологиях и управляемый моделями MOST, обеспечивает управление процессами разработки, которое формализует правила, условия и действия инженеров-программистов. Таким образом, проект MOST покрывает и фундаментальные исследования, и прикладные разработки.
В ряде публикаций предлагаются определённые методы онтологического моделирования процессов проектирования ПО и инструменты, разработанные на его основе.
Так, в работе [32] предложено повторное использование ПО на основе онтологического подхода. Представлена база знаний KOntoR, в которой онтологии повышают ценность библиотек для повторного использования за счёт семантической интеграции явных и неявных метаданных, что обеспечивает средства для получения новых фактов. Фрагмент онтологии KOntoR приведён на рисунке 3. Авторы приводят примеры, которые показывают, как пользователи библиотеки ПО могут извлечь выгоду из формализованных знаний, например, о лицензиях на ПО или технологиях программирования.
Рисунок 3
В работе [34] акцент сделан на использовании Semantic Web в качестве среды для представления знаний об эволюции ПО с помощью онтологий, технологий связанных данных (Linked Data) и рассуждений. Авторы разработали пирамиду онтологий для формального описания эволюции ПО (SEON), где специфицируются участники процесса разработки, их деятельность, артефакты, которые они создают, и отношения между ними (рисунок 4).
Рисунок 4
Реализация инструментария поддержки SEON выполнена в виде веб-сервисов с интерфейсом запросов на естественном языке и визуализацией результатов. Представлены три приложения, которые работают с SEON в качестве семантической основы. Первое - платформа веб-сервисов анализа эволюции ПО (рисунок 5); второе - ЕЯ-интерфейс для ответов на вопросы по пониманию программ (Hawkshaw); третье приложение представляет собой рекомендующую систему Semantic Visualization Broker (SVB) для анализа семантики заданного набора данных и составления списка визуализаций, которые могут быть полезны для более глубокого понимания анализируемой системы ПО.
Рисунок 5 - Платформа Веб-сервисов анализа эволюции ПО [34]
В работе [37] представлен инструментарий помощи интеллектуальным агентам в решении задач разработки и настройки ПО. Предложенный метод - это онтологический подход, помогающий в принятии решений и обмене информацией посредством использования онтологии ODYSSEY для спецификации ЖЦ разработки ПО. Онтология ODYSSEY разработана в соответствии с методологией Enterprise Ontology и закодирована в формализме Descriptive Logic (DL). Здесь интересна попытка формального описания классических моделей ЖЦ разработки ПО. Например, DL-спецификация верхнего уровня водопадной модели ЖЦ разработки ПО определяется как
а представление этой спецификации в системе Protйgй показано на рисунке 6.
Рисунок 6 - Фрагмент онтологии водопадной модели ЖЦ [37]
В исследовании [38] авторами предлагается DKDOnto - онтология ПрО для распределённых программных проектов. Цель создания этой онтологии - поддержка проектов путём определения общего словаря для рассредоточенных команд разработчиков. Пользователи DKDOnto могут консультироваться с базой знаний, которая возвращает по их запросам лучшие практики, найденные в той же конфигурации проекта. Полученные ответы могут использоваться другими командами, вовлечёнными в тот же проект, или другими командами из других проектов. Фрагмент онтологии DKDOnto представлен на рисунке 7.
Рисунок 7
В работе [39] отмечается, что онтологии в настоящее время являются частью большого числа информационных систем. В результате команды разработчиков ПО, которым приходится объединять деятельность по разработке онтологий с практиками разработки ПО, сталкиваются с рядом проблем, поскольку эти две области развивались, как правило, раздельно. Подход авторов OnToology состоит в том, чтобы обеспечить:
- автоматизацию крупномасштабных вспомогательных действий, связанных с разработкой онтологий, включая документирование, управление версиями, оценку и публикацию онтологий, которые поддерживаются и управляются версиями в известной среди разработчиков ПО среде распределённой системе управления версиями Git;
- рабочее место для поддержки непрерывной интеграции, когда регистрируются новые изменения в онтологии; интеграцию всех работ с Git.
Архитектура программного комплекса OnToology представлена на рисунке 8.
Рисунок 8 - Архитектура программного комплекса OnToology [39]
При этом OnToology может поддерживать как отдельных проектировщиков, так и команды разработчиков в рамках ЖЦ Git. OnToology - это вебсистема, которая объединяет набор существующих инструментов для документации, оценки и публикации. Таким образом, инструментарий OnToology претендует на внедрение средств онтологического инжиниринга в «классические» инструменты совместного проектирования ПО и конкурирует с WebProtege [47, 48]. Интересным в данном решении является то, что в инструментарии OnToology поддерживается преобразование онтологий, спроектированных с использованием OWL, в JSON-представление. Важно и то, что данный инструментарий интегрирован с привычной для разработчиков ПО средой совместного проектирования Git.
Вопросы создания ПО прикладных систем на базе онтологических моделей рассматриваются в работах [49-53], выполненных в нашей стране. Так, в работе [49] обсуждаются общие принципы использования онтологий при разработке программных систем и их сопровождении, даётся классификация онтологий, используемых при проектировании, проведён анализ способов их применения.
В работе [51] предлагается подход к построению ПО для проектирования теплоснабжающих систем (ТСС) на основе концепции модельно-управляемой разработки. Используются технологии метапрограммирования и знания о ПрО в виде онтологий. Приведено описание программного комплекса СОСНА, разработанного на базе изложенного подхода. Программная система автоматически строится на основе следующих компонент: компьютерной модели конкретной ТСС; предварительно разработанных моделей элементов ТСС; программных компонент, реализующих методы и алгоритмы решения прикладных задач; онтологической системы предметных знаний (рисунок 9).
Рисунок 9 - Схема построения модели программной системы [51]
Наиболее интересным здесь является то, что алгоритм верхнего уровня, определяющий схему взаимодействия программных компонент и ход вычислительного процесса, строится автоматически во время построения программной системы на основе описания прикладной задачи и методики её решения, а преобразование математических и графических моделей элементов ТСС в программный код осуществляется на основе XSLT-правил (extensible Stylesheet Language Transformations -- язык преобразования XML-документов).
В работе [52] обсуждаются вопросы использования логической модели представления знаний для обеспечения системы требований к ПО. В рамках модели определяются различные типы требований и устанавливаются иерархические и ассоциативные отношения между ними. На основе критического анализа существующих моделей требований строится онтология типов требований, определяющая отношения между типами требований (классами онтологии), с использованием теории полевой структуры частей речи. Здесь представлена одна из немногих попыток построения онтологии проектирования ПО на основе лингвостатистического анализа текстов требований к разрабатываемому ПО. Для решения проблемы обеспечения выполнения свойств спецификации предлагается гибридная модель знаний, включающая фреймовую онтологию, содержащую иерархическое описание типов (классов) требований и ассоциативных связей между ними (рисунок 10) и систему правил, основанную на продукционной (логической) модели представления знаний.