Главная
страница 1
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 модулей:


  1. dudge-ejb – в этом модуле реализована основная логика системы. В свою очередь, этот модуль содержит 2 класса, в которых реализована большая часть бизнес-логики:

    1. 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-аннотаций.

  1. dudge-lib – содержит классы, использующиеся в других модулях.

  2. dudge-slave – содержит класс, использующийся для проверки решений – SlaveBean, который реализует интерфейс SlaveLocal, представленный на рисунке 7. Данный интерфейс декларирует только 1 метод – testSolution.

Рис. 7 – UML-диаграмма класса SlaveBean




  1. 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


Смотрите также:
1 Архитектура Dudge
114.83kb.
1 стр.
Архитектура древней Руси
37.06kb.
1 стр.
«…Архитектура тоже летопись мира» ( Н. В. Гоголь)
13.16kb.
1 стр.
1. 5 Архитектура операционной системы
861.78kb.
4 стр.
Архитектура компьютера
37.3kb.
1 стр.
Архитектура это не схема. Архитектура имеет несколько уровней
57.96kb.
1 стр.
1 План доработки Dudge
52.98kb.
1 стр.
Термины и определения Архитектура
143.25kb.
1 стр.
Вопросы к экзамену Архитектура «монументального историзма»
42.04kb.
1 стр.
Вопросы к зачету Архитектура «монументального историзма» (Византийский стиль) в Киевской Руси
42.04kb.
1 стр.
Реферат «архитектура древнего рима»
369.62kb.
1 стр.
Кураторский манифест starсhitecture звездная архитектура. Архитектура звезд
12.12kb.
1 стр.