Файл: Разработка базы данных.pdf

ВВЕДЕНИЕ

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

Разрабатываемая система должна предоставлять следующие возможности:

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

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

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

Глава 1.

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

• Не интерактивные системы обучения программированию. В большинстве своем такие системы представляют собой электронный учебник, содержащий материал для изучения.
• Системы обучения визуальному программированию. Обычно представляют собой IDE для создания программ методом работы с графическими элементами. В качестве примера можно привести систему Scratch. С одной стороны, такие системы обычно имеют низкой порог входа, с другой стороны визуальное программирование редко используется в “реальной” разработке, и по мнению автора рациональнее было бы начать обучение с распространённых языков программирования, хотя такие системы целесообразно использовать для обучения логике детей и школьников.
• Системы обучения программированию реализованные в виде игр. Суть обучения состоит в том, что обучающийся должен программировать игровую логику во время игрового процесса. В качестве примера можно привести игру Code hero. Такие обучающие системы хоть и выглядят оригинально, но не лишены недостатков. Основные недостатки: узкий круг задач, которые нужно решить программированием, однообразность.
• Системы обучения программированию через решение задач на языке программирования. Обучение с помощью таких систем наиболее приближено к реальной деятельности программиста. Суть обучения в подобных системах состоит в том, что учащемуся дается задание, которое нужно, затем решение проверяется на правильность. В качестве примера можно упомянуть Codecademy, интерактивную онлайн платформу для обучения программированию.

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

В качестве языка программирования для обучения был выбран язык C#. C# — это самый удобный язык.

Правила именования параметров функций:

• Для именования параметров используется стиль camel case;
• Имена параметров должны давать четкое представление о том для чего используется параметр, и какое значение следует передать при вызове функции.
• В том случае, когда это не препятствует понимаю кода, в качестве имени параметра функции используется имя соответствующего параметру класса. Для коллекций и массивов используется имя объектов, содержащихся в коллекции или массиве.
• Имена параметров не должны совпадать с именами членов класса, если этого не удается избежать, то для разрешения конфликтов используется ключевое слово this.
• В именах параметров не используется венгерская нотация.

Правила именования свойств:

• Для именования свойств используется стиль pascal case;
• В том случае, когда это не препятствует понимаю кода, в качестве имени Свойства используется имя соответствующего свойству класса. Для коллекций и массивов используется имя объектов, содержащихся в коллекции или массиве.
• Название свойства типа bool должно представлять из себя вопрос, требующий ответа да или нет.

Правила именования полей:

• Для именования полей, доступных вне класса, используется стиль pascal case, для private полей - camel case;
• В том случае, когда это не препятствует понимаю кода, в качестве имени поля используется имя соответствующего полю класса. Для коллекций и массивов используется имя объектов, содержащихся в коллекции или массиве.
• Название поля типа bool должно представлять из себя вопрос, требующий ответа да или нет.

Правила именования переменных:

• Для именования переменных используется стиль camel case;
• В циклах foreach имя переменной назначается как имя массива в единственном числе.

Для именования констант используется стиль pascal case.

Правила именования enum’ов:

• Для именования enum’ов и их значений используется стиль pascal case;
• Имена enum’ов указываются в единственном числе;
• Имена, как правило, состоят из имени сущности, к которой относится enum и названия содержимого enum’а (status, type, state).

Правила именования exception’ов:

• Для exception’ов используется стиль pascal case;
• Имена классов для создаваемых custom exception’ов заканчиваются суффиксом Exception;
• В качестве имени объекта исключения внутри catch, для исключений типа Exception, используется имя “ex”.

В таблице 1.1 приведены сводные правила именования идентификаторов.

Таблица 1.1 - Сводная таблица правил именования идентификаторов

Глава 2.

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

На рисунке 2.1 приводится структурная схема проектируемой ИС.

Рисунок 2.1 – Структурная схема системы

Система состоит из следующих модулей, взаимодействующих между собой:

• Модуль выполнения заданий. Отвечает выполнение заданий учениками. Связан с модулем тестирования кода и с модулем экспертной оценки.
• Модуль интерфейса ученика. Отвечает за взаимодействие с учеником. Связан с модулем выполнения заданий.
• Модуль экспертной оценки. Отвечает за экспертную оценку задания. Для работы использует значения метрик кода.
• Модуль тестирования кода. Отвечает за проверку решения с помощью набора тестов
• Модуль оценки метрик кода. Оценивает характеристики кода и передает значения в модуль экспертной оценки для интерпретации.
• Модуль интерфейса преподавателя. Отвечает за взаимодействие с преподавателем.
• Модуль создания заданий. Содержит инструментарий для создания новых тестовых заданий. Взаимодействует с модулем интерфейса преподавателя.

Концептуальная схема БД

Концептуальная схема базы данных строиться для описания содержания и структуры базы данных. Схема базы данных — её структура, описанная на формальном языке, поддерживаемом системой управления базами данных. Сущность – любой различимый объект, информацию о котором необходимо хранить в базе данных.

Концептуальная схема БД приведена на рисунке 2.2.

Рисунок 2.2 - Концептуальная схема БД

• Группа\Класс. В этой сущности содержится информация о группе или классе в котором учатся ученики.
• Замечание. Эта сущность содержит информацию о замечании к исходному коду решения, включая идентификатор автора замечания, текст замечания, информацию о том, было ли замечание исправлено.
• Решение. В этой сущности содержится информация решении задачи учеником.
• Исходный код решения. Эта сущность содержит исходный код решения, при внесении правок в исходный код, старая сущность остается неизменной, а в таблицу добавляется новая запись.
• Результат. Эта сущность содержит оценку решения, а также вспомогательную информацию.
• Задание. В этой сущности содержится информация о задании для решения. Условия задания, тесты и прочая информация храниться во внутреннем формате программы.
• Пользователь. В этой сущности содержится такая информация о пользователе системы, как логин, пароль, электронная почта, роль пользователя в системе (администратор, учащийся, преподаватель).

Функциональная схема системы

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

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

• Создание заданий.
• Выполнение заданий.
• Отображение интерфейса.

Рисунок 2.3 – Функциональная схема системы

На вход поступают:

• Исходный код.
• Задание.
• Тесты.

Управление осуществляется c помощью:

• Правил тестирования кода.
• Правил работы с метриками.
• Формата ошибок.
• Правил формирования интерфейса.
• Формата задания.
• Формата тестов.

Механизмом являются:

• Сборщик заданий.
• Windows Presentation Framework.
• Алгоритмы.

На выход поступают:

• Пользовательский интерфейс.
• Преподавательский интерфейс.

На рисунке 2.4 показана диаграмма «Выполнение заданий», которая содержит следующие действия над объектами:

• Тестирование кода.
• Экспертная оценка кода.
• Формирование отчета об ошибках.

Рисунок 2.4 - Функциональный блок «Выполнение заданий»

На вход поступают:

• Исходный код.
• Задание.

Управление осуществляется c помощью:

• Правил тестирования кода.
• Формата ошибок.
• Правил работы с метриками.

На выход поступает отчет об ошибках. Механизмом являются алгоритмы. 

На рисунке 2.5 показана диаграмма «Экспертная оценка кода», которая содержит следующие действия над объектами:

• Оценка метрик кода.
• Анализ метрик кода.

Рисунок 2.5 - Функциональный блок «Экспертная оценка кода»

На выход поступает результат экспертной оценки. На вход поступает исходный код. Управление осуществляется c помощью правил работы с метриками. Механизмом является алгоритмы. 

На рисунке 2.6 показана диаграмма «Отображение интерфейса», которая содержит следующие действия над объектами:

• Отображение пользовательского интерфейса.
• Отображение преподавательского интерфейса.