Рамка за разработка за JSR 290 TCK

Заглавие на работата: Разработка на рамка за JSR 290 TCK

Предметна област: Информатика, кибернетика и програмиране

Описание: Комплектът за съвместимост на технологиите (TCK) е тестов пакет, който ви позволява да тествате изпълнението на всяка заявка за спецификация на Java (JSR) за съответствие със спецификацията. Това е един от трите компонента на ратифициран JSR в процеса на общността на Java, които са: JSR спецификация JSR Референтна реализация

Дата на добавяне: 2015-02-02

Размер на файла: 450 KB

Работата е изтеглена от: 2 души.

Държавен университет в Санкт Петербург

Катедра по системно програмиране

Рамка за разработка за JSR 290 TCK

Курсова работа на студент от група 445

Евстифеев Сергей Викторович

Описание на предметната област

Набор от тестове за технологична съвместимост (TCK), който ви позволява да тествате изпълнението на всяка заявка за спецификация на Java (JSR) за съответствие със спецификацията. Това е един от трите компонента на ратифициран JSR в процеса на общността на Java, които са:

JSR спецификация
JSR референтна реализация
Комплект за технологична съвместимост

Основната цел на създаването на TCK е да се изпълни добре известният лозунг „Пиши веднъж, изпълнявай навсякъде“, което предполага не само, че байт кодът ще бъде изпълнен на всяка 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? >) ви позволява да създавате приложения, които комбинират технологии за уеб интерфейс (като XHTML Basic и SVG Tiny) с Java код, използвайки спецификацията на W3C CDF (Compound Document Format [http://www.w3.org/2004/CDF/]). API, описан в този JSR, предоставя 3 начина за интегриране между Java и XML UI:

Кръстосано препращане между маркиране и Java ME код
Включване на някои Java ME компоненти в маркирането
Използване на маркирани данни в Java ME приложения

Основната цел е да се използва потребителският интерфейс, който би бил твърде труден за изпълнение със скриптове, на мобилни устройства.

TCK съдържа голям брой тестове, използващи различни инструменти за тестване на съвместимост на Java. В момента има голям брой библиотеки и помощни програми,улеснявайки разработването на TCK, обаче, създаването на единен универсален набор от инструменти, който напълно ще задоволи нуждите на разработчиците на тестове за всеки TCK, е невъзможно, както поради разликите между спецификите на различните JSR спецификации, така и разликите в изискванията на разработчиците към инструментариума при разработването на различни TCK. Например, конкретна спецификация може да наложи изисквания (или препоръки), които се различават от стандартните изисквания за изтриване на екземпляри на обекти от конкретни класове. Внедряването може да използва сложни платформени компоненти, освобождаването на памет от които може да изисква допълнителни действия от разработчика. Второ, за удобство при писане на тестове може да са необходими стандартизирани методи за създаване на масиви от обекти от същия тип и конфигурирането им за правилна работа. Такава стандартизация е близка по своята идея до модулното програмиране:

Разработчиците могат да използват стандартизирани модели преди и след, за да осигурят правилната работа на приложението
Наличен е един механизъм за създаване и изтриване на обекти, който в същото време улеснява работата на разработчика при създаване на нови и поддържане на съществуващи тестове, а също така улеснява четливостта на кода, което също е важно, тъй като лицензополучателите, тестващи техните реализации, трябва да могат лесно да разбират TCK кода
Наличен е механизъм за контролиране на жизнения цикъл на сложни обекти, информацията за който се предоставя от спецификацията чрез използването на модела Listener

Изпълнението на всички тези изисквания води до създаването на пълноценна рамка. По време на процеса на разработка бяха използвани описаните по-долу подходи и модели на програмиране.

Обектите на платформата (FluidImage, вижте JSR спецификацията) се капсулиратсъдържанието на уеб UI обект, представен като DOM дърво и може да съдържа значително количество информация и следователно става необходимо да се контролира процесът на зареждане и изтриване на такива обекти, което е имплементирано в спецификацията JSR 290, като се използват асоциирани обекти Listener, към които се правят обратни извиквания, докато обектът се зарежда. Спецификацията обаче не позволява получаването на асоциирания слушател чрез специфичен метод за получаване и следователно има страхотна възможност за напълно прозрачна интеграция с рамката, извършена както следва:

Когато създава обект, разработчикът може да предаде конкретен Listener като един от параметрите (обект, който имплементира интерфейса FluidImagListener, вижте спецификацията). Рамката ви позволява да „опаковате“ този слушател в друг, който е екземпляр на специална реализация на горния интерфейс и е предназначен да осигури контрол върху жизнения цикъл на обектите. В този случай създаденият обект се регистрира от рамката за по-нататъшно правилно изтриване по време на изпълнението на тестовия последващ шаблон.
„Обвиването“ на слушател в друг е пример за стандартния модел на декоратора. Поради факта, че декораторът в този случай е тясно интегриран с рамката, той ви позволява да приложите методи за контролиране на зареждането на обект, например най-необходимият: изчакайте, докато обектът се зареди напълно (информацията за това се предава чрез извикване на методите на слушателя и изглежда неуместно да се прилагат механизми за синхронизиране на всяко място, където се изисква отделно). Също така става възможно да се създаде метод за получаване на слушател, който е уникален за рамката (вижте споменаването по-горе)
В резултат на това, че обектътсе регистрира от рамката по време на създаване, е доста лесно да се приложи изтриването на всички обекти, създадени по време на изпълнението на теста, просто чрез извършване на правилната операция за изтриване на обекти за всички регистрирани обекти
Ако изтеглянето не е било успешно и методът на слушателя е бил извикан, съобщавайки за грешка, това също е известно, тъй като методът за контрол на изтеглянето връща булев резултат.

Схематично можете да изобразите кода така:

публичен клас FrameworkListener имплементира FluidImageListener

частен слушател на обекти;

публичен FrameworkListener(слушател на FluidImageListener)