Розробка framework для JSR 290 TCK
Назва роботи: Розробка framework для JSR 290 TCK
Предметна область: Інформатика, кібернетика та програмування
Опис: Technology Compatibility Kit (TCK) - тестова сюїта, що дозволяє протестувати реалізацію Java Specification Request (JSR) на відповідність специфікації. Це одна із трьох складових ратифікованого JSR у Java Community Process, якими є: Специфікація JSR JSR Reference Implementation
Дата завантаження: 2015-02-02
Розмір файлу: 450 KB
Роботу завантажили: 2 чол.
Санкт-Петербурзький Державний Університет
Кафедра системного програмування
Розробка framework для JSR 290 TCK
Курсова робота студента 445 групи
Євстіфєєва Сергія Вікторовича
Опис предметної області
Technology Compatibility Kit (TCK) - тестова сюїта, що дозволяє протестувати реалізацію будь-якого Java Specification Request (JSR) на відповідність специфікації. Це одна з трьох складових ратифікованого JSR Java Community Process , якими є:
- Специфікація JSR
- JSR Reference Implementation
- Technology Compatibility Kit
Основною метою створення TCK' є виконання відомого слогана «Write once, run anywhere», що передбачає не тільки те, що байткод буде виконуватися на будь-якій java-машині, але і те, що при написанні коду розробнику не потрібно ґрунтуватися на специфіці роботи якої -або конкретної java-машини, достатньо лише знання специфікації.
Тести, що містяться в TCK, отримують з тверджень специфікації відповідного JSR. Щоб перевірити відповідність імплементації деякого JSR специфікації, імплементація має успішно пройти відповідний TCK. Таким чином,TCK дуже важливий при створенні імплементації JSR. Спершу домагаються того, щоб TCK взагалі можна було запустити, оскільки це вимагає достатнього рівня працездатності від мережевого стека пристрою, що тестується. Потім TCK має бути налаштований правильним чином: у зв'язку з тим, що TCK має бути досить гнучким, щоб працювати з різними імплементаціями, існує велика кількість різних опцій.
Можна вважати імплементацію сумісною після того, як вона проходить TCK. Однак, незважаючи на те, що TCK проводить досить значне тестування, існують області, які він не покриває, наприклад, продуктивність та опціональні можливості. Для цих випадків призначені JDTS , а також тестування пристрою в робочих ситуаціях.
Додаткову інформацію про Java Compatibility Test Tools можна знайти тут: http://java.sun.com/developer/technicalArticles/JCPtools2/ .
JSR 290 ( http://jcp.org/en/jsr/detail? > ) дозволяє створювати додатки, що комбінують технології Web UI (такі як XHTML Basic і SVG Tiny ) з Java-кодом, використовувати специфікацію W3C CDF (Compound Document Format [http://www.w3.org/2004/CDF/]). API , описаний у цьому JSR надає 3 способи інтеграції між Java та XML UI :
- Cross-referencing між розміткою та кодом Java ME
- Включення деяких Java ME компонентів у розмітку
- Використання даних розмітки в Java ME додатках
Основною метою є використання UI, яке надто важко було б здійснити за допомогою скриптів на мобільних пристроях.
TCK містить велику кількість тестів, що використовують різні Java Compatibility Test Tools. На даний момент існує велика кількість бібліотек та утиліт,що полегшують розробку TCK-ев, проте створення єдиного універсального набору інструментальних засобів, який повністю задовольнятиме запити розробників тестів будь-якого TCK, неможливо, зважаючи як на відмінності між специфікою різних специфікацій JSR, так і на відмінності у вимогах розробників до інструментарію при розробці різних TCK. Так, конкретна специфікація може пред'являти відмінні від стандартних вимоги (або рекомендації) до екземплярів об'єктів конкретних класів, що видаляються. Імплементація може використовувати складні платформні компоненти, звільнення пам'яті з-під яких може вимагати від розробника додаткових дій. По-друге, для зручності написання тестів можуть знадобитися стандартизовані способи створення масивів однотипних об'єктів та їх налаштування для коректної роботи. Така стандартизація близька за своєю ідеєю до модульного програмування:
- Розробники можуть використовувати стандартизовані before- та after-патерни, що забезпечують коректну роботу програми
- Доступний єдиний механізм створення та видалення об'єктів, що одночасно полегшує роботу розробника по створенню нових та підтримці вже існуючих тестів, а також полегшує читабельність коду, що теж важливо, тому що licensees, що тестують свої імплементації повинні мати можливість легко зрозуміти код TCK
- Доступний механізм контролю за життєвим циклом складних об'єктів, інформація про який надається специфікацією за допомогою використання патерну Listener
Виконання всіх цих вимог виливається у створення повноцінного framework -а. У процесі розробки було використано підходи та патерни програмування, описані нижче.
Платформні об'єкти (FluidImage, див. специфікацію JSR) інкапсулюютьвміст Web UI об'єкта, представленого у вигляді DOM Tree і можуть містити значний обсяг інформації, у зв'язку з чим виникає необхідність контролювати процес завантаження та видалення таких об'єктів, що реалізовано в специфікації JSR 290 з використанням асоційованих Listener-об'єктів, до яких здійснюються callback-і під час завантаження об'єкта. Однак специфікація не дозволяє отримати асоційований Listener за допомогою специфічного getter-методу, у зв'язку з чим виникає чудова можливість абсолютно прозорої інтеграції з framework-ом, що здійснюється наступним чином:
- При створенні об'єкта, розробник може передати як один з параметрів, специфічний Listener (об'єкт, що реалізує інтерфейс FluidImagListener, див. специфікацію). Framework дозволяє «обернути» цей Listener в інший, який є екземпляром спеціальної реалізації зазначеного вище інтерфейсу і призначений для надання контролю за життєвим циклом об'єктів. При цьому об'єкт, що створюється, реєструється framework -ом для подальшого коректного видалення в процесі виконання тестового after -патерна.
- «Обгортка» Listener-а іншим є прикладом стандартного патерна Decorator. Завдяки тому, що Decorator в даному випадку тісно інтегрований з framework -ом, він дозволяє реалізувати методи контролю за завантаженням об'єкта, наприклад, найнеобхідніший: дочекатися, поки об'єкт не буде повністю завантажений (інформація про це передається за допомогою виклику методів Listener -а, а реалізовувати механізми синхронізації у кожному місці, де це потрібно, окремо, видається недоцільним). Також виникає можливість створення Listener getter -методу, властивого лише framework -у (див. згадування вище)
- Внаслідок того, що об'єктреєструється framework -ом під час створення, досить просто реалізується видалення всіх створених під час виконання тесту об'єктів, просто виконуючи операцію коректного видалення об'єкта всім зареєстрованих об'єктів
- Якщо завантаження не увінчалася успіхом і був викликаний метод Listener -а, що повідомляє про помилку, про це теж можна дізнатися, оскільки метод контролю за завантаженням повертає boolean результат.
Схематично можна зобразити код так:
public class FrameworkListener implements FluidImageListener
private Object listener;
Public FrameworkListener(FluidImageListener listener)