ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9102| Title: | Програмне забезпечення інформаційної системи формування юридичних документів для вступників в заклади вищої освіти |
| Authors: | Заспа, Григорій Олександрович Макійчук, Анна Вадимівна |
| Keywords: | ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;ІНФОРМАЦІЙНА СИСТЕМА;ЮРИДИЧНІ ДОКУМЕНТИ;ФОРМУВАННЯ ДОКУМЕНТІВ;ВСТУП;ПРИЙМАЛЬНА КОМІСІЯ;АВТОМАТИЗАЦІЯ;SOFTWARE;INFORMATION SYSTEM;LEGAL DOCUMENTS;DOCUMENT FORMATION;ADMISSION;ADMISSIONS COMMITTEE;AUTOMATION |
| Issue Date: | 17-Jun-2025 |
| Abstract: | АНОТАЦІЯ
Макійчук Анна Вадимівна
Програмне забезпечення інформаційної системи формування юридичних
документів для вступників в заклади вищої освіти
121 - Інженерія програмного забезпечення
Черкаський державний технологічний університет
м. Черкаси, 2025
Кваліфікаційна робота присвячена розробці програмного забезпечення
інформаційної системи, призначеної для автоматизації процесу формування пакета
юридичних документів вступників до закладів вищої освіти. Метою дослідження є
підвищення ефективності роботи приймальної комісії шляхом централізованого
керування даними вступників та замовників, автоматизованої генерації основних
типів юридичних документів і забезпечення інтеграції з внутрішніми та зовнішніми
сервісами.
У роботі проведено аналіз існуючих аналогічних рішень, розроблено веб-
додаток з розподілом ролей користувачів та реалізовано інтеграцію із зовнішніми
системами через REST API з використанням захисту JWT. Розроблено функціонал
створення, редагування, сортування та пошуку даних студентів і замовників, а також
автоматичну генерацію юридичних документів на основі шаблонів з можливістю їх
завантаження у форматі .DOCX.
Програмна реалізація системи здійснена з використанням технологій Java,
Spring Boot, PostgreSQL та Gradle для серверної частини, а також Angular, Material UI
і TypeScript для клієнтської частини. Розроблений інтерфейс є інтуїтивно зрозумілим
та може бути використаний працівниками приймальних комісій закладів вищої
освіти. ANNOTATION Makiichuk Anna Vadymivna Software of the information system for the formation of legal documents for applicants to higher education institutions 121 - Software Engineering Cherkasy State Technological University Cherkasy, 2025 The qualification work is devoted to the development of software for an information system designed to automate the process of forming a package of legal documents for applicants to higher education institutions. The aim of the research is to increase the efficiency of the admissions committee by providing centralized management of applicant and client data, automated generation of the main types of legal documents, and integration with internal and external services. The work includes an analysis of existing similar solutions, the development of a web application with user role distribution, and the implementation of integration with external systems via REST API using JWT protection. Functionality for creating, editing, sorting, and searching student and client data has been developed, as well as the automatic generation of legal documents based on templates with the possibility of downloading them in .DOCX format. The software implementation of the system was carried out using Java, Spring Boot, PostgreSQL, and Gradle for the server side, and Angular, Material UI, and TypeScript for the client side. The developed interface is intuitive and can be used by admissions committee staff of higher education institutions. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9102 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Макійчук Анна Вадимівна.pdf Restricted Access | 13.81 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Програмне забезпечення інформаційної системи формування
юридичних документів для вступників в заклади вищої освіти
Виконала: студентка 4 курсу, групи ПЗ-2104
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студентка Макійчук А.В.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Бутенко М.В.
(прізвище та ініціали)
Черкаси 2025
ЧДТУ 252159.011 ПЗ
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С. В.
«___» _______________ 2025 року
ЗАВДАННЯ
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Макійчук Анна Вадимівна
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмне забезпечення інформаційної системи формування юридичних
документів для вступників в заклади вищої освіти
Керівник проекту (роботи) Заспа Григорій Олександрович к. т. н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «25» лютого 2025 року
№53/03-03
2. Строк подання студентом проекту (роботи) 12 червня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; вимоги до
проекту; календарне планування проекту; управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ; Існуючі методи та засоби розв’язання поставлених завдань; Впровадження результатів досліджень у
практику проектування програмного забезпечення інформаційних систем; Розробка та тестування
програмного забезпечення;Висновок; Список використаних джерел; Додаток А. Специфікація; Додаток Б.
Лістинг програми; Додаток В. Інструкція користувача; Додаток Г. Графічні матеріали
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Діаграма класів; Діаграма пакетів; Діаграма компонентів; Діаграма розгортання; Діаграма діяльності;
Діаграма послідовності; Діаграма комунікації;Функціональна схема системи;Логічна схема системи;
Додаток Г: слайд 1, слайд 2, слайд 3, слайд 4, слайд 5, слайд 6, слайд 7, слайд 8, слайд 9, слайд 10, слайд 11,
слайд 12, слайд 13, слайд 14, слайд 15, слайд 16 , слайд 17, слайд 18, слайд 19, слайд 20, слайд 21, слайд 22,
слайд 23, слайд 24, слайд 25, слайд 26, слайд 27, слайд 28, слайд 29, слайд 30, слайд 31, слайд 32, слайд 33,
слайд 34, слайд 35, слайд 36, слайд 37, слайд 38, слайд 39, слайд 40.
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 2 грудня 2024 р.
5
ЧДТУ 252159.011 ПЗ
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів випускної Примітки
п/п
роботи
1 Постановка задачі 02.12.2024 виконано
2 Підготовка завдання 10.12.2024 виконано
3 Погодження завдання 18.12.2024 виконано
4 Затвердження завдання 19.12.2024 виконано
Основна стадія 02.01.2025
1 Підбір матеріалів 12.01.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 27.01.2025 виконано
3 Розрахунок основних параметрів роботи 15.02.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 18.02.2025 виконано
5 Оформлення первісної редакції роботи 24.02.2025 виконано
Заключна стадія 28.03.2025
1 Узгодження прийнятих проектних рішень з 13.04.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 15.05.2025 виконано
кінцевій редакції
3 Попередній захист роботи виконано
4 Затвердження роботи виконано
5 Рецензування роботи виконано
6 Захист роботи 16.06.2025
Студент _____________________ Макійчук А.В.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)
6
ЧДТУ 252159.011 ПЗ
АНОТАЦІЯ
Макійчук Анна Вадимівна
Програмне забезпечення інформаційної системи формування юридичних
документів для вступників в заклади вищої освіти
121 - Інженерія програмного забезпечення
Черкаський державний технологічний університет
м. Черкаси, 2025
Кваліфікаційна робота присвячена розробці програмного забезпечення
інформаційної системи, призначеної для автоматизації процесу формування пакета
юридичних документів вступників до закладів вищої освіти. Метою дослідження є
підвищення ефективності роботи приймальної комісії шляхом централізованого
керування даними вступників та замовників, автоматизованої генерації основних
типів юридичних документів і забезпечення інтеграції з внутрішніми та зовнішніми
сервісами.
У роботі проведено аналіз існуючих аналогічних рішень, розроблено веб-
додаток з розподілом ролей користувачів та реалізовано інтеграцію із зовнішніми
системами через REST API з використанням захисту JWT. Розроблено функціонал
створення, редагування, сортування та пошуку даних студентів і замовників, а також
автоматичну генерацію юридичних документів на основі шаблонів з можливістю їх
завантаження у форматі .DOCX.
Програмна реалізація системи здійснена з використанням технологій Java,
Spring Boot, PostgreSQL та Gradle для серверної частини, а також Angular, Material UI
і TypeScript для клієнтської частини. Розроблений інтерфейс є інтуїтивно зрозумілим
та може бути використаний працівниками приймальних комісій закладів вищої
освіти.
Ключові слова: ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, ІНФОРМАЦІЙНА
СИСТЕМА, ЮРИДИЧНІ ДОКУМЕНТИ, ФОРМУВАННЯ ДОКУМЕНТІВ, ВСТУП,
ПРИЙМАЛЬНА КОМІСІЯ, АВТОМАТИЗАЦІЯ.
7
ANNOTATION
Makiichuk Anna Vadymivna
Software of the information system for the formation of legal documents for
applicants to higher education institutions
121 - Software Engineering
Cherkasy State Technological University
Cherkasy, 2025
The qualification work is devoted to the development of software for an information
system designed to automate the process of forming a package of legal documents for
applicants to higher education institutions. The aim of the research is to increase the
efficiency of the admissions committee by providing centralized management of applicant
and client data, automated generation of the main types of legal documents, and integration
with internal and external services.
The work includes an analysis of existing similar solutions, the development of a
web application with user role distribution, and the implementation of integration with
external systems via REST API using JWT protection. Functionality for creating, editing,
sorting, and searching student and client data has been developed, as well as the automatic
generation of legal documents based on templates with the possibility of downloading them
in .DOCX format.
The software implementation of the system was carried out using Java, Spring Boot,
PostgreSQL, and Gradle for the server side, and Angular, Material UI, and TypeScript for
the client side. The developed interface is intuitive and can be used by admissions committee
staff of higher education institutions.
Keywords: SOFTWARE, INFORMATION SYSTEM, LEGAL DOCUMENTS,
DOCUMENT FORMATION, ADMISSION, ADMISSIONS COMMITTEE,
AUTOMATION.
8
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ......................................................................... 5
ВСТУП .............................................................................................................................. 6
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ...................................................................................... 11
1.1 Актуальні проблеми, що виникають в процесі виконання завдань ............... 11
1.2 Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань ..................................................................................................... 14
1.3 Аналіз існуючих аналогів інформаційних систем ............................................ 16
1.4 Конкретизація завдань роботи ........................................................................... 20
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ................................................................... 23
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ......................................................................................................................... 24
2.1 Моделювання предметної області ..................................................................... 24
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області ................................................................................................ 24
2.1.2 Елементи моделювання предметної області ............................................. 27
2.1.3 Робоча область моделювання ..................................................................... 29
2.2 Формування та аналіз вимог ............................................................................... 31
2.2.1 Формування вимог до програмного забезпечення ................................... 32
2.2.2 Формування вимог за допомогою діаграми прецедентів ........................ 37
2.3 Проектування логічної структури програмного комплексу............................ 41
2.3.1 Діаграми класів ............................................................................................ 41
2.3.2 Діаграми пакетів .......................................................................................... 45
2.4 Архітектурне проектування ................................................................................ 46
2.4.1 Діаграма компонентів ....................................................................................... 46
ЧДТУ 252159.011 ПЗ
Зм Лист № документа Підпис Дата
Розроб. Макійчук А.В. Літ. Лист Листів.
Керівник Заспа Г. О. Програмне забезпечення [н] 3
інформаційної системи
формування юридичних
документів для вступників в ФІТІС,
Н. контр. Півень О. Б. заклади вищої освіти Кафедра ПЗАС, ПЗ-2104
Затверд. Голуб С. В.
9
2.3.2 Діаграми пакетів .......................................................................................... 45
2.4 Архітектурне проектування ................................................................................ 46
2.4.1 Діаграма компонентів ....................................................................................... 46
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ................................................................................................................. 47
2.5 Моделювання поведінки системи ...................................................................... 49
2.5.1 Діаграма діяльності ..................................................................................... 49
2.5.2 Діаграма послідовності ............................................................................... 53
2.5.3 Діаграма комунікації ................................................................................... 55
2.5.4 Діаграма скінченного автомату .................................................................. 56
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ..................................................................... 58
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .......................................................................................................... 59
3.1 Розробка програмного комплексу ...................................................................... 59
3.1.1 Обґрунтування вибору засобів реалізації ................................................. 59
3.1.2 Опис структурної (функціональної) схеми ............................................... 61
3.1.3 Опис логічної схеми системи ..................................................................... 64
3.1.4 Розробка бази даних .................................................................................... 77
3.1.5 Розробка інтерфейсу користувача ............................................................. 92
3.1.6 Опис розробки програмних компонентів ................................................ 106
3.2 Тестування системи ........................................................................................... 114
3.2.1 Модульне тестування ................................................................................ 114
3.2.2 Інтеграційне тестування ............................................................................ 117
3.2.3 Системне тестування ................................................................................. 119
3.2.4 Приймальне тестування ............................................................................ 121
3.3 Приклади впровадження програмного комплексу ......................................... 122
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ................................................................ 128
ВИСНОВОК ................................................................................................................. 129
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................ 131
ДОДАТОК А ................................................................................................................. 136
ДОДАТОК Б ................................................................................................................. 138
ДОДАТОК В ................................................................................................................. 155
ДОДАТОК Г ................................................................................................................. 159
ЧДТУ 252159.011 ПЗ
10
11
ЧДТУ 252159.011 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
API - Application Programming Interface
URL - Uniform Resource Locator
СУБД - Система управління базою даних
ORM - Object-relational mapping
ЧДТУ - Черкаський державний технологічний університет
UML - Unified Modeling Language
JWT - JSON Web Token
JSON - JavaScript Object Notation
SQL - Structured Query Language
HTTP - HyperText Transfer Protocol
MVC - Model-View-Controller pattern
HTML - HyperText Markup Language
CSS - Cascading Style Sheets
ООП - Обʼєкто-орієнтований підхід
ПЗ - Програмне забезпечення
JVM - Java Virtual Machine
DTO - Data Transfer Object
SPA - Single-Page Application
ІПН - Ідентифікаційний код платника податків
12
ЧДТУ 252159.011 ПЗ
ВСТУП
Актуальність теми зумовлена значним обсягом інформації та складністю
процесів вступу до закладів вищої освіти. Обробка персональних даних
вступників, інформації про замовників та підготовка пакету документів
згідно з нормативними вимогами залишаються частково або повністю
неавтоматизованимив б агатьоху ніверситетах.Р учнев икористання електронних
таблиць, текстових шаблонів та оформлення документів працівниками
приймальних комісій призводить до затримок, помилок, дублювання даних та
ускладнює облік.
Розробка сучасного програмного забезпечення для вирішення цих
проблем є ключовим завданням інженерії програмного забезпечення. Цей
процес включає системне проектування, що охоплює аналіз вимог, архітектурне
планування, вибір оптимальних технологій, розробку, тестування та подальшу
підтримку системи. Саме такий підхід дозволяє створювати надійні,
масштабовані та ефективні інформаційні системи. Для реалізації даного
проекту обрано сучасний стек технологій, що включає Java, Spring Boot,
Gradle для бекенду та Angular, TypeScript, Material UI для фронтенду, що
відповідає поточним тенденціям у розробці корпоративного програмного
забезпечення.
Застосування принципів інженерії програмного забезпечення
забезпечує автоматизацію обробки даних, генерації документів та інтеграції з
зовнішніми сервісами (DeanOffice, «Дія»), підвищуючи швидкість та якість
роботи приймальних комісій і мінімізуючи людський фактор.
Підвищення прозорості, швидкості та точності роботи з документами є
актуальним завданням для освітніх закладів. Зростаючі вимоги до захисту
персональних даних, розмежування прав доступу та ведення єдиних реєстрів
роблять впровадження спеціалізованих інформаційних систем необхідним.
Ці системи забезпечують централізовану обробку даних, автоматичне
формування документів та безпечну взаємодію між працівниками.
ЧДТУ 252159.011 ПЗ
Особливу актуальність має підтримка багаторівневого доступу з
урахуванням ролей користувачів (оператори факультетів, адміністратори) для
зменшення ризиків несанкціонованого доступу. Важливим є також
забезпечення швидкої перевірки даних через інтеграцію з державними
сервісами («Дія») та внутрішніми університетськими системами (DeanOffice).
Крім того, проблема стандартизації та автоматизації формування
типових юридичних документів вступника (заяв, договорів, згод) є
надзвичайно актуальною. Їх ручне оформлення є часозатратним та схильним
до помилок.
Таким чином, автоматизація створення та обробки вступних документів
за допомогою розробленої системи суттєво оптимізує адміністративні
процеси, мінімізує помилки, підвищить прозорість вступної кампанії та
відповідатиме актуальним вимогам до програмного забезпечення в освіті.
Виконання цієї роботи демонструє практичне застосування знань та навичок з
розробки програмного забезпечення, зокрема з використанням обраного
технологічного стеку.
Метою роботи є проектування та конструювання програмного
забезпечення інформаційної системи для автоматизації процесу обробки
даних вступників та формування юридично значущих документів відповідно
до сучасних вимог інженерії програмного забезпечення в освітній галузі.
Завдання:
аналіз та формалізація функціональних і нефункціональних вимог до
програмного забезпечення;
проектування архітектури інформаційної системи, орієнтованої на
модульність, масштабованість та безпеку;
розробка серверної частини (backend) для обробки даних, управління
користувачами та взаємодії з базою даних;
розробка клієнтської частини (frontend) для забезпечення зручного та
адаптивного інтерфейсу користувача;
ЧДТУ 252159.011 ПЗ
реалізація механізмів авторизації та розмежування прав доступу на
основі ролей;
впровадження інтеграції з зовнішніми сервісами: deanoffice (для
синхронізації довідкових даних) та «дія» (для автоматичного
заповнення персональних даних);
розробка функціоналу для автоматичної генерації документів за
шаблонами з динамічною підстановкою даних;
проведення комплексного тестування програмного забезпечення для
забезпечення коректності, надійності та відповідності вимогам.
Об’єкт розробки: процес розробки програмного забезпечення
інформаційної системи формування юридичних документів для вступників у
заклади вищої освіти.
Інструментарій
Для реалізації програмного забезпечення було використано сучасні
засоби та технології, що дозволили побудувати надійний і масштабований
клієнт-серверний застосунок із підтримкою інтеграції з внутрішніми й
зовнішніми сервісами
Серверна частина системи розроблена мовою програмування Java, яка є
однією з найпоширеніших для створення бекенд-рішень.
У якості основного фреймворку було обрано Spring Boot — платформу,
що забезпечує зручне створення REST API, обробку запитів, реалізацію
авторизації (на основі JWT), валідацію даних і гнучку конфігурацію.
Для зберігання інформації про користувачів, вступників, замовників
використано реляційну базу даних PostgreSQL, яка зарекомендувала себе як
стабільна та продуктивна СУБД. Збирання та керування залежностями на
сервері здійснювалося за допомогою системи Gradle.
Клієнтська частина була реалізована з використанням мови TypeScript
та фреймворку Angular, який дозволив побудувати динамічний,
ЧДТУ 252159.011 ПЗ
багатофункціональний інтерфейс користувача з підтримкою маршрутизації,
реактивних форм та взаємодії з REST API.
Для створення адаптивного й зручного інтерфейсу застосовувалась
бібліотека Angular Material, яка забезпечує компоненти відповідно до
стандартів Material Design.
У рамках проєкту також реалізовано інтеграцію з двома важливими
зовнішніми системами. Перша — це система DeanOffice, яка вже функціонує
в університеті як цифровий деканат. Через REST API забезпечено доступ до
наявних даних про студентів, що дозволяє синхронізувати інформацію між
системами й уникнути дублювання даних. Друга — це державний мобільний
застосунок Дія, з яким реалізовано обмін даними в автоматичному режимі.
Користувач (вступник або замовник) підтверджує передачу персональних
даних на своєму телефоні, після чого система автоматично заповнює
відповідні поля форми. Серед даних, які можуть бути отримані через Дію:
паспортна інформація, реєстраційний номер платника податків, місце
проживання, ПІБ та інші ключові відомості.
Методи проектування та конструювання: у процесі розробки
програмного забезпечення було використано сукупність сучасних підходів до
проєктування та реалізації інформаційних систем, які забезпечують логічну
побудову архітектури, масштабованість і зручність підтримки. Методи
дозволили ефективно організувати роботу над системою відповідно до вимог
до якості та безпеки програмного забезпечення в освітній сфері.
Зокрема, застосовано такі методи:
декомпозиція — розбиття системи на окремі логічні модулі
(вступники, замовники, документи, авторизація);
об’єктно-орієнтоване проектування — побудова структури
програмного забезпечення з урахуванням принципів інкапсуляції,
наслідування та поліморфізму;
ЧДТУ 252159.011 ПЗ
моделювання UML — візуалізація структури та взаємодії
компонентів за допомогою діаграм класів, прецедентів та
послідовності;
інкрементальна розробка — реалізація функціоналу частинами із
поступовим нарощуванням можливостей системи;
принцип розділення відповідальностей (SRP) — чітке розмежування
логіки за призначенням компонентів;
конструювання з можливістю перевірки — реалізація функцій з
орієнтацією на тестування та модульну перевірку працездатності.
Опис отриманих результатів: у результаті було розроблено програмне
забезпечення, що автоматизує процеси обробки даних вступників і
формування юридично значущих документів. Система має модульну
архітектуру, простий і зручний інтерфейс, а також реалізовану авторизацію
користувачів із розмежуванням ролей.
Практичне значення отриманих результатів: Розроблене програмне
забезпечення вже було успішно застосовано під час вступної кампанії в
приймальній комісії університету. Система суттєво полегшила роботу
співробітників, забезпечивши швидке й зручне формування великої кількості
вступних документів. Використання ПЗ дозволило зменшити кількість
помилок, уніфікувати документи та оптимізувати процеси прийому.
Програма відповідає сучасним вимогам до збереження, структурування
та захисту освітньої інформації.
Практичне значення полягає в тому, що ПЗ:
автоматизує рутинні дії працівників приймальної комісії;
зменшує час на підготовку пакету вступних документів;
забезпечує однакову структуру та юридичну коректність документів;
покращує точність і повноту введених даних;
Особистий внесок автора полягає у:
ЧДТУ 252159.011 ПЗ
проведенні аналізу предметної області та існуючих аналогів
розробок;
розробці концептуальної та логічної моделі інформаційної системи;
проектуванні архітектури програмного забезпечення та бази даних;
реалізації серверної частини програмного забезпечення з
використанням java, spring boot та postgresql;
реалізації клієнтської частини програмного забезпечення з
використанням angular, material ui та typescript;
налаштуванні інтеграції з зовнішніми сервісами через rest api;
розробці користувацького інтерфейсу;
проведенні тестування розробленої системи.
ЧДТУ 252159.011 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Актуальні проблеми, що виникають в процесі виконання
завдань
Помилки ручного введення даних
Навіть за наявності електронних форм, оператори приймальних комісій
часто переносять інформацію з паперових заяв вручну: прізвища, імена, дати
народження, паспортні дані. Помилки трапляються через людський фактор —
стомлення, неуважність, різні способи запису дат та спеціальних символів. У
результаті форма допускає неточності, які виявляються на етапі перевірки вже
після подачі документів, що призводить до відмов у реєстрації чи подовження
часу обробки [1]. Обсяги «ручної» роботи стримують автоматизацію та
знижують якість кінцевого результату.
Негнучкість шаблонів документів
Типові рішення базуються на статичних шаблонах DOCX або PDF із
жорстко прописаними «рядками-границями», яким потрібні додаткові правки
в коді щоразу при зміні законодавчих або внутрішніх вимог. Це створює
затримки під час оновлення формулярів і ризики розбіжностей між різними
версіями документів у різних підрозділах університету. Часто доводиться
запускати паралельні гілки коду просто задля підтримки кількох версій
шаблонів одночасно [2].
Проблеми продуктивності та масштабованості
Під час піку вступної кампанії (останній тиждень подачі) система може
обробляти сотні запитів на формування документів у секунду. Якщо серверна
архітектура однозадачна або базується на синхронних викликах, це
призводить до тайм-аутів і зависань. Результат — користувачі бачать помилки
«500 Internal Server Error», а адміністраторам доводиться вручну
перезапускати черги пакетної обробки документів. Подібні «вузькі місця»
часто виявляються вже в продакшені, коли навантаження неможливо точно
ЧДТУ 252159.011 ПЗ
спрогнозувати [3].
Виклики інтеграції та інтероперабельності
Інтеграція з державними платформами (наприклад, «Дія»), внутрішніми
системами DeanOffice, сторонніми реєстрами студентів у різних форматах
часто ускладнюється несумісністю схем і нестачею узгоджених специфікацій.
Різні версії API [4], що змінюються без попереднього повідомлення, можуть
призвести до раптових збоїв у процесі формування пакетів документів і втрати
даних, які вже були підтверджені користувачами.
Відповідність нормам захисту персональних даних
Збір і зберігання таких чутливих даних, як паспортні реквізити,
ідентифікаційні коди та адреси проживання, вимагають строгого дотримання
GDPR, Закону України «Про захист персональних даних» та внутрішніх
політик безпеки. Брак централізованої системи управління правами доступу та
відсутність чіткого журналювання дій користувачів призводять до ризику
витоку або несанкціонованого доступу, а університетам загрожують суттєві
адміністративні штрафи [5].
Порушення принципів SOLID
У великих проєктах розробники часто нехтують розділенням
відповідальності (Single Responsibility) та інверсією залежностей (Dependency
Inversion), внаслідок чого контролери зростають до сотень рядків коду, а зміна
одного методу потребує правок у кількох модулях. Такі «заплетені»
залежності ускладнюють тестування, розширення та підтримку ПЗ, роблячи
його «крихким» перед змінами вимог [6].
Порушення принципу DRY (Don’t Repeat Yourself)
Дублювання фрагментів бізнес-логіки в різних сервісах чи «хардкод»
однакових SQL-запитів в кількох місцях призводить до того, що виправлення
помилки в одному місці не завжди застосовується скрізь. Згодом масив
однакових рядків коду стає джерелом регресій та труднощів у виявленні й
виправленні багів [7].
ЧДТУ 252159.011 ПЗ
Порушення принципу KISS (Keep It Simple, Stupid)
Часто розробники додають занадто багато рівнів абстракції або
шаблонів проєктування (наприклад, складні фабрики чи провайдери для
елементарних об’єктів), що призводить до «over-engineering». Нові члени
команди витрачають
надто багато часу на розуміння архітектури замість продуктивної роботи, а
дебагінг компонентів зі складною залежною структурою займає тижні замість
днів [8].
Накопичення технічного боргу
Щоб випустити черговий реліз до початку вступної кампанії, команди
часом залишають «гарячі патчі» без повного рефакторингу. З роками
технічний борг росте: застарілі бібліотеки, невикористані сервіси, застарілий
код. Це призводить до зниження продуктивності, виснаження ресурсів при
розгортанні та ризику серйозних збоїв при масштабуванні [9].
Відсутність належної обробки помилок та виключень
У багатьох REST-сервісах catch-блоки лишаються порожніми або
обмежуються простим логуванням на консоль. Клієнти отримують
непередбачувані відповіді або generic-статуси без пояснення причин збоїв. Це
ускладнює відлагодження та автоматизацію клієнтської частини, яка не може
коректно реагувати на помилки сервера [10].
Недостатнє автоматизоване тестування
Коли в проєкті є лише кілька базових unit-тестів чи зовсім їх немає, будь-
які зміни бізнес-логіки можуть випадково зламати критичний функціонал
(регресії). Відсутність integration-і e2e-тестів означає, що помилки в сценаріях
від користувацького інтерфейсу дізнаються лише на стадії «реальної»
експлуатації системи [11].
Відсутність або погана організація CI/CD
Деплой вручну через SFTP чи скрипти без єдиного pipeline призводить
до «воєнних» ситуацій під час оновлень: втрати артефактів, неконсистентні
ЧДТУ 252159.011 ПЗ
версії серверів та баз даних. Проблеми з повторюваністю релізів
уповільнюють час виходу оновлень і підвищують ризик людських помилок
[12].
Нестача централізованого логування та моніторингу
Локальні файли логів на різних серверах не збираються в єдину систему,
а відсутність метрик і алертів ускладнює своєчасне виявлення аномалій
(наприклад, раптового зростання часу відповіді API чи сплесків помилок) .
Результат — інциденти
тривалий час залишаються непоміченими, перш ніж вплинуть на кінцевих
користувачів [13].
Конфлікти залежностей та «dependency hell»
У великих Java- and JavaScript-проєктах одночасне використання кількох
бібліотек із несумісними версіями може призвести до конфліктів типів,
runtime-помилок або необхідності примусового виключення частини
функціоналу. Постійне оновлення залежностей без достатньої ретельності
загрожує поломкою суміжних модулів [14].
1.2 Методи та засоби, які вже використовуються для усунення
проблем та виконання завдань
У сучасних інформаційних системах для автоматизації формування
юридичних документів та супутніх процесів застосовується широкий набір
технологій і підходів. Нижче наведено детальний опис основних методів і
засобів.
Автоматизація введення та перевірки даних (OCR, RPA)
Для мінімізації помилок ручного введення застосовують технології
оптичного розпізнавання символів (OCR). OCR-модулі здатні зчитувати текст
із відсканованих заяв або PDF-форм, перетворюючи його в структуровані поля
бази даних [15]. Після розпізнавання дані проходять перевірку за правилами
валідації, що дозволяє відкидати некоректні значення ще до запису в систему.
Крім того, роботизація процесів (RPA) автоматизує перенесення та перевірку
ЧДТУ 252159.011 ПЗ
інформації між різними підсистемами, усуваючи необхідність ручного
копіювання та значно скорочуючи час обробки [16].
Динамічні шаблони документів та движки шаблонізації
Замість того, щоб використовувати фіксовані шаблони у форматах
DOCX або PDF, які важко змінювати, сучасні системи застосовують гнучкіші
підходи. Для цього використовуються спеціальні програмні бібліотеки, такі як
Apache POI [17] та docx4j [18]. Вони дозволяють розробникам створювати
структуру документів за допомогою коду, що робить шаблони дуже
адаптивними.
Крім того, застосовуються так звані "движки правил" (rule-engines) ,
наприклад, Drools [19]. Ці інструменти дозволяють системі самостійно
вирішувати, яка інформація має з'явитися в документі, залежно від певних
умов. Вони також підтримують версіонування полів, тобто дозволяють
швидко змінювати вигляд або вміст полів у документах "на льоту".
Мікросервісна архітектура та асинхронні черги повідомлень
Для обробки великих обсягів запитів система розбивається на незалежні
сервіси: генерації, форматування, збереження документів. Між ними
організовують асинхронні черги на базі RabbitMQ [20] або Apache Kafka [21],
що дозволяє паралельно обробляти тисячі повідомлень. Горизонтальне
масштабування окремих мікросервісів за потреби усуває «вузькі місця» під час
пікових навантажень.
Захист персональних даних і управління доступом
Щоб відповідати GDPR та українському законодавству, запроваджують
шифрування «at rest» (AES-256) та «in transit» (TLS) [22], систему ролей та
прав доступу (RBAC [23]) з інтеграцією LDAP/Active Directory або OAuth
2.0/OpenID Connect [24]. Всі операції з чутливими даними фіксуються в аудит-
логах, що дозволяє відстежувати зміни й відновлювати історію доступів.
Принципи SOLID, DRY, KISS
Для підвищення якості коду використовують принципи SOLID [25],
ЧДТУ 252159.011 ПЗ
DRY [26] та KISS [27]. Дотримання цих підходів сприяє чіткому розділенню
відповідальностей, уникненню дублювання коду та зниженню складності
архітектури.
Автоматизоване тестування (Unit, Integration, E2E)
Unit-тести на JUnit 5 [28] із Mockito [29] покривають бізнес-логіку
сервісного шару на Spring Boot; інтеграційні тести з @SpringBootTest та
вбудованою in-memory базою H2 [30] перевіряють роботу репозиторіїв і шарів
доступу до даних; E2E-тести на Cypress [31] імітують повні сценарії
користувачів у Angular-додатку. Така багаторівнева стратегія гарантує
стабільність і швидке виявлення регресій при подальшому розвитку проєкту.
CI/CD-конвеєри
Інтеграція та розгортання автоматизуються за допомогою Jenkins [32],
GitLab CI [33] чи GitHub Actions [34]. Кожен коміт проходить збірку,
тестування і розгортання в staging-середовище, а в разі успіху – у production.
Це зменшує кількість ручних помилок і пришвидшує час виходу нових релізів.
Моніторинг і централізоване логування
Використовують ELK-стек (Elasticsearch, Logstash/Fluentd, Kibana) [35]
або Prometheus [36] + Grafana [37] для збору метрик, візуалізації
продуктивності та налаштування алертів на аномалії (зріст часу відповіді,
збільшення відсотка помилок). Це дає змогу проактивно реагувати на
інциденти до їхнього загострення.
Контейнерне розгортання та управління кластерами
Для уніфікації середовищ застосовують Docker [38] — пакування
сервісів із усіма залежностями в контейнери. Оркестрація Kubernetes [39]
забезпечує автоматичне масштабування, self-healing та декларативне
керування конфігураціями кластерів, що дозволяє швидко розгортати нові
версії та гарантувати високу доступність.
Міграції та версіонування схеми бази даних
Щоб уникнути розбіжностей схем між середовищами та спростити
ЧДТУ 252159.011 ПЗ
оновлення структури таблиць, застосовують інструменти міграцій: Flyway [40]
або Liquibase [41]. Вони зберігають усі зміни схеми у вигляді версіонованих
скриптів, автоматично виконують їх у потрібному порядку при запуску
програми та забезпечують можливість відкату до попередньої версії у разі
помилок.
1.3 Аналіз існуючих аналогів інформаційних систем
Інформаційно-аналітична система підтримки освітньої діяльності
університету
Розроблена на базі ЧДТУ веб-орієнтована система, що забезпечує
уніфікацію електронного документообігу, централізоване збирання даних про
успішність студентів. Містить модулі для адміністратора, деканату,
налаштування критеріїв оцінювання та формування звітів.
Переваги:
централізоване збереження та обробка інформації про навчальний
процес;
гнучкі шаблони документів;
розмежування доступу за ролями;
інтеграція з іншими підсистемами університету.
Недоліки:
відсутність мобільної версії для зручної роботи зі смартфонів.
Slate by Technolutions
Slate by Technolutions — це комплексна система для управління всім
циклом вступної кампанії в навчальних закладах. Вона допомагає
автоматизувати процеси від першого контакту з абітурієнтом до його
зарахування.
ЧДТУ 252159.011 ПЗ
Рисунок 1.1 – Інтерфейс системи управління вступною кампанією
Переваги:
універсальний онлайн-прийом заяв: інтуїтивна форма подачі і
завантаження документів з перевіркою на коректність;
потужний редактор шаблонів: інтерфейс дозволяє створювати і
тестувати шаблони документів без залучення розробників;
автогенерація пакетів документів: є можливість генерувати складні
pdf-пакети (заяви, листи, договори) в один клік;
масові комунікації: підтримка як email, так і sms-розсилок, що
дозволяє швидко інформувати різні сегменти абітурієнтів;
інтеграція з docusign: спрощує процес електронного підпису
важливих документів.
ЧДТУ 252159.011 ПЗ
висока вартість: заявки для невеликих вишів можуть виявитися
економічно невигідними через щомісячну підписку;
обмежена кастомізація: глибока модифікація шаблонів вимагає
знань html/css та розуміння внутрішньої логіки платформи;
залежність від зовнішніх сервісів: для коректної роботи необхідні
платні сервіси підпису й email-провайдери.
Slate допомагає навчальним закладам оптимізувати роботу приймальних
комісій, покращити взаємодію з абітурієнтами та підвищити ефективність
вступного процесу [42] (рисунок 1.1).
OpenApply (від Liaison International)
OpenApply — це хмарна платформа (SaaS), розроблена для спрощення
процесу подачі заяв абітурієнтами до навчальних закладів. Вона має
вбудований інструмент для створення PDF-документів (рисунки 1.2-1.4).
Переваги:
інтуїтивний веб-редактор шаблонів: можливість редагувати html-
шаблони з миттєвим попереднім переглядом;
rest api: відкритий інтерфейс дозволяє автоматизувати генерування
документів і підключати зовнішні сервіси;
масові email-кампанії: автоматичне інформування абітурієнтів про
статус заяв і необхідні дії;
мобільний додаток: швидкий доступ до інформації про документи та
статус заявки з будь-якого пристрою.
Недоліки:
обмежена гнучкість ui: налаштування користувацького інтерфейсу
досить базові і обмежені стандартними параметрами;
додаткові модулі за плату: розширена функціональність (наприклад,
просунута аналітика) доступна тільки через окремі ліцензії;
залежність від інтернету: оскільки рішення хмарне, у разі
ЧДТУ 252159.011 ПЗ
нестабільного з’єднання можливі затримки у роботі.
OpenApply допомагає навчальним закладам ефективніше керувати
вступним процесом, забезпечуючи зручність для абітурієнтів та підвищуючи
продуктивність приймальних комісій [43].
Рисунок 1.2 – Основні можливості на платформі OpenApply
482 ЧДТУ 252159 12 01
Рисунок 1.3 – Головна сторінка платформи
Рисунок 1.4 - Імпорт або експорт документів
1.4 Конкретизація завдань роботи
Авторизація з певним ролями доступу
ЧДТУ 252159.011 ПЗ
1 Користувач здійснює вхід до системи за допомогою індивідуального
логіна та пароля.
2 Система підтримує розподіл ролей: оператор (доступ до даних
абітурієнтів свого факультету з правом редагування та додавання) та
адміністратор (повний доступ до всіх даних і налаштувань).
Управління даними абітурієнтів
1 Оператор приймальної комісії, відповідальний за певний факультет,
може створювати нові записи абітурієнтів, заповнюючи необхідну
інформацію (ПІБ, паспортні дані, ІПН тощо).
2 Оператор приймальної комісії має можливість редагувати дані
обраного абітурієнта, що належить до його факультету.
3 Реалізовано перегляд списку абітурієнтів з функціями фільтрації (за
ПІБ, курсом, спеціальністю, формою навчання) та сортування.
Оператору відображаються лише абітурієнти, що відносяться до
закріпленого за ним факультету.
4 Адміністратор має всі можливості оператора (створення,
редагування, перегляд, фільтрація, сортування) для всіх абітурієнтів,
незалежно від факультету. Крім того, адміністратор має право
видаляти записи абітурієнтів з системи.
Управління даними замовників
1 Оператор може додавати інформацію про замовника, обираючи його
тип (фізична або юридична особа).
2 При редагуванні даних абітурієнта оператор може змінювати
інформацію про пов'язаного замовника.
3 Якщо абітурієнт є повнолітнім, система автоматично визначає його
як замовника.
4 Для абітурієнтів, що вступають на бюджетну форму навчання,
передбачено вибір відповідного типу замовника без необхідності
введення додаткових даних.
ЧДТУ 252159.011 ПЗ
5 Розширення: При додаванні нового абітурієнта, система надає
можливість вибору існуючого замовника з попередньо введеної бази
даних (якщо такий існує). При цьому відображається список раніше
введених замовників (з можливістю пошуку за ПІБ або назвою), що
дозволяє уникнути повторного введення однакової інформації.
Інтеграція з DeanOffice
1 При створенні або редагуванні запису абітурієнта оператору
надається можливість вибору актуальних даних про факультети,
спеціальності та освітні програми, що підвантажуються з DeanOffice.
Інтеграція з “Дією”
2 Оператор має функціонал для автоматичного завантаження
паспортних та ідентифікаційних даних абітурієнта через інтеграцію
з сервісом "Дія".
Генерація пакета юридичних документів
1 Оператор може обрати один або декілька доступних типів
документів (контракт, договір про надання освітніх послуг, заява,
договір про навчання) для генерації.
2 Система автоматично заповнює обрані шаблони даними абітурієнта
та пов'язаного замовника.
3 Сформовані документи у форматі .DOCX автоматично
завантажуються на пристрій оператора.
ЧДТУ 252159.011 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було проаналізовано актуальні проблеми, з якими
стикаються приймальні комісії та розробники автоматизованих систем
обробки заяв абітурієнтів, зокрема: помилки ручного введення даних,
негнучкість шаблонів, продуктивнісні обмеження під час пікових
навантажень, складнощі інтеграції з зовнішніми сервісами та забезпечення
безпеки персональних даних. Було розглянуто існуючі підходи — від систем
на базі статичних DOCX/PDF-шаблонів до комплексних SaaS-рішень (Slate,
OpenApply), їхні переваги й обмеження.
Дослідження методів і засобів виявило, що для усунення виявлених
недоліків необхідно застосувати: динамічні механізми шаблонізації,
асинхронну й мікросервісну архітектуру, сучасні засоби інтеграції з OCR та
RPA, а також суворі механізми шифрування та управління доступом.
Конкретизовані завдання роботи націлені на реалізацію цих підходів — від
побудови гнучкої системи шаблонів до організації безпечного каналу обміну з
порталом «Дія» і DeanOffice.
Отже, перший розділ закладає теоретичну основу й обґрунтовує потребу
в розробці нової інформаційної системи, яка б поєднала переваги аналізованих
аналогів та врахувала виявлені недоліки.
482 ЧДТУ 252159 12 01
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання охоплює всі сутності, процеси та
правила, необхідні для підтримки циклу роботи з абітурієнтами у системі
автоматизації прийому до закладу вищої освіти. Вона включає реєстрацію та
управління користувачами, збір і верифікацію даних абітурієнтів, обробку
заявок, роботу з довідниками факультетів, спеціальностей та освітніх програм,
а також механізм генерації документів на основі шаблонів.
Ця область покликана забезпечити такі ключові функціональності:
керування користувачами: створення та автентифікація облікових
записів операторів і адміністраторів з різними рівнями доступу;
обробка заяв абітурієнтів: прийом, збереження та верифікація
персональних даних та документів абітурієнтів;
управління довідниками: синхронізація факультетів, спеціальностей
і освітніх програм із зовнішніми системами (deanoffice) та підтримка
актуальності цих довідників;
генерація документів: підготовка docx-файлів за обраними
шаблонами з підстановкою інформації про абітурієнта, замовника та
освітню програму;
впровадження інтеграцій: взаємодія з державним порталом «дія» для
підтвердження достовірності даних абітурієнта.
Ця модель предметної області стане основою для подальшої розробки
логіки системи, визначення API-інтерфейсів і структури бази даних.
Модель предметної області
482 ЧДТУ 252159 12 01
Модель предметної області — це статичне уявлення ключових
сутностей та їхніх взаємозв’язків у межах системи. На діаграмі (рисунок 2.1)
представлено:
сутності: об’єкти доменної області (користувачі, абітурієнти,
шаблони документів тощо);
асоціації: взаємозв’язки між сутностями з вказаними
кардинальностями (один-до-багатьох, один-до-одного);
атрибути: набір основних полів, які характеризують кожну сутність.
Дана UML-діаграма слугує фундаментом для побудови схеми бази
даних та визначення REST/API-інтерфейсів. Вона допомагає чітко окреслити
структуру даних, залежності та обмеження, необхідні для реалізації бізнес-
логіки.
Рисунок 2.1 – Модель предметної області
Словник предметної області
Користувач – обліковий запис у системі з унікальним логіном і
захищеним паролем. Кожний користувач має одну з двох ролей: ADMIN
(адміністратор) або OPERATOR (оператор приймальної комісії).
482 ЧДТУ 252159 12 01
Оператор – користувач із роллю OPERATOR, який працює виключно з
абітурієнтами свого факультету.
Адміністратор – користувач із роллю ADMIN, який має до всіх даних
системи.
Абітурієнт – фізична особа, яка подає документи до ЗВО через систему;
характеризується ПІБ, датою народження, серією й номером паспорта, ІПН,
контактними даними.
Замовник – той, хто оплачує навчання: фізична особа (може збігатися з
абітурієнтом), юридична особа або «бюджет».
Факультет – структурний підрозділ університету, відповідальний за
певні напрями підготовки.
Спеціальність – напрям підготовки фахівців у межах факультету;
характеризується кодом і назвою.
Освітня програма – документальна структура (перелік дисциплін та
кількість кредитів) для певної спеціальності й ступеня; містить інформацію
про акредитацію.
Ступінь – рівень кваліфікації, який отримує абітурієнт після успішного
завершення освітньої програми.
Шаблон документа – файлова заготовка у форматі DOCX із
вбудованими плейсхолдерами (наприклад, {FULL_NAME}, {SPECIALTY},
{DATE}). Шаблон містить поля з певними плейсхолдерами, які під час
генерації автоматично заповнюються актуальними даними абітурієнта та
замовника.
Згенерований документ – створений на основі конкретного шаблону.
Містить фактичні дані абітурієнта, замовника, факультету та програми;
завантажується у форматі DOCX, містить у назві ПІБ студента, дату й час
створення.
Інтеграція з DeanOffice – сервіс для автоматичної синхронізації
довідників факультетів, спеціальностей і освітніх програм із інформаційно-
482 ЧДТУ 252159 12 01
аналітичною системою університету. Дозволяє уникнути ручного введення та
гарантує актуальність даних.
Інтеграція з «Дією» – сервіс для отримання та верифікації персональних
даних абітурієнта з державного порталу «Дія» (паспортні дані, ІПН тощо).
Забезпечує достовірність інформації та скорочує час заповнення форм.
2.1.2 Елементи моделювання предметної області
Для моделювання предметної області та при проектуванні системи в
цілому будемо використовувати мову UML Для діаграм мови UML існують
три типи візуальних позначень: графічні символи, зв’язки (єднальні елементи),
текст (рисунки 2.2-2.4).
482 ЧДТУ 252159 12 01
Рисунок 2.2 - Основні графічні символи UML [44]
482 ЧДТУ 252159 12 01
Рисунок 2.3 - Єднальні елементи UML [44]
482 ЧДТУ 252159 12 01
Рис. 2.4 – Основні діаграми UML, що використовуються в проєкті [44]
Графічні моделі наочно демонструють структуру предметної області,
окреслюючи архітектуру програмного комплексу: його основні компоненти,
взаємозв’язки та точки інтеграції з зовнішніми сервісами. Вони забезпечують
спільне бачення системи для всіх зацікавлених сторін — від аналітиків і
розробників до менеджерів проєкту — що дозволяє оперативно узгоджувати
вимоги та зменшує ймовірність непорозумінь.
Такі діаграми полегшують оцінку впливу майбутніх змін, прискорюють
підготовку технічної документації та навчання нових учасників команди. До
того ж, наочно відображаючи зв’язки між об’єктами й модулями, вони
слугують надійним фундаментом для подальшого логічного та фізичного
проєктування, а також для контролю якості реалізації.
2.1.3 Робоча область моделювання
Авторизація та розмежування ролей
Метою є гарантувати безпечний вхід у систему й динамічне
відображення інтерфейсу залежно від ролі. Авторизовуватись може
користувач з певною роллю (Operator або Admin).
Користувач вводить у форму свій логін і пароль. Інтерфейс надсилає ці
дані до сервісу автентифікації, де за логіном знаходять профіль і перевіряють
відповідність пароля. У разі невідповідності система повідомляє про помилку
(«Невірний логін» або «Невірний пароль») і блокує доступ. Якщо дані
правильні, формується сесійний токен, який містить роль користувача. Після
цього інтерфейс завантажує головний екран: оператор бачить лише список
абітурієнтів свого факультету і відповідні кнопки взаємодії, адміністратор —
повну таблицю з усіма вступника різних факультетів, додавання та
редагування інформації.
Додавання абітурієнта та замовника з імпортом із «Дії»
Метою спрощення введення даних шляхом автоматичного підтягання
верифікованих державних реквізитів.
482 ЧДТУ 252159 12 01
Оператор відкриває форму створення нового абітурієнта. Він може
одразу скористатися кнопкою «Імпорт із Дії»: система ініціює авторизацію на
держпорталі й повертає ПІБ, дату народження, паспортні дані та ІПН. Ці поля
автоматично заповнюються, оператор лише перевіряє їх і додає відсутні
(телефон, email). Далі потрібно обрати факультет і освітню програму зі
випадаючого списку, які синхронізуються із DeanOffice. Після цього
визначається тип замовника: «бюджет» не вимагає введення реквізитів, для
фізичної або юридичної особи відкриваються відповідні поля. І на завершення
оператор натискає «Зберегти», і система створює записи в таблицях
абітурієнтів і, якщо треба, замовників.
Альтернативні ситуації
Якщо «Дія» тимчасово недоступна — оператор вводить всі поля вручну.
При отриманні некоректних даних від «Дії» — система відображає
попередження й пропонує продовжити ручне введення.
Результат
У таблиці з’являється новий рядок із профілем абітурієнта та даними
замовника.
Редагування даних абітурієнта та замовника
Метою забезпечити гнучке управління профілем абітурієнта після його
створення.
Щоб змінити інформацію про вступника, оператор у таблиці вступників
обирає потрібного студента та натискає на кнопку «Редагувати». Далі
відкривається форма із вже підставленими даними про студента та замовника,
якщо він є. Оператор коригує будь-які поля: наприклад, уточнює email, змінює
реквізити замовника або оновлює програму навчання. Після натискання
«Зберегти» система перевіряє права операторського доступу, проводить
валідацію введених значень і оновлює записи в база. Після успішного
редагування у таблиці відразу підтягується оновлена інформація.
Альтернативні ситуації.
482 ЧДТУ 252159 12 01
У разі невідповідності формату даних — підсвічуються проблемні поля.
Результат
Запис абітурієнта та дані замовника оновлено в базі даних і
відображається в таблиці студентів.
Генерація юридичних документів
Метою є автоматичо сформувати пакет необхідних документів на основі
шаблонів і даних абітурієнтів.
Оператор у таблиці відмічає одного або кількох абітурієнтів і натискає
кнопку «Генерувати документи». Система відображає перелік чотирьох
доступних шаблонів (контракт на навчання, договір про освітні послуги, заява
на вступ, договір про навчання). Оператор вибирає ті документи, які потрібні,
та підтверджує запит. Після цього сервіс по черзі обробляє кожен шаблон:
підставляє у файл-заготовку поля абітурієнта (ПІБ, ІПН, факультет, програма,
дата), формуючи готовий документ у .docx форматі. Щоб уникнути колізій,
імена файлів генеруються за схемою
Прізвище_Ім’я_YYYYMMDD_HHMMSS.docx. Згенеровані файли відразу
завантажуються на комп’ютер оператора.
Результат
Оператор отримує готові завантажені документи для подальшого друку
або розсилки.
2.2 Формування та аналіз вимог
Для розробки програмного забезпечення, що автоматизує створення
юридичних документів для вступників до ЗВО, критично важливо детально
сформувати та проаналізувати вимоги.
Замовником проєкту є університет, а саме:
приймальна комісія – є основними користувачами, формуючи
операційні потреби.
Етап формування та аналізу вимог передбачає збір інформації від усіх
зацікавлених сторін, її уточнення для уникнення неоднозначностей та
482 ЧДТУ 252159 12 01
документування. Результатом цього етапу є специфікація вимог, яка
поділяється на:
первинні (вимоги замовника): що система повинна робити з погляду
користувача;
детальні (вимоги розробника): як це буде реалізовано технічно;
функціональні: що система повинна робити;
нефункціональні: якісні характеристики системи (наприклад,
продуктивність, безпека).
Цей процес забезпечує узгодженість між усіма учасниками проєкту.
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
Первинні вимоги і детальні вимоги
ПЕРВИННІ ВИМОГИ
1 Будь-який співробітник приймальної комісії, який використовує
систему, повинен мати унікальні облікові дані (логін та пароль) для
безпечного входу в систему.
2 Система повинна розділяти ролі користувачів: адміністратор і
оператор приймальної комісії.
3 Оператор повинен мати доступ лише до абітурієнтів свого
факультету: при вході в систему оператор приймальної комісії
повинен бачити та мати можливість працювати лише з даними тих
абітурієнтів, які подали заяви на факультети, за які відповідає даний
оператор.
4 Оператор повинен мати можливість додати абітурієнта як і вручну,
так і частину інформації (в основному паспортні дані) з
підтягуванням даних із «Дії».
5 Система повинна підтримувати декілька типів замовників: фізична
особа, юридична особа.
482 ЧДТУ 252159 12 01
6 Оператор повинен мати змогу редагувати дані абітурієнта та
замовника. Після додавання інформації про абітурієнта та/або
замовника, оператор повинен мати можливість вносити зміни до
раніше введених даних.
7 Оператор повинен мати змогу обирати шаблони документів і
генерувати їх для обраних студентів. Система повинна надавати
оператору можливість вибору одного або кількох шаблонів
документів (наприклад, заява про вступ, договір про навчання, згода
на обробку персональних
даних).
8 Згенеровані документи повинні бути завантаженими на пристрій
оператора приймальної комісії.
9 Система повинна мати механізм для періодичного або за запитом
обміну даними з існуючою університетською системою DeanOffice.
Це включає отримання актуальних списків факультетів,
спеціальностей, освітніх програм, а також іншої необхідної
довідкової інформації.
ДЕТАЛЬНІ ВИМОГИ
Авторизація повинна здійснюватись з перевіркою облікових даних у базі
даних; При спробі входу користувача в систему, серверна частина повинна
отримати введені логін та пароль з веб-інтерфейсу. Потім система здійснює
пошук введеного логіна у таблиці користувачів (users) бази даних. Якщо логін
знайдено, то далі користувач отримує доступ.
Після входу користувач отримує токен із зашифрованою інформацією
про його роль і доступ. Після успішної авторизації, серверна частина системи
генерує JWT. Цей токен містить зашифровану інформацію про ідентифікатор
користувача (user_id), його роль (role - адміністратор або оператор), а також
може включати додаткову інформацію про його права доступу, наприклад,
ідентифікатор факультету (faculty_id) для операторів. Токен підписується
482 ЧДТУ 252159 12 01
секретним ключем сервера для забезпечення його цілісності та автентичності.
Згенерований JWT повертається клієнту (веб-браузеру), який повинен
зберігати його (наприклад, у cookie або localStorage) та передавати у заголовку
Authorization (зазвичай з префіксом Bearer) при кожному наступному HTTP-
запиті до API серверної частини для підтвердження своєї автентичності та
прав доступу.
В інтерфейсі оператора відображаються лише абітурієнти, прив’язані до
факультету користувача. Коли оператор приймальної комісії входить в
систему та переходить до розділу зі списком абітурієнтів, серверна частина
системи при обробці запиту на отримання цих даних повинна враховувати
faculty_id, що міститься в JWT цього оператора. Запит до бази даних (таблиці,
що зберігає інформацію про абітурієнтів) повинен містити умову фільтрації,
яка відбирає лише ті записи абітурієнтів, у яких поле, що відповідає за
факультет, збігається з faculty_id оператора. Таким чином, оператор бачить
лише релевантних для його роботи абітурієнтів.
Додавання абітурієнта можливе через заповнення форми, також за
допомогою імпорту деяких даних з «Дії». У разі успішного імпорту поля
заповнюються автоматично. Система повиненна надавати користувачу
(оператору) можливість додавання інформації про абітурієнта та заповнення
деяких полів за допомогою додатка «Дія». Оператору надається веб-форма з
усіма необхідними полями для введення персональних даних абітурієнта,
контактної інформації, місце проживання тощо. Після заповнення форми та її
відправлення, дані передаються на сервер для валідації та збереження в базі
даних. Оператор може натиснути на певну кнопку, щоб отримати дані з
додатка «Дія» і після успішної передачі даних від «Дії» на сервер системи,
отримані дані автоматично заповнюють відповідні поля у формі створення
профілю абітурієнта в інтерфейсі оператора, мінімізуючи необхідність
ручного введення.
482 ЧДТУ 252159 12 01
При створенні абітурієнта можна обрати тип замовника, який впливає на
структуру заповнюваних даних: у формі додавання інформації про абітурієнта
повинен бути передбачений елемент керування (наприклад, випадаючий
список або радіо-кнопки) для вибору типу замовника послуги: "Фізична
особа", "Юридична особа", "Бюджет". Залежно від обраного типу, веб-
інтерфейс повинен динамічно відображати різні набори полів, необхідних для
введення інформації про замовника.
1 Для фізичної особи: Відображаються поля для введення ПІБ, ІПН,
паспортних даних, адреси проживання.
2 Для юридичної особи: Відображаються поля для введення назви
організації, коду ЄДРПОУ, юридичної адреси, контактних даних.
3 Для бюджету: Поля для введення інформації про замовника можуть
бути відсутні.
Також система повинна надавати можливість вибору існуючого
замовника з попередньо введеної бази даних. Потрібно відобра список раніше
введених
замовників (з можливістю пошуку), що дозволяє уникнути повторного
введення
інформації.
Дані абітурієнта повинні бути доступні для редагування. Усі зміни
фіксуються із зазначенням часу та користувача. Систма має надавати
оператору можливість відкрити існуючий запис абітурієнта для перегляду та
внесення змін до всіх його даних, а також до даних пов'язаного замовника. При
збереженні внесених змін, серверна частина системи повинна оновити дані
про студента та про замовника.
Система повинна мати інтерфейс вибору одного або кількох документів
для генерації: шаблони зберігаються у форматі DOCX з певними
плейсхолдерами. Система повинна надавати оператору можливість обрати
один або кілька доступних шаблонів документів зі списку (наприклад, за
482 ЧДТУ 252159 12 01
допомогою чекбоксів). Ці шаблони повинні бути попередньо завантажені до
системи та зберігатися на сервері у форматі DOCX. У тексті цих шаблонів
повинні бути використані спеціальні плейсхолдери (текстові мітки у фігурних
дужках), які відповідають полям даних абітурієнта та його замовника
(наприклад, #FullName, #Faculty тощо).
Дані автоматично підставляються в шаблон і результатом є файл для
завантаження з іменем "Прізвище_Ім'я_Дата.docx". Після того як оператор
обрав один або кілька шаблонів та вказав абітурієнта (або групу абітурієнтів)
для генерації документів, серверна частина системи повинна виконати
наступні дії для кожного обраного шаблону та абітурієнта:
Зчитати вміст відповідного DOCX-файлу шаблону.
1 Знайти всі плейсхолдери у тексті шаблону.
2 Отримати з бази даних дані обраного абітурієнта та його замовника.
3 Замінити кожен плейсхолдер на відповідне значення з отриманих
даних.
4 Сформувати новий DOCX-файл з підставленими даними.
5 Надати оператору згенерований файл. Ім'я кожного файлу повинно
формуватися за визначеним форматом, наприклад,
"Прізвище_Ім'я_Дата_Час.docx", щоб забезпечити їхню унікальність
та інформативність.
Інтеграція з DeanOffice відбувається через API, який викликається при
додаванні або редагуванні профілю абітурієнта для підвантаження даних про
факультет. При створенні або редагуванні профілю абітурієнта у веб-
інтерфейсі, клієнтська частина повинна надсилати запити до API серверної
частини. Серверна частина, у свою чергу, повинна здійснювати виклик
відповідних ендпоінтів API системи DeanOffice для отримання актуальних
довідкових даних, таких як список факультетів, спеціальностей, освітніх
програм. Отримані від DeanOffice дані повинні бути оброблені та збережені у
локальній базі даних системи для подальшого використання при відображенні
482 ЧДТУ 252159 12 01
випадаючих списків та валідації введених даних у формах. Цей процес може
відбуватися синхронно (під час створення/редагування) або асинхронно
(наприклад, періодично для оновлення локальних довідників).
Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Вимоги замовника
1 Автентифікація і безпека даних. Система повинна забезпечити
надійний вхід користувачів через унікальні логіни та паролі, а також
розмежування прав між операторами факультетів і
адміністраторами.
2 Автоматизація введення даних. Можливість імпорту даних
абітурієнта з державного порталу «Дія» та автоматичне
підвантаження довідників із DeanOffice.
3 Управління профілями абітурієнтів. Створення, редагування та
зберігання профілів із валідацією обов’язкових полів
4 Генерація юридичних документів. Автоматичне формування пакета
документів у форматі DOCX за вибором шаблонів із підстановкою
персональних даних.
5 Контроль доступу. Оператори мають бачити лише своїх абітурієнтів;
адміністратори — повний обсяг даних.
6 Журналювання і звітність. Фіксація всіх дій користувачів із
подальшою можливістю формування звітів за період
Вимоги розробника
1 Технологічний стек. Використання Java + Spring Boot, PostgreSQL,
Angular + TypeScript; REST API з JWT-автентифікацією.
2 Архітектура. Мікросервісна або модульна структура з чітким
розподілом відповідальності (Auth, Applicants, Documents).
3 Масштабованість. Підтримка горизонтального масштабування
компонентів генерації документів за допомогою черг повідомлень.
482 ЧДТУ 252159 12 01
4 Тестування. Покриття коду юніт- та інтеграційними тестами не
менше ніж 80%;
Функціональні вимоги
1 Створення, редагування та перегляд абітурієнтів.
2 Фільтрація, сортування, пошук по таблиці абітурієнтів.
3 Отримання інформації про факультети, спеціальності та освітні
програм з DeanOffice.
4 Інтеграція з «Дією» для автоматичного заповнення даних.
5 Реалізація всіх CRUD-операцій для сутностей Applicant, Customer,
Document.
6 Реалізація механізму вибору існуючого замовника при створенні
абітурієнта.
7 Підтримка ролей і прав доступу на рівні REST ендпойнтів.
8 Генерація декількох документів одночасно з динамічною
підстановкою.
Нефункціональні вимоги
1 Безпека: використання HTTPS; авторизація через JWT.
2 Продуктивність: швидка генерація документів.
3 Інтерфейсність: підтримка сучасних браузерів, адаптивність
інтерфейсу.
4 Доступність: рівень доступності — не менше 99,5% часу.
5 Супровідність: погоджений стиль коду, зрозуміла структура
репозиторію.
6 Юзабіліті: інтерфейс згідно з принципами Material Design,
адаптивність до різних екранів.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів (Use Case Diagram) є графічним інструментом
UML для формалізації вимог до системи з точки зору її користувачів. Вона
складається з акторів — зовнішніх ролей або систем, які взаємодіють із
482 ЧДТУ 252159 12 01
розроблюваним ПЗ, та прецедентів (варіантів використання) — сценаріїв
виконання певних функцій системи. Актори з’єднуються з прецедентами
зв’язками асоціацій, що показують, які саме операції вони можуть ініціювати
або на які можуть реагувати. Завдяки простій та інтуїтивній візуалізації
діаграма прецедентів дозволяє швидко зафіксувати набір вимог, узгодити їх із
зацікавленими сторонами та забезпечити чітке бачення функціональних
можливостей системи ще на ранньому етапі проєктування (рисунки 2.5-2.10).
Рисунок 2.5 – Діаграма прецендентів авторизації у інформаційну систему
482 ЧДТУ 252159 12 01
Рисунок 2.6 – Діаграма прецедентів управління записами
абітурієнтів для оператора
Рисунок 2.7 – Діаграма прецедентів управління записами абітурієнтів для
адміністратора
482 ЧДТУ 252159 12 01
Рисунок 2.8 – Діаграма прецедентів отримання даних про певний факультет
Рисунок 2.9 – Діаграма прецедентів отримання даних про всі факультети
482 ЧДТУ 252159 12 01
Рисунок 2.10 – Діаграма прецедентів: Генерація юридичних документів
2.3 Проектування логічної структури програмного комплексу
Проектування логічної структури програмного комплексу полягає в
перетворенні моделі предметної області на узгоджену мережу програмних
компонентів і сервісів без прив’язки до конкретних технологій розгортання.
На цьому етапі визначаються класи-абстракції, їхні зв’язки (асоціації,
узагальнення, агрегація), а також логічні пакети чи модулі, які групують класи
за функціональними зонами (наприклад, модуль авторизації, модуль роботи з
абітурієнтами, модуль документів).
Крім того, формулюються інтерфейси сервісів і контракти обміну
даними між модулями — це забезпечує слабке зчеплення, чітке розмежування
відповідальності та гнучкість у розширенні системи. Результатом такого
проєктування є зрозуміла «карта» внутрішньої архітектури, яка служить
орієнтиром для розробки, тестування та подальшої еволюції ПЗ.
2.3.1 Діаграми класів
Діаграма класів — це UML-модель, що відображає статичну структуру
482 ЧДТУ 252159 12 01
системи через класи та зв’язки між ними. Клас позначається прямокутником
із назвою у верхній частині і представляє узагальнену сутність із властивим
набором даних та операцій. Зв’язки між класами (асоціації, узагальнення,
агрегація, композиція) демонструють, як об’єкти взаємодіють та організовані
у відношення «ціле–частина» або «успадкування». На початковому етапі
моделювання в діаграмі класів зазвичай вказують лише назви класів та типи
зв’язків без деталізації атрибутів та методів, що допомагає зосередитися на
загальній архітектурі та взаємодії основних компонентів системи (рисунки
2.11-2.14).
482 ЧДТУ 252159 12 01
Рисунок 2.11 - Діаграма класів модуля Applicantt
482 ЧДТУ 252159 12 01
Рисунок 2.12 - Діаграма класів модуля Deanoffice
482 ЧДТУ 252159 12 01
482 ЧДТУ 252159 12 01
Рисунок 2.13 - Діаграма класів модуля Document
Рисунок 2.14 - Діаграма класів модуля Security
2.3.2 Діаграми пакетів
Діаграма пакетів — це UML-модель, призначена для логічного
групування схожих елементів моделі (наприклад, класів, компонентів чи
варіантів використання) у контейнери – «пакети». Пакет позначається
прямокутником із вкладеним іменем і може містити інші пакети або елементи
482 ЧДТУ 252159 12 01
UML. За допомогою діаграм пакетів можна показати ієрархію модулів,
залежності між підсистемами та зони відповідальності, що значно спрощує
структурування великих моделей, полегшує навігацію та підтримку системи
(рисунок 2.15).
Рисунок 2.15 – Діаграма пакетів
2.4 Архітектурне проектування
Архітектурне проектування встановлює базову структуру системи
шляхом визначення ключових компонентів, їхніх відповідальностей та
взаємодій. Воно спрямоване на реалізацію нефункціональних вимог
(продуктивність, надійність, масштабованість, безпека) та створює чітку
основу для побудови, розгортання й подальшої еволюції ПЗ.
2.4.1 Діаграма компонентів
482 ЧДТУ 252159 12 01
Діаграма компонентів — це UML-діаграма, що ілюструє розподіл
системи на фізичні чи логічні компоненти (модулі), а також інтерфейси та
залежності між ними. Компонент позначається прямокутником зі стереотипом
<<component>> і
може містити внутрішні структури або бути пов’язаний із файлами артефактів
(бібліотеки, модулі). На діаграмі показують:
компоненти - окремі елементи системи з чітко визначеними межами
відповідальності;
інтерфейси - набір операцій, які компоненти надають (provided) або
використовують (required);
залежності - зв’язки між компонентами, що показують напрямок і
тип взаємодії.
Діаграма компонентів (рисунок 2.16) сприяє розумінню розгортання
системи, плануванню модульного тестування та організації процесу CI/CD, а
також полегшує комунікацію між розробниками та операційною командою.
Рисунок 2.16 – Діаграма компонентів
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Розгортання програмної системи на апаратних засобах
482 ЧДТУ 252159 12 01
Розгортання системи передбачає розміщення програмних компонентів
на фізичних або віртуальних пристроях та налаштування зв'язку між ними.
Основні кроки:
клієнтський пристрій: веб-браузер або мобільний додаток, що
взаємодіє із сервером через http/https;
веб-сервер: проксі-сервер (наприклад, nginx або apache), який
приймає запити від клієнтів і проксить їх на сервер додатків;
сервер додатків: контейнер виконання (наприклад, jetty), що
розгортає артефакт бекенду (.jar) та обробляє бізнес-логіку;
сервер бази даних: postgresql, який зберігає постійні дані системи;
мережеве середовище: налаштування vlan, docker-сіток або хмарних
мереж, забезпечення безпечного каналу (tls) між вузлами.
Діаграма розгортання
Діаграма розгортання (Deployment Diagram) відображає структуру
апаратних та віртуальних вузлів (рисунок 2.17), середовищ виконання
(execution environments) та артефактів (artifacts). Вона показує:
вузли (nodes): фізичні пристрої або віртуальні машини, позначені
тривимірними прямокутниками зі стереотипом <<device>>;
середовища виконання (execution environments): контейнери або
рушії (наприклад, jetty), що розміщують артефакти;
артефакти (artifacts): виконувані файли, бібліотеки та бази даних;
зв’язки: комунікаційні канали (http, tcp) між вузлами.
482 ЧДТУ 252159 12 01
Рисунок 2.17 – Діаграма розгортання
2.5 Моделювання поведінки системи
Моделювання поведінки системи зосереджується на описі динамічних
аспектів її роботи: послідовності дій, умовних переходів і паралельних потоків
виконання. Ця стадія проєктування дозволяє візуалізувати процеси обробки
даних, взаємодії компонентів та ролей, оптимізувати бізнес-логіку і
забезпечити зрозуміле представлення поведінки системи для всіх зацікавлених
сторін.
2.5.1 Діаграма діяльності
Діаграма діяльності (Activity Diagram) — UML-діаграма, що моделює
робочі процеси та алгоритми всередині системи (рисунки 2.18-2.21). Вона
складається з:
дій (activities): вузли, що позначають конкретні кроки або завдання;
переходів (transitions): стрілки, які показують напрямок та
послідовність виконання дій;
початкового та кінцевого станів (initial and final nodes): точки входу
та виходу з процесу;
482 ЧДТУ 252159 12 01
умовних розгалужень (decision nodes): вузли для вибору
альтернативних шляхів виконання на основі умов;
об’єднувачів та розгалужувачів (merge and fork nodes): елементи для
моделювання паралельних та синхронізованих потоків;
доріжок і пулів (lanes and pools): розбиття процесу за
відповідальністю користувачів, ролей або компонентів системи;
Діаграми діяльності допомагають:
візуалізувати бізнес-логіку та алгоритмічні сценарії;
виявити вузькі місця та оптимізувати послідовність операцій;
узгодити процеси між аналітиками, розробниками та кінцевими
користувачами;
служити документацією для подальшої розробки та тестування.
Рисунок 2.18 – Діаграма діяльності авторизації
482 ЧДТУ 252159 12 01
Рисунок 2.19 – Діаграма діяльності управління записами абітурієнтів
482 ЧДТУ 252159 12 01
482 ЧДТУ 252159 12 01
Рисунок 2.20 – Діаграма діяльності формування юридичних документів
482 ЧДТУ 252159 12 01
482 ЧДТУ 252159 12 01
Рисунок 2.21 – Діаграма діяльності отримання даних про факультет
2.5.2 Діаграма послідовності
Діаграма послідовності (Sequence Diagram) — UML-діаграма взаємодії,
що відображає часовий порядок обміну повідомленнями між об’єктами чи
компонентами (рисунки 2.22-2.26). Основні елементи:
лінії життя (lifelines): вертикальні пунктирні лінії, що представляють
існування об’єктів у часі;
повідомлення (messages): стрілки між лініями життя — синхронні
виклики, асинхронні повідомлення, повернення значень;
фокус управління (execution occurrence): прямокутні смужки на лінії
життя, що показують період виконання операцій;
початок і кінець (creation and destruction): спеціальні повідомлення
для створення чи знищення об’єкта.
Діаграми послідовності корисні для:
документування сценаріїв виконання конкретних функціональних
вимог (варіантів використання);
виявлення затримок і залежностей у потоках викликів;
узгодження інтерфейсів та протоколів взаємодії між компонентами;
підтримки розробки та тестування, зокрема при реалізації сервісних
викликів чи вебзапитів.
482 ЧДТУ 252159 12 01
Рисунок 2.22 - Діаграма послідовності авторизації
Рисунок 2.23 - Діаграма послідовності додавання абітурієнта
482 ЧДТУ 252159 12 01
Рисунок 2.24 - Діаграма послідовності редагування абітурієнта
Рисунок 2.25 - Діаграма послідовності генерації юридичних документів
482 ЧДТУ 252159 12 01
Рисунок 2.26 - Діаграма послідовності видалення абітурієнта адміністатором
2.5.3 Діаграма комунікації
Діаграма комунікації (Communication Diagram) — UML-діаграма
взаємодії, що акцентує увагу на структурі зв’язків між об’єктами та порядку
обміну повідомленнями (рисунок 2.27). Ключові елементи:
об’єкти: представлені прямокутниками з ім’ям та роллю підсистеми;
лінії зв’язку: зв’язують об’єкти, демонструючи їхню здатність
обмінюватися повідомленнями;
позначки повідомлень: числові маркери біля стрілок вказують на
послідовність обміну.
Діаграма комунікації дозволяє:
відобразити топологію взаємодії компонентів;
визначити залежності та напрями потоків даних;
спростити аналіз зв’язків у розподілених чи модульних системах;
використовувати більш компактне представлення, ніж діаграма
послідовності.
482 ЧДТУ 252159 12 01
Рисунок 2.27 - Діаграма комунікації системи
2.5.4 Діаграма скінченного автомату
Діаграма скінченних автоматів (State Machine Diagram) — UML-
діаграма, що описує життєвий цикл об’єктів через стани та переходи (рисунок
2.28). Основні елементи:
стан (state): прямокутник із закругленими кутами, що позначає умову
або ситуацію об’єкта;
початковий стан (initial node): заповнене коло, яке вказує на початок
життєвого циклу;
кінцевий стан (final node): подвійне коло, що означає завершення
існування об’єкта;
переходи (transitions): стрілки між станами, часто супроводжуються
подіями або умовами;
вхідні/вихідні дії (entry/exit actions): короткі операції, що
виконуються при вході чи виході зі стану;
застосування діаграм скінченних автоматів;
моделювання реактивної поведінки системних об’єктів;
482 ЧДТУ 252159 12 01
опис обробки подій та часових умов;
формалізація життєвих циклів складних елементів (наприклад,
статус заявки чи запиту);
забезпечення чіткої документації для розробки і тестування
поведінкової частини системи.
Рисунок 2.28 - Діаграма скінченного автомату системи
482 ЧДТУ 252159 12 01
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі було спроектовано програмне забезпечення системи
автоматизації прийому абітурієнтів на всіх рівнях моделювання.
1 Предметна область: визначено ключові сутності, їх атрибути та
взаємозв’язки, що забезпечують чітку основу для побудови бази
даних та API-інтерфейсів.
2 Елементи моделювання: описано графічні символи, зв’язки та UML-
діаграми, які будуть використовуватися для документації структури,
поведінки та взаємодії системи.
3 Структурні діаграми: розроблено класову модель, організовано
класи у пакети, спроектовано компоненти та описано їх інтерфейси.
4 Архітектурні діаграми: сформована схема компонентів, визначені
межі відповідальності модулів та описано розгортання на апаратних
вузлах через Deployment Diagram.
5 Динамічні моделі: змодельовано бізнес-процеси за допомогою
Activity Diagram, послідовності викликів через Sequence та
Communication Diagrams, а також описано життєвий цикл об’єктів за
допомогою State Machine Diagram.
Таким чином, у другому розділі закладено повний набір проєктних
артефактів, від предметної області до опису динамічної поведінки до
необхідних для подальшої реалізації, тестування й впровадження системи.
482 ЧДТУ 252159 12 01
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
3.1.1 Обґрунтування вибору засобів реалізації
Вибір технологічного стеку для розробки системи автоматизованого
формування документів є критично важливим для успіху проєкту. Ми
ретельно проаналізували та обґрунтували кожен компонент, щоб забезпечити
відповідність функціональним та нефункціональним вимогам, а також
ефективність розробки та подальшої експлуатації.
Обрані мови програмування
Java: Вибрано для бекенду як стабільна, перевірена та
високопродуктивна мова для корпоративної розробки. Версія LTS гарантує
довгострокову підтримку, а оптимізації JVM забезпечують ефективну обробку
великих обсягів даних під час пікових навантажень [45]. Велика екосистема та
активна спільнота прискорюють розробку.
TypeScript: Використовується для фронтенду разом з Angular.
TypeScript, будучи надмножиною JavaScript, додає статичну типізацію, що
дозволяє виявляти помилки на етапі розробки, покращує читабельність коду
та спрощує рефакторинг у великих проєктах [46].
Обрані фреймворки та бібліотеки
Spring Boot: Лідер серед Java-фреймворків для швидкої розробки
бекенду. Завдяки автоконфігурації та вбудованому HTTP-серверу значно
прискорює старт проєкту та спрощує розгортання. Набір "стартерів" надає
готові рішення для типових задач [47].
Angular: Потужний фреймворк для розробки фронтенду. Пропонує чітку
модульну архітектуру, реактивні форми з RxJS для роботи з асинхронними
даними, та вбудовану маршрутизацію для складних Single Page Applications
(SPA) [48].
482 ЧДТУ 252159 12 01
Spring Security: Комплексний фреймворк для забезпечення безпеки Java-
додатків. Надає потужні можливості для аутентифікації, авторизації,
управління
ролями та захисту від веб-атак [49].
Hibernate ORM (через Spring Data JPA): Технологія ORM (Object-
Relational Mapping), яка значно спрощує взаємодію з базою даних, дозволяючи
працювати з об'єктами Java замість прямого SQL. Це зменшує обсяг
шаблонного коду та прискорює розробку.
docx4j: Бібліотека для генерації юридичних документів у форматі
Microsoft Word (DOCX). Дозволяє нативно працювати з DOCX без
встановленого MS Office, заповнювати плейсхолдери реальними даними та
підтримує складні елементи документів [50].
JWT: Використовується для безстанної аутентифікації. Сервер генерує
JWT, що містить інформацію про користувача, що спрощує масштабування
системи та фільтрацію даних [51].
Angular Material: Бібліотека UI-компонентів, що реалізує Material
Design. Забезпечує єдиний, сучасний та інтуїтивно зрозумілий стиль
інтерфейсу, прискорюючи розробку UI.
ModelMapper: Допоміжна бібліотека для автоматичного перетворення
об'єктів між DTO та Entity, зменшуючи обсяг ручного коду [52].
Обрані системи та середовища розробки
PostgreSQL: Реляційна система керування базами даних (СУБД) для
надійного та безпечного зберігання даних. Відома своєю винятковою
надійністю, відповідністю стандарту ACID [53], розширюваністю та високою
продуктивністю.
IntelliJ IDEA: Основне інтегроване середовище розробки (IDE) для
backend-частини на Java/Spring Boot.
WebStorm: Використовується як інтегроване середовище розробки (IDE)
для frontend-частини на Angular/TypeScript.
482 ЧДТУ 252159 12 01
Gradle: Система збірки та управління залежностями проєкту. Забезпечує
високу швидкість інкрементальних збірок та гнучку конфігурацію плагінів.
Git та GitHub: Система контролю версій Git та платформа GitHub
забезпечують ефективну командну розробку, централізоване зберігання коду,
відстеження змін та управління гілками [54].
3.1.2 Опис структурної (функціональної) схеми
Структурна схема (рисунок 3.1) відображає основні логічні та фізичні
компоненти програмного комплексу та їхні взаємозв’язки. Вона дає загальне
уявлення про архітектуру системи, показуючи, які підсистеми існують, за які
функціональні блоки вони відповідають, і як вони спілкуються між собою,
використовуючи, наприклад, HTTP-виклики або безпосередній доступ до
бази даних. Ця схема є фундаментальною для розуміння розподілу
відповідальності та потенційних точок інтеграції.
482 ЧДТУ 252159 12 01
Рисунок 3.1 - Загальна структурна схема компонентів системи
Опис компонентів архітектурної схеми
Інтерфейс користувача
Клієнтська частина системи, через яку оператори та адміністратори
здійснюють усі дії: логін, введення даних абітурієнта, перегляд списків, запуск
генерації документів. Надсилає HTTP-запити до бекенд-сервісів і відображає
отримані результати.
Сервіс аутентифікації
Приймає запити на вхід у систему, перевіряє облікові дані користувача
та видає маркер (токен) для подальшої авторизації всіх наступних запитів.
Сервіс абітурієнтів
Виконує операції створення, читання, оновлення й видалення профілів
абітурієнтів: зберігає їхні персональні дані, пошукові запити та забезпечує
доступ до списків усіх зареєстрованих кандидатів.
Сервіс документів
Відповідає за підготовку й формування юридичних документів
(контрактів, заяв та ін.): отримує шаблони, підставляє в них дані абітурієнтів і
повертає готові файли клієнту.
Сервіс інтеграції
Забезпечує комунікацію із зовнішніми інформаційними системами:
отримує довідкові дані (факультети, спеціальності) від одного API та
підтверджує персональні дані абітурієнтів (паспорт, ІПН) через інший.
PostgreSQL (база даних)
Центральне сховище, де зберігаються всі сутності системи: користувачі,
абітурієнти, налаштування та історія згенерованих документів.
Шаблони документів
Файлове або мережне сховище з шаблонами (DOCX) юридичних форм,
які наповнюються даними та віддаються готовими документами.
482 ЧДТУ 252159 12 01
Зовнішні сервіси:
DeanOffice API – джерело довідкових даних для приймальної комісії
(факультети, спеціальності, освітні програми тощо).
Diia API – державний сервіс для верифікації паспортних та інших
персональних даних абітурієнтів.
Функціональна схема (рисунок 3.2-3.8) деталізує інформаційні потоки
між підсистемами, показуючи, як дані вводяться, обробляються й
повертаються користувачеві чи зовнішнім системам. Вона ілюструє
послідовність дій та взаємодію компонентів системи для виконання ключових
бізнес-процесів.
Рисунок 3.2 - Функціональна схема основного інформаційного потоку
Пояснення кроків функціональної схеми
Введення даних користувачем: Користувач починає взаємодію з
системою через інтерфейс користувача, вводячи необхідні дані, такі як
логін/пароль для входу, інформацію для створення або редагування профілю
абітурієнта, або обираючи шаблони документів для генерації.
482 ЧДТУ 252159 12 01
Аутентифікація: Після введення облікових даних, сервіс
аутентифікації перевіряє їхню відповідність записам у PostgreSQL. У разі
успішної перевірки, користувачеві видається JWT, який слугуватиме для
підтвердження його особи та прав доступу до системи протягом сесії.
Дії користувача: Цей центральний етап починається після успішної
аутентифікації. Сервіс абітурієнтів виконує базові CRUD-операції,
здійснюючи читання та запис даних про абітурієнтів у PostgreSQL. З цього ж
етапу ініціюються два ключові процеси:
генерація документів: при запиті на створення юридичних
документів, сервіс документів взаємодіє з папкою шаблонів для
отримання необхідного шаблону. потім він автоматично заповнює
плейсхолдери шаблону даними абітурієнта та замовника і надсилає
готовий файл у форматі docx назад до клієнта;
синхронізація зовнішніх даних: для забезпечення актуальності та
повноти інформації, сервіс інтеграції здійснює синхронізацію з
зовнішніми системами. це відбувається через deanoffice api для
оновлення довідників (наприклад, списків факультетів та освітніх
програм) та через diia api для отримання та верифікації персональних
даних абітурієнтів, таких як паспортні дані, іпн тощо.
3.1.3 Опис логічної схеми системи
Логічна схема системи є формалізованим представленням послідовності
дій, що відбуваються в межах функціонування програмного забезпечення, та
дозволяє описати інформаційні процеси, які забезпечують досягнення
цільових результатів. Такий опис включає етапи обробки даних, прийняття
рішень, взаємодії з користувачем, збереження та передачу інформації в
системі.
Одним з найбільш поширених способів відображення логіки роботи ПЗ
є алгоритмічний опис у текстовій формі з подальшим поданням графічної
інтерпретації у вигляді блок-схем або діаграм діяльності UML.
482 ЧДТУ 252159 12 01
У даному проєкті реалізована система для автоматизації процесу
формування та генерації документів вступників до закладу вищої освіти з
підтримкою шаблонів, перевірки даних тощо. В описі логічних схем (рисунки
3.3-3.8) розглядаються основні сценарії роботи, подані як алгоритми.
Аутентифікація та видача JWT
Коли користувач вводить логін і пароль у веб-інтерфейсі, Angular-клієнт
відправляє POST-запит на ендпоінт /api/auth/login, передаючи JSON із полями
username та password. Далі відбувається перевірка на валідність введених
даних. У разі невдалого входу сервер повертає помилку HTTP 401
Unauthorized. Якщо ж автентифікація проходить успішно, у сервісі
здійснюється пошук користувача через
userRepository.findByUsername(username) та перевірка, що в його списку ролей
лише одна роль (наприклад, ROLE_OPERATOR або ROLE_ADMIN) – інакше
формується HTTP 400 Bad Request. Далі викликається метод
jwtService.generateToken(userDetails), який формує JWT. У токені
встановлюються такі клейми:
sub = username (ідентифікатор користувача);
rol = роль (ROLE_OPERATOR/ROLE_ADMIN);
iss = faculty_id (якщо роль = ROLE_OPERATOR);
iat = час видачі;
exp = час закінчення дії (унікальний для токена, налаштовується
через властивість jwt-expiration-time).
Після підписання токена секретним ключем сервер повертає HTTP 200
OK із тілом { "token": "<JWT-токен>" }, який клієнт зберігає (наприклад, у
LocalStorage) та використовує для подальших запитів.
482 ЧДТУ 252159 12 01
Рисунок 3.3 - Логічна схема аутентифікації та генерації JWT
Після видачі токена клієнт додає його до заголовка кожного наступного
запиту: Authorization: Bearer <JWT>, що дозволяє безстатусну авторизацію –
інформацію про роль та faculty_id містить сам токен.
Авторизація запитів із фільтрацією за роллю і faculty_id
Після збереження JWT клієнт кожного разу надсилає його в заголовку
Authorization. Spring Security-фільтр перехоплює вхідний запит і викликає
jwtService.extractUserName(token) для отримання username та
jwtService.extractClaim(token, "rol") для з’ясування ролі користувача –
ROLE_ADMIN або ROLE_OPERATOR. Якщо токен прострочений або підпис
недійсний, сервер повертає HTTP 401 Unauthorized. Якщо ж усе в порядку,
виконується певний метод з jwtService, щоб отримати faculty_id, який
зберігається в DNS-клеймі iss (для оператора). Далі jwtService виклакає метод,
щоб отримати дані з таблиці applicants.
Сервер виконує цей запит через Spring Data JPA. Таким чином, кожен
оператор бачить лише абітурієнтів свого факультету, а адміністратор – усіх.
482 ЧДТУ 252159 12 01
Рисунок 3.4 - Логічна схема авторизації за ролями
За такого підходу всі запити на читання даних абітурієнтів забезпечують
наскрізну перевірку прав доступу: роль і приналежність до факультету
закладені в самому токені. Кожен оператор бачить лише абітурієнтів свого
факультету, завдяки faculty_id, закладеному в JWT. Адміністратор отримує всі
активні записи.
1 Якщо заголовок Authorization відсутній або містить некоректний
JWT, відразу повертається 401.
2 Якщо JWT валідний, система отримує з нього role і facultyId.
3 Якщо користувач із роллю ROLE_ADMIN, немає жодних обмежень
у запиті до таблиці applicants.
4 Якщо ROLE_OPERATOR, запит фільтрується за facultyId, щоб
повернути лише тих абітурієнтів, які належать до даного факультету.
Отримання списку активних абітурієнтів
482 ЧДТУ 252159 12 01
На стороні бекенду виконується простий запит до таблиці applicants з
умовою is_active = true. Роль користувача враховується лише для обмеження
доступу оператора до записів свого факультету — без додаткових умов
пошуку чи сортування. Натомість всі параметри пошуку, фільтрації та
сортування (наприклад, за прізвищем, факультетом, спеціальністю)
обробляються на фронтенді за допомогою можливостей AG Grid [55].
Після отримання List<ApplicantDTO> клієнт передає отримані дані у AG
Grid. Саме вже у таблиці студентів і вмикаються вбудовані механізми:
фільтрація (з полями, які оператор задає у таблиці);
пошук по всіх колонках;
сортування (натискання на заголовок колонки сортує дані).
Таким чином, бекенд обмежує лише вибірку «активних» та «за
факультетом», а всі інші операції виконуються швидко й ефективно на
фронтенді.
Додавання абітурієнта
1 Клієнт відправляє POST-запит на /api/applicants, додаючи у
заголовок JWT (Authorization: Bearer <token>). Сервер перевіряє
дійсність токена: якщо він прострочений або підпис некоректний,
повертається HTTP 401 Unauthorized.
2 Якщо токен дійсний, Spring Boot автоматично проводить валідацію
полів ApplicantDTO за анотаціями @NotNull, @Pattern, @Email
тощо. У разі помилок валідації система відповідає HTTP 400 Bad
Request із переліком виявлених помилок.
3 За відсутності помилок визначається значення поля customerType.
Якщо customerType == "PERSON", перевіряється, чи в
ApplicantDTO.personCustomerId передано існуючий ідентифікатор.
Якщо так, викликається
personCustomerService.getById(personCustomerId); у разі відсутності
запису повертається HTTP 400 Bad Request із повідомленням
482 ЧДТУ 252159 12 01
“Замовника не знайдено”. Якщо personCustomerId не вказано, але
присутній об’єкт personCustomer, через ModelMapper створюється
новий запис у таблиці person_customer (метод
personCustomerService.addPersonCustomer(...)), і збережений об’єкт
пов’язується з новим Applicant.
4 Якщо customerType == "ORGANIZATION", відбувається аналогічна
перевірка: якщо в ApplicantDTO.organizationCustomerId є значення,
викликається
organizationCustomerService.getById(organizationCustomerId) і, за
його відсутності, повертається HTTP 400 Bad Request. Якщо ж
передано об’єкт organizationCustomer, створюється новий запис у
таблиці organization_customer через
organizationCustomerService.addOrganizationCustomer(...) й
асоціюється з Applicant.
5 Якщо customerType == "BUDGET", значення полів для замовника
ігноруються.
6 Після опрацювання замовника створюється об’єкт Applicant на
основі отриманих полів із ApplicantDTO за допомогою ModelMapper,
далі встановлюється createdAt = LocalDateTime.now() і isActive = true.
7 Метод applicantService.addApplicant(applicant) зберігає сформовану
сутність у базі даних через applicantRepository.save(applicant). У
відповіді повертається HTTP 200 OK із JSON-об’єктом нового
абітурієнта, у якому вже є згенерований id.
482 ЧДТУ 252159 12 01
Рисунок 3.5 - Логічна схема додавання абітурієнта
Оновлення абітурієнта
482 ЧДТУ 252159 12 01
1 Клієнт надсилає PUT-запит до /api/applicants/{applicantId}, додаючи
JWT у заголовок. Сервер перевіряє токен і, у разі недійсності,
відповідає HTTP 401 Unauthorized.
2 Якщо токен дійсний, виконується applicantService.getApplicant
ById(applicantId). Якщо запис з таким id не знайдено, сервер повертає
HTTP 404 Not Found.
3 За наявності запису Spring Boot автоматично проводить валідацію
полів ApplicantDTO. Якщо результати валідації невдалі, система
відповідає HTTP 400 Bad Request.
4 Далі обробляється поле customerType. Якщо customerType ==
"PERSON", перевіряється personCustomerId: якщо воно вказане,
викликається personCustomerService.getById(personCustomerId) і, у
разі відсутності запису, повертається HTTP 400 Bad Request
“Замовника не знайдено”. Якщо замовник знайдений, за потреби
оновлюються його поля, у результаті викликається
personCustomerService.update(...). Якщо ж у
ApplicantDTO.personCustomer надано дані нового замовника, то
створюється запис у person_customer (addPersonCustomer(...)) і він
пов’язується з Applicant.
5 Якщо customerType == "ORGANIZATION", виконується аналогічна
логіка: перевіряється organizationCustomerId і, за його відсутності, за
наявності об’єкта organizationCustomer, створюється новий запис або
оновлюється наявний через organizationCustomerService.
6 Якщо customerType == "BUDGET", значення полів для замовника
ігноруються.
Видалення абітурієнта (адміністратор)
1 Адміністратор відправляє DELETE-запит до
/api/applicants?ids=(наприклад 5,12,18). Сервер перевіряє токен: якщо
він недійсний, повертається HTTP 401 Unauthorized. Потім з токена
482 ЧДТУ 252159 12 01
витягується клейм rol: якщо це не ROLE_ADMIN, сервер відповідає
HTTP
403 Forbidden.
2 Якщо роль користувача — ROLE_ADMIN, строка параметра ids
розбивається на список чисел.
3 Для кожного id із цього списку виконується
applicantRepository.findById(id). Якщо запис існує, викликається
applicantRepository.delete(applicant).
4 Після завершення циклу видалення повертається HTTP 200 OK, без
тіла відповіді.
482 ЧДТУ 252159 12 01
Рисунок 3.6 - Логічна схема оновлення даних студента
482 ЧДТУ 252159 12 01
Рисунок 3.7 - Логічна схема видалення студента або студентів
482 ЧДТУ 252159 12 01
Генерація юридичних документів
Коли оператор або адміністратор переглядає список абітурієнтів, він
може відмітити одного чи кількох студентів за допомогою галочок у таблиці.
Після цього він натискає кнопку «Згенерувати документи» і в діалоговому
вікні обирає один або кілька типів шаблонів (наприклад, «Заява», «Договір»).
Після цього Angular-клієнт для кожного відміченого абітурієнта по черзі
відправляє GET-запит на ендпоінт /api/{document-type}/{applicantId}, де
{document-type} — обраний тип документа, {applicantId} — ідентифікатор
конкретного студента.
На сервері відбувається наступне:
перевірка авторизації. якщо у заголовку http не знайдено дійсного jwt
або термін його дії минув, запит повертає http 401 unauthorized;
підготовка до генерації. створюється колекція generatedfiles для
збереження згенерованих документів;
обробка кожного абітурієнта. для кожного applicantid викликається
метод пошуку студента, який перевіряє чи існує студент з таким .
якщо запис не знайдено або абітурієнт неактивний (isactive == false),
то відобразиться помилка;
обробка шаблонів. якщо абітурієнт дійсний і активний, для кожного
вибраного типу документа завантажується відповідний docx-шаблон
із ресурсу (наприклад, contractapplication.docx). через утиліту
templatefiller.fill(...) на основі docx4j проходять усі xml-вузли
шаблона і замінюють плейсхолдери (наприклад, #fullname, #faculty,
#studyyear) на реальні поля: прізвище та ім’я абітурієнта, назву
факультету, рік навчання тощо;
відправлення результату. після заповнення даними студента або
студентів усіх обраних оператором шаблонів документів,
482 ЧДТУ 252159 12 01
згенеровані документи відправляються на клієнт і автоматично
завантажуються на пристрій користувача.
Рисунок 3.8 - Логічна схема генерація юридичних документів
Таким чином, оператору не потрібно нічого робити з внутрішніми
файлами — після натискання кнопки всі необхідні дії відбуваються на сервері,
і браузер одразу зберігає згенерований документ на його комп’ютер.
Алгоритм пошуку та вибору існуючого замовника
482 ЧДТУ 252159 12 01
1 Оператор відкриває форму для створення абітурієнта й обирає тип
замовника: “Фізична особа” або “Юридична особа”.
2 Якщо обрано “Фізична особа”, то оператор може ввести прізвище та
ім’я, після чого Angular надсилає запит до сервера з параметрами
пошуку (прізвище та ім’я). Сервер робить запит до таблиці
person_customer, де відбирає ті записи, у яких поле last_name містить
заданий текст (і поле first_name містить введене ім’я, якщо воно
задане). У відповідь сервер надсилає список усіх знайдених фізичних
осіб у формі об’єктів із ПІБ та датою народження.
3 Angular відображає отриманий список у формі. Якщо оператор
обирає одну з позицій цього списку, усі поля форми, що стосуються
фізичної особи (ПІБ, дата народження, паспортні дані, адреса,
телефон, email), автоматично заповнюються даними з обраного
запису. Якщо сервер повернув порожній список, то на екрані нічого
не появиться і всі поля залишаються порожніми, щоб оператор міг
заповнити їх вручну.
4 Якщо обрано “Юридична особа”, то оператору відразу повинен
ввести ЄДРПОУ існуючого замовника. Далі надсилається GET-запит
із параметром (код ЄДРПОУ) до сервера, який у таблиці
organization_customer шукає всі записи, де поле edrpou_code містить
заданий набір цифр. Сервер повертає список знайдених організацій
із необхідними полями (назва, адреса, телефон, email).
5 Angular показує цей перелік результатів під полем вводу. Якщо
оператор натискає рядок із потрібною організацією, відповідні поля
форми (назва організації, адреса, код ЄДРПОУ, банківські реквізити,
телефон, email) заповнюються значеннями з обраного запису. Якщо
жодної організації не знайдено, оператору залишаються порожні
поля, які він заповнює вручну.
482 ЧДТУ 252159 12 01
6 Після того як оператор обрав існуючого замовника або самостійно
заповнив всі поля, він завершує введення даних абітурієнта
(факультет, спеціальність, курс тощо) і натискає кнопку “Зберегти”.
У DTO надсилаються або personCustomerId / organizationCustomerId,
якщо вибрано існуючий запис, або повні дані нового об’єкта
PersonCustomer / OrganizationCustomer. Сервер відповідно або
використовує наявний запис замовника, або створює новий у базі.
Алгоритм автоматичного отримання паспортних даних із «Дія»
1 У формі створення чи редагування абітурієнта поряд із полями
паспортних даних знаходиться кнопка “Отримати дані з Дія”. Коли
оператор натискає цю кнопку, Angular-клієнт формує GET-запит до
внутрішнього ендпоінта, наприклад, /api/diia/import-passport.
2 Сервер приймає запит і перевіряє дійсність JWT у заголовку. Якщо
токен недійсний або відсутній — повертає HTTP 401 Unauthorized.
Якщо токен дійсний, сервер формує запит до державного API «Дія»,
передаючи необхідні автентифікаційні дані (токен користувача від
«Дія»).
3 Державний сервіс «Дія» обробляє запит і повертає JSON-об’єкт із
паспортними даними та ідентифікаційним кодом платника податків.
4 Якщо «Дія» повернула помилку (наприклад, прострочений
сертифікат, неправильні дані), сервер повертає помилку. Відповідно,
поля залишаються порожніми, й оператор заповнює їх вручну.
5 Якщо ж дані надійшли успішно, сервер повертає Angular HTTP 200
OK із JSON-пакетом, що містить усі перелічені вище поля. Angular
отримує цю відповідь і виконує програмне авто-заповнення форми:
поля “прізвище”, “ім’я”, “по батькові” оновлюються з lastname,
firstname та patronymic;
поле “дата народження” встановлюється зі значенням birthdate;
482 ЧДТУ 252159 12 01
поля “серія паспорта”, “номер паспорта”, “ким виданий” та “дата
видачі” заповнюються з відповідних полів відповіді;
поле “термін дії паспорта” установлюється з passportexpirydate;
поле “ідентифікаційний код” заповнюється з taxpayercode.
6 Після автозаповнення оператор має змогу перевірити, чи всі поля
коректні, і, за потреби, змінити будь-які значення вручну. Решту
полів (контактні дані, факультет, спеціальність тощо) він заповнює
самостійно.
7 Після завершення формування даних абітурієнт зберігає форму
кнопкою “Зберегти”. DTO, яке відправляється на сервер, містить уже
заповнені паспортні поля, ІПН та інші атрибути абітурієнта. Сервер
зберігає новий або оновлює існуючий запис у таблиці applicants.
У результаті оператору достатньо натиснути одну кнопку “Отримати
дані з Дія”, і всі ключові паспортні дані підтягуються автоматично, що значно
скорочує час введення та знижує ризик помилки.
3.1.4 Розробка бази даних
Концептуальна модель даних описує, які об’єкти існують у системі та
як вони взаємодіють, не акцентуючись на конкретній реалізації чи типах
даних. Це дозволяє узгодити розуміння вимог між замовником, користувачами
бізнес‐логіки та розробниками (рисунки 3.9-3.17).
482 ЧДТУ 252159 12 01
Рисунок 3.9 - Загальна схема бази даних системи автоматизованого
формування юридичних документів
У системі реалізовано вісім основних таблиць, що забезпечують
зберігання інформації про абітурієнтів, їхніх замовників, користувачів та
додаткові службові дані.
1 PersonCustomer – містить дані замовників–фізичних осіб (ПІБ,
паспортні дані, ІПН тощо).
2 OrganizationCustomer – зберігає інформацію про юридичних
замовників (назва організації, ЄДРПОУ, банківські реквізити тощо).
3 Applicant – центральна таблиця, що містить повні профілі
абітурієнтів (особисті й навчальні дані, посилання на замовника,
статус “active”).
482 ЧДТУ 252159 12 01
4 User – облікові записи системи (оператори та адміністратори) із
логіном, хешованим паролем і, опційно, прив’язкою до факультету.
5 Role – перелік можливих ролей (ROLE_ADMIN, ROLE_OPERATOR
тощо).
6 UsersRoles – проміжна таблиця для зв’язку «багато-до-багатьох» між
користувачами й ролями; дає змогу одному користувачеві мати
декілька ролей.
7 Payment – довідкова таблиця з тарифами на навчання залежно від
ступеня, форми навчання та року.
8 FlywaySchemaHistory – службова таблиця Flyway, що фіксує історію
виконаних міграцій схеми (версія, час виконання, успіх чи помилка).
Кожна таблиця пов’язана з іншими за допомогою зовнішніх ключів або
логічних відповідностей. Наприклад, у Applicant поля person_customer_id та
organization_customer_id є зовнішніми ключами, що вказують відповідно на
PersonCustomer.id та OrganizationCustomer.id. Зв’язок «багато-до-багатьох»
між User і Role реалізовано через таблицю UsersRoles.
Таблиця PersonCustomer
482 ЧДТУ 252159 12 01
Рисунок 3.10 - Структура таблиці PersonCustomer
Таблиця PersonCustomer призначена для зберігання вичерпної
інформації про замовників-фізичних осіб, які можуть бути пов’язані з одним
або кількома абітурієнтами. Ключова роль цієї таблиці – зберігати дані про
замовника та також забезпечити можливість повторного використання даних
фізичної особи як замовника замість введення цих даних вручну для кожного
нового абітурієнта.
Поля таблиці PersonCustomer:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор запису
фізичної особи-замовника. Значення генерується автоматично базою
даних при додаванні нового запису;
first_name VARCHAR NOT NULL: Ім’я фізичної особи-замовника.
Це поле є обов’язковим для заповнення;
482 ЧДТУ 252159 12 01
last_name VARCHAR NOT NULL: Прізвище фізичної особи-
замовника; Також обов’язкове для заповнення;
patronymic VARCHAR NULL: По батькові фізичної особи. Це поле
може бути порожнім (NULL), якщо така інформація відсутня;
birth_date DATE NULL: Дата народження фізичної особи.
Використовується для більш точної ідентифікації та пошуку
замовника;
phone_number VARCHAR NOT NULL: контактний номер телефону
замовника. Обов’язкове поле, необхідне для формування контактних
даних у документах;
email VARCHAR NOT NULL: Адреса електронної пошти замовника.
Це обов’язкове поле, яке може бути використане для автовідправки
повідомлень (за потреби);
registration_address VARCHAR NOT NULL: Повна адреса реєстрації
(прописка) фізичної особи. Це обов’язкове поле;
taxpayer_code VARCHAR NOT NULL UNIQUE: Ідентифікаційний
код платника податків (ІПН) фізичної особи. Має обмеження
UNIQUE, що гарантує відсутність дублювання записів для однієї і
тієї ж особи в системі;
document_name VARCHAR NULL: Тип документа, що посвідчує
особу замовника (наприклад, «паспорт громадянина України», «ID-
картка»);
document_series VARCHAR NULL: Серія документа, що посвідчує
особу;
document_number VARCHAR NULL: Номер документа, що
посвідчує особу;
document_issued_by VARCHAR NULL: Назва органу, що видав
документ (наприклад, «УДМС м. Києва», «ДМС України»);
document_issued_date DATE NULL: Дата видачі документа;
482 ЧДТУ 252159 12 01
document_expiry_date DATE NULL: Термін дії документа. Це поле
може бути NULL для безстрокових документів старого зразка;
living_address VARCHAR NULL: Фактична адреса проживання
замовника. Може відрізнятися від registration_address або бути
порожньою (NULL), якщо вона збігається або не надана;
Зв’язки між іншими таблицями:
Таблиця PersonCustomer має зв'язок «один-до-багатьох» з таблицею
Applicant
(Applicant.person_customer_id → PersonCustomer.id). Це означає, що один
замовник (фізична особа) може бути пов’язаний з багатьма абітурієнтами.
Зв'язок реалізовано через зовнішній ключ (FOREIGN KEY) person_customer_id
у таблиці Applicant. При видаленні запису з таблиці PersonCustomer, відповідні
поля person_customer_id у таблиці Applicant автоматично отримують значення
NULL (констрейнт ON DELETE SET NULL). Це гарантує, що абітурієнти не
будуть автоматично видалені при видаленні замовника, але втратять зв'язок з
ним.
Таблиця Applicant
482 ЧДТУ 252159 12 01
Рисунок 3.11 - Структура таблиці Applicant
Applicant – це центральна бізнес-таблиця програмного комплексу. Вона
зберігає повну інформацію про абітурієнта, включаючи його особисті дані,
навчальні атрибути, а також інформацію про пов’язаного замовника (фізичну
або юридичну особу). Поле active використовується для реалізації концепції
«м’якого видалення» (soft delete), що дозволяє приховувати записи замість їх
фізичного видалення.
Поля таблиці Applicant:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор абітурієнта;
first_name VARCHAR NOT NULL: Ім’я абітурієнта;
last_name VARCHAR NOT NULL: Прізвище абітурієнта;
patronymic VARCHAR NULL: По батькові абітурієнта. Може бути
порожнім (NULL);
482 ЧДТУ 252159 12 01
birth_date DATE NOT NULL: Дата народження абітурієнта. Це
обов’язкове поле, необхідне для валідації віку та формування
документів;
passport_series VARCHAR NOT NULL: Серія паспорта або іншого
документа, що посвідчує особу абітурієнта;
passport_number VARCHAR NOT NULL: Номер паспорта або іншого
ID-документа;
passport_issued_by VARCHAR NOT NULL: Орган, що видав паспорт;
passport_issued_date DATE NOT NULL: Дата видачі паспорта;
passport_expiry_date DATE NULL: Термін дії паспорта. Може бути
порожнім (NULL) для документів старого зразка без терміну дії;
taxpayer_code VARCHAR NOT NULL: Ідентифікаційний код
платника податків (ІПН) абітурієнта;
registration_address VARCHAR NOT NULL: Адреса реєстрації
(прописка) абітурієнта;
living_address VARCHAR NULL: Фактична адреса проживання.
Може відрізнятися від registration_address або бути порожньою
(NULL);
phone_number VARCHAR NOT NULL: Контактний номер телефону
абітурієнта;
email VARCHAR NOT NULL: Адреса електронної пошти
абітурієнта;
faculty VARCHAR NOT NULL: Назва факультету, на який вступає
абітурієнт. Це поле є дублем даних з довідкової таблиці Faculty для
оптимізації продуктивності при формуванні документів, щоб
уникнути зайвих JOIN-операцій;
faculty_id INTEGER NOT NULL: Зовнішній ключ (FOREIGN KEY)
на довідкову таблицю Faculty(id);
482 ЧДТУ 252159 12 01
degree VARCHAR NOT NULL: Назва ступеня вищої освіти
(наприклад, «Бакалавр», «Магістр»). Це дубльоване поле з
довідкової таблиці Degree;
degree_id INTEGER NOT NULL: Зовнішній ключ (FOREIGN KEY)
на довідкову таблицю Degree(id);
education_form VARCHAR NOT NULL: Форма навчання (наприклад,
«денна», «заочна»);
speciality VARCHAR NOT NULL: Назва спеціальності. Це
дубльоване поле з довідкової таблиці Specialization.
speciality_id INTEGER NOT NULL: Зовнішній ключ (FOREIGN
KEY) на довідкову таблицю Specialization(id);
educational_program VARCHAR NOT NULL: Назва освітньої
програми. Це дубльоване поле з довідкової таблиці
EducationalProgram;
educational_program_id INTEGER NOT NULL: Зовнішній ключ
(FOREIGN KEY) на довідкову таблицю EducationalProgram(id);
study_year INTEGER NOT NULL: Поточний курс навчання
абітурієнта (наприклад, 1, 2, 3 тощо);
admission_basis VARCHAR NOT NULL: Підстава вступу (наприклад,
'PZSO' – повна загальна середня освіта, 'SHORTENED' – скорочений
термін навчання, 'NORMATIVE' – на основі освітньо-
кваліфікаційного рівня, 'BACHELOR' – на основі бакалавра);
entry_date DATE NOT NULL: Дата фактичного вступу до
навчального
закладу (наприклад, «2024-09-01»);
admission_year INTEGER NOT NULL: Рік вступу до навчального
закладу
(наприклад, 2024);
482 ЧДТУ 252159 12 01
unzr_code VARCHAR NULL: Унікальний номер запису в реєстрі
(УНЗР), якщо використовується. Може бути NULL;
customer_type VARCHAR NOT NULL: Тип замовника, що визначає,
чи є замовник фізичною особою ('PERSON'), юридичною особою
('ORGANIZATION') або оплата здійснюється за рахунок бюджету
('BUDGET');
person_customer_id INTEGER NULL: Зовнішній ключ (FOREIGN
KEY) на таблицю PersonCustomer(id). Заповнюється тільки коли
customer_type = 'PERSON';
organization_customer_id INTEGER NULL: Зовнішній ключ
(FOREIGN KEY) на таблицю OrganizationCustomer(id).
Заповнюється тільки коли customer_type = 'ORGANIZATION';
active BOOLEAN NOT NULL DEFAULT TRUE: Позначка активності
запису. Якщо значення FALSE, профіль вважається «видаленим»
(soft delete), тобто він не відображається в основних списках, але
зберігається в базі даних для історії або відновлення.
Зв’язки між іншими таблицями:
FK(person_customer_id) → PersonCustomer(id): Зв'язок з таблицею
PersonCustomer, використовується, коли абітурієнт має фізичного
замовника. Якщо запис замовника фізичної особи видаляється,
відповідне поле person_customer_id у таблиці Applicant стає NULL
(ON DELETE SET NULL);
FK(organization_customer_id) → OrganizationCustomer(id): Зв'язок з
таблицею OrganizationCustomer, використовується, коли замовник є
юридичною особою. Якщо запис організації видаляється,
organization_customer_id у таблиці Applicant також стає NULL (ON
DELETE SET NULL);
FK(faculty_id) → Faculty(id): Зовнішній ключ до довідкової таблиці
Faculty, що забезпечує цілісність даних про факультет;
482 ЧДТУ 252159 12 01
FK(degree_id) → Degree(id): Зовнішній ключ до довідкової таблиці
Degree, що забезпечує цілісність даних про освітній ступінь;
FK(speciality_id) → Specialization(id): Зовнішній ключ до довідкової
таблиці Specialization, що забезпечує цілісність даних про
спеціальність;
FK(educational_program_id) → EducationalProgram(id): Зовнішній
ключ до довідкової таблиці EducationalProgram, що забезпечує
цілісність даних про освітню програму.
Поле active забезпечує реалізацію концепції Soft Delete, що дозволяє не
видаляти записи фізично, а лише позначати їх як неактивні. Це важливо для
збереження історії даних та можливості їх відновлення.
Таблиця OrganizationCustomer
Рисунок 3.12 - Структура таблиці OrganizationCustomer
Таблиця OrganizationCustomer містить дані про замовників-
юридичних осіб (компаній, установ, підприємств), які можуть бути стороною
договору на навчання для певних абітурієнтів. Використовується, коли в
профілі абітурієнта поле customer_type має значення 'ORGANIZATION'.
Поля таблиці OrganizationCustomer:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор запису
юридичної
482 ЧДТУ 252159 12 01
особи-замовника. Генерується автоматично;
name VARCHAR NOT NULL: Повна назва організації. Це поле є
обов’язковим;
address VARCHAR NOT NULL: Юридична адреса реєстрації
організації. Обов’язкове поле;
bank_details VARCHAR NULL: Банківські реквізити організації
(номер рахунку, МФО банку, назва банку тощо). Це поле може бути
порожнім (NULL), якщо дані не надано одразу;
edrpou_code VARCHAR NOT NULL UNIQUE: Унікальний код
ЄДРПОУ (Єдиний державний реєстр підприємств та організацій
України) організації. Обмеження UNIQUE гарантує, що два різні
записи не матимуть однакового коду, забезпечуючи унікальну
ідентифікацію юридичних осіб;
phone_number VARCHAR NULL: Контактний номер телефону
організації. Може бути NULL;
email VARCHAR NULL: Адреса електронної пошти організації.
Може бути NULL.
Зв’язки між іншими таблицями:
Таблиця OrganizationCustomer має зв'язок «один-до-багатьох»
(Applicant.organization_customer_id → OrganizationCustomer.id) з таблицею
Applicant. Це означає, що одна юридична особа може бути замовником для
багатьох абітурієнтів. Зв'язок реалізовано через зовнішній ключ
organization_customer_id у таблиці Applicant. При видаленні запису з
OrganizationCustomer, відповідні поля organization_customer_id у таблиці
Applicant отримують значення NULL, дозволяючи абітурієнту залишатися в
системі без прив'язки до вилученої організації.
Таблиця User
Таблиця User містить облікові записи всіх користувачів системи –
операторів та адміністраторів. Вона зберігає основні ідентифікаційні дані
482 ЧДТУ 252159 12 01
користувача, логін (username), пароль (password), а також, для операторів,
зв’язок із конкретним факультетом (faculty_id). Ця таблиця є основою для
реалізації системи безпеки на базі Spring Security та JWT.
Рисунок 3.13 - Структура таблиці User
Поля таблиці User:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор користувача;
first_name VARCHAR NOT NULL: Ім’я користувача.
Використовується для відображення в інтерфейсі користувача та в
журналі дій;
last_name VARCHAR NOT NULL: Прізвище користувача;
username VARCHAR NOT NULL UNIQUE: Унікальний логін для
входу в систему. Обмеження UNIQUE гарантує, що не буде двох
користувачів з однаковим логіном;
password VARCHAR NOT NULL: Захешований пароль користувача.
Для безпеки паролі зберігаються у хешованому вигляді (наприклад,
за допомогою алгоритму BCrypt), а не у відкритому тексті;
faculty_id INTEGER NULL: Зовнішній ключ (FOREIGN KEY) до
таблиці Faculty(id). Визначає, до якого факультету прив'язаний
оператор. Для адміністратора системи це поле може бути NULL,
оскільки адміністратори мають доступ до даних усіх факультетів.
Зв’язки між іншими таблицями:
482 ЧДТУ 252159 12 01
FK(faculty_id) → Faculty(id): Зв'язок із довідковою таблицею
факультетів. Якщо оператор прикріплений до конкретного
факультету (тобто faculty_id не NULL), цей зовнішній ключ гарантує,
що при логіні цей оператор бачитиме лише абітурієнтів, пов’язаних
з його факультетом, реалізуючи принцип розмежування доступу;
при видаленні запису з таблиці User, всі записи у зв'язуючій таблиці
UsersRoles, що посилаються на цей user_id, видаляються
автоматично (констрейнт ON DELETE CASCADE). Це забезпечує
цілісність даних та автоматичне видалення ролей користувача при
його вилученні.
Таблиця Role
Рисунок 3.14 - Структура таблиці Role
Таблиця Role містить перелік всіх можливих ролей у системі
(наприклад, ROLE_ADMIN, ROLE_OPERATOR). Ці ролі використовуються
для реалізації механізмів контролю прав доступу та авторизації, визначаючи,
які дії дозволені конкретному користувачеві.
Поля таблиці Role:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор ролі.
Генерується автоматично;
name VARCHAR NOT NULL UNIQUE: Унікальна назва ролі.
Обмеження UNIQUE є критично важливим, щоб уникнути
плутанини між ролями (наприклад, "адмін" і "Адмін" не можуть
482 ЧДТУ 252159 12 01
співпадати, якщо система чутлива до регістру, або
забезпечуватимуть, що назви є унікальними незалежно від регістру).
Зв’язки між іншими таблицями:
UsersRoles.role_id → Role.id: Зовнішній ключ (FOREIGN KEY) у
таблиці UsersRoles посилається на Role.id. Цей зв'язок є частиною
реалізації схеми
«багато-до-багатьох» між користувачами та ролями, дозволяючи
одному користувачу мати кілька ролей одночасно, а одній ролі бути
призначеною багатьом користувачам.
Таблиця UsersRoles
Рисунок 3.15 - Структура таблиці UsersRoles
Таблиця UsersRoles є допоміжною таблицею, що реалізує зв’язок
«багато-до-багатьох» між таблицями User та Role. Кожен рядок у цій таблиці
означає, що певний користувач (user_id) має певну роль (role_id). Це дозволяє
гнучко призначати ролі користувачам, а також дозволяє кожній ролі бути
пов'язаною з багатьма користувачами.
Поля таблиці UsersRoles:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор рядка в цій
таблиці. Генерується автоматично;
user_id INTEGER NOT NULL: Зовнішній ключ (FOREIGN KEY) до
таблиці User(id). Вказує на користувача;
482 ЧДТУ 252159 12 01
role_id INTEGER NOT NULL: Зовнішній ключ (FOREIGN KEY) до
таблиці Role(id). Вказує на роль.
Обмеження:
UNIQUE(user_id, role_id): Це унікальне обмеження на комбінацію
полів user_id та role_id запобігає дублюванню записів, гарантуючи,
що один і той же користувач не може мати одну й ту ж роль двічі;
ON DELETE CASCADE на обох зовнішніх ключах: Забезпечує
цілісність даних та автоматичне управління зв'язками. Якщо запис
користувача (User) або запис ролі (Role) видаляється, всі відповідні
рядки в таблиці UsersRoles, що посилаються на видалений id,
видаляються автоматично.
Таблиця Payment
Рисунок 3.16 - Структура таблиці Payment
Таблиця Payment використовується як довідник тарифів на навчання.
Вона зберігає інформацію про вартість навчання, яка залежить від освітнього
ступеня, форми навчання та навчального року. Це дозволяє системі динамічно
розраховувати тарифи для різних категорій абітурієнтів.
Поля таблиці Payment:
id SERIAL PRIMARY KEY: Унікальний ідентифікатор рядка в
таблиці Payment. Генерується автоматично;
482 ЧДТУ 252159 12 01
degree VARCHAR NOT NULL: Назва освітнього ступеня (наприклад,
«Бакалавр», «Магістр»). Це поле є дублем даних з довідкової таблиці
Degree для спрощення запитів;
education_form VARCHAR NOT NULL: Форма навчання (наприклад,
«денна», «заочна»);
year INTEGER NOT NULL: Навчальний рік, до якого застосовується
тариф (наприклад, 2024);
price NUMERIC(12,2) NOT NULL: Вартість навчання (тариф) у
гривнях за рік. Тип NUMERIC(12,2) забезпечує точність зберігання
грошових значень
(до 12 цифр загалом, з 2 цифрами після коми).
Обмеження:
UNIQUE(degree, education_form, year): Це унікальне обмеження на
комбінацію полів degree, education_form та year забезпечує, що для
кожної унікальної комбінації ступеня, форми навчання та року буде
існувати не більше одного запису. Це гарантує, що для певних умов
завжди буде один і тільки один тариф.
Таблиця FlywaySchemaHistory
482 ЧДТУ 252159 12 01
Рисунок 3.17 - Структура таблиці FlywaySchemaHistory
Таблиця FlywaySchemaHistory є системною таблицею, яка
створюється та управляється інструментом міграцій бази даних Flyway. Вона
відстежує всі виконані міграції схеми бази даних (SQL-скрипти або Java-
класи), їхній порядок, версію, статус виконання та інші метадані. Ця таблиця
не використовується безпосередньо в бізнес-логіці програмного комплексу,
але є абсолютно необхідною для автоматизованого управління версіями схеми
БД, забезпечення її консистентності та відтворюваності розгортання.
Поля таблиці FlywaySchemaHistory:
installed_rank INTEGER PRIMARY KEY: Порядковий номер
виконаного скрипта міграції. Це натуральне число, яке визначає
порядок застосування міграцій;
version VARCHAR NULL: Версія міграції. Зазвичай це серія цифр,
що відображає унікальну версію схеми після застосування міграції.
Може бути NULL для повторюваних скриптів (repeatable migrations);
description VARCHAR NOT NULL: Короткий опис міграції
(наприклад, «create_applicant_table», «add_index_to_user_username»);
type VARCHAR NOT NULL: Тип міграції (зазвичай 'SQL' для SQL-
скриптів або 'JDBC' для Java-класів);
script VARCHAR NOT NULL: Ім’я файлу скрипта міграції або назва
Java-класу;
checksum INTEGER NULL: Контрольна сума скрипта. Служить для
виявлення випадкових або несанкціонованих змін у скрипті після
його першого виконання, допомагаючи уникнути розбіжностей у
середовищах;
installed_by VARCHAR NOT NULL: Ім’я користувача бази даних, від
імені якого виконувалася міграція;
482 ЧДТУ 252159 12 01
installed_on TIMESTAMP NOT NULL: Дата та час виконання
міграції;
execution_time INTEGER NOT NULL: Час виконання міграції в
мілісекундах;
success BOOLEAN NOT NULL: Позначка успіху (TRUE) або
помилки (FALSE) під час виконання міграції. Це поле дозволяє
Flyway відстежувати стан міграцій та запобігати повторному
виконанню невдалих або успішних скриптів.
3.1.5 Розробка інтерфейсу користувача
Розробка інтерфейсу користувача (UI) – один із ключових етапів
створення інформаційної системи. Інтерфейс забезпечує зв’язок оператора або
адміністратора із програмно-технічним забезпеченням (рисунки 3.18-3.31),
тому його зручність, прозорість і передбачуваність мають вирішальне
значення для ефективності роботи системи.
Форма авторизації
Форма авторизації повинна бути максимально простою та зрозумілою.
Вона складається з двох полів та однієї кнопки, містить валідацію та обробку
помилок:
поле «Ім’я користувача» і «Пароль» позначені однаково, UX-
принцип: «Match between system and the real world» (Нільсен [56]);
валідація активується після натискання «Вхід». Якщо дані не
заповнені, під полями з’являються червоні підказки. Це відповідає
принципу «Error prevention»;
у разі невдалої авторизації з’являється текст під кнопкою «Спроба
логіну невдала». Це забезпечує певну прозорість: користувач бачить
482 ЧДТУ 252159 12 01
причину невдачі й може виправити дані (або повторити спробу
пізніше).
Рисунок 3.18 - Форма авторизації користувача
Рисунок 3.19 - Форма авторизацїі при помилковому введенні паролю
482 ЧДТУ 252159 12 01
Після успішної авторизації JWT зберігається у localStorage, а користувач
перенаправляється на головну сторінку додатку. Якщо ж користувач повторно
відкриває застосунок і в локальному сховищі вже є дійсний токен,
авторизаційна форма автоматично пропускається.
Головний екран – список абітурієнтів
Рисунок 3.20 - Головна сторінка після авторизації
Після входу користувач переходить до екрану, де відображається
ApplicantListComponent — табличний компонент, побудований за допомогою
AG-Grid. Важливі аспекти:
Відображення даних
1 Як тільки компонент завантажується, метод loadApplicants() запитує
у сервісу ApplicantService.getAllActiveApplicants() список активних
абітурієнтів.
2 Якщо роль користувача — «Оператор», на бекенді фільтрація за
faculty_id, тому компонент отримує лише записи свого факультету.
3 Якщо роль — «Адміністратор», getAllActiveApplicants() повертає всі
факультети. Тому адміністратор бачить увесь перелік.
Структрура таблиці абітурієтів
1 Перша колонка — нумерація з чекбоксом для вибору одного чи
кількох записів.
482 ЧДТУ 252159 12 01
2 Інші колонки містять інформацію про студента (ПІБ, факультет,
спеціальність, освітня програма тощо). Доступне сортування та
пошук в таблиці (потрібно клікнути на певну колонку двічі або один
раз). Варто зазначити, що у таблиці відображені усі “active” записи
вже попередньо відфільтрованих на сервері.
3 Відповідь сервера містить лише ті апліканти, у яких active = true.
Рисунок 3.21 - Відображення таблиці абітурієнтів на головній сторінці
додатка
Кнопки дій на головній сторінці
Після успішного входу користувачу (оператору чи адміністратору)
система відразу відображає перелік абітурієнтів. Угорі, у шапці (“Header”),
розташований набір кнопок, які дають змогу виконувати основні операції над
записами.
Рисунок 3.22 - Кнопки дій для користувача з роллю оператора
Для оператора
Додати студента (зелена кнопка)
1 При натисканні відкривається модальне вікно з формою “Додавання
студента”.
482 ЧДТУ 252159 12 01
Редагувати запис (жовта кнопка)
1 Стає активною лише після того, як оператор у таблиці обере певного
студента або декількох студентів.
2 Відкривається майже та ж сама форма, що й на додавання студента,
але уже з попередньо заповненими даними вибраного студента.
Сформувати документ (синя кнопка)
1 Доступна тоді, коли обрано хоча б одного студента (чекбокс у
таблиці).
2 При натисканні відкривається модальне вікно “Виберіть документи”.
Вийти (червона кнопка)
1 Завжди доступна (“Вийти” з системи).
2 При натисканні видаляє JWT зі сховища браузера і повертає на
форму входу.
Зображення користувача та назва факультету
1 Праворуч від кнопок відображається кругла іконка (аватарка) з
силуетом, біля якої показано скорочену назву факультету
(наприклад, “ФІТІС”).
2 Назва факультету визначається під час аутентифікації й береться з
токену (поле faculty_id). Це дає оператору зрозуміти, з яким
факультетом він зараз працює.
Для адміністратора
Рисунок 3.23 - Кнопки дій для користувача з роллю адміністратор
Усі ті самі кнопки, що й у оператора, плюс одна додаткова:
Видалити студента (червона кнопка)
482 ЧДТУ 252159 12 01
1 Доступна лише адміністратору і стає активною, коли хоча б один
рядок у таблиці позначено.
2 При натисканні відкривається підтверджувальний діалог.
Рисунок 3.24 - Форма підтвердження видалення студентів
Якщо адміністратор підтверджує, відправляється запит DELETE
/api/applicants?ids=[...]. Після успіху в таблиці зникають видалені записи.
У випадку адміністратора назва факультету не відображається, оскільки
він має доступ відразу до всіх записів без прив’язки до одного факультету.
Форма додавання студента
482 ЧДТУ 252159 12 01
Рисунок 3.25 - Форма додавання студента з обраним типом замовникаа
“Фізична особа”
Форма відкривається як модальне вікно поверх основного списку
абітурієнтів. У верхній частині розташовано поле для введення 13-значного
штрихкоду паспорта з додатку «Дія» та дві кнопки: «Надіслати запит до Дії»
і «Вставити дані студента». Спочатку активна лише кнопка «Надіслати запит
до Дії»; якщо відповідь від «Дії» знайдена успішно, друга кнопка стає
доступною й одним натисканням підтягує збережені у «Дії» дані (ПІБ, дату
народження, контакти, адресу, паспортні дані тощо) у відповідні поля форми.
Якщо ж інформації у «Дії» нема або запит не вдався, оператор продовжує
заповнювати всі поля вручну.
Блок «Студент»
Нижче від інтеграції з «Дією» йде набір полів, у якому обов’язковими є:
прізвище, Ім’я та Дата народження;
номер телефону та Електронна пошта;
адреса реєстрації (тільки текстове поле) і поле «Дійсний до» для
паспорта;
серія та Номер паспорта, «Ким виданий» і «Коли виданий»;
482 ЧДТУ 252159 12 01
ІПН (РНОКПП);
вибір із випадаючих списків: Факультет, Освітній ступінь,
Спеціальність, Освітня програма, Форма навчання, Курс, Вступ на
основі та Початок навчання.
Необов’язковими залишаються «По батькові», «Фактична адреса»
(з’являється окремим полем, якщо вона відрізняється від реєстрації) і «УНЗР»
(ID-картки), а також «Курс» й «Початок навчання» з календарем.
Після вибору факультету у списку спеціальностей одразу
відображаються лише ті напрями, що належать до цього факультету, а коли
оператор обирає певну спеціальність — підтягуються відповідні освітні
програми. Це зменшує число варіантів і робить заповнення інтуїтивнішим.
Розділ “Замовник”
Під усіма полями студента розміщується умовний блок із заголовком
“Замовник (поля не потрібно заповнювати, якщо студент повнолітній і сам є
замовником)”.
Вибір типу замовника
Нижче наведено три можливі варіанти:
фізична особа;
юридична особа;
бюджет.
Залежно від вибору під кнопками з’являються відповідні поля для
заповнення.
Коли обрано “Фізична особа”
482 ЧДТУ 252159 12 01
Рисунок 3.26 - Обраний тип замовника “Фізична особа”
Відразу після вибору цього пункту з’являється форма з такими полями
(навпроти кожного вказано, чи його необхідно заповнювати обов’язково чи
ні):
прізвище – обов’язкове;
ім’я – обов’язкове;
по батькові – необов’язкове;
дата народження – обов’язкове;
номер телефону – обов’язкове;
електронна пошта – обов’язкове;
адреса реєстрації місця проживання – обов’язкове;
фактична адреса проживання – необов’язкове (заповнюється у
випадку лише якщо вона відрізняється від адреси реєстрації);
назва документа (наприклад, “паспорт” або “ID-картка”) –
обов’язкове;
серія документа – необов’язкове (якщо у документі є серія);
номер документа – обов’язкове;
ким виданий – обов’язкове;
коли виданий – обов’язкове (дата);
дійсний до – обов’язкове (дата);
482 ЧДТУ 252159 12 01
ІПН (10 цифр) – обов’язкове.
Механізм автозаповнення полів даними існуючого замовника
(фізичної особи)
Коли оператор повністю введе прізвище та ім’я, спрацьовує
автозаповнення — Angular робить GET /api/person-
customers/search?lastName=<…>&firstName = <…>.
Якщо у відповіді приходить перелік існуючих записів, вони
відображаються під полями як підказки у вигляді «ПІБ (дата народження)»;
вибір зі списку миттєво заповнює решту полів (паспортні дані, контакти,
адресу та ін.). Якщо жодної фізичної особи не знайдено, оператор заповнює
всі поля вручну.
Рисунок 3.27 - Відображення існуючого замовника
Коли обрано “Юридична особа”
Рисунок 3.28 - Обраний тип замовника “Юридична особа”
482 ЧДТУ 252159 12 01
У цьому разі формується інша група полів. Перелік даних та їх статус
заповнення:
найменування організації – обов’язкове;
юридична адреса – обов’язкове;
номер телефону – обов’язкове;
електронна пошта – обов’язкове;
банківські реквізити (рахунок у форматі IBAN) – обов’язкове;
код ЄДРПОУ – обов’язкове.
Механізм автозаповнення полів даними існуючого замовника
(юридичної особи)
Коли оператор ввів код ЄДРПОУ, Angular надсилає запит GET
/api/organization-customers/search?edrpou=<код>
Якщо сервер повертає список існуючих організацій, під формою
відображаються підказки у вигляді «Назва організації – код ЄДРПОУ». Вибір
одного з елементів списку автоматично заповнює всі необхідні поля. Якщо
підказок немає, дані вводяться вручну.
Коли обрано “Бюджет”
У цьому разі жодні поля замовника не відображаються, адже платником
виступає держава.
Валідація полів у формі
Усі поля, позначені червоною зірочкою, валідуються на рівні клієнта:
пусте обов’язкове поле підсвічується червоним, Email перевіряється за
допомогою регулярного виразу, телефон підпадає під маску +380…, ІПН
мусить містити рівно 10 цифр (на бекенді також ж перевірка коректності
даних) тощо. Якщо оператор натискає «Зберегти» з помилками, під
відповідним елементом з’являється повідомлення «Поле обов’язкове» або
«Невірний формат», і відправка даних блокується доти, доки помилки не
усунуті.
Кнопки дій у формі
482 ЧДТУ 252159 12 01
«Зберегти» (зелена кнопка)
Після натискання система перевіряє всі обов’язкові поля (якщо хоча б
одне з них порожнє або невірно заповнене, під відповідним інпутом
з’являється червоний текст із повідомленням «Поле обов’язкове» або
«Невірний формат»). Якщо валідація пройшла успішно, Angular надсилає
запит на додавання студент.
Після успішного збереження модальне вікно закривається, а таблиця
оновлюється, показуючи внесені правки.
«Скасувати» (червона кнопка)
Коли натискає оператор, усі зміни, які були внесені вручну після
відкриття форми, відкидаються. Модальне вікно просто закривається, не
надсилаючи жодних запитів до сервера.
Хрестик у заголовку
Виконує таку саму дію, як «Скасувати»: закриває модальне вікно без
збереження змін.
Форма «Редагування студента»
Після вибору існуючого запису студента (натискання на рядок таблиці
та кнопку «Редагувати запис») відкривається модальне вікно, у якому
відображається приблизно та сама структура полів, що й у формі створення.
Головна відмінність — усі поля вже заповнені поточними даними абітурієнта
та його замовника (якщо замовник був вказаний під час додавання).
Рисунок 3.29 - Форма редагування даних студента
482 ЧДТУ 252159 12 01
Генерація документів
Коли оператор або адміністратор вибирає в таблиці одного чи кількох
студентів і натискає кнопку «Сформувати документ», над основною областю
відображається невелике модальне вікно, що дозволяє вибрати необхідні
шаблони. У верхній частині діалогу розміщено заголовок «Виберіть
документи» – він чітко інформує користувача про те, що зараз відбувається.
Нижче під ним ‒ група чекбоксів із назвами доступних шаблонів: «Контракт»,
«Заява на укладання договору», «Згода одержувача освітньої послуги»,
«Договір про навчання у закладі вищої освіти». Перший чекбокс «Обрати всі»
автоматично відмічає або знімає всі інші позначки.
Як тільки оператор відмічає потрібні шаблони та натискає кнопку
«Згенерувати» (синя, розташована внизу вікна), модальне діалогове вікно
закривається і відбувається запит до бекенду.
На боці бекенду відбувається наступне:
Перевіряється, чи існує такий студент. Якщо якийсь запис виявився
неактивним або взагалі не знайдений, він ігнорується без зупинки загальної
роботи (в консолі буде виведено помилку).
Для кожного дійсного студентського запису програма бере певні дані
(ПІБ, факультет, спеціальність, реквізити замовника тощо) та завантажує
обраний шаблон (DOCX-файл із ресурсів); у шаблоні на місці плейсхолдерів
на кшталт #FullName, #Faculty та ін. уставляються реальні значення,
використовуючи бібліотеку docx4j.
Отриманий документ «набивається» даними й зберігається у тимчасовій
папці на сервері з унікальною назвою (наприклад,
Contract_Petrenchenko_Oleksiy_06-06-2025_14-22.docx).
Після того, як усі помічені комбінації «студент і шаблон» оброблено,
сервер повертає клієнту їх у вигляді одного чи декількох файлів. Якщо
відмічено лише один файл, Angular автоматично ініціює завантаження цього
482 ЧДТУ 252159 12 01
єдиного DOCX: браузер показує стандартне вікно збереження. Якщо шаблонів
або студентів було декілька, генеруються одразу всі DOCX-файли, і кожен із
них миттєво «падає» у папку завантажень користувача.
У процесі завантаження у верхньому правому куті браузера з’являється
невеликі сповіщення “Done” про кожен DOCX-файл (наприклад,
«Contract_Petrenchenko_Oleksiy_06-06-2025_14-39.docx – 15,7 КБ – Done»).
Якщо ж у сервісі виникла помилка (наприклад, не знайдено даних для
одного зі студентів, або внутрішня помилка при роботі з docx4j), клієнт не
отримує жодних файлів.
Рисунок 3.30 - Модальне вікно «Виберіть документи» з чекбоксами для
вибору шаблонів.
Рисунок 3.31 - Індикація завантаження згенерованих DOCX-файлів у
браузері (сповіщення у вигляді «toast»).
Таким чином, інтерфейс генерації документів вирізняється наступним:
482 ЧДТУ 252159 12 01
миттєве відкриття зрозумілого списку доступних шаблонів без
переходу на іншу сторінку;
чекбокс «Обрати всі» для зручності, коли потрібно видати один і той
самий набір документів одразу кільком студентам;
одночасна генерація кількох файлів із вбудованими даними та
автоматичне завантаження без додаткових підтверджень, що знижує
кількість зайвих кліків;
зрозумілі сповіщення у браузері, які підтверджують успішне
збереження кожного DOCX.
Завдяки такому підходу оператор чи адміністратор витрачає мінімальну
кількість часу на випуск необхідної юридичної документації: достатньо лише
відзначити студентів і позначити шаблони, решту про себе виконує система.
Інтерфейс адміністратора
Права адміністратора розширюють інтерфейс оператора:
кнопка «Видалити студента». Доступна лише для адміністраторів.
Натискання викликає підтверджувальне модальне вікно «Ви
впевнені, що хочете видалити вибраних заявників?» з кнопками
«Видалити» (червона) та «Скасувати» (сірого кольору). Якщо
адміністратор підтверджує, відправляється DELETE-запит до
/api/applicants/{id};
перегляд і редагування записів усіх факультетів. Адміністратор не
обмежений у фільтрації за факультетом: таблиця одразу показує
записи з усією бази. При відкритті форми «Редагувати студента»
адміністратор може змінити значення поля «Факультет» та інші
поля, які для оператора заблоковані;
у шапці інформація про факультет відсутня, оскільки адміністратор
має глобальний доступ.
3.1.6 Опис розробки програмних компонентів
482 ЧДТУ 252159 12 01
Загалом бекенд і фронтенд побудовані у вигляді окремих модулів, кожен
із яких виконує певну роль і взаємодіє з іншими через чітко визначені
інтерфейси.
Бекенд
Spring Boot-програма (DeanofficeRecruitmentBackendApplication)
ініціалізує контекст, підключається до бази даних PostgreSQL і запускає
вбудований Tomcat.
Конфігурація безпеки
При запуску завантажується фільтр JWT (JwtAuthenticationFilter), який
перевіряє кожен вхідний запит (за винятком /api/auth/login). Фільтр бере
заголовок Authorization: Bearer <token>, розшифровує JWT, перевіряє його
дійсність і термін дії, а потім встановлює аутентифікованого користувача
(об’єкт UsernamePasswordAuthenticationToken) у контекст безпеки.
AuthenticationController обробляє POST-запити на /api/auth/login,
отримує ім’я користувача й пароль у тілі запиту, передає їх у
AuthenticationServiceImpl. Якщо аутентифікація успішна, сервіс повертає
згенерований JWT із роллю(ми) користувача та часом дії.
Сутності _user і role відповідають таблицям у БД: _user: id, first_name,
last_name, username, password, faculty_id і role: id, name. Зв’язок між ними
реалізовано через таблицю users_roles: user_id, role_id.
DeanofficeDataController слухає /api/degrees, /api/faculties і /api/
specializations. Для кожного запиту виконується метод у
DeanofficeDataService, котрий у свою чергу надсилає REST-запит до
зовнішнього сервісу деканату.
ApplicantController приймає запити на /api/applicants.
1 GET /api/applicants повертає всі активні записи абітурієнтів; якщо
роль користувача ― «Оператор», фільтрує лише тих, хто належить
до його факультету; якщо «Адмін» ― повертає всі.
2 GET /api/applicants/{id} повертає деталі одного абітурієнта.
482 ЧДТУ 252159 12 01
3 POST /api/applicants спочатку валідує JWT, потім обробляє вхідний
DTO. Якщо customerType == «PERSON», перевіряє personCustomerId
або створює нового PersonCustomer через PersonCustomerService.
Аналогічно для «ORGANIZATION». Для «BUDGET» поле
замовника ігнорується. Після заповнення всіх полів формується
новий Applicant, встановлюються createdAt = now(), isActive = true, і
викликається ApplicantService.addApplicant(applicant).
4 PUT /api/applicants/{id} виконує аналогічну перевірку наявності
замовника чи створює нового, оновлює поля абітурієнта й викликає
ApplicantService.updateApplicant(applicant).
5 DELETE /api/applicants/{id} не видаляє запис із БД повністю, а
змінює в полі isActive на false (soft-delete).
Методи у PersonCustomerController доступні за /api/person-
customers/search (GET із параметрами lastName і firstName) для
автозаповнення полів фізичної особи і /api/person-customers/{id} для
отримання повного запису. Аналогічно OrganizationCustomerController
реалізує /api/organization-customers/search? edrpou=<…> і
/api/organization-customers/{id}. Послідовність така: якщо оператор вводить
прізвище та ім’я, Angular робить GET-запит до /api/person-customers/search, а
сервер повертає усі збіги. Вибір із цього списку заповнює форму.
PaymentService обгортає PaymentRepository (сутність Payment). За
викликом getAllPayments(year, degree, educationForm) повертається вартість за
поточний рік і форму навчання; ця інформація використовується при
формуванні та заповненні сум у документах.
Генерація документів у DOCX
ContractApplicationController слухає GET /api/application-
contract/{applicantId}. Він викликає
ContractApplicationService.createAgreement, який:
482 ЧДТУ 252159 12 01
отримує Applicant за applicantService.getApplicantById(applicantId).
Якщо запис не знайдено, кидає помилку;
завантажує шаблон DOCX через
DocumentIOService.getTemplate("dir/ ContractApplication.docx");
викликає
DocumentTemplateFillerService.fillTemplateWithApplicantData(
template, applicant, specialization) для заміни плейсхолдерів у XML
DOCX: створює карту Map<String, String> placeholders, заповнює всі
теги (ім’я, прізвище, ІПН, факультет, дані замовника, тарифні дані) і
виконує пошук і заміну всередині template.getMainDocumentPart();
формує унікальну назву файлу ("ContractApplication_" + transliterate
(applicant.getLastName() + "_" + applicant.getFirstName()) + " " + дата-
час);
викликає DocumentIOService.saveDocumentToTemp(template,
fileName, File FormatEnum.DOCX) → у java.io.tmpdir зберігає
результат як DOCX.
DocumentIOService має метод getTemplate(String path), де path – шлях
всередині src/main/resources/docs/templates/, і метод saveDocumentToTemp,
який, залежно від FileFormatEnum, або зберігає DOCX, або в PDF. У нашому
випадку - ми зберігаємо все в DOCX.
DocumentTemplateFillerService відповідає за конкретну логіку побудови
карти плейсхолдерів:
зчитує із Applicant і Specialization необхідні поля (ПІБ, дата
народження, адреси, паспортні дані тощо);
обчислює дати початку й кінця навчання (getStudyEndYear(...),
getStudyEndMonth(...));
перебирає всі об’єкти Text у документі та виконує заміну
text.setValue(text.getValue().replace(key, value)).
482 ЧДТУ 252159 12 01
Крім цього, існують менш значущі компоненти для інших типів
документів, реалізовані аналогічно.
Фронтенд
У ролі клієнта використано Angular. Використано підхід модульного
структурування: є окремі модулі AuthModule, ApplicantModule,
DocumentModule.
При старті програми через main.ts завантажується AppModule, який
імпортує AppRoutingModule.
Маршрутизація (Router)
Єдина точка підстановки компонентів позначена тегом <router-outlet>.
Оскільки в цій версії UI не використовує бічного меню, після логіну
відображається компонент ApplicantListComponent.
Компонент LoginComponent містить шаблон з полями введення ім’я
користувача й пароль.
При відправці форми обробник викликає authenticationService.
login(username, password); вдалий результат миттєво зберігає JWT у
localStorage і перенаправляє користувача на "/dashboard". Якщо помилка,
показується повідомлення під полем паролю.
Компонент ApplicantActionsComponent завжди фіксований угорі.
Праворуч розташовано кнопки дій (їхній набір залежить від ролі користувача):
“Додати студента”, “Редагувати запис”, “Сформувати документ”, “Вийти”.
Якщо роль “Адмін”, додається кнопка “Видалити студента”. Праворуч від
кнопок — іконка поточного користувача із назвою факультету користувача
(для оператора). Якщо роль “Адмін”, назва факультету відсутня, адже
адміністратор має доступ до всіх факультетів.
Компонент ApplicantListComponent
Після успішної авторизації одразу відбувається завантаження даних про
студентів, а саме йде виклик методу ApplicantService.getAllApplicants(); Якщо
авторизований користувач має роль “Оператор”, то завантажуються дані
482 ЧДТУ 252159 12 01
певного факультету студентів, а якщо роль “Адмін” - дані студентів з усіх
факультетів. Відповідь (список об’єктів ApplicantBaseDTO: id, lastName,
firstName, patronymic, faculty, specialty, educationalProgram, degree,
educationForm, admissionBasis, paymentType) показується у табличному
компоненті Angular Material Table. Перший стовпець — чекбокс, який
дозволяє позначити один або кілька рядків. Далі — список фіксованих
колонок: “№” (індекс), “Прізвище студента”, “Ім’я студента”, “По батькові
студента”, “Факультет”, “Спеціальність”, “Освітня програма”, “Освітній
ступінь”, “Форма навчання”, “Вступ на основі”, “Оплата”.
Над таблицею (у тому самому рядку, але зліва) розташовані кнопки дій
з того самого ApplicantActionsComponent. При натисненні “Додати студента”
відкривається модальне вікно з компонентом ApplicantFormComponent у
режимі “add” (шлях сторінки при цьому не змінюється). При виборі одного
запису й натисненні “Редагувати запис” відкривається те саме
ApplicantFormComponent, але в режимі “edit”, а його поля попередньо
заповнюються через ApplicantService. getApplicantById(id). Кнопка “Видалити
студента” (лише для адміна) надсилає DELETE /api/applicants/{ids} і після
успіху знову завантажує список. Кнопка “Сформувати документ” відображає
DocumentGenerateComponent (модальне вікно), у якому прапорцями можна
вибрати один або кілька шаблонів документів; при натисненні “Згенерувати”
формується POST запит до з тілом запиту. Сервер повертає сформовані
документи і відразу завантажує їх.
Компонент HomeComponent
Основний компонент інтерфейсу користувача, який слугує контейнером
для відображення та взаємодії з даними абітурієнтів. Він інтегрує два інших
ключових компоненти – ApplicantActionsComponent та
ApplicantListComponent – забезпечуючи злагоджену роботу функціоналу,
пов'язаного з управлінням абітурієнтами.
482 ЧДТУ 252159 12 01
Компонент ApplicantFormComponent одразу після відкриття запитує
через DeanofficeDataService довідкові дані: GET /api/degrees, /api/faculties,
/api/specializations.
У верхній частині форми є поле «Штрихкод паспорта у застосунку Дія
(13
цифр)» і дві кнопки: “Надіслати запит до Дії” та “Вставити дані студента”.
Якщо одразу у полі введено штрихкод, за натисканням “Надіслати запит до
Дії” Angular робить GET-запит до сервісу Дії, отримує JSON із переліком полів
(ПІБ, дата народження, адреса, паспортні дані тощо) і натисненням “Вставити
дані студента” заповнює відповідні поля усієї форми. Якщо даних немає або
помилка, оператор заповнює форму вручну.
Розділ "Студент" містить основні дані абітурієнта:
особисті дані: прізвище, ім’я, по батькові, дата народження, номер
телефону, електронна пошта;
адреси: адреса реєстрації, фактична адреса проживання (якщо
відрізняється);
паспортні дані: серія, номер, ким виданий, коли виданий, дійсний до,
УНЗР ID-картки, ІПН;
навчальні дані: факультет, освітній ступінь, спеціальність, освітня
програма (всі з бекенду деканату), форма навчання, курс (від 1 до 4),
вступ на основі, початок навчання.
Блок "Замовник":
Цей блок з'являється, якщо абітурієнт неповнолітній або має замовника.
Містить три радіокнопки: "Фізична особа", "Юридична особа", "Бюджет".
"Фізична особа": При виборі з'являється форма для введення даних
фізичної особи. Під час введення прізвища або імені, Angular робить GET-
запит до /api/person-customers/search для пошуку існуючих замовників.
Знайдені варіанти відображаються у випадаючому списку, вибір якого
482 ЧДТУ 252159 12 01
автоматично заповнює решту полів. Якщо збігів немає, поля заповнюються
вручну.
"Юридична особа": При виборі з'являється форма для введення даних
юридичної особи. Після введення коду ЄДРПОУ та натискання Enter, Angular
надсилає GET-запит до /api/organization-customers/search?edrpou=<…>.
Знайдені компанії відображаються у списку, вибір якого заповнює форму.
Якщо збігів немає,
поля заповнюються вручну.
"Бюджет": При виборі цього варіанту всі поля блоку "Замовник"
залишаються порожніми.
Збереження даних або скасування:
Для того, щоб зберегти введенні дані при додаванні студента або
редагуванні, то потрібно натиснути кнопку “Зберегти”. Якщо помилок немає,
то запит проходить успішно і на клієнт повертається оновлений список
студентів.
Якщо необхідно скасувати зміни або зовсім не зберігати введені дані, то
варто натиснути на “хрести” у формі або на кнопку “Скасувати”. У результаті
нічого не збережеться, зміни не застосуються і форма просто закриється.
Валідація форми
Якщо форма неповна або містить невалідні дані (наприклад,
неправильний формат електронної пошти), відповідне поля засвітиться
червоним і кнопка “Зберегти” буде недоступною.
Компонент ApplicantCreateComponent
Cлугує обгорткою для форми додавання нового абітурієнта. Він
відповідає за ініціалізацію, керування станом модального вікна, інтеграцію з
сервісом "Дія" для автоматичного заповнення даних, а також за взаємодію з
основною формою абітурієнта (ApplicantFormComponent).
ApplicantCreateComponent відображається як повноекранне модальне
вікно, що забезпечує максимальний простір для заповнення форми.
482 ЧДТУ 252159 12 01
Потік даних та взаємодія:
ApplicantCreateComponent виступає як контролер для ApplicantForm
Component.
1 Ініціалізує ApplicantFormComponent у режимі додавання.
2 Надає функціонал для автоматичного заповнення форми через
"Дію".
3 Відстежує стан валідації ApplicantFormComponent (через подію
formChanged), щоб керувати доступністю кнопки "Зберегти".
4 Ініціює процес збереження даних (виклик onSubmit()), коли основна
форма валідна та користувач натискає "Зберегти".
Компонент ApplicantEditComponent є модальним вікном,
призначеним для редагування існуючих даних абітурієнта. Він працює як
обгортка для ApplicantFormComponent, забезпечуючи попереднє заповнення
форми даними абітурієнта та керування процесом збереження оновленої
інформації.
ApplicantEditComponent надає користувачам можливість переглядати та
змінювати деталі профілю абітурієнта в зручному модальному інтерфейсі, з
фокусом на валідації та збереженні змін.
Як і ApplicantCreateComponent, цей компонент відображається як
повноекранне модальне вікно, забезпечуючи достатньо простору для взаємодії
з формою.
Відмінності від ApplicantCreateComponent:
призначення: ApplicantEditComponent сфокусований на оновленні
існуючих даних, тоді як ApplicantCreateComponent – на створенні
нових;
передача даних: ApplicantEditComponent приймає об'єкт
applicantData для попереднього заповнення форми, тоді як
ApplicantCreateComponent починає з порожньої форми;
482 ЧДТУ 252159 12 01
інтеграція з "Дія": ApplicantEditComponent не містить блоку
інтеграції з "Дія", оскільки дані вже існують і в основному
редагуються, а не вводяться з нуля;
умова для кнопки "Зберегти": Кнопка "Зберегти" в
ApplicantEditComponent активна лише за наявності isFormChanged,
тоді як у ApplicantCreateComponent вона залежить від загальної
валідності форми (isFormValid). Це відображає різницю в логіці: для
редагування важливо, чи були внесені саме зміни, для створення – чи
заповнені всі обов'язкові поля.
Компонент DocumentGenerateComponent
Цей компонент відкривається як модальне вікно для формування
документів.
Інтерфейс: Відображає список чекбоксів з назвами шаблонів документів
(наприклад, Контракт, Заява на укладення договору). Присутній чекбокс
"Обрати всі" для вибору усіх документів відразу.
Кнопки керування: "Згенерувати" та "Скасувати".
Генерація документів: При натисканні "Згенерувати", компонент
виконує POST запит із тілом, що містить ідентифікатори обраних абітурієнтів,
обрані шаблони. Сервер повертає масив файлів у форматі DOCX (або один
DOCX), які автоматично завантажуються браузером на пристрій користувача.
Особливості адмінського інтерфейсу
Адмінська версія інтерфейсу має розширені можливості:
кнопка "Видалити студента": У заголовку з'являється додаткова
кнопка. Після вибору одного або кількох абітурієнтів у списку та
натискання цієї кнопки, для кожного позначеного рядка
надсилається DELETE /api/applicants/{ids}, після чого таблиця
абітурієнтів оновлюється;
482 ЧДТУ 252159 12 01
доступ до факультетів: У формі додавання/редагування
ApplicantFormComponent, адміністратору доступні всі факультети
без фільтрації. Оператор же бачить лише свій факультет і не може
змінювати поле факультету у формі.
3.2 Тестування системи
Цей розділ описує процес тестування розробленої інформаційної
системи для автоматизованого формування юридичних документів
абітурієнтів ЧДТУ. Мета тестування — переконатися, що всі компоненти
додатку (бекенд, фронтенд) виконують свої функції коректно та відповідно до
вимог. Тестування проводиться на чотирьох рівнях: модульному,
інтеграційному, системному та приймальному. Кожен рівень передбачає
власні цілі, об’єкти та методи перевірки.
3.2.1 Модульне тестування
Модульне тестування перевіряє окремі одиниці коду в ізоляції від решти
системи, що дозволяє виявити дефекти на раніших стадіях розробки та
гарантувати стабільність кожного компонента перед їхньою інтеграцією.
У проєкті було виконано модульні тести для ключових бекенд-сервісів і
фронтенд-компонентів.
Усі фронтенд-тести успішно проходять у середовищі, що демонструє
коректну взаємодію компонентів із сервісами та реактивними формами.
Результати відображено в таблиці.
Таблиця 3.1
Результати модульного тестування фронтенд-компонентів
Компонент Сценарій Що перевіряємо Результат
482 ЧДТУ 252159 12 01
ApplicantListComp ngOnInit Завантаження списку Успішно
onent абітурієнтів при
ініціалізації компонента
HomeComponent handleGenerateDoc Виклик Успішно
ument() FileService.downloadFile(
)
ApplicantFormCom Ініціалізація форми Форма невалідна при Успішно
ponent порожніх полях
ApplicantCreateDial Submit valid data Заповнення полів і Успішно
ogComponent відправка даних у сервіс
ApplicantEditDialog Load and edit Завантаження поточних Успішно
Component даних, відстеження змін і
виклик updateApplicant()
Усі бекенд-тести проходять успішно, бізнес-логіка сервісів працює
відповідно до вимог. Результати відображено в таблиці.
Таблиця 3.2
Результати модульного тестування бекенд-сервісів
Сервіс Метод Що перевіряємо Результат
ApplicantService addApplicant() Додавання нового Успішно
абітурієнта
getApplicantById() Пошук абітурієнта за Успішно
ID
482 ЧДТУ 252159 12 01
getAllActiveApplicant Повернення списку Успішно
sWithCustomerData() активних абітурієнтів з
даними замовників
deleteApplicants() Видалення абітурієнтів Успішно
за списком ID
OrganizationCusto searchByName() Пошук організацій за Успішно
merService назвою
addOrganizationCusto Додавання нової Успішно
mer() організації
updateOrganizationCu Оновлення даних Успішно
stomer() організації
PersonCustomerSer searchExistingCustom Пошук замовника за Успішно
vice ers() ПІБ
addPersonCustomer() Додавання нового Успішно
замовника
updatePersonCustomer Оновлення даних Успішно
() замовника
Продовження таблиці 3.2
ContractApplication createAgreement() Генерація .docx файлу Успішно
Service угоди
DocumentTemplate fillTemplateWithAppli Заповнення шаблону Успішно
FillerService cantData() DOCX даними
абітурієнта
482 ЧДТУ 252159 12 01
3.2.2 Інтеграційне тестування
Інтеграційне тестування перевіряє взаємодію між компонентами
системи — від REST-контролера до збереження чи читання даних у базі —
задля виявлення помилок у комунікації модулів та гарантування їхньої
сумісності в цілому.
У проєкті інтеграційні тести реалізовано для ключових контролерів і
сервісів, із повним підняттям контексту Spring Boot та використанням in-
memory H2 для ізольованих баз даних [57].
Інструменти й підходи
1 MockMvc для емуляції HTTP-запитів до REST-контролерів без
старту зовнішнього сервера.
2 @SpringBootTest(webEnvironment = RANDOM_PORT) із
TestRestTemplate для реальних HTTP-запитів проти піднятого
сервера.
3 H2 In-Memory як ізольована база даних, налаштована через
application-test.properties.
Етапи виконання інтеграційних тестів:
ініціалізація контексту Spring Boot з H2 і завантаження тестових
даних.
виклик REST-ендпоїнтів відповідних контролерів через MockMvc
або TestRestTemplate.
перевірка HTTP-статусів і структури JSON-відповідей.
валідація змін у базі даних через виклик репозиторіїв.
Таблиця 3.3
Інтеграційні тести ключових компонентів
Контролер / Сервіс Ендпоїнт / Метод Що перевіряєм Результат тесту
482 ЧДТУ 252159 12 01
ApplicantController GET Повернення Успішно
/api/applicants/{id} даних повертається 200
абітурієнта за ID OK + JSON
POST /api/applicants Створення Успішно
нового створюється запис
абітурієнта у БД
OrganizationCusto GET Пошук Успішно
merController /api/organization- організацій за повертається
customers/search?nam назвою список JSON
e=
PersonCustomerCon GET /api/person- Пошук фізосіб за Успішно
troller customers/search?last ПІБ повертається
Name=&firstName= список JSON
ContractApplication GET /api/application- Генерація .docx Повертає файл
Controller contract/{id} файлу контракту 200 OK + docx
PersonalDataConse GET Генерація .docx Повертає файл
ntController /api/personal-data- файлу згоди на 200 OK + docx
consent/{id} обробку ПДН
StudyAgreementCo GET /api/study- Генерація .docx Повертає файл
ntroller agreement/{id} файлу угоди 200 OK + docx
навчання
Усі інтеграційні тести виконані успішно, підтверджуючи коректну
роботу
REST-шарів, здатність обробляти запити, генерувати документи та
взаємодіяти з базою даних.
482 ЧДТУ 252159 12 01
3.2.3 Системне тестування
Системне тестування — це інструмент перевірки повної
функціональності та працездатності інтегрованої інформаційної системи в
цілому перед її передачею кінцевим користувачам. На відміну від модульного
та інтеграційного тестування, тут оцінюється поведінка системи «ззовні»
(black-box testing) при різних сценаріях використання, включно з
функціональними, нефункціональними (навантаження, безпека) та
інтерфейсними перевірками.
У проєкті системне тестування проводилося за допомогою Postman як
основного інструмента для е2е-тестів API. Було створено колекцію запитів,
яка імітує реальні бізнес-процеси: реєстрація абітурієнта, пошук та оновлення
даних, генерація документів і завантаження результатів. Для кожного запиту
налаштовано перевірки (assertions) статусів та структури відповіді (JSON-
schema, HTTP-headers), а також запускалися сценарії з різними вхідними
даними та зовнішніми залежностями (наприклад, імітація викликів Diia API та
DeanOffice API).
Ключові кроки системного тестування із Postman:
імпорт колекції ендпоїнтів і налаштування змінних середовища
(baseUrl, токени);
виконання сценаріїв у Runner або Newman для послідовності запитів;
перевірка коректності HTTP-статусів, структури даних і заголовків;
оцінка продуктивності при серії запитів із різним навантаженням
(через Collection Runner).
Таблиця 3.4
Результати системного тестування
Ендпоїнт / Сценарій Опис тесту Очікуваний результат Фактичний
результат
482 ЧДТУ 252159 12 01
Продовження таблиці 3.4
POST /api/applicants Створення HTTP 201 Created, Відповідає
нового об’єкт з ID та полями очікування
абітурієнта через м
повну форму
GET Отримання HTTP 200 OK, JSON із Відповідає
/api/applicants/{id} раніше правильними полями очікування
створеного м
абітурієнта
PUT Оновлення даних HTTP 200 OK, Відповідає
/api/applicants/{id} абітурієнта повернено оновлені очікування
дані м
DELETE Видалення групи HTTP 200 OK Відповідає
/api/applicants?ids=[…] абітурієнтів очікування
м
GET /api/organization- Пошук HTTP 200 OK, масив Відповідає
customers/search?name організацій за перевірених DTO очікування
= назвою м
GET /api/person- Пошук фізичних HTTP 200 OK, масив Відповідає
customers/search?lastN осіб за перевірених DTO очікування
ame=…&firstName=… прізвищем та м
ім’ям
GET /api/application- Генерація HTTP 200 OK, Content- Файл
contract/{id} контракту DOCX Type: успішно
application/vnd.openxml повернено
482 ЧДТУ 252159 12 01
formats
Продовження таблиці 3.4
GET Генерація згоди HTTP 200 OK, Файл успішно
/api/personal-data- на обробку Content-Type: повернено
consent/{id} персональних application/vnd.op
даних DOCX enxmlformats
GET /api/study- Генерація HTTP 200 OK, Файл успішно
agreement/{id} договору Content-Type: повернено
навчання DOCX application/vnd.op
enxmlformats
3.2.4 Приймальне тестування
Приймальне тестування виконується організацією, що відповідає за
інсталяцію, супровід програмної системи та навчання кінцевого користувача.
У рамках цього етапу перевірялися всі ключові бізнес-сценарії через веб-
інтерфейс та інструменти розробника:
Таблиця 3.5
Підсумки приймального тестування
Сценарій Що перевіряли Результат
Авторизація HTTP-заголовок Працює коректно
Authorization, розбір JWT
через jwt.io
482 ЧДТУ 252159 12 01
CRUD-операції зі Додавання, редагування, Працює коректно
студентом видалення через UI +
Network-запити
Продовження таблиці 3.5
Пошук та фільтрація Фільтрація, сортування, Працює коректно
пагінація
Генерація документів GET-запити - HTTP 200 + Працює коректно
Content-Type,
форматування DOCX
Логування та зберігання Console без помилок, Працює коректно
збереження токену у
Storage
3.3 Приклади впровадження програмного комплексу
У цьому підрозділі наведено практичні приклади використання
розробленого веб-додатку в реальних умовах, а також описано інструкцію
користувача й методологічні підходи, що лежать в основі процесу
впровадження та супроводу (рисунки 3.32 -3.38).
Інтерфейс користувача
При відкритті головної сторінки системи користувач бачить список
абітурієнтів із можливістю фільтрації, сортування та пошуком. Далі наведено
кілька послідовних рисунків із певними поясненнями:
482 ЧДТУ 252159 12 01
Рисунок 3.32 - Вхід у програму
Рисунок 3.33 - Головна сторінка програми
482 ЧДТУ 252159 12 01
Рисунок 3.34 - Форма додавання нового абітурієнта з усіма обов’язковими й
необов’язковими полями
Рисунок 3.35 - Форма редагування даних існуючого студента, включно з
вибраним замовником
482 ЧДТУ 252159 12 01
Рисунок 3.36 - Форма формування документів з можливістю обрати різні
шаблони
Рисунок 3.37 - Завантажені сформовані шаблони документів
482 ЧДТУ 252159 12 01
Рисунок 3.38 - Приклад відкритого DOCX-файлу з автоматично заповненими
полями.
482 ЧДТУ 252159 12 01
Інструкція користувача
Вхід – на сторінці входу вказати логін та пароль, далі натиснути «Вхід».
Додати студента – “Додати студента”, заповнити форму та натиснути
«Зберегти».
Пошук або фільтрація – ввести текст у поле над таблицею для фільтрації,
клікнути заголовок колонки для сортування.
Редагувати дані студента – біля запису натиснути «Редагувати запис»,
змінити дані у модальному вікні та натиснути «Зберегти» (або “Скасувати”
якщо потрібно).
Видалити (доступно лише адміну) – обрати студента або декількох
студентів, натиснути «Видалити» і підтвердити дію.
Генерувати документ – натиснути кнопку “Сформувати документ”, у
модальному вікні обрати тип документа або декілька типів документів, далі
натиснути “Згенерувати”. У результаті відбудеться автоматичне завантаження
обраних шаблонів у форматі DOCX.
Вийти – натиснути іконку профілю → «Вийти».
Гнучкі методології розробки
Під час впровадження проекту використовувалась адаптована Scrum-
модель: робочий об’єм розбито на двотижневі спринти, на початку кожного з
яких визначалися ключові завдання, а наприкінці — проводився демо-огляд і
ретроспектива. Застосовано Test-Driven Development для критичних
компонентів (сервісів і шаблонізаторів документів), що забезпечило високий
рівень покриття юніт- і інтеграційних тестів. Моделювання функціональних
вимог виконано за допомогою UML-діаграм кейсів використання та класів, що
спростило комунікацію між розробниками та замовником.
Хмарні технології
Для хостингу додатку обрано універсальний підхід із використанням
Cloud-ресурсів: додаток розгорнуто в контейнері Docker, що працює в
кластері Kubernetes у приватному OpenStack. База даних PostgreSQL
482 ЧДТУ 252159 12 01
розміщена на окремому вузлі з резервним копіюванням. Використані практики
Infrastructure as Code (Terraform) і логування через ELK-стек, що дозволило
оперативно реагувати на критичні події та масштабувати систему.
Розробка веб-сервісів
Процес створення REST-API поділено на стадії:
аналіз ринку — вивчення подібних систем для вступників та пошук
можливостей вдосконалення;
прототипування — макети UI було намальовано вручну на
звичайних листках та обговорено детально під час розробки;
R&D і проектування БД — вибір архітектури додатку на Spring
Boot і
Серверне веб-програмування
Клієнтська частина побудована на HTML5, CSS3 (SCSS),
JavaScript/TypeScript, Angular Material. Серверна — на Java 17 із Spring Security
(JWT-автентифікація), Spring Data JPA (ORM) і docx4j для роботи з DOCX-
шаблонами. Використано MVC-архітектуру, завдяки чому легко розділити
відповідальність і підтримувати код.
Інтеграція інформаційних потоків
Для синхронізації даних абітурієнтів та отримання папортних даних
реалізовано через REST API:
DeanOffice API — отримання списку факультетів, спеціальностей,
освітніх програм;
Diia API — імпорт та валідація паспортних даних.
482 ЧДТУ 252159 12 01
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У цьому розділі було проведено всебічне тестування розробленої
інформаційної системи для автоматизації документообігу абітурієнтів.
Завдяки приймальному тестуванню, що охопило ключові бізнес-сценарії, а
також аналізу механізмів безпеки, вдалося підтвердити відповідність системи
заявленим функціональним та нефункціональним вимогам.
В рамках тестування було успішно перевірено повний цикл роботи
системи: від аутентифікації користувачів з різними ролями (оператор,
адміністратор) до збереження та обробки даних абітурієнтів та замовників.
Особливу увагу було приділено надійності механізму безпеки, який базується
на стандарті JSON Web Token (JWT). Всі операції з генерації, передачі та
валідації JWT виконувалися коректно, а політика CORS була налаштована
належним чином, забезпечуючи захищену взаємодію між клієнтською та
серверною частинами системи.
Проведені перевірки показали, що система стабільно функціонує під
навантаженням основних сценаріїв, демонструє бездоганну взаємодію між
клієнтом та сервером, а також має потенціал для подальшого масштабування
та розширення функціоналу. Таким чином, результати тестування дозволяють
рекомендувати інформаційну систему до впровадження в режимі пілотної
експлуатації з подальшим моніторингом її продуктивності та безпеки.
482 ЧДТУ 252159 12 01
ВИСНОВОК
У даній кваліфікаційній роботі було успішно розроблено та
імплементовано інноваційну веб-систему, що докорінно змінює підхід до
автоматизації формування документів для абітурієнтів у закладах вищої
освіти. Це не просто програмний продукт, а комплексне рішення,
спроектоване для вирішення нагальних викликів, пов'язаних з паперовим
документообігом та ручним введенням даних, що є частим явищем у вступних
кампаніях.
Була створена система, що базується на сучасних технологіях та
архітектурних патернах, що гарантує її надійність, безпеку та
масштабованість. Завдяки використанню Spring Boot на сервері та Angular для
клієнтської частини, програма пропонує інтуїтивно зрозумілий інтерфейс та
високу продуктивність. Центральним елементом є надійний механізм
управління користувачами та ролями з JWT-авторизацією, що забезпечує чітке
розмежування доступу та захист конфіденційних даних. Кожен оператор або
адміністратор працює в захищеному середовищі, де його дії контролюються
та відповідають його повноваженням.
Одним з найважливіших досягнень є повна автоматизація процесу
генерації документів. Система здатна генерувати різноманітні шаблони — від
контрактів та заяв до згод — з урахуванням усіх нюансів та індивідуальних
даних абітурієнтів. Це не тільки значно прискорює документообіг, але й
мінімізує ризики людських помилок, забезпечуючи точність та відповідність
нормативним вимогам.
Особлива увага була приділена інтеграції (із державним сервісом та з
деканатським сервісом ЧДТУ), такими як "Дія" та "DeanOffice". Це дозволяє
системі автоматично підтягувати особисті дані абітурієнтів та інформацію про
їхню попередню освіту, звільняючи співробітників приймальних комісій від
рутинної роботи з введення даних та перевірки їхньої достовірності.
Додатково, було реалізовано зручний пошуковий компонент для роботи із
482 ЧДТУ 252159 12 01
замовниками-організаціями, що дозволяє швидко знаходити компанії за кодом
ЄДРПОУ та автоматично заповнювати їхні реквізити.
Усі етапи розробки супроводжувалися ретельним тестуванням,
включаючи модульні та приймальні тести, що підтвердило бездоганну
відповідність системи всім функціональним та нефункціональним вимогам.
Програмний комплекс продемонстрував високу стабільність, коректність
взаємодії між компонентами та готовність до експлуатації в реальних умовах.
Завершуючи, можна констатувати, що розроблена веб-система є
цілісним та інноваційним рішенням, готовим до негайного впровадження у
практику закладів вищої освіти. Вона не лише автоматизує ключові процеси
документообігу, але й закладає міцний фундамент для подальшого розвитку
та розширення функціоналу.
Ця робота не лише демонструє глибокі знання у сфері розробки
програмного забезпечення, а й пропонує практичне рішення, здатне значно
покращити ефективність та прозорість вступної кампанії в українських
закладах вищої освіти.
482 ЧДТУ 252159 12 01
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Arion Research LLC. Automating data entry: saving time and reducing
errors with AI-powered OCR [Електронний ресурс]. Режим доступу:
https://www.arionresearch.com/blog/automating-data-entry-saving-time-
and-reducing-errors-with-ai-powered-ocr
2 DocRaptor. Why HTML to PDF is better than static PDF templates.
[Електронний ресурс]. Режим доступу:
https://docraptor.com/blog/why-html-to-pdf-is-better-than-static-pdf-
templates
3 New Relic. What is performance testing? [Електронний ресурс]. Режим
доступу: https://newrelic.com/resources/what-is-performance-testing
4 MuleSoft. What is API integration? [Електронний ресурс]. Режим
доступу: https://www.mulesoft.com/resources/api/what-is-api-
integration
5 Державна служба України з питань захисту персональних даних. Про
захист персональних даних [Електронний ресурс]. Режим доступу:
https://zakon.rada.gov.ua/laws/show/2297-17
6 GeeksforGeeks. SOLID Principles in Software Engineering.
[Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/solid-principles-in-software-engineering/
7 Martin, R. C. (2008). Clean Code: A Handbook of Agile Software
Craftsmanship. Prentice Hall.
8 Techopedia. KISS Principle. [Електронний ресурс]. Режим доступу:
https://www.techopedia.com/definition/26849/kiss-principle
9 Atlassian. What is technical debt? [Електронний ресурс]. Режим
доступу: https://www.atlassian.com/agile/software-
development/technical-debt
482 ЧДТУ 252159 12 01
10 Baeldung. Error Handling in Spring REST. [Електронний ресурс].
Режим доступу: https://www.baeldung.com/exception-handling-for-
rest-with-spring
11 IBM. Software testing. [Електронний ресурс]. Режим доступу:
https://www.ibm.com/topics/software-testing
12 Red Hat. What is CI/CD? [Електронний ресурс]. Режим доступу:
https://www.redhat.com/en/topics/devops/what-is-ci-cd
13 Splunk. What is log management? [Електронний ресурс]. Режим
доступу: https://www.splunk.com/en_us/data-insights/what-is-log-
management.html
14 Towards Data Science. What is dependency hell? [Електронний ресурс].
Режим доступу: https://towardsdatascience.com/what-is-dependency-
hell-2f2f7b4e8d3
15 Gartner. Optical Character Recognition (OCR). [Електронний ресурс].
Режим доступу: https://www.gartner.com/en/information-
technology/glossary/optical-character-recognition-ocr
16 Deloitte. Robotic Process Automation (RPA). [Електронний ресурс].
Режим доступу:
https://www2.deloitte.com/us/en/pages/finance/articles/robotics-process-
automation.html
17 Apache POI. [Електронний ресурс]. Режим доступу:
https://poi.apache.org/
18 docx4j. [Електронний ресурс]. Режим доступу:
https://www.docx4java.org/
19 Drools. [Електронний ресурс]. Режим доступу:
https://www.drools.org/
20 RabbitMQ. [Електронний ресурс]. Режим доступу:
https://www.rabbitmq.com/
482 ЧДТУ 252159 12 01
21 Apache Kafka. [Електронний ресурс]. Режим доступу:
https://kafka.apache.org/
22 Cloudflare. What is TLS? [Електронний ресурс]. Режим доступу:
https://www.cloudflare.com/learning/ssl/what-is-tls/
23 Okta. What is RBAC? [Електронний ресурс]. Режим доступу:
https://www.okta.com/identity-101/what-is-rbac/
24 OAuth. [Електронний ресурс]. Режим доступу: https://oauth.net/
25 SOLID Principles. [Електронний ресурс]. Режим доступу:
https://www.baeldung.com/solid-principles
26 Wikipedia. Don't repeat yourself. [Електронний ресурс]. Режим
доступу: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
27 Wikipedia. KISS principle. [Електронний ресурс]. Режим доступу:
https://en.wikipedia.org/wiki/KISS_principle
28 JUnit. [Електронний ресурс]. Режим доступу: https://junit.org/
29 Mockito. [Електронний ресурс]. Режим доступу:
https://site.mockito.org/
30 H2 Database. [Електронний ресурс]. Режим доступу:
https://www.h2database.com/html/main.html
31 Cypress. [Електронний ресурс]. Режим доступу:
https://www.cypress.io/
32 Jenkins. [Електронний ресурс]. Режим доступу:
https://www.jenkins.io/
33 GitLab CI/CD. [Електронний ресурс]. Режим доступу:
https://docs.gitlab.com/ee/ci/
34 GitHub Actions. [Електронний ресурс]. Режим доступу:
https://github.com/features/actions
35 Elastic. The ELK Stack. [Електронний ресурс]. Режим доступу:
https://www.elastic.co/what-is/elk-stack
482 ЧДТУ 252159 12 01
36 Prometheus. [Електронний ресурс]. Режим доступу:
https://prometheus.io/
37 Grafana. [Електронний ресурс]. Режим доступу: https://grafana.com/
38 Docker. [Електронний ресурс]. Режим доступу:
https://www.docker.com/
39 Kubernetes. [Електронний ресурс]. Режим доступу:
https://kubernetes.io/
40 Flyway. [Електронний ресурс]. Режим доступу: https://flywaydb.org/
41 Liquibase. [Електронний ресурс]. Режим доступу:
https://www.liquibase.com/
42 Technolutions. Slate. [Електронний ресурс]. Режим доступу:
https://technolutions.com/slate/
43 Liaison International. OpenApply. [Електронний ресурс]. Режим
доступу: https://www.openapply.com/
44 Методичні рекомендації з моделювання та проектування об’єктно-
орієнтованих систем [Електронний ресурс]. Режим доступу:
https://cz.chdtu.edu.ua/metodychni-rekomendacziyi-2/
45 Oracle. Java Platform, Standard Edition 17 [Електронний ресурс].
Режим доступу:
https://www.oracle.com/java/technologies/javase/jdk17-archive.html
46 Angular. Angular 16 Documentation [Електронний ресурс]. Режим
доступу: https://angular.io/docs
47 Spring Boot Documentation. Getting Started with Spring Boot
[Електронний ресурс]. Режим доступу: https://docs.spring.io/spring-
boot/docs/3.1.4/reference/html/
48 Angular. Angular 16 Documentation [Електронний ресурс]. Режим
доступу: https://angular.io/docs (Дублюється з [45], але залишимо для
послідовності, якщо це окреме посилання на Angular в контексті
фреймворку)
482 ЧДТУ 252159 12 01
49 Spring Security Documentation. [Електронний ресурс]. Режим
доступу: https://docs.spring.io/spring-security/reference/ (Офіційна
документація Spring Security)
50 docx4j. docx4j User Guide [Електронний ресурс]. Режим доступу:
https://www.docx4java.org/trac/docx4j
51 JWT IO. JSON Web Tokens Introduction [Електронний ресурс]. Режим
доступу: https://jwt.io/introduction/
52 ModelMapper. ModelMapper Official Site [Електронний ресурс].
Режим доступу: https://modelmapper.org/
53 PostgreSQL Global Development Group. PostgreSQL 15 Documentation
[Електронний ресурс]. Режим доступу:
https://www.postgresql.org/docs/15/
54 Git. About Version Control. [Електронний ресурс]. Режим доступу:
https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
55 AG Grid. [Електронний ресурс]. Режим доступу: https://www.ag-
grid.com/angular-data-grid/getting-started/
56 Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design.
Nielsen Norman Group. [Електронний ресурс]. Режим доступу:
https://www.nngroup.com/articles/ten-usability-heuristics/
57 H2 Database. [Електронний ресурс]. Режим доступу:
https://www.h2database.com/html/main.html
58 JWT IO. JSON Web Tokens Introduction. [Електронний ресурс].
Режим доступу: https://jwt.io/introduction/
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С. В.
482 ЧДТУ 252159 12 01
___________________________
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
ФОРМУВАННЯ ЮРИДИЧНИХ ДОКУМЕНТІВ ДЛЯ ВСТУПНИКІВ В
ЗАКЛАДИ ВИЩОЇ ОСВІТИ
Специфікація
482ЧДТУ252159.011
Листів 2
Розробник ________________ Макійчук А.В.
Керівник ________________ Заспа Г.О.
Н.Контроль ________________ Півень О.Б.
Черкаси 2025
Позначення Найменування Примітка
Документація
482 ЧДТУ 252159 12 01 Лістинг програми
482 ЧДТУ 252159 34 01 Інструкція користувача
482 ЧДТУ 252159 90 01 Графічні матеріали
482 ЧДТУ 252159 12 01
482 ЧДТУ 252159 12 01
ДОДАТОК Б
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
ФОРМУВАННЯ ЮРИДИЧНИХ ДОКУМЕНТІВ ДЛЯ ВСТУПНИКІВ В
ЗАКЛАДИ ВИЩОЇ ОСВІТИ
Лістинг програми
ЧДТУ 252159.011 ПЗ
Листів 17
Розробник ________________ Макійчук А.В.
Черкаси 2025
Бекенд
Файл ApplicantController
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.*;
import ua.edu.chdtu.recruitment.applicant.dto.ApplicantDTO;
import ua.edu.chdtu.recruitment.applicant.dto.ApplicantWriteDTO;
import ua.edu.chdtu.recruitment.shared.entity.Applicant;
import ua.edu.chdtu.recruitment.shared.entity.OrganizationCustomer;
import ua.edu.chdtu.recruitment.shared.entity.PersonCustomer;
import
ua.edu.chdtu.recruitment.shared.exception.OperationCannotBePerformedException;
import ua.edu.chdtu.recruitment.shared.exception.WrongRolesNumberException;
import ua.edu.chdtu.recruitment.shared.util.Mapper;
import javax.validation.Valid;
import java.util.List;
@RestController
@RequestMapping("/api/applicants")
@Validated
public class ApplicantController {
private final ApplicantService applicantService;
private final PersonCustomerService personCustomerService;
private final OrganizationCustomerService organizationCustomerService;
@Autowired
public ApplicantController(ApplicantService applicantService,
PersonCustomerService personCustomerService, OrganizationCustomerService
organizationCustomerService) {
this.applicantService = applicantService;
this.personCustomerService = personCustomerService;
this.organizationCustomerService = organizationCustomerService;
}
@GetMapping
public ResponseEntity<List<ApplicantDTO>> getAllActiveApplicants() throws
WrongRolesNumberException {
List<Applicant> applicants =
applicantService.getAllActiveApplicantsWithCustomerData();
List<ApplicantDTO> applicantDTOS = Mapper.map(applicants,
ApplicantDTO.class);
return ResponseEntity.ok(applicantDTOS);
482 ЧДТУ 252159 34 01
}
@GetMapping("/{applicantId}")
public ResponseEntity<ApplicantDTO> getApplicantById(@PathVariable Integer
applicantId) throws OperationCannotBePerformedException {
Applicant applicant = applicantService.getApplicantById(applicantId);
ApplicantDTO applicantDTO = Mapper.mapEntityToDTO(applicant,
ApplicantDTO.class);
return ResponseEntity.ok(applicantDTO);
}
@DeleteMapping
public ResponseEntity<Void> deleteApplicants(@RequestParam List<Integer>
ids) {
applicantService.deleteApplicants(ids);
return ResponseEntity.ok().build();
}
@PostMapping
public ResponseEntity addApplicant(@Valid @RequestBody ApplicantWriteDTO
applicantDTO) {
Applicant applicant = Mapper.mapDTOtoEntity(applicantDTO,
Applicant.class);
if (applicantDTO.getPersonCustomer() != null &&
applicantDTO.getOrganizationCustomer() != null)
return ResponseEntity.badRequest().body("Замовником не можуть бути
фізична особа та організація одночасно");
if (applicantDTO.getPersonCustomer() != null &&
applicantDTO.getPersonCustomerId() != null)
return ResponseEntity.badRequest().body("Не можна одночасно вказати
і personCustomerId, і personCustomer");
if (applicantDTO.getOrganizationCustomer() != null &&
applicantDTO.getOrganizationCustomerId() != null)
return ResponseEntity.badRequest().body("Не можна одночасно вказати
і organizationCustomerId, і organizationCustomer");
if (applicantDTO.getPersonCustomerId() != null) {
PersonCustomer existingCustomer =
personCustomerService.getById(applicantDTO.getPersonCustomerId());
if (existingCustomer == null)
return ResponseEntity.badRequest().body("Замовника з таким ID не
знайдено");
482 ЧДТУ 252159 34 01
applicant.setPersonCustomer(existingCustomer);
}
if (applicantDTO.getOrganizationCustomerId() != null) {
OrganizationCustomer existingCustomer =
organizationCustomerService.getById(applicantDTO.getOrganizationCustomerId());
if (existingCustomer == null)
return ResponseEntity.badRequest().body("Замовника з таким ID не
знайдено");
applicant.setOrganizationCustomer(existingCustomer);
}
Applicant newApplicant = applicantService.addApplicant(applicant);
return ResponseEntity.ok(newApplicant);
}
@PutMapping("/{applicantId}")
public ResponseEntity updateApplicant(@PathVariable int applicantId, @Valid
@RequestBody ApplicantDTO applicantDTO) throws OperationCannotBePerformedException {
Applicant applicant = Mapper.mapDTOtoEntity(applicantDTO,
Applicant.class);
if (applicantDTO.getPersonCustomer() != null &&
applicantDTO.getOrganizationCustomer() != null)
return ResponseEntity.badRequest().body("Замовником не можуть бути
фізична особа та організація одночасно");
applicant.setId(applicantId);
Applicant updatedApplicant =
applicantService.updateApplicant(applicant);
return ResponseEntity.ok(updatedApplicant);
}
}
Файл ApplicantService
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import ua.edu.chdtu.recruitment.shared.entity.Applicant;
import ua.edu.chdtu.recruitment.shared.entity.OrganizationCustomer;
import ua.edu.chdtu.recruitment.shared.entity.PersonCustomer;
import
ua.edu.chdtu.recruitment.shared.exception.OperationCannotBePerformedException;
482 ЧДТУ 252159 34 01
import ua.edu.chdtu.recruitment.shared.exception.WrongRolesNumberException;
import ua.edu.chdtu.recruitment.shared.repository.ApplicantRepository;
import
ua.edu.chdtu.recruitment.shared.repository.OrganizationCustomerRepository;
import ua.edu.chdtu.recruitment.shared.repository.PersonCustomerRepository;
import ua.edu.chdtu.recruitment.shared.util.FacultyUtil;
import java.util.ArrayList;
import java.util.List;
import java.util.Optional;
@Service
public class ApplicantService {
private final ApplicantRepository applicantRepository;
private final PersonCustomerRepository personCustomerRepository;
private final OrganizationCustomerRepository organizationCustomerRepository;
@Autowired
public ApplicantService(ApplicantRepository applicantRepository,
PersonCustomerRepository personCustomerRepository,
OrganizationCustomerRepository
organizationCustomerRepository, PersonCustomerService personCustomerService,
OrganizationCustomerService
organizationCustomerService) {
this.applicantRepository = applicantRepository;
this.personCustomerRepository = personCustomerRepository;
this.organizationCustomerRepository = organizationCustomerRepository;
}
public List<Applicant> getAllActiveApplicantsWithCustomerData() throws
WrongRolesNumberException {
String role = FacultyUtil.getUserRole();
if (role.equals("ROLE_ADMIN")) {
return applicantRepository.findAllActiveWithCustomerData();
}
else if (role.equals("ROLE_OPERATOR")) {
String facultyId = FacultyUtil.getUserFacultyId();
return
applicantRepository.findAllActiveByFacultyIdWithCustomerData(facultyId);
}
return new ArrayList<>();
}
@Transactional
482 ЧДТУ 252159 34 01
public Applicant addApplicant(Applicant applicant) {
return applicantRepository.save(applicant);
}
public void deleteApplicants(List<Integer> ids) {
applicantRepository.deleteByIds(ids);
}
public Applicant getApplicantById(Integer applicantId) throws
OperationCannotBePerformedException {
Optional<Applicant> applicantOptional =
applicantRepository.findById(Math.toIntExact(applicantId));
if (applicantOptional.isPresent()) {
return applicantOptional.get();
} else {
throw new OperationCannotBePerformedException("Такого студента не
знайдено");
}
}
@Transactional
public Applicant updateApplicant(Applicant applicant) throws
OperationCannotBePerformedException {
if (!applicantRepository.existsById(applicant.getId())) {
throw new OperationCannotBePerformedException("Студента з таким id не
знайдено: " + applicant.getId());
}
return applicantRepository.save(applicant);
}
public Object getCustomerDataByApplicantId(Integer applicantId) throws
OperationCannotBePerformedException {
Applicant applicant = getApplicantById(applicantId);
if (applicant != null) {
if (applicant.getPersonCustomer() != null) {
int personCustomerId = applicant.getPersonCustomer().getId();
return
personCustomerRepository.findById(personCustomerId).orElse(null);
} else if (applicant.getOrganizationCustomer() != null) {
int organizationCustomerId =
applicant.getOrganizationCustomer().getId();
return
organizationCustomerRepository.findById(organizationCustomerId).orElse(null);
}
}
return null;
482 ЧДТУ 252159 34 01
}
}
Файл OrganizationCustomerController
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import ua.edu.chdtu.recruitment.applicant.dto.OrganizationCustomerDTO;
import ua.edu.chdtu.recruitment.shared.entity.OrganizationCustomer;
import ua.edu.chdtu.recruitment.shared.util.Mapper;
import java.util.Collections;
import java.util.List;
@RestController
@RequestMapping("/api/organization-customers")
public class OrganizationCustomerController {
private final OrganizationCustomerService organizationCustomerService;
@Autowired
public OrganizationCustomerController(OrganizationCustomerService
organizationCustomerService) {
this.organizationCustomerService = organizationCustomerService;
}
@GetMapping("/search")
public ResponseEntity<List<OrganizationCustomerDTO>>
searchOrganizationCustomer(
@RequestParam Long edrpouCode
) {
try {
List<OrganizationCustomer> organizationCustomers =
Collections.singletonList(organizationCustomerService.getByEdrpouCode(edrpouCode));
List<OrganizationCustomerDTO> organizationCustomerDTOS =
Mapper.map(organizationCustomers, OrganizationCustomerDTO.class);
return ResponseEntity.ok(organizationCustomerDTOS);
}
catch (RuntimeException exception) {
return ResponseEntity.notFound().build();
}
}
482 ЧДТУ 252159 34 01
}
Файл OrganizationCustomerService
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import ua.edu.chdtu.recruitment.shared.entity.OrganizationCustomer;
import
ua.edu.chdtu.recruitment.shared.repository.OrganizationCustomerRepository;
@Service
public class OrganizationCustomerService {
@Autowired
private OrganizationCustomerRepository organizationCustomerRepository;
public OrganizationCustomer getById(int id) {
return organizationCustomerRepository.findById(id).orElseThrow(() -> new
RuntimeException("Organization customer with ID " + id + " not found"));
}
public OrganizationCustomer addOrganizationCustomer(OrganizationCustomer
organizationCustomer) {
return organizationCustomerRepository.save(organizationCustomer);
}
public OrganizationCustomer updateOrganizationCustomer(int
organizationCustomerId, OrganizationCustomer organizationCustomerData) {
OrganizationCustomer organizationCustomer =
organizationCustomerRepository.findById(Math.toIntExact(organizationCustomerId))
.orElseThrow(() -> new RuntimeException("Organization customer
not found"));
organizationCustomer.setName(organizationCustomerData.getName());
organizationCustomer.setAddress(organizationCustomerData.getAddress());
organizationCustomer.setBankDetails(organizationCustomerData.getBankDetails());
organizationCustomer.setEdrpouCode(organizationCustomerData.getEdrpouCode());
organizationCustomer.setPhoneNumber(organizationCustomerData.getPhoneNumber());
organizationCustomer.setEmail(organizationCustomerData.getEmail());
return organizationCustomerRepository.save(organizationCustomer);
}
482 ЧДТУ 252159 34 01
public OrganizationCustomer getByEdrpouCode(Long edrpouCode) {
return organizationCustomerRepository.findByEdrpouCode(edrpouCode)
.orElseThrow(() -> new RuntimeException("Організація з ЄДРПОУ "
+ edrpouCode + " не знайдена"));
}
public OrganizationCustomer
updateOrAddOrganizationCustomer(OrganizationCustomer organizationCustomer) {
if (organizationCustomer.getId() != 0) {
return updateOrganizationCustomer(organizationCustomer.getId(),
organizationCustomer);
} else {
return addOrganizationCustomer(organizationCustomer);
}
}
}
Файл PersonCustomerController
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import ua.edu.chdtu.recruitment.applicant.dto.PersonCustomerDTO;
import ua.edu.chdtu.recruitment.shared.entity.PersonCustomer;
import ua.edu.chdtu.recruitment.shared.util.Mapper;
import java.util.List;
@RestController
@RequestMapping("/api/person-customers")
public class PersonCustomerController {
private final PersonCustomerService personCustomerService;
@Autowired
public PersonCustomerController(PersonCustomerService personCustomerService)
{
this.personCustomerService = personCustomerService;
}
@GetMapping("/search")
public ResponseEntity<List<PersonCustomerDTO>> searchPersonCustomer(
@RequestParam String lastName,
482 ЧДТУ 252159 34 01
@RequestParam(required = false) String firstName
) {
List<PersonCustomer> personCustomers =
personCustomerService.searchExistingCustomers(lastName, firstName);
List<PersonCustomerDTO> personCustomerDTOS = Mapper.map(personCustomers,
PersonCustomerDTO.class);
return ResponseEntity.ok(personCustomerDTOS);
}
}
Файл PersonCustomerService
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import ua.edu.chdtu.recruitment.shared.entity.PersonCustomer;
import ua.edu.chdtu.recruitment.shared.repository.PersonCustomerRepository;
import java.util.List;
@Service
public class PersonCustomerService {
@Autowired
private PersonCustomerRepository personCustomerRepository;
public PersonCustomer getById(int id) {
return personCustomerRepository.findById(id).orElseThrow(() -> new
RuntimeException("Person customer with ID " + id + " not found"));
}
public PersonCustomer addPersonCustomer(PersonCustomer personCustomer) {
return personCustomerRepository.save(personCustomer);
}
public PersonCustomer updatePersonCustomer(int personCustomerId,
PersonCustomer personCustomerData) {
PersonCustomer personCustomer =
personCustomerRepository.findById(Math.toIntExact(personCustomerId))
.orElseThrow(() -> new RuntimeException("Person customer not
found"));
personCustomer.setFirstName(personCustomerData.getFirstName());
personCustomer.setLastName(personCustomerData.getLastName());
personCustomer.setPatronymic(personCustomerData.getPatronymic());
personCustomer.setBirthDate(personCustomerData.getBirthDate());
personCustomer.setPhoneNumber(personCustomerData.getPhoneNumber());
482 ЧДТУ 252159 34 01
personCustomer.setEmail(personCustomerData.getEmail());
personCustomer.setRegistrationAddress(personCustomerData.getRegistrationAddress());
personCustomer.setLivingAddress(personCustomerData.getLivingAddress());
personCustomer.setTaxpayerCode(personCustomerData.getTaxpayerCode());
personCustomer.setDocumentName(personCustomerData.getDocumentName());
personCustomer.setDocumentSeries(personCustomerData.getDocumentSeries());
personCustomer.setDocumentNumber(personCustomerData.getDocumentNumber());
personCustomer.setDocumentIssuedDate(personCustomerData.getDocumentIssuedDate());
personCustomer.setDocumentIssuedBy(personCustomerData.getDocumentIssuedBy());
personCustomer.setDocumentExpiryDate(personCustomerData.getDocumentExpiryDate());
return personCustomerRepository.save(personCustomer);
}
public PersonCustomer updateOrAddPersonCustomer(PersonCustomer
personCustomer) {
if (personCustomer.getId() != 0) {
return updatePersonCustomer(personCustomer.getId(), personCustomer);
} else {
return addPersonCustomer(personCustomer);
}
}
public List<PersonCustomer> searchExistingCustomers(String lastName, String
firstName) {
return personCustomerRepository.findByLastNameAndFirstName(lastName,
firstName);
}
}
Файл PaymentService
package ua.edu.chdtu.recruitment.applicant;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import ua.edu.chdtu.recruitment.shared.entity.EDegree;
import ua.edu.chdtu.recruitment.shared.entity.EEducationForm;
import ua.edu.chdtu.recruitment.shared.entity.Payment;
import ua.edu.chdtu.recruitment.shared.repository.PaymentRepository;
482 ЧДТУ 252159 34 01
@Service
public class PaymentService {
@Autowired
private PaymentRepository paymentRepository;
public Payment getAllPayments(int year, EDegree degree, EEducationForm
educationForm) {
return paymentRepository.findAllByYearDegreeAndEducationForm(year,
degree, educationForm);
}
}
Фронтенд
Файл applicant-list.component.ts
import {Component, EventEmitter, Input, OnInit, Output} from '@angular/core';
import { ApplicantService } from 'src/services/applicant.service';
import { ColDef, GridApi, ColumnApi, AgGridEvent } from 'ag-grid-community';
@Component({
selector: 'app-applicant-list',
template: `
<ag-grid-angular
style="width: 100%; height: 680px;"
class="ag-theme-quartz"
[rowData]="applicants"
[columnDefs]="columnDefs"
[defaultColDef]="defaultColDef"
[rowSelection]="rowSelection"
[animateRows]="true"
(gridReady)="onGridReady($event)"
(selectionChanged)="onSelectionChanged($event)"
>
</ag-grid-angular>
`,
styleUrls: ['./applicant-list.component.sass'],
})
export class ApplicantListComponent implements OnInit {
@Input() selectedApplicantIds: number[] = [];
@Output() selectionChanged = new EventEmitter<number[]>();
private gridApi!: GridApi;
public applicants: any[] = [];
public rowSelection: 'multiple' | 'single' = 'multiple';
public columnDefs: ColDef[] = [
{
headerName: '№',
482 ЧДТУ 252159 34 01
valueGetter: "node.rowIndex + 1",
width: 25,
checkboxSelection: true,
headerCheckboxSelection: true,
headerCheckboxSelectionFilteredOnly: false,
pinned: 'left',
sortable: false,
filter: false
},
{headerName: 'Прізвище\nстудента', field: 'lastName', sortable: true, filter:
true},
{headerName: 'Ім\'я студента', field: 'firstName', sortable: true, filter:
true},
{headerName: 'По батькові\nстудента', field: 'patronymic', sortable: true,
filter: true},
{headerName: 'Факультет', field: 'faculty', sortable: true, filter: true},
{
headerName: 'Спеціальність',
field: '',
sortable: true,
filter: true,
valueGetter: (params) => {
const specialityCode = params.data.specialityCode;
const speciality = params.data.speciality;
return `${specialityCode} ${speciality}`;
}
},
{headerName: 'Освітня програма', field: 'educationalProgram', sortable: true,
filter: true},
{headerName: 'Освітній\nступінь', field: 'degree', sortable: true, filter:
true},
{headerName: 'Форма навчання', field: 'educationForm', sortable: true,
filter: true},
{headerName: 'Вступ на основі', field: 'admissionBasis', sortable: true,
filter: true, valueFormatter: this.translateAdmissionBasis},
{headerName: 'Оплата', field: 'customerType', sortable: true, filter: true,
valueFormatter: this.translateCustomerType}
];
public defaultColDef: ColDef = {
flex: 1,
minWidth: 100,
wrapText: true,
autoHeight: true,
resizable: true,
sortable: true,
filter: true
};
482 ЧДТУ 252159 34 01
constructor(private applicantService: ApplicantService) {
}
ngOnInit() {
this.loadApplicants();
this.applicantService.dataChanged.subscribe(() => {
this.loadApplicants();
});
}
loadApplicants() {
this.applicantService.getAllApplicants().subscribe(
(data: any) => {
if (Array.isArray(data)) {
this.applicants = data;
} else {
console.error('Data is not an array:', data);
}
}
);
}
onGridReady(params: { api: GridApi; columnApi: ColumnApi }) {
this.gridApi = params.api;
this.gridApi.sizeColumnsToFit();
}
onSelectionChanged(event: AgGridEvent) {
const selectedRows: any[] = event.api.getSelectedRows();
const newSelectedIds = selectedRows.map((row) => row.id);
this.selectionChanged.emit(newSelectedIds);
}
translateCustomerType(params: any): string {
const customerType = params.value;
switch (customerType) {
case 'BUDGET':
return 'бюджет';
case 'PERSON':
return 'фізична особа';
case 'ORGANIZATION':
return 'організація';
default:
return customerType;
}
}
482 ЧДТУ 252159 34 01
translateAdmissionBasis(params: any): string {
const admissionBasis = params.value;
switch (admissionBasis) {
case 'PZSO':
return 'ПЗСО';
case 'SHORTENED':
return 'Скорочена';
case 'NORMATIVE':
return 'Норматив';
case 'BACHELOR':
return 'Бакалавр';
default:
return admissionBasis;
}
}
}
Файл applicant-actions-component.html
A<div class="nav">
<button type="button" class="btn btn-success" (click)="addApplicant()">Додати
студента</button>
<button type="button" class="btn btn-danger" [disabled]="!isSingleSelection &&
!isMultipleSelection" (click)="deleteApplicant()" *ngIf="isAdmin">Видалити
студента</button>
<button type="button" class="btn btn-warning" [disabled]="!isSingleSelection"
(click)="editApplicant(selectedApplicantIds[0])">Редагувати запис</button>
<button type="button" class="btn btn-primary" [disabled]="!isSingleSelection &&
!isMultipleSelection" (click)="openDocumentSelectionDialog()">Сформувати
документ</button>
<button type="button" class="btn btn-danger" (click)="logout()">Вийти</button>
<img *ngIf="isLoggedIn" src="../../assets/images/user-icon.svg" alt="user
icon" width="38" height="38">
<span *ngIf="!isAdmin">{{ facultyAbbr }}</span>
</div>
Файл applicant-actions-component.ts
import { Component, EventEmitter, Input, Output, OnInit } from '@angular/core';
import { BsModalService } from 'ngx-bootstrap/modal';
import { ApplicantEditDialogComponent } from '../applicant-edit-dialog/applicant-
edit-dialog.component';
import { ApplicantCreateDialogComponent } from '../applicant-create-
dialog/applicant-create-dialog.component';
import { DocumentSelectionDialogComponent } from '../document-selection-
dialog/document-selection-dialog.component';
import { AuthenticationService } from
"../../services/auth/authentication.service";
482 ЧДТУ 252159 34 01
import { Faculty } from "../../models/faculty";
@Component({
selector: 'app-applicant-actions',
templateUrl: './applicant-actions.component.html',
styleUrls: ['./applicant-actions.component.sass']
})
export class ApplicantActionsComponent implements OnInit {
@Input() selectedApplicantIds: number[] = [];
@Output() onEditApplicant = new EventEmitter<number[]>();
@Output() onDeleteApplicant = new EventEmitter<void>();
@Output() onGenerateDocument = new EventEmitter<any>();
isLoggedIn: boolean = false;
isAdmin: boolean = false;
isOperator: boolean = false;
facultyAbbr: string | null = '';
constructor(
private modalService: BsModalService,
private authService: AuthenticationService,
) {}
ngOnInit() {
this.authService.isLoggedIn.subscribe(isLoggedIn => {
this.isLoggedIn = isLoggedIn;
});
this.isAdmin = this.authService.getUserRole() === 'ROLE_ADMIN';
this.isOperator = this.authService.getUserRole() === 'ROLE_OPERATOR';
this.authService.facultiesProvider.subscribe((faculties: Faculty[]) => {
if (faculties.length > 0 && !this.isAdmin && this.isOperator) {
this.facultyAbbr = faculties[0].abbr;
this.authService.setFacultyAbbr(faculties[0].abbr);
}
});
this.authService.getFacultiesBasedOnRole();
}
get isSingleSelection(): boolean {
return this.selectedApplicantIds.length === 1;
}
get isMultipleSelection(): boolean {
return this.selectedApplicantIds.length > 1;
}
482 ЧДТУ 252159 34 01
addApplicant(): void {
this.modalService.show(ApplicantCreateDialogComponent, {
class: 'modal-fullscreen',
backdrop: 'static',
ignoreBackdropClick: true
});
}
deleteApplicant(): void {
if (this.isAdmin) {
this.onDeleteApplicant.emit();
}
}
openDocumentSelectionDialog(): void {
const initialState: Partial<DocumentSelectionDialogComponent> = {
documents: ['Контракт', 'Заяву на укладання договору', 'Згоду одержувача
освітньої послуги', 'Договір про навчання у закладі вищої освіти']
};
const bsModalRef = this.modalService.show(DocumentSelectionDialogComponent,
{initialState});
// @ts-ignore
bsModalRef.content.onGenerateDocuments.subscribe((selectedDocuments:
string[]) => {
this.generateDocuments(selectedDocuments);
});
}
generateDocuments(selectedDocuments: string[]): void {
console.log("Emitting event with selected documents:", selectedDocuments);
this.onGenerateDocument.emit({selectedApplicantIds:
this.selectedApplicantIds, selectedDocuments});
}
editApplicant(applicantId: number): void {
if (this.isSingleSelection) {
this.modalService.show(ApplicantEditDialogComponent, {
backdrop: 'static',
class: 'modal-fullscreen',
ignoreBackdropClick: true,
initialState: {
applicantId: applicantId,
}
});
}
}
482 ЧДТУ 252159 34 01
logout(): void {
this.authService.logout();
}
482 ЧДТУ 252159 34 01
ДОДАТОК В
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
ФОРМУВАННЯ ЮРИДИЧНИХ ДОКУМЕНТІВ ДЛЯ ВСТУПНИКІВ В
ЗАКЛАДИ ВИЩОЇ ОСВІТИ
Інструкція користувача
482 ЧДТУ 252159 34 01
Листів 2
Розробник ________________ Макійчук А.В.
Черкаси 2025
Клонування репозиторію
Виконайте у терміналі:
git clone <URL_репозиторію>;
cd <папка_репозиторію>.
Установка і налаштування бази даних
Переконайтеся, що на вашому комп’ютері встановлено PostgreSQL. Створіть
базу даних з ім’ям recruitment-documents (наприклад, через psql):
CREATE DATABASE "recruitment-documents";
Конфігурація підключення до БД
Потрібно відредагувати файл src/main/resources/application.properties (або
application.yml), вказавши:
spring.datasource.url=jdbc:postgresql://localhost:5432/recruitment-documents
spring.datasource.username=<користувач>
spring.datasource.password=<пароль>
Збірка та запуск бекенду
У корені проєкту варто виконати наступні команди:
./gradlew build;
./gradlew bootRun.
Бекенд запуститься на умовно на такій URL http://localhost:8080.
Налаштування та запуск фронтенду
Перейдіть у папку з frontend, виконайте:
npm install;
ng serve.
Фронтенд буде доступний за адресою http://localhost:4200.
Вхід у систему
Відкрийте у браузері http://localhost:4200. У формі логіну введіть ваші облікові
дані й натисніть «Вхід». Після успішної аутентифікації ви опинитеся на головній
сторінці.
Кнопки дій для користувача
482 ЧДТУ 252159 90 01
Зверху відобразиться ряд кноком: “Додати студента”, “Редагувати запис”,
“Сформувати документ”, “Видалити студента” (лише для адміна), “Вихід”.
Додавання студента
Для цього натисніть «Додати студента» та заповніть необхідні поля і збережіть.
У формі потрібно зробити наступне:
оберіть тип замовника: «Фізична особа», «Юридична особа» або «Бюджет».
Якщо абітурієнт повнолітній, він може сам бути замовником;
щоб скористатися вже наявним замовником, введіть прізвище та імя (для
фізичної особи) або ЄДРПОУ (для юридичної особи). Якщо замовник існує,
то появиться список усіх можливих і варто обрати відповідні дані;
щоб заповнити деякі дані через додаток Дію, потрібно натиснути
«Надіслати запит до Дії», далі “Вставити дані студента”. У результаті
частина полів у формі буде заповнена даними (паспортні дані, місце
проживання тощо);
Заповніть усі інші обов’язкові поля і натисніть «Зберегти».
Редагування студента
Для редагування для початку оберіть студента або студентів, далі натисніть
кнопку “Редагувати запис”, внесіть зміни і збережіть. У результаті в таблиці студентів
має відобразитись змінений запис.
Генерація документів
Потрібно обрати студента або студентів та натиснути на кнопку “Сформувати
документ”, далі оберіть шаблон (шаблони) і натисніть «Генерувати». Після цього
заповненні шаблони відразу завантажуються на ваш пристрій у форматі DOCX.
Видалення студента (тільки для адміністратора)
Для цього потрібно обрати студента та натиснути на кнопку “Видалити
студента”, далі появиться модальне вікно підтвердження. Якщо це було помилковим
натисканням, то можна закрити форму клікнувши на хрестик або на кнопку
“Скасувати”. Якщо все ж таки потрібно видалити запис з таблиці варто натиснути на
кнопку “Видалити”.
482 ЧДТУ 252159 90 01
Вихід з системи
Для цього натисніть на кнопку «Вихід». Після цього ви повернетесь на сторінку
логіну.
482 ЧДТУ 252159 90 01
ДОДАТОК Г
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ ФОРМУВАННЯ
ЮРИДИЧНИХ ДОКУМЕНТІВ ДЛЯ ВСТУПНИКІВ В ЗАКЛАДИ ВИЩОЇ ОСВІТИ
Графічні матеріали
482 ЧДТУ 252159 90 01
Листів 21
Розробник ________________ Макійчук А.В.
Черкаси 2025
482 ЧДТУ 252159 90 01
Рисунок Г1 – Слайд вступу
Рисунок Г2 – Слайд опису актуальності даної роботи
6
482 ЧДТУ 252159 90 01
Рисунок Г3 – Слайд опису мети роботи
Рисунок Г4 – Слайд опису завдань
7
482 ЧДТУ 252159 90 01
Рисунок Г5 – Слайд опису обраного підходу
Рисунок Г6 – Слайд опису обраних технологій
8
482 ЧДТУ 252159 90 01
Рисунок Г7 – Слайд опису первинних вимог
Рисунок Г8 – Слайд опису функціональних вимог
9
482 ЧДТУ 252159 90 01
Рисунок Г9 = Слайд опису нефункціональних вимог та технічної архітектури
Рисунок Г10 = Слайд опису існуючих аналогів
10
482 ЧДТУ 252159 90 01
Рисунок Г11 – Слайд опису основних функцій додатку
Рисунок Г12 – Слайд опису послідовності запитів
11
482 ЧДТУ 252159 90 01
Рисунок Г13 – Слайд опису висновків до першого розділу
Рисунок Г14 – Слайд опису другого розділу
12
482 ЧДТУ 252159 90 01
Рисунок Г15 – Слайд опису моделювання предметної області
Рисунок Г16 – Слайд відображення діаграми класів
13
482 ЧДТУ 252159 90 01
Рисунок Г17 – Слайд відображення діаграми пакетів
Рисунок Г18 – Слайд відображення діаграми компонентів
14
482 ЧДТУ 252159 90 01
Рисунок Г19 – Слайд відображення діаграми розгортання
Рисунок Г20 – Слайд відображення діаграми діяльності
15
482 ЧДТУ 252159 90 01
Рисунок Г21 – Слайд відображення діаграми послідовності
Рисунок Г22 – Слайд відображення діаграми комунікації
16
482 ЧДТУ 252159 90 01
Рисунок Г23 – Слайд відображення діаграми скінченного автомату
Рисунок Г24 – Слайд опису висновків до другого розділу
17
482 ЧДТУ 252159 90 01
Рисунок Г25 – Слайд опису огляду третього розділу
Рисунок Г26 – Слайд опису логічної та функціональної схеми
18
482 ЧДТУ 252159 90 01
Рисунок Г27 – Слайд відображення функціональної схеми
Рисунок Г28 – Слайд опису проектування бази даних
19
482 ЧДТУ 252159 90 01
Рисунок Г29 – Слайд відображення схеми бази даних
Рисунок Г30 – Слайд опису розробки інтерфейсу користувача
20
482 ЧДТУ 252159 90 01
Рисунок Г31 – Слайд опису керування записами студентів
Рисунок Г32 – Слайд опису форми додавання студента
21
482 ЧДТУ 252159 90 01
Рисунок Г33 – Слайд опису генерації документів
Рисунок Г34 – Слайд опису тестування системи
22
482 ЧДТУ 252159 90 01
Рисунок Г35 – Слайд опису модульного тестування
Рисунок Г36 – Слайд опису приймального тестування
23
482 ЧДТУ 252159 90 01
Рисунок Г37 – Слайд опису інтеграційного тестування
Рисунок Г38 – Слайд опису системного тестування
24
482 ЧДТУ 252159 90 01
Рисунок Г39 – Слайд “Висновки та перспективи”
Рисунок Г40 – Слайд “Дякую за увагу”
25