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


 

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

81013. Особенности дошкольного и школьного специального (коррекционного) образования 28.25 KB
  комплектование ДОУ по принципу ведущего отклонения в развитии ребенка с нарушениями слуха – глухие и слабослышащие; с нарушениями зрения; с нарушениями речи; с нарушениями интеллекта; с ЗПР; с нарушениями опорно – двигательного аппарата. для каждой категории детей с психофизическими нарушениями предусмотрена своя специальная школа; 2.
81014. Принципы специального образования 28.23 KB
  Выготского о зоне ближайшего развития ; принцип ранней педагогической помощи обеспечение раннего выявления и ранней диагностики отклонения ребенка для определения его образовательных потребностей; принцип коррекционнокомпенсирующей направленности опора на сохранные анализаторы а так же использование компенсаторных возможностей детей; принцип социальноадаптирующей направленности обучения подготовка ребенка с психофизическими нарушениями к максимально самостоятельной жизни в обществе чтобы избежать социального выпадения; принцип...
81015. Показатели развития ребенка, значимые для выявления психофизических нарушений 27.51 KB
  В соответствии с этим учитывается степень достижения зрелости в каждый период развития ребенка до и после его рождения. Во время эмбрионального развития организм плода очень восприимчив к различным неблагоприятным факторам. Развитие сенсорных и моторных функций которые являются базой для развития психических процессов.
81016. Причины аномального развития детей. Типы нарушений психического развития 29.04 KB
  Типы нарушений психического развития по Лебединскому: недоразвитие ранее время поражения незрелость мозга. Пример: умственная отсталость психические функции недоразвиты вынужденная недостаточность высших психических функций мышления речи; ✓ задержанное развитие замедление темпов формирования познавательной и эмоциональной сфер; ✓ поврежденное развитие более позднее после 2 3 лет патологическое воздействие на мозг; ✓ дефицитарное развитие тяжелые нарушения отдельных систем: зрения слуха речи опорнодвигательного...
81017. Принципы и методы диагностики отклонений в развитии ребенка. Функции психолого-медико-педагогической консультации 30.39 KB
  Принцип комплексного изучения ребенка который предполагает всестороннее обследование особенностей развития всех видов познавательной деятельности эмоциональноволевой сферы личности навыков и т.Принцип целостного системного изучения ребенка.Принцип динамического изучения ребенка согласно которому при обследовании важно выяснить не только то что дети знают и умеют но и их возможности в обучении зона ближайшего развития.
81018. Политический реализм и неореализм в теории международных отношений 36.26 KB
  Все концепции международных отношений нсмотря на кардинальные различия рассматривают мировую политику в целом а не отдельные ее элементы. Это отличает их от внутриобщественных отношений построенных на принципах иерархии субординации формализованных правовых нормах. В отличии от внутриобщественных отношений где формально закреплена функция государственного принятия решений в МО это невозможно на правовом уровне.
81019. Либерализм в теории международных отношений. Неолиберализм 37.31 KB
  увеличивается количество акторов и их направление интересов предсказать не всегда возможно. 2 развитие коммуникации нетрадиционных акторов международных отношений т.3 государство теряет способность деятельность других акторов которая все чаще осуществляется в обход государственного суверенитета и вопреки ему. Сужение полномочий национальных правительств увеличение многообразия акторов приводит к росту анархии в МО делают отношения неуправляемыми и плохо поддающимися структурированию.
81020. Идеализм как школа международных отношений 35.05 KB
  Основной целью стало выработка моделей нормативного ведения мировых отношений. Идеалисты отрицали силовые и военные средства как регуляторы международных отношений ориентируясь на институты международного права. Однако послевоенный мир и вторая мировая война выявили несостоятельность идеалистической концепции регулирования международных отношений.
81021. Традиционализм и модернизм как направление дискуссии в теории международных отношений 32.17 KB
  Модернисты рассматривали национальные государства в качестве автономных властных систем которые испытывает влияние других субъектов международных отношений и определенным образом реагирует на уровне внешней политики. Основная задача в ТМО – смоделировать поведение того или иного государства при воздействии внешних субъектов и спрогнозировать поведение. Традиционалисты акцентируют внимание на необходимости учета в анализе МО тех факторов которые относятся к культурным особенностям государств: влияние традиций обычаев национального...