ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2016 г.)
2-летний импакт-фактор РИНЦ: 0,493
2-летний импакт-фактор РИНЦ без самоцитирования: 0,389
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,732
5-летний импакт-фактор РИНЦ: 0,364
5-летний импакт-фактор РИНЦ без самоцитирования: 0,303
Суммарное число цитирований журнала в РИНЦ: 5022
Пятилетний индекс Херфиндаля по цитирующим журналам: 355
Индекс Херфиндаля по организациям авторов: 499
Десятилетний индекс Хирша: 11
Место в общем рейтинге SCIENCE INDEX за 2016 год: 304
Место в рейтинге SCIENCE INDEX за 2016 год по тематике "Автоматика. Вычислительная техника": 11

Больше данных по публикационной активности нашего журнале за 2008-2016 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

3
Ожидается:
16 Июня 2018

Онтологии для реализации обратной трассировки при разработке и сопровождении программ

Ontology’s for realization of reverse tracing at development and maintenance of programs
Статья опубликована в выпуске журнала № 4 за 2009 год.[ 16.12.2009 ]
Аннотация:Дается краткая характеристика метода обратной трассировки кода, направленного на улучшение понимаемости программ в процессе их разработки и сопровождения. Обосновывается применение онтологий как средства представления знаний в процессе разработки и сопровождения программ. Предлагается вариант онтологии, предназначенной для представления знаний в процессе отслеживания и устранения ошибок программного проекта.
Abstract:The short characteristic of a method of reverse trace of the code directed on improvement of intelligibility of programs in the course of their working out and support is given. Application ontology as means of representation of knowledge in the course of development and maintenance of programs is proved. The variant ontology, intended for representation of knowledge in the course of tracing and elimination of errors of the program project is offered
Авторы: Рогальчук В.В. (joawl@mail.ru) - Петербургский государственный университет путей сообщения, , , Хомоненко А.Д. (khomon@mail.ru) - Петербургский государственный университет путей сообщения, , , доктор технических наук
Ключевые слова: отношения, ошибки, программное обеспечение, сопровождение программ, разработка программ, представление знаний, онтологии, обратная трассировка программ
Keywords: relations, errors, the software, maintenance of programs, development of programs, representation of knowledge, ontology, reverse trace of programs
Количество просмотров: 10496
Версия для печати
Выпуск в формате PDF (4.85Мб)

Размер шрифта:       Шрифт:

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

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

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

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

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

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

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

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

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

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

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

Подпись:   Рис. 2. Онтология описания ошибок

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

Подпись:   Рис. 3. Вид среды редактора Protege в процессе создания онтологииСтруктура онтологии аналогична иерархической структуре каталога. На основе сформированной онтологии 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 с.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=2358
Версия для печати
Выпуск в формате PDF (4.85Мб)
Статья опубликована в выпуске журнала № 4 за 2009 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: