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

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

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

Введение

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

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

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

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

1. Анализ существующих подходов к решению рассматриваемых задач.

2. Исследование предметной области статического анализа: инструменты статического анализа, типы обнаруживаемых ошибок.

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

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

5. Внедрение полученных результатов в деятельность университета.

В соответствии с вышесказанным объектом исследования являются ошибки дизайна программного кода.

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

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

Научная новизна работы заключается в следующем:

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

Практическая значимость результатов диссертации заключается в следующем:

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

Апробация работы: на тему диссертационной работы было опубликовано 3 статьи:

Статический анализ исходного кода в обучении и разработке программного обеспечения // Молодой ученый. -- 2018. -- №22. -- С. 38-39. -- URL https://moluch.ru/archive/208/50975/

Типовые ошибки дизайна программного кода // Молодой ученый. -- 2019. -- №2. -- С. 1-2. -- URL https://moluch.ru/archive/240/55453/

Статический и динамический анализ исходного кода // Молодой ученый. -- 2019. -- №2. -- С. 2-4. -- URL https://moluch.ru/archive/240/55456/

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

1. Анализ предметной области

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

Задачи, решаемые программами статического анализа кода, можно разделить на 3 категории:

Выявление ошибок в программах. Подробнее про это будет рассказано ниже.

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

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

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

Главное преимущество статического анализа состоит в возможности существенного снижения стоимости устранения дефектов в программе. Чем раньше ошибка выявлена, тем меньше стоимость ее исправления. Так согласно данным, приведенным в книге Макконнелла "Совершенный Код" [2], исправление ошибки на этапе тестирования обойдется в десять раз дороже, чем на этапе конструирования (написания кода).

Другие преимущества статического анализа кода:

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

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

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

Недостатки статического анализа кода:

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

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

1.1 Основные типы ошибок в программном коде

В общем случае задачей статического анализа можно назвать обнаружение ошибок дизайна программного кода. Ниже описаны некоторые наиболее распространенные ошибки дизайна [3], обнаружив которые на ранних этапах разработки можно избежать серьезных проблем:

1. Длинные методы

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

2. Отказ от наследства

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

3. Группы данных

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

4. Дублирование кода

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

5. Посредник

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

6. Одержимость примитивными типами

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

7. Комментарии

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

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

8. Расходящиеся модификации

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

9. Завистливые функции

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

10. Ленивый класс

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

11. Имя метода, включающее тип

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

12. Невнятное название

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

13. Мертвый код

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

1.2 Обзор систем дистанционного обучения

Для анализа выбраны самые популярные платформы для онлайн-обучения в России и за рубежом. Далее приведено их краткое описание и выводы, сделанные из анализа [4].

Codecademy

Интерактивная онлайн-платформа для обучения 12 языкам программирования: Python, PHP, JavaScript, Ruby, Java и др., а также работе с библиотекой jQuery и языкам разметки и оформления веб-страницы HTML и CSS.

Udacity

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

Codewars

Это интерактивный сборник задач по программированию. Сейчас сервис поддерживает следующие языки: Clojure, C++, C#, Elixir, F#, Go, Haskell, Java, JavaScript, PHP, Python, Ruby, Rust, Shell, SQL, Swift, TypeScript.

Coursera

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

Code Avengers

Code Avengers предоставляет возможность обучаться в интерактивной и игровой форме основам HTML5, CSS3, JavaScript прямо в браузере.

Hexlet

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

JavaRush

JavaRush обучает программированию на Java в форме онлайн-игры. Курс JavaRush содержит 1200 практических задач возрастающей сложности.

Javascript.ru

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

ITVDN

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

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

1.3 Обзор инструментов статического анализа

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

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

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

Свободное применение, неограниченное лицензией

По перечисленным критериям проведен отбор инструментов статического анализа по реестрам [5, 6]. Отбор сузил выбор до следующих инструментов:

coala - «из коробки» поддерживает более 60 языков прогаммирования, возможно расширение за счет модулей (так называемых Bears),

сqc - поддерживает только форматы js, jsx, vue, css, less, scss, sass and styl,

graudit - использует регулярные выражения для поиска ошибок,

Infer - поддерживает только языки Java, C and Objective-C,

oclint - поддерживает только языки C, C++ and Objective-C,

PMD - поддерживает только языки Java, Javascript, PLSQL, XML, XSL,

SonarQube - расширения для некоторых языков программирования, таких как C/C++, распространяются платно,

TscanCode - поддерживает только языки C/C++, C#, Lua, слабая поддержка.

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

Поиск на основе регурярных выражений,

Анализ грамматики языка.

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

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

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

1.4 Функции системы

Анализируя функции системы, можно выделить следующие:

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

Сохранение результатов статического анализа в БД

Возможность просмотра результатов статического анализа пользователем через web-интерфейс

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

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

2. Проектирование

2.1 Диаграмма вариантов использования

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

Рисунок 1 - Диаграмма вариантов использования

2.2 Пользовательский интерфейс

На рисунке 2 представлен макет страницы просмотра решения.

Рисунок 2 - Макет страницы просмотра решения

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

На рисунке 3 представлен макет панели администратора.

Рисунок 3 - Макет панели администратора

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

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

2.3 Архитектура системы

Рассмотрим существующую архитектуру дистанционного практикума по программированию, изображенную на рисунке 4. [9]



Рисунок 4 - Существующая архитектура системы

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

Для разработки выбран язык Java с применением фреймворка SpringBoot [10], так как эти технологии позволят свести к минимуму написание низкоуровневого кода для интеграции модуля в существующую систему.

Стоит сразу определиться с решениями для интеграции модуля в систему. Во-первых, поскольку подсистема должна обеспечить отображение результатов статического анализа на web-клиенте и управление из панели администратора, система будет предоставлять соответствующие сервисы по технологии REST. Во-вторых, необходимо интегрировать модуль с приложением main_mod для запуска статического анализа по окончанию основной проверки решения. Было принято решение использовать протокол обмена сообщениями AMQP. Реализации клиентских модулей для этого протокола существуют и для C++, на котором разработано приложение main_mod, и для Java. Для работы приложения с БД будет использована технология JDBC.

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

Рисунок 5 - Архитектура дорабатываемой системы

2.4 Проектирование прикладных приложений

Приложение main_mod

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

AMQP-брокер

В качестве AMQP-брокера будет выступать RabbitMQ [12]. ПО разработано на языке Erlang, поэтому помимо самого брокера в системе должен быть установлен дистрибутив Erlang/OTP.

Приложение статического анализа.

Как уже упоминалось ранее, приложение должно обеспечивать поддержку технологий REST, JDBC и AMQP. Весь стек необходимых технологий покрывается библиотеками Spring - spring-boot-starter-amqp, spring-boot-starter-web, spring-boot-starter-data-jpa, а также драйвером JDBC для БД Firebird - jaybird-jdk18. Для функционирования приложения в системе должен быть установлен дистрибутив JDK 1.8.

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

Прикладная архитектура приложения представлена на рисунке 6.

Рисунок 6 - Прикладная архитектура приложения статического анализа

1. AMQP-слушатель

Задача AMQP-слушателя - принять уведомление о завершении проверки решения на корректность, выполнить статический анализ решения и сохранить результат в БД.

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

Результат выполнения статического анализа представляет собой JSON-объект следующего вида:

[

{

"additional_info": "",

"affected_code": [

{

"end": {

"column": 9,

"file": "/home/pavel/Desktop/DbSeeder.java",

"line": 112

},

"file": "/home/pavel/Desktop/DbSeeder.java",

"start": {

"column": 9,

"file": "/home/pavel/Desktop/DbSeeder.java",

"line": 112

}

}

],

"aspect": "NoneType",

"confidence": 100,

"debug_msg": "",

"diffs": null,

"id": 36314598184926129066205396129825355428,

"message": "Each variable declaration must be in its own statement.",

"message_arguments": {},

"message_base": "Each variable declaration must be in its own statement.",

"origin": "CheckstyleBear (MultipleVariableDeclarations)",

"severity": 1

},

...

]

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

2. REST-контроллеры

REST-контроллеры обслуживают пользовательские запросы. В зависимости от того, какую роль имеет пользователь, ему должны быть доступны:

1) Пользователь - сервис получения списка ошибок по конкретному решению.

2) Администратор - получение списка компиляторов в связке с включенными для них модулями coala, отключение анализа конкретным модулем в зависимости от компилятора, отключение отображения результатов анализа конкретным модулем в зависимости от компилятора.

Доступ к REST-контроллерам будет защищен механизмом Spring Security.

2.5 Проектирование web-клиента

Страница просмотра решения

Список найденных ошибок должен подгружаться на страницу динамически при раскрытии соответствующей панели. Это позволит сэкономить ресурсы, когда пользователь открывает страницу решения без цели просмотра результатов статического анализа. Для этого, а также для реализации раскрывающегося списка будет использована библиотека jQuery [13] с набором компонентов jQueryUI. jQueryпозволяет работать с DOM-моделью страницы, динамически изменяя ее содержимое, а также отправлять запросы XMLHttpRequest к REST-сервисам.

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

Доработка обработчиков Perl

Во-первых, необходимо доработать обработчики отрисовки страницы просмотра решения и страницы администрирования. На страницы будут добавлены необходимые компоненты и JavaScript-код, подключена библиотека jQuery.

Во-вторых, необходимо реализовать механизм аутентификации в подсистеме статического анализа, поскольку заголовок Authorization, содержащий логин и пароль пользователя и сохраняющийся в сессии на уровне браузера недоступен из JavaScript-кода. Эту проблему можно решить сохранением сессии в cookies. Таким образом, необходимо в Perl-скрипт аутентификации добавить вызов к сервису подсистемы статического анализа, передав оригинальный заголовок Authorization. Если переданные в заголовке данные корректны, сервис создаст сессию пользователя на сервере и вернет присвоенный сессии cookieJSESSIONID. Далее этот cookie необходимо передать из Perl-обработчика клиенту.

2.6 Проектирование структуры данных

Логическая схема имеющейся базы данных изображена на рисунке 7. [14]



Рисунок 7 - Логическая схема БД

Основной интерес для проекта представляют таблицы STATUS и COMPIL, выделенные на схеме.

COMPIL - компиляторы. Атрибуты:

ID_CMP- идентификатор компилятора;

NAME- название компилятора.

STATUS - таблица с присланными решениями. Атрибуты:

ID_STAT- идентификатор решения;

DT_TM - дата и время получения системой решения;

ID_PUBL - идентификатор пользователя, приславшего решение;

ID_PRB - идентификатор задачи, на которую прислано решение;

ID_CMP - идентификатор компилятора, используемого для компиляции донного решения;

ID_RSL - идентификатор результата проверки решения;

TEST_NO - в случае неверного решения, указывается номер теста на котором произошла ошибка;

TIME_WORK - максимальное (на один тест) время работы решения;

MEM_USE - максимальное (на один тест) использование решением оперативной памяти.

Результаты статического анализа будут сохранены в отдельную таблицу, структура которой в соответствии с JSON-структурой будет иметь следующий вид:

Таблица SOLUTION_ISSUES - ошибки, обнаруженные статическим анализатором. Атрибуты:

ISSUE_ID-идентификатор ошибки,

ID_STAT-идентификатор решения,

START_LINE-строка начала фрагмента кода с ошибкой,

START_COL-столбец начала фрагмента кода с ошибкой,

END_LINE-строка конца фрагмента кода с ошибкой,

END_COL-столбец конца фрагмента кода с ошибкой,

MESSAGE-сообщение об ошибке,

ID_BEAR-идентификатор модуля, обнаружившего ошибку,

SEVERITY-серьезность ошибки.

Также необходимо ввести в БД сущность проверяющего модуля coala:

Таблица BEAR - проверяющие модули. Атрибуты:

ID_BEAR-идентификатор модуля

NAME-название модуля

И таблицу-связку между компиляторами и проверяющими модулями:

Таблица COMPIL_BEAR - связка проверяющих модулей и компиляторов. Атрибуты:

ID_BEAR-Идентификатор проверяющего модуля,

ID_CMP-Идентификатор компилятора,

ENABLED-признак того, что проверка решений данным модулем включена для компилятора,

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

Часть схемы БД, которую затронули изменения, показана на рисунке 8.



Рисунок 8 - Измененная структура БД

2.7 Проектирование алгоритмов

Алгоритм обработки сообщения об окончании компиляции и проверки корректности вывода программы изображен на рисунке 9.



Рисунок 9 - Алгоритм обработки слушателем сообщения об окончании основной проверки решения

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

К окружению, в котором будет функционировать система, по результатам проектирования предъявлены требования на наличие следующего ПО:

JDK 1.8

Python 3.7.3

Erlang/OTP 22.0

RabbitMQ 3.7.15

3. Разработка

3.1 Выбор инструментальных средств разработки

Разработка приложения статического анализа будет выполняться в интегрированной среде разработки IntelliJIDEA 2019.1. Для управления зависимостями в проекте применено приложение Gradle.Для доработки приложения проверки решений main_mod будет использована интегрированная среда разработки MicrosoftVisualStudio 2019 с набором инструментов MicrosoftVisualC++ 2013.Для работы с СУБД Firebird, исполнения SQL-скриптов будет использована утилита IBExpert 2011.

3.2 Разработка структуры БД

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

Таблица проверяющих модулей

CREATETABLEBEAR (

ID_BEAR INTEGER NOT NULL,

NAME VARCHAR(50) NOT NULL

);

Таблица-связка проверяющих модулей с компиляторами

CREATETABLE COMPIL_BEAR (

ID_BEAR INTEGER NOT NULL,

ID_CMP INTEGER NOT NULL,

ENABLED CHAR(1) DEFAULT 'y' NOT NULL,

SHOWED CHAR(1) DEFAULT 'y' NOT NULL

);

Таблица найденных ошибок

CREATE TABLE SOLUTION_ISSUE (

ISSUE_ID INTEGER NOT NULL,

ID_STAT INTEGER NOT NULL,

START_LINE INTEGER,

START_COL INTEGER,

END_LINE INTEGER,

END_COL INTEGER,

MESSAGE VARCHAR(1000) NOT NULL,

ID_BEAR INTEGER NOT NULL,

SEVERITY INTEGER NOT NULL

);

Необходимо задать первичные и внешние ключи для таблиц:

ALTER TABLE BEAR ADD PRIMARY KEY (ID_BEAR);

ALTER TABLE COMPIL_BEAR ADD PRIMARY KEY (ID_BEAR, ID_CMP);

ALTER TABLE COMPIL_BEAR ADD FOREIGN KEY (ID_BEAR) REFERENCES BEAR (ID_BEAR);

ALTER TABLE COMPIL_BEAR ADD FOREIGN KEY (ID_CMP) REFERENCES COMPIL (ID_CMP);

ALTER TABLE SOLUTION_ISSUE ADD PRIMARY KEY (ISSUE_ID);

ALTER TABLE SOLUTION_ISSUE ADD FOREIGN KEY (ID_STAT) REFERENCES STATUS (ID_STAT);

ALTER TABLE SOLUTION_ISSUE ADD FOREIGN KEY (ID_BEAR) REFERENCES BEAR (ID_BEAR);

Также будут созданы генераторы идентификаторов для таблиц BEAR и SOLUTION_ISSUE и триггеры на вставку в эти таблицы, использующие генераторы. Полный листинг SQL-скриптов приведен в приложении 1.

3.3 Настройка AMQP-брокера

В качестве AMQP-брокера ранее был выбран RabbitMQ.Необходимо установить дистрибутив Erlang/OTP и затем RabbitMQ.На брокере нужно создать две очереди:

1. accepted_solutions - главная очередь, которая будет использоваться для обмена сообщениями между приложением main_mod и приложением статического анализа.

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

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

3.4 Доработка приложения main_mod.exe

Сборка библиотеки SimpleAmqpClient

Необходимым условием для сборки SimpleAmqpClient является наличие скомпилированных библиотек rabbitmq-cи boost. Поэтому сперва нужно собрать их и затем саму библиотеку SimpleAmqpClient.

Чтение конфигурации

Конфигурация приложения находится в файле master.cfg, откуда читается приложением в класс TConfig. В эту конфигурацию необходимо вынести настройки подключения к AMQP-брокеру. Для этого в класс TConfig добавляется структура TMessaging:

structTMessaging {

char* host;

char* port;

char* username;

char* password;

};

Отправка уведомлений по AMQP

При старте приложения устанавливается подключение к AMQP-брокеру вызовом следующей функции:

mqConnection = AmqpClient::Channel::Create(master_cfg->Messaging->host, atoi(master_cfg->Messaging->port), master_cfg->Messaging->username, master_cfg->Messaging->password);

Функция WhileTestSolve дорабатывается таким образом, что после проверки решения в очередь accepted_solutions отправляется сообщение с идентификатором решения:

string messageBody = "id_stat=" + to_string(elm.id_stat);

AmqpClient::BasicMessage::ptr_t message = AmqpClient::BasicMessage::Create(messageBody);

message->ContentType("text/plain");

mqConnection->BasicPublish("", "accepted_solutions", message);

3.5 Настройка приложения coala

coala предлагает несколько способов установки. Наиболее удобно развернуть coala в изолированной среде pipenv. Пререквизитами для этого является наличие установленного в системе Python.

В специально созданной директории необходимо выполнить команды pip3 install pipenv и pipenv install coala-bears. После этого можно приступать к работе с coala.Запуск командной строки в изолированной среде выполняется командой pipenv shell, после чего становятся доступны команды для взаимодействия с coala. В дальнейшем это будет использовано для запуска coala из Java-приложения.

3.6 Реализация приложения статического анализа

С учетом необходимых зависимостей от библиотек, листинг конфигурации сборки build.gradle приведен в приложении 2.

1. Точкой входа в приложение SpringBoot служит класс Application:

@SpringBootApplication

@EnableRabbit

@EnableJpaRepositories

public class Application {

public static void main(String[] args) {

SpringApplication.run(Application.class, args);

}

}

Аннотации @SpringBootApplication, @EnableRabbit, @EnableJpaRepositories включают конфигурацию контекста Spring, автосканирование пакетов на Spring-компоненты, инициализацию AMQP-клиента для RabbitMQ и инициализацию JPA.

2. Разработка слоя доступа к данным

Для доступа к данным будет использована спецификация JPA (JavaPersistenceAPI). Она реализует концепцию ORM (объектно-реляционное отображение).

При помощи IntelliJIDEA можно сгенерировать классы сущностей JPA по имеющейся схеме БД. Пример такого класса для таблицы SOLUTION_ISSUES приведен в приложении 3.

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

Репозиторий сущности COMPIL.

public interface CompilRepository extends CrudRepository<CompilEntity, Short> {

}

Репозиторий сущности STATUS.

public interface StatusRepository extends CrudRepository<StatusEntity, Integer> {

}

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

public interface CompilBearRepository extends CrudRepository<CompilBearEntity, Short> {

@Modifying

@Query("update CompilBearEntity cb set cb.enabled = ?1 where cb.compilByIdCmp.idCmp = ?2 and cb.bearByIdBear.idBear = ?3")

int setEnabled(boolean enabled, short compilerId, int bearId);

@Modifying

@Query("update CompilBearEntity cb set cb.showed = ?1 where cb.compilByIdCmp.idCmp = ?2 and cb.bearByIdBear.idBear = ?3")

int setShowed(boolean showed, short compilerId, int bearId);

}

Эти интерфейсы наследуют методы для выполнения CRUD-операций из интерфейса CrudRepository.

3. Сервис проверки решения

Для обработки сообщений от AMQP необходимо создать новый компонент Spring, в котором должен быть метод помеченный аннотацией @RabbitListener(queues = "accepted_solutions"). Единственный параметр метода, строка content, является телом AMQP-сообщения.

Необходимо извлечь из тела параметр id_stat и получить по нему решение с помощью метода репозитория StatusRepository.findById(). Дальнейший алгоритм соответствует блок-схеме, приведенной в разделе 2.7. Отдельно рассмотреть стоит только взаимодействие с приложением coala в классе Analyzer.

Полный текст класса CheckingCompletionListener приведен в приложении 4

Ввод исходного текста и получение результатов в coala осуществляется через промежуточные файлы. Поэтому в методе Analyzer.analyze() в первую очередь генерируются случайные названия файлов для исключения конфликтов при конкурентном анализе нескольких решений:

String uuid = UUID.randomUUID().toString();

File in = new File(coalaPath + "\\" + uuid + ".in");

File out = new File(coalaPath + "\\" + uuid + ".out");

После этого исходный текст решения записывается в файл in:

FileUtils.writeStringToFile(in, source, StandardCharsets.UTF_8);

Далее следует непосредственно вызов coala в изолированной среде pipenv:

CommandLine cmdLine = CommandLine.parse("cmd /c cd " + coalaPath + " && echo coala -I --no-autoapply-warn --json" +

" --bears=" + String.join(",", bears) +

" --files=" + in.getName() +

" -o=" + out.getName() +

" | pipenv shell");

DefaultExecutor executor = new DefaultExecutor();

String json;

try {

executor.execute(cmdLine);

} catch (IOException e) {

e.printStackTrace();

}

По завершении результаты анализа считываются из файла out, файлы in и out удаляются и результат парсится из JSON-строки в Java-объекты с помощью библиотеки FasterXMLJackson:

try (FileInputStream fileInputStream = new FileInputStream(out)) {

json = IOUtils.toString(fileInputStream);

} catch (IOException e) {

throw new RuntimeException(e);

}

in.delete();

out.delete();

return parseJson(json);

4. REST-контроллеры

Будут созданы следующие REST-сервисы:

AdminController

GET /admin/bears - получение списка компиляторов в связке с проверяющими модулями и статусов активации сканирования и активации отображения пользователю

POST /admin/analysis-state - включение/отключение проверки модулем coala по компилятору

POST /admin/showing-state - включение/отключение отображения пользователю ошибок, обнаруженных конкретным модулем coala по компилятору

UserController

GET /issues получение списка ошибок по идентификатору решения

AuthController

GET /auth сервис, не несущий предметной пользы. Нужен только для аутентификации пользователя.

Полные исходные тексты классов контроллеров приведены в приложении 5.

5. Аутентификация в приложении

Аутентификация в приложении реализована с помощью библиотеки SpringSecurity. В приложение введены две роли: USER и ADMIN, соответствующие существующей ролевой модели дистанционного практикума. Роли ADMIN доступны все сервисы, включая сервисы соответствующие паттерну /admin/**. Роли USER доступны сервисы за исключением сервисов /admin/**.

Конфигурация безопасности выглядит следующим образом:

@Override

protected void configure(HttpSecurity http) throws Exception {

http.authorizeRequests()

.antMatchers("/admin/**").hasAuthority("ADMIN")

.antMatchers("/**").hasAnyAuthority("USER", "ADMIN")

.and().httpBasic()

.and().csrf().disable();

}

Полный текст конфигурации безопасности, включающий механизм проверки логина и пароля пользователя и получения роли пользователя из БД приведен в приложении 6. Конфигурация приложения определяется в файле application.properties. Перечислим лишь основные параметры для подключения к БД, AMQP-брокеру и путь к директории с coala:

spring.rabbitmq.host=localhost

spring.rabbitmq.port=5672

spring.rabbitmq.username=guest

spring.rabbitmq.password=guest

spring.datasource.url=jdbc:firebirdsql://localhost/c:\\acm\\db\\acm.gdb

spring.datasource.username=sysdba

spring.datasource.password=masterkey

coala.path=C:\\coala

6. Сборка и запуск приложения

Приложение собирается командой gradlebuildJar. Собранный JAR создается в директории build/libs. Для подключения внешнего файла конфигурации достаточно расположить рядом с JAR файл application.properties. Запуск приложения осуществляется командой java -jarsas-1.0-SNAPSHOT.jar. При этом в переменной окружения PATH должна быть добавлена директория JDK 1.8.

3.7 Настройка ApacheHTTPServer

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

ProxyPass /sas/ http://localhost:8081/

ProxyPassReverse /sas/ http://localhost:8081/

3.8 Доработка web-клиента

1. Аутентификация в приложении статического анализа

Значение заголовка Authorization, сохраненное в браузере при аутентификации в системе дистанционного практикума недоступно в JavaScript-коде, поэтому необходимо пройти авторизацию в системе статического анализа в момент обработки CGI-запроса. Для этого в подпрограмму authenticate_process скрипта common_func.plдобавляется вызов сервиса /sas/auth, с передачей ему исходного заголовка Authorization. Полученный в ответ заголовок Set-Cookie необходимо вернуть на web-клиент. Таким образом, в браузере сохранится cookie сессии, созданной в приложении статического анализа.

$ua = LWP::UserAgent->new;

$req = HTTP::Request->new(GET => "http://" . $ENV{"HTTP_HOST"} . "/sas/auth");

$req->header('Authorization' => "Basic " . $ENV{'HTTP_CGI_AUTHORIZATION'});

$res = $ua->request($req);

print header(-status=>"301 Moved Permanently",

-cookie=>[$cookie_login],

-Location=>$new_url,

-Set_Cookie => $res->header('Set-Cookie'));

2. Отображение ошибок на странице просмотра решения

Шаблон страницы просмотра решения находится в файле src_full_ru.html.

Нужно подключить к странице скрипты jQuery и jQueryUI:

<script type="text/javascript" src="/jquery-3.4.1.min.js"></script>

<script type="text/javascript" src="/jquery-ui-1.12.1.custom/jquery-ui.min.js"></script>

На страницу добавляется div-блок с id=”accordion”, в котором будет отображаться выпадающий список ошибок.

При помощи jQuery необходимо назначить на событие загрузки DOM-модели страницы колбэк-функцию, в которой происходит инициализация определенного ранее блока выпадающего списка, но пока без загрузки его содержимого. Для этого используя функцию accordion библиотеки jQueryUI, инициализируется выпадающий список ошибок, на событие открытия которого назначается обработчик загрузки списка ошибок XHR-запросом к сервису /sas/issues. Полученный JSON приводится к списку ссылок (тегов <a>), который отрисовывается в раскрытой панели. После чего на ссылки в данной панели назначается колбэк-функция, которая подсвечивает в исходном тексте программы фрагмент текста с ошибкой.

В связи с тем, что тексты ошибок, генерируемыеcoala, изначально на английском языке, желательно предусмотреть возможность их перевода для русскоязычных пользователей. Для этого будет использованGoogleAPI. В теле страницы создается div-блок с class=”goog-trans-control” и подключается JS-скрипт Google-переводчика, который настраивается на этот класс и на класс объекта, содержимое которого необходимо перевести.

Полный текст кода JavaScript, определенного на странице просмотра решения, приведен в приложении 7.

3. Управление статическим анализом в панели администратора

В тело страницы добавляется div-блок с id=”static-analysis”, в котором в дальнейшем будет отрисовываться таблица компиляторов и модулей.На событие загрузки DOM-модели назначается колбэк-функция, котораяобращением к сервису /sas/admin/bears загружает список компиляторов и связанных с ними модулей статического анализа.

Для каждого компилятора в таблице создается строка, и в свою очередь в каждой из них также создается отдельная строка для связанных модулей coala с чекбоксами для включения/отключения статического анализа и включения/отключения отображения ошибок по решению.На события изменения состояния чекбоксов назначаются колбэк-функции, которые вызывают сервисы /sas/admin/analysis-state и /sas/admin/showing-state соответственно, которые изменяют состояние модулей в БД.

Полный текст кода JavaScript, определенного на странице администрирования, приведен в приложении 8.

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

4. Тестирование

статический программный алгоритм

4.1 Обоснование методики тестирования

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

Тест-кейс №1 Проверка решения: ошибка компиляции.

Шаги

1. Авторизоваться в системе

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

3. Дождаться окончания окончания проверки

4. Перейти на страницу просмотра решения

Ожидаемый результат

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

Тест-кейс №2 Проверка решения: успешная компиляция, ошибки дизайна

Предусловия

В панели администратора активирован анализ и отображение ошибок всех модулей

Шаги

1. Авторизоваться в системе

2. Выбрать задачу, отправить корректное решение, содержащее ошибки, обнаруживаемые статическим анализатором

3. Дождаться окончания проверки

4. Перейти на страницу просмотра решения

Ожидаемый результат

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

Тест-кейс №3 Изменение состояния активации модулей статического анализа в панели администратора

Шаги

1. Авторизоваться в системе под учетной записью администратора

2. Перейти в панель администрирования

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

4. Обновить страницу

Ожидаемый результат

Состояние модулей сохранилось

Тест-кейс №4 Проверка решения: отсутствие ошибок

В панели администратора активирован анализ и отображение ошибок всех модулей

Шаги

1. Авторизоваться в системе

2. Выбрать задачу, отправить корректное решение, без ошибок, обнаруживаемых статическим анализатором

3. Дождаться окончания проверки

4. Перейти на страницу просмотра решения

Ожидаемый результат

Список ошибок дизайна программного кода не отображается

Тест-кейс №5 Скрытие результатов проверки определенными модулями

В панели администратора активирован анализ и отображение ошибок всех модулей

Шаги

1. Авторизоваться в системе

2. Выбрать задачу, отправить корректное решение, содержащее ошибки, обнаруживаемые статическим анализатором

3. Дождаться окончания проверки

4. Перейти на страницу просмотра решения

Ожидаемый результат

Список ошибок дизайна программного кодане отображается

Шаги

5. Авторизоваться под учетной записью администратора

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

7. Перейти на страницу просмотра решения

Ожидаемый результат

Список ошибок дизайна программного кодане отображается

4.2 Результаты тестирования

Выполнено тестирование системы по составленным тест-кейсам. Результаты тестирования отражены в таблице 1.

Таблица 1 - Результаты тестирования

№ п/п	№ тест-кейса	Результат
1	1	пройден
2	2	пройден
3	3	пройден
4	4	пройден
5	5	пройден

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

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

Заключение

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

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

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

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

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

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

Литература

1. Статический анализ кода[Электронный ресурс] // PVS-Studio-Режим доступа: https://www.viva64.com/ru/t/0046/

2. Макконнелл С. Совершенный код. Мастер-класс / Пер. с англ. - М.: Издательско-торговый дом "Русская редакция"; СПб.: Питер, 2005. - 896 стр.: ил. ISBN 5-7502-0064-7.