Software & Systems

На эффективность процессов разработки и сопровождения программного обеспечения (ПО) большое влияние оказывает используемая технология. Одним из подходов, способствующих повышению эффективности разработки и сопровождения ПО, является метод обратной трассировки [1]. Названный метод заключается в предоставлении разработчику инструментария, обеспечивающего поиск и навигацию от элементов программного кода к связанным с его созданием и изменением в ходе развития проекта документам. Это способствует лучшему пониманию и ускорению изучения кода программ. Так как задача изучения программ является одной из самых трудоемких в процессах разработки и сопровождения [2], использование обратной трассировки позволяет снизить общую стоимость проекта разработки. Наличие дополнительного инструментария увеличивает эффективность поиска и устранения ошибок, за счет чего повышается надежность программной системы.

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

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

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

Систематическое описание онтологий для области программной инженерии приводится в [4]. В частности, авторы описывают онтологии для методологий разработки ПО, его сопровождения и измерения характеристик. Для сопровождения ПО предложена следующая группа подонтологий: описания элементов программной системы, используемых в создании компьютерных знаний, организационной структуры, процесса сопровождения и домена приложения. Как показывает проведенный анализ, данные онтологии не в полной мере поддерживают решение задачи обеспечения понимаемости кода при обратной трассировке программы. В состав реализующей обратную трассировку среды разработки должны входить средства интеграции с существующими системами управления задачами и отслеживания сообщений об ошибках. Следовательно, в состав онтологической системы необходимо включить подонтологию описания задач разработки и сопровождения ПО, а также подонтологию описания ошибок, обнаруживаемых в процессе инспектирования программного проекта. На рисунке 1 показаны основные элементы пяти подонтологий и некоторые из связей между ними.

Подонтология управления задачами для разработчиков создана для интеграции системы управления задачами с системой реализации обратной трассировки. Любые реализации систем управления задачами оперируют понятиями Задача и Комментарий. Задача обсуждается Сотрудниками организации-разработчика. В ходе обсуждения с Задачей связывается множество Комментариев, каждый из которых может устанавливать новое Состояние задачи (Новая задача, Изуча­ется, Отложена, Выполнена, Закрыта, Возобновлена и т.д.). В составе онтологической системы каждый комментарий является Документом, к которому могут быть проведены трассировочные связи от Артефактов, используемых и изменяемых в ходе решения задачи. Задачи могут ссылаться на другие задачи через отношения иерархии и взаимозависимости, а также на экземпляры других классов в базе знаний.

Онтология описания ошибок

В процессах разработки и сопровождения ПО постановка новых задач часто связана с поступлением информации об обнаруженных ошибках. Предлагаемая в настоящей статье подонтология разработана для интеграции Bug-tracking-систем (систем отслеживания ошибок) в трассировочную среду разработки и содержит основные понятия, используемые в этих системах (рис. 2). На рисун- ке 2 классы, представленные в онтологии на рисунке 1, выделены подчеркиванием.

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

Для реализации онтологии естественно воспользоваться программным инструментарием, предназначенным для проектирования, редактирования и анализа онтологий. Из множества современных инструментальных сред поддержки разработки онтологий (Ontolingua, WebOnto, Protege, OntoSaurus и др.) наибольшее распространение получил редактор Protege.

Пример реализации онтологии в среде Protege

Программа Protege предназначена для построения (создания, редактирования и просмотра) онтологий прикладной области. Ее первоначальная цель – помощь разработчикам ПО в создании и поддержке явных моделей предметной области и включение этих моделей непосредственно в программный код. Protege позволяет проектировать онтологии, разворачивая иерархическую структуру абстрактных или конкретных классов и слотов. Редактор Protege основан на фреймовой модели представления знания OKBC (Open Know­ledge Base Connectivity) и снабжен рядом плагинов, что позволяет адаптировать его для редактирования моделей, хранимых в разных форматах (стандартный текстовый, в БД JDBC, UML, языков XML, XOL, SHOE, RDF и RDFS, DAML+OIL, OWL).

Структура онтологии аналогична иерархической структуре каталога. На основе сформированной онтологии Protege позволяет генерировать формы получения знаний для введения экземпляров классов и подклассов. Рассмотрим реализацию разработанной авторами онтологии в среде Protege (рис. 3). На вкладке Asserted class hierarchy содержится иерархия классов общей онтологии процесса разработки ПО с выбранным классом Ошибка.

На вкладке Object properties для выбранного класса Ошибка указываются свойства, в которых этот класс участвует. На вкладке Annotations приводится комментарий для класса, а на вкладке Description дается описание его свойств: наследуемые суперклассы, логически выведенные суперклассы, хранимые в онтологии объекты этого класса и несовместные классы.

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

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

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

Литература

1.   Рогальчук В.В., Хомоненко А.Д. Метод обратной трассировки и оценивание его влияния на стоимость разработки программного обеспечения // Научно-технические ведомости СПбГПУ. СПб, 2008. № 4 (62). С. 146–151. (Информатика. Телекоммуникации. Управление).

2.   Grubb P., Takang A.A. Software maintenance: concepts and practice (2nd edition). Singapore: World Scientific Publishing, 2003. 369 p.

3.   Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. СПб: Питер, 2001. 384 с.

4.   Calero C., Ruiz F., Piattini M. Ontologies for Software Engineering and Software Technology. Springer-Verlag Berlin Heidelberg. 2006. 339 p.

5.   Джалота П. Управление программным проектом на практике. М.: Изд-во «ЛОРИ», 2005. 223 с.