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-
на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на
английском языке, которая разъясняет человеку причину именно такого ответа.»
81
адресами и методом их вызова (GET, POST, PUT, DELETE, PATCH) согласно
стилю REST[10]
<<Интерфейс>>
RegistrationModule
UUID createRegistration(Registration
registration)
void updateRegistration(Registration
registration)
Registration readRegistration(UUID id)
void removeRegistration(UUID id)
void registrationActivity(boolean activity)
RegistrationController
void postRegistration(FoRegistration
registration)
void putRegistration(FoRegistration
registration)
FoRegistration getRegistration(UUID id)
void patchRegistration(boolean activity)
void deleteRegistration(UUID id)
@RestController
Рисунок 24 Взаимодействие контроллера и функций модуля
В результате проектирования становится возможным написать реализацию
системы. Результат реализации представлен в приложении.
2.4. Контрольный пример реализации проекта и его описание
Исходные данные компьютер под управлением операционной системы
Windows 7. Созданы базы данных, автоматически установлены соответствующие
миграции (объекты базы данных). Приложение запущено. Учетная запись
оператора существует. В качестве точки входа используется адрес узла (URL).
Обратившимся лицом, является вымышленная гражданка Российской Федерации,
Тестова Тест Тестовна 1983 г.р., СНИЛС: 000-000-900 27, в связи с рождением
второго ребенка и возникшим правом на сертификат МСК.
Оператор открывает браузер и переходит на указанный адрес. Возникает окно
входа в систему изображенное на Ошибка! Источник ссылки не найден.
82
Рисунок 25 Форма авторизации пользователя
После входа пользователь переходит в главное меню. Ошибка! Источник
ссылки не найден. Ошибка! Источник ссылки не найден.отображает главное
меню приложения:
Рисунок 26 Главное меню приложения
Оператор выбирает «Новое Обращение» и переходит к в меню выбора
тематик. После выбора необходимой тематики. Оператор попадает на форму
регистрации изображенного на Ошибка! Источник ссылки не найден.:
83
Рисунок 27 Форма заявления
Так как Тестова Тест Тестовна уже обращалась в отделение, то данные ее
были сохранены. Оператор производит поиск по базе данных граждан. Для
этого нажимает кнопку «Поиск гражданина» и переходит к окну поиска
гражданина. В окне вводит данные о СНИЛС, нажимает кнопку «Искать». Поиск
нашел Тестову Т.Т. Окно поиска и результаты поиска представлены на Ошибка!
Источник ссылки не найден.
Рисунок 28 Окно результата поиска
При нажатии кнопки «Использовать». Данные о Тестовой Т.Т. попадают на
форму регистрации. После этого оператору остается заполнить данные о детях и
отметить некоторые пункты. Ошибка! Источник ссылки не найден.29
отображает процедуру ввода данных о детях.
Регистрация на этом завершена. Остается нажать кнопку «Сформировать»
Следует обратить внимание что данная процедура заняла несколько минут. Если
84
бы данные о гражданине не оказались в базе обращений - время заполнения
увеличилось бы незначительно.
Рисунок 29 Ввод данных о детях
После формирования заявления пользователь попадает в раздел управления
заявлением. Где может перейти к редактированию, отправке, печати выходных
форм, заявление под подпись. Стоит отметить, что система автоматически
отправляет заявление в целевую подсистему «ПС МСК» по нажатию кнопки
«Отправить в ЦП». После отправки редактирование заявления недоступно. Так
как целевая подсистема на тестовой площадке недоступна, рассмотрение такого
заявления занимает несколько рабочих дней и является неправомерным,
используется эмулятор целевой подсистемы. Ошибка! Источник ссылки не
найден. отображает станицу управления заявлением с положительным
результатом.
85
Рисунок 30 Карточка заявления с результатом рассмотрения
Специалист может распечатать расписку-уведомление, заявление о выдаче
сертификата МСК (Ошибка! Источник ссылки не найден.1), а после принятия
решения форму результата рассмотрения и данные о сертификате.
Рисунок 31 Заявление о выдаче государственного сертификата на МСК