Commit 70a0dd15 authored by Victor Yacovlev's avatar Victor Yacovlev

File moved to Python branch again

parent cfc5c269
Общие требования
================
В принципе, многие общие требования можно считать выполненными, поскольку они следуют из особенностей реализации платформы Кумир.
1. Кросс-платформенность: Windows, Linux (в частности, Ubuntu). Обязательна поддержка Mac. Как показывает опыт ВШЭ, половина студентов пользуется личными ноутбуками Apple.
2. Невысокие системные требования, в частности, к оперативной памяти и разрешению экрана. Одним из преимуществ нашей IDE по сравнению с PyCharm является возможность комфортной работы на нетбуках.
3. Простой пользовательский интерфейс. Нет более 6-7 пунктов меню, не более 10 кнопок в панели инструментов. Среда ориентирована на работу с отдельными программами, а не проектами.
4. Язык -- Python версии 3.x. Предполагается, что к моменту получения студентом диплома, версия Python 2.x будет считаться неактуальной.
Требования к функциональности статической проверки ошибок
=========================================================
Поскольку Python -- язык динамический, на нем можно писать такие программы, которые в принципе не подлежат статическому анализу на предмет ошибок. Один из примеров: программа спрашивает у пользователя имя переменной и выводит на экран ее содержимое. Тем не менее, для простых программ (среди учебных это порядка 90%), нужна диагностика ошибок, сопоставимая с Кумиром.
Кроме того, существуют различные анализаторы стиля кода (например, PEP-8), которые ругаются не на ошибки, а на оформление программы. Поскольку автоматизированная проверка на прохождение стандартов оформления, как правило, учитывается при проверке программ (в ВШЭ со студентов это точно требуют), нужна интеграция этих проверок в IDE.
При этом следует учесть, что у существующих анализаторов кода могут быть достаточно строгие критерии, которые приводят к тому, что корректные программы будут избыточно раскрашены красным подчеркиванием (что не любит Кунширенко, и я с ним согласен). Поэтому, все "ошибки" должны быть классифицированы вручную. Классы отображаемых ошибок определяются:
1) настройками среды;
2) принудительно в задании практикума (см. ниже).
Разработанные в рамках проекта анализаторы должны иметь возможность работать *автономно* от среды разработки. Преподаватель должен иметь возможность организовать проверку заданий на сервере, например, с использованием ejudje.
Возможный, но не единственный, вариант решения -- недостающий анализатор (проверка "типизации") оформить в виде плагина к одному из существующих штатных статических анализаторов.
Требования к механизму тестирования заданий
===========================================
> Сейчас код системы поддержки практикумов (для Кумира и Питона) совпадает, если не на 100%, то на 98 точно. Хотим ли мы и дальше поддерживать
> единство кода? И делать его модульным? Нужно понять насколько ситемы практикумов для Питона и Кумира должны быть похожи. -- Д.Х.
> -- Практикум - это *всего один* из модулей. Если функциональность/реализация практикума в Кумир радикально отличается от такового в Python, никто не мешает переделать
только его: сделать еще один модуль, который реализует тот же интерфейс. В.Я.
В Python есть механизм для Unit-testinga, но я не разу не встречал ни одного учебного курса, где используется или хотя бы упоминается юнит-тестирование. Таким образом, перед нами не ставятся жесткие рамки на формат тестирующих программ и их возможностей.
В отличии от языка Кумир, где есть прибитый гвоздями главный алгоритм с входными и выходными параметрами, мы должны допускать тестирование *произвольной* Python-программы. Таким образом, для проверки заданий нужно уметь:
1) перехватывать вывод программы для дальнейшего анализа;
> Возможно это нужно и для Кумира. Д.Х.
> -- Поддерживаю. В.Я.
2) имитировать ввод с клавиатуры входных данных;
3) уметь работать вообще без ввода-вывода: изменять на лету значения определенных переменных и уметь получать их значения.
> Это делает не система поддержки практикума а проверяющая программа. Д.Х.
> -- Да, но в API для учительского режима должны быть для этого соответствующие функции. В.Я.
Замечание: это все уже реализовано.
Кроме того, часто требуется не только анализ работы программы, но и анализ ее исходного текста. Механизм проверки заданий должен уметь общаться с синтаксическим анализатором, и на усмотрение автора задания, требовать, чтобы текст программы соответствовал определенным требованиям.
Например, у меня по 10-бальной шкале, за домашнее задание снималось 3 балла, если программа содержала ошибку анализатора PyLint, и 1 балл, если ошибка PEP-8. При этом программа могла работать и выдавать корректный результат. Эту проверку хочется автоматизировать.
> Это, скорее всего, совсем не сложно. Но нужно понять насколько сильно этот функционал должен быть настраевыемым учителем. Д.Х.
> Мне хватит набора CheckBox'ов и для каждого класса ошибок, и полей для ввода вещественных коэффициетов -- штрафов. В.Я.
Требования к организации взаимодействия преподавателя с учениками (Практикум)
=============================================================================
Если ориентируемся на ВУЗы, то с первого курса студенты должны уметь использовать GIT. Кто не умеет -- получает неудовлетворительную оценку.
Практикум должен предоставлять возможность использования GIT-репозитория в качестве "рабочей тетради". Предполагается, что пользователь сам настроит себе учетную запись, и вручную при создании "рабочей тетради" введет имя пользователя, URL репозитория и ключ доступа. Все остальное должна делать IDE, но в разумных пределах: ни в коем случае не стоит скрывать от пользователя все внутренности работы. В качестве примера ненавязчивой работы с репозиториями можно посмотреть клиент GitHub для Windows.
С точки зрения учительской версии, хотелось бы, но уже в порядке низкого приоритета:
1. Возможность по списку URL репозиториев загрузить все задания, проверить их, и выставить оценки. Для этого, в аттрибутах заданиях практикума, должно быть определено однозначное имя файла программы (относительно корня репозитория), которую нужно проверять.
2. Возможность сравнения текстов программ из разных репозиториев, с сигнализацией о проценте сходства (множественное выравнивание). Это нужно для борьбы с плагиатом. При этом, определенные фрагменты программ в заданиях нужно помечать в задании практикума как допустимые к копированию. В частности, некоторые куски кода я даю как supplementary, и было бы странным считать плагиатом материал из лекций.
3. Возможность учета понижающих коэффициентов для оценок за невовремя сданные решения.
Другие требования
=================
1. В Python есть консоль. Некоторые преподаватели, например Алексеевский или Курячий, методически используют ее точно так же, как в Кумире используется "пульт" исполнителя на первых занятиях, еще до введения понятия программы. Сейчас она в каком-то виде уже реализована под рабочим названием "песочница".
2. Насчет стандартных исполнителей системы Кумир -- не совсем понятно, зачем они нужны в контексте Python. Вполне возможно, их следует исключить из этой среды для того, чтобы не перегружать интерфейс.
3. Вместо принятых в Кумир исполнителей, нужны графические инструменты (aka "исполнители") для существующих Python-пакетов в зависимости от конкретных предметных областей. Например, для численных методов это может быть визуализация графиков и матриц, для биологов -- визуализация выравниваний, пространственных структур и.т.д.
4. Отладчик. Нужно учесть динамические свойства языка, в частности -- возможность изменять значения переменных во время "паузы" или выполнять произвольный код в консоли, связанной с состоянием выполняемой программы. Пока не понятно, как сделать удобнее -- заводить отдельную мини-консоль в отладчике, либо предусмотреть возможность переключения контекста в основной консоли, которая используется в качестве "песочницы".
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment