66
Продолжение таблицы № 7
Наименование
поля
Идентификатор
поля
Тип поля
Длина поля
Прочее
Дата решения
date
date
4 байт
Данные по
решению
data
jsonb
-
Справочники проектируются с учетом типовой структуры, так с ними будет
удобнее работать: читать, записывать, изменять, сокращается количество
повторяемого кода. Удалять записи из справочников запрещено, так как на запись
могут ссылаться неявным образом данные регистрации. Таковыми
справочниками являются: Страны Мира, Тематики, Адреса, Пользователи, Роли
пользователя, типы решений. При расширении системы, следует пытаться
применить, в первую очередь типовую структуру отраженную в Таблица № 8.
Таблица № 8
Наименование
поля
Идентификатор
поля
Тип
поля
Длина
поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный ключ
Название
записи
name
varchar
50
символов
Идентификатор
родительской
записи
parent_id
bigint
8 байт
Индексированное
поле
Активность
записи
is_active
boolean
1 байт
Внешний
идентификатор
записи
code
varchar
10
символов
Структура типового справочника
Так же в системе имеются типовые-расширенные справочники: Формы,
Документы, Территориальные органы, Печатные формы. Таблица № 9
отображает структуру таблицы «Формы»
67
Таблица № 9
Наименование
поля
Идентификатор
поля
Тип поля
Длина поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный
ключ
Название
формы
name
varchar
50 символов
Идентификатор
родительской
записи
parent_id
bigint
8 байт
Активность
записи
is_active
boolean
1 байт
Внешний
идентификатор
записи
code
varchar
10 символов
Данные формы
data
jsonb
-
Версия формы
version
integer
4 байт
Структура таблицы «Формы»
В Таблица № 10 представлена структура справочника «Документы»
Таблица № 10
Наименование
поля
Идентификатор
поля
Тип
поля
Длина
поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный ключ
Название
документа
name
varchar
50
символов
Идентификатор
содержания
обращения
parent_id
bigint
8 байт
Индексированное
поле
Активность
записи
is_active
boolean
1 байт
Структура таблицы «Документы»
Структура справочника «Территориальные органы» изображен в Таблица № 11
68
Таблица № 11
Наименование
поля
Идентификатор
поля
Тип
поля
Длина
поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный ключ
Наименование
территориального
органа
name
varchar
50
символов
Идентификатор
родительской
записи
parent_id
bigint
8 байт
Индексированное
поле
Внешний ключ
Активность
записи
is_active
boolean
1 байт
Внешний
идентификатор
записи
code
varchar
10
символов
Наименование
директора
director_name
varchar
100
символов
Наименование
бухгалтера
accountant_name
varchar
100
символов
Адрес
address
varchar
150
символов
Структура справочника «Территориальные органы»
Структура справочника «Печатные формы» отображает Таблица № 12
Таблица № 12
Наименование
поля
Идентификатор
поля
Тип поля
Длина поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный
ключ
Структура справочника «Печатные формы»
69
Продолжение таблицы № 12
Наименование
поля
Идентификатор
поля
Тип поля
Длина поля
Прочее
Название
печатной
формы
name
varchar
50 символов
Идентификатор
тематики
parent_id
bigint
8 байт
Внешний
ключ
Активность
записи
is_active
boolean
1 байт
Внешний
идентификатор
записи
code
varchar
10 символов
Идентификатор
содержания
address_id
bigint
8 байт
Внешний
ключ
Кроме типовых-расширенных таблиц, в базе данных существуют не типовые
системные таблицы: Аккаунты, Модель доступа. В Таблица № 13 отображена
структура справочника «Аккаунты»
Таблица № 13
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный ключ
Идентификатор
пользователя
user_id
bigint
8 байт
Внешний ключ
Имя учетной
записи
login
varchar
50
символов
Индексированное
поле
Пароль
password
bytea
50 байт
Неудачных
попыток входа
fail_count
int
4 байта
Структура справочника «Аккаунты»
70
Продолжение таблицы № 13
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Последний
удачный вход
date
timestamp
с учетом
часового
пояса
8 байт
Требования о
смене пароля
is_need_new_pwd
boolean
1 байт
Дата последней
смены пароля
last_pwd_date
date
4 байт
Учетная запись
заблокирована
is_block
boolean
1 байт
Индексированное
поле
В Таблица № 14 отображена структура справочника «Модель доступа»
Таблица № 14
Наименование
поля
Идентификатор
поля
Тип поля
Длина
поля
Прочее
Идентификатор
id
bigint
8 байт
Первичный ключ
Идентификатор
роли
role_id
bigint
8 байт
Указатель
модуля
module_handler
varchar
10 байт
Индексированное
поле
Признак
разрешения
is_alloy
boolean
1 байт
Структура справочника «Модель Доступа»
После проектирования таблиц необходимо определить взаимосвязь между
таблицами. Главным образом это касается таблиц с полями, связанных внешним
ключом с другими таблицами. Ошибка! Источник ссылки не найден.
изображает взаимосвязь таблиц проектного приложения.
71
register
idPK
theme_idFK
address_idFK
snils
patronymic
name
family
regnum
birthday
status
register_area_idFK
edit_date
register_date
receive_date
register_user_idFK
edit_user_idFK
is_active
data
D
document
idPK
register_idFK
document_idFK
seria
number
date
expire
org
data
* .. 1
D
result
idPK
register_idFK
result_idFK
date
data
1 .. 1
cat_result
idPK
name
parent_idFK
is_active
code
1..*
*..1
cat_address
idPK
name
parent_idFK
is_active
code
cat_themes
idPK
name
parent_idFK
is_active
code
1 .. *
cat_document
idPK
name
parent_idFK
is_active
code
cat_users
idPK
name
parent_idFK
is_active
code
1..*
cat_roles
idPK
name
parent_idFK
is_active
code
cat_forms
idPK
name
parent_idFK
is_active
code
1..1
data
version
cat_country
idPK
name
parent_idFK
is_active
code
*.. 1
cat_terorg
idPK
name
parent_idFK
is_active
code
director_name
accountant_name
address
account
idPK
login
password
fail_count
date
1..1
*.. 1
is_need_new_pwd
last_pwd_date
is_block
user_idFK
access
idPK
module_handler
is_allow
role_idFK
1 .. *
1..*
Рисунок 19 Взаимосвязь таблиц проектного приложения
72
2.3.3 Структурная схема пакета (дерево вызова процедур и программ)
При проектировании системы следует определить архитектуру приложения.
Приложение не должно быть монолитным и состоять из требуемого числа
изолированных (самостоятельных) модулей. Из известных миру классических
архитектур следует выбрать архитектуру, построенную на шаблоне
высоконагруженных систем – трехзвенная архитектура (Ошибка! Источник
ссылки не найден.).
В качестве клиента будет выступать веб-приложение, расположенное на
легковесном веб-сервере исполняемое на стороне пользователя.
Серверным слоем будет выступать серверное-приложение. В качестве языка
приложения необходимо использовать надежный типизированный язык высокого
уровня. Хорошим решением будет использовать язык Java, с подключением
фреймворка Spring Framework и паттерна «Внедрение зависимости», взамен Java
Enterprise Edition [11].
Слоем данных выступает реляционная база данных, отвечающая всем
предъявленным требованиям надежности и скорости.
Рисунок 20 Трехзвенная архитектура и взаимодействие звеньев
Клиентская часть может не иметь пользовательского интерфейса все действия
производятся REST запросами, например для взаимодействия с Фронт-Офисом с
Единым Порталом Государственных Услуг или Личным Кабинетом
Застрахованного Лица. Или иметь, в случае работы пользователей Пенсионного
Фонда, для которых предусмотрен графический интерфейс. Одной из
особенностей трехзвенной архитектуры является то, что клиент не привязывается
к определенной платформе или языку и может иметь любую структуру. Ошибка!
Источник ссылки не найден.Отображает примерную схему одностраничного
клиента на языке TypeScript с использованием каркаса Angular 5 и классическим
взаимодействием компонентов с внутренними сервисами, которые общаются с
сервером через сервисы REST[15].
Клиент
Rest
Сервер
JDBC
База данных
73
Структура серверной части не является монолитной и состоит из модулей, что
позволяет масштабировать проект в зависимости от нагрузки [14]. Состоит из
следующих модулей:
1. Модуль регистрации. Модуль отвечает за бизнес-данные которые могут
поступать из других модулей или систем. Осуществляет базовые(CRUD)
операции:
/Index.html
Модуль Статистики
Модуль регистрации
Компонент Регистрации
Компонент Выбора
Компонент
Выбора
Сервис Справочников
Сервис Регистраций
получить_справочник()
получить_справочник
(ид_родителя : int)
Сервер
Компонент формы
Компонент Выбора
Компонент Ввода
Компонент Даты
...
получить_форму
(ид_содержания : int)
Зарегистрировать
обращение(json)
JSON
Компонент Флаг
Компонент
Кнопка
...
...
Рисунок 21 Проектируемая структура клиентского приложения
а) Создание – обращения. Создание нового обращения, присвоение ему
уникального идентификационного номера. Создание обращения возможно с
использованием существующего. Пользователю совсем не обязательно заполнять
постоянные поля и имеется возможность заполнить новое обращение с
использованием ранее зарегистрированного и не имеющего отношения, в
предметном смысле, к существующему
б) Редактирование – позволяет изменять информацию существующих
обращений. После сохранения изменений номер идентифицируемого обращения
не изменяется. В целях обеспечения правомерности изменений, редактирование
должно журналировать мета данные о изменениях в обращении и пользователе
совершающим редактирование.
в) Удаление – физическое удаление информации об обращении из БД. Равно
как и для редактирования, должно журналировать мета данные о пользователе
74
совершающим удалении. Как дополнительная мера защиты обращение может
только помечаться удаленным, таким образом можно исключить случайное
удаление информации.
в) Просмотр(чтение) – вспомогательная функция модуля регистрации.
Предоставляет чтение информации об обращении(обращениях) из базы данных.
В прикладном смысле предоставляет клиенту чистые бизнес-данные.
2) Модуль пользовательских форм. Модуль предоставляет графическую форму
регистрации. Производит контроль над вводимой информацией.
3) Модуль поиска обращений. Модуль предоставляет программные средства для
поиска обращений по гражданам и основным реквизитам обращений.
4) Модуль формирования статистики. Прикладной инструмент для создания
отчетов по различным срезам. Позволяет автоматизировать анализ и
отчетность работы отделений.
5) Модуль Интеграции – Модуль передачи обращений в целевые подсистемы и
получения результатов рассмотрения.
6) Модуль авторизации и аутентификации – задачей модуля является
идентификация пользователя, авторизация в системе и определение прав
пользования
7) Модуль печатных форм – модуль предназначен для генерации выходных
документов, по представленным шаблонам. Шаблоны располагаются в
директории и легко изменяются. Это важно тогда, когда требования к
выходным документам изменяются.
8) Информационно-справочный модуль – задачей модуля является
централизованное управление справочниками: предоставление доступа
клиенту и другим модулям Фрон-офиса. При необходимости можно легко
переключить на взаимодействие данного модуля с независимой документо-
ориентированной базой данных(NOSQL
1
). При таком изменении нет опасения
1
NoSQL (англ. not only SQL, не только SQL), в информатике — термин, обозначающий ряд подходов,
направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей,
используемых в традиционных реляционных СУБД (https://ru.wikipedia.org/wiki/NoSQL)
75
«поломать» систему, так как внешние взаимодействие остается неизменным,
скрывая реализацию внутри модуля.
Каждый модуль должен представлять из себя REST сервис и выполняет только
свою задачу, предоставляя интерфейс для внешнего доступа и скрывая
реализацию внутри модуля. Таким разделением обуславливается высокая
надежность и отказоустойчивость в работе Фронт-Офис. На Ошибка! Источник
ссылки не найден. отображено взаимодействие сервисов между собой, клиентом
и целевой подсистемой.