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