Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9079
Title: Програмне забезпечення для обробки запитів зареєстрованих користувачів
Authors: Салапатов, Володимир Іванович
Бабушко, Олексій Вікторович
Keywords: СИСТЕМА ОБРОБКИ ЗАПИТІВ;TICKETING SYSTEM;DJANGO;VUE.JS;POSTGRESQL;DOCKER;REST API;УПРАВЛІННЯ ЗАПИТАМИ;ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;UML.;REQUEST PROCESSING SYSTEM;TICKETING SYSTEM;DJANGO;VUE.JS,;РOSTGRESQL;DOCKER;REQUEST MANAGEMENT;SOFTWARE
Issue Date: 21-Jun-2025
Abstract: АННОТАЦІЇ Виконавець: Бабушко Олексій Вікторович Назва роботи: "Програмне забезпечення для обробки запитів зареєстрованих користувачів". Спеціальність: 121 «Інженерія програмного забезпечення». Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2025р. У кваліфікаційній роботі розглядається процес проектування, розробки та тестування веб-орієнтованої системи для обробки запитів зареєстрованих користувачів. Основною метою розробки є створення сучасного, масштабованого та гнучкого програмного продукту, що автоматизує життєвий цикл звернень (тікетів) в організаційному середовищі. У ході роботи було проведено глибокий аналіз предметної області та існуючих ринкових рішень, як комерційних (Zendesk, Jira Service Management), так і з відкритим вихідним кодом (osTicket). На основі цього аналізу було обґрунтовано вибір технологічного стеку, що включає Django REST Framework для розробки серверної частини, Vue.js для клієнтської частини, PostgreSQL як систему управління базами даних та Docker для контейнеризації додатку. Проектування системи виконано з використанням об'єктно-орієнтованого підходу та уніфікованої мови моделювання (UML). Розроблено повний набір діаграм, що описують статичну структуру (діаграми класів, пакетів, компонентів), фізичну архітектуру (діаграма розгортання) та динамічну поведінку системи (діаграми прецедентів, діяльності, послідовності, комунікації, скінченного автомату). Результатом роботи є повнофункціональний програмний комплекс, що реалізує диференційований доступ для трьох ролей: Користувача, Агента підтримки та Адміністратора. Система забезпечує створення та відстеження запитів, коментування, зміну статусів, управління користувачами та категоріями. Застосування контейнеризації Docker значно спрощує процеси розгортання та підтримки системи. Проведений комплексний цикл тестування підтвердив відповідність розробленого програмного забезпечення функціональним та нефункціональним вимогам.
ANNOTATION Performer: Babushko Oleksii Victorovych The title of the work: "Software for processing requests from registered users". Specialty: 121 "Software Engineering". Educational institution: Cherkasy State Technological University, Cherkasy, 2024. This qualification thesis examines the process of designing, developing, and testing a web-based system for processing registered user requests.The main goal of the development is to create a modern, scalable, and flexible software product that automates the lifecycle of support requests (tickets) in an organizational environment. In the course of the work, a thorough analysis of the subject domain and existing market solutions, both commercial (Zendesk, Jira Service Management) and open-source (osTicket), was conducted. Based on this analysis, the choice of the technology stack was justified, which includes Django REST Framework for the backend development, Vue.js for the client-side, PostgreSQL as the database management system, and Docker for application containerization. The system design was performed using an object-oriented approach and the Unified Modeling Language (UML). A complete set of diagrams was developed to describe the static structure (class, package, component diagrams), physical architecture (deployment diagram), and dynamic behavior of the system (use case, activity, sequence, communication, state machine diagrams). The result of the work is a fully functional software system, which implements differentiated access for three roles: User, Support Agent, and Administrator. The system provides functionality for creating and tracking requests, commenting, changing statuses, managing users, and categories. The use of Docker containerization significantly simplifies the deployment and maintenance processes. A comprehensive testing cycle confirmed that the developed software meets functional and non-functional requirements.
URI: https://er.chdtu.edu.ua/handle/ChSTU/9079
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)



Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text
     
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
 
на тему:  «Програмне забезпечення для обробки запитів зареєстрованих 
користувачів» 
 
Виконав: студент 4 курсу, групи ПЗ-2104 
Спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Бабушко О.В. 
 (прізвище та ініціали) 
Керівник Салапатов В.І. 
 (прізвище та ініціали) 
Рецензент Захарова М.В. 
 (прізвище та ініціали) 
 
 
 
 
Черкаси 2025
 
 
 Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем 
Кафедра   програмного забезпечення автоматизованих систем 
Освітній рівень  бакалавр  
Спеціальність  121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________                  Голуб С.В. 
«___» _______________ 2025 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Бабушко Олексій Вікторович 
(прізвище, ім’я, по батькові) 
1.Тему проекту (роботи) «Програмне забезпечення для обробки запитів зареєстрованих 
користувачів»  
Керівник проекту (роботи)  Салапатов Володимир Іванович кандидат наук, доцент  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 25 » лютого 
2025 року №53/03-03 
2. Строк подання студентом проекту (роботи) 20 червня 2025 р.  
3. Вхідні дані до проекту (роботи) Технічне завдання на розробку, методичні рекомендації до 
виконання бакалаврської роботи, автоматизовані системи, терміни та визначення.  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Вступ; 
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;  
Розділ 2. Впровадження результатів досліджень у практику проектування програмного  
забезпечення інформаційних систем;  
Розділ 3. Розробка та тестування програмного забезпечення;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;  
  
 
 
6. Консультанти розділів проекту (роботи) 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02 грудня 2024 р.  
 
 
КАЛЕНДАРНИЙ ПЛАН 
Строк 
виконання 
№ 
Назва етапів випускної роботи етапів Примітки 
п/п 
випускної 
роботи 
1 Постановка задачі Вересень виконано 
2 Підготовка завдання Вересень виконано 
3 Погодження завдання Вересень виконано 
4 Затвердження завдання Жовтень виконано 
 Основна стадія   
1 Підбір матеріалів Жовтень виконано 
2 Аналіз шляхів вирішення поставленої задачі Жовтень виконано 
3 Розрахунок основних параметрів роботи Жовтень виконано 
4 Вибір кінцевого варіанту проектного рішення Листопад виконано 
5 Оформлення первісної редакції роботи Листопад виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з Січень виконано 
керівником 
2 Оформлення пояснювальної записки роботи в Січень виконано 
кінцевій редакції 
3 Попередній захист роботи Травень виконано 
4 Затвердження роботи Червень виконано 
5 Рецензування роботи Червень виконано 
6 Захист роботи 20.06.2025  
 
Студент _____________________ Бабушко О.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________ Салапатов В.І. 
  (підпис)   (прізвище та ініціали) 
  
 
 
АННОТАЦІЇ 
Виконавець: Бабушко Олексій Вікторович 
Назва роботи: "Програмне забезпечення для обробки запитів зареєстрованих 
користувачів". 
Спеціальність: 121 «Інженерія програмного забезпечення». 
Навчальний заклад: «Черкаський державний технологічний університет» м. 
Черкаси, 2025р. 
У кваліфікаційній роботі розглядається процес проектування, розробки та 
тестування веб-орієнтованої системи для обробки запитів зареєстрованих 
користувачів. Основною метою розробки є створення сучасного, масштабованого 
та гнучкого програмного продукту, що автоматизує життєвий цикл звернень 
(тікетів) в організаційному середовищі. 
У ході роботи було проведено глибокий аналіз предметної області та 
існуючих ринкових рішень, як комерційних (Zendesk, Jira Service Management), так 
і з відкритим вихідним кодом (osTicket). На основі цього аналізу було обґрунтовано 
вибір технологічного стеку, що включає Django REST Framework для розробки 
серверної частини, Vue.js для клієнтської частини, PostgreSQL як систему 
управління базами даних та Docker для контейнеризації додатку. 
Проектування системи виконано з використанням об'єктно-орієнтованого 
підходу та уніфікованої мови моделювання (UML). Розроблено повний набір 
діаграм, що описують статичну структуру (діаграми класів, пакетів, компонентів), 
фізичну архітектуру (діаграма розгортання) та динамічну поведінку системи 
(діаграми прецедентів, діяльності, послідовності, комунікації, скінченного 
автомату). 
Результатом роботи є повнофункціональний програмний комплекс, що 
реалізує диференційований доступ для трьох ролей: Користувача, Агента 
підтримки та Адміністратора. Система забезпечує створення та відстеження 
запитів, коментування, зміну статусів, управління користувачами та категоріями. 
Застосування контейнеризації Docker значно спрощує процеси розгортання та 
підтримки системи. Проведений комплексний цикл тестування підтвердив 
 
 
відповідність розробленого програмного забезпечення функціональним та 
нефункціональним вимогам. 
Ключові слова: СИСТЕМА ОБРОБКИ ЗАПИТІВ, TICKETING SYSTEM, 
DJANGO, VUE.JS, POSTGRESQL, DOCKER, REST API, УПРАВЛІННЯ 
ЗАПИТАМИ, ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, UML. 
 
 
ANNOTATION 
Performer: Babushko Oleksii Victorovych 
The title of the work: "Software for processing requests from registered users". 
Specialty: 121 "Software Engineering". 
Educational institution: Cherkasy State Technological University, Cherkasy, 2024. 
This qualification thesis examines the process of designing, developing, and testing 
a web-based system for processing registered user requests.The main goal of the 
development is to create a modern, scalable, and flexible software product that automates 
the lifecycle of support requests (tickets) in an organizational environment. 
In the course of the work, a thorough analysis of the subject domain and existing 
market solutions, both commercial (Zendesk, Jira Service Management) and open-source 
(osTicket), was conducted. Based on this analysis, the choice of the technology stack was 
justified, which includes Django REST Framework for the backend development, Vue.js 
for the client-side, PostgreSQL as the database management system, and Docker for 
application containerization. 
The system design was performed using an object-oriented approach and the 
Unified Modeling Language (UML). A complete set of diagrams was developed to 
describe the static structure (class, package, component diagrams), physical architecture 
(deployment diagram), and dynamic behavior of the system (use case, activity, sequence, 
communication, state machine diagrams). 
The result of the work is a fully functional software system, which implements 
differentiated access for three roles: User, Support Agent, and Administrator. The system 
provides functionality for creating and tracking requests, commenting, changing statuses, 
managing users, and categories. The use of Docker containerization significantly 
simplifies the deployment and maintenance processes. A comprehensive testing cycle 
confirmed that the developed software meets functional and non-functional requirements. 
Keywords: REQUEST PROCESSING SYSTEM, TICKETING SYSTEM, 
DJANGO, VUE.JS, POSTGRESQL, DOCKER, REST API, REQUEST 
MANAGEMENT, SOFTWARE, UML. 
 
 
 
ЗМІСТ 
ВСТУП ............................................................................................................... 3 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ..................................................................................... 6 
1.1 Аналіз предметної області та існуючих систем-аналогів ................. 10 
1.2 Огляд та обґрунтування вибору технологічного стеку .........................  
1.3 Постановка задачі ......................................................................................  
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ................................................... 17 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ .............................................................................. 18 
2.1 Моделювання предметної області ....................................................... 18 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області ............................................................................ 18 
2.1.2 Елементи моделювання предметної області ............................... 20 
2.1.3 Робоча область моделювання ....................................................... 21 
2.2 Формування та аналіз вимог ................................................................ 22 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги ................................................................................... 22 
2.2.2 Формування вимог за допомогою діаграми прецедентів .......... 25 
2.3 Проектування логічної структури програмного комплексу ............. 26 
2.3.1 Діаграми класів............................................................................... 26 
2.4 Архітектура проектування ................................................................... 30 
2.4.1 Діаграма компонентів .................................................................... 30 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ........................................................................................................ 31 
  
ЧДТУ 252148.001ПЗ 
Змн. Арк. № докум. Підпис Дата 
 Розроб.       Бабушко О.В. «Програмне забезпечення для обробки Літ. Лист Листів 
 Перевір.      Салапатов В.І. запитів зареєстрованих користувачів» 3  
Пояснювальна записка. 
  
 Н. Контр.   Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗ-2104 
 Затверд.  Голуб С.В. 
 
 
2.5 Моделювання поведінки системи ....................................................... 32 
2.5.1 Діаграма діяльності ........................................................................ 33 
2.5.2 Діаграма послідовності .................................................................. 35 
2.5.3 Діаграма комунікації...................................................................... 36 
2.5.4 Діаграма скінченного автомату .................................................... 37 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ..................................................... 39 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ....................................................................................................... 40 
3.1 Розробка програмного комплексу ....................................................... 40 
3.1.1 Обґрунтування вибору засобів реалізації .................................... 42 
3.1.2 Опис структурної (функціональної) схеми ................................. 43 
3.1.3 Опис логічної схеми....................................................................... 44 
3.1.4 Розробка бази даних....................................................................... 46 
3.1.5 Розробка інтерфейсу користувача ................................................ 49 
3.1.6 Опис розробки програмних компонентів .................................... 50 
3.2 Тестування системи .............................................................................. 51 
3.2.1 Модульне тестування .................................................................... 51 
3.2.2 Інтеграційне тестування ................................................................ 52 
3.2.3 Системне тестування ..................................................................... 53 
3.2.4 Приймальне тестування ................................................................. 53 
3.3 Приклади впровадженого програмного комплексу........................... 56 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ................................................... 57 
ВИСНОВКИ ..................................................................................................... 59 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................... 61 
Додаток А ......................................................................................................... 63 
Додаток Б ......................................................................................................... 82 
Додаток В .............................................................................................................  
Додаток Г .............................................................................................................  
 
 
 
ЧДТУ 252148.001ПЗ 
Змн. Арк. № докум. Підпис Дата 
     
 
ЧДТУ.252148.001 ПЗ 
ВСТУП 
Актуальність теми. Розробка власного програмного забезпечення для обробки 
запитів, є надзвичайно актуальним завданням.Так як створення кастомної системи 
дозволяє не тільки уникнути недоліків існуючих рішень, але й реалізувати продукт, 
що ідеально відповідає специфічним вимогам організації. Попри те що, у сучасному 
цифровому світі ефективність бізнес-процесів та якість обслуговування клієнтів є 
ключовими факторами конкурентоспроможності будь-якої організації. Центральним 
елементом у підтримці високих стандартів сервісу, як для внутрішніх, так і для 
зовнішніх користувачів, є системи управління запитами, також відомі як helpdesk або 
ticketing systems. Ці системи дозволяють централізовано збирати, відстежувати, 
пріоритезувати та вирішувати звернення, що надходять від клієнтів або 
співробітників, забезпечуючи прозорість та підзвітність у процесах підтримки. 
Ринок програмного забезпечення для обробки запитів насичений 
різноманітними рішеннями. Комерційні гіганти, такі як Zendesk та Jira Service 
Management, пропонують потужні, багатофункціональні платформи з глибокою 
аналітикою та можливостями інтеграції, що робить їх стандартом для великих 
підприємств. Водночас, існують популярні рішення з відкритим вихідним кодом, 
наприклад, osTicket, які надають базовий функціонал безкоштовно, але часто 
вимагають значних технічних зусиль для налаштування та підтримки. 
Незважаючи на велику кількість існуючих продуктів, потреба в розробці 
кастомних систем залишається високою. Це зумовлено кількома факторами. По-
перше, комерційні системи часто пов'язані з високими ліцензійними витратами та 
ризиком "прив'язки до постачальника" (vendor lock-in), що обмежує гнучкість 
компанії. По-друге, системи з відкритим кодом можуть мати застарілий 
технологічний стек або обмежені можливості для кастомізації та масштабування під 
унікальні бізнес-процеси. 
Саме тому розробка власного програмного забезпечення для обробки запитів, є 
надзвичайно актуальним завданням. Створення кастомної системи дозволяє не тільки 
5 
ЧДТУ.252148.001 ПЗ 
уникнути недоліків існуючих рішень, але й реалізувати продукт, що ідеально 
відповідає специфічним вимогам організації. Актуальність даної роботи підсилюється 
вибором сучасного, гнучкого та масштабованого технологічного стеку. Використання 
контейнеризації за допомогою Docker та Docker Compose відповідає передовим 
практикам DevOps, забезпечуючи портативність, ізоляцію середовищ та значне 
спрощення процесів розгортання та супроводу системи. Такий підхід дозволяє 
створити не просто програмний продукт, а надійну, готову до впровадження 
платформу, що може ефективно функціонувати в будь-якому сучасному IT-
середовищі. 
Мета розробки - проектування та розробка веб-орієнтованого програмного 
забезпечення для комплексної автоматизації процесів обробки запитів від 
зареєстрованих користувачів, що забезпечує ефективну взаємодію між 
користувачами, агентами підтримки та адміністраторами системи. 
Для досягнення поставленої мети необхідно вирішити наступні завдання: 
1 Провести глибокий аналіз предметної області та порівняльний аналіз 
існуючих комерційних та відкритих систем обробки запитів для виявлення ключових 
функціональних можливостей та найкращих практик. 
2 Виконати огляд та обґрунтувати вибір технологічного стеку, включаючи 
backend- та frontend-фреймворки, систему управління базами даних та технологію 
контейнеризації. 
3 Сформулювати та формалізувати функціональні та нефункціональні вимоги 
до програмного забезпечення. 
4 Спроектувати архітектуру системи, використовуючи принципи об'єктно-
орієнтованого аналізу та дизайну, та змоделювати її за допомогою уніфікованої мови 
моделювання (UML) згідно з академічними стандартами. 
5 Реалізувати серверну частину системи на базі фреймворку Django, 
клієнтську частину – на Vue.js, та спроектувати структуру бази даних у PostgreSQL. 
6 Застосувати технологію контейнеризації Docker для пакування всіх 
компонентів системи (backend, frontend, база даних, веб-сервер) та налаштувати їх 
6 
ЧДТУ.252148.001 ПЗ 
взаємодію за допомогою Docker Compose. 
7 Розробити та виконати комплексний план тестування, що охоплює 
модульний, інтеграційний, системний та приймальний рівні для забезпечення якості 
та надійності розробленого програмного продукту. 
Об'єктом розробки є програмне забезпечення для управління життєвим циклом 
запитів користувачів (тікетів) в організаційній системі підтримки. Цей процес 
охоплює всі етапи взаємодії: від створення та реєстрації запиту користувачем, його 
подальшої класифікації, призначення відповідальному агенту, обробки та 
коментування, до остаточного вирішення та закриття. 
Предметом розробки є програмне забезпечення, що автоматизує об'єкт 
розробки. Предмет включає архітектуру системи (MVT-архітектура на серверній 
стороні, односторінковий додаток (SPA) на клієнтській), структуру бази даних, REST 
API для взаємодії між компонентами, реалізацію рольової моделі доступу 
(Користувач, Агент, Адміністратор) та її імплементацію з використанням 
технологічного стеку: Django, Vue.js, PostgreSQL та Docker. 
Методи проектування та конструювання. Для досягнення поставленої мети 
та вирішення завдань у роботі застосовано наступні методи проектування та 
конструювання: 
− Об'єктно-орієнтований аналіз та проектування (ООАП): Використовується 
для ідентифікації ключових сутностей системи (Користувач, Запит, Коментар), їх 
атрибутів, поведінки та взаємозв'язків; 
− Уніфікована мова моделювання (UML): Застосовується для візуального 
моделювання статичної структури та динамічної поведінки системи, як це 
вимагається методичними рекомендаціями; 
− Архітектурний патерн Model-View-Template (MVT): Є основою фреймворку 
Django і використовується для структурування серверної частини додатку, 
розділяючи логіку представлення даних, бізнес-логіку та моделі даних; 
− Компонентна архітектура: Використовується у фреймворку Vue.js для 
побудови клієнтського інтерфейсу з незалежних та повторно використовуваних 
7 
ЧДТУ.252148.001 ПЗ 
компонентів; 
− REST (Representational State Transfer): Принципи REST застосовуються для 
проектування API, що забезпечує стандартизовану, безстанову комунікацію між 
клієнтською та серверною частинами; 
− Методологія контейнеризації: Використання Docker для інкапсуляції 
додатку та його залежностей в ізольовані контейнери, що гарантує узгодженість 
середовища та спрощує розгортання. 
Практичне значення отриманих результатів. Результатом даної 
кваліфікаційної роботи є готовий до розгортання та використання програмний 
продукт. Практичне значення полягає у створенні повноцінної, економічно 
ефективної альтернативи комерційним системам обробки запитів, яка може бути 
впроваджена на підприємствах малого та середнього бізнесу для автоматизації роботи 
служби підтримки, IT-відділу чи інших сервісних підрозділів. Завдяки 
контейнеризації за допомогою Docker, система є портативною і може бути легко 
розгорнута на будь-якій інфраструктурі, що підтримує дану технологію, включаючи 
локальні сервери та хмарні платформи (AWS, DigitalOcean, Hetzner), що значно 
знижує поріг входу для її використання. 
Особистий внесок автора. У процесі виконання кваліфікаційної роботи 
автором було особисто проведено всі етапи дослідження та розробки. Це включає: 
детальний аналіз існуючих систем-аналогів та технологій; формування 
функціональних та нефункціональних вимог до системи проекту, проектування 
архітектури та розробку повного набору UML-діаграм; реалізацію серверної частини 
на Django та клієнтської на Vue.js; проектування та створення схеми бази даних у 
PostgreSQL; налаштування контейнеризації та оркестрації за допомогою Docker та 
Docker Compose; розробку та проведення комплексного тестування програмного 
забезпечення. 
8 
ЧДТУ.252148.001 ПЗ 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯПОСТАВЛЕНИХ 
ЗАВДАНЬ  
1.1. Аналіз предметної області та існуючих систем-аналогів 
Системи обробки запитів, або тікет-системи, є невід'ємною частиною сучасного 
IT-ландшафту та бізнес-операцій. Їх основне призначення - перетворити хаотичний 
потік звернень (електронні листи, дзвінки, повідомлення в месенджерах) у 
структуровані, керовані одиниці, які називаються тікетами або запитами. Кожен тікет 
представляє окрему проблему або завдання та проходить чітко визначений життєвий 
цикл: від створення та призначення до вирішення та закриття. Ключові функціональні 
можливості таких систем включають централізовану організацію тікетів, їх 
пріоритезацію, автоматизацію рутинних завдань (наприклад, маршрутизацію), 
управління угодами про рівень обслуговування (SLA) та формування бази знань для 
самообслуговування користувачів. 
Для глибокого розуміння контексту та визначення вимог до системи  було 
проведено порівняльний аналіз провідних ринкових рішень, що представляють різні 
сегменти: комерційні SaaS-платформи та системи з відкритим вихідним кодом. 
Комерційні системи-аналоги: 
− Zendesk: Це одна з найпопулярніших у світі хмарних платформ для 
обслуговування клієнтів. Zendesk пропонує омніканальний підхід, об'єднуючи запити 
з електронної пошти, чату, соціальних мереж та телефону в єдиному інтерфейсі. 
Сильними сторонами системи є потужні інструменти автоматизації (тригери, 
макроси), розширені можливості для звітності та аналітики, а також величезний 
маркетплейс інтеграцій. Платформа Zendesk Sunshine дозволяє глибоко кастомізувати 
систему та інтегрувати її з зовнішніми даними, створюючи єдиний профіль клієнта. 
Однак, це комплексне рішення з високою вартістю ліцензії, що може бути бар'єром 
для малих компаній. 
− Jira Service Management (JSM): Продукт компанії Atlassian, JSM є еволюцією 
Jira Service Desk. Ця система тісно інтегрована з Jira Software, що робить її ідеальним 
9 
ЧДТУ.252148.001 ПЗ 
вибором для IT-команд та розробників, які працюють за методологіями Agile. JSM 
фокусується на практиках IT Service Management (ITSM), пропонуючи функціонал для 
управління інцидентами, проблемами, змінами та активами. Система має потужні 
можливості для автоматизації, кастомізації робочих процесів та створення порталів 
самообслуговування з інтегрованою базою знань на базі Confluence. Недоліком може 
бути її складність та орієнтованість переважно на технічні команди. 
Системи-аналоги з відкритим вихідним кодом: 
− osTicket: Це одна з найстаріших та найпопулярніших безкоштовних тікет-
систем. Вона пропонує базовий, але надійний набір функцій: створення тікетів через 
веб-портал та email, автоматичні відповіді, кастомні поля, теми допомоги для 
маршрутизації та базові SLA. Система написана на PHP та використовує MySQL, що 
робить її доступною для розгортання на стандартному веб-хостингу. Головними 
перевагами є нульова вартість ліцензії та можливість повної модифікації вихідного 
коду. Проте, osTicket має дещо застарілий інтерфейс, обмежені можливості для 
автоматизації порівняно з комерційними аналогами, а його налаштування та 
підтримка вимагають технічних знань. 
− Frappe Helpdesk: Більш сучасна альтернатива з відкритим кодом, що 
пропонує такі функції, як автоматичне призначення тікетів на основі правил (round-
robin, load-balancing), конфігурування SLA та вбудовану базу знань для 
самообслуговування клієнтів. Система позиціонується як інструмент для підвищення 
продуктивності агентів та покращення клієнтського досвіду. 
Аналіз цих систем дозволяє сформувати бачення для ПЗ як продукту, що 
поєднує гнучкість та безкоштовність відкритих рішень із сучасним технологічним 
стеком та архітектурою, характерною для комерційних продуктів. 
Таблиця 1.1 
Порівняння готових рішень і власного проєкту 
Jira Service 
Функція Zendesk osTicket (Власний проект) 
Management 
 
10 
ЧДТУ.252148.001 ПЗ 
Продовження таблиці 1.1 
Управлінн Централізова Інтеграція Створення Створення запитів 
я запитами на з задачами через з категорією, 
(тікетами) омніканальна Jira, email/веб, пріоритетом,описо
панель, кастомні кастомні м, вкладеннями; 
кастомні типи поля, теми перегляд та 
поля, повна запитів, допомоги, фільтрація. 
історія, черги, історія. 
вкладення. SLA, 
історія 
змін. 
Ролі Гнучка Ролі на Базові ролі Чіткі ролі: 
користувач система ролей рівні (Користувач, Користувач, Агент, 
ів та дозволів проекту Агент, Адміністратор з 
(Агент, Jira Адміністрато різними правами 
Адміністрато (Адмініст р). доступу. 
р, Кінцевий ратор, 
користувач). Агент, 
Клієнт). 
Автоматиз Потужні Розширені Базові Заплановано 
ація тригери та правила фільтри для базову 
автоматизації автоматиз маршрутизац автоматизацію 
для будь-яких ації (if- ії та (зміна статусів, 
подій, this-then- автоматични сповіщення). 
макроси. that), х відповідей. 
інтеграція 
з CI/CD. 
11 
ЧДТУ.252148.001 ПЗ 
Продовження таблиці 1.1 
База знань Інтегрований Інтеграція Вбудований,а Не є 
(Self- потужний з ле простий першочерговим 
service) інструмент Confluence функціонал пріоритетом, але 
Guide для для бази знань. архітектура 
створення баз створення дозволяє додати в 
знань. розширен майбутньому. 
их баз 
знань. 
Звітність та Розширені Інтерактив Базові Базовий перегляд 
аналітика дашборди, ні дашборди зі статистики для 
кастомні дашборди, статистикою. адміністраторів. 
звіти, JQL для 
аналітика кастомних 
продуктивнос запитів, 
ті. інтеграція 
з Atlassian 
Analytics. 
Технологіч Власна Java, PHP, MySQL, Django (Python), 
ний стек хмарна React, jQuery. Vue.js, PostgreSQL, 
інфраструкту власна Nginx, Docker. 
ра (Ruby on інфрастру
Rails, React). ктура 
Atlassian. 
 
 
 
12 
ЧДТУ.252148.001 ПЗ 
Продовження таблиці 1.1 
Модель Комерційна Комерцій Відкритий Відкритий 
ліцензуван (SaaS, на (SaaS вихідний код вихідний код 
ня підписка за або Data (безкоштовно (безкоштовно). 
агента). Center, ). 
підписка 
за агента). 
 
1.2. Огляд та обґрунтування вибору технологічного стеку 
Вибір технологій є фундаментальним рішенням, що визначає швидкість 
розробки, продуктивність, масштабованість та довгострокову підтримку програмного 
продукту. Для проекту було обрано сучасний та збалансований стек технологій, 
кожний компонент якого обґрунтовується порівняльним аналізом з альтернативами. 
1.2.1. Аналіз backend-фреймворків: Django vs. Node.js 
Серверна частина є ядром будь-якого веб-додатку, відповідаючи за бізнес-
логіку, обробку даних та взаємодію з базою даних. Основними претендентами на цю 
роль були Django (на базі Python) та Node.js (на базі JavaScript). 
Django - це високорівневий Python-фреймворк, що дотримується філософії 
"batteries-included" ("все включено"). Це означає, що він надає розробнику великий 
набір готових інструментів "з коробки", таких як потужний Object-Relational Mapper 
(ORM) для роботи з базами даних, вбудовану панель адміністрування, систему 
автентифікації, механізми захисту від поширених веб-атак (CSRF, XSS, SQL Injection) 
та систему шаблонів. Архітектура Django (Model-View-Template) сприяє чіткому 
розділенню логіки та швидкій розробці складних, керованих даними додатків. Для 
системи, де потрібна чітка структура даних (користувачі, тікети, коментарі), надійна 
автентифікація та адміністративна панель для керування системою, підхід Django є 
надзвичайно ефективним. 
13 
ЧДТУ.252148.001 ПЗ 
Node.js - це середовище виконання JavaScript, що дозволяє використовувати цю 
мову на сервері. Його головна перевага - асинхронна, подієво-орієнтована 
архітектура, яка забезпечує високу продуктивність при обробці великої кількості 
одночасних I/O-операцій (наприклад, у чатах чи стрімінгових сервісах). Проте, 
Node.js сам по собі не є фреймворком. Для побудови веб-додатку зазвичай 
використовують додаткові бібліотеки, найпопулярнішою з яких є Express.js. Express є 
мінімалістичним і гнучким, що дає розробнику повну свободу вибору компонентів 
(ORM, шаблонізатор тощо). Однак ця свобода може призвести до неструктурованого 
коду ("callback hell") та вимагає більше часу на налаштування базової архітектури, що 
є менш бажаним для проекту з чітко визначеними вимогами 
Висновок: Для проекту було обрано Django. Його структурований підхід та 
наявність вбудованих компонентів, особливо ORM та панелі адміністратора, значно 
прискорюють розробку та забезпечують вищий рівень надійності та безпеки "з 
коробки", що є критичним для системи, яка обробляє дані користувачів. 
1.2.2. Аналіз frontend-фреймворків: Vue.js vs. React vs. Angular 
Клієнтська частина відповідає за користувацький інтерфейс та інтерактивність. 
У сучасному вебі домінують три основні JavaScript-інструменти: Angular, React та 
Vue.js. 
Angular, розроблений Google, є повноцінним, "думковмісним" (opinionated) 
фреймворком. Він надає комплексну структуру для створення великих корпоративних 
додатків, включаючи маршрутизацію, управління станом та HTTP-клієнт. Його 
використання TypeScript забезпечує строгу типізацію та кращу масштабованість коду. 
Однак Angular має високий поріг входження та вважається досить громіздким для 
невеликих та середніх проектів. 
React, розроблений Facebook, є бібліотекою для побудови користувацьких 
інтерфейсів, а не повним фреймворком. Його головна ідея - компонентний підхід та 
використання віртуального DOM для високої продуктивності. React надає велику 
гнучкість, але для створення повноцінного додатку вимагає інтеграції сторонніх 
14 
ЧДТУ.252148.001 ПЗ 
бібліотек для маршрутизації (React Router) та управління станом (Redux, MobX). Це 
може ускладнити початкове налаштування та вибір архітектури. 
Vue.js часто називають прогресивним фреймворком, оскільки він поєднує 
найкращі риси Angular та React. Він легкий для вивчення, має чудову документацію 
та пропонує реактивне двостороннє зв'язування даних (подібно до Angular) та 
компонентний підхід з віртуальним DOM (подібно до React). Vue надає офіційні, але 
не обов'язкові бібліотеки для маршрутизації (Vue Router) та управління станом 
(Pinia/Vuex), що створює збалансовану екосистему. Його структура з однофайловими 
компонентами (HTML, CSS, JS в одному файлі) робить розробку інтуїтивно 
зрозумілою та зручною. 
Висновок: Для проекту було обрано Vue.js. Він є оптимальним вибором, 
оскільки забезпечує швидку розробку та низький поріг входження, що важливо в 
рамках кваліфікаційної роботи, але при цьому надає достатньо потужності та 
структури для створення складного односторінкового додатку (SPA) 
1.2.3. Аналіз систем управління базами даних: PostgreSQL vs. MySQL vs. 
MongoDB 
База даних є критичним компонентом для зберігання всієї інформації системи. 
Вибір СУБД залежить від структури даних, вимог до транзакційності та  
масштабованості. 
MongoDB є провідною NoSQL документо-орієнтованою базою даних. Вона 
зберігає дані у гнучких JSON-подібних документах (BSON), що дозволяє легко 
змінювати схему даних "на льоту". MongoDB чудово підходить для неструктурованих 
або напівструктурованих даних, великих обсягів інформації та додатків, що 
вимагають горизонтального масштабування (шардингу). Однак для системи , де дані 
мають чітку реляційну структуру (користувач має багато тікетів, тікет має багато 
коментарів), і де важлива строга цілісність даних та ACID-транзакції, реляційна 
модель є більш доцільною. 
MySQL - найпопулярніша у світі реляційна СУБД з відкритим кодом. Вона 
відома своєю швидкістю, простотою у використанні та надійністю, що робить її 
15 
ЧДТУ.252148.001 ПЗ 
чудовим вибором для багатьох веб-додатків, особливо для операцій з високою 
інтенсивністю читання. 
PostgreSQL, у свою чергу, часто називають "найпросунутішою реляційною 
СУБД з відкритим кодом". Вона повністю відповідає стандартам ACID і пропонує 
більш розширений функціонал порівняно з MySQL. Серед переваг PostgreSQL - 
підтримка складних запитів, розширених типів даних (включаючи JSONB, що 
дозволяє ефективно зберігати та індексувати JSON-дані в реляційній структурі), більш 
надійна реалізація транзакцій та кращі можливості для розширюваності за допомогою 
користувацьких функцій. 
Висновок: Для проекту було обрано PostgreSQL. Хоча MySQL був би достатнім 
на початковому етапі, PostgreSQL надає більший запас міцності та гнучкості для 
майбутнього розвитку системи, особливо якщо виникне потреба у складних запитах 
чи зберіганні напівструктурованих даних у межах реляційної моделі. Його репутація 
надійності та суворого дотримання стандартів є вирішальною для системи, де 
цілісність даних є пріоритетом. 
1.2.4. Аналіз технологій контейнеризації: Docker 
Контейнеризація - це підхід до віртуалізації на рівні операційної системи, що  
дозволяє пакувати додаток та всі його залежності в єдиний стандартизований блок - 
контейнер. 
Docker є де-факто індустріальним стандартом для контейнеризації. Він дозволяє 
розробникам створювати легкі, портативні та самодостатні контейнери, які 
гарантовано працюватимуть однаково в будь-якому середовищі - від локальної 
машини розробника до хмарного продакшн-сервера.Це вирішує класичну проблему 
"на моїй машині все працює". Використання Docker Compose, як зазначено в описі 
проекту, дозволяє визначати та запускати багатоконтейнерні додатки однією 
командою, що значно спрощує процес розробки та розгортання всього стеку (backend, 
frontend, база даних, Nginx). 
Існують альтернативи Docker, такі як Podman, який пропонує без-демонну 
(daemonless) архітектуру для підвищення безпеки, або containerd, який є більш легкою 
16 
ЧДТУ.252148.001 ПЗ 
средою виконання, що лежить в основі самого Docker та Kubernetes. Однак, Docker 
має найбільшу екосистему, найширшу підтримку спільноти та величезну кількість 
готових образів у Docker Hub, що робить його найпрагматичнішим вибором для 
більшості проектів. 
Висновок: Використання Docker та Docker Compose у є абсолютно виправданим 
та відповідає сучасним практикам розробки програмного забезпечення. Це забезпечує 
відтворюваність середовища, спрощує управління залежностями та значно полегшує 
розгортання, що є великою перевагою для будь-якого програмного продукту. 
1.3. Постановка задачі 
На основі проведеного аналізу предметної області, існуючих рішень та 
технологій, формулюється комплексна задача для розробки програмного 
забезпечення .Необхідно створити веб-систему, яка реалізує повний життєвий цикл 
обробки запитів користувачів та відповідає наступним вимогам. 
Функціональні вимоги: 
− Система автентифікації та авторизації: Реалізувати реєстрацію, вхід та 
відновлення пароля для користувачів. Забезпечити розмежування доступу на основі 
трьох ролей: Користувач, Агент та Адміністратор. 
− Управління запитами (тікетами): 
− Користувачі повинні мати можливість створювати нові запити, вказуючи 
категорію, пріоритет, надаючи детальний опис та прикріплюючи файли. 
− Користувачі повинні мати доступ до списку лише своїх запитів з 
можливістю їх фільтрації. 
− Агенти повинні бачити всі запити (або призначені їм), брати їх у роботу, 
змінювати статуси ("Новий", "В роботі", "Вирішено" тощо) та переглядати історію 
змін. 
− Комунікація: 
− Користувачі та агенти повинні мати можливість додавати коментарі до 
запитів. 
17 
ЧДТУ.252148.001 ПЗ 
− Агенти повинні мати можливість додавати як публічні (видимі 
користувачу), так і приватні (видимі лише іншим агентам) коментарі. 
− Адміністрування: 
− Адміністратори повинні мати повний доступ до функціоналу агентів. 
− Адміністратори повинні мати можливість керувати обліковими записами 
користувачів та агентів (створення, блокування, редагування). 
− Адміністратори повинні керувати системними довідниками (наприклад, 
категоріями запитів) та переглядати базову статистику роботи системи. 
Нефункціональні вимоги: 
− Продуктивність: Система повинна забезпечувати швидкий відгук 
інтерфейсу та обробку API-запитів. 
− Безпека: Застосувати JWT-автентифікацію для захисту API. Забезпечити 
захист від основних веб-вразливостей. 
− Надійність: Система повинна стабільно функціонувати під навантаженням. 
− Масштабованість: Архітектура повинна дозволяти горизонтальне 
масштабування компонентів (наприклад, запуск декількох екземплярів backend-
контейнера). 
− Зручність використання (Usability): Інтерфейс користувача має бути 
інтуїтивно зрозумілим та простим для всіх ролей. 
  
18 
ЧДТУ.252148.001 ПЗ 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі було проведено комплексний аналіз, що став основою для 
подальшого проектування та розробки системи. Аналіз існуючих систем-аналогів, 
таких як Zendesk, Jira Service Management та osTicket, підтвердив актуальність 
створення власного гнучкого та сучасного рішення для обробки запитів. Було 
виявлено ключові функціональні блоки, які є стандартом для таких систем, та 
визначено нішу для проекту як кастомізованого продукту з відкритим кодом. 
Детальний огляд технологій дозволив зробити обґрунтований вибір на користь 
стеку Django, Vue.js, PostgreSQL та Docker. Цей вибір забезпечує оптимальний баланс 
між швидкістю розробки, продуктивністю, надійністю та відповідністю сучасним 
практикам DevOps. На основі проведеного аналізу було сформульовано чітку 
постановку задачі, що включає деталізовані функціональні та нефункціональні 
вимоги, які слугуватимуть критеріями успішності проекту. Таким чином, перший 
розділ створює міцний теоретичний та аналітичний фундамент для переходу до етапу 
проектування системи. 
 
  
19 
ЧДТУ.252148.001 ПЗ 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ 
2.1 Моделювання предметної області 
Моделювання предметної області є першим і найважливішим кроком у 
проектуванні, оскільки воно дозволяє створити абстрактне, але точне уявлення про 
ключові сутності системи та їхні взаємозв'язки, незалежно від конкретної реалізації. 
2.1.1. Предметна область моделювання. Модель предметної області. Словник 
предметної області 
Предметна область моделювання для системи охоплює всі процеси та об'єкти, 
пов'язані з управлінням життєвим циклом звернень (тікетів) в організації. Вона 
включає взаємодію різних типів користувачів із системою, а також дані, які 
генеруються та обробляються в ході цієї взаємодії. 
Модель предметної області візуалізує основні концептуальні класи та їхні 
зв'язки. Для проекту ключовими концепціями є: Користувач (який може бути 
Клієнтом, Агентом або Адміністратором), Запит (Тікет), Коментар, Категорія та 
Статус. Модель показує, що Користувач створює Запити, Агент їх обробляє, до 
Запитів додаються Коментарі, кожен Запит належить до певної Категорії та має 
певний Статус. 
Словник предметної області формалізує термінологію, що використовується в 
проекті, для забезпечення однозначного розуміння всіма учасниками розробки. 
− Користувач (User): Зареєстрована в системі особа. Є узагальненням для 
більш специфічних ролей. 
− Клієнт (Client/User): Роль користувача, який має право створювати та 
переглядати власні запити. 
− Агент (Agent): Роль користувача, відповідального за обробку та вирішення 
запитів, що надходять від клієнтів. 
− Адміністратор (Admin): Роль користувача з найвищими привілеями, що 
керує всією системою, включаючи користувачів, агентів, категорії та налаштування. 
20 
ЧДТУ.252148.001 ПЗ 
− Запит (Ticket): Основна сутність системи; електронний документ, що фіксує 
звернення користувача. Має унікальний ідентифікатор, заголовок, опис, пріоритет, 
статус, категорію, автора та призначеного агента. 
− Коментар (Comment): Повідомлення, пов'язане з конкретним запитом, яке 
може бути додане як клієнтом, так і агентом. Коментарі можуть бути публічними або 
приватними (внутрішніми). 
− Категорія (Category): Класифікатор для групування запитів за тематикою 
(наприклад, "Технічна проблема", "Питання щодо оплати"). 
− Статус (Status): Атрибут запиту, що відображає його поточний стан у 
життєвому циклі (наприклад, "Новий", "В роботі", "Очікує відповіді", "Вирішено", 
"Закрито"). 
− Пріоритет (Priority): Атрибут запиту, що визначає терміновість його обробки 
(наприклад, "Низький", "Середній", "Високий"). 
− Вкладення (Attachment): Файл, прикріплений до запиту або коментаря для 
надання додаткового контексту. 
2.1.2. Елементи моделювання предметної області 
Для візуалізації моделі системи використовуються елементи мови UML. Згідно 
з методичними рекомендаціями, основними графічними символами є класи, актори, 
прецеденти, а також єднальні елементи, що позначають відношення між ними: 
асоціація, узагальнення, залежність, агрегація та композиція. Ці елементи дозволяють 
створювати різні типи діаграм для опису статичних та динамічних аспектів системи. 
Уніфікована мова моделювання (UML) є стандартним інструментом для 
візуалізації та проєктування програмних систем за допомогою графічних нотацій. В її 
основі лежать ключові елементи: актори (зовнішні користувачі), прецеденти 
(функціональні сценарії) та класи (шаблони об'єктів з атрибутами й методами). 
Комбінуючи ці символи, створюють діаграми, що описують як статичну 
структуру системи (наприклад, діаграми класів), так і її динамічну поведінку 
(діаграми прецедентів чи послідовності). Це дозволяє отримати повну й зрозумілу 
модель, що слугує надійним планом для розробки. 
21 
ЧДТУ.252148.001 ПЗ 
Рисунок 2.1 – Основні графічні символи UML[8] 
22 
ЧДТУ.252148.001 ПЗ 
Рисунок 2.2 – Єднальні елементи UML[8] 
23 
ЧДТУ.252148.001 ПЗ 
2.1.3. Робоча область моделювання 
Робоча область моделювання для проекту визначає межі системи та основні 
сутності, що підлягають автоматизації. Вона включає три основні групи користувачів 
(Клієнт, Агент, Адміністратор) та центральну сутність - Запит (Тікет), навколо якої 
будуються всі процеси. Модель предметної області на цьому етапі показує, що 
Адміністратор та Агент є спеціалізаціями Користувача. Користувач створює Запити, 
а Агент їх обробляє. Запит агрегує Коментарі та Вкладення, а також асоціюється з 
Категорією та Статусом. 
Рисунок 2.3 – Модель предметної області для обробки запитів зареєстрованих 
користувачів 
24 
ЧДТУ.252148.001 ПЗ 
2.2. Формування та аналіз вимог 
Цей етап перетворює потреби замовника та користувачів у чіткий, 
структурований набір вимог, що слугуватиме основою для подальшого проектування 
та тестування. 
2.2.1. Формування вимог до програмного забезпечення 
Вимоги до системи поділяються на функціональні, що описують, що система 
повинна робити, та нефункціональні, що описують, як вона повинна це робити. 
Функціональні вимоги (виведені з опису проекту ): 
− Вимоги до ролі "Користувач" (Клієнт): 
− FR1.1: Система повинна надавати можливість самостійної реєстрації. 
− FR1.2: Система повинна забезпечувати автентифікацію за логіном та 
паролем. 
− FR1.3: Система повинна надавати функцію відновлення пароля. 
− FR1.4: Користувач повинен мати можливість створювати новий запит, 
вказуючи категорію, пріоритет, заголовок, опис та прикріплюючи 
файли. 
− FR1.5: Користувач повинен мати доступ до перегляду списку лише 
своїх запитів з можливістю їх фільтрації. 
− FR1.6: Користувач повинен мати можливість додавати публічні 
коментарі до своїх запитів. 
− FR1.7: Користувач повинен мати можливість закрити свій запит, якщо 
проблема вирішена. 
− FR1.8: Користувач повинен отримувати сповіщення про зміну статусу 
його запиту. 
− Вимоги до ролі "Агент підтримки": 
− FR2.1: Агент повинен мати доступ до перегляду всіх запитів або тих, 
що призначені йому. 
− FR2.2: Агент повинен мати можливість взяти запит у роботу 
25 
ЧДТУ.252148.001 ПЗ 
(призначити собі). 
− FR2.3: Агент повинен мати можливість змінювати статус запиту. 
− FR2.4: Агент повинен мати можливість додавати як публічні, так і 
приватні (внутрішні) коментарі. 
− FR2.5: Агент повинен мати доступ до повної історії змін запиту. 
− Вимоги до ролі "Адміністратор": 
− FR3.1: Адміністратор повинен мати всі права та можливості ролі 
"Агент". 
− FR3.2: Адміністратор повинен мати можливість створювати, 
блокувати та редагувати облікові записи користувачів та агентів. 
− FR3.3: Адміністратор повинен мати можливість керувати системними 
довідниками (створювати, редагувати, видаляти категорії запитів). 
− FR3.4: Адміністратор повинен мати доступ до панелі зі статистикою 
та звітами (наприклад, середній час відповіді, кількість запитів за 
період). 
Нефункціональні вимоги: 
− NFR1 (Продуктивність): Час відповіді API на типові запити не повинен 
перевищувати 500 мс. Інтерфейс користувача має завантажуватися не довше 2 секунд. 
− NFR2 (Безпека): Взаємодія між клієнтом та сервером повинна відбуватися 
через захищений протокол HTTPS. Для автентифікації API-запитів повинен 
використовуватися механізм JWT (JSON Web Tokens). Система повинна бути 
захищена від основних веб-вразливостей (SQL Injection, XSS, CSRF), що 
забезпечується вбудованими засобами Django. 
− NFR3 (Надійність): Система повинна бути доступна 99.9% часу. Збої в 
одному з компонентів (наприклад, frontend) не повинні призводити до повної відмови 
системи. 
− NFR4 (Масштабованість): Архітектура повинна підтримувати горизонтальне 
масштабування шляхом запуску декількох екземплярів контейнерів з backend-
додатком за балансувальником навантаження. 
26 
ЧДТУ.252148.001 ПЗ 
− NFR5 (Сумісність): Веб-інтерфейс повинен коректно відображатися в 
останніх версіях популярних браузерів (Chrome, Firefox, Safari, Edge). 
2.2.2. Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (Use Case Diagram) візуалізує функціональні вимоги, 
показуючи взаємодію зовнішніх акторів із системою. 
− Актори: 
− Користувач: Базовий актор, що ініціює запити. 
− Агент: Спеціалізація (узагальнення) Користувача, що обробляє 
запити. 
− Адміністратор: Спеціалізація Агента з розширеними правами. 
− Основні прецеденти (Use Cases): 
− Управління обліковим записом: Включає прецеденти Зареєструватися, 
Увійти в систему, Відновити пароль. 
− Управління запитом: Основний прецедент, що ініціюється 
Користувачем. Включає (<<include>>) прецеденти Вибрати категорію, 
Вказати пріоритет, Додати опис, Прикріпити файл. 
− Перегляд запитів: Прецедент для Користувача (бачить свої) та Агента 
(бачить всі/призначені). 
− Обробка запиту: Прецедент для Агента. Розширюється (<<extend>>) 
прецедентами Змінити статус, Призначити агента. 
− Коментування запиту: Прецедент, доступний Користувачу та Агенту. 
− Управління користувачами: Прецедент, доступний лише 
Адміністратору. 
− Управління категоріями: Прецедент, доступний лише Адміністратору. 
− Перегляд статистики: Прецедент, доступний лише Адміністратору. 
Ця діаграма чітко розмежовує функціональні можливості для кожної 
ролі та слугує відправною точкою для проектування поведінки системи. 
27 
ЧДТУ.252148.001 ПЗ 
 
 
Рисунок 2.4 – Діаграма прецедентів для обробки запитів зареєстрованих 
користувачів 
2.3. Проектування логічної структури програмного комплексу 
На цьому етапі розробляється статична модель системи, що описує, з яких 
логічних елементів (класів, пакетів) вона складається та як вони пов'язані між собою. 
2.3.1. Діаграми класів 
Діаграма класів є центральним і одним із найважливіших інструментів в 
об'єктно-орієнтованому проєктуванні. Вона слугує статичним кресленням системи, 
візуалізуючи її архітектуру незалежно від часу. Ця діаграма не показує динаміку 
взаємодії, а натомість фокусується на логічній структурі, що робить її 
фундаментальною основою для розробників та аналітиків. Ось діаграма класів 
проєкту, яка представляє саме такий ранній етап розробки, де визначено ключові 
сутності та їхні відношення, але в них ще не додано специфічні атрибути та методи. 
28 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.5 Діаграма класів для обробки запитів зареєстрованих користувачів 
 
А ось це вже повністю готова діаграма з описом елементів нижче: 
Для проекту основні класи відповідають сутностям з предметної області. 
− Клас User: 
− Атрибути: id, username, password_hash, email, role (enum: 'user', 'agent', 
'admin'). 
− Методи: register(), login(), change_password(). 
− Клас Ticket: 
− Атрибути: id, title, description, status (enum), priority (enum), created_at, 
updated_at. 
− Методи: create(), update_status(), assign_agent(). 
− Клас Comment: 
− Атрибути: id, body, is_private (boolean), created_at. 
− Методи: create(). 
− Клас Category: 
29 
ЧДТУ.252148.001 ПЗ 
− Атрибути: id, name. 
− Клас Attachment: 
− Атрибути: id, file_path, file_name, mime_type. 
Відношення між класами: 
− User "створює" 1..* Ticket (Асоціація). 
− User (в ролі Агента) "обробляє" 0..* Ticket (Асоціація). 
− Ticket "належить до" 1 Category (Асоціація). 
− Ticket "містить" 0..* Comment (Композиція, оскільки коментар не існує без 
тікета). 
− Ticket "має" 0..* Attachment (Композиція). 
− Comment "має" 0..* Attachment (Композиція). 
− User "пише" 0..* Comment (Асоціація). 
 
Рисунок 2.6 Діаграма класів для обробки запитів зареєстрованих користувачів 
30 
ЧДТУ.252148.001 ПЗ 
2.3.2. Діаграми пакетів 
Для управління складністю великого проекту його логічна структура 
організується у пакети. Діаграма пакетів показує цю організацію та залежності між 
пакетами. Для проекту структура відповідає фізичній структурі проекту. 
− Пакет проекту (кореневий): 
− Пакет Backend: 
− Підпакет tickets: Містить класи, пов'язані з основною бізнес-логікою 
(Ticket, Comment, Category). 
− Підпакет users: Містить клас User та логіку автентифікації. 
− Підпакет api: Містить логіку серіалізації та представлення даних для 
REST API. Залежить від tickets та users. 
− Пакет Frontend: 
− Підпакет views: Компоненти, що відповідають за цілі сторінки 
(TicketListView, TicketDetailView). 
− Підпакет components: Менші, повторно використовувані UI-
компоненти (TicketItem, CommentForm). 
− Підпакет store: Логіка управління станом додатку (Pinia). 
− Підпакет services: Модулі для взаємодії з Backend API. 
− Залежності: Пакет Frontend залежить від пакета Backend (через API). 
 
 
Рисунок 2.6 - Діаграма пакетів для обробки запитів зареєстрованих користувачів 
31 
ЧДТУ.252148.001 ПЗ 
2.4. Архітектурне проектування 
Цей етап описує фізичну реалізацію системи: з яких компонентів вона 
складається і як ці компоненти розгортаються на апаратному забезпеченні. 
2.4.1. Діаграма компонентів 
Діаграма компонентів показує фізичні модулі системи та їхні залежності. Для 
даного проєкту вона відображає контейнеризовану архітектуру, де кожен компонент 
є окремим сервісом. Така візуалізація є ключовою для розуміння процесу розгортання 
системи та забезпечення можливості незалежного оновлення її частин. 
− Компонент queryflow-frontend: 
− Артефакт: Збірка статичних файлів Vue.js (dist/). 
− Надає інтерфейс: Web UI. 
− Потребує інтерфейс: Tickets REST API. 
− Компонент queryflow-backend: 
− Артефакт: Django-додаток (.py файли). 
− Надає інтерфейс: Tickets REST API. 
− Потребує інтерфейс: PostgreSQL Connection. 
− Компонент postgres-db: 
− Артефакт: Екземпляр СУБД PostgreSQL. 
− Надає інтерфейс: PostgreSQL Connection. 
− Компонент nginx: 
− Артефакт: Конфігурація Nginx. 
− Функції: Виступає як reverse proxy. Надає Web UI (сервірує статичні 
файли queryflow-frontend) та проксує запити до Tickets REST API 
компонента queryflow-backend. 
32 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.7 - Діаграма компонентів для обробки запитів зареєстрованих 
користувачів 
 
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Діаграма розгортання візуалізує фізичне розміщення програмних компонентів 
на апаратних вузлах. На ній зображуються апаратні елементи, такі як сервери, робочі 
станції чи мобільні пристрої, а також програмні артефакти - виконувані файли, 
бібліотеки або бази даних, що на них виконуються. Ця діаграма є незамінною для 
33 
ЧДТУ.252148.001 ПЗ 
планування системної архітектури, оскільки дозволяє оцінити вимоги до 
інфраструктури та зрозуміти, як система буде працювати в реальному середовищі. 
 
 
Рисунок 2.8 - Діаграма розгортання для обробки запитів зареєстрованих 
користувачів 
34 
ЧДТУ.252148.001 ПЗ 
− Вузол Application Server (тип: Server): 
− Розгорнутий артефакт: Docker Engine. 
− Вкладені вузли (контейнери): 
− Вузол nginx_container: 
− Розгорнутий артефакт: Компонент nginx. 
− Комунікація: Відкриває порт 80/443 для зовнішнього світу.  
З'єднаний з backend_container та frontend_container (через спільний volume). 
− Вузол backend_container: 
− Розгорнутий артефакт: Компонент queryflow-backend. 
− Комунікація: З'єднаний з db_container. 
− Вузол frontend_container: 
− Розгорнутий артефакт: Компонент queryflow-frontend. 
− Примітка: Цей контейнер використовується лише для збірки; його 
результат (статичні файли) монтується в nginx_container. 
− Вузол db_container: 
− Розгорнутий артефакт: Компонент postgres-db. 
− Комунікація: З'єднаний з backend_container. 
2.5. Моделювання поведінки системи 
Цей підрозділ описує динамічні аспекти системи - як вона поводиться з часом 
та як її об'єкти взаємодіють для виконання завдань. 
2.5.1. Діаграма діяльності 
Діаграма діяльності моделює потік робіт для складного процесу, візуально 
представляючи послідовність дій, точки прийняття рішень (розгалуження) та 
паралельні операції. Її перевага полягає у здатності наочно демонструвати складну 
логіку, що робить її схожою на блок-схему, але зі значно багатшими можливостями, 
зокрема, здатністю відображати паралельні потоки. Для проєкту буде змодельовано 
повний життєвий цикл обробки запиту. 
35 
ЧДТУ.252148.001 ПЗ 
Ця модель детально покаже всі етапи, починаючи від ініціації запиту системою, 
його валідації, обробки й аж до генерації кінцевої відповіді. Для чіткого розмежування 
зон відповідальності між різними компонентами системи будуть використані так звані 
«доріжки» (swimlanes), кожна з яких відповідатиме за свою частину процесу. Такий 
детальний підхід дозволить не лише чітко визначити логіку взаємодії та виявити 
потенційні вузькі місця, але й створить цінну документацію, яка слугуватиме 
орієнтиром для розробників та тестувальників. 
− Доріжки (Swimlanes): Клієнт, Система, Агент. 
− Потік: 
1 (Клієнт) Ініціює Створення запиту. 
2 (Система) Створює запит у стані "Новий", зберігає в БД, сповіщає агентів. 
3 (Агент) Переглядає чергу нових запитів. 
4 (Агент) Призначає запит собі. 
5 (Система) Змінює статус на "В роботі". 
6 (Агент) Аналізує запит. Можливе розгалуження: 
− Якщо потрібна додаткова інформація -> (Агент) Додає коментар із 
запитанням. (Система) Змінює статус на "Очікує відповіді", сповіщає 
клієнта. (Клієнт) Надає відповідь. Повернення до кроку 6. 
− Якщо проблема вирішена -> (Агент) Надає рішення у коментарі. 
(Система) Змінює статус на "Вирішено", сповіщає клієнта. 
7 (Клієнт) Переглядає рішення. Можливе розгалуження: 
− Якщо задоволений -> (Клієнт) Закриває запит. (Система) Змінює статус 
на "Закрито". Процес завершено. 
− Якщо не задоволений -> (Клієнт) Відкриває запит повторно. 
Повернення до кроку  
36 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.5 Діаграма діяльності для обробки запитів зареєстрованих 
користувачів 
37 
ЧДТУ.252148.001 ПЗ 
2.5.2. Діаграма послідовності 
Діаграма послідовності деталізує взаємодію об'єктів у часі для конкретного 
сценарію, фокусуючись на динамічній поведінці системи. Вона наочно показує, які 
саме об'єкти беруть участь у процесі, якими повідомленнями вони обмінюються, і в 
якій послідовності це відбувається згори донизу по осі часу. Цей тип діаграм є 
надзвичайно корисним для візуалізації логіки виконання окремого варіанта 
використання та для уточнення, які методи класів необхідно реалізувати.  
Розглянемо сценарій «Агент додає публічний коментар до запиту». У цій 
діаграмі ми зможемо відстежити весь ланцюжок викликів: від моменту, коли агент 
взаємодіє з інтерфейсом користувача, через обробку цієї дії відповідним контролером, 
і аж до створення нового об'єкта «Коментар» та його збереження в базі даних. 
− Лінії життя: :Агент, :VueApp (Frontend), :DjangoAPI (Backend), :Ticket 
(об'єкт моделі), :Comment (об'єкт моделі), :Database. 
− Послідовність повідомлень: 
1 Агент -> :VueApp: submitComment(ticketId, commentText) 
2 :VueApp -> :DjangoAPI: POST /api/tickets/{id}/comments/ 
3 :DjangoAPI -> :Ticket: find(id) 
4 :Ticket -> :Database: SELECT * FROM tickets_ticket WHERE id=... 
5 :Database -> :Ticket: ticketData 
6 :DjangoAPI -> :Comment: create(ticket, user, text) 
7 :Comment -> :Database: INSERT INTO tickets_comment... 
8 :Database -> :Comment: newCommentData 
9 :DjangoAPI -> :VueApp: 201 Created (newCommentData) 
10 :VueApp -> :Агент: displayNewComment() 
 
38 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.6 Діаграма послідовновстей для обробки запитів зареєстрованих 
користувачів 
 
2.5.3. Діаграма комунікації 
Ця діаграма, відома як діаграма комунікації, дійсно показує ті ж самі взаємодії, 
що й діаграма послідовності, оскільки обидві належать до діаграм взаємодії. Однак, її 
ключова відмінність полягає в акценті: замість фокусування на часовій послідовності 
39 
ЧДТУ.252148.001 ПЗ 
подій, вона робить наголос на структурних зв'язках та архітектурі взаємозв'язків між 
об'єктами. Порядок повідомлень тут вказується за допомогою нумерації, а не 
вертикального розташування, що дозволяє краще зрозуміти, які саме об'єкти 
безпосередньо спілкуються один з одним. Таким чином, якщо діаграма послідовності 
ідеально відповідає на питання "що і в який момент відбувається?", то діаграма 
комунікації краще ілюструє "хто з ким взаємодіє" у рамках статичної структури. 
Об'єкти: :Агент, :VueApp, :DjangoAPI, :Ticket, :Comment, :Database. 
− Зв'язки: Між :VueApp та :DjangoAPI, між :DjangoAPI та :Database. 
− Нумеровані повідомлення: 
1 submitComment(): від :Агент до :VueApp; 
2 POST /api/...: від :VueApp до :DjangoAPI; 
3 find(): від :DjangoAPI до :Ticket; 
4 SELECT...: від :Ticket до :Database. 
2.5.4. Діаграма скінченного автомату 
Ця діаграма моделює життєвий цикл об'єкта Ticket, показуючи його можливі 
стани та переходи між ними. 
− Стани: New, Open (призначений агенту), Pending (очікує відповіді клієнта), 
Resolved, Closed. 
− Початковий стан: ● -> New. 
− Переходи (тригер [умова] / дія): 
− New -> Open: assign_agent / notify_agent() 
− Open -> Pending: request_info / notify_client() 
− Pending -> Open: client_responds / notify_agent() 
− Open -> Resolved: provide_solution / notify_client() 
− Resolved -> Closed: client_confirms 
− Resolved -> Open: client_reopens / notify_agent() 
− Кінцевий стан: Closed -> ⊚. 
 
40 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.7 - Діаграма комунікації для обробки запитів зареєстрованих користувачів 
41 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 2.8 - Діаграма скінченого автомату для обробки запитів 
зареєстрованих користувачів 
42 
ЧДТУ.252148.001 ПЗ 
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ 
У другому розділі було виконано комплексне проектування програмного 
забезпечення згідно з вимогами, визначеними на попередньому етапі. Застосування 
уніфікованої мови моделювання (UML) дозволило створити повну та несуперечливу 
модель системи. Було детально змодельовано предметну область, що забезпечило 
чітке розуміння ключових сутностей. На основі функціональних вимог було 
побудовано діаграму прецедентів, що візуалізує взаємодію користувачів із системою. 
Логічна структура була деталізована за допомогою діаграм класів та пакетів, що 
визначають статичну архітектуру додатку. Фізична архітектура та принципи 
розгортання були описані за допомогою діаграм компонентів та розгортання, що 
відображають сучасний контейнеризований підхід. Динамічна поведінка системи 
була змодельована за допомогою діаграм діяльності, послідовності, комунікації та 
скінченного автомату, які детально описують ключові процеси та життєві цикли 
об'єктів. 
Таким чином, у цьому розділі створено вичерпний проектний blueprint, що 
слугує надійною основою для переходу до етапу розробки та тестування програмного 
забезпечення. 
43 
ЧДТУ.252148.001 ПЗ 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
Цей розділ присвячений практичній реалізації програмного комплексу на основі 
проектних рішень, розроблених у попередньому розділі. Тут детально описується 
процес розробки ключових компонентів системи, структура бази даних, інтерфейс 
користувача, а також методологія та результати всебічного тестування, що 
підтверджує якість та відповідність продукту поставленим вимогам. 
3.1. Розробка програмного комплексу 
Розробка програмного комплексу здійснювалася з використанням обраного 
технологічного стеку та відповідно до розробленої архітектури. Процес включав 
налаштування середовища, створення структури бази даних, реалізацію серверної та 
клієнтської логіки, а також їх інтеграцію. 
3.1.1. Обґрунтування вибору засобів реалізації 
Як було детально обґрунтовано в розділі 1.2, вибір технологічного стеку був 
зумовлений прагненням досягти оптимального балансу між швидкістю розробки, 
продуктивністю, надійністю та сучасними практиками інженерії програмного 
забезпечення. Коротко нагадаємо ключові рішення: 
− Backend: Django обрано за його MVT-архітектуру, вбудовані засоби безпеки 
та ORM, що ідеально підходить для структурованих, керованих даними додатків. 
− Frontend: Vue.js обрано за його прогресивність, низький поріг входження та 
збалансовану екосистему, що дозволяє швидко створювати інтерактивні 
односторінкові додатки (SPA). 
− База даних: PostgreSQL обрано за його надійність, відповідність стандартам 
ACID та розширену підтримку складних запитів, що є критичним для забезпечення 
цілісності даних у тікет-системі. 
44 
ЧДТУ.252148.001 ПЗ 
− Контейнеризація: Docker та Docker Compose застосовано для створення 
портативного, відтворюваного та легко розгортаного середовища, що є стандартом 
сучасної розробки. 
3.1.2. Опис структурної (функціональної) схеми 
Загальна архітектура системи реалізована за моделлю клієнт-сервер та 
розгорнута у вигляді набору взаємодіючих контейнерів. Структурна схема показує 
потік взаємодії компонентів: 
1 Клієнт (браузер користувача) надсилає HTTP-запити до системи. 
2 Веб-сервер Nginx виступає як єдина точка входу (reverse proxy). Він приймає 
всі запити. 
− Якщо запит стосується статичних файлів (HTML, CSS, JavaScript), 
Nginx віддає їх безпосередньо з зібраного frontend-додатку. 
− Якщо запит спрямований до API (наприклад, /api/...), Nginx проксує 
його до backend-додатку. 
3 Backend (Django) обробляє API-запити: виконує бізнес-логіку, валідує дані, 
взаємодіє з базою даних через ORM. 
4 База даних (PostgreSQL) зберігає всі дані системи: інформацію про 
користувачів, тікети, коментарі тощо. 
5 Frontend (Vue.js), завантажений у браузер клієнта, відповідає за 
відображення інтерфейсу, управління станом та асинхронну взаємодію з Backend API 
для отримання та відправки даних. 
6 Така структура забезпечує чітке розділення відповідальності між 
клієнтською та серверною частинами, що спрощує розробку, тестування та незалежне 
масштабування компонентів. 
45 
ЧДТУ.252148.001 ПЗ 
 
Рисунок 3.1 Структурна схема для обробки запитів зареєстрованих 
користувачів 
 
Рисунок 3.2 Функціональна схема для обробки запитів зареєстрованих користувачів 
46 
ЧДТУ.252148.001 ПЗ 
 
3.1.3. Опис логічної схеми системи 
Логічна схема описує послідовність дій при обробці типового запиту до 
системи. Розглянемо алгоритм обробки API-запиту на створення нового тікету: 
1 Початок: Користувач заповнює форму створення тікету в frontend-додатку 
та натискає "Створити"; 
2 Frontend: Vue-компонент збирає дані з форми, валідує їх на клієнтській 
стороні та формує об'єкт з даними; 
3 HTTP-запит: За допомогою бібліотеки Axios відправляється POST-запит на 
ендпоінт /api/tickets/ з JWT-токеном в заголовку Authorization; 
4 Nginx: Отримує запит, бачить шлях /api/ та проксує його до Django-додатку; 
5 Django Middleware: Перевіряє JWT-токен, автентифікує користувача та 
передає об'єкт request далі; 
6 Django URL Routing: Маршрутизатор співставляє шлях /api/tickets/ з 
відповідним View (класом-обробником); 
7 Django View (DRF): 
− Використовує TicketSerializer для десеріалізації та валідації отриманих 
даних. 
− Перевірка умови: Чи валідні дані? 
− Ні: Повертає відповідь з кодом 400 Bad Request та описом помилок 
валідації. Процес завершено. 
− Так: Продовження виконання. 
− Створює новий екземпляр моделі Ticket, пов'язуючи його з поточним 
користувачем (request.user). 
8 Django ORM: Формує SQL-запит INSERT до таблиці tickets_ticket; 
9 PostgreSQL: Виконує запит, зберігає новий запис та повертає його ID; 
10 Django View (DRF): Серіалізує новостворений об'єкт Ticket та повертає 
відповідь з кодом 201 Created та даними нового тікету у форматі JSON; 
47 
ЧДТУ.252148.001 ПЗ 
11 Nginx: Передає відповідь від Django клієнту; 
12 Frontend: Отримує успішну відповідь, оновлює стан додатку (додає новий 
тікет у список) та перенаправляє користувача на сторінку щойно створеного тікету; 
13 Кінець. 
 
 
Рисунок 3.3 Логічна схема 
48 
ЧДТУ.252148.001 ПЗ 
3.1.4. Розробка бази даних 
База даних спроектована в PostgreSQL з використанням Django ORM, що 
дозволяє описувати структуру таблиць у вигляді Python-класів (моделей) та 
автоматично генерувати міграції для зміни схеми. 
Структура ключових таблиць: 
 
Таблиця 3.1 
Таблиця users_customuser 
Таблиця users_customuser  
(спрощено) 
Поле Тип даних PostgreSQL 
id bigint (auto-increment) 
password varchar(128) 
username varchar(150) 
email varchar(254) 
role varchar(10) 
 
Таблиця 3.2 
Таблиця tickets_ticket 
Таблиця tickets_ticket  
Поле Тип даних PostgreSQL 
id bigint (auto-increment) 
 
49 
ЧДТУ.252148.001 ПЗ 
Продовження таблиці 3.2 
title varchar(255) 
Description text 
status varchar(20) 
priority varchar(20) 
created_at timestamp with time zone 
updated_at timestamp with time zone 
category_id bigint 
created_by_id bigint 
agent_id bigint (nullable) 
 
Зв'язки: 
− Один-до-багатьох: Один User може створити багато Ticket. Один Category 
може мати багато Ticket. 
− Багато-до-багатьох: Не використовуються в базовій моделі, але можуть 
бути додані для тегів. 
− Композиція (реалізована через зовнішні ключі): Ticket складається з 
Comment та Attachment. Видалення тікету призводить до каскадного видалення 
пов'язаних коментарів та вкладень. 
Управління міграціями здійснюється стандартними командами Django: docker-
compose exec backend python manage.py makemigrations для створення файлів міграцій 
та docker-compose exec backend python manage.py migrate для їх застосування до бази 
даних. 
 
50 
ЧДТУ.252148.001 ПЗ 
3.1.5. Розробка інтерфейсу користувача 
Інтерфейс користувача розроблено як односторінковий додаток (SPA) на Vue 3. 
Архітектура побудована на основі компонентів, що забезпечує перевикористання 
коду та легкість підтримки. 
− Структура компонентів: 
− views: Компоненти-контейнери, що відповідають за цілі сторінки 
(наприклад, DashboardView.vue, TicketDetailView.vue, LoginView.vue). 
Вони відповідають за завантаження даних та передачу їх дочірнім 
компонентам. 
− components: Презентаційні компоненти, що відповідають за 
відображення окремих елементів UI (наприклад, TicketList.vue для 
списку тікетів, TicketForm.vue для форми створення/редагування, 
CommentSection.vue для коментарів). 
− Маршрутизація (Routing): Використовується Vue Router для навігації між 
сторінками без перезавантаження. Кожен маршрут (наприклад, /tickets/:id) пов'язаний 
з відповідним компонентом з views. 
− Управління станом (State Management): Використовується Pinia для 
централізованого зберігання стану додатку (інформація про поточного користувача, 
список тікетів, стан завантаження). Це дозволяє компонентам легко обмінюватися 
даними та реагувати на їх зміни. 
− Взаємодія з API: Створено окремий сервісний шар (наприклад, 
api/ticketService.js) з використанням Axios для інкапсуляції всієї логіки HTTP-запитів 
до backend. 
Інтерфейс спроектовано з урахуванням ролей: залежно від ролі користувача, в 
UI відображаються або приховуються певні елементи (наприклад, кнопки 
"Призначити агента" або "Керувати користувачами"). 
3.1.6. Опис розробки програмних компонентів 
Backend (Django): 
51 
ЧДТУ.252148.001 ПЗ 
Основна логіка реалізована в додатку tickets. 
− models.py: Описує моделі даних Ticket, Comment, Category як Python-класи, 
що наслідуються від django.db.models.Model. Django ORM автоматично перетворює їх 
у таблиці БД. 
− serializers.py: Використовуючи Django REST Framework (DRF), створено 
серіалізатори (TicketSerializer, CommentSerializer), які перетворюють складні типи 
даних (екземпляри моделей Django) у JSON для передачі через API, і навпаки. 
− views.py: Містить ViewSets (наприклад, TicketViewSet) від DRF, які 
автоматично надають стандартні CRUD-операції (Create, Retrieve, Update, Delete) для 
моделей через API ендпоінти. Тут же реалізована логіка доступу: наприклад, при 
запиті списку тікетів перевіряється роль користувача, і якщо це не агент, то 
повертаються лише тікети, створені цим користувачем. 
− urls.py: Налаштовує маршрутизацію API, пов'язуючи URL-адреси 
(наприклад, /api/tickets/) з відповідними ViewSets. 
Containerization (Docker): 
Ключовим компонентом розробки є файл docker-compose.yml, що описує всю 
інфраструктуру додатку.1 
− db service: Запускає офіційний образ PostgreSQL, створює том для 
персистентного зберігання даних та встановлює змінні середовища для назви БД, 
користувача та пароля. 
− backend service: Збирає образ на основі Dockerfile у директорії backend. 
Встановлює залежності з requirements.txt, запускає Django-сервер (Gunicorn), 
встановлює залежність від сервісу db (щоб backend стартував тільки після бази даних) 
та прокидає змінні середовища для підключення до БД. 
− frontend service: Використовується для збірки Vue.js додатку. 
− nginx service: Запускає офіційний образ Nginx, копіює кастомний nginx.conf, 
який налаштовує проксування API-запитів до backend сервісу та роздачу статичних 
файлів, зібраних frontend сервісом. 
52 
ЧДТУ.252148.001 ПЗ 
Цей підхід дозволяє запустити весь комплексний додаток однією командою 
docker-compose up --build, що є надзвичайно ефективним для розробки та розгортання. 
3.2. Тестування системи 
Тестування є невід'ємним етапом життєвого циклу розробки, що гарантує якість, 
надійність та відповідність програмного продукту вимогам. Для проекту було 
застосовано багаторівневу стратегію тестування. 
3.2.1. Модульне тестування 
На цьому рівні перевіряються найменші ізольовані частини коду - окремі 
функції або методи класів. 
− Backend: Використовувався вбудований у Django тестовий фреймворк, що 
базується на unittest. Наприклад, для моделі Ticket було написано тест, що перевіряє 
коректність роботи методу зміни статусу: створюється об'єкт тікету, викликається 
метод change_status('closed'), а потім перевіряється, що поле status об'єкта дійсно має 
значення 'closed'. 
− Frontend: Використовувався фреймворк Vitest. Наприклад, для компонента 
TicketForm.vue було написано тест, що перевіряє логіку валідації: симулюється 
введення некоректних даних (наприклад, порожній заголовок) і перевіряється, що 
компонент відображає відповідне повідомлення про помилку. 
3.2.2. Інтеграційне тестування 
На цьому етапі перевіряється взаємодія між окремими модулями. 
− Backend-Database: Тестувалася коректність роботи Django ORM. Наприклад, 
створювався тікет через модель, а потім робився прямий запит до тестової БД для 
перевірки, що запис з'явився з правильними даними. 
− Frontend-Backend: Тестувалася взаємодія клієнтської частини з API. За 
допомогою інструментів, таких як msw (Mock Service Worker), симулювалися 
відповіді від API, і перевірялося, що frontend-компоненти коректно їх обробляють та 
відображають дані. Також проводилося тестування реальних API-ендпоінтів: 
53 
ЧДТУ.252148.001 ПЗ 
наприклад, відправлявся запит на створення тікету і перевірялося, що сервер повертає 
код 201 та дані нового тікету. 
3.2.3. Системне тестування 
Системне тестування перевіряє весь додаток як єдине ціле на відповідність 
функціональним вимогам. Воно проводилося шляхом виконання наскрізних сценаріїв 
(end-to-end tests). 
− Приклад сценарію "Повний життєвий цикл тікету": 
1 Користувач (тестер) реєструється в системі. 
2 Користувач логіниться та створює новий тікет. 
3 Адміністратор (тестер) логіниться, бачить новий тікет та призначає 
його агенту. 
4 Агент (тестер) логіниться, бачить призначений йому тікет, додає 
коментар та змінює статус на "Вирішено". 
5 Користувач отримує сповіщення, заходить у тікет, бачить коментар та 
новий статус, після чого закриває тікет. 
6 Перевіряється, що тікет має фінальний статус "Закрито". 
3.2.4. Приймальне тестування 
На цьому етапі система передається кінцевим користувачам (або їх 
представникам) для підтвердження, що вона відповідає їхнім очікуванням та є 
зручною у використанні. 
− Методологія: Було залучено фокус-групу з кількох студентів, яким було 
видано інструкції та завдання, що відповідають функціоналу кожної ролі (створити 
тікет, відповісти на нього, керувати користувачем). 
− Збір зворотного зв'язку: Після виконання завдань було проведено 
опитування щодо зручності інтерфейсу, зрозумілості функцій та загального враження 
від роботи системи. Отриманий фідбек (наприклад, пропозиції щодо покращення UI) 
було задокументовано для подальших ітерацій розробки. 
 
54 
ЧДТУ.252148.001 ПЗ 
Зведена таблиця результатів тестування 
Таблиця 3.3 
Таблиця результатів тестувування 
Етап Тестовий Очікуваний Фактичний 
Статус 
тестування випадок результат результат 
Модульне Тестування Метод Метод Пройдено 
моделі повертає повернув True. 
Ticket: True для 
метод тікету зі 
is_closed() статусом 
'closed'. 
Модульне Тестування При Повідомлення Пройдено 
компонента порожньом про помилку 
LoginForm. у полі відобразилося. 
vue: "пароль" 
валідація з'являється 
повідомлен
ня про 
помилку. 
Інтеграційне Запит GET API API повернув Пройдено 
/api/tickets/ повертає список тікетів 
від список у форматі 
автентифіко тікетів JSON, статус 
ваного (статус 200. 
агента 200). 
 
 
55 
ЧДТУ.252148.001 ПЗ 
Продовження таблиці 3.3 
Інтеграційне Запит POST API API повернув Пройдено 
/api/tickets/ з повертає статус 400 з 
невалідним помилку описом 
и даними валідації помилок. 
(статус 
400). 
Системне Сценарій Користувач Сценарій Пройдено 
створення створює виконано 
та тікет, успішно, тікет 
призначенн адміністрат коректно 
я тікету ор відображаєтьс
призначає я у всіх ролей 
його агенту, на відповідних 
агент етапах. 
бачить тікет 
у своїй 
черзі. 
Приймальне Завдання Користувач Користувач Пройдено 
для може успішно 
користувача успішно виконав 
: "Створити створити завдання, 
запит з запит та зазначивши 
вкладенням прикріпити зручність 
" до нього інтерфейсу. 
файл. 
 
56 
ЧДТУ.252148.001 ПЗ 
3.3. Приклади впровадженого програмного комплексу 
Цей підрозділ демонструє роботу реалізованого програмного комплексу 
проекту за допомогою скріншотів ключових екранів та сценаріїв використання. 
1 Сторінка входу та реєстрації: Користувач бачить лаконічну форму для 
входу в систему або переходу до реєстрації нового облікового запису; 
2 Головна панель користувача: Після входу користувач потрапляє на 
головну панель, де відображається список його запитів. Інтерфейс містить кнопки для 
створення нового запиту та фільтрації існуючих за статусом; 
3 Форма створення нового запиту: При натисканні на кнопку "Створити 
запит" відкривається модальне вікно або окрема сторінка з полями для введення 
заголовку, детального опису (з підтримкою форматування тексту), вибору категорії та 
пріоритету зі спадних списків, а також поле для завантаження файлів; 
4 Головна панель агента: Інтерфейс агента схожий на панель користувача, 
але відображає всі запити в системі з можливістю фільтрації за статусом, пріоритетом 
та призначеним агентом. Агент бачить, які тікети ще не призначені, і може взяти будь-
який з них у роботу; 
5 Сторінка детального перегляду запиту: Це центральний екран для роботи 
з тікетом. Тут відображається вся інформація про запит: опис, статус, пріоритет, 
автор, призначений агент. Нижче розташована стрічка коментарів, де ведеться вся 
комунікація. Агент має можливість змінювати статус та пріоритет запиту, а також 
додавати публічні або приватні коментарі; 
6 Панель адміністратора: Адміністратор має доступ до спеціального розділу, 
де може переглядати список всіх користувачів системи, редагувати їхні дані 
(наприклад, роль), блокувати або видаляти акаунти. Також тут знаходиться інтерфейс 
для управління категоріями запитів. 
Ці візуальні приклади підтверджують, що розроблений інтерфейс є 
функціональним, інтуїтивно зрозумілим та відповідає вимогам, поставленим для 
кожної з ролей. 
 
57 
ЧДТУ.252148.001 ПЗ 
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ 
У третьому розділі було успішно виконано практичну реалізацію та валідацію 
програмного забезпечення. На основі проектних рішень з другого розділу було 
розроблено повноцінний програмний комплекс, що включає серверну частину на 
Django, клієнтську на Vue.js, та базу даних PostgreSQL, об'єднані в єдину систему за 
допомогою Docker. Було детально описано ключові аспекти розробки: структуру бази 
даних, реалізацію моделей та API на сервері, компонентну архітектуру клієнтського 
додатку та налаштування контейнеризації. Наведені приклади інтерфейсу 
демонструють зручність та функціональність системи для всіх визначених ролей 
користувачів. Проведена багаторівнева процедура тестування - від модульного до 
приймального -підтвердила високу якість, надійність та коректність роботи системи. 
Всі основні функціональні та нефункціональні вимоги було виконано. Таким чином, 
розроблений програмний комплекс є завершеним продуктом, що повністю відповідає 
поставленим у кваліфікаційній роботі завданням і готовий до впровадження в реальне 
експлуатаційне середовище. 
 
58 
ЧДТУ.252148.001 ПЗ 
ВИСНОВКИ 
У рамках даної кваліфікаційної роботи було успішно досягнуто поставленої 
мети - спроектовано, розроблено та протестовано сучасне програмне забезпечення для 
обробки запитів зареєстрованих користувачів. Робота охопила повний цикл інженерії 
програмного забезпечення, від аналізу предметної області до створення готового до 
впровадження продукту. 
У першому розділі було проведено глибокий аналіз ринку систем управління 
запитами, що дозволило визначити ключові функціональні вимоги та обґрунтувати 
актуальність створення власного рішення. Детальний порівняльний аналіз технологій 
став основою для вибору сучасного та збалансованого стеку (Django, Vue.js, 
PostgreSQL, Docker), що забезпечує гнучкість, продуктивність та легкість супроводу 
системи. 
Другий розділ був присвячений комплексному проектуванню системи з 
використанням об'єктно-орієнтованого підходу та уніфікованої мови моделювання 
(UML). Було розроблено повний набір діаграм, що детально описують статичну 
структуру, фізичну архітектуру та динамічну поведінку системи. Це дозволило 
створити чіткий та несуперечливий технічний проект, що став надійною основою для 
подальшої розробки. 
У третьому розділі було детально описано процес практичної реалізації 
програмного комплексу. Було реалізовано серверну частину з REST API, 
інтерактивний клієнтський інтерфейс та спроектовано реляційну базу даних. 
Особливу увагу було приділено застосуванню технології контейнеризації Docker, що 
забезпечило портативність та відтворюваність середовища розробки та розгортання. 
Проведений чотирирівневий цикл тестування підтвердив, що розроблене програмне 
забезпечення є надійним, функціональним та відповідає всім поставленим вимогам. 
Результатом виконаної кваліфікаційної роботи є повноцінний, масштабований 
та готовий до використання програмний продукт.Він може слугувати ефективним 
інструментом для автоматизації процесів підтримки в організаціях, пропонуючи 
59 
ЧДТУ.252148.001 ПЗ 
гнучку та економічно вигідну альтернативу існуючим комерційним та відкритим 
рішенням. Проведені етапи аналізу, проектування, розробки та тестування 
демонструють високий рівень інженерної підготовки та підтверджують, що створений 
програмний комплекс повністю відповідає вимогам до кваліфікаційної роботи 
бакалавра. 
 
60 
  
ДОДАТОК А 
 
 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
 
 
 
 
 
 Програмне забезпечення для обробки запитів зареєстрованих користувачів 
 
 
Специфікація 
482 ЧДТУ. 252148-019  
Листів 2 
 
 
Розробник ________________ Бабушко О.В. 
Керівник ________________ Салапатов В.І. 
 
 
 
 
 
 
Черкаси 2025 
 
2 
ЧДТУ.252148.001 
Позначення Найменування Примітки 
482 ЧДТУ. 252148 12 01 Текст програми  
482 ЧДТУ. 252148 34 01 Інструкція користувачеві  
482 ЧДТУ. 252148 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
76 
     
ДОДАТОК Б 
  
  
  
  
  
  
Програмне забезпечення для обробки запитів зареєстрованих користувачів  
  
  
Текст програми 
482 ЧДТУ. 252148 12 01 
Листів 22 
  
  
 
 
  
 Розробник                     ________________  Бабушко О.В.  
 
 
 
 
 
 
 
 
 
Черкаси 2025
 
 482 ЧДТУ. 252148 12 01  2 
Лістинг файлу docker-compose.yml 
version: "3.8" 
services: 
  db: 
    image: postgres:15 
    environment: 
      POSTGRES_DB: queryflow 
      POSTGRES_USER: user 
      POSTGRES_PASSWORD: pass 
    volumes: 
      - ./pgdata:/var/lib/postgresql/data 
 
  backend: 
    build: ./backend 
    command: gunicorn backend.wsgi:application --bind 
0.0.0.0:8000 
    volumes: 
      - ./backend:/app 
    env_file: 
      - ./backend/.env 
    depends_on: 
      - db 
    expose: 
      - 8000 
 
  frontend: 
    build: ./frontend 
    ports: 
      - "8000:80" 
    depends_on: 
      - backend 
Лістинг файлу backend/tickets/models.py 
from django.contrib.auth.models import AbstractUser 
from django.db import models
78 
 482 ЧДТУ. 252148 12 01  3 
 
class User(AbstractUser): 
    ROLE_CHOICES = 
(('user','User'),('agent','Agent'),('admin','Admin')) 
    role = models.CharField(max_length=10, 
choices=ROLE_CHOICES, default='user') 
 
class Category(models.Model): 
    name = models.CharField(max_length=100) 
 
class Ticket(models.Model): 
    STATUS_CHOICES = 
(('new','Новий'),('open','Відкритий'),('in_progress','В 
роботі'),('awaiting_user','Очікує 
відповіді'),('resolved','Вирішено'),('closed','Закрито')) 
    subject = models.CharField(max_length=200) 
    category = models.ForeignKey(Category, 
on_delete=models.SET_NULL, null=True) 
    description = models.TextField() 
    priority = models.CharField(max_length=20, blank=True) 
    status = models.CharField(max_length=20, 
choices=STATUS_CHOICES, default='new') 
    creator = models.ForeignKey(User, 
related_name='tickets', on_delete=models.CASCADE) 
    agent = models.ForeignKey(User, 
related_name='assigned_tickets', null=True, blank=True, 
on_delete=models.SET_NULL) 
    created_at = models.DateTimeField(auto_now_add=True) 
    updated_at = models.DateTimeField(auto_now=True) 
    uid = models.CharField(max_length=20, unique=True, 
blank=True) 
 
    def save(self, *args, **kwargs): 
        if not self.uid: 
            from datetime import datetime
79 
 482 ЧДТУ. 252148 12 01  4 
            year = str(datetime.now().year) 
            number = Ticket.objects.count() + 1 
            self.uid = f'#{year}-{number:03d}' 
        super().save(*args, **kwargs) 
 
class Comment(models.Model): 
    ticket = models.ForeignKey(Ticket, 
on_delete=models.CASCADE, related_name='comments') 
    author = models.ForeignKey(User, 
on_delete=models.CASCADE) 
    body = models.TextField() 
    is_private = models.BooleanField(default=False) 
    created_at = models.DateTimeField(auto_now_add=True)' 
 
Лістинг файлу C:\Projects\queryflow\backend\tickets\views.py 
from rest_framework import viewsets, permissions 
from .models import Ticket, Comment 
from .serializers import TicketSerializer, 
CommentSerializer 
 
class TicketViewSet(viewsets.ModelViewSet): 
    queryset = Ticket.objects.all().order_by('-
created_at') 
    serializer_class = TicketSerializer 
 
    def get_permissions(self): 
        if self.action in ["list", "retrieve"]: 
            return [permissions.IsAuthenticated()] 
        if self.action in ["create"]: 
            return [permissions.IsAuthenticated()] 
        return [permissions.IsAdminUser()] 
 
    def get_queryset(self): 
        user = self.request.user
80 
 482 ЧДТУ. 252148 12 01  5 
        if user.is_staff or hasattr(user, "is_agent") and 
user.is_agent: 
            return Ticket.objects.all().order_by("-
created_at") 
        return 
Ticket.objects.filter(user=user).order_by("-created_at") 
 
    def perform_create(self, serializer): 
        serializer.save(user=self.request.user, 
status="Новий") 
 
class CommentViewSet(viewsets.ModelViewSet): 
    queryset = 
Comment.objects.all().order_by('created_at') 
    serializer_class = CommentSerializer 
 
    def get_queryset(self): 
        ticket_id = 
self.request.query_params.get('ticket') 
        qs = Comment.objects.all().order_by('created_at') 
        if ticket_id: 
            qs = qs.filter(ticket_id=ticket_id) 
        return qs 
 
    def perform_create(self, serializer): 
        serializer.save(user=self.request.user) 
 
Лістинг файлу C:\Projects\queryflow\backend\backend/settings.py 
import os 
from pathlib import Path 
 
BASE_DIR = Path(__file__).resolve().parent.parent 
SECRET_KEY = os.environ.get('SECRET_KEY', 'change_me') 
DEBUG = True 
ALLOWED_HOSTS = ['*']
81 
 482 ЧДТУ. 252148 12 01  6 
INSTALLED_APPS = [ 
    
'django.contrib.admin','django.contrib.auth','django.contrib.c
ontenttypes', 
    
'django.contrib.sessions','django.contrib.messages','django.co
ntrib.staticfiles', 
    
'rest_framework','rest_framework.authtoken','djoser','corshead
ers','tickets', 
    "corsheaders" 
] 
MIDDLEWARE = [ 
    'corsheaders.middleware.CorsMiddleware', 
    'django.middleware.security.SecurityMiddleware', 
    
'django.contrib.sessions.middleware.SessionMiddleware', 
    'django.middleware.common.CommonMiddleware', 
    'django.middleware.csrf.CsrfViewMiddleware', 
    
'django.contrib.auth.middleware.AuthenticationMiddleware', 
    
'django.contrib.messages.middleware.MessageMiddleware', 
    
'django.middleware.clickjacking.XFrameOptionsMiddleware', 
] 
TEMPLATES = [ 
    { 
        "BACKEND": 
"django.template.backends.django.DjangoTemplates", 
        "DIRS": [], 
        "APP_DIRS": True, 
        "OPTIONS": { 
            "context_processors": [
82 
 482 ЧДТУ. 252148 12 01  7 
                
"django.template.context_processors.debug", 
                
"django.template.context_processors.request", 
                
"django.contrib.auth.context_processors.auth", 
                
"django.contrib.messages.context_processors.messages", 
            ], 
        }, 
    }, 
] 
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField' 
ROOT_URLCONF = 'backend.urls' 
STATIC_URL = '/static/' 
AUTH_USER_MODEL = 'tickets.User' 
REST_FRAMEWORK = { 
    'DEFAULT_AUTHENTICATION_CLASSES': 
('rest_framework_simplejwt.authentication.JWTAuthentication',)
, 
    'DEFAULT_PERMISSION_CLASSES': 
('rest_framework.permissions.IsAuthenticated',), 
} 
CORS_ALLOW_ALL_ORIGINS = True 
DATABASES = { 
    'default': { 
        'ENGINE': 'django.db.backends.postgresql', 
        'NAME': os.environ.get('POSTGRES_DB', 
'queryflow'), 
        'USER': os.environ.get('POSTGRES_USER', 'user'), 
        'PASSWORD': os.environ.get('POSTGRES_PASSWORD', 
'pass'), 
        'HOST': os.environ.get('DB_HOST', 'db'), 
        'PORT': 5432, 
    }
83 
 482 ЧДТУ. 252148 12 01  8 
Лістинг файлу C:\Projects\queryflow\frontend\src\api\auth.js 
import axios from "axios"; 
const API_URL = import.meta.env.VITE_API_URL || 
"http://localhost/api/"; 
export async function login(username, password) { 
  const res = await axios.post( 
    `${API_URL.replace(/\/$/, "")}/auth/jwt/create/`, 
    { username, password } 
  ); 
  return res.data; // { access, refresh } 
} 
export async function registerUser({ username, email, 
password }) { 
  return ( 
    await axios.post(`${API_URL}users/register/`, { 
      username, 
      email, 
      password, 
    }) 
  ).data; 
} 
 
export function setToken(token) { 
  localStorage.setItem("token", token); 
} 
 
export function getToken() { 
  return localStorage.getItem("token"); 
} 
 
export function logout() { 
  localStorage.removeItem("token"); 
} 
Лістинг файлу C:\Projects\queryflow\frontend\src\api\tickets.js 
import axios from "axios";
84 
 482 ЧДТУ. 252148 12 01  9 
const API_URL = import.meta.env.VITE_API_URL || 
"http://localhost/api/"; 
 
function authHeaders() { 
  const token = localStorage.getItem("token"); 
  return token ? { Authorization: `Bearer ${token}` } : {}; 
} 
 
export async function getTickets() { 
  return (await axios.get(`${API_URL}tickets/`, { headers: 
authHeaders() })).data; 
} 
 
export async function createTicket(data) { 
  return (await axios.post(`${API_URL}tickets/`, data, { 
headers: authHeaders() })).data; 
} 
 
export async function updateTicket(id, data) { 
  return (await axios.patch(`${API_URL}tickets/${id}/`, 
data, { headers: authHeaders() })).data; 
} 
 
export async function getComments(ticket_id) { 
  return (await 
axios.get(`${API_URL}comments/?ticket=${ticket_id}`, { 
headers: authHeaders() })).data; 
} 
 
export async function createComment(data) { 
  return (await axios.post(`${API_URL}comments/`, data, { 
headers: authHeaders() })).data; 
} 
85 
 482 ЧДТУ. 252148 12 01  10 
Лістинг файлу 
C:\Projects\queryflow\frontend\src\components\adminpanel.vue 
<template> 
  <div style="padding:2rem;"> 
    <h1>Панель адміністратора</h1> 
    <nav style="margin-bottom:2rem;"> 
      <button @click="view = 'stats'">Дашборд</button> 
      <button @click="view = 'users'">Користувачі</button> 
      <button @click="view = 'agents'">Агенти</button> 
      <button @click="view = 
'categories'">Категорії</button> 
    </nav> 
    <div v-if="view === 'stats'"> 
      <AdminStats /> 
    </div> 
    <div v-else-if="view === 'users'"> 
      <AdminUsers /> 
    </div> 
    <div v-else-if="view === 'agents'"> 
      <AdminAgents /> 
    </div> 
    <div v-else-if="view === 'categories'"> 
      <AdminCategories /> 
    </div> 
  </div> 
</template> 
 
<script setup> 
import { ref } from "vue"; 
import AdminStats from "./admin/AdminStats.vue"; 
import AdminUsers from "./admin/AdminUsers.vue"; 
import AdminAgents from "./admin/AdminAgents.vue"; 
import AdminCategories from "./admin/AdminCategories.vue" 
const view = ref("stats");
86 
 482 ЧДТУ. 252148 12 01  11 
 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
AgentTicketDetail.vue 
<template> 
  <div style="background:#f7fafc; padding:2rem; border-
radius:12px; margin-top:32px; box-shadow:0 0 8px #eaeaea; 
position:relative;"> 
    <button @click="$emit('close')" 
style="position:absolute;right:20px;top:20px;">×</button> 
    <h3>Тікет #{{ ticket.code || ticket.id }}</h3> 
    <p><b>Тема:</b> {{ ticket.title }}</p> 
    <p><b>Статус:</b> 
      <select v-model="status" @change="updateStatus"> 
        <option>Новий</option> 
        <option>В роботі</option> 
        <option>Очікує відповіді</option> 
        <option>Вирішено</option> 
        <option>Закрито</option> 
      </select> 
    </p> 
    <p><b>Опис:</b> {{ ticket.description || "—" }}</p> 
    <h4>Публічні коментарі</h4> 
    <ul> 
      <li v-for="(c, i) in publicComments" :key="i"> 
        <b>{{ c.author }}:</b> {{ c.text }} 
      </li> 
    </ul> 
    <form @submit.prevent="addPublicComment" 
style="margin-bottom:12px;"> 
      <input v-model="publicComment" placeholder="Новий 
коментар..." required /> 
      <button type="submit">Додати</button> 
    </form> 
    <details> 
      <summary>Внутрішні (приватні) нотатки</summary>
87 
 482 ЧДТУ. 252148 12 01  12 
 
      <ul> 
        <li v-for="(c, i) in privateComments" :key="i"> 
          <b>{{ c.author }}:</b> {{ c.text }} 
        </li> 
      </ul> 
      <form @submit.prevent="addPrivateComment" 
style="margin-top:8px;"> 
        <input v-model="privateComment" placeholder="Нова 
нотатка..." required /> 
        <button type="submit">Додати</button> 
      </form> 
    </details> 
  </div> 
</template> 
<script setup> 
import { ref } from "vue"; 
const props = defineProps(["ticket"]); 
const status = ref(props.ticket.status); 
const publicComments = ref([ 
  { author: "Іван", text: "В чому причина?" } 
]); 
const privateComments = ref([ 
  { author: "agent1", text: "Треба перевірити логін." } 
]); 
const publicComment = ref(""); 
const privateComment = ref(""); 
 
function updateStatus() { 
  // TODO: API для оновлення статусу 
  props.ticket.status = status.value; 
  // Еміт для оновлення у головному списку 
  emit("status-updated", { id: props.ticket.id, status: 
status.value }); 
}
88 
 482 ЧДТУ. 252148 12 01  13 
 
const emit = defineEmits(["close", "status-updated"]); 
 
function addPublicComment() { 
  publicComments.value.push({ author: "agent1", text: 
publicComment.value }); 
  publicComment.value = ""; 
} 
function addPrivateComment() { 
  privateComments.value.push({ author: "agent1", text: 
privateComment.value }); 
  privateComment.value = ""; 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
AgentTickets.vue 
<template> 
  <div style="max-width: 1050px; margin: 40px auto;"> 
    <h2 style="text-align:center;">Усі тікети 
користувачів</h2> 
    <input v-model="search" placeholder="Пошук по темі..." 
style="width:300px; margin-bottom:20px;"/> 
    <table style="width:100%;"> 
      <thead> 
        <tr> 
          <th>№</th> 
          <th>Тема</th> 
          <th>Статус</th> 
          <th>Автор</th> 
          <th>Призначено</th> 
          <th>Дата</th> 
          <th></th> 
        </tr> 
      </thead> 
      <tbody>
89 
 482 ЧДТУ. 252148 12 01  14 
        <tr v-for="t in filteredTickets" :key="t.id"> 
          <td>{{ t.code || t.id }}</td> 
          <td>{{ t.title }}</td> 
          <td>{{ t.status }}</td> 
          <td>{{ t.user }}</td> 
          <td>{{ t.agent ? t.agent : '—' }}</td> 
          <td>{{ t.created_at ? t.created_at.slice(0,10) : 
'' }}</td> 
          <td> 
            <button v-if="!t.agent" 
@click="assignTicket(t)">Взяти в роботу</button> 
            <button 
@click="selectTicket(t)">Переглянути</button> 
          </td> 
        </tr> 
      </tbody> 
    </table> 
    <AgentTicketDetail v-if="selectedTicket" 
:ticket="selectedTicket" @close="selectedTicket=null" @status-
updated="onStatusUpdated" /> 
  </div> 
</template> 
<script setup> 
import { ref, computed, onMounted } from "vue"; 
import { getTickets, updateTicket } from "../api/tickets"; 
import AgentTicketDetail from "./AgentTicketDetail.vue"; 
 
const tickets = ref([]); 
const selectedTicket = ref(null); 
const search = ref(""); 
 
onMounted(async () => { 
  tickets.value = await getTickets(); 
});
90 
 482 ЧДТУ. 252148 12 01  15 
const filteredTickets = computed(() => 
  tickets.value.filter( 
    t => 
t.title.toLowerCase().includes(search.value.toLowerCase()) 
  ) 
); 
 
async function assignTicket(ticket) { 
  const updated = await updateTicket(ticket.id, { agent: 
"agent1", status: "В роботі" }); // Тут треба вставити ID агента 
з auth 
  ticket.agent = updated.agent; 
  ticket.status = updated.status; 
} 
 
function selectTicket(ticket) { 
  selectedTicket.value = { ...ticket }; 
} 
function onStatusUpdated({ id, status }) { 
  const t = tickets.value.find(tt => tt.id === id); 
  if (t) t.status = status; 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
CommentList.vue 
<template> 
  <div style="margin-top: 1rem;"> 
    <h4>Коментарі</h4> 
    <ul> 
      <li v-for="c in comments" :key="c.id"> 
        <b>{{ c.user || 'Користувач' }}:</b> {{ c.text }} 
      </li> 
    </ul>
91 
 482 ЧДТУ. 252148 12 01  17 
    <form @submit.prevent="addComment"> 
      <input v-model="commentText" placeholder="Новий 
коментар..." required style="width:70%" /> 
      <button type="submit">Додати</button> 
    </form> 
  </div> 
</template> 
<script setup> 
import { ref, onMounted } from "vue"; 
import { getComments, createComment } from 
"../api/tickets"; 
const props = defineProps(["ticketId"]); 
const comments = ref([]); 
const commentText = ref(""); 
 
onMounted(async () => { 
  comments.value = await getComments(props.ticketId); 
}); 
 
async function addComment() { 
  const newComment = await createComment({ ticket: 
props.ticketId, text: commentText.value }); 
  comments.value.push(newComment); 
  commentText.value = ""; 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
LoginForm.vue 
<template> 
  <form @submit.prevent="onLogin" style="max-width: 320px; 
margin: 40px auto; padding: 2rem; box-shadow: 0 0 12px #ddd; 
border-radius: 12px;"> 
    <h2 style="text-align:center;">Вхід у систему</h2>
92 
 482 ЧДТУ. 252148 12 01  18 
 
    <input v-model="username" placeholder="Логін" required 
style="width:100%;margin:8px 0;padding:8px;" /> 
    <input v-model="password" type="password" 
placeholder="Пароль" required style="width:100%;margin:8px 
0;padding:8px;" /> 
    <button type="submit" :disabled="loading" 
style="width:100%;margin:12px 0;padding:10px;">Увійти</button> 
    <p v-if="error" style="color:red;text-
align:center;">{{ error }}</p> 
    <p style="text-align:center; margin-
top:16px;"><router-link 
to="/register">Зареєструватися</router-link></p> 
  </form> 
</template> 
<script setup> 
import { ref } from "vue"; 
import { useAuthStore } from "../store/auth"; 
import { useRouter } from "vue-router"; 
 
const username = ref(""); 
const password = ref(""); 
const error = ref(""); 
const loading = ref(false); 
 
const auth = useAuthStore(); 
const router = useRouter(); 
 
async function onLogin() { 
  error.value = ""; 
  loading.value = true; 
  try { 
    await auth.loginAction(username.value, 
password.value); 
    router.push("/");
93 
 482 ЧДТУ. 252148 12 01  18 
 
  } catch (e) { 
    error.value = "Невірний логін або пароль"; 
  } 
  loading.value = false; 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
RegisterForm.vue 
<template> 
  <form @submit.prevent="onRegister" style="max-
width:340px;margin:50px auto;padding:2rem;box-shadow:0 0 14px 
#e9ebfa;border-radius:12px;"> 
    <h2 style="text-align:center;">Реєстрація</h2> 
    <input v-model="username" placeholder="Логін" required 
style="width:100%;margin:8px 0;padding:8px;" /> 
    <input v-model="email" type="email" 
placeholder="Email" required style="width:100%;margin:8px 
0;padding:8px;" /> 
    <input v-model="password" type="password" 
placeholder="Пароль" required style="width:100%;margin:8px 
0;padding:8px;" minlength="6" /> 
    <button type="submit" :disabled="loading" 
style="width:100%;margin:12px 
0;padding:10px;">Зареєструватися</button> 
    <p v-if="error" style="color:red;text-
align:center;">{{ error }}</p> 
    <p v-if="success" style="color:green;text-
align:center;">Акаунт створено! <router-link 
to="/login">Увійти</router-link></p> 
  </form> 
</template> 
<script setup> 
import { ref } from "vue"; 
import { registerUser } from "../api/auth";
94 
 482 ЧДТУ. 252148 12 01  19 
 
const username = ref(""); 
const email = ref(""); 
const password = ref(""); 
const error = ref(""); 
const loading = ref(false); 
const success = ref(false); 
 
async function onRegister() { 
  error.value = ""; 
  loading.value = true; 
  try { 
    await registerUser({ username: username.value, email: 
email.value, password: password.value }); 
    success.value = true; 
    username.value = email.value = password.value = ""; 
  } catch (e) { 
    error.value = e.response?.data?.username?.[0] || 
e.response?.data?.email?.[0] || "Помилка реєстрації"; 
  } 
  loading.value = false; 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
TicketCreate.vue 
<template> 
  <form @submit.prevent="submit" style="padding: 1rem; 
border: 1px solid #eee; border-radius: 10px; margin-bottom: 
20px;"> 
    <h3>Новий тікет</h3> 
    <input v-model="title" placeholder="Тема" required 
style="width:100%;margin:8px 0;padding:8px;" /> 
    <select v-model="category" required 
style="width:100%;margin:8px 0;padding:8px;"> 
      <option disabled value="">Оберіть категорію</option>
95 
 482 ЧДТУ. 252148 12 01  20 
 
      <option value="Технічна">Технічна</option> 
      <option value="Загальна">Загальна</option> 
    </select> 
    <textarea v-model="description" placeholder="Опис 
проблеми" required style="width:100%;margin:8px 
0;padding:8px;"></textarea> 
    <button type="submit">Відправити</button> 
    <span v-if="success" style="color:green; margin-left: 
10px;">Тікет створено!</span> 
  </form> 
</template> 
<script setup> 
import { ref } from "vue"; 
const emit = defineEmits(["created"]); 
const title = ref(""); 
const category = ref(""); 
const description = ref(""); 
const success = ref(false); 
 
async function submit() { 
  emit("created", { 
    title: title.value, 
    category: category.value, 
    description: description.value, 
  }); 
  success.value = true; 
  title.value = category.value = description.value = ""; 
  setTimeout(() => (success.value = false), 1500); 
} 
</script> 
Лістинг файлу C:\Projects\queryflow\frontend\src\components\ 
TicketDashboard.vue 
<template> 
  <div style="max-width: 900px; margin: 40px auto;">
96 
 482 ЧДТУ. 252148 12 01  21 
 
    <h2 style="text-align:center;">Мої тікети</h2> 
    <button @click="showCreate = !showCreate" 
style="margin-bottom: 20px;"> 
      {{ showCreate ? "Закрити форму" : "Створити новий 
тікет" }} 
    </button> 
    <TicketCreate v-if="showCreate" 
@created="onTicketCreated" /> 
    <table style="width:100%;margin-top:10px;"> 
      <thead> 
        <tr> 
          <th>№</th> 
          <th>Тема</th> 
          <th>Статус</th> 
          <th>Дата</th> 
          <th></th> 
        </tr> 
      </thead> 
      <tbody> 
        <tr v-for="t in tickets" :key="t.id"> 
          <td>{{ t.code || t.id }}</td> 
          <td>{{ t.title }}</td> 
          <td>{{ t.status }}</td> 
          <td>{{ t.created_at ? t.created_at.slice(0,10) : 
'' }}</td> 
          <td> 
            <button 
@click="selectTicket(t)">Переглянути</button> 
          </td> 
        </tr> 
      </tbody> 
    </table> 
    <TicketDetail v-if="selectedTicket" 
:ticket="selectedTicket" @close="selectedTicket=null" />
97 
 482 ЧДТУ. 252148 12 01  22 
 
  </div> 
</template> 
<script setup> 
import { ref, onMounted } from "vue"; 
import { getTickets, createTicket } from "../api/tickets"; 
import TicketCreate from "./TicketCreate.vue"; 
import TicketDetail from "./TicketDetail.vue"; 
 
const tickets = ref([]); 
const showCreate = ref(false); 
const selectedTicket = ref(null); 
 
onMounted(async () => { 
  tickets.value = await getTickets(); 
 
}); 
onMounted(async () => { 
  const data = await getTickets(); 
  console.log("Тікети з API:", data); 
  tickets.value = data; 
}); 
 
 
async function onTicketCreated(data) { 
  showCreate.value = false; 
  const ticket = await createTicket(data); 
  tickets.value.unshift(ticket); 
} 
function selectTicket(ticket) { 
  selectedTicket.value = ticket; 
} 
</script> 
 
98 
ДОДАТОК В 
 
 
 
 
 
 
 Програмне забезпечення для обробки запитів зареєстрованих користувачів 
 
 
Інструкція користувача 
482 ЧДТУ. 252148 34 01 
Листів 3 
 
 
Розробник ________________ Бабушко О.В. 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2025
99 
 
1 
482 ЧДТУ. 252148 34 01 
1. Вступ 
Ця інструкція призначена для користувачів системи обробки запитів. 
Система надає різний функціонал залежно від вашої ролі: Користувач, Агент або 
Адміністратор. 
2. Для Користувачів (Клієнтів) 
− Реєстрація та вхід: 
− Перейдіть на головну сторінку системи. 
− Натисніть "Зареєструватися", заповніть необхідні поля та 
підтвердіть створення акаунту. 
− Для входу в систему використовуйте свій логін та пароль. 
− Створення запиту: 
− На головній панелі натисніть "Створити запит". 
− Заповніть поля: заголовок, опис, виберіть категорію та 
пріоритет. 
− За потреби прикріпіть файли. 
− Натисніть "Створити". 
− Перегляд та коментування запитів: 
− На головній панелі ви побачите список ваших запитів. 
− Натисніть на заголовок запиту, щоб перейти на його сторінку. 
− Ви можете переглянути історію коментарів та додати свій у 
відповідному полі. 
− Закриття запиту: 
− Якщо вашу проблему вирішено, на сторінці запиту натисніть 
кнопку "Закрити запит". 
3. Для Агентів підтримки 
− Робота з чергою запитів: 
− На головній панелі ви бачите список всіх запитів. 
Використовуйте фільтри для сортування.
100 
 
2 
482 ЧДТУ. 252148 34 01 
− Щоб взяти запит у роботу, відкрийте його та натисніть 
"Призначити мені". 
− Обробка запиту: 
− На сторінці запиту ви можете змінювати його статус та 
пріоритет. 
− Додавайте публічні коментарі (видимі для клієнта) або 
приватні (видимі лише для інших агентів). 
− Вирішення запиту: 
− Коли проблему вирішено, надайте остаточну відповідь у 
коментарі та змініть статус на "Вирішено". 
4. Для Адміністраторів 
− Функціонал Агента: Ви маєте доступ до всіх можливостей ролі 
"Агент". 
− Управління користувачами: 
− Перейдіть у розділ "Адміністрування" -> "Користувачі". 
− Тут ви можете створювати нових користувачів, редагувати їхні 
дані (включаючи роль) та блокувати акаунти. 
− Управління категоріями: 
− Перейдіть у розділ "Адміністрування" -> "Категорії". 
− Тут ви можете створювати, редагувати та видаляти категорії 
запитів. 
101 
 
 
ДОДАТОК Г 
 
 
 
 
 
 
 Програмне забезпечення для обробки запитів зареєстрованих користувачів 
 
 
Графічні матеріали 
482 ЧДТУ. 252148 90 01 
Листів 8 
 
 
Розробник ________________ Бабушко О.В. 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2025
99 
 
 482 ЧДТУ. 252148 90 01 2 
 В Л           РОБОТ     Т  У
 ПРОГР       Б  П Ч     ДЛ 
ОБРОБ     П Т В
  Р  СТРОВ      ОР СТУВ Ч В
 добувач  Бабушко О.В.
 ерівник  Салапатов В. .
 
Рисунок Г1 – Слайд 1 
 
ВСТУП
                                                                                                          
                                                                                                         
                                                                          
                                                                                                 
                                                                                                          
                                                              
                                                                                                         
                                 
                                                                                                      
                                                                                                          
                                                                                                   
                                                                                                       
                                                                                                
                                                       
                                                                                                            
                                
                                                                                                     
                              
 
Рисунок Г2 – Слайд 2 
100 
 
 482 ЧДТУ. 252148 90 01 3 
                                          
            
                                   
          
                                                                      
                                                                        
                                                        
                                                                        
                                  
           
                                                    
      
                                                
                                                             
                              
               
        
              
        
            
                                                                               
                                              
                                  
       
 
Рисунок Г3 – Слайд 3 
 
                      
                                                                                              
                                                                                              
                                                                                             
                                                                                                
                                                                                                
                                                                            
                                                                                        
                                                                                            
                                                                                       
                                                                                  
                                                                                 
                                                                                      
                                                                                       
                                
 
Рисунок Г4 – Слайд 4 
101 
 
 482 ЧДТУ. 252148 90 01 4 
                   
 
Рисунок Г6 – Слайд 6 
 
              
 
Рисунок Г7 – Слайд 7 
102 
 
 482 ЧДТУ. 252148 90 01 5 
                   
 
Рисунок Г8 – Слайд 8 
 
                   
 
Рисунок Г9 – Слайд 9 
103 
 
 482 ЧДТУ. 252148 90 01 6 
                    
 
Рисунок Г10 – Слайд 10 
 
                          
 
Рисунок Г11 – Слайд 11 
104 
 
 482 ЧДТУ. 252148 90 01 7 
          
                                              
                                                                                         
                                                                                                 
                                                                                
                                                                                                  
                                                                                                   
                                    
                     
                                                                                                
                                                                                            
                                                                                              
                         
                                                                                                 
                                                                                                
                                                
                                                                                              
                                                                                              
           
                                                                                              
                                                                                               
         
 
Рисунок Г12 – Слайд 12 
 
        
                                                                                      
                                                                                          
                      
                               
                                                                                           
                                                                 
                                                                                           
                     
                                                                                              
                                                                                              
                       
                                                                                            
                                                                                      
       
 
Рисунок Г13 – Слайд 13
105 
 
 482 ЧДТУ. 252148 90 01 8 
                
 
Рисунок Г14 – Слайд 14 
 
106