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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Обзор[править | править код]

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

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

Квантификация и забывчивость[править | править код]

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

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

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

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

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

Понятия и терминология[править | править код]

Тела совета[править | править код]

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

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

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

Пример[править | править код]

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

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

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

Аспектно-ориентированное программирование (АОП)[править | править код]

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

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

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

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

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

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

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

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

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

Использование[править | править код]

  • JBoss Application Server (JBoss AS) — свободный сервер приложений java с открытым исходным кодом, который поддерживает Java EE. Ядро AS JBoss интегрировано с аспектно-ориентированным языком программирования JBoss. Сервер приложений использует AOP JBoss, чтобы развернуть службы, такие как управление безопасностью и управление транзакциями.[4]

Примечания[править | править код]

  1. ↑ 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)
  2. ↑ 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.
  3. ↑ 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
  4. ↑ 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

Ссылки[править | править код]

Источник — https://ru.wikipedia.org/w/index.php?title=Аспектно-ориентированная_разработка_программного_обеспечения&oldid=117734248