ВР.pdf. Реферат Магистерская
 Скачать 3.61 Mb.
|
|
3 Процесс разработки 3.1 Документирование API Так как в процессе разработки участвовало две команды, было необходимо каким-то образом документировать REST API, для возможности его использования разработчиками одностраничного приложения. Для решения этой задачи существуют несколько подходов: ● составление описания методов и моделей в текстовом виде вручную; ● использование одной из спецификаций: ○ Swagger(OpenAPI); ○ RAML; ○ WADL. Первый подход не требует изучения спецификаций и установки дополнительного ПО, но это ведет к отсутствию возможности автоматической генерации интерактивной документации. Второй подход требует знания инструментов и языков, но дает преимущества, такие как генерация документации и кода по спецификации. В качестве инструмента для документирования API в проекте был выбран Swagger, так как в его состав входят библиотеки для генерации спецификации, интерактивного отображения и отправки запросов. Основной частью документирования API с помощью Swagger является схема. Она представляет собой текстовый файл, содержащий описание всех HTTP ресурсов, включая доступные пути, методы, модели запроса и ответа. Текст может иметь формат JSON или YAML, набор доступных полей определяется спецификацией OpenAPI. Из особенностей стоит отметить, что спецификация не зависит от языка программирования и имеет декларативный характер, поэтому позволяет клиентам использовать её, не вникая в детали реализации сервера. 50 Спецификация может создаваться тремя способами: ● ручной, когда API полностью описывается человеком; ● автоматический, когда спецификация генерируется на основе кода; ● полуавтоматический, когда часть описания генерируется на основе кода, а часть, например, названия методов и комментарии, заполняются человеком. В системе был применен полуавтоматический способ генерации, так как он имеет разумный баланс между трудоемкостью создания документации и ее понятностью для человека. Для этого была использована библиотека play-swagger. Она генерирует файл спецификации на основе файла с маршрутами (это компонент Play Framework). Каждая запись из этого файла превращается в один метод в документации, при необходимости разработчик может добавить дополнительную информацию вручную, в виде комментария к записи с маршрутом. Комментарий содержит в себе текст в формате YAML, он должен соответствовать спецификации OpenAPI. Так как этот файл хранится в системе контроля версий в текстовом формате, это позволяет без труда отслеживать вносимые изменения. Выглядит это следующим образом: ### # summary: Returns logged in user # tags: # - User ### GET /users/current controllers.user.UserController.me Для отображения сгенерированной схемы используется специальный компонент — Swagger UI. Swagger UI — это веб приложение, которое можно развернуть самостоятельно в локальной сети, визуализирующее файл для схемы в наглядном виде, позволяющее отправлять запросы на сервер прямо из документации. Его интерфейс представлен на рисунке 3.1.1. 51 Рисунок 3.1.1 — Интерфейс Swagger UI В итоге мы получили страницу, всегда содержащую актуальную информацию о доступных методах сервера, позволяющая UI разработчикам более эффективно разбираться в структуре API, без привлечения разработчика серверной части. 3.2 Особенности тестирования Одним из нефункциональных требований являлось покрытие всего кода юнит-тестами. Юнит-тестирование или модульное тестирование — это процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже протестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. 52 Для того, чтобы покрытие было более полным, использовался подход, называемый property-based testing или тесты, основанный на свойствах. Первое, что стоит сказать property-based тесты используют подход черного ящика и запускаются многократно, соответственно отлично подходят для использования в модульных тестах. Суть заключается в следующем, для каждой тестируемой функции необходимо описать допустимое множество входных значений, при которых выполняются заданные условия. Причём, в отличии от классических юнит-тестов, тестовые данные не задаются явно, а генерируются автоматически. Это дает следующие преимущества: ● код тестов становится короче; ● так как входные данные не контролируются, покрытие кода тестами обычно получается выше чем в классическом подходе; ● в сгенерированные данные всегда включаются специальные случаи, которые разработчик мог упустить из вида — пустые списки, максимальные значения чисел, строки из иероглифов; ● принято считать, что property-based тесты легче читаются человеком; ● благодаря процессу, называемому shrinking(сокращение) тестовый фреймворк подбирает минимальный набор данных, вызывающий падение тестов. Тестовый фреймворк делает несколько прогонов теста с различными сгенерированными данными (по умолчанию 100). Суть shrinking заключается в том, что в случае падения теста фреймворк не сразу выдает результат с данными его вызвавшими, а тратит некоторое количество попыток, чтобы найти максимально простые(минимальные) параметры, вызвавшие падение. В качестве фреймворка для модульного тестирования использовался ScalaTest, для поддержки property-base тестирования была использована библиотека ScalaCheck. ScalaCheck имеет в своём составе генераторы для всех базовых типов данных: числа, строки, коллекции, даты. Помимо этого есть 53 возможность описывать генераторы для собственных типов. Для тестирования DAO классов была использована СУБД H2, позволяющая быстро создавать тестовые БД в памяти. Разберем тест, проверяющий корректность сохранения формы (вместе со всеми элементами) в базе. "formDao.create" should { "create form in database" in { forAll { (form: Form) => dao.create(form) val formFromDb =dao.findById(created.id) formFromDb mustBe form } } } Здесь автоматически генерируются различные экземпляры класса Form. Далее они сохраняются и затем сразу получаются из БД, после чего производится проверка, что полученная из БД форма соответствует сохраняемой. 3.3 Непрерывная интеграция и доставка Помимо проектирования и разработки, было необходимо обеспечить автоматическое тестирование новых версий, развертывание на окружении для разработки, а в дальнейшем и развертывание на рабочее окружение, для проведения опросов среди сотрудников. Непрерывная интеграция – это практика разработки программного обеспечения, при которой разработчики регулярно объединяют изменения программного кода в центральном репозитории, после чего автоматически выполняется сборка, тестирование и запуск. Понятие непрерывной интеграции чаще всего применяется к стадии сборки или интеграции процесса выпуска ПО и включает в себя как компонент автоматизации, так и компонент культуры разработки. Главная задача непрерывной интеграции – быстрее находить и исправлять ошибки, улучшать качество ПО и сокращать временные затраты на проверку и выпуск новых обновлений ПО. 54 Непрерывная доставка – это, в свою очередь, практика разработки программного обеспечения, когда при любых изменениях в программном коде выполняется автоматическая сборка, тестирование и подготовка к окончательному выпуску. Непрерывная доставка является одним из основополагающих принципов разработки современных приложений, поскольку расширяет практику непрерывной интеграции за счет того, что все изменения кода после стадии сборки развертываются в тестовой и/или в рабочей среде. Отличие непрерывной доставки от непрерывного развертывания заключается в том, что при непрерывной доставке для развертывания обновлений в рабочей среде требуется подтверждение вручную. При непрерывном развертывании это происходит автоматически без специального подтверждения. Для реализации всех этих подходов использовался компонент GitLab, под названием GitLab CI. GitLab — это платформа управления Git-репозиториями, анализа кода, отслеживания ошибок, тестирования, деплоя, ведения каналов и вики-страниц. Так как сам GitLab уже был запущен в локальной сети предприятия, его установка и настройка рассматриваться не будет. Для того, чтобы автоматически выполнялись активности по тестированию и развертыванию сборок необходимы две вещи — конфигурация CI/CD, представляющая собой YAML файл .gitlab-ci.yaml в корне репозитория и runner (исполнитель) — программа, запущенная в каком-либо окружении и, собственно, выполняющая команды, прописанные в конфигурационном файле. В конфигурационном файле есть возможность определять различные стадии. Стадия — это набор действий, выполняемый при определенных условиях. Например, можно создать стадию test , запускающую модульные тесты при каждой фиксации изменений в репозитории и стадию deploy_develop , автоматически выполняемую при 55 загрузке изменений в develop ветку. Также существует термин pipeline — это набор стадий, выполняемых для конкретного действия в репозитории. Рисунок 3.3.1 — Pipeline из 4 стадий В приложении были созданы следующие стадии: ● test — запуск модульных тестов; ● build — создание исполняемых артефактов(jar файлов) и сборка Docker образов; ● migrate — запуск утилиты, выполняющей миграцию схемы и данных в БД; ● deploy — развертывание приложения на тестовом окружении; ● deploy_master — развертывание окружения на рабочем окружении, запускается только вручную. Стоит рассказать про миграцию базы данных. Для выполнения этой задачи была использована библиотека Flyway. Flyway позволяет разработчику описывать изменения в БД на языке SQL и автоматически применять эти изменения к базе данных по команде. В случае возникновения ошибки изменения будут отменены. Чтобы развертывать приложение используется Docker. Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесен на любую систему, поддерживающую запуск контейнеров, а также предоставляет среду по управлению контейнерами. Модель Docker состоит из следующих базовых элементов: ● Dockerfile; 56 ● образ; ● контейнер. Рисунок 3.3.2 — Взаимосвязи между элементами системы Docker Dockerfile автоматизирует процесс создания образов. Dockerfile описывает среду и используется для сборки образа. Образ — это шаблон для создания контейнера, содержащий в себе исполняемые файлы со всеми необходимыми зависимостями. Контейнер — это запущенный образ, исполняемая единица, которой можно управлять независимо — перезапускать, останавливать, удалять, конфигурировать. Каждая подсистема разворачивается в отдельном контейнере, также в Docker запущены СУБД и брокер сообщений. Такая схема развертывания применяется на всех окружениях: локальном, тестовом и рабочем. В случае необходимости система может быть развернута на новом окружении одной командой. Для конфигурации контейнеров используется утилита Docker Compose. Это инструмент для описания и запуска систем, состоящих из нескольких контейнеров. Утилита использует YAML файл с конфигурацией контейнеров (открытые порты, настройки томов) и способна запускать контейнеры используя эту конфигурацию. По сути, это является автоматизированным аналогом ручного вызова команд Docker с помощью терминала. 57 Рисунок 3.3.3 — Диаграмма развертывания системы На рисунке 3.3.3 представлена диаграмма развертывания системы. Обратный прокси здесь — это веб сервер Nginx, который сконфигурирован переадресовывать запросы в той или иной контейнер в зависимости от URL, а также предоставляющий HTTPS интерфейс для запросов извне. 58 Заключение В рамках данной работы решены все поставленные задачи: ● собраны и формализованы требования; ● система спроектирована; ● система разработана; ● система протестирована и внедрена. Таким образом, цель — разработать и внедрить систему для оценки персонала по методу «360 градусов» — достигнута. Система успешно встроена в рабочий процесс компании. Проблем в ходе эксплуатации не выявлено, события оценки проводятся регулярно. 59 Литература 1. Ларман К. Применение UML и шаблонов проектирования. / К. Ларман – Издательский дом «Вильямс», 2004. 620 с. 2. Уорд П. Метод 360 градусов. М.: ГИППО, 2006. 120 с. 3. Cockburn A. Writing Effective Use Cases. 1st ed. Addison-Wesley Professional, 2000. 304 pp. 4. Edwards, M.R. and Ewen, A.J. 360-Feedback: The Powerful New Model for Employee Assessment & Performance Improvement. AMACOM, New York, 2013 5. Fowler M. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002. 6. Gitlab User Guide [Электронный ресурс] // Gitlab [сайт]. 2019. URL: https://docs.gitlab.com/ (дата обращения: 30 апреля 2019). 7. jXLS documentation [Электронный ресурс] // jXLS [сайт]. 2019. URL: http://jxls.sourceforge.net (дата обращения: 28 апреля 2019). 8. Legendre P. The Kendall Coefficient of Concordance Revisited. Journal of Agricultural, Biological, and Environmental Statistics, 2005, Volume 10, Number 2, Pages 226–245 DOI: 10.1198/108571105X46642. 9. Peiperl M. Getting 360-Degree Feedback Right. Harvard Business Review, January 2001, 79(1):142-7, 177, PMID: 11189458. 10.Play 2.7.x documentation [Электронный ресурс] // Play Framework [сайт]. 2019. URL: https://www.playframework.com/documentation/2.7.x/Home (дата обращения: 15 января 2019). 11.RabbitMQ documentation [Электронный ресурс]. 2019. URL: https://www.rabbitmq.com/documentation.html (дата обращения: 21 марта 2019). 12.Saxena S. Mastering Play Framework for Scala. Packt Publishing, 2015. 60 13.Swagger documentation [Электронный ресурс] // Swagger [сайт]. 2019. URL: https://swagger.io/docs/ (дата обращения: 29 апреля 2019). 14.Torno W. Introduction to special issue on 360‐degree feedback. Human Resource Management, Summer/Fall 1993, vol. 32, no. 2, pp. 211-219. doi: 10.1002/hrm.3930320202. 15.Turnbull J. The Docker Book: Containerization is the new virtualization. / James Turnbull; 18092 edition, 2014. 61 Приложение А. Скриншоты интерфейса Редактирование профиля Список активных событий оценки 62 Процесс ответов на вопросы формы 63 Приложение Б. Скриншоты отчета Таблица компетенций График компетенций История значений компетенций 64 График изменения компетенций Детальный отчёт 65 Агрегированный отчет 66 Отчет о проверке на заимствования №1 Автор: Ильченко Егор zzodoo@gmail.com / ID: 2302102 Проверяющий: Ильченко Егор (zzodoo@gmail.com / ID: 2302102) Отчет предоставлен сервисом «Антиплагиат»- http://users.antiplagiat.ru ИНФОРМАЦИЯ О ДОКУМЕНТЕ № документа: 7 Начало загрузки: 14.05.2019 18:31:17 Длительность загрузки: 00:00:04 Имя исходного файла: магистерская Размер текста: 3435 кБ Cимволов в тексте: 58010 Слов в тексте: 7026 Число предложений: 466 ИНФОРМАЦИЯ ОБ ОТЧЕТЕ Последний готовый отчет (ред.) Начало проверки: 14.05.2019 18:31:22 Длительность проверки: 00:00:03 Комментарии: не указано Модули поиска: Модуль поиска Интернет ЗАИМСТВОВАНИЯ 5,95% ЦИТИРОВАНИЯ 0% ОРИГИНАЛЬНОСТЬ 94,05% Заимствования — доля всех найденных текстовых пересечений, за исключением тех, которые система отнесла к цитированиям, по отношению к общему объему документа. Цитирования — доля текстовых пересечений, которые не являются авторскими, но система посчитала их использование корректным, по отношению к общему объему документа. Сюда относятся оформленные по ГОСТу цитаты; общеупотребительные выражения; фрагменты текста, найденные в источниках из коллекций нормативно- правовой документации. Текстовое пересечение — фрагмент текста проверяемого документа, совпадающий или почти совпадающий с фрагментом текста источника. Источник — документ, проиндексированный в системе и содержащийся в модуле поиска, по которому проводится проверка. Оригинальность — доля фрагментов текста проверяемого документа, не обнаруженных ни в одном источнике, по которым шла проверка, по отношению к общему объему документа. Заимствования, цитирования и оригинальность являются отдельными показателями и в сумме дают 100%, что соответствует всему тексту проверяемого документа. Обращаем Ваше внимание, что система находит текстовые пересечения проверяемого документа с проиндексированными в системе текстовыми источниками. При этом система является вспомогательным инструментом, определение корректности и правомерности заимствований или цитирований, а также авторства текстовых фрагментов проверяемого документа остается в компетенции проверяющего. № Доля в отчете Доля в тексте Источник Ссылка Актуален на Модуль поиска Блоков в отчете Блоков в тексте 1,73% 0,91% 0,88% [01] 1,73% Методика оценки персонал… http://knowledge.allbest.ru раньше 2011 Модуль поиска Интернет 6 6 [02] 0,91% Модульное тестирование http://ru.wikipedia.org 09 Апр 2018 Модуль поиска Интернет 4 4 [03] 0,88% RabbitMQ tutorial 2 — Очере… http://habrahabr.ru 28 Окт 2014 Модуль поиска Интернет 6 6 Еще источников: 8 Еще заимствований: 2,43% |