Что такое AOSD?
Аспектно-ориентированная разработка программного обеспечения (AOSD) - это относительно новая парадигма разработки бизнес-приложений. Основа данного подхода - Аспект. Это точка зрения, с которой может быть рассмотрено какое-либо понятие, процесс, перспектива. Чтобы быстрее вникнуть в суть подхода, давайте рассмотрим веб-сайт в различных аспектах. Информационная архитектура описывает сайт в аспекте организации его структуры. Usability описывает сайт в аспекте удобства его использования. Графический дизайн представляет сайт в аспекте его визуального восприятия. Функциональная модель описывает сайт в аспекте его бизнес-логики. Все это различные составляющие процесса разработки веб-сайта, каждая из которых требует специфичных ресурсов, подходов и реализаций. Успешный проект подразумевает качественное решение со стороны каждого их этих аспектов. Если кому-либо данный пример покажется сложным, можно обратиться к более простой и универсальной схеме. Когда проектируется жилой дом, архитекторы проектируют каркасный чертеж, далее подготавливается схема электропроводки, схема водоснабжения и прочее. Очевидно, что каждый этап является самостоятельным, но необходимым для успеха всего проекта. Каждый этап - это аспект, в котором можно рассматривать проект. Как это ни банально, но в разработке программного обеспечения может быть использован тот же принцип выделения аспектов бизнес логики приложений. Более 20 лет назад Бьерн Страуструп воплотил в C++ компоновку программного кода в наборы логических объектов, поведение которых и соотношение друг с другом может быть определено различным образом (наследование, инкапсуляция, абстракция, полиморфизм). Это надежная, проверенная временем парадигма разработки программного обеспечения - объектно-ориентированное программирование. Однако этот подход имеет свои ограничения в декомпозиции аспектов бизнес-логики приложения. За прошедшее время было разработано множество новых подходов для преодоления данных ограничений. Среди них можно назвать адаптивное программирование, композиционные фильтры, гиперпространства, аспектно-ориентированное программирование, моделирование ролей, предметно-ориентированное программирование и т.д. Последнее время подобные изыскания стали подаваться под эгидой аспект-ориентированной разработкой программного обеспечения. Как уже говорилось выше, код сквозной функциональности так или иначе будет распределен по различным модулям, что наихудшим образом скажется на качестве программного обеспечения с точки зрения наглядности бизнес-логики, ее адаптации и способности к развитию. Задача AOSD в том, чтобы выделить сквозную функциональность и вынести ее за пределы бизнес-логики приложений.
Давайте представим какое-нибудь комплексное веб-приложение, например, CMS, и рассмотрим, на каком этапе и каким образом мы можем столкнуться с указанными проблемами. Допустим, что для некоторого числа функций системы требуется преобразование входных данных из XML в массивы. В данном случае аспект XML-парсинга затрагивает лишь небольшое число функций и не предполагает существенного развития. Как мы видим, здесь не требуется расширенная декомпозиция, нет очевидной необходимости в использовании AOSD. Логичнее всего определить эту процедуру в метод корневого класса (или же внешнего класса, смотря по обстоятельствам) и вызывать его по мере необходимости.
Рисунок 1.Приемлемая декомпозиция.
Однако если же речь идет о мониторинге производительности, и наша задача - по требованию снять показания со всех выполняемых функций на их входах и выходах, то едва ли помогут какие-либо манипуляции с объектами. Впрочем, дотошный читатель предложит воспользоваться предыдущим примером в масштабе всего приложения и в дальнейшем использовать триггер для включения и выключения сбора статистических данных. Остается его предупредить, что когда вдруг возникнет необходимость задействовать протоколирование системных транзакций для заданных случаев, при данном подходе придется вспоминать все детали программной архитектуры и реорганизовывать ее.
Рисунок 2. Неприемлемая декомпозиция.
Насколько было бы удобнее попросить систему в рамках некоторого аспекта должным образом обслужить заданные события в определенных объектах. Скажем, проходит время, и для нашего большого и сложного проекта приходят новые требования по безопасности. Мы пишем процедуру дополнительных проверок безопасности и требуем от системы в рамках аспекта безопасности при вызове заданных методов выполнять данную процедуру. Парадигма аспектно-ориентированной разработки программного обеспечения подразумевает это. Мы выделяем новый уровень абстракции вне существующей программной архитектуры и декларируем в нем функциональность, в том или ином отношении применимую к системе в целом. Как видно из , мы можем выделить программные процедуры, обслуживающие систему, например, в рамках аспекта безопасности и вынести их из основных классов. Далее мы можем проделать то же в отношении процедур аспекта контроля входных данных. Таким образом, при каждом проходе мы освобождаем бизнес-логику системы, делаем ее более наглядной. Фактически мы получаем в результате наглядную бизнес-логику в основных классах системы и аккуратно расфасованную сквозную функциональность вне базовой модели.
Рисунок 3. Аспектная декомпозиция.
Итак, резюмируем:
- Основа аспектно-ориентированного подхода состоит в идентификации общности программного кода в рамках каких-либо аспектов и вынесении выделенных процедур за пределы основной бизнес-логики.
- Процесс аспектной ориентации и разработки программного обеспечения может включать моделирование, дизайн, программирование, обратный инжениринг, реинжениринг.
- Зона покрытия аспектно-ориентированной разработки ПО включает приложения, компоненты, базы данных.
- Взаимодействие и интеграция с прочими парадигмами осуществляется посредством фреймворков, генераторов, языков программирования и языков описания архитектуры (ADL).
