Уточнение требований к системе

 

В конце января текущего года состоялась встреча группы разработчиков системы с заказчиком системы в лице Дерябина О.В.. На этой встрече обсуждались описанные выше особенности инструментария BOINC и были конкретизированы многие требования к системе.

       Контекст использования системы. В настоящий момент система рассчитывается на использование в локальной сети предприятия. Однако было решено не делать существенного различия между использованием системы в локальной сети и в условиях открытого Интернета.

Требования к мерам по обеспечению безопасности. Предполагается использование стандартных механизмов авторизации: сессии, HTTPS (SSL), доступ с помощью пароля и имени пользователя. Были определены основные роли пользователей системы, а именно:

 

                    Участник- Исполнение заданий с разрешения администратора- Доступ к главной странице web-интерфейса (возможность стать участником)- Просмотр некоторой статистики.                                                    Разработчик:- То же, что и участник+ Добавлять задания+ Смотреть результаты исполнения заданий в рамках своего проекта.                                                    Администратор:- То же, что и участник+ Наделение участников полномочиями администратора или разработчика+ Разрешать/запрещать участие пользователей (в т.ч. по IP-адресам в сети)

       Требования к производительности. Первоначально система рассчитывается на десятки пользователей, объединенных в одну группу, и сотни unit-тестов в течение 12 часов. Типичным примером использования системы является следующий пример: Ночью выделенный сервер собирает проект и отправляет его на тестирование. К утру результаты тестирования должны быть получены разработчиками.

       Архитектура системы и её развертывание. Система будет представлять собой клиент-серверную систему. Внешние системы. Предполагается использовать БД MySQL для хранения данных. Альтернатива MySQL - PostgreSQL. Предполагается начинать с поддержки ОС Linux как для серверных, так и для клиентских компонент.

       Уточнения в формулировке основных понятий предметной области. Под unit-тестом понимается самодостаточный компонент, который дает в результате выполнения один из следующих ответов: {Тест пройден, Тест не пройден, Произошла фатальная ошибка, Превышен лимит времени исполнения}

       Режимы работы системы. Клиентская часть системы должна быть способна работать в любом из 3-х режимов:

1. Экранная заставка

2. Фоновая задача с минимальным приоритетом

3. Задача реального времени (высокий приоритет подразумевает, что нет ограничения на использование ресурсов клиентской системы)

В любом из этих режимов клиентская система в некоторый момент выходит на связь с сервером и сообщает сведения о себе. Это означает готовность клиентской машины исполнять тесты. После чего, в соответствии с требованиями по планированию, сервер может выдать клиенту задание. В течение всего последующего времени клиент и сервер поддерживают соединение (keep-alive). В случае остановки клиента и отказа от выполнения задания, он посылает серверу уведомление об этом, либо сервер ждет истечения таймаута и считает, что клиент прервал выполнение теста.

Система должна поддерживать 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