Разработка и использование в Финансовом университете свободной системы проверки контрольных и домашних работ на Java (Андрей Михеев, OSEDUCONF-2025)

Докладчик

Андрей Михеев

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

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

Однако, в представленном в работе проекте производится проверка программ на Python, а нам требовалась проверка программ на Java (Т.к. основной наш свободный проект RunaWFE написан на Java. Проект сотрудничает с ВУЗами, участники проекта ведут занятия в ВУЗах и привлекают в проект студентов). Попытка расширить на Java уже существующую систему тестирования на Python не оказалась успешной, т.к. её разработчики были загружены работой в других проектах. Поэтому из этой системы были взяты только идеи, а система тестирования на Java была написана «с нуля», с привлечением студентов проекта RunaWFE.

В докладе рассказано про разработку и использование системы в ВУЗе, о её достоинствах и недостатках, а также о борьбе с «Искусственным Интеллектом».

Презентация

Thesis

Постановка задачи

Количество студентов, у которых преподаватель ведёт семинары по программированию, как правило, достаточно большое (обычно, — от 50 до 200). Обязательным элементом занятий является самостоятельное выполнение заданий студентами, результатом которых являются разработанные программы. При таком количестве студентов преподаватель физически не может «вручную» полноценно проверить каждое выполненное задание. Поэтому используются различные упрощённые формы проверки работ, такие как: выборочная проверка, поверхностный просмотр кода без компиляции и запуска программы, коллективное решение и защита работ и т.п. Одной из форм проверки является автоматическое тестирование программ. Такой вариант проверки позволяет одному преподавателю работать с большим количеством студентов. У этого подхода тоже есть минусы. В частности, тесты обычно никак не оценивают качество кода программы. Но основной проблемой последних полутора лет преподавания становится использование студентами для генерации кода сервисов Искусственного Интеллекта (ИИ). Стандартные задачи ИИ решает уже достаточно хорошо и это приводит к тому, что оценки у студентов, пытающихся самостоятельно решить задачу, оказываются хуже, чем у студентов, представляющих решения, сгенерированные ИИ. Что заметно демотивирует студентов. Однако, оказалось, что пока ещё в формулировках задач можно «обмануть» ИИ так, чтобы он проявил элементы своего «нечеловеческого мышления» и при помощи этого отделить самостоятельно разработанные программы от сгенерированных ИИ.

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

Установка периода для загрузки решения задачи для группы

В курсе по Java в качестве решения задачи студенты загружают в систему zip-архив, содержащий проект IntelliJ IDEA Community Edition, в котором решается поставленная задача.

Просмотр всех ответов

После окончания срока загрузки работ преподаватель может посмотреть все решения (см. Рисунок \ref{mikheev-img002}), а также скачать все решения студентов в виде одного архива:

Получение решений студентов

Решения контрольной работы всех студентов группы в виде одного архива

Архив содержит набор папок, названия которых соответствуют ФИО студентов. Внутри каждой папки содержится zip-архив, содержащий проект с решением задачи.

Тестирующая система должна работать следующим образом: Для проверки каждого задания предусмотрен набор тестов, задаваемых файлами тестовых входящих и исходящих данных. Также должен задаваться набор конструкций Java, которые студентам запрещено использовать (которые не входят в изучаемый курс). Тестирующая система должна собрать программу из исходного кода, для каждого студента и каждого теста поместить в соответствующее место тестовые входящие данные, выполнить программу и сравнить результат с тестовым исходящим файлом. В результате работы системы должен быть сгенерирован отчёт, в котором для каждого студента отмечено, какие тесты прошли, а какие нет и были ли использованы «запрещенные» конструкции.

Структура разработанной программы

Программа была реализована как студенческая работа в виде проекта, размещённого на github. Проект называется HW-checker, разработан на Java, имеет графический интерфейс на базе JavaFX и может быть собран с использованием Maven или запущен из IDE.

Программа анализирует проект каждого студента, компилирует и выполняет тестируюмую программу на наборе тестов, используя класс CommandExecutor. Класс DocGenerator генерирует итоговый отчёт.

Основные компоненты программы:

• HWCheckerApplication: Главный класс приложения, отвечает за запуск программы.
• Launcher: Инициализация и подготовка программы к работе, осуществление проверки задания.
• MainController: Контроллер для управления основным интерфейсом.
• SettingsController: Контроллер для изменения настроек проверки.
• Localization: Поддержка локализации интерфейса.
• DirDeleter: Удаление временных файлов после проверки.
• DocGenerator: Генерация документации, связанной с проверкой.
• Unzipper: Распаковка архивов.
• XmlEditor: Работа с конфигурационными XML-файлами.
• CommandExecutor: Выполнение команд.
• LaunchInfo: Параметры проверки.
• Report: Отчёт о проверке.
• TestInfo: Управление информацией о тестах.
• RestrictionChecker: Анализирует проект на предмет соответствия заранее заданным правилам (например, использование запрещённых методов).

Конфигурация системы содержит следующие настройки:

• Использование Maven: Включить или отключить сборку проекта с использованием Maven.
• Использование H2-драйвера. — Определяет, требуется ли подключение находящегося в системе драйвера для H2-базы данных при выполнении тестов.
• Выбор версии JDK. — Система поддерживает выбор версии JDK для проверки работы. Это достигается благодаря возможности указания пути к конкретному JDK.
• Установка времени ожидания выполнения программы. — Для предотвращения зависания проверки из-за бесконечных циклов или длительного выполнения программы, система позволяет настроить максимальное время выполнения теста.

Работа тестирующей системы

Для работы тестирующей системы в файловой системе должны быть созданы три папки: Restrictions, Students и Tests (см. Рисунок \ref{mikheev-img005}).

Папки, необходимые для работы программы

В папку Restrictions надо поместить файл, содержащий список запрещённых конструкций. Пример файла:

Пример файла с запрещёнными конструкциями (запрещается использование стримов)

В папку Students надо разархивировать файл-архив с решениями студентов.

В папку Tests надо поместить набор папок, названия которых совпадают с названиями заданий (например, HW1, HW2 и т.д.). Внутри каждой папки должны содержатся папки, соответствующие тестам (например, TEST1, TEST2 и т.д.). Внутри папок тестов находятся папки INPUT и OUTPUT. Для каждого теста задаются файл (файлы) входящих данных и файл исходящих данных. Например, input.csv и output.txt. Файлы входящих данных находятся в папке INPUT, а исходящих — в папке OUTPUT.

На текущий момент в системе реализованы тесты двух типов. В случае тестов первого типа система компилирует программу из исходного кода при помощи jdk, в случае тестов второго типа используется maven и генерируется jar-файл, который запускается на выполнение.

После запуска системы тестирования в появившемся графическом окне надо настроить путь к jdk командой Settings, настроить пути к папкам, выбрать тип используемых тестов и указать, надо ли использовать содержащийся в системе драйвер к СУБД H2.

Графическое окно системы тестирования

Далее надо выполнить команду «Запуск проверки». После окончания тестирования будет сгенерирован отчёт о тестировании.

Применение тестирующей системы. Борьба с «Искусственным Интеллектом»

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

• В качестве задач в основном давались классические задачи на разработку алгоритмов и структур данных, но к ним делались дополнения, не являющиеся логичными с точки зрения «здравого смысла» и практического использования.
• Также была задействована проблема, для которой не существует решения, однако существует большое количество заметно отличающихся решений для её частных случаев.
• Использовались достаточно длинные формулировки заданий.
• Перед тем, как давать задачу студентам, проверялось, что ChatGPT решает её неправильно.
• Правильность загруженных в систему решений не сообщалась студентам до окончания времени загрузки.
• Искались решения с одинаковыми, нетипичными с точки зрения обычной логики ошибками.

Пример определения заимствованных решений:

Определение заимствованных решений. (Правильное решение: 7,9,4,1,2,8,6,5,3)

Выводы

В работе проверялись правильные решения на «похожесть». В данной работе все правильные решения (т.е. прошедшие тесты) принимались, заимствованные — аннулировались, а для неправильных, но не заимствованных, давалась возможность исправить и защитить их на следующем семинаре.

В целом, можно согласиться с выводом работы: Пока ещё, применяя различные приёмы, можно более-менее «отлавливать» заимствованные решения, но в будущем это будет всё более сложно и менее точно и в конечном счёте ИИ и другие технологии разовьются настолько, что сделать это (в той форме обучения, которая используется сейчас) будет нельзя. Кроме того, в обучении программированию появился «запрос от бизнеса»: учить студентов программированию «вместе с ИИ» в таких средах, как Cursor и GitHub Copilot — это приводит к большей продуктивности программиста и, соответственно, к существенному удешевлению разработки. По-видимому, относиться к такой ситуации надо так же, как к обучению на уроках математики в школе: в младших классах пользоваться калькулятором нельзя и считать надо самому, а в средних и старших, калькулятор — это необходимость и при решении задач надо уметь им хорошо пользоваться.

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

Лучшее решение, конечно, — это сознательность студентов: чтобы они не искали «косвенных способов» решения учебных задач, а относились к ним как к ещё не решённым задачам. Однако, в существующих условиях таких студентов не будет много.

640px