CC BY
29
Дослиджена проблема c^adHocmi розробки та тдтримки наскрiзного функционалу програмного забезпечення та ii ршення за допомогою аспектно-орieнтованого тдходу. Описано складтсть засто-сування аспектно-орieнтованого програмуван-ня в об'eктно-орieнтованих мовах програмування. Запропоновано архтектуру, яка забезпечить неза-лежтсть синтаксису оголошення та впровадження аспектiв в об'eктно-орieнтованi програми
Ключовi слова: аспектно-орieнтоване програмування, АОП, ттегращя асnектiв, наскрiзний функционал, архтектура ПЗ, точка з'еднання
Исследована проблема сложности разработки и поддержки сквозного функционала программного обеспечения и её решения с помощью аспектно-ориентированного подхода. Описаны сложность применения аспектно-ориентированного программирования в объектно-ориентированных языках программирования. Предложена архитектура, которая обеспечит независимость синтаксиса определения и внедрения аспектов в объектно-ориентированные программы
Ключевые слова: аспектно-ориентированное программирование, АОП, интеграция аспектов, сквозной функционал, архитектура ПЗ, точка соединения
-□ □-
УДК: 004.4
|DOI: 10.15587/1729-4061.2016.63717|
1НТЕГРАЦ1Я ЗАСОБ1В АСПЕКТО-ОР16НТОВАНОГО П1ДХОДУ У
об'сктно-
ОР1£НТОВАНУ МОВУ ПРОГРАМУВАННЯ
В. М. Медведева
Кандидат техычних наук, доцент* E-mail: bohdan.hukivskyi@gmail.com Б. М. Гук^вський*
E-mail: bohdan.hukivskyi@gmail.com *Кафедра автоматизаци проектування енергетичних процеав та систем Нацюнальний техшчний ушверситет УкраТни «Кшвський пол^ехшчний шститут» пр. Перемоги, 37, м. КиТв, УкраТна, 03056
1. Вступ
Технологи створення програм пройшли насичений шлях розвитку, було створено ряд мов програмування, алгоритмiв, технологш i т. п. 1снують рiзнi тдходи для написання програм. Кожен з цих пiдходiв мае сво'1 переваги та недолжи, яю визнають задачi, де може за-стосовуватися той чи шший пiдхiд. При виборi пiдходу важливо враховувати як предметну область виршува-но'1 задачi, так i таю фактори i потреби, як швидюсть написання рiшення, вiдмовостiйкiсть, надiйнiсть, ста-бiльнiсть, економiчнiсть та ряд шших факторiв. Поед-навши найбiльш устшш пiдходи, було створено ряд парадигм програмування.
Парадигма програмування - це набiр щей та понять, що визначають стиль написання програм [1]. Найб^ьш поширеними е: iмперативне програмуван-ня, декларативне програмування, структурне про-грамування, функщональне програмування, логiчне програмування та об'ектно-орiентоване програму-вання. Кожна з цих парадигм знаходить застосування в рiзних областях програмування, але однозначно, на сьогодш найб^ьш розповсюдженим е об'ектно-о-рiентоване програмування (ООП) [2]. Причина його усшху полягае у тому, що саме ООП виршуе одну з найзначшших проблем програмування - складшсть. Чим бiльша i складнiша програма, тим важче розби-ти 11 на невеликi та чiтко обмежеш блоки. Розбиття програми на класи, яю з певною мiрою абстракцп представляють реальнi об'екти, справляеться з щею проблемою [2].
Але, хоч об'ектно-орiентоване програмування представляе ряд способiв для розпод^ення функщо-нальностi на модулi, функцп та класи, iснуе функщо-нал, який не вдаеться винести в окрему сутшсть засо-бами ООП. Такий функщонал називають наскрiзним, так як його реалiзацiя розподiлена по рiзним модулям програми [3]. Це призводить до розосередження коду програми, тдвищуе складшсть його розумшня та ускладнюе супровiд програмного забезпечення.
Ця проблема е надзвичайно актуальною, у зв'язку з необхщшстю автоматизаци велико'! кiлькостi бiзнес процесiв. При автоматизацii iснуе необхщшсть вирь шити двi групи завдань, а саме: завдання, що пов'я-заш з логiкою бiзнес процесу, та завдання, пов'язаш з сервшним функцiоналом, велика частина якого е наскрiзним. При високiй складностi систем ршенням цих завдань можуть займатися рiзнi розробники, тому вкрай важливо мати можлившть видiлити '1х в окремi модулi. Для вирiшення ще'1 проблеми було створено аспектно-орiентовану парадигму програ-мування.
Аспектно-орiентований пiдхiд (АОП) дозволяе ви-дiлити наскрiзний функцiонал в окрему сутшсть, що дозволяе роздшити бiзнес логiку та сервiсний код. Основними поняттями АОП являються [4]:
- аспект - модуль чи клас, що реалiзуе наскрiзний функщонал. Аспект змшюе поведiнку коду, застосову-ючи пораду в точках з'еднання, що визначеш певним зрiзом;
- порада - за«б оформлення коду, який повинен бути викликаний iз точки з'еднання;
©
г
- точка з'еднання - точка в программ де n0Tpi6H0 використати пораду;
- зрiз - набiр точок з'еднання;
- впровадження - змша структури класу чи змша iерархii наслiдування для додавання функцюнальнос-т в код.
Проте iснуе проблема складност реалiзацii впровадження в об'ектно-орiентованих мовах програму-вання.
2. Аналiз лiтературних даних i постановка проблеми
Об'ектно-орiентованi мови програмування з лег-кiстю дозволяють реалiзувати такi сутносп АОП, як аспект, порада, точка з'еднання та зрiз, але не представ-ляють стандартних засобiв реалiзацii впровадження. Для його реалiзацii шнуе 2 основнi пiдходи [1]:
1. Впровадження на етат компiляцii.
2. Впровадження на етат виконання.
Впровадження на етат комтляцп мае таю переваги, як висока швидкодiя та можливкть впровадження в будь-яких мкцях програми [5]. Але мае i суттевий недолж - необхвдшсть модифiкацii компiлятора. Це призводить до ряду проблем. Так, програму, написа-ну з використанням впровадження аспекпв на етат комтляцп, неможливо комтлювати на звичайному, не модифжованому компiляторi [2]. Це значно усклад-нюе процес командноi розробки i розробки програм з вщкритим сирцевим кодом. 1ншим недолiком е те, що при оновленi версп компiлятора, необхщно вносити вiдповiднi змiни i в вераю з пiдтримкою впровадження аспекпв. Для мови програмування C# такий пiдхiд використовуе фреймворк PostSharp. Цей фреймворк модифжуе стандартний процес комтляцп, що доз-воляе використовувати широкий спектр точок впро-вадження [6]. Але програма, написана за допомогою цього фреймворку, не може бути скомтльована стан-дартним комтлятором. Для мови програмування Java шнуе фреймворк AspectJ з аналопчними перевагами та проблемами [4].
Впровадження на етат виконання значно посту-паеться в швидкодп та в гнучкост [7]. Б^ьшкть АОП фреймворкiв, що працюють на етат виконання, вико-ристовують генерацiю проксi класiв, що, як мжмум, подвоюе кiлькiсть викликiв функцш пiд час виконання програми. Впровадження методом генерацп проксi значно обмежуе спектр можливих точок з'еднання. Але найбшьшою проблемою е те, що неявна генеращя проксi можлива лише за умови створення екземплярiв об'екпв за допомогою контейнера залежностей, тобто лише в програмах, як використовують принцип швер-сп залежностей [8]. В протилежному випадку, в про-грамi замiсть використання стандартного оператора створення об'екту виникае необхщшсть використову-вати фабрику - породжуючий шаблон проектування [3], що створить потрiбний проксь Незважаючи на численнi недолiки, вщсутшсть необхiдностi модифжа-цii компiлятора робить метод впровадження на етат комтляцп досить популярним, особливо враховуючи те, що бшьшшть програм рiвня корпорацп використовують принцип iнверсii залежностей [2]. Зазвичай АОП фреймворки такого типу являються модулями для конкретних Inversion of control (IOC) контейне-
рiв, що унеможливлюе змшу контейнера, без змши аспектiв. Такий пiдхiд широко застосовуеться в мовi програмування C#, наприклад, IOC контейнер Unity [9]. Для контейнера Castle Windsor кнують модулi для пiдтримки АОП, а також е можлившть самостiйноi реалiзацii АОП [10].
Оскiльки обидва методи мають як переваги так i недолiки, iснують бiблiотеки для впровадження АОП як на етат комтляцп, так i на етат виконання [11]. Але виникае проблема неможливост змши типу впровадження без змши коду. Адже бiблiотеки мають рiз-ний синтаксис оголошення аспекпв i ряд iнших ввд-мшностей. Крiм того, розробник мае вмии працювати з рiзними бiблiотеками впровадження АОП, адже рiзнi задачi можуть потребувати рiзнi типи впроваджен-ня. Тому постае задача розробки фреймворка, який тдтримуватиме рiзнi типи впровадження аспектiв з единим синтаксисом '¿х оголошення. Такий фреймворк повинен представити зручний синтаксис оголошення аспекпв та систему, яка дозволить вибрати споиб впровадження, або ж створити свш власний. Серед необхщних способiв впровадження необхiдно мати як способи на етат комтляцп, так i на етат виконання. Крiм того, способи штеграцп на етат виконання по-виннi тдтримувати DI фреймворки, а також надати споаб iнтеграцii без використання DI.
3. Мета i завдання дослщження
Метою роботи е розробка фреймворку, який дозволить виконати впровадження наскрiзного функщоналу в об'ектно-орiентований програмний код. Важливою вимогою е незалежшсть оголошення та впровадження аспекпв, що дозволить застосовувати розроблений фреймворк для виршення рiзних типiв задач.
Для досягнення поставлено! мети були поставлен наступш завдання:
- розробити архиектуру, яка забезпечить незалежшсть впровадження вiд оголошення;
- розробити синтаксис оголошення аспекпв та за-безпечити можливiсть його розширення та модифжацп;
- розробити засоби впровадження на етат комтляцп та розробити модифжащю комтлятора для ix пiдтримки;
- розробити засоби штеграцп на етат виконання та створити модулi для найб^ьш популярних IOC кон-тейнерiв для спрощення ix тдключення;
- розробити прототип системи та модульш тести для перевiрки якостi та швидкостi роботи.
4. Архитектура рiшення проблеми
Для забезпечення незалежност опису та впровадження наскрiзного функцiоналу пропонуеться використати шаблон проектування мкт. У такому випадку абстракщею виступатиме абстрактний клас Aspect, що включае в себе метод визначення зрiзу та метод-пора-ду. А реалiзацiею виступатиме деякий абстрактний клас Introduction, з методом Introduce, який забезпечить штегращю аспекту. Рiзнi реалiзацii цього класу можуть забезпечувати як впровадження на етат комтляцп так i на етат виконання (рис. 1).
Рис. 1. Концептуальна дiаграма клаав
Клас Aspect може мати нащадкiв, як призначе-m для реалiзацii типового HacKpi3Horo функцiоналу. Наприклад, клас LogAspect забезпечуе ведення протоколу роботи програми, а клас AuthAspect дозволяе обмежувати доступ до певних методiв та властивостей. Також, розробники можуть створити своi нащадки класу Aspect з потрiбним функцiоналом. Для реалiза-цii не складних аспектiв доречним буде FluentAspect, який дозволяе налаштувати наскрiзну поведiнку у Fluent стиль
Для штеграцп на етапi виконання з використанням IOC, нащадок класу Introduce конф^уруе контейнер створюючи потрiбнi перехоплювачi. Якщо конкретний IOC не тдтримуе перехоплювачi, то конфiгуруеться проксь Для iнтеграцii на етапi виконання без викори-стання IOC виконуеться конф^уращя фабрик. Клас CompileTimelntroduction забезпечуе модифжований компiлятор необхiдними даними для впровадження аспекпв в потрiбних точках коду в процес компiляцii.
Крiм класiв Aspect та Introduction необхщш сер-вiснi класи, такi як AdviceConfigurationContext та PointcutConfigurationContex. Вони забезпечують гнуч-кий спосiб конфiгурацii поради та зрiзу точок з'еднан-ня ввдповвдно. Для iнiцiалiзацii аспектiв в програмi iснуе клас Bootstraper, який використовуе класи iерар-xii AspectProvider для отримання визначення аспектiв, що зареестрованi в програмi. Кожен провайдер успад-ковуеться вiд AspectProvider та реалiзуе його метод GetAspect(). Наприклад, ConfigurationAspectProvider повертае аспекти, що зареестроваш за допомогою класу конф^урацп, а AttributeAspectProvider повертае аспекти зареестроваш за допомогою атрибупв реестра-цii аспектiв.
Така архiтектура забезпечуе можлившть створення нащадкiв класу Aspect та пов'язаних з ним клаав кон-ф^урацп незалежно вiд нащадюв класу Introduction. А це означае, що штерфейс оголошення аспектiв буде незалежним вщ способу впровадження.
5. Процес розробки системи
6 три основш архггектурш аспекти, якi повинш бути визначенi для забезпечення функщональних ви-мог, до початку розробки. Щ рiшення:
1. Кордони (Boundaries).
2. Структура (Structure).
3. Модель домену (Domain model).
5. 1. Визначення кордошв
Перед створенням будь-яких артефакив (код або дiаграми), архитектор повинен зрозумии мету рiшення i де це рiшення пiдходить в контекст бiзнес-проблеми. Це е виршальним. Зокрема, архiтектор повинен мати уявлення про те, як об'екти виступають в якостi вхо-дiв до ршення, i якi об'екти потрiбнi для вирiшення, щоб виконати бiзнес-вимоги. Архiтектор також повинен зрозумии потiк бiзнес-операцiй, тобто як вони виконуються вручну.
Знання кордошв ршення дае архiтекторовi розумш-ня цiлi, до яюл вiн може вести розробку. Це також забезпечуе архитектору можливкть взаемодiяти з замовником та перевiрити правильнiсть розумiння потреб. Це кри-тичний перший крок до визначення структури ршення.
У системi впровадження аспекпв в програмний код можна вид^ити такi вимоги:
- 3MÍHa поведшки коду без змши самого коду;
- iнкапсуляцiя наскрiзного функцiоналу у окремi сутностi - аспекти;
- синтаксис оголошення аспекпв не повинен зале-жати ввд методiв впровадження;
- створення власних способiв впровадження;
- створення власних варiацiй синтаксису оголошення.
З цих вимог можна зробити висновок, що система мае взаeмодiяти з зовшшшми способами впровадження, яю можуть являти собою комтлятор, якщо впровадження вiдбуваeться на етат компiляцii або з механiзмом прив'язки титв, у випадку впровадження на етат виконання.
5. 2. Структурування ршення
Структурування ршення - одне з найважливь ших завдань, що повинен виршити архiтектор. Не визначення структури ршення може призвести до його громкткост i викликати складношд в розробцi i пiдтримцi. Ршення може забезпечувати виконання вимог, що не потрiбнi на поточний момент, але це дасть можлившть розширення в майбутньому.
Одним з перших артефакпв при виконаннi структурування е схема концептуальноi архiтектури. Концептуальна архитектура визначае, як функщональш вимоги будуть виконанi в структур^ визначенiй для рiшення. Визначення концептуальноi архiтектури повинно включати:
- як ршення пiддаeться зовнiшнiм процесам, як користувачi будуть взаeмодiяти з ршенням;
- як угоди будуть здшснюватися протягом всього рiшення, як обласи рiшення будуть доступнi i тдда-ватися манiпуляцiям;
- як ршення буде обробляти поди всередиш i зовнi.
Визначаючи структуру ршення на початку про-
цесу, архитектор може почати спiлкуватися з рiзними зацiкавленими сторонами. Бiзнес спонсори часто ви-користовують концептуальну схему, щоб почати ство-рення маркетингу для ршення.
Використовуючи iнструмент моделювання, який дозволяе архiтекторовi визначити концептуальну архитектуру при створеннi робочий потоку ршення, можна звести до мiнiмуму будь-яку двозначшсть архь тектури, i можна показати будь-як технiчнi питання, яю можуть виникнути.
Пiсля перевiрки правильносп кордонiв, можна приступити до структуризацп рiшення. Вiд початко-вого аналiзу, ми знаемо наступнi вимоги ршення:
- iснуe необхiднiсть iнтеграцii як на етат комтля-цii, так i на етат виконання;
- необхщно забезпечити незалежнiсть оголошення вщ способу впровадження аспектiв;
- способи впровадження можуть як поставлятись разом з фреймворком, так i у виглядi окремих бiблi-отек;
- користувач може розробити власш способи впро-вадження;
- синтаксис оголошення може бути рiзним, а саме з використанням наслвдування та перевизначення мето-дiв аспекпв, створення GENERIC аспектiв та гнучка конфжуращя (Fluent Api).
З цих потреб можна зробити висновок про необ-хщшсть розбиття системи на 2 модулi - оголошення
та штегращю. KpiM того, у випадку штеграцп на eTani комшляцп необхiдний окремий модуль, що е модифiкaцieю компiляторa. А у випадку штеграцп на етат виконання необхщний модуль, що забез-печить створення перехоплювача чи проксi. З ядра також можна видшити модуль конф^урацп, який може модифiкувaтися, для змши синтаксису оголошення (рис. 2).
Рис. 2. Структурна схема системи
5. 3. Проектування моделi предметно!' обласи
Концептуальна архиектура е важливим першим артефактом в архiтектурi ршення, але це тiльки перший крок. Взявши концептуальну структурну схему за основу, ïï можна розширювати та деталiзувати.
Модель предметно! област мiстить об'екти, якi не-обхщш для виконання функцiональних вимог. Модель також визначае вщносини мiж об'ектами. Ця частина визначення виршення також потребуе архитектора розглянути, як контролювати доступ до об'ектiв домену i як координувати операцп в домеш. Результат мо-делювання домену може включати в себе будь-яку або всi з наступних рiвнiв застосунку: frameworks, object models, service definitions.
Проаналiзувавши функщональне навантаження на кожен з модулiв, можна побудувати його структуру. Вона повинна забезпечувати зручне розширення сис-теми та бути легкою в розумшш. На рис. 3 представлена дiаграма клаав системi iнтеграцiï аспекив.
Опис класiв:
1) Bootstrapper - точка входу в систему. Аспекти по-чинають дiяти пiсля виклику методу Bootsprap.
2) IConfigurator - штерфейс, що забезпечуе отри-мання конфжурацп. Configurator - його базова абстрактна реалiзацiя.
3) Configuration - збержае налаштування iнтеграцiï та аспекпв.
4) IaspectProvider - штерфейс що забезпечуе от-римання списку аспекпв. Його реалiзацiï Configura-tionAspectProvider, ExternalConfigurationAspectProvid er, AttributeAspectProvider забезпечують рiзнi способи пошуку оголошення аспектiв, ввдповвдно: напряму в контекстi конфiгурацiï — AspectConfigurationContext, в зовнiшньому джерелi (напр. XML файл конфжурацп) та за допомогою атрибутiв.
5) IAspect - штерфейс, що представляе собою аб-стракцiю сутностi аспекту, та мае два методи, яю забезпечують отримання зрiзу та поради. В системi визначено його 3 базовi реалiзацii.
6) Aspect - абстрактна реалiзацiя iнтерфейсу Iaspect, наслщуючись вiд якого та визначаючи методи Advice i Pointcut можна оголосити свш аспект. Також позначивши нащадка атрибутом AutoRegAspect, мож-на забезпечити його автоматичне використання.
7) GenericAspect - узагальнений клас, що приймае аргументи типи, обмежеш нащадками штерфейшв IadviceProvider IpointcutProvider. Застосування цього класу як бази для аспекпв доцiльно тодi, коли iснуе необхщшсть розмежувати зрiз та пораду.
8) FluentAspect - забезпечуе створення аспекту тд час виконання у гнучкому стиль Може бути швидко застосований для невеликих аспекпв, або для тимча-сових аспектiв в процеи налагоджування програми.
9) Advice - представляе собою пораду. Його методи виконуються у вщповщних мiсцях кожно' точки з'ед-нання.
10) ExecutionContext - представляе контекст виконання програми, з необхщною шформащею для методу поради.
11) Pointcut - представляе зрiз, включае в себе на-бiр точок з'еднання.
12) Joinpoint - точка з'еднання, описуе, в якому мш-щ програми необхiдно впровадити аспект.
13) Introduction - клас, що забезпечуе впроваджен-ня. Мае один абстрактний метод Introduce, який при визначеш в нащадку виконуе впровадження.
14) CompileTimeIntroduction - е основою для мето-дiв впровадження на етат комтляцп.
15) ExecutionTimeIntroduction - е основою для мето-дiв впровадження на етапi виконання.
6. 1нфрастуктура системи
В данiй програмнш системi база даних вико-ристовуеться для збереження налаштувань аспек-ив. Була створена наступна множина статичних клаив (рис. 4).
Рис. 4. Дiаграма статичних класiв
AspectConfig - клас для збереження конф^урацп аспекпв. Може зберiгати або назву типу для створення ввдомого зрiзу або PontcutConfig i AdviceConfig для конструювання динамiчного аспекту.
Рис. 3. Дiаграма класiв
PontcutConfig - клас призначений для збереження конф1гурацп 3pi3iB. Може збер1гати або назву типу для створення ввдомого 3pi3y або набiр Joinpoint для конструювання динамiчного 3pi3y.
JoinpointConfig - клас, призначений для збереження назви типу зрiзy та параметрiв, необхвдних для створення об'екту.
AdviceConfig - клас, призначений для збер1гання назви типу поради та параметрiв необхiдних для створення об'екту.
Для збер1гання статичноï iнформацiï системи ви-користовуеться реляцiйна база даних, так як вона за-безпечуе високий рiвень незалежностi структури збереження даних вщ структури програми. В процеа ïï розробки було побудовано концептуальну схему бази даних (рис. 5), а на ïï основi побудовано даталопчну модель (рис. 6).
Таблиця 1
Структура таблиц AspectConfig
1 Pointe ut ' AdviceConfig ]
Id Id
2] Name 2] Name
Ц Description ^ Description
TypeName |~l] TypeName
Щ CtorArgs ^AcpectConfig "" 3 CtorArgs
AspectConfig Id и AspectConfig Id
[l] Name
3 Description
TypeName
fj^ CtorArgs
Щ Is Active
( JoinPoin ^
'It Id
^ Name
[l^ Description
f|] TypeName
Щ CtorArgs
[3 Pointcutld
Рис. 5. Концептуальна схема бази даних
f Pointent \
Id lnteger(10)
Щ Name varchar(255)
^ Description varchar(max) W
Щ TypeName varchar(255) CÎJ
Щ CtorArgs varchar(max) CÎJ
Щ AspectConfig Id integer(10) IÄJ-B
f AcpectConfig \
f W Integer(IO)
f]^ Name varchar(255)
f^ Description varchar(max) Cil
fi^ TypeName varchar(255) Ci)
CtorArgs varchar(max) Ci)
IsActive bit Ci)
f JoinPoin л
Id lnteger(10)
|~fl Name varchar(255)
^ Description varchar(max) Iii
^ TypeName varchar(255) на
U CtorArgs varchar(max) m
^ Pointcutld integer(10) M
{ AdviceConfig \
? И integer(10)
|~fl Name varclw(255)
f^ Description varclrar(max) m
f^ TypeName varchar(255) lül
|~fl CtorArgs varclrar(max) lüJ
Щ AspectConfig Id integer(10) lil-и
ewe red By Visual Paradigm Community Edition 1
Рис. 6. Даталопчна схема бази даних
У табл. 1-4 представлено опис полiв бази даних.
База даних використовуе лише стандартш SQL типи даних та не мае збережених процедур чи функ-цш, що дозволяе розмiщувати ii на будь-якому су-часному SQL серверь KpiM того, iснуе можлившть перевизначити провайдер даних та використати для збереження iнформацii NoSQL базу чи iншi типи по-стiйних сховищ.
Назва стовпчика Тип даних Опис
Id integer(10) Ушкальний iдентифiкатор
Name Varchar(255) Логiчна назва аспекта (напр. аспект ведення протоколу роботи)
Description Varchar(MAX) Опис аспекту
TypeName Varchar(255) Повна назва системного типу аспекту для рефлексшного створення
CtorArgs Varchar(MAX) Агрументи конструктора для Мщашзацп' типу аспекта
IsActive Bit Прапорець. Показуе чи активний данний аспект
Таблиця 2 Структура таблиц PointcutConfig
Назва стовпчика Тип даних Опис
Id integer(10) Ушкальний щентифшатор
Name Varchar(255) Лопчна назва зрiзy (напр. методи, назва яких закш-чуеться на AppService та методи що позначеш атрибутом Log)
Description Varchar(MAX) Опис зрiзy
TypeName Varchar(255) Повна назва системного типу зрiзy для рефлексiйного створення
CtorArgs Varchar(MAX) Агрументи конструктора для iнiцiалiзацiï типу зрiзy
Таблиця 3 Структура таблиц JoinPointConfig
Назва стовпчика Тип даних Опис
Id integer(10) Ушкальний щентифжатор
Name Varchar(255) Логiчна назва точки впроваджен-ня (напр. поля з навою User)
Description Varchar(MAX) Опис точки впровадження
TypeName Varchar(255) Повна назва системного типу точки впровадження для рефлексшного створення
CtorArgs Varchar(MAX) Агрументи конструктора для шщашзаци типу точки впровадження
Таблиця 4 Структура таблиц AdviceConfig
Назва стовпчика Тип даних Опис
Id integer(10) Ушкальний щентифшатор
Name Varchar(255) Лопчна назва поради (напр. запи-сати назву методу в файл)
Description Varchar(MAX) Опис поради
TypeName Varchar(255) Повна назва системного типу поради для рефлексшного створення
CtorArgs Varchar(MAX) Агрументи конструктора для iнiцiалiзацiï типу поради
7. Модуи та розгортання системи
7. 1. Дiаграма компонент
Го ловним компонентом системи е бiб лiотека Saspect. dll, яка використовуючи компонент Bootstrapper впро-ваджуе в програму клiента аспекти. Для налаштування аспектiв використовуеться Configurator, що забезпечуе отримання конф^урацп з вказаним провайдером ас-пектiв та метод штеграцп. Метод iнтеграцii реалiзова-ний у виглядi окремого компоненту та завантажуеться динамiчно, саме такий, який було сконф^уровано. Для деяких методiв iнтеграцii необхiдний компонент ком-тлятора (SaspectBuilder) (рис. 7).
7. 2. Дiаграма розташування
Зазвичай вся система розташовуеться на комп'юте-рi розробника-користувача фреймворку. Якщо при розробцi програм застосовуеться сервер побудови про-грам, то система мае бути розмщена також i на серверi (рис. 8). У випадку використання штеграцп на ета-т компiляцii, модифжований компiлятор також мае бути розмщений на комп'ютерi розробника-користу-вача та на серверь
З дiаграм розмщення можна зробити висновок, що розгортання системи е вщносно простим, особливо у випадку використання штеграцп на етат виконання.
Рис. 7. Дiаграма компоненлв фреймворку штеграцп аспектiв
Рис. 8. Дiаграма розташування фреймворку штеграцп аспекпв
8. Приклад використання фреймворку
Нехай маемо типову задачу: необхщно створити WEB-сервш, що забезпечуе отримання, створення, оновлення та видалення коpиcтувачiв певно! системи. З використанням сучасних технологш побудови веб API та ORM фреймфорка, на перший погляд код сервшу буде простим. Розроблено демонстрацшний сервш на мовi програмування C# та з використанням технологи WebApi. (рис. 9).
Але у реальних задача виникае потреба в реа-лiзацiï такого функщоналу, як ведення журналу, обробки помилок, обмеження доступу, пepeвipки на коректшсть для аргуменпв та iншi типовi задачi [12].
В результат^ наприклад, метод Get, що займав один рядок коду, значно зб^ьшився в обcязi i це усклад-нило його розумшня (рис. 10). Кpiм того, у pазi не-обхiдноcтi змiнити поведшку, наприклад ведення журналу, може виникнути необхщшсть змiнювати виклики в у«х мicцях, де вiн застосовуеться.
Використання аспекшв дозволяе видiлити на-cкpiзний функцiонал в окpeмi cутноcтi. Так, з використанням аспекпв, метод Get залишаеться таким же компактним, як на рис. 9, i, в той же час, мае функцiонал, як на рис. 10. Саме ж оголошення пове-дiнки аcпeктiв зiбpанe о однiй cутноcтi, що дозволяе легко розумгги та модepнiзовувати код програми (рис. 11).
Рис. 9. Базова реалiзацiя cepBicy обслуговування користувача
public User Get(int id) {
if(id < 0) {
Log.Warn("Bad input value - id");
throw new ArgumentException("Id must be > 0");
}
if ( ! User .Current .HasPermission("GetUser")) {
Log»Warn("User {6} have not permission."jUser.Current); throw new PermissionMissingException("You can not get user")]
>
try {
Log.Trace("Begin execution getting user with id = {0}", id); var result = context.User.FirstOrDefault(r => r.id == id); Log.Trace("ExecLiticn getting user with id = {0} and return {1}",id,result) return result;
}
catch(SQLException ex) {
Log.Error("SQL exception on user get", ex); HandleSQlException(ex);
}
catch(Eception ex) {
Log.Error("Unknown exception in user get", ex); HandleException(ex);
}
finally {
context.Dispose();
}
Рис. 10. Код методу Get з додатковим функцюналом
public class ExceptionHandlerAspect: Aspect {
public ovverider void Pointcut(PointcutConfigurationContext context) {
contxt.CreateDoinPoit().OnMethodCa11().InClass(r => r.Name.EndWith("Service"));
>
public override void Advice(AdviceConfigurationContext context) {
context.OnException(ec => {
if(ec.Exception is SqlException) {
Log.Error("SQL Exception on {l}"jec.MethodName)j
»
}
else {
}
Log.Errar("Unknown exception on {1} {2}"jex.MethodNamejec.Exception);
Рис. 11. Аспект обробки виключень у методах веб cepeicy
Одного разу оголошений аспект ввдпрацьовуе в у«х налаштованих мкцях, що значно зменшуе обсяг коду (табл. 5), особливо на складних програмних системах, яю е характерними в Enterprise сегмент [13]. Також використання аспекпв е надзвичайно ефективним при виршеш задач моделювання, де в наявноcтi складна i мiнлива логiка та структура програми та стаб^ьний cepвicний код.
Таблиця 5
Юлькють рядкiв сирцевого коду
Юльюсть рядгав сирцевого коду до впровадження аспекпв Кльгасть рядгав сирцевого коду тсля впровадження аспекпв
5000 4228
10000 7906
15000 11584
20000 15262
25000 18940
30000 22618
35000 26296
40000 29974
45000 33652
50000 37330
Можна зробити висновок, що використання аспек-пв дозволяе досягти значного скорочення сирцевого коду, особливо для великих за обсягом програм.
9. Висновки
1. Розроблено архггектурне ршення, яке забезпе-чуе можливicть оголошення аспекпв в нeзалeжноcтi вiд способу '¿х iнтeгpацiï. Для досягнення незалеж-ност використано шаблон проектування мicт та ряд породжуючих шаблонiв, таких як фабричний метод, будiвeльник та абстрактна фабрика.
2. Розроблено три способи оголошення аспекпв, а саме: оголошення за допомогою наслвдування вiд базового класу, узагальнення шаблонного класу, та гнучке створення аспекту на етат виконання.
3. Для штеграцп на етат комтляцп був розробле-ний спещальний модуль iнтeгpацiï та модифiкацiя комтлятора Roslyn, яка забезпечуе виконання системи конф^урацп аcпeктiв та впроваджуе в код точки виклику порад.
4. Для штеграцп на етат виконання без вико-ристання контейнера залежностей розроблено мето-ди-помiчники для створення прок« клаив. Також розроблено модулi для популярних контeйнepiв за-лежностей, як дозволяють виконати iнтeгpацiю засо-бами цих контeйнepiв.
5. Проведено тестування pозpоблeноï системи, яке показало значне скорочення pозмipу сирцевого коду. Найб^ьш виражене скорочення було у великих системах piвня пiдпpиемcтва. При використанш впро-вадження на етат комтляцп падшня швидкодiï про-грам не виявлено. При використанш штеграцп на етат виконання втрати швидкодп не перевищують таких при використанш аналопчного пpокci класу.
Лiтература
1. Floyd, R. The Paradigms of Programming [Text] / R. W. Floyd // Communications of the ACM. - 1979. - Vol. 22, Issue 8. -P. 455-460. doi: 10.1145/359138.359140
2. Бадд, Т. Объектно-ориентированное программирование в действии. [Текст] / Т. Бадд. - СПб.: «Питер», 1997. - 464 с.
3. Гамма, Е. Design Patterns: Elements of Reusable Object-Oriented Software [Text] / Е. Гамма, Р. Хелм, Р. Джонсон, Д. Влюа-дес. - СПб.: Питер, 2014. - 372 с.
4. Miles, R. AspectJ Cookbook [Text] / R. Miles. - O'Reilly Media, 2012. - 356 p.
5. Нейгел, К. С# 5.0 и платформа .NET 4.5 для профессионалов [Текст] / К. Нейгел, Б. Ивьен, Д. Глинн, К. Уотсон, М. Скин-нер. - М. : ООО «И.Д. Вильяме», 2013. - 1543 с.
6. Gael, F. PostSharp Roadmap and Support Policies Published [Electronic resource] / F. Gael. - PostSharp Blog, 2015. - Available at: http://www.postsharp.net/blog/post/PostSharp-Roadmap-and-Support-Policies-Published
7. Yang, H. Software Reuse in the Emerging Cloud Computing Era [Text] / H. Yang, X. Liu. - Information Science Reference, 2012. - 54 p. doi: 10.4018/978-1-4666-0897-9
8. Sells, C. Essential.NET: The common language runtime [Text] / C. Sells. - Addison-Wesley Professional, 2011.
9. Gael, F. Dino Esposito, Cutting Edge - Aspect-Oriented Programming, Interception and Unity 2.0 [Electronic resource] / F. Gael. - MSDN Magazine, 2013. - Available at: https://msdn.microsoft.com/en-us/magazine/gg490353.aspx
10. Rossi, J. Introduction to AOP With Castle [Electronic resource] / J. Rossi. - Castle Project Blog, 2015. - Available at: http:// docs.castleproject.org/Default.aspx?Page=Introduction-to-AOP-With-Castle&NS=Windsor&AspxAutoDetectCookieSupport=1
11. Win, B. Security through aspect-oriented programming [Text] / B. Win, B. Vanhaute, B. De Decker. - In Advances in Network and Distributed Systems Security, 2002. - P. 125-138. doi: 10.1007/0-306-46958-8_9
12. Kiczales, G. Aspect-oriented programming [Text] / G. Kiczales, J. Lamping, A.Mendhekar, C. Maeda, C. Lopes, J. M. Loingtier, J. Irwin // ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming, 1997. - P. 220-242. doi: 10.1007/BFb0053381
13. Fowler, M. Patterns of Enterprise Application Architectur [Text] / M. Fowler. - Addison Wesley, 2012.
-□ □-;-
Показано, що причиною високого вiд-сотку бракованих гумометалевих виробiв на виходi технологiчного процесу 1хньо-го виготовлення е инорування на еташ проектування зв'язностi параметрiв пгд-систем окремо всередин конструкци i технологИ, а також мiж цими тдсисте-мами. Побудована комплексна оптим^ зацшна модель конструкци та технологи. Запропонована комплексна символьна модель для еволющшноп оптимiзацii за допомогою генетичного алгоритму
Ключовi слова: гумометалевi вироби, зв'язтсть параметрiв, генетичш алго-
ритми, комплексш символьш моделi
□-□
Показано, что причиной большого процента бракованных резинометаллических изделий на выходе технологического процесса их изготовления является игнорирование на этапе проектирования связности параметров подсистем отдельно внутри конструкции и технологии, а также между этими подсистемами. Построена комплексная оптимизационная модель конструкции и технологии. Предложена комплексная символьная модель для эволюционной оптимизации с помощью генетического алгоритма
Ключевые слова: резинометаллические изделия, связность параметров, генетические алгоритмы, комплексные символьные модели -□ □-
УДК 004.942:62-272.6
|DOI: 10.15587/1729-4061.2016.65456|
1НФОРМАЦ1ЙН1 ТЕХНОЛОГИ ОПТИМ1ЗАЦИ
КОНСТРУКЦИ ТА ТЕХНОЛОГИ ВИГОТОВЛЕННЯ ГУМОМЕТАЛЕВИХ ВИРОБ1В
0. С. Савельева
Доктор техычних наук, доцент* E-mail: okssave@gmail.com
1. I. Становська Кандидат техычних наук**
E-mail: iraidasweet07@rambler.ru О. Ю. Лебедева* E-mail: ozrti@rambler.ru А. В. Торопен ко Кандидат техычних наук* E-mail: alla.androsyk@gmail.com *Кафедра нафтогазового та хiмiчного машинобудування*** **Кафедра вищоТ математики та моделювання систем*** ***Одеський нацюнальний полЬехшчний уыверситет пр. Шевченка, 1, м. Одеса, УкраТна, 65044
1. Вступ
При проектуванш конструкци i технологи виготовлення окремо гумових або окремо металевих виробiв, як правило, застосовуються рiзнi методи оптимiзацii, що обумовлюеться суттево рiзними властивостями цих матерiалiв та очевидними вщ-мшностями в умовах iхнього виготовлення та екс-плуатаци, а також в зовшшшх прихованих впливах
на вирiб. Натомшть, об'еднаш гумометалевi вироби (мехашчш амортизатори, автомоб^ьш покришки, корпуси тдводних човшв, магштна та електропро-вщна гуми, тощо) [1-4], хоча й складаються i3 суттево рiзнорiдних за властивостями елеменпв (металу та гуми), проектуються, виготовляються i працюють «як одна деталь», i отже вимагають при цьому деякого сумкного, комплексного тдходу на у«х перелiчених етапах свого життевого циклу.
