Аспектно–ориентированное программирование
Аспектно–ориентированное программирование (АОП) [18–20] – это парадигма построения гибких к изменению ПС за счет добавление новых функций, средств безопасности и взаимодействия компонентов с другой средой, синхронизации одновременного доступа частей ПС к данным, вызова общесистемных средств и др.
Аспектом может быть некоторая функция, ПИК, элемент или часть готовой программы, отдельный компонент, концепция взаимодействия, защиты и др. Созданная средствами АОП ПС из отдельных программ семейства может включать набор ПИК, объекты, небольшие методы и аспекты, как средство дополнения ПС необходимыми концепциями взаимодействия или защиты для новой среды, которые пересекают (переплетают) компоненты и тем самым значительно усложняют процесс вычислений.
Реализация аспектов в различных частях программного кода ПС решается путем установления перекрестных ссылок и точек соединения, через которые осуществляется связь аспекта с транзакциями, защитой данных и т.п.
В основе АОП лежит метод разбиения задач ПрО на ряд функциональных компонентов с применением аспектов (синхронизации, взаимодействия, защиты и др.), которые встраиваются в отдельные компонентов в некоторые их точки для выполнения соответствующих нефункциональных требований к организации выполнения компонента с другими компонентами или средами.
Кроме того, в качестве аспекта может использоваться некоторая задача, которая интересует нескольких заинтересованных лиц проекта и представленная с помощью вариантов использования, функции для компонента или программы. Некоторые аспекты могут реализовываться на этапах ЖЦ процесса разработки, способствуя улучшению результат разработки ПС.
Создание конечного продукта ПС в АЛП выполняется по технологии, соответствующей разработке компонентных систем, с той разницей, что здесь используются аспекты, которые задают условия выполнения компонентов (безопасность, защиту, взаимодействие и др.) в среде функционирования. В процессе разработки аспекты отображают разные роли взаимодействующих лиц, что приближает аспект к роли программного агента в плане выполнения некоторых функций при определении архитектуры системы, управления проектом и повышения качества ПС.
Для использования аспекта в проектных решениях в АОП введен дополнительный механизм фильтрации входных сообщений, с помощью которых выполняется изменение параметров и имен текстов аспектов в конкретно заданном компоненте системы. Код компонента становится «нечистым» (т.е.с пересекаемыми его аспектами), для которого требуется разработка новых подходов к композиции компонентов, ориентированных на Уро и на выполнение ее функций.
Общие средства композиции объектов ООП или компонентов (вызов процедур, RPC, RMI, IDL и др.) в АОП являются недостаточными, так как аспекты требуют декларативного сцепления между частичными описаниями, а также связывания отдельных обрывков из различных объектов. Одним из механизмов композиции является фильтр композиции, суть которого состоит в обновлении заданных аспектов синхронизации или взаимодействия без изменения функциональных возможностей компонента с помощью входных и выходных параметров сообщений, которые проходят фильтрацию и изменения, связанные с переопределением имен или функций самих объектов.
Фильтры делегируют внутренним компонентам параметры, переадресовывая установленные ссылки, проверяют и размещают в буфере сообщения, локализуют ограничения на синхронизацию и готовят компонент для выполнения.
В ОО–программах могут быть мелкие методы, дополнительно выполняющие расчеты с обращением к другим методам внешнего уровня. Деметер сформулировал закон [40–43], согласно которому длинные последовательности мелких методов не должны выполняться. В результате создается код алгоритма с именами классов, не задействованных в выполнении расчетных операций, а также новый дополнительный класс, который расширяет этот код функциями изменения расчетных программ.
С точки зрения моделирования, аспекты можно рассматривать как каркасы декомпозиции системы, в которых отдельные аспекты синхронизации, взаимодействия и др. пересекают ряд многократно используемых ПИК (рис.5.4).
Р1 Р2 Р3
Рис. 5.4. Пример структуры программы из Р1, Р2 и Р3 аспектами защиты
Разным аспектам проектируемой системы могут отвечать и разные парадигмы программирования: объектно–ориентированные, структурные и др. Они по отношению к проектируемой ПрО образуют мультипарадигмную концепцию аспектов, такую как синхронизация, взаимодействие, обработка ошибок и др. и требуют значительных доработок процессов их реализации. Кроме того, можно устанавливать связи с другими предметными областями для описания аспектов приложения в терминах родственных
областей. Появились языки АОП, которые позволяют описывать пересекающиеся аспекты в разных ПрО. В процессе компиляции переплетения объединяются, оптимизируются и генерируются [20] и выполняются в динамике.
Существенной чертой любых аспектов является модель, которая пересекает структуру другой модели, для которой первая модель является аспектом. Так как аспект связан с моделью, то ее можно перестроить так, чтобы аспект стал, например, модулем и выполнял функцию посредника, беря на себя все образцы взаимодействия. Однако решение, таким образом, проблемы пересечения может привести к усложнению и понижению эффективности выполнения созданного модуля или компонента.
Переплетение аспектов с компонентами может проявиться на последующих этапах процесса разработки, поэтому требуется минимизация количества сцеплений между аспектами и компонентами путем реализации ссылок в вариантах использования или сопоставления с образцом. Аспекты реализуются блоками кода с установленными перекрестными ссылками между ними, иными словами в блоках появляются точки связей с сообщениями, обработкой ошибок и т.п.
Связь между характеристиками и аспектами ПС может быть выявлена в ходе анализа ПрО. Тогда создается динамическое связывание или статическое или «жесткое» связывание в период компиляции.
АОП стимулирует разработку новых механизмов композиции, ориентированных на ПрО и на выполнение ее задач. Аспекты с точки зрения моделирования можно рассматривать как каркасы декомпозиции системы с многократным использованием. АОП соответствует мультипарадигмовой концепции, сущность которой состоит в том, что разным аспектам проектируемой ПС, должны отвечать разные парадигмы программирования: объектно–ориентированные или структурные. Каждая из парадигм относительно реализации разных аспектов ПС (синхронизации, внедрения, обработки ошибок и др.) требует усовершенствования и обобщения применительно к каждой новой ПрО.
В АОП используется модель модульных расширений, создаваемая в рамках метамодельного программирования. Эта модель ориентирована на оперативное использование новых механизмов композиции отдельных частей ПС или семейств с учетом предметно–ориентированных возможностей языков (например, SQL) и каркасов, которые поддерживают разного рода аспекты [20].
Технология разработки прикладной системы с использованием АОП базируется на технологии ООП и имеет вид:
1..Декомпозиция функциональных задач с предположением многоразового применения соответствующих модулей и выделение аспектов, т.е свойств их выполнения (параллельно, синхронно, безопасно и т.д.).
2. Анализ языков спецификации аспектов и определение конкретных аспектов для выполнения задач ПрО;
3. Определение в модулях точек соединения аспектов для формирования ссылок на них.
4. Разработка фильтров и описание связей аспектов с функциональными компонентами, выделенными в ПрО. Система фильтров отображается в модели EJB, работающей на стороне сервера и управляющей данными с обеспечением безопасности и защитой доступа;
5. Определение механизмов композиции (вызовов процедур, методов, сцеплений) функциональных модулей многоразового применения и аспектов в точках их соединения, как фрагментов модулей с обеспечением свойств управления выполнением этих модулей, или ссылок из этих точек на другие модули.
6. Создание объектной или компонентной модели, дополнение ее входными и выходными фильтрами сообщений, посылающих объектам с ссылками, задание на выполнение методов или аспектов управления синхронизацией, защитой и т.д.
7. Анализ библиотеки расширений для выбора некоторых функциональных модулей, необходимых для реализации задач домена.
8. Компиляция, отладка модулей и аспектов, а также композиция их в прикладную программу.
Для эффективной реализации аспектов разработаны ІР–библиотека расширений, активные библиотеки, Smalltalk и ЯП, расширенные средствами описания аспектов.
В ІР–библиотеке размещены некоторые функции компиляторов, методов, средства оптимизации, редактирования, отображения. и др. Например, библиотека матриц, с помощью которой вычисляются выражения с массивами, обеспечивается скорость выполнения, предоставления памяти и т.п.[21]. Использование таких библиотек в расширенных средах программирования называют родовым программированием, а решение проблем экономии, перестройки компиляторов под каждое новое языковое расширение, использование шаблонов и результатов предыдущей обработкой относят к области ментального программирования [22].
Библиотека включают отдельные функции компиляторов, средств оптимизации, редактирования, отображения понятий, перестройки отдельных компонентов компиляторов под новое языковое расширения, а также средства программирования на основе шаблонов и т.п. Библиотеки с такими возможностями получили название библиотек генерирующего типа.
Иной вид библиотек АОП – активные библиотеки, которые содержат не только базовый код реализации понятий ПрО, но и целевой код обеспечения компиляции, оптимизации, адаптации, визуализацию и редактирование.
Активные библиотеки пополняются средствами и инструментами интеллектуализации агентов, с помощью которых поддерживается разработка специализированных агентов для решения конкретных задач реализуемой ПрО.