В работе рассматриваются возможности автоматизации проверки задач для курса «Функциональное программирование» [1], читающемся на математико-механическом факультете СПбГУ. Последние четыре года при проведении курса используется система тестирования и учета решения задач [2]. В результате внедрения этои системы заметно увеличилась активность студентов при решении задач, и, в то же время, заметно упростилась работа преподавателя. В 2016 году система была дополнена средствами автоматизированнои проверки задач. Это позволило преподавателю избавиться от части рутиннои работы и сосредоточиться на содержательнои работе со студентами. В то же время, первые результаты работы с новои версиеи системы показали необходимость ее усовершенствования. В настоящее время разрабатывается проект новои версии системы, позволяющеи сделать работу преподавателя более комфортнои . Перечислим кратко особенности рассматриваемого курса. Курс «Функциональное программирование» проводится на математико-механическом факультете СПбГУ для студентов 4 или 3 курс, в зависимости от специальности. Курс читается на основе языка Haskell [3]. Для участников не предполагаются какие-либо знания в области функционального программирования, но предполагается достаточно хорошие навыки программирования вообще и общая математическая культура. Рассматриваются темы от основ функционального программирования (функции высшего порядка, алгебраические типы данных и т.д.) до достаточно сложных тем, таких, как продолжения (continuations), монады, «бесплатные теоремы» (theorems for free) и т.д.

Курс слушают примерно 70-80 человек. Проверка задач с помощью тестов используется в большинстве массовых онлаи н курсов (например, в курсе Stepic, подготовленным Д.Н.Москвиным [4]). В отличие от таких курсов, в рассматриваемои системе автоматическое засчитывание задач, у которых прошли все тесты, не предусмотрено, они в любом случае просматриваются и засчитываются вручную. В следующеи версии предполагается реализовать автоматическое засчитывание задач с прои денными тестами, но не для всех, а только для задач, повышеннои сложности. Для такого автоматического засчитывания будет необходимо также обеспечить контроль списывания, он обсуждается ниже.

По сравнению с распространенными системами тестирования, реализованная подсистема тестирования обладает рядом особенностеи :

1. Студенту сообщается тестовый пример вызова, на котором его решение дало неправильные результаты. В большинстве систем тестирования [4,5] Автоматическое засчитывание типичных правильных решений. Одна из особенностеи простых задач, которые даются для закрепления материала в том, что у них, как правило, есть небольшое количество возможных правильных решении , и большинство студентов присылают одно из них.

Например, для закрепления темы «бесконечные списки» дается задача «Описать бесконечныи список [7,77,777,7777,7777…]». Для этои задачи есть не так мало решении , которые приходят в голову студентам. Но есть примерно 3-4 наиболее типичных правильных решения, которые, в совокупности, присылают примерно 50% студентов. Из оставшихся студентов примерно 40% присылает тоже 4-5 типичных вариантов решения, но эти варианты не совсем правильные, для них требуется написать замечания.

Важнои особенностью, характернои , видимо, именно для функционального программирования, является то, что эти типичные решения часто совпадают (с точностью до имен переменных). Это связано с тем, что что в языке Haskell студенту не надо реализовывать ввод и вывод данных, подключать библиотеки и писать другои вспомогательныи код, которыи каждыи студент напишет немного по-другому. Решение простои задачи состоит, во многих случаях, из 1-10 строк кода.

Система автоматического засчитывания задач на основе правильных решении позволяет преподавателю хранить такие правильные решения в базе и засчитывать их автоматически (рис.2). Таким образом, у преподавателя освобождается время для работы с 10-20% студентов, приславших нестандартные решения -или решения с ошибками, или, наоборот, решения, использующие нестандартные подходы.

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

Преподаватель должен нажать кнопку «Засчитать одобренные решения», и это делается, как правило, раз или два в день. Смысл в том, чтобы студент не знал, что некоторые из его решении засчитываются автоматически. Как нам кажется, если студент будет знать, что при некоторых обстоятельствах его решения зачтется сразу, у него может возникнуть ощущение, что такое решения является более правильным, он может попытаться подобрать его и т.д. 2. Перед сравнением присланного решения с правильными образцами оно, в любом случае, проверяется тестами. Это значительно упрощает сравнение задач. Например, мы можем, заменять переменные на их порядковые номера (чтобы сравнить программы с точностью до имен переменных) и не беспокоиться о том, что можем про неправильную программу решить, что она в точности равна правильнои и засчитать. Сравниваемые программы точно по краи неи мере дают правильные результаты, иначе они не прошли бы тесты. Каталог типичных замечаний. Замечания, которые преподаватель пишет студентам, тоже часто повторяются. Как правило, для каждои задачи есть 3-5 типичных замечании , которые охватывают 30-80% всех случаев. В текущеи версии системы реализован простои набор средств, позволяющии облегчить процесс проставления замечании . Для каждои задачи можно ввести и запомнить несколько типичных замечании . При проверке задачи этот список показывается рядом с проверяемым решением, и преподаватель может одним нажатием вставить его в нужное место (рис. 3).

Автоматизированное проставление замечаний. Еще одна возможность, реализованная в системе, но оказавшаяся не очень востребованнои , -это автоматизированное проставление замечании . Замечания могут снабжаться условием, при котором они возникают. В настоящее время условие -это просто фрагмент текста. Например, "if (" -это условие для того, чтобы добавить типичное замечание «После if скобки можно не писать».

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

Недостатки текущеи версии системы и планируемые дополнения В настоящее время проектируется следующая версия системы. Опишем ее основные возможности:

1. Нормализация типичных решений Даже в самых простых задачах все-таки образуется много типичных решении из-за того, что студенты используют разные варианты записи конструкции . Приведем простои пример. Допустим, в задаче требуется записать выражение x*x+1. Даже те студенты, которые прислали в остальном одинаковое решение, напишут это по-разному -x^2+1, 1+x*x, (x*x)+1, (x*x+1) и различные сочетания этих вариантов. Таким образом, приходится хранить в базе очень много похожих вариантов решения.

Для решения этои проблемы предполагается задавать набор преобразовании , которые, если есть такая возможность, следует применить к решению, чтобы привести его к единому нормализованному виду. Например, в рассмотренном выше примере, таким преобразованиями могли бы быть правила «Заменить x*x на x^2" и т.д. Применение таких преобразовании позволит значительно уменьшить набор правильных решении , хранящихся в системе. Схожая технология для автоматическои генерации замечании описана в [6].

2. Автоматическая обработка типичных неправильных или не совсем правильных решений. Хотелось бы иметь возможность автоматически засчитывать (или не засчитывать) типичные не совсем правильные решения задач, добавляя, при необходимости, нужные замечания. Сеи час в системе это не предусмотрено, автоматически можно засчитывать только полностью правильные задачи. Это добавление просто реализовать, и оно существенно упростило бы работу преподавателя.

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

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

Следует отметить, однако, что анонимныи опрос, проведенныи среди участников курсов прошлых лет [7] показал, что большинство участников, если и писали задачи не самостоятельно, то делали это 1-2 раза за курс. Возможно это связано с подбором задач, они, именно с целью минимизировать списывание даются или достаточно простыми, чтобы даже слабо подготовленным студентам было интересно попробовать решить из самим, или достаточно сложными, чтобы студенты не рисковали копировать чужое решения, понимая, что это легко может быть обнаружено.

Тем не менее, предполагается включить в состав системы базовые возможности по контролю за списыванием:

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

Более далекие планы развития системы Перечислим кратко направления, в которых предполагается развивать систему в дальнеи шем:

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

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