Способи визначення використання шаблонів проектування у вихідному коді програм на основі деревовидних структур даних

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Способи визначення використання шаблонів проектування у вихідному коді програм на основі деревовидних структур даних

Ткач Ю.М.

Вступ

Актуальність теми. Із розвитком комп'ютерної інженерії у інших сферах життя людини, зростає кількість та розмір розроблених систем. Із плином часу, створена система підтримується та розширюється за рахунок нових функціональних вимог до неї різними людьми або навіть компаніями. Це впливає на характеристики програмного забезпечення за різними показниками: кількість рядків вихідного коду, цикломатичнаскладність, метрики Халстедата інші. Для впорядкування вихідного коду та для вирішення типових задач при розробці використовують шаблони проектування. Такий підхід дозволяє прискорити розуміння зв'язаності частин коду за типовим використанням зав'язків спадкування та реалізації інженерам, що тільки підтримують розроблені системи та не приймали участі у створені. Тому створення засобів автоматизованого виявлення шаблонів проектування у існуючому вихідному є актуальним.

Процеси перетворення програмного коду, зміни внутрішньої структури програмного забезпечення для полегшення розуміння коду і легшого внесення подальших змін без зміни зовнішньої поведінки самої системи є нагальними проблемами у сфері рефакторингу вихідного коду. Наслідком зміни внутрішньої структури програмного коду може бути зменшення витрат часу необхідних для додавання нових функціональних можливостей або виправлення помилок в існуючому коді.

Складність виконання такої задачі полягає в тому, що виконувати перетворення неможливо без розуміння структури та мети створення конкретних модулів системи, що піддаються рефакторингу. Для полегшення розуміння укладу сукупності елементів у виділеній частині проекту та їх взаємозв'язків між собою часто використовують методи візуалізації. У якості елементів виступають структури даних, що використовуються мовою програмування, або відбувається перетворення до узагальнених елементів.

Незважаючи на велику кількість засобів для полегшення процесу зазначеного перетворення вихідного коду, відсутність в них достатньої автоматизованості спричиняє великі трудові затрати, тому існує необхідність створення нових способів для вирішення задач автоматизованого рефакторингу.

Однією з таких задач є автоматизація процесу зміни структури внутрішнього коду, що використовує шаблони проектування. Дана магістерська дисертації присвячена рішенню задачі прискорення процесу визначення наявності шаблонів проектування у програмах та розробці більш швидкого способу визначення наявності шаблонів проектування у програмах, ніж спосіб повного перебору.

Об'єктом дослідження є процес визначення використання шаблонів проектування у вихідному коді програм.

Предметом дослідження є способи визначення використання шаблонів проектування у вихідному коді програм на основі деревовидних структур даних.

Мета роботи: прискорення процесу визначення наявності шаблонів проектування у програмах, розробка більш швидкого способу визначення наявності шаблонів проектування у програмах, ніж спосіб повного перебору

Курсова робота складається з вступу, двох розділів та висновків.

1. Аналіз способів рефакторингу та методів виявлення шаблону проектування

1.1 Аналіз способів рефакторингу програмного забезпечення

Рефакторинг - це процес такої зміни програмної системи, за якої не змінюється зовнішня поведінка коду, але покращується його внутрішня структура. Це спосіб систематичного впорядкування програми, при якому шанси появи нових помилок є мінімальними. При проведенні рефакторингу коду покращується дизайн вже готової програми [13].

Покращення коду після його написання може виявитись дещо дивним, оскільки в сьогоднішньому розумінні розробки програмного забезпечення спочатку робиться дизайн системи, а потім пишеться код. З часом програма модифікується, і цілісність системи, відповідність її структури початковому плануванню поступово погіршується.

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

При проведенні рефакторингу виявляється, що відношення різних етапів роботи змінюється. Процес проектування розтягнуто на весь період розробки, а не сконцентровано лише на її початковому етапі. В процесі роботи над проектом стає зрозумілим, як його можна покращити. Така взаємодія призводить до створення програми, якість програмного коду якої залишається високою під час доповнення та розвитку продукту.

Основна ціль рефакторингу - зробити код простішим і зрозумілішим. Причому, рефакторингі оптимізація це далеко не одне і те ж. В результаті оптимізації код працює швидше, але не обов'язково є простішим і зрозумілішим. Рефакторинг - це спрощення і покращення розуміння коду розробниками, які будуть підтримувати поточний функціонал та розширювати його. Рефакторинг можна застосовувати до будь-якої програми. Частіше за все це робиться інтуїтивно. Якщо якийсь код є не дуже вдалим, або через певний період часу незрозуміло, що робить та чи інша частина програми, - потрібно здійснити рефакторинг. Можна виокремити деякі ознаки коду, над яким необхідно виконати перетворення для зниження складності за метриками. Типовими метриками для оцінювання коду у числових показниках є:

• порядок зростання (мається на увазі аналіз алгоритмів, в термінах теорії складності обчислень);

• кількість рядків коду;

• цикломатичнаскладність;

• кількість помилок на рядок коду;

• ступінь покриття коду тестуванням;

• покриття вимог;

• кількість класів та інтерфейсів;

• зв'язність;

• пов'язаність;

• розмір бінарних файлів.

Дублювання коду - одна з найпоширеніших причин для виконання рефакторингу. Код, який дублюється в програмі, є основним джерелом помилок. Якщо якась дія виконується у декількох різних місцях, але однаковою послідовністю команд, то цей код потрібно винести в окрему функцію і замінити старі місця на виклики нової функції. Інакше висока ймовірність того, що при виправленні помилки в одному місці копії команд залишаться не відредагованими, і у них залишиться помилка.

Як правило, людина не може повністю сприймати і оцінювати правильність коду, якщо він займає більше ніж 2-3 десятки рядків. Такі методи і функції потрібно розбивати на декілька дрібніших і робити одну загальну функцію, що буде послідовно викликати ці методи. Ніколи не варто скорочувати розмір функції, вписуючи декілька операторів в один рядок. Ймовірність допустити помилку в такому коді зростатиме.

Велика кількість параметрів зазвичай не тільки ускладнює розуміння того, що робить даний метод чи функція, але і ускладнює розуміння коду, що використовує цю функцію. Якщо ж дійсно є потреба у великій кількості параметрів функції, то їх необхідно винести в окрему структуру або клас і передавати вказівник чи посилання на об'єкт цієї структури чи класу.

Якщо у розробленому програмному забезпеченні є один або декілька великих класів, то їх необхідно розділити на менші, та включити об'єкти цих класів в один загальний клас.

Велика кількість тимчасових змінних також є ознакою проблемного коду, якому необхідний рефакторинг. Як правило, багато тимчасових змінних зустрічаються у занадто великих функціях, після рефакторингу яких, кількість змінних в них стане меншою і код стане значно зрозумілішим і зручнішим для подальшої модифікації.

Велика кількість звертань об'єктів одного класу до даних об'єкта іншого класу вказує на високу зв'язність структур даних. Потрібно переглянути функціонал об'єктів оскільки можливо, було прийняте невірне архітектурне рішення, і його потрібно поміняти якомога раніше, щоб помилка не поширилась по всьому коду.

Не доцільно створювати занадто багато глобальних змінних. Якщо ж така необхідність є, то потрібно спробувати згрупувати їх в структури, класи, або хоча б винести їх в окремий простір імен. Тоді шанс помилкового використання якоїсь змінної стане значно нижчим.

Основними стимулами для проведення рефакторингу є:

• додавання нової функції, яка недостатньо вкладається в прийняте архітектурне рішення;

• виправлення помилки, причини виникнення якої не є очевидними;

• подолання труднощів командної розробки, які зумовлені складною логікою програми.

Основними прийомами рефакторингу, що дозволяють поділити код на менші та зрозуміліші частини, є:

• відокремлення методу (Extract Method);

• відокремлення базового класу (Extract Superclass).

Основними прийомами рефакторингу, що дозволяють забезпечити

додаткову абстракцію, є:

• інкапсуляція поля (Encapsulate Field) -- замінює прямий доступ до поля на доступ через методи, що надають доступ для читання та запису;

• узагальнення типу (Generalize Type) -- заміна типів, з якими працює клас, на більш узагальнені;

• заміна блоків перевірки типів на шаблони «Стан» (State) або «Стратегія» (Strategy);

• заміна умовних операторів поліморфізмом с;

• створення поля або локальної змінної (Introduce Field/Introduce Local Variable).

Основними прийомами рефакторингу, що змінюють назви членів та їх розташування, є:

• переміщення метода класу (Move Method) або переміщення поля класу в інші класи або файли коду;

• перейменування члена класу (Rename) -- зміна імені, з автоматичною заміною всіх посилань на старе ім'я в коді;

• переміщення члена класу до базового/дочірнього класу (Pull Up/Push Down).

Ще одним способом є зміна архітектури проекту. Цей процес сильно залежить від методології керування проектами та проектування і тому така класифікація відсутня.

Рефакторинг вихідного коду можна поділити на два види за принципом виконання [1]:

• рефакторинг виконаний людиною або групою людей;

• автоматизований рефакторинг програмними засобами.

Переваги неавтоматизованого рефакторингу:

• дозволяє контрольованим способом перетворювати програмний код;

• вищий рівень якості зміни внутрішньої структури програмного забезпечення порівняно з автоматизованим рефакторингом;

• покращення розуміння коду для легшого внесення подальших змін без зміни зовнішньої поведінки самої системи.

Недоліки неавтоматизованого рефакторингу:

• тривалий час виконання;

• високий рівень складності при виконанні декомпозиції великого проекту;

• при залученні сторонніх осіб для рефакторингу можуть

виникнути проблеми порушення конфіденційності створеного проекту.

Переваги перетворюються у недоліки та навпаки у випадку застосування автоматизованого процесу рефакторингу вихідного коду.

При поєднанні таких двох ідей, як зміна архітектури проекту та використання шаблонів проектування, рефакторинг перетворюється на маніпуляції з шаблонами проектування.

Виділяють наступні види роботи з шаблонами у вихідному коді:

• додавання шаблонів для структуризації процесу;

• зміна структури шаблонів проектування для спрощення подальшої підтримки продукту та полегшення розуміння вихідного коду;

• повна відмова від шаблонів проектування. [1]

1.2 Шаблони проектування та їх представлення

У розробці програмного забезпечення шаблон проектування є загальним, багаторазовим рішенням для широко поширеної проблеми в заданому контексті при розробці програмного забезпечення. Це не закінчене рішення, яке можна перетворити безпосередньо в вихідний або машинний код. Це опис або шаблон для вирішення проблеми, яка може бути використана у багатьох різних ситуаціях. Шаблони проектування є формалізованими найкращими практиками, які програміст може використовувати для вирішення спільних проблем при розробці програми або системи.

Об'єктно-орієнтовані шаблони проектування, зазвичай демонструють взаємозв'язки та взаємодію між класами або об'єктами, не вказуючи застосування кінцевих класів програми або об'єктів, які беруть участь. Шаблони, що передбачають змінний стан, можуть бути неприйнятними для функціональних мов програмування. Деякі шаблони можуть бути винесені непотрібними в мовах, які мають вбудовану підтримку для вирішення проблеми, яку вони намагаються вирішити. Об'єктно-орієнтовані шаблони не завжди підходять для не об'єктно-орієнтованих мов програмування.

Шаблони проектування можуть розглядатися як структурований підхід до проміжного етапу у програмуванні між рівнями парадигми програмування та конкретним алгоритмом.

Шаблони проектування, які ми знаємо сьогодні, були створені Еріком Ґаммою, Річардом Хелмом, Ральфом Джонсоном та Джоном Вліссідсом. Вони опублікували книгу «Design Patterns-- Elements of Reusable Object - Oriented Software». У цій книзі описані 23 шаблони проектування. Також команда авторів цієї книги відома суспільству під назвою банда чотирьох (англ. Gang of Four - GoF). Саме ця книга послужила приводом до широкого поширення шаблонів проектування. З плином часу, додавалися нові шаблони проектування, які допомагали вирішувати інші типові архітектурні питання.

Класифікація шаблонів проектування за трьома типами була представлена у книзі банди чотирьох [3]:

• твірні (породжуючі) шаблони;

• структурні шаблони;

• шаблони поведінки.

Кожен із шаблонів проектування може бути формально описаний за допомогою структурної UML діаграми, а саме діаграми класів.

Діаграма класів -- статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм. Діаграма класів служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об'єкти, а також їх відносини.

Декларативні частини діаграми мають методи та атрибути, як складові елементи. Для кожного типу елементу можна виділити дві характеристики: межі використання та видимість. Під межами використання розуміється використання методів або атрибутів: статичний, той що належить класу, або об'єктний, той що належить створеному об'єкту класу. Для задання видимості використовують позначення, що зображені на табл. 1.1. Одну з позначок необхідно вказати перед ім'ям методу або атрибуту.

Таблиця 1.1. Позначки для вказання видимості елементів діаграми класів

Позначення	Пояснення позначення
+	публічний
-	приватний
#	захищений
/	наслідуваний
~	пакетний
*	випадковий

Існує декілька видів зав'язків між елементами діаграми класів. Їх можна поділити на два типи за елементами між якими вони існують: зв'язок на рівні об'єктів та зв'язок на рівні класів або інтерфейсів. Нижче наведено список можливих зав'язків між елементами на діаграмі класів.

Відношення залежності в загальному випадку вказує деяке семантичне відношення між двома елементами моделі або двома множинами таких елементів, яке не є відношенням асоціації, узагальнення або реалізації. Воно стосується тільки самих елементів моделі і не потребує множини окремих прикладів для пояснення свого змісту. Відношення залежності використовується в такій ситуації, коли деяка зміна одного елемента моделі може потребувати зміну іншого залежного від неї елемента моделі.

Відношення залежності графічно зображається пунктирною лінією між відповідними елементами зі стрілкою на одному з її кінців. На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу-клієнта залежності до незалежного класу або класу- джерела.

В якості класу-клієнта і класу-джерела залежності можуть виступати цілі множини елементів моделі. У цьому випадку одна лінія зі стрілкою, що виходить від джерела залежності, розщеплюється в деякій точці на декілька окремих ліній, кожна з яких має окрему стрілку для класу-клієнта.

Стрілка може помічатися необов'язковим, але стандартним ключовим словом в лапках і необов'язковим індивідуальним іменем. Для відношення залежності визначені ключові слова, які позначають деякі спеціальні види залежностей. Ці ключові слова записуються в лапках поруч зі стрілкою, яка відповідає даній залежності. Прикладами стереотипів для відношення залежності можуть бути:

* «access» -- служить для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів;

* «bind» -- клас-клієнт може використовувати деякий шаблон для своєї наступної параметризації;

* «derive» -- атрибути класу-клієнта можуть бути обчислені за атрибутам класу-джерела;

* «import» -- відкриті атрибути і операції класу-джерела стають частиною класу-клієнта, так як би вони були оголошені безпосередньо в ньому;

* «refine» -- вказує, що клас-клієнт служить уточненням класу- джерела з історичних причин, коли з'являється додаткова інформація в ході роботи над проектом.

Відношення асоціації відповідає наявності деякого відношення між класами. Дане відношення позначається суцільною лінією з додатковими спеціальними символами, які характеризують окремі властивості конкретної асоціації. Як додаткові спеціальні символи можуть використовуватися ім'я асоціації, а також імена і кратність класів-ролей асоціації. Ім'я асоціації є необов'язковим елементом її позначення. Якщо воно задане, то записується з великої букви поруч з лінією відповідної асоціації. [14]

Найбільш простий випадок даного відношення -- бінарна асоціація. Вона зв'язує два класи і, як виняток, може зв'язувати клас з самим собою. Для бінарною асоціації на діаграмі може бути вказано порядок слідування класів з використанням трикутника в формі стрілки поруч з іменем даної асоціації. Напрямок цієї стрілки вказує на порядок класів, один із яких є першим (зі сторони трикутника), а інший -- другим (зі сторони вершини трикутника). Відсутність даної стрілки поруч з іменем асоціації означає, що порядок слідування класів у цьому відношенні не визначений.

Тернарна асоціація і асоціації з більшою кількістю зв'язуваних класів, в загальному випадку називаються N-арною асоціацією. Така асоціація зв'язує деяким відношенням 3 і більше класів, при цьому один клас може брати участь в асоціації більше ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказано на діаграмі. Кожен екземпляр N-арної асоціації представляє собою N-арний кортеж значень об'єктів із відповідних класів. Бінарна асоціація є частковим випадком N-арної асоціації, коли N=2, і має своє власне позначення.

N-арна асоціація графічно позначається ромбом, від якого ведуть лінії до символів класів даної асоціації. У цьому випадку ромб з'єднується з символами відповідних класів суцільними лініями.

Порядок класів в N-арній асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N-арної асоціації, а сама N-арна асоціація має атрибути, операції, асоціації. Іншими словами, така асоціація, у свою чергу, є класом з відповідним позначенням у виді прямокутника і є самостійним елементом мови UML -- асоціацією-класом (Association Class). [5]

Окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. Для цієї мети у мові UML вводиться спеціальний елемент -- кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінців асоціації. Найбільш важливі властивості асоціації вказуються на діаграмі поруч з цими елементами асоціації. [14]

Одним із таких додаткових позначень є ім'я ролі окремого класу, який входить в асоціацію. Ім'я ролі представляє собою стрічку тексту поруч з кінцем асоціації для відповідного класу. Вона вказує специфічну роль, яку відіграє клас, який є кінцем асоціації. Ім'я ролі не є обов'язковим елементом позначень.

Наступний елемент позначень -- кратність окремих класів, які є кінцями асоціації. Кратність окремого класу позначається у виді інтервалу цілих чисел, аналогічно кратності атрибутів і операцій класів. Інтервал записується поруч з кінцем асоціації і для N-арної асоціації означає потенційне число окремих екземплярів або значень кортежів цієї асоціації, які можуть мати місце, коли інші N-1 екземплярів або значень класів фіксовані.

Частковим випадком відношення асоціації є так звана виключна асоціація (Xor-association). Семантика даної асоціації вказує на той факт, що із декількох потенційно можливих варіантів даної асоціації в кожен момент часу може використовуватися тільки один її екземпляр. На діаграмі класів виключна асоціація зображається пунктирною лінією, яка з'єднує дві і більше асоціації, поруч з якою записується стрічка-обмеження «{хог}».

Спеціальною формою або частковим випадком відношення асоціації є відношення агрегації, яке, в свою чергу, також має спеціальну форму -- відношення композиції.

Відношення агрегації може бути між декількома класами у тому випадку, якщо один із класів представляє собою деяку сутність, що включає в себе як складові частини інші сутності. [18]

Дане відношення має фундаментальне значення для опису структури складених систем, оскільки застосовується для представлення системних взаємозв'язків типу «частина-ціле». Розкриваючи внутрішню структуру системи, відношення агрегації показує, з яких компонентів складається система і як вони зв'язані між собою. З точки зору моделі окремі частини системи можуть виступати як у виді елементів, так і у виді підсистем, які, у свою чергу, також можуть утворювати складові компоненти або підсистеми. Це відношення за своєю суттю описує декомпозицію або поділ складної системи на більш прості складові частини, які також можуть бути поділені, якщо у цьому виникне необхідність.

Розглянутий поділ системи на складові частини представляє собою деяку ієрархію її компонентів, проте дана ієрархія принципово відрізняється від ієрархії, яка породжується відношенням узагальнення. Відмінність полягає у тому, що частини системи ніяк не зобов'язані успадковувати її властивості і поведінку, оскільки є самостійними сутностями. Більше того, частини цілого мають свої власні атрибути і операції, які суттєво відрізняються від атрибутів і операцій цілого.

Графічно відношення агрегації зображається суцільною лінією, один із кінців якої представляє собою незамальований ромб. Цей ромб вказує на той з класів, який представляє собою «ціле». Інші класи є його «частинами».

Відношення композиції є частковим випадком відношення агрегації. Це відношення використовується для виділення спеціальної форми відношення «частина-ціле», при якому складові частини в деякому змісті знаходяться в середині цілого. Специфіка взаємозв'язків між ними полягає у тому, що частини не можуть виступати у відриві від цілого, тобто зі знищенням цілого знищуються і всі його складові частини.

Графічно відношення композиції зображається суцільною лінією, один із кінців якої представляє собою зафарбований ромб. Цей ромб вказує на той з класів, який представляє собою клас-композицію або «ціле». Інші класи є його «частинами».

Для відношення композиції і агрегації можуть використовуватися додаткові позначення, які застосовуються для відношення асоціації. А саме, вказівка кратності класу асоціації і імені даної асоціації, які не є обов'язковими.

Відношення узагальнення є звичайним таксономічним відношенням між більш загальним елементом (батьком або предком) і більш частковим або спеціальним елементом (дочірнім або нащадком). Дане відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання і іншими елементами мови.

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

Як правило, на діаграмі може вказуватися декілька ліній для одного відношення узагальнення, що зображає його таксономічний характер. У цьому випадку більш загальний клас поділяється на підкласи одним відношенням узагальнення.

З метою спрощення позначень на діаграмі класів сукупність ліній, які позначають одне й те ж відношення узагальнення, може об'єднуватися в одну лінію. У цьому випадку дані окремі лінії зображаються такими, що сходяться до єдиної стрілки.

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

Розроблена система використовує зв'язки діаграми класів для визначення залежності між елементами програмного забезпечення, що аналізується. Після отримання зав'язків діаграми класів, використовується модифікований спосіб розпізнавання подібності дерев для розпізнавання твірних шаблонів проектування. Доцільно навести опис шаблонів проектування, що належать лише до цього типу.

Породжуючі шаблони -- це шаблони проектування, що абстрагують процес побудови об'єктів. Вони допоможуть зробити систему незалежною від способу створення, композиції та представлення її об'єктів.

Шаблон, який породжує класи, використовує успадкування, щоб варіювати створюваний клас, а шаблон, що створює об'єкти, делегує конструювання іншому об'єктові. Ці шаблони важливі, коли система більше залежить від композиції об'єктів, ніж від успадкування класів. Таким чином, замість безпосереднього опису фіксованого набору поведінок, визначається невеликий набір фундаментальних поведінок, за допомогою композиції яких можна отримувати складніші. Таким чином, для створення об'єктів з конкретною поведінкою використовуються інші механізми, у порівняння з простим інстанціюванням екземпляру класу.

Твірні шаблони приховують інформацію про конкретні класи, які застосовуються у системі та деталі того, як ці класи створюються і стикуються між собою. Єдина інформація про об'єкти, що відома системі -- їх інтерфейси. Нижче наведено породжуючі шаблони проектування.

Абстрактна фабрика (англ. Abstract Factory) -- шаблон проектування, що забезпечує інкапсуляцію окремих фабрик під єдиною схемою, приховуючи їх деталізацію. Належить до класу твірних шаблонів.

В типових випадках застосування, розробник, що використовує готову абстрактну фабрику, створює її конкретну реалізацію, а потім використовує загальний універсальний інтерфейс фабрики, для створення екземплярів об'єктів, які є частиною схеми. Клієнтський вихідний код не знає, які саме об'єкти він отримує від цих фабрик, оскільки він використовує універсальний інтерфейс для їх створення. Шаблон розмежовує деталі реалізації множини об'єктів від їх загального використання в коді, оскільки створення об'єкта здійснюється за допомогою методів, що забезпечуються інтерфейсом фабрики.[14]

Типовими прикладами застосування шаблону проектування абстрактна фабрика є такі вимоги до системи:

* система не повинна залежати від того, як утворюються, компонуються та представляються вхідні до неї об'єкти;

* об'єкти, що входять до однієї групи за тематикою їх використання, повинні використовуватися разом і необхідно забезпечити виконання цього обмеження;

* налаштування системи повинно бути забезпечено однією з груп об'єктів, що входять до її складу;

* необхідно представити бібліотеку об'єктів, розкриваючи тільки їхні інтерфейси, але не реалізацію.

Представлення шаблону проектування у вигляді діаграми класів наведено на рис. 1.1.

Рисунок 1.1. UML діаграма класів для абстрактної фабрики

Фабричний метод -- твірний шаблон, який використовує фабричні методи для вирішення проблеми створення об'єктів, не маючи необхідності вказувати точний клас об'єкта, який буде створено. Це відбувається шляхом створення об'єктів за допомогою фабричного методу, який вказано в інтерфейсі і реалізованого дочірніми класами, або реалізованого в базовому класі, і можливо перевизначене дочірніми класами. Цей метод є альтернативою до безпосереднього виклику конструктора. [13] Призначення цього шаблону є визначення інтерфейсу для створення об'єкта. Водночас фабричний клас залишає підкласам рішення про те, який саме клас інстанціювати. Фабричний метод дозволяє класу делегувати інстанціювання підкласам. Слід використовувати шаблон коли: * класу не відомо заздалегідь, об'єкти яких саме класів йому потрібно створювати; * клас спроектовано так, щоб об'єкти, котрі він створює, 20 специфікувалися підкласами; * клас делегує свої обов'язки одному з кількох допоміжних підкласів, та потрібно локалізувати знання про те, який саме підклас приймає ці обов'язки на себе. [23] Для виявлення цього шаблону використовується UML діаграма класів, що зображена на рис. 1.2.



Рисунок 1.2. UML діаграма класів шаблону фабричний метод

рефакторинг програмний код шаблон

На рис. 1.2 зображено декілька елементів:

• Product-- продукт, який визначає інтерфейс об'єктів, що створюються фабричним методом.

• Concrete Product-- конкретний продукт, який реалізує інтерфейс Product.

• Creator -- творець оголошує фабричний метод, що повертає об'єкт класу, який реалізовує інтерфейс Product.

• Concrete Creator-- конкретний творець, який перевизначає фабричний метод, що повертає об'єкт ConcreteProduct.

Будівельник (англ. Builder) -- шаблон проектування, відноситься до класу твірних шаблонів. На відміну від шаблону абстрактної фабрики і фабричного методу, ціль яких є застосування поліморфізму, задачею шаблону будівельника є забезпечення реалізації анти шаблону багатоступеневого конструювання. Анти шаблон "телескопічний конструктор" коли різна комбінація параметрів конструктора призводить до появи експоненційної множини конструкторів. Замість того, щоб використовувати набір конструкторів, використовують шаблон будівельник, згідно якого використовують інший об'єкт (будівельник), що отримує на вхід параметри по одному, крок за кроком, і повертає за один прохід створений об'єкт. [12]

Шаблон проектування призначається для відокремлення конструювання складного об'єкта від його подання. Таким чином, у результаті одного й того ж процесу конструювання, можуть бути отримані різні подання.

Слід використовувати шаблон будівельник коли:

• алгоритм створення складного об'єкта не повинен залежати від того, з яких частин складається об'єкт та як вони стикуються поміж собою;

• процес конструювання повинен забезпечити різні подання об'єкта, що конструюється. [8]

Приклад UML діаграми класів для цього шаблону проектування наведена нижче на рис. 1.3.

Рисунок 1.3. UML діаграма класів шаблону будівельник

Елементи діаграми класів на рис. 1.3 можуть бути пояснені таким чином:

* Builder -- будівельник, який визначає абстрактний інтерфейс для створення частин об'єкта Product.

* ConcreteBuilder -- конкретний будівельник, який конструює та збирає докупи частини продукту шляхом реалізації інтерфейсу Builder;

* Director -- керівник, який конструює об'єкт, користуючись інтерфейсом Builder;

* Product -- продукт, який подає складний конструйований об'єкт.

1.3 Аналіз існуючих засобів виявлення шаблонів проектування у вихідному коді

Для полегшення внесення змін у структуру шаблонів проектування на сьогоднішній день створено декілька інструментів для виявлення шаблонів проектування у вихідному коді.

Існує декілька інструментів для виявлення шаблонів проектування у вихідному коді мовою Java:

• PINOT (Pattern INferencerec Overy Tool)

• MUSCAT

• JPINOT

• FUJABA

• WOP PINOT

Ця утиліта використовує Jikes (Java-компілятор написаний на С++ з відкритим вихідним кодом) з вбудованим аналізатором шаблонів та може розпізнати усі структурні та поведінкові шаблони проектування описані у книзі «Шаблони проектування: Елементи повторно використовуваного об'єктно-орієнтованого програмного забезпечення» спільного авторства Еріха Г амма, Річарда Хелма,Ральфа Джонсона, Джона Вліссідеса[21].

Переваги:

• результативність підтверджена тестами на проектах з відкритим вихідним кодом мовою Java:Java AWT 1.3, JHotDraw6.0b1,JavaSwing 1.4, java.io 1.4.2, java.net 1.4.2, javac 1.4.2, ApacheAnt 1.6.2, ArgoUML 0.18.1;

• наявність розширень для збільшення можливостей та покращення якості роботи.

Недоліки:

• відсутність підтримки, останні зміни були внесені 27 листопада 2007 року;

• жорстка залежність від компілятора через прив'язку до абстрактного синтаксичного дерева (АСД), таблиці символів (ТС), що генеруються. [17]

MUSCAT

Даний інструмент є розширеною версією PINOT з виділенням мови візуального уточнення MUSCAT (Minimal UML SpecifiCATionlanguage), яка дозволяє користувачам визначати структурні та поведінкові аспекти шаблонів проектування.

Переваги:

• візуалізація шаблонів проектування;

• можливість модифікації аспектів шаблонів проектування.

Недоліки:

• необхідність вивчення створеної мови для налаштування;

• відсутність можливості додавання нових шаблонів проектування;

• залежність від програмного забезпечення, підтримка якого вже закінчилась. [1]

JPINOT

Цей проект являється копією PINOT, виконаний як надбудова до javacта слугує фундаментом для подальшого покращення виявлення шаблонів проектування за допомогою PINOT. [5]

FUJABA

Програмний продукт дозволяє підтримку моделе-орієнтованої методики створення програмного забезпечення та підтримки створеного проекту. Спочатку Fujabaмав на меті полегшення розробки та підтримки створених проектів, оскільки його назва є акронімом “From UML toJavaandbackagain”.

Переваги:

• використання потужного апарату Unified Modeling Language (UML) діаграм класів та зв'язків між класами;

• широка міжнародна підтримка даного проекту.

Недоліки:

• зміщення акценту з виявлення шаблонів проектування на підтримку моделе-орієнтованої методики розробки;

• нижчі показники виявлення шаблонів проектування порівняно із аналогічною утилітою PINOT;

• зміна вектору підтримки, перехід до реалізації будови діаграм історій. [4]

WOP

Web Of Patterns (WOP) - інструментарій, який має на меті поширення знань про архітектуру програмного забезпечення. WOP складається з двох частин:

• мово-незалежного формату для опису шаблонів проектування за стандартами World Wide Web Consortium (W3C), а саме за допомогою моделі для опису даних (англ. Resource Description Framework, RDF) та мови опису онтології для семантичного павутиння (англ. Web Ontology Language, OWL);

• набір Eclipse-додатків, які використовують вищезгадані мовонезалежні формати.

Переваги:

• мово-незалежна формалізація шаблонів проектування;

• можливість оцінювати та брати участь у створенні опису до шаблонів проектування усіма учасниками проекту та онлайн підтримка.

Недоліки:

• нижчі показники виявлення шаблонів проектування порівняно з аналогічною утилітою PINOT ;

• припинення підтримки, останнє оновлення проекту датується 18 березням 2007 року. [3]

2. Структура системи для виявлення шаблонів проектування та її тестування

Система для виявлення шаблонів проектування складається з трьох окремих модулів, що не залежать один від одного. Призначення першого модуля - побудова абстрактного синтаксичного дерева на основі констекстно-вільної граматики. Вхідний параметр для цього модуля - розширена або доповнена нотація Бекуса-Наура, яка описує граматику об'єктно-орієнтованої мови. Вихідне значення - АСД, яке описане структурою даних мовою Clojure.

Другий модуль будує графи, які зображують зв'язки між класами використовуючи типи зв'язків із діаграм класів. Вхідний параметр - результат роботи першого модулю.

Третій модуль відповідальний за виявлення шаблону проектування. Вхідними параметрами для цього модулю - два набори графів, отриманих в результаті роботи другого модулю. Перший набір графів описує шаблон проектування, а другий набір представляє аналізовану систему. Результатом роботи є повідомлення про повну чи часткову присутність або відсутність шаблону проектування в аналізованій системі.

Перевагою даної системи є те, що вона не прив'язана до конкретної реалізації шаблону проектування та може аналізувати присутність будь-якого шаблону в аналізованому вихідному коді.

2.1 Контекстно-вільна граматика мови Java

Для реалізації системи виявлення шаблонів проектування було обрано аналіз мови програмування Java. Створена граматика описує лише ті частини мови, що необхідні для побудови графів зв'язків: оголошення класу, інтерфейсу, пакету, імпорту пакету, методу, атрибуту, локальної змінної, формального параметру та значення, що повертається з методу.

У графі, що відображає зв'язки, що використовуються у діаграмах класів, вершинами являються оголошені класи, інтерфейси. Через це була необхідність додавання в граматику правила, що описують створення класів або інтерфейсів. В мові програмування Java реалізація зв'язків узагальнення і реалізації є простою.

Для спадкування існує ключове слово extends, завдяки якому по оголошенню класу зрозуміти, який клас успадковується. Для опису зв'язку реалізації введено ключове слово implements. В оголошенні класу, усі ідентифікатори, що стоять після implements є ідентифікаторами інтерфейсів. Таких ідентифікаторів може бути декілька. Оголошений клас повинен реалізувати усі методи, що оголошені у відповідних інтерфейсах.

У мові програмування Java є поняття повністю кваліфікованого ідентифікатора, який є унікальним для усього проекту. Для побудови коректної відповідності ідентифікаторів системи, що аналізується, необхідно знати в якому пакеті оголошений клас і місце його використання. Для цього було додано правило для оголошення пакетів та їх імпорту до граматики.

За допомогою оголошення методів класу можна зробити висновок про те, які типи були використані у ньому. Завдяки доданому правилу оголошення методу можна будувати ребра, які описують взаємозв'язки між класами, графу. Всередині оголошення методу існують усі інші правила, завдяки яким можна розділити які взаємозв'язки існують між об'єктами класів.

Якщо тип атрибуту класу не є примітивним, то це означає, що між типом, який має оголошений атрибут, та класом, в якому атрибут оголошено, існує зв'язок. Якщо даний атрибут не являється контейнером, то це означає, що між класами існує залежність. В інакшому випадку, це означає, що зв'язок є асоціацією, а саме композицією [15].

Якщо локальна змінна або формальний параметр використовує певний клас в якості типу контейнера, це показує зв'язок асоціації, а саме агрегацію. Якщо ж тип змінної є не примітивний тип, це означає, що існує залежність між класом, який використовує цю змінну та типом, що використовується.

У разі, якщо значення, що повертає метод, не є контейнером, то це вказує на зв'язок залежності. В інакшому випадку, значення, що повертається створює зв'язок асоціації між двома класами, якщо тип контейнеру не є примітивним.

2.2 Синтаксичний аналізатор та побудова дерева розбору

Граматика є вхідним параметром для створення функції, яка поєднує в собі лексичний та синтаксичний аналізатори, з подальшим її використанням для побудови АСД. Комбінація аналізаторів будується за допомогою сторонньої бібліотеки Instaparse.

Дана бібліотека було обрана за ряд переваг:

• жодна граматика не залишається осторонь: функція може бути побудована для будь-якої контекстно-вільної граматики, включаючи ліворекурсивні, праворекурсивні та неоднозначні граматики;

• поєднання лексичного та синтаксичного аналізаторів завдяки можливості використання регулярних виразів для опису правил граматики;

• розширено клас граматики, що підтримуються, крім контекстно-вільних граматик можна працювати з РВ-граматиками, що розбирають вирази за допомогою попереднього прямого перегляду та оберненого попереднього перегляду;

• деталізоване повідомлення помилок розбору;

• може продукувати ліниву послідовність усіх можливих АСД;

• аналізує увесь вихідний текст програми, де підрядки, що не піддаються розбору вставляються у дерево розбору.

Час побудови та аналіз абстрактного синтаксичного дерева спрощується за рахунок неповного опису мови у створеній контекстно-вільній граматиці.

2.3 Побудова графів зв'язків між класами для вихідного коду

Задачею другого модуля є побудова графа зв'язків, що використовуються у діаграмах класів, на основі АСД.

Для побудови кожного із видів зв'язків необхідно проаналізувати відповідну вершини дерева для того. Усі функції, що будують зв'язки об'єднує рекурсивне використання вбудованої бібліотеки matchв мову Clojure, а саме однойменного макросу для пошуку відповідних вершин дерева, що необхідні для аналізу. Даний макрос реалізує алгоритм компіляції зіставлення з шаблоном, який використовує поняття "необхідність", при виявленні відповідності зі зразком. Бібліотека використовує алгоритм, який описаний у статті Лука Меренгата (Luc Maranget). Стаття має назву “Трансляція співставлення шаблону в гарне дерево рішень” (Compiling Pattern Matching to good Decision Trees). Вхідні параметри для усіх функцій однакові - абстрактне синтаксичне дерево одного файлу та словник з ключем-ідентифікатором та значенням - інформація про ідентифікатор. В кожній реалізації будови графа зв'язку виконується аналіз оголошення класу та інтерфейсів, однак відрізняються аналізовані дочірні вершини.

Для побудови зв'язку узагальнення необхідно проаналізувати лише вершини, що відповідають правилу граматики extends в оголошеннях класів та інтерфейсів. Розглянемо конкретний приклад. З лістингу 2.1 програми мовою Java можна отримати граф зображений на рис. 2.1.

privateinterfaceMainInterface{ }

privateinterfaceAnotherInterface { }

privateinterfaceSubinterfaceextendsMainInterface { }

publicinterface Gen2 extendsMainInterface, AnotherInterface { }

Лістинг 2.1. Приклад реалізації зв'язку узагальнення між інтерфейсами MainInterface та SubInterface, Gen2 і MainInterface, AnotherInterface



Рисунок 2.1. Граф, що показує зв'язок узагальнення між інтерфейсами з лістингу 2.1

Для побудови зв'язку реалізації необхідно проаналізувати лише вершини, що відповідають правилу граматики implements в оголошеннях класів та інтерфейсів.

Побічним результатом роботи системи при аналізі лістингу 2.2 буде граф зображений на рис. 2.2.

privateinterfaceTest { }

privateinterfaceAnotherTest { }

privateclassOneImplementationimplementsTest { }

publicclassTwoImplementationimplementsTest, AnotherTest { }

Лістинг 2.2. Приклад вихідного коду зі створенням звязків реалізації між інтерфейсом Test та класом OneImplementation, між інтерфейсами Test, AnotherTest та класом TwoImplementation

Рисунок 2.2. Граф, що показує зв'язок реалізації між інтерфейсами та класами з лістингу 2.2

Для побудови зв'язку залежності необхідно аналізувати типи, які мають атрибути класу, локальні змінні всередині методів, об'єкти, що повертаються в методах. Якщо даний тип не належить до пакету java.lang, тобто не є вбудованим для мови програмування, то додається ребро між аналізованим класом та вершиною, яка представляє використаний тип.

З лістингу 2.3. програми мовою Javaбуде отримано граф зображений на рис. 2.3.

privateclassTest { }

privateinterfaceTestConstructorI { }

publicclass Dep1 {

public Dep1 (TestConstructorItest) { }

publicvoidfoo (intpar, Testparameter) { }

}

Лістинг 2.3. Приклад зв'язку залежності між класом Dep1 та інтерфейсом TestConstructorl і класом Test

Рисунок 2.3. Граф, що показує зв'язок залежності між одним класом з інтерфейсом та іншим класом з лістингу 2.3

2.4 Інтерфейс користувача

Система має текстовий користувацький інтерфейс. Для запуску необхідно передати два параметри: шлях до шаблону проектування та шлях до системи, в якій буде визначатись використання шаблону проектування.

Програма виконає ланцюжок перетворень шаблону проектування до послідовності графів, які відображають зв'язки між класами, та аналогічну послідовність дій для системи[6]. Створені графи являються вхідними параметрами для способу виявлення використання шаблонів проектування. Результатом роботи є повідомлення про співпадіння, яке трьох частин: точне (exact), можливе (possible) та відсутнє (absent).

Кожна з частин повідомлення має спільну структуру: набір рядків, де першою частиною є ідентифікатор класу або інтерфейсу з шаблону проектування, символ відповідності (->), ідентифікатор класу або інтерфейсу з аналізованої системи.

Точне співпадіння можливе у випадку, коли було не знайдено жодних протиріч у результуючій відповідності між графом шаблону проектування та системи. Можливе співпадіння показує, наявність протирічь у результаті роботи. Відсутність співпадіння стверджує неможливість наявності шаблону проектування у аналізованому коді.

Відмінність між можливим співпадінням та його відсутністю полягає в тому, що в можливому співпадінні є протиріччя між зв'язками, проте структура ярусів графів - однакова. Відсутність співпадіння можлива у випадку, коли взагалі відсутні певні види зв'язків у проаналізованій системі порівняно з шуканим шаблоном проектування.

Приклад результати роботи системи наведено на рис. 2.4.

Рисунок 2.4. Результат роботи при точному співпадінні шаблону проектування з аналізованою системою

Для ілюстрації роботи було використано шаблон “Абстрактної фабрики” (Abstract Factory) та системи, що є моделлю використання в ігровій розробці, яка використовує вищезгаданий шаблон проектування.

Виявлення шаблону використання шаблону «Будівник» (Builder) для тієї ж системи виведе повідомлення про можливе співпадіння (рис. 2.5), оскільки в шуканому шаблоні присутні зв'язки залежності та узагальнення з аналогічної структурою, як і в абстрактній фабриці.

Відповідність в можливому співпадінні є не повною. Оскільки спосіб розрахований на зупинку процесу пошуку у разі виявлення першої невідповідності між деревоподібними представленнями вихідного коду та шаблону проектування, така помилка зіставлення може виникнути на будь-якій ітерації. Тому результат роботи для аналогічних систем може бути різним.

Рисунок 2.5. Результат роботи при можливому співпадінні шаблону проектування з аналізованою системою

Для наведеної системи можливість співпадіння можлива у разі відсутності одного з видів зв'язків: успадкування або залежності. Шаблон проектування одинак не використовує узагальнення, тому в результаті усі частини повідомлення будуть пустими, окрім розділу про відсутність збігу. Результат наведено на рис. 2.6.



Рисунок 2.6. Результат роботи при відсутності співпадіння шаблону проектування з аналізованою системою

2.5 Підхід до тестування системи

Техніка тестування включає як процес пошуку помилок або інших дефектів, так і випробування програмних складових з метою оцінки. При тестуванні оцінювались критерії:

• відповідність вимогам до системи, що розробляється;

• коректність роботи модулів;

• виконання функцій за прийнятний час;

Компоненти системи було протестовано за допомогою методу структурного тестування, або тестування «білого ящика», на основі потоку даних. Дана методика забезпечує аналіз вихідного коду програми. Існує три різновиди структурного тестування [10]:

• на основі потоку керування програми;

• на основі потоку даних;

• мутаційне тестування.

При використанні першого типу тестується логіка програми, що представлена у вигляді графа керування: вершинами є оператори, а гілками - переходи між ними.

При тестування на основі потоку даних увага приділяється взаємозв'язкам між змінними. Виділяються вершини, у яких змінна ініціалізується та в яких використовується, і вивчаються переходи й взаємозв'язки між такими вершинами.

Мутаційне тестування полягає у внесенні помилок у вихідний код програми та порівняння роботи вихідної програми та програми мутанта. Оскільки здійснити вичерпне структурне тестування вкрай важко, необхідно вибрати такі критерії його повноти, які допускали б їхню просту перевірку й полегшували б цілеспрямований підбір тестів [110].

Для виконання тестів використовувались вбудовані можливості мови програмування, а саме модуль clojure.test та можливості системи для управління проектом Leiningen. Для розширення наборів тестування необхідно лише у відповідній теці test оголосити тест за допомогою ключове слово deftest та додати перевірки. Запуск та перевірка коректності створеного набору тестів виконується за допомогою виконання команди leintest в директорії проекту.

2.6 Тестування системи

Кожен з модулів системи був покритий певними тестовими випадками.

Для перевірки коректності побудови абстрактного синтаксичного дерева було створено декілька файлів з вихідним кодом мовою Java. Кожен з файлів перевіряє коректність роботи певного правила з граматики. Такий підхід необхідний для того, щоб полегшити налагодження роботи синтаксичного аналізатора.

Даний модуль має найбільшу схильність до спричинення зупинки роботи усієї системи при різних вхідних даних. Також тестові набори допомагають зрозуміти які типи вихідного коду можуть бути сконвертовані до абстрактного синтаксичного дерева.

Також було покрито декількома тестовими випадками модуль, який відповідальний за побудову зв'язків діаграми класів між класами та інтерфейсами з абстрактного синтаксичного дерева. Тестовими випадками покриті такі типи зв'язків:

* узагальнення (generalization);

* реалізація (realization);

* залежність (dependency).

Для типу зв'язку узагальнення створено декілька тест-функцій. Основна функція для тестування збирання зв'язку є test-gener-match-decl. Вона перевіряє коректність роботи виявлення в абстрактному синтаксичному дереві правил classDeclaration та interfaceDeclaration з викликом відповідних функцій для побудови вершин майбутнього графу. Створено два тестових випадки:

* позитивні дані. Тестова функція викликається двічі для двох правил відповідно. На виході повинні отримати список словників, які представляють вершини майбутнього графа з ключем у вигляді структури даних з ім'ям вершини (назва класу або інтерфейсу) та її типом (клас або інтерфейс), а значення - список вершин, які з'єднані з цією вершиною.

* Негативні дані: на вхід подається абстрактне синтаксичне дерево з відсутніми правилами classDecalartion та interfaceDeclaration. На виході повинні отримати аналогічний список словників, де значеннями являються пусті списки.

Існує декілька спільних функцій, для двох типів зв'язку: узагальнення і реалізації, оскільки вершини для них будуються на основі однакових правил classDeclarationта interfaceDeclaration. Основною задачею є перевірка коректності збирання назв користувацьких типів після ключових слів extendsта implements в оголошенні класів та інтерфейсів.

...