CC BY
19
Таблица 2
Результаты оптимизации наборов трасс в телекоммуникационных проектах
Количество базовых протоколов в проекте Количество требований в проекте Количество полученных трасс, покрывающих все требования Оптимальный набор трасс
60 107 110 46
124 148 30 26
497 57 223 195
значительно сэкономить время и трудоемкость анализа формальных моделей разрабатываемых систем, а также разработку тестов, проверяющих
их функциональность. Преимущества описанных методов были доказаны в ходе их применения в ряде крупных телекоммуникационных проектов.
СПИСОК ЛИТЕРАТУРЫ
1. Boehm, B. Software Risk Management: Principles and Practices. [Текст]/В. Boehm//IEEE Computer Society Press.
2. Booch, Gr. Object-Oriented Analysis and Design with Applications. [Текст]/Gr. Booch//Addison-Wesley Professional; 2 ed.-Oct. 10, 1993.
3. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст]/А.А. Летичевский, Ю.В. Капитонова, A.A. Летичевский (мл.) [и др.]//Ки-бернетика и системный анализ.-2005.-№ 4.-С. 3-21.
4. Hoare, C.A.R. Communicating Sequential Processes. [TeKCT]/C.A.R. -Hoare Prentice Hall. London, 1985.
5. Letichevsky, A. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications. [TeKCT]/A. Letichevsky, J. Kapitonova, A. Letichevsky Jr. [et al.]//Proc of ISSRE04 Workshop on Integrated-reliability with Telecommunications and UML Languages (ISSRE04:WTTUL).-02 Nov 2004. -IRISA Rennes France.
УДК 004.415
P.C. Муханов, В.О. Сафонов
реализация и практическое применение системы
aspect.net для академической версии .net
На сегодняшний день наиболее распространена методология объектно-ориентированного программирования (ООП). Менеджеры большинства новых проектов выбирают именно эту концепцию. Несмотря на эффективность подхода ООП, существуют проблемы, для которых нужна более совершенная методология. В современном мире промышленное производство программного обеспечения достигло таких масштабов и такой сложности, что с каждым днем все труднее и дороже обходятся его разработка, поддержка, отладка, добавление новой функциональности, докумен-
тирование, расширение и развитие. Сложность, присущая большинству современных программных систем, обусловлена четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; трудностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем [1].
Как в свое время на смену процедурному подходу пришло объектно-ориентированное про-
граммирование (ООП), так и сейчас на смену объектно-ориентированной концепции постепенно приходит совершенно новая парадигма - аспектно-ориентированное программирование (АОП). АОП является развитием процедурного и объектно-ориентированного программирования. Данная методология призвана снизить время, стоимость и сложность разработки современного программного обеспечения (ПО). Следует отметить, что концепция АОП не заменяет подход ООП, а органично дополняет его [2]. Появление новых методологий всегда способствовало развитию науки и индустрии программного обеспечения, т. к. любая новая концепция, любой новый подход - это решение проблем, являющихся предпосылками для ее появления. Сложность программных систем -ключевая проблема всей индустрии. Поэтому любая новая методология для решения этой задачи, в т. ч. АОП, является актуальным направлением научных исследований.
Суть концепции АОП заключается в том, что программная система рассматривается как совокупность различных компонент, отвечающих за ту или иную функциональность. Некоторую функциональность можно реализовать путем создания некоего модуля или нескольких модулей. Под «модулем» понимается некая четко выраженная структурная единица программы - процедура, функция, метод, класс, структура данных, пакет. Но есть еще такое понятие, как сквозная функциональность (crosscutting concerns), которую невозможно эффективно реализовать вышеописанным образом, ее нельзя выделить в отдельные сущности, т. к. фрагменты ее реализации рассредоточены по коду всей программной системы [3]. Реализация подобной сквозной функциональности без использования методологии АОП приведет к непонятному, рассредоточенному и запутанному коду, в котором абсолютно не связанные функциональности будут реализованы в одном модуле, повысит вероятность появления ошибок и некорректной работы системы в целом, что увеличит время и расходы на разработку. АОП предлагает сквозную функциональность выделять в специализированные модули - аспекты и реализовывать отдельно от бизнес-логики.
Статья описывает проект, поддержанный Microsoft Research, - разработку и реализацию AspectRotor 2.2, систему аспектно-ориентированного программирования для платформы SSCLI/Rotor 2.0 [9] на базе техноло-
гии Aspect.NET [2, 3]. В настоящее время, в силу ряда причин, описанных далее, не существует доступного инструментария АОП-разработки для shared-source платформы Rotor, несмотря на растущую популярность АОП-подхода к разработке ПО. Таким образом, данная работа имеет как теоретическую часть - исследование существующих подходов к разработке программного обеспечения с использованием парадигмы АОП, так и практическую - создание системы AspectRotor.
Понятие аспектно-ориентированного программирования (АОП). Основные понятия аспектно-ориентированного программирования: сквозная функциональность (cross-cutting concern), аспект (aspect), внедрение (weaving), набор правил внедрения (pointcut - a set of weaving rules for an aspect), точки присоединения (join points).
Аспект - это некоторый модуль, единица компиляции, содержащая в себе реализацию сквозной функциональности на некотором языке программирования. Он состоит из модулей (modules) (методы или функции), данных (data), действий (actions), правил внедрения (weaving rules). Каждое действие применяется (например, записывается в бинарный файл кода результирующей целевой программы), согласно правилам внедрения в конкретные точки присоединения (join points) целевого приложения (target application). Такой набор правил может быть определен отдельно от конкретного аспекта в качестве модуля правил, чтобы обеспечить возможность внедрения нескольких аспектов, согласно одинаковому набору правил. Посредством вызова действий аспекта целевое приложение использует сквозную функциональность. Таким образом, аспект инкапсулирует в себе определенную функциональность, которая никоим образом не зависит от контекста, в котором действия аспекта будут выполняться. На самом деле многие инженеры-разработчики используют аспекты в своей повседневной работе, но это происходит неявно. В результате отладка и поддержка программной системы обходятся очень дорого. Одна из причин - отсутствие функциональности АОП в языках программирования и используемых инструментах. Также существует проблема переиспользования аспектов. Не только модули, но и аспекты можно вновь использовать во многих приложениях. С глобальной точки зрения само понятие аспекта никоим образом не связано ни с одним языком программирования, ни с какой парадигмой, методологией. Аспект - это
общее фундаментальное понятие. В терминах инженерии знаний аспект можно рассматривать как гибридную коллекцию знаний [6]. Таким образом, в идеальном приложении аспект должен быть реализован в максимально общей форме, чтобы его можно было легко переиспользовать, без привязки к конкретному языку программирования.
Под внедрением аспекта понимается интеграция кода аспекта в код целевого приложения. Набор правил внедрения - это определенный набор правил, согласно которым происходит внедрение необходимого кода аспекта в соответствующее место в коде целевого приложения.
Точки присоединения (join points) - это конкретные точки в целевом приложении, в которых вызываются действия аспектов. Они определяются системой на основе правил внедрения (weaving conditions), определенных как часть правил внедрения аспекта. Эти условия внедрения содержат указания для системы АОП относительно точек вызова действия аспектов: до (before), после (after), вместо (instead); контекст вызова (вызываемый метод, присваивание или использование поля), а также групповые символы (wildcards) для определения контекста вызова. Процесс внедрения аспекта состоит из трех фаз: поиска точек присоединения в целевом приложении, их фильтрации, а затем выполнения действий аспекта в выбранных точках.
Обзор существующих технологий. На данный момент большинство инструментов для разработки программного обеспечения с использованием парадигмы АОП ориентированы на технологию Java, что сильно ограничивает их гибкость и применимость. Microsoft.NET - среда, популярность которой среди разработчиков растет, что является предпосылкой разработки инструментов АОП для данной платформы. Подобные решения для платформы Microsoft.NET (Aspect#, Loom.NET, Weave.NET, R#, Spring.NET и т. д.) пока находятся на стадии академических научно-исследовательских экспериментов. В целом развитие всей методологии АОП сейчас находится на этапе перехода от научно-исследовательских экспериментов к широкому промышленному использованию.
Некоторые решения АОП, существующие для Microsoft.NET, просто расширяют какой-либо конкретный язык программирования .NET средствами АОП. Это является серьезным огра-
ничением, т. к. невозможно использовать подобные инструменты для других языков платформы .NET. Также при такой одноязычности невозможно применять существующее огромное количество утилит, упрощающих разработку для данной платформы. Другие недостатки - низкая производительность результирующих программ и недостаток инструментария для просмотра результатов внедрения без декомпиляции.
В настоящее время применяются различные подходы разработки программных систем с использованием методологии АОП. Рассмотрим их преимущества и недостатки. Динамический подход (runtime weaving) реализован в системе Spring. NET: внедрение происходит во время исполнения программы, т. е. при выполнении некоторых условий вызываются действия аспекта. У этого подхода есть серьезный недостаток - низкая производительность. Расширение существующего языка (AspectJ, Aspect#) приводит к необходимости создания специального компилятора для расширенного языка и его модификации при каждом расширении базового языка. При статическом внедрении на уровне сборок (Aspect.NET) достигается высокая производительность, имеется явная доступность результатов (через средства деком-пиляции) и, благодаря декомпозиции на сквозную функциональность и основную бизнес-логику, код становится более структурированным.
AspectJ - первый и до сих пор наиболее популярный инструмент для разработки программного обеспечения с помощью методологии АОП, ориентированный на Java-технологию. По сути, в нем используется расширенный АОП-конструкциями язык Java. Немалую роль в распространении AspectJ сыграла интеграция с популярными средами разработки, например, JBuilder. Но наиболее развитой надстройкой, также разработанной группой инженеров под руководством Грегора Кикжалеса, является AspectJ Development Tools для интегрированной среды разработки Eclipse. Несмотря на его популярность, AspectJ все еще находится на стадии перехода от исследовательского проекта к коммерческому использованию.
Aspect.NET - инструмент для разработки ПО с использованием методологии АОП, разработанный группой аспирантов под руководством профессора В.О. Сафонова в рамках программы Microsoft Research. Aspect.NET реализован как add-in к популярной интегрированной среде раз-
работки - Microsoft Visual Studio; это означает, что данный инструмент не нужно запускать отдельно, он запускается одновременно с запуском самой среды и интегрирован с ней.
AspectRotor. Основная идея AspectRotor -предоставить пользователям возможность применять АОП при разработке программного обеспечения для академической версии .NET - платформы SSCLI/Rotor. Основные технологии, на которых построена новая версия AspectRotor 2.2:
Phoenix Research Development Kit (RDK) June 2008 [7];
SSCLI (Shared Source Common Language Infrastructure)/Rotor 2.0;
QT SDK [8];
Aspect.NET 2.2.
AspectRotor представляет собой систему аспектно-ориентированного программирования для академической версии .NET - платформы Microsoft Shared Source Common Language Infrastructure (SSCLI), или Rotor, на базе технологии Aspect.NET. В настоящее время не существует доступного инструментария АОП-разработки для shared-source платформы Rotor, несмотря на растущую популярность АОП-подхода к разработке ПО. Причинами являются незавершенность самой платформы, усложняющая адаптацию и применение напрямую технологий, разработанных для коммерческой версии платформы .NET, динамическое внедрение кода, несовместимость форматов отладочной информации, внедрение во время загрузки и т. п. Такое положение приводит к тому, что для среды Rotor приходится заново реализо-вывать весь набор инструментов АОП-разработки. Наряду с отсутствием штатных сервисов построения графического пользовательского интерфейса это многократно усложняет задачу.
Теоретическая часть включает в себя подробное исследование существующих подходов к разработке программного обеспечения с использованием методологии АОП, обзор необходимых технологических и инструментальных средств для разработки в среде Rotor, проектирования кросс-платформного графического интерфейса с помощью библиотеки QT.
Практической частью явилось создание готового продукта для разработки АО программ, причем использование готовых компонентов Aspect. NET, таких, как подсистема внедрения аспектов и конвертеры описаний аспектов из метаязыка, по-
зволило избежать вышеперечисленных трудностей и впервые предложить пользователям мощную среду разработки аспектно-ориентированных программ для Rotor-платформы. Одновременно с этим разработаны средства инсталляции продукта и необходимая документация.
Рассмотрим несколько примеров практического использования - создания в среде AspectRotor аспекта на метаязыке с последующим внедрением в код основной бизнес-логики целевого приложения.
Аспект 1, описанный на метаязыке. Это простой пример профилирующего аспекта, печатающего какие-либо трассировочные данные, что является частой и повседневной задачей практически в любой современной программной системе: %aspect Aspect using System;
using AspectDotNet; {
%modules
public static void Say (String s) { Console. WriteLine(s); }
%rules %before %call * %action
public static void SayHello () {Say(«Hello»); }
%after %call * %action
public static void SayBye () {Say («Bye»); }
}
Аспект 1. После конвертации метаязыка в язык C#:
namespace Aspect { using System; using AspectDotNet;
public class Aspect {
[AspectDef(«Aspect», «module», «»,«»)] public static void Say(String s) { Console. WriteLine(s); }
[AspectDef(«Aspect», «action», «%before %call *»,«»)]
public static void SayHello() {Say(«Hello»); }
[AspectDef(«Aspect», «action», «%after %call *», «»)]
public static void SayBye() { Say («Bye»); }
}
}
Целевое приложение 1, где описана основная бизнес-логика: using System;
class MainApp {
public static void Main() {
HelloFunction();
}
static void HelloFunction() {
Console.WriteLine(«Hello, World!»);
}
}
Целевое приложение 1 выводит на консоль следующие данные: Hello, World!
Результирующее приложение 1 (после применения аспекта), исходный код после декомпиля-ции, например, используя Red Gate .NET Reflector: using System;
class MainApp {
public static void Main() {
Aspect.Aspect.SayHello();
HelloFunction();
Aspect.Aspect.SayBye();
}
static void HelloFunction() {
Aspect.Aspect.SayHello(); Console.WriteLine(«Hello, World!»); Aspect.Aspect.SayBye();
}
}
Результирующее приложение 1 печатает на консоль иные данные: Hello Hello
Hello, World!
Bye
Bye
Таким образом, мы видим, что результирующее приложение изменилось соответствующим об-
разом после применения вышеуказанных действий аспекта. Исходный код при этом никоим образом не изменялся, все трансформации происходят на уровне MSIL посредством инструмента Phoenix.
Целевое приложение 2 представляет собой простейшей пример ситуации, когда необходима более тщательная обработка ошибок:
public class BreakerTester {
public static void Breaker(int n) {
Console.WriteLine(«Breaker call number» + n);
switch (n)
{
case 1: throw new ArgumentException(); case 2: throw new NullReferenceException(); case 3: throw new IndexOutOfRangeExcep-
tion();
default: throw new InvalidOperationExcepti-
on();
}
}
static void Main(string[] args) {
Breaker(l);
Breaker(3);
Breaker(lO);
Console.WriteLine(«Press ENTER to exit»;
Console.ReadLine();
}
}
Целевое приложение 2 в виду необработанного исключения аварийно завершается после печати на консоль следующих данных: Breaker call number 1
Аспект 2, метаязык. Данный аспект позволяет быстро диагностировать приложение и внести в него соответствующие поправки для правильной работы:
%aspect Aspect1
class Aspect1 {
%instead %call *BreakerTester.Breaker(int) && args(..) %action
public static void WrapperAction (int n) {
try
{
BreakerTester.Breaker(n);
}
catch (Exception e) {
string s = e.ToString();
Console.WriteLine ( «Breaker call number» + n + «finished» + «Exception handled:»);
Console.WriteLine(s.Substring(0, s.IndexOf(«:»))); }
}
}
Результирующее приложение 2 с примененным аспектом можно легко диагностировать: Breaker call number 1
Breaker call number 1 finished. Exception handled:
System.ArgumentException Breaker call number 3
Breaker call number 3 finished. Exception handled:
System.IndexOutOfRangeException Breaker call number 10
Breaker call number 10 finished. Exception handled:
System.InvalidOperationException
Press ENTER to exit
Парадигма АОП до сих пор находится в стадии научных исследований, несмотря на свою очевидную перспективность и теоретическую обоснованность. Основные причины - недостаточная поддержка существующими инструментами АОП традиционных процессов разработки программного обеспечения; отсутствие длительного опыта использования данной концепции, сдерживающего начало широкого использования этой методологии в промышленных разработках.
Система AspectRotor, созданная Р. Мухано-вым, позволяет использовать АОП при разработках для академической версии .NET - платформы SSCLI/Rotor, способствует более широкому использованию и распространению АОП, не ограничиваясь лишь платформами Java и (коммерческой) Microsoft.NET. Это позволит сделать еще один шаг для накопления индустрией ПО опыта в создании программных систем с использованием данной методологии, что, безусловно, усилит ее развитие и активное использование.
СПИСОК ЛИТЕРАТУРЫ
1. Буч, Г. Объектно-ориентированный анализ и проектирование [Текст]/Г. Буч.-СПб.: Бином, Невский диалект, 1999.
2. Safonov, V.O. Using aspect-oriented programming for trustworthy software development [Текст]/УО. Safonov// Wiley Interscience.-John Wiley & Sons, 2008. -P. 338
3. Сафонов, В.О. Aspect.NET - инструмент аспектно-ориентированного программирования для разработки надежных и безопасных программ [Текст]/ В.О. Сафонов//Компьютерные инструменты в образо-вании.-2007.-№ 5.
4. Safonov, V.O. Aspect.NET - an aspect-oriented programming tool for Microsoft.NET [Текст]/УО. Safonov, D.A. Grigoriev//Proc. of IEEE Regional conf. -St. Petersburg, 2005.
5. Safonov, V.O. Aspect.NET: concepts and
architecture [Текст]/УО. Safonov//.NET Developer's Journal.-Oct. 2004.
6. Safonov, V.O. Aspect.NET - A New Approach to Aspect-Oriented Programming [Текст]/УО. Safonov// NET Developer's Journal.-Apr. 2003
7. Сайт, посвященный Phoenix Academic Program [Электронный ресурс] http://www.research.microsoft. com/phoenix/
8. Документация по QT SDK компании Nokia [Электронный ресурс] http://doc.qt.nokia.com/
9. Shared Source Common Language Infrastructure/ Rotor 2.0 [Электронный ресурс] http://research.microsoft. com/sscli/
10. Aspect-Oriented Software Development Community & Conference [Электронный ресурс] http:// aosd.net/
