3.Введення в аоп
АСПЕКТ (від латів. aspectus — вигляд), точка зору, з якою розглядається яке-небудь явище, поняття, перспектива. (Великий енциклопедичний словник)
Дослідники вивчили різні шляхи виділення в окремі модулі крізної функціональності в складних програмних системах. Аспектно-орієнтоване програмування (АОП) є одним з цих рішень. АОП пропонує засоби виділення крізній функціональності в окремі програмні модулі — аспекти.
З погляду АОП в процесі розробки достатньо складної системи програміст вирішує дві ортогональні задачі:
Розробка компонентів, тобто виявлення класів і об'єктів, складових словник наочної області.
Розробка сервісів, що підтримують взаємодію компонентів, тобто побудова структур, що забезпечують взаємодію об'єктів, при якій виконуються вимоги завдання.
Сучасні мови програмування (такі як, наприклад, C++, VB і т.п.) орієнтовані, перш за все, на рішення першої задачі. Код компоненту представляється у вигляді класу, тобто він добре локалізований і, отже, його легко проглядати, вивчати, модифікувати, повторно використовувати. З іншого боку, при програмуванні процесів, в які залучені різні об'єкти, ми отримуємо код, в якому елементи, пов'язані з підтримкою такого процесу, розподілені за кодом всієї системи. Ці елементи зустрічаються в коді безлічі класів, їх сукупність в цілому не локалізована в осяжному сегменті коду. В результаті ми стикаємося з проблемою "заплутаного" коду.
В рамках АОП затверджується, що ніяка технологія проектування не допоможе вирішити дану проблему, якщо тільки ми залишатимемося в рамках мови, орієнтованої тільки на розробку компонентів. Для програмування сервісів, що забезпечують взаємодію об'єктів, потрібні спеціальні засоби, можливо спеціальні мови.
3.1.Основні концепції аоп
Аспектно-орієнтований підхід розглядає програмну систему як набір модулів, кожен з яких відображає певний аспект — мету, особливість функціонування системи. Набір модулів, створюючих програму, залежить від вимог до програми, особливостей її наочної області. Разом з функціональними вимогами до програми пред'являються і загальносистемні вимоги, наприклад: цілісності транзакцій, авторизованого доступу до даним, ведення журналу подій і т.д. При проектуванні програмної системи розробник вибирає модулі так, щоб кожен з них реалізовував певну функціональну вимогу до системи. Проте реалізація деяких вимог до програми часто не може бути локалізована в окремому модулі в рамках процедурного або об'єктно-орієнтованого підходу. В результаті код, що відображає такі аспекти функціонування системи, зустрічатиметься в декількох різних модулях. Традиційні парадигми програмування використовують при проектуванні програми функціональну декомпозицію і не дозволяють локалізувати крізну функціональність в окремих модулях. Необхідність реалізації крізної функціональності наявними засобами веде до того, що деякий компонент містить код, що відображає безліч ортогональних вимог до системи. Це робить такий модуль вузькоспеціалізованим, погіршує можливості його повторного використання і в деяких випадках приводить до дублювання коду. У свою чергу, це викликає підвищення вірогідності внесення помилок, збільшення часу відладки, знижує якість програми і у великій мірі утрудняє її супровід. Аспектно-орієнтований підхід в деяких випадках дозволяє уникнути описаних проблем і поліпшити загальний дизайн системи, забезпечуючи можливість локалізації крізної функціональності в спеціальних модулях — аспектах.
АОП дозволяє реалізовувати окремі концепції в слабосвязанном вигляді, і, комбінуючи такі реалізації, формує кінцеву систему. АОП дозволяє побудувати систему, використовуючи слабосвязанные розбиті на окремі модулі (аспекти) реалізації загальносистемних вимог.
Розробка в рамках АОП складається з трьох окремих кроків:
Аспектна декомпозиція: розбиття вимог для виділення загальній і крізній функціональності. На цьому кроці необхідно виділити функціональність для модульного рівня з крізної функціональності системного рівня. Наприклад, в прикладі з кредитними картами можна виділити три речі: ядро обробки кредитних карт, журнал подій, аутентифікація.
Реалізація функціональності: Реалізувати кожну вимогу окремо. У прикладі з кредитними картами необхідно окремо реалізувати модуль обробки кредитних карт, модуль журналу, модуль аутентифікації.
Компоновка аспектів: На цьому кроці аспектний інтегратор визначає правила для створення своїх модулів — аспектів, складаючи кінцеву систему. У прикладі з кредитними картами необхідно визначити, в термінах мови реалізовуючого АОП, при виклику яких операцій необхідно вносити запис до журналу, і по завершенню яких дій необхідно повідомляти про успіх/неуспіх операції. Також можна визначити правила, по яких викликатиметься модуль аутентифікації перед доступом до бизнес-логике обробки кредитних карт.
Малюнок 6. Фази аспектно-орієнтованої розробки ПО.
АОП відрізняє багато що від традиційних підходів ООП при реалізації крізної функціональності: тут потрібно по-іншому уявляти собі процес декомпозиції, а архітектура програмного продукту, що виходить, в значній мірі виходить за рамки уявлень, традиційних для об'єктного програмування. При розробці на АОП концепції реалізуються абсолютно незалежно один від одного, оскільки всі зв'язки (крізна функціональність), що існують між ними, можуть бути локалізовані в аспектних модулях, що описують протокол взаємодії концепцій. Наприклад, в модулі обробки кредитних карт може бути відсутнім запис в журнал або виклик модуля авторизації, проте при роботі може викликатися подібна крізна функціональність, якщо вона описана в протоколі взаємодії. Це серйозний крок в розвитку методологій від ООП.
Аспектом в АОП є системний модуль, в який винесена крізна функціональність. Аспектний модуль — це результат аспектної декомпозиції, на етапі якої виявляються які-небудь явища, поняття, події які можуть бути застосовані до групи компонентів, отриманих після об'єктної декомпозиції. Аспект є мовною концепцією, схожою з класом, але тільки більш високого рівня абстракції.
Аспекти можуть зачіпати багато компонентів і використовують так звані точки вставки для реалізації регулярних дій, які зазвичай розосереджені по всьому тексту програми. У аспектному модулі описуються зрізи крапок — точки виконання програми, в які вбудовуються інструкції мови, які повинні виконуватися до, після або замість строго певної точки виконання програми. Подібні інструкції мови є функціональністю, що підтримує взаємодію компонентів. Крім того, в аспектному модулі можуть описуватися ролі компонентів, на які може впливати даний аспект. У окремих реалізаціях АОП за допомогою аспектних модулів можна впливати на існуючу схему спадкоємства. З погляду АОП аспект є сервісом, що зв'язує компоненти системи.
Приклад інтеграції аспектів.
Для ілюстрації роботи інтегратора аспектів повернемося наприклад обробки кредитних карт. Скорочено розглянемо тільки 2 операції — кредит і дебет:
public classCreditCardProcessor {
public void debit(CreditCard card, Currency amount)
throwsInvalidCardException, NotEnoughAmountException
CardExpiredException {
// логіка по дебету
}
public void credit(CreditCard card, Currency amount)
throws InvalidCardException {
// логіка по кредиту
}
}
і інтерфейс журналу подій:
public interface Logger {
public void log(Stringmessage);
}
Для отримання бажаної композиції потрібне застосування наступних правил, виражених на звичайній мові:
записати в журнал початок кожної операції
записати в журнал закінчення кожної операції
записати в журнал кожну виняткову ситуацію, яка може виникнути в процесі роботи цього модуля.
Інтегратор аспектів, застосовуючи такі правила, отримає код еквівалентний даному:
public class CreditCardProcessorWithLogging {
Logger _logger;
public void debit(CreditCard card, Money amount)
throws InvalidCardException, NotEnoughAmountException
CardExpiredException {
_logger.log("Starting CreditCardProcessor.debit(CreditCard
Money) "+ "Card: " + card + " Amount: " + amount);
// Debiting logic
_logger.log("Completing CreditCardProcessor.debit(CreditCard
Money) " + "Card: " + card + " Amount: " + amount);
}
public void credit(CreditCard card, Money amount)
throws InvalidCardException {
System.out.println("Debiting");
_logger.log("Starting CreditCardProcessor.credit(CreditCard
Money) " + "Card: " + card + " Amount: " + amount);
// Crediting logic
_logger.log("Completing CreditCardProcessor.credit(CreditCard
Money) " + "Card: " + card + " Amount: " + amount);
}
}
Автоматична компоновка аспектів і традиційних модулів програми — компонентів є ключовою властивістю АОП, яка визначає основну перевагу даної технології: робить можливою інкапсуляцію крізної функціональності в окремих програмних модулях.
Малюнок 7. Процес компоновки аспектних і традиційних модулів.
Автоматизована компоновка аспектів і компонентів є могутнім засобом генерації коду і в загальному випадку гарантує, що аспект буде застосований до всіх модулів-компонентів, які він зачіпає, чого складно добитися, якщо вносити крізну функціональність до модулів (уручну). Реалізація автоматичної компоновки аспектів і компонентів багато в чому визначає можливості тієї або іншої аспектно-орієнтованої платформи. В даний час обговорюються два підходи до інтеграції аспектів:
Статична інтеграція на етапі компіляції
Динамічна інтеграція на етапі виконання програми