Аспектно-орієнтовані методи в управлінні
інформаційними потоками баз даних ДП АСУТП
Богданов Микола Костянтинович
В
класах баз даних ДП АСУТП, також як і в класах програмних систем,
спостерігається проблема ускладнення структури через необхідність підтримки в них
різних обмежень і вимог до інформаційної системи в цілому.
Використання методів аспектно-орієнтованого програмування дозволяє
відокремити засоби реалізації контрактів класів від описуваних ними абстракцій
сутностей.
Введення. Сутність аспектно-орієнтованого
програмування
Методи
об'єктно-орієнтованого аналізу і проектування дозволяють створити модель
(архітектуру) інформаційної системи; провести аналіз і створити на його основі
модель предметної області. Типізації проектних рішень служить широко
поширена концепція шаблонів, ефективні методи аналізу та
проектування можуть бути оформлені як стратегії.
Однак
при розробці програмної системи необхідно також забезпечити виконання
різних вимог до неї. Це можуть бути вимоги до безпеки
(необхідність авторизації при проведенні транзакцій клієнт-сервер), якості
обслуговування, синхронізації операцій читання/запису і забезпечення цілісності
даних та ін
Раніше
для специфікування необхідності забезпечення деяким класом певних
вимог було введено поняття контракту [14]. Однак підтримка будь-якого
вимоги, що не відноситься до суті, описуваної класом, ускладнює його
структуру, більш того, існує ряд вимог, загальних для багатьох різних
класів або не є функціональними, реалізація яких в окремих
класах виключно утруднена (такі вимоги називають "перетинають"
(crosscutting)). Потрібно введення деякого додаткового програмного
"Шару", на який було б покладено виконання "контрактних зобов'язань"
класів, абстрагуються сутності предметної області.
Для
цього, в 1997 р. групою розробників з Xerox PARC на чолі з Г. Кікзалесом
була запропонована концепція аспектно-орієнтованого програмування (АОП)
[13]. Ними було явно введено поняття аспекту, яким є те властивість
системи, яке не може бути явно реалізовано у вигляді процедури. "Аспекти
мають тенденцію не бути елементами функціональної декомпозиції системи, але
скоріше бути властивостями, які системно впливають на продуктивність або
семантику компонентів ". У цьому аспекти протилежні компонентів, "мають
тенденцію бути одиницями функціональної декомпозиції системи ". Мета АОП --
"Підтримати програміста в чіткому розподілі компонентів і аспектів один від
одного, забезпечуючи механізми, які зроблять можливим абстрагувати їх і
об'єднувати для отримання системи в цілому ". (Російською мовою концепції та
переваги АОП описані в [3 ]).
В
роботі [11] розглядається перехід від контрактного проектування до
використанню аспектів. Маючи на увазі під словом "контракт" "специфікацію
обмежень, які повинні бути дотримані деякою сутністю, яка запитує
послугу від іншої сутності ", автори вказують, що" звичайно частини проекту,
які реалізують певний контракт, "розсіяні" (scattered) по всьому
проекту ". На ті ж проблеми "розсіювання", а також на "заплутування" (tangling)
структури класів внаслідок необхідності реалізації в них механізмів
підтримки вимог, не пов'язаних з описуваними ними абстракціями, вказували
С. Кларк і Р. Уолкер [8], підкреслюючи, що "розсіювання і заплутування мають
негативний вплив на життєвий цикл розробки, з точок зору можливостей
розуміння, налагодження, розвитку, повторного використання "(класів та архітектури
системи в цілому).
Невід'ємною
частиною середовища розробки, що підтримує АТ-парадигму, також є інструмент
"Зв'язування" (weaving), що виконує генерацію результуючого програмного коду
(на етапі компіляції або навіть під час виконання) з двох, в загальному випадку
незалежних, проектів: реалізують функціональні вимоги і винесену в
аспекти логіку.
Для
успішного застосування будь-якої техніки програмування потрібно не тільки її
підтримка мовою програмування, а й можливість формалізації прийнятих
рішень на етапі проектування. З цього випливає необхідність наявності як
мінімум графічної нотації для запису моделей, як максимум - методології,
формалізує процес проектування, та підтримки нової технології в
CASE-засобах розробки.
Огляд методів моделювання аспектів
Як
зазначають автори [16], у той час як існує підтримує АТ-концепції
мова програмування AspectJ [5], відсутня реалізований мову
моделювання, що підтримує проектування AspectJ-програм. Пропозиції по
розробці подібного мови присвячена велика кількість робіт, представлених
на різних конференціях у 1998-2002 рр..
Переважна
більшість дослідників пропонують грунтуватися на існуючому стандарті
UML [2] і застосувати існуючі в ньому механізми розширення графічної нотації
сутностей і відносин (стереотипи, обмеження, помічені значення) для
опису додаткових концепцій AO-проектування.
Так,
в роботі [15] пропонується ввести три нові концепції: групи (для цілей
класифікації гетерогенних і розподілених сутностей), які перетинають відносини
(що дозволяють програмісту визначити "точки перетину" аспекту з функціональної
програмою), Аспектное класи (реалізують розширення програми в точках
перетину). Графічно це передбачає використання наявних в UML
елементів: класів і асоціацій з додаванням стереотипів "group", "pointcut",
"Aspect". Для методів аспектно класу вводяться стереотипи "before", "after",
"Around", що описують момент їхнього виклику по відношенню до виклику "перетинаються"
функцій, а також пропонується набір правил визначення та інтерпретації
семантики ролей і кратностей для перетинають відносин.
В
[12] розглядається виділення аспектів у програмній системі. Приклади діаграм
у цій роботі схожі на наведені в [15]: аспект розглядається як диспетчер
взаємодії двох взаємозалежних класів та інших, що надають деяку
функціональність. Але, на відміну від [15], в модель явно вводиться поняття "точки
перетину ", яку пропонується моделювати як варіант класу, а не як
варіант асоціації, більш детально розглянуті "точки з'єднання" - місця
взаємодії з аспектом, переривання/відновлення виконання основної
програми. "Точки з'єднання можуть бути об'єднані для побудови інтерфейсу
аспекту, також як безліч інтерфейсів в UML можуть бути об'єднані у форму
інтерфейсу класу ". Вводиться поняття парних (conjugated) точок з'єднання, у
яких відбувається виклик методів з однаковими сигнатурами, але напрямки
потоку управління протилежні (в яких управління передається аспекту і
повертається їм).
С.
Кларк і Р. Уолкер пропонують свій варіант нотації [8] для опису аспектів
засобами UML. Вони пропонують використовувати параметрізіруемие пакети (що само
по собі є непередбачуваних розширенням UML) зі стереотипом "subject",
оскільки в принципі розглядають аспекти як елементи
суб'єктно-орієнтованого проекту. Усередині пакета можуть бути розміщені
діаграми класів і взаємодії, що дозволяє графічно показати поведінка
програми після зв'язування. Такий пакет є в термінології авторів
"Композиційним шаблоном". При цьому, "параметрізіруя проектний суб'єкт і
забезпечуючи механізм для прив'язки цих параметрів до елементів моделі в інших
проектних суб'єктах, ми можемо визначити композицію перетинає поведінки з
основним проектом способом, що допускає повторне використання ". Пропонована
семантика (відношення композиції, розширюване рядком bind) оперує класами та
методами пов'язують суб'єктів.
В
[16] автори розглядають моделювання "перетинають ефектів" окремо в
структурі типів і в поведінці певної системи. Оригінальність їх підходу
полягає в пропозиції використовувати параметрізіруемие, помічені
стереотипом "introduction" кооперації для визначення властивостей (атрибутів,
операцій) і відносин кожного з "пересічний" аспекту і звичайних класів.
Параметр кооперації використовується для визначення правил зв'язування (фактично
- Інстанцірованія кооперації та її вбудовування в існуючу систему класів).
Крім цих кооперацій, в аспекту класах вводяться, незалежно від методів,
елементи зі стереотипами "pointcut" і "advice": "точки перетину" і
"Повідомлення", що визначають перетин логіки аспекту і програмної системи, і
вводять механізм перехоплення управління. Запропонована нотація базується на
концепціях мови AspectJ, але є занадто ускладненою.
Розробники
UML вказують, що "На практиці для іменування класу використовують одне або
кілька коротких іменників, взятих зі словника моделюється системи "
[2]. Аналогічно, в більшості розглянутих робіт ім'я аспектно класу
є власною мовою і показує виконувану операцію.
Крім
розглянутих вище чотирьох робіт, що пропонують опрацьовані, готові до
практичного застосування графічні нотації, є велика кількість
статей теоретичної спрямованості. Так, в [4] робиться спроба формалізувати
використання коштів розширень UML для специфікування понять
АТ-методології. Для цього використовується поняття "профілю" UML - механізму,
дозволяє описати правила використання засобів розширення мови в деякій
предметної області. Розширюючи метамоделі UML, автори визначають набір
стереотипів і їх додаток до таких елементів метамоделі, як клас і
асоціація. Автори [17] також пропонують розширити метамоделі UML для опису
аспекту класів і відносин, але основний акцент зроблений на пропозиції
заснованого на правилах XML мови розмітки для опису проектних моделей, в
Зокрема, що містять аспекти. Вигоди його введення обгрунтовуються
необхідністю наявності "нейтрального по відношенню до додатків формату" для
комунікації між розробниками, полегшенням повторного використання
описів аспектів, а також їх розподілом між різними засобами
проектування, зв'язування, кодогенераціі. Комплексним підходом відрізняється
стаття відомих розробників з IBM У. Харрісона, П. Терра і Г. Оссхера [9],
в якій вони розглядають способи, якими інформація про аспекти може бути
відображена на різних діаграмах UML. Тут же слід згадати роботи С.
Кларк [6, 7], в яких вона "представляє підхід до розробки систем,
що базується на об'єктно-орієнтованої моделі, але розширює її додаванням
нових можливостей декомпозиції ". У доповіді [10] представлений прототип
автоматизованого засоби для перетворення високорівневих моделей UML,
підтримують абстракції АОП, до низькорівневим деталізованим моделями, за
яким може бути згенерований програмний код, тобто запропоновано проводити
зв'язування на рівні моделей.
Метою
наступній частині цієї статті є дати уявлення про застосовність
АТ-методів в обробці інформаційних потоків в об'єктно-орієнтованої середовищі,
варіантом реалізації якої є об'єктна (об'єктно-ієрархічна) база
даних програмного комплексу диспетчерського пункту (ДП) АСУТП. При складанні
діаграм ми будемо дотримуватися нотації, запропонованої в [15].
Бази даних ДП АСУТП і завдання управління
інформаційними потоками
Більшість
СУБД ДП АСУТП використовують моделі набору сутностей або ієрархічну, а не
поширену в інших класах систем зберігання даних реляційну [1].
Це пов'язано з більш високою швидкодією вибірки даних, простотою
програмної реалізації, можливістю відобразити в ієрархії груп даних структуру
автоматизується виробництва, наявністю методів відносної адресації. При
використанні моделі набору сутностей область зберігання даних організована
лінійно, але проводиться упорядкування об'єктів з використанням методів
найменування, а логічні взаємозв'язки між ними з необхідністю призводять до
побудови деякого графа. Виходячи з цього, в даній роботі розглядається
клас так званих об'єктно-ієрархічних СКБД, що надають механізми
упорядкування збережених об'єктів і програмний інтерфейс маніпулювання ними.
База
даних ДП АСУТП є як приймачем, запитують дані від зовнішніх
систем, так і їх пасивним джерелом і таким чином виконує роль маршрутизатора
інформаційних потоків від систем автоматики і телемеханіки до графічних
додатків, систем комерційного обліку і планування виробництва,
експертним системам. При цьому виникають загальні для систем зберігання та обробки
даних завдання: виконання функціональних операцій; підтримку цілісності і
еквівалентності реплік даних, а також спеціалізовані - взаємодія з
підсистемою інформаційного обміну і т.п.
Реалізація функціональних операцій
Найпростіший
випадок використання аспекти - реалізація деякого функціонального
вимоги, необхідного різним (не має нічого спільного базового) класів. У цьому
випадку аспект стає схожий на статичний клас-утиліту (utility class), з
більш чітко формалізованим в проекті правилом його використання.
Для
прикладу розглянемо клас, який зберігає деяке значення і його мітку часу,
що має два поліморфних методу запису нового значення: одна з переданої
міткою часу, інший - без неї. Тоді у разі, коли мітка часу не
передана, необхідно визначити поточний час системи і записати його. Для цих
цілей введемо аспектний клас TimeStamping. Його можна показати на діаграмі
класів (мал. 1а), при цьому ми показуємо зв'язаність аспекту не з одним, а з
групою класів, об'єднує які в даному випадку тільки необхідність
отримання значення поточного часу. Те, що у прийнятій нотації група
моделюється як варіант класу, а не пакету UML, дозволяє вказати для неї
методи, маючи на увазі, що вони присутні у всіх класах, що становлять
групу. (Тут і далі ми задаємо назву групи Signal, підкреслюючи, що оперуємо
з безліччю класів, що зберігають значення деякого аналогового, дискретного,
логічного виміру; одиницю довідкової інформації або похідну від цих
значень величину). Діаграма взаємодії (рис. 1б) показує
послідовність виконуваних операцій після виконання зв'язування (генерації
програмного коду). При виклику методу SetValue (value) відбувається "перетинання";
ми показуємо це тим, що на "лінії життя" об'єкта класу Signal не відзначений
фокус управління, який спочатку переходить примірнику аспектно класу, і
тільки потім повертається ім.
Рис.
1. Реалізація функціональних операцій аспектно класом.
Інший
приклад зв'язування деякого аспекту з кожним з певного набору об'єктів у
індивідуальності - необхідність відстежувати факт зміни зберігається значення.
Перехоплення виклику методу запису нового значення дозволяє встановити прапор наявності
зміни. Програмі-серверу, обробляє запити зовнішніх систем на
одержання змінених даних, досить буде аналізувати стан даного
прапора, а не виконувати порівняння збережених копій попередніх переданих значень з
поточними.
Синхронізація
розрахунків і змін
В
базах даних ДП АСУТП часто виконуваної операцією є розрахунок
агрегованих значень; наприклад, визначення максимального значення з
безлічі або розрахунок миттєвої витрати рідини або газу, використовуючи
оперативні дані про тиск, його перепаді на діафрагму і температурі, а також
ряд заданих нормативних поправочних коефіцієнтів. У моделі ми можемо
відобразити це, встановивши асоціацію один-до-багатьох (часто відповідної
відношенню контейнер-елемент) і використавши клас-асоціацію Multiplexer (в
який закладена логіка перетворення кількох вихідних значень в одне
похідне). Об'єкти-елементи є джерелами даних для свого
контейнера, у свою чергу, деяка підсистема опитування систем автоматики
є джерелом оперативних даних для них самих. Ці взаємозв'язки можна
показати, використовуючи діаграму класів UML (див. рис. 2).
Рис.
2. Типові відносини класів БД ДП АСУТП.
В
зистема, керованої подіями, при зміні хоча б одного із значень,
беруть участь у розрахунку результату і зберігаються в об'єктах-елементах, повинен
відбуватися перерахунок формули і запис нового розрахункового значення в
об'єкт-контейнер. Розглянемо для прикладу розрахунок деякого стану за двома
вихідним логічним сигналами "відкритий", "закрите" (див. рис. 3).
Рис.
3. Варіант алгоритму перерахунку агрегованого значення.
В
розглянутому алгоритмі є упущення - перерахунок результату відбувається при
надходження першого ж зі змін. У випадку, коли відбулася зміна обох
значень, виконання проміжного розрахунку формули агрегування з
використанням одного нового і одного застарілого значення надмірно, і, швидше за
за все, помилково. При цьому ми не можемо заздалегідь стверджувати, що завжди при
надходження нового значення одного з сигналів надходить і нове значення
іншого. Т.ч., ми приходимо до вимоги відстежувати режим надходження
оновлень. Для вирішення цього завдання можна запропонувати блокувати джерелом
даних передачу повідомлень про зміну значень в об'єктах-елементах на період
запису всього безлічі надійшли оновлених значень. Тоді про події
зміні надійдуть в клас-контейнер після запису обох нових значень і розрахунок
буде виконано два рази, але з актуальними даними. (Будучи впевненим, що при надходженні
перші ж з повідомлень актуальні обидва значення, можна скоротити кількість
перерахунків до одного).
Однак
проблема залишається, якщо джерело даних - не один об'єкт, а безліч, і на
діаграмі ми розглядаємо зв'язок "багато-ко-многим". (Завдання часто виникає
при реалізації суб'єктно-орієнтованого підходу до проектування бази даних
ДП АСУТП, при якому вводиться безліч класів, що містять набори
нормативно-довідкових даних, що описують один і той же виробничий об'єкт
при різних точках зору (принципи декомпозиції предметної області), але
яким потрібно розділяти оперативні дані про його стан). Передача
(копіювання) даних з джерел одержувачам призводить до необхідності
фіксації результатів.
Тут
ми приходимо до класичної ситуації введення аспекти - реалізація в окремому
класі-джерелі або одержувача даних алгоритму відстеження взаємодії
інших пар об'єктів і синхронізації з ними виключно утруднена. Мета --
забезпечити синхронізацію оновлення даних; бажане поведінка аспекти --
реалізувати "конвеєрну передачу" оновлень по рівнях ієрархії і між
піддерев БД.
Рис.
4. Введення аспекту TransferSynchronizing для управління передачею даних.
Спочатку
визначимо "точку перетину". Вона одна - аспект перехоплює управління при
спробі виконання яких-небудь з об'єктів-джерел запису одного або
декількох нових значень; блокує обробку нових значень в
об'єктах-одержувачів, дає завершитися перехоплених методам SetValue (...), після
чого чекає протягом заданого інтервалу часу виконання аналогічних
дій іншими об'єктами-джерелами (див. рис. 4). Після закінчення часу
очікування відбувається розблокування всіх об'єктів-одержувачів, у які були
записані нові значення. Дана логіка показана на рис. 5; ставлення
"Багато-ко-многим" класів-джерел та одержувачів даних розглядається як
безліч відносин "один-ко-многим" їх примірників. (Ми розглядаємо
безлічі об'єктів - примірників деяких класів, об'єднані в дві групи
по їх ролі у приватному інформаційному взаємодії: джерел та одержувачів
даних; стереотипи "source" і "receiver" є похідними від базового
"Group". Імена груп (при відмінності стереотипу) співпадають, що підкреслює
однаковість що входять до них класів).
Рис.
5. Виконання передачі даних при введеному аспекті TransferSynchronizing.
Відзначимо,
що не потрібно вводити точку перетину з класом-одержувачем даних,
оскільки немає необхідності перехоплювати всі виконувані виклики зміни
даних у ньому, а також використання стереотипу "around" для методу OnSetValue ()
аспектно класу: частина службових операцій виконується до виконання виклику
SetValue (...), частина - після. Запропоноване рішення все ще містить низку
недоліків: об'єкт-джерело залежимо від реалізації об'єкта-одержувача; введення
періодів очікування погано узгоджується з подієвої моделлю; об'єкт-одержувач
повинен перевіряти попадання різниці нового і попереднього значень в "зону
нечутливості "; його структура ускладнюється засобами підтримки блокувань.
Можна запропонувати варіант, вільний і від даних недоліків.
Для
цього визначимо, що у кожної групи є менеджер - примірник аспектно
класу, що виконує контракти кожного з класів групи, в т.ч. і виклик методу
SetValue (...) для запису зміненого значення в клас-одержувач. Це дозволяє
також виконувати операції блокування/розблокування тільки по відношенню до
цього аспектно класу. На нього ж може бути перекладене виконання перевірки
"Суттєвості" відмінності нового значення від поточного в об'єкті. Тоді бажане
поведінка, що реалізує транзакційний підхід до передачі масиву даних, можна
відобразити у вигляді: діаграми (див. рис. 6). (На діаграмі показано
взаємодію тільки двох груп, хоча, зрозуміло, об'єкти і навіть єдиний
об'єкт групи-джерела може бути записувати дані в кілька об'єктів,
в т.ч. що належать різним групам.) Оскільки, як зазначалося вище, кожна
з груп може грати роль як джерела, так і одержувача даних, то на
діаграмі класів достатньо показати зв'язок аспекту і однієї групи (див. рис.
7а).
Діаграма,
що показує внутрішню логіку аспекту при розблокуванні, наведено на рис.
7б. Відзначимо, що можливе одночасне блокування групи декількома
менеджерами груп-джерел: запис різних даних в один і той самий об'єкт у
будь-якому випадку не має сенсу, а одночасний запис значень в різні
об'єкти заблокованій групи кількома джерелами не призводить ні до яких
негативних наслідків.
Рис.
6. Виконання передачі даних при введеному аспекті GroupManager.
Рис.
7. Структура і внутрішня логіка аспектно класу GroupManager.
Взаємодія
з підсистемою інформаційного обміну
Взаємодія
"Об'єкт БД - модуль інформаційного обміну з зовнішніми системами (далі - сканування)"
в ряді баз даних ДП АСУТП налаштовується за використанням "списку сигналів": у
табличній формі об'єднуються індивідуальні параметри опитування кожного сигналу
(тип даних, адреса в контролері, періоди періодичних опитувань значень і
змін і т.і.). В інших системах дана параметрична інформація
зберігається в самому об'єкті БД. Обидва цих підходу володіють тим недоліком, що
не використовують природно напрошується припущення про однаковості
параметрів (комунікаційних, перетворення "сирих" даних) для однотипних
об'єктів БД, тобто екземплярів одного класу. Тому в даному випадку аспектний
клас використовується як розширник структури класу БД (це зазначено ставленням
залежності зі стереотипом "extend"): він містить таблиці відповідностей класу і
параметрів сканування, класу і правил перетворення отриманих даних, а
також список відповідностей індивідуальних об'єктів і адрес в зовнішній системі
(або правила отримання адрес на ім'я об'єктів).
З
іншого боку, від різних модулів сканування потрібно забезпечувати
однотипне поведінка за певних подіях; наприклад, якість значень
всіх об'єктів БД, що отримують дані від зовнішньої системи, з якої втрачено
зв'язок, має бути встановлено в "недостовірне". Аспектное клас "перетинає"
операції модуля сканування, результати яких впливають на інші об'єкти БД, і
реалізує однакову логіку для різних додатків інформаційного обміну.
Висновок
Ієрархія
класів відображає рівні абстракції сутностей предметної області, ієрархія
об'єктів (у БД ДП АСУТП) є інформаційною моделлю автоматизується
виробництва, технологічного процесу. Для відображення різних точок зору
можливо поділ класів і побудову кількох подмоделей, використовуючи
різні принципи декомпозиції. Застосування методів аспектно-орієнтованого
програмування дозволяє відокремити засоби реалізації контрактів кожного з
класів (механізмів підтримки в них різних обмежень і вимог до
інформаційній системі в цілому) від описуваних ними абстракцій сутностей, за
рахунок чого підвищити ступінь надійності БД, продуктивність обробки і
передачі даних, можливість повторного використання проектних рішень.
Рис.
8. Налаштування взаємодії та обробка подій підсистеми інформаційного
обміну.
Список літератури
Богданов
Н.К. Тиражовані програмні комплекси для створення АСУТП.// Промислові АСУ
і контролери. 2000. № 12. - С. 35-39
Буч
Г., Рамбо Д., Джекобсон А. Мова UML. Керівництво користувача. М.: ДМК Пресс,
2000. - 432 с.
Шукла
Д., Селлз С.Ф.К. АОП: Більш ефективна інкапсуляція і повторне використання
коду.// MSDN Magazine/Русская редакция. 2002. Спецвипуск
№ 1.
Aldawud, O., Elrad, T., Bader, A. A
UML Profile for Aspect-Oriented Modeling. In proc. of Aspect-Oriented
Programming Workshop at OOPSLA, 2001.
AspectJ Home Page.
http://www.aspectj.org
Clarke, S. Composing Design Models:
An Extension to the UML. In proc. of International Conference on the UML, 2000,
pp. 338-352.
Clarke, S. Extending Standard UML
with Model Composition Semantics.// Science of Computer Programming. Vol. 44,
Issue 1 (July 2002), pp. 71-100
Clarke, S., Walker, R. Composition
Patterns: An Approach to Designing Reusable Aspects. In proc. of ICSE 2001.
Harrison, W., Tarr, P., Ossher, H. A
Position On Considerations in UML Design of Aspects. In proc. of Workshop on
Aspect-Oriented Modeling with UML at AOSD, 2002.
Ho, W., Pennaneac'h, F., Jezequel,
J., Plouzeau, N. Aspect-Oriented Design with the UML. In proc. of
Multi-Dimensional Separation of Concerns Workshop at ICSE, 2000, pp. 60-64
Jezequel, J., Plouzeau, N., Weis,
T., Geihs, K. From Contracts to Aspects in UML Designs. In proc. of Workshop on
Aspect-Oriented Modeling with UML at AOSD, 2002.
Kande, M.M., Kienzle, J.,
Strohmeier, A. From AOP to UML - A Bottom-Up Approach. In proc. of Workshop on
Aspect-Oriented Modeling with UML at AOSD, 2002.
Kiczales, G., Lamping, J.,
Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J., Irwin, J. Aspect-Oriented
Programming. In proc. of ECOOP, 1997, LNCS 1241, pp. 220-242
Meyer, B. Object-Oriented Software
Construction. New-York, NY: Prentice Hall, 1988.
Pawlak,
R., Duchien, L., Florin, G., Legond-Aubry, F., Seinturier, L., Martelli, L. A
UML Notation for Aspect-Oriented Software Design. In proc. of Workshop on
Aspect-Oriented Modeling with UML at AOSD, 2002.
Stein,
D., Hanenberg, S., Unland, R. Designing Aspect-Oriented Crosscutting in UML. In
proc. of Workshop on Aspect-Oriented Modeling with UML at AOSD, 2002.
Suzuki,
J., Yamamoto, Y. Extending UML with Aspects: Aspect Support in the Design
Phase. In proc. of
Aspect-Oriented Programming Workshop at ECOOP, 1999.
Інтернет
Workshop on Aspect-Oriented Modeling
with UML at AOSD'02. http://lglwww.epfl.ch/workshops/aosd-uml/papers.html
Workshop on Multi-Dimensional
Separation of Concerns (ICSE 2000)
http://www.research.ibm.com/hyperspace/workshops/icse2000/papers-index.htm
Aspect-Oriented Software Development
http://www.aosd.net/
Aspect-Oriented Programming
http://www.c2.com/cgi/wiki?AspectOrientedProgramming
Для
підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/
