Разработка и реализация пользовательского интерфейса аспектно-ориентированного программирования

За долгие годы существования и развития методологий программирования исследователями и практиками было создано значительное число различных подходов к созданию программного обеспечения (ПО). Без сомнения, наиболее признанным по праву считается объектно-ориентированный подход (ООП) [9]. За последние десятилетия он практически монопольно укоренился в сфере разработки ПО и является стандартом. Объектно-ориентированный подход решил огромное число проблем, существовавших в его предшественнике — процедурном подходе. Разбиение элементов предметной области на классы позволило многократно упростить и структурировать исходный код программ. Однако средствами ООП проблема структурированности все же не решается в лучшем виде. Всегда остается функциональность в рамках метода, класса или целых компонент, не поддающаяся вынесению и' подходящей локализации. Применяя, например, use-case анализ [11], можно вынести функциональность, решающую не более одной бизнес-задачи, из одного класса во множество элементарных классов, четко разграниченных с точки зрения выполняемых ими действий. Однако фрагменты исходного кода, обеспечивающие взаимодействие этого множества классов, все равно сохранятся и, более того, будут рассредоточены по исходному коду программы, ухудшая тем самым структурированность приложения и возможность его дальнейшей поддержки. Даже относительно удачное детальное проектирование модулей ПО практически не может решить эту задачу в рамках одной лишь ООП-методологии.

Аспектно-ориентированный подход к разработке ПО (другой вариант — аспектно-ориентированное программирование, АОП) [12, 13, 10] является технологией для решения широкого круга задач, позволяющей уменьшить сложность разработки и сопровождения программных продуктов.

Аспектно-ориентированный подход позволяет вынести сквозную функциональность (cross-cutting concerns) [12] — фрагменты, рассредоточенные по коду программы, отвечающие за реализацию некоторой функциональности, — из модулей программы, упрощая тем самым структуру исходного кода.

Вот типичные виды сквозной функциональности [10]:

• безопасность (security) — аутентификация пользователей и программавторизация (проверка полномочий для выполнения тех или иных действий) — криптографические операции над данными с целью обеспечения их конфиденциальности и т. д.;

• надежность (reliability) — проверка инвариантов в классах, а также выполнения преди постусловий, обработка ошибок и т. д.;

• безопасность мпогопоточного выполнения кода (multi-threaded safety)1 — синхронизация по ресурсам или по событиям, выделение критических участков кода, взаимное исключение доступа к ним и др.;

• протоколирование и профилирование работы программы (logging and profiling) — трассировка начала и окончания выполнения каждой функции (каждого метода), вывод их аргументов и результатов, сбор и вывод статистической информации об исполнении различных фрагментов программы и т. д.

Более сложным примером является расширение компилятора путем реализации некоторых новых языковых конструкций, например, новых видов операторов. Очевидно, все фазы компилятора — лексический анализ, синтаксический анализ, семантический анализ, оптимизация и генерация кода — должны быть обновлены для этого. Это означает, что, помимо добавления набора новых модулей в существующий код компилятора, необходимо будет внедрить множество рассредоточенных фрагментов кода объявлений данных, функций, вызовов методов — чтобы связать воедино новые модули компилятора с уже существующими.

Теоретические основы АОП развиты множеством исследователей [11, 12, 36, 38], однако до сих пор не существует устоявшегося практического подхода, и зачастую даже базовые концепции АОП интерпретируются и используются разными авторами по-разному. По сей день не появилось инструментов, которые можно было бы легко интегрировать в существующие среды разработки ПО. Единственное исключение составляет система AspectJ [19, 39, 57] и ее расширение AspectJ Development Tools for Eclipse [63] для Java-платформы. Подобные средства для других платформ позволили бы создателям ПО использовать потенциал АОП в своих разработках, создавая более организованный, читаемый и сопровождаемый программный код.

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

Проект Aspect.NET разрабатывается группой исследователей математико-механического факультета под руководством и при непосредственном участии профессора Владимира Олеговича Сафонова с 2002 года. Цель этого проекта — создать современный АОП-инструмент на базе платформы Microsoft .NET [17], являющейся широко используемой многоязыковой платформой для разработки ПО. Кратко перечислим основные задачи проекта Aspect.NET.

• Создание полнофункционального инструментария для поддержки АОП на платформе .NET.

• Вклад в распространение методологии АОП в сообществе .NET.

• Создание базы для дальнейших исследований и разработок в области АОП.

Цели и задачи.

Данная диссертация выполнена в рамках проекта Aspect.NET. В ней исследуются пользовательские интерфейсы в существующих АОП-инструментариях, предлагается ряд новых методов реализации пользовательского интерфейса АОП и описывается выполненная автором реализация предложенных методов.

Цели работы следующие.

1. Разработка методов реализации пользовательского интерфейса для инструментов АОП и их интеграции в современные среды для разработки программ.

2. Реализация пользовательского интерфейса Aspect.NET Framework на основе разработанных методов.

3. Реализация расширения Aspect.NET Framework для неявного применения АОП при решении некоторых типичных задач разработки и сопровождения программ.

4. Использование подсистемы Aspect.NET Framework в рамках системы Aspect.NET при разработке программного продукта для решения ряда задач.

Причины возникновения проблемы и ее актуальность.

Усложнение программных систем — глобальная современная проблема, которая требует постоянного внимания и изучения. АОП-методология призвана снизить время, стоимость и сложность разработки современного ПО путем выделения определенных частей — аспектов, отвечающих за ту или иную функциональность, реализация которой рассредоточена по коду программы.

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

Большинство инструментов для поддержки АОП разработано для Java-платформы (так или иначе все они связаны с технологией AspectJ). Авторы проекта Aspect.NET считают, что важным вкладом в развитие АОП могла бы послужить полноценная реализация этой методологии для современной и популярной платформы разработки — .NET. Реализация соответствующей среды разработки способна сыграть важную роль в привлечении разработчиков к использованию АОП-методологии на платформе .NET. Руководитель проекта Aspect.NET профессор В. О. Сафонов по-новому интерпретировал идеи Г. Кикжалеса, применяя их к широким возможностям платформы .NET.

Аспекты в системе Aspect.NET определяются при помощи описания классов со специальными аннотациями на метаязыке Aspect.NET ML [10, 16], независимого от выбранного языка .NET платформы. Одна из компонент Aspect.NET ответственна за конвертирование спецификаций на Aspect.NET ML-аннотаций в пользовательские атрибуты, предназначенные для использования другими компонентами Aspect.NET. Таким образом, информация об аспектах, включающая правила внедрения, хранится в виде пользовательских атрибутов в метаданных сборки. Такой подход обеспечивает независимость спецификации аспектов от их реализации.

Приведем пример описания аспекта в Aspect.NET. Аспект «Test» имеет одно действие «TestWriteAction», выводящее на консоль строку «test» перед вызовом любого метода с именем, начинающимся на «Write»: aspect Test public class Test rules before %call Write* public static void TestWriteAction ().

Console.WriteLine («test»);

Компоновщик Aspecl.NET реализован на основе инструментария построения оптимизирующих компиляторов Microsoft Phoenix RDK [28]. В частности, были использованы высокоуровневые сервисы и библиотеки (Phoenix API) для анализа, создания и модификации .NET-сборок. Компания Microsoft считает технологию Phoenix перспективной, что во многом повлияло на широту предоставленной функциональности и высокую производительность этой библиотеки.

Поиск точек внедрения и внедрение функциональности аспекта в Aspect.NET производятся статически, благодаря чему достигается максимальная производительность по сравнению с динамическим внедрением (Aspect#) и внедрением во время выполнения загрузки сборки (Weave.NET). Компоновщик работает в два прохода: поиск точек внедрения и собственно внедрение. Между двумя проходами пользователю предоставляется удобная и новая, по сравнению с другими инструментариями, возможность просмотреть найденные точки внедрения и отключить какие-либо нежелательные из них. Она достигается через реализованный нами графический интерфейс системы Aspect.NET Framework путем отображения иерархии найденных точек по модулям, классам, методам и параллельного отображения исходного кода целевого модуля (при условии наличия отладочной информации модуля).

Aspect.NET Framework реализован на основе Microsoft Visual Studio SDK [29] — наиболее функционально богатого API, который позволяет практически неограниченно настраивать и модернизировать среду разработки Microsoft Visual Studio: модифицировать обработчики любых событий среды разработки, преобразовывать окна, панели и мастера. Microsoft Visual Studio SDK дает возможность контролировать подсветку исходного кода и анализ языков программирования, разрабатывать и модифицировать отладчики для различных языков.

Процессы поиска и интеграции точек внедрения реализованы как задачи MSBuild [30] и запускаются незаметно для разработчика.

Заключение

.

В ходе выполнения работы достигнуты следующие результаты:

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

2. Реализована и интегрирована в Visual Studio 2008 подсистема Aspect.NET Framework, являющаяся пользовательским интерфейсом системы Aspect.NET.

3. Реализован инструмент Aspect. log4net, обеспечивающий неявное использование АОП для протоколирования.

4. Подсистема Aspect.NET Framework в составе системы Aspect.NET успешно использована для протоколирования и проектирования с преди постусловиями в крупном программном продукте объемом более 40 человеко-лет.

Все полученные результаты являются новыми.

Предложенный способ реализации АОП интерфейса, а именно, интеграция в наиболее распространенную среду разработки Microsoft Visual Studio 2008, позволил сделать использование системы Aspect .NET максимально комфортным для .NET-программистов. Обусловлено это тем, что нужды программистов полностью обеспечиваются данной средой разработки, а созданный нами Aspect.NET Framework органично расширяет возможности VisualStudio и прозрачно внедряется в процесс сборки проектов MSBuild. Ввиду того, что для платформы .NET не существует аналогов пользовательского интерфейса для систем АОП, за базовый образец при создании нами был выбран пользовательский интерфейс инструмента AspectJ для Java-платформы под названием AspectJ Development Tools.

Созданный нами пользовательский интерфейс собрал в себе всю функциональность, реализованную командой Грегора Кикжалеса в AspectJ Development Tools. Такую как, просмотр содержимого аспектов, раскрасчик аспектов, просмотр влияния аспекта на уровне текста исходного кода. Однако помимо этого была добавлена возможность управляемого пользователем внедрения аспектов с использованием графического пользовательского интерфейса.

К сожалению, реализованную соискателем надстройку Aspect. log4nct трудно сравнивать с единственным аналогом — расширением АОП-инструментария PostSharp под названием Log4PostSharp, появившимся позднее. Причиной тому является то, что в Log4PostSharp жестко зафиксировано множество правил внедрения аспекта с протоколирующей функциональностью, отсутствует графический пользовательский интерфейс и интеграция с процессом сборки проектов. Стоит заметить, что множество шаблонов правил в Aspect. log4net можно с легкостью изменять, создавая специфичные мастера-расширения для решения разнообразных прикладных задач за счёт неявного применения АОП.

Апробация Aspect.NET Framework как части Aspect.NET на крупных программных продуктах позволила объективно оценить эффективность созданного нами расширения и методологии АОП как таковой. В частности, нами была достигнута возможность уменьшения исходного кода крупного программного продукта на 11% за счёт вынесения проверки значений параметров методов и протоколирующей функциональности в аспекты, а применение Aspect. log4net позволило существенно снизить временные издержки, связанные с использованием АОП-инструментария.

Документация, примеры и дистрибутив системы доступны на сайте Microsoft Faculty Connection [72]. Результаты проекта были представлены на научных конференциях, опубликованы в международных и отечественных изданиях. Реализованный инструментарий был высоко оценен многими пользователями.

По теме диссертации опубликованы работы [1−4] и [8]. Статья [1] опубликована в журнале, входящем в перечень ВАК.

На данный момент нам видится ряд следующих перспективных задач дальнейшего развития темы.

Подсказки и контекстная помощь. Планируется добавить в Visual Studio контекстную помощь, которая, к примеру, будет раскрывать пользователю особенности языка Aspect.NET ML, а также помечать ошибочные предложения в редакторе исходного кода аспекта. Также пользу принесет и поддержка Visual Studio IntelliSense для Aspect.NET ML, то есть возможности подсказки возможных вариантов завершения набираемого пользователем Aspect.NET ML предложения. В AJDT for Eclipse подобная функциональность уже существует.

Кроме того в будущем планируется расширить панель редактора файлов Microsoft Visual Studio элементами управления на полях напротив строк, удовлетворяющих правилам аспектов. Эти элементы управления позволят еще более наглядно помечать указанные строки, а также более эффективно перемещаться от точек внедрения к правилам, породившим эти точки и наоборот.

Анализ и преобразование правил. Нам видится перспективным добавление к Aspect.NET Framework логики для автоматического упрощения правил либо приведения их удобочитаемому виду. Например, правило вида «(%after %call *) || (%after %call MyMethod)» очевидно, стоит привести к эквивалентному правилу «%after %call *».

В случае же если аспект разрабатывается специально для конкретной программы, возможность преобразования его правил с учетом структуры и особенностей результирующей программы также может оказаться востребованной. Например, если в программе есть всего две функции, с именами, начинающимися на «MyMethod»: «MyMethodl» и «MyMcthod2», то правило вида «(%after %call MyMethodl) || (%after %call MyMethod2)» можно было бы свернуть в более короткое «(%after %call MyMethod ([l, 2]{ 1}))» либо проделать обратную операцию — развернуть правило «(%after %call MyMethod*)» в «(%after %call MyMethodl) || (%after %call MyMethod2)». После такой замены к добавленному в код программы методу с именем, например, «MyMethod3» аспект применяться не будет.

Читатель правил. Аналогичная функциональность была описана в работе [54]. Читатель правил подразумевает возможность создания автоматического пояснения к правилу на адекватном человеческом языке. К примеру, правило вида «%call %before (private *.set*(., int))>> можно пояснить следующей фразой: «before a call made to a private method with name starting with «set» defined on any type, and which last argument of an integer type». Подобная функциональность могла бы быть полезна для автоматического документирования исходного кода.

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

Рефакторинг. В Visual Studio, начиная с версии 2005, появились встроенные возможности рефакторинга исходного кода программ, позволяющие осуществлять такие действия, как автоматическое переименование элементов программы, вычленение интерфейсов из классов, вынесение блоков кода в отдельные методы и ряд других полезных функций. Для более широкой поддержки Aspect.NET к этим функциям можно было бы добавить такие, как «преобразовать фрагмент кода программы в действие аспекта» и «выделить объявление данных программы во внедряемое объявление типа (inter-type declaration)». Поддержка хотя бы этих двух функций фактически позволяла бы говорить о поддержке базового механизма аспектизатора [8].