1 Архитектура Dudge
Система-арбитр Dudge написана на языке программирования Java.
Поскольку Dudge является веб-приложением, для его запуска необходим сервер приложений. В качестве сервера приложений Dudge использует GlassFish.
Взаимодействие Dudge, GlassFish и JVM схематично изображено на рисунке 1:
Рис. 1 – Взаимодействие Dudge, GlassFish и JVM
Dudge состоит из 3 основных уровней:
уровень клиента (рисунок 2);
бизнес уровень (J2EE сервер) (рисунок 3);
уровень хранения данных (EIS уровень) (рисунок 4).
Рис. 2 – Уровень клиента
В качестве J2EE сервера Dudge использует GlassFish, а EIS уровень представляет собой базу данных, находящуюся под управлением СУБД PostgreSQL. Аббревиатура EIS расшифровывается как Enterprise Information Systems. Уровень EIS предложен спецификацией J2EE. К нему относятся хранилища данных и сторонние приложения, напрямую взаимодействующие с ними в обход Бизнес Уровня системы, но являющиеся при этом её частью. Также к этому уровню относятся платформозависимые модули, использующиеся приложением.
Рис. 3 – Бизнес уровень системы
Рис. 4 – Уровень хранения данных
Dudge создан с использованием технологии EJB (Enterprise Java Beans). Он состоит из 4 модулей:
dudge-ejb – в этом модуле реализована основная логика системы. В свою очередь, этот модуль содержит 2 класса, в которых реализована большая часть бизнес-логики:
DudgeBean – основной класс системы (рисунок 5). Он реализует два интерфейса: DudgeLocal и DudgeRemote. В DudgeRemote объявлены только 2 метода – getSolutionEager и saveSolution. Они нужны для обмена информацией о сданном решении и статусе его проверки между DudgeBean и SlaveBean (модуль проверки). Остальные методы, необходимые для работы основного класса системы, объявлены в интерфейсе DudgeLocal;
PermissionCheckerBean – класс, использующийся другими классами системы для проверки прав пользователя на то или иное действие. Его UML диаграмма представлена на рисунке 6. Данный класс реализует интерфейс PermissionCheckerRemote.
Рис. 5 – UML-диаграмма класса DudgeBean
Рис. 6 – UML-диаграмма класса PermissionCheckerBean
Кроме того, в модуле dudge-ejb находятся классы сущностей, используемых в контексте работы системы. Например: Contest, Language, Problem, Role, Solution и т.д. Для каждой из этих сущностей реализовано объектно-реляционное отображение (маппинг) на базу данных путём использования JPA-аннотаций.
dudge-lib – содержит классы, использующиеся в других модулях.
dudge-slave – содержит класс, использующийся для проверки решений – SlaveBean, который реализует интерфейс SlaveLocal, представленный на рисунке 7. Данный интерфейс декларирует только 1 метод – testSolution.
Рис. 7 – UML-диаграмма класса SlaveBean
dudge-war – в данном модуле находится реализация веб-интерфейса проекта. При создании UI использовались JSP (JavaServer Pages) страницы, компоненты библиотеки Ext JS и Фреймворк Struts.
Основной функцией системы-арбитра Dudge является проверка решений задач по программированию. Решения отправляются участниками соревнования в виде исходного кода. IDEF0 диаграмма для процесса проверки решений, присланных участниками, представлена на рисунке 8.
Рис. 8 – IDEF0-диаграмма для процесса проверки решения
Информация о ходе и результатах проверки решения сохраняется в базу данных и в дальнейшем доступна для участников соревнований, организаторов и администраторов через веб-интерфейс системы.
Система Dudge использует в качестве СУБД PostgreSQL 8.4. PostgreSQL – это свободная объектно-реляционная система управления базами данных. Сильными сторонами PostgreSQL считаются:
поддержка БД практически неограниченного размера;
мощные и надёжные механизмы транзакций и репликации;
расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL, PL/Perl, PL/Python и PL/Tcl; дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme и PL/sh, а также имеется поддержка загрузки C-совместимых модулей;
имеется механизм наследования таблиц;
легкая расширяемость.
Ограничения в работе PostgreSQL, как СУБД, представлены в таблице 1.
Таблица 1 – Ограничения PostgreSQL
Параметр
|
Максимальное значение
|
Максимальный размер базы данных
|
Нет ограничений
|
Максимальный размер таблицы
|
32 Тбайт
|
Максимальный размер записи
|
1,6 ТБайт
|
Максимальный размер поля
|
1 Гбайт
|
Максимум записей в таблице
|
Ограничено размером таблицы
|
Максимум полей в таблице
|
250—1600, в зависимости от типов полей
|
Максимум индексов в таблице
|
Нет ограничений
|
База данных Dudge в настоящий момент включает в себя 14 таблиц:
Applications – в данной таблице хранятся поданные заявки на участие в соревновании. Таблица содержит следующие поля:
owner – логин пользователя, отправившего заявку;
contest_id – идентификатор соревнования, к которому относится поданная заявка на участие;
filing_time – время подачи заявки;
message – текст сообщения;
status – текущий статус заявки.
Первичный ключ образуют поля owner и contest_id.
Все поля данной таблицы являются обязательными для заполнения.
Complaints – в данной таблице хранятся замечания от участников. Таблица содержит следующие поля:
complaint_id – идентификатор замечания;
problem_id – идентификатор задачи, к которой относится замечание;
owner – логин пользователя, отправившего замечание;
filing_time – время отправки замечания;
message – текст замечания.
Первичный ключ – поле complaint_id.
Все поля данной таблицы являются обязательными для заполнения.
Contest_Languages – данная таблица используется для хранения соответствий существующих в системе соревнований и языков программирования. Таблица содержит следующие поля:
contest_id – идентификатор соревнования;
language_id – идентификатор языка программирования.
Первичный ключ образуют поля contest_id и language_id.
Все поля данной таблицы являются обязательными для заполнения.
Contest_Problems – данная таблица используется для хранения соответствий существующих в системе соревнований и задач. Таблица содержит следующие поля:
contest_id – идентификатор соревнования;
problem_id – идентификатор задачи;
problem_order – порядковый номер задачи;
problem_mark – заголовок для данной проблемы в рамках соответствующего соревнования;
problem_cost – «стоимость» задачи.
Первичный ключ образуют поля contest_id и problem_id.
Все поля данной таблицы являются обязательными для заполнения.
Contests – в данной таблице хранится информация о соревнованиях. Таблица содержит следующие поля
contest_id – идентификатор соревнования;
caption – название соревнования;
description – описание соревнования;
con_type – тип соревнования;
start_time – дата и время начала соревнования;
duration – продолжительность соревнования;
freeze_time – оставшееся время до конца соревнования, при котором монитор соревнований становится недоступным для участников;
is_open – является ли соревнование открытым для все желающих принять в нём участие;
rules – правила соревнования.
Первичный ключ – поле contest_id.
Все поля данной таблицы, за исключением поля description, являются обязательными для заполнения.
Languages – в данной таблице хранятся языки программирования. Таблица содержит следующие поля
language_id – идентификатор языка программирования;
title – название языка программирования;
description – описание языка программирования;
file_extension – расширение файлов с исходным кодом для данного языка программирования;
compilation_cmd – команда для компиляции исходных кодов;
execution_cmd – команда для выполнения скомпилированной программы.
Первичный ключ – поле language_id.
Все поля данной таблицы являются обязательными для заполнения.
News – в данной таблице хранятся новости. Таблица содержит следующие поля:
news_id – идентификатор новости;
author – логин пользователя, добавившего новость;
adding_time – время создания новости;
message – текст новости.
Первичный ключ – поле news_id.
Все поля данной таблицы являются обязательными для заполнения.
Params – в данной таблице хранятся параметры системы. Например, версия базы данных и идентификатор соревнования по умолчанию. Таблица содержит следующие поля:
pname – название параметра;
pvalue – значение параметра.
Первичный ключ – поле pname.
Все поля данной таблицы являются обязательными для заполнения.
Problems – в данной таблице хранятся задачи. Таблица содержит следующие поля:
problem_id – идентификатор задачи;
owner – логин пользователя, добавившего задачу;
title – название задачи;
is_hidden – является ли задача скрытой, т.е. недоступной для использования в соревнованиях;
description – текст задачи;
create_time – время добавления задачи;
memory_limit – лимит памяти, потребляемой программой во время выполнения;
cpu_time_limit – лимит процессорного времени для выполнения программы;
real_time_limit – лимит фактического времени выполнения программы;
output_limit – лимит на объём выходных данных программы;
is_healthy – является ли задача «здоровой». При добавлении новых тестов к задаче, в данное поле устанавливается значение false. Если отправленное участником соревнования решение задачи успешно проходит все тесты, в данное поле задачи устанавливается значение true.
author – автор задачи;
Первичный ключ – поле problem_id.
Все поля данной таблицы являются обязательными для заполнения.
Roles – в данной таблице хранятся роли пользователей. Таблица содержит следующие поля:
contest_id – идентификатор соревнования;
username – логин пользователя;
role_type – роль пользователя в данном соревновании.
Первичный ключ образуют поля contest_id, username и role_type.
Все поля данной таблицы являются обязательными для заполнения.
Runs – в данной таблице хранится информация о выполнении тестов. Таблица содержит следующие поля:
solution_id – идентификатор решения задачи;
test_id – идентификатор теста;
run_number – число запусков;
result_type – результат выполнения теста;
memory – максимальное значение памяти, потребляемой во время выполнения программы;
cpu_time – процессорное время выполнения программы;
real_time – фактическое время выполнения программы.
Первичный ключ образуют поля solution_id и test_id.
Все поля данной таблицы являются обязательными для заполнения.
Solutions – в данной таблице хранятся присланные участниками решения задач. Таблица содержит следующие поля:
solution_id – идентификатор решения задачи;
submit_time – время отправки решения задачи;
username – логин пользователя, отправившего решение задачи;
contest_id – идентификатор соревнования;
problem_id – идентификатор задачи;
language_id – идентификатор языка программирования;
source_code – исходный код решения задачи;
status – статус обработки решения задачи;
status_message – текст сообщения для статуса обработки решения задачи;
compilation_time – время компиляции исходного кода решения задачи.
Первичный ключ – поле solution_id.
Все поля данной таблицы являются обязательными для заполнения.
Tests – в данной таблице хранятся тесты для задач. Таблица содержит следующие поля:
test_id – идентификатор теста для задачи;
problem_id – идентификатор задачи;
test_number – порядковый номер теста для задачи;
input_data – входные данные;
output_data – выходные данные.
Первичный ключ – поле test_id.
Все поля данной таблицы являются обязательными для заполнения.
Users – в данной таблице хранится информация о пользователях. Таблица содержит следующие поля:
login – логин пользователя;
pwd_hash – хэш-код для пароля;
email – электронная почта пользователя;
real_name – имя пользователя;
organization – организация/ВУЗ пользователя;
register_date – дата регистрации пользователя;
age – возраст пользователя;
jabber_id – jabber пользователя;
icq_number – icq пользователя;
is_admin – является ли пользователь администратором;
can_create_contest – может ли пользователь создавать новые соревнования;
can_create_problem – может ли пользователь добавлять в систему новые задачи.
Первичный ключ – поле login.
Все поля данной таблицы, за исключением полей age и icq_number, являются обязательными для заполнения.
Также в БД хранится 6 последовательностей (Sequence), использующихся для автоматической генерации первичных ключей в таблицах Complaints, Contests, News, Problems, Solutions и Tests. При добавлении в таблицу новой записи, в качестве первичного ключа ей устанавливается текущее значение последовательности. После чего, значение последовательности увеличивается на 1.
Даталогическая модель базы данных представлена на рисунке 10. В данной модели все линии связей имеют отношение 1 к N.
Рис. 10 – Даталогическая модель базы данных Dudge |
