Учреждение Российской академии наук

Институт автоматики

и процессов управления

Дальневосточного отделения РАН

Е.А. Шалфеева

ИСПОЛЬЗОВАНИЕ ОНТОЛОГИЙ

ПРИ РАЗРАБОТКЕ

УПРАВЛЯЕМЫХ ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ

Владивосток

2011

УДК 004.89

Шалфеева Е.А. ИСПОЛЬЗОВАНИЕ ОНТОЛОГИЙ ПРИ РАЗРАБОТКЕ

УПРАВЛЯЕМЫХ ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ. Владивосток: ИАПУ ДВО РАН, 2011. 35 с.

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

Работа рассчитана на специалистов в области искусственного интеллекта, в частности, онтолого-базированной разработки программных систем, а также аспирантов и студентов соответствующих специальностей.

Ответственный редактор д.ф.-м.н. А.С. Клещев

Рецензент д.т.н. В.В. Грибова

© ИАПУ ДВО РАН, 2011

В последнее десятилетие прогресс в создании практически полезных и жизнеспособных интеллектуальных программных систем в различных областях человеческой деятельности в большой степени связывается с разработкой механизмов управления ими.

На сегодняшний день для повышения эффективности разработки программных систем («would facilitate building bigger and better systems and cheaply») используются (обычно повторно) такие информационные ресурсы как декларативные знания (declarative knowledge) и онтологии [Corcho 2006]. Прогресс в создании жизнеспособных интеллектуальных программных систем (сокр. ИПС) в большой степени связывается с выделением в качестве декларативной информации все большей доли компонентов ИПС. Предполагается, что воздействуя на нее, а не меняя непосредственно код, можно улучшать систему или менять некоторые ее характеристики [Грибова 2010].

Управление здесь означает внесение изменений в любой из трех архитектурных компонентов ИПС (решатель задач, пользовательский интерфейс, база знаний), не требующее перекомпиляции кодов программных единиц. В частности, управляемость решателя задач может быть повышена за счет отделения в нем декларативного компонента от процедурного [Грибова 2010a]. В данном случае решатель ИПС, с одной стороны, связан с декларативно представленными хранимыми знаниями, а с другой, сам имеет хранимое декларативное представление. Поэтому необходимы методы эффективной разработки всех декларативных компонентов ИПС и высокоуровневого управления ими, подразумевающего синхронизацию изменений во всех взаимосвязанных представлениях компонентов ИПС, а также автоматизацию документирования компонентов и всей ИПС.

Для управления или сопровождения программного обеспечения известны методы, позволяющие проводить изменения в «ранних» моделях - либо в функциональных спецификациях [Maharaj 2000, RAISE 1995], либо в специфицирующих поведение систем UML-моделях - с последующей автоматической генерацией по ним фрагментов исходного кода [Гуров 2005, Шалыто 2003].

Однако, по мнению теоретиков и практиков проектирования программного обеспечения, возможности применения этой методологии весьма ограничены. Они эффективны в тех случаях, когда функциональность и другие желаемые свойства программ могут быть выражены в математически строгой спецификации. Применение «формальных методов» продемонстрировано для детерминированных программ («в которых начальное состояние однозначно определяет конечное состояние»), а расширения таких методов на более общие классы программ чрезмерно сложно. Форма представления требований пригодна для программистов, но неудобна для обсуждения с пользователями. Такая документация оказывается непрактичной для больших, сложных систем. Для большинства программных разработок использовать формальные методы сложнее, и обходится это недешево [Voas 1999, Parnas 2010]. Применение «автоматного программирования» продемонстрировано для программирования задач логического управления, задач циклической природы различного назначения и систем, особенностью которых является «сложное поведение», т.е. многообразие комбинаций внешних управляющих воздействий [Кузнецов 2000].

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

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

Целью работы является разработка моделей и методов согласованного декларативного представления компонентов ИПС, предназначенного для эффективного их создания и управление ими.

1. Разработка сопровождаемых программных систем

Согласно IEEE Guide to the Software Engineering Body of Knowledge (SWEBOK) фаза сопровождения в жизненном цикле программных систем обычно начинается сразу после их приемки/передачи и действует в течение периода гарантии или, чаще, технической поддержки. Однако, сама деятельность, связанная с сопровождением, должна начинаться намного раньше. Сопровождаемость (Maintainability) программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований [SWEBOK 2004].

Желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения программного обеспечения. Инженеры формулируют запросы на изменения, идентифицируют компоненты, в которые необходимо внести изменения. Если программное обеспечение изначально разрабатывается с учетом его дальнейшей поддержки, это существенно облегчает анализ влияний вносимых изменений. Систематические специфицирование, оценивание и контроль выбранных характеристик упрощают дальнейшее сопровождение [SWEBOK 2004].

Одной из ключевых проблем сопровождения является отсутствие системной документации, мешающее формированию понимания программной системы и приводящее к невозможности адекватного анализа влияния. Проблемы сопровождаемости принято решать через «применение соответствующих техник и автоматизации необходимых задач по поддержке жизненного цикла с помощью специализированных инструментальных средств» [SWEBOK 2004].

Современные идеи в области создания жизнеспособных ИПС связаны не столько с длительным их сопровождением, сколько с управлением ими. Управление здесь - решение задач сопровождения программного средства с помощью специальных высокоуровневых механизмов управления, сводящих к минимуму изменение его кода [Грибова 2010].

1.1. Обеспечение управляемости или сопровождаемости программных систем

В связи с остро стоящими вопросами внесения изменений в процессе разработки программных систем много внимания в публикациях отводится теме архитектуры и разработке на основе моделей (Model Driven Architecture - MDA, Model Driven Software Development). Их идеи состоят в том, что вводятся «вышестоящие уровни описаний» программной системы и предметной области, на основе которых в идеале решается или облегчается задача генерации программного кода.

Моделе–управляемая разработка укорачивает цикл от внесения изменения в модель до получения скомпилированного продукта. Для новых проектов, не требующих привязки к существующим базам данных (БД) рекомендуется все структурные изменения вносить на уровне диаграммы классов, и из нее же генерируется «физическая модель данных» (ФМД). При создании приложений, работающих с уже существующими БД рекомендуется все структурные изменения вносить на уровне ФМД, а диаграмма классов восстанавливается по ФМД или синхронизируется с ней. В частности, инструментарий Sybase PowerDesigner умеет корректно преобразовывать ФМД в модели классов объектов и обратно, а также генерировать код классов доступа к данным. Наиболее мощной и высокоуровневой практической реализацией идей MDA на сегодня является инструментарий ARIS Toolset, предназначенный для моделирования информационных систем управления предприятием [Тарасов 2007]. Применение этого подхода опробовано для приложений, работающих с базами данных.

1.2. Обеспечение документирования программных систем

Применение CASE-средств (компьютерная технология программирования) рассчитано на компьютерное представление программных документов и на использование формальных языков уже на ранних этапах разработки ПС, например, графических языков спецификаций. Это позволяет рационально изменить совокупность технологических процессов разработки и сопровождения ПС. Графические методы спецификаций приводят к созданию различных схем и диаграмм, которые определяют структуру информационной среды и структуру управления ПС. К таким структурам привязываются фрагменты описания данных и программ, представленные, например, на алгебраических языках спецификаций. Такие спецификации позволяют автоматически осуществлять различные виды контроля спецификаций ПС, в значительной степени или полностью автоматически генерировать программы. При этом количество видов документов сокращается по сравнению с традиционной технологией. Существенной частью разработки спецификаций является создание словаря именованных сущностей, используемых в спецификациях [Жоголев 2004].

Для упрощения процесса создания проектной документации и поддержания ее в течение всего цикла разработки ПО - рутинной и необходимой деятельности технологии разработки программных систем – используют инструменты, такие как Crystal Reports,

SoDA (Software Documentation Automation). SoDA, в частности, позволяет осуществлять отчетность по различным стандартам - от ISO, заложенного в саму систему, до любых других, вплоть до придуманных в самой компании. С помощью удобного визуального редактора можно создавать шаблоны, соответствующие всевозможным внешним стандартам (таким как ISO 9000, IEEE, MIL-STD-498 и DOD-STD-2167A) или внутренним стандартам компании. По задаваемым пользователем шаблонам SoDA "компилирует" документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в Rational Rose. Далее пользователь может отредактировать полученный документ.

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

SoDA может отслеживать изменения, происходящие с источниками, на основе которых была в последний раз "скомпилирована" документация, а пользователь может из любой части документации быстро получить доступ к источникам, информация из которых в ней используется. Изменения, внесенные в модель, автоматически отражаются в документе (т.к. все элементы документа представляют собой внедренные объекты) [Новичков 2001].

Инструмент Rational Rose в рамках автоматизации этапов анализа и проектирования ПО позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: диаграммы классов; диаграммы состояний; диаграммы взаимодействия; диаграммы модулей; диаграммы процессов; спецификации классов, объектов, атрибутов и операций, заготовки текстов программ; модель разрабатываемой программной системы (она содержит всю необходимую информацию о проекте). Этот инструмент имеет механизм так называемого обратного проектирования, когда исходный код превращается в модель Rose (преобразуясь в UML-нотацию). При обратном проектировании учитываются все составляющие классов, а также комментарии, которыми они снабжались, вследствие чего на выходе получается полная модель всех классов (с иерархией) [Боггс 2000].

Роль проектной документации меняется: код основывается на проектной документации, а не наоборот [Шалыто 2003]. Документация описывает не только конечный продукт, но и процесс его создания. Проектная документация должна содержать, в частности, формальную спецификацию на логику разрабатываемой программы, так как «то, что не специфицировано формально, не может быть проверено, а то, что не может быть проверено, не может быть безошибочным». Перепроектирование программы в этом случае может быть выполнено значительно проще, чем при наличии только исходных текстов.

Программное обеспечение с подробной открытой проектной документацией, в которой программная документация является лишь составной частью, может рассматриваться в качестве новой разновидности паттернов проектирования [Шалыто 2003].

Таким образом, с учетом современного отношения к сопровождаемости систем как к управляемости и с учетом современного состояния дел в инструментальной поддержке сопровождения систем, можно конкретизировать проблему для систем, основанных на знаниях. Методы создания управляемых ИПС должны быть связаны с моделированием взаимосвязи декларативных представлений, документов, проектных и других технологических моделей ИПС.

следующая страница>