Разработка адаптируемой системы контроля знаний студентов по теме "Теория графов"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждение высшего образования

Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Разработка адаптируемой системы контроля знаний студентов по теме «Теория графов»

студент образовательной программы

«Программная инженерия» Лосев Ян Сергеевич

Аннотация

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

Данная работа состоит из четырех глав, содержит 3 таблицы, 20 изображений и 3 приложения.

Введение

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

Объектом исследования является процесс проверки знаний учащихся.

Предметом исследования является адаптируемая система автоматизированной проверки знаний.

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

Для достижения поставленной цели необходимо решить следующие задачи:

Обзор существующих обучающих систем.

Сбор и анализ информации о проектировании и реализации адаптируемых обучающих систем.

Проектирование информационной системы контроля знаний студентов.

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

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

Тестирование разработанной системы.

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

1. Анализ существующих систем контроля знаний студентов

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

Анализ существующих решений

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

В первую очередь были рассмотрены системы для контроля знаний и обучения учащихся старших классов. Сегодня при подготовке к единым государственным экзаменам очень часто используются системы «Решу ЕГЭ» и «Яндекс Просвещение» [1]. Данные инструменты имеют большую базу оценочных средств, которая постоянно актуализируется и пополняется, а также они имеют мощный инструментарий для тестирования учащихся (рис. 1.1).



Рисунок 1.1. Яндекс Просвещение. Пример тестирования

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

Далее рассмотрим систему обучения «Coursera» [2]. Данный ресурс позволяет не только заниматься онлайн обучением, но и создавать собственные курсы, при прохождении специализированной верификации. Таким образом, несмотря на то, что преподаватели не имеют возможности самостоятельно создать необходимый им курс на базе «Coursera», такую возможность они могут получить при поддержке университета, в котором занимаются преподавательской деятельностью. Как результат, преподаватели имеют мощный адаптируемый инструмент для обучения и оценки знаний студентов.

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

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

В качестве примера системы, обладающей возможностью генерировать оценочные средства приведена система Mathmaster [3]. Данная система является бесплатной и доступна онлайн. Используя программные возможности Mathmaster пользователь может генерировать множество уникальных заданий из различных областей математики. Однако, данный ресурс предназначен для школьников и учителей так как сложность заданий ограниченна школьной программой. На рисунке 1.2 показан пример работы данной системы.

Рисунок 2. Mathmaster. Генерация заданий по математике

адаптируемый контроль знание студент

Также был рассмотрел аналог под названием «Virtual Mathematics Assistant». Данное приложение было разработано Микаэлем Фриденфалком и внедрено в Уппсальском университете. С точки зрения функциональности, это приложение наиболее близко подходит к разрабатываемой системе, так как оно представляет собой автоматизированную систему проверки студенческих знаний в предметной области «дискретная математика» и, по заявлению автора, оно способно сэкономить двести потенциальных единиц времени преподавателя против одной единицы, затраченной программистом. Однако приложение адаптировано лишь для дискретной математики и возможность изменения предметной области в нем не предусмотрена. К сожалению, сейчас нет возможности попробовать воспользоваться этим приложением так как оно не находится в открытом доступе, однако доступна статья [4] содержащая информацию о выполненной работе по разработке обучающей системы подобной той, что разрабатывается в рамках текущей выпускной квалификационной работы.

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

Обзор используемой литературы

В данной статье [4] представлен процесс разработки системы автоматической генерации оценочных средств для экзаменирования студентов, а также ее внедрение в Уппсальском университете. Данная система поддерживает два основных режима: разработчика и пользователя. Режим разработчика позволяет программисту сосредоточиться на реализации и валидации каждого компонента в системе. Режим пользователя предназначен для преподавателей. В этом режиме пользователю разрешено делать и корректировать готовые тесты для контроля студенческих знаний. Пример разработки и внедрения подобной системы очень полезен при разработке собственной адаптируемой системы мониторинга знаний студентов. Кроме того, система, представленная в этом источнике, автоматизирует процесс обучения в предметной области «дискретная математика», которая аналогична предметной области текущей выпускной квалификационной работы. Как утверждает автор статьи, система, которая была разработана в процессе его исследования, экономит потенциально двести часов преподавателя дискретной математики относительно разработчика, затрачивающего один час на настройку этой системы. Данный факт подчеркивает её актуальность.

В данном источнике [5] содержится подробное описание предметной области, необходимой для демонстрации работоспособности разрабатываемой системы. Данной предметной областью является раздел дискретной математики - теория графов. Этот ресурс содержит информацию, необходимую для реализации алгоритмов генерации оценочных средств в этой предметной области. В рамках данной работы, предметная область будет представлена в виде онтологии, вершинами которой будут являться базовые понятия предметной области, т. е. теории графов. Связи онтологии будут спроецированы на реализованные алгоритмы переходов между элементами предметной области, т. е. вершинами онтологии. Разрабатываемая программная система сможет взаимодействовать с онтологией, и использовать спроецированные алгоритмы переходов между её вершинами, для генерации оценочных средств. Данный ресурс [5] актуален, так как реализация этих алгоритмов необходима для иллюстрации возможностей системы с точки зрения генерации оценочных средств.

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

Требования к разрабатываемому программному обеспечению

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

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

Возможность работы с различными предметными областями путем настройки системы.

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

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

Полный список требований к разрабатываемой системе представлен в техническом задании в приложении A.

Экономическое обоснование решения

В качестве способа для определения стоимости разрабатываемой системы применяется модель COCOMO (Constructive Cost Model) [7]. Данная модель использует несложную формулу регрессии для определения трудозатратности, продолжительности и числа персонала, необходимого для разработки приложения. Модель COCOMO выделяет следующие базовые уравнения:

Трудоемкость = a * (KLOC)b. Измеряется в человеко-месяцах

Длительность разработки = с * (Трудоемкость)d. Измеряется в месяцах.

Число разработчиков = Трудоемкость / длительность разработки.

Коэффициенты a, b, c, d определяются согласно таблице коэффициентов модели базового уровня (Таблица 1.1):

Таблица 1.1. Коэффициенты для базовой модели COCOMO

Тип проекта	a	b	c	d
Органический	2.40	1.05	2.50	0.38
Полураздельный	3.00	1.12	2.50	0.35
Встроенный	3.60	1.20	2.50	0.32

Чтобы определить коэффициенты, которые необходимо использовать в уравнениях модели COCOMO нужно определиться с типом проекта. В случае, когда процесс разработки программного обеспечения заключён в строгие рамки, используется встроенный тип. Для проектов со смешанными требованиями и со средними по размеру проектными группами подходит полураздельный тип. Если жестких требований не предъявляется, то для проекта с небольшой командной удачным выбором станет органический тип проекта.

Так как для данной работы были выдвинуты не слишком жесткие требования, а команда разработки состоит из одного человека, было решено использовать органическую модель проекта. Следовательно, были выбраны следующие коэффициенты: a=2.4, b=1.05, c=2.5, d=0.38.

Чтобы рассчитать трудоемкость проекта, необходимо определить приблизительный объем кода разрабатываемого приложения. Так как в результате выполнения курсовых работ на втором и третьем курсах уже имеются данные по количеству написанных строк кода, можно использовать эти данные для приблизительной оценки объема кода, который будет написан на текущем этапе работы, при условии, что трудоемкость при написании выпускной квалификационной работы приблизительно равна трудоемкости написания курсовых работ третьего или второго курсов. В действительности же трудоемкость текущей работы выше, чем курсовых работ прошлых лет, поэтому грубую оценку необходимо увеличить не меньше, чем в два раза. К сожалению, подобный способ оценки трудоемкости проекта не точен, однако он полезен для грубой оценки трудоемкости разработки программного обеспечения, в случае, когда время на выполнение работы выделено с значительным запасом. Таким образом, эмпирическим путем было выявлено, что в результате реализации дополнительной функциональности разрабатываемой системы, будет написано примерно 1000 строк кода, следовательно, коэффициент KLOC = 1,00.

Далее необходимо оценить трудозатраты по разработке данного программного обеспечения, основываясь на объеме кода, рассчитанного ранее. Используя формулу определения трудоемкости, сложность данного проекта составляет 2.4*11.05 = 4.97 человека-месяца.

Длительность разработки составляет 2.5*1.270.38 = 4.59 месяцев. Количество разработчиков, необходимое для разработки данной системы составляет 4.97 / 4.59 = 2 (округленное до целого вверх) человек.

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

2. Проектирование адаптируемой системы контроля знаний студентов

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

Проектирование онтологии для демонстрации адаптируемости системы

Онтология является одной из наиболее востребованных моделей для представления знаний. Онтология состоит из понятий, связей между этими понятиями, различных аксиом и ограничений [8]. Графически, онтологии принято изображать в виде семантических сетей - информационных моделей, представляющих собой ориентированные графы, вершинами которых являются объекты предметной области, а дуги - отношениями между этими объектами. На рисунке 2.1 представлен пример семантической сети, графически иллюстрирующей онтологию.

Рисунок 2.1. Пример онтологии

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

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

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

Вершины должны представлять собой неделимые элементы предметной области.

Должно быть возможно реализовать алгоритмы переходов между вершинами онтологии.

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

Следующие элементы теории графов были выбраны в качестве вершин описываемой онтологии:

Матрица смежности - квадратная матрица A = (aij) размера n, где aij = 1, если существует ребро между вершинами i и j, и aij = 0 иначе.

Матрица инцидентности - матрица B = (bij) размера n x m, где bij = 1, если вершина i инцидентна ребру j, и bij = 0 иначе.

Матрица расстояний - квадратная матрица C = (cij) размера n, где cij = d, d >=0, если существует ребро размера d между вершинами i и j, иначе d = 0.

Планарность означает, что граф можно отобразить на плоскости таким образом, чтобы его ребра не пересекались.

Центр - это любая вершина графа, такая, что расстояние от нее до наиболее отдаленной вершины минимально.

Радиус - наименьший из эксцентриситетов вершин.

Диаметр - наибольший из эксцентриситетов вершин.

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

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

Число компонент связности.

На рисунке 2.2 представлен ориентированный граф, который был сформирован на основе этих данных.

Рисунок 2.2. Граф иллюстрирующий онтологию

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

Двумерный массив - byte [, ].

Одномерный массив - byte [ ].

Число - byte.

Строка - string.

Логическое значение - boolean.

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

Спроецировав связи представленного графа на алгоритмы переходов между вершинами онтологии, граф приобретает следующий вид (рис 2.3).

Рисунок 2.3. Граф иллюстрирующий онтологию

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

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

Разработка возможности системы быть адаптируемой к различным предметным областям

Для того, чтобы разрабатываемая система удовлетворяла требованию адаптируемости, пользователь должен иметь возможность передать спроектированную им онтологию в разрабатываемую систему. На данном этапе работы подразумевается, что такими правами для взаимодействия с системой должен обладать пользователь с ролью - преподаватель.

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

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

Проектирование информационной системы

В процессе обучения участвуют две сущности: студент и преподаватель. Проектируемая обучающая система на данном этапе должна предоставлять возможности тестирования студентов. Тестирование подразумевает собой наличие тестов, каждый из которых должен быть составлен из заданий. Один преподаватель может создавать несколько тестов, причем каждый тест состоит из некоторого множества заданий. Также стоит заметить, что различные тесты могут включать в себя одинаковые задания, а значит между тестом и заданием необходимо организовать связь «многие ко многим». Для реализации подобной связи можно ввести дополнительную сущность, связывающую пару тест-задание. Аналогично и для студента и теста.

Таким образом, обосновывается выбор списка сущностей.

Преподаватель.

Студент.

Задание.

Тест.

Задание_Тест.

Студент_Тест.

Задание_Тест и Студент_Тест введены для реализации связи «многие ко многим».

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

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

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

Атрибут «Группа» у сущности «Студент» необходим для реализации поиска по группе.

В зависимости от значения атрибута «Тематика» у сущности «Задание» определится нужный алгоритм для генерации задания.

Атрибут «Адрес» у сущности «Задание» необходим для хранения данных о местоположении файла с заданием.

Атрибуты «Имя» нужны для наглядности информации.

На рисунке 2.4 представлена спроектированная концептуальная модель в нотации ERD для выбранной предметной области.

Рисунок 2.4. Концептуальная модель в нотации ERD

Полученная на предыдущем этапе концептуальная модель была переложена в технологию Object-Relational Mapping. В качестве инструмента была использована.Net Entity Framework. На рисунке 2.5 представлена полученная модель.

Рисунок 2.5. Концептуальная модель в.Net Entity Framework

Данная модель идентична модели Entity-Relationship Diagram (рис. 2.4). После ее построения.Net Entity Framework сгенерирует базу данных, используя специализированные программные средства. В данном случае это Microsoft SQL Server 2012 Express - система управления данными, обеспечивающая функциональное и надежное хранилище данных.

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

Рисунок 2.6. Диаграмма классов информационной системы

На рисунке 2.7 представлена диаграмма прецедентов [9]. Также представлено описание прецедентов в нотации диаграмм последовательностей. Наиболее значимыми прецедентами в рамках текущей выпускной квалификационной работы являются прецеденты: загрузка структуры онтологии и загрузка библиотеки с реализованным поведением онтологии. Данные прецеденты доступны для пользователя, имеющего роль - преподаватель, и они являются ключевыми прецедентами, без которых невозможно полноценное функционирование адаптируемой системы, имеющей возможность генерировать оценочные средства. Таким образом, сначала пользователь создаст в системе онтологию, после чего реализует алгоритмы переходов между вершинами онтологии, далее получит возможность генерировать оценочные средства и составлять тесты для выполнения студентами.

Рисунок 2.7. Диаграмма прецедентов разрабатываемой системы

На рисунке 2.8 представлено описание прецедента «Заполнение структуры онтологии» в нотации диаграмм последовательностей.

Рисунок 2.8. Диаграмма последовательностей для прецедента «Заполнение структуры онтологии»

На рисунке 2.9 представлено описание прецедента «Загрузка алгоритмов генерации оценочных средств» в нотации диаграмм последовательностей.

Рисунок 2.9. Диаграмма последовательностей для прецедента «Загрузка алгоритмов генерации оценочных средств»

Описание остальных прецедентов в нотации диаграмм последовательностей представлено в приложении B.

3. Реализация системы

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

Обоснование выбора технологий, используемых для реализации системы

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

В качестве основного языка для разработки системы был выбран язык программирования C#. C# представляет собой высокоуровневый объектно-ориентированный язык разработанный компанией Microsoft. Данный язык прекрасно подходит как для реализации серверных приложений, так и для реализации клиентских приложений и интерфейсов. Помимо прочего, согласно рейтингу TIOBE, язык программирования C# входит в пятерку самых популярных языков программирования, что также положительно влияет на его выбор как основного языка для реализации разрабатываемой системы.

Для реализации серверной части системы была выбрана технология ASP.NET Web Api 2. Данная технология представляет собой фреймворк, позволяющий быстро и достаточно просто реализовать HTTP сервис, а также это идеальная платформа для разработки серверных приложений с использованием технологии REST API.

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

Взаимодействие с сервером осуществляется посредством HTTP запросов с использованием архитектурного стиля REST API. REST (Representational State Transfer, передача состояния представления) - архитектурный стиль взаимодействия компонентов приложения. Не существует официального стандарта для протоколов, построенных на базе REST, поскольку, в отличие от SOAP, REST является архитектурным стилем, но не протоколом [10]. За счет этого, приложения, построенные на базе архитектуры REST, могут достаточно гибко эволюционировать, подстраиваясь под новые требования. REST архитектура требует соблюдения следующих условий:

Модель клиент-сервер. Так как система является распределенной и состоит из серверной и клиентской частей, данное условие выполняется автоматически.

Отсутствие состояния. Сервер не должен хранить в себе состояние клиента. Данное условие также выполняется.

Кэширование. Система может кэшировать результат для ускорения расчетов. В данной работе указанное условие не является релевантным.

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

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

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

Реализация системы как распределенного приложения

Выше было упомянуто, что разрабатываемая система частично уже была реализована в процессе выполнения курсовых работ прошлых лет. На данном этапе работы необходимо разработать архитектуры системы. Система должна представлять собой клиент - серверное приложение для операционной системы Windows. Клиентское приложение будет взаимодействовать с серверы, которое в свою очередь будет взаимодействовать с базами данных. Данный подход обладает следующими преимуществами:

Наличие возможности удаленного назначения заданий для выполнения студентам, а также наличие возможности удаленного выполнения этих заданий.

Возможность масштабирования системы

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

Таким образом, была сформирована архитектура системы. На рисунке 3.1 представлена разработанная архитектура адаптируемой системы для оценки знаний студентов.

Рисунок 3.1. Архитектура системы для оценки знаний студентов

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

Взаимодействие между клиентом и сервером осуществляется посредством HTTP запросов.

Реализация модуля для настройки онтологии

Для того, чтобы система смогла начать генерировать оценочные средства в некоторой предметной области, нужно реализовать в ней онтологию этой предметной области. Пользователь должен выделить базовые понятия предметной области и сформировать из них онтологию. Далее необходимо спроецировать алгоритмы переходов между вершинами онтологии на её связи и реализовать эти алгоритмы, используя язык программирования платформы.Net Framework. Далее каким-то образом, необходимо передать онтологию в систему, чтобы возможность генерации начала функционировать. Система будет использовать эти алгоритмы для генерации оценочных средств, что позволит пользователю генерировать задачи в соответствии с реализованной онтологией, составлять из этих задач тесты и назначать эти тесты студентам для выполнения. Также система позволит просмотреть результаты выполнения тестов и сформировать отчет в MS Excel.

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

Рисунок 3.2. Интерфейс заполнения онтологии

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

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

На рисунке 3.3 представлена структура класса - шаблона. Экземпляр этого класса содержит свойства Items и Relations, и реализует методы, необходимые для генерации задания. Свойство Items представляет собой множество вершин онтологии, а свойство Relations представляет собой двумерный массив, который является отображением ориентированного графа онтологии. Используя свойство Relations, система сможет определить, какие элементы предметной области связанны между собой и вызвать соответствующие методы класса - шаблона. Листинг шаблона представлен в приложении С.

Рисунок 3.3. Сформированный шаблон класса для реализации генератора

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

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

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

Рисунок 3.4. Результат использования генератора

Каждое сгенерированное задание должно соответствовать некоторым требованиям системы. Оно должно содержать список вариантов ответов в первой строке и индекс правильного варианта ответа во второй. Далее следуют блоки входных и выходных данных. Таким образом, каждое сгенерированное задание представляет собой объект, содержащий свойства:

Ответ - массив вариантов ответа с указанным правильным.

Входные данные - текст входных данных задания. Будет отображаться в сгенерированном задании.

Выходные данные - текст выходных данных задания. Будет отображаться в сгенерированном задании.

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

На рисунке 3.5 представлен шаблон метода результатом которого является объект задания.

Рисунок 3.5. Шаблон метода для реализации алгоритма перехода между вершинами онтологии

Таким образом, входными данными сгенерированного задания является значение свойства Input объекта, возвращенного методом, выполненным в процессе генерации задания в первую очередь, а выходными - значение свойства Output объекта, возвращенного методом, выполненным в процессе генерации задания в последнюю очередь. При последовательном выполнении алгоритмов, в каждый следующий метод передается значение свойства Obj, в котором содержится объект, полученный при переходе из одной вершины онтологии в другую.

Тестирование системы

Разработанное приложение прошло три стадии тестирования: модульное, интеграционное и системное.

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

Рисунок 3.6. Предупреждение об отсутствии входных данных

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

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

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

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

На этапе интеграционного тестирования тестированию подвергались группы программных модулей. Всего было рассмотрено четыре группы:

Интерфейс преподавателя.

Интерфейс студента.

Интерфейс суперпользователя.

Интерфейс настройки генератора.

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

Рисунок 3.8. Исключительная ситуация. Преподаватель попытался назначить несуществующий тест

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

Рисунок 3.9. Результат генерации задания

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

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

На этапе системного тестирования производилось полное тестирование с использованием стратегии черного ящика и проверкой достаточности критериев [11]. Таблица тестов представлена в таблице 3.1.

Таблица 3.2. Набор тестов

Тест	Функция	Входные данные	Результат
T1	Добавление информации в БД	-	Ошибка
T2	Добавление информации в БД	string s	Элемент добавлен в БД
T3	Удаление информации из БД	-	Элемент удален из БД
T4	Редактирование информации в БД	-	Ошибка
T5	Редактирование информации в БД	string s	Элемент обновлен в БД
T6	Заполнение онтологии	-	Сформированный шаблон кода - генератора
T7	Загрузка библиотеки	*.dll	Библиотека успешно загружена и функционирует
T8	Генерация задания	string input string output	Сгенерированное задание
T9	Запрос по группе	All	Список всех студентов

Таблица 3.2 представляет собой проверку достаточности тестов по критериям черного ящика.

Таблица 3.2. Достаточность критериев

Функция	Входные данные	Т1	Т2	Т3	Т4	Т5	Т6	Т7	Т8	Т9
Добавление информации в БД	-	+
Добавление информации в БД	string s		+
Удаление информации из БД	-			+
Редактирование информации в БД	-				+
Редактирование информации в БД	string s					+
Заполнение онтологии	-						+
Загрузка библиотеки	*.dll							+
Генерация задания	string input string output								+
Запрос по группе	All									+
	Выходные данные
	Ошибка	+		+	+		+
	Корректный результат		+			+		+	+	+

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

Заключение

В результате выполнения работы была спроектирована, разработана и реализована адаптируемая система проверки знаний студентов. Цель, поставленная перед выполнением работы, была достигнута в полной мере. На данный момент разработанная система позволяет взаимодействовать преподавателям и студентам, посредством проведения проверки знаний студентов в части предметной области «теория графов». Также система является адаптируемой к различным предметным областям, поэтому преподаватель имеет возможность настроить ее под любую интересующую его предметную область.

Задачи, поставленные перед началом работы, были решены практически в полной мере. Был проведен анализ существующих решений и обзор литературы. Была разработана адаптируемая система для контроля знаний студентов. Данная система позволяет тестировать студентов в различных предметных областях, а ее работоспособность была проиллюстрирована реализацией фрагмента предметной области «теория графов». После было проведено тестирование разработанной системы.

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

Библиографический список

1. Яндекс Просвещение [Электронный ресурс] // Яндекс Просвещение: [сайт]. [2018]. URL: https://education.yandex.ru/about/

2. Coursera [Электронный ресурс] // Coursera: [сайт]. [2018]. URL: https://about.coursera.org/

3. Mathmaster [Электронный ресурс] // Mathmaster: [сайт]. [2018]. URL: http://mathmaster.org/

4. Fridenfalk, M. System for automatic generation of examination papers in discrete mathematics [Электронный ресурс] // System for automatic generation of examination papers in discrete mathematics [сайт] URL: https://files.eric.ed.gov/fulltext/ED562287.pdf (дата обращения: 07.05.2018).

5. Epp S. Student solutions manual and study guide, Discrete mathematics with applications. Boston, MA: Brooks/Cole; 2012. 661 c.

6. Tan, Y. Analyzing traffic problem model with graph theory algorithms [Электронный ресурс] // Analyzing traffic problem model with graph theory algorithms [сайт] URL: https://ieeexplore.ieee.org/document/7237137/ (дата обращения: 07.05.2018).

7. COCOMO 2 [Электронный ресурс] // COCOMO 2: [сайт]. [2018]. URL: http://www.softstarsystems.com/cocomo2.html

8. Пономарев, Ф.А., Чуприна, С.И. Многопользовательский адаптируемый редактор онтологий MULTONT 1.1 [Электронный ресурс] // Многопользовательский адаптируемый редактор онтологий MULTONT 1.1 [сайт] URL: http://vestnik.pstu.ru/get/_res/fs/file.pdf/6098/%CF%EE%ED%EE%EC%E0%F0%E5%E2+%D4.%C0.%2C+%D7%F3%EF%F0%E8%ED%E0+%D1.%C8.+%CC%ED%EE%E3%EE%EF%EE%EB%FC%E7%EE%E2%E0%F2%E5%EB%FC%F1%EA%E8%E9+%E0%E4%E0%EF%F2%E8%F0%F3%E5%EC%FB%E9+%F0%E5%E4%E0%EA%F2%EE%F0+%EE%ED%F2%EE%EB%EE%E3%E8%E9+MulTOnt+1.1file.pdf (дата обращения: 21.05.2018).

9. Введение в UML [Электронный ресурс] // ИНТУИТ: [сайт]. [2018]. URL: https://www.intuit.ru/studies/courses/1007/229/info

10. Руководство по REST API [Электронный ресурс] // Руководство по REST API: [сайт]. [2018]. URL: http://www.restapitutorial.ru

11. Плаксин М.А. Тестирование и отладка программ. М.: БИНОМ. Лаборатория знаний; 2007. 167 с.

Техническое задание

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования «Национальный исследовательский университет «Высшая школа экономики»
Факультет экономики, менеджмента и бизнес-информатики
Руководитель: к.т.н., доцент кафедры информационных технологий в бизнесе ________________А.Ю. Городилов ___ (подпись) (расшифровка)	Руководитель: студент образовательной программы «Программная инженерия» факультета экономики, менеджмента и бизнес-информатики НИУ ВШЭ - Пермь _________________Я.С. Лосев ____ (подпись) (расшифровка)
«__» ______________________ 20__ г.	«__» ______________________ 20__ г.
АДАПТИРУЕМАЯ СИСТЕМА ДЛЯ КОНТРОЛЯ ЗНАНИЙ СТУДЕНТОВ
НИУ ВШЭ - Пермь
Клиент-серверное приложение
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
На 10 листах
Действует с 22.01.2018
СОГЛАСОВАНО
Руководитель: к.т.н., доцент кафедры информационных технологий в бизнесе ________________А.Ю. Городилов______ (подпись) (расшифровка)
«__» ______________________ 20__ г.

Техническое задание на программу по ГОСТ 19.201-78

Введение

Наименование программы

Полное наименование: Адаптируемая система для проверки знаний студентов по теме «теория графов».

Краткое название: «Адаптируемая система для проверки знаний студентов по теме «теория графов»»

Краткая характеристика области применения

«Адаптируемая система для проверки знаний студентов по теме теория графов» -- это программный продукт, предназначенный как для помощи в обучении студентов, так и для помощи в работе преподавателей.

Основание для разработки

Основание для проведения разработки

Основанием для проведения разработки является договорённость между к.т.н., доцентом кафедры информационных технологий в бизнесе Алексеем Юрьевичем Городиловым именуемым в дальнейшем Заказчиком и со студентом НИУ ВШЭ в Перми Лосевым Яном Сергеевичем, именуемым в дальнейшем Разработчиком.