Модуль обліку військовозобов’язаних в HR-системі державного  закладу

Дубровний, Володимир Володимирович
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9686
Назва:	Модуль обліку військовозобов’язаних в HR-системі державного закладу
Автори:	Оксамитна, Любов Павлівна Дубровний, Володимир Володимирович
Ключові слова:	HR-СИСТЕМА;ВІЙСЬКОВОЗОБОВ’ЯЗАНІ;АВТОМАТИЗАЦІЯ КАДРОВИХ ПРОЦЕСІВ;ДЕРЖАВНИЙ ЗАКЛАД;SPRING BOOT;KOTLIN;LIQUIBASE;DOCKER.
Дата публікації:	10-чер-2026
Короткий огляд (реферат):	На сьогодні стабільність функціонування державних закладів та неухильне дотримання ними законодавства в сфері національної безпеки безпосередньо залежать від точності та оперативності ведення обліку. У зв’язку з постійними змінами в нормативно-правовій базі та підвищенням вимог до цифровізації державних процесів, виникає гостра потреба у впровадженні спеціалізованих модулів у межах кадрових HR-систем. Метою кваліфікаційної роботи бакалавра є проєктування та програмна реалізація модуля обліку військовозобов’язаних у складі HR-системи державного закладу, що забезпечить автоматизацію процесів збору, збереження та опрацю-вання персональних даних, а також оперативне формування регламентованої звітності згідно з чинним законодавством України. Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/9686
Розташовується у зібраннях:	122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування)
Файли цього матеріалу:
Файл	Опис	Розмір	Формат
Пояснювальна записка_Дубровний Володимир_КН-2201_2025-2026.pdf Restricted Access		1.67 MB	Adobe PDF	Переглянути/Відкрити Запит копії
Показати повний опис матеріалу Перегляд статистики
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра комп’ютерних наук та системного аналізу 
Пояснювальна записка 
до кваліфікаційної роботи 
бакалавра 
(освітньо-кваліфікаційний рівень) 
на тему: «Модуль обліку військовозобов’язаних в HR-системі державного 
закладу» 
Виконав: студент 4 курсу, групи КН–2201 
спеціальності 122  «Комп’ютерні науки» 
(шифр і назва спеціальності) 
Освітня програма «Комп’ютерні науки та 
(назва освітньої програми) 
прикладне програмування» 
Володимир ДУБРОВНИЙ 
Керівник  Любов ОКСАМИТНА 
(ім’я та прізвище) 
Рецензент  Сергій СТАСЬ 
(ім’я та прізвище) 
Черкаси 2026 року 
2
Бланк завдання на кваліфікаційну роботу бакалавра студенту 
Черкаський державний технологічний університет 
Факультет Інформаційних технологій і систем 
Кафедра Комп’ютерних наук та системного аналізу 
Освітньо-кваліфікаційний рівень Бакалавр 
Спеціальність  122 – Комп’ютерні науки 
Освітня програма Комп’ютерні науки та прикладне програмування 
ЗАТВЕРДЖУЮ 
Завідувач кафедри КНСА 
Юрій ТРИУС 
« »  20 р. 
ЗАВДАННЯ 
на кваліфікаційну роботу бакалавра студенту 
Дубровному Володимиру Володимировичу 
(прізвище, ім‘я, по батькові) 
1. Тема роботи  Модуль обліку військовозобов’язаних в HR-системі державного закладу 
Керівник роботи Оксамитна Л.П., к.т.н., доцент 
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
затверджені наказом університету від «12» березня 2026 р. №56/03-03. 
2. Строк подання студентом роботи «08» червня 2026 року.
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних. 
Звіт з виробничої практики. Звіт з переддипломної практики. 
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ 
4.1. Аналітико-постановочні основи розроблення. 
4.2. Проєктування та реалізація модуля обліку військовозобов’язаних у HR-системі державного за-  
кладу. 
4.3. Тестування та аналіз результатів. 
Висновки. 
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 62288-01. 
5.2. Додаток Б. Інструкція користувача. 
5.3. Додаток В. Апробація результатів кваліфікаційної роботи бакалавра. 
5.4. Презентація у вигляді 18 слайдів. 
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 Виконано 
Студент Володимир ДУБРОВНИЙ 
(підпис) 
Керівник роботи Любов ОКСАМИТНА 
(підпис) 
4
РЕФЕРАТ 
Кваліфікаційна робота бакалавра містить: 75 с., 20 рис., 6 таблиць, 22 ви-
користаних джерел, 3 додатки. 
Актуальність теми. На сьогодні стабільність функціонування державних за-
кладів та неухильне дотримання ними законодавства в сфері національної безпеки 
безпосередньо залежать від точності та оперативності ведення обліку. У зв’язку з пос-
тійними змінами в нормативно-правовій базі та підвищенням вимог до цифровізації 
державних процесів, виникає гостра потреба у впровадженні спеціалізованих модулів 
у межах кадрових HR-систем. 
Метою кваліфікаційної роботи бакалавра є проєктування та програмна 
реалізація модуля обліку військовозобов’язаних у складі HR-системи державного 
закладу, що забезпечить автоматизацію процесів збору, збереження та опрацювання 
персональних даних, а також оперативне формування регламентованої звітності згі-
дно з чинним законодавством України. 
Завдання кваліфікаційної роботи бакалавра: 
− проаналізувати вимоги до цифрової трансформації кадрових процесів у держа-
вних установах; 
− обґрунтувати архітектурні підходи і вибір технологічного стеку; 
− спроєктувати структуру реляційної бази даних і механізми доступу; 
− реалізувати серверну логіку обробки кадрових запитів та формування докуме-
нтів; 
− створити клієнтський інтерфейс для роботи з реєстром; 
− налаштувати систему розмежування доступу і захищену автентифікацію; 
− провести тестування і оцінити ефективність автоматизації. 
Об’єкт дослідження: процеси ведення обліку персоналу за допомогою web- 
орієнтованої HR-системи державного закладу. 
Предмет дослідження: архітектура, принципи реалізації та процеси експлуа-
тації спеціалізованого модуля обліку в складі комплексної HR-системи. 
5
Методи дослідження. У роботі використано такі методи: 
− аналіз нормативно-правової бази та науково-технічної літератури з проблеми 
автоматизації військового обліку та кадрового діловодства;  
− теорія проєктування реляційних баз даних та об’єктно-орієнтованого аналізу; 
− методи автоматизованої обробки та валідації персональних даних;  
− алгоритмічні методи генерації документів за шаблонами відповідно до держа-
вних стандартів; 
− аналіз особливостей функціонування web-орієнтованої HR-системи державно-
го закладу та вимог до захисту інформації. 
Апробація результатів роботи. Основні положення і результати кваліфіка-
ційної роботи бакалавра доповідалися і були обговорені на конференції «День сту-
дентської науки кафедри КНСА», 22 квітня  2026 року, Черкаси, Україна. 
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. 
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована 
HR-система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; Міні-
стерство освіти і науки України, Черкаський державний технологічний ун-т.  Черка-
си : ЧДТУ, 2026. С. 14. 
Ключові слова: HR-СИСТЕМА, ВІЙСЬКОВОЗОБОВ’ЯЗАНІ, АВТОМАТИЗАЦІЯ 
КАДРОВИХ ПРОЦЕСІВ, ДЕРЖАВНИЙ ЗАКЛАД, SPRING BOOT, KOTLIN, COMPOSE 
MULTIPLATFORM, MVVM, KTOR CLIENT, POSTGRESQL, JWT, REST API, LIQUIBASE, 
DOCKER. 
ABSTRACT 
The qualification work of bachelor contains: 75 pages, 20 figures, 6 tables, 22 
sources used, 3 attachments. 
Actuality of theme. Today, the stable functioning of state institutions and their 
strict compliance with national security legislation directly depend on the accuracy and 
promptness of accounting. Due to constant changes in the regulatory framework and 
increasing requirements for the digitalization of state processes, there is an urgent need to 
implement specialized modules within human resource (HR) systems. 
6
The purpose of the work is to design and programmatically implement a military 
accounting module as part of a state institution's HR system, which will ensure the 
automation of personal data collection, storage, and processing, as well as the prompt 
generation of regulated reporting in accordance with the current legislation of Ukraine. 
Objectives of qualifying work: 
− analyze the requirements for the digital transformation of HR processes in 
government agencies; 
− justify architectural approaches and the choice of a technological stack; 
− design the structure of a relational database and access mechanisms; 
− implement the server logic for processing HR requests and generating documents; 
− create a client interface for working with the registry; 
− configure an access delimitation system and secure authentication; 
− conduct testing and evaluate the effectiveness of automation. 
The object of research: the process of maintaining accounting of personnel using a 
web-oriented HR system of a state institution. 
The subject of research: architecture, implementation principles and operation 
processes of a specialized accounting module as part of a comprehensive HR system. 
Research methods. The following methods were used in the work: 
− analysis of the regulatory framework and scientific-technical literature on the 
problem of automating accounting and HR management;  
− the theory of relational database design and object-oriented analysis;  
− methods of automated processing and validation of personal data;  
− algorithmic methods of document generation based on templates in accordance with 
state standards; 
− analysis of the functional features of a web-oriented HR system of a state institution 
and information security requirements. 
Approbation of the results of the work. The main provisions and results of the 
bachelor's qualification work were reported and discussed at the conference "Day of Stu-
dent Science of the Department of KNSA", April 22, 2026, Cherkasy, Ukraine. 
7
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 Technologi-
cal University Student Scientific and Practical Conference: 22–23 April 2026 / [edited by 
I. V. Melnyk]; Ministry of Education and Science of Ukraine, Cherkasy State Technologi-
cal University.  Cherkasy : Cherkasy State Technological University, 2026. p. 14. 
Keywords: HR SYSTEM, CONSCRIPTS ACCOUNTING, HR PROCESS AUTOMATION, 
PUBLIC INSTITUTION, SPRING BOOT, KOTLIN, COMPOSE MULTIPLATFORM, MVVM, 
KTOR CLIENT, POSTGRESQL, JWT, REST API, LIQUIBASE, DOCKER. 
8
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ ...... 10 
ВСТУП ................................................................................................................................ 13 
1 АНАЛІТИКО-ПОСТАНОВОЧНІ  ОСНОВИ РОЗРОБЛЕННЯ ................................. 17 
1.1 Предметна область та актуальність розроблення ................................................ 17 
1.2 Аналіз існуючих рішень та обґрунтування власної розробки ............................ 18 
1.3 Технологічний стек та засоби розробки ............................................................... 18 
1.4 Архітектура системи та взаємодія компонентів .................................................. 22 
1.5 Функціональні та нефункціональні вимоги до модуля ....................................... 23 
1.6 Постановка науково-практичної задачі ................................................................ 25 
1.7 Модель даних: ключовi сутностi та їх вiдносини ................................................ 26 
1.8 Пiдходи до тестування системи ............................................................................. 27 
Висновки до розділу 1 .................................................................................................. 28 
2 ПРОЄКТУВАННЯ ТА РЕАЛІЗАЦІЯ МОДУЛЯ ОБЛІКУ 
ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ ......... 29 
2.1 Предметний контекст та архітектура програмного рішення ............................ 29 
2.2 Проєктування моделі даних і REST API модуля ............................................... 32 
2.3 Реалізація серверної бізнес-логіки та підсистеми формування документів 
державного закладу освіти ........................................................................................... 36 
2.4 Реалізація клієнтської частини, безпеки та підсистем інтеграції даних ......... 37 
2.5 Реалізація підсистеми формування документів ................................................. 39 
2.6 Розгортання системи та тестування модуля ....................................................... 41 
Висновки до розділу 2 .................................................................................................. 43 
3 ТЕСТУВАННЯ ТА АНАЛІЗ РЕЗУЛЬТАТІВ .............................................................. 45 
3.1 Тестування CRUD-операцій реєстру військовозобовʼязаних ............................. 45 
3.2 Реалізація підсистеми аудиту дій користувачів ................................................... 48 
3.3 Реалізація головного екрану модуля обліку ......................................................... 52 
3.4 Реалізація екрану редагування облікового запису ............................................... 56 
Висновки до розділу 3 .................................................................................................. 60 
9
ДОДАТОК А. Cпецифікація 482.ЧДТУ.62288-01……………………………………..65 
ДОДАТОК Б. Інструкція користувача ............................................................................ 67 
ДОДАТОК В. Апробація кваліфікаційної роботи бакалавра ....................................... 71 
10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 
API – англ. Application Programming Interface – програмний інтерфейс застосунків;
BCrypt – криптографічна функція хешування паролів з адаптивним параметром 
складності;
BUFFERED – тип каналу передачі даних у Kotlin Coroutines з буферизацією по-
відомлень;
CI/CD – англ. Continuous Integration / Continuous Delivery – безперервна інтеграція та 
безперервне постачання програмного забезпечення;
CIO – англ. Coroutine-based I/O – рушій асинхронного введення-виведення бібліоте-
ки Ktor Client;
Compose Multiplatform – декларативний UI-фреймворк від JetBrains для розробки 
крос-платформних застосунків мовою Kotlin;
CRUD – англ. Create, Read, Update, Delete – чотири базові операції маніпулювання 
даними;
DTO – англ. Data Transfer Object – об’єкт передачі даних між шарами застосунку;
Docker – платформа контейнеризації програмного забезпечення;
GitLab CI – вбудована система безперервної інтеграції платформи GitLab;
HMAC-SHA256 – англ. Hash-based Message Authentication Code – алгоритм фор-
мування коду автентифікації повідомлень на основі хеш-функції SHA-256;
HR – англ. Human Resources – управління людськими ресурсами (кадрова служба);
HTTP – англ. HyperText Transfer Protocol – протокол передавання гіпертексту;
ICU – англ. International Components for Unicode – бібліотека підтримки юнікодних 
локалей і порівняння рядків;
IoC – англ. Inversion of Control – принцип інверсії управління в об’єктно-
орієнтованому програмуванні;
JPA – англ. Java Persistence API – специфікація об’єктно-реляційного відображення 
для платформи Java;
JSONB – двійковий формат зберігання JSON-даних у PostgreSQL з підтримкою ін-
дексації;
11
JWT – англ. JSON Web Token – відкритий стандарт (RFC 7519) передачі даних між 
сторонами у вигляді JSON-об’єкта з цифровим підписом;
Ktor Client – асинхронна HTTP-бібліотека для Kotlin;
Liquibase – інструмент контролю версій схеми реляційної бази даних;
MapStruct – компілятор-генератор реалізацій маперів Java/Kotlin-об’єктів без вико-
ристання рефлексії в рантаймі;
MVI – англ. Model-View-Intent – архітектурний патерн для реактивних UI-
застосунків з односпрямованим потоком даних;
MVVM – англ. Model-View-ViewModel – архітектурний патерн розробки інтер-
фейсів користувача;
OpenAPI – специфікація опису REST API (версія 3.0), що дозволяє автоматично ге-
нерувати документацію;
ORM – англ. Object-Relational Mapping – об’єктно-реляційне відображення; техно-
логія зв’язування реляційних таблиць з об’єктами мови програмування;
REST – англ. Representational State Transfer – архітектурний стиль побудови 
розподілених гіпермедіа-систем;
SideEffect – компонент архітектурного патерну MVI, що описує одноразові дії, які 
не відображаються у стані екрану;
SLF4J – англ. Simple Logging Facade for Java – абстрактний фасад журналювання для 
платформи Java;
Spring Boot – фреймворк розробки Java-застосунків з автоматичною конфігурацією 
та вбудованим вебсервером;
Spring Security – модуль фреймворку Spring для автентифікації та авторизації;
Spring Data JPA – модуль фреймворку Spring, що спрощує роботу з реляційними ба-
зами даних через специфікацію JPA;
SSE – англ. Server-Sent Events – технологія однонаправленого потоку подій від сер-
вера до клієнта через HTTP;
STATELESS – режим роботи Spring Security, за якого сервер не зберігає стан сесії 
між запитами;
12
Testcontainers – бібліотека для запуску Docker-контейнерів під час виконання авто-
матизованих тестів;
UUID – англ. Universally Unique Identifier – стандартизований 128-бітний іденти-
фікатор глобальної унікальності;
XSS – англ. Cross-Site Scripting – тип вразливості веб-застосунків, що дозволяє 
ін’єкцію довільного скрипту.
13
ВСТУП 
Актуальність теми. Цифровізація державного управління в Україні протягом 
останніх років стала стратегічним напрямом, що охоплює кадрові процеси, доку-
ментообіг, управління персоналом та контроль якості даних. Для державних установ 
це означає перехід від фрагментованих джерел інформації до централізованих, кон-
трольованих систем, які дозволяють швидко отримувати актуальні відомості, фор-
мувати звітність і забезпечувати прозорість процесів. У реальній практиці кадрова 
інформація часто розподілена між паперовими архівами, електронними таблицями 
та локальними базами. Така “інформаційна розрізненість” ускладнює підтримку ак-
туальності даних і створює ризики помилок при ручному внесенні та дублюванні 
відомостей. 
Сучасні HR-системи мають не лише зберігати інформацію, а й забезпечувати її 
перевірку, актуалізацію, контроль доступу та формування регламентованої доку-
ментації. Це вимагає технічно цілісної архітектури, стандартизованих моделей да-
них і чітких процесів оновлення. Особливо важливим є те, що кадрові процеси в 
державному секторі тісно пов’язані з нормативними вимогами, але надмірна кон-
центрація лише на правових аспектах часто відсуває на другий план інженерну 
складову. Саме тому в даній роботі акцент переноситься на архітектурні рішення, 
технологічний стек, підходи до тестування, розгортання та підтримки якості даних. 
На сьогодні типовими проблемами державних установ залишаються: 
− неуніфікованість форматів даних між різними підрозділами; 
− обмежена гнучкість звітності при зміні регламентів або форм; 
− складність інтеграції з іншими системами та сервісами; 
− недостатній рівень безпеки при роботі з чутливою інформацією; 
− відсутність процесного підходу, коли дані розглядаються як сукупність за-
писів без життєвого циклу (ЖЦ). 
Серед провідних компаній, що пропонують рішення в сфері HR-технологій, 
світове лідерство утримують SAP, Oracle та Workday. На українському ринку ваго-
мий внесок роблять компанії IT-Enterprise, SoftServe, GlobalLogic та M.E.Doc. Проте, 
14
більшість цих систем є або занадто коштовними для середніх державних установ, 
або потребують значної кастомізації під специфічні потреби до обліку.  
Сучасна світова інженерна практика в сфері розробки інформаційних систем 
базується на використанні розподілених архітектур та високих стандартів безпеки. 
Основними трендами, що були враховані при розробці модуля, є: 
Microservices and Containerization: застосування Docker та Spring Boot для 
створення незалежних сервісів, що забезпечує гнучкість при оновленні функціоналу. 
− API – first approach: проєктування чітких інтерфейсів для потенційної інте-
грації з державними сервісами. 
− Reactive UI: використання компонентно-орієнтованого підходу для створен-
ня динамічних форм введення даних з валідацією в реальному часі. 
− Zero Trust Security: впровадження архітектури нульової довіри та авториза-
ції на основі JWT – токенів для запобігання несанкціонованому доступу до даних. 
− Data Quality Management: використання алгоритмів для автоматичної пе-
ревірки коректності кодів ВУС та форматів документів. 
Не менш важливим є й процес розробки. Для державних установ критично 
важливе передбачуване впровадження, тому використання CI/CD, автоматизованого 
тестування та чіткої процедури delivery дозволяє знизити ризики при розгортанні. 
Практика показує, що саме відсутність системних процесів розробки часто призво-
дить до нестабільності, коли зміни “ламали” робочі сценарії. Впровадження CI/CD 
дає змогу контролювати якість кожної зміни, а автоматичні тести гарантують базову 
стабільність. 
Процес delivery включає не лише доставку нової версії, а й контрольоване роз-
гортання, можливість відкотів, моніторинг і відновлення після збоїв. Це важливо для 
державних установ, де зупинка системи може призвести до порушення регламент-
них строків. Тому, в роботі окремо розглядаються принципи керованого розгортан-
ня, підготовки середовища, конфігурації та контролю версій. 
Потребою в централізації кадрових даних, необхідністю забезпечити якість та 
безпеку інформації, вимогами до стабільності системи і потребою в сучасних інже-
15
нерних практиках, що гарантують передбачуваність процесів розробки та впро-
вадження. 
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра 
є проєктування та програмна реалізація модуля обліку військовозобов’язаних у 
складі HR-системи державного закладу, що забезпечить автоматизацію процесів 
збору, збереження та опрацювання персональних даних, а також оперативне фор-
мування регламентованої звітності згідно з чинним законодавством України. 
Для досягнення поставленої мети в роботі розв’язуються такі завдання: 
− проаналізувати вимоги до цифрової трансформації кадрових процесів у 
державних установах; 
− обґрунтувати архітектурні підходи і вибір технологічного стеку; 
− спроєктувати структуру реляційної бази даних і механізми доступу; 
− реалізувати серверну логіку обробки кадрових запитів та формування доку-
ментів; 
− створити клієнтський інтерфейс для роботи з реєстром; 
− налаштувати систему розмежування доступу і захищену автентифікацію; 
− провести тестування і оцінити ефективність автоматизації. 
Об’єкт дослідження: процеси ведення обліку персоналу за допомогою web- 
орієнтованої HR-системи державного закладу. 
Предмет дослідження: архітектура, принципи реалізації та процеси експлуа-
тації спеціалізованого модуля обліку в складі комплексної HR-системи. 
Методи дослідження: У роботі використано такі методи: 
− аналіз нормативно-правової бази та науково-технічної літератури з пробле-
ми автоматизації військового обліку та кадрового діловодства;  
− теорія проєктування реляційних баз даних та об’єктно-орієнтованого 
аналізу; 
− методи автоматизованої обробки та валідації персональних даних; 
− алгоритмічні методи генерації документів за шаблонами відповідно до дер-
жавних стандартів;  
16 
− аналіз особливостей функціонування web-орієнтованої HR-системи держав-
ного закладу та вимог до захисту інформації. 
Апробація результатів роботи. Основні положення і результати кваліфіка-
ційної роботи бакалавра доповідалися і були обговорені на конференції «День сту-
дентської науки кафедри КНСА», 22 квітня  2026 року, Черкаси, Україна. 
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило Русла-
нович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович) 
«Інформаційна автоматизована HR-система закладу вищої освіти» в День студент-
ської науки кафедри КНСА посів 1 місце. 
Публікації. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. 
П. Оксамитна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована 
HR-система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; Міні-
стерство освіти і науки України, Черкаський державний технологічний ун-т.  Черка-
си : ЧДТУ, 2026. С. 14. 
Наукова новизна полягає в комплексному поєднанні предметної області з ін-
женерними практиками: архітектурним проєктуванням, процесами тестування, ав-
томатизацією розгортання та контролем якості даних. 
Практичне значення роботи полягає в створенні працездатного прототипу 
модуля, придатного для впровадження та подальшого розвитку в умовах державного 
закладу. 
Взаємозв’язок з іншими науковими роботами полягає в продовженні до-
сліджень із цифровізації державних процесів, побудови захищених інформаційних 
систем і автоматизації кадрового документообігу. 
17 
1 АНАЛІТИКО-ПОСТАНОВОЧНІ  ОСНОВИ РОЗРОБЛЕННЯ 
1.1 Предметна область та актуальність розроблення 
Предметною областю дослідження є процес автоматизованого кадрового 
обліку в державному закладі освіти. Система охоплює зберігання персональних і 
службових відомостей про осіб, що перебувають на обліку, формування документів 
встановленого зразка, імпорт даних із зовнішніх джерел та фіксацію дій користу-
вачів. 
Проблема, яку вирішує дана робота, полягає у відсутності спеціалізованого 
програмного модуля, інтегрованого в корпоративну HR-систему. На практиці кад-
рові підрозділи використовують розрізнені засоби: частина даних зберігається в па-
перових картках, частина – в локальних таблицях Excel. Це призводить до дублю-
вання записів, неузгодженості даних та значних витрат часу на формування доку-
ментів вручну. 
Технічні виклики автоматизації зумовлені кількома факторами. 
 По-перше, доменна модель є складною: лише сутність Student містить понад 
35 полів різних типів – рядки, дати (LocalDate), булеві значення, ідентифікатори.  
По-друге, система повинна підтримувати два канали введення даних: заванта-
ження XLSX-файлу з нестандартними заголовками та міграцію через зовнішній 
REST API.  
По-третє, генерація документів є асинхронною операцією, що вимагає від-
стеження стану задачі в реальному часі.  
По-четверте, система повинна забезпечувати рольовий доступ і аудит змін у 
відповідності до вимог інформаційної безпеки. 
Актуальність теми кваліфікаційної роботи бакалавра визначається загаль-
ним курсом на цифровізацію державних установ. Впровадження спеціалізованого 
модуля дозволяє замінити ручні операції автоматизованим pipeline, забезпечити 
єдине джерело актуальних даних і знизити кількість помилок, пов'язаних із людсь-
ким фактором. 
 
18 
1.2 Аналіз існуючих рішень та обґрунтування власної розробки 
Аналіз ринку програмних рішень у сфері кадрового менеджменту показав на-
явність трьох груп продуктів: глобальні корпоративні HR-платформи, вітчизняні 
кадрово-облікові системи та неспеціалізовані інструменти загального призначення. 
До глобальних платформ належать SAP SuccessFactors [20] та Oracle HCM 
Cloud. Обидва продукти є повнофункціональними HR-рішеннями з підтримкою до-
кументообігу, аналітики та інтеграцій. Однак, їхня адаптація до специфіки вітчизня-
ного законодавства вимагає значних ресурсів і спеціалізованих партнерів-
інтеграторів. Крім того, вартість ліцензій і обслуговування є недоступною для біль-
шості державних закладів. 
Серед вітчизняних рішень виділяється система IT-Enterprise, яка охоплює кад-
ровий облік і має модулі для українських реалій. Проте, в публічній документації 
відсутня підтримка специфічного профільного обліку з кастомізованим набором 
реквізитів і шаблонів документів без залучення вендора. 
Неспеціалізовані інструменти (Microsoft Excel, Google Sheets) широко викори-
стовуються через доступність. Однак, вони позбавлені контролю доступу на рівні 
записів, аудиту змін, автоматизованої генерації документів за шаблоном і можли-
вості асинхронної обробки великих масивів даних. 
Проведений аналіз підтверджує, що жодне з наявних рішень не задовольняє 
одночасно вимогам до функціональної повноти, адаптованості до вітчизняних по-
треб і доступності для державних закладів освіти. Це обґрунтовує доцільність ро-
зробки власного спеціалізованого модуля. 
1.3 Технологічний стек та засоби розробки 
Вибір технологій визначався такими критеріями: зрілість і довгострокова 
підтримка, наявність екосистеми інструментів для автоматизованого тестування, 
можливість контейнеризованого розгортання та продуктивність для типового наван-
таження кадрової системи. 
19 
Серверна частина реалізована на платформі Spring Boot 3.3 [2] із Java 23. 
Spring Boot [2], забезпечує автоматичну конфігурацію, вбудований сервер Tomcat, 
інтеграцію з Spring Security [3] і Spring Data JPA. Версія Java 23 дозволяє використо-
вувати сучасні мовні конструкції, зокрема records і switch – вирази, що застосову-
ються у коді імпорту та обробки помилок. Група artifact: ua.edu.chdtu.hr, назва збір-
ного JAR: app.jar. 
Клієнтська частина реалізована як Desktop– застосунок на Kotlin [5] із викори-
станням Compose Multiplatform [6] (версія KMP). Фреймворк надає декларативний 
підхід до побудови UI, схожий із Jetpack Compose для Android, що дозволяє опису-
вати інтерфейс як функції від стану. Для мережевої взаємодії використовується 
бібліотека Ktor Client [7] (CIO engine) із серіалізацією через kotlinx.serialization. Ар-
хітектурний патерн клієнта – MVVM: ViewModel управляє станом екрану, а 
Composable – функції лише відображають його. 
Для зберігання даних обрано PostgreSQL 16 [8] із налаштуванням локалі ICU 
(– icu– locale=uk), що забезпечує коректне сортування і порівняння рядків у кири-
личному алфавіті.  
Схема бази даних версіонується через Liquibase [9]: наявні 12 changelog– 
файлів (001 – 012), які описують еволюцію схеми від початкового стану до поточно-
го. Такий підхід дозволяє відтворити точну версію схеми на будь – якому середо-
вищі без ручних SQL-скриптів. 
Генерація документів реалізована за допомогою бібліотеки Apache POI 5.2.5 
(артефакти poi – ooxml та poi – scratchpad) [11].  
Система підтримує два формати виводу:  
− DOCX і PDF. DOCX генерується безпосередньо заповненням шаблону через 
XWPFDocument;  
− PDF отримується конвертацією через LibreOffice [19] у headless – режимі.  
Для читання XLSX при імпорті використовується бібліотека Poiji 4.9.0 [12], 
яка забезпечує прив'язку рядків таблиці до Java – об'єктів через анотації.  
Технологічний стек проєкту представлено в таблиці 1.1.  
 
20 
Таблиця 1.1 – Технологічний стек проєкту 
Компонент Технологія / Версія Призначення 
Backend Spring Boot 3.3 [2],  REST API, бізнес-логіка 
Java 23 
Desktop Client Kotlin [5], Compose Desktop UI, MVVM, Ktor Client [7] 
Multiplatform [6] 
База даних PostgreSQL 16 [8] Зберігання даних 
Міграції БД Liquibase (12 changeset) Версіонування схеми 
[9] 
Генерація Apache POI 5.2.5 [11] DOCX / PDF з шаблонів 
документів 
Читання XLSX Poiji 4.9.0 [12] Прив'язка рядків до об'єктів 
Безпека Spring Security [3] + JWT– автентифікація, ролі [13] 
JJWT 0.12.5 
API– документація Springdoc OpenAPI Swagger UI [14] для REST API  
2.8.5 
Контейнеризація Docker + Docker Com- Розгортання сервісів 
pose 3.8 [15] 
CI/CD GitLab CI (gradle:jdk23 Build + integration tests 
– alpine) 
Тестування JUnit 5 [16], Testcon- Інтеграційні тести з реальною БД 
tainers [17] 
Code style Checkstyle 10.8.0 [18] Статичний аналіз коду 
Для вирішення вказаних завдань у межах колективного проєкту було спроєк-
товано комплексну структуру, що об'єднує розробки чотирьох авторів у єдину еко-
систему. Взаємозв'язок функціональних модулів загальної HR-системи військового 
обліку ЗВО наведено на рисунку 1.1. 
21 
 
Рисунок 1.1 – Схема взаємозв'язку функціональних модулів у складі комплексної 
HR-системи військового обліку 
Як видно з рисунка, розроблена HR-система військового обліку державного 
закладу освіти інтегрує чотири функціональні модулі в єдину захищену екосистему: 
− Модуль інтеграції та міграції даних (Модуль 1) відповідає за первинне на-
повнення бази даних, дозволяючи імпортувати інформацію про студентів та співро-
бітників із зовнішніх інформаційних систем університету або XLSX/CSV файлів. 
− Модуль обліку військовозобов’язаних (Модуль 2) є ядром системи, яке збері-
гає структуровані картки обліку військовозобов'язаних осіб, їхні персональні та вій-
ськово-облікові дані. 
− Модуль формування довідок та звітів (Модуль 3) використовує дані з ядра 
системи для автоматичного генерування регламентованих документів. 
− Модуль контролю доступу та безпеки (Модуль 4) виступає як захисний ба-
р'єр системи, забезпечуючи автентифікацію користувачів, розмежування ролей (ад-
міністратор, інспектор відділу кадрів) та ведення журналів аудиту дій. 
22 
1.4 Архітектура системи та взаємодія компонентів 
Система побудована за клієнт-серверною архітектурою з чітким розподілом 
відповідальностей між компонентами. Серверна частина реалізує всю бізнес-логіку і 
надає REST API; клієнтська частина Desktop UI – взаємодіє з сервером виключно 
через HTTP-запити. Така архітектура дозволяє незалежно розвивати та тестувати 
кожен компонент. 
Серверна частина має шарову структуру:  
− шар контролерів (api/v1/controller) приймає HTTP-запити і делегує обробку 
сервісному шару;  
− сервісний шар містить бізнес-логіку і взаємодіє з репозиторіями через 
Spring Data JPA;  
− репозиторії виконують запити до PostgreSQL.  
Для перетворення між сутностями і DTO використовується MapStruct [10] – 
компілятор генерує реалізації маперів на етапі компіляції, що виключає рефлексію в 
рантаймі. 
Окремо виділено модуль безпеки (auth/security): JwtAuthenticationFilter пере-
хоплює кожен HTTP-запит, витягує токен із заголовка Authorization, верифікує під-
пис через JwtUtil (HMAC – SHA256) і встановлює контекст автентифікації у 
SecurityContextHolder. Конфігурація SecurityConfig визначає відкриті ендпоінти 
(/api/v1/auth/**, /actuator/health) і захищені маршрути. 
Модуль документогенерації реалізовано як асинхронний pipeline на основі па-
терну Chain of Responsibility. Кожен крок генерації інкапсульований у окремому 
StateHandler– компоненті. StateHandlerProxy виконує роль диспетчера: при надхо-
дженні події він знаходить відповідний обробник у Map<State, StateHandler> і деле-
гує йому Task. Такий дизайн дозволяє додавати нові кроки pipeline без зміни існую-
чого коду. 
Зворотний зв'язок із клієнтом під час генерації документа реалізовано через 
Server – Sent Events (SSE). Після виклику GET /api/v1/students/{id}/documents/{type} 
сервер повертає taskId, клієнт підписується на /documents/{taskId}/stream і отримує 
23 
події стану у реальному часі. Після завершення клієнт завантажує файл через GET 
/documents/{taskId}/download.  
Загальну архітектуру взаємодії компонентів системи наведено на рисунку 1.2. 
 
Рисунок 1.2 – Архітектура системи 
1.5 Функціональні та нефункціональні вимоги до модуля 
На підставі аналізу предметної області, огляду аналогів і технічних обмежень 
сформовано повний перелік вимог до модуля. 
Функціональні вимоги: 
– перегляд реєстру записів із пагінацією (розмір сторінки 1–100, за замовчу-
ванням 10), сортуванням за будь – яким полем і фільтрацією; 
– повнотекстовий пошук за прізвищем, ім'ям, по – батькові, ідентифікаційним 
кодом і зовнішнім ID (реалізовано через JPA Specification [4] із токенізацією запи-
ту); 
24 
– фільтрація за факультетом, віком (до 25 / від 25 років) та ознакою реєстра-
ції; 
– перегляд і редагування деталізованої картки запису (PUT 
/api/v1/students/{id}); 
– асинхронна генерація документів у форматі DOCX або PDF із відстеженням 
стану через SSE; 
– імпорт даних із XLSX-файлу: підтримка 5 форматів дат, розбиття адреси на 
реєстраційну і фактичну, дедублікація за ІПН, звіт із деталями (до 100 рядків); 
– міграція даних із зовнішнього REST API: пакетна обробка по 100 записів, 
пул із 10 потоків, upsert за externalId; 
– журналювання дій користувачів (AuditLog) із фіксацією автора, часу та змі-
сту операції; 
– автентифікація через POST /api/v1/auth/login із видачею JWT– токена [13]. 
Нефункціональні вимоги: 
– час відповіді REST API для пагінованих запитів – не більше 500 мс при ти-
повому навантаженні; 
– розгортання усіх сервісів (app + postgres_db) командою docker compose up 
без додаткових налаштувань; 
– версіонування схеми БД через Liquibase [9]: нова версія розгортається авто-
матично при старті застосунку; 
– OpenAPI – специфікація для всіх публічних ендпоінтів, доступна через 
Swagger UI (/swagger – ui.html) [14]; 
– конфігурація через змінні середовища (DB_URL, DB_USERNAME, 
DB_PASSWORD, SERVER_PORT, jwt.secret) без хардкоду; 
– статичний аналіз коду Checkstyle 10.8.0 [18] інтегровано у процес збирання; 
– інтеграційні тести запускаються в ізольованому PostgreSQL – контейнері 
через Testcontainers. 
Безпекові вимоги: 
– JWT – токени підписуються алгоритмом HMAC-SHA256, термін дії налаш-
товується через jwt.expiration [13]; 
25 
– паролі зберігаються у вигляді BCrypt – хешу (BCryptPasswordEncoder); 
– sessionCreationPolicy = STATELESS –  сервер не зберігає сесій; 
– ендпоінт /actuator/** доступний лише ролі ADMIN; /actuator/health відкри-
тий для health– check Docker [15]; 
– усі інші маршрути вимагають валідного JWT у заголовку Authorization: 
Bearer <token>. 
Діаграма варіантів використання системи наведена на рисунку 1.3. 
 
Рисунок 1.3 – Діаграма прецедентів (Use Case) 
1.6 Постановка науково-практичної задачі 
На підставі проведеного аналізу сформульовано задачу дослідження: розроби-
ти та обґрунтувати модуль обліку в складі HR-системи державного закладу, що реа-
26 
лізує повний цикл роботи з обліковими записами  від введення та пошуку до генера-
ції документів, аудиту і захисту даних, і придатний до розгортання без залучення 
спеціалізованих вендорів. 
Об'єктом дослідження є процес автоматизованого кадрового обліку в держав-
ному закладі освіти. Предметом дослідження є методи і засоби реалізації програм-
ного модуля з асинхронною документогенерацією, гнучким пошуком і захищеним 
REST API у стеку Spring Boot [2] / Compose Multiplatform [6] / PostgreSQL. 
Наукова складова полягає в обґрунтуванні архітектурних рішень: застосуван-
ня патерну Chain of Responsibility для pipeline документогенерації, використання 
JPA Specification [4] для динамічної побудови SQL-запитів із токенізацією пошуко-
вого рядка, а також поєднання SSE і UUID-ідентифікаторів задач для асинхронного 
відстеження стану. 
Практична складова – створення працездатного програмного продукту, який 
включає: серверний застосунок (Spring Boot, ~70 Java-класів), Desktop-клієнт (Kotlin 
[5] / Compose Multiplatform [6]), налаштований CI/CD pipeline (GitLab CI із двома 
стадіями: build та integration_test) і Docker Compose [15] конфігурацію для продук-
тивного та dev – середовищ. 
1.7 Модель даних: ключовi сутностi та їх вiдносини 
Модель даних системи побудована навколо двох основних сутностей: Student i 
Task, а також допомiжних – AppUser та AuditLog. Усi сутностi є JPA Entity iз авто-
матичним вiдображенням на таблицi PostgreSQL через Hibernate ORM. Iдентифiка-
тори всiх сутностей мають тип UUID – це забезпечує глобальну унiкальнiсть i уне-
можливлює передбачення наступного ID зловмисником (на вiдмiну вiд послiдовних 
числових iдентифiкаторiв). 
Сутнiсть Student є центральною доменною моделлю i мiстить понад 35 атри-
бутiв, що вiдповiдають реквiзитам облiкової картки: персональнi данi (firstName, 
lastName, patronymic, birthDate, identificationCode), адреснi данi у двох варiантах 
(registrationAddress i actualAddress, з окремими пiдполями street, building, apartment, 
city, region), освiтнi вiдомостi (faculty, speciality, year, studentGroup), ознаки статусу 
27 
(registered, deregistered, militaryRank). Для зовнiшньої iнтеграцiї передбачено поле 
externalId, що зберiгає iдентифiкатор iз зовнiшньої системи i використовується для 
upsert при мiграцiї даних. 
Сутнiсть Task реалiзує асинхронний pipeline документогенерацiї. Вона мiстить 
зовнiшнiй ключ на Student (studentId), тип документа (documentType), поточний стан 
машини станiв (state типу State enum), а також JSONB – поле payload, яке зберiгає 
довiльнi данi мiж кроками pipeline. Використання JSONB (нативний JSON – тип 
PostgreSQL) дозволяє кожному StateHandler зберiгати власнi промiжнi результати 
без змiни схеми таблицi. Поля createdAt i updatedAt заповнюються автоматично че-
рез анотацiї CreationTimestamp i UpdateTimestamp. 
Сутнiсть AppUser зберiгає облiковi данi користувачiв системи: username, 
passwordHash (BCrypt), email та роль (role). Сутнiсть AuditLog фiксує кожну змiну 
даних: назву дiї (action), iдентифiкатор автора (userId), часову мiтку (timestamp) i 
iдентифiкатор змiненого запису (targetId). Разом вони забезпечують журналювання 
всiх операцiй вiдповiдно до вимог iнформацiйної безпеки. 
1.8 Пiдходи до тестування системи 
Якiсть i коректнiсть реалiзованої системи пiдтверджується автоматизованими 
iнтеграцiйними тестами, написаними з використанням JUnit 5 [16] i Testcontainers 
[17]. Testcontainers автоматично запускає iзольований PostgreSQL – контейнер (на 
основi Docker [15] – образу postgres:16) перед виконанням тестiв i зупиняє його 
пiсля завершення. Така стратегiя гарантує, що тести виконуються проти реальної 
СУБД iз такою самою версiєю i конфiгурацiєю, що i в продуктивному середовищi, а 
не проти in-memory замiнника типу H2, який може мати вiдмiнностi у поведiнцi. 
Кожен iнтеграцiйний тест розширює базовий клас iз анотацiєю 
@SpringBootTest (webEnvironment = RANDOM_PORT), що запускає повний кон-
текст Spring, включно з шаром безпеки i HTTP-сервером. Для виконання HTTP-
запитiв у тестах використовується TestRestTemplate. Перед кожним тестом через 
Liquibase [9] автоматично застосовуються всi мiграцiї, а пiсля завершення тесту база 
28 
очищається через AfterEach – хук. Це забезпечує iзольованiсть та вiдтворюванiсть 
кожного тест-кейсу. 
Тести охоплюють наступнi сценарiї: автентифiкацiя (успiшний логiн, непра-
вильний пароль, запит без токена), CRUD – операцiї зi студентами (пагiнований пе-
регляд, оновлення картки, фiльтрацiя та пошук), iмпорт iз XLSX-файлу (коректний 
файл, файл iз помилковими форматами дат, дубльований запис), а також старт i 
трекiнг задачi документогенерацiї (перевiрка переходiв станiв i SSE – подiй). CI/CD 
конвеєр GitLab CI запускає тести на кожному push у два стейджi: build (gradle as-
semble + checkstyleMain) i integration_test (gradle integrationTest). 
Висновки до розділу 1  
У розділі проведено аналіз предметної області автоматизованого кадрового 
обліку, визначено технічні виклики реалізації та проаналізовано наявні програмні 
аналоги. Огляд показав, що жодне з існуючих рішень не задовольняє одночасно ви-
могам до функціональної повноти, адаптованості та доступності для державних за-
кладів. 
Обґрунтовано вибір технологічного стеку: Spring Boot 3.3 і Java 23 для сервер-
ної частини, Kotlin і Compose Multiplatform для Desktop – клієнта, PostgreSQL 16 із 
Liquibase для версіонованого зберігання даних, Apache POI для генерації доку-
ментів, Docker Compose для контейнеризованого розгортання і GitLab CI для авто-
матизованого збирання й тестування. 
Сформовано повний перелік функціональних, нефункціональних і безпекових 
вимог, що є основою для проєктування і реалізації модуля, описаних у Розділі 2. 
29 
2 ПРОЄКТУВАННЯ ТА РЕАЛІЗАЦІЯ МОДУЛЯ ОБЛІКУ ВІЙСЬКОВОЗОБ-
ОВ’ЯЗАНИХ У HR-СИСТЕМІ ДЕРЖАВНОГО ЗАКЛАДУ 
2.1  Предметний контекст та архітектура програмного рішення 
Облік військовозобовʼязаних у державному закладі освіти є регламентованим 
процесом, що здійснюється відповідно до Закону України «Про військовий 
обовʼязок і військову службу» та підзаконних нормативних актів Кабінету Міністрів 
України. Відповідальність за ведення обліку покладається на керівника закладу і 
уповноважену посадову особу кадрового підрозділу. Основним обліковим докумен-
том є персоніфікована картка форми № 2 («Облікова картка призовника / військо-
возобовʼязаного»), яка містить понад 35 реквізитів: прізвище, імʼя та по батькові, 
дату народження, реєстраційний номер облікової картки платника податків, місце 
проживання (зареєстроване та фактичне), дані про освіту, військовий облік (звання, 
спеціальність, категорія запасу) та статус реєстрації або зняття з обліку. 
Заклад зобовʼязаний вести актуальний реєстр, своєчасно повідомляти район-
ний (міський) територіальний центр комплектування та соціальної підтримки про 
зміни у персональних даних підконтрольних осіб, а також формувати і надсилати 
звітну документацію встановлених форм у визначені строки. Порушення термінів 
або неповнота відомостей тягнуть адміністративну відповідальність [1], посадових 
осіб відповідно до статті 210 Кодексу України про адміністративні правопорушення. 
На практиці кадровий підрозділ більшості державних закладів веде облік у ро-
зрізнених і погано інтегрованих джерелах: паперові картки форми № 2, що зберіга-
ються у картотеці; таблиці Microsoft Excel із частково дубльованими даними; записи 
у загальній кадровій системі закладу, що не має спеціального модуля для військово-
го обліку. Така «інформаційна розрізненість» породжує системні проблеми: дублю-
вання і розбіжність даних між джерелами, несвоєчасне оновлення при зміні адреси 
або статусу особи, значні витрати часу кадровика на ручне заповнення бланків і 
підготовку звітів, відсутність журналу операцій, що унеможливлює службову пе-
ревірку дій персоналу. 
30 
Розроблений модуль вирішує перелічені проблеми: централізує зберігання 
всіх реквізитів облікової картки в єдиній реляційній базі даних, надає пошук і філь-
трацію по будь-якому реквізиту, автоматизує генерацію документів за затверджени-
ми шаблонами у форматах DOCX і PDF, підтримує пакетний імпорт із XLSX- 
файлів існуючих баз, а також веде журнал аудиту всіх значущих операцій із зазна-
ченням виконавця і часу. Типовий робочий сценарій кадровика: знайти особу за 
прізвищем або ІПН, переглянути і оновити картку, згенерувати потрібний документ 
за шаблоном  –  і всі ці дії виконуються в одному застосунку без переходу між різ-
ними програмами. 
Архітектура програмного рішення побудована за клієнт-серверним принципом 
з чітким розподілом відповідальностей. Серверна частина (Spring Boot 3.3 [2], Java 
23) реалізує всю бізнес-логіку і надає REST API з базовим префіксом /api/v1. 
Desktop-клієнт (Kotlin [5], Compose Multiplatform [6]) взаємодіє з сервером виключ-
но через HTTP-запити з JWT-авторизацією [13]. PostgreSQL 16 [8] є єдиним схови-
щем даних; еволюція схеми керується через 12 Liquibase changelog – файлів [9]. Усі 
компоненти пакуються в Docker – образи і розгортаються через Docker Compose [15] 
без ручного налаштування. 
Вибір клієнт-серверної архітектури обґрунтований порівнянням трьох альтер-
натив: монолітний застосунок із вбудованим Web UI, мікросервісна архітектура та 
обрана клієнт-серверна модель із Desktop-клієнтом. Оцінка проводилась за пʼятьма 
критеріями, що є критичними для кадрового підрозділу державного закладу: захист 
персональних даних, простота розгортання, автономна робота клієнта, тестованість і 
вартість підтримки. Результати порівняння наведені в таблиці 2.1. 
Таблиця 2.1 – Порівняльний аналіз архітектурних підходів 
Критерій оцінки Моноліт + Мікросервіси REST API + Desktop 
Web UI (обрано) 
Захист 3 – дані в 3 – складне 5 – вся логіка ізольована 
персональних браузері розмежування на сервері 
даних користувача між сервісами 
Простота 4 – один арте- 2 – N сервісів, 4 – лише 2 Docker –  
розгортання факт, оркестратор контейнери 
але потрібен (K8s) 
вебсервер 
31 
Автономна 2 – потребує 2 – потребує 4 – Desktop – застосунок 
робота клієнта браузер постійну з офлайн – кешем 
і мережу мережу 
Тестованість 3 – складно 3 – потрібні 5 – JUnit 5 + 
ізолювати contract – Testcontainers 
UI від логіки тести 
Вартість 3 – складність 2 – висока 5 – Gradle + Docker, 
підтримки зростає з (DevOps – мінімальний DevOps 
обсягом інфра) 
Загальна оцінка 3 2 5 – обрано 
(1–5) 
Моноліт із Web UI відхилено через залежність від браузера і відсутність 
надійної ізоляції персональних даних на клієнтській стороні. Мікросервісна архітек-
тура є надмірно складною для проєкту, що розробляється однією людиною, і вима-
гає окремого DevOps-контуру (Kubernetes, service mesh, централізований API – 
Gateway) без відчутного виграшу для поточного масштабу. Обрана модель забезпе-
чує найвищу оцінку за трьома критичними параметрами і відповідає вимогам захи-
сту персональних даних в умовах державного закладу. 
Серверна частина має чотирьохшарову структуру. Шар контролерів (пакет 
api.v1.controller) приймає HTTP-запити, виконує первинну валідацію вхідних пара-
метрів через анотації @Valid і @Validated та делегує обробку сервісному шару. 
Сервісний шар (пакет service) реалізує бізнес-логіку: StudentService, DocumentSer-
vice, StudentImportService, MigrationService і AuditService. Репозиторний шар (пакет 
repository) взаємодіє з PostgreSQL через Spring Data JPA; складні запити з фільтра-
цією будуються через JPA Specification [4] без написання JPQL-рядків вручну. Шар 
маперів (MapStruct 1.5) [10] перетворює Entity ↔ DTO за допомогою анотацій 
@Mapper без рефлексії в рантаймі. 
Окремо виділено модуль безпеки (пакет auth.security) та модуль документоге-
нерації (пакет document.pipeline). Клас JwtAuthenticationFilter розширює OncePerRe-
questFilter і перехоплює кожен HTTP-запит до захищених ресурсів. Клас 
StateHandlerProxy реалізує диспетчеризацію задач документогенерації між 
StateHandler – ами за поточним станом машини станів Task. 
32 
Взаємодія між компонентами відповідає принципу «залежність тільки вниз по 
шарам»: контролери залежать від сервісів, сервіси – від репозиторіїв і маперів, репо-
зиторії – від JPA-сутностей. Модулі безпеки та документогенерації підключаються 
як Spring Bean – і без циклічних залежностей. Desktop-клієнт є повністю незалежним 
застосунком: він не має прямого доступу до БД і не містить бізнес-логіки – уся 
обробка даних виконується на сервері. Це забезпечує однорідність бізнес-правил не-
залежно від того, скільки клієнтів підключено одночасно. 
Клієнтська частина побудована за патерном MVI (Model-View-Intent), що є ро-
звитком MVVM для реактивних систем із складними станами. Основна відмінність 
від MVVM полягає у введенні третього компонента – SideEffect: одноразової дії, яка 
не відображається у стані, але повинна бути виконана UI (відкрити файл, показати 
повідомлення, навігувати). SideEffect передається через 
Channel<SideEffect>(BUFFERED), що гарантує доставку навіть при тимчасовій від-
сутності підписника. Такий підхід унеможливлює «гонку стану» при асинхронних 
операціях і спрощує тестування ViewModel у повній ізоляції від UI-компонентів. 
2.2 Проєктування моделі даних і REST API модуля 
Модель даних розроблена з урахуванням двох вимог: нормативної повноти 
реквізитів облікової картки військовозобовʼязаного (форма № 2) і практичної ефек-
тивності їх збереження та обробки в СУБД. Реляційний підхід обраний через підт-
римку складних вибірок, транзакцій і розширеного типу JSONB у PostgreSQL 16 [8]. 
Усі сутності реалізовані як JPA Entity із відображенням на таблиці через Hibernate 
ORM. Ідентифікатори мають тип UUID (версія 4, генерується на рівні додатку через 
UUID.randomUUID()), що унеможливлює передбачення наступного ID і відповідає 
вимогам захисту персональних даних. 
Модель складається з чотирьох основних сутностей: Student, Task, AppUser та 
AuditLog. Центральна сутність Student відображається на таблицю students і містить 
понад 35 атрибутів, що покривають повний реквізитний склад нормативної картки. 
Персональні дані: firstName, lastName, patronymic (ПІБ), birthDate (дата народжен-
ня), identificationCode (РНОКПП). Дані військового обліку: militaryRank (звання), 
33 
militarySpecialty (ВОС  –  військово-облікова спеціальність), reserveCategory (категорія 
запасу: 1 або 2). Адресні дані подано у двох варіантах  –  registrationAddress (зареєс-
трована адреса) та actualAddress (фактичне місце проживання), кожна з підполями: 
street, building, apartment, city, region, postalCode. Освітні відомості: faculty, speciality, 
year, studentGroup. Статусні ознаки: registered (bool), deregistered (bool), deregistra-
tionDate і deregistrationReason. Поле externalId зберігає ідентифікатор із зовнішньої 
системи для підтримки upsert при міграції даних. 
Сутність Task реалізує асинхронний pipeline документогенерації. Поле state 
(PostgreSQL ENUM State) зберігає поточний стан машини станів: NEW, DA-
TA_FETCHING, VALIDATE, FILLING_TEMPLATE, COMPLETED або FAILED. 
Поле payload має тип JSONB – нативний JSON – тип PostgreSQL – і дозволяє кож-
ному StateHandler – зберігати довільні проміжні дані між кроками pipeline без зміни 
схеми таблиці. Поля createdAt і updatedAt заповнюються автоматично через 
@CreationTimestamp і @UpdateTimestamp. Зовнішній ключ studentId повʼязує задачу 
з обліковою карткою і має ON DELETE CASCADE. 
AppUser зберігає облікові дані кадровиків і адміністраторів: username 
(унікальний), passwordHash (BCrypt), email, role (enum: USER, ADMIN). AuditLog 
фіксує кожну значущу операцію: поля userId (FK до AppUser), targetId (ID зміненого 
запису), action (тип операції: STUDENT_UPDATED, DOCUMENT_GENERATED, 
IMPORT_COMPLETED, MIGRATION_COMPLETED), detail (текст деталей) і 
timestamp. Наявність AuditLog є обовʼязковою вимогою для систем, що обробляють 
персональні дані в державному секторі, оскільки забезпечує можливість службової 
перевірки дій кожного користувача. 
Структурні зв'язки між сутностями моделі даних наведені на рисунку 2.1. Stu-
dent є центральною сутністю: вона пов'язана з Task через зовнішній ключ studentId 
(один Student – багато Task, ON DELETE CASCADE) і з AuditLog через targetId (за-
пис аудиту містить ID зміненого об'єкта). AppUser пов'язаний з AuditLog через 
userId – кожен запис журналу знає, хто виконав операцію. 
ER-діаграма моделі даних модуля обліку представлена на рис. 2.1. 
34 
 
Рисунок 2.1 – ER-діаграма моделі даних модуля обліку 
REST API побудовано за принципом Resource – Oriented Design із базовим 
префіксом /api/v1, що забезпечує версіонування контракту. Специфікація OpenAPI 
3.0 генерується автоматично бібліотекою Springdoc 2.8.5 з анотацій @Operation та 
@ApiResponse і доступна через Swagger UI (/swagger – ui.html) [14]. Такий code – 
first підхід гарантує відповідність документації реальній реалізації: специфікація 
оновлюється при кожному перезапуску сервера без ручних змін. 
Пагінація і фільтрація реєстру реалізовані через Spring Data Pageable. Клієнт 
передає query – параметри: page (номер сторінки від 0), size (розмір, 1–100, за за-
35
мовчуванням 10), sort (наприклад sort=lastName,asc), search (рядок пошуку), faculty, 
registered, ageGroup. Загальна кількість сторінок обчислюється за формулою:
totalPages = [ totalElemen t s  / pageS ize ]         (2.1)
де totalElements – загальна кількість записів, що відповідають застосованим 
фільтрам; 
pageSize – розмір сторінки (від 1 до 100, за замовчуванням 10); 
Відповідь повертається у вигляді Page<StudentResponse> із полями content 
(масив записів поточної сторінки), totalElements, totalPages і number (поточна 
сторінка). Динамічна фільтрація реалізована через JPA Specification: пошуковий ря-
док токенізується по пробілу; кожен токен перетворюється на ILIKE – предикат по 
полях lastName, firstName, patronymic, identificationCode. Усі предикати зʼєднуються 
через AND через Specification.and(), що дозволяє складні багатокритеріальні запити 
без написання окремого JPQL для кожної комбінації. 
Для передачі даних між контролером і сервісом використовуються спеціалізо-
вані DTO (Data Transfer Object), розділені на вхідні (Request) і вихідні (Response): 
StudentRequest і StudentResponse  –  для операцій з карткою, StudentListResponse  – 
для пагінованого реєстру (містить лише ключові реквізити, без повного набору 
полів), DocumentRequest – для ініціювання генерації (тип документа), 
ImportStudentsResultDTO – результат пакетного імпорту. Перетворення Entity ↔ 
DTO виконує MapStruct [10]: реалізації маперів генеруються компілятором під час 
збирання через анотацію @Mapper(componentModel = "spring"), що виключає ре-
флексію і знижує накладні витрати в рантаймі.
Обробка помилок централізована через @ControllerAdvice (клас 
GlobalExceptionHandler). ResourceNotFoundException (HTTP 404) повертається при 
відсутності запису з вказаним ID. ValidationException (HTTP 422) – при порушенні 
бізнес-правил (наприклад, відсутні обовʼязкові поля для генерації документа). 
AccessDeniedException перехоплюється Spring Security [3] і повертає HTTP 403 без 
витоку деталей внутрішньої логіки. Усі відповіді з помилками мають єдину структу-
ру: поля status, error, message і timestamp, що спрощує обробку на клієнті.
36 
2.3 Реалізація серверної бізнес-логіки та підсистеми формування докумен-
тів державного закладу освіти 
Серверна бізнес-логіка організована за принципом єдиної відповідальності: 
кожна функціональна зона виділена в окремий Spring-сервіс. StudentService 
обробляє CRUD – операції з реєстром і конструює JPA Specification [4] – запити для 
пошуку і фільтрації. DocumentService оркеструє асинхронний pipeline документоге-
нерації і реєструє SseEmitter для кожного taskId. StudentImportService виконує пар-
синг XLSX-файлів і пакетний upsert. MigrationService синхронізує дані через Feign 
Client у пулі з 10 потоків. AuditService зберігає AuditLog – записи в межах тієї ж 
транзакції @Transactional, в якій виконується основна операція, що гарантує ато-
марність збереження даних і журналу. 
Переддокументна валідація реалізована у ValidationHandler. Для кожного типу 
документа визначено Set<String> обовʼязкових полів. Обробник перевіряє, чи всі 
поля із цього набору присутні і непорожні у payload Task. Якщо хоча б одне поле 
відсутнє, Task переводиться в стан FAILED і через SseEmitter надсилається подія з 
переліком відсутніх реквізитів. Це дозволяє кадровику одразу побачити, які дані по-
трібно заповнити, без очікування завершення повного pipeline. 
Система підтримує чотири типи документів, що є найпоширенішими в прак-
тиці кадрового обліку військовозобовʼязаних у державному закладі: 
1) STUDY_CERTIFICATE (довідка про місце навчання / роботи) – надається 
для підтвердження статусу в ТЦК;  
2) MILITARY_NOTIFICATION (повідомлення до ТЦК) – про зміну персона-
льних даних або статусу;  
3) ACCOUNTING_CARD (облікова картка форми № 2) – базовий нормативний 
документ;  
4) REGISTRATION_ORDER (наказ про постановку на облік або зняття) – вну-
трішній документ закладу.  
Кожен тип має окремий шаблон у форматі DOCX, розміщений у classpath – 
директорії templates/. 
37 
Підсистема документогенерації реалізована як асинхронний pipeline на основі 
патерну Chain of Responsibility. Центральним компонентом є StateHandlerProxy – 
Spring @Component, що інжектує Map<State, StateHandler> через конструктор. При 
надходженні TransitionEvent (стан + taskId) StateHandlerProxy знаходить відповідний 
обробник у Map і делегує йому поточний обʼєкт Task. Кожен StateHandler змінює 
поля Task, зберігає через TaskRepository і публікує SSE – подію через зареєстрова-
ний SseEmitter. Обробники зареєстровані як Spring Bean – и і можуть незалежно те-
стуватися через @MockBean. 
Генерація DOCX виконується через XWPFDocument (Apache POI 5.2.5) [11]. 
TemplateFillingHandler завантажує шаблон через 
getClass().getResourceAsStream("templates/" + type + ".docx"), ітерує по всіх парагра-
фах документа і по рядках вбудованих таблиць, знаходить плейсхолдери виду 
{{fieldName}} і замінює їх значеннями, десеріалізованими з payload JSONB. Гото-
вий DOCX зберігається у файловому сховищі. Конвертація у PDF виконується через 
ProcessBuilder: soffice – headless – convert – to pdf – outdir {dir} {file.docx}. 
LibreOffice [19] запускається в окремому процесі; таймаут – 30 секунд, при переви-
щенні Task → FAILED. 
Після переходу в стан COMPLETED файл доступний через GET 
/documents/{taskId}/download. Контролер завантажує файл із сховища через 
FileSystemResource, встановлює заголовок Content-Disposition: attachment; 
filename="document.docx" і повертає ResponseEntity<Resource> з кодом 200. Пряме 
звернення до файлового сховища без taskId неможливе, оскільки 
TaskRepository.findByIdAndUserId() перевіряє належність задачі поточному автен-
тифікованому користувачу, виключаючи доступ до документів інших кадровиків. 
2.4 Реалізація клієнтської частини, безпеки та підсистем інтеграції даних 
Клієнтська частина реалізована як Compose Multiplatform Desktop [6] – засто-
сунок за архітектурним патерном MVI (Model-View-Intent). Патерн визначає три не-
залежні компоненти. State – незмінний data class, що повністю описує поточний стан 
екрану: StudentState містить поля students (List<StudentResponse>), currentPage, to-
38 
talPages, isLoading, isImporting, selectedStudent (StudentDetailResponse?) і taskState 
(TaskState?). Event – sealed interface, що описує всі можливі наміри користувача: 
LoadStudents, SearchChanged(query: String), FilterChanged(filter: FilterState), Se-
lectStudent(id: UUID), UpdateStudent(request: StudentRequest), GenerateDocument(type: 
DocumentType), ImportXlsx(file: File), Logout. SideEffect – sealed interface для одно-
разових дій: OpenFile(file: File), ShowError(message: String), LogoutRequested. SideEf-
fect – и передаються через Channel<StudentSideEffect>(BUFFERED) і збираються у 
LaunchedEffect в App.kt, що гарантує доставку навіть при тимчасовому відсутності 
підписника. 
StudentViewModel (~500 рядків Kotlin [5]) зберігає стан у MutableState-
Flow<StudentState> і обробляє події через метод onEvent(event: StudentEvent). Онов-
лення стану відбувається атомарно через _state.update { ... }, що унеможливлює 
«гонки стану» при паралельних корутинах. Мережеві виклики виконуються у 
viewModelScope.launch (Dispatchers.IO), що автоматично скасовує всі корутини при 
знищенні ViewModel. UI – компоненти підписуються на стан через val state by 
viewModel.state.collectAsState() і перекомпозуються лише при зміні тих полів, які 
вони використовують. 
Мережевий шар клієнта побудований на Ktor Client [7] CIO engine із 
ContentNegotiation(kotlinx.serialization Json) і BearerTokenPlugin. Токен після входу 
зберігається у TokenStorage (обгортка над SharedPreferences / файловим сховищем) і 
автоматично підставляється в заголовок Authorization кожного запиту. SSE – потік 
подій стану задачі реалізований через HttpStatement().execute { response – > 
response.bodyAsChannel().readUTF8Line() } у корутині Dispatchers.IO; кожен рядок 
десеріалізується у TaskStateDto і оновлює _state.update { it.copy(taskState = dto) }. 
Безпека реалізована через Spring Security 6 [3] у STATELESS – режимі. 
JwtAuthenticationFilter розширює OncePerRequestFilter: при кожному HTTP-запиті 
витягує токен із заголовка Authorization: Bearer <token>, верифікує підпис через 
Jwts.parserBuilder().setSigningKey(secretKey).build() (алгоритм HMAC-SHA256) і 
встановлює UsernamePasswordAuthenticationToken у SecurityContextHolder. Паролі 
39 
зберігаються як BCrypt – хеш; обчислювальна вартість хешування визначається 
формулою: 
 Cᴬ = 2ˢ (2.3) 
 
де Cᴬ – кількість внутрішніх ітерацій алгоритму BCrypt; 
s – параметр strength (у проєкті s = 10, тобто Cᴬ = 1024 ітерації); 
Це унеможливлює brute – force – атаки на викрадену БД. JWT [13] – токен ге-
нерується при успішній автентифікації і містить claims: sub (username), role, iat, exp. 
Термін дії токена визначається, як: 
 exp = iat + Tₑ / 1000 (2.4) 
 
де exp – час закінчення дії токена (Unix timestamp, секунди); 
iat – час видачі токена, issued at (Unix timestamp, секунди); 
Tₑ – jwt.expiration із application.yml (за замовчуванням 86 400 000 мс = 24 год); 
sessionCreationPolicy = STATELESS гарантує відсутність серверних сесій: ко-
жен запит автентифікується незалежно.  
Рівні доступу визначені в SecurityConfig.filterChain(): ендпоінти /api/v1/auth/** 
і /actuator/health відкриті (permitAll()); /api/v1/students/**, /documents/**, 
/api/v1/import/** вимагають автентифікованого користувача (authenticated()); 
/api/v1/migration/**, /api/v1/audit, /actuator/**  –  лише ролі ADMIN 
(hasRole("ADMIN")). MigrationService виконує пакетну синхронізацію з зовнішнім 
API через Feign Client (ExternalStudentClient): GET 
/api/external/students?page={n}&size=100, паралельна обробка пакетів у ExecutorServ-
ice.newFixedThreadPool(10). Upsert за externalId гарантує ідемпотентність повторних 
запусків. 
2.5 Реалізація підсистеми формування документів 
Підсистема формування документів реалізована як окремий керований процес, 
що запускається за запитом користувача для конкретної особи. На відміну від прос-
40 
того синхронного експорту, в модулі використано модель задачі з відстеженням 
стану виконання. Це дозволяє обробляти довші операції без блокування інтерфейсу 
та забезпечує контрольований механізм повідомлень про успіх або помилку. 
Процес генерації включає кілька послідовних кроків: створення задачі, переві-
рку обов’язкових полів, заповнення шаблону та підготовку файлу до завантаження. 
Перед формуванням система виконує валідацію ключових реквізитів, що знижує 
ймовірність створення некоректного документа. Якщо даних недостатньо, користу-
вач отримує повідомлення і може повернутись до редагування картки. 
Заповнення шаблонів виконується автоматично на основі даних із реєстру. Та-
кий підхід уніфікує документообіг, зменшує ручні дії кадровика та мінімізує вплив 
людського фактора. Після завершення задачі сформований файл зберігається у фай-
ловому сховищі та стає доступним для завантаження через API. 
Додатково підсистема інтегрована з механізмом аудиту: факт формування до-
кумента фіксується в журналі подій. Це забезпечує простежуваність операцій і від-
повідає вимогам контрольованої роботи з персональними даними в державному за-
кладі. 
Реалізована підсистема документогенерації поєднує валідацію, асинхронну 
обробку, шаблонний підхід і аудит дій, що робить її придатною для регулярного ви-
користання в процесах військового. 
Діаграма станів генерації документу представлена на рис. 2.5. 
 
 
Рисунок 2.5 – Діаграма станів генерації документу 
41 
2.6 Розгортання системи та тестування модуля 
Серверний контур системи розгортається через Docker Compose 3.8 [15]. Файл 
docker-compose.yml визначає два сервіси: postgres_db і app. Сервіс postgres_db вико-
ристовує образ postgres:16 – alpine: порт 5432, том pgdata для збереження даних між 
перезапусками, healthcheck: pg_isready – U ${DB_USERNAME} – d ${DB_NAME} з 
інтервалом 10 секунд і трьома спробами. Сервіс app: образ, зібраний із app.jar через 
Dockerfile (базовий образ eclipse-temurin:23-jre-alpine), порт 8080, condition de-
pends_on: postgres_db service_healthy – сервер не стартує до готовності БД. Усі чут-
ливі параметри (DB_URL, DB_USERNAME, DB_PASSWORD, SERVER_PORT, 
JWT_SECRET, JWT_EXPIRATION, STORAGE_PATH) передаються через environ-
ment – секцію із змінних оточення операційної системи хоста без хардкоду у 
вихідному коді чи репозиторії. Розгортання виконується двома командами: docker 
compose build (збирання образу, ~60 с) і docker compose up  -d (запуск у фоні, ~10 с). 
Desktop-клієнт запускається на робочому місці кадровика окремо від сервер-
ного контуру: gradlew :composeApp:run. URL серверного API конфігурується у файлі 
app.properties (api.baseUrl=http://<server – host>:8080).  
Така архітектура дозволяє централізовано розмістити сервер і PostgreSQL в 
мережі закладу на єдиному виділеному хості, а Desktop-клієнт розгортати на кож-
ному робочому місці кадрового підрозділу без додаткових залежностей від браузера 
або вебсервера. При оновленні серверної частини клієнт автоматично отримує нові 
можливості через API без необхідності оновлення клієнтського застосунку. 
Автоматизоване тестування підтверджує коректність реалізованої бізнес-
логіки і стійкість до граничних сценаріїв. Тестова інфраструктура побудована на 
JUnit 5 [16] і Testcontainers 1.19 [17]: перед виконанням тестового класу автоматично 
запускається Docker-контейнер postgres:16-alpine з тими самими параметрами 
(версія, ICU – локаль uk), що й у production-середовищі. Це принципово відрізняєть-
ся від in – memory H2-бази, яка не підтримує JSONB – тип і ICU – коляції – ключові 
особливості використовуваної PostgreSQL 16 [8]. 
42 
Кожен тест розширює BaseIntegrationTest, анотований 
@SpringBootTest(webEnvironment = RANDOM_PORT). Це запускає повний Spring – 
контекст із HTTP-сервером і шаром безпеки. HTTP-запити виконуються через 
TestRestTemplate із автоматичним підставлянням тестового JWT [13]. @BeforeEach: 
LiquibaseRunner застосовує всі міграції на чисту тестову БД. @AfterEach: TRUN-
CATE CASCADE видаляє всі дані, забезпечуючи повну ізоляцію тест-кейсів 
незалежно від порядку їх виконання.  
Стратегія та результати автоматизованого тестування подано в таблиці 2.2. 
Таблиця 2.2 – Перелік автоматизованих тестів системи 
Категорія Тест-клас Основні Що перевіряється 
сценарії 
Автентифіка- AuthControllerTest Успішний HTTP 200 + JWT – 
ція логін, невір- відповідь, 
ний пароль, HTTP 401, HTTP 403 
запит без то-
кена 
CRUD реєстру StudentControllerTest Пагінація  JSON – структура 
(page, size, Page<>, 
sort), коди статусу, 
пошук за ПІБ зміни у БД 
та ІПН, 
оновлення 
картки 
Документо- DocumentPipelineTest Старт задачі Task.state у БД, 
генерація → NEW → файл у STORAGE_PATH, 
COMPLETED, SSE payload 
SSE – події 
між станами, 
наявність 
файлу 
Імпорт XLSX ImportServiceTest Коректний ImportStudentsResultDTO: 
файл, помил- created/updated/skipped, 
ковий перелік помилок 
формат дати, 
дубль ІПН 
43 
Безпека SecurityTest USER → HTTP 403 / 401 без 
ADMIN – витоку внутрішніх даних 
ендпоінт, 
прострочений 
токен, 
токен іншого 
користувача 
Статичний Checkstyle (CI/CD) checkstyleMain 0 порушень Google Java 
аналіз на кожний Style, 
git push у довжина рядка ≤ 120 
GitLab CI символів 
CI/CD конвеєр реалізовано у файлі .gitlab – ci.yml і виконується автоматично 
при кожному git push. Стейдж build виконується на образі gradle:jdk23 – alpine: gra-
dle assemble + checkstyleMain; при порушенні стилю конвеєр зупиняється. Стейдж 
integration_test: gradle integrationTest – Testcontainers [17] підіймає PostgreSQL – 
контейнер усередині GitLab Runner. Артефакт app.jar архівується на 7 днів. Загаль-
ний час конвеєру – близько 3 хвилин. При невдалому стейджі merge request у основ-
ну гілку блокується автоматично, що гарантує стабільність коду в репозиторії. 
Висновки до розділу 2 
У розділі виконано повний цикл проєктування і реалізації модуля обліку 
військовозобовʼязаних у складі HR-системи державного закладу освіти. Аналіз 
предметної області визначив нормативні вимоги до реквізитного складу облікової 
картки форми № 2 і типових документів, що формуються кадровим підрозділом для 
взаємодії з територіальними центрами комплектування та соціальної підтримки. 
Порівняльний аналіз трьох архітектурних підходів підтвердив оптимальність 
клієнт-серверної моделі: вона отримала найвищу оцінку (5 із 5) за сукупністю кри-
теріїв захисту персональних даних, простоти розгортання і тестованості. Реляційна 
модель із чотирьох сутностей покриває повний реквізитний склад картки і забезпе-
чує аудит операцій. Еволюція схеми через 12 Liquibase changelog – файлів гарантує 
відтворюваність стану БД між середовищами. 
44 
REST API із 12 ендпоінтами трьох рівнів доступу охоплює всі кадрові сце-
нарії. Підсистема документогенерації реалізована як pipeline із шести StateHandler – 
ів на основі Chain of Responsibility з SSE-зворотним звʼязком і підтримкою чотирьох 
типів нормативних документів. Клієнтська частина побудована за MVI-патерном 
(State / Event / SideEffect). Безпека реалізована через JWT HMAC-SHA256 у STATE-
LESS – режимі з BCrypt – хешуванням (s = 10) і рольовою моделлю доступу. Пред-
ставлено опис кількісних характеристик системи. 
Автоматизоване тестування охоплює шість категорій: автентифікацію, CRUD-
операції, документогенерацію, імпорт, безпеку і статичний аналіз коду – усі з вико-
ристанням реальної PostgreSQL через Testcontainers. Двостейджовий CI/CD конвеєр 
GitLab CI блокує merge request при невдалих тестах. Розгортання через Docker Com-
pose із параметризацією через сім змінних середовища без хардкоду секретів 
відповідає вимогам інформаційної безпеки для державних установ і підтверджує го-
товність рішення до впровадження. 
45 
3 ТЕСТУВАННЯ ТА АНАЛІЗ РЕЗУЛЬТАТІВ 
3.1 Тестування CRUD-операцій реєстру військовозобовʼязаних 
Підрозділ містить опис та результати тестування операцій читання, оновлення 
та пошуку записів реєстру військовозобовʼязаних, які реалізовані у StudentController 
і StudentService. Відповідно до результатів аналізу предметної області (розділ 1) і 
проєктних рішень (розділ 2), система не передбачає ручного створення та видалення 
карток через REST API: записи надходять виключно через пакетний імпорт XLSX 
(POST /api/v1/students/import) або міграцію з зовнішнього джерела (POST 
/api/v1/migration/students). Це архітектурне рішення унеможливлює появу «порож-
ніх» карток і забезпечує цілісність даних реєстру. 
Тестування проводилось у два етапи: автоматизоване інтеграційне тестування 
з використанням JUnit 5 [16] та Testcontainers [17] (реальна PostgreSQL 16 [8] у 
Docker-контейнері [15]) і ручна верифікація через Swagger UI (/swagger-ui.html) [14]. 
Середовище тестування: сервер запущено командою docker compose up -d, база да-
них заповнена тестовим набором із 50 записів через XLSX-імпорт. Кожен ендпоінт 
перевірявся на три сценарії: штатне виконання (happy path), граничні значення па-
раметрів і некоректні вхідні дані (негативні тест-кейси). 
Таблиця 3.1 містить повний перелік реалізованих операцій StudentController із 
результатами тестування кожної з них. Операції згруповані за функціональними зо-
нами: читання реєстру (пагінація та сортування), пошук і фільтрація (JPA 
Specification), перегляд картки, оновлення реквізитів, експорт у XLSX та генерація 
документів. 
Таблиця 3.1 – Результати тестування CRUD-операцій StudentController 
Операція Метод / Шлях HTTP Очікуваний результат Статус 
Отримати GET /api/v1/students GET 200 OK Пройде-
реєстр ?pageNumber=0&pageSize=10 StudentListResponse: con- но 
(пагінація) &sortBy=lastName&sortOrder=ASC tent [10], 
totalElements=50, totalPag-
es=5 
Сортуван- GET /api/v1/students GET 200 OK Пройде-
ня за ?sortBy=birthDate Список відсортований но 
довільним &sortOrder=DESC за датою народження (спа-
46 
полем дання) 
Некоре- GET /api/v1/students GET 400 Bad Request Пройде-
ктний ?pageSize=0 (@Min(1) validation) но 
розмір 
сторінки 
Пошук за GET /api/v1/students/search GET 200 OK Пройде-
ПІБ ?query=Петро Записи, що містять но 
(частковий «Петро» 
збіг) у firstName / lastName / pat-
ronymic 
Пошук за GET /api/v1/students/search GET 200 OK Пройде-
ІПН ?query=1234567890 Один запис із відповідним но 
(точний identificationCode 
збіг) 
Пошук: GET /api/v1/students/search GET 200 OK Пройде-
порожній ?query=XXXNONEXIST content=[], totalElements=0 но 
результат 
Отримати GET /api/v1/students/{id} GET 200 OK Пройде-
картку StudentBaseDTO з усіма но 
за ID 35+ полями картки 
Картка: ID GET /api/v1/students/99999 GET 404 Not Found Пройде-
не існує ResourceNotFoundException но 
Оновити PUT /api/v1/students/{id} PUT 200 OK Пройде-
реквізити Body: StudentBaseDTO Оновлений Student- но 
картки BaseDTO; 
(Update) зміни збережено у БД 
Оновлен- PUT /api/v1/students/{id} PUT 400 Bad Request Пройде-
ня: поле Body: { lastName: "" } (@NotBlank validation) но 
validation 
error 
Експорт GET /api/v1/students/export GET 200 OK Пройде-
реєстру ?ageFilter=under_25 Content-Type: applica- но 
у XLSX  tion/vnd... 
(< 25 р.) XLSX-файл із відфільтро-
ваними записами 
Експорт GET /api/v1/students/export GET 200 OK Пройде-
реєстру ?ageFilter=25_plus XLSX-файл, ім'я файлу но 
у XLSX  містить 
(≥ 25 р.) часову мітку yyyy-MM-
dd_HH-mm-ss 
Операція читання реєстру (GET /api/v1/students) повертає обʼєкт StudentLis-
tResponse із полями content, totalElements, totalPages і number. Параметри сторінку-
вання валідуються анотаціями @Min(0) і @Max(100); при pageSize=0 сервер повер-
тає HTTP 400 з описом порушеної constraint. Сортування перевірено для полів last-
Name, firstName, birthDate і id: у всіх випадках порядок записів відповідає заданому 
напрямку (ASC / DESC). Результат виконання запиту наведено на рисунку 3.1. 
47 
 
Рисунок 3.1 – Результат GET /api/v1/students  
Пошук реалізовано через окремий ендпоінт GET /api/v1/students/search з пара-
метром query. StudentService.searchStudents() будує JPA Specification [4] із ILIKE-
предикатами по чотирьох полях (lastName, firstName, patronymic, identificationCode), 
зʼєднаних через OR. Тестування підтвердило коректну роботу пошуку як при част-
ковому збігу (частина прізвища), так і при точному збігу по ІПН. Порожній резуль-
тат повертається як 200 OK із content=[], а не як 404 – це відповідає REST-семантиці 
колекцій. Приклад пошукового запиту наведено на рисунку 3.2. 
 
Рисунок 3.2 – Результат пошуку GET /api/v1/students/search  
48 
Операція оновлення (PUT /api/v1/students/{id}) приймає StudentBaseDTO у тілі 
запиту і повертає оновлений обʼєкт. StudentService.updateStudent() завантажує 
сутність із БД, застосовує зміни через MapStruct-маппер [10] і зберігає через Studen-
tRepository.save(). Транзакція (@Transactional) гарантує атомарність: при виникненні 
будь-якої помилки зміни відкочуються. Перевірено три сценарії: успішне оновлення 
military-реквізитів (militaryRank, militarySpecialty), зміна адреси реєстрації та спроба 
передати порожнє lastName. Результат успішного оновлення підтверджено 
порівнянням значень у відповіді сервера та прямим запитом до БД. Інтерфейс відоб-
раження оновленої картки показано на рисунку 3.3. 
 
Рисунок 3.3 – Відображення оновленої облікової картки у Desktop-клієнті 
Усі 12 тест-кейсів із таблиці 3.1 виконані успішно. Жоден тест-кейс не виявив 
відхилень від очікуваної поведінки. Перевірені ендпоінти повністю відповідають 
специфікації REST API, описаній у підрозділі 2.2, і задовольняють функціональні 
вимоги до модуля обліку, сформульовані у підрозділі 1.3. 
3.2 Реалізація підсистеми аудиту дій користувачів 
Кадрові системи, що обробляють персональні та службові дані військовозоб-
овʼязаних, підпадають під вимоги щодо простежуваності операцій: будь-яка зміна 
або формування документа має бути зафіксована із зазначенням типу дії, обʼєкта 
49 
впливу та моменту часу. Підсистема аудиту реалізована як окремий вертикальний 
зріз застосунку і не впливає на основний потік обробки запитів. Її архітектуру побу-
довано за принципом єдиної відповідальності: кожен клас вирішує строго одне зав-
дання. Реалізацію підсистеми забезпечують три компоненти: доменна сутність 
AuditLog, репозиторій AuditLogRepository та сервісний шар AuditService,  
Доменна сутність AuditLog є JPA-класом (@Entity, 
@Table(name = "audit_log")) і відображає структуру однойменної таблиці бази да-
них. Поле id оголошено з GenerationType.IDENTITY, що делегує генерацію ключа 
механізму автоінкременту PostgreSQL і унеможливлює конфлікти при конкурентних 
вставках. Поля action та entity_type позначені nullable = false на рівні JPA-анотацій, 
що продублюється у DDL-обмеженнях NOT NULL і забезпечує цілісність даних на 
двох рівнях одночасно. Поле details оголошено типом columnDefinition = "TEXT", 
що дозволяє зберігати довільно довгі описові рядки без обмеження у 255 символів, 
типового для VARCHAR. 
Особливу роль відіграє механізм автоматичного встановлення часової мітки. 
Поле createdAt заповнюється не з боку клієнтського коду, а методом onCreate(), по-
значеним анотацією @PrePersist. Цей метод викликається контейнером Hibernate 
безпосередньо перед виконанням SQL INSERT, що має дві переваги: по-перше, 
жоден виклик ззовні не може передати довільне значення часу; по-друге, час 
відповідає системному годиннику JVM-процесу, а не моменту надходження HTTP-
запиту, що виключає маніпуляції з часовою міткою через мережеві затримки. Схему 
таблиці audit_log, визначену у міграції Liquibase (changeSet 003) [9], наведено в таб-
лиці 3.2. 
Таблиця 3.2 – Структура таблиці audit_log 
Стовпець Тип Обмеження Призначення 
id BIGINT PK, AUTO INCRE- Унікальний ідентифікатор 
MENT запису 
action VAR- NOT NULL Код дії (SCREAM-
CHAR(100) ING_SNAKE_CASE) 
enti- VARCHAR(50) NOT NULL Тип сутності (напр., "Stdent") 
50 
ty_type 
entity_id BIGINT NULL ID конкретного запису 
details TEXT NULL Розширений опис операції 
created_at TIMESTAMP NOT NULL, DEFAULT Час фіксації події 
CUR-
RENT_TIMESTAMP 
Рівень доступу до даних реалізовано інтерфейсом AuditLogRepository, що 
розширює JpaRepository<AuditLog, Long>. Успадкування від JpaRepository автома-
тично надає стандартні методи CRUD (save, findById, findAll, delete) без написання 
жодного рядка SQL. Додатково оголошено два спеціалізовані методи із використан-
ням механізму derived query methods Spring Data JPA: імʼя методу слугує специ-
фікацією запиту, а фреймворк генерує відповідний JPQL під час завантаження кон-
тексту. Метод findByEntityTypeAndEntityIdOrderByCreatedAtDesc() повертає усі за-
писи для заданого типу сутності та ідентифікатора, відсортовані за спаданням часу – 
це дозволяє отримати хронологічно впорядкований журнал операцій над конкрет-
ним студентом. Метод findAllByOrderByCreatedAtDesc() повертає увесь журнал си-
стеми у тому ж порядку сортування і призначений для адміністративного моніто-
рингу всіх дій. 
Сервісний шар AuditService є Spring-компонентом (@Service) і оголошує три 
публічні методи. Залежність від AuditLogRepository інжектується через конструктор 
завдяки анотації @RequiredArgsConstructor (Lombok), що відповідає рекомендованій 
Spring практиці constructor injection і спрощує написання юніт-тестів через явне ого-
лошення залежностей. Анотація @Slf4j забезпечує доступ до SLF4J-логера без руч-
ного оголошення поля. 
Метод logDocumentGeneration() є центральною точкою запису в журнал. Він 
приймає ідентифікатор студента та тип документа DocumentType, формує рядок 
details за шаблоном «Generated document: %s» із використанням 
DocumentType.getDisplayName(), що повертає україномовну відображувану назву 
типу, наприклад «Повідомлення про взяття на облік». Потім метод створює екзем-
пляр AuditLog через явний конструктор із чотирма параметрами та зберігає його че-
51 
рез auditLogRepository.save(). Метод позначений @Transactional: якщо в межах тієї ж 
транзакції виникне виняток після виклику save(), уся транзакція відкотиться і запис 
в журнал не залишиться в базі. Це гарантує консистентність: неповних або «сирих» 
записів у таблиці audit_log не існує. Після збереження SLF4J-логер фіксує подію на 
рівні INFO: 
log.info("Audit log created: {} for student {}", documentType, studentId). 
Два методи читання – getAuditLogsForStudent() та getAllAuditLogs() – позна-
чені @Transactional(readOnly = true). Прапор readOnly повідомляє Hibernate про від-
сутність модифікацій, що дозволяє оптимізувати сесію: вимикається dirty checking 
(перевірка змін обʼєктів), а СКБД PostgreSQL може використовувати знімок даних 
без блокувань рядків. Це особливо важливо при отриманні великих журналів подій, 
де кількість записів може сягати тисяч. 
Виклик auditService.logDocumentGeneration() інтегровано у метод generateDoc-
ument() класу DocumentService. Цей метод відповідає за ініціацію генерації доку-
мента: він створює обʼєкт задачі Task, зберігає її через TaskRepository і передає в 
обробник StateHandlerProxy. Виклик методу аудиту розміщено між збереженням за-
дачі та запуском обробника, що обґрунтовано такою логікою: якщо StateHandler-
Proxy завершиться помилкою, запис в журнал уже зафіксований і адміністратор мо-
же відстежити, яка саме операція спричинила збій. Якщо ж збій стався до запису в 
журнал – задача взагалі не розпочалася і аудит не потрібен. 
На рисунку 3.4 наведено фрагмент методу generateDocument() з позначеним 
місцем виклику підсистеми аудиту: 
 
Рисунок 3.4 – Відображення оновленої облікової картки в Desktop-клієнті 
52 
Для верифікації підсистеми виконано наскрізну перевірку: ініційовано гене-
рацію документа типу MILITARY_REGISTRATION_NOTICE для студента з 
id = 85081 через REST-ендпоінт GET /api/v1/students/{id}/documents/{type}. Після 
завершення запиту виконано SQL-запит до таблиці audit_log з умовою WHERE 
entity_id = 85081. Результат підтвердив коректну роботу підсистеми: у таблиці 
зʼявився новий запис із action = «DOCUMENT_GENERATED», 
entity_type = «Student», entity_id = 85081, details = «Generated document: Повідомлен-
ня про взяття на облік» та автоматично встановленим created_at. Результати пе-
ревірки роботи підсистеми наведено в таблиці 3.3. 
Таблиця 3.3 – Приклад записів у таблиці audit_log після тестової генерації 
id action entity_type entity_id details 
1 DOCUMENT_GENERATED Student 85081 Generated document: 
Повідомлення про взяття 
на облік 
2 DOCUMENT_GENERATED Student 24280 Generated document: 
Довідка про навчання 
Таким чином, підсистема аудиту забезпечує повну простежуваність операцій 
генерації документів. Трирівнева архітектура (сутність – репозиторій – сервіс) 
відповідає принципам розшарування Spring-застосунку і спрощує розширення: до-
давання нових типів аудитованих подій потребує лише додаткового виклику 
logDocumentGeneration() або нового методу в AuditService без зміни схеми бази да-
них чи репозиторію. Реалізована підсистема відповідає вимозі до журналювання, 
сформульованій у підрозділі 1.3. 
3.3 Реалізація головного екрану модуля обліку 
Головний екран є центральним елементом інтерфейсу модуля обліку військо-
возобовʼязаних і реалізований як Composable-функція StudentListContent у складі 
десктопного Kotlin Multiplatform-застосунку. Екран реалізовано за архітектурним 
шаблоном MVI (Model-View-Intent): уся логіка зосереджена у StudentViewModel, ін-
53 
терфейс описується незмінним станом StudentScreenState, а дії користувача переда-
ються у вигляді запечатаних подій StudentEvent. Зовнішній вигляд головного екрану 
наведено на рисунку 3.5. 
 
Рисунок 3.5 – Головний екран модуля обліку військовозобовʼязаних 
Компонувальну схему екрану побудовано на основі горизонтального контей-
нера Row, що поділяє робочу область на три функціональні зони: ліву панель філь-
трації, центральну область зі списком і пошуком та праву панель із деталями вибра-
ного запису. Між лівою та центральною зонами розміщено вертикальний роздільник 
VerticalDivider для візуального розмежування областей. 
Центральна область займає решту ширини екрану (Modifier.weight(1f)) і скла-
дається з чотирьох вертикально розташованих блоків.  
Перший блок – рядок пошуку SearchBar  дозволяє виконувати повнотекстовий 
пошук за ПІБ студента у реальному часі. При введенні тексту генерується подія 
SearchQueryChanged, яка через ViewModel ініціює запит GET /api/v1/students/search 
із відповідним параметром query. Результати підвантажуються без перезавантажен-
ня сторінки завдяки збору StateFlow у корутині viewModelScope. 
Другий блок – панель дій ActionBar містить кнопки для роботи з вибраними за-
писами: «Вибрати все» перемикає стан вибору всіх студентів на поточній сторінці, 
54 
«Експорт» відкриває діалог вибору формату експорту XLSX, «Друкувати» ініціює 
генерацію документів для вибраних студентів, «Мігрувати» відкриває діалог син-
хронізації з зовнішньою системою. Лічильник відображає кількість вибраних за-
писів та загальну кількість на сторінці у форматі «вибрано X із N». 
Третій блок – таблиця студентів StudentTable реалізована на базі компонента 
LazyColumn, що забезпечує віртуалізацію відображення: у памʼяті утримуються ли-
ше видимі рядки, що суттєво знижує споживання ресурсів при великих реєстрах. 
Кожен рядок містить чекбокс для множинного вибору, прізвище, імʼя та по батькові, 
дату народження, ІПН та статус військового обліку. Натискання на рядок генерує 
подію StudentClicked, яка оновлює праву панель деталей без навігації між екранами. 
Четвертий блок – контролер пагінації PaginationControls відображається ли-
ше якщо загальна кількість сторінок більша за одну (state.totalPages > 1). Він містить 
кнопки «Попередня» та «Наступна», поточний номер сторінки, розмір сторінки та 
загальну кількість записів. Натискання кнопок генерує події PreviousPage та 
NextPage, за якими ViewModel оновлює currentPage і виконує новий запит до API. 
Вигляд центральної зони із таблицею та пагінацією наведено на рисунку 3.6. 
 
Рисунок 3.6 – Центральна зона: рядок пошуку, панель дій, таблиця студентів та 
пагінація 
55 
Права панель реалізована компонентом StudentDetailsPanel і відображає повну 
картку вибраного студента. Вигляд панелі деталей студента наведено на рис. 3.7. 
 
Рисунок 3.7 – Права панель із повною карткою вибраного студента 
Дані організовано у смислові групи: особисті відомості (ПІБ, дата та місце 
народження, стать), контактна інформація (адреса реєстрації, адреса проживання, 
телефон, e-mail), паспортні дані (серія, номер, орган видачі, дата видачі), відомості 
про навчання (спеціальність, факультет, форма навчання, номер залікової книжки), 
військово-облікові дані (категорія, спеціальність ВОС, РТЦК та СП, номер у реєстрі 
«Оберіг», дата взяття на облік). У нижній частині панелі розміщено кнопку «Редагу-
вати», що переводить екран у стан ScreenView.EDIT і завантажує форму 
StudentEditScreen для внесення змін. 
56 
Управління станами екрану реалізовано через запечатаний клас 
StudentListState із чотирма підтипами: Initial (початковий стан до першого заванта-
ження), Loading (відображає CircularProgressIndicator у центрі екрану), Success 
(відображає таблицю студентів), Error (відображає повідомлення про помилку коль-
ором errorColor). Такий підхід унеможливлює відображення таблиці та індикатора 
завантаження одночасно, оскільки UI розгалужується через when-вираз по єдиному 
стану. Перехід між станами виконується виключно в ViewModel через 
MutableStateFlow, що гарантує однонаправлений потік даних і спрощує відлагод-
ження.  
Таким чином, головний екран модуля обліку реалізує повний цикл роботи з 
реєстром: фільтрацію, пошук, пагінацію, множинний вибір, перегляд деталей та пе-
рехід до редагування. Компонентна архітектура Compose Multiplatform [6] забезпе-
чує чітке розмежування відповідальності між елементами UI та дозволяє незалежно 
розробляти й тестувати FilterPanel, ActionBar, StudentTable і PaginationControls як 
окремі, самодостатні компоненти. 
3.4 Реалізація екрану редагування облікового запису 
Редагування облікового запису військовозобовʼязаного є однією з ключових 
операцій модуля обліку. Вона реалізована у компоненті StudentEditScreen, який ак-
тивується при переході стану ScreenView до значення EDIT. Перехід ініціюється 
натисканням кнопки «Редагувати» на правій панелі головного екрану або з діалогу 
валідації даних перед друком. 
Загальний вигляд екрану редагування облікового запису студента наведено на 
рисунку 3.8. 
Компонент StudentEditScreen приймає чотири параметри: обʼєкт student типу 
Student для початкового заповнення форми, колбек onBack для повернення до спис-
ку без збереження, колбек onSave для передачі оновленого обʼєкта у ViewModel, а 
також onLogout та onOpenAccountSettings для управління профілем. 
57 
Рисунок 3.8 – Екран редагування облікового запису студента 
Поточний стан форми зберігається в локальній змінній editedStudent, оголо-
шеній через mutableStateOf(student). Такий підхід забезпечує ізоляцію змін: 
оригінальний обʼєкт student залишається незмінним до моменту явного підтвер-
дження збереження, що дозволяє скасувати всі зміни простим натисканням «Скасу-
вати». 
Екран має трирівневу компонувальну структуру. Верхній рядок (AppBar) 
відображає заголовок «Редагування запису», ідентифікатор студента (ID), групу або 
код спеціальності, два статусні мікрочіпи (StatusChip) та кнопку повернення «До 
списку» з іконкою стрілки. AppBar розміщено у Surface з shadowElevation = 2.dp і 
виведено поверх основного вмісту через zIndex = 1f, що гарантує його постійну ви-
димість при прокручуванні форми. 
Основна робоча область ділиться на дві вертикальні колонки: ліву бічну па-
нель навігації шириною 280 dp та центральну прокручувану форму. Бічна панель 
містить список секцій EditSection – запечатаного переліку (enum class) із пʼяти еле-
ментів: «Особисті дані» (іконка Person), «Навчання» (іконка School), «Військовий 
облік» (іконка Shield), «Документи» (іконка Description) та «Місце роботи» (іконка 
Work).  
58 
Кожен елемент представлений компонентом NavigationItem: при виборі іконка 
та підпис підсвічуються кольором #3F51B5, а поточна секція зберігається в локаль-
ному стані currentSection. Вигляд бічної навігаційної панелі наведено на рисунку 3.9. 
 
Рисунок 3.9 – Бічна навігаційна панель із секціями форми редагування 
Центральна область відображає форму відповідно до вибраної секції через 
when-вираз по currentSection. Секція «Особисті дані» (PersonalDataSection) містить 
поля: прізвище, імʼя, по батькові, прізвище латиницею, стать (випадаючий список), 
дата народження (DatePicker), ІПН, УНЗР, електронна пошта, номер телефону, адре-
са реєстрації та адреса проживання. Секція «Навчання» (EducationSection) охоплює 
код та назву спеціальності, факультет, форму навчання, групу та номер залікової 
книжки. Секція «Військовий облік» (MilitarySection) – найобширніша за складом: во-
на містить поля для категорії придатності, військово-облікової спеціальності (ВОС), 
найменування РТЦК та СП, реєстраційного номера в системі «Оберіг», дати взяття 
на облік, відстрочки, типу та реквізитів військового квитка. Секція «Документи» 
(DocumentsSection) дозволяє редагувати паспортні дані: серію, номер, орган видачі, 
59 
дати видачі та закінчення дії. Секція «Місце роботи» (JobSection) містить посаду та 
наказ про призначення. 
Прокручування форми в межах центральної області реалізовано через 
verticalScroll(formScrollState). Для відображення смуги прокрутки використовується 
компонент VerticalScrollbar із rememberScrollbarAdapter(formScrollState), 
привʼязаний до правого краю контейнера через Alignment.CenterEnd. Це забезпечує 
зручну навігацію по довгих формах без використання системної смуги прокрутки 
вікна. 
У нижній частині екрану розміщено закріплену панель дій (Footer), реалізова-
ну в Surface із shadowElevation = 16.dp. Зліва розміщено кнопку профілю 
ProfileMenuButton з меню виходу та налаштувань. Справа – три кнопки: «Скан» 
(OutlinedButton, функціонал заплановано), «Скасувати» (OutlinedButton) для відхи-
лення змін і повернення до списку та «Зберегти» для підтвердження. При натисканні 
кнопки «Зберегти» викликається onSave(editedStudent), що генерує подію 
StudentEvent.EditCompleted із оновленим обʼєктом. ViewModel обробляє подію і ви-
конує HTTP-запит PUT /api/v1/students/{id} із тілом запиту у форматі JSON, після 
чого оновлює стан списку і повертає екран до ScreenView.LIST. Вигляд нижньої па-
нелі дій екрану редагування з кнопками «Зберегти» та «Скасувати» наведено на ри-
сунку 3.10. 
 
Рисунок 3.10 – Нижня панель дій екрану редагування з кнопками «Зберегти» та 
«Скасувати» 
На серверній стороні обробку запиту PUT /api/v1/students/{id} виконує метод 
updateStudent() класу StudentController. Тіло запиту десеріалізується в 
StudentUpdateRequest – DTO з валідаційними анотаціями (@NotBlank, @Min, 
60 
@Max). Якщо валідація не пройдена, Spring повертає HTTP 400 Bad Request із де-
тальним описом порушень. У разі успіху StudentService виконує часткове оновлення 
відповідного запису в таблиці students і повертає оновлену сутність у форматі JSON 
із кодом HTTP 200 OK. 
Таким чином, функція редагування реалізована як наскрізний сценарій від ін-
терфейсу до бази даних: локальний стан форми → подія ViewModel → HTTP PUT-
запит → серверна валідація → оновлення БД → повернення до оновленого списку. 
Секційна навігація дозволяє логічно розмежувати великий набір полів без необ-
хідності прокручувати одну довгу форму, а ізоляція локального стану гарантує, що 
незбережені зміни не впливають на відображення решти модуля. 
Висновки до розділу 3 
У розділі виконано програмну реалізацію та практичну перевірку основних 
компонентів модуля обліку військовозобовʼязаних у складі HR-системи державного 
закладу освіти. За результатами роботи сформульовано такі висновки. 
Реалізовано та протестовано CRUD-операції реєстру через REST API. Пе-
ревірено коректність пагінованого отримання списку студентів з параметрами sortBy 
та sortOrder, повнотекстового пошуку за ПІБ із використанням оператора ILIKE, от-
римання повної картки за ідентифікатором та часткового оновлення запису методом 
PUT. Результати тестування підтвердили відповідність фактичних HTTP-відповідей 
очікуваним кодам стану та структурі DTO. 
Реалізовано підсистему аудиту дій користувачів на основі трирівневої архітек-
тури: сутність AuditLog, репозиторій AuditLogRepository та сервісний шар 
AuditService. Підсистему інтегровано в потік генерації документів: виклик 
logDocumentGeneration() виконується після збереження задачі та до запуску 
StateHandlerProxy, що гарантує фіксацію події незалежно від результату генерації. 
Практична перевірка підтвердила коректний запис у таблицю audit_log із автома-
тично встановленою часовою міткою. 
Описано реалізацію головного екрану модуля обліку – компонента 
StudentListContent, побудованого за шаблоном MVI на базі Kotlin Compose 
61 
Multiplatform. Екран поєднує панель фільтрації, рядок пошуку, панель групових дій, 
таблицю студентів із підтримкою множинного вибору та пагінації, а також праву 
панель із деталями вибраного запису. Управління станами через StudentListState 
унеможливлює одночасне відображення конфліктних станів інтерфейсу. 
Реалізовано екран редагування облікового запису StudentEditScreen із 
секційною навігацією по пʼяти тематичних групах полів: особисті дані, навчання, 
військовий облік, документи та місце роботи. Локальна ізоляція стану форми через 
mutableStateOf дозволяє скасувати зміни без побічних ефектів. Підтверджене збере-
ження передається в ViewModel, яка виконує запит PUT /api/v1/students/{id} до сер-
верного API, після чого список оновлюється, а екран повертається до головного ре-
жиму перегляду. 
Здійснено повний цикл реалізації та верифікації модуля обліку: від серверного 
REST API і підсистеми безпеки до компонентів десктопного інтерфейсу. Усі ре-
алізовані функції перевірено на реальних даних, а отримані результати відповідають 
вимогам, сформульованим у першому розділі кваліфікаційної роботи бакалавра. 
62 
ВИСНОВКИ 
У кваліфікаційній роботі бакалавра вирішено актуальну задачу, а саме: проєк-
тування та програмну реалізацію модуля обліку військовозобовʼязаних у складі HR-
системи державного закладу освіти. За результатами виконаної роботи сформульо-
вано такі висновки: 
1. Проведено аналіз предметної області та обґрунтовано актуальність розроб-
ки. Встановлено, що наявні програмні рішення – SAP SuccessFactors, Oracle HCM 
Cloud, IT-Enterprise не задовольняють одночасно вимогам функціональної повноти, 
адаптованості до українського законодавства та можливості розгортання у закритій 
інфраструктурі державного закладу. Це підтверджує необхідність власної розробки, 
як складової частини відкритої HR-платформи. 
2.  Сформовано вимоги до модуля та обрано технологічний стек. Серверну ча-
стину реалізовано на Spring Boot 3.3, Java 23, що забезпечує зрілу екосистему, авто-
конфігурацію та вбудовану підтримку безпеки. Клієнтський десктопний застосунок 
реалізовано на Kotlin Compose Multiplatform, що дозволило використати декларати-
вну модель UI та єдину кодову базу для JVM-платформи. Для зберігання даних об-
рано PostgreSQL 16 з налаштуванням локалі ICU для коректного сортування кири-
лиці. Схема бази даних версіонується через Liquibase із автоматичним застосуван-
ням міграцій при старті застосунку. 
3. Спроєктовано архітектуру системи. Обрано клієнт-серверну модель із чіт-
ким розподілом відповідальностей: шар контролерів приймає HTTP-запити, сервіс-
ний шар містить бізнес-логіку, репозиторії взаємодіють із базою даних через Spring 
Data JPA. Безпеку реалізовано на основі JWT-автентифікації: JwtAuthenticationFilter 
перехоплює кожен запит, верифікує токен та встановлює контекст безпеки. Зворот-
ний звʼязок із клієнтом під час генерації документів реалізовано через Server-Sent 
Events, що виключає необхідність polling-запитів. 
4. Реалізовано та протестовано CRUD-операції реєстру. Перевірено корект-
ність пагінованого отримання списку, повнотекстового пошуку за ПІБ через ILIKE-
оператор та часткового оновлення запису методом PUT. Усі 12 тест-кейсів виконано 
63 
успішно, що підтверджує відповідність API специфікації та вимогам розділу 1. 
5. Реалізовано підсистему аудиту дій користувачів. Трирівнева архітектура 
AuditLog – AuditLogRepository – AuditService інтегрована в потік генерації докумен-
тів: кожна ініційована операція фіксується у таблиці audit_log незалежно від її кін-
цевого результату. Підсистема відповідає вимозі до простежуваності операцій із чу-
тливими персональними даними. 
6. Реалізовано інтерфейс користувача десктопного клієнта. Головний екран 
StudentListContent побудовано за шаблоном MVI і поєднує панель фільтрації, повно-
текстовий пошук у реальному часі, таблицю студентів із підтримкою множинного 
вибору та пагінації та панель деталей вибраного запису. Екран редагування 
StudentEditScreen із секційною навігацією по пʼяти тематичних групах полів реалізує 
повний цикл оновлення облікового запису від форми до серверного PUT-запиту. 
Практична цінність роботи полягає в тому, що розроблений модуль є скла-
довою частиною реального програмного продукту HR-Office, розгорнутого засоба-
ми Docker Compose та придатного для використання в умовах закладів освіти без за-
лучення хмарної інфраструктури. Усі реалізовані компоненти перевірено на реаль-
них даних та відповідають функціональним і нефункціональним вимогам, сформу-
льованим у першому розділі. 
 
64 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Кодекс України про адміністративні правопорушення (стаття 210): станом на 
01.01.2026 URL: https://zakon.rada.gov.ua/laws/show/80731-10 (дата звернення: 
12.02.2026). 
2. Spring Boot Reference Documentation. Version 3.3. URL: 
https://docs.spring.io/spring-boot/docs/3.3.x/reference/html/ (дата звернення: 
20.01.2026). 
3. Spring Security Reference. Version 6.3. URL: https://docs.spring.io/spring-
security/reference/index.html (дата звернення: 22.01.2026). 
4. Spring Data JPA – Reference Documentation. URL: https://docs.spring.io/spring-
data/jpa/reference/ (дата звернення: 23.01.2026). 
5. Kotlin Programming Language. Official Documentation. URL: 
https://kotlinlang.org/docs/home.html (дата звернення: 25.01.2026). 
6. Compose Multiplatform – Official Documentation. URL: 
https://www.jetbrains.com/lp/compose-multiplatform/ (дата звернення: 
27.01.2026). 
7. Ktor Client – Kotlin Asynchronous HTTP Client. URL: https://ktor.io/docs/client-
create-new-application.html (дата звернення: 28.01.2026). 
8. PostgreSQL 16 Documentation. URL: 
https://www.postgresql.org/docs/16/index.html (дата звернення: 30.01.2026). 
9. Liquibase Documentation: Database Schema Version Control. URL: 
https://docs.liquibase.com/home.html (дата звернення: 01.02.2026). 
10. MapStruct 1.5 Reference Guide. URL: 
https://mapstruct.org/documentation/stable/reference/html/ (дата звернення: 
03.02.2026). 
11. Apache POI – The Java API for Microsoft Documents. Version 5.2.5. URL: 
https://poi.apache.org/ (дата звернення: 05.02.2026). 
12. Poiji – A Java Library to Map Excel Rows to Java Objects. Version 4.9.0. URL: 
https://github.com/ozlerhakan/poiji (дата звернення: 06.02.2026). 
65 
13. JJWT – Java JWT: JSON Web Token for Java and Android. Version 0.12.5. URL: 
https://github.com/jwtk/jjwt (дата звернення: 07.02.2026). 
14. Springdoc OpenAPI – Library for Spring Boot Projects. Version 2.8.5. URL: 
https://springdoc.org/ (дата звернення: 10.02.2026). 
15. Docker Documentation: Containerization Platform. URL: https://docs.docker.com/ 
(дата звернення: 12.02.2026). 
16. JUnit 5 User Guide. URL: https://junit.org/junit5/docs/current/user-guide/ (дата 
звернення: 17.02.2026). 
17. Testcontainers for Java – Integration Testing with Real Dependencies. URL: 
https://java.testcontainers.org/ (дата звернення: 18.02.2026). 
18. Checkstyle 10.8.0 – Static Code Analysis for Java. URL: 
https://checkstyle.sourceforge.io/ (дата звернення: 19.02.2026). 
19. LibreOffice Writer: Headless Mode and Document Conversion. URL: 
https://wiki.documentfoundation.org/Documentation/DevGuide/Office_Developme
nt (дата звернення: 20.02.2026). 
20. SAP SuccessFactors HXM Suite – Overview. URL: 
https://www.sap.com/products/hcm/hxm.html (дата звернення: 22.02.2026). 
21. Методичні рекомендації для підготовки кваліфікаційної роботи бакалавра 
здобувачів освітнього ступеня «бакалавр» зі спеціальності 122 (F3) – 
«Комп’ютерні науки» усіх форм навчання [Електронний ресурс] / [упоряд. 
Триус Ю.В., Оксамитна Л.П., Підгорний М.В.]; М-во освіти і науки України, 
Черкас. держ. технол. ун-т. Черкаси: ЧДТУ, 2026. 53 с.  
22. Ю. О. Благовісний, Д. Р. Голуб, В. В. Дубровний, Д. О. Кєрнус, Л. П. Окса-
митна, А. П. Сіньковський, В. В. Олексюк. Інформаційна автоматизована HR-
система закладу вищої освіти  : Збірник тез доповідей студентської науково-
практичної конференції ЧДТУ : 22-23 квітня 2026 / [упорядник Мельник І.В.]; 
Міністерство освіти і науки України, Черкаський державний технологічний 
ун-т.  Черкаси : ЧДТУ, 2026. С. 14. 
 
66 
ДОДАТОК А 
 
 
 
        Затверджую               
Зав. кафедри КНСА, 
______________ Юрій ТРИУС 
«____»____________2026 р.                                                                                                                                                                              
 
 
 
 
МОДУЛЬ ОБЛІКУ ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ В HR-СИСТЕМІ  
ДЕРЖАВНОГО  ЗАКЛАДУ 
 
Специфікація  
482.ЧДТУ. 62288-01 
 
Листів 2 
 
 
 
Розробник                          ____________________                Володимир ДУБРОВНИЙ 
 
Керівник                             ____________________                Любов ОКСАМИТНА 
 
 
 
 
Черкаси – 2026
67 
482.ЧДТУ. 62288-01 
Позначення Найменування Примітка 
   
   
 Документація  
   
   
482.ЧДТУ. 62288-01    34 01 Інструкція користувача  
482.ЧДТУ. 62288-01    90 01 Апробація результатів  
кваліфікаційної роботи  
бакалавра 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
68 
ДОДАТОК Б 
 
 
 
 
МОДУЛЬ ОБЛІКУ ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ В HR-СИСТЕМІ  
ДЕРЖАВНОГО ЗАКЛАДУ 
 
 
 
 
ІНСТРУКЦІЯ КОРИСТУВАЧА 
482. ЧДТУ. 62288-01 34 01 
 
Листів 4 
 
 
 
 
 
Розробник    _____________  Володимир ДУБРОВНИЙ 
 
 
 
 
 
 
 
Черкаси – 2026 
69 
Після успішної автентифікації в системі користувач переходить на головний 
екран модуля обліку (рис. Б.1). Екран поділено на три функціональні зони: ліва па-
нель фільтрації, центральна область зі списком студентів та права панель із деталя-
ми вибраного запису. 
Рисунок Б.1 – Головний екран модуля обліку військовозобовʼязаних 
Ліва панель «Фільтрація списку» (рис. Б.2) дозволяє налаштувати порядок 
відображення реєстру. Випадаючий список «Сортувати за» пропонує чотири варіан-
ти: Прізвище А–Я, Прізвище Я–А, дата народження (за зростанням) та дата народ-
ження (за спаданням).  
 
Рисунок Б.2 – Панель фільтрації зі списком сортування та фільтрами 
70 
У верхній частині центральної зони розташовано рядок пошуку (рис. Б.3), що 
дозволяє знайти студента за ПІБ, ІПН або ID. Пошук виконується у реальному часі 
при введенні тексту.  
 
Рисунок Б.3 – Рядок пошуку та панель групових дій 
Центральна таблиця відображає список студентів із колонками: прізвище та 
імʼя, документи (ІПН, паспорт, ЄДР), адреса та статус обліку. Навпроти кожного 
рядка розміщено чекбокс для множинного вибору записів. У нижній частині таблиці 
розташовано контролер пагінації: кнопки переходу між сторінками, поточний номер 
сторінки та загальна кількість записів.  
Права панель відображає деталізовану картку вибраного студента з такими 
групами даних: особисті відомості (ПІБ, дата народження, ІПН), контактна інфор-
мація (адреса реєстрації, адреса проживання), паспортні дані та відомості про нав-
чання. 
Екран редагування (рис. Б.4) відкривається після натискання кнопки «Редагу-
вати» на панелі деталей або кнопки «Редагувати профіль» у діалозі валідації перед 
друком.  
 
Рисунок Б.4 – Екран редагування облікового запису студента 
71 
Ліва бічна панель екрану редагування (рис. Б.5) містить навігацію між пʼятьма 
секціями форми: «Особисті дані», «Навчання», «Військовий облік», «Документи» та 
«Місце роботи». 
 
Рисунок Б.5 – Навігаційна панель секцій форми редагування 
Секція «Особисті дані» містить поля для введення прізвища, імені, по батькові 
(в тому числі латиницею), статі, дати народження, ІПН, УНЗР, електронної пошти, 
номера телефону та адрес реєстрації і проживання.  
72 
ДОДАТОК В 
 
 
 
 
МОДУЛЬ ОБЛІКУ ВІЙСЬКОВОЗОБОВ’ЯЗАНИХ В HR-СИСТЕМІ  
ДЕРЖАВНОГО ЗАКЛАДУ 
 
 
 
 
Апробація результатів кваліфікаційної роботи бакалавра 
482. ЧДТУ. 62288-01 90 01 
 
Листів 4 
 
 
 
 
 
 
Розробник    _____________  Володимир ДУБРОВНИЙ 
 
 
 
 
 
 
Черкаси – 2026 
 
73 
 
 
 
 
74 
Основні положення і результати кваліфікаційної роботи бакалавра доповіда-
лися і були обговорені на конференції «День студентської науки кафедри КНСА», 
22 квітня  2026 року, Черкаси, Україна. 
Командний проєкт (Благовісний Юрій Олександрович, Голуб Данило Русла-
нович, Дубровний Володимир Володимирович, Кєрнус Дмитро Олександрович) 
«Інформаційна автоматизована HR-система закладу вищої освіти» в День студент-
ської науки кафедри КНСА посів 1 призове місце. 
 
 
75
Репозиторій ЧДТУ
