АННОТАЦИЯ 3
Перечень условных обозначений, символов, сокращений, терминов 3
Введение 4
1 Анализ и проектирование 6
1.1 Функциональные требования 6
1.2 Нефункциональные требования 8
1.3 Модель предметной области 9
1.4 Архитектурно-значимые варианты использования 10
1.4.1 Выполнить заявку на регистрацию 10
1.4.2 Создать заявку для регистрации 12
1.4.3 Посмотреть список заявок сотрудника 13
2 Используемые для разработки технологии 14
2.1 Сервис управления заявками 14
2.1.1 Spring Framework 14
2.1.2 Язык программирования 15
2.1.3 Система автоматической сборки Gradle 15
2.1.4 Thymeleaf 16
2.1.5 Spring Cloud OpenFeign 17
2.1.6 Проект Lombok и библиотека MapStruct 18
2.2 АРМ 20
2.2.1 Google Web Toolkit 20
3 Разработка 22
3.1 Использованные шаблоны проектирования 22
3.1.1 Шаблон проектирования «Builder» (Строитель) 22
3.1.2 Шаблон проектирования «Registry» (Реестр) 23
3.1.3 Шаблон проектирования «Proxy» (Заместитель) 23
3.2 Разработка сервиса управления заявками 26
3.2.1 Model-View-Controller 26
3.2.2 Структура сервиса 27
3.2.3 Схема базы данных 28
3.2.4 Диаграмма классов 29
3.2.5 Процесс аутентификации сотрудника 31
3.2.1 Передача информации из контроллера в представление 33
3.2.2 Создание заявки на регистрацию 34
3.2.3 Обслуживание заявок на регистрацию 34
3.3 Интеграция в АРМ 37
3.3.1 Взаимодействие клиента и сервера 38
3.3.2 Управление событиями в GWT 41
3.4 Написание тестов 42
3.5 Пользовательский интерфейс 44
Заключение 47
Список использованных источников и литературы 48
В современном мире сложно представить себе компанию, которая не стремится к оптимизации своей деятельности и повышению эффективности работы. Одним из путей достижения этой цели является автоматизация процессов. Особенно актуальной автоматизация становится для крупных компаний. Они имеют больше возможностей для внедрения новых технологий, но в то же время сталкиваются с необходимостью управлять большим количеством бизнес-процессов одновременно. Если в небольшой компании руководитель может контролировать все процессы лично, то в крупной это становится практически невозможным.
Компания, о которой далее пойдет речь, занимается разработкой в области информационных технологий для финансового сектора, а также предоставляет платежные сервисы как физическим лицам, так и организациям.
Для обеспечения бесперебойной работы предоставляемых услуг в компании существует отдел сопровождения, который ответственен за выполнение широкого спектра задач. К примеру, сбор данных о конкретном переводе и осуществление разного рода операций над ним является типичным примером задачи сотрудника отдела сопровождения.
В целях сокращения накладных расходов, уменьшения вероятности возникновения ошибок и снижения необходимого времени на выполнение разного рода задач, в компании был разработан специальный АРМ. Он представляет из себя веб-приложение с различными веб-страницами и операциями на них. За каждой веб-страницей стоит определенная область ответственности со своим ограниченным набором операций. Операции нужны для выполнения бизнес-процессов. Например, если пользователю необходимо заблокировать перевод, то он может перейти на специальную веб-страницу в АРМ, найти запрашиваемый перевод и выполнить блокировку перевода через специальную форму операции.
Управление возможностями пользователей АРМ происходит через роли и привилегии учетной записи. Операции, доступные пользователю, зависят от привилегий его учетной записи. Если у пользователя есть привилегия для выполнения хотя бы одной операции на веб-странице, то он сможет перейти на нее. В противном случае веб-приложение покажет ошибку и не позволит ничего сделать. Из данного описания должно быть очевидно, что ролевая модель в АРМ имеет весомое значение.
Пользователь не может самостоятельно менять свои учетные данные. Для этого ему необходимо составить специальную заявку используя форму в ERS сервисе и дождаться ее выполнения.
Созданная заявка проходит несколько этапов согласований, после чего ее выполняет фоновая задача, запускающаяся с определенной периодичностью. Ее создал разработчик из команды не связанной с АРМ, вследствие чего возникли ряд трудностей. Фоновая задача была разработана на технологическом стеке, который не был привычен команде, разрабатывающей АРМ. В случае необходимости доработок, приходилось привлекать разработчиков из сторонних подразделений компании. Кроме того, фоновая задача не могла выполнять некоторые специфичные заявки. Обычно менее опытные сотрудники испытывают трудности на этапе составления заявки из-за незнания, какую информацию нужно предоставить и в каком виде это необходимо сделать. В свою очередь, руководители этих сотрудников тратили время на запрос информации о созданных заявках.
В связи с указанными проблемами и невозможностью предоставления API АРМ, в силу технических особенностей проекта, было принято решение о разработке отдельного сервиса, который упростил бы процесс создания заявок и в то же время обеспечил бы их выполнение. Исходя из этих целей был составлен перечень задач:
1) провести анализ требований;
2) спроектировать архитектуру сервиса;
3) разработать сервис;
4) разработать веб-страницы.
Решению поставленных задач посвящена данная выпускная квалификационная работа.
В рамках данной работы проведен анализ требований и спроектирован сервис. Была реализована архитектурно значимая функциональность сервиса управления заявками, а также расширена функциональность АРМ для работы с сервисом. Часть функциональности покрыта модульными тестами. На момент написания работы, сервис развернут в тестовом окружении, где проходит процесс тестирования, исправления ошибок и внесения косметических доработок. В дальнейшем предполагается доработать сервис добавив оставшиеся сценарии, а также внедрить сервис для отправки рассылок.
