К вспомогательным файлам можно отнести файлы вариантов (var-файлы), контрольные файлы (check-файлы), библиотеки с дополнительными заданиями, созданные с помощью конструктора учебных заданий (dll-файлы), файлы дополнений и файлы внешних групп (txt-файлы, появившиеся соответственно в версии 4.15 и 4.16), а также файл loaddat.txt для дополнительной настройки рабочих каталогов (появился в версии 4.18). Все перечисленные виды файлы используются непосредственно электронным задачником или его модулями и обеспечивают дополнительные возможности при выполнении учебных заданий.

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

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

В версии 4.15 в модуль PT4Load был реализован другой, более гибкий способ добавления файлов, основанный на каталогах обновлений, которые могли располагаться как на сетевых дисках, так и на ftp-серверах: преподаватель помещал требуемые файлы в каталог обновлений, а учащийся настраивал в программе PT4Load свойства этого каталога (путь к сетевому диску или путь к ftp-серверу вместе с логином и паролем доступа), после чего мог в любой момент с помощью команды «Обновить» обеспечить обновление всех вспомогательных файлов (кроме того, модуль PT4Load один раз в день сам проверял, требуется ли обновление файлов, и при необходимости выполнял это обновление).

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

Однако работа с каталогами обновлений (в том виде, в котором она была реализована в версии 4.15) создавала ряд трудностей как для преподавателя, так и для учащегося. Преподаватель был вынужден использовать «внешние» по отношению к задачнику программные средства для загрузки на сетевой диск или ftp-сервер вспомогательных файлов, причем ситуация усложнялась, если для различных учащихся группы следовало предусмотреть различные вспомогательные файлы. Кроме того, требовалось либо получать специальные логины и пароли для учащихся, обеспечивающие только доступ на чтение из соответствующих каталогов ftp-сервера, или предоставлять учащимся полный доступ к содержимому этих каталогов, что приводило к опасности «порчи» этого содержимого. Учащийся, со своей стороны, был вынужден выполнять начальные действия по настройке каталога обновления, без которых его использование было невозможным.

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

Сохранение результатов: использование системы контроля версий

Аналогичные проблемы возникают и в отношении сохранения результатов работы. Все сведения о запусках программ, выполняющих задания, протоколируются в файле результатов results.dat (или results.abc при использовании среды PascalABC.NET). Это позволяет просматривать результаты непосредственно из рабочего каталога (с помощью модуля PT4Results); кроме того, в контрольном центре преподавателя предусмотрены средства как просмотра, так и резервного копирования файлов результатов, однако для этого требуется наличие доступа к рабочим каталогам учащихся с компьютера, на котором запущен контрольный центр. Следует также отметить, что указанный механизм предполагает, что все задания выполняются в единственном рабочем каталоге, что часто оказывается неудобным, так как учащийся может выполнять некоторые задания не в классе, а на домашнем компьютере (или создавать отдельные подкаталоги для каждой изучаемой темы). В этой ситуации информация о выполнении заданий распределяется по различным файлам результатов, что приводит к нескольким проблемам: учащийся вынужден повторно запускать программу с решениями на компьютерах дисплейного класса, чтобы информация об этих заданиях была занесена в файл результатов, доступный для просмотра преподавателем, а преподаватель лишен возможности контроля за процессом выполнения задания, поскольку в файле результатов указываются только сведения об успешном выполнении заданий (и при этом было непонятно, выполнил ли учащийся задание сам или просто позаимствовал у кого-то готовую программу с решением).

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

Попытка организовать централизованное хранение различных вариантов программ с решениями заданий была предпринята в одной из ранних версий задачника (версия 4.6, 2007 год). В ней был реализован механизм, позволяющий сохранять варианты программы в репозитории системы контроля версий CVS. Для этого преподаватель создавал с помощью специальной программы PTBackupMaker файл backup.dat — файл с backup-конфигурацией, — который было достаточно разместить в рабочем каталоге учащегося. Информация, содержащаяся в этом файле, позволяла программе учащегося осуществлять запуск CVS-клиента, который пересылал различные версии этой программы на удаленный CVS-сервер в соответствующий репозиторий (характеристики которого также были указаны в файле backup.dat). В дальнейшем преподаватель мог подключаться к удаленному CVS-серверу с помощью соответствующих средств контрольного центра преподавателя и просматривать различные версии всех программ учащихся.

Однако этот механизм в дальнейшем практически не использовался в силу ряда причин. Во-первых, он требовал возможности доступа преподавателя к какому-либо CVS-серверу на удаленном компьютере, во-вторых, на компьютере учащегося должен был быть установлен локальный CVS-клиент, обеспечивающий взаимодействие учебной программы и CVS-сервера. Кроме того, система контроля версий CVS вскоре уступила позиции другим системам (SVN, git). Требовалась разработка более универсального механизма сохранения вариантов программ, не связанного с конкретными системами контроля версий и, по возможности, не требующих установки дополнительных программных компонентов ни со стороны преподавателя, ни со стороны учащегося.

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

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

Разработка сайта:
М. Э. Абрамян, В. Н. Брагилевский

Последнее обновление:
01.01.2024