Архитектура Dudgex

1 Архитектура Dudge
Система-арбитр Dudge написана на языке программирования Java.
Поскольку Dudge является
веб-приложением, для его
запуска
необходим сервер приложений. В качестве сервера приложений Dudge
использует GlassFish.
Взаимодействие Dudge, GlassFish и JVM схематично изображено на
рисунке 1:
Dudge
GlassFish Server
Java Virtual Machine
Рис. 1 – Взаимодействие Dudge, GlassFish и JVM
Dudge состоит из 3 основных уровней:
 уровень клиента (рисунок 2);
 бизнес уровень (J2EE сервер) (рисунок 3);
 уровень хранения данных (EIS уровень) (рисунок 4).
Уровень клиента
Web клиент
Оффлайн клиент
Рис. 2 – Уровень клиента
В качестве J2EE сервера Dudge использует GlassFish, а EIS уровень
представляет собой базу данных, находящуюся под управлением СУБД
PostgreSQL. Аббревиатура EIS расшифровывается как Enterprise Information
Systems. Уровень EIS предложен спецификацией J2EE. К нему относятся
хранилища данных и сторонние приложения, напрямую взаимодействующие
с ними в обход Бизнес Уровня системы, но являющиеся при этом её частью.
Также
к
этому
уровню
использующиеся приложением.
относятся
платформозависимые
модули,
J2EE сервер
Web контейнер
Java Web приложение
Servlets
JSPs
EJB контейнер
Session Beans
JPA Entities
Data Source
Рис. 3 – Бизнес уровень системы
Уровень EIS
Модуль проверки решений
Database
Рис. 4 – Уровень хранения данных
Dudge создан с использованием технологии EJB (Enterprise Java Beans).
Он состоит из 4 модулей:
1) 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-аннотаций.
2) dudge-lib – содержит классы, использующиеся в других модулях.
3) dudge-slave – содержит класс, использующийся для проверки
решений – SlaveBean, который реализует интерфейс SlaveLocal,
представленный на рисунке 7. Данный интерфейс декларирует
только 1 метод – testSolution.
Рис. 7 – UML-диаграмма класса SlaveBean
4) dudge-war – в данном модуле находится реализация веб-интерфейса
проекта.
При
создании
UI
использовались
JSP
(JavaServer
Pages) страницы, компоненты библиотеки Ext JS и Фреймворк
Struts.
Основной функцией системы-арбитра Dudge является проверка
решений задач по программированию. Решения отправляются участниками
соревнования в виде исходного кода. IDEF0 диаграмма для процесса
проверки решений, присланных участниками, представлена на рисунке 8.
EntityManager
MessageProducer
Исходный код решения
GlassFish JMS implementation
Сохранить
информацию о
решении в БД
SourceCompiler
1
Отправить
решение в
очередь
EntityManager
2
Получить
решение
Статус завершения процесса проверки
Проверить
решение
3
SolutionsQueue
4
SlaveBean
Сохранить
информацию о
проверке
решения в БД
5
DudgeBean
Рис. 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 – в данной таблице хранятся поданные заявки на участие в
соревновании. Таблица содержит следующие поля:
o owner – логин пользователя, отправившего заявку;
o contest_id – идентификатор соревнования, к которому относится
поданная заявка на участие;
o filing_time – время подачи заявки;
o message – текст сообщения;
o status – текущий статус заявки.
Первичный ключ образуют поля owner и contest_id.
Все поля данной таблицы являются обязательными для заполнения.
 Complaints – в данной таблице хранятся замечания от участников.
Таблица содержит следующие поля:
o complaint_id – идентификатор замечания;
o problem_id – идентификатор задачи, к которой относится
замечание;
o owner – логин пользователя, отправившего замечание;
o filing_time – время отправки замечания;
o message – текст замечания.
Первичный ключ – поле complaint_id.
Все поля данной таблицы являются обязательными для заполнения.
 Contest_Languages – данная таблица используется для хранения
соответствий существующих в системе соревнований и языков
программирования. Таблица содержит следующие поля:
o contest_id – идентификатор соревнования;
o language_id – идентификатор языка программирования.
Первичный ключ образуют поля contest_id и language_id.
Все поля данной таблицы являются обязательными для заполнения.
 Contest_Problems – данная таблица используется для хранения
соответствий существующих в системе соревнований и задач. Таблица
содержит следующие поля:
o contest_id – идентификатор соревнования;
o problem_id – идентификатор задачи;
o problem_order – порядковый номер задачи;
o problem_mark – заголовок для данной проблемы в рамках
соответствующего соревнования;
o problem_cost – «стоимость» задачи.
Первичный ключ образуют поля contest_id и problem_id.
Все поля данной таблицы являются обязательными для заполнения.
 Contests – в данной таблице хранится информация о соревнованиях.
Таблица содержит следующие поля
o contest_id – идентификатор соревнования;
o caption – название соревнования;
o description – описание соревнования;
o con_type – тип соревнования;
o start_time – дата и время начала соревнования;
o duration – продолжительность соревнования;
o freeze_time – оставшееся время до конца соревнования, при
котором монитор соревнований становится недоступным для
участников;
o is_open – является ли соревнование открытым для все желающих
принять в нём участие;
o rules – правила соревнования.
Первичный ключ – поле contest_id.
Все поля данной таблицы, за исключением поля description, являются
обязательными для заполнения.
 Languages – в данной таблице хранятся языки программирования.
Таблица содержит следующие поля
o language_id – идентификатор языка программирования;
o title – название языка программирования;
o description – описание языка программирования;
o file_extension – расширение файлов с исходным кодом для
данного языка программирования;
o compilation_cmd – команда для компиляции исходных кодов;
o execution_cmd – команда для выполнения скомпилированной
программы.
Первичный ключ – поле language_id.
Все поля данной таблицы являются обязательными для заполнения.
 News – в данной таблице хранятся новости. Таблица содержит
следующие поля:
o news_id – идентификатор новости;
o author – логин пользователя, добавившего новость;
o adding_time – время создания новости;
o message – текст новости.
Первичный ключ – поле news_id.
Все поля данной таблицы являются обязательными для заполнения.
 Params – в данной таблице хранятся параметры системы. Например,
версия базы данных и идентификатор соревнования по умолчанию.
Таблица содержит следующие поля:
o pname – название параметра;
o pvalue – значение параметра.
Первичный ключ – поле pname.
Все поля данной таблицы являются обязательными для заполнения.
 Problems – в данной таблице хранятся задачи. Таблица содержит
следующие поля:
o problem_id – идентификатор задачи;
o owner – логин пользователя, добавившего задачу;
o title – название задачи;
o is_hidden – является ли задача скрытой, т.е. недоступной для
использования в соревнованиях;
o description – текст задачи;
o create_time – время добавления задачи;
o memory_limit – лимит памяти, потребляемой программой во
время выполнения;
o cpu_time_limit – лимит процессорного времени для выполнения
программы;
o real_time_limit – лимит фактического времени выполнения
программы;
o output_limit – лимит на объём выходных данных программы;
o is_healthy – является ли задача «здоровой». При добавлении
новых тестов к задаче, в данное поле устанавливается значение
false. Если отправленное участником соревнования решение
задачи успешно проходит все тесты, в данное поле задачи
устанавливается значение true.
o author – автор задачи;
Первичный ключ – поле problem_id.
Все поля данной таблицы являются обязательными для заполнения.
 Roles – в данной таблице хранятся роли пользователей. Таблица
содержит следующие поля:
o contest_id – идентификатор соревнования;
o username – логин пользователя;
o role_type – роль пользователя в данном соревновании.
Первичный ключ образуют поля contest_id, username и role_type.
Все поля данной таблицы являются обязательными для заполнения.
 Runs – в данной таблице хранится информация о выполнении тестов.
Таблица содержит следующие поля:
o solution_id – идентификатор решения задачи;
o test_id – идентификатор теста;
o run_number – число запусков;
o result_type – результат выполнения теста;
o memory – максимальное значение памяти, потребляемой во время
выполнения программы;
o cpu_time – процессорное время выполнения программы;
o real_time – фактическое время выполнения программы.
Первичный ключ образуют поля solution_id и test_id.
Все поля данной таблицы являются обязательными для заполнения.
 Solutions – в данной таблице хранятся присланные участниками
решения задач. Таблица содержит следующие поля:
o solution_id – идентификатор решения задачи;
o submit_time – время отправки решения задачи;
o username – логин пользователя, отправившего решение задачи;
o contest_id – идентификатор соревнования;
o problem_id – идентификатор задачи;
o language_id – идентификатор языка программирования;
o source_code – исходный код решения задачи;
o status – статус обработки решения задачи;
o status_message – текст сообщения для статуса обработки решения
задачи;
o compilation_time – время компиляции исходного кода решения
задачи.
Первичный ключ – поле solution_id.
Все поля данной таблицы являются обязательными для заполнения.
 Tests – в данной таблице хранятся тесты для задач. Таблица содержит
следующие поля:
o test_id – идентификатор теста для задачи;
o problem_id – идентификатор задачи;
o test_number – порядковый номер теста для задачи;
o input_data – входные данные;
o output_data – выходные данные.
Первичный ключ – поле test_id.
Все поля данной таблицы являются обязательными для заполнения.
 Users – в данной таблице хранится информация о пользователях.
Таблица содержит следующие поля:
o login – логин пользователя;
o pwd_hash – хэш-код для пароля;
o email – электронная почта пользователя;
o real_name – имя пользователя;
o organization – организация/ВУЗ пользователя;
o register_date – дата регистрации пользователя;
o age – возраст пользователя;
o jabber_id – jabber пользователя;
o icq_number – icq пользователя;
o is_admin – является ли пользователь администратором;
o can_create_contest – может ли пользователь создавать новые
соревнования;
o can_create_problem – может ли пользователь добавлять в систему
новые задачи.
Первичный ключ – поле login.
Все поля данной таблицы, за исключением полей age и icq_number,
являются обязательными для заполнения.
Также
в
БД
хранится
6
последовательностей
(Sequence),
использующихся для автоматической генерации первичных ключей в
таблицах Complaints, Contests, News, Problems, Solutions и Tests. При
добавлении в таблицу новой записи, в качестве первичного ключа ей
устанавливается текущее значение последовательности.
После чего,
значение последовательности увеличивается на 1.
Даталогическая модель базы данных представлена на рисунке 10. В
данной модели все линии связей имеют отношение 1 к N.
Рис. 10 – Даталогическая модель базы данных Dudge