Уточнение требований к системе 6 Архитектура системы 8 (стр. 2 из 2)
Система должна поддерживать JUnit тесты [3, 4]. Мы отказываемся от создания собственной системы unit-тестирования. Следует отметить, что в настоящий момент система JUnit является стандартом де-факто для unit-тестирования кода, написанного на Java, поддержка этой системы включена в большинство как коммерческих, так и свободно распространяемых средств разработки, в частности Eclipse, IntelliJ Idea, Net Beans и.т.д. В то же время не известны попытки создания распределенной системы тестирования на основе JUnit.
Требования по распределению заданий. Тесты должны исполняться в порядке убывания приоритета теста. Тест отдается только той машине, которая способна его исполнить. Каждому тесту дается верхняя временная оценка, в случае превышения, исполнение прерывается.
Изложенные требования отразили потребность сохранить сильные стороны концепции BOINC, вместе с тем дали достаточно информации для начала разработки архитектуры системы.
Достаточно внимательный взгляд на требования приводит к мысли о том, что существуют технологии, получившие всеобщее признание и позволяющие построить систему, удовлетворяющую требованиям. Речь идет об использовании Java2 Enterprise Edition для создания серверных компонент системы, при этом клиентская часть системы может быть реализована независимо и может использовать какие-либо другие технологические решения. Далее будет показано, каким образом следует использовать J2EE для разрешения существующих проблем. В настоящее время примеры использования J2EE для целей unit-тестирования не известны.
Использование сервлетов для взаимодействия с клиентскими приложениями и JSP
для взаимодействия с пользователями упростит как доставку рабочих модулей клиентам и обработку ответов клиентов, так и взаимодействие пользователя с системой.
Предполагается полностью отказаться от стратегии формирования URL на ресурсы, что позволит хранить рабочие модули и результаты в БД. Вместо URL предлагается использовать методы GET и POST протокола HTTP, с помощью которых передавать необходимые сведения. Здесь и стоит применить сервлеты.
Данный подход имеет множество преимуществ с точки зрения безопасности и позволит отказаться от мониторинга файлов на предмет их актуальности (это можно будет делать средствами SQL). При таком подходе мы сможем получить значительную независимость от реализации клиентских программ (Сейчас мы зависим от сторонней реализации).
Предлагается использовать информацию в формате XML для связи уровней представления и логики приложения. Использование таких технологий как XSLT при генерации разного рода отчетов позволит гибко настраивать как внешний вид, так и содержание отчетов. Реализация на Java позволит отказаться от жесткой привязки, как к операционной системе, так и к БД. Предлагается использовать JNDI для сведения подобных зависимостей к минимуму.
Предварительная схема работы системы распределения тестовых заданий:
Рис. 1. Предварительная схема работы системы распределения тестовых заданий.
На данной схеме можно видеть взаимодействие основных компонент, отвечающих за распределение тестовых заданий. Также был разработан черновик протокола взаимодействия клиентских и серверных частей системы. В настоящее время в этот черновик вносятся изменения, связанные с представлением информации о клиентской системе.
На следующей схеме представлена последовательность взаимодействия основных компонент системы, отвечающих за прием, проверку результатов тестирования и фиксацию полученных сведений в БД.
Рис 2. Предварительная схема работы системы обработки результатов тестирования.
Следует отметить, что клиентская часть системы не является монолитной. Тестируемые компоненты могут стать причиной критической ошибки в системе, контролирующей исполнение теста, поэтому было принято решение о том, что клиентская часть системы разделена на две части, сбой в одной из которых, предположительно, не влечет немедленного сбоя в работе другой части. Естественным разделением в данном случае было признано следующее: отдельное приложение, отвечающее за взаимодействие с сервером, запуск и остановку тестирования, отправку результатов, сбор сведений о системе клиента и приложение, контролирующее исполнение теста, время исполнения теста и передающее результат работы компоненту, отвечающему за коммуникацию с сервером.
Пользовательский интерфейс системы будет располагаться в основном на сервере управления и будет реализован с помощью сервлетов и JSP. Здесь стоит отметить, что это относится не только к интерфейсу управления заданиями, просмотру результатов, но и к управлению клиентским ПО. Другими словами, клиентское ПО предоставляет только необходимые средства управления. Они предоставляет следующие возможности: возможность запустить, остановить демон, отвечающий за тестирование либо коммуникацию с сервером. Дополнительную функциональность по управлению клиентским ПО предполагается настраивать с помощью web-интерфейса на сервере, т.к. клиентское ПО может работать полностью под управлением сервера. Одновременно это обеспечит большую интеграцию средств управления, нежели это имеет место в системах, основанных на BOINC.
Сбор сведений о системе клиента. Как уже отмечалось, важным элементом системы тестирования является сбор информации о системе, на которой предполагается исполнение теста. Во-первых, это позволит точно определить степень пригодности клиентской части для исполнения конкретного теста, а во-вторых, даст разработчиком информацию о том, какие из поддерживаемых систем (конфигураций) были задействованы, и на каких из них тестирование было успешным, а на каких нет.
Отдельной проблемой оказался способ описания конфигурации клиентской системы. Такое описание должно быть расширяемым, т.е. легко вообразить ситуацию, когда будут возникать новые существенные характеристики клиентской системы по мере внедрения и эксплуатации системы тестирования. Для решения подобной проблемы мною был разработана структура XML-документа, позволяющая описать клиентскую систему с точки зрения постоянных параметров (Название ОС, например) и параметров на усмотрение сервера (список установленных JDK, если их несколько). Вместе с тем, такой формат позволяет описывать практически произвольные параметры клиентской системы. Содержание документа представляет собой оформленную в формате иерархическую XML таблицу списков записей о свойствах клиентской системы.
Упомянутые описания обрабатываются сервером. Для этого серверная часть также должна быть легко расширяема. Для обеспечения подобной расширяемости предполагается применить модульную организацию компонента, обрабатывающего информацию о системе клиента. Предполагается разработать простой интерфейс для расширения возможностей анализа конфигурации клиента.
Результатом проделанной работы стало точное понимание требований к системе, также было составлено достаточно точное представления о структуре будущей оригинальной системы. Составлен перечень средств, с помощь которых предполагается достижение поставленной задачи автоматизации процесса unit-тестирования и более эффективного использования простаивающих рабочих станций разработчиков.
Оригинальное решение будет основано на одной из ключевой технологии Java2 Enterprise Edition – сервлетах. Использование сервлетов/JSP оправдано также и для создания web-интерфейса системы, поэтому было решено использовать именно сервлеты для коммуникации клиентских машин с сервером управления.
Необходимо также отметить, что ограничив рассмотрение вопроса только с позиции применения Java2, существуют немало различных подходов, в частности основанных на XML-RPC или SOAP [2]. Эти подходы также обеспечивают высокую переносимость, безопасность, расширяемость, и предлагают собственные решения по доставке исполняемого кода от серверов управления к клиентским машинам. Но существуют также и ограничения, связанные с использованием этих подходов.
1. University of California, Creating BOINC projects http://boinc.berkeley.edu/create_project.php
2. Karre A. A do-it-yourself framework for grid computing, 2003
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-grid_p.html
3. Beck K., Gamma E. JUnit Cookbook
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
4. Morris D. JUnit Automates Java Testing, 2003
http://www.itjungle.com/mpo/mpo110603-story01.html