CC BY
15
Этап верификации исходной иМЬ-мо-дели позволил выявить порядка 100 неточностей, 12 из которых разработчиками были признаны дефектами, исправленными в последующих версиях продукта.
Этап автоматической генерации тестов занимает несколько минут, что значительно меньше времени на ручную разработку. Даже учитывая затраты, необходимые на разработку иМЬ-диаграммы (в случае отсутствия готовой спецификации тестового сценария) и .х15 файла для настройки кон-
кретного тестового прогона, выигрыш по времени на получение только одного ТТСЫ-теста в соответствии с предложенной методикой составляет несколько часов.
Разработанная методика верификации и автоматизации тестирования доказала свои преимущества в крупном телекоммуникационном проекте и может быть в дальнейшем переиспользована во многих других проектах, поддерживающих иМЬ-проекти-рование.
СПИСОК ЛИТЕРАТУРЫ
1. U ML Distilled Second Edition. A Brief Guide to the Standard Object Modeling Language.
2. Visser W., Havelund K., Brat G., Park S. and Lcrda F. Model checking programs // Automated Software Engineering Journal, 10(2), April 2003.
3. Fernandez J.-C., Jard C., Jeron Th. and Viho C. Using on-the-fly verification techniques for the generation of test suites // Proc. 8th Conference on Computer Aided Verification, volume 1102 of Lecture Notes in Computer Science, New Brunswick, August 1996.
4. Легичевский A.A., Капитонова К).В.. Jle-тичевский А.А. (мл.) и др. Спецификация систем с помощью базовых протоколов // Кибернетика и системный анализ. 2005. № 4. С. 3—21.
5. Letichevsky A., Kapitonova J., Ixtichevsky A. Jr., Volkov V., Baranov S., Kotlvarov V., Weigert T. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications. Proc of ISSRE04 Workshop on Integrated-reliability with Telecommunications and UML Languages (ISSRE04:WITUL), 2 Nov. 2004:1RISA Rennes France.
6. ITU-T Recommendations Z. 140—142 (2002): The Testing and Test Control Notation Version 3 (TTCN-3).
7. Kotlyarov V., Drobintsev P., Peskov D., Yusupov Y. Implementation of an Integrated Verification and Testing Technology in Telecommunication Project // Proc. of St. Petersburg IEEE Chapter, International Conference, May 18-21, St. Petersburg. Russia, 2005. P. 87-92.
УДК 004.4*2
Д.А. Григорьев
РАЗРАБОТКА И ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ АСПЕКТНО-ОРИЕНТИРОВАННОЙ СРЕДЫ ПРОГРАММИРОВАНИЯ ДЛЯ ПЛАТФОРМЫ MICROSOFT.NET
В традиционных объектно-ориентированных программах актуальной является задача декомпозиции компонентов по "сквозной" функциональности, реализация которой рассредоточена сразу по нескольким уровням системы. Примерами такой функциональности могут служить протоколирование событий, авторизация и управление безопасностью, обработка транзак-
ций и т. п. С помощью объектно-ориенти-рованного программирования (ООП) [1] можно достаточно подробно описать понятия предметной области. При этом, однако, одну и ту же задачу необходимо отдельно решать для каждого уровня абстракции архитектуры.
Применение шаблонов проектирования ООП характеризуется тем, что необходимо [I]
проинициализировать соответствующие фабричные классы и вставить вызовы интерфейсных методов во все точки кода, где необходима данная функциональность. В дальнейшем нельзя будет повторно применить подобное решение в другом проекте без модификации кода. Иными словами, реализация шаблонов проектирования рассредоточена по нескольким модулям, и они сами по себе являются "сквозными" компонентами. Если заранее предназначение шаблона неизвестно. то воспринимать такую функциональность становится затруднительно.
Аспектно-ориентированное программирование (АОП) позволяет решить данную проблему: собрать "сквозные" компоненты в один модуль (аспект), в котором объединяются действия, выполняемые в определенных точках программы, и правила их внедрения в целевой код бизнес-логики. Под бизнес-логикой понимается исходный код, который описывает сущности предметной области и работу с ними в ее рамках. Такой код сосредоточен лишь на решении пользовательской задачи, в то время как "сквозная" функциональность выносится в отдельные модули — аспекты. Совокупность аспектов затем применяется к основной бизнес-логике с помощью правил внедрения, и на выходе получается система, которая решает целевую задачу. За счет возможности многократного переиспользования аспектов и отделения вспомогательных задач от основного кода удобство разработки и сопровождения программных систем существенно повышается. В дополнение к определению множества точек внедрения, куда необходимо вставить действие в целевом коде, правила могут передавать в действие аспекта динамический контекст потока выполнения в данной точке.
Следует заметить, что АОП не заменяет ООП, а органично его дополняет. Более того, реализация шаблонов проектирования с помощью АОП повышает их эффективность [21.
Постановка задачи. Данная статья описывает реализацию и практическое применение Aspect.NET — среду АОП-разработки для платформы Microsoft.NET, реализацией которого занимается коллек-
тив авторов под научным руководством проф. В.О. Сафонова. Для того, чтобы сделать Aspect.NET привлекательным для использования в повседневном программировании, автором статьи сформулированы следующие требования к технологии Aspect.NET.
1. Расширить оригинальную спецификацию метаязыка описания аспектов Aspecl.NET ML [3j для более точного описания местонахождения точек внедрения. На практике зачастую приходится ограничивать место вызова действия аспекта точной сигнатурой целевого метода, именем типа целевого объекта, а также конкретизировать класс, в котором встречается вызов целевого метода.
2. Разработать механизм доступа действия аспекта к контексту точки внедрения. Для того, чтобы выполнять свое предназначение, аспект должен знать о метаданных целевого метода, значениях его аргументов, значении возвращаемого результата, сгенерированном в месте применения действии аспекта исключении, а также владеть информацией о его местонахождении в исходном тексте.
3. Реализовать разработанную спецификацию в виде отдельного приложения — компоновщика аспектов. Данное приложение получает готовые сборки аспектов из редактора аспектов, построенного в виде надстройки к MS Visual Studio [4|, и статически интегрирует их в целевой код. Для поиска, отображения и фильтрации заданных точек внедрения предусмотрен специальный режим сканирования целевой сборки. Интерфейс компоновщика аспектов должен позволять использование в рамках сторонних АОП-инструментов.
Обзор и сравнение существующих технологий. Наиболее популярным и мощным инструментом АОП является AspectJ [2], который представляет собой расширение языка Java конструкциями описания аспектов. Собственное расширение Java для описания аспектов позволяет более гибко и полно описывать структуру аспекта и правила его внедрения. При этом реализация аспекта выглядит довольно естественно и улучшается его восприятие. Однако в дан-
ном подходе есть и отрицательный момент: поскольку AspectJ просто дополняет язык Java некими конструкциями, то его нельзя перенести без существенных изменений на другой язык программирования. Отсюда возникает необходимость вносить изменения в систему каждый раз, когда меняется спецификация самого языка Java. Для реализации AspectJ разработчикам пришлось заново создавать всю инфраструктуру разработки аспектно-ориентированного ПО. На данный момент его инструментарий включает: отдельный компилятор/компоновщик аспектов, утилиту для составления документации, обозреватель "сквозной" функциональности. среду разработки, отладчик и визуализатор примененных аспектов.
Сам процесс внедрения аспектов в основную программу может быть динамическим (JBoss АОР [5], Spring.NET [6|), в процессе загрузки приложения (Weave.NET [7]) или статическим (AspectJ, ССС for .NET [81, Aspect.NET). В первом случае виртуальная машина при выполнении некоторых условий во время выполнения программы запускает действия аспекта. При этом накладные расходы на мониторинг потока выполнения могут значительно ухудшить эффективность. Кроме того, множество отслеживаемых таким образом точек внедрения довольно ограничено, и становится невозможным отследить некоторые события. например, доступ и модификацию некоторого поля. Второй случай аналогичен первому за исключением того, что действия аспекта вставляются лишь один раз при загрузке приложения. Это позволяет повысить производительность результирующей сборки в ряде случаев, однако не избавляет от присущих динамическому внедрению ограничений. В случае же статического внедрения аспекты и основная программа сливаются вместе в сборки на уровне байт-кода для Java или MSIL для .NET. Здесь накладные расходы на вызовы действий аспектов практически отсутствуют, и наблюдается предсказуемость поведения результирующего кода, поскольку взаимодействие с аспектами зафиксировано до момента исполнения программы. Стоит отметить также такие преимущества, как удобный и нагляд-
ный доступ к результатам (обусловленное возможностью декомпилировать полученную бинарную сборку и исследовать все возможные нюансы поведения программы), а также полную совместимость с существующими инструментами для работы с бинарными сборками платформы .NET.
Наконец, немаловажная причина, которая до сих пор сдерживает применение ас-пектно-ориентированных инструментов для платформы .NET. — это полное отсутствие графического интерфейса для таких систем. Таким образом, теряется возможность визуальной отладки, представления и разработки аспектов. В свою очередь, инструменты АОП для Java используют подобные сервисы, предоставляемые свободно распространяемой средой разработки Eclipse [9]. На текущий момент среди инструментов АОП для платформы .NET Aspect.NET обладает наиболее полнофункциональным графическим интерфейсом. Кроме того, в нем реализована система ручной фильтрации обнаруженных точек внедрения. На данный момент автору статьи неизвестна какая-либо другая среда разработки АОП программ с похожей возможностью фильтрации.
Теоретические основы технологии Aspect.NET. Основное предназначение Aspect.NET — предоставить программисту возможность применять АОП в своей повседневной работе с платформой .NET и обеспечить максимально легкую интеграцию с существующими процессами разработки ПО. Кроме того, в перспективе должна поддерживаться работа со всеми .NET совместимыми языками.
Рассмотрим основные концепции, на которых базируется АОП-разработка в системе Aspect.NET [3]. Спецификацией аспекта является единица компиляции, или класс, состоящий из модулей аспекта (внутренние закрытые поля или методы), действий аспекта и правил их применения. Согласно этим правилам действия аспекта могут быть использованы в конкретных точках внедрения целевого приложения, местонахождение которых задается с помощью текстовой маски или регулярного выражения. Например, правило "%before %call *OrderSystem.StartOrderProcessing" означает:
вставить действие аспекта перед вызовом метода StartOrderProcessing класса OrderSystem. Место внедрения действия аспекта относительно целевого метода может быть задано следующим образом: "вызвать перед" (%before), "вставить вместо" (%instead), "вызвать после" (%after). Целевым называется метод в коде бизнес-логики, который является точкой внедрения для действия аспекта. В свою очередь, целевым объектом назовем объект, у которого вызывается целевой метод. Вызывая действия аспекта в определенных точках, целевое приложение реализует функциональность "сквозных" компонент.
Определение аспекта записывается на специальном метаязыке Aspect.NET ML, что позволяет сделать описание независимым от языка реализации аспекта. Инструментальная система Aspect.NET конвертирует эти аннотации на метаязыке в специально разработанные пользовательские атрибуты, которые затем сохраняются в метаданных целевой сборки. Этот важный принцип позволяет избежать необходимости добавления поддержки АОП в какой-либо .NET совместимый язык (С#, VB.NET и пр.) через введение дополнительных языковых конструкций.
Для иллюстрации описанной концепции приведем пример простого аспекта, на метаязыке Aspect.NET ML (здесь и далее по тексту в качестве языка реализации аспектов используется С#):
%aspect Politeness { %modules //Модули
public static Say Hello () {
System.Console. WriteLine(" Hello");
I
public static SayBye () {
System.Console. WriteLine(" Bve");
}
%rules //Правила %before %call * %action public static void SayHelloAction { Politeness.SayHelloO)
%after %call *%action public static void
SayByeAction { Politeness.SavBye()| >
Усовершенствованная технология Aspect.NET.
Для решения поставленных задач была про-
228
анализирована история развития системы разработки АОП программ AspectJ [2), поскольку ее технологии стали стандартом де-факто в мире АОП. В итоге функциональность Aspect.NET была расширена следующими возможностями, особенно важными для практического применения.
Расширенное по сравнению с прежней спецификацией описание точек внедрения и возможность более точно задавать их местоположение в целевом коде. Aspect.NET поддерживает следующие спецификаторы для задания точек внедрения:
регулярное выражение по полной сигнатуре метода. Например, правило может иметь вид
%instead %call static public void*. MyType.*Method(float, string, ..)
ограничение области вызова целевого метода. Например, если его вызов встречается внутри любого метода определенного класса М (ключевое слово %within{M)) или внутри определенного метода с маской Т (ключевое слово %withincode ( Т))\
возможность выбора ("||"), объединения ("&&") или отрицания ("!") нескольких спецификаторов в одном условии, например
%before %call *Get* && %within (*МуТуре) && %!withincode(*.ctor)
% be Го re %call *Set* && %within(*MyType) && %!withincode(*.ctor)
Реализация доступа действия аспекта к динамическому и статическому контексту своей точки внедрения. Динамический контекст точки внедрения аспекта — это объекты, которые связаны с потоком выполнения соответствующего целевого метода. В свою очередь, статическим контекстом называется информация в виде метаданных и строк, связанная с местом выполнения целевого метода. Иначе говоря, динамический и статический контексты отличаются тем, что в первом случае контекст меняется от вызова к вызову действия аспекта в данной точке внедрения. Возможность работы с контекстом — необходимое требование к АОП-среде, по-
-
скольку это основной способ взаимодействия аспекта с бизнес-логикой. Кроме того, доступ к динамическому контексту должен быть максимально наглядным и простым, чтобы снизить опасность непреднамеренного побочного влияния, которое оказывает аспект на результирующую программу. Далее приведены идентификаторы метаязыка Aspect.NET ML, предоставляющие внутри действия аспекта доступ к контексту его точки внедрения.
%TargetObject — это ссылка типа System.Object на объект в целевой программе, к которому применяется целевой метод в точке присоединения. Например, если вызов целевого метода в точке присоединения имеет вид р.М(), то %TargetObject обозначает ссылку на объект р. Если целевой метод статический, %TargetObject равно null.
%This — это ссылка типа System.Object на объект в целевой программе, внутри метода которого оказалось вставлено данное действие аспекта. Например, если в верхнем примере р.М() содержится внутри метода объекта X, то X является ссылкой %This для действия аспекта, применяемого к р.М().
%RetValue — это ссылка типа System.Object на результат, возвращаемый целевым методом. Если результат является простым типом, то происходит его упаковка. Для всех действий кроме %after имеет значение null.
%WithinType — это ссылка типа System. Туре на определение класса, в котором расположен вызов целевого метода.
%WithinMethod — это ссылка типа System. Reflection. Method Base на объект, представляющий метод, в котором расположен вызов целевого метода.
%SourceFilePath — это строка, представляющая путь к целевому файлу исходного кода, в котором расположен вызов целевого метода.
%SourceFileLine — это строка, представляющая номер строчки в исходном коде файла, где расположен вызов целевого метода.
Передача значений аргументов целевых методов в действия аспекта. Большинство
задач, которые могут быть решены с помощью АОП, требуют использования в действиях аспекта значений аргументов целевых методов. В самом деле, стандартными средствами .NET можно получить только сигнатуру исполняемого в данный момент метода: тип результата, его текстовое имя и список параметров. В то же время, доступ к значениям аргументов необходим для систем протоколирования, кэширования, авторизации и пр. В Aspect.NET значения аргументов целевых методов неявно передаются средой в действия аспекта, если это определено декларацией args в правиле внедрения. Декларация я/т?л(..) обозначает, что все аргументы целевого метода будут переданы в соответствующие аргументы действия аспекта, при этом в сигнатуре действия должен быть объявлен в точности тот же набор аргументов. Приведем пример из области авторизации, иллюстрирующий работу с аргументами:
Код бизнес-логики:
public class BankAccount { float account;
public float witlidraw(float amount){/*...*/} I
Код аспекта:
%aspect Bank Management { %instead %cali *BankAccount.withdraw(float) && args(..) %action
public static float WithdrawWrapper(float amount) {
BankAccount acc = (BankAccount) %TargetObject;
if (isLicenceValid(%TargetMemberlnfo.Name)) return acc.withdraw(amount):
Consolé.WriteLine("Witlidraw operation is not allowed");
return acc.Balance; >
}
Данное действие аспекта определяет "заглушку", которая будет вставлена вместо целевого метода withdraw. Внутри
действия происходит проверка прав на выполнение операции withdraw и вызывается исходная операция с тем же набором параметров, если авторизация прошла успешно. Доступ к целевому объекту и имени операции осуществляется через свойства % Target Object и % TargetMemberInfo контекста точки внедрения.
Решающее значение для облегчения интеграции процесса АОП-разработки в повседневную деятельность разработчиков ПО. по мнению автора статьи, имеют также следующие обстоятельства:
Использование привычной среды разработки. Система Aspect.NET реализована как надстройка над средой разработки программного обеспечения Microsoft Visual Studio |4| и состоит из двух главных компонентов: редактора аспектов и подсистемы внедрения аспектов в целевой код (компоновщик). Редактор аспектов обеспечивает конечное взаимодействие с пользователем, в то время как подсистема внедрения аспектов организует выполнение пользовательских действий над аспектами, бизнес-логикой и предоставляет редактору аспектов вспомогательные сервисы. В задачу автора статьи входила также работа над данной подсистемой внедрения аспектов.
Отсутствие необходимости изучать новый язык. С самого начала В.О. Сафоновым [3] было предложено, чтобы спецификация на Aspect.NET ML автоматически конвертировалась в синтаксически корректную единицу компиляции, а все аспект-ные аннотации хранились бы в пользовательских атрибутах. Появилась возможность описывать аспекты непосредственно на одном из языков платформы .NET, и потребовалось разработать соответствующую спецификацию. Автором статьи предложены следующие правила, которые легли в основу последней версии Aspect.NET: аспект является классом, который необходимо унаследовать от класса Aspect; действия аспекта являются статическими методами, которые получают доступ к контексту точки внедрения с помощью вызова свойств Aspect; правила внедрения записываются в пользовательском атрибуте AspectAction для каждого действия; действия иди класс ас-
пекта могут быть дополнительно аннотированы атрибутом Aspect Description, содержащем текстовое описание. Таким образом, пример аспекта BankManagement можно переписать для языка С# следующим образом:
public class BankManagement: Aspect { [AspectDocument("npoBepKa текущей лицензии и авторизация")]
|AspectAction("%instead %cal! *BankAccount. withdraw(float) && args(..)")|
public static float WithdrawWrapper(float amount) {
BankAccount acc = ( BankAccount) base. TargetObject;
if (isLicenceValid(base.TaigetMemberlnfo.Name)) return acc.withdraw(amount); Console.WriteLineC'Withdraw opération is not allowed");
return acc.Balance; >
}
Фильтрация обнаруженных точек внедрения. Местонахождение точек внедрения для действия аспекта задается в правилах внедрения. Однако эти правила определяют всю совокупность точек внедрения, удовлетворяющих их условиям. Если пользователю необходимо применить действие лишь к некоторым найденным точкам, то ему придется усложнить правила внедрения, чтобы исключить ненужные точки внедрения. Такая избыточная сложность затрудняет попытки разобраться в функциональности аспекта. В Aspect.NET редактор аспектов с помощью компоновщика дает возможность пользователю выбрать нужные точки внедрения из общего списка найденных.
Возможность исследовать структуру итоговой программы с внедренными аспектами. Кроме уже упоминавшейся возможности декомпиляции результирующей сборки компоновщик предоставляет редактору аспектов информацию о местонахождении точек внедрения, найденных в исходной бизнес-логике. По этой информации редактор аспектов делает визуализацию вплетения аспектов в бизнес-логику и осуществляет навигацию по точкам внедрения в исходном тексте пользователя.
Привлекательные возможности АОП по изменению готовых программных продуктов, исправлению и увеличению их функциональности способствуют появлению специализированных утилит, предназначенных для добавления новых свойств исходным системам. Такие инструменты помогали бы пользователю определять нужные точки внедрения и вставлять туда действия заложенных в них аспектов. Список применения подобных утилит включает в себя распараллеливание программ, устранение многопоточных блокировок [10], устранение дефектов, тестирование и т. д. Например. М. Грачев в своей работе [II] реализовал на базе Aspect.NET систему поддержки протоколирования, схожую с log4j [12], но лишенную ее недостатков как объектно-ориентированного решения. Применение данного инструмента позволило существенно сократить объем исходного кода и свести учет изменений в требованиях протоколирования к нескольким щелчкам мыши. Рассмотрим детальный сценарий взаимодействия стороннего инструмента АОП с компоновщиком:
пользователь загружает в инструмент АОП исходный код бизнес-логики. Исходный код затем компилируется инструментом АОП в бинарную .NET сборку, внедрения. Создается аспектная сборка;
для того чтобы получить полный список точек внедрения выбранного аспекта в пределах целевой сборки, инструмент АОП вызывает компоновщик, который снабжается отладочной информацией (в виде .pdb файла) для поддержания взаимнооднозначного соответствия между расположением инструкций целевой сборки и целевого исходного текста;
компоновщик формирует и возвращает обратно инструменту АОП XML-файл с информацией о координатах точек внедрения на уровнях целевой сборки и исходного текста;
инструмент АОП отображает найденные альтернативы применения аспектов в исходном коде пользователя и приглашает пользователя подтвердить или отфильтровать список точек для применения аспектов;
на основе спецификаций из данного списка аспектная и целевая сборки интегрируются в новую результирующую сборку, которая и будет представлять собой итоговый результат применения аспектов.
Итак, на данный момент в системе Aspect.NET автором статьи реализованы все описанные в статье возможности. Спецификация метаязыка определения аспектов Aspect.NET ML расширена для решения большинства задач, типичных для АОП. Специальный конвертер трансформирует определение аспекта на Aspect.NET ML в определение, составленное на пользовательских атрибутах, что обеспечивает совместимость АОП-разработки с привычным инструментарием .NET программиста. Компоновщик аспектов статически интегрирует аспекты и бизнес-логику на уровне MSIL сборок. Такой подход позволил добиться производительности результирующего приложения, сравнимой с добавлением кода вызовов аспектов вручную [10]. С другой стороны, статическое внедрение обеспечивает предсказуемость поведения результирующей программы и открывает возможность для анализа полученного кода. Работа компоновщика ведется в два этапа: сканирование точек внедрения и собственно внедрение аспектов. Этот механизм дает возможность фильтрации обнаруженных точек внедрения и применения Aspect.NET в сторонних утилитах.
Aspect.NET имеет графический интерфейс (разработан М. Грачевым) и поддерживает как работу с MS Visual Studio, так и с SSCLI Rotor [13] (реализовано Р. Му-хановым). Произведено документирование системы и составлены содержательные примеры [14—17]. Система доказала свою эффективность при апробации в областях создания безопасного программного обеспечения [10| и протоколирования [II]. Дистрибутив Aspect.NET доступен через сайт Microsoft Academic Alliance [14]. Полученные результаты представлены на научных конференциях и опубликованы в международных и отечественных изданиях.
СПИСОК ЛИТЕРАТУРЫ
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://nisdn.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).
