4. Попытка - сущность, используемая для представления оцениваемой работы студента. Программа должна предоставить оценку для каждого правила оценивания при осуществлении попытки. Попытка ассоциирована исключительно с одним студентом, загрузившим файл с оцениваемой программой.

3.2 Архитектура приложения

Архитектура приложения может быть представлена в виде набора модулей, взаимодействующих друг с другом (рис. 5):

1. Сервер оценки. Данный сервер является основным модулем, участвующим в ходе проверки. Основные функции сервера:

· Регистрация пользователей, а также аутентификация их в системе;

· Предоставление общей информации о доступных курсах и заданиях;

· Предоставление информации о результатах проверки работ;

· Осуществление оценки попытки сдачи определенного задания;

· Регистрация новых курсов, заданий;

· Загрузка файлов в файловое хранилище.

2. Веб-интерфейс. Данный модуль предоставляет пользователю интерфейс, основанный на веб-страницах, чтобы осуществлять взаимодействие с программой. Модуль взаимодействует с сервером оценки в качестве интерфейса к предоставляемому сервером функционалу;

3. Файловое хранилище - модуль, предоставляющий возможность хранить загруженные файлы, а также иметь к ним доступ через протокол HTTP.

4. Оценивающие сервисы (оценщики) - совокупное название всех модулей, непосредственно осуществляющих проверку загруженных работ по критериям;

5. База данных - хранилище данных учетных записей пользователей, информации о курсах, заданиях, правил (подправил) оценивания, а также результатов проверок;

6. Прокси сервер - сервер, обрабатывающий все входящие запросы пользователя. Перенаправляет запросы в различные модули программы.

Рисунок 5. Изображение архитектуры программы

3.3 Сервер оценки

Сервер оценки является ключевым модулем данной программы. Данный модуль представляет собой приложение, написанное в соответствии с паттерном MVC (Model-View-Controller) [33]. Контроллерами (Controller) выступают классы, осуществляющие поддержку REST интерфейса. Поддержка MVC паттерна предоставляется фреймворком Spring MVC [34], а сам сервер разрабатывался с использованием фреймворка Spring Boot [35].

3.3.1 REST интерфейс

Модуль сервера оценки предоставляет ряд различных контроллеров, которые позволяют взаимодействовать с данным модулем посредством протокола HTTP. Каждому контроллеру ставится HTTP метод посылаемого обрабатываемого запроса, а также URL адрес, по которому будет осуществлен запрос. Основные контроллеры перечислены в табл. 2:



Таблица 2 Основные REST контроллеры сервера оценки

№	URL адрес	HTTP метод запроса	Параметры	Описание
1	/api	GET	Нет.	Контроллер, возвращающий информацию о всех курсах, зарегистрированных в системе, а также о всех заданиях, проходящих на данных курсах.
2	/api/{courseShortName}	GET	Параметр пути - courseShortName.	Контроллер, возвращающий информацию о курсе, зарегистрированным с заданным коротким именем в системе, а также о всех заданиях, проходящих на данном курсе.
3	/api/assignments/getAssignmentById	GET	assignmentId - уникальный идентификатор задания.	Контроллер, возвращающий информацию о задании, зарегистрированным с заданным уникальным идентификатором в системе.
4	/api/login	POST	username - имя пользователя, password - пароль пользователя.	Контроллер, осуществляющий вход пользователя в систему.
5	/api/logout	POST	Нет.	Контроллер, осуществляющий выход из системы.
6	/api/assignments/getAllResultsById	GET	assignmentId - уникальный идентификатор задания.	Контроллер, возвращающий информацию о результатах всех попыток определенного задания, зарегистрированного с заданным уникальным идентификатором.
7	/api/assignments/getAttemptsById	GET	assignmentId - уникальный идентификатор задания.	Контроллер, возвращающий информацию о результатах всех попыток, сделанных студентом, осуществляющим запрос на определенном задании, зарегистрированным с заданным уникальным идентификатором.
8	/api/assignments/triggerAssignmentById	POST	assignmentId - уникальный идентификатор задания, inputFile - загружаемый файл.	Контроллер, позволяющий загрузить файл в программу и зарегистрировать попытку сдачи задания студентом, сделавшим данный запрос.

3.3.2 Формат данных

При использовании запросов к серверу могут быть использованы параметры HTTP запроса (например, «/api/assignments/getAssignmentById»). Параметры HTTP запроса представлены в виде строк. Такие строки могут представлять собой числа, имена или объекты в формате JSON [36].

Данные ответов от сервера представлены в формате JSON и представляют собой объекты, которые могут иметь вложенную структуру.

3.3.3 База данных

Для возможности надежного хранения данных, полученных в ходе эксплуатации, используется реляционная база данных, сохраняющая данные на дисковое пространство компьютера.

Диаграмма реляционных таблиц базы данных представлена на рис. 6.

В качестве реляционной базы данных был выбран инструмент PostgreSQL версии 9.5.1.

При использовании фреймворка Spring для взаимодействия с базой данных было принято решение использовать Spring Data JPA [37] - инструмент, позволяющий связывать реляционные базы данных с объектно-ориентированными моделями данных. В частности, Spring Data JPA является надстройкой, упрощающей работу с фреймворком Hibernate [38], который предоставляет схожие функции.

Рисунок 6. Схема реляционной базы данных

Для конфигурации сущностей, которые необходимо хранить в базе данных использовались аннотации Java Persistence API [39], которые определяют, в каком виде будут храниться объекты в базе данных.

3.3.4 Система учетных записей

Вследствие необходимости различать пользователей, использующих программу, а также разделять их права, появилась необходимость в использовании механизмов, обеспечивающих безопасность данных, а также разграничение их прав, которые определяют возможность осуществления определенных действий.



3.3.5 Аутентификация

Для обеспечения идентификации пользователя, взаимодействующего с программой, используется система учетных записей. При этом некоторые интерфейсы сервера, требуют, чтобы пользователь был аутентифицирован программой, что подразумевает наличие у этого пользователя учетной записи.

Аутентификация происходит посредством интерфейса «/api/login», требующего имя учетной записи (представленного в виде адреса электронной почты), а также пароль. В случае успешного входа, сервер посылает «куки» (cookie) браузеру [40], с которого был послан запрос, которые используются при дальнейших запросах.

Программа позволяет осуществить регистрацию нового пользователя с помощью интерфейса «/api/registration», доступного всем пользователям. Регистрация требует от пользователя предоставления следующих данных:

1. Имя учетной записи в виде адреса электронной почты. Данное имя будет использовано при входе в систему.

2. Пароль, содержащий не менее 6 и не более 20 символов. Пароль должен состоять из цифр и букв латинского алфавита в различном регистре. Необходимо, чтобы пароль содержал как минимум одну цифру, одну букву нижнего регистра и одну букву верхнего регистра. Использование различных регистров и цифр значительно увеличивает количество возможных комбинаций паролей, что усложняет задачу взлома учетной записи с помощью перебора. Ограничения на минимальную длину пароля также повышает надежность, так как подразумевает различных комбинаций для пароля наименьшей возможной длины, что делает практически невозможным перебор всех комбинаций пароля даже такого размера.

3.3.6 Роли

У каждого зарегистрированного участника существует определенная роль в программе, определяющая ряд функций, доступных этому участнику. Права и ограничения на действия продемонстрированы в табл. 3.

Таблица 3 Роли пользователей программы

Роль	Роль в контексте алгоритмов оценивания	Права и ограничения
ROLE_STUDENT	Студент	Роль студента. Может быть участником курса. Может загружать работы в заданиях на курсах, в которых он участвует. Может получать информацию о результатах оценки высланных работ этим пользователем в соответствии с правилами, выставленными профессором.
ROLE_PROFESSOR	Преподаватель	Роль преподавателя. Может быть участником курса. Может создавать задания на курсах, в которых он участвует, а также выставлять правила просмотра результатов студентами. Может получать информацию о результатах оценки всех высланных работ на курсах, в которых он участвует.
ROLE_ADMIN	Преподаватель	Роль администратора. Может создавать курсы. Может создавать задания на любых курсах, а также выставлять правила просмотра результатов студентами. Может получать информацию о результатах оценки всех высланных работ на любых курсах.

При регистрации пользователя с помощью интерфейса «/api/registration» ему присваивается роль «ROLE_STUDENT».

Поддержка использования различных ролей пользователей поддерживается с помощью фреймворка Spring Security [41].

Разграничение REST интерфейсов по ролям пользователей представлено в табл. 4.

Таблица 4 Соответствие ролей и основных REST интерфейсов

URL адрес контроллера	Роли, имеющие доступ
/api	Авторизация не требуется
/api/{courseShortName}	Авторизация не требуется
/api/assignments/getAssignmentById	Авторизация не требуется
/api/login	Авторизация не требуется
/api/logout	ROLE_STUDENT, ROLE_PROFESSOR, ROLE_ADMIN
/api/assignments/getAllResultsById	ROLE_PROFESSOR, ROLE_ADMIN
/api/assignments/getAttemptsById	ROLE_STUDENT
/api/assignments/triggerAssignmentById	ROLE_STUDENT

3.3.7 Регистрация на курсе

При использовании системы ролей существует проблема разграничения прав между различными курсами, которые доступны различным пользователям с одинаковыми ролями. Например, два различных пользователя с ролью «ROLE_STUDENT» должны иметь различный доступ, если принимают участие в разных курсах.

Для решения данной проблемы используется подход регистрации пользователей на курсе. Данная регистрация может быть применена к пользователям с ролями «ROLE_STUDENT» или «ROLE_PROFESSOR». Каждый пользователь может быть участником определенного курса, при этом данная информация сохраняется в базе данных.

В случае обработки запроса, подразумевающего регистрацию пользователя на данном курсе, сервер обращается к базе данных, чтобы выяснить, зарегистрирован ли данный пользователь на данном курсе или нет. В случае, если регистрации на курсе нету, пользователь не может воспользоваться интерфейсом. Следующий список содержит интерфейсы, проверяющие наличие регистрации пользователя:

1. «/api/assignments/getAllResultsById» - проверка регистрации преподавателя на данном курсе;

2. «/api/assignments/getAttemptsById» - проверка регистрации студента на данном курсе;

3. «/api/assignments/triggerAssignmentById» - проверка регистрации студента на данном курсе.

3.3.8 Сохранение пароля пользователя

После регистрации учетная запись пользователя записывается в базу данных. Пароль учетной записи пользователя может храниться в первоначальном виде, но при утечке данных пользовательский пароль может быть украден. Наиболее известным и повсеместным способом решения проблемы утечки паролей является хэширование паролей с помощью определенных хэш-функций и хранения результатов хэширования паролей вместо изначальных незакодированных [42]. В случае попытки входа в систему, программа вновь высчитывает хэш пароля с помощью той же хэш-функции и проверяет, совпадает ли полученный хэш с тем, что хранится в базе. Использование хэш-функции позволяет скрыть исходное значение пароля пользователя и делает декодирование хэша практически невозможным.

Одним из минусов использования подхода хэширования пароля является возможное наличие результата в существующих словарях паролей. В случае, если хэшированные пароли будут доступны злоумышленнику, он может воспользоваться словарем таких паролей [43], которые, как правило, содержат пары пароль-хэш. Если злоумышленник найдет данный хэшированный пароль в своем словаре, он может узнать изначальный пароль, использованный при регистрации. Особенно эффективным этот подход является в случае использования пользователями простых и популярных паролей, которые наиболее вероятно появятся в словаре.

Для решения данной проблемы используется подход хэширования пароля с использованием «соли» (salt) [44] - случайной последовательности символов, используемой при хэшировании наряду с изначальным паролем. Соли, при этом, могут храниться в открытом виде вместе с хэшированными паролями, так как даже в случае их утечки, злоумышленнику придется подбирать пароль с заданной солью путем перебора, что делает расшифровку пароля практически невозможной.

В данной программе используется функция bcrypt [45] со случайно сгенерированной «солью» длиной в 10 символов. В базе данных хранятся «соль», а также хэшированный пароль.

3.4 Оценка работы

3.4.1 Поддерживаемые критерии

Существует определенный набор критериев, которые могут быть использованы при проверке программы. В реализации программы была добавлена поддержка двух языков программирования: Java версии 1.7 и Python версии 2.7.11. Эти два языка были выбраны по причине своей большой распространенности в академическом мире, а также потому что являются представителями различных классов - Java является компилируемым языком (в байткод), Python не компилируется, а передается интерпретатору в виде исходного кода. Далее описаны поддерживаемые критерии.

Поддерживаемые критерии для языка Java версии 1.7 представлены в табл. 5.

Таблица 5 Поддерживаемые критерии для языка Java версии 1.7

Название критерия	Тип критерия	Формат оцениваемой работы	Параметры критерия	Применяемые подправила
COMPILE (Компиляция)	Анализ исходного кода, индивидуальная проверка.	Исходный код.	Отсутствуют.	Долевое (100 - компиляция успешна, 0 - компиляция неуспешна).
UNIT_TESTS (Юнит-тестирование с помощью фреймворка JUnit)	Исполнение программы, индивидуальная проверка.	Скомпилированная программа.	Время выполнения всех юнит-тестов.	Долевое, долевое с порогом, штрафное, штрафное с порогом
CHECK_STYLE (Проверка стилей с помощью инструмента PMD)	Анализ исходного кода, индивидуальная проверка.	Исходный код.	В файлах проверки - файлы конфигурации инструмента PMD (rule sets).	Штрафное, штрафное с порогом
RUN_CONSOLE (Тестирование с помощью командной строки)	Исполнение программы, индивидуальная проверка.	Скомпилированная программа.	В файлах проверки - время выполнения и потребляемая для проводимых тестов.	Долевое, долевое с порогом, штрафное, штрафное с порогом
PLAGIARISM (Проверка работы на плагиат)	Анализ исходного кода, групповая проверка	Исходный код.	Отсутствуют.	Долевое (100 - работа не считается списанной, 0 - работа считается списанной).

Поддерживаемые критерии для языка Python версии 2.7.11 представлены в табл. 6.

Таблица 6 Поддерживаемые критерии для языка Python 2.7.11

Название критерия	Тип критерия	Формат оцениваемой работы	Параметры критерия	Применяемые подправила
UNIT_TESTS (Юнит-тестирование с помощью фреймворка, встроенным в язык Python)	Исполнение программы, индивидуальная проверка.	Исходный код.	Время выполнения всех юнит-тестов, название файла с точкой входа для начала юнит-тестирования.	Долевое, долевое с порогом, штрафное, штрафное с порогом
CHECK_STYLE (Проверка стилей с помощью инструмента PEP8)	Анализ исходного кода, индивидуальная проверка.	Исходный код.	Отсутствуют.	Штрафное, штрафное с порогом
RUN_CONSOLE (Тестирование с помощью командной строки)	Исполнение программы, индивидуальная проверка.	Исходный код.	В файлах проверки - время выполнения и потребляемая для проводимых тестов.	Долевое, долевое с порогом, штрафное, штрафное с порогом

3.4.2 Концепция оценщиков

Для оценки поддерживаемых критериев была разработана концепция оценщиков - сервисов, принимающих на вход попытку сдачи задания и осуществляющих проверку в соответствии какому-либо критерию. Каждому поддерживаемому критерию существует соответствие определенного оценщика.

В случае, если программа регистрирует новую попытку сдачи работы, вычисляется набор правил, по которому она должна быть оценена, откуда можно понять, какие оценщики необходимо использовать.

Вследствие того, что критерии могут относиться к различным типам оцениваемых работ, оценщики принимают работы в форматах, определенными критериями. В большей степени это относится к компилируемым языкам, где, например, компиляция осуществляется на основе исходного кода, а запуск программы, на основе результата компиляции.

Так как проверка одного критерия может занимать довольно продолжительное время, было принято решение реализовать асинхронное взаимодействие с оценщиками. Это обеспечивает более удобную организацию распараллеливания задач, а также позволяет уменьшить количество используемых потоков, которые могли быть использованы во время ожидания ответа от оценщика.

Асинхронное взаимодействие предполагает посылку запросов к удаленным сервисам и ожидание срабатывания функции обратного вызова (callback) [46]. Для того, чтобы понять, к какому запросу изначально относится текущий обратный вызов, запросу присваивается случайный идентификатор этого запроса, а также регистрируем этот идентификатор как ожидаемый. В свою очередь ожидается, что пришедший идентификатор запроса от оценщика будет совпадать с ожидаемым. Генерация случайного идентификатора осуществляется с помощью встроенного в язык Java класса SecureRandom [47], который предоставляет возможность генерации криптографически сильных случайных чисел. Длина полученной строки равна 30 символам, где каждый символ принимает одно из 37 возможных значений, что подразумевает различных комбинаций. По этой причине совпадение этих идентификаторов является крайне маловероятным для всех практических значений количества проверяемых работ.

Для того, чтобы учесть возможные ошибки на стороне оценщиков, каждый запрос регистрируется с определенным сроком, после истечения которого будет считаться, что произошла ошибка на стороне оценщика. Даже если после истечения этого срока будет зарегистрирован обратный вызов с удаленным только что идентификатором, то он будет проигнорирован.

3.4.3 Взаимодействие с Jenkins

После рассмотрения инструментов подхода непрерывной интеграции в рамках анализа предметной области было принято решение использовать инструмент Jenkins для предоставления сервисов оценщиков. Jenkins обладает богатым набором поддерживаемых плагинов, а также является легко расширяемым, что позволяет создавать различные сценарии проверки критериев.

Использование инструмента Jenkins также облегчает работу с параллельным выполнением оценки этих критериев, так как управление параллельным выполнением задач занимается внутренняя система сборщиков.

В роли сервисов оценщиков выступали так называемые проекты (job) - сценарии процесса сборки. Для каждого существующего оценщика существует свой проект, который может быть запущен сервером оценки. Опишем общий сценарий каждого такого проекта:

· Принятие запроса на проверку;

· Скачивание файлов, необходимых для проверки;

· Проведение проверки;

· Запись результатов проверки в локальную папку «/grader_results»;

· Отправка обратного вызова с результатами проверки.

Перечисление всех такие проектов, их соответствие проверяемым критерием, а также более подробное описание их работы представлено в табл. 7.

Таблица 7 Соответствие проектов инструмента Jenkins и поддерживаемых критериев

Название проекта	Язык	Оцениваемый критерий	Описание работы
java-compile	Java 1.7	COMPILE	Исходные файлы работы студента, а также файлы проверки копируются в единую папку, имеющую структуру проекта Maven. Далее происходит компиляция проекта с помощью сборщика Maven путем выполнения стадии «compile». Затем результаты отправляются в сервер проверки.
java-unit-tests	Java 1.7	UNIT_TESTS	Скомпилированная программа и файлы проверки копируются в папку проекта, запускается скрипт на языке Groovy, осуществляющий запуск фреймворка юнит-тестирования. Затем результаты отправляются в сервер проверки.
java-run-console	Java 1.7	CONSOLE	Скомпилированная программа и файлы проверки копируются в папку проекта, запускается скрипт на языке Groovy, осуществляющий запуск программы с консольным вводом. Затем результаты отправляются в сервер проверки.
java-checkstyle	Java 1.7	CHECK_STYLE	Исходные файлы работы студента, а также файлы проверки копируются в единую папку, имеющую структуру проекта Maven. Далее происходит запуск сборщика Maven с плагином PMD. Затем результаты отправляются в сервер проверки.
python-unit-tests	Python 2.7.11	UNIT_TESTS	Исходные файлы работы студента, а также файлы проверки копируются в единую папку. Запускается файл исходного кода с точкой вызова фреймворка юнит-тестирования. Затем результаты отправляются в сервер проверки.
python-run-console	Python 2.7.11	CONSOLE	Исходные файлы работы студента, а также файлы проверки копируются в единую папку, запускается скрипт на языке Groovy, осуществляющий запуск программы с консольным вводом. Затем результаты отправляются в сервер проверки.
python-checkstyle	Python 2.7.11	CHECK_STYLE	Исходные файлы работы студента, а также файлы проверки копируются в единую папку, запускается инструмент PEP8, поставляющийся внутри дистрибутива языка Python. Затем результаты отправляются в сервер проверки.

Взаимодействие с инструментом Jenkins осуществляется с помощью REST интерфейса, что позволяет отправлять запросы автоматически. Каждый вызов сборки проекта (т.е. запуска оценщика) содержит следующие параметры:

· «student_files_url» - URL адрес для скачки файлов студента;

· «secret_files_url» - ссылка на файлы использующиеся для проверки;

· «callback_id» - уникальный идентификатор запроса;

· «callback_url» - адрес, по которому нужно отправить обратный вызов;

· «params» - параметры в формате JSON, специфичные для определенного оценщика.

Несмотря на широкий спектр поддерживаемых плагинов и расширений, необходимо было создать набор скриптовых файлов, чтобы дать возможность выполнять действия, необходимые для проверки. Так как Jenkins является сильно расширяемым инструментом, он поддерживает выполнение сторонних скриптовых файлов на множестве языков программирования во время осуществления сборки проектов.

В качестве языка программирования для скриптов был выбран язык программирования Groovy в связи с тем, что он является языком, выполняющимся с помощью Java Virtual Machine, что предоставляет спектр возможностей языка Java. Также в этот язык встроена поддержка использования инструмента Apache Ant, что является очень удобным при организации файлов для сборки. Приведем список используемых скриптов:

· copy-files.groovy - скрипт для осуществления копирования файлов из файлового хранилища в директорию текущего проекта;

· run-java-console.groovy - скрипт для запуска Java приложения через консольный ввод-вывод;

· run-java-unit-tests.groovy - скрипт для запуска юнит-тестов Java приложения;

· run-python-unit-tests.groovy - скрипт для запуска юнит-тестов Python приложения;

· run-python-console.groovy - скрипт для запуска Python приложения через консольный ввод вывод;

· send-callback.groovy - скрипт для отправки обратного вызова, содержащего результаты проверки.

3.4.4 Файловая структура

Для осуществления проверки работы необходимо, чтобы тестируемый проект обладал определенной структурой, которая может использоваться различными оценщиками, для получения вспомогательных файлов, участвующих при проверке. Некоторые такие файлы могут даже не являться частями тестируемой программы, но выступать в качестве конфигурации оценивания.

Общие файлы задания, доступные студентам, не обязаны иметь никакой структуры, но крайне рекомендуется использовать такую же структуру файлов и папок, что и в проекте, который будет реализовывать студент.

Файлы студента должны быть представлены ZIP-архивом и должны содержать файлы тестируемого проекта. При этом, архив должен быть построен напрямую из корневой папки проекта.

Проверочные файлы должны быть представлены в виде ZIP-архива, корневая папка которого должна содержать папку «project», где размещен тестируемый проект, а также папку «config», где расположены дополнительные вспомогательные файлы, использующиеся при оценке.

Папка «config» предназначена для хранения файлов, которые участвуют при тестировании определенных критериев. Возможное содержание папки «config» описано в табл. 8.

Таблица 8 Описания содержания папки «config»

Название папки внутри «config»	Использующие оценщики	Комментарий
pmd	java-checkstyle	Папка «pmd» должна содержать файлы формата XML, представляющие собой конфигурации правил для инструмента PMD (rule sets).
console	java-run-console, python-run-console	Папка «console» должна содержать файлы расширения .txt, которые используются для передачи данных с помощью консольного ввода при запуске программы. Файл с входными данными должен иметь название n.txt, файл с ожидаемыми выходными данными должен иметь название n.txt, где n - номер проводимого теста. Также в папке «console» должны содержаться файлы «constraints» с информацией о требованиях к потребляемой памяти и затраченному времени.

3.4.5 Безопасность выполнения стороннего кода

Во время проведения тестирования работы программы существует необходимость ее запускать. По причине того, что невозможно заранее предсказать поведение программы, присланной на проверку, возникает необходимость ограничить возможные действия со стороны запускаемых программ, чтобы такие программы не могли нанести вред системе.

Выделим типы атак, которые могут быть использованы программой:

1. Обращение к дисковому пространству - чтение, удаление, модифицирование файлов;

2. Максимально возможная загрузка вычислительной мощности процессора (создание большого количества потоков, совершающих непрерывные вычисления);

3. Максимально возможная загрузка оперативной памяти;

4. Создание вечно работающих программ;

5. Выполнение директив командной строки.

Для устранения атак типа (1), (2), (3) и (5) используются средства операционной системы linux, а также сторонние программы ulimit и cpulimit, позволяющие запустить программу от лица определенного пользователя, а также выставить ограничения на потребляемые память и частоту процессора.

Чтобы решить проблему вечно работающих программ (тип атаки (4)) используется замер времени при запуске программы, и после достижения порогового значения процесс программы принудительно убивается с помощью средств linux.

3.4.6 Оценщик для поиска плагиата

Для нахождения плагиата в наборе программных документов был реализован описанный алгоритм, основанный на генерализации исходного кода и на алгоритме поиска и сравнения отпечатков.

Для реализации алгоритма генерализации кода было использовано абстрактное синтаксическое дерево для поиска конструкций, которое необходимо изменить. Для построения абстрактного синтаксического дерева использовалась библиотека javaparser [48]. Для реализации алгоритма поиска и сравнения отпечатков использовались стандартные средства языка Java, а также был реализован алгоритм кольцевого-хэша для эффективного подсчета набора хэшей документа.

В отличие от остальных оценщиков, работа данного оценщика основана на проверке не одной индивидуальной работы студента, а многих работ вместе. По этой причине, данный оценщик не участвует в оценке непосредственно в момент сдачи работы. Вместо этого, запуск данного оценщика осуществляется после окончания срока сдачи работ в систему (ожидается, что все работы студентов к этому моменту являются сданными) или осуществляется вручную.

При запуске этого оценщика, программа осуществляет проверку на последних загруженных студентами работах. Иными словами, для каждого студента только последняя загруженная им работа в программу будет участвовать в данной проверке. В дальнейшем, предоставляется отчет о проведении проверки, имеющий рекомендательный характер. Преподаватель может ознакомиться с результатами проверки и отметить пользователей, которые должны быть, по его мнению, уличены в списывании. После этого, программа записывает результат данной проверки.

Сервис данного оценщика является внутренним модулем и доступен с помощью REST интерфейса, реализованным с помощью фреймворка Jetty[49]. Сервис работает на сервере приложений Project Grizzly [50].

3.5 Хранение файлов

Хранение файлов является важной задачей реализации программы. Каждая сдача работы студента обусловлена отправкой файла, который необходимо хранить внутри системы для его дальнейшего пользования.

Все загруженные в программу файлы должны являться ZIP-архивами, чтобы программа имела возможность распаковывать и использовать их содержимое.

Загруженные файлы используются сервисами оценщиков, чтобы проводить тестирование и оценку программного обеспечения. Необходимо также учесть, что файлы должны быть доступны и для преподавателей. Сами студенты также должны иметь возможность скачивать файлы, которые они загружали в программу, а также иметь доступ к общим файлам заданий.

Одним из наиболее простых и удобных для пользователя вариантов является использования URL адреса для скачки файла через HTTP протокол без средств аутентификации. Это также удобно использовать внутри сервисов оценщиков, так как доступ к этому файлу будет зависеть только от доступности сервера файлового хранилища.

Однако можно предположить, что использование ссылок на файлы без аутентификации может быть неприемлемо в случаях, когда необходимо ограничить доступ к файлам для определенных круг лиц. Для решения данной проблемы, возможно ограничить не доступ к самим файлам по ссылкам, а доступ к самим ссылкам. Это позволит свободно использовать файлы внутри программы (имея привилегированный доступ к ссылкам), но и ограничивает доступ к файлам для нежелательных лиц.

При этом стоит учесть, что значение ссылок на файлы играет немаловажную роль в ограничении доступа. Например, если бы какой-либо файл студента с идентификационным номером 1 хранился по адресу «SERVER_URL:/1/some_file.txt», то можно было бы предположить, по каким адресам хранятся файлы других пользователей. По этой причине в качестве ссылки на файл использовалась случайная последовательность символов.

Генерация последовательность символов осуществляется с помощью класса SecureRandom на языке Java. Длина последовательности равна 30 символам, и каждый символ может принимать одно из 37 возможных значений, что подразумевает различных комбинаций.

Для осуществления хранения файлов файловое хранилище программы использует файловую систему операционной системы, на которой оно находится.

3.6 Веб интерфейс программы

Пользовательское взаимодействие с программой осуществляется через предоставляемый веб-интерфейс, который является набором веб-страниц, просматриваемых с помощью браузера.

В качестве фреймворка для отображения визуальных элементов был выбран популярный, на момент 2016 года, Twitter Bootstrap [51], включающий в себя HTML и CSS шаблоны, а также расширения на языке JavaScript. Помимо этого, были использованы плагины, расширяющие возможности данного фреймворка: Bootstrap File Input 4.3.2 [52], Bootstrap Notify 3.1.3 [53].

3.6.1 Взаимодействие с сервером оценки

С помощью веб-интерфейса, пользователь отправляет запросы на сервер оценки, для взаимодействия с программой. Все запросы на сервер являются AJAX-запросами [54], что позволяет отправлять множество запросов без перезагрузки страницы, а также обрабатывать ответы от сервера. Для осуществления такого типа запросов используется популярная библиотека jQuery 2.1.4 [55].

Для аутентификации пользователя в системе используются «куки» (cookies), которые отправляет сервер при входе в систему. После входа сохраненные «куки» отправляются внутри каждого запроса, и программа проверяет их корректность. В случае, если «куки» не представлены или устарели, программа просит пользователя авторизоваться.

В качестве ответов от сервера могут приходить объекты в формате JSON, поддержка которого встроена в язык JavaScript.

3.6.2 Система шаблонов

В следствие того, что данная программа не занимается генерацией разметки на стороне сервера, используется подход веб-шаблонов, встроенных в статическую разметку. Иными словами, генерация динамических страниц веб-страницы, осуществляется непосредственно на стороне пользователя с помощью средств языка JavaScript. Для поддержки веб-шаблонов используется библиотека HandleBars 4.0.4 [56], позволяющая создавать разметку на основе прописанных шаблонов и поданных входных данных.

Сервер nginx. Так как программа состоит из множества модулей, с которыми необходимо взаимодействовать пользователю, хорошей практикой является создание единой точки входа для всех запросов пользователя. Для решения этой проблемы можно использовать прокси-сервер, в роли которого в данной программе выступает веб-сервер nginx [57].

Nginx является высокопроизводительным веб-сервером, обеспечивающим функции обработки HTTP запросов, что позволяет легко настроить доступ к файлам по HTTP протоколу или создать прокси-сервер для передачи запросов на другие сервера.

При реализации программы сервер nginx использовался для обеспечения следующих функций:

· Создать единую точку входа для пользователя (все пользовательские запросы идут через один сервер), что дает возможность поддержки правила ограничения домена [58];

· Обеспечить доступ к файлам, находящимся в файловом хранилище (запросы по адресам «SERVER/files/*»);

· Обеспечить доступ к файлам статического веб-интерфейса (запросы по адресам «SERVER/site/*»);

· Обеспечить доступ к REST API сервера проверки (запросы по адресам «SERVER/api/*»).

Использование данного сервера также позволяет легко настроить кластерное решение, где многие сервера представлены во множественном виде, и необходимо распределить нагрузку между ними [59], что может потребоваться в будущем. В третьей главе описаны особенности реализации программы: используемые фреймворки, подходы, инструменты и языки программирования. Приведен краткий обзор общей архитектуры программы и взаимодействия различных модулей между друг другом. Также описан принцип взаимодействия с инструментом Jenkins.

Заключение

В рамках выполнения выпускной квалификационной работы была разработана программа, позволяющая автоматизировать проверку заданий по программированию по определенному набору критериев. Для реализации алгоритма были использованы подходы, широко использующиеся в индустрии. В программе был использован инструмент непрерывной интеграции Jenkins. Был также разработан, реализован и интегрирован в программу алгоритм поиска плагиата в исходном коде на языке Java.

Помимо этого, были изучены различные подходы верификации программного обеспечения, использующиеся в индустрии. Были изучены различные приемы построения веб-приложений, использования реляционных баз данных, а также написания веб-страниц.

Таким образом, в процессе выполнения выпускной квалификационной работы были решены следующие задачи:

1. Изучены распространенные аспекты проверки заданий по программированию;

2. Проведен анализ подходов к автоматизации проверки корректности работы программы, анализа программного кода, а также обнаружения плагиата в текстовых документах и программных кодах;

3. Выбраны подходы автоматизации проверки заданий по программированию на основе проведенного анализа;

4. Разработана архитектура программы автоматизации проверки работ по программированию;

5. Разработана программа в соответствии с разработанной архитектурой.

В качестве направлений дальнейшей работы могут выступать:

· Добавление поддержки других популярных языков программирования для проведения проверки (напр., языки C/C++, PHP, JavaScript и др.);

· Добавление поддержки других типов проектов для поддерживаемых языков (напр. Maven, Gradle, CMake и др.);

· Добавление поддержки сторонних сервисов статического анализа кода и обнаружения плагиата (напр. MOSS, JPlag и др.);

· Улучшение разработанного метода поиска плагиата с помощью добавления поддержки других языков программирования.



Список источников

1. Compilation and Interpretation [Электронный ресурс] //URL: http://www.cs.unc.edu/~olivier/comp524/Lecture02.pdf (Дата обращения: 19.03.2016, режим доступа: свободный).

2. Google Java Style [Электронный ресурс] //URL: https://google.github.io/styleguide/javaguide.html (Дата обращения: 13.04.2016, режим доступа: свободный).

3. Martin Fowler - Xunit [Электронный ресурс] //URL: http://www.martinfowler.com/bliki/Xunit.html (Дата обращения: 13.04.2016, режим доступа: свободный).

4. ejudge home page [Электронный ресурс] //URL: https://ejudge.ru/ (Дата обращения: 13.04.2016, режим доступа: свободный).

5. Peach3 - Welcome [Электронный ресурс] //URL: https://ext.peach3.nl/ (Дата обращения: 13.04.2016, режим доступа: свободный).

6. Web-CAT Community Home [Электронный ресурс] //URL: http://web-cat.org/ (Дата обращения: 13.04.2016, режим доступа: свободный).

7. Codeforces [Электронный ресурс] //URL: http://codeforces.com/ (Дата обращения: 02.05.2016, режим доступа: свободный).

8. Timus Online Judge [Электронный ресурс] //URL: http://acm.timus.ru/?locale=ru (Дата обращения: 02.05.2016, режим доступа: свободный).

9. Avoiding Plagiarism: Writing Computer Code [Электронный ресурс] //URL: http://www.upenn.edu/academicintegrity/ai_computercode.html (Дата обращения: 15.01.2015, режим доступа: свободный).

10. Roy, Chanchal Kumar;Cordy, James R., «A Survey on Software Clone Detection Research», Queen's University, Canada, 2007.

11. MOSS - A System for Detecting Software Plagiarism [Электронный ресурс] //URL: http://theory.stanford.edu/~aiken/moss/ (Дата обращения: 07.02.2015, режим доступа: свободный).

12. JPlag - Detecting Software Plagiarism [Электронный ресурс] //URL: https://jplag.ipd.kit.edu/ (Дата обращения: 08.02.2015, режим доступа: свободный).

13. Brin S., David S., «Copy Detection Mechanisms for Digital Documents», Stanford University, Stanford, 2001.

14. Markoviж A., Rakoиeviж S., «PROCEEDINGS OF THE XIV INTERNATIONAL SYMPOSIUM SYMORG 2014: MODELS AND SUSTAINABLE COMPETITIVENESS», SYMORG, Zlatibor, 2014.

15. Schleimer S., Wilkerson D., Aiken A., «Winnowing: Local Algorithms for Document Fingerprinting», Stanford University, Stanford, 2003.

16. PEP 8 Reference [Электронный ресурс] //URL: https://www.python.org/dev/peps/pep-0008/ (Дата обращения: 5.02.2016, режим доступа: свободный).

17. PHP Code Checker Onli [Электронный ресурс] //URL: http://phpcodechecker.com/ (Дата обращения: 9.02.2016, режим доступа: свободный).

18. JSLint Tool [Электронный ресурс] //URL: http://www.jslint.com/ (Дата обращения: 9.02.2016, режим доступа: свободный).

19. Intellij IDEA - JetBrains [Электронный ресурс] //URL: https://www.jetbrains.com/idea/ (Дата обращения: 10.02.2016, режим доступа: свободный).

20. PMD Toolset [Электронный ресурс] //URL: https://pmd.github.io/ (Дата обращения: 25.03.2016, режим доступа: свободный).

21. CLang Home Page [Электронный ресурс] //URL: http://clang.llvm.org/ (Дата обращения: 7.04.2016, режим доступа: свободный).

22. PVS-Studio: статический анализатор кода для C/C++/C# [Электронный ресурс] //URL: http://www.viva64.com/ru/pvs-studio/ (Дата обращения: 21.04.2016, режим доступа: свободный).

23. Make GNU Project [Электронный ресурс] //URL: https://www.gnu.org/software/make/ (Дата обращения: 22.04.2016, режим доступа: свободный).

24. CMake Home [Электронный ресурс] //URL: https://cmake.org/ (Дата обращения: 11.04.2016, режим доступа: свободный).

25. Apache Ant Project [Электронный ресурс] //URL: http://ant.apache.org/ (Дата обращения: 11.04.2016, режим доступа: свободный).

26. Maven - Welcome to Apache Maven [Электронный ресурс] //URL: https://maven.apache.org/ (Дата обращения: 1.02.2016, режим доступа: свободный).

27. Jenkins - Continuous Integration [Электронный ресурс] //URL: https://jenkins.io/ (Дата обращения: 5.03.2016, режим доступа: свободный).

28. TeamCity - JetBrains [Электронный ресурс] //URL: https://www.jetbrains.com/teamcity/ (Дата обращения: 7.03.2016, режим доступа: свободный).

29. Continuous delivery from code to deployment [Электронный ресурс] //URL: https://ru.atlassian.com/software/bamboo/ (Дата обращения: 20.04.2016, режим доступа: свободный).

30. The Ultimate List of Open Source Static Code Analysis Tools [Электронный ресурс] //URL: https://www.checkmarx.com/2014/11/13/the-ultimate-list-of-open-source-static-code-analysis-security-tools/ (Дата обращения: 20.04.2016, режим доступа: свободный).

31. Broder A., «On the resemblance and containment of documents», DIGITAL Systems Research Center, Palo Alto, 1997.

32. Merge Join Architecture [Электронный ресурс] //URL: http://blogs.msdn.com/b/craigfr/archive/2006/08/03/687584.aspx (Дата обращения: 17.04.2016, режим доступа: свободный).

33. Паттерны для новичков: MVC vs MVP vs MVVM [Электронный ресурс] //URL: https://habrahabr.ru/post/215605/ (Дата обращения: 28.03.2016, режим доступа: свободный).

34. Web MVC Framework [Электронный ресурс] //URL: http://docs.spring.io/autorepo/docs/spring/3.2.x/spring-framework-reference/html/mvc.html (Дата обращения: 28.03.2016, режим доступа: свободный).

35. Spring Boot - Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-boot/ (Дата обращения: 28.03.2016, режим доступа: свободный).

36. Введение в JSON [Электронный ресурс] //URL: http://www.json.org/json-ru.html (Дата обращения: 20.05.2016, режим доступа: свободный).

37. Spring Data JPA - Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-data-jpa/ (Дата обращения: 29.03.2016, режим доступа: свободный).

38. Hibernate. Everything data. - Hibernate [Электронный ресурс] //URL: http://hibernate.org/ (Дата обращения: 29.03.2016, режим доступа: свободный).

39. Java Persistence API [Электронный ресурс] //URL: http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html (Дата обращения: 29.03.2016, режим доступа: свободный).

40. What is a cookie? - All about Cookies [Электронный ресурс] //URL: http://www.allaboutcookies.org/cookies/ (Дата обращения: 21.04.2016, режим доступа: свободный).

41. Spring Security - Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-security/ (Дата обращения: 21.04.2016, режим доступа: свободный).

42. Safely Storing User Passwords: Hashing vs. Encrypting [Электронный ресурс] //URL: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374 (Дата обращения: 21.04.2016, режим доступа: свободный).

43. CrackStation's Password Cracking Dictionary [Электронный ресурс] //URL: https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm (Дата обращения: 21.04.2016, режим доступа: свободный).

44. Salted Password Hashing - Doing it Right [Электронный ресурс] //URL: https://crackstation.net/hashing-security.htm (Дата обращения: 21.04.2016, режим доступа: свободный).

45. Class BCrypt (Spring Security 4.1.0.RELEASE API) [Электронный ресурс] //URL: http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCrypt.html (Дата обращения: 21.04.2016, режим доступа: свободный).

46. Понимание callback-функций (колбеков) [Электронный ресурс] //URL: https://habrahabr.ru/post/151716/ (Дата обращения: 03.05.2016, режим доступа: свободный).

47. SecureRandom (Java Platform SE 7 ) - Oracle Help Center [Электронный ресурс] //URL: https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html (Дата обращения: 10.05.2016, режим доступа: свободный).

48. Java Parser and Abstract Syntax Tree [Электронный ресурс] //URL: https://github.com/javaparser/javaparser (Дата обращения: 11.05.2016, режим доступа: свободный).

49. Jetty - Servlet Engine and Http Server - Eclipse [Электронный ресурс] //URL: http://www.eclipse.org/jetty/ (Дата обращения: 25.03.2015, режим доступа: свободный).

50. Project Grizzly [Электронный ресурс] //URL: https://grizzly.java.net/ (Дата обращения: 25.03.2015, режим доступа: свободный).

51. Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. [Электронный ресурс] //URL: http://getbootstrap.com/ (Дата обращения: 8.02.2016, режим доступа: свободный).

52. File Input - Bootstrap File Input - © Kartik [Электронный ресурс] //URL: http://plugins.krajee.com/file-input (Дата обращения: 20.04.2016, режим доступа: свободный).

53. Bootstrap Notify v3.1.3 [Электронный ресурс] //URL: http://bootstrap-notify.remabledesigns.com/ (Дата обращения: 20.04.2016, режим доступа: свободный).

54. Введение в AJAX и COMET [Электронный ресурс] //URL: https://learn.javascript.ru/ajax-intro (Дата обращения: 23.05.2016, режим доступа: свободный).

55. jQuery [Электронный ресурс] //URL: https://jquery.com/ (Дата обращения: 20.02.2016, режим доступа: свободный).

56. Handlebars.js: Minimal Templating on Steroids [Электронный ресурс] //URL: http://handlebarsjs.com/ (Дата обращения: 20.02.2016, режим доступа: свободный).

57. nginx [Электронный ресурс] //URL: http://nginx.org/ru/ (Дата обращения: 03.03.2016, режим доступа: свободный).

58. Кросс-доменные ограничения и их обход [Электронный ресурс] //URL: https://learn.javascript.ru/same-origin-policy (Дата обращения: 12.05.2016, режим доступа: свободный).

59. Using nginx as HTTP load balancer [Электронный ресурс] //URL: http://nginx.org/en/docs/http/load_balancing.html (Дата обращения: 20.05.2016, режим доступа: свободный).

Размещено на Allbest.ru

...