Уточнение требований к системе 6 Архитектура системы 8 (стр. 1 из 2)
Курсовая работа
СИСТЕМА РАСПРЕДЕЛЕННОГО UNIT-ТЕСТИРОВАНИЯ «Testing grid»: уточнение требований и разработка архитектуры системы
Кузнецов Алексей Александрович
Научный руководитель
доцент ФИТ НГУ, Иртегов Дмитрий Валентинович, начальник отдела внутренних разработок SWsoft Дерябин Олег Владиславович
_____________________________
Новосибирск – 2006
Введение и постановка задачи. 3
Уточнение требований к системе. 6
Введение и постановка задачи
Цель проекта «Testing Grid»— создание системы распределенного unit-тестирования с использованием некоторых подходов GRID. Тестирование является одним из важнейших этапов разработки приложения, всестороннее тестирование — сложный, долгий и ресурсоемкий процесс. Но, тем не менее, необходимый. Для облегчения и автоматизации этого процесса и нужна эта система.
Одним из важнейших этапов разработки программного обеспечения является этап определения требований к системе. Уже на данном этапе работы возникли первые сложности, которые были обусловлены причинами, о которых будет сказано ниже.
Первой проблемой оказалось огромное количество различных подходов к решению проблемы построения распределенных систем. Второй и более значимой проблемой было то обстоятельство, что заказчик системы в лице О. В. Дерябина не был готов предоставить ясные сведения о том, какое место должна занимать подобная система в процессе тестирования программного обеспечения.
Тем не менее, было принято решение о выработке черновика требований к системе распределенного тестирования. Работа по формулировке требований производилась силами команды разработчиков будущей системы и контролировалась О. В. Дерябиным. В результате данных усилий был создан документ, в достаточной мере отражающий предварительное представление разработчиков о структуре системы, об основных терминах предметной области, но не о средствах и способах достижения поставленных целей.
В этой связи было принято решение о создании прототипа системы на основе некоторых открытых и некоммерческих сторонних разработок, которые уже существовали. Выбор подобной основы пал на достаточно популярный набор компонент BOINC, который, предположительно, представлял собой набор компонентов, использование которых в нашей системе представлялось целесообразным.
В ходе разработки прототипа системы, основанного на инструментарии BOINC, были проведены исследования, выявившие сильные и слабые стороны возможности дальнейшего использования BOINC в качестве основы системы распределенного unit-тестирования.
К сильным сторонам системы BOINC были отнесены следующие факты:
1. Использование протокола HTTP для коммуникации между клиентским и серверным приложениями. Данный факт, как мы убедились в дальнейшем, имеет важнейшее значение.
2. Наличие ЭЦП, как механизма защиты системы от вредоносного кода предполагается, что это позволяет исключить возможность исполнения вредоносного кода.
3. Наличие Web-интерфейса для управления системой.
К слабым сторонам системы BOINC были отнесены следующие факты:
1. В системе очень слабо развита система авторизации. Возникает проблема разграничения полномочий пользователей системы. Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто участник (предоставляет машину, и не имеющий права на просмотр результатов исполнения.
Примером может служить пользователь рабочей станции из другого отдела компании). Однако в случае с BOINC мы имеем систему, которая не различает клиентов. Т.е. всякий может подключиться к системе. И все пользователи имеют одинаковые права. В данной системе, разграничение полномочий фактически - задача Web-интерфейса и сетевого экрана, который будет необходимо тонко настраивать для того, чтобы оградить систему от нежелательных пользователей. В системе BOINC предполагается, что исполняемый код исходит от администратора системы, однако в нашем случае это не так. Необходимо связывать новые рабочие модули с идентификатором пользователя, который их создал.
2. Хранение рабочих модулей и результатов их работы осуществляется файловой системой. Это порождает очень любопытную систему уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Удаление этих файлов — цель дополнительного демона FileDeleter, который постоянно работает на сервере.
3. Скудные возможности для диалога между сервером и клиентами. Фактически, весь диалог сводится к тому, что клиент запрашивает работу у сервера и возвращает серверу результат. В нашем случае это означает, что сервер не может заранее узнать, обладает ли клиент необходимыми ресурсами для выполнения рабочего модуля. Дело в том, что система определения возможностей клиента находится в зачаточном состоянии, и стандартных средств для ее расширения не было предусмотрено. Нам же крайне важна именно развитая система определения ресурсов клиентских машин. Также принятая в BOINC система рабочих модулей предполагает, что в нашем случае очередной тестирующий модуль должен передаваться каждый раз вместе с тестируемым модулем, что накладно.
4. Недостаточная надежность системы и низкое качество реализации. Действительно, явилась очень значимым обстоятельством чрезвычайно неустойчивая работа некоторых подсистем. Причины этого остаются невыясненными до сих пор.
5. Значительное разнообразие использованных средств, использованных для создания системы BOINC. По данной системе можно судить об этапах развития сети Интернет на протяжении последних 10 лет. К их числу можно отнести: PHP, CGI, Python, C\С++, XML, системные сценарии (shell-scripts) для Linux и многое другое. Подобный коктейль средств не был желателен с точки зрения, как безопасности, так и интеграции различных компонент.
6. Отсутствие полной, корректной и непротиворечивой документации. Действительно, в ходе работ по созданию прототипа системы на основе BOINC, часто возникали проблемы с качеством официальной документации [1], которая частично устарела, не описывала многие аспекты работы системы BOINC и зачастую содержала противоречивые инструкции по развертыванию.
Как можно видеть из приведенных выше сведений, сильные стороны системы оказались в её концепции, а не реализации. Реализация же данной системы не была проведена достаточно качественно, и дополнительная реализация многих возможностей, полезных для распределенного тестирования оказывается крайне затрудненной. В этой связи была поставлена задача выработки концепции и архитектуры системы на основе полученного опыта эксплуатации и адаптации системы BOINC для наших целей.
Уточнение требований к системе
В конце января текущего года состоялась встреча группы разработчиков системы с заказчиком системы в лице Дерябина О.В.. На этой встрече обсуждались описанные выше особенности инструментария BOINC и были конкретизированы многие требования к системе.
Контекст использования системы. В настоящий момент система рассчитывается на использование в локальной сети предприятия. Однако было решено не делать существенного различия между использованием системы в локальной сети и в условиях открытого Интернета.
Требования к мерам по обеспечению безопасности. Предполагается использование стандартных механизмов авторизации: сессии, HTTPS (SSL), доступ с помощью пароля и имени пользователя. Были определены основные роли пользователей системы, а именно:
Участник- Исполнение заданий с разрешения администратора- Доступ к главной странице web-интерфейса (возможность стать участником)- Просмотр некоторой статистики. Разработчик:- То же, что и участник+ Добавлять задания+ Смотреть результаты исполнения заданий в рамках своего проекта. Администратор:- То же, что и участник+ Наделение участников полномочиями администратора или разработчика+ Разрешать/запрещать участие пользователей (в т.ч. по IP-адресам в сети)Требования к производительности. Первоначально система рассчитывается на десятки пользователей, объединенных в одну группу, и сотни unit-тестов в течение 12 часов. Типичным примером использования системы является следующий пример: Ночью выделенный сервер собирает проект и отправляет его на тестирование. К утру результаты тестирования должны быть получены разработчиками.
Архитектура системы и её развертывание. Система будет представлять собой клиент-серверную систему. Внешние системы. Предполагается использовать БД MySQL для хранения данных. Альтернатива MySQL - PostgreSQL. Предполагается начинать с поддержки ОС Linux как для серверных, так и для клиентских компонент.
Уточнения в формулировке основных понятий предметной области. Под unit-тестом понимается самодостаточный компонент, который дает в результате выполнения один из следующих ответов: {Тест пройден, Тест не пройден, Произошла фатальная ошибка, Превышен лимит времени исполнения}
Режимы работы системы. Клиентская часть системы должна быть способна работать в любом из 3-х режимов:
1. Экранная заставка
2. Фоновая задача с минимальным приоритетом
3. Задача реального времени (высокий приоритет подразумевает, что нет ограничения на использование ресурсов клиентской системы)
В любом из этих режимов клиентская система в некоторый момент выходит на связь с сервером и сообщает сведения о себе. Это означает готовность клиентской машины исполнять тесты. После чего, в соответствии с требованиями по планированию, сервер может выдать клиенту задание. В течение всего последующего времени клиент и сервер поддерживают соединение (keep-alive). В случае остановки клиента и отказа от выполнения задания, он посылает серверу уведомление об этом, либо сервер ждет истечения таймаута и считает, что клиент прервал выполнение теста.