Підтримка АОП впродовж життєвого циклу ПС

Середовище CME (Concern Manipulation Environment) (http://www.research.ibm.com/ cme/) надає інструменти розроблення, маніпулювання та еволюції аспектно-орієнтованих ПС впродовж їхнього ЖЦ. Розробляється як відкритий проект Eclipse. Пропонує споживачам загальну платформу, в якій можуть взаємодіяти й інтегруватися різні інструментальні засоби аспектно-орієнтованого розроблення ПС (AOSD, від Aspect-oriented software development), забезпечуючи кінцевих користувачів потужним зручним середовищем програмної інженерії, а розробників і дослідників більш потужними будівельними блоками для побудови нових інструментів і парадигм.

Архітектура СМЕ включає чотири шари (рис. 3.2):

Рисунок 3.2. Діаграма реалізації середовища СМЕ

1) колекція інструментів кінцевого користувача, які підтримують розробників у аспектно-орієнтованій програмній інженерії впродовж усього ЖЦ. Інструменти налаштовуються на виконання конкретних задач (наприклад, створення варіантів або додавання характеристик), стадії ЖЦ, артефакти (наприклад, проект, UML-діаграми, початковий або двійковий код Java тощо), підхід AOSD (наприклад, AspectJ, Hyper/J, фільтри композицій тощо), а також середовища (наприклад, Eclipse);

2) колекція компонентів, які забезпечують більшість з високо-рівневих можливостей, потрібних інструментам кінцевого користувача. Компоненти зазвичай незалежні від задачі, стадії ЖЦ, AOSD-підходу або середовища і можуть до них адаптуватися. Прикладами є: засоби аналізу, збереження артефактів, рефакторінг компонентів, можливості композиції;

3) колекція фреймворків, які забезпечують незалежний від мови та AOSD-підходу доступ до низько-рівневого подання завдань і можливостей маніпулювання, і які підтримують технологію плагінів щодо використання різних двигунців ще нижчого рівня.

4) колекція двигунців, які встановлюють залежний від мови та AOSD-підходу доступ до низько-рівневого подання завдань і можливостей маніпулювання.

Аналіз вимог і проектування архітектури. Поняття «Ранні Аспекти» охоплює підходи аспектно-орієнтованої інженерії вимог і проектування архітектури, які розвиваються у Португалії А. Рашидом та П.Савьєром [10–14]. У [11] їх явно вирізняють як аспекти на найвищому рівні абстракції (рис. 3.3).

Рисунок 3.3. Класифікація рівнів розгляду аспектів

Ранні аспекти є наскрізною функційністю (характеристиками, властивостями, об’єктами інтересу, сферами відповідальності, під проблемами) [11], яка ідентифікується на ранніх стадіях розроблення ПС, включаючи аналіз вимог, аналіз ПрО та архітектурне проектування. Наскрізна функціональність (наскрізні функції, crosscutting concerns) визначаються у [11] як проблемно-орієнтовані поняття, які не вкладаються в об’єктну абстракцію. Функціональність є наскрізною (concern is crosscutting), коли вона або її частина робить внесок у виконання множини функцій (concerns). Перетин (crosscutting) виникає, коли встановлюється зв'язок двох абстракцій (сrosscutting arises when two abstractions relate).

Ранні аспекти стосуються модуляризації аспектних вимог, ідентифікації їхнього впливу на інші вимоги (аспекти нижчих рівнів) в системі, досягнення критичних компромісів між аспектними вимогами до початку побудови архітектури і визначення їхнього відображення і впливу на артефакти на пізніших стадіях розроблення ПС. Зазначається обопільно корисний взаємозв’язок аспектно-орієнтованої парадигми розроблення ПС та доменної інженерії, причому АOSD розглядається як можлива технологія виконання доменної інженерії.

Інструментальну підтримку АОП інженерії вимог забезпечує ARCADE (Aspectual Requirements Composition and Decision Support Tool). Інструмент дозволяє визначати контекстні вимоги (viewpoint requirements), аспектні вимоги і правила композиції, використовуючи передбачувані для цього шаблони (темплейти). Шаблони можуть бути активовані за допомогою XML схем. Модулі, що інкапсулюють різноманітні вимоги і правила композиції, зберігаються в eXist – СКБД для XML. Комбінація DOM (Document Object Model, Об'єктної Моделі Документа) і SAX (Simple API for XML, Простий API для XML) служать, по-перше, для перевірки правильності правил композиції, тобто для гарантування того, що вони посилаються на контекстні і аспектні вимоги, які існують в базі даних; а по-друге – для композиції аспектів і контекстів та ідентифікації конфліктів задля досягнення компромісів.

Схема інтеграції елементів АОП до підходу MDD подана на рис. 3.5.

Рисунок 3.5. Схема інтеграції АОП та MDD

Покращена платформа реалізації СПС, розроблена в рамках проекту AMPLE, включає набір інструментів для підтримки MDD – openArchitectureWare та аспектно-орієнтовану мову ECaesarJ.

Набір інструментів openArchitectureWare розширений аспектно-орієнтованими технологіями, які припускають роботу з аспектами на всіх стадіях процесу MDD, зокрема: XWeave – для роботи з аспектами на рівні моделей, Xpand та Xtend – для аспектно-орієнтованої декомпозиції «модель-модель» та «модель-текст». АО-технології в процесі MDD припускають модульність варіантів на різних рівнях абстракції.

Мова ECaesarJ (http://caesarj.org/downloads/ecaesarj/latest/) припускає гнучку модуляризацію варіантів у характеристиках (feature-oriented variation) на рівні реалізації [16]. Опис названих інструментів та доступ до них забезпечено на сайті http://ample.holos.pt/pageview.aspx?pageid=80&langid=1.

Аспектно-орієнтоване моделювання архітектури. Еталонна архітектура подана на рис. 3.7. База є одиницею модульності, яка формалізує інтереси, що не перетинаються, а Аспект – формалізує інтереси, які перетинаються (crosscutting concern).

Композиція Аспектів і Бази утворює Переплетіння (weaving). Аспект складається з опису того, як адаптувати Задачу (concern), Точки приєднання (pointcut) і необов’язкової Відносної позиції, яка описує, де треба адаптувати Задачі. Мова визначає поняття, необхідні для формалізації Задач.

Задачі формалізуються за допомогою елементів певної мови. Такі елементи є або структурними, або поведінковими. Адаптація специфікує, яким чином адаптується структура або поведінка Задачі (розширюється, замінюється або видаляється). Це поняття подібне до фрагменту вставки (advice). Структурна адаптація включає в себе структурні елементи мови для адаптування задач. Аналогічно, поведінкова адаптація включає в себе поведінкові елементи мови для адаптування задач.

Висновок. У розділі визначено історичні витоки та основні елементи парадигми аспектно-орієнтованого програмування, розглянуто доступні інструменти АОП. Зроблено огляд підходів до моделювання аспектів та засобів їх програмної підтримки впродовж ЖЦ ПС, зокрема, «Ранні аспекти» для аналізу вимог і проектування архітектури ПС.

Запропоновано до використання такі підходи аспектно-орієнтованої інженерії СПС:

– аспектно-орієнтована керована моделями інженерія СПС (за проектом AMPLE, Aspect-oriented Model driven Product Line Engineering);

– аспектно-орієнтоване проектування архітектури СПС (за проектом AOPLA, Aspect-Oriented Product Line Architecture design approach).

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Основні елементи парадигми АОП	\|	Методичні аспекти АОП

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.