Программа автоматической проверки заданий по программированию



ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет компьютерных наук

Департамент программной инженерии

УТВЕРЖДАЮ

Академический руководитель образовательной программы «Программная инженерия»,

профессор департамента программной инженерии, канд. техн. наук

__________________ В.В. Шилов

«___» _____________ 2016 г.

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

Программа автоматической проверки заданий по программированию

по направлению подготовки 09.03.04 «Программная инженерия»

Научный руководитель:

доцент департамента программной инженерии,

к.т.н.

Р.З. Ахметсафина

_________________________

                         Оценка

_________________________

                    Подпись, Дата

Выполнил:

студент группы БПИ121

4 курса бакалавриата

образовательной программы «Программная инженерия»

А.А. Коренев

_________________________

                          Подпись, Дата

Реферат

Работа посвящена автоматизации процессов проверки заданий по программированию.

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

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

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

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

Работа содержит 63 страницы, 3 главы, 6 рисунков, 8 таблиц, 59 источников, 5 приложений.

Ключевые слова: автоматизация проверки, автоматическое оценивание заданий по программированию.

Abstract

Current work is dedicated to automation of processes of programming assignments assessment.

In this paper, we provide a list of criteria which can be used during the grading of assignments. We also observed various approaches of source code analysis and different approaches of testing of programs behavior, which includes software build from source code besides actual launching.

We designed an approach to automated checking of programming assignments, based on the examined approaches of software verification and software building and testing automation using continuous integration technique

The aim of the work is a program which provides an ability to support various criteria of assignment checking and also to perform assessment of such criteria. The program aims to reduce amount of time spent on manual assessment and to reduce the gap between submitting an assignment and its assessment.

The built solution uses a continuous integration tool called Jenkins and has a web-interface for interacting with a user.

The paper contains 63 pages, 3 chapters, 6 illustrations, 8 tables, 59 bibliography items, 5 appendices.

Keywords: assessment automation, checking automation, software assignments checking, software assignments assessment.

Основные определения, термины и понятия

  1. Компиляция – транслирование исходного кода программы в более низкоуровневый код (иногда машинный код).
  2. Критерий проверки – оцениваемый аспект сданной студентом работы.
  3. Непрерывная интеграция – методика, направленная на осуществление постоянной сборки изменяемого проекта с целью осуществления регрессионного и интеграционного тестирования.
  4. Оцениваемая работа – набор файлов, предоставляемый студентом, в качестве выполненного задания по программированию. Может представлять собой как исходные коды программы, так и скомпилированную программу.
  5. Подправило оценивания – правило оценивания отдельного критерия проверки работы.
  6. Правило оценивания – совокупность подправил оценивания и их коэффициентов в совокупности формирующая итоговое числовое значение оценки проверяемой работы.
  7. Преподаватель – участник оценивания, предоставляющий общие файлы для задания, тестирующие правила, а также составляющий правило оценивания задания.
  8. Регрессионное тестирование – методика тестирования программного обеспечения для обнаружения ошибок в уже протестированном исходном коде.
  9. Стандарт оформления кода (стиль программирования) – набор правил, соблюдаемых при написании программного кода.
  10. Статический анализ кода – анализ программного обеспечения, осуществляемый без запуска программы.
  11. Студент – участник оценивания, предоставляющий файлы для их оценки.
  12. Юнит-тестирование (модульное тестирование) – методика осуществления тестирования программного обеспечения с помощью тестирования отдельных изолированных модулей программы.

Оглавление

Введение

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

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

Помимо временных затрат при «ручной» проверке возникает целый ряд проблем:

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

  1. Изучить распространенные аспекты проверки заданий по программированию;
  2. Провести анализ подходов к автоматизации проверки корректности работы программы;
  3. Рассмотреть подходы к автоматизации анализа программного кода;
  4. Рассмотреть подходы обнаружения плагиата в текстовых документах и программных кодах;
  5. Выбрать подходы автоматизации проверки заданий по программированию на основе проведенного анализа;
  6. Разработать архитектуру программы автоматизации проверки работ по программированию;
  7. Разработать программу в соответствии с разработанной архитектурой;
  8. Провести тестирование и отладку разработанной программы;
  9. Разработать техническую документацию.

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

Глава 1. Предметная область

  1. Критерии проверки задания

Проверка заданий по программированию представляет собой задачу анализа программ на предмет соответствию ряду критериев. Программы, в свою очередь, могут быть написаны с использованием компилируемых или интерпретируемых [1] языков программирования. Наличие двух разных типов языков предполагает, что программы могут быть представлены как минимум в двух видах:

Как правило, основным критерием правильности программы является корректность ее исполнения и/или корректная обработка входных данных. Однако со временем появились новые критерии проверки. Зачастую создание любой программы, каким-либо образом позволяющей решить поставленную проблему, является недостаточным. Проверяющего могут заинтересовать и другие аспекты работы программного обеспечения, такие как время исполнения и потребляемые ресурсы, также могут выдвигаться требования к исходному коду программы, соответствующие лучшим практикам разработки ПО. Можно выделить две группы критериев проверки программы:анализисходного кодаи исполнение программы.

Под анализом исходного кода имеется в видустатический анализ кода (staticcodeanalysis), то есть анализ программного обеспечения без его исполнения. Перечислим возможные критерии анализа исходного кода заданий:

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

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

Тем не менее, существует ряд инструментов, которые решают похожие задачи, среди которых можно выделить три наиболее подходящих и популярных инструмента:ejudge [4],Peach3 [5] иWeb-CAT [6].

  1. ejudge является системой проведения онлайн соревнований по программированию и представляет собой мощный инструмент, позволяющий компилировать и запускать программы на исходном коде большинства популярных языков программирования.ejudge также способен осуществлять проверку правильности программы, используя для ввода-вывода данных командную строку. Также существуют аналоги, такие какcodeforces [7],Timus [8], предоставляющие схожий функционал проверки программного обеспечения.
  2. Peach3 – система управления обучением, позволяющая компилировать и тестировать ПО на языкеJava с помощью юнит-тестирования. Некоторые версииPeach3 предоставляют возможность проверки исходного кода на плагиат, однако такие версии продукта не являются свободно распространяемыми. Данная система предоставляет возможность проверки исходного кода на соответствие стилю программирования на языкеJava.
  3. Web-CAT предоставляет возможности автоматизированной системы оценивания исходного кода по критерию полноты тестирования этого кода. Одним из основных плюсов данного инструмента является его расширяемая архитектура. Тем не менее, активная разработкаWeb-CAT не ведется уже с 2012 года.

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

  1. Обзор подходов и инструментов

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

  1. Проверка исходного кода на плагиат

Чтобы провести анализ подходов поиска плагиата в наборе документов, необходимо выделить ряд изменений исходного текста программы, к которым должен быть устойчив эффективный алгоритм [9]:

  1. изменение комментариев кода;
  2. изменение количества переносов строк, пробелов и отступов;
  3. изменение типов переменных или возвращаемых значений функций на аналогичные (что может незначительно сказаться на выполнении программы. Например, снижение или повышение точности в переменных с плавающей запятой);
  4. переименованиепеременныхифункций;
  5. замена строковых и символьных констант;
  6. перестановкаблоков кода;
  7. добавление «ненужных» блоков кода (т.е. таких, которые практически не влияют на исполнение программы).

Среди наиболее распространенных подходов обнаружения плагиата можно выделить следующие [10]:

Существует довольно много инструментов для поиска плагиата в работах на естественном языке, многие из которых являются бесплатными и доступны в сети Интернет. Более того, многие из таких инструментов ищут плагиат с помощью нахождения точных копий участков кода, что не всегда эффективно. Намного меньше инструментов, которые учитывают специфику программных кодов и многих описанных выше типов изменений. Наиболее популярными и близкими к выделенным критериям инструментами являютсяMOSS (StanfordUniversity) [11] иJPlag (KarlsruheInstituteofTechnology) [12]. Но эти инструменты не чувствительны к некоторым из перечисленных ранее типов изменений исходных работ, а именно изменениям типов (3) и (5).

Одним из наиболее популярных алгоритмов для поиска плагиата в текстовых документах являетсяалгоритм поиска и сравнения отпечатков[13,14]. Данный алгоритм относится к типу анализаторов строковых представлений программного кода и имеет ряд сильных сторон:

  1. высокаяскорость работы;
  2. устойчивость к перестановкам частей документа [15];
  3. относительнопростая реализация;
  4. устойчивость к шумам (т.е. вставке дополнительных участков текста в исходный документ) [15].

Использование данного алгоритма, однако, не решает задачу обнаружения плагиата полностью, а решает только проблемы, связанные с изменениями типов (6) и (7) [15]. Алгоритм находит совпадающие части в парах документов, но чувствителен к изменениям типов (1) - (5).

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

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

  1. Проверка исходного кода на возможность компиляции и проверка синтаксиса на корректность

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

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

Существует множество инструментов и онлайн сервисов для проверки интерпретируемого программного кода на корректность, среди которых можно выделитьPEP 8 (Python) [16], PHP Code Checker [17],JSLint (JavaScript) [18] и многие другие.

  1. Проверка исходного кода на соответствие стандартам оформления

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

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

Можно выделить наиболее популярные инструменты:IntellijIDEA (Java) [19],PMD (Java) [20],Clang (C,C++,Objective-C) [21],PVS-Studio (C,C++,C++11,C#) [22] и многие другие.

  1. Компиляция исходного кода

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

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

javac YourJavaSourceFile.java

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

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

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

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

  1. Юнит тестирование

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

Вследствие широкой распространенности было создано значительное количество инструментов для осуществления данного типа тестирования. Одним из примеров таких фреймворков является семействоxUnit [3], поддерживающее большинство популярных языков программирования. Помимо этого, юнит-тестирование является встроенным в качестве одного из этапов сборки проекта при использовании некоторых фреймворков автоматической сборки (например,ApacheMaven). Тем не менее, инструменты тестирования позволяют запускать тесты и без использования подобных фреймворков сборки.

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

  1. Взаимодействие с программой через командную строку и файлы

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

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

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

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

  1. Ограничение используемых ресурсов

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

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

Однако при юнит-тестировании могут возникнуть некоторые проблемы:

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

Наиболее популярными инструментами непрерывной интеграции являются:Jenkins (Hudson) [27],TeamCity (JetBrains) [28],Bamboo (Atlassian) [29] и другие.

Выводы по главе

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

Глава 2. Алгоритмы проверки заданий по программированию

  1. Алгоритм работы статических анализаторов кода

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

Как правило, статический анализ кода предполагает анализ исходного текста программы для построения определенной модели на его основе. Рассмотрим наиболее известные модели [30]:

Рисунок 1. Визуализация абстрактного синтаксического дерева на примере программного кода

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

  1. Алгоритм поиска плагиата в наборе документов
    1. Генерализация исходного кода

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

Шаги данного алгоритма выполняются строго в порядке их описания.

Для устранения различий между документами с различными комментариями (изменение (1)) все комментарии исключаются из документов.

Для устранения различий между документами с измененными типами возвращаемых значений функций или типов переменных (изменение (3)) все возвращаемые типы функций и типы переменных изменяются по следующим правилам:

  1. Все названия целочисленных типов и их классов-оберток (таких как «int», «Integer», «long», «Long», «byte», «Byte», «char», «Character» и др.)  меняются на «int».
  2. Все названия типов чисел с плавающей точкой и их классов-оберток (такие как «double», «Double», «float», «Float») меняются на «flt».
  3. Все остальные названия типов вJava меняются на «ref».

Для устранения различий между документами с измененными названиями переменных и функций (изменение (4)) все названия переменных и функций изменяются по следующим правилам:

  1. Все имена функций при вызове и декларации изменяются на «fun».
  2. Все объявления переменных с определенным типом изменяются на название этого типа. Пример: строка «intx = 0» на данном этапе изменится на «int = 0», а строка «flty» изменится на «flt».

Для устранения различий между документами с различным количеством переносов строк, пробелов и отступов (изменение (2)) все переносы строк, пробелы и отступы исключаются из документов.

Для устранения различий между документами с различными строковыми и символьными константами (изменение (5)) проводится замена всех строковых констант на строку «str» и всех констант типаchar на строку «chr».

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

  1. Алгоритм поиска и сравнения отпечатков

Алгоритм поиска и сравнения отпечатков документов является одним из наиболее популярных алгоритмов для поиска плагиата. Он основан на выборе множества небольших участков документа в качестве отпечатка этого документа и сравнения этого отпечатка с другими [13,14]. В данной работе этот алгоритм применяется на генерализированных исходных кодах.

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

Введем определение функции ,которая возвращает детерминированное (при одинаковых входных параметрах всегда возвращается одно и то же значение) целочисленное равномерно распределенное значение в определенном диапазоне значений, где– подстрока документа [15]. Результат данной функции мы будем называтьхэшем.

Введем определениекак последовательной подстроки документа длинойсимволов [15].

  1. Поиск отпечатков

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

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

где  – целое простое неизменяемое в ходе алгоритма число.

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

Выбранный набор хэшей и является отпечатком документа.

Рисунок 3. Схематическое представление вычисления отпечатка на строковой последовательности “adorunrunrun

  1. Сравнение отпечатков документов

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

Назовем последовательности хэшейи отпечатками документов  и  соответственно. Определим значениекак степень «присутствия» документав документепо формуле [31]:

Далее можно определить значение максимального «присутствия»междудокументамиипо формуле, которая выводится из предыдущей формулы для расчета :

Для расчета данного значения необходимо быстро вычислять значение пересечения двух наборов хэшей. Для этого можно отсортировать оба набора (алгоритмическая сложность ),где– количество сортируемых элементов) и затем, используяалгоритм соединения слиянием сортированных списков[32], вычислить повторяющиеся значения хэшей и их количество (алгоритмическая сложность ,гдеи– размеры наборов хэшей).

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

  1. Поиск совпавших областей в парах документов

После нахождения всех значений часть значений отсеиваются по определенному числовому порогу, чтобы исключить неверные совпадения, значение которого принадлежит отрезку [0.0, 1.0). Так как заданное на входе алгоритма значениеk(длина строки, по которой вычисляется хэш) является длиной подстроки, которая при совпадении с большой долей вероятности является заимствованной из другого документа подстрокой [15], пороговое значение должно быть сравнительно небольшим. В данной программе значение равно , что показывает хорошие результаты в отношении отсеивания неверных совпадений.

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

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

Позиции совпавших областей запоминаются и записываются в исходных документах.

  1. Описание параметров алгоритма

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

  1. – длина подстроки, по которой высчитывается значение функции . Значение  должно задавать длину строки, при которой множественное совпадение различных строк длиныс другим документом будет считаться подозрительным [15]. Все обнаруженные совпадающие подстроки длиной меньшене будут расценены алгоритмом как плагиат. С учетом генерализации исходного кода, которая сводит анализируемый документ практически до взаимодействия трехсимвольных переменных с математическими операторами и другими конструкциями языкаJava, берется значениеравное . Это значение больше, чем наиболее длинные генерализированные конструкции, которые зачастую встречается в данном языке.
  2. длина «окна» в рамках которого необходимо выбрать хэш, чтобы он вошел в отпечаток документа. Значение  варьируется в зависимости от размера документа, но не может быть менее 15 и более 35. Наименьшее значение  выбирается в случае, если документ имеет размер менее 8000 символов. Если документ больше, то можно увеличить значение , чтобы уменьшить размер получаемых отпечатков для ускорения работы алгоритма. Оценка верхней границы параметра  получена экспериментально. При ее превышении в отпечаток документа не попадает значительная его часть, и плагиат может быть не выявлен.
    1. Критерии оцениваемой работы

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

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

  1. Роли

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

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

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

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

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

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

  1. Разграничение доступа к результатам

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

  1. Формирование итоговой оценки

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

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

Оценка за работу студента может принимать значение от 0 до 100 баллов. Формула вычисления оценки устанавливается преподавателем.

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

,

где  – подправило с индексом ,  – множество индексов блокирующих правил, а  – итоговая оценка.

Подправило же применяется для оценки одного конкретного критерия. Значение оценки подправила выражается в виде числа от 0 до 100. Возможные типы подправил, применяемых в различных случаях представлены в табл. 1.

Таблица 1

Типы подправил оценивания

Тип подправила

Правило составления оценки

Долевое

Долевое с порогом

Штрафное

Штрафное с порогом

  1. Этапы выполнения проверки задания

Определим упорядоченный список этапов проверки заданий:

  1. Работа загружена студентом;
  2. Выполняется проверка правил задания, заданных преподавателем. Определяется набор проверок, необходимых для проведения тестирования;
  3. Основываясь на определенных в шаге 2 проверок, начинается параллельная проверка статического анализа кода за исключением проверки на плагиат (даже если она была указана в качестве правил, заданных преподавателем), а также проверка исполнения программы;
    1. Используя определенный в шаге 2 набор необходимых проверок исходного кода, начинается статический анализ кода. Проверки могут быть запущены параллельно по причине независимости их результатов. Для увеличения скорости проверки алгоритмы могут быть объединены, но это является частным случаем;
    2. Используя определенный в шаге 2 набор необходимых проверок для тестирования поведения программы, начинается тестирование, состоящее из следующих шагов:
      1. Загруженные файлы студентом (studentfiles) и файлы, предоставленные преподавателем, для проведения тестирования (secret files) объединяются в один проект;
      2. В случае, если программа представлена в виде исходного кода на компилируемом языке, начинается сборка проекта. Если проект не может быть удачно собран, проверка прерывается, и все последующие фазы, которые планировалось провести для тестирования поведения программы считаются провалившимися;
      3. В случае, если необходимо провести юнит-тестирование проекта, программа запускается вместе с юнит-тестами, предоставленными в файлах проверки (secretfiles);
      4. В случае, если необходимо провести тестирование с помощью проверки взаимодействия программы с командной строкой, программа запускается и в нее передаются данные, предоставленные в файлах проверки (secretfiles). Ожидаемый выход программы также представлен в файлах проверки, который используется для определения корректного поведения программы;
    1. В случае завершения всех проверок (за исключением плагиата), определяется правило (набор подправил), формирующих оценку;
    2. После определения правила оценивания, начинается формирование оценки – применение подправил к значениям метрик, полученным в ходе тестирования различных критериев;
    3. После применения правила оценивания, полученная оценка запоминается. Далее генерируется три вида отчета, основанных на настройках доступа к отчету о проверке студентом: отчет для просмотра студентом до окончания приема работ, отчет для просмотра студентом после окончания приема работ, отчет для просмотра преподавателем.

Схематическое представление последовательности этапов проверки продемонстрировано на рис. 4.

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

Рисунок 4. Схематическое представление этапов проведения проверки задания по программированию

Выводы по главе

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

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

Глава 3. Программная реализация

  1. Модель данных

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

  1. Курс – сущность, используемая для группировки набора заданий. Данная сущность может быть ассоциирована с дисциплиной, которая содержит набор заданий.
  2. Задание – сущность, используемая для представления задания по программированию. Задание может содержать в себе описание, предоставлять общие файлы (commonfiles) и файлы для проведения оценки (secretfiles), а также иметь крайний срок приема работ на проверку. Задание должно содержать в себе набор подправил оценивания, по которому осуществляется формирование итоговой оценки.
  3. Подправило оценивания – сущность, используемая для отображения определенного аспекта работы, которое возможно оценить. Правило оценивания содержит определенный вес, который отображает, насколько сильно данное правило влияет на формирование оценки.
  4. Попытка– сущность, используемая для представления оцениваемой работы студента. Программа должна предоставить оценку для каждого правила оценивания при осуществлении попытки. Попытка ассоциирована исключительно с одним студентом, загрузившим файл с оцениваемой программой.
    1. Архитектура приложения

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

  1. Сервер оценки. Данный сервер является основным модулем, участвующим в ходе проверки. Основные функции сервера:
    • Регистрация пользователей, а также аутентификация их в системе;
    • Предоставление общей информации о доступных курсах и заданиях;
    • Предоставление информации о результатах проверки работ;
    • Осуществление оценки попытки сдачи определенного задания;
    • Регистрация новых курсов, заданий;
    • Загрузка файлов в файловое хранилище.
    1. Веб-интерфейс. Данный модуль предоставляет пользователю интерфейс, основанный на веб-страницах, чтобы осуществлять взаимодействие с программой. Модуль взаимодействует с сервером оценки в качестве интерфейса к предоставляемому сервером функционалу;
    2. Файловое хранилище – модуль, предоставляющий возможность хранить загруженные файлы, а также иметь к ним доступ через протоколHTTP.
    3. Оценивающие сервисы (оценщики) – совокупное название всех модулей, непосредственно осуществляющих проверку загруженных работ по критериям;
    4. База данных– хранилище данных учетных записей пользователей, информации о курсах, заданиях, правил (подправил) оценивания, а также результатов проверок;
    5. Прокси сервер– сервер, обрабатывающий все входящие запросы пользователя. Перенаправляет запросы в различные модули программы.

Рисунок 5. Изображение архитектуры программы

  1. Сервер оценки

Сервер оценки является ключевым модулем данной программы. Данный модуль представляет собой приложение, написанное в соответствии с паттерномMVC (Model-View-Controller) [33]. Контроллерами (Controller) выступают классы, осуществляющие поддержкуREST интерфейса. ПоддержкаMVC паттерна предоставляется фреймворкомSpringMVC [34], а сам сервер разрабатывался с использованием фреймворкаSpringBoot [35].

  1. REST интерфейс

Модуль сервера оценки предоставляет ряд различных контроллеров, которые позволяют взаимодействовать с данным модулем посредством протоколаHTTP. Каждому контроллеру ставитсяHTTP метод посылаемого обрабатываемого запроса, а такжеURL адрес, по которому будет осуществлен запрос. Основные контроллеры перечислены в табл. 2:

Таблица 2

ОсновныеREST контроллеры сервера оценки

URLадрес

HTTPметод запроса

Параметры

Описание

1

/api

GET

Нет.

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

2

/api/{courseShortName}

GET

Параметр пути- courseShortName.

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

3

/api/assignments/getAssignmentById

GET

assignmentId –уникальный идентификатор задания.

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

4

/api/login

POST

username – имя пользователя,password – пароль пользователя.

Контроллер, осуществляющий вход пользователя в систему.

5

/api/logout

POST

Нет.

Контроллер, осуществляющий выход из системы.

6

/api/assignments/getAllResultsById

GET

assignmentId – уникальный идентификатор задания.

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

7

/api/assignments/getAttemptsById

GET

assignmentId –уникальный идентификатор задания.

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

8

/api/assignments/triggerAssignmentById

POST

assignmentId – уникальный идентификатор задания,inputFile – загружаемый файл.

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

  1. Формат данных

При использовании запросов к серверу могут быть использованы параметрыHTTP запроса (например, «/api/assignments/getAssignmentById»). ПараметрыHTTP запроса представлены в виде строк. Такие строки могут представлять собой числа, имена или объекты в форматеJSON [36].

Данные ответов от сервера представлены в форматеJSON и представляют собой объекты, которые могут иметь вложенную структуру.

  1. База данных

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

Диаграмма реляционных таблиц базы данных представлена на рис. 6.

Рисунок 6. Схема реляционной базы данных

В качестве реляционной базы данных был выбран инструментPostgreSQL версии 9.5.1.

При использовании фреймворкаSpring для взаимодействия с базой данных было принято решение использоватьSpringDataJPA [37] – инструмент, позволяющий связывать реляционные базы данных с объектно-ориентированными моделями данных. В частности,SpringDataJPA является надстройкой, упрощающей работу с фреймворкомHibernate [38], который предоставляет схожие функции.

Для конфигурации сущностей, которые необходимо хранить в базе данных использовались аннотацииJavaPersistenceAPI [39], которые определяют, в каком виде будут храниться объекты в базе данных.

  1. Система учетных записей

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

  1. Аутентификация

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

Аутентификация происходит посредством интерфейса «/api/login», требующего имя учетной записи (представленного в виде адреса электронной почты), а также пароль. В случае успешного входа, сервер посылает «куки» (cookie) браузеру [40], с которого был послан запрос, которые используются при дальнейших запросах.

Программа позволяет осуществить регистрацию нового пользователя с помощью интерфейса «/api/registration», доступного всем пользователям. Регистрация требует от пользователя предоставления следующих данных:

  1. Имя учетной записи в виде адреса электронной почты. Данное имя будет использовано при входе в систему.
  2. Пароль, содержащий не менее 6 и не более 20 символов. Пароль должен состоять из цифр и букв латинского алфавита в различном регистре. Необходимо, чтобы пароль содержал как минимум одну цифру, одну букву нижнего регистра и одну букву верхнего регистра. Использование различных регистров и цифр значительно увеличивает количество возможных комбинаций паролей, что усложняет задачу взлома учетной записи с помощью перебора. Ограничения на минимальную длину пароля также повышает надежность, так как подразумевает  различных комбинаций для пароля наименьшей возможной длины, что делает практически невозможным перебор всех комбинаций пароля даже такого размера.
    1. Роли

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

Таблица 3

Роли пользователей программы

Роль

Роль в контексте алгоритмов оценивания

Права и ограничения

ROLE_STUDENT

Студент

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

ROLE_PROFESSOR

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

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

ROLE_ADMIN

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

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

При регистрации пользователя с помощью интерфейса «/api/registration» ему присваивается роль «ROLE_STUDENT».

Поддержка использования различных ролей пользователей поддерживается с помощью фреймворкаSpringSecurity [41].

РазграничениеREST интерфейсов по ролям пользователей представлено в табл. 4.

Таблица 4

Соответствие ролей и основныхREST интерфейсов

URLадрес контроллера

Роли, имеющие доступ

/api

Авторизация не требуется

/api/{courseShortName}

Авторизация не требуется

/api/assignments/getAssignmentById

Авторизация не требуется

/api/login

Авторизация не требуется

/api/logout

ROLE_STUDENT, ROLE_PROFESSOR, ROLE_ADMIN

/api/assignments/getAllResultsById

ROLE_PROFESSOR, ROLE_ADMIN

/api/assignments/getAttemptsById

ROLE_STUDENT

/api/assignments/triggerAssignmentById

ROLE_STUDENT

  1. Регистрация на курсе

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

Для решения данной проблемы используется подход регистрации пользователей на курсе. Данная регистрация может быть применена к пользователям с ролями «ROLE_STUDENT» или «ROLE_PROFESSOR». Каждый пользователь может быть участником определенного курса, при этом данная информация сохраняется в базе данных.

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

  1. «/api/assignments/getAllResultsById» - проверка регистрации преподавателя на данном курсе;
  2. «/api/assignments/getAttemptsById» - проверка регистрации студента на данном курсе;
  3. «/api/assignments/triggerAssignmentById» - проверка регистрации студента на данном курсе.
    1. Сохранение пароля пользователя

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

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

Для решения данной проблемы используется подход хэширования пароля с использованием «соли» (salt) [44] - случайной последовательности символов, используемой при хэшировании наряду с изначальным паролем. Соли, при этом, могут храниться в открытом виде вместе с хэшированными паролями, так как даже в случае их утечки, злоумышленнику придется подбирать пароль с заданной солью путем перебора, что делает расшифровку пароля практически невозможной.

В данной программе используется функцияbcrypt [45] со случайно сгенерированной «солью» длиной в 10 символов. В базе данных хранятся «соль», а также хэшированный пароль.

  1. Оценка работы
    1. Поддерживаемые критерии

Существует определенный набор критериев, которые могут быть использованы при проверке программы. В реализации программы была добавлена поддержка двух языков программирования:Java версии 1.7 иPython версии 2.7.11. Эти два языка были выбраны по причине своей большой распространенности в академическом мире, а также потому что являются представителями различных классов –Java является компилируемым языком (в байткод),Python не компилируется, а передается интерпретатору в виде исходного кода.Далее описаны поддерживаемые критерии.

Поддерживаемые критерии для языкаJava версии 1.7 представлены в табл. 5.

Таблица 5

Поддерживаемые критерии для языкаJava версии 1.7

Название критерия

Тип критерия

Формат оцениваемой работы

Параметры критерия

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

COMPILE (Компиляция)

Анализ исходного кода, индивидуальная проверка.

Исходный код.

Отсутствуют.

Долевое (100 – компиляция успешна, 0 – компиляция неуспешна).

UNIT_TESTS (Юнит-тестирование с помощью фреймворкаJUnit)

Исполнение программы, индивидуальная проверка.

Скомпилированная программа.

Время выполнения всех юнит-тестов.

Долевое, долевое с порогом, штрафное, штрафное с порогом

CHECK_STYLE (Проверка стилей с помощью инструментаPMD)

Анализ исходного кода, индивидуальная проверка.

Исходный код.

В файлах проверки – файлы конфигурации инструментаPMD (rulesets).

Штрафное, штрафное с порогом

RUN_CONSOLE (Тестирование с помощью командной строки)

Исполнение программы, индивидуальная проверка.

Скомпилированная программа.

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

Долевое, долевое с порогом, штрафное, штрафное с порогом

PLAGIARISM (Проверка работы на плагиат)

Анализ исходного кода, групповая проверка

Исходный код.

Отсутствуют.

Долевое (100 – работа не считается списанной, 0 – работа считается списанной).

Поддерживаемые критерии для языкаPython версии 2.7.11 представлены в табл. 6.

Таблица 6

Поддерживаемые критерии для языкаPython 2.7.11

Название критерия

Тип критерия

Формат оцениваемой работы

Параметры критерия

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

UNIT_TESTS (Юнит-тестирование с помощью фреймворка, встроенным в языкPython)

Исполнение программы, индивидуальная проверка.

Исходный код.

Время выполнения всех юнит-тестов, название файла с точкой входа для начала юнит-тестирования.

Долевое, долевое с порогом, штрафное, штрафное с порогом

CHECK_STYLE (Проверка стилей с помощью инструментаPEP8)

Анализ исходного кода, индивидуальная проверка.

Исходный код.

Отсутствуют.

Штрафное, штрафное с порогом

RUN_CONSOLE (Тестирование с помощью командной строки)

Исполнение программы, индивидуальная проверка.

Исходный код.

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

Долевое, долевое с порогом, штрафное, штрафное с порогом

  1. Концепция оценщиков

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

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

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

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

Асинхронное взаимодействие предполагает посылку запросов к удаленным сервисам и ожидание срабатыванияфункции обратного вызова (callback) [46]. Для того, чтобы понять, к какому запросу изначально относится текущий обратный вызов, запросу присваивается случайный идентификатор этого запроса, а также регистрируем этот идентификатор как ожидаемый. В свою очередь ожидается, что пришедший идентификатор запроса от оценщика будет совпадать с ожидаемым. Генерация случайного идентификатора осуществляется с помощью встроенного в языкJava классаSecureRandom [47], который предоставляет возможность генерации криптографически сильных случайных чисел. Длина полученной строки равна 30 символам, где каждый символ принимает одно из 37 возможных значений, что подразумевает различных комбинаций. По этой причине совпадение этих идентификаторов является крайне маловероятным для всех практических значений количества проверяемых работ.

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

  1. Взаимодействие с Jenkins

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

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

В роли сервисов оценщиков выступали так называемыепроекты (job) – сценарии процесса сборки. Для каждого существующего оценщика существует свой проект, который может быть запущен сервером оценки. Опишем общий сценарий каждого такого проекта:

Перечисление всех такие проектов, их соответствие проверяемым критерием, а также более подробное описание их работы представлено в табл. 7.

Таблица 7

Соответствие проектов инструментаJenkins и поддерживаемых критериев

Название проекта

Язык

Оцениваемый критерий

Описание работы

java-compile

Java 1.7

COMPILE

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

java-unit-tests

Java 1.7

UNIT_TESTS

Скомпилированная программа и файлы проверки копируются в папку проекта, запускается скрипт на языкеGroovy, осуществляющий запуск фреймворка юнит-тестирования. Затем результаты отправляются в сервер проверки.

java-run-console

Java 1.7

CONSOLE

Скомпилированная программа и файлы проверки копируются в папку проекта, запускается скрипт на языкеGroovy, осуществляющий запуск программы с консольным вводом. Затем результаты отправляются в сервер проверки.

java-checkstyle

Java 1.7

CHECK_STYLE

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

python-unit-tests

Python 2.7.11

UNIT_TESTS

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

python-run-console

Python 2.7.11

CONSOLE

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

python-checkstyle

Python 2.7.11

CHECK_STYLE

Исходные файлы работы студента, а также файлы проверки копируются в единую папку, запускается инструментPEP8, поставляющийся внутри дистрибутива языкаPython. Затем результаты отправляются в сервер проверки.

Взаимодействие с инструментомJenkins осуществляется с помощьюREST интерфейса, что позволяет отправлять запросы автоматически. Каждый вызов сборки проекта (т.е. запуска оценщика) содержит следующие параметры:

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

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

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

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

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

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

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

Таблица 8

Описания содержания папки «config»

Название папки внутри «config»

Использующие оценщики

Комментарий

pmd

java-checkstyle

Папка «pmd» должна содержать файлы форматаXML, представляющие собой конфигурации правил для инструментаPMD (rulesets).

console

java-run-console, python-run-console

Папка «console» должна содержать файлы расширения .txt, которые используются для передачи данных с помощью консольного ввода при запуске программы. Файл с входными данными должен иметь названиеn.txt, файл с ожидаемыми выходными данными должен иметь названиеn.txt, гдеn – номер проводимого теста. Также в папке «console» должны содержаться файлы «constraints» с информацией о требованиях к потребляемой памяти и затраченному времени.

  1. Безопасность выполнения стороннего кода

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

Выделим типы атак, которые могут быть использованы программой:

  1. Обращение к дисковому пространству – чтение, удаление, модифицирование файлов;
  2. Максимально возможная загрузка вычислительной мощности процессора (создание большого количества потоков, совершающих непрерывные вычисления);
  3. Максимально возможная загрузка оперативной памяти;
  4. Создание вечно работающих программ;
  5. Выполнение директив командной строки.

Для устранения атак типа (1), (2), (3) и (5) используются средства операционной системыlinux, а также сторонние программыulimit иcpulimit, позволяющие запустить программу от лица определенного пользователя, а также выставить ограничения на потребляемые память и частоту процессора.

Чтобы решить проблему вечно работающих программ (тип атаки (4)) используется замер времени при запуске программы, и после достижения порогового значения процесс программы принудительно убивается с помощью средствlinux.

  1. Оценщик для поиска плагиата

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

Для реализации алгоритма генерализации кода было использовано абстрактное синтаксическое дерево для поиска конструкций, которое необходимо изменить. Для построения абстрактного синтаксического дерева использовалась библиотекаjavaparser [48]. Для реализации алгоритма поиска и сравнения отпечатков использовались стандартные средства языкаJava, а также был реализован алгоритм кольцевого-хэша для эффективного подсчета набора хэшей документа.

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

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

Сервис данного оценщика является внутренним модулем и доступен с помощьюREST интерфейса, реализованным с помощью фреймворкаJetty[49]. Сервис работает на сервере приложенийProjectGrizzly [50].

  1. Хранение файлов

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

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

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

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

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

При этом стоит учесть, что значение ссылок на файлы играет немаловажную роль в ограничении доступа. Например, если бы какой-либо файл студента с идентификационным номером 1 хранился по адресу «SERVER_URL:/1/some_file.txt», то можно было бы предположить, по каким адресам хранятся файлы других пользователей. По этой причине в качестве ссылки на файл использовалась случайная последовательность символов.

Генерация последовательность символов осуществляется с помощью классаSecureRandom на языкеJava. Длина последовательности равна 30 символам, и каждый символ может принимать одно из 37 возможных значений, что подразумевает  различных комбинаций.

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

  1. Веб интерфейс программы

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

В качестве фреймворка для отображения визуальных элементов был выбран популярный, на момент 2016 года,TwitterBootstrap [51], включающий в себяHTML иCSS шаблоны, а также расширения на языкеJavaScript. Помимо этого, были использованы плагины, расширяющие возможности данного фреймворка:BootstrapFileInput 4.3.2 [52],BootstrapNotify 3.1.3 [53].

  1. Взаимодействие с сервером оценки

С помощью веб-интерфейса, пользователь отправляет запросы на сервер оценки, для взаимодействия с программой. Все запросы на сервер являютсяAJAX-запросами [54], что позволяет отправлять множество запросов без перезагрузки страницы, а также обрабатывать ответы от сервера. Для осуществления такого типа запросов используется популярная библиотека jQuery 2.1.4 [55].

Для аутентификации пользователя в системе используются «куки» (cookies), которые отправляет сервер при входе в систему. После входа сохраненные «куки» отправляются внутри каждого запроса, и программа проверяет их корректность. В случае, если «куки» не представлены или устарели, программа просит пользователя авторизоваться.

В качестве ответов от сервера могут приходить объекты в форматеJSON, поддержка которого встроена в языкJavaScript.

  1. Система шаблонов

В следствие того, что данная программа не занимается генерацией разметки на стороне сервера, используется подход веб-шаблонов, встроенных в статическую разметку. Иными словами, генерация динамических страниц веб-страницы, осуществляется непосредственно на стороне пользователя с помощью средств языкаJavaScript. Для поддержки веб-шаблонов используется библиотекаHandleBars 4.0.4 [56], позволяющая создавать разметку на основе прописанных шаблонов и поданных входных данных.

  1. Сервер nginx

Так как программа состоит из множества модулей, с которыми необходимо взаимодействовать пользователю, хорошей практикой является создание единой точки входа для всех запросов пользователя. Для решения этой проблемы можно использовать прокси-сервер, в роли которого в данной программе выступает веб-серверnginx [57].

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

При реализации программы серверnginx использовался для обеспечения следующих функций:

Использование данного сервера также позволяет легко настроить кластерное решение, где многие сервера представлены во множественном виде, и необходимо распределить нагрузку между ними [59], что может потребоваться в будущем.

Выводы по главе

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

Заключение

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

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

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

  1. Изучены распространенные аспекты проверки заданий по программированию;
  2. Проведен анализ подходов к автоматизации проверки корректности работы программы, анализа программного кода, а также обнаружения плагиата в текстовых документах и программных кодах;
  3. Выбраны подходы автоматизации проверки заданий по программированию на основе проведенного анализа;
  4. Разработана архитектура программы автоматизации проверки работ по программированию;
  5. Разработана программа в соответствии с разработанной архитектурой.

В качестве направлений дальнейшей работы могут выступать:

Список источников

  1. CompilationandInterpretation [Электронный ресурс] //URL:http://www.cs.unc.edu/~olivier/comp524/Lecture02.pdf (Дата обращения: 19.03.2016, режим доступа: свободный).
  2. GoogleJavaStyle [Электронный ресурс] //URL:https://google.github.io/styleguide/javaguide.html (Дата обращения: 13.04.2016, режим доступа: свободный).
  3. MartinFowler -Xunit [Электронный ресурс] //URL:http://www.martinfowler.com/bliki/Xunit.html (Дата обращения: 13.04.2016, режим доступа: свободный).
  4. ejudgehomepage [Электронный ресурс] //URL:https://ejudge.ru/ (Дата обращения: 13.04.2016, режим доступа: свободный).
  5. Peach3 -Welcome [Электронный ресурс] //URL:https://ext.peach3.nl/ (Дата обращения: 13.04.2016, режим доступа: свободный).
  6. Web-CATCommunityHome [Электронный ресурс] //URL:http://web-cat.org/ (Дата обращения: 13.04.2016, режим доступа: свободный).
  7. Codeforces [Электронный ресурс] //URL:http://codeforces.com/ (Дата обращения: 02.05.2016, режим доступа: свободный).
  8. TimusOnlineJudge [Электронный ресурс] //URL:http://acm.timus.ru/?locale=ru (Дата обращения: 02.05.2016, режим доступа: свободный).
  9. AvoidingPlagiarism:WritingComputerCode [Электронный ресурс] //URL:http://www.upenn.edu/academicintegrity/ai_computercode.html (Дата обращения: 15.01.2015, режим доступа: свободный).
  10. Roy, Chanchal Kumar;Cordy, James R., «A Survey on Software Clone Detection Research», Queen's University, Canada, 2007.
  11. MOSS – A System for Detecting Software Plagiarism [Электронныйресурс] //URL:http://theory.stanford.edu/~aiken/moss/ (Датаобращения: 07.02.2015,режимдоступа:свободный).
  12. JPlagDetectingSoftwarePlagiarism [Электронный ресурс] //URL:https://jplag.ipd.kit.edu/ (Дата обращения: 08.02.2015, режим доступа: свободный).
  13. Brin S., David S., «Copy Detection Mechanisms for Digital Documents», Stanford University, Stanford, 2001.
  14. Marković A., Rakočević S., «PROCEEDINGS OF THE XIV INTERNATIONAL SYMPOSIUM SYMORG 2014: MODELS AND SUSTAINABLE COMPETITIVENESS», SYMORG, Zlatibor, 2014.
  15. Schleimer S., Wilkerson D., Aiken A., «Winnowing: Local Algorithms for Document Fingerprinting», Stanford University, Stanford, 2003.
  16. PEP 8Reference [Электронный ресурс] //URL:https://www.python.org/dev/peps/pep-0008/ (Дата обращения: 5.02.2016, режим доступа: свободный).
  17. PHPCodeCheckerOnli [Электронный ресурс] //URL:http://phpcodechecker.com/ (Дата обращения: 9.02.2016, режим доступа: свободный).
  18. JSLintTool [Электронный ресурс] //URL:http://www.jslint.com/ (Дата обращения: 9.02.2016, режим доступа: свободный).
  19. IntellijIDEAJetBrains [Электронный ресурс] //URL:https://www.jetbrains.com/idea/ (Дата обращения: 10.02.2016, режим доступа: свободный).
  20. PMDToolset [Электронный ресурс] //URL:https://pmd.github.io/ (Дата обращения: 25.03.2016, режим доступа: свободный).
  21. CLangHomePage [Электронный ресурс] //URL:http://clang.llvm.org/ (Дата обращения: 7.04.2016, режим доступа: свободный).
  22. PVS-Studio: статический анализатор кода дляC/C++/C# [Электронный ресурс] //URL:http://www.viva64.com/ru/pvs-studio/ (Дата обращения: 21.04.2016, режим доступа: свободный).
  23. MakeGNUProject [Электронный ресурс] //URL:https://www.gnu.org/software/make/ (Дата обращения: 22.04.2016, режим доступа: свободный).
  24. CMakeHome [Электронный ресурс] //URL:https://cmake.org/ (Дата обращения: 11.04.2016, режим доступа: свободный).
  25. ApacheAntProject [Электронный ресурс] //URL:http://ant.apache.org/ (Дата обращения: 11.04.2016, режим доступа: свободный).
  26. MavenWelcometoApacheMaven [Электронный ресурс] //URL:https://maven.apache.org/ (Дата обращения: 1.02.2016, режим доступа: свободный).
  27. JenkinsContinuousIntegration [Электронный ресурс] //URL:https://jenkins.io/ (Дата обращения: 5.03.2016, режим доступа: свободный).
  28. TeamCityJetBrains [Электронный ресурс] //URL:https://www.jetbrains.com/teamcity/ (Дата обращения: 7.03.2016, режим доступа: свободный).
  29. Continuousdeliveryfromcodetodeployment [Электронный ресурс] //URL:https://ru.atlassian.com/software/bamboo/ (Дата обращения: 20.04.2016, режим доступа: свободный).
  30. TheUltimateListofOpenSourceStaticCodeAnalysisTools [Электронный ресурс] //URL:https://www.checkmarx.com/2014/11/13/the-ultimate-list-of-open-source-static-code-analysis-security-tools/ (Дата обращения: 20.04.2016, режим доступа: свободный).
  31. Broder A., «On the resemblance and containment of documents», DIGITAL Systems Research Center, Palo Alto, 1997.
  32. Merge Join Architecture [Электронный ресурс] //URL: http://blogs.msdn.com/b/craigfr/archive/2006/08/03/687584.aspx (Дата обращения: 17.04.2016, режим доступа: свободный).
  33. Паттерны для новичков: MVC vs MVP vs MVVM [Электронный ресурс] //URL: https://habrahabr.ru/post/215605/  (Дата обращения: 28.03.2016, режим доступа: свободный).
  34. WebMVCFramework [Электронный ресурс] //URL: http://docs.spring.io/autorepo/docs/spring/3.2.x/spring-framework-reference/html/mvc.html  (Дата обращения: 28.03.2016, режим доступа: свободный).
  35. SpringBoot -Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-boot/  (Дата обращения: 28.03.2016, режим доступа: свободный).
  36. Введение в JSON [Электронный ресурс] //URL: http://www.json.org/json-ru.html (Дата обращения: 20.05.2016, режим доступа: свободный).
  37. Spring Data JPA - Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-data-jpa/ (Дата обращения: 29.03.2016, режим доступа: свободный).
  38. Hibernate. Everything data. – Hibernate [Электронный ресурс] //URL: http://hibernate.org/ (Дата обращения: 29.03.2016, режим доступа: свободный).
  39. Java Persistence API [Электронный ресурс] //URL: http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html (Дата обращения: 29.03.2016, режим доступа: свободный).
  40. Whatisacookie? -AllaboutCookies [Электронный ресурс] //URL: http://www.allaboutcookies.org/cookies/ (Дата обращения: 21.04.2016, режим доступа: свободный).
  41. SpringSecurity -Projects [Электронный ресурс] //URL: http://projects.spring.io/spring-security/ (Дата обращения: 21.04.2016, режим доступа: свободный).
  42. SafelyStoringUserPasswords:Hashingvs.Encrypting [Электронный ресурс] //URL: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374 (Дата обращения: 21.04.2016, режим доступа: свободный).
  43. CrackStation's Password Cracking Dictionary [Электронный ресурс] //URL: https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm (Дата обращения: 21.04.2016, режим доступа: свободный).
  44. SaltedPasswordHashing -DoingitRight [Электронный ресурс] //URL: https://crackstation.net/hashing-security.htm (Дата обращения: 21.04.2016, режим доступа: свободный).
  45. ClassBCrypt (Spring Security 4.1.0.RELEASE API) [Электронный ресурс] //URL: http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCrypt.html (Дата обращения: 21.04.2016, режим доступа: свободный).
  46. Пониманиеcallback-функций (колбеков) [Электронный ресурс] //URL: https://habrahabr.ru/post/151716/ (Дата обращения: 03.05.2016, режим доступа: свободный).
  47. SecureRandom (JavaPlatformSE 7 ) -OracleHelpCenter [Электронный ресурс] //URL: https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html (Дата обращения: 10.05.2016, режим доступа: свободный).
  48. JavaParserandAbstractSyntaxTree [Электронный ресурс] //URL: https://github.com/javaparser/javaparser (Дата обращения: 11.05.2016, режим доступа: свободный).
  49. Jetty -ServletEngineandHttpServerEclipse [Электронный ресурс] //URL: http://www.eclipse.org/jetty/ (Дата обращения: 25.03.2015, режим доступа: свободный).
  50. ProjectGrizzly [Электронный ресурс] //URL: https://grizzly.java.net/ (Дата обращения: 25.03.2015, режим доступа: свободный).
  51. Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web.[Электронный ресурс] //URL: http://getbootstrap.com/ (Дата обращения: 8.02.2016, режим доступа: свободный).
  52. FileInput -BootstrapFileInput - ©Kartik [Электронный ресурс] //URL: http://plugins.krajee.com/file-input (Дата обращения: 20.04.2016, режим доступа: свободный).
  53. BootstrapNotifyv3.1.3 [Электронный ресурс] //URL: http://bootstrap-notify.remabledesigns.com/ (Дата обращения: 20.04.2016, режим доступа: свободный).
  54. Введение в AJAX и COMET [Электронный ресурс] //URL: https://learn.javascript.ru/ajax-intro (Дата обращения: 23.05.2016, режим доступа: свободный).
  55. jQuery [Электронный ресурс] //URL: https://jquery.com/ (Дата обращения: 20.02.2016, режим доступа: свободный).
  56. Handlebars.js:MinimalTemplatingonSteroids [Электронный ресурс] //URL: http://handlebarsjs.com/ (Дата обращения: 20.02.2016, режим доступа: свободный).
  57. nginx [Электронный ресурс] //URL: http://nginx.org/ru/ (Дата обращения: 03.03.2016, режим доступа: свободный).
  58. Кросс-доменные ограничения и их обход [Электронный ресурс] //URL: https://learn.javascript.ru/same-origin-policy (Дата обращения: 12.05.2016, режим доступа: свободный).
  59. UsingnginxasHTTPloadbalancer [Электронный ресурс] //URL: http://nginx.org/en/docs/http/load_balancing.html (Дата обращения: 20.05.2016, режим доступа: свободный).

Приложения




Похожие работы, которые могут быть Вам интерестны.

1. Разработка модуля интегрирующей системы автоматической проверки задач по программированию кафедры АВТ ВоГУ в систему Moodle

2. Программа аудиторской проверки основных средств

3. Кантователь с автоматической фиксацией изделия

4. Исследование эффективности автоматической векторизации циклов компиляторами

5. Оборудование автоматической системой пожарной сигнализацией фабрики гофрокартона

6. Валидность заданий на взаимное оценивание в массовых открытых онлайн- курсах

7. РАЗРАБОТКА ПЛАНОВЫХ ЗАДАНИЙ ДЛЯ СОРТИРОВОЧНОЙ ЖЕЛЕЗНОДОРОЖНОЙ СТАНЦИИ КУРСОВАЯ РАБОТА

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

9. МЕТОДИКА ПРИМЕНЕНИЯ ТВОРЧЕСКИХ ЗАДАНИЙ ПО ХИМИИ В КЛАССАХ СОЦИАЛЬНО-ГУМАНИТАРНОГО ПРОФИЛЯ

10. Психолого-педагогический анализ работы учителей по применению тестовых заданий на уроках математики