3.3.Недоліки аспектного підходу
Зараз аспектно-орієнтований підхід володіє поряд недоліків:
Не повністю пропрацювала методологія АОП-розробки програм. В даний момент закінчений компілятор, що відтестував, є тільки для декількох мов, що обмежує застосування даної технології. З іншого боку, реалізація концепцій АОП тільки на рівні мовних розширень представляється неповною і неефективною. Перспективнішим варто рахувати проникнення самих базових ідей АОП і використання їх на різних рівнях засобів розробки — мов (С++, Pascal), платформ (.NET, Java), і технологій (COM, CORBA і т.д.), по аналогії з вже традиційним використанням ООП.
Недостатньо якісна реалізація розширень мов. В даний час існуючі реалізації АОП-розширень для різних мов і платформ розрізняються по своїх можливостях, але можна виділити загальні риси: кожна реалізація АОП повинна надати механізм опису логіки крізної функціональності і механізм опису крапок програми, в яких дана логіка застосовуватиметься. Проте кожна реалізація по-своєму визначає види крапок скріплення, в яких можна застосувати аспект, а також вирішує питання їх опису, що утрудняє розуміння і використання загальних принципів АОП.
Недостатньо пропрацював механізм прив'язки аспектів до компонентів. У поширених в даний час АОП-реалізаціях точки скріплення описуються в термінах програмних конструкцій — класів, методів, полів класу. При цьому виходить тісний зв'язок між аспектом і компонентом, до якого він застосовується. Логіка прив'язки аспекту до даної точки коду виражена неявно і цілком визначається програмною конструкцією, в термінах якої побудований опис. Тісний зв'язок між аспектом і компонентом робить аспект залежним від компоненту і при цьому порушується одна з основних ідей АОП — незалежність компонентів від вживаних до нього аспектів.
3.4.Aspectj як одна з реалізацій аоп
АОП можна підтримувати в рамках вже існуючих мов. Так, зокрема, дослідницький центр Xerox PARC розробив систему ASPECTJ, підтримуючу АОП в рамках мови Java. Цей пакет вбудовується в такі системи розробки, як Eclipse, Sun ONE Studio, Forte 4J і Borland JBuilder. У даній роботі ASPECTJ був вибраний через те, що дана реалізація АОП володіє найбільш широкими можливостями.
ASPECTJ — це просте і практичне розширення мови Java, яке додає до Java можливості АОП, що надаються. Пакет ASPECTJ складається з компілятора (ajc), відладчика (ajdb), і генератора документації (ajdoc). Оскільки ASPECTJ є розширенням Java, то будь-яка програма, написана на Java, буде правильною з погляду семантики ASPECTJ. Компілятор ASPECTJ видає байт-код сумісний з віртуальною машиною Java. Оскільки як базова мова для ASPECTJ була вибрана мова Java, то він успадкував від Java всі переваги і спроектований таким чином, що буде легко зрозумілий розробникам Java. Додані розширення стосуються в основному способів завдання правил інтеграції аспектів і java-об'єктів. Дані правила виражаються в ключових поняттях ASPECTJ:
JoinPoint — строго певна точка виконання програми, що асоціюється з контекстом виконання (виклик методу, конструктора, доступ до поля класу, обробник виключення, і т.д.)
Pointcut — набір (зріз) точок JoinPoint що задовольняють заданій умові.
Advice — набір інструкцій мови java, що виконуються до, після або замість кожної з точок виконання (JoinPoint), що входять в заданий зріз (Pointcut)
Aspect — основна одиниця модульної ASPECTJ. У аспектах задаються зрізи точок виконання (Pointcut) і інструкції, які виконуються в точках виконання (Advice)
Introduction — здатність аспекту змінювати структуру Java-класу шляхом додавання нових полів і методів, так і ієрархію класу.
Pointcut і Advice визначають правила інтеграції. Аспект — одиниця, що нагадує клас в ООП, сполучає елементи pointcut і елементи advice разом, і формує модуль на зрізі системи.
Розглянемо приклад, на якому можна зрозуміти, як мова ASPECTJ реалізує принципи АОП. Як приклад візьмемо модель простого графічного редактора. Даний графічний редактор може працювати з двома типами графічних елементів — крапкою і лінією. Діаграма класів графічного редактора представлена на малюнку 8. Класи Point і Line реалізують інтерфейс FigureElement метод переміщення фігури, що містить. Операціями, що впливають на оновлення екрану, є операції переміщення фігур. Після переміщення фігури необхідно відновити зображення (Display). Оновлення зображення в даному випадку є крізною функціональністю, яка повинна викликатися за деяких умов (зміні положення фігур).
Малюнок 8. Модель графічного редактора.
Клас Line містить в собі 2 екземпляри класу Point. Класи, реалізовуючу крапку і лінію, можуть бути представлені в наступному вигляді:
class Line implements FigureElement}
_ private Point p1, p2;
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1) { this.p1 = p1; }
void setP2(Point p2) { this.p2 = p2; }
void moveBy(int dx, int dy) { ... }
}
class Point implements FigureElement {
private int x = 0, у = 0;
int getX() { return x; }
int getY() { return у; }
void setX(int x) { this.x = x; }
void setY(int у) { this.y = у; }
void moveBy(int dx, int dy) { ... }
}
Припустимо, клієнт перемістив фігуру на 2 пункти, при цьому відпрацював метод lineInst.moveBy(2,2). На схемі функцій (малюнок 9), що викликаються, можна побачити, як відбувається робота цього методу. У тілі методу moveBy, що викликається()содержится логіка по переміщенню фігури; метод має вхідні параметри, значення, що повертається, і набір інструкцій мови, серед яких знаходиться виклик аналогічного методу у двох крапок — елементів класу Line. Метод moveBy() у класу Point, також має вхідні параметри, значення, що повертається, і набір інструкцій мови. Кожна строго певна точка виконання програми, що асоціюється з контекстом виконання, з урахуванням обмежень мови ASPECTJ є JoinPoint-ом. Виконання методу moveBy() у класу Line, виклик методу moveBy у Point — є точками JoinPoint.
Малюнок 9. Схема функцій, що викликаються.
Тут необхідно ввести відмінність в термінологію точок виконання програми в рамках ASPECTJ. Точки выполения бувають двох типів — крапка виконання методу, яка є виконанням всього тіла методу, і точка виклику методу, яка є точкою безпосереднього виклику методу. Іншими словами тіло методу може бути представлене крапкою з боку клієнта або тільки виклик методу може бути представлений як крапка.
Мова ASPECTJ дозволяє описувати декілька типів подібних точок виконання програми.
Виклик методів і конструкторів
Виконання методів і конструкторів
Доступ до полів класу
Обробка виняткових ситуацій
Статична і динамічна ініціалізація класів
При виклику клієнтом методу moveBy всі точки виконання (joinPoint) знаходяться усередині потоку управління, починаючи з точки тієї, що задовольняє умові. Засобами мови ASPECTJ можна впливати на потік управління, описавши відповідний потік управління як набір точок pointcut.
Малюнок 10. Потік виконання методу moveBy.
Конструкцією мови що дозволяє описувати набір точок JoinPoint що задовольняють заданій умові є pointcut. Наприклад, call(void Line.setP1(Point)) відповідає кожній точці виконання програми, якщо вона є викликом методу з сигнатурою "void Line.setP1(Point)". При конструюванні подібних зрізів можна використовувати логічні операції &&, || і !, що дає велику гнучкість при описі наборів точок виконання програми. Зрізи крапок можуть мати ім'я, що дозволяє їх повторно використовувати при конструюванні інших зрізів і описі набору інструкцій Advice.
Advice — набір інструкцій мови java, що виконуються до, після або замість кожної з точок виконання, що входять в заданий зріз, набір інструкцій, що виконується в деякій точці виконання по певних правилах. Мова ASPECTJ дозволяє описувати подібні інструкції по наступних правилах:
before. Набір інструкцій виконується перед виконанням інструкцій що входять в описувану точку виконання.
afterreturning. Набір інструкцій виконується після повернення значення з описуваної точки виконання.
afterthrowing. Набір інструкцій виконується після виникнення виняткової ситуації в описуваній точці виконання.
after. Набір інструкцій виконується після повернення з описуваної точки виконання у будь-якому випадку.
around. Набір інструкцій виконується замість описуваної точки виконання.
Приведені правила формування набору виконуваних інструкцій в точці виконання програми дають багато можливостей при вбудовуванні крізної функціональності. При цьому складнощі, які виникають за наявності в системі крізної функціональності описані вище, зникають. При цьому в системі немає заплутаного і розосередженого коду крізної функціональності що заважає розумінню суті кожного конкретного компоненту.
Аспект — одиниця модульної ASPECTJ. У аспектах задаються зрізи точок виконання і інструкції, які виконуються в точках виконання. Аспект має схожість з класом — аспект може містити методи і поля, розширювати інші класи або аспекти або реалізовувати інтерфейси.
Далі представлено два варіанти коду даного графічного редактора — з використанням мови ASPECTJ і без нього. У варіанті без використання ASPECTJ видно, що при зміні координат фігур в методи, що відповідають за цю функціональність, вбудований код що реалізовує оновлення дисплея. У прикладі з використанням аспектного підходу класи містять код, що відповідає тільки за свою логіку. Набір інструкцій, що реалізовує крізну функціональність "оновлення дисплея" знаходиться в аспектному модулі, — aspect DisplayUpdating. На цьому прикладі наочно показана основна перевага аспектного підходу — локалізація крізної функціональності в окремих модулях і вбудовування подібної функціональності в необхідні ділянки системи.
Приклад коду графічного редактора без використання мови ASPECTJ:
class Line implements FigureElement {
private Point p1, p2;
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1){
this.p1 = p1;
Display.update(this);
}
void setP2(Point p2){
this.p2 = p2;
Display.update(this);
}
}
class Point implements FigureElement {
private int x = 0, у = 0;
int getX() { return x; }
int getY() { return у; }
void setX(int x){
this.x = x;
Display.update(this);
}
void setY(int у){
this.y = у;
Display.update(this);
}
}
Приклад коду графічного редактора з використанням мови ASPECTJ:
class Line implements FigureElement {
private Point p1, p2;
Point getP1() { return p1; }
Point getP2() { return p2; }
void setP1(Point p1){
this.p1 = p1;
}
void setP2(Point p2){
this.p2 = p2;
}
}
class Point implements FigureElement {
private int x = 0, у = 0;
int getX() { return x; }
int getY() { return у; }
void setX(int x) {this.x = x; }
void setY(int у) {this.y = у; }
}
aspect DisplayUpdating {
pointcut move(FigureElement figElt):
target(figElt)&&
(call(void FigureElement.moveBy(int, int) ||
call(void Line.setP1(Point)) ||
call(void Line.setP2(Point)) ||
call(void Point.setX(int)) ||
call(void Point.setY(int)));
after(FigureElement fe) returning: move(fe){
Display.update(fe);
}
}
При розробці програмних систем з використанням засобів мови ASPECTJ можна повністю слідувати трьом принципам розробки аспектного підходу: виділяти в окремі модулі крізну функціональність — провести аспектну декомпозицію; реалізувати кожну вимогу окремо; інтегрувати аспекти в програмний код. У прикладі з графічним редактором на етапі аспектної декомпозиції була виявлена крізна функціональність — оновлення дисплея. Дана вимога була реалізована в аспектному модулі DisplayUpdating. У цьому аспекті визначається зріз точок move(..), які включають точки виконання програми, після яких буде вбудована необхідна крізна функціональність. На малюнку 11 схемний зображений аспект, що знаходиться на зрізі моделі графічного редактора.
Малюнок 11. Аспект DisplayUpdating на зрізі системи.
Інтеграції аспектів (weaving) відбувається у момент компіляції. Модель побудови готової програмної системи при використанні компілятора ajc зображена на малюнку 12.
Малюнок 12. Інтеграція аспектів.