77210

Разработка 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

1 чел.

Санкт-Петербургский Государственный Университет

Математико-механический факультет

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

Разработка framework для JSR 290 TCK

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

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

Научный руководитель

Василий Исаенко

Санкт-Петербург

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

Technology Compatibility Kit (TCK) – тестовая сюита, позволяющая протестировать реализацию какого-либо Java Specification Request (JSR) на соответствие спецификации. Это одна из трех составляющих ратифицированного JSR в Java Community Process, которыми являются:

  1.  Спецификация JSR
  2.  JSR Reference Implementation
  3.  Technology Compatibility Kit

Основной целью создания TCK'ев является выполнение известного слогана «Write once, run anywhere», что подразумевает не только то, что байткод будет выполняться на любой java-машине, но и то, что при написании кода разработчику не нужно основываться на специфике работы какой-либо конкретной java-машины, достаточно лишь знания спецификации.

Обычно TCK использует графическе приложение, обменивающееся данными по TCP/IP с тестируемым устройством или java-машиной. Тесты передаются на устройство по HTTP, результаты отсылаются на хост-приложение аналогичным образом. Разделение на тестируемое устройство и хост-приложение позволяет протестировать виртуальные машины на таких устройствах, как CLDC-мобильные телефоны, не обладающих достаточной функциональностью для запуска полноценного хост-приложения.

Содержащиеся в 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?id=290) позволяет создавать приложения, комбинирующие технологии Web UI (такие как XHTML Basic и SVG Tiny) с Java-кодом, использовать спецификацию W3C CDF (Compound Document Format [http://www.w3.org/2004/CDF/]). API, описанный в данном JSR предоставляет 3 способа интеграции между Java и XML UI:

  1.  Cross-referencing между разметкой и кодом Java ME
  2.  Включение некоторых Java ME компонент в разметку
  3.  Использование данных разметки в Java ME приложениях

Основной целью является использование UI, которое слишком трудно было бы осуществить с помощью скриптов, на мобильных устройствах.

 Содержание работы

 TCK содержит большое количество тестов, использующих различные  Java Compatibility Test Tools. На данный момент существует большое количество библиотек и утилит, облегчающих разработку TCK-ев, однако создание единого универсального набора инструментальных средств, который будет полностью удовлетворять запросы разработчиков тестов любого TCK, невозможно, ввиду как различий между спецификой различных спецификаций JSR, так и различий в требованиях разработчиков к инструментарию при разработке различных TCK. Так, конкретная спецификация может предъявлять отличные от стандартных требования (или рекомендации) к удаляемым экземплярам объектов конкретных классов. Имплементация может использовать сложные платформенные компоненты, освобождение памяти из-под которых может потребовать от разработчика дополнительных действий. Во-вторых, для удобства написания тестов могут потребоваться стандартизированные способы создания массивов однотипных объектов и их настройки для корректной работы. Такая стандартизация близка по своей идее к модульному программированию:

  1.  Разработчики могут использовать стандартизированные before- и after-паттерны, обеспечивающие корректную работу приложения
  2.  Доступен единый механизм создания и удаления объектов, что одновременно облегчает работу разработчика по созданию новых и поддержке уже существующих тестов, а также облегчает читабельность кода, что тоже важно, так как licensees, тестирующие свои имплементации должны иметь возможность легко понять код TCK
  3.  Доступен механизм контроля за жизненным циклом сложных объектов, информация о котором предоставляется спецификацией посредством использования паттерна Listener

Выполнение всех этих требований выливается в создание полноценного framework-а. В процессе разработки были использованы подходы и паттерны программирования, описанные ниже.

Decorator pattern 

Платформенные объекты (FluidImage, см. спецификацию JSR) инкапсулируют содержимое Web UI объекта, представимого в виде DOM Tree и могут содержать значительный объем информации, в связи с чем возникает необходимость контролировать процесс загрузки и удаления таких объектов, что реализовано в спецификации JSR 290 с использованием ассоциированных Listener-объектов, к которым осуществляются callback-и по ходу загрузки объекта. Однако спецификация не позволяет получить ассоциированный Listener с помощью специфического getter-метода, в связи с чем возникает прекрасная возможность абсолютно прозрачной интеграции с framework-ом, осуществляемая следующим образом:

  1.  При создании объекта, разработчик может передать в качестве одного из параметров, специфичный Listener (объект, реализующий интерфейс FluidImagListener, см. спецификацию). Framework позволяет «обернуть» этот Listener в другой, являющийся экземпляром специальной реализации указанного выше интерфейса и предназначенный для предоставления контроля за жизненным циклом объектов. При этом создаваемый объект регистрируется framework-ом для дальнейшего корректного удаления в процессе выполнения тестового after-паттерна.
  2.  «Обертка» Listener-а другим является примером стандартного паттерна Decorator. Благодаря тому, что Decorator в данном случае тесно интегрирован с framework-ом, он позволяет реализовать методы контроля за загрузкой объекта, например самый необходимый: дождаться, пока объект не будет полностью загружен (информация об этом передается с помощью вызова методов Listener-а, а реализовывать механизмы синхронизации в каждом месте, где это потребуется, отдельно, представляется нецелесообразным). Также возникает возможность создания Listener getter-метода, присущего только framework-у (см. упоминание выше)
  3.  В результате того, что объект регистрируется framework-ом при создании, достаточно просто реализуется удаление всех созданных за время выполнения теста объектов, просто выполняя операцию корректного удаления объекта для всех зарегистрированных объектов
  4.  Если загрузка не увенчалась успехом и был вызван метод Listener-а, сообщающий об ошибке, об этом тоже можно узнать, так как метод контроля за загрузкой возвращает boolean результат.

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

public class FrameworkListener implements FluidImageListener {

   

   private Object listener;

   public FrameworkListener(FluidImageListener listener) {

       this.listener = listener;

   }

   

   public void callbackMethod1() {

       processCallback();

       listener.callbackMethod1();

   }

   

   public void callbackMethod2() {

       processCallback();

       listener.callbackMethod2();

   }

   

   public void callbackMethod3() {

       processCallback();

       listener.callbackMethod3();

   }

   

   public void processCallback() {

       // callback processing here

   }

}

Factory Method pattern

 Во время выполнения теста, возникает необходимость создания объектов, соответствующих ресурсам, передаваемым в командной строке. Эти ресурсы могут быть различного происхождения (например URL или файловые пути). Спецификация предусматривает различные методы для создания ресурсов различного происхождения, тем не менее при разработке тестов намного удобнее просто передать список всех ресурсов в едином формате, который будет корректно обработан framework-ом и может быть с легкостью использован во время выполнения. Был создан специальный абстрактный класс со специфичным Factory-методом и подклассы, соответствующие ресурсам различного происхождения. В итоге, полиморфизм позволяет тривиальным образом создать объекты для всех ресурсов, переданных в командной строке, с помощью вызова Factory-метода для каждого ресурса из списка.

Regular Expressions

 FluidImageListener, уже упомянутый выше,  производит индикацию процесса загрузки объекта FluidImage с помощью callback-ов. В тестовых целях, выявляется необходимость обрабатывать цепочки вызовов для проверки на соответствие шаблонам, относящимся к различным случаям (корректная ситуация с различными вариациями и множество различных ситуаций, в которых загрузка не заканчивается успехом).

Создан механизм сопоставления цепочек callback-ов шаблонам, задаваемым пользователем (проверка истинности предикатов). Шаблоны представляют собой простейшие регулярные выражения (реализованы последовательности, задаваемые «*», «?», «[^a]» и некоторые другие). Также реализована проверка шаблона, соответствующего нескольким альтернативным цепочкам (упрощенный аналог «[a|b]»).

Схематично соответствующая UML activity diagram выглядит подобным образом:

Multi-threaded programming

Многие участки framework-а потребовали использования многопоточного программирования. Например работа с ассоциированными Listener-ами, обработка событий и тп. Также можно упомянуть о реализации spurious wakeups-aware timed wait на java. Тогда как untimed wait реализуется тривиальным образом, в случае timed wait требуется некоторая дополнительная работа.

Unit testing

В процессе разработки в некоторых случаях потребовалось убедиться в корректности работы алгоритма ввиду его нетривиальности, вследствие чего вероятность ошибок достаточно велика. На промежуточных этапах были использованы такие утилиты, как стандартная Junit и спецефическая JMUnit (для тестирования Java ME приложений).

Framework

Создание framework потребовало оценки требований разработчика к функциональности и нахождения баланса где-то посередине между чересчур сложной, но наполненной всевозможной функциональностью средой, и средой простой для понимания, но бедной функциональностью. Также требовалось обеспечить возможную гибкость и возможность переиспользования по частям для создаваемой framework.

Результат

В процессе работы в команде создан framework, облегчающий работу разработчика. Получен опыт в практическом использовании паттернов программирования. Получен опыт в работе с большим объемом работающего кода, опыт локализации и устранения ошибок, и осуществления качественных преобразований кода, не меняющих внешний API. Получен опыт многопоточного программирования. Получен опыт использования различных утилит анализа и тестирования кода.

Среди недостатков стоит отметить некоторые ограничения на framework, вызванные с одной стороны тем, что код предназначен для конфигурации CLDC, где отсутствует Reflection API, а с другой — ограничениями на изменение кода  существующих библиотек.

Использованные источники:

  1.  Concurrent Programming in Java: Design Principles and Patterns, Doug Lea.
  2.  Приемы объектно-ориентированного проектирования. Паттерны проектирования. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес.
  3.  Head First Design Patterns. Eric Freeman, Elisabeth Robson, Kathy Sierra, Bert Bates
  4.  http://jmunit.sourceforge.net/
  5.  http://jcp.org/en/jsr/detail?id=290


 

А также другие работы, которые могут Вас заинтересовать

53369. Объемное моделирование и конструирование из бумаги. Игрушки из бумажных полосок 172.5 KB
  Игрушки из бумажных полосок Вид урока Урок беседа Тип урока Урок изучения нового материала Студенты преподаватели Айрапетова Мария Сергеевна Гусева Анна Павловна Ершова Дарья Дмитриевна Максимова Марина Вадимовна Государственный социальный заказ Во исполнение Закона Российской Федерации Об образовании. Добиваться: применения различных форм методов средств технологий при проведении образовательного урока; установления взаимодействия с различными субъектами образовательного процесса. Технологическая карта урока Триединые...
53370. Розвиток слухової уваги, слухової пам’яті та фонематичного сприймання у дітей дошкільного віку 68 KB
  Діти стають у коло непомітно для ведучого вони передають за спиною один одному дзвіночок. Логопед розрає дітям ведмедиків з зображенням цих предметів потім за ширмою озвучує ці предмети а діти повинні відгадати який ведмедик шумить. Дидактична гра Хто кличе Діти по черзі називають ім’я ведучого який стоїть до них спиною. Потім гра ускладнюється і діти кличуть ведучого: Ау то голосно то тихо в залежності від того що скаже логопед: Далеко пішли у ліс Близько пішли у ліс.
53371. Учет косвенных расходов в составе себестоимости продукции. Синтетический учёт движения нематериальных активов 22.77 KB
  Косвенные затраты — затраты, которые, в отличие от прямых затрат, не могут быть непосредственно отнесены на себестоимость одного конкретного вида продукции. Косвенные затраты относятся одновременно ко всем видам продукции и распределяются между ними условно: общепроизводственные и общехозяйственные расходы, часть расходов на продажу и др
53372. Дидактические игры как средство активизации учащихся при изучении таблицы умножения 52.5 KB
  Хочу рассказать о некоторых дидактических математических играх, которые я использую на уроках с целью активизации учащихся при формировании вычислительных навыков. Навык, как известно, приобретается в результате многократных повторений одних и тех же операций. Чтобы избежать однообразия в шлифовке табличных случаев умножения и деления, провожу упражнения в игровой, занимательной форме.
53373. Роль ігор-драматизацій в навчанні дошкільників англійської мови 97 KB
  Всі етапи роботи з казкою здійснюються разом з дітьми. Ініціативу розподілу ролей я надаю малечі (за бажанням), разом з тим, тактовно корегую їх вибір, адже дітям з низьким або середнім рівнем розвитку бажано надати роль, яка є невеличкою за обсягом, не дуже складною та не містить у собі тих мовних структур, які викликають труднощі у дитини (зокрема це стосується звуковимови), щоб не зникло бажання приймати участь у виставі.
53374. Использование деловых и ролевых игр на уроках химии для развития ключевых компетентностей учащихся 121.5 KB
  В процессе игры у детей вырабатывается привычка сосредоточиться мыслить самостоятельно развивает внимание стремление к знаниям. По спектру целевой ориентации игры подразделяются: дидактические: расширение кругозора познавательная деятельность; применение ЗУН в практической деятельности; формирование определенных умений и навыков необходимых в практической деятельности; развитие общеучебных умений и навыков; развитие трудовых навыков. В нее включаются последовательно игры и упражнения формирующие умение выделять основные характерные...
53375. Дидактическая игра – залог успешной деятельности учащихя на уроке 101 KB
  Игра помогает формированию фонематического восприятия слова обогащает ребенка новыми сведениями активирует мыслительную деятельность внимание а главное стимулирует речь. В каком глаголе слово нет слышится сто раз стонет В каком слове семь гласных семья Что принадлежит только тебе а употребляется другими чаще чем тобой имя Какое слово состоит из трёх одинаковых букв три – о Какая часть растения бывает и частью слова корень Какие буквы обозначают два звука если стоят в начале слова или после гласной ...
53376. Ігрові завдання на корекцію емоційної сфери дітей дошкільного віку 98.5 KB
  Психологічний етюд Хто що любить Діти приходять у лісове кафе. Психологічний етюд Клумба і садівник Діти обирають ролі квітів на клумбі. Психологічний етюд Слухаємо себе Ведучий звертається до дітей: Давайте сядемо зручніше розслабимося і заплющимо очі. Психологічний етюд Неслухняні ведмежата Ведмедики з'їли смачні але немиті яблука.
53377. Игры для детей к Библейским урокам 43 KB
  Во время этой игры дети могут увидеть что Божья любовь неотделима от нас также как и наша тень. Пока бутерброды теплые поговорить о том что нам тепло когда Божья любовь покрывает нас как расплавленный сыр покрывает хлеб.