Уточнение требований к системе 6 Архитектура системы 8
Курсовая работаСИСТЕМА РАСПРЕДЕЛЕННОГО UNIT-ТЕСТИРОВАНИЯ «Testing grid»: уточнение требований и разработка архитектуры системыКузнецов Алексей АлександровичНаучный руководительдоцент ФИТ НГУ, Иртегов Дмитрий Валентинович, начальник отдела внутренних разработок SWsoft Дерябин Олег Владиславович_____________________________Новосибирск – 2006Оглавление Введение и постановка задачиЦель проекта «Testing Grid»— создание системы распределенного unit-тестирования с использованием некоторых подходов GRID. Тестирование является одним из важнейших этапов разработки приложения, всестороннее тестирование — сложный, долгий и ресурсоемкий процесс. Но, тем не менее, необходимый. Для облегчения и автоматизации этого процесса и нужна эта система. Одним из важнейших этапов разработки программного обеспечения является этап определения требований к системе. Уже на данном этапе работы возникли первые сложности, которые были обусловлены причинами, о которых будет сказано ниже. Первой проблемой оказалось огромное количество различных подходов к решению проблемы построения распределенных систем. Второй и более значимой проблемой было то обстоятельство, что заказчик системы в лице О. В. Дерябина не был готов предоставить ясные сведения о том, какое место должна занимать подобная система в процессе тестирования программного обеспечения. Тем не менее, было принято решение о выработке черновика требований к системе распределенного тестирования. Работа по формулировке требований производилась силами команды разработчиков будущей системы и контролировалась О. В. Дерябиным. В результате данных усилий был создан документ, в достаточной мере отражающий предварительное представление разработчиков о структуре системы, об основных терминах предметной области, но не о средствах и способах достижения поставленных целей. В этой связи было принято решение о создании прототипа системы на основе некоторых открытых и некоммерческих сторонних разработок, которые уже существовали. Выбор подобной основы пал на достаточно популярный набор компонент BOINC, который, предположительно, представлял собой набор компонентов, использование которых в нашей системе представлялось целесообразным. В ходе разработки прототипа системы, основанного на инструментарии BOINC, были проведены исследования, выявившие сильные и слабые стороны возможности дальнейшего использования BOINC в качестве основы системы распределенного unit-тестирования. К сильным сторонам системы BOINC были отнесены следующие факты:Использование протокола HTTP для коммуникации между клиентским и серверным приложениями. Данный факт, как мы убедились в дальнейшем, имеет важнейшее значение.Наличие ЭЦП, как механизма защиты системы от вредоносного кода предполагается, что это позволяет исключить возможность исполнения вредоносного кода.Наличие Web-интерфейса для управления системой. К слабым сторонам системы BOINC были отнесены следующие факты:В системе очень слабо развита система авторизации. Возникает проблема разграничения полномочий пользователей системы. Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто участник (предоставляет машину, и не имеющий права на просмотр результатов исполнения. Примером может служить пользователь рабочей станции из другого отдела компании). Однако в случае с BOINC мы имеем систему, которая не различает клиентов. Т.е. всякий может подключиться к системе. И все пользователи имеют одинаковые права. В данной системе, разграничение полномочий фактически - задача Web-интерфейса и сетевого экрана, который будет необходимо тонко настраивать для того, чтобы оградить систему от нежелательных пользователей. В системе BOINC предполагается, что исполняемый код исходит от администратора системы, однако в нашем случае это не так. Необходимо связывать новые рабочие модули с идентификатором пользователя, который их создал.Хранение рабочих модулей и результатов их работы осуществляется файловой системой. Это порождает очень любопытную систему уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Удаление этих файлов — цель дополнительного демона FileDeleter, который постоянно работает на сервере.Скудные возможности для диалога между сервером и клиентами. Фактически, весь диалог сводится к тому, что клиент запрашивает работу у сервера и возвращает серверу результат. В нашем случае это означает, что сервер не может заранее узнать, обладает ли клиент необходимыми ресурсами для выполнения рабочего модуля. Дело в том, что си...
