CC BY
64
дугу приводится список проходящих через нее циклов.
Показатель выраженности предпочтений отражает степень несимметричности элементов относительно главной диагонали. Для матрицы кратности предпочтений вычисляется коэффициент количественной (кардинальной) согласованности по формуле, предложенной Т. Саати.
В правой части вкладки «Результат» задаются параметры вычисления приоритетов сущностей и результаты вычислений, представленные в абсолютной и порядковой шкалах. Приоритеты сущностей вычисляются на основе матрицы А по итерационной формуле: \¥=(с-А + Е)к-ет, где Е - еди-
1Т
.. ; е - транспонированный вектор текущих приоритетов с единичными начальными значениями.
Регулируемые параметры с и к представляют собой масштабный коэффициент (с>1) и степень матрицы. Увеличение масштабного коэффициента улучшает различимость приоритетов, а при к—>оо величина приоритетов учитывает результаты взаимодействия сущностей между собой, то есть их силу. Изменение приоритетов сущностей в зависимости от значения степени к, измеренной в логарифмической шкале, иллюстрируется графиком (рис. 4).
СВП может использоваться для многокритериальной оптимизации по методу Саати. Участвующие в оптимизации МПС формируются как экспертами, так и автоматически, по значениям признаков из таблицы системы СВИРЬ-Р. Формирование МПС на основании столбца таблицы осуществляется попарным сравнением его значений. В этом режиме из системы СВИРЬ-Р задаются не только список сущностей и тип МПС для каждого признака, но и параметры вычисления приоритетов с и к. Указывается также способ формирования МПС.
Многокритериальная оценка приоритета сущностей вычисляется перемножением матрицы
Рис. 4. График изменения приоритетов
приоритетов сущностей по каждому из критериев на вектор важности этих критериев. Он задается из системы СВИРЬ-Р либо вычисляется на основе экспертных предпочтений в системе СВП. МАИ реализуется путем вычисления приоритетов в таблицах иерархии от листовых до корневой.
Результаты однокритериальной и многокритериальной оптимизации возвращаются в таблицы «Решение» системы СВИРЬ-Р. Содержимое МПС с оценками их согласованности и выраженности предпочтений, а также приоритеты сущностей экспортируются в табличный процессор MS Excel для документирования и последующей обработки.
Литература
1. Саати Т.Л. Принятие решений при зависимостях и обратных связях. М.: Изд-во ЛКИ, 2007. 357 с.
2. Микони С.В. Многокритериальный выбор на конечном множестве альтернатив: учеб. пособие. СПб: Лань, 2009. 273 с.
3. Микони С.В., Киселев И.С. Приближенный метод доопределения матрицы парных сравнений с кратными предпочтениями // IEEE AIS'07; CAD-2007: тр. конф. (Дивноморское, 3-9 сентября 2007 г.). М.: Наука. Физматлит, 2007. Т. 1. С. 330335.
ОНТОЛОГИИ ДЛЯ РЕАЛИЗАЦИИ ОБРАТНОЙ ТРАССИРОВКИ ПРИ РАЗРАБОТКЕ И СОПРОВОЖДЕНИИ ПРОГРАММ.
В.В. Рогальчук; А.Д. Хомоненко, д.т.н.
(Петербургский государственный университет путей сообщения, [email protected], [email protected])
Дается краткая характеристика метода обратной трассировки кода, направленного на улучшение понимаемости программ в процессе их разработки и сопровождения. Обосновывается применение онтологий как средства представления знаний в процессе разработки и сопровождения программ. Предлагается вариант онтологии, предназначенной для представления знаний в процессе отслеживания и устранения ошибок программного проекта.
Ключевые слова: обратная трассировка программ, онтологии, представление знаний, разработка программ, сопровождение программ, программное обеспечение, ошибки, отношения.
На эффективность процессов разработки и сопровождения программного обеспечения (ПО)
большое влияние оказывает используемая технология. Одним из подходов, способствующих по-
вышению эффективности разработки и сопровождения ПО, является метод обратной трассировки [1]. Названный метод заключается в предоставлении разработчику инструментария, обеспечивающего поиск и навигацию от элементов программного кода к связанным с его созданием и изменением в ходе развития проекта документам. Это способствует лучшему пониманию и ускорению изучения кода программ. Так как задача изучения программ является одной из самых трудоемких в процессах разработки и сопровождения [2], использование обратной трассировки позволяет снизить общую стоимость проекта разработки. Наличие дополнительного инструментария увеличивает эффективность поиска и устранения ошибок, за счет чего повышается надежность программной системы.
При реализации метода обратной трассировки кода программ требуется решить задачу представления знаний о разрабатываемом проекте ПО. Одним из наиболее перспективных подходов к представлению знаний, по мнению многочисленных специалистов, является использование он-тологий [3].
Онтология - модель представления знаний, комбинирующая в себе свойства семантических сетей и логических моделей. Понимание термина «онтология» варьируется в зависимости от области применения, но среди множества различных определений чаще всего используется определение Грубера: онтология - точная спецификация концептуализации [3]. Под концептуализацией понимается обобщение понятий и информации, необходимых для описания объектов и решения задач в выбранной области знаний - свойства, отношения, аксиомы, утверждения, ограничения.
В [3] предложено рассматривать онтологию как базу знаний, которая может отчуждаться от разработчика и физически делиться между пользователями. Онтологии как средство представления знаний разрабатываются для большого количества предметных областей.
Систематическое описание онтологий для области программной инженерии приводится в [4]. В частности, авторы описывают онтологии для методологий разработки ПО, его сопровождения и измерения характеристик. Для сопровождения ПО предложена следующая группа подонтологий: описания элементов программной системы, используемых в созда-
нии компьютерных знаний, организационной структуры, процесса сопровождения и домена приложения. Как показывает проведенный анализ, данные онтологии не в полной мере поддерживают решение задачи обеспечения понимаемости кода при обратной трассировке программы. В состав реализующей обратную трассировку среды разработки должны входить средства интеграции с существующими системами управления задачами и отслеживания сообщений об ошибках. Следовательно, в состав онтологической системы необходимо включить подонтологию описания задач разработки и сопровождения ПО, а также подонтологию описания ошибок, обнаруживаемых в процессе инспектирования программного проекта. На рисунке 1 показаны основные элементы пяти подонтологий и некоторые из связей между ними.
Подонтология управления задачами для разработчиков создана для интеграции системы управления задачами с системой реализации обратной трассировки. Любые реализации систем управления задачами оперируют понятиями Задача и Комментарий. Задача обсуждается Сотрудниками организации-разработчика. В ходе обсуждения с Задачей связывается множество Комментариев, каждый из которых может устанавливать новое Состояние задачи (Новая задача, Изучается, Отложена, Выполнена, Закрыта, Возобновлена и т.д.). В составе онтологической системы каждый комментарий является Документом, к ко-
Рис. 1. Схема онтологии разработки и сопровождения ПО
торому могут быть проведены трассировочные связи от Артефактов, используемых и изменяемых в ходе решения задачи. Задачи могут ссылаться на другие задачи через отношения иерархии и взаимозависимости, а также на экземпляры других классов в базе знаний.
Онтология описания ошибок
В процессах разработки и сопровождения ПО постановка новых задач часто связана с поступлением информации об обнаруженных ошибках. Предлагаемая в настоящей статье подонтология разработана для интеграции Bug-tracking-систем (систем отслеживания ошибок) в трассировочную среду разработки и содержит основные понятия, используемые в этих системах (рис. 2). На рисунке 2 классы, представленные в онтологии на рисунке 1, выделены подчеркиванием.
Этап жизненного цикла
А
Задача
ссылаетс
относится
оценена
Тип ошибки
Оценка серьезности
имеет уровень
производительность-v.
стоимость ^ Ур°вень серьезности . ti влияния
функциональность-г1
Рис. 2. Онтология описания ошибок
Описание Ошибки содержит время и описание ее обнаружения (элементарные поля свойств «дата обнаружения», «описание»). Указывается Сотрудник, создавший описание. Оценка серьезности ошибки связывается с Уровнем серьезности, также указывается вынесший оценку Сотрудник. Информация об оценках серьезности в дальнейшем может использоваться для ранжирования задач.
Для реализации онтологии естественно воспользоваться программным инструментарием, предназначенным для проектирования, редактирования и анализа онтологий. Из множества современных инструментальных сред поддержки разработки онтологий (Ontolingua, WebOnto, Protege, OntoSaurus и др.) наибольшее распространение получил редактор Protege.
Пример реализации онтологии в среде Protege
Программа Protege предназначена для построения (создания, редактирования и просмотра) онтологий прикладной области. Ее первоначальная цель - помощь разработчикам ПО в создании и поддержке явных моделей предметной области и включение этих моделей непосредственно в программный код. Protege позволяет проектировать онтологии, разворачивая иерархическую структуру абстрактных или конкретных классов и слотов. Редактор Protege основан на фреймовой модели представления знания OKBC (Open Knowledge Base Connectivity) и снабжен рядом плагинов, что позволяет адаптировать его для редактирования моделей, хранимых в разных форматах (стандартный текстовый, в БД JDBC, UML, языков XML, XOL, SHOE, RDF и RDFS, DAML+OIL, OWL).
Структура онтологии аналогична иерархической структуре каталога. На основе сформированной онтологии Protege позволяет генерировать формы получения знаний для введения экземпляров классов и подклассов. Рассмотрим реализацию разработанной авторами онтологии в среде Protege (рис. 3). На вкладке Asserted class hierarchy содержится иерархия классов общей онтологии процесса разработки ПО с выбранным классом Ошибка.
Рис. 3. Вид среды редактора Protege в процессе создания онтологии
На вкладке 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 с.
ЛЕКСИЧЕСКИЕ ОНТОЛОГИИ WORDNET В ТЕХНОЛОГИЯХ SEMANTIC W^^B
Яблонский С.А., к.т.н.; Сухоногов А.М.
(Петербургский государственный университет путей сообщения, [email protected])
В статье дается обзор технологий Semantic Web и определяется место в них лексических онтологий WordNet. Особое внимание уделяется лексической онтологиии WordNet для русского языка (Russian WordNet), разрабатываемой авторами статьи. Описаны структура онтологии, ее состав и возможные сферы применения. Разработка новых методик работы с подобными базами знаний с целью организации веб-добычи семантических данных является одной из приоритетных научных задач.
Ключевые слова: Semantic Web, лексические онтологии, WordNet, Russian WordNet.
В настоящее время исследователями все больше осознается необходимость перехода от документов, читаемых компьютером, к документам, понимаемым компьютером, что является одним из важнейших путей развития World Wide Web. Такой переход становится возможным на основе технологий Semantic Web (W3C Semantic Web Activity - http://www.w3.org/2001/sw/Activity).
Проект Semantic Web (SW) предложил Тим Бернерс-Ли (Tim Berners-Lee) - один из основоположников WWW и нынешний председатель WWW-консорциума (W3C). Концепция SW заключается в организации такого представления информации в сети, чтобы допускалась не только ее визуализация, как это происходит сейчас, но и эффективная
автоматическая обработка. Для этого необходимо решить целый ряд задач [1]. Выделяются следующие этапы развития WWW-сети.
1. Web 1.0 - объединение в сети информации и постоянное ее пополнение.
2. Web 2.0 - объединение в социальные сети людей - Social Web.
3. Web 3.0 - объединение в сети знаний.
4. Web 4.0 - объединение в сети людей и компьютеров для общения и получения знаний наравне друг с другом.
Первые два этапа уже пройдены, третий и четвертый - перспектива.
Базовая модель SW, по Тиму Бернерс-Ли, включает следующие компоненты: URI/IRI - уни-
