Сущность аспектно-ориентированного программирования
Методы объектно-ориентированного анализа и проектирования позволяют создать модель (архитектуру) информационной системы; провести анализ и создать на его основе модель предметной области. Типизации проектных решений служит широко распространенная концепция шаблонов, эффективные методы анализа и проектирования могут быть оформлены как стратегии.
Однако при разработке программной системы требуется также обеспечить выполнение различных требований к ней. Это могут быть требования к безопасности (необходимость авторизации при проведении транзакций клиент-сервер), качеству обслуживания, синхронизации операций чтения/записи и обеспечению целостности данных и др.
Ранее для специфицирования необходимости обеспечения некоторым классом определенных требований было введено понятие контракта [14]. Однако поддержка любого требования, не относящегося к сущности, описываемой классом, усложняет его структуру, более того, существует ряд требований, общих для многих различных классов или не являющихся функциональными, реализация которых в отдельных классах исключительно затруднена (такие требования называют “пересекающими” (crosscutting)). Требуется введение некоторого дополнительного программного “слоя”, на который было бы возложено выполнение “контрактных обязательств” классов, абстрагирующих сущности предметной области.
Для этого в 1997 г. группой разработчиков из Xerox PARC во главе с Г. Кикзалесом была предложена концепция аспектно-ориентированного программирования (АОП) [13]. Ими было явно введено понятие аспекта, которым является то свойство системы, которое не может быть явно реализовано в виде процедуры. “Аспекты имеют тенденцию не быть элементами функциональной декомпозиции системы, но скорее быть свойствами, которые системно воздействуют на производительность или семантику компонентов”. В этом аспекты противоположны компонентам, “имеющим тенденцию быть единицами функциональной декомпозиции системы”. Цель АОП – “поддержать программиста в четком разделении компонентов и аспектов друг от друга, обеспечивая механизмы, которые сделают возможным абстрагировать их и объединять для получения системы в целом”. (На русском языке концепции и преимущества АОП описаны в [3]).
В работе [11] рассматривается переход от контрактного проектирования к использованию аспектов. Имея в виду под словом “контракт” “спецификацию ограничений, которые должны быть соблюдены некоторой сущностью, запрашивающей услугу от другой сущности”, авторы указывают, что “обычно части проекта, которые реализуют определенный контракт, “рассеяны” (scattered) по всему проекту”. На те же проблемы “рассеивания”, а также на “запутывание” (tangling) структуры классов вследствие необходимости реализации в них механизмов поддержки требований, не связанных с описываемыми ими абстракциями, указывали С. Кларк и Р. Уолкер [8], подчеркивая, что “рассеивание и запутывание имеют негативное влияние на жизненный цикл разработки, с точек зрения возможностей понимания, отладки, развития, повторного использования” (классов и архитектуры системы в целом).
Неотъемлемой частью среды разработки, поддерживающей АО-парадигму, также является инструмент “связывания” (weaving), выполняющий генерацию результирующего программного кода (на этапе компиляции или даже во время выполнения) из двух, в общем случае независимых, проектов: реализующих функциональные требования и вынесенную в аспекты логику.
Для успешного применения любой техники программирования требуется не только ее поддержка языком программирования, но и возможность формализации принятых решений на этапе проектирования. Из этого следует необходимость наличия как минимум графической нотации для записи моделей, как максимум – методологии, формализующей процесс проектирования, и поддержки новой технологии в CASE-средствах разработки.
