CC BY
34
СПИСОК ЛИТЕРАТУРЫ
1. Booch G. Object-Oriented Analysis and Design with Applications. USA: Addison-Wesley. 2007. 430 c.
2. Miles R. AspectJ Cookbook. Cambridge, USA: O'Reilly. 2004. 354 c.
3. Safonov V.O. Aspect.NET: a new approach to aspect-oriented programming // NET Developer's Journal. 2003. № 4. P. 36-40.
4. Официальный сайт проекта Microsoft Visual Studio // http://msdn.microsoft.com/en-us/ vstudio/default.aspx.
5. Официальный сайт проекта J BOSS AOP // http://www.jboss.org/products/aop.
6. Официальный сайт проекта Spring.NET // http://www.springframework.net/overview.html.
7. Официальный сайт проекта Weave.NET // www.dsg.cs.tcd.ie/sites/Weave.NET.html.
8. Y. Xiong, F. Wan. ССС. An Aspect Oriented Intermediate Language on NET Platform // In Proceedings of the International Workshop on Aspect-Oriented Software Development. September 2004. P. 44-58.
9. Официальный сайт проекта Eclipse // http:// eclipse.org/.
10. Safonov V.O. Using aspect-oriented programming for trustworthy software development // Wiley Interscience. John Wiley & Sons, 2008. 338 c.
11. Грачев M.K. Aspect.NET Framework и его применение в задаче протоколирования // Вестник СПбГУ. Вып. 4. Сер. 10. 2008.
12. Официальный сайт проекта log4.l // http://dmi.ensica.fr/doc/Java/log4j/.
13. Официальный сайт проекта Microsoft Rotor // http://research.microsoft.com/ programs/ europe/rotor/.
14. Страница проекта Aspect.NET на сайте Microsoft Academic Resource Center // https:// www.academicresourcecenter.net/curriculum/ pfv.aspx? I D=6801.
15. Safonov V.O., Grigoriev D. Aspect.NET: concepts and architecture // NET Developer's Journal. 2005. № 7. P. 28-33.
16. Safonov V.O., Grigoriev D. Aspect.NET — an aspect-oriented programming tool for Microsoft.NET // 110th Anniversary of Radio Invention. St. Petersburg, 2006. P. 11—21.
17. Григорьев Д.А., Грачев M.K., Масленников А.И. Сафонов В.О. Адаптация методологии АОП для практического применения на платформе Microsoft.NET // Технологии Microsoft в теории и практике программирования: Тезисы докладов конкурса-конференции. СПб.: Изд-во СПбГПУ, 2007.
УДК 681.3
Д.А. Лукашев, В.П. Котляров, Ю.В. Юсупов АВТОФОРМАЛИЗАЦИЯ ФРАГМЕНТОВ JAVA-KOflA ДЛЯ UML-МОДЕЛЕЙ
В современном программировании роль методов обратного инжиниринга становится все более заметной, в особенности при восстановлении спецификаций проектов, написанных на языке иМЬ, в которых высокоуровневые спецификации перемежаются с кодовыми фрагментами. Анализ различных свойств корректности поведенческой модели, созданной на основе спецификации требований программного продукта, требует от модели полноты формального задания, чему препятствуют кодовые вставки. Описание подхода к пополнению формального задания иМЕ-модели приводится в данной статье. Описан процесс трансфор-
мации кодового фрагмента на языке Java в абстрагированное представление в нотации базовых протоколов. Основным инструментом, автоматизирующим подобное преобразование, служит Klocwork, дополненный системой специализированных чекеров (checkers). Объединяя базовые протоколы кодовых фрагментов с трансформированной в язык базовых протоколов UML-моделью, получаем пригодное для анализа формализованное представление всей поведенческой модели. Для преобразования UML-модели в язык базовых протоколов и последующего анализа используется инструментарий Verifier of Requirement Specifications (VRS).
Конференция "Технологии Microsoft в теории и практике программирования"
Формализация и верификация модели.
Программное обеспечение (ПО) часто используется в критичных к ошибкам областях человеческой деятельности, поэтому гарантии качества производимого продукта — неотъемлемая часть современного процесса производства ПО. Использование формального подхода для достижения заданного уровня качества — одно из бурно развивающихся направлений в данной области.
Верификация как основной метод формального подхода в самом общем смысле означает проверку соответствия между требованиями к системе и свойствами реализованной системы [I]. Также формальная верификация обеспечивает гарантию того, что в системе будут проанализированы все ключевые свойства во всех режимах работы.
Универсальность формального языка, покрывающего несколько основных этапов жизненного цикла программного продукта. а также машинно-читаемый формат лежат в основе технологии, направленной на повышение качества ПО с помощью совместного использования верификации и тестирования |2|. Формальный язык базовых протоколов [3] поспособствовал объединению системы верификации VRS [4] и системы автоматизации тестирования TAT |2| в одну технологическую цепочку. Семантика данного языка имеет расширенный MSC-формат [5], позволяющий формализовать функциональные спецификации и строить поведенческие модели систем.
Язык базовых протоколов является внутренним форматом инструмента VRS (Verifier of Requirement Specifications), задача которого заключается в проверке различных свойств корректности поведенческих моделей систем. Системы могут быть реализованы на языках MSC, SDL [6] и UML [7], которые наиболее известны в области визуального моделирования. Подробнее работа инструментария VRS описана в [2].
В основе использования базовых протоколов лежит теория агентов и сред, де-татьно описанная в [8|. В соответствии с ней система может быть представлена в виде композиции окружения и агентов (сущностей, объектов, процессов и т. п.). Состояние системы в любой момент времени
характеризуется состояниями агентов, а также значениями их параметров и атрибутов.
Как правило, изменение состояния агента (системы) связано с некоторыми действиями, переводящими агент (систему) в другое состояние. Такого рода переход системы может быть с легкостью описан с помощью базового протокола.
В общем случае базовый протокол — это тройка Хоара [9], реализованная средствами языка элементарных MSC-диаграмм. Каждая диаграмма описывает переход программной системы из одного состояния в другое. При этом каждый базовый протокол представляет собой выражение вида
Vx(a -»< ц > р),
где х — список (типизированных) параметров; a (предусловие — PRE) и [3 (постусловие — POST) — формулы базового языка; ц — процесс протокола (вполне определенное поведение).
Проверка UML-модели осуществляется в два этапа. Первый этап — этап формализации, на котором происходит трансляция с языка UML в язык базовых протоколов с помощью модуля UML2BP системы VRS. Результат работы модуля — множество базовых протоколов, представляющих собой формальную модель системы. На втором этапе полученный набор формальных нотаций поступает на вход верификатора. Для корректной проверки свойств системы необходима ее полная поведенческая модель, получение которой не всегда возможно. Трудности возникают в rex случаях, когда конечные автоматы (state machine diagram), описывающие поведение системы, перемежаются с текстовыми диаграммами (text diagram). Данные диаграммы, как правило, содержат Java-код, который не всегда поддается формализации модулем UML2BP, что отражается на неполноте модели.
Данная статья описывает подход, позволяющий пополнить формальную модель системы недостающими нотациями в формате базовых протоколов. Описан процесс формализации фрагментов Java-кода, основанный на инструменте анализа кода Klocwork. Для данного инструмента был реализован модуль (JAR), использующий
открытый интерфейс в системе Klocwork и структуру абстрактного синтаксического дерева (АСД) для сбора данных по коду, а также построения и генерации базовых протоколов.
Реализация формализации Java-кода. Для автоматизации процесса формализации кодовых вставок, содержащих Java-код, решено использовать современный инструмент анализа кода, с помощью которого обеспечиваются:
поддержка анализа Java-кода; простой формат промежуточных представлений кода:
доступ к базе данных, содержащей результаты анализа;
возможность расширения базовой функциональности.
После проведенного исследования в области инструментария принято решение использовать Klocwork. Данный инструмент является статическим анализатором С, С++ и Java-кодэ и удовлетворяет требованиям к базовому инструменту, в данном случае обеспечивает:
большие объемы обрабатываемого кода систем (~4—5 MLOC);
высокую скорость обработки исходного кода за счет оптимизированных алгоритмов анализа;
использование унифицированных интерфейсов. позволяющих получать доступ к промежуточным данным статического и динамического анализа кода систем.
Klocwork — это мощный промышленный инструмент для решения задач обрат-
ного инжиниринга (reverse engineering) — анализа исходного кода с целью идентификации системных компонент и их взаимосвязей, а также представления его в другой форме или на более высоком уровне абстракций [10]. Промежуточным представлением программы является абстрактное синтаксическое дерево (АСД), которое создается в ходе анализа исходного кода. На его основе строятся графические представления программы, проводятся синтаксический анализ кода и его проверка на разные свойства, осуществляемая с помошыо специальных программ — чекеров (checker).
Чекер — динамически подключаемый модуль (JAR), реализованный на языке Java. Данная библиотека содержит правила обхода АСД с целью проверки заданных свойств кода. На рис.1 представлена схема применения чекера для анализа исходного кода.
В общем задача чекера сводится к формированию ответов на запросы о свойствах кода на основе его АСД. А поскольку данная структура является унифицированным форматом данных и содержит полную информацию о коде, она может быть использована для построения по ней формального описания без обращения к исходным текстам.
Процесс формализации фрагментов Java-кода и получения множества базовых протоколов с использованием инструмента Klocwork можно разбить на два основных этапа.
Первый этап связан с анализом исходного кода и автоматическим построением АСД. Он полностью реализуется за счет базового инструментария Klocwork. Вся
(АСД
Чекер (Java)
Klocwork
чекер (JAR)
. Результаты
Компилятор Java
Создание JAR
Рис. 1. Использование чекера для анализа исходного кода в среде К1ос\Уогк
4-
Конференция "Технологии Microsoft в теории и практике программирования"
информация о разобранном коде сохраняется в специализированной базе данных и имеет структуру АСД. Доступ к данным осуществляется через открытый интерфейс в системе Klocwork и с помощью методов обхода дерева (набор методов описан в документации к Klocwork).
На втором этапе происходит анализ АСД с помощью чекера. Данная компонента реализована на языке Java в виде динамически подключаемого модуля без применения каких-либо специализированных мета-язы-ков, что. несомненно, упрощает ее поддержку и модификацию.
Эффективность работы чекера достигается за счет применения реализованных алгоритмов обхода дерева, осуществляющих перебор всех его вершин. В зависимости от типа вершины происходят ее разбор, анализ предыдущей вершины и формирование составляющих базового протокола — предусловия, процессной части и постусловия.
Java — объектно-ориентированный язык. Поэтому также реализованы функции, учитывающие последовательность вызовов конструкторов и методов классов при формировании базовых протоколов, т. е. функции
обработки вызовов конструктора базового класса, статической инициализации, полиморфных методов.
На рис. 2 изображен этап работы вершин, цель которого — формирование формул для пред- и постусловий, а также процессной части, состоящей из событий и сигналов.
Поскольку кодовые фрагменты для формализации могут представлять из себя отдельные функции с длиной в несколько десятков строк кода и нелинейным потоком управления, поставлена задача реализации метода сохранения порядка следования протоколов. Для этого в пред- и постусловие каждого протокола вводится специальный атрибут "control_flow,\ основные задачи которого — сохранение потока управления исходного кода и упрощение анализа базовых протоколов, осуществляемого после этапа генерации формализмов в текстовой нотации формата МБС.
Таким образом, можно утверждать, что решение поставленных задач станет реализацией процесса возвратного проектирования. заключающегося в анализе исходного
Рис. 2. Этап разбора вершин АСД и построения базовых протоколов
кода и представлении его на более высоком уровне абстракций в нотации базовых протоколов.
Данный метод по формализации фрагментов .1ауа-кода был апробирован в не-
скольких крупных проектах по верификации иМЬ-систем с помощью УЯБ-техно-логии. Формализация осуществлялась на фрагментах кода объемом порядка 100 ШС и дала положительные результаты.
СПИСОК ЛИТЕРАТУРЫ
I. IEEE Standard Glossary of Software Engineering Terminology, ANSI/IEEE Standard 610.12-1990, IEEE Standard. IEEE. NY. 1990.
2 Дробиниев Г1.Д. Интегрированная техноло-шя обеспечения качества программных продуктов с помощью верификации и тестирования: Дис. ... канд. техн. наук / СПбГПУ. СПб., 2006. 238 с.
3. Letichevsky A. A., Kapitonova J.V., Volkov V.A., Letichevskv A.A. (jr-). Baranov S.N., kotlyarov V.P., Weigert T. System Specification with Basic Protocols // Cybernetics and Systems Analysis archive. Volume 41. Issue 4 (July 2005). P. 479-493.
4. Baranov S., Jervis C., Kotlyarov V,, Letichevsky A., Weigert T. Leveraging UML to deliver correct telecom applications in UML for Real: Design of Embedded Real-Time Systems by L. Lavagno, G. Martin, and B. Selic (editors), 323-342. Kluwer Academic Publishers, 2003.
5. ITU Recommendation Z. 120. Message Sequence Charts (MSC), 11/99.
6. ITU-T z. 100 (08/2002) // Telecommunication standardization sector of ITU. 202 p. littp:// www. it u.int/rec/T-REC-Z. 100-200208-I/e.
7. OMG. UML 2.0 Infrastructure Specification. September, 2004. http://www.omg.org.
8. Letichevsky A.A., Gilbert D.R. A Model for Interaction of Agents and Environments // Selected papers from the 14th International Workshop on Recent Trends in Algebraic Development Techniques. Lecture Notes in Computer Science, 1827, 311-328, 1999.
9. Hoare C.A.R., Communicating sequential processes. Prentice Hall, London, 1985.
10. Chikofsky E.J., Cross J.H. Reverse engineering and design recovery: A taxonomy // IEEE Software. 1990. 7. P. 13-17.
УДК 681.3
В. П. Кот ля ров, A.B. Петров
АВТОМАТИЗАЦИЯ ФОРМАЛИЗАЦИИ ТРЕБОВАНИЙ К ПРОГРАММНЫМ ПРОЕКТАМ
Современный программный продукт (ПП) создается с целью удовлетворить потребности заказчика, обозначенные в документе — так называемых требованиях, которые определяют свойства продукта, заказанные или подтвержденные заказчиком. Номенклатура свойств ПП очень разнообразна. однако одно свойство присутствует во всех требованиях — это качество.
Метрика качества ПП определяет ограничения на плотность дефектов — остаточных ошибок в продукте. Построение объективной процедуры выявления ошибок приводит к формализации спецификаций указанных требований.
В результате вычисление метрики качества в виде допустимого уровня остаточных дефектов становится формально определенным и, следовательно, объективно измеряемым, что позволяет гарантировать желаемую степень качества ПП (например, 100 %), измеряемую относительно формализованных требований.
Измеряемость требований и критерии качества. В современной проектной документации формулировка требований задается либо конструктивно (измеряемо), когда из текста требования на естественном языке удается реконструировать процедуру контроля или сценарий проверки выполнения
