Создание и использование онтологий проектов в разработке автоматизированных систем

Размещено на http://www.allbest.ru/

СОЗДАНИЕ И ИСПОЛЬЗОВАНИЕ ОНТОЛОГИЙ ПРОЕКТОВ В РАЗРАБОТКЕ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

П.И. Соснин (sosnin@ulstu.ru)

Ульяновский государственный технический университет, Ульяновск

Оперативное использовании онтологий проектов способствует повышению вероятности успеха разработок сложных автоматизированных систем (АС). Предлагается строить онтологии проекта в виде специализированной АС, обслуживающей концептуальную активность проектировщиков. Такая онтология для каждого проекта строится на основе инструментальной оболочки, включающей формы, для их наполнения онтологическим содержанием, и логико-лингвистические средства для извлечения концептов, их проверки и сборок в прологоподобные формулы.

Введение

Разработка любой сложной АС невозможна без использования интеллектуальной активности проектировщиков, особо важной на этапе концептуального проектирования, когда для АС строится её понятийная версия. Основными «строительными блоками» концептуальной версии АС являются «подходящие понятия», за правильность отбора которых и связывание в более сложные конструкты отвечают акты индивидуального «понимания» и коллективного «взаимопонимания».

В начале разработки конкретной АС «понятия» для её концептуальной сборки, а значит и для осуществления актов «понимания» и «взаимопонимания», в коллективе проектировщиков чаще всего отсутствуют. Эволюция «понимания» и «взаимопонимания» осуществляется по ходу проектирования АС и сопровождается накоплением подходящих «понятий» и связыванием их в систему.

Отмеченная роль понимания (индивидуального и коллективного) в разработках АС хорошо известна [Kroll, 2003]. Для позитивного применения феномена понимания создаются и используются различные средства взаимодействия с пониманием и его инструментальной поддержки. Одним из типов таких средств являются глоссарии в разных вариантах их материализации. Электронный глоссарий является, например, важнейшим артефактом мастер-методологии (и технологии) Rational Unified Process (RUP) широко используемой в разработках АС [Kroll, 2003], однако глоссарий в RUP нормативно определён без автоматизированных средств его заполнения информационным содержанием по ходу проектирования. Отметим, что в проектировании АС проблема динамического извлечения, определения, моделирования, регистрации, сохранения и визуализации понятий как единиц понимания не получила удовлетворительного решения до настоящего времени.

В статье для явной работы с пониманием проектировщиков предлагается включать в инструментальную среду разработки АС подсистему «Онтологии проекта», которая создаётся и используется по ходу проектирования АС. Более того, подсистема «Онтология проекта» строится как специализированная АС (обозначим её АС^ОНТ), нацеленная на поддержку актов понимания и взаимопонимания проектировщиков. Для создания конкретных экземпляров АС^ОНТ разработана специализированная инструментальная оболочка, которая обслуживает извлечение и проверку составляющих онтологии проекта из постановок проектных задач и формулировок проектных решений.

Исходные предпосылки

В зависимости от специфики приложений или точки зрения различают онтологии верхнего уровня, предметных областей, ориентированные на задачи и прикладные онтологии [Гаврилова, 2001]. Онтологии проектов, обслуживающие проектирование и эксплуатацию сложных АС, относятся к классу прикладных онтологий.

В соответствии с публикацией [Guarino et al., 2009] для теории и практика прикладных онтологий «требуется намного больше экспериментов, чем их уже было сделано». Необходимо отметить, что такого экспериментирования особенно не хватает для построений онтологий проектов сложных АС.

Специфика онтологий проектов отражена в ряде публикаций. В техническом отчёте [Garcia et al., 2003] основное внимание концентрируется на треугольнике «люди, процессы, продукты» и согласованном понимании во взаимодействиях между людьми, а также их с процессами и продуктами. Исследования управляющих эффектов онтологий проектов обсуждается в публикации [Guarino et al., 2009].

Использование потенциала онтологий в разработке программных систем и онтологические проблемы программных продуктов представлены в статье [Eden, 2007]. В средствах, представленных в этой статье, принимается в расчёт опыт разработок онтологий задач и роль различных видов знаний. Место знаний в онтологиях задач отражено и обсуждается в публикации [Ikeda et al., 1998], а роль онтологических знаний в моделях решений раскрыта в публикации [Garcia, 2003].

Содержание публикаций, представленных выше, и других публикаций (Интернет-поиска) по онтологиям проектов учтено автором, но не затрагивает сущности предлагаемых ниже средств, которую определяет:

Среда разработки онтологии проекта

В основу комплекса средств, обеспечивающего создание и использование онтологий проектов в виде системы АС^ОНТ, положена инструментальная оболочка, получившая название LINA (Linguistic Into Nominative Activity). Любой экземпляр АС^ОНТ_j начинает свой «жизненный цикл» с исходного состояния оболочки, которое шаг за шагом наполняется информационным материалом, поступающим в реальном времени из процесса проектирования определённой АС. Основной архитектурный вид оболочки (и любого экземпляра АС^ОНТ_j) представлен на рис. 1 и включает ряд компонентов, в том числе компоненту «Рабочий словарь», выполняющий роль «мягкой» проектной онтологии.

Рис. 1. Архитектура инструментальной оболочки LINA

Для каждой статьи онтологии АС^ОНТ_j существует соответствующий аналог в рабочем словаре. Если статья имеет тип «понятие», то такой аналог используется (прежде всего) как форма для хранения представительного множества употреблений понятия, извлекаемых из текстов T_i проектных задач и формулировок проектных решений.

Если статья имеет тип «аксиома», то в её аналоге в рабочем накапливаются необходимые употребления понятий и проектировщиком осуществляется их сборка в прологоподобную формулу.

Информация о понятиях и аксиомах переносится из статей рабочего словаря в статьи онтологии в рамках специализированной задачи, решаемой администратором онтологии, взаимодействующим как с содержанием статьи, так и с авторами этого содержания (если это необходимо). Работа администратора управляется:

- событиями, каждое из которых порождается, когда результат сравнения используемого понятия с онтологией не корректен;

- запланировано, в соответствии с требованиями нормативной систематизации онтологии в условиях эволюции её содержания (включение очередных изменений в систему онтологии АС^ОНТ_j).

Отметим, что информационный материал для администратора онтологии АС^ОНТ_j через рабочий словарь поставляют проектировщики, в обязанность которых входит проверка семантики текстов T_i с помощью «Лингвистического процессора».

Лингвистический процессор

Жизненный цикл онтологии АС^ОНТ_j встроен в жизненный цикл разрабатываемой АС_j так, что каждая текстовая единица T_i, семантика которой должна быть обязательно проверена, поступает на вход компоненты «Лингвистический процессор», обеспечивающей предикатно-онтологический контроль [Соснин, 2009] каждого из предложений П_ij текста T_i.

Базовой единицей контроля является простое предложение ПП, экземпляры которого ПП_ijk выделяются из предложение П_ij текста T_i с использованием псевдофизического моделирования П_ij, операционная обстановка которого приведена на Рис. 2. В таком моделировании словам каждого предложения П_ij приписывается статус «объектов», участвующих в «силовых взаимодействиях», обусловленных «гравитацией» «электрическим полем», «трением» и «упругостью» явных связей между «объектами» (типа «пружинных связей»).

Псевдофизические характеристики «объектам» («масса» и «заряд») приписываются по результатам морфологического анализа предложения П_ij, а параметры («трения» и «упругости») подобраны так, чтобы процесс взаимодействия сходился апериодически. В результат взаимодействия, которое автоматизировано корректируется, «объекты» группируются в совокупность простых предложений {ПП_ijk}.

Рис. 2. Операционная обстановка псевдофизического моделирования

Контроль семантики каждого простого предложения осуществляется с использованием его семантической модели S(ПП_ijk), структура и содержание которой (для одной из типовых версий ПП_ijk) обобщённо представлены на Рис. 3.

Рис. 3. Типовой объект семантического контроля

Семантическая модель S(ПП_ijk) в реализации метода контроля семантики определена как аддитивная совокупность составляющих

S(ПП_ijk) = S₀(ПП_ijk) +??S_m(ПП_ijk),

в число которых включены:

S₀(ПП_ijk) - предикатная модель РР_ijk, прошедшая проверку на соответствие онтологии;

?S₁(ПП_ijk) - синтаксемные характеристики [1] предложения ПП_ijk;

?S₂(ПП_ijk) - вероятностные характеристики ПП_ijk;

?S₃(ПП_ijk) - характеристики нечёткости свойства или отношения, названного в ПП_ijk;

?S₄(ПП_ijk) - причина управляющего воздействия на процесс проектирования;

?S₅(ПП_ijk) - вариант интерпретации проектировщиком содержания ПП_ijk.

Реальность семантических анализа ПП_ijk и проверок такова, что «вычисления» семантических составляющих могут быть прерваны из-за различных объективных причин (новое понятие, непонимание, неполнота знаний, преждевременность предикации). Часть из этих причин приводит к вопросам, на которые следует найти ответ или построить его (развитие онтологии, управление процессом проектирования).

Источники онтологической информации

Инструментальная оболочка LINA способна обрабатывать входной поток текстов T_i, поступающий (в её буфер) из любых источников. Одним из таких источников является система WIQA (Working In Questions and Answers) [Соснин, 2007], обслуживающая моделирование системы проектных задач, визуализируемых в формах, обобщённо представленных на Рис. 4 для демонстрации интерфейсных решений.

Рис. 4. Среда моделирования проектных задач

Система WIQA предназначена для регистрации текущего состояния проекта АС в форме динамического дерева проектных задач, каждая из которых представлена вопросно-ответным протоколом (QA-протоколом) её решения, включая сформулированные проектные решения. В тексты QA-протоколов, если это необходимо по нормативам или для понимания, может быть включена графика (например, UML-диаграммы или другие виды block-and-line схем).

Рабочий словарь

В комплексе средств, обеспечивающем создание онтологий проектов, принципиальное место занимает компонента «Рабочий словарь», которая как «мягкая» версия онтологии аккумулирует всю извлечённую онтологическую информацию, распределяя её по статьям словаря и онтологии. В рабочий словарь введена «нулевая статья» (Рис. 5), в которую поступают простые предикаты (образуя очередь) для их проверок на соответствие онтологии.

Рис. 5. Нулевая статья рабочего словаря

В результате проверок на соответствие онтологии формируются: список Sp({П_ijk}), содержащий «задания» на коррекцию и развитие онтологии проекта; список вопросов Sp({Q_r}), определяющий «направления» развитие проекта; множество предложений{П_ijk}), подтвердивших свою корректность и направленных в статьи «Рабочего словаря» для построения формальных спецификаций проектных задач и проектных решений, материализация которых приведёт созданию АС.

Логический процессор

Компонента «Логический процессор» предназначена для построения прологоподобных формальных представлений текстовых единиц (постановок задач, проектных решений, определений понятий) из информационного материала, который накапливается в статьях рабочего словаря для составных концептуальных конструктов, в число которых входят и аксиомы онтологии проекта. Построение каждой конкретной формулы осуществляется проектировщиком в операционной обстановке, представленной обобщённо на Рис. 6. с использованием визуального редактирования.

Рис.6.

Для того чтобы связать в формулу предикаты, собранные в определённой статье рабочего словаря, проектировщик использует образцы формул для двух простых предикатов, кодирующих семантику «сложного предложения, состоящего из двух простых». В комплекс LINA встроены две библиотеки образцов - для грамматик русского языка (46 шаблонов) и английского языка (32 шаблона).

Систематизация онтологии

Одной из важнейших характеристик любой онтологии, а значит и онтологии проекта, является её систематизация. В рассматриваемом случае онтология проекта построена как специализированная АС, в системность которой вносит вклад её архитектура (комплексирование стилей «клиент-сервер», «модель-вид-контроллер» и «репозиторий»).

С позиций традиционных средств систематизации в онтологии проектов введены и открыты для использования два уровня классификации понятий (понятий с позиций их признаков и классы вариантов употребления понятий), а также системные отношения «часть-целое», «наследование», «вид материализации», «ассоциации» (по сходству, смежности, времени и «пространству» с позиций «места» в АС) и причинно-следственные отношения. Сеть отношений формируется администратором онтологии по мере поступления информационного материала и визуализируется в текущем состоянии для оперативного использования на рабочих местах.

Заключение

В статье представлен комплекс средств создания и использования онтологий проектов в разработке сложных АС, когда коллективам проектировщиков приходится решать большое количество задач, оперативно выявляемых и формулируемых по ходу процесса проектирования. Основным отличием предлагаемых средств является создание онтологии проекта в виде комплекса средств АС^ОНТ, обслуживающего эволюцию понимания и взаимопонимания проектировщиков, обязанных контролировать семантику решаемых проектных задач и формулировок проектных решений, регистрируя её в прологоподобных формах.

Важной спецификой комплекса АС^ОНТ является использование рабочего словаря, предназначенного для первичного накопления и обработки онтологической информации до её регистрации в онтологии. Рабочий словарь позволяет подключить к работе с онтологией проекта проектировщиков, предоставляя право на перенос информации в онтологии только её администратору. Включение комплекса АС^ОНТ в состав системы WIQA.Net, обладающего Web-оболочкой [Соснин, 2007], открывает доступ к онтологии проекта в Интернете для пользователей, которым предоставлены такие полномочия руководством проекта.

Список литературы

моделирование псевдофизический процессор лингвистический

[Гаврилова, 2001] Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем // Учебник. - СПб.: Питер, 2000.

[Соснин, 2007] Соснин П.И. Вопросно-ответное моделирование в разработке автоматизированных систем. - Ульяновск: УлГТУ, 2007.

[Соснин, 2009] Соснин П.И., Шамшев А.Б. Предикатно-онтологический контроль семантики проектных задач и проектных решений // Конгресс по интеллектуальным системам и информационным технологиям. АИС'09 - М.: Физматлит, 2009.

[Eden, 2007] Eden A. H., Turner R. Problems in the Ontology of Computer Programs. // Applied Ontology. - Amsterdam, IOS Press, 2007. Vol. 2. No. 1

[Garcia, 2003] Garcia A. C. B., Kunz J., Ekstrom M. and Kiviniemi A. Building a Project Ontology with Extreme Collaboration and Virtual Design & Construction CIFE Technical Report. - Stanford university, 2003.

[Guarino, 2009] Guarino N., Oberle D. and Staab S. What is an Ontology? In S. Staab and R. Studer (eds.),Handbook on Ontologies, Second Edition. // International handbooks on information systems. Springer Verlag: 2009.

[Ikeda, 1998] Ikeda M., Seta K., Kakusho O., Mizoguchi R.Task ontology: Ontology for building conceptual problem solving models. // Proc. of ECAIЗ98 Workshop on applications of ontologies and problem-solving model, 1998.

[Kroll, 2003] Kroll P. and Kruchten Ph. The Rational Unified Process Made Easy: A Practitioners Guide to the RUP. - Addison-Wesley, 2003.

Размещено на Allbest.ru