ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9684| Title: | Модуль автоматизованого формування довідок та звітних документів у HR-системі державного закладу |
| Authors: | Оксамитна, Любов Павлівна Голуб, Данило Русланович |
| Keywords: | ВІЙСЬКОВИЙ ОБЛІК;КАДРОВИЙ ОБЛІК;ВІЙСЬКОВОЗОБОВ'ЯЗАНІ;АВТОМАТИЗАЦІЯ ПРОЦЕСІВ;HR-OFFICE;KOTLIN MULTIPLATFORM;POSTGRESQL;DOCKER. |
| Issue Date: | 10-Jun-2026 |
| Abstract: | В умовах стрімкої цифровізації, автоматизація внутрішніх процесів стає критично важливою для забезпечення життєдіяльності. Велика кількість паперової документації, необхідність перевірки актуальності персональних даних та регулярне формування звітних документів для державних органів створюють значне навантаження на HR-відділи. Метою кваліфікаційної роботи бакалавра є розробка та впровадження модуля автоматизованого формування довідок та звітних документів у складі HR-системи державного закладу. Однак, для реального робочого процесу цього недостатньо, що дозволяє оптимізувати процеси військового обліку. Це досягається шляхом автоматизації збору й актуалізації даних через інтеграцію із зовнішніми API, забезпечення зручного інтерфейсу для маніпулювання даними у форматі Excel-таблиць та впровадження механізму генерації документів (.docx, .pdf). Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. Практичне значення отриманих результатів полягає в розробці програмного комплексу HR-Office, що автоматизує процес формування кадрових документів військового обліку в закладах вищої освіти. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9684 |
| Appears in Collections: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Голуб Данило_КН-2201_2025-2026.pdf Restricted Access | 1.54 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Модуль автоматизованого формування довідок та звітних
документів у HR-системі державного закладу»
Виконав: студент 4 курсу, групи КН-2201
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
Освітня програма «Комп’ютерні науки та
(назва освітньої програми)
прикладне програмування»
Данило ГОЛУБ
Керівник Любов ОКСАМИТНА
(ім’я та прізвище)
Рецензент Сергій СТАСЬ
(ім’я та прізвище)
Черкаси 2026 року
2
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 122 – Комп’ютерні науки
Освітня програма Комп’ютерні науки та прикладне програмування
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
Юрій ТРИУС
« » 2026 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Голубу Данилу Руслановичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Модуль автоматизованого формування довідок та звітних документів у HR-системі
державного закладу
Керівник роботи Оксамитна Л.П., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «12» березня 2026 р. №56/03-03.
2. Строк подання студентом роботи « 08 » червня 2026 року.
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних.
Звіт з виробничої практики. Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналітичний огляд літературних та інших джерел.
4.2. Проєктування модуля автоматизованої генерації довідок та звітних документів.
4.3. Програмна реалізація та експериментальне дослідження системи.
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 62285-01.
5.2. Додаток Б. Текст програми.
5.3. Додаток В. Інструкція користувача.
5.4. Додаток Г. Апробація кваліфікаційної роботи бакалавра.
5.5. Презентація у вигляді 20 слайдів.
3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
консультанта завдання видав завдання прийняв
7. Дата видачі завдання 12.01.2026 р
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи бакалавра Строк виконання
етапів роботи Примітка
1 Видача завдання на кваліфікаційну роботу 12.01.2026 Виконано
бакалавра.
2 Аналіз літературних джерел, об’єкту та предмету Виконано
дослідження. до 08.02.2026
3 Написання теоретичного розділу кваліфікаційної Виконано
роботи бакалавра. до 23.03.2026
4 Написання аналітичного розділу (аналіз об’єкту
й предмету дослідження). до 06.04.2026 Виконано
5 Написання практичних розділів й висновків по Виконано
роботі. до 15.05.2026
6 Передзахист кваліфікаційної роботи бакалавра Виконано
на засіданні кафедри КНСА. 20.05.2026
7 Подання роботи завідувачу кафедри КНСА. до 10.06.2026 Виконано
8 Захист кваліфікаційної роботи бакалавра. 10.06.2026 Виконано
Студент Данило ГОЛУБ
(підпис)
Керівник роботи Любов ОКСАМИТНА
(підпис)
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 76 с., 22 рис., 6 таблиць, 29
використаних джерел, 4 додатки.
Актуальність теми. В умовах стрімкої цифровізації, автоматизація
внутрішніх процесів стає критично важливою для забезпечення життєдіяльності.
Велика кількість паперової документації, необхідність перевірки актуальності
персональних даних та регулярне формування звітних документів для державних
органів створюють значне навантаження на HR-відділи.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра
є розробка та впровадження модуля автоматизованого формування довідок та
звітних документів у складі HR-системи державного закладу. Однак, для реального
робочого процесу цього недостатньо, що дозволяє оптимізувати процеси
військового обліку. Це досягається шляхом автоматизації збору й актуалізації даних
через інтеграцію із зовнішніми API, забезпечення зручного інтерфейсу для
маніпулювання даними у форматі Excel-таблиць та впровадження механізму
генерації документів (.docx, .pdf).
Завдання кваліфікаційної роботи бакалавра:
− виконати аналіз існуючих підходів до автоматизованої генерації документів
та огляд систем-аналогів;
− спроєктувати архітектуру модуля генерації на основі патерну скінченного
автомата (FSM) та ланцюжка обробників;
− розробити алгоритм заповнення DOCX-шаблонів із збереженням
форматування засобами бібліотеки Apache POI [5];
− реалізувати механізм асинхронного сповіщення клієнта через Server-Sent
Events та підсистему валідації вхідних даних;
− розробити клієнтський десктопний додаток на Kotlin/Compose for Desktop
[14] з інтерфейсом для пошуку, фільтрації та ініціації генерації документів;
− провести контрольний приклад та підтвердити працездатність системи.
Об’єкт дослідження: процес автоматизованої генерації довідок та звітних
5
документів у HR-системі закладу вищої освіти.
Предмет дослідження: методи, моделі та програмні засоби реалізації модуля
автоматизованої генерації кадрових документів на основі скінченного автомата та
DOCX-шаблонів у клієнт-серверній архітектурі.
Методи дослідження: системний аналіз предметної галузі; порівняльний
аналіз існуючих підходів і систем-аналогів; методи об'єктно-орієнтованого
проєктування та архітектурних патернів (GoF [11], Clean Architecture [17]); методи
прикладної реалізації та інтеграційного тестування програмного забезпечення на
платформі Spring Boot [24] та Kotlin Multiplatform [16].
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л.
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована
HR-система закладу вищої освіти : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.];
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.
Черкаси : ЧДТУ, 2026. С. 14.
Практичне значення отриманих результатів полягає в розробці
програмного комплексу HR-Office, що автоматизує процес формування кадрових
документів військового обліку в закладах вищої освіти. Впровадження системи
дозволяє скоротити час генерації одного документа з 15–20 хвилин ручного
заповнення до менше, ніж 3 секунди автоматичної обробки, усунути помилки
ручного введення завдяки механізму валідації даних та забезпечити централізоване
зберігання інформації про студентів із веденням журналу усіх операцій.
Розроблений модуль скінченного автомата є універсальним і може бути
адаптований для генерації інших типів службових документів без модифікації
архітектурного ядра системи.
Ключові слова: ВІЙСЬКОВИЙ ОБЛІК, КАДРОВИЙ ОБЛІК,
ВІЙСЬКОВОЗОБОВ'ЯЗАНІ, АВТОМАТИЗАЦІЯ ПРОЦЕСІВ, HR-OFFICE, SPRING
6
BOOT, KOTLIN MULTIPLATFORM, POSTGRESQL, JWT, REST API, DOCKER.
ABSTRACT
The qualification work of bachelor contains: 76 pages, 22 figures, 6 tables, 29
sources used, 4 attachments.
Actuality of theme. In the conditions of rapid digitalization, the automation of
internal processes becomes critically important to ensure vital activity. A large amount of
paper documentation, the need to verify the relevance of personal data, and the regular
generation of reporting documents for government agencies create a significant burden
on HR departments.
The purpose of the work is the development and implementation of an automated
module for generating certificates and reporting documents as part of an HR system,
which allows optimizing the processes of military accounting. This is achieved by
automating the collection and updating of data through integration with external APIs,
providing a convenient interface for manipulating data in the format of Excel spreadsheets,
and implementing a mechanism for generating documents (.docx, .pdf)
Objectives of qualifying work:
− analyze existing approaches to automated document generation and review
similar systems;
− design the architecture of the generation module based on the finite state machine
(FSM) pattern and a chain of handlers;
− develop an algorithm for filling DOCX templates with formatting preservation
using the Apache POI library [5];
− implement a mechanism for asynchronous client notification via Server-Sent
Events and an input data validation subsystem;
− develop a client desktop application in Kotlin/Compose for Desktop [14] with an
interface for searching, filtering, and initiating document generation;
− conduct a test case and confirm the system's operability.
The object of research: the process of automated generation of certificates and
reporting documents in the HR system of a higher education institution.
7
The subject of research: methods, models and software tools for implementing a
module for automated generation of personnel documents based on a finite state machine
and DOCX templates in a client-server architecture.
Research methods: system analysis of the subject area; comparative analysis of
existing approaches and similar systems; methods of object-oriented design and
architectural patterns (GoF [11], Clean Architecture [17]); methods of application
implementation and integration testing of software on the Spring Boot [24] and Kotlin
Multiplatform [16] platforms.
Approbation of results. The main provisions and results of the bachelor's
qualification thesis were presented and discussed at the conference «Student Science Day
of the CNSA Department», 22 April 2026, Cherkasy, Ukraine.
Publications. Yu. O. Blagovisny, D. R. Holub, V. V. Dubrovny, D. O. Kjernus, L.
P. Oksamytna, A. P. Sinkovskiy, V. V. Oleksiuk. Automated HR information system of a
higher education institution : Collection of abstracts from the Cherkasy State
Technological University Student Scientific and Practical Conference: 22–23 April 2026 /
[edited by I. V. Melnyk]; Ministry of Education and Science of Ukraine, Cherkasy State
Technological University. Cherkasy : Cherkasy State Technological University, 2026. p.
14.
The practical significance of the obtained results lies in the development of the
HR-Office software system that automates the process of generating military registration
documents in higher education institutions. The implementation of the system reduces the
time required to produce a single document from 15–20 minutes of manual filling to less
than 3 seconds of automated processing, eliminates manual data entry errors through a
built-in validation mechanism, and provides centralised storage of student records with full
audit logging of all operations. The developed finite state machine module is universal and
can be adapted to generate other types of administrative documents without modifying the
core system architecture.
Keywords: MILITARY REGISTRATION, PERSONNEL RECORDS, MILITARY
SERVICE PERSONNEL, PROCESS AUTOMATION, HR-OFFICE, SPRING BOOT,
KOTLIN MULTIPLATFORM, POSTGRESQL, JWT, REST API, DOCKER.
8
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ ...... 10
ВСТУП ................................................................................................................................ 11
1 АНАЛІТИЧНИЙ ОГЛЯД ЛІТЕРАТУРНИХ ТА ІНШИХ ДЖЕРЕЛ ........................ 16
1.1 Предметна область та актуальність автоматизації документообігу в HR-
системах .......................................................................................................................... 16
1.2 Огляд існуючих підходів до генерації документів у програмних системах ...... 18
1.2.1 Методи управління станами в процесах документогенерації. ...................... 20
1.2.2 API-орієнтовані підходи та асинхронна обробка. .......................................... 22
1.3 Аналіз існуючих систем та рішень-аналогів у сфері HR-систем ........................ 23
1.3.1 Українські та регіональні рішення. .................................................................. 24
1.3.2 Відкрите програмне забезпечення та академічні розробки. .......................... 25
1.4 Критичний аналіз методів та алгоритмів розв'язання задачі ............................... 26
1.4.1 Патерн Strategy для підтримки кількох форматів виводу. ............................. 27
1.4.2 Методи валідації даних перед генерацією. ..................................................... 27
1.4.3 Підходи до зберігання та надання доступу до згенерованих документів. ... 28
1.4.4 Аудит операцій як складова якості системи. .................................................. 28
1.5 Провідні вчені та фахівці в галузі управління HR-процесами ............................ 28
Висновки до розділу 1 ................................................................................................... 30
2 ПРОЄКТУВАННЯ МОДУЛЯ АВТОМАТИЗОВАНОЇ ГЕНЕРАЦІЇ ДОВІДОК ТА
ЗВІТНИХ ДОКУМЕНТІВ ................................................................................................ 31
2.1 Постановка задачі проєктування ............................................................................ 31
2.2 Архітектура модуля генерації та клієнт-серверної взаємодії .............................. 33
2.3 Проєктування моделі даних та процесів керування станами .............................. 35
2.4 Проєктування підсистем шаблонізації, валідації та аудиту ................................ 37
Висновки до розділу 2 ................................................................................................... 39
3 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ЕКСПЕРИМЕНТАЛЬНЕ ДОСЛІДЖЕННЯ
СИСТЕМИ .......................................................................................................................... 41
3.1 Середовище розробки та стек технологій ............................................................. 41
9
3.2 Реалізація ключових компонентів .......................................................................... 42
3.2.1 Оркестрація процесу генерації. ........................................................................ 42
3.2.2 Управління переходами станів. ........................................................................ 43
3.2.3 Алгоритм заповнення DOCX-шаблону.. ......................................................... 43
3.2.4 Сервіс сповіщень у реальному часі.. ................................................................ 43
3.3 Сценарії використання та інтерфейс користувача ................................................ 44
3.3.1 Авторизація в системі. ....................................................................................... 44
3.3.2 Ініціація генерації документа. Генерація документа – основний бізнес-
сценарій модуля. ......................................................................................................... 45
3.3.3 Валідація даних перед генерацією. .................................................................. 46
3.3.4 Результат генерації............................................................................................. 47
3.4 Контрольний приклад .............................................................................................. 47
3.5 Безперервна інтеграція ............................................................................................ 49
Висновки до розділу 3 ................................................................................................... 49
ВИСНОВКИ ....................................................................................................................... 51
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .. .......................................................................53
ДОДАТОК А. Специфікація 482. ЧДТУ. 62285-01 ........................................................ 56
ДОДАТОК Б. Текст програми .......................................................................................... 58
ДОДАТОК В. Інструкція користувача ............................................................................ 66
ДОДАТОК Г. Апробація результатів кваліфікаційної роботи бакалавра ................... 73
10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
ЗВО – заклад вищої освіти;
ПЗ – програмне забезпечення;
БД – бази даних;
СКБД – система керування базами даних;
РНОКПП – реєстраційний номер облікової картки платника податків;
API – Application Programming Interface, програмний інтерфейс взаємодії;
REST – Representational State Transfer, архітектурний стиль веб-сервісів;
SSE – Server-Sent Events, механізм серверних подій у реальному часі;
FSM – finite state machine, скінченний автомат;
JWT – JSON Web Token, стандарт автентифікації на основі токенів;
MVVM – Model-View-ViewModel, архітектурний патерн інтерфейсу;
ORM – Object-Relational Mapping, об'єктно-реляційне відображення;
DI – Dependency Injection, ін'єкція залежностей;
DOCX – формат документів Microsoft Word на основі Open XML;
JSON – JavaScript Object Notation, формат обміну даними;
JSONB – бінарний формат зберігання JSON у PostgreSQL;
UUID – Universally Unique Identifier, універсальний унікальний ідентифікатор;
HTTP – HyperText Transfer Protocol, протокол передачі гіпертексту;
CRUD – Create, Read, Update, Delete, базові операції з даними;
CI/CD – Continuous Integration / Continuous Delivery, безперервна інтеграція та
доставка.
11
ВСТУП
Тема кваліфікаційної роботи бакалавра присвячена практичній задачі: зробити
роботу відділу кадрів швидшою та стабільнішою за рахунок автоматизованого
формування довідок і звітних документів. У поточній роботі кадрового підрозділу
багато часу витрачається не на складні рішення, а на повторювані операції:
перевірку картки студента, перенесення даних у шаблон, виправлення пропусків,
повторне формування документа. Саме ці операції і є основним об’єктом
автоматизації.
Актуальність теми. Актуальність теми кваліфікаційної роботи бакалавра
визначається прикладною потребою. Коли документи формуються вручну або у
напівавтоматичному режимі, з’являються типові труднощі: зайві кроки, випадкові
помилки в полях, різний результат при однакових вхідних даних, складність
пакетного друку. Для відділу кадрів це означає додаткове навантаження й витрату
часу. Тому, доцільно перейти до підходу, де система бере на себе рутинну частину
процесу, а користувач контролює лише ключові етапи.
Загальна оцінка сучасних існуючих проблем у даній предметній галузі. У
межах предметної галузі існують готові інструменти для шаблонізації та збереження
кадрових даних. Однак, для реального робочого процесу цього недостатньо.
Потрібна єдина схема, в якій поєднані: перевірка даних перед формуванням,
зрозумілий стан виконання задачі, підтримка DOCX/PDF, коректна обробка
помилок та зручна взаємодія через інтерфейс оператора. Для подібних систем
найчастіше виникають такі труднощі:
– по-перше, відсутність єдиних правил перевірки перед друком;
– по-друге, різні вимоги до різних типів документів;
– по-третє, складність пакетної обробки при частково неякісних даних;
– по-четверте, недостатня прозорість причин відмови;
– по-п'яте, неузгодженість між клієнтською і серверною частинами.
Серед провідних світових рішень у сфері HR-систем особливе місце займають
платформи SAP SuccessFactors [22], Oracle HCM Cloud [19] та Workday [28]. Кожна з
12
них містить модулі управління документами та звітності, проте їх реалізація
передбачає значні витрати на ліцензування та інфраструктуру, що робить їх
недоступними для більшості українських державних установ. На українському
ринку провідними розробниками HR-програмного забезпечення є компанія IT-
Enterprise [12] та система електронної звітності M.E.Doc [18]. Проте, жодна з цих
систем не вирішує комплексно задачу автоматизованого формування кадрових
документів за DOCX-шаблонами із підтримкою асинхронної обробки та явного
контролю стану задачі.
Світові тенденції. Світові тенденції у сфері автоматизації кадрового
документообігу мають практичний характер: системи відходять від ручного
заповнення, переходять до процесного формування документів, додають явний
контроль станів задач, посилюють валідацію вхідних даних та інтегрують механізми
сповіщення в реальному часі. Для управління складними процесами обробки
активно застосовується концепція скінченних автоматів (FSM) [23], а для
асинхронного сповіщення клієнта – механізм Server-Sent Events (SSE) [27]. Провідні
архітектори програмного забезпечення: Фаулер [9], Еванс [7], Мартін [17]
обґрунтовують перехід до явного моделювання станів і переходів у бізнес-процесах
як ключовий чинник підтримуваності та розширюваності системи.
Взаємозв'язок з іншими науковими роботами. Кваліфікаційна робота
бакалавра виконана на кафедрі комп'ютерних наук та системного аналізу (КНСА)
Черкаського державного технологічного університету відповідно до наукового
напряму кафедри в галузі проєктування та розробки інформаційних систем і
програмного забезпечення. Тематика роботи пов'язана з актуальними завданнями
автоматизації управлінських процесів у закладах вищої освіти (ЗВО) та цифрової
трансформації державних установ відповідно до програмних документів Кабінету
Міністрів України щодо розвитку електронного урядування.
Мета і задачі дослідження. Мета кваліфікаційної роботи бакалавра –
розробка та впровадження модуля автоматизованого формування довідок та звітних
документів у складі HR-системи державного закладу, що дозволяє оптимізувати
процеси військового обліку. Це досягається шляхом автоматизації збору й
13
актуалізації даних через інтеграцію із зовнішніми API, забезпечення зручного
інтерфейсу для маніпулювання даними у форматі Excel-таблиць та впровадження
механізму генерації документів (.docx, .pdf).
Для досягнення поставленої мети необхідно вирішити такі завдання:
– виконати аналіз існуючих підходів до автоматизованої генерації документів
та огляд систем-аналогів;
– спроєктувати архітектуру модуля генерації на основі патерну скінченного
автомата (FSM) та ланцюжка обробників;
– розробити алгоритм заповнення DOCX-шаблонів із збереженням
форматування засобами бібліотеки Apache POI [5];
– реалізувати механізм асинхронного сповіщення клієнта через Server-Sent
Events та підсистему валідації вхідних даних;
– розробити клієнтський десктопний додаток на Kotlin/Compose for Desktop
[14] з інтерфейсом для пошуку, фільтрації та ініціації генерації документів;
– провести контрольний приклад та підтвердити працездатність системи.
Об'єкт дослідження: процес автоматизованої генерації довідок та звітних
документів у HR-системі закладу вищої освіти.
Предмет дослідження: методи, моделі та програмні засоби реалізації модуля
автоматизованої генерації кадрових документів на основі скінченного автомата та
DOCX-шаблонів у клієнт-серверній архітектурі.
Методи дослідження: системний аналіз предметної галузі; порівняльний
аналіз існуючих підходів і систем-аналогів; методи об'єктно-орієнтованого
проектування та архітектурних патернів (GoF [11], Clean Architecture [17]); методи
прикладної реалізації та інтеграційного тестування програмного забезпечення на
платформі Spring Boot [24] та Kotlin Multiplatform [16].
Наукова новизна отриманих результатів. Розроблено архітектуру модуля
генерації кадрових документів, що поєднує: формальну модель скінченного
автомата для управління життєвим циклом задачі генерації; алгоритм run-by-run
заміни плейсхолдерів у DOCX-документах, що коректно обробляє розбиття тексту
на декілька XML-Run-об'єктів; декларативну конфігурацію маппінгу полів через
14
JSON-файли без перекомпіляції коду. Запропоноване рішення є практично
значущим для закладів вищої освіти державної форми власності з обмеженими
ресурсами та специфічними вимогами до кадрового документообігу.
Практичне значення отриманих результатів. Розроблений модуль
автоматизованого формування довідок та звітних документів у складі HR-системи
державного закладу впроваджено в складі системи HR-Office та перевірено на
реальних даних кадрового підрозділу.
Практичне значення полягає в розробці програмного комплексу HR-Office, що
автоматизує процес формування кадрових документів військового обліку в закладах
вищої освіти (ЗВО). Впровадження системи дозволяє скоротити час генерації одного
документа з 15–20 хвилин ручного заповнення до менше, ніж 3 секунди
автоматичної обробки, усунути помилки ручного введення завдяки механізму
валідації даних та забезпечити централізоване зберігання інформації про студентів із
веденням журналу усіх операцій. Розроблений модуль скінченного автомата є
універсальним і може бути адаптований для генерації інших типів службових
документів без модифікації архітектурного ядра системи.
Архітектура системи підтверджує свою розширюваність: додавання нового
типу документа потребує лише створення DOCX-шаблону та JSON-конфігурації без
зміни коду ядра. Закон України «Про захист персональних даних» [1] враховано при
проєктуванні підсистеми аудиту доступу до згенерованих документів.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро
Олександрович) «Інформаційна автоматизована HR-система закладу вищої освіти» в
День студентської науки кафедри КНСА посів 1 місце.
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л.
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована
HR-система закладу вищої освіти : Збірник тез доповідей студентської науково-
15
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.];
Міністерство освіти і науки України, Черкаський державний технологічний ун-т.
Черкаси : ЧДТУ, 2026. С. 14.
16
1 АНАЛІТИЧНИЙ ОГЛЯД ЛІТЕРАТУРНИХ ТА ІНШИХ ДЖЕРЕЛ
1.1 Предметна область та актуальність автоматизації документообігу в
HR-системах
Кадровий документообіг є невід'ємним елементом діяльності будь-якої
організації. Він охоплює сукупність процесів, пов'язаних зі створенням, обробкою,
зберіганням і передаванням офіційних документів, що регламентують трудові та
навчальні відносини між установою та її персоналом чи студентами. У закладах
освіти державного сектору, де діють жорсткі нормативні вимоги до форм і термінів
подання звітності, якість та швидкість формування таких документів безпосередньо
визначає ефективність роботи кадрових підрозділів.
Термін «HR-система» (від англ. Human Resources Information System, HRIS)
позначає клас програмних рішень, що автоматизують процеси обліку персоналу,
управління кадровою документацією та формування звітності. Каванаг та Джонсон
визначають HRIS як інтегровану систему, що поєднує бази даних з можливостями
обробки та оперативного доступу до інформації про персонал [15]. Таке визначення
підкреслює ключову функцію системи: не лише зберігати дані, а й ефективно
трансформувати їх у готові до використання документи.
Проблема автоматизації документообігу в кадрових системах набула
особливої гостроти в умовах цифрової трансформації державного управління. У
2020–2025 роках Кабінет Міністрів України прийняв низку програмних документів,
що закріпили курс на цифровізацію публічних послуг і впровадження електронного
урядування. Законом України «Про електронні документи та електронний
документообіг» (№ 851-IV) та «Про електронні довірчі послуги» (№ 2155-VIII)
встановлено правову основу для переходу від паперових до цифрових форм
документів, що стало передумовою для широкого впровадження автоматизованих
засобів їх генерації [3].
Ручне формування документів у кадрових підрозділах має ряд системних
недоліків:
17
– по-перше, значні часові витрати: заповнення одного комплекту документів
для студентів вимагає від 15 до 30 хвилин;
– по-друге, висока ймовірність «людського фактора»: помилки в реквізитах,
прізвищах, датах і номерах документів;
– по-третє, труднощі із підтримкою актуальності шаблонів при зміні
нормативної бази;
– по-четверте, відсутність простежуваності: немає єдиного журналу, в якому
фіксується, хто, коли і для кого сформував той чи інший документ.
На рівні прикладної інженерії задача автоматизованої генерації документів у
HR-системах розглядається в чотирьох вимірах:
– шаблонізація (підстановка значень у форми документів із збереженням
форматування);
– управління даними (забезпечення цілісності та актуальності даних);
– оркестрація процесу (координація послідовних етапів генерації, валідації та
збереження);
– безпека та аудит (контроль доступу та фіксація подій для забезпечення
простежуваності).
Таким чином, предметна область дослідження є технічно складною та
практично затребуваною. Вона поєднує підходи з теорії інформаційних систем,
програмної інженерії, управління документами та інформаційної безпеки, що
зумовлює необхідність комплексного аналітичного огляду існуючих підходів,
методів і рішень.
Кваліфікаційна робота бакалавра виконувалась у межах групового проєкту з
розробки HR-системи обліку військовозобов'язаних державного закладу освіти.
Груповий проєкт охоплює чотири взаємопов'язані модулі:
– «Модуль інтеграції та міграції даних для HR-системи обліку
військовозобов'язаних»;
– «Модуль обліку військовозобов'язаних в HR-системі державного закладу
освіти»;
– «Модуль автоматизованого формування довідок та звітних документів у
18
HR-системі»;
– «Модуль контролю доступу та базової безпеки у HR-системі військового
обліку».
Загальна архітектура групового проєкту наведена на рис. 1.1. У межах даної
роботи автором особисто розроблено модуль автоматизованого формування довідок
та звітних документів.
Рисунок 1.1 – Схема взаємозв'язку функціональних модулів у складі комплексної
HR-системи військового обліку
1.2 Огляд існуючих підходів до генерації документів у програмних
системах
Шаблонний підхід до генерації документів у програмних системах є найбільш
поширеним і добре дослідженим. Його суть полягає в попередньому визначенні
структури документа (шаблону) з місцями для підстановки змінних значень
19
(плейсхолдерів), які заповнюються в момент генерації на основі даних з
інформаційної системи.
У науковій літературі вирізняють кілька різновидів шаблонних підходів
залежно від формату вихідного документа (табл. 1.1):
– текстові шаблонні рушії (Thymeleaf, FreeMarker, Mustache, Jinja2)
орієнтовані на генерацію HTML або текстових файлів. Уоллс описує підхід
інтеграції шаблонних рушіїв із Spring Boot, що дозволяє швидко створювати веб-
додатки з динамічним вмістом [26];
– офісно-орієнтовані підходи (Apache POI, docx4j, JasperReports, iText)
забезпечують генерацію документів у форматах DOCX та PDF, що є стандартними
для офіційного документообігу.
Таблиця 1.1 – Порівняльна характеристика шаблонних підходів до генерації
документів
Підхід / Формат Формат. Підтр. Склад.
Бібліотека виводу збереж. DOCX інтегр.
Apache POI DOCX, Частково Так Середня
(XWPF) XLSX
docx4j DOCX, PDF Так Так Висока
JasperReports PDF, HTML, Так Ні Висока
XLSX
iText / OpenPDF PDF Так Ні Середня
Thymeleaf → PDF PDF (через CSS- Ні Низька
wkhtmltopdf) залежно
DOCX-шаблон + DOCX Так Так Низька
Placeholder API
Аналіз таблиці 1.1 свідчить про те, що для задачі генерації офіційних
документів у державних установах, де критично важливим є збереження
затвердженого форматування, найбільш прийнятним є підхід на основі DOCX-
шаблонів із заміною плейсхолдерів. Саме такий підхід реалізований у системі HR-
Office, де шаблон документа у форматі DOCX містить іменовані мітки у фігурних
20
дужках (наприклад, {{SURNAME}}, {{BIRTH_DATE}}), що замінюються
реальними даними студента в момент генерації.
Проте, шаблонний підхід має суттєве практичне обмеження: синхронізація
шаблону та моделі даних. Якщо в шаблоні з'являється новий плейсхолдер, а
відповідне поле в логіці підстановки не оновлено, то документ формуватиметься
некоректно. Для вирішення цієї проблеми в системі HR-Office застосовано JSON-
конфігурації маппінгу: файл MILITARY_REGISTRATION_NOTICE.json описує
відповідність між плейсхолдерами шаблону та полями DTO (об'єкту передачі
даних), що дозволяє декларативно змінювати маппінг без перекомпіляції коду.
1.2.1 Методи управління станами в процесах документогенерації. Процес
генерації складних документів рідко є атомарною операцією. Він включає кілька
послідовних фаз: збір даних, їх валідацію, заповнення шаблону, збереження
результату та надання доступу до файлу. Некероване виконання цих фаз у рамках
одного синхронного HTTP-запиту призводить до відомих проблем: тайм-аути при
великих документах, непрозорі помилки часткових збоїв, неможливість відновлення
після збою на конкретному кроці.
У сучасній практиці розробки програмних систем для управління складними
процесами активно застосовується концепція скінченних автоматів (Finite State
Machines, FSM).
Формально скінченний автомат визначається п'ятіркою:
M = (Q, Σ, δ, q₀, F),
де Q – множина станів,
Σ – вхідний алфавіт,
δ – функція переходів,
q₀ – початковий стан,
F – множина кінцевих станів [23].
У контексті документогенерації ця концепція реалізується шляхом
формалізації кожного кроку обробки, як окремого стану задачі.
У класичній праці «Design Patterns» Гамма, Хелм, Джонсон та Вліссідес
визначають патерн State як один з ключових для управління складними процесами:
21
«Дозвольте об'єкту змінювати свою поведінку, коли змінюється його внутрішній
стан. Об'єкт виглядатиме так, ніби змінив свій клас» [11]. Фаулер у праці «Patterns of
Enterprise Application Architecture» [9] розвиває ці ідеї у контексті побудови
корпоративних систем. Цей патерн є основою для реалізації task-based state flow у
розробленій системі.
У системі HR-Office модуль генерації документів побудовано на основі
скінченного автомата із визначеними станами, що охоплюють повний цикл обробки
задачі – від створення до завершення або фіксації помилки. Концептуальну модель
автомата наведено на рисунку 1.2. Кожному стану відповідає окрема дія: отримання
даних, валідація, заповнення шаблону або обробка помилок. Детальний опис станів,
матриця переходів та конкретна реалізація розглядаються в Розділі 2.
Рисунок 1.2 – Концептуальна модель скінченного автомата генерації
документа
Важливою особливістю обраного підходу є наявність явної матриці
22
дозволених переходів між станами. Будь-яка спроба здійснити нелегітимний перехід
призводить до генерації виключення, що унеможливлює порушення логіки обробки.
Дослідник Вернон у монографії «Implementing Domain-Driven Design» підтверджує,
що «явне моделювання станів і переходів у бізнес-процесах значно покращує
зрозумілість коду і спрощує виявлення дефектів» [25].
Альтернативним підходом є використання повнофункціональних
оркестраторів робочих потоків (Camunda BPM, Activiti, Apache Airflow), що
базуються на стандарті BPMN 2.0 [10]. Проте, для прикладних задач рівня одного
модуля повнофункціональний оркестратор є надмірним рішенням, збільшує
операційну складність і вимагає значних ресурсів для розгортання. У розробленій
системі обрано легший підхід, а саме: власна реалізація FSM на базі патерну State з
використанням механізму ін'єкції залежностей Spring Framework.
1.2.2 API-орієнтовані підходи та асинхронна обробка. Сучасні HR-системи,
як правило, будуються за клієнт-серверною архітектурою з REST API як основним
механізмом взаємодії. REST (Representational State Transfer) – архітектурний стиль,
запропонований Роєм Філдінгом у його дисертації 2000 року [8]. Ключовими
обмеженнями REST є: клієнт-серверна модель, відсутність збереження стану
(stateless), уніфікований інтерфейс та можливість кешування відповідей. Ці
принципи є стандартом де-факто для мікросервісних і монолітних систем.
Задача генерації документів все таки погано вписується в синхронну REST-
парадигму: генерація документа з великим шаблоном та складними даними може
тривати секунди, що перевищує типові тайм-аути клієнтів.
Для вирішення цієї проблеми застосовуються два підходи:
1) Long Polling: клієнт відправляє запит на ініціацію генерації, отримує
ідентифікатор задачі (taskId), а потім періодично опитує сервер щодо стану
виконання. Цей підхід вносить затримки та надлишкове навантаження на сервер;
2) Server-Sent Events (SSE): після ініціації задачі сервер сам надсилає клієнту
оновлення статусу через довготривале HTTP-з'єднання. Специфікація SSE визначена
у стандарті HTML Living Standard і підтримується всіма сучасними HTTP-клієнтами
[27]. Перевагою SSE порівняно з WebSocket є простота – SSE є однонаправленим
23
потоком від сервера до клієнта, що достатньо для сповіщень про стан задачі.
Порівняння синхронного та асинхронного підходів наведено на рисунку 1.3.
У системі HR-Office обрано SSE-підхід. Деталі його реалізації описано в
Розділі 2.
Рисунок 1.3 – Порівняння синхронного (Long Polling) та асинхронного (SSE)
підходів
1.3 Аналіз існуючих систем та рішень-аналогів у сфері HR-систем
Серед провідних світових рішень у сфері HR-систем особливе місце займають
платформи SAP SuccessFactors, Oracle HCM Cloud та Workday. Кожна з них містить
модулі управління документами та звітності, хоч їх реалізація суттєво відрізняється
за підходами.
SAP SuccessFactors є одним із найбільш поширених HR-рішень
корпоративного рівня, що використовується організаціями по всьому світу [22].
Модуль документообігу заснований на концепції «форм і маршрутів» (forms and
routing): адміністратор визначає шаблон форми та маршрут її затвердження, а
система автоматизує проходження форми по ланцюжку відповідальних осіб. Такий
підхід є потужним для управління затвердженнями, але є надмірно складним для
задачі простої генерації довідок за типовими шаблонами.
Oracle HCM Cloud забезпечує генерацію документів через інтегровану систему
24
звітності Oracle Business Intelligence Publisher (BI Publisher). BI Publisher дозволяє
визначати шаблони у форматах RTF або XSL-FO і генерувати документи у форматах
PDF, Excel, HTML [19]. Попри потужність рішення, його впровадження вимагає
ліцензування Oracle, значної конфігурації та компетентних фахівців Oracle-стеку,
що унеможливлює його застосування у невеликих державних установах.
Workday реалізує документогенерацію через механізм «Document Templates»,
де шаблони визначаються у форматі Rich Text та заповнюються даними через
Workday Report-as-a-Service [28]. Workday орієнтований на SaaS-модель та
передбачає постійну підписку, що є неприйнятним для більшості українських
державних установ з бюджетними обмеженнями.
Критична оцінка зазначених платформ свідчить: попри широкий функціонал,
вони є надмірно складними та дорогими для цільового сценарію державної установи
середнього розміру. Жодна з них не адаптована до специфіки українського
нормативного поля (форм звітності Міністерства освіти, вимог до військового
обліку тощо) без значної кастомізації.
1.3.1 Українські та регіональні рішення. На українському ринку провідними
вітчизняними рішеннями для автоматизації бізнес-процесів є продукти компаній IT-
Enterprise та M.E.Doc. IT-Enterprise розробляє комплексну ERP-систему, що включає
модуль каднового обліку з формуванням стандартних кадрових документів. Система
підтримує генерацію наказів, довідок та звітів за шаблонами Microsoft Word з
використанням механізму COM Automation [12]. Недоліком такого підходу є
прив'язка до Microsoft Office на стороні сервера, що суттєво ускладнює розгортання
системи в Linux-середовищах та сучасній хмарній інфраструктурі.
M.E.Doc – спеціалізована система електронної звітності, призначена
насамперед для подання звітності до податкових органів, а не для повноцінного HR-
документообігу [18]. Інші рішення на ринку (наприклад, MASTER:Кадри або хмарні
HRM-системи, такі як Hurma та PeopleForce) орієнтовані переважно на комерційний
сектор і вимагають значної кастомізації під потреби державних установ. За оцінками
галузевих оглядів [2], значна частина державних установ України продовжує
використовувати таблиці Excel як основний інструмент кадрового документообігу,
25
що свідчить про суттєву незаповнену нішу для сучасних веб-орієнтованих рішень.
1.3.2 Відкрите програмне забезпечення та академічні розробки. Серед
відкритих рішень для роботи з документами особливу увагу привертає бібліотека
Apache POI – Java API для читання та запису файлів у форматах Microsoft Office.
Apache POI є де-факто стандартом для роботи з DOCX та XLSX у Java-екосистемі
[5]. Бібліотека надає низькорівневий API для маніпуляції елементами документа
(абзаци, комірки, параграфи), що забезпечує повний контроль над форматуванням.
Практичним викликом при використанні Apache POI XWPF є проблема розділених
runs: Word може зберігати текст одного плейсхолдера у кількох окремих run-
об'єктах. Підходи до вирішення цієї проблеми розглянуто в підрозділі 1.4.
Альтернативним інструментом для роботи з форматом DOCX є бібліотека
docx4j, яка пропонує розширені можливості порівняно з Apache POI. Платформа
забезпечує прямий доступ до внутрішньої архітектури Open Office XML (OOXML)
та містить готові засоби для перетворення DOCX у PDF. Як зазначається у джерелі
[6], архітектура docx4j спирається на строгу модель OOXML. Хоча це і дозволяє
здійснювати максимально точний контроль над структурою документації, такий
підхід зумовлює вищий поріг входження для інженерів і може ускладнювати
реалізацію базових операцій із документами.
Для генерації PDF-документів широко використовуються бібліотеки iText
(комерційна) та OpenPDF (відкрита fork-версія). iText 7 підтримує стандарт PDF/A
для архівного зберігання документів – важлива вимога для офіційного
документообігу [13]. В академічному середовищі задача автоматизованої генерації
документів у HR-системах вивчається у контексті ширших тем документ-
менеджменту та управління бізнес-процесами. Ричардсон у монографії з
мікросервісних патернів описує підхід виокремлення функцій формування
документів у незалежний сервіс зі стандартизованим API, що забезпечує
масштабованість та незалежне розгортання. Такий підхід доцільний для великих
організацій, але для систем рівня одного закладу створює надмірну інфраструктурну
складність.
26
1.4 Критичний аналіз методів та алгоритмів розв'язання задачі
Для реалізації послідовних етапів обробки задачі в модулі генерації
документів застосовано архітектурний патерн Chain of Responsibility (Ланцюжок
обов'язків). Патерн визначений в класичній праці «банди чотирьох» (GoF): Гамма,
Хелм, Джонсон, Вліссідес – як такий, що «дозволяє передати запит уздовж
ланцюжка обробників, кожен із яких вирішує, чи обробляти запит самостійно, чи
передавати далі» [11]. У контексті документогенерації цей патерн дозволяє
розподілити процес на незалежні етапи: збір даних, валідацію, заповнення шаблону
та збереження результату (рисунок 1.4).
Рисунок 1.4 – Архітектура ланцюжка обробників у модулі генерації
Практичне застосування цього патерну передбачає створення єдиного
інтерфейсу обробника з методами ідентифікації стану та безпосередньої обробки.
Диспетчер (оркестратор) збирає всі реалізації обробників через механізм ін'єкції
залежностей і маршрутизує задачу до відповідного обробника за її поточним станом.
Кожен обробник виконує одну функцію: збір даних, перевірку їх якості або
генерацію файлу. Конкретна реалізація цього підходу в системі HR-Office детально
розглядається в Розділі 2.
27
Такий підхід реалізує принцип «відкритості/закритості» (Open/Closed
Principle) з SOLID-принципів [17]: система є відкритою для розширення (додавання
нового типу документа не потребує зміни оркестраційного коду) та закритою для
модифікації (ядро ланцюжка обробки залишається незмінним).
1.4.1 Патерн Strategy для підтримки кількох форматів виводу. Для
підтримки кількох форматів вихідних документів (DOCX, PDF) у системі
застосовано патерн Strategy (Стратегія). За цим патерном визначається єдиний
інтерфейс генератора документів із методами перевірки сумісності з форматом та
безпосередньої генерації. Конкретні реалізації інкапсулюють логіку роботи з
відповідними бібліотеками. Обробник заповнення шаблону отримує всі реалізації
через механізм ін'єкції залежностей, знаходить потрібну за типом формату і делегує
генерацію. Така архітектура дозволяє додавати нові формати без зміни
оркестраційного коду.
Генерація DOCX-документів потребує спеціалізованого підходу через
особливості внутрішньої структури формату Open XML. Microsoft Word може
розбивати текст одного плейсхолдера на кілька Run-об'єктів у XML-структурі
файлу, що унеможливлює просту заміну рядка. Для подолання цієї проблеми
використовується алгоритм run-by-run злиття, який об'єднує текст параграфа,
знаходить плейсхолдер у зведеному рядку та підставляє значення зі збереженням
оригінального форматування. Блок-схему алгоритму та деталі реалізації наведено в
Розділі 2 (рисунок 2.4).
1.4.2 Методи валідації даних перед генерацією. Однією з найважливіших
складових процесу документогенерації є валідація вхідних даних. Формування
документа з неповними або некоректними даними є гіршим результатом, ніж
відмова від генерації з чітким повідомленням про проблему. У програмній інженерії
розрізняють два рівні валідації: синтаксичну (перевірка формату та типу даних) та
семантичну (перевірка змістової правильності значень у контексті бізнес-правил).
У системі валідація реалізована як окремий етап ланцюжка обробки, що
делегує перевірку спеціалізованому сервісу. Сервіс повертає структуровану
відповідь – агрегацію результатів для кожного правила. Архітектура забезпечує
28
легке розширення: додавання нових правил зводиться до створення нового методу
та його включення до списку валідацій. У разі виявлення помилок система
повідомляє клієнта через механізм асинхронних подій та зупиняє генерацію.
1.4.3 Підходи до зберігання та надання доступу до згенерованих
документів. Після успішної генерації документа постає питання про його
зберігання та надання доступу користувачу. Існує три основні підходи:
– зберігання в базі даних (BLOB) є простим у реалізації, транзакційним та не
потребує додаткової інфраструктури, але створює значне навантаження на БД;
– зберігання у файловій системі сервера є простим, але не масштабується при
горизонтальному розгортанні;
– об'єктне сховище (AWS S3, MinIO, Google Cloud Storage) є де-факто
стандартом для хмарних систем, але потребує налаштування додаткового
компонента [21].
У системі HR-Office обрано зберігання у файловій системі сервера: шлях до
директорії конфігурується через параметри додатку, файл іменується за унікальним
ідентифікатором задачі, а шлях зберігається у відповідному полі сутності Task у базі
даних. Клієнт завантажує документ через окремий GET-ендпоінт із коректними
HTTP-заголовками.
1.4.4 Аудит операцій як складова якості системи. Забезпечення
простежуваності дій є невід'ємною вимогою до кадрових систем, що обробляють
чутливі персональні дані. У системі реалізовано підсистему журналювання, що
зберігає записи аудиту у реляційній базі даних. Кожен запис фіксує тип дії, тип
сутності, ідентифікатор та деталізований опис. Підсистема також надає можливість
перегляду історії операцій. Такий підхід відповідає вимогам Закону України «Про
захист персональних даних» [1]. Деталі реалізації розглянуто в Розділі 2.
1.5 Провідні вчені та фахівці в галузі управління HR-процесами
Задача автоматизації документообігу та управління HR-процесами
знаходиться на перетині кількох наукових напрямів і має широке коло дослідників.
29
Мартін Фаулер (Martin Fowler) є одним з найвпливовіших архітекторів
програмного забезпечення, чиї роботи з корпоративних патернів [9] заклали основу
для проєктування бізнес-систем. Ерік Еванс (Eric Evans) у монографії «Domain-
Driven Design» [7] запропонував підхід до моделювання складних бізнес-доменів,
що безпосередньо застосовується при проектуванні HR-модулів.
Еріх Гамма, Річард Хелм, Ральф Джонсон, Джон Вліссідес («банда
чотирьох», GoF) – автори фундаментальної праці «Design Patterns: Elements of
Reusable Object-Oriented Software» [11], патерни якої (State, Chain of Responsibility,
Strategy) становлять основу для архітектурних рішень у модулі генерації документів
системи HR-Office.
Рой Філдінг (Roy Fielding) – дослідник, який у 2000 році визначив принципи
REST [8] і тим самим заклав підґрунтя для розробки API сучасних HR-систем, у
тому числі клієнт-серверного інтерфейсу системи HR-Office.
В Україні дослідженнями в сфері HR-інформаційних систем та автоматизації
державного документообігу займається чимало вчених, зокрема, Юрій Триус
(ЧДТУ), який розвиває напрям адаптивних навчальних систем та моделей
управління в освіті [4], а також дослідники Академії державного управління, що
вивчають проблеми цифрової трансформації державних установ.
На рівні провідних фірм у сфері інструментів розробки документних систем
слід відзначити Apache Software Foundation (бібліотеки POI, PDFBox), iText Group
(iText PDF), JasperSoft (JasperReports), а також вітчизняну компанію SoftServe, що
публікує прикладні дослідження у сфері HR Tech для українського ринку.
Сучасна практика розробки програмного забезпечення передбачає
застосування методології безперервної інтеграції (Continuous Integration, CI). За
визначенням М. Фаулера, CI – це практика, при якій кожна зміна у кодовій базі
автоматично перевіряється шляхом збірки та запуску тестів, що дозволяє виявляти
дефекти на ранніх етапах розробки [9]. У контексті системи HR-Office цей підхід
реалізовано через платформу GitLab CI/CD.
30
Висновки до розділу 1
У розділі виконано аналітичний огляд літературних та інших джерел
предметній галузі автоматизованої генерації документів у HR-системах.
Дослідження охоплювало теоретичні підходи, відкрите програмне забезпечення,
комерційні рішення та академічні розробки, а також аналіз реалізованого MVP
системи HR-Office.
Проведений огляд засвідчив, що задача автоматизованої генерації кадрових
документів є багатогранною та охоплює питання шаблонізації (вибір бібліотек і
форматів), управління складними процесами (FSM, патерн Chain of Responsibility),
API-проектування (REST, SSE), валідації даних та аудиту. Аналіз існуючих аналогів
показав, що глобальні корпоративні HR-платформи (SAP SuccessFactors, Oracle
HCM, Workday) є надмірно складними та фінансово недоступними для більшості
державних установ України. Наявні вітчизняні рішення або орієнтовані на Windows-
середовище з використанням COM Automation, або не охоплюють повного циклу
документогенерації.
Критичний аналіз методів виявив ключові вимоги до ефективного модуля
генерації документів: застосування DOCX-шаблонів із плейсхолдерами та
алгоритмом run-by-run злиття для збереження затвердженого форматування
офіційних форм; реалізація явного ланцюжка станів обробки задачі на основі FSM з
матрицею дозволених переходів; дворівнева валідація з розмежуванням критичних і
некритичних полів; асинхронна обробка з механізмом SSE для повідомлення
клієнта; розширювана архітектура на основі патернів Handler Chain і Strategy для
підтримки нових типів та форматів документів без зміни ядра системи.
Актуальність постановки задачі підтверджується відсутністю на ринку
доступного, клієнт-серверного, відкритого рішення для автоматизованої генерації
кадрових документів, яке б відповідало специфіці українського нормативного
середовища та могло бути розгорнуто в державній установі без залежності від
комерційного програмного забезпечення. Обґрунтовано вибір об'єкта і предмета
дослідження.
31
2 ПРОЄКТУВАННЯ МОДУЛЯ АВТОМАТИЗОВАНОЇ ГЕНЕРАЦІЇ
ДОВІДОК ТА ЗВІТНИХ ДОКУМЕНТІВ
Другий розділ присвячений проєктуванню модуля автоматизованої генерації
довідок та звітних документів у складі HR-системи державного закладу. Завданням
проєктування є перетворення вимог, визначених у результаті аналітичного огляду, в
конкретні архітектурні та програмні рішення. У розділі сформульовано постановку
задачі, визначено архітектуру модуля, спроєктовано модель даних і модель
життєвого циклу задачі генерації, а також описано підсистеми шаблонізації,
валідації та аудиту.
Проєктні рішення враховують специфіку предметної області: формування
кадрових документів установленого зразка, де важливими є збереження
затвердженого форматування; коректність персональних даних та відповідність
нормативним вимогам. Модуль спроєктовано з орієнтацією на розширюваність
(додавання нових типів документів без зміни ядра), надійність (контрольований
ланцюжок виконання із фіксацією помилок) та простежуваність (аудит кожної
операції генерації).
2.1 Постановка задачі проєктування
Проєктування модуля автоматизованої генерації довідок та звітних документів
у складі HR-системи державного закладу ґрунтується на необхідності забезпечити
повний цикл формування кадрових документів – від ініціювання запиту
користувачем до отримання готового файлу у затвердженому форматі. На відміну
від монолітних рішень, де генерація виконується як одна непрозора операція, в
розробленій системі процес розкладається на керований ланцюжок етапів із
формалізованими станами, валідацією на кожному кроці та асинхронним
сповіщенням клієнта про результат.
Постановка задачі проєктування визначається трьома ключовими вимогами.
По-перше, система повинна підтримувати генерацію документів різних типів
32
(довідка про навчання, повідомлення до ТЦК) на основі єдиного архітектурного
механізму без дублювання логіки для кожного типу.
По-друге, процес генерації має бути прозорим і контрольованим: кожен етап
обробки задачі повинен мати чітко визначений стан, а переходи між станами –
підлягати формальній перевірці.
По-третє, система має забезпечувати збереження затвердженого
форматування офіційних документів, що виключає використання генераторів на
основі HTML-to-PDF конвертерів і вимагає прямої маніпуляції DOCX-структурою.
Додатковою вимогою є інтеграція модуля генерації з підсистемою аудиту для
забезпечення простежуваності операцій та з механізмом SSE (Server-Sent Events) для
асинхронного зворотного зв'язку з клієнтським додатком. Таким чином, задача
проєктування охоплює не лише алгоритми генерації файлів, а й архітектуру
оркестрації, валідації, зберігання та доставки результатів.
Метою проєктування є створення модульної, розширюваної архітектури
підсистеми генерації документів, яка забезпечує коректне формування файлів із
динамічними даними студентів. Межі проєктування охоплюють серверну частину
системи, реалізовану на Spring Boot [24] з використанням PostgreSQL як СКБД [20].
До складу проєктного рішення входять: модель даних (сутності Task, Student,
AuditLog), API-контракти, архітектура ланцюжка обробки, стратегія генерації
файлів, механізм маппінгу плейсхолдерів та підсистема обробки подій.
Критерії успішності проєктування визначено наступним чином:
функціональна коректність (документ відображає актуальні дані), процесна
надійність (послідовний ланцюжок станів NEW → COMPLETED/FAILED),
валідаційна повнота (відмова системи при відсутності необхідних полів),
розширюваність архітектури та наявність простежуваності через аудит.
Базовим функціональним сценарієм модуля є генерація документа за запитом
користувача. Користувач ініціює генерацію у клієнтському додатку, сервер створює
задачу (Task) зі станом NEW і повертає її ідентифікатор. Далі клієнт підписується на
потік сповіщень (SSE) для відстеження прогресу. Обмеженнями предметної області
є суворо затверджений формат нормативних документів, необхідність обчислення
33
похідних полів (наприклад, статусу військового обліку) і специфіка роботи з DOCX-
форматом, що вимагає розробки власного алгоритму злиття тексту при підстановці
значень.
2.2 Архітектура модуля генерації та клієнт-серверної взаємодії
Серверна частина системи HR-Office побудована на платформі Spring Boot
(Java 23) [24] з використанням Spring Data JPA для роботи з СКБД PostgreSQL.
Архітектура відповідає принципам багатошарового проєктування з розмежуванням
відповідальності: API-контролери, сервісний рівень, репозиторії доступу до даних та
доменна модель. Модуль генерації документів реалізовано як окремий пакет
ua.edu.chdtu.hr.document із внутрішньою архітектурою на основі патернів,
обґрунтованих у Розділі 1 (State, Chain of Responsibility, Strategy) [11]. Структуру
пакетів модуля наведено на рисунку 2.1.
Структурно модуль складається з пакетів (рисунок 2.1): handler (обробники
станів), orchestration (диспетчер StateHandlerProxy), policy (матриця дозволених
переходів), strategy (генератори файлів), service (DocumentService, LabelService,
SseService, AuditService, TaskValidationService, TransitionService), event (подієвий
механізм TransitionEvent) та repository (доступ до бази даних із песимістичним
блокуванням).
Рисунок 2.1 – Структура пакетів модуля генерації документів
Взаємодія між компонентами побудована за принципом слабкого зчеплення.
Оркестратор StateHandlerProxy не залежить від деталей реалізації обробників. Для
зв'язку між етапами використовується компонент TransitionService, який валідує
34
перехід через StateTransitionPolicy, зберігає новий стан задачі та публікує подію
TransitionEvent через механізм Spring ApplicationEventPublisher. Подію перехоплює
TransitionEventListener і делегує обробку наступному StateHandler через
StateHandlerProxy. Послідовність взаємодії компонентів при генерації документа
наведено на рисунку 2.2.
Рисунок 2.2 – Послідовність взаємодії компонентів при генерації документа
Зовнішня взаємодія між десктопним клієнтом (Kotlin Multiplatform, Compose
Desktop) та сервером побудована на REST API із версіонуванням (/api/v1/). Операція
генерації розділена на дві фази: синхронна ініціація (сервер повертає taskId) та
асинхронне спостереження через SSE-потік. Ключові ендпоінти наведено в табл. 2.1.
Таблиця 2.1 – Специфікація REST API модуля генерації документів
Ендпоінт Метод Опис Відповідь
/students/{id}/documents/{type} GET Ініціація 200: {taskId}
генерації
/students/documents/{taskId}/stream GET SSE-потік 200: text/event-
стану stream
/students/documents/{taskId}/download GET Завантаження 200:
файлу application/octet-
stream
35
2.3 Проєктування моделі даних та процесів керування станами
Основою модуля автоматизованої генерації довідок та звітних документів є
модель даних і механізм керування життєвим циклом задачі. Контекст генерації
документа поєднує персональні дані студента, шаблон документа, обчислені
значення плейсхолдерів та службову інформацію про стан обробки.
Модель даних модуля включає три ключові сутності: Task (задача генерації),
Student (дані студента) та AuditLog (журнал аудиту). Зв'язки між сутностями
наведено на ER-діаграмі (рисунок 2.3). Сутність Task є центральною: вона зберігає
ідентифікатор задачі, стан, тип документа і формат, посилання на студента, JSON-
словник обчислених значень та шлях до сформованого файлу (таблиця 2.2).
Рисунок 2.3 – ER-діаграма моделі даних модуля генерації
36
Таблиця 2.2 – Структура сутності Task
Поле Тип Призначення
id UUID Унікальний ідентифікатор задачі
state State (enum) Поточний стан задачі в ланцюжку обробки
format DocumentFormat Формат вихідного документа (DOCX/PDF)
documentType DocumentType Тип документа для генерації
studentId Long Ідентифікатор студента
payload JSONB Словник підстановок (плейсхолдер → значення)
filePath String Шлях до згенерованого файлу (якщо успішно)
failureReason String Причина невдалої генерації
Життєвий цикл задачі генерації реалізовано як скінченний автомат (Finite State
Machine, FSM) [23] із шістьма станами: NEW, DATA_FETCHING, VALIDATE,
FILLING_TEMPLATE, COMPLETED та FAILED. Матриця дозволених переходів
закріплена в компоненті StateTransitionPolicy (Таблиця 2.3).
Таблиця 2.3 – Матриця дозволених переходів станів задачі
Поточний стан Дозволені переходи
NEW DATA_FETCHING, FAILED
DATA_FETCHING VALIDATE, FAILED
VALIDATE FILLING_TEMPLATE, FAILED
FILLING_TEMPLATE COMPLETED, FAILED
COMPLETED (кінцевий стан)
FAILED (кінцевий стан)
Рисунок 2.4 – Діаграма станів задачі генерації документа
37
Спроба здійснити перехід, не передбачений матрицею (наприклад, з
COMPLETED до DATA_FETCHING), спричиняє виключення IllegalStateException.
Для захисту від конкурентних конфліктів StateHandlerProxy використовує метод
findWithLockById репозиторію TaskRepository, що виконує SQL-запит SELECT ...
FOR UPDATE і блокує запис задачі до завершення транзакції.
Для практичної реалізації обробки кожного стану спроєктовано ланцюжок
обробників (на основі патерну Chain of Responsibility)[11]. Отримавши подію з
ідентифікатором задачі, оркестратор визначає необхідний обробник (StateHandler) та
викликає метод його виконання. Розподіл відповідальності між основними
обробниками наведено у таблиці 2.4.
Таблиця 2.4 – Відповідність обробників станам задачі
Стан Обробник Відповідальність
DATA_FETCHING DataFetchingHandler Збір даних, побудова словника
плейсхолдерів
VALIDATE ValidationHandler Перевірка повноти та коректності
даних
FILLING_TEMPLATE TemplateFillingHandler Генерація файлу формату DOCX та
збереження
2.4 Проєктування підсистем шаблонізації, валідації та аудиту
Окрім керування станами, модуль включає функціональні підсистеми, що
забезпечують безпосередню роботу з даними та файлами: стратегію генерації
документів, механізм маппінгу плейсхолдерів, валідацію вхідних даних та аудит
операцій.
Для підтримки декількох форматів вихідних документів застосовано патерн
Strategy, обґрунтований у підрозділі 1.4. Основна реалізація – DocxGenerator, який
використовує бібліотеку Apache POI (модуль XWPF) для маніпуляції DOCX-
файлами. Алгоритм run-by-run злиття забезпечує коректну підстановку значень зі
збереженням оригінального форматування шаблону. Блок-схему алгоритму
заповнення шаблону наведено на рисунку 2.5.
38
Рисунок 2.5 – Блок-схема алгоритму заповнення DOCX-шаблону
Зв'язування плейсхолдерів шаблону з полями студента організовано
декларативно через JSON-конфігурації. Кожному типу документа відповідає
окремий файл у classpath (наприклад,
templates/labels/MILITARY_REGISTRATION_NOTICE.json). LabelService
завантажує конфігурацію через Jackson ObjectMapper. Для додавання нового типу
документа достатньо створити DOCX-шаблон і відповідний JSON-файл маппінгу
без перекомпіляції коду.
Валідація організована через TaskValidationService відповідно до підходу,
описаного в підрозділі 1.4.
Для типу документа MILITARY_REGISTRATION_NOTICE перевіряється
39
наявність номера телефону – обов'язкового реквізиту повідомлення до ТЦК. У разі
помилки ValidationHandler сповіщає клієнта через SseService.emitError() з подією
VALIDATION_ERROR і переводить задачу до стану FAILED. Приклад роботи
валідації в клієнтському додатку наведено на рисунку 2.6.
Рисунок 2.6 – Результат валідації в клієнтському додатку
Підсистема аудиту (AuditService) фіксує факт генерації документа в таблиці
audit_log бази даних. Структуру записів та приклад журналу наведено на рис. 2.7.
Рисунок 2.7 – Приклад записів у таблиці аудиту
Висновки до розділу 2
У розділі виконано проєктування модуля автоматизованої генерації довідок та
звітних документів. Центральним архітектурним рішенням є скінченний автомат із
шістьма станами та явною матрицею переходів, реалізований через компоненти
40
StateHandlerProxy, TransitionService та StateTransitionPolicy. Наведено структуру
пакетів модуля, діаграму станів, послідовність взаємодії компонентів та ER-діаграму
моделі даних.
Спроєктовано ланцюжок обробників (DataFetchingHandler, ValidationHandler,
TemplateFillingHandler) та стратегію генерації DOCX із алгоритмом run-by-run
злиття, що зберігає форматування шаблону. Для декларативної підтримки різних
типів документів розроблено механізм JSON-конфігурацій маппінгу. Взаємодію із
клієнтом побудовано на REST API із двофазним процесом генерації та SSE.
Отримані рішення є достатніми для переходу до практичної реалізації.
41
3 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ЕКСПЕРИМЕНТАЛЬНЕ
ДОСЛІДЖЕННЯ СИСТЕМИ
У попередніх розділах було обґрунтовано вибір технологічного стеку та
архітектурних патернів (Розділ 1), а також спроєктовано архітектуру модуля
генерації документів із визначенням структури компонентів, діаграми станів та
моделі даних (Розділ 2). У даному розділі представлено практичну реалізацію
спроєктованої системи: описано середовище розробки та технічні вимоги, наведено
ключові фрагменти програмного коду з поясненнями прийнятих рішень,
продемонстровано сценарії взаємодії користувача з інтерфейсом системи та
виконано контрольний приклад, що підтверджує працездатність розробленого
програмного забезпечення.
3.1 Середовище розробки та стек технологій
Для реалізації системи HR-Office обрано стек технологій, що забезпечує
надійність, масштабованість та крос-платформність. Серверна частина побудована
на платформі Java з використанням фреймворку Spring Boot, який є індустріальним
стандартом для створення корпоративних веб-застосунків. Клієнтський десктопний
додаток реалізовано мовою Kotlin з використанням фреймворку Compose for
Desktop [14], що забезпечує декларативний підхід до побудови інтерфейсу
користувача [16]. Повний перелік інструментів та технологій наведено в таблиці 3.1.
Таблиця 3.1 – Інструменти та технології розробки
Компонент Технологія Версія
Мова серверної частини Java (Eclipse Temurin) 23
Backend-фреймворк Spring Boot 3.3.3
Мова клієнтської Kotlin Multiplatform 2.0+
частини
UI-фреймворк Compose for Desktop 1.6+
СУБД PostgreSQL 16
42
Версіонування БД Liquibase 4.27.0
Генерація документів Apache POI 5.2.5
Контейнеризація Docker + Docker 24+
Compose
Ключовими залежностями серверної частини є: spring-boot-starter-web для
побудови REST API, spring-boot-starter-data-jpa для роботи з базою даних через ORM
Hibernate [20], spring-boot-starter-security разом із бібліотекою JJWT для JWT-
автентифікації з алгоритмом HMAC-SHA512, poi-ooxml [5] для маніпуляції
документами формату DOCX, а також liquibase-core для автоматичного
версіонування схеми бази даних.
Вимоги до технічних засобів для розгортання серверної частини: операційна
система Linux (Ubuntu 22.04+) або Windows Server, мінімум 2 ядра CPU та 4 ГБ
оперативної пам'яті, Java Runtime Environment версії 23 або вище, Docker Engine
версії 24+. Клієнтський додаток потребує JRE 17+ та сумісний із операційними
системами Windows, macOS та Linux завдяки крос-платформності Kotlin
Multiplatform [16].
3.2 Реалізація ключових компонентів
У даному підрозділі описано архітектурні рішення, реалізовані в програмному
коді системи. Повні лістинги класів наведено в Додатку Б.
3.2.1 Оркестрація процесу генерації. Центральним компонентом модуля
генерації є клас StateHandlerProxy (Додаток Б, Лістинг Б.1), який реалізує патерн
Chain of Responsibility [11], описаний в підрозділі 1.4. Клас виконує роль
оркестратора: отримує задачу та делегує її обробку відповідному обробнику
залежно від поточного стану.
У конструкторі класу Spring Boot автоматично інжектує список усіх
компонентів, що реалізують інтерфейс StateHandler, через механізм Dependency
Injection. Метод Collectors.toMap перетворює цей список на асоціативний масив
Map<State, StateHandler>, що забезпечує пошук потрібного обробника за O(1).
43
Анотація @Transactional гарантує атомарність операції, а метод findWithLockById
використовує SQL-запит SELECT ... FOR UPDATE для запобігання конкурентному
доступу до однієї задачі.
3.2.2 Управління переходами станів. Логіку переходів між станами FSM
реалізовано в двох класах: TransitionService виконує сам перехід (Додаток Б, Лістинг
Б.2), а StateTransitionPolicy перевіряє його допустимість (Додаток Б, Лістинг Б.2).
Клас StateTransitionPolicy реалізує декларативний підхід до визначення
дозволених переходів: матриця переходів задана як Map<State, Set<State>>, що
значно спрощує модифікацію бізнес-логіки порівняно з розгалуженими
конструкціями if-else. Анотація Propagation.MANDATORY вимагає наявності
активної транзакції, що гарантує цілісність даних при переході між станами. Після
збереження нового стану TransitionService публікує подію TransitionEvent через
механізм Spring ApplicationEventPublisher, що забезпечує слабку зв'язність (Loose
Coupling) між компонентами.
3.2.3 Алгоритм заповнення DOCX-шаблону. Генерація документів формату
DOCX реалізована в класі DocxGenerator, який використовує бібліотеку Apache POI
[5]. Ключовим є метод replaceRunByRun (Додаток Б, Лістинг Б.4), що реалізує
алгоритм, блок-схему якого наведено на рисунку 2.5.
Алгоритм вирішує фундаментальну проблему роботи з DOCX: Microsoft Word
може розбивати текст одного плейсхолдера (наприклад, {{surname}}) на декілька
Run-об'єктів у XML-структурі документа. Алгоритм спочатку збирає тексти всіх
Run-ів у список, конкатенує їх для пошуку плейсхолдера, обчислює індекси
початкового та кінцевого Run-ів, замінює текст зі збереженням оригінального
форматування (шрифт, розмір, накреслення), а потім очищує проміжні Run-об'єкти.
Цикл while повторюється до тих пір, поки в абзаці залишаються незамінені
плейсхолдери.
3.2.4 Сервіс сповіщень у реальному часі. Механізм Server-Sent Events [27],
обґрунтований в підрозділі 1.2, реалізовано в класі SseService (Додаток Б, Лістинг
Б.5). Клас забезпечує підписку клієнта на оновлення статусу задачі та надсилання
подій при кожному переході між станами FSM.
44
Для зберігання активних підписок використовується ConcurrentHashMap –
потокобезпечна реалізація асоціативного масиву, що гарантує коректну роботу в
багатопотоковому середовищі Spring Boot. При підписці створюється об'єкт
SseEmitter з налаштованим таймаутом та обробниками помилок. Метод emitEvent
надсилає клієнту поточний стан задачі; при досягненні термінального стану
(COMPLETED або FAILED) з'єднання автоматично закривається.
3.3 Сценарії використання та інтерфейс користувача
У даному підрозділі описано основні сценарії взаємодії користувача з
десктопним клієнтом HR-Office, що стосуються безпосередньо модуля генерації
документів. Детальну покрокову інструкцію з усіма екранами наведено в Додатку В.
Для роботи з системою користувач проходить автентифікацію через екран
входу та потрапляє на головний екран додатку.
3.3.1 Авторизація в системі. Головний екран додатку з панеллю фільтрації та
карткою студента показано на рис. 3.1. Він складається з трьох функціональних зон:
ліва панель фільтрації, центральна таблиця зі списком студентів та права панель
деталізації. Панель фільтрації надає сортування за прізвищем, фільтрацію за
факультетом та віковою категорією, а також поле пошуку за прізвищем або ІПН.
Рисунок 3.1 – Головний екран додатку з панеллю фільтрації та карткою студента
45
Усі фільтри працюють в режимі реального часу: список оновлюється одразу
після зміни параметрів. При натисканні на рядок студента відкривається детальна
картка з повною інформацією, організованою в логічні секції: особисті дані, адреси,
документи та навчання.
3.3.2 Ініціація генерації документа. Генерація документа – основний бізнес-
сценарій модуля. Користувач обирає одного або кількох студентів за допомогою
чекбоксів у таблиці та натискає кнопку «Друкувати». Система відображає діалог
вибору типу документа: «Повідомлення про зміну облікових даних» або «Довідка
призовнику» (рисунок 3.2).
Рисунок 3.2 – Діалог вибору типу документа для генерації
46
3.3.3 Валідація даних перед генерацією. Перед початком генерації система
автоматично перевіряє повноту даних студента. Якщо виявлено відсутні обов'язкові
поля (наприклад, ІПН для повідомлення до ТЦК), відображається діалогове вікно
«Дані не повні» (рисунок 3.3) з переліком відсутньої інформації та трьома
варіантами дій: «Скасувати» (відмінити генерацію), «Редагувати» (перейти до
форми редагування для заповнення відсутніх полів) або «Друкувати без даних»
(згенерувати документ із порожніми полями замість відсутніх значень). Такий підхід
забезпечує гнучкість роботи: інколи документ потрібен терміново, навіть із
неповними даними.
Рисунок 3.3 – Діалог валідації: «Дані не повні»
47
3.3.4 Результат генерації. Після успішної генерації документ автоматично
завантажується на комп'ютер користувача у форматі DOCX. Згенерований файл
зберігає повне форматування оригінального шаблону: шрифти, розміри,
вирівнювання та структуру таблиць (рисунок 3.4). Система підтримує як одиничну,
так і пакетну генерацію для кількох студентів одночасно – для кожного створюється
окрема задача зі своїм незалежним життєвим циклом FSM.
3.4 Контрольний приклад
Для підтвердження працездатності розробленої системи виконано наскрізний
контрольний приклад: генерацію документа «Повідомлення про зміну облікових
даних військовозобов'язаного» для конкретного студента з бази даних.
Крок 1. Авторизація. Користувач запускає клієнтський додаток HR-Office та
вводить облікові дані. Система успішно автентифікує користувача та відображає
головний екран зі списком студентів.
Крок 2. Пошук студента. У полі пошуку вводимо прізвище. Система фільтрує
список та відображає відповідний запис. Натискаємо на рядок для перегляду
детальної картки.
Крок 3. Перевірка даних. У правій панелі відображається повна картка
студента. Перевіряємо наявність обов'язкових полів: ПІБ, дата народження,
паспортні дані, адреса реєстрації, телефон, ІПН, УНЗР, відомості про військовий
облік.
Крок 4. Ініціація генерації. Натискаємо кнопку «Друкувати» та обираємо тип
документа «Повідомлення про зміну облікових даних». Система створює нову
задачу (Task) зі статусом NEW та запускає ланцюжок обробки.
Крок 5. Обробка задачі. Скінченний автомат послідовно проходить через
стани: NEW → DATA_FETCHING (збір даних студента з бази та формування
словника плейсхолдерів) → VALIDATE (перевірка наявності обов'язкових полів) →
FILLING_TEMPLATE (завантаження DOCX-шаблону та заміна плейсхолдерів
алгоритмом run-by-run) → COMPLETED (збереження файлу та сповіщення клієнта
48
через SSE).
Крок 6. Отримання результату. Клієнтський додаток отримує SSE-подію з
типом COMPLETE та автоматично завантажує згенерований файл (рисунок 3.5).
Перевіряємо коректність заповнення: ПІБ, дата народження, паспортні дані, адреса –
всі поля заповнені відповідно до картки студента.
Рисунок 3.4 – Результат контрольного прикладу: згенероване повідомлення
Крок 7. Верифікація в базі даних. Для підтвердження виконуємо SQL-запит до
таблиці task. Результат підтверджує, що задача успішно пройшла всі стани FSM та
завершилася зі статусом COMPLETED, тип документа –
MILITARY_REGISTRATION_NOTICE, файл збережено у файловій системі сервера
(рисунок 3.5).
Рисунок 3.5 – Запис у таблиці task для контрольного прикладу
Крок 8. Перевірка помилкового сценарію. Для демонстрації обробки помилок
обираємо студента з відсутнім полем ІПН та ініціюємо генерацію. Система
відображає діалог «Дані не повні» з вказівкою на відсутнє поле. Задача переходить у
стан FAILED, що підтверджує коректну роботу механізму валідації.
49
3.5 Безперервна інтеграція
Для забезпечення якості коду та автоматизації процесу збірки в проєкті
налаштовано конвеєр безперервної інтеграції (CI) на базі платформи GitLab CI/CD.
Конфігурація конвеєра описується у файлі .gitlab-ci.yml, який розміщується в
кореневій директорії кожного репозиторію. При кожному внесенні змін до кодової
бази (git push) GitLab Runner автоматично запускає визначену послідовність етапів.
Конвеєр серверної частини (hr-office) складається з двох етапів (stages): build
та integration_test. На етапі build виконується компіляція вихідного коду Java 23 та
збірка артефакту (JAR-файл) за допомогою системи збірки Gradle. Успішне
завершення цього етапу гарантує, що код не містить синтаксичних помилок та всі
залежності коректно підключені. На етапі integration_test запускаються інтеграційні
тести з використанням бібліотеки Testcontainers, яка автоматично піднімає
тимчасовий контейнер PostgreSQL для перевірки взаємодії з базою даних у
середовищі, максимально наближеному до продуктивного. Для цього у конфігурації
підключено сервіс Docker-in-Docker (docker:24.0.5-dind).
Конвеєр клієнтської частини (hr-office-ui) містить один етап – build, на якому
виконується збірка десктопного додатку Kotlin Multiplatform з використанням
Compose for Desktop. Для оптимізації часу збірки налаштовано кешування
залежностей Gradle за ключем поточної гілки, що дозволяє повторно
використовувати завантажені бібліотеки між послідовними запусками конвеєра.
Застосування CI забезпечує ранню діагностику дефектів: розробник отримує
зворотний зв'язок про результат збірки та тестування протягом кількох хвилин після
відправки змін до репозиторію, що значно скорочує цикл виявлення та виправлення
помилок.
Висновки до розділу 3
У розділі виконано програмну реалізацію системи автоматизованої генерації
кадрових документів HR-Office та проведено її експериментальне дослідження.
Контрольний приклад підтвердив повну працездатність системи: цикл
50
генерації документа від ініціації користувачем до збереження готового файлу
виконується менш ніж за 3 секунди, що свідчить про ефективність обраної
архітектури на основі скінченного автомата та ланцюжка обробників.
Інтерфейс користувача забезпечує інтуїтивну взаємодію із системою:
фільтрація, пошук, перегляд деталей студента та генерація документа доступні без
додаткового навчання. Механізм валідації попереджає користувача про неповні дані
до початку генерації, що запобігає створенню некоректних документів та надає
гнучкість через можливість друку без відсутніх даних.
Архітектура системи підтвердила свою розширюваність: додавання нового
типу документа потребує лише створення DOCX-шаблону та набору плейсхолдерів
без модифікації ядра системи. Налаштований конвеєр безперервної інтеграції на базі
GitLab CI/CD автоматизує процес збірки та інтеграційного тестування, що
забезпечує стабільність кодової бази при командній розробці.
51
ВИСНОВКИ
У кваліфікаційній роботі бакалавра вирішено прикладну задачу автоматизації
процесу формування довідок та звітних документів у HR-системі обліку
військовозобов'язаних закладу вищої освіти. Мета роботи досягнута в повному
обсязі: розроблено програмний модуль, що забезпечує автоматичну генерацію
кадрових документів зі збереженням затвердженого форматування.
У ході виконання кваліфікаційної роботи бакалавра вирішено такі завдання:
– проведено аналіз проблематики ручного формування кадрових документів у
підрозділах обліку військовозобов'язаних. Встановлено п'ять ключових труднощів:
відсутність єдиних правил перевірки перед друком, різні вимоги до різних типів
документів, складність пакетної обробки при частково відсутніх даних, недостатня
прозорість причин відмови та неузгодженість між клієнтською і серверною
частинами. Порівняльний аналіз існуючих бібліотек (Apache POI, docx4j,
JasperReports, iText) підтвердив, що для генерації офіційних документів із
збереженням затвердженого форматування оптимальним є підхід на основі DOCX-
шаблонів із плейсхолдерами;
– обґрунтовано архітектуру модуля генерації документів на основі патерну
скінченного автомата (FSM) із шістьма станами: NEW, DATA_FETCHING,
VALIDATE, FILLING_TEMPLATE, COMPLETED та FAILED. Такий підхід
забезпечує чітке розмежування етапів обробки задачі, прозорість причин відмови та
можливість незалежного масштабування кожного етапу. Патерн Chain of
Responsibility застосовано для оркестрації обробників, що дозволяє додавати нові
етапи без модифікації існуючого коду;
– розроблено та реалізовано алгоритм заповнення DOCX-шаблонів методом
run-by-run, що вирішує фундаментальну проблему роботи з форматом DOCX: текст
одного плейсхолдера може бути розбитий Microsoft Word на декілька окремих Run-
об'єктів у XML-структурі документа. Алгоритм виконує конкатенацію текстів
сусідніх Run-ів, знаходить плейсхолдер, підставляє значення та очищує проміжні
Run-об'єкти, зберігаючи оригінальне форматування (шрифт, розмір, накреслення)
52
затвердженого офіційного бланку;
– реалізовано механізм дворівневої валідації даних перед генерацією
документа з розмежуванням обов'язкових та необов'язкових полів. При виявленні
відсутніх даних система не блокує роботу, а надає кадровому спеціалісту три
варіанти дій: скасувати генерацію, перейти до форми редагування або виконати друк
із порожніми полями. Такий підхід відповідає реальному робочому процесу, де
документ може бути потрібен терміново навіть із неповними даними;
– реалізовано асинхронний механізм сповіщення клієнта про стан виконання
задачі генерації на основі технології Server-Sent Events (SSE). Порівняно з
альтернативним підходом на основі polling (циклічних запитів), SSE забезпечує
миттєве оновлення стану без надлишкового навантаження на сервер, одностороннє
з'єднання без накладних витрат WebSocket та автоматичне відновлення з'єднання
при збоях мережі;
– виконано контрольний приклад, який підтвердив повну працездатність
модуля генерації: задача типу MILITARY_REGISTRATION_NOTICE пройшла
повний цикл FSM від стану NEW до COMPLETED, що верифіковано безпосереднім
запитом до бази даних. Згенерований DOCX-документ містить коректно підставлені
дані студента зі збереженням форматування офіційного бланку. Перевірка
помилкового сценарію (відсутній ІПН) підтвердила коректний перехід задачі до
стану FAILED з фіксацією причини відмови.
Практична цінність розробленого модуля полягає в наступному: скорочення
часу формування одного документа з кількох хвилин ручної роботи до декількох
секунд автоматичної обробки; усунення помилок ручного заповнення реквізитів;
підтримка пакетної генерації для одночасної обробки кількох студентів. Ключовою
перевагою є розширюваність: додавання нового типу документа потребує лише
створення DOCX-шаблону та JSON-конфігурації плейсхолдерів без модифікації
програмного ядра модуля.
53
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Закон України «Про захист персональних даних» від 01.06.2010 № 2297-VI.
Відомості Верховної Ради України. 2010. № 34. Ст. 481.
2. Міністерство цифрової трансформації України. Цифрова трансформація: звіт
за 2023 рік. URL: https://thedigital.gov.ua (дата звернення: 08.04.2026).
3. Семенченко А., Дрешпак В. Цифрова трансформація публічного управління в
Україні: стан, проблеми, перспективи // Державне управління: удосконалення
та розвиток. 2021. № 3. URL: http://www.dy.nayka.com.ua/?op=1&z=1952 (дата
звернення: 07.04.2026).
4. Триус Ю. В. Комп'ютерно-орієнтовані методичні системи навчання
математики : монографія. Черкаси : Брама-Україна, 2005. 400 с.
5. Apache Software Foundation. Apache POI – the Java API for Microsoft Documents.
URL: https://poi.apache.org (дата звернення: 10.04.2026).
6. Docx4j Project. Official Documentation. URL: https://github.com/plutext/docx4j
(дата звернення: 10.04.2026).
7. Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software.
Addison-Wesley, 2003. 530 p.
8. Fielding R. T. Architectural Styles and the Design of Network-based Software
Architectures : PhD dissertation. University of California, Irvine, 2000. 180 p.
9. Fowler M. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
533 p.
10. Freund J., Rücker B. Real-Life BPMN: Using BPMN 2.0 to Analyze, Improve, and
Automate Processes. 4th ed. Independently published, 2019. 374 p.
11. Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1994. 395 p.
12. IT-Enterprise. Кадровий облік та управління персоналом. URL:
https://www.it.ua/products/hr (дата звернення: 09.04.2026).
13. iText Group. iText 7: Building Blocks. Gent : iText Group NV, 2022. 228 p.
14. JetBrains. Compose Multiplatform. URL: https://www.jetbrains.com/lp/compose-
54
multiplatform/ (дата звернення: 20.03.2026).
15. Kavanagh M. J., Johnson R. D. Human Resource Information Systems: Basics,
Applications, and Future Directions. 4th ed. SAGE Publications, 2018. 592 p.
16. Kotlin Multiplatform Documentation. JetBrains s.r.o. URL:
https://kotlinlang.org/docs/multiplatform.html (дата звернення: 20.03.2026).
17. Martin R. C. Clean Architecture: A Craftsman's Guide to Software Structure and
Design. Prentice Hall, 2017. 432 p.
18. M.E.Doc. Базовий модуль. Звітність. URL: https://medoc.ua (дата звернення:
09.04.2026).
19. Oracle Corporation. Oracle Business Intelligence Publisher User's Guide. Release
11.1.1. Redwood Shores : Oracle, 2014. 498 p.
20. PostgreSQL 16 Documentation. The PostgreSQL Global Development Group.
URL: https://www.postgresql.org/docs/16/ (дата звернення: 14.03.2026).
21. Richardson C. Microservices Patterns: With Examples in Java. Manning
Publications, 2018. 520 p.
22. SAP SuccessFactors. SAP SuccessFactors HXM Suite. URL:
https://www.sap.com/products/hcm.html (дата звернення: 10.04.2026).
23. Sipser M. Introduction to the Theory of Computation. 3rd ed. Cengage Learning,
2012. 504 p.
24. Spring Boot Reference Documentation. VMware, Inc. URL:
https://docs.spring.io/spring-boot/docs/current/reference/html/ (дата звернення:
12.03.2026).
25. Vernon V. Implementing Domain-Driven Design. Addison-Wesley, 2013. 656 p.
26. Walls C. Spring Boot in Action. Manning Publications, 2016. 264 p.
27. WHATWG. Server-sent events. HTML Living Standard. URL:
https://html.spec.whatwg.org/multipage/server-sent-events.html (дата звернення:
12.04.2026).
28. Workday Inc. Workday Document Generation. URL: https://doc.workday.com
(дата звернення: 11.04.2026).
29. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. П.
55
Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована
HR-система закладу вищої освіти : Збірник тез доповідей студентської
науково-практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник
Мельник І.В.]; Міністерство освіти і науки України, Черкаський державний
технологічний ун-т. Черкаси : ЧДТУ, 2026. С. 14.
56
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2026 р.
МОДУЛЬ АВТОМАТИЗОВАНОГО ФОРМУВАННЯ ДОВІДОК ТА ЗВІТНИХ
ДОКУМЕНТІВ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ
Специфікація
482.ЧДТУ. 62285-01
Листів 2
Розробник ____________________ Данило ГОЛУБ
Керівник ____________________ Любов ОКСАМИТНА
Черкаси – 2026
57
482.ЧДТУ. 62285-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 62285-01 12 01 Текст програми
482.ЧДТУ. 62285-01 34 01 Інструкція користувача
482.ЧДТУ. 62285-01 90 01 Апробація
кваліфікаційної роботи
бакалавра
58
ДОДАТОК Б
МОДУЛЬ АВТОМАТИЗОВАНОГО ФОРМУВАННЯ ДОВІДОК ТА ЗВІТНИХ
ДОКУМЕНТІВ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ
Текст програми
482.ЧДТУ. 62285-01 12 01
Листів 8
Розробник _____________ Данило ГОЛУБ
Черкаси – 2026
59
Лістинг Б.1 – Клас StateHandlerProxy – оркестратор ланцюжка обробників
package ua.edu.chdtu.hr.document.orchestration;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import ua.edu.chdtu.hr.domain.State;
import ua.edu.chdtu.hr.domain.Task;
import ua.edu.chdtu.hr.document.handler.StateHandler;
import ua.edu.chdtu.hr.document.repository.TaskRepository;
import java.util.List;
import java.util.Map;
import java.util.Optional;
import java.util.UUID;
import java.util.stream.Collectors;
@Service
public class StateHandlerProxy {
private final Map<State, StateHandler> actionServices;
private final TaskRepository taskRepository;
public StateHandlerProxy(List<StateHandler> services, TaskRepository taskRepository) {
this.actionServices = services.stream()
.collect(Collectors.toMap(StateHandler::getState, service -> service));
this.taskRepository = taskRepository;
}
@Transactional
public void applyAction(State action, UUID taskId) {
Task task = taskRepository.findWithLockById(taskId)
.orElseThrow(() -> new IllegalArgumentException("Task not found with ID: " + taskId));
Optional.ofNullable(actionServices.get(action))
.orElseThrow(() -> new IllegalArgumentException("Unsupported action type: " + action))
.handle(task);
}
}
Лістинг Б.2 – Клас StateTransitionPolicy – матриця дозволених переходів FSM
package ua.edu.chdtu.hr.document.policy;
import org.springframework.stereotype.Component;
import ua.edu.chdtu.hr.domain.State;
import java.util.Map;
import java.util.Set;
@Component
public class StateTransitionPolicy {
private final Map<State, Set<State>> ALLOWED_TRANSITIONS = Map.of(
State.NEW, Set.of(State.DATA_FETCHING, State.FAILED),
State.DATA_FETCHING, Set.of(State.VALIDATE, State.FAILED),
State.VALIDATE, Set.of(State.FILLING_TEMPLATE, State.FAILED),
60
State.FILLING_TEMPLATE, Set.of(State.COMPLETED, State.FAILED)
);
public void validate(State from, State to) {
if (!ALLOWED_TRANSITIONS.getOrDefault(from, Set.of()).contains(to)) {
throw new IllegalStateException(
String.format("Invalid state transition from %s to %s", from, to));
}
}
}
Лістинг Б.3 – Клас TransitionService – виконання переходів між станами
package ua.edu.chdtu.hr.document.service;
import lombok.RequiredArgsConstructor;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
import ua.edu.chdtu.hr.domain.State;
import ua.edu.chdtu.hr.domain.Task;
import ua.edu.chdtu.hr.document.event.TransitionEvent;
import ua.edu.chdtu.hr.document.policy.StateTransitionPolicy;
import ua.edu.chdtu.hr.document.repository.TaskRepository;
@Service
@RequiredArgsConstructor
public class TransitionService {
private final StateTransitionPolicy policy;
private final TaskRepository taskRepository;
private final ApplicationEventPublisher applicationEventPublisher;
@Transactional(propagation = Propagation.MANDATORY)
public void transition(Task task, State targetState) {
policy.validate(task.getState(), targetState);
task.setState(targetState);
taskRepository.save(task);
applicationEventPublisher.publishEvent(new TransitionEvent(task.getId(), targetState));
}
}
61
Лістинг Б.4 – Клас DocxGenerator – генерація DOCX з алгоритмом run-by-run
package ua.edu.chdtu.hr.document.strategy;
import io.micrometer.common.util.StringUtils;
import lombok.extern.slf4j.Slf4j;
import org.apache.poi.xwpf.usermodel.*;
import org.springframework.core.io.ClassPathResource;
import org.springframework.stereotype.Component;
import ua.edu.chdtu.hr.domain.Task;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.List;
import java.util.Map;
import ua.edu.chdtu.hr.domain.DocumentFormat;
@Slf4j
@Component
public class DocxGenerator implements DocumentGenerator {
@Override
public boolean supports(DocumentFormat format) {
return format == DocumentFormat.DOCX;
}
@Override
public byte[] generate(Task task) {
boolean preserveRuns = true;
String templateName = switch (task.getDocumentType()) {
case EDUCATION_CERTIFICATE -> "templates/Довідка призовнику.docx";
case MILITARY_REGISTRATION_NOTICE ->
"templates/Повідомлення_про_зміну_облікових_даних.docx";
};
try (InputStream is = new ClassPathResource(templateName).getInputStream();
ByteArrayOutputStream out = new ByteArrayOutputStream()) {
Map<String, String> placeholders = task.getPayload();
try (XWPFDocument doc = new XWPFDocument(is)) {
replaceInParagraphs(doc.getParagraphs(), placeholders, preserveRuns);
for (XWPFTable table : doc.getTables()) {
for (XWPFTableRow row : table.getRows()) {
for (XWPFTableCell cell : row.getTableCells()) {
replaceInParagraphs(cell.getParagraphs(), placeholders, preserveRuns);
}
}
}
doc.write(out);
return out.toByteArray();
}
} catch (IOException e) {
log.error("Error generating DOCX document {} for task {}", task.getDocumentType(),
task.getId(), e);
throw new RuntimeException("Failed to generate DOCX document", e);
}
}
private void replaceInParagraphs(List<XWPFParagraph> paragraphs, Map<String, String>
placeholders,
62
boolean preserveRuns) {
for (XWPFParagraph paragraph : paragraphs) {
String text = paragraph.getText();
if (StringUtils.isBlank(text))
continue;
if (text.contains("{{")) {
if (preserveRuns) {
replaceRunByRun(paragraph, placeholders);
} else {
replaceInRuns(paragraph, placeholders);
}
}
}
}
private void replaceRunByRun(XWPFParagraph paragraph, Map<String, String> placeholders) {
List<XWPFRun> runs = paragraph.getRuns();
if (runs == null || runs.isEmpty()) {
return;
}
List<String> runTexts = new java.util.ArrayList<>(runs.size());
for (XWPFRun run : runs) {
String text = run.getText(0);
runTexts.add(text == null ? "" : text);
}
while (true) {
String merged = String.join("", runTexts);
int matchIndex = Integer.MAX_VALUE;
String matchKey = null;
for (String key : placeholders.keySet()) {
int idx = merged.indexOf(key);
if (idx >= 0 && idx < matchIndex) {
matchIndex = idx;
matchKey = key;
}
}
if (matchKey == null) {
break;
}
int start = matchIndex;
int endExclusive = start + matchKey.length();
int startRun = -1;
int endRun = -1;
int startOffset = 0;
int endOffsetExclusive = 0;
int cursor = 0;
for (int i = 0; i < runTexts.size(); i++) {
int len = runTexts.get(i).length();
int next = cursor + len;
if (startRun == -1 && start < next) {
startRun = i;
startOffset = start - cursor;
}
63
if (endExclusive <= next) {
endRun = i;
endOffsetExclusive = endExclusive - cursor;
break;
}
cursor = next;
}
if (startRun == -1 || endRun == -1) {
break;
}
String prefix = runTexts.get(startRun).substring(0, Math.max(0, startOffset));
String suffix = runTexts.get(endRun).substring(Math.max(0, endOffsetExclusive));
String replacement = placeholders.getOrDefault(matchKey, "");
runTexts.set(startRun, prefix + replacement + suffix);
for (int i = startRun + 1; i <= endRun; i++) {
runTexts.set(i, "");
}
}
for (int i = 0; i < runs.size(); i++) {
runs.get(i).setText(runTexts.get(i), 0);
}
}
private void replaceInRuns(XWPFParagraph paragraph, Map<String, String> placeholders) {
List<XWPFRun> runs = paragraph.getRuns();
if (runs == null || runs.isEmpty())
return;
StringBuilder fullText = new StringBuilder();
for (XWPFRun xwpfRun : runs) {
String t = xwpfRun.getText(0);
if (t != null) {
fullText.append(t);
}
}
String merged = fullText.toString();
if (!merged.contains("{{"))
return;
for (Map.Entry<String, String> entry : placeholders.entrySet()) {
merged = merged.replace(entry.getKey(), entry.getValue());
}
boolean first = true;
for (XWPFRun run : runs) {
if (first) {
run.setText(merged, 0);
first = false;
} else {
run.setText("", 0);
}
}
}
}
64
Лістинг Б.5 – Клас SseService – сповіщення клієнта у реальному часі (SSE)
package ua.edu.chdtu.hr.document.service;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;
import ua.edu.chdtu.hr.domain.State;
import ua.edu.chdtu.hr.document.repository.TaskRepository;
import java.io.IOException;
import java.util.EnumSet;
import java.util.Map;
import java.util.UUID;
import java.util.concurrent.ConcurrentHashMap;
@Slf4j
@Service
public class SseService {
private final Map<UUID, SseEmitter> emitters = new ConcurrentHashMap<>();
private final TaskRepository taskRepository;
private final Map<State, SseAction> stateActions = Map.of(
State.COMPLETED, this::completeAction,
State.FAILED, this::completeAction
);
private final EnumSet<State> terminalStates = EnumSet.of(State.COMPLETED, State.FAILED);
private final Long timeoutMs;
public SseService(TaskRepository taskRepository, @Value("${app.sse.timeout-ms:1800000}") Long
timeoutMs) {
this.taskRepository = taskRepository;
this.timeoutMs = timeoutMs;
}
public SseEmitter subscribe(UUID taskId) {
SseEmitter emitter = new SseEmitter(timeoutMs);
emitters.put(taskId, emitter);
emitter.onCompletion(() -> {
log.info("SSE emitter for task {} completed", taskId);
emitters.remove(taskId);
});
emitter.onTimeout(() -> {
log.warn("SSE emitter for task {} timed out", taskId);
emitters.remove(taskId);
});
emitter.onError((e) -> {
log.error("SSE emitter for task {} threw an error", taskId, e);
emitters.remove(taskId);
});
try {
var taskOpt = taskRepository.findById(taskId);
if (taskOpt.isPresent() && terminalStates.contains(taskOpt.get().getState())) {
completeAction(emitter, taskId, taskOpt.get().getState());
return emitter;
}
emitter.send(SseEmitter.event().name("INIT").data("Connected to task: " + taskId));
65
} catch (IOException e) {
emitter.completeWithError(e);
}
return emitter;
}
public void emitEvent(UUID taskId, State state) {
SseEmitter emitter = emitters.get(taskId);
if (emitter != null) {
SseAction action = stateActions.getOrDefault(state, this::completeAction);
action.execute(emitter, taskId, state);
}
}
public void emitError(UUID taskId, String errorMessage) {
SseEmitter emitter = emitters.get(taskId);
if (emitter != null) {
try {
emitter.send(SseEmitter.event().name("VALIDATION_ERROR").data(errorMessage));
} catch (IOException e) {
log.error("Failed to send error event to emitter for task {}", taskId, e);
emitters.remove(taskId);
}
}
}
private void completeAction(SseEmitter emitter, UUID taskId, State state) {
try {
emitter.send(SseEmitter.event().name("COMPLETE").data(state.name()));
emitter.complete();
} catch (Exception e) {
log.error("Failed to send final complete event to emitter for task {}", taskId, e);
} finally {
emitters.remove(taskId);
}
}
66
ДОДАТОК В
МОДУЛЬ АВТОМАТИЗОВАНОГО ФОРМУВАННЯ ДОВІДОК ТА ЗВІТНИХ
ДОКУМЕНТІВ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ
ІНСТРУКЦІЯ КОРИСТУВАЧА
482. ЧДТУ. 62285-01 34 01
Листів 7
Розробник _____________ Данило ГОЛУБ
Черкаси – 2026
67
Інструкція користувача призначена для ознайомлення з функціональними
можливостями модуля автоматизованого формування довідок у HR-системі ЗВО.
Для роботи з системою користувачу потрібен комп'ютер під управлінням
операційної системи Windows, macOS або Linux із встановленим середовищем Java
Runtime Environment (JRE) версії 17 або вище. Доступ до системи здійснюється
через десктопний клієнт, розроблений за допомогою технології Compose for Desktop.
Після запуску додатку користувача зустрічає екран авторизації (рисунок В.1).
Для входу в систему необхідно ввести свої облікові дані: логін та пароль. Додатково
передбачена можливість збереження сесії за допомогою чекбоксу «Запам'ятати
мене», що дозволить уникати повторної авторизації при наступних запусках
програми.
Рисунок В.1 – Екран авторизації користувача
У разі успішної авторизації відкривається головне вікно системи (рис. В.2),
яке поділене на дві основні робочі зони: бічну панель фільтрації (зліва) та таблицю
68
зі списком студентів (по центру). У лівій частині екрану користувач може
здійснювати швидкий пошук осіб за прізвищем, іменем, по батькові або
індивідуальним податковим номером (ІПН). Також доступні розширені фільтри для
сортування списку за факультетом, курсом чи віковою категорією. Система
автоматично оновлює таблицю при зміні параметрів фільтрації.
Рисунок В.2 – Головний екран системи
Для перегляду розширеної інформації про конкретного студента необхідно
натиснути на відповідний рядок у таблиці. Після цього відкриється детальна картка
профілю (рисунок В.3). Картка містить декілька вкладок:
− основна інформація (ПІБ, дата народження, контакти);
− паспортні дані та адреси реєстрації/проживання;
− відомості про військовий облік (ТЦК, статус, ВОС);
− історія згенерованих документів.
Ця функція дозволяє працівнику відділу кадрів швидко перевірити
актуальність даних перед формуванням звітності.
69
Рисунок В.3 – Картка детальної інформації про студента
Щоб розпочати процес генерації довідки, необхідно виконати такі кроки:
1. У головному списку студентів виділити одну або декілька осіб за
допомогою чекбоксів зліва від їхніх прізвищ.
2. Натиснути кнопку «Друкувати», що розташована у верхній панелі
інструментів.
70
3. На екрані з'явиться діалогове вікно (рисунок В.4), у якому потрібно обрати
необхідний тип документа зі списку (наприклад, «Довідка призовнику» або
«Повідомлення про зміну облікових даних»).
4. Підтвердити свій вибір натисканням кнопки «Згенерувати».
Рисунок В.4 – Діалог вибору типу документа
Перед безпосереднім формуванням документа система здійснює автоматичну
перевірку (валідацію) наявності всіх необхідних даних у профілі вибраних
студентів.
Якщо для створення документа не вистачає критично важливої інформації
(наприклад, відсутній номер телефону, адреса проживання чи інформація про ТЦК),
71
генерація призупиняється і на екран виводиться вікно з попередженням (рис. В.5).
У цьому вікні користувачу пропонується перелік відсутніх полів та три
варіанти подальших дій:
− «Скасувати» – зупинити процес генерації для цього студента;
− «Редагувати» – перейти до форми заповнення відсутніх даних (після
збереження процес генерації можна буде відновити);
− «Друкувати без даних» – продовжити формування документа, ігноруючи
відсутню інформацію (на місці цих даних у документі будуть залишені
порожні поля або плейсхолдери).
Рисунок В.5 – Вікно валідації при нестачі даних
Після успішного проходження валідації або вибору опції «Друкувати без
даних», система розпочинає фонову генерацію. Завдяки механізму Server-Sent
Events (SSE), користувач бачить індикатор прогресу в реальному часі. Після
завершення процесу готовий документ автоматично завантажується та зберігається
на комп'ютері користувача у форматі DOCX або PDF (залежно від налаштувань).
72
Згенерований документ має повністю збережене офіційне форматування та готовий
до друку або відправки (рисунок В.6).
Рисунок В.6 – Приклад згенерованого документа
73
ДОДАТОК Г
МОДУЛЬ АВТОМАТИЗОВАНОГО ФОРМУВАННЯ ДОВІДОК ТА ЗВІТНИХ
ДОКУМЕНТІВ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ
Апробація кваліфікаційної роботи бакалавра
482. ЧДТУ. 62285-01 90 01
Листів 4
Розробник _____________ Данило ГОЛУБ
Черкаси – 2026
74
75
Основні положення і результати кваліфікаційної роботи бакалавра
доповідалися і були обговорені на конференції «День студентської науки кафедри
КНСА», 22 квітня 2026 року, Черкаси, Україна.
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило
Русланович, Дубровний Володимир Володимирович, Кєрнус Дмитро
Олександрович) «Інформаційна автоматизована HR-система закладу вищої освіти» в
День студентської науки кафедри КНСА посів 1 місце.
76