Материал: Автоматизация обработки заявок Пенсионным Фондом РФ
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
76
Модуль Регистраций
Контекст: /registration
Карточка регистрации
GET
/{id}
Создать регистрацию
POST
/ + JSON
Изменить регистрацию
PUT
/{id} + JSON
Аннулирование регистрации
PATCH
/{id}/null
Удалить регистрацию
DELETE
/{id} + JSON
Модуль Экранных Форм
Контекст: /form
Выбор тематики и содержания
GET
/{id}
Форма регистрации(Новое заявление)
GET
/form/{formId}
Просмотр зарег. заявления
GET
/registration/{regId}
Изменение регистрации
GET
/registration/{regId}/edit
Просмотр результатов рассмотрения
GET
/result/{regId}
Изменить результат рассмотрения
PUT
/{id}/result/ + JSON
Модуль Поиска
Контекст: /search
Поиск по СНИЛС
POST
/snils/ + JSON
Поиск по анкетным данным
POST
/person/ + JSON
Поиск по документу
POST
/document/ + JSON
Модуль Статистики
Контекст: /stat
Статистика по тематикам
POST
/theme/ + JSON
Статистика по районам
POST
/areas/ + JSON
Статистика по пользователям
POST
/users/ + JSON
Модуль Интеграции
Контекст: /ext
Отправить в целевую подсистему
POST
/send/ + JSON
Установить статус заявлению
PUT
/result/ + JSON
Установить статус заявления
PATCH
/result/ + JSON
Модуль Печатных Форм
Контекст: /print
Получить печатную форму
GET
/form/{formCode}/{regId}
Веб-Клиент
Целевая подсистема
Информационно-справочный
модуль
Контекст: /cat
Получить справочник
GET
/{name}
Получить значение из справочника
GET
/{name}/{1}
Рисунок 22 Взаимодействие модулей приложения
77
2.3.4. Описание программных модулей
Главным модулем системы Фронт-офис, является модуль регистрации.
Именно его работа составляет целевой функционал системы. Работа модуля будет
осуществляться даже в отсутствие других модулей (например, аппаратный сбой),
а при регистрации из других систем (Единый Портал Государственных Услуг,
Личный Кабинет Пенсионного Фонда РФ) работа останется без изменений.
Модуль регистрации предназначен для сохранения регистрационных данных,
изменения таковых, удаления и чтения.
Модуль должен иметь простую структуру, исключающую сложные
программные ошибки, тупиковые ситуации либо сложно отлаживаемые участки
кода. Так же при проектировании следует придерживаться принципа
проектирования на уровне интерфейсов.
Для начала спроектируем ядро модуля. Класс RegistrationModule будет
являться интерфейсом ядра модуля Регистрации, которая определит базовые
методы для работы с регистрацией, а именно:
createRegistration – Создать новую регистрацию. Метод принимающий объект
имплементирующий интерфейс Registration – объект бизнес-данных. Метод
возвращает, в случае успеха, уникальный идентификатор - UUID. Если
регистрация будет неуспешной, метод обязан вернуть исключение
RegistrationException (не отображен на схеме).
updateRegistration – Изменить существующую регистрацию. Метод так же
принимает в качестве аргумента объект, имплементирующий Registration. Ничего
не возвращает в случае успешного сохранения. В случае с невозможностью
сохранить изменения, выбрасывает исключение RegistrationException.
Обязательным условием является указание идентификатора (поле id) в
передаваемом параметре registration. Если id регистрации не будет указан,
выбрасывается исключение RegistrationNotFoundException.
readRegistration – Получить объект регистрации из репозитория(БД). В
качестве параметра метод получает уникальный идентификатор – UUID. В
качестве результата возвращает объект имплементирующий интерфейс
78
Registration. В случае отсутствия регистрации с заданным UUID, метод
возвращает исключение RegistrationNotFoundException.
removeRegistration – Метод удаляющий регистрационную запись. Параметр,
аналогично методу получения регистрации, принимает в качестве аргумента
уникальный идентификатор обращения UUID. Не возвращает значений.
Выбрасывает исключение RegistrationNotFoundException в случае отсутствия
регистрационной записи с указанным идентификатором.
registrationActivity – Метод устанавливает признак аннулирования обращения.
Принимает 2 аргумента: уникальный идентификатор – UUID и признак
аннулирования. В случае с отсутствием регистрационной записи, аналогично
выбрасывает исключение RegistrationNotFoundException.
Все описанные методы являются CRUD-операциями
2
[8]. Исключение
составляет метод registrationActivity, который расширяет стандартный CRUD –
интерфейс. Метод был реализован в результате изменения бизнес требований в
процессе разработке. Так же служит примером гибкости архитектуры Фронт-
Офиса.
Интерфейс RegistrationModule имплементирует класс реализации –
RegistrationService. Переопределенные методы класса вызывают методы объекта,
имплементирующего интерфейс RegistrationRepository. Методы
RegistrationRepository – следующий слой абстракции, они схожи в названиях и
назначениях, но служат для работы непосредственно с базой данных. В текущей
реализации методы используют сторонний модуль объектно-реляционного
маппинга Hibernate, для доступа к записям к таблице «Регистрации».
Рисунок 23 Результат проектирования ядра модуля регистрации.
Следует понять, как клиентское приложение сможет получить доступ к
функциям модуля Регистрации.
Клиентское приложение является внешним по отношению к функциям ядра
модуля. Поэтому необходимо создать некий фасад для доступа. Так как
приложение ориентировано на работу с веб, для обеспечения доступа создадим
фасадный класс, представляющий собой REST контроллер. При необходимости
2
CRUD (сокр. от англ. create, read, update, delete — «создать, прочесть, обновить, удалить»)
79
изменения взаимодействия с модулем, потребуется только изменить фасадную
часть приложения.
RegistrationService
<<Интерфейс>>
RegistrationModule
UUID createRegistration(Registration
registration)
void updateRegistration(Registration
registration)
Registration readRegistration(UUID id)
void removeRegistration(UUID id)
void registrationActivity(UUID id, boolean
activity)
UUID createRegistration(Registration
registration)
void updateRegistration(Registration
registration)
Registration readRegistration(UUID id)
void registrationActivity(UUID id, boolean
activity)
<<Интерфейс>>
CrudRepository<T>
T findById(T)
void save(T)
void delete(T)
void removeRegistration(UUID id)
<<Интерфейс>>
RegistrationRepository<T>
active(T)
deactive(T)
Рисунок 23 Результат проектирования ядра модуля регистрации
REST-контроллер представляет собой внешний интерфейс при
взаимодействии с модулем. В его задачу должно входит принятие запроса от
клиента и подготовка ответа с последующей отправкой. Методы контроллера
реагируют на события методов возвращая ответ понятный клиенту.
Следует определить методы контроллера:
postRegistration – Зарегистрировать заявление. В названии метода указан
метод доступа до метода – POST. В качестве аргумента в теле запроса передается
объект в формате JSON. Специальный обработчик десериализует JSON объект в
экземпляр класса FoRegistration, имплементирующего интерфейс Registration и
содержащим в себе бизнес-данные о заявлении. Вызывает метод ядра модуля, тем
самым вызывая процесс регистрации заявления в системе. В случае успеха методу
возвращается уникальный идентификатор. Получив идентификатор метод
устанавливает код состояния HTTP
3
равным «201 Created», устанавливает в
3
«Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по
протоколу HTTP. Он представляет собой целое число из трёх десятичных цифр. Первая цифра указывает
80
заголовке ответа location url-адрес[14], маппированный на REST-метод чтения
регистрации (getRegistration), добавляя в конец адреса уникальный
идентификатор (например: http://front-
office.pfrf.ru/services/rest/api/registration/e57d0b3e-8aa9-41a6-88f5-923700a853d1).
В случае возвращения метода ядра исключения RegistrationException,
устанавливается код состояния HTTP равным «500 Internal Server Error»,
обозначающим внутреннюю ошибку сервера и возвращает ответ клиенту.
getRegistration – Метод возвращающий бизнес-данные по регистрации в виде
JSON объекта. Метод запроса GET. В качестве аргумента принимает уникальный
идентификатор, который указывается вместе с url адресом. При возникновении
исключительных ситуаций возвращает статусы: «404 Not Found» – при
RegistrationNotFound и «500 Internal Server Error» – при RegistrationException.
putRegistration – Метод позволяет изменить данные заявления. Принимает, в
теле запроса сериализованный JSON, методом PUT. Поведение аналогично
postRegistration. Возвращает : «404 Not Found» – при RegistrationNotFound и «500
Internal Server Error» – при RegistrationException.
deleteRegistration – использует метод DELETE. Ожидает от клиента id
заявления, который передается с url, аналогичто getRegistration. Безвозвратно
удаляет обращение. Возвращает аналогичные другим методам коды: «404» - при
RegistrationNotFoundException и «500 Internal Server Error» – при
RegistrationException.
patchRegistration – метод применяется для изменения активности заявления:
аннулировано / активно. Метод доступа PATCH. Возвращает аналогичные
deleteRegistration коды.
Рисунок 24 Взаимодействие контроллера и функций модуля визуализирует
спроектированное взаимодействие и отображает UML структуру взаимодействия
контроллера и ядра модуля.
Взаимодействие всех модулей, как и модуля регистрации, с ядрами модулей
будет построено по однотипной структуре. Методы класса связываются с URL-
на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на
английском языке, которая разъясняет человеку причину именно такого ответа.»
Источник: https://baza.diplomsite.ru/previewfile/1902