Аспектно-ориентированная разработка программного обеспечения

В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка установлена 27 июня 2012.

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

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

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

Цели

Сквозные проблемы

Целью использования аспектно-ориентированного программирования является борьба с проблемами, вызванными рассеиванием и запутыванием кода. Задача аспектно-ориентированной разработки программного обеспечения — обеспечить систематические методы для модулизации сквозных проблем.

Говорят, что реализация проблемы рассеяна, если его код рассредоточен по многим модулям. В результате проблема влияет на реализацию многих модулей и соответственно её реализация не является модульной.

Говорят, что реализация проблемы запутана, если её код смешан с кодом, который реализует другие проблемы. Модуль, в котором происходит путаница, не связен.

Рассеивание и путаница часто возникают вместе, хотя они — различные понятия.

Аспектно-ориентированная разработка программного обеспечения полагает, что рассеивание кода и путаница — признаки сквозных проблем. Сквозные проблемы не могут быть построены из модулей, с помощью механизмов декомпозиции языка (объектного или процедурного), потому что они по сути требуют различных правил декомпозиции. Реализация и интеграция этих проблем с основной функциональной декомпозицией системы вызывают путаницу и рассеивание кода.

Примеры сквозных проблем

• Синхронизация (информатика)
• Работа в реальном времени
• Обнаружение и исправление ошибок
• Особенности продукта
• Менеджер памяти
• Проверка данных
• Персистентность
• Обработка транзакций
• Информационная безопасность
• Кэширование
• Ведение логов
• Мониторинг
• Бизнес-логика
• Переносимые программы
• Интернационализация и Локализация
• Некоторые виды оптимизации

Проблемы возникающие при рассеянии и путанице

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

Отсутствие интерфейсов между реализацией сквозных проблем и реализацией модулей системы мешает разработке, развитию и обслуживанию системы.

Системная разработка

Модуль — прежде всего единица независимой разработки. Он в значительной степени может быть реализован независимо от других модулей. Модульный принцип достигается с помощью чёткого определения интерфейсов между частями системы.^[1]

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

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

Наконец, проблемы, которые не выделены в модули, трудно протестировать в отдельности. Зависимости проблемы относительно поведения других модулей явно не описаны. Следовательно, реализация теста для таких проблем требует знания о реализации многих модулей в системе.

Обслуживание системы и развитие

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

Обзор

Суть аспектно-ориентированной разработки

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

Квантификация и забывчивость

Самое известное определение природы АОРПО принадлежит Филмену и Фридману, которые характеризовали АОРПО в виде записи аспектно-ориентированность = квантификация + забывчивость.^[2]

Забывчивость обозначает, что у программа нет знает, какие аспекты изменяют её, тогда как квантификация обозначает, что аспекты могут влиять на многие части в програмы.

Вместо термина забывчивость часто используется понятие невторгаемости. Термин невторгаемость обозначает то, что аспекты могут добавить поведение к программе, не внося изменения в саму программу, но при этом не предполагает, что программа ничего не знают об аспектах.

Определение Филмена ориентации аспекта часто считают слишком ограниченным.^[3] Многие аспектно-ориентированные подходы используют аннотации, чтобы явно объявить указать расположение мест, где аспекты определяют поведение. Эти подходы требуют ручного контроля и модификации других модулей в системе и поэтому являются вторгающимися. Кроме того АОРПО не обязательно требует квантификации. Аспекты могут использоваться, чтобы изолировать функции, реализация которых была бы иначе перепутана с другими функциями. Такие аспекты не обязательно используют квантификацию во многих точках системы.

Поэтому особенности аспектно-ориентированной разработки лучше характеризуются модульным принципом реализации сквозных проблем, абстракциями аспектно-ориентированных языков, которые позволяют использовать модульность, и аспектно-ориентированными операторами.

Понятия и терминология

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

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

Такие точки называют точками соединения.

Модель точки соединения

Точки соединения — точки в выполнении программы, такие как вызовы метода, где поведение, предоставленное аспектами, объединено. Точка соединения — точка в выполнении программы, которая используется, чтобы определить динамическую структуру сквозных проблем.

Модель точки соединения аспектно-ориентированного языка определяет типы точек соединения, которые поддерживаются аспектно-ориентированным языком и возможными точками столкновения между аспектами и базовыми модулями.

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

Примеры точек соединения

• выполнение метода
• вызов метода
• доступ для чтения поля и доступ для записи
• выполнение обработчика исключений
• статическая и динамическая инициализация

Метод вызова точки соединения — это действия объекта, который получает этот вызов. Он включает все действия вызова от определения аргументов до возврата.

Многие подходы АОП реализуют поведение аспекта перехватами в теневых точках соединения, которые является статической проекцией точки соединения в коде программы.

Объявление среза

Квантификация по точкам соединения определяется на уровне языка. Эта квантификация может быть неявной в структуре языка или может быть выражена, с использованием подобной запросу конструкции, называемой срезом. Срезы определены как предикат в синтаксическом дереве программы, и объявляет интерфейс, который ограничивает, какие элементы основной программы выбраны срезом. Срез выбирает определенные точки соединения и значения. Синтаксическая формулировка среза может изменяться в различных подходах. Обычно срез может составляться из других срезов с помощью булевых операторов И, ИЛИ и НЕ. С помощью подстановочных знаков выражения среза могут выбирать сразу многие события. Например, в синтаксисе AspectJ, срез move

pointcut move: call(public * Figure.* (..))

выбирает все вызовы к публичным методам Figure.

Срез cflow выбирает точки соединения, на основании того, возникают ли они в динамическом контексте других точек соединения. Например, в синтаксисе AspectJ cflow(move()) выбирает каждую точку соединения, которая находится в динамическом контексте точек соединения, выбранных срезом move.

Срезы могут быть разделены на две категории:

• Типизированные срезы, такие как срез call, выбирают один тип точек соединения, используя сигнатуру.
• Нетипизированные срезы, такие как срез cflow выбирают все типы точек соединения, используя множество свойств.

Тела совета

Тело совета — код, который выполняется, когда точка соединения достигнута. Совет выделяет в отдельный модуль функциональные детали проблемы. Моменты, в которые тела советов, зависящие от аспектов (и от основы), выполняются могут быть различные, в том числе:

• как только точка соединения достигнута, до того, как начнётся выполнение основы
• после основной семантики точки соединения. Если точка соединения — выполнение метода, то совет выполняется после того, как метод возвратится либо при возникновении исключения
• как только точка соединения достигнута, причём аспект определяет выполнится ли основная семантика. То есть совет может изменить последовательность выполнения программы.

Кроме того существуют более общие способы описать упорядочивание тел совета с помощью графиков частичного порядка.^[4]

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

Межтиповые описания

Межтиповые описания позволяют программисту изменять статическую структуру программы, такую как члены класса и иерархия классов. Они позвляют вставлять новые члены классов и опускать классы ниже в иерархии классов.

Аспекты

Аспект — модуль, который инкапсулирует проблему. Аспект составлен из срезов, тел советов и межтиповых описаний. В некоторых подходах аспект может также содержать классы и методы.

Объединение аспектов

Объединение аспектов (англ. aspect weaving) — процесс согласования аспектов с другими модулями системы. Объединение аспектов производится специализированным компилятором, названным объединителем аспектов.

Пример

Рисунок 1 — Редактор рисунка в UML

Рисунок 2 — Аспектно-ориентированный редактор рисунка в UML

На рисунке 1 показан типичный пример сквозной проблемы в графическом редакторе, взятый от литературы по АОРПО. В нём показан абстрактный класс Shape, который может быть перемещен. Каждый раз, когда он перемещен, дисплей должен быть обновлен. Так же на рисунке 1 так же показаны два подкласса Shape: Line и Point, которые реализуют его функциональность. Проблема обновления дисплея рассеяна в реализации обоих подклассов. На рисунке 2 показана аспектно-ориентированная реализация той же самой системы, где функциональность обновления дисплея находится в отдельном аспекте.

Дескриптор среза move на рисунке 2 перехватывает выполнение методов moveBy подклассов Shape и вызывает обновления дисплея после того как их выполнение закончится. В результате проблема становится отдельным модулем, что облегчает развитие и поддержку системы.

Аспектно-ориентированная разработка требований

Аспектно-ориентированная разработка требований (также называемые «ранние аспекты») сосредотачивается на идентификации, спецификации и представлении сквозных свойств на уровне требований. Примерами таких свойств является безопасность, мобильность, доступность и необходимость работы в реальном времени. Сквозные свойства — требования, варианты использования или возможности, которые серьёзно влияют на другие требования или части архитектуры.

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

Аспектно-ориентированная архитектура системы

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

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

Аспектно-ориентированное проектирование

Аспектно-ориентированное проектирование имеет, как и любой другой вид проектирования программного обеспечения, целью характеризацию и спецификацию поведения и структуры системы. Его особенность при проектировании программного обеспечения заключается в том, что проблемы, которые будут рассеяными и запутанными в традиционных подходах, в нём могут быть отдельными модулями.

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

Аспектно-ориентированное программирование (АОП)

Основная статья: Аспектно-ориентированное программирование

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

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

Поддержка разработчиков приложений

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

• основные концепции аспектно-ориентированного программирования
• программирование на аспектно-ориентированных языках
• составление программных компонентов, написаннных на любом языке с помощью аспектно-ориентированных методов композиции
• среды аспектно-ориентированного программирования

Поддержка разработчиков языка

Области использования при поддержке построения аспектных языков:

• построение языков для определенных областей и/или платформ
• перенос принципов реализации аспектно-ориентированных сред выполнения, в том числе:
  • интерпретаторов
  • компиляторов
  • виртуальных машин

Формальные методы для поддержки аспектно-ориентированной разработки

Формальные методы могут использоваться как для семантического определения аспектов, так и для анализа и проверки аспектно-ориентированных систем. Аспектно-ориентированное программирование расширяет нотации программирования с помощью модулей аспекта, которые изолируют объявление того, когда аспект должен быть применен (точки соединения) и какие действия должны быть выполнены, когда это условие достигнуто (советы). Экспертиза формальных семантических определений конструкций аспекта полезны разработчикам языка, для того чтобы дать глубокое понимание различий среди конструкций. Аспекты могут снижать надежность системы, в которую они включены, и, кроме того, могут нарушить работу важных частей системы, которые нормально работали без аспектов. Кроме того аспекты добавляют необходимые сквозные свойства к системе. В результате возникают проблемы о правильности работы аспектов и проверке. Основные виды экспертизы:

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

Каждый из вышеупомянутых методов может быть использован для:

• определения и анализа отдельного аспекта по отношению к существующей системе,
• определения условий для правильного соединения аспектов
• обнаружение и разрешение потенциальных проблем из-за влияния аспектов друг на друга

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

Аспектно-ориентированное связующее программное обеспечение

Связующее программное обеспечение и АОРПО в значительной степени дополняют друг друга. Их основные области использования:

• поддержка разработчиков приложений, которая включает
  • основные концепции для поддержки аспектного связующего программного обеспечения,
  • аспектно-ориентированная разработка программного обеспечения использующая связующее программное обеспечение, в том числе аспектная модель программирования, аспектная модель развертывания, инфраструктуру платформы и службы связующего программное обеспечение
• разработка семейства продуктов (методы, архитектура, методы) в распределенных и «всепроникающих» вычислениях
• поддержка разработчика связующего программного обеспечения, а именно:
  • связующее программное обеспечение инфраструктуры узла
  • связующее программное обеспечение для распространения
  • общие службы связующего программного обеспечения
  • проблемно-ориентированные службы связующего программного обеспечения.

Использование

• IBM Websphere Application Server (WAS) — сервер приложений Java. В нём используется ApectJ для изоляции функций различных вариантах.
• JBoss Application Server (JBoss AS) — свободный сервер приложений java с открытым исходным кодом, который поддерживает Java EE. Ядро AS JBoss интегрировано с аспектно-ориентированным языком программирования JBoss. Сервер приложений использует AOP JBoss, чтобы развернуть службы, такие как управление безопасностью и управление транзакциями.^[5]
• Oracle TopLink
• SAP
• Sun Microsystems использует AspectJ, чтобы оптимизировать разработку мобильных приложений для платформы Java ME.
• Siemens Soarian — система управления медицинской информации. Soarian использует AspectJ, чтобы для реализации сквозных функций, таких как трассировка, аудит и мониторинг производительности в процессе быстрой разработки.
• Motorola wi4 — системой сотовой инфраструктуры, которая поддерживает стандарт беспроводного широкополосного доступа WiMAX. Программное обеспечение управления wi4 разработано, с использованием аспектно-ориентированного расширения стандарта UML 2.0 называющегося WEAVR. WEAVR используется при разработки для отладки и тестирования.
• ASML — производитель систем литографии для полупроводниковой отрасли. ASML использует аспектно-ориентированное расширение C под названием Mirjam, для реализации трассировки и профилирования.
• Glassbox — агент поиска и устранения неисправностей для приложений Java, который автоматически диагностирует типичные проблемы. Модуль инспектора Glassbox контролирует работу виртуальной машины с Java с помощью AspectJ.
• .NET 3.5 поддерживает аспектно-ориентированные проблемы с помощью Unity.

Примечания

1. ↑ Parnas, D.L. (1972): On the Criteria To Be Used in Decomposing Systems into Modules, in: Communications of the ACM, December 1972, Vol. 15, No. 12, 1053—1058
2. ↑ Filman, R. and D. Friedman. «Aspect-oriented programming is quantification and Obliviousness.» Proceedings of the Workshop on Advanced Separation of Concerns, in conjunction with OOPSLA’00 (2000)
3. ↑ Rashid, A and A. Moreira. «Domain Models are NOT Aspect Free.» Proceedings of the 9th Internation Conference on Model-Driven Engineering Languages and Systems (Models06). Genoa, Italy. LNCS 4199. Springer-Verlag (2006): 155—169.
4. ↑ William Harrison, Harold Ossher, Peri Tarr. General Composition of Software Artifacts, Proceedings of Software Composition Workshop 2006, March 2006, Springer-Verlag, LNCS 4089, pages 194—210
5. ↑ Chapter 8. JBoss AOP. Red Hat (2010). Архивировано из первоисточника 12 февраля 2012.

Литература

• Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J.-M. Loingtier, J. Irwin (1997): Aspect-Oriented Programming, in: Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 1997), Jyvaskyla, Finland, Lecture Notes in Computer Science 1241, Springer-Verlag, 220—242
• Murphy, G.C., R.J. Walker, E.L.A. Baniassad, M.P. Robillard, A. Lai, M.A. Kersten (2001): Does Aspect-Oriented Programming Work?, in: Communications of the ACM, October 2001, Vol. 44, No. 10, 75-77
• Tarr, P., H. Ossher, W. Harrison, S.M. Sutton Jr. (1999): N Degrees of Separation: Multi- Dimensional Separation of Concerns, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, California, USA, IEEE Computer Society Press, 107—119

Ссылки

• Aspect-Oriented Software Development Community and Conference
• European Network of Excellence on Aspect-Oriented Software Development
• Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design
• The Aspect-Oriented Software Architecture Design Portal
• Aspect-Oriented Software Engineering at Lancaster
• Early Aspects for Business Process Modeling (An Aspect-Oriented Language for BPMN)
• Composition Filters Model
• Demeter and Adaptive Programming
• IBM subject-oriented programming
• Aspect-Oriented Software Development Course, Bedir Tekinerdogan, Bilkent University

Связать^?

На эту статью не ссылаются другие статьи Википедии. Пожалуйста, воспользуйтесь подсказкой и установите ссылки в соответствии с принятыми рекомендациями.