Embed Size (px)
Citation preview
ТЕХНИЧЕСКИ УНИВЕРСИТЕТ – СОФИЯСПЕЦИАЛИЗИРАНО ЖУРИ ПО ЕЛЕКТРОННА И
КОМПЮТЪРНА ТЕХНИКА
маг. инж. Марио Георгиев Павлов
АСПЕКТНО-ОРИЕНТИРАН СОФТУЕРЕН ДИЗАЙН И
АНАЛИЗ
АВТОРЕФЕРАТ
НА ДИСЕРТАЦИОНЕН ТРУД
ЗА ПОЛУЧАВАНЕ НА ОБРАЗОВАТЕЛНАТА И НАУЧНА СТЕПЕН
“ДОКТОР”
Научна специалност: „Системно програмиране”
София, 2013 г.
ТЕХНИЧЕСКИ УНИВЕРСИТЕТ – СОФИЯСПЕЦИАЛИЗИРАНО ЖУРИ ПО ЕЛЕКТРОННА И
КОМПЮТЪРНА ТЕХНИКА
маг. инж. Марио Георгиев Павлов
АСПЕКТНО-ОРИЕНТИРАН СОФТУЕРЕН ДИЗАЙН И
АНАЛИЗ
АВТОРЕФЕРАТ
НА ДИСЕРТАЦИОНЕН ТРУД
ЗА ПОЛУЧАВАНЕ НА ОБРАЗОВАТЕЛНАТА И НАУЧНА СТЕПЕН
“ДОКТОР”
Научна специалност: „Системно програмиране”
Научен ръководител: доц. д-р инж. Даниела Гоцева
София, 2013 г.
Дисертационният труд се състои от пет глави. Текстът е написан на 143страници и съдържа 26 фигури, 7 таблици и 1 диаграма. Цитирани са 130литературни източника и Internet страници. Номерата на фигурите и таблицитев автореферата съвпадат с тези от дисертацията.
Дисертационният труд е обсъден и насочен за защита на разширенозаседание на катедра „Компютърни системи” към Факултет по компютърнисистеми и управление на Технически университет – София, състояло се на 20май 2013 год.
Защитата на дисертационния труд ще се състои на 07.10.2013г. oт 14:30часа в зала 1434 на I блок на Технически Университет–София.
Материалите по защитата са на разположение на интересуващите се вканцеларията на Факултета по „Комютърни системи и управление”, стая 1443а,I блок на Технически Университет-София.
Автор: Марио Георгиев ПавловЗаглавие: Аспектно-ориентиран софтуерен дизайн и анализ
3
ОБЩА ХАРАКТЕРИСТИКА НА ДИСЕРТАЦИОННИЯ ТРУДЦел и задачи на изследванетоЦелта на дисертационния труд е да се анализира значението на термина„софтуерен дизайн“ и да се предложат и анализират подходи за прилагане нааспектно-ориентирано програмиране за силно модуларизиране и цялостно,дългосрочно подобряване на софтуерни дизайни. За изпълнение на тази цел садефинирани следните задачи:
1. Да се дефинира терминът „софтуерен дизайн“. Да се изследват ианализират принципите на добър софтуерен дизайн. Да се анализиратпричините за влошаване на софтуерния дизайн и да се дискутиратефектите от следването на принципите на добър софтуерен дизайн върхупроцесите по влошаване на дизайна на софтуерни системи.
2. Да се анализират често срещани дизайн-проблеми и техните утвърденирешения. Да се изследват възможности и подходи за подобряване насъществуващите решения.
3. Да се изследват и анализират аспектно-ориентираните системи. Да сеанализират възможностите за прилагане на аспектно-ориентиранопрограмиране за модуларизиране и цялостно, дългосрочно подобряванена софтуерни дизайни.
4. Да се разработят аспектно-ориентирани решения и дизайн-шаблони заважни, често срещани дизайн-проблеми.
5. Да се експериментира с аспектно-ориентирани имплементации науправление на зависимости и налагане на дизайн-политики и правила.
6. Да се разработи експериментална, аспектно-ориентирана методология надизайн, чрез която да могат да се синтезират дизайни за реални проблеми.
Структура на дисертационния трудДисертационният труд е оформен в 5 глави, от които въведение, обзорна част,основна част, заключение със справки за приносите, списък на публикациите ибиблиография. Общият обем на работата е 143 страници, включващи текст, 26фигури, 7 таблици и 1 диаграма. Цитирани са 130 литературни източника иInternet страници. Номерата на фигурите и таблиците в автореферата съвпадат стези от дисертацията.
4
СЪДЪРЖАНИЕ НА ДИСЕРТАЦИОННИЯ ТРУДГлава 1. ВЪВЕДЕНИЕ В АСПЕКТНО-ОРИЕНТИРАНО ПРОГРАМИРАНЕ И СОФТУЕРЕН ДИЗАЙН
1.1. Какво е парадигма на програмиранеПарадигма на програмиране е фундаментален стил на компютърно
програмиране. Съществуват три основни категории парадигми напрограмиране:
• декларативно програмиране• императивно програмиране• структурно програмиране
От своя страна, всяка категория дефинира поне една основна парадигма напрограмиране [1]. Виж таблица 1.
Декларативнопрограмиране
Императивнопрограмиране
Структурнопрограмиране
Функционалнопрограмиране
Процедурнопрограмиране
Обектно-ориентиранопрограмиране
Логическопрограмиране
Таблица 1: Основни парадигми на програмиране.
Различните парадигми на програмиране имат различни концепции за това как сепредставят програмните структури и абстракции (функции, променливи и т.н.).Парадигмите, освен това, се различават и по начина, по който се изчисляватизрази или се пренасят данни.
1.2. Преглед на основните парадигми на програмиране.Функционалното програмиране разглежда процеса на изчисление като
оценка на математически функции. При тази парадигма се избягва промяна всъстоянието на данните.
Логическото програмиране използва математическата формална система„first-order logic“ [2] за програмиране или, с други, думи използва изричнаматематическа логика за програмиране.
Процедурното програмиране описва стъпките, които трябва да сеизвършат, за да се стигне до желано състояние на програмата.
Обектно-ориентираното програмиране използва класове, които дефиниратполета от данни и функции (методи). Инстанциите на тези класове се наричатобекти и могат да си взаимодействат.
Към момента са известни повече от 60 парадигми на програмиране, катоповечето са подразделения на гореспоменатите основни парадигми. Една отпоследните разработени парадигми на програмиране е аспектно-ориентирано
5
програмиране. Този стил може да се разглежда като подразделение на обектно-ориентираното програмиране. Фигура 1 показва дървовиден изглед на връзкитемежду различните парадигми на програмиране.
Целта на аспектно-ориентираното програмиране е да се улесни отделянето нафункционалност, чието естество е такова, че е вплетена във всички главнимодули на програмата. Терминът за такъв тип функционалност е „cross-cuttingconcern“ или „второстепенен модул“. Чрез аспектно-ориентирано програмиране„cross-cutting concerns“ се отделят в специални програмни конструкции,наречени аспекти.
Основния ефект, който „cross-cutting concerns“ имат върху дизайна на еднософтуерно приложение е да намаляват модуларността, а ефектите, които иматвърху имплементацията на приложението са, така наречените, „code scattering“[4] и „code tangling“ [4]. Това са термини, които описват разпръснат код(дублиран код) и заплетен код (значителни зависимости между подсистеми)респективно.
Глава 2. ОБЗОР И АНАЛИЗ НА ДОСЕГАШНИТЕ ИЗСЛЕДВАНИЯ В
6
Фигура 1: Йерархия на парадигмите на програмиране.
Декларативно програмиране
Императивно програмиране
Структурно програмиране
Функционално програмиране
Логическо програмиране
Процедурно програмиране
Обектно-ориентирано програмиране
Аспектно-ориентирано програмиране
ОБЛАСТ СОФТУЕРЕН ДИЗАЙН.2.1. Принципи на софтуерен дизайн.Какво е софтуерен дизайн? Под термина „софтуерен дизайн“ се има
предвид архитектурата на модулите и техните взаимовръзки в рамките на еднософтуерно приложение. От техническа гледна точка това означава статичнатаструктура на пакети, компоненти и класове [28, 29].
За да може да се направи адекватна оценка на аспектно-ориентиранотопрограмиране и облагите от него, е необходимо да се изяснят основнитеконцепции, които са приети и които водят до добър софтуерен дизайн и тяхнотоотношение към аспектно-ориентираното програмиране. Тъй като обектно-ориентираното програмиране е доминиращата парадигма с общопредназначение, през последните няколко десетилетия принципите, свързани собектно-ориентиран дизайн, са много добре развити и доказани в практиката.Съществува една популярна група принципи под названието „SOLID“ [7]. Тясъдържа пет принципа, дефинирани от Robert C. Martin. Виж таблица 3.
Инициал Название (Акроним) Концепция
S Single responsibilityprinciple (SRP)
Един клас трябва да има само еднаотговорност. [8]
O Open/closed principle(OCP)
Един клас трябва да е отворен заразширение и затворен за промяна. [9]
L Liskov substitutionprinciple (LSP)
Обектите в една програма трябва да сазаменими с техните наследници без товада променя поведението на програмата.
[10]
I Interface segregationprinciple (ISP)
Множество специфични интерфейси сапо-добри от един интерфейс с общо
предназначение. [11]
D Dependency inversionprinciple (DIP)
Зависимостите трябва да са спрямоабстракции, а не спрямо имплементации.
[12]
Таблица 3: Принципи на дизайн от групата „SOLID“.
Когато тези принципи са приложени заедно се предполага, че резултатът е чистсофтуерен дизайн, който лесно може да се поддържа и разширява.
2.2. Признаци за лош софтуерен дизайн.Първоначално повечето софтуерни проекти стартират с чист и хубав
дизайн, някои дори успяват да запазят това през първоначалната имплементациячак до изкарване. Постепенно започват да се появяват „грозни“ елементи в кода.В началото тези грешки са незначителни, но постепенно се натрупват и
7
акумулират докато се стигне до момент, в който целия дизайн е доминиран отгрозни, неясни, непохватни и неефективни парчета код. Дизайна на програматасе превръща в безформена и неадекватна купчина програмни конструкции, вкоито привидно няма ред и смисъл. Резултатът от това е програма, която многотрудно се поддържа и изисква много усилия, за да се направи и най-малкатапромяна. Такова състояние на софтуерна система води до силното желание нанейните автори да се направи редизайн. Това означава да се създаде нов дизайни да се имплементира, а старата програма да се изхвърли. Този тип дейнострядко е успешен. Причината е, че докато се работи по новия дизайн, стариятпродължава да се развива и новият трябва постоянно да го гони. Това води и довлошаване на новия дизайн. Накрая, (след много повече време, от- колкото епланирано първоначално [45]) новият дизайн е готов, но е в толкова лошосъстояние, че авторите му искат нов редизайн [48].
Има четири основни признака, които показват че дизайнът севлошава/гние [7]:
• Скованост (rigidity) – когато програмата е в такова състояние, че простипромени се правят трудно. Промяна в един модул налага промяна в другмодул, която налага промяна в друг модул и т.н. Така промяна, коятонормално би трябвало да може да стане за два дни, отнема седмици. Товаводи до нежелание от страна ръководителите да се правят промени, коитоне са абсолютно наложителни.
• Чупливост (fragility) – този признак е свързан със сковаността. Това е,когато промяна в една част от системата предизвиква проблеми в другичасти, непряко свързани с нея. Когато чупливостта се увеличава,вероятността да се появят проблеми нараства експоненциално, докато сесе стигне до момента, в който всяка поправка на проблем (bug)предизвиква нови проблеми. Това прави приложението невъзможно заподдържане.
• Неподвижност (immobility) – когато е трудно или невъзможно повторнода се използва код. Ако се установи нужда от функционалност, която вечее налична в някой модул от друг (или същия) проект, но този модул носисъс себе си прекалено много зависимост (багаж). Тогава усилиетомодулът да се въведе там, където е нужен, е прекалено голямо и тазифункционалност просто се имплементира отново.
• Вискозност (viscosity) – когато има нужда от промяна, обикновено могатда се намерят множество начини тя да се осъществи. Начините могат дасе разделят на два вида: промени, които запазват дизайна и промени,които не го запазват. Ако възможностите за промени, които запазватдизайна, са значително по-трудни за осъществяване, тогава се наблюдавависока вискозност.
По тези четири признака надеждно може да се определи дали дизайнът гниеили се разпада. Причината това да се случва е съвсем ясна: необходимостта отпромени. Ако една програма никога не се променя, то нейния дизайн никога
8
няма да деградира. Особено благоприятни условия за влошаване на дизайна сакратки срокове, за които трябва да се извърши дадена промяна; инженери, коитоне са наясно с първоначалния дизайн и такъв тип промени, за които не епомислено в първоначалния дизайн на системата [47]. Най-често, промени,свързани със зависимостите в една система, причиняват всички тези проблеми.Четирите признака за влошен дизайн са директно или индиректно причинени отпромени, свързани със зависимостите между модули. Затова е необходимо да сеспазват определени принципи, така че да може лошите последствия от променипо програмата да се сведат до минимум или да се елиминират напълно.
Глава 3. OСНОВИ НА АСПЕКТНО-ОРИЕНТИРАНОТО ПРОГРАМИРАНЕ.
3.1. Анатомия на аспектно-ориентирана система.Аспектно-ориентираното програмиране е отделна парадигма на
програмиране. За да може тя да се прилага, е необходимо да има нейнареализация. Такава реализация се състои от език за програмиране иинструменти, свързани с него. Както всеки програмен език, имплементациятана аспектно-ориентирано програмиране се състои от две части [119, 127]:
• Спецификация на езика за програмиране – описва програмнитеконструкции и синтаксиса, чрез който се изразяват.
• Имплементация на езика за програмиране – набор от инструменти, коитопроверяват коректността на изходния код и го превеждат до изпълнимкод.
Реализацията на аспектно-ориентирана система трябва да специфицира език заимплементиране на индивидуални модули и „weaving“ правила.Бележка: терминът „weaving“ означава - вплитането на връзки/дефиницииили извиквания към класове и методи, които не са налични в изходния кодпървоначално, в случая с аспектно-ориентираното програмиране. Товавплитане се осъществява чрез определени правила.Имплементацията на аспектно-ориентиран език трябва да поддържа поне двеосновни операции: да комбинира модулите на системата, съобразнодефинираните „weaving“ правила, и да създава изпълними файлове на базата натези модули. Има два основни варианта това да се постигне. Първият вариант е,когато системата е напълно хомогенна, и тези две операции не са техническиразделени. Такива системи към момента не съществуват, но се очаква в бъдещесистемите да са такива. Втори вариант е, когато аспектно-ориентираният езиксе явява като разширение на вече съществуваща технология. При този вариантима три начина за изпълнение на гореспоменатите операции:
• „source-to-source“ транслация (source weaving) – връзки/дефиниции иизвиквания се вмъкват директно в изходния „source“ код и резултатът паке изходен „source“ код, който вече съдържа кода, свързан свторостепенните модули, съгласно „weaving“ правилата. След това, тозикод се компилира до изпълним код, използвайки стандартните
9
инструменти на главния език.• Бинарна транслация (binary weaving) - изходния код на главните и
второстепенните модули се компилира, използвайки стандартнитеинструменти на главния език, и резултатът се подава на инструмента завплитане (weaving) на аспектно-ориентирания език, който вплитадефинициите и извикванията директно в бинарния код.
• Транслация по време на зареждане (load-time weaving) – конфигурация наначина, по който приложението работи. По време на самото зареждане,точно преди да стартира нормалната работа, дефинициите и извикваниятадиректно се вплитат в паметта.
Всички съществуващи аспектно-ориентирани системи, в момента, използватвтори вариант. Логическа схема на аспектно-ориентирана система е показана нафигура 18.
Една от сновните идеи на аспектно-ориентираното програмиране е да помага замодуларизиране на „cross-cutting“ функционалности. Същото правят и многодруги технологии като инструменти за манипулиране на бинарен код, „proxydesign pattern“, метапрограмиране и други. Затова трябва да се дефиниратхарактеристиките, които правят една система аспектно-ориентирана, така че даможе да се различават аспектно-ориентираните системи от останалитетехнологии. Пълна аспектно-ориентирана система поддържа следнитеконцепции:
• „join point“ - системата излага точки по време на нейното изпълнение.Тези точки включват: изпълнение на методи, създаване на обекти,хвърляне на изключения и други. Всички системи имат „join points“ -
10
Фигура 18: Схема на вплитане на модули.
Главни модули (core concerns)
Второстепенни модули (cross-
cutting concerns)
Аспектно-ориентиран компилатор (weaver)
Крайно приложение
готово за изпълнение
дори, тези които не поддържат аспектно-ориентирано програмиране.Обаче, аспектно-ориентираните системи формално ги дефинират икатегоризират.
• „pointcut“ - конструкция за избиране на „join points“. Имплементиранетона „cross-cutting“ функционалност изисква избирането на точки отизпълнението на програмата (join points). В примера с проследяването сеизбират всички публични методи в програмата, за да се проследиизпълнението ѝ. „Pointcut“ конструкциите избират точки от програмата(join points), които отговарят на определени критерии. Това е подобно наSQL и избирането на редове от таблица, съгласно „where“ клаузата.„Pointcut“ конструкциите могат да са вложени така, че да се формиратсложни критерии. Освен това, те предоставят достъп до контекста наизпълнението на програмата в определена точка. Например, могат да сеприхващат параметрите на методите, които се изпълняват. Концепцията за„join point“ заедно с „pointcut“ конструкцията формират, така наречения,„join point model“ на една аспектно-ориентирана система.
• „advice“ - конструкция за промяна изпълнението на точка от програмата.Тази конструкция се използва заедно с „pointcut“ конструкцията и служиза добавяне или подмяна на поведението на точките, избрани чрез„pointcuts“. Това е известно още като „dynamic cross-cutting“. „Advice“конструкциите са три вида:◦ „before advice“ - добавя поведение, преди изпълнението на избраната
точка◦ „after advice“ - добавя поведение след изпълнението на избраната точка◦ „around advice“ - добавя или подменя поведението около избраната
точка; може да изпълни операцията, свързана с избраната точка нулаили повече пъти
• „inter-type declaration“ - конструкции за промяна статичната структура насистемата. Това са конструкции за добавяне или проверка на декларации.В примера с проследяването на програмата може да е необходимо въввсеки клас да се добави поле, което да реферира logger обекта. Това евъзможно с „inter-type declaration“. Тези конструкции могат да сеизползват и за добавяне на методи, наследяване и други.
• „aspect“ – конструкция, в която се поставя „cross-cutting“ логиката.Аспектите са подобни на класовете, те съдържат всички останаликонструкции: pointcuts, advice и inter-type declarations, както ивторостепенната функционалност, която ще бъде вплетена в останалатачаст от системата. Аспектът е единицата за модуларизиране на „cross-cutting“ функционалност, както класа е единицата за модуларизиране наглавна функционалност. Аспектите могат да имат връзки помежду си поподобен на класовете начин. Също така, аспектите могат да използваткласове.
11
Глава 4. ТЕОРЕТИЧНИ ИЗСЛЕДВАНИЯ НА АСПЕКТНО-ОРИЕНТИРАН СОФТУЕРЕН ДИЗАЙН.
4.1 Анализ и дискусия на подходи за подобряване на софтуерендизайн.
В тази глава подробно се разглеждат често срещани дизайн-проблем итехните съществуващи решения под формата на:
• идиоми• дизайн-шаблони• добри практики• конвенции
Недостатъците на тези решения се анализират и се формулират аспектно-ориентирани подходи за намаляване или елиминиране на недостатъците.Новите и старите решения се сравняват и се извежда ефективността на всякоаспектно-ориентирано решение. Всички решения се проверяват чрезпринципите на софтуерен дизайн от групата „SOLID“.
Декориране и обработка на null. На код листинг 28 е показан простпример, илюстриращ следните два проблема:
• Клиентите на класа OpticalMediaWarehouse са принудени да обработватстойност „null“.
• Клиентите на класа OpticalMediaWarehouse имат възможност да променятсъдържанието на върнатите колекции.
class OpticalMediaWarehouse {
private Collection<CD> cds;private Collection<DVD> dvds;
// отрязан код за по-ясно
Collection<CD> getCds() {return cds;
}
Collection<DVD> getDvds() {return dvds;
}}
Код листинг 28: Наивна имплементация на склад за оптични дискове.
На код листинг 30 е показано аспектно-ориентирано решение и на дватапроблема.
aspect DataProtector {
pointcut unmodifiableCollections() :execution(Collection+ OpticalMediaWarehouse.*(..));
Collection<?> around() : unmodifiableCollections() {
12
Collection<?> result = proceed();if (null == result) {
return Collections.emptyList();}return Collections.unmodifiableCollection(result);
}}
Код листинг 30: Аспектно-ориентиран шаблон „декоратор“.
Това е аспект, избиращ всички методи от класа OpticalMediaWarehouse, коитовръщат колекция или кой да е наследник и при изпълнението им обвивавърнатите колекции в декорирани колекции. В случаите, когато методитевръщат стойност „null“, аспектът се грижи клиентите да получат празнаколекция. По този начин те винаги получават колекции, които не могат да сепроменят. Това позволява класа OpticalMediaWarehouse да е фокусиран самовърху бизнес-логиката си. Това решение вече е по-добро от всеобщо приетитедобри практики, защото не се изисква никакъв код за декориране или обработкана „null“ в самия клас. Въпреки това, все още са възможни някои подобрения;например - да се напише „pointcut“ дефиницията по начин, който обхващавсички методи, имащи нужда от декориране, включително и такива, които ще седобавят в бъдеще.
Използване на колекции. Java платформата предлага отличниимплементации на широк набор от различни видове колекции. За да може даденобект ефективно да бъде съхранен в колекция, платформата изисква обектът дапритежава валидни имплементации на методите equals() и hashCode(), съгласнострого дефинирани правила. Ако тези методи не се имплементират изобщо илине се имплементират правилно, резултатите може да са много негативни: отпонижена производителност на колекциите до грешно поведение при търсене вколекции. Ако се състави пример, в който участват различни, взаимнонезависими типове класове с общата характеристика, че се идентифицират суникални идентификатори, може да се извади общ интерфейс, деклариращметод, който връща идентификатор. Виж код листинг 37.
interface Identifiable {
String getId();}
class Element implements Identifiable {
public String getId() {// отрязан код за по-ясно
}
String getDescription() {// отрязан код за по-ясно
}}
13
class Node implements Identifiable {
public String getId() {// отрязан код за по-ясно
}
Node getParent() {// отрязан код за по-ясно
}}
Код листинг 37: Общ интерфейс между независими типове.
Двата класа имат различни имплементации на метода getId(), но технитеequlas() и hashCode() ще са напълно идентични. Това означава, че всеки кластрябва да има собствена имплементация на equals() и hashCode(), но сидентичен код. Освен това, няма ефективен начин тези методи да се наследятбез да се дублира код поне за декларациите. Това може да се избегне като седобави аспектът, показан на код листинг 38.
interface Identifiable {
String getId();
static aspect Impl {
public boolean Identifiable.equals(Object o) {// отрязан код за по-ясноreturn this.getId().equals(((Identifiable) o).getId());
}
public int Identifiable.hashCode() {return this.getId().hashCode();
}}
}
Код листинг 38: Статичен аспект, който предоставя имплементации на методите equals()и hashCode().
Този статичен аспект ще постави дефинираните имплементации на equals() иhashCode() във всеки клас, който имплементира интерфейса Identifiable. По тозиначин, класовете остават в съгласие с „The Single Responsibility Principle“, тъйкато тези методи не са свързани с техните главни отговорности, а служат за товада осигурят правилното функциониране на колекциите, които съхраняватобекти от въпросните класове. Иначе казано, equals() и hashCode()представляват „cross-cutting“ функционалност, свързана със съхранението наобектите. От този пример следва, че „static crosscutting“ свойствата на AspectJимат потенциал да съкращават още повече код и ,специално, в този пример, дасъкращават и вероятността за грешки. Правилната имплементация на тезиметоди не е тривиална задача и лесно може да се сгреши, още повече, когато
14
всеки клас трябва да има почти една и съща имплементация.Мигриране към декларативни конфигурации. Заради тенденцията
големите софтуерни библиотеки и „frameworks“ да минават от традиционна къмдекларативна конфигурация, техните клиенти са принудени да мигрират своитеконфигурации. Това води до значително количество промени, особено в големисофтуерни проекти. На код листинги 43 и 44 са показани servlet класове итяхната традиционна конфигурация.
class TimeServlet extends HttpServlet {// отрязан код за по-ясно
}
class DateServlet extends HttpServlet {// отрязан код за по-ясно
}
Код листинг 43: Servlet класове за съобщаване на време и дата.
<web-app>// отрязан код за по-ясно
<servlet><servlet-name>TimeServlet</servlet-name><servlet-class>TimeServlet</servlet-class>
</servlet><servlet-mapping>
<servlet-name>TimeServlet</servlet-name><url-pattern>/time</url-pattern>
</servlet-mapping><servlet>
<servlet-name>DateServlet</servlet-name><servlet-class>DateServlet</servlet-class>
</servlet><servlet-mapping>
<servlet-name>DateServlet</servlet-name><url-pattern>/date</url-pattern>
</servlet-mapping>// отрязан код за по-ясно</web-app>
Код листинг 44: Традиционна конфигурация на servlet класове за съобщаване на време и дата.
За да се премине към декларативна конфигурация към всеки servlet клас, трябвада се добави определена Java анотация с определени атрибути както е показанона код листинг 45.
@WebServlet(urlPatterns = "/time")class TimeServlet extends HttpServlet {
// отрязан код за по-ясно}
@WebServlet(urlPatterns = "/date")class DateServlet extends HttpServlet {
// отрязан код за по-ясно
15
}
Код листинг 45: Декларативно конфигурирани servlet класове за съобщаване на време и дата.
Този начин на конфигуриране, определено, е по-прост и има много приятнистранични ефекти като фактът, че може да се третира като чист Java код исъответно придобива възможността да се използват съществуващитеинструменти за Java код за неговото поддържане. Същевременно тазиконфигурация се явява като „cross-cutting concern“ за всеки servlet клас.Работата на един servlet клас е да обработва HTTP заявки, а не да предоставяинформация за това каква е технологията или URL адреса. За щастие, чрезAspectJ servlet класовете могат напълно да се освободят от тези страничниотговорности както е показано на код листинг 46.
public aspect ServletMigrator {
declare @type: TimeServlet : @WebServlet(urlPatterns = "/time");declare @type: DateServlet : @WebServlet(urlPatterns = "/date");
}
Код листинг 46: Миграция от традиционна към декларативна конфигурация.
ServletMigrator аспектът поставя необходимите анотации на съответните servletкласове, така че да се постигне миграция от традиционна към декларативнаконфигурация без самите servlet класове да съдържат конфигурационни данни,още повече, без да е необходимо да се променят изобщо. Този подход може дасе използва като общ дизайн-шаблон за мигриране на големи софтуернипроекти от традиционна към декларативна конфигурация, без негативнистранични ефекти. Този начин на мигриране ще има още по-висока стойност заклиенти на „frameworks“ като Spring и JSF, където конфигурационните данни самного повече.
Управление на памет. Аспектно-ориентирано програмиране може да сеизползва и за модуларизиране на сложни, „cross-cutting“ функционалности зауправление на памет. Управлението на памет, определено, не трябва дапринадлежи на нито един главен модул от която и да е програма. За товааспектите са най-подходящото място за такъв тип функционалности.Управлението на памет в Java е автоматично, но въпреки това има много случаи,в които е необходимо да се обърне специално внимание на обектите в паметта.Съвсем накратко - обектите се пазят в паметта докато има „живи“ референциикъм тях. Това означава, че един обект ще бъде изчистен от паметта, когато веченяма референции към него от нито една нишка или когато всички референцииса от, така наречения, „isle of isolation“. Под референция се разбира „твърда“референция. Това е директна референция от един обект към друг. В Javaсъществуват още 3 вида референции, 2 от тях представляват специални „меки“и „слаби“ референции. Меките и слабите референции позволяват обектите,
16
сочени от тях, да се изчистят, ако се получи недостиг на памет по време наработа. С помощта на меки и/или слаби референции може да се създаватвисоко-ефективни (от гледна точка на памет) програми. За нещастие тяхнотоизползване е сложно и води до много големи степени на „code scattering“ и„code tangling“. За силно минимизиране или пълно елиминиране на тезинеприятни ефекти може да се използва аспектно-ориентирано програмиране.Код листинг 51 показва пълен пример за модуларизиране използването на мекиреференции.
interface HeavyEntity {
byte[] getData();}
class HeavyEntityProducer {
static HeavyEntity createHeavyEntity() {// отрязан код за по-ясно
}}
class HeavyEntityClient {
public static void main(String[] args) {HeavyEntity heavyEntity = HeavyEntityProducer.createHeavyEntity();byte[] data = heavyEntity.getData();// отрязан код за по-ясно
}}
aspect HeavyEntityReferenceSoftener {
pointcut heavyEntityCreation() : execution(HeavyEntity HeavyEntityProducer.*(..));
HeavyEntity around() : heavyEntityCreation() {return new SoftenedHeavyEntity(proceed());
}
static class SoftenedHeavyEntity implements HeavyEntity {
private SoftReference<HeavyEntity> softReference = null;
SoftenedHeavyEntity(HeavyEntity heavyEntity) {softReference = new SoftReference<HeavyEntity>(heavyEntity);
}
public byte[] getData() {HeavyEntity heavyEntity = softReference.get();if(null == heavyEntity) {
throw new RuntimeException("This object has been garbage-collected!");
}return heavyEntity.getData();
}}
17
}
Код листинг 51: Модуларизирано използване на меки референции.
Вижда се програма, която използва обекти, които заемат значително количествопамет, под името HeavyEntity. За да се увеличи ефективността на паметта сеизползват обекти от тип SoftReference, чрез които се постигат меки референции.Аспектът HeavyEntityReferenceSoftener се грижи, когато има нужда от тежъкобект, той да бъде „опакован“ в клас от тип SoftenedHeavyEntity, така че да сеизползва SoftReference за рефериране на тежкия обект. Това позволява, принужда, да се изчистват тежките обекти, за да може програмата да продължинормална работа. В случаите, когато се извика метод на тежък обект, който вечее изчистен, се хвърля изключение, което обяснява ситуацията. Механизмът заизключения може да се използва за придобиване на нов тежък обект, когато енужно. За придобиване на тежки обекти може да се използва и друг аспект,което би довело до още по-високо ниво на модуларност. В този пример, цялаталогика по използване на меки референции се намира в един аспект. Товаосвобождава главните модули на програмата от нуждата да се грижат зареференциите, което значително опростява цялостния дизайн на програмата.Ако тази програма се изпълнява в среда, където не се очаква недостиг на памет,HeavyEntityReferenceSoftener аспекът може да се извади без това да доведе допромяна в поведението на програмата. Този подход може да се използва, катодизайн-шаблон за управление на памет чрез аспекти. В практиката този шаблонможе да се имплементира, така че да се внесе динамичен елемент присъздаването на меки референции, тоест да се създават меки референции само,ако дадени условия са налице.
Глава 5. ЕКСПЕРИМЕНТАЛНИ ИЗСЛЕДВАНИЯ НА АСПЕКТНО-ОРИЕНТИРАН СОФТУЕРЕН ДИЗАЙН.
5.1 Инжектиране на зависимости.Като част от стремежа и усилието на софтуерните инженери да спазват
„The Dependency Inversion Principle“ са изобретени подходите за инжектиранена зависимости. Те са известни като „dependency injection“ или „inversion ofcontrol“ шаблони. Основната цел на тези шаблони е да се освободят класове имодули от зависимости към конкретни класове, вместо това в кода на даден класда съществува само декларация на абстрактния тип на зависимостта, адефиницията да се поставя по време на работа от трета страна. Обикновено,имплементация на система за инжектиране на зависимости се нарича„контейнер“. На код листинг 53 е показан пример за инжектиране назависимости.
class QuizMasterService {
private QuizMaster quizMaster;
18
void setQuizMaster(QuizMaster quizMaster) {this.quizMaster = quizMaster;
}
void askQuestion() {System.out.println(quizMaster.popQuestion());
}}
Код листинг 53: Инжектиране на зависимости чрез Spring Framework.
Полето quizMaster се оставя без дефиниция и се добавя „setter“ метод(setQuizMaster()), чрез който контейнерът да постави необходимия обект [75, 76,77, 78, 79]. Един от най-успешните и популярни контейнери за инжектиране назависимости е Spring Framework [20, 21, 22]. Пример за инжектиране назависимости със Spring Framework в класа QuizMasterService е показан на кодлистинг 54.
<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="springQuizMaster" class="SpringQuizMaster"></bean><bean id="strutsQuizMaster" class="StrutsQuizMaster"></bean><bean id="quizMasterService" class="QuizMasterService">
<property name="quizMaster"><ref local="springQuizMaster"/></property>
</bean>
</beans>
Код листинг 54: Конфигурация за инжектиране на зависимости чрез Spring Framework.
Това е конфигурационен файл, в който е описано, че инстанцията от типQuizMasterService трябва да получи инстанция от тип SpringQuizMaster, катозависимост [71, 72, 73, 74]. Или с други думи, да се инжектира обект от типSpringQuizMaster в поле с името quizMaster на обект от тип QuizMasterService.
Инжектирането на зависимости със Spring Framework е много просто игъвкаво, но има и своите недостатъци. Изискват се допълнителни библиотеки,инжектирането не е динамично, създаването на зависимости не е „lazy“ и други.Чрез AspectJ може да се създаде подобна система за инжектиране назависимости, която е потенциално по-проста и не страда от гореспоменатитенедостатъци. На код листинг 55 е показан такъв пример.
class QuizMasterService {
private QuizMaster quizMaster;
19
void askQuestion() { System.out.println(quizMaster.popQuestion()); }}
privileged aspect DependencyInjection {
pointcut dependency(QuizMasterService qms) :get(QuizMaster QuizMasterService.quizMaster) && this(qms);
before(QuizMasterService qms) : dependency(qms) {if (null == qms.quizMaster) {
qms.quizMaster = new SpringQuizMaster();}
}}
Код листинг 55: Аспектно-ориентирано инжектиране на зависимости.
В тази версия не е нужно дори да има „setter“ метод в класа QuizMasterService,тъй като аспекти, декларирани с „privileged“ имат достъп до всички членове отдаден клас, включително и тези, декларирани като „private“. Както се вижда, иаспектът, и класът са много прости, а, все пак, изпълняват същото, което SpringFramework изпълнява. Единствената разлика е, че с използването на аспекти сегуби възможността от външно описване на зависимостите, както е в SpringFramework и XML конфигурацията. За сметка на това, няма никаквидопълнителни зависимости под формата на библиотеки и инжектирането можеда е напълно динамично. Тоест, може да се инжектират различни типове, акоопределени условия са налице. Таблица 5 показва сравнение междуимплементацията на инжектиране на зависимости, реализирана с AspectJ иSpring Framework.
AspectJ Spring Framework
Допълнително дисковопространство
100 кило-байта 4.15 мега-байта
Общо редове код 34 40
Брой допълнителнибиблиотеки
1 8
Външна конфигурация Не Да
Динамично инжектиране Да Да (чрез SpringFramework API)
Възможни стратегии наинжектиране
• eager• lazy
• eager
20
Възможни точки наинжектиране
• По време на инициализация на обектите
• След конструиране на обектите
• При четене на поле,което изисква инжектиране на зависимост
• Други
• Чрез конструктор• Чрез „setter“ метод
Таблица 5: Сравнение между аспектно-ориентирано инжектиране на зависимости и Spring Framework.
От сравнението се вижда, че имплементация с AspectJ може да бъде по-проста ипо-мощна, но не може да се постигне външно конфигуриране. Това правиизборът на подход пряко свързан с естеството на приложението. Акоприложението е такова, че не е необходимо външно конфигуриране, значи можеда се избере AspectJ и да се спести от сложност, в противен случай трябва да сеизползва Spring Framework. Разбира се, винаги може да се изработи решение набазата на AspectJ, което зарежда зависимости, като чете инструкции от външенконфигурационен файл, но това би означавало да се дублира функционалносттана Spring Framework. Всъщност, Spring Framework вътрешно използва AspectJ,за да постигне целите си.
5.2. Налагане на дизайн-правила.Деградиране на дизайн. Процесът по постепенно пресичане на
границите на дефинирани дизайн-политики и правила може да се наречедеградиране, гниене или разрушаване на дизайн. Някои от най-честитеизвинения за това са:
• Крайни срокове – когато наближават сроковете за изпълнение на задачи,хората са склонни да игнорират или прескочат някои правила, за да могатпо-бързо да кажат, че работата е свършена. Резултатът е лош и грозен код.
• Качеството е с нисък приоритет – понякога на инженерите не е позволенода отдават необходимото (или никакво) внимание на качеството на кода,което води до нестабилна и трудна за поддържане система.
• Непознаване на правилата – този проблем се наблюдава, когатоинженерните екипи нарастват като членове. Новите инженери, които сеприсъединяват към даден екип, не могат да се запознаят с целия дизайн ивсички негови правила преди да започнат работа по системата, затова сапредразположени към допускането на грешки, поради неинформираност.
• Незаинтересованост от правилата – някои инженери просто не смятат, чеправилата си заслужава да се следват и не ги следват. Или не са съгласни с
21
определени политики и затова не ги следват.• Системата има ниско покритие от тестове и, като резултат, „refactoring“ е
много трудно или невъзможно да се прави – вероятно, това е най-лошотосъстояние, до което една система може да достигне. При таковаположение, въпросът е да не се повреди системата, а не да се следваткаквито и да е правила. Дадена система веднъж започне ли да изостава стестовете, нейното поддържане прогресивно става по-трудно.Налагане на политики и правила. Възможен начин за понижаване на
цената по поддържане на една система е чрез механизъм за налагане на нейнитедизайн-правила, с цел да се елиминира възможността за грешки, породени отнезнание или незаинтересованост. Общо взето, има два начина за налагане надизайн-политики или правила: автоматично или ръчно. Най-разпространениятначин за налагане на политики е ръчно, чрез регулярни прегледи на код (codereview). А автоматично налагане на правила се постига чрез различниинструменти за статичен анализ на код. Таблица 6 показва плюсовете иминусите на двата подхода.
Плюсове Минуси
Ръчно • Разпознава комплексни нарушения
• Спомага за привеждането на кода към единен стандарт
• Повишава общото ниво на познаване на кода в екипа
• Протича много бавно
• Много трудно се прилага за големи промени
• Някои нарушения могат да се пропуснат несъзнателно
22
Автоматично • Моментална индикация в случаина нарушения
• Никога не се пропускат проблеми, които могат да се установят
• Протича много бързо
• Не зависи от големината на промените
• Наборът от правиламоже да е много голям
• Не може да засича комплексни нарушения
• Може да изисква сложна конфигурация
Таблица 6: Сравнение между автоматично и ръчно налагане на дизайн-политики.
Няма категоричен отговор, кой подход е по-добър, но е безопасно да се твърди,че и двата подхода може и трябва да се използват заедно.
Чрез използване на аспектно-ориентираната парадигма на програмиранеможе да се създаде „framework“ за налагане на дизайн-политики и правила. Товае възможно благодарение на „join point“ модела на аспектно-ориентиранитесистеми. Тъй като, той предоставя достъп до почти всички точки отизпълнението на програмата, както и статичната й структура много лесно може,чрез тези точки, да анализира какъв е дизайнът на програмата. Това ще рече, чеможе да се разгледат:
• зависимостите• веригите на изпълнение• йерархиите на наследяване• декларациите на членове• инициализациите на обекти• и много други
в едно приложение. Фактически, всички тези елементи формират дизайна наедна програма. Това позволява да се създадат правила под формата на „pointcut“дефиниции, намиращи комбинации от тези елементи, които не са разрешени.Например:
• зависимости между класове които са неправилни• извиквания на забранени методи• неправилно създаване на обекти• грешно обработване на изключения
23
• забранени зависимости между слоеве• неправилен достъп до променливи• и много други
За целта на този труд е разработена пълна демонстрация на решение за налаганена дизайн-политики под формата на софтуерна рамка (framework). Тази рамка есвободно достъпна под името DPE (Design policy enforcement) [39] вSourceForge платформата [40]. Архитектурата е съвсем проста: състои се отнабор от абстрактни аспекти, които представляват различни категории направила и един аспект, който определя реда на проверка на правила. Всекиабстрактен аспект предоставя поне един абстрактен „pointcut“, който да седефинира от наследници, така че да се разреши проверката на въпроснотоправило за конкретен код. Към момента DPE поддържа следните категории:
• Достъп до стандартната библиотека на Java (JDK)• Достъп до слоеве в системата• Използване на Reflection• Достъп до полета (член-променливи)• Използване на System класа• Налагане на „factory“ шаблон• Обработване на „runtime/unchecked“ изключения• Обработване на „Error“ изключения• Потребителска категория
Всеки аспект от рамката дефинира общи „pointcuts“, които покриват цялатакатегория, и абстрактни „pointcuts“, които да се дефинират от наследниците,така че да се допълни или филтрира правилото, с цел конкретния аспект даслужи като самостоятелно правило, което съвпада със спецификата напрограмата. Например, част от аспекта, служещ за контрол на достъпа до JDK, епоказан на код листинг 56.
public abstract aspect JdkAccessEnforcement { pointcut jdk16() : call(* java.applet..*.*(..)) ||
call(java.applet..*.new(..)) ||get(* java.applet..*) ||call(* java.awt..*.*(..)) ||call(java.awt..*.new(..)) ||get(* java.awt..*) ||
// отрязан код за по-ясно public abstract pointcut allowed(); public abstract pointcut enabled(); declare error : enabled() && (!allowed() && jdk16()) :
"Illegal JDK access!";}
Код листинг 56: Контрол на достъп до JDK.
24
В jdk6() „pointcut“ дефиницията са поставени всички възможни извиквания къмкод от JDK. Целта на allowed() е наследниците да дефинират позволенитекласове от JDK, а целта на enabled() е наследниците да дефинират, къде сапозволени тези класове. По този начин, абстрактният аспект играе ролята на бялсписък (white list), в който няма позволени извиквания, а наследниците трябвада добавят позволените (белите) елементи чрез дефиниция на allowed() и,съответно, да посочат за къде важи този бял списък чрез enabled(). Код листинг57 показва пример за наследник на JdkAccessEnforcement.
public aspect JdkAccessEnforcementImpl extends JdkAccessEnforcement {
public pointcut allowed() :call(* java.lang..*.*(..)) ||call(java.lang..*.new(..));
public pointcut enabled() : within(org.project.database..*);}
Код листинг 57: Позволяване на достъп до JDK.
Този аспект позволява използването на класовете от пакетите java.lang и указва,че белият списък трябва да важи за целия код, намиращ се в org.project.databaseпакета и всички негови под-пакети. Иначе казано, JdkAccessEnforcementImplгласи: забранени са всички класове от JDK, с изключение на класовете впакетите java.lang и тази забрана важи за целия код, намиращ се вorg.project.database пакета и всички негови под-пакети. За да се наложатправилата от този аспект в дадена програма, е необходимо при компилиранетоѝ, в „classpath“ дефиницията да се включи DPE библиотеката иJdkAccessEnforcementImpl аспекта. Така, при нарушение на политиката, ще сезадейства „declare error“ конструкцията от JdkAccessEnforcement и ще се изведесъответното съобщение за грешка.
5.3. Експериментална, аспектно-ориентираната методология на дизайн.
Методологии на дизайн. Методологията на дизайн представлява наборот ръководни принципи и насоки за създаване на софтуерен дизайн.Методологиите предоставят подредени правила, процедури и процеси, коитонаправляват създаването на софтуерни дизайни. Някои от най-популярните ишироко използвани методологии са [41]:
• top-down дизайн [42, 43]• bottom-up дизайн [43]• структуриран дизайн• обектно-ориентиран дизайн
Анализ на качествата на методологиите на дизайн. Методологиите надизайн имат три основни качества: приложимост, ефективност и сложност. Тези
25
качества имат определени взаимозависимости и степента, до която тесъществуват в дадена методология, е много важно за нейното вътрешноравновесие. Приложимостта определя областите, в които една методологияможе да се прилага, проблемите, които може да решава и средите, в които можеда се изпълнява. Ефективността на методологията определя качеството нанейните резултати. Обикновено, се измерва в солидност и разширяемост наполучените дизайни. А сложността определя количеството ресурси, които сеизискват от дизайнера. Това ще рече количеството време, компютърна ичовешка сила - нужни за успешното изпълнение на методологията.Следователно, добра методология на дизайн е такава методология, коятомаксимизира приложимостта и ефективността и минимизира сложността.Отношенията между тези качества са описани в таблица 7.
Приложимост Ефективност Сложност
Приложимост С увеличаванетона приложимостта,
ефективносттанамалява
пропорционално.Главният проблеме, че колкото по-
широк спектър отпроблеми се
покриват от даденаметодология,толкова по-
неефективни сатехните решения.Обикновено, от
това страдаразширяемостта наполучения дизайн.
С повишаването наприложимостта,почти винаги се
повишава исложността. Товае, защото колкотоповече проблемисе адресират от
даденаметодология,
толкова повечересурси сеизискват за
нейнотоизпълнение.
Ефективност С увеличаванетона ефективността,
приложимосттанамалява. Тъй
като, е много по-лесно да се
изработи решениена един или
няколко подобнипроблема. Освен
С повишаването наефективността, емного вероятно,сложността даспада. Това се
получава, защотоефективността
предполагапростота на
решенията, което
26
това, решението напо-малък брой
проблеми,обикновено, е по-просто, което води
до високаефективност.
от, своя страна,означава, че евероятно да се
изискват по-малкоресурси.
Сложност Когато сложносттае висока,
приложимосттасъщо може да е
висока. Това можеда се случи, акообластите, коитоса обхванати от
методологията, саголеми или са
обхванати многообласти. При това
положение сеизискват големи
количестваресурси.
Поддържането наниско ниво на
сложност,допринася за
високаефективност,защото е по-евтино да сеизпълнява
методологията.
Таблица 7: Отношения между качествата на методологиите на дизайн.
Поддържането на хубав баланс между тези качества в рамките на даденаметодология е от съществена важност за нейния успех.
Създаване на методология на дизайн. Когато съществува проблем, закойто няма посветена методология, е добра идея да се експериментира скомбинации от методологии или създаване на нова методология. Създаването наметодология на дизайн не е никак лесна задача, изисква се отлично познаванена въпросната област, както и професионална компетентност в областите насофтуерен дизайн и методологии на дизайн. Разбира се, високите изисквания неса извинение да не се експериментира с начини за съставяне на успешниметодологии на дизайн. Както беше обяснено по-горе, методология на дизайнпредставлява подредени правила, процедури и процеси, които направляватрешаването на дизайн проблем. Изглежда, че тази обща дефиниция достанаподобява дефиницията на алгоритъм [50, 53, 54, 55, 56, 57, 58, 59, 60].Следователно, е възможно да се направи следната аналогия: методология надизайн се отнася към дизайн-проблем, както алгоритъм се отнася къмматематически проблем. Тази аналогия води до следния въпрос: могат липарадигмите за синтезиране на алгоритми да се използват за синтезиране на
27
методологии на дизайн [61, 62, 63, 64, 65]? Добро начало за търсене на отговорае чрез експериментиране. Има множество парадигми за синтезиране наалгоритми [66, 67, 68, 69, 70], най-популярните са:
• divide and conquer• dynamic programming [51]• greedy algorithm
всяка от тях може да се използва за експериментиране. Обаче, естеството на„dynamic programming“ парадигмата я прави най-логичният кандидат [83, 84,85]. Тя може да се опише така: като начало въпросният проблем се разбива намалки под-проблеми, които са по-лесни за решаване, след това техните решениясе комбинират в цялостно решение на оригиналния проблем [86, 87]. Многочесто под-проблемите и техните решения са идентични, следователно, голямброй решения могат да се използват наготово при решаването на всички под-проблеми [88]. Виж фигура 25.
Следвайки главната идея на „dynamic programming“ парадигмата, може да сеекспериментира със съставяне на аспектно-ориентирана методология на дизайн[89, 90, 91, 92].
Експериментално съставяне на методология на дизайн. Добра идея епървата стъпка да бъде мислено моделиране на добра аспектно-ориентиранаметодология на дизайн. Една от главните характеристики на такава технологиятрябва да бъде момент от нея, в който може директно да се приложи обектно-ориентираната методология на дизайн. Идеята зад тази характеристика е, чеаспектно-ориентираното програмиране е разширение на обектно-ориентираното
28
Фигура 25: Модел на „dynamic programming“ алгоритъм.
проблем
1
2
3
i
1
j
решение
подпроблеми
междинни решения
програмиране, следователно, в определен момент трябва да се стигне до чистобектно-ориентиран дизайн. Това предполага, че началната точка наметодологията трябва да бъде или комуникацията между общите модули, илидефинирането на „cross-cutting“ модулите. Втората възможност приляга поестествен начин на идеята за аспектно-ориентирана методология, затова тяотива като начална точка. Може да се каже, че основният начин на работа натази експериментална методологията е: започва се с дефиниция навторостепенните модули, докато се изчерпят, след това се преминава къмизпълнение на обектно-ориентираната методология на дизайн само върхуглавните модули.
На базата на тази обща и повърхностна дефиниция, може да се започнесинтезиране на конкретните механики. При дадено описание на проблем, почтивинаги се подразбират някои от второстепенните функционалности.Следователно, като първа стъпка на методологията ще бъде да се дефиниратвторостепенните модули (crosscutting concerns), които са очевидни от самотоописание на проблема. Такива, в повечето случаи, са: проследяване (tracing),кеширане, контрол на достъп, поддръжка на транзакции и други. След това, зада се дефинират останалите „cross-cutting“ модули, ще бъде необходимо да сезапочне с описването на нивата или слоевете на системата. Това трябва да бъдеитеративен процес в стил „top-down“. След всяка итерация, трябва да се правиоценка за потенциални второстепенни модули, ако такива могат да бъдатидентифицирани. Когато вече не могат да бъдат дефинирани повече „cross-cutting“ функционалности, тази итеративна стъпка се счита за приключена. Втози момент всички или почти всички възможни второстепенни модули ще садефинирани. При това положение, може да се започне съставянето на главнитемодули. За тях трябва да се приложи директно обектно-ориентиранатаметодология на дизайн. Тъй като, ще се работи само върху главни модули,нейното изпълнение ще бъде сравнително просто. По време на тази стъпка евъзможно да се появят второстепенни модули, които са били скрити впредишната стъпка. Ако това се случи, текущата стъпка трябва да се прекъсне,да се отиде на предишната стъпка и да се коригират второстепенните модули,спрямо възникналите нови такива. Това прекъсване трябва да се изпълнява поподобие на концепцията за „backtracking“ алгоритми [52]. Това означава, че доизвестна степен и тази стъпка може да се разглежда като итеративна или понеусловно-итеративна. След като приключи изпълнението на обектно-ориентираната методология, като следваща стъпка е логично да се извършицялостен преглед и проверка на получения дизайн. Това ще рече, че дизайнеръттрябва по някакъв начин да докаже, например, чрез потребителски сценарии(use cases) [102], че резултатът задоволява всички изисквания.
Методологията, описана по-горе, може да бъде обобщена в следнитечетири стъпки:
1. Дефиниране на „cross-cutting“ модули, които са очевидни от описаниетона проблема.
29
2. Итеративно дефиниране на слоевете на системата в стил „top-down“ иизвличане на „cross-cutting“ модули след всяка итерация.
3. Прилагане на обектно-ориентираната методология на дизайн върхуглавните модули, с възможност за връщане към стъпка 2 в случите, когатосе появи скрита „cross-cutting“ функционалност (подобно на„backtracking“).
4. Цялостен преглед и проверка на получения дизайн, с цел да се докаженеговата легитимност.
Визуално представяне на методологията е показано на фигура 26.
30
Фигура 26: Четирите главни стъпки на аспектно-ориентирана методология на дизайн.
Дефиниране на „cross-cutting“ модули, които са очевидни от описанието
на проблема.
Итеративно дефиниране на
слоевете на системата и
извличане на „cross-cutting“ модули след
всяка итерация.
Прилагане на обектно-
ориентираната дизайн
методология върху главните
модули.
Цялостен преглед и проверка на получения
дизайн с цел да се докаже неговата
легитимност.
ПРИНОСИ
1. Формулирани са обектно-ориентирани и аспектно-ориентирани подходиза повишаване ефективността на софтуерни дизайни на базата назадълбочени проучвания на характеристиката „модуларност на софтуерендизайн“ и нейното въздействие върху развитието на софтуерни системи.
2. Предложени са аспектно-ориентирани решения на често срещани дизайнпроблеми, които заместват обектно-ориентирани шаблони. Анализирана еефективността на новите решения спрямо шаблоните „decorator“ и „null-object“.
3. Разработени са аспектно-ориентирани шаблони и идиоми за решаване напроблеми, свързани с:
◦ работа с колекции в Java◦ мигриране на системи към декларативни стилове на конфигурация◦ освобождаване на памет чрез „омекотяване на референции“◦ валидиране на входни данни
4. Предложен е подход за аспектно-ориентирано управление на зависимости(инжектиране на зависимости). Анализирани са разликите междуаспектно-ориентирано инжектиране на зависимости и Spring Framework.
5. Разработена е експериментална система за автоматично налагане надизайн-политики и правила, базирана на AspectJ.
6. Разработена е експериментална, аспектно-ориентирана методология надизайн, използвайки главните концепции от парадигмата за синтезиранена алгоритми „dynamic programming“ и алгоритмите от тип„backtracking“.
31
ПУБЛИКАЦИИ
1. Daniela Gotseva, Mario Pavlov. Aspect Orientation: The Path to HighlyModular Software Design, Computer and Communication Engineering, 2012.
2. Daniela Gotseva, Mario Pavlov. SOLVING COMMON DESIGN PROBLEMSUSING ASPECT-ORIENTED PROGRAMMING, X International Conference"Challenges in High Education and Research in 21st Centuary", 2012.
3. Daniela Gotseva, Mario Pavlov. Aspect-oriented programming with AspectJ.IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1,212-218. September 2012. http://ijcsi.org/papers/IJCSI-9-5-1-212-218.pdf
4. Daniela Gotseva, Mario Pavlov. Aspect-Oriented Design Diversity.International Journal of Emerging Technologies in Computational and AppliedSciences (IJETCAS), 128-132. 2013.http://iasir.net/IJETCASpapers/IJETCAS12-344.pdf
5. Daniela Gotseva, Mario Pavlov. How Aspect-Oriented Programming CanEnforce Clean Design. International Journal of Software and Web Sciences(IJSWS), 63-68. 2013. http://iasir.net/IJSWSpapers/IJSWS12-356.pdf
6. Daniela Gotseva, Mario Pavlov. An Experimental Aspect-Oriented DesignMethodology. IJCSI International Journal of Computer Science Issues, Vol. 10,Issue 2, No 1, 486-490. March 2013. http://www.ijcsi.org/papers/IJCSI-10-2-1-486-490.pdf
32
ЛИТЕРАТУРА (извадка)
[1] Kurt Nørmark. Overview of the four main programming paradigms. Aalborg University. 9 May 2011.[2] Peter B. Andrews. An Introduction to Mathematical Logic and Type Theory: To Truth Through Proof, 2nd ed.. Berlin: Kluwer Academic Publishers. 2002.[4] Ramnivas Laddad. AspectJ in action. Manning. 2010.[7] Robert C. Martin. Design Principles and Design Patterns. http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf[8] Robert C. Martin. The Single Responsibility Principle. http://objectmentor.com/resources/articles/srp.pdf[9] Robert C. Martin. The Open Closed Principle. http://objectmentor.com/resources/articles/ocp.pdf[10] Robert C. Martin. The Liskov Substitution Principle. http://objectmentor.com/resources/articles/lsp.pdf[11] Robert C. Martin. The Interface Segregation Principle. http://objectmentor.com/resources/articles/isp.pdf[12] Robert C. Martin. The Dependency Inversion Principle. http://objectmentor.com/resources/articles/dip.pdf[20] Craig Walls. Spring in Action. Manning Publications. June 29, 2011.[21] J Sharma, Ashish Sarin. Getting started with Spring Framework. CreateSpace Independent Publishing Platform. December 10, 2012.[22] Madhusudhan Konda. Just Spring. O'Reilly Media. August 2, 2011.[28] Kevin Tate. Sustainable Software Development: An Agile Perspective. Addison-Wesley Professional. October 21, 2005.[29] Clifford J. Berg. High-Assurance Design: Architecting Secure and Reliable Enterprise Applications. Addison-Wesley Professional. October 23, 2005.[39] http://sourceforge.net/projects/dpe/[40] http://sourceforge.net[41] Benjamin Kok Swee Khoo. A Survey of Major Software Design Methodologies. http://userpages.umbc.edu/~khoo/survey2.html[42] Deduction & Induction, Research Methods Knowledge Base. socialresearchmethods.net. October 20, 2006.[43] Top-Down Design (Introduction to Statistical Computing). masi.cscs.lsa.umich.edu. September 19, 2011.[45] Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley Professional.August 12, 1995.[47] Richard P. Gabriel. Lisp: Good News Bad News How to Win Big. Lucid, Inc. 1991.[48] Tom DeMarco, Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House. 1987.[50] Robert Sedgewick, Kevin Wayne. Algorithms. Addison-Wesley Professional. March 19, 2011.
33
[51] Richard Bellman. The theory of dynamic programming. Bulletin of the American Mathematical Society. 1954.[52] Eitan Gurari. Backtracking algorithms "CIS 680: DATA STRUCTURES: Chapter 19: Backtracking Algorithms". 1999[53] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein. Introduction to Algorithms. The MIT Press. Jul 31, 2009.[54] Thomas H. Cormen. Algorithms Unlocked. The MIT Press. Mar 1, 2013.[55] Steven S Skiena. The Algorithm Design Manual. Springer. Nov 5, 2010.[56] Sanjoy Dasgupta, Christos Papadimitriou, Umesh Vazirani. Algorithms. McGraw-Hill Science/Engineering/Math. Sep 13, 2006.[57] George T. Heineman, Gary Pollice, Stanley Selkow. Algorithms in a Nutshell. O'Reilly Media. Oct 21, 2008.[58] Robert Sedgewick and Philippe Flajolet. Addison-Wesley Professional. An Introduction to the Analysis of Algorithms. Jan 28, 2013.[59] Narasimha Karumanchi. Data Structures and Algorithms Made Easy: Data Structure and Algorithmic Puzzles. CreateSpace Independent Publishing Platform. Dec 19, 2011.[60] Christopher Steiner. Automate This: How Algorithms Came to Rule Our World. Portfolio. Aug 30, 2012.[61] Jon Kleinberg, Éva Tardos. Algorithm Design. Addison-Wesley. Mar 26, 2005.[62] Richard Johnsonbaugh, Marcus Schaefer. Algorithms. Prentice Hall. Aug 10, 2003.[63] Robert Sedgewick. Algorithms in C. Addison-Wesley Professional. Sep 10, 2001.[64] Robert Sedgewick. Algorithms in C++. Addison-Wesley Professional Jul 23, 1998.[65] Russ Miller, Laurence Boxer. Algorithms Sequential & Parallel: A Unified Approach. Cengage Learning. Dec 20, 2012.[66] Haralambos Marmanis, Dmitry Babenko. Algorithms of the Intelligent Web. Manning. Jul 5, 2009.[67] Anany Levitin, Maria Levitin. Algorithmic Puzzles. Oxford University Press. Oct 14, 2011.[68] Donald E. Knuth. The Art of Computer Programming. Addison-Wesley Professional. Mar 13, 2011,[69] Niklaus Wirth. Algorithms + Data Structures = Programs. Prentice Hall. Feb 1976.[70] Robert Lafore. Data Structures and Algorithms in Java. Sams Publishing. Nov 16, 2002.[71] Willie Wheeler, Joshua White. Spring in Practice. Manning. April 28, 2013.[72] Gary Mak, Daniel Rubio, Josh Long. Spring Recipes: A Problem-Solution Approach. Apress. Sep 1, 2010.[73] Sam Brannen, Tareq Abedrabbo, Boris Burgstaller, Baruch Sadogursky. Spring in a Nutshell. O'Reilly Media. Apr 4, 2013.
34
[74] Mark Pollack, Oliver Gierke, Thomas Risberg, Jon Brisbin. Spring Data. O'Reilly Media. Oct 12, 2012.[75] Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, Olivier Bazoud. Spring Batch in Action. Manning. Oct 7, 2011.[76] Thomas Van de Velde, Bruce Snyder, Christian Dupuis, Sing Li. Beginning Spring Framework 2. Wrox. Dec 10, 2007.[77] Paul Tepper Fisher, Brian D. Murphy. Spring Persistence with Hibernate (Beginning). Apress. Nov 2, 2010.[78] Mark Fisher, Jonas Partner, Marius Bogoevici and Iwein Fuld. Spring Integrationin Action. Manning. Sep 26, 2012.[79] Matt Raible. The Spring Primer. SourceBeat. August 14, 2008.[83] Richard Neapolitan, Kumarss Naimipour. Foundations of Algorithms. Jones and Bartlett Publishers. Dec 28, 2009.[84] Jeff Edmonds. How to Think About Algorithms. Cambridge University Press. May 19, 2008.[85] Thomas Cormen, Charles Leiserson, Ronald Rivest, Clifford Stein. Introduction to Algorithms. McGraw-Hill Science/Engineering/Math. Dec 16, 2003.[86] Anany Levitin. Introduction to the Design and Analysis of Algorithms. Addison-Wesley. Oct 9, 2011.[87] Kyle Loudon. Mastering Algorithms with C. O'Reilly Media. Aug 12, 1999.[88] Ronald L. Graham, Donald E. Knuth, Oren Patashnik. Concrete Mathematics: A Foundation for Computer Science. Addison-Wesley Professional. Mar 10, 1994.[89] Lance Fortnow. The Golden Ticket: P, NP, and the Search for the Impossible. Princeton University Press. Mar 31, 2013.[90] Narasimha Karumanchi. Data Structures and Algorithms Made Easy in Java: Data Structure and Algorithmic Puzzles. CreateSpace Independent Publishing Platform. Dec 16, 2011.[91] Peter Eeles, Peter Cripps. The Process of Software Architecting. Addison-Wesley Professional. Jul 24, 2009.[92] Eric J. Braude. Software Design: From Programming to Architecture. Wiley. Mar 5, 2003.[119] Gregor Kiczales , John Lamping , Anurag Mendhekar , Chris Maeda , Cristina Lopes , Jean-marc Loingtier , John Irwin. Aspect-oriented programming. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.115.8660.1997.[127] The AspectJ 5 development kit developers notebook, http://eclipse.org/aspectj/
35
Aspect-oriented software design and analysis
MSc Engr Mario Pavlov
Abstract
The aspect-oriented programming (AOP) is a programming paradigm thatallows creating highly modular software designs by completely separating the cross-cutting concerns from the main concerns (core modules).
This thesis discusses various problems related to the design of large-scalesoftware systems. The principles of software design as well as the symptoms ofsoftware design decay are analyzed in detail in order to provide a foundation fordifferent approaches to composing highly modular, flexible and extensible softwaredesigns.
The purpose of this work is to analyze the viability of using aspect-orientedprogramming to resolve the separation of cross-cutting concerns in complex softwaresystems. To create clean solutions to common design problems or improve uponexisting solutions. To experiment with aspect-oriented implementations ofdependency management and design-policy enforcement solutions. To compose andformalize a general-purpose aspect-oriented software design methodology.
A brief summary of the contributions of this research is as follows:• Formulation of object-oriented and aspect-oriented techniques for improving
modularity.• Creation of various aspect-oriented design patterns for addressing common
design problems.• An experimental, aspect-oriented implementation of a dependency
management framework.• An experimental, aspect-oriented implementation of a design-policy
enforcement framework.• Proposal for an aspect-oriented software design methodology applicable for a
wide set of problems.All results from this work are presented in a way that allows them to be applied
directly to real-world problems. All experimental solutions can easily be integrated inexisting systems or used when designing and creating new systems.
36
