Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/8858Full metadata record
| DC Field | Value | Language |
|---|---|---|
| dc.contributor.advisor | Півень, Олександр Борисович | - |
| dc.contributor.author | Хвостик, Артур Олександрович | - |
| dc.date.accessioned | 2026-03-19T19:39:08Z | - |
| dc.date.available | 2026-03-19T19:39:08Z | - |
| dc.date.issued | 2024-12-18 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/8858 | - |
| dc.description.abstract | АНОТАЦІЯ Хвостик Артур Олександрович студент спеціальності 121 «Інженерія програмного забезпечення» Представлено кваліфікаційну роботу бакалавра на тему – Програмне забезпечення системи управління заявками для зв’язку з працівниками технічного відділу підприємства» в Черкаському державному технологічному університеті у місті Черкаси в 2024 році. Кваліфікаційна робота бакалавра присвячена розробці програмного забезпечення для системи управління заявками, призначеної для організації та поліпшення комунікації з технічним відділом підприємства. Системи, побудована на сучасних технологіях, таких як ReactJS, Node JS, та MongoDB, забезпечує високий рівень продуктивності, надійності та масштабованості, що дозволяє ефективно обробляти значні обсяги даних і швидко реагувати на запити користувачів. Клієнтська частина програми створена з використанням ReactJS, що забезпечує інтуїтивний інтерфейс для зручності користувачів. Серверна частина, побудована на платформі Node JS, дозволяє швидко обробляти запити, а використання MongoDB для зберігання даних забезпечує надійне і безпечне управління інформацією. Функціонал системи включає можливості створення, обробки та відстеження заявок із різними статусами і рівнями доступу, що забезпечує безпеку та контроль над конфіденційною інформацією. Багаторівнева система доступу дозволяє ефективно розподіляти права користувачів відповідно до їхніх ролей, що значно підвищує безпеку і надійність роботи з даними. Особлива увага приділена зручності інтерфейсу та автоматизації процесів для полегшення взаємодії з системою. Реалізація даного рішення сприяє підвищенню ефективності роботи технічного відділу, дозволяє швидко обробляти заявки та зменшувати час, необхідний для вирішення технічних питань. | uk_UA |
| dc.description.abstract | ANNOTATION Khvostyk Artur Oleksandrovych, student of specialty 121 "Software Engineering" А bachelor's qualification work on the topic - Аpplication management system software for communication with employees of the technical department of the enterprise" ah the Cherkasy State Technological University in the city of Cherkasy in 2024 is presented. The bachelor's qualification work is devoted to the development of a software system for a management requests, designed to organize and enhance communication with an enterprise’s technical department., Built with modern technologies, including ReactJS, Node JS, and MongoDB, the system provides high performance, reliability, and scalability, allowing effecient processing of large data volumes and quick responses to user requests. The client side of the application, created using ReactJS, ensures an intuitive interface for ease of use, while the server side developed with he Node JS quickly process requests, MongoDB is used for secure and reliable data management and storage. The system’s functionality includes request creation, processing, and tracking, with various statuses and access levels to ensure data security and confidentiality. A multi-level access system effectively allocates user permissions according to their roles, enhancing the security and reliability of data handling. Special attention is given to the interface’s usability and the automation of processes to simplify user interaction with the system. Implementation this solution improves the efficiency of the technical department by enabling fast request processing and reducing the time needed to resolve technical issues. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ | uk_UA |
| dc.subject | MongoDB | uk_UA |
| dc.subject | EXPRESS.JS | uk_UA |
| dc.subject | REACT.JS | uk_UA |
| dc.subject | NODE.JS | uk_UA |
| dc.subject | СИСТЕМА ОБРОБКИ ЗАЯВОК | uk_UA |
| dc.subject | SOFTWARE DEVELOPMENT | uk_UA |
| dc.subject | MongoDB | uk_UA |
| dc.subject | EXPRESS.JS | uk_UA |
| dc.subject | REACT.JS | uk_UA |
| dc.subject | NODE.JS | uk_UA |
| dc.subject | TICKET SYSTEM | uk_UA |
| dc.title | Програмне забезпечення системи управління заявками для зв'язку з працівниками технічного відділу підприємства | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Хвостик Артур Олександрович.pdf Restricted Access | 5.11 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Програмне забезпечення системи управління заявками для зв'язку з
працівниками технічного відділу підприємства
Студент Хвостик А. О.
(прізвище та ініціали)
Керівник Півень О. Б.
(прізвище та ініціали)
Рецензент Федонюк В.В.
(прізвище та ініціали)
Черкаси 2024
B Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» ______________ 2024 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Хвостик Артур Олександрович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмне забезпечення системи управління заявками для зв'язку з
працівниками технічного відділу підприємства
Керівник проекту (роботи) Півень Олександр Борисович к.ф.-м.н. доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «14» 10 2024
року № 305/04
2.Строк подання студентом проекту (роботи) 17.12.2024
3. Вхідні дані до проекту (роботи) 1) Платформа x86-64, 2) Мова програмування JavaScript
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результатів дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3. Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки А, Додатки Б, Додатки В.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Додатки В - Графічний матеріал.
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання вересень 2024 р.
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 04.09.2024 виконано
2 Підготовка завдання 09.09.2024 виконано
3 Погодження завдання 11.09.2024 виконано
4 Затвердження завдання 14.09.2024 виконано
Основна стадія
1 Підбір матеріалів 21.09.2024 виконано
2 Аналіз шляхів вирішення поставленої задачі 23.09.2024 виконано
3 Розрахунок основних параметрів роботи 31.09.2024 виконано
4 Вибір кінцевого варіанту проектного рішення 08.10.2024 виконано
5 Оформлення первісної редакції роботи 11.10.2024 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 28.10.2024 виконано
керівником
2 Оформлення пояснювальної записки роботи в 08.11.2024 виконано
кінцевій редакції
3 Попередній захист роботи 05.12.2024 виконано
4 Затвердження роботи 06.12.2024 виконано
5 Рецензування роботи 15.12.2024 виконано
6 Захист роботи 17.12.2024
Студент _____________________ Хвостик А.О.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Півень О.Б.
(підпис) (прізвище та ініціали)
ЗМІСТ
ВСТУП ........................................................................................................................... 5
РОЗДІЛ 1 ІСНУЮЧУ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАДАЧ ........................................................................................................................... .7
1.1 Опис існуючих методів на засобів використаних при розробці .................... 7
1.2 Аналіз існуючих аналогів програми ................................................................. 8
1.3 Постановка задач ............................................................................................... 11
Висновки до розділу 1 ............................................................................................ 13
РОЗДІЛ 2 ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ 14
2.1 Моделювання предметної області ................................................................... 14
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області .............................................................................................. 14
2.1.2 Елементи моделювання предметної області ........................................... 16
2.1.3 Робоча область моделювання ................................................................... 19
2.2 Формування та аналіз вимог ............................................................................ 21
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги ................................................................................................................... 21
2.2.2 Формування вимог за допомогою діаграми прецедентів....................... 23
2.3 Проектування логічної структури програмного комплексу ......................... 25
2.3.1 Діаграми класів ........................................................................................... 25
2.3.2 Діаграми пакетів ......................................................................................... 28
2.4 Архітектурне проектування ............................................................................. 29
2.4.1 Діаграма компонентів ................................................................................ 29
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання .......................................................................................................... 30
ЧДТУ 241923.025 ПЗ
З м Лис № Докум. Підпис Дат
.Р озрт об Хвостик А.О. а
«Програмне забезпечення системи управління Л іт. Лист Листів
К. ерівник П івень О.Б.
заявками для зв'язк у з працівниками
технічного відділу підприємства» ФІТІС, Кафедра ПЗАС, ПЗ-
Н .контр Півень О.Б.
(Пояснюваль на записка) 2104
.З атв . Голуб С.В.
А
2.5 Моделювання поведінки системи .................................................................... 31
2.5.3 Діаграма діяльності .................................................................................... 31
2.5.3 Діаграма послідовності .............................................................................. 34
2.5.3 Діаграма комунікації .................................................................................. 35
2.5.4 Діаграма скінченного автомату ................................................................ 37
Висновки до розділу 2…………………………………………………………….....38
РОЗДІЛ 3 РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ .................................. 39
3.1 Розробка програмного комплексу ................................................................... 39
3.1.1 Обґрунтування вибору засобів реалізації ................................................ 39
3.1.2 Опис структурної (функціональної) схеми ............................................. 42
3.1.3 Опис логічної схеми системи .................................................................... 46
3.1.4 Розробка бази даних ................................................................................... 48
3.1.5 Розробка інтерфейсу користувача ............................................................ 50
3.1.6 Опис розробки програмних компонентів ................................................ 55
3.2 Тестування системи .......................................................................................... 57
3.2.1 Модульне тестування ................................................................................. 57
3.2.2 Інтеграційне тестування ............................................................................ 60
3.2.3 Системне тестування ................................................................................. 62
3.2.4 Приймальне тестування ............................................................................. 63
3.3 Приклади впровадженого програмного комплексу ....................................... 65
Виснвоки до розділу 3…………………………………………………………… ...66
ВИСНОВКИ ................................................................................................................. 68
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................... 69
ДОДАТКИ .................................................................................................................... 71
Лист
ЧДТУ 241923.025 ПЗ
З м. Лист № док. Підпис Дата
АНОТАЦІЯ
Хвостик Артур Олександрович студент спеціальності 121 «Інженерія
програмного забезпечення» Представлено кваліфікаційну роботу бакалавра на
тему – Програмне забезпечення системи управління заявками для зв’язку з
працівниками технічного відділу підприємства» в Черкаському державному
технологічному університеті у місті Черкаси в 2024 році.
Кваліфікаційна робота бакалавра присвячена розробці програмного
забезпечення для системи управління заявками, призначеної для організації та
поліпшення комунікації з технічним відділом підприємства. Системи,
побудована на сучасних технологіях, таких як ReactJS, Node JS, та MongoDB,
забезпечує високий рівень продуктивності, надійності та масштабованості, що
дозволяє ефективно обробляти значні обсяги даних і швидко реагувати на
запити користувачів. Клієнтська частина програми створена з використанням
ReactJS, що забезпечує інтуїтивний інтерфейс для зручності користувачів.
Серверна частина, побудована на платформі Node JS, дозволяє швидко
обробляти запити, а використання MongoDB для зберігання даних забезпечує
надійне і безпечне управління інформацією.
Функціонал системи включає можливості створення, обробки та
відстеження заявок із різними статусами і рівнями доступу, що забезпечує
безпеку та контроль над конфіденційною інформацією. Багаторівнева система
доступу дозволяє ефективно розподіляти права користувачів відповідно до
їхніх ролей, що значно підвищує безпеку і надійність роботи з даними.
Особлива увага приділена зручності інтерфейсу та автоматизації процесів для
полегшення взаємодії з системою. Реалізація даного рішення сприяє
підвищенню ефективності роботи технічного відділу, дозволяє швидко
обробляти заявки та зменшувати час, необхідний для вирішення технічних
питань.
Ключові слова: РОЗРОБЕП ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ,
MongoDB, EXPRESS.JS, REACT.JS, NODE.JS СИСТЕМА ОБРОБКИ ЗАЯВОК
ANNOTATION
Khvostyk Artur Oleksandrovych, student of specialty 121 "Software
Engineering" А bachelor's qualification work on the topic - Аpplication management
system software for communication with employees of the technical department of
the enterprise" ah the Cherkasy State Technological University in the city of
Cherkasy in 2024 is presented.
The bachelor's qualification work is devoted to the development of a software
system for a management requests, designed to organize and enhance communication
with an enterprise’s technical department., Built with modern technologies, including
ReactJS, Node JS, and MongoDB, the system provides high performance, reliability,
and scalability, allowing effecient processing of large data volumes and quick
responses to user requests. The client side of the application, created using ReactJS,
ensures an intuitive interface for ease of use, while the server side developed with he
Node JS quickly process requests, MongoDB is used for secure and reliable data
management and storage.
The system’s functionality includes request creation, processing, and tracking,
with various statuses and access levels to ensure data security and confidentiality. A
multi-level access system effectively allocates user permissions according to their
roles, enhancing the security and reliability of data handling. Special attention is
given to the interface’s usability and the automation of processes to simplify user
interaction with the system. Implementation this solution improves the efficiency of
the technical department by enabling fast request processing and reducing the time
needed to resolve technical issues.
Keywords: SOFTWARE DEVELOPMENT, MongoDB, EXPRESS.JS,
REACT.JS, NODE.JS TICKET SYSTEM
ЧДТУ 241923.025 ПЗ
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ
API - Application Programming Interface (Інтерфейс
програмування застосунків)
CRUD - Create, Read, Update, Delete (Створення, Читання,
Оновлення, Видалення)
UI - User Interface (Інтерфейс користувача)
UX - User Experience (Досвід користувача)
JSON - JavaScript Object Notation (Нотація об'єктів
JavaScript)
JWT - JSON Web Token (Веб-токен у форматі JSON)
REST - Representational State Transfer (Передача стану
представлення)
SQL - Not Only SQL (Не тільки SQL)
DOM - Document Object Model (Об'єктна модель
документа)
ЧДТУ 241923.025 ПЗ
ВСТУП
Актуальність теми
Актуальність теми визначається потребою у розробці програмного
забезпечення системи управління заявками полягає в потребі автоматизації
процесів технічної підтримки, що дозволяє уникнути затримок у вирішенні
проблем, покращити організацію робочого часу технічного персоналу та
підвищити рівень обслуговування. Сучасні підприємства часто стикаються з
необхідністю ефективного управління технічними запитами, які виникають у
співробітників. Наявність централізованої системи управління заявками
забезпечує швидкий і чіткий зв'язок з технічним відділом, що підвищує
продуктивність роботи та мінімізує простої.
Мета роботи
Метою розробки є розробка програмного забезпечення для потреб
користувачів шляхом управління заявками технічним відділом підприємства,
що забезпечує швидку і зручну взаємодію між співробітниками підприємства та
технічним відділом.
Завдання розробки
Завданням є розробка програмного забезпечення:
аналіз вимог до системи;
проєктування структури і функціоналу;
реалізація програмного забезпечення;
тестування та налагодження системи.
Об'єктом розробки
Об’єктом розробки є система управління заявками для технічного відділу
підприємства, яка включає функціонал подачі, обробки та моніторингу заявок.
Предмет розробки
Предметом розробки є процеси побудови програмного забезпечення для
системи управління заявками для взаємодії між співробітниками підприємства
та технічним відділом. Система включає функціональні модулі, що
6
ЧДТУ 241923.025 ПЗ
забезпечують подачу заявок, моніторинг їхнього статусу та обробку запитів
технічними працівниками.
Методи проєктування та конструювання
Для розробки програмного забезпечення використані методи об'єктно-
орієнтованого програмування, а також принципи модульного проектування та
структурного підходу. Система спроектована з використанням сучасних
фреймворків та мов програмування, що забезпечують гнучкість,
масштабованість і зручність її подальшої підтримки.
Опис отриманих реузльтатів
Розроблено комплексне програмне забезпечення, яке дозволяє
користувачам подавати заявки на технічну підтримку, а технічному персоналу
ефективно їх обробляти, відслідковувати статуси виконання та взаємодіяти з
іншими учасниками процесу. Розроблена система пройшла тестування і
відповідає вимогам функціональності та надійності.
Практичне значення отриманих результатів
Розроблене програмне забезпечення дозволить скоротити час обробки
заявок, підвищити якість підтримки, зменшити адміністративне навантаження
на технічний відділ та забезпечити більш ефективний розподіл ресурсів.
Особистий внесок автора У процесі виконання роботи самостійно
проведено аналіз вимог до системи, здійснено проєктування структури та
функціоналу, реалізовано програмне забезпечення, а також виконано
тестування системи, що свідчить про високий рівень залученості в процес
розробки та глибоке розуміння теми.
7
ЧДТУ 241923.025 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Опис існуючих методів на засобів використаних при розробці
Для розробки системи управління заявками технічного відділу було
використано сучасні інструменти та бібліотеки, що сприяють забезпеченню
високої функціональності, масштабованості та зручності обміну даними між
клієнтською і серверною частинами додатку.
Клієнтська частина (FrontEnd) реалізована з використанням фреймворку
ReactJS, який дозволяє створювати інтерфейс користувача з можливістю
динамічного оновлення. Для обміну даними з сервером застосовано бібліотеку
axios, яка забезпечує обробку HTTP-запитів. Оформлення інтерфейсу
реалізовано за допомогою бібліотеки Material-UI та фреймворків Bootstrap і
React-Bootstrap, що дозволяють створювати сучасний вигляд додатку.
Інтеграція високоякісних елементів інтерфейсу забезпечується бібліотекою
DevExtreme. Для роботи з токенами аутентифікації використовується jwt-
decode, що дає змогу обробляти JSON Web Token [1]. Для управління
навігацією між сторінками застосовується бібліотека react-router-dom, яка
оптимізує переходи всередині додатку [2].
Для зберігання даних використано MongoDB Atlas, хмарне рішення, що
забезпечує надійне зберігання великих обсягів інформації з високою
продуктивністю. Як NoSQL база даних, MongoDB зберігає дані у вигляді JSON-
документів, що зручно для роботи з JavaScript-орієнтованими інструментами на
сервері та клієнті [3].
Серверна частина (BackEnd) побудована на платформі NodeJS з
використанням фреймворку Express, що дозволяє організувати серверну логіку
та обробку HTTP-запитів. Для створення і перевірки JSON Web Token
використовується бібліотека jsonwebtoken, що гарантує захищений доступ до
системи. Хешування паролів реалізоване за допомогою бібліотеки bcrypt, що
підвищує рівень безпеки конфіденційних даних. Для обробки завантаження
8
ЧДТУ 241923.025 ПЗ
файлів застосовується бібліотека multer, а для роботи з файловою системою
сервера використовуються бібліотеки path та fs. Налаштування політик доступу
для взаємодії між сервером та клієнтами з різних доменів здійснюється через
бібліотеку cors, а обробка тіла HTTP-запитів у форматі JSON – через body-
parser. Взаємодія з базою даних MongoDB організована за допомогою
бібліотеки mongoose, яка дозволяє ефективно керувати збереженням інформації
через використання схем даних.
Застосування цих інструментів і технологій забезпечує створення
надійної, зручної у використанні системи управління заявками, що відповідає
вимогам сучасних бізнес-процесів.
1.2 Аналіз існуючих аналогів програми
Система управління заявками для технічного відділу підприємства є
критично важливою для забезпечення своєчасного обслуговування, підтримки
ефективної роботи персоналу та оптимізації витрат часу на обробку запитів. У
процесі розробки такого програмного забезпечення важливо врахувати наявний
досвід та рішення, які вже використовуються іншими компаніями. Аналіз
існуючих аналогів дозволяє визначити ефективні функції та механізми
автоматизації, що можуть бути запозичені та адаптовані до специфічних потреб
підприємства.
Для всебічного порівняння аналогів було виділено кілька основних
критеріїв, що допомагають оцінити рівень функціональності, зручності та
економічної доцільності кожної системи:
функціональність: Оцінюється обсяг функцій, який пропонує система
для управління заявками, включаючи основні та додаткові
можливості;
можливості кастомізації: Важливий критерій, що визначає здатність
системи адаптуватися до індивідуальних вимог бізнесу та
специфічних робочих процесів;
зручність використання: Оцінюється інтерфейс системи, простота
9
ЧДТУ 241923.025 ПЗ
освоєння та доступність основних функцій для користувачів різного
рівня;
автоматизація процесів: Підтримка автоматизованих процесів, таких
як розподіл завдань, авто-відповіді та сповіщення, що сприяє
зниженню навантаження на працівників;
вартість: Розглядається цінова політика системи, включаючи витрати
на ліцензії, розгортання та підтримку.
На основі цих критеріїв було обрано три найбільш поширені системи
управління заявками, які широко використовуються у різних сферах: Jira
Service Management, Zendesk та Freshdesk. Платформа Jira показано на рисунку
1.1
Рисунок 1.1 – Платформа Jira
Jira Service Management є комплексною системою для управління
заявками, орієнтованою на великі компанії зі складними бізнес-процесами.
Основною перевагою Jira є її багата функціональність, що включає
можливості для складної обробки заявок, організації командної роботи,
налаштування робочих процесів і генерації звітів [4]. Система забезпечує
високий рівень кастомізації: користувачі можуть налаштовувати власні робочі
10
ЧДТУ 241923.025 ПЗ
процеси, ролі та права доступу, що дозволяє адаптувати Jira під специфічні
потреби різних команд. Крім того, система підтримує широку інтеграцію з
іншими інструментами, що розширює її можливості.
Основним недоліком Jira є складність інтерфейсу, що може ускладнити
освоєння для нових користувачів. Багатий функціонал може створити
надлишок налаштувань, які не завжди потрібні середнім і малим компаніям. Це
також призводить до необхідності витратити час на навчання працівників, які
будуть використовувати систему.
Zendesk є універсальною платформою для обробки запитів, орієнтованою
на забезпечення підтримки клієнтів. Система дозволяє працювати з запитами,
що надходять із різних каналів, таких як електронна пошта, соціальні мережі та
веб-форми [5]. Платформа Zendesk показано на рисунку 1.2
Рисунок 1.2 – Платформа Zendesk
11
ЧДТУ 241923.025 ПЗ
Основні переваги Zendesk є простий, інтуїтивний інтерфейс, який
дозволяє швидко освоїти систему навіть новим користувачам. Система також
забезпечує широкий функціонал для роботи з зовнішніми запитами, включаючи
можливості автоматизації стандартних відповідей та налаштування шаблонів.
Zendesk підтримує налаштування простих робочих процесів, що сприяє
оптимізації обробки заявок та підвищенню ефективності команди.
Основні недоліки Zendesk є обмежені можливості кастомізації та
автоматизації для складних внутрішніх процесів. Система більше орієнтована
на зовнішню взаємодію з клієнтами, тому для управління заявками всередині
підприємства її функціонал може бути недостатнім.
Freshdesk є рішенням для обробки запитів, яке підходить як для роботи з
клієнтами, так і для внутрішньої підтримки всередині компанії. Платформа
Freshdesk показано на рисунку 1.3
Рисунок 1.3 – Платформа Freshdesk
Основні переваги Freshdesk є зручний інтерфейс, який сприяє швидкому
освоєнню системи та легкості використання для всіх категорій користувачів.
Система підтримує основні функції управління заявками, включаючи
12
ЧДТУ 241923.025 ПЗ
можливість створення бази знань та інтеграцію з іншими сервісами для
покращення продуктивності. Крім того, Freshdesk підтримує автоматизацію
простих процесів, таких як автоматичне розподілення запитів і авто-відповіді,
що дозволяє знижувати навантаження на працівників технічної підтримки.
Основні недоліки Freshdesk є обмежені можливості кастомізації, що
може стати перешкодою для компаній, яким потрібні складні налаштування для
специфічних процесів. Автоматизація процесів є базовою і не охоплює складні
сценарії, що також обмежує застосування системи в великих компаніях зі
складними робочими процесами.
Аналіз показав, що кожна з цих систем має як переваги, так і обмеження,
що може вплинути на вибір. Розробка власного рішення дозволить врахувати
всі особливості, необхідні для ефективної обробки заявок технічного відділу
підприємства.
1.3 Постановка задач
Основною метою є розробка програмного забезпечення для створення
системи управління заявками для зв'язку з технічним відділом підприємства,
яка забезпечить ефективну комунікацію між працівниками, дозволить
оперативно вирішувати технічні питання та оптимізує робочі процеси. Для
досягнення цієї мети необхідно виконати низку задач, що спрямовані на
створення функціонального, зручного у використанні та адаптивного
програмного забезпечення.
1 Розробити інтерфейс користувача, який забезпечить інтуїтивно
зрозумілу взаємодію з системою для швидкого доступу до функцій
управління заявками. Інтерфейс повинен включати можливості для
створення, перегляду та управління заявками.
2 Розробити функціонал для створення, обробки та відстеження заявок.
Ця функція повинна включати можливість реєстрації нових запитів.
3 Забезпечити можливість авторизації користувачів із різними рівнями
доступу. Система має підтримувати багаторівневу систему прав
13
ЧДТУ 241923.025 ПЗ
доступу, включаючи права адміністратора, технічного персоналу та
звичайних користувачів, що дозволить захистити конфіденційну
інформацію та забезпечити безпеку даних.
4 Реалізувати інтеграцію з базою даних для зберігання та управління
інформацією про заявки, користувачів і статус виконання. База даних
має забезпечувати надійне збереження даних, підтримку пошуку та
аналізу інформації про заявки, а також легкий доступ до історії
запитів.
Виконання цих задач дозволить створити ефективну систему управління
заявками, що сприятиме покращенню роботи технічного відділу підприємства,
підвищенню рівня обслуговування та мінімізації часу, необхідного для обробки
запитів.
14
ЧДТУ 241923.025 ПЗ
Висновки до розділу 1
У першому розділі було детально розглянуто ключові технології,
інструменти та бібліотеки, що використовуються для розробки системи
управління заявками технічного відділу підприємства. Обґрунтування вибору
таких сучасних рішень, як ReactJS, axios, Material-UI, Bootstrap, MongoDB,
NodeJS та Express, базується на їхніх потужних функціональних можливостях,
що сприяють високій продуктивності, масштабованості та зручності у
створенні динамічного інтерфейсу користувача.
Аналіз існуючих аналогів, таких як Jira Service Management, Zendesk та
Freshdesk, показав, що кожна з цих платформ володіє перевагами та
недоліками, які важливо врахувати під час створення власної системи.
На основі проведеного аналізу були визначені основні завдання для
розробки системи управління заявками. Вони включають створення
інтуїтивного та функціонального інтерфейсу, що дозволить користувачам легко
створювати, переглядати та керувати заявками.
Застосування сучасних технологій та інструментів забезпечить надійне
функціонування системи, дозволить автоматизувати рутинні процеси та
створити гнучке рішення, що задовольнить вимоги підприємства. Таким чином,
впровадження системи управління заявками не тільки підвищить ефективність
роботи технічного відділу, але й забезпечить своєчасне обслуговування запитів,
мінімізуючи затрати часу на їх обробку та покращуючи рівень внутрішньої
комунікації.
15
ЧДТУ 241923.025 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область управління заявками для технічного відділу
підприємства охоплює всі процеси, пов’язані з обробкою внутрішніх запитів на
технічну підтримку. У сучасних організаціях зростає потреба в ефективному та
швидкому обслуговуванні технічних запитів, що виникають серед
співробітників. Ця потреба спричинена ускладненням технічної
інфраструктури, підвищенням вимог до її безперебійної роботи та необхідністю
швидкого реагування на будь-які збої чи несправності.
Основна мета системи управління заявками — забезпечити
структурування процесу обробки запитів, надати доступ до необхідних ресурсів
технічного відділу, покращити комунікацію між відділами і дозволити
організувати роботу з заявками більш прозоро. Це має зменшити затримки у
виконанні запитів, знизити навантаження на технічний відділ і підвищити
задоволеність співробітників.
Модель предметної області включає ключові об'єкти та їх взаємозв'язки,
які відображають усі етапи роботи з заявками та взаємодію між користувачами.
Основними елементами моделі є:
користувач — особа, що взаємодіє з системою, має доступ до її
функцій відповідно до ролі. Користувачі поділяються на звичайних
користувачів, які створюють заявки, та технічних спеціалістів, які
обробляють ці заявки;
адміністратор — головна особа, яка приймає остаточне рішення щодо
16
ЧДТУ 241923.025 ПЗ
підтвердження, пріоритету або закриття заявки. Адміністратор також
має право переглядати всі заявки, контролювати роботу технічних
спеціалістів і втручатися у процес обробки заявок за потреби;
заявка — ключовий об’єкт, який містить опис проблеми, створений
користувачем. Кожна заявка має свій життєвий цикл, що включає
етапи створення, обробки та завершення;
статус заявки — параметр, який відображає поточний стан заявки.
Статуси, як-от "Нова", "В обробці" та "Виконана", оновлюються
залежно від етапу життєвого циклу заявки;
технічний спеціаліст — співробітник технічного відділу,
відповідальний за обробку заявок. Спеціаліст має доступ до
коментарів, може змінювати статуси заявок, а також комунікувати з
користувачами для уточнення деталей.
Словник предметної області
Розглянемо основні елементи словника предметної області:
користувач — співробітник підприємства, який створює заявку на
технічну підтримку або переглядає свої попередні запити;
адміністратор — особа, яка контролює загальну роботу системи,
підтверджує або завершує заявки, а також здійснює управління
процесами всередині системи;
заявка — запит на технічну підтримку або вирішення проблеми,
створений користувачем для передачі в технічний відділ;
статус — параметр, що відображає поточний етап обробки заявки та
змінюється відповідно до стадії її вирішення;
технічний спеціаліст — співробітник, який обробляє заявки, що
надходять від користувачів, виконує технічні завдання та залишає
коментарі щодо прогресу виконання заявки.
17
ЧДТУ 241923.025 ПЗ
2.1.2 Елементи моделювання предметної області
Першим є звичайний користувач — працівник підприємства, що подає
заявку для вирішення технічних проблем. Заявка включає опис проблеми, що
може містити додаткову інформацію, файли або деталі, необхідні для
розв'язання питання. Іншим типом користувача є технічний спеціаліст, що
отримує заявку, аналізує її та виконує дії для вирішення проблеми. Спеціаліст
може змінювати статус заявки, додавати коментарі та відмічати етапи
завершення процесу. Також передбачено роль адміністратора, що має
розширені права, включаючи перегляд усіх заявок, контроль роботи технічних
спеціалістів та можливість втручатися у процеси системи. Кожен користувач
має унікальний ідентифікатор, що дозволяє чітко визначати, хто створив заявку,
працював над нею або приймав управлінські рішення.
Ключовим об’єктом у системі є заявка, що містить ідентифікатор, опис
проблеми, дату створення, статус та, за потреби, додаткові файли або
повідомлення. Заявка проходить кілька етапів: від "Нової" до "Виконаної" або
"Скасованої". Такий процес забезпечує контроль над життєвим циклом заявки.
Кожен статус відображає етап обробки запиту, що дозволяє користувачеві
відстежувати прогрес його виконання, технічному спеціалісту — організувати
свою роботу, а адміністратору — забезпечити загальний контроль процесу.
Журнал змін є важливим компонентом системи, який зберігає
інформацію про всі дії із заявками. У ньому фіксуються створення заявок,
оновлення статусів, коментарі технічних спеціалістів та завершення обробки
запитів. Такий журнал забезпечує прозорість у роботі системи та дозволяє
відслідковувати історію кожної заявки, що важливо для подальшого аналізу й
оптимізації процесів.
База даних є центральним компонентом зберігання інформації та
забезпечує надійний доступ до даних для всіх процесів у системі. Вона містить
таблиці користувачів, заявок, коментарів, історії змін та статусів, що дозволяє
швидко отримувати необхідну інформацію для обробки запитів. Надійність та
ефективність бази даних гарантують стабільну роботу всієї системи.
18
ЧДТУ 241923.025 ПЗ
Для відображення взаємозв’язків між компонентами системи
використовується моделювання за допомогою UML (Unified Modeling
Language). UML допомагає створювати діаграми класів, які відображають
основні сутності, зокрема користувачів, заявки, статуси та ролі. Діаграми
послідовностей описують процеси взаємодії між користувачами та заявками,
демонструючи послідовність дій від моменту створення заявки до її
завершення. Крім того, діаграми діяльності та комунікації деталізують основні
бізнес-процеси, сприяючи ефективній побудові програмного забезпечення та
забезпеченню надійного обміну даними.
Рисунок 2.2 - Основні графічні символи UML [7]
19
ЧДТУ 241923.025 ПЗ
Рисунок 2.3 – Єднальні елементи UML [7]
Під час проєктування програмного забезпечення було розроблено
фундаментальні діаграми з використанням основних графічних символів UML.
2.1.3 Робоча область моделювання
Робоча область моделювання системи управління заявками охоплює всі
операції та взаємодії, що підтримують створення, обробку та завершення заявок
між користувачами та технічними спеціалістами. Основне середовище, в якому
здійснюється ця діяльність, є веб-додатком, що дозволяє користувачам
подавати заявки на технічну підтримку, переглядати статуси своїх заявок та
взаємодіяти з технічними спеціалістами для вирішення технічних питань.
Користувачі та технічні спеціалісти діють у єдиній моделі робочої області,
що має на меті впорядкувати обробку запитів та забезпечити ефективний
контроль на кожному етапі життєвого циклу заявки. Для моделювання
структури робочої області використовується діаграма моделі робочої області
UML, яка ілюструє всі основні компоненти системи та зв’язки між ними,
забезпечуючи структуроване відображення процесів і ролей.
Діаграма моделі робочої області (рис 2.4) відображає всі основні об'єкти —
користувачів, технічних спеціалістів і заявки — та показує, як ці об'єкти
взаємодіють один з одним у процесі обробки запиту. Наприклад, звичайний
20
ЧДТУ 241923.025 ПЗ
користувач створює заявку, яка проходить через різні статуси, такі як "Нова",
"В обробці", "Виконана" або "Скасована", відображаючи кожний етап обробки.
Технічний спеціаліст приймає заявку в роботу, вносить коментарі, оновлює
статус і фіксує зміни в журналі, що є частиною моделі для відстеження кожного
кроку обробки.
Рисунок 2.4 Модель робочої області системи управління заявками
21
ЧДТУ 241923.025 ПЗ
Крім того, модель робочої області демонструє взаємодію між базою даних
MongoDB та серверною частиною, яка обробляє запити за допомогою Node.js і
Express, що забезпечує доступ до даних заявок та профілів користувачів.
Модель показує, як запити передаються між фронтендом і сервером, а також
зберігаються й оновлюються в базі даних. Це сприяє оптимальній організації
роботи системи та забезпечує цілісність даних, необхідну для стабільної й
ефективної обробки заявок.
Діаграма моделі робочої області також враховує механізми доступу до
системи за допомогою авторизації через JWT (JSON Web Token), забезпечуючи
захищений вхід користувачів у систему та надаючи їм доступ до відповідних
функцій залежно від їхніх ролей. Ця модель дозволяє деталізувати всі етапи
роботи системи, забезпечуючи прозорість процесів і надійний обмін даними
між компонентами системи, що відповідає вимогам до сучасних систем
управління заявками технічної підтримки.
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.
Формування вимог до програмного забезпечення
При розробці системи управління заявками для технічного відділу
важливо чітко визначити вимоги, які повинні бути реалізовані в програмному
забезпеченні, щоб забезпечити його відповідність потребам користувачів і
надійну роботу. Вимоги можна розділити на первинні та детальні, а також на
вимоги замовника і розробника, функціональні та нефункціональні. Кожна
група вимог орієнтована на різні аспекти роботи системи, сприяючи створенню
комплексного та ефективного рішення.
Первинні та детальні вимоги
Первинні вимоги описують загальні очікування щодо функціоналу
22
ЧДТУ 241923.025 ПЗ
системи та її призначення. У даному випадку основні цілі системи управління
заявками включають:
забезпечення прозорості обробки запитів на технічну підтримку;
підвищення швидкості їх виконання;
поліпшення комунікації між технічним відділом і співробітниками
підприємства.
Детальні вимоги включають конкретні функції та можливості, які
система повинна надавати. До них належать:
реєстрація та авторизація користувачів з різними рівнями доступу
(звичайні користувачі, технічні спеціалісти);
створення заявок з описом проблеми та прикріпленням файлів;
перегляд і редагування заявок з можливістю змінювати їх статус,
додавати коментарі від технічного спеціаліста та відслідковувати
історію змін;
зберігання даних про всі заявки та дії над ними в базі даних для
подальшого аналізу і звітності.
Вимоги замовника і розробника
Вимоги замовника відображають побажання щодо зручності
використання системи. Замовник очікує, що система:
забезпечить зручний та інтуїтивний інтерфейс для співробітників
різного рівня;
дозволить відстежувати статус кожної заявки та оперативно
обробляти запити;
надасть можливості для зберігання історії заявок та генерування
звітів;
забезпечить безпеку даних, особливо конфіденційної інформації про
користувачів і запити.
Вимоги розробника зосереджуються на технічних аспектах, які повинні
бути реалізовані, щоб забезпечити стабільну і масштабовану роботу системи.
23
ЧДТУ 241923.025 ПЗ
Серед них:
використання бази даних, що підтримує масштабованість і швидке
збереження даних (MongoDB);
реалізація безпечного доступу до системи через аутентифікацію за
допомогою JSON Web Token (JWT);
створення чітко структурованого коду, що полегшить підтримку та
розвиток системи;
використання надійних бібліотек і фреймворків, таких як ReactJS для
клієнтської частини і NodeJS для серверної.
Функціональні та нефункціональні вимоги
Функціональні вимоги описують конкретні функції, які система
повинна виконувати:
реєстрація та авторизація користувачів – забезпечення процесу входу
в систему з підтримкою багаторівневого доступу та ролей;
управління заявками – можливість для користувачів створювати
заявки, додавати до них коментарі, прикріплювати файли та
переглядати їх статуси;
журнал дій – зберігання всіх змін і коментарів для кожної заявки в
базі даних для подальшого аналізу та забезпечення прозорості
процесів.
Нефункціональні вимоги охоплюють вимоги до якості роботи системи:
продуктивність – система повинна обробляти запити користувачів без
затримок, навіть при великій кількості одночасних запитів;
масштабованість – можливість розширення функціоналу та
збільшення обсягу даних без втрати ефективності роботи;
зручність використання – інтуїтивний інтерфейс, який легко
освоюється співробітниками без технічної підготовки;
безпека – захист персональних даних і інформації про заявки,
включаючи використання JWT для аутентифікації та ролей доступу;
24
ЧДТУ 241923.025 ПЗ
надійність – система повинна бути стійкою до збоїв і забезпечувати
безперебійне збереження даних у разі непередбачених ситуацій;
модульність – можливість змінювати та додавати функції без значного
переписування існуючого коду, що забезпечує легку підтримку і
розвиток системи.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів використовується для формування вимог до
системи управління заявками, забезпечуючи візуальне представлення основних
функцій, які повинна виконувати система, та взаємодій між користувачами та
функціональними компонентами. Ця діаграма дозволяє структурувати
функціональність системи навколо ключових дій (рис 2.5), що їх виконують
користувачі, а також описує потоки взаємодій для кожної ролі.
Рис 2.5 - Діаграма прецендентів системи управління заявками
Перший прецедент відображає процес створення заявки, в якому
звичайний користувач, тобто співробітник, подає запит на технічну підтримку,
вводячи опис проблеми, час створення та прикріплюючи супровідні файли,
якщо необхідно. Інший важливий прецедент пов'язаний із переглядом статусу
заявки, де користувач може отримати актуальну інформацію щодо прогресу
обробки свого запиту, починаючи з моменту створення заявки й до її
25
ЧДТУ 241923.025 ПЗ
завершення.
Обробка заявки є ключовим прецедентом для технічного спеціаліста,
який отримує доступ до нових запитів, проводить дії для вирішення проблем,
змінює статус заявки та додає коментарі, щоб забезпечити зворотний зв’язок із
користувачем. Після завершення роботи над запитом технічний спеціаліст
завершує заявку, відмічаючи, що проблема вирішена, і зазначаючи в деталях
виконані дії.
Користувач має змогу переглядати історію своїх заявок, що дозволяє
ознайомитися з минулими запитами та отримати доступ до їхніх результатів.
Для безпеки система підтримує авторизацію користувачів через процес
автентифікації за допомогою JWT, що дозволяє ідентифікувати кожного
користувача та налаштувати рівень доступу до функцій системи залежно від
його ролі.
Діаграма прецедентів таким чином забезпечує чітке уявлення про основні
дії, які повинен виконувати кожен користувач, і дозволяє структурувати
функціональність системи, зберігаючи її простоту та інтуїтивність. Це сприяє
точному визначенню вимог до програмного забезпечення, що забезпечить
ефективну підтримку всіх операцій управління заявками та відповідає потребам
користувачів.
2.3 Проектування логічної структури програмного комплексу
2.3.1 Діаграма класів
При проєктуванні обрано структуру, яка складається з окремих класів для
фронтенду та бекенду. Кожен клас має свою специфічну роль у функціонуванні
системи [9] управління заявками. Ці класи взаємодіють між собою,
забезпечуючи основні функціональні можливості, такі як створення,
редагування та перегляд заявок (рис 2.6).
На серверній стороні, реалізованій на Node.js та MongoDB,
використовуються такі класи (рис 2.7):
26
ЧДТУ 241923.025 ПЗ
User — модель для зберігання інформації про користувачів,
включаючи ім’я, прізвище, електронну пошту, пароль, роль та дату
створення. Це дозволяє керувати даними користувачів і забезпечує
їхню автентифікацію у системі (User).
Ticket — модель для зберігання інформації про заявки, включаючи
назву, дату створення, контент, повідомлення, статус та прикріплені
файли. Ця модель підтримує структуру заявок і дозволяє технічним
спеціалістам додавати коментарі до кожної заявки для детального
відображення процесу її обробки (Ticket).
Users.js та Tickets.js — це роутери, які керують HTTP-запитами для
створення та обробки заявок і користувачів. Вони забезпечують
функціонал реєстрації, авторизації та управління статусами заявок.
Клас Users.js включає логіку для реєстрації та логіна користувачів із
використанням токенів, шифрування паролів за допомогою bcrypt та
генерації JWT для забезпечення безпечної автентифікації (Users)
(Tickets).
На клієнтській стороні, реалізованій на ReactJS, використовуються такі
компоненти (рис 2.8):
Register та Login — компоненти, які дозволяють користувачам
зареєструватися та увійти в систему. Login компонент викликає
функцію логіну з використанням токена, щоб забезпечити безпеку при
доступі до системи, а Register компонент відповідає за реєстрацію
нового користувача та передає інформацію на бекенд для зберігання у
базі даних(Register) (Login).
Ticket — компонент, який дозволяє користувачам створювати заявки,
додаючи деталі, такі як ім'я заявки, зміст, повідомлення та
зображення. Компонент відправляє цю інформацію на сервер для
обробки і зберігання у базі даних (Ticket).
TicketShow — компонент, який відображає всі заявки для
користувачів та дозволяє фільтрувати заявки за статусом, додавати
27
ЧДТУ 241923.025 ПЗ
коментарі, змінювати статус заявки, а також переглядати зображення,
пов'язані із заявкою. Цей компонент також забезпечує інтерактивний
інтерфейс для взаємодії технічних спеціалістів із заявками,
підтримуючи виконання CRUD операцій для управління заявками
(TicketShow).
Рисунок 2.6 – Діаграма класів клієнтської частини
Рисунок 2.7 – Діаграма класів клієнтської частини
28
ЧДТУ 241923.025 ПЗ
Рисунок 2.8 – Діаграма класів серверної частини
Рисунок 2.9 – Діаграма класів серверної частини
29
ЧДТУ 241923.025 ПЗ
Рисунок 2.10 – Діаграма класів програмної реалізації
Рисунок 2.11 – Діаграма класів програмної реалізації
30
ЧДТУ 241923.025 ПЗ
2.3.2 Діаграми пакетів
Розроблена діаграма пакетів наочно представляє структуру системи
управління заявками (рис 2.12), показуючи, як основні компоненти організовані
у фронтенд- і бекенд-пакети та як вони взаємодіють між собою і з базою даних
[10]. В основі системи лежать три основні пакети: Frontend, Backend та
Database, кожен із яких виконує певну роль.
Frontend пакет включає всі компоненти, що забезпечують взаємодію з
користувачем. Реалізований на ReactJS, цей пакет містить класи для реєстрації
та авторизації користувачів, а також для створення та перегляду заявок, що
дозволяє користувачам ефективно керувати запитами через інтуїтивний
інтерфейс. Водночас Backend пакет виконує функцію обробки даних,
приймаючи запити від Frontend пакета та забезпечуючи доступ до бази даних.
Реалізований на Node.js, Backend пакет управляє інформацією про користувачів
і заявки, здійснюючи їх створення, редагування та перегляд.
Пакет Database відповідає за зберігання інформації. Здійснене на
MongoDB, зберігання охоплює всі дані про користувачів і заявки. Frontend
передає запити до Backend пакета через HTTP-запити, а Backend взаємодіє з
Database через операції CRUD, забезпечуючи повний цикл обробки даних.
Рисунок 2.12 – Діаграма пакетів
31
ЧДТУ 241923.025 ПЗ
2.4 Архітектурне проектування
2.4.1 Діаграма компонентів
Було розроблено діаграму компонентів (рис 2.13) описує, як різні частини
системи управління заявками функціонально пов'язані між собою. Вона
відображає компоненти, що складають систему, та їх взаємозв’язки, показуючи,
як інформація передається між різними елементами, такими як клієнтська
частина, серверна частина і база даних [11].
Рис 2.13 - Діаграма компонентів для системи управління заявками
Основними компонентами є Frontend, Backend та Database, кожен з яких
взаємодіє із зовнішнім середовищем і виконує свою специфічну роль. Frontend,
побудований на ReactJS, включає компоненти інтерфейсу для роботи
користувача: Register, Login, Ticket і TicketShow. Ці компоненти передають дані
у вигляді HTTP-запитів на Backend.
Backend, реалізований на Node.js з використанням Express, обробляє
HTTP-запити від Frontend та взаємодіє з MongoDB для доступу до даних. Він
складається з таких компонентів, як Users, який відповідає за реєстрацію та
32
ЧДТУ 241923.025 ПЗ
логін користувачів, і Tickets, який обробляє всі функції, пов'язані із заявками:
створення, зміну статусів, додавання коментарів та відправку даних до
Frontend.
Компонент Database зберігає всі дані про користувачів і заявки у
колекціях MongoDB (User Collection та Ticket Collection). Backend передає
запити на базу даних через CRUD-операції, що дозволяє додавати нові дані,
редагувати їх або видаляти. Уся система побудована таким чином, що Frontend
відправляє запити на Backend, а Backend виконує операції з даними в Database і
повертає результат.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Програмна система для управління заявками розгорнута на апаратних
засобах, що включають клієнтську частину, серверну інфраструктуру та базу
даних. Клієнтська частина взаємодіє із серверною інфраструктурою через
інтернет, відправляючи запити до бекенд-сервера, який обробляє ці запити та
передає їх до бази даних (рис 2.14).
Клієнт (Frontend) розгорнутий на веб-браузері користувача і взаємодіє із
сервером через HTTP-запити. Реалізація клієнтської частини базується на
ReactJS, що дозволяє створювати динамічний інтерфейс користувача для
роботи з заявками. Користувачі можуть реєструватися, входити до системи,
створювати заявки та переглядати статуси запитів через веб-інтерфейс.
Сервер (Backend) розміщений на центральному сервері або в хмарному
середовищі, де обробляються всі запити від клієнтів. Реалізований на Node.js та
Express, сервер приймає HTTP-запити від клієнтської частини, обробляє їх та
здійснює необхідні дії, такі як створення нових записів у базі даних або
оновлення існуючих. Сервер також використовує JWT (JSON Web Tokens) для
автентифікації користувачів, щоб забезпечити безпеку доступу до системи.
База даних (Database) реалізована на MongoDB і зберігає інформацію про
користувачів і заявки. База даних розгорнута на сервері, що дозволяє зберігати
всі дані в одному місці і забезпечувати зручний доступ до них через CRUD-
33
ЧДТУ 241923.025 ПЗ
операції. З сервером база даних взаємодіє через драйвер MongoDB, що
забезпечує обробку запитів та зберігання даних.
Усі компоненти системи зв’язані між собою через інтернет-з’єднання, де
клієнтська частина надсилає HTTP-запити на сервер для обробки інформації.
Сервер взаємодіє з базою даних через драйвер MongoDB, що забезпечує
зручний доступ до збережених даних для подальшої обробки, редагування або
видалення. Таке розгортання дозволяє системі бути гнучкою та
масштабованою, оскільки клієнтська частина може функціонувати на будь-
якому пристрої з доступом до інтернету, а сервер та база даних можуть
розгортатися як на фізичному обладнанні підприємства, так і в хмарних
середовищах. Це забезпечує стабільність роботи системи та доступність її
функцій для користувачів незалежно від їх місцезнаходження.
Рисунок 2.14 – Діаграма розгортання системи управління заявками
34
ЧДТУ 241923.025 ПЗ
2.5 Моделювання поведінки системи
Нижче розглянуто процес моделювання поведінки програмного
забезпечення.
2.5.1 Діаграма діяльності
Діаграми діяльності представляють основні робочі процеси системи
управління заявками, які відображають послідовність дій для ключових
функціональних можливостей [12]. Оскільки в системі є кілька важливих
операцій, кожна з них представлена окремою діаграмою діяльності: створення
заявки, обробка заявки технічним спеціалістом та перегляд статусу заявки
користувачем.
1 Діаграма діяльності для створення заявки
Ця діаграма показує процес створення нової заявки користувачем (рис
2.15). Користувач вводить дані заявки (назва, опис, зображення, файли), після
чого відправляє запит на сервер. Сервер перевіряє дані та, якщо вони коректні,
створює новий запис у базі даних та повертає підтвердження користувачеві.
Рисунок 2.15 – Діаграма діяльності для створення заявки
35
ЧДТУ 241923.025 ПЗ
2 Діаграма діяльності для обробки заявки технічним спеціалістом
Ця діаграма відображає процес обробки заявки технічним спеціалістом
(рис 2.16). Спеціаліст переглядає список заявок, вибирає конкретну заявку для
обробки, вивчає її зміст і додає коментарі або змінює статус заявки (наприклад,
на "Виконана", якщо проблему вирішено). Після завершення спеціаліст зберігає
зміни в базі даних.
Рисунок 2.16 – Діаграма діяльності для обробки заявки технічним спеціалістом
3 Діаграма діяльності для перегляду статусу заявки користувачем
36
ЧДТУ 241923.025 ПЗ
Ця діаграма ілюструє процес, під час якого користувач переглядає статус
раніше поданої заявки (рис 2.17). Користувач відкриває розділ перегляду
заявок, сервер отримує дані з бази даних та відображає поточний статус обраної
заявки разом з іншими деталями та коментарями, якщо вони є.
Рисунок 2.17 – Діаграма діяльності для для перегляду статусу заявки
користувачем
2.5.2 Діаграма послідовності
При проєктуванні було розроблено діаграми послідовності, які
відображають покрокову взаємодію між користувачами, компонентами
клієнтської частини та сервером у процесах обробки заявок. Вони дозволяють
простежити логіку обробки запитів у різних сценаріях, що забезпечує наочне
уявлення про те, як саме функціонує система.
1. Діаграма послідовності для створення заявки
37
ЧДТУ 241923.025 ПЗ
У цій діаграмі відображається послідовність дій, пов'язаних із процесом
створення заявки (рис 2.18). Користувач заповнює інформацію про заявку,
відправляє її на сервер, після чого сервер обробляє дані, додає новий запис у
базу даних і повертає підтвердження користувачеві.
Рисунок 2.18 – Діаграма послідовності створення заявки
38
ЧДТУ 241923.025 ПЗ
2 Діаграма послідовності для перегляду статусу заявки
Друга діаграма ілюструє процес, коли користувач переглядає статус
створеної заявки (рис 2.19). Користувач запитує інформацію про певну заявку,
сервер звертається до бази даних, отримує необхідні дані та передає їх на
клієнтську частину для відображення користувачеві.
Рисунок 2.19 – Діаграма послідовності перегляду статусу заявки
2.5.3 Діаграма комунікації
39
ЧДТУ 241923.025 ПЗ
Діаграми комунікації відображають обмін повідомленнями між об’єктами
в системі для реалізації певного функціоналу. Кожна діаграма показує, як
об’єкти взаємодіють між собою у процесах створення та перегляду заявки,
забезпечуючи розуміння логіки роботи системи.
1 Діаграма комунікації для створення заявки
Ця діаграма демонструє процес комунікації між об’єктами при створенні
заявки (рис 2.20). Користувач взаємодіє з інтерфейсом клієнтської частини для
введення даних заявки, відправляє запит на сервер для збереження даних,
сервер передає запит до бази даних, а потім підтвердження повертається
користувачеві.
Рисунок 2.20 – Діаграма комунікації створення заявки
2. Діаграма комунікації для перегляду статусу заявки
40
ЧДТУ 241923.025 ПЗ
Діаграма показує, як об’єкти системи взаємодіють між собою, коли
користувач переглядає статус заявки (рис 2.21). Користувач звертається до
клієнтської частини для перегляду інформації про певну заявку, яка надсилає
запит до сервера. Сервер запитує необхідні дані з бази даних і повертає їх для
відображення на клієнтській частині.
Рисунок 2.21 – Діаграма комунікації перегляду статусу заявки
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (рис 2.22) показує можливі стани заявки в
системі управління заявками та переходи між ними на основі дій користувача
або технічного спеціаліста [13]. Це дозволяє відобразити логіку переходів у
статусах заявки, починаючи від її створення і до завершення.
Основні стани заявки в системі:
41
ЧДТУ 241923.025 ПЗ
Нова — заявка тільки створена користувачем і чекає на обробку.
В обробці — заявка знаходиться в роботі у технічного спеціаліста.
Виконана — заявка вирішена, і проблема, зазначена в ній, усунута.
Скасована — заявка була скасована користувачем або технічним
спеціалістом через непотрібність або неможливість вирішення.
Рисунок 2.22 – Діаграмма скінченного автомату основних станів заявки в
системі
42
ЧДТУ 241923.025 ПЗ
Висновки до розділу 2
Було проведено моделювання предметної області, що дозволило
детально визначити основні об'єкти, ролі користувачів і процеси, які мають
бути реалізовані в системі управління заявками. Завдяки цьому стало можливим
розробити модель, що відображає логіку взаємодії між користувачами,
технічними спеціалістами та самими заявками.
Було розроблено основні елементи проєктування системи управління
заявками, включаючи діаграми класів, пакетів, компонентів, діяльності,
послідовності, комунікації та скінченних автоматів. Всі ці діаграми допомогли
наочно структурувати і продемонструвати взаємозв’язки між компонентами
системи, їхні функції та процеси взаємодії.
Аналіз діаграм класів і пакетів показав чіткий розподіл ролей між
фронтенд- та бекенд-компонентами, де кожен елемент виконує свою
специфічну функцію у забезпеченні стабільного функціонування системи.
Діаграма компонентів продемонструвала, як різні частини системи
об'єднуються для реалізації основної функціональності та обробки запитів від
користувачів.
Діаграми діяльності та послідовності відобразили ключові процеси, такі
як створення, обробка та перегляд заявок, що забезпечують чітке розуміння дій
і переходів між станами заявки. Діаграма комунікації показала обмін
повідомленнями між різними об'єктами в системі для реалізації
функціональних сценаріїв. Діаграма скінченного автомату детально
представила всі можливі стани заявки, починаючи з моменту її створення та
закінчуючи виконанням або скасуванням.
Усі розроблені діаграми дали змогу всебічно дослідити структуру та
функціональність системи управління заявками, що дозволяє забезпечити
логічний, структурований підхід до проєктування. Такий комплексний підхід до
моделювання системи полегшує розуміння взаємодії між елементами системи,
підвищує ефективність процесу розробки та сприяє побудові стабільної та
гнучкої системи для управління заявками.
43
ЧДТУ 241923.025 ПЗ
3 РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
3.1.1 Обґрунтування вибору засобів реалізації
Для створення системи управління заявками технічного відділу були
обрані сучасні технології, які забезпечують високу продуктивність,
масштабованість, зручність у розробці та відповідність вимогам до проєкту.
Вибір засобів реалізації базувався на необхідності створення ефективного і
зручного інтерфейсу користувача (Frontend), стабільного серверного
забезпечення (Backend), а також надійної бази даних для зберігання
інформації. Нижче детально розглянемо кожен із цих аспектів.
Для створення інтерфейсу користувача було обрано бібліотеку ReactJS,
яка дозволяє розробляти динамічні та інтерактивні веб-застосунки. ReactJS –
це одна з найпопулярніших JavaScript-бібліотек для побудови інтерфейсів
користувача, розроблена компанією Facebook, яка забезпечує високу
продуктивність і зручність у розробці завдяки підходу до компонентного
програмування [14]. Використання компонентів дозволяє розробникам
створювати окремі модулі, які можна легко поєднувати, повторно
використовувати та підтримувати.
Однією з важливих функцій ReactJS є віртуальний DOM (Document Object
Model), який забезпечує високу швидкодію застосунку. Віртуальний DOM
дозволяє ReactJS ефективно оновлювати користувацький інтерфейс,
виконуючи мінімальну кількість змін у реальному DOM [14]. Це особливо
важливо для систем управління заявками, де оновлення даних (наприклад,
статус заявки або нові коментарі) має бути відображене для користувача
швидко та без затримок.
Додатково до основної бібліотеки ReactJS було обрано кілька важливих
інструментів і бібліотек для полегшення розробки інтерфейсу. Зокрема:
axios – бібліотека для виконання HTTP-запитів, яка дозволяє
44
ЧДТУ 241923.025 ПЗ
відправляти та отримувати дані з сервера. Вона забезпечує гнучкість і
зручність у роботі з REST API, що робить її ідеальним вибором для
обміну даними між клієнтською і серверною частинами застосунку.
material-ui/core та bootstrap – бібліотеки компонентів, які забезпечують
стилізацію інтерфейсу та надають готові компоненти, такі як кнопки,
форми, панелі навігації тощо. Використання цих бібліотек значно
спрощує процес створення зручного і сучасного інтерфейсу,
дотримуючись найкращих практик дизайну.
devextreme та devextreme-react – бібліотеки, які містять набір
потужних компонентів для розробки веб-застосунків, зокрема таблиць
і графіків, що є корисними для візуалізації даних та роботи з великим
обсягом інформації в системі управління заявками.
jwt-decode – бібліотека для декодування JSON Web Token (JWT). Це
дозволяє працювати з авторизацією на основі токенів, забезпечуючи
безпечний доступ користувачів до застосунку.
react-bootstrap – компонентна бібліотека для інтеграції стилів Bootstrap
з компонентами React, що спрощує створення адаптивного і стильного
інтерфейсу.
react-router-dom – бібліотека для маршрутизації в React-застосунках,
яка дозволяє легко керувати переходами між сторінками та
реалізовувати багатоекранний інтерфейс для зручної навігації
користувачів.
Таким чином, ReactJS разом із додатковими бібліотеками забезпечує
високу продуктивність, гнучкість і легкість у розробці інтерфейсу
користувача, що є ключовими вимогами для систем управління заявками.
Для серверної частини було обрано платформу Node.js разом із
фреймворком Express. Node.js – це серверна платформа на основі JavaScript,
яка дозволяє виконувати JavaScript-код на стороні сервера. Завдяки
асинхронній природі Node.js та можливості обробляти велику кількість
запитів, платформа є ідеальним вибором для веб-застосунків, які потребують
45
ЧДТУ 241923.025 ПЗ
високої швидкодії [15].
Express – це мінімалістичний фреймворк для Node.js, який надає простий
і ефективний спосіб створення серверних застосунків і API. Express дозволяє
швидко налаштовувати маршрути, обробляти запити та відповіді, працювати з
middleware, що робить його дуже гнучким і зручним у розробці [16]. У системі
управління заявками Express використовується для обробки запитів від
клієнтської частини, управління авторизацією та доступом до бази даних.
Крім того, для серверної частини було обрано кілька важливих бібліотек:
jsonwebtoken – бібліотека для роботи з JWT-токенами, яка
використовується для авторизації користувачів. Завдяки цьому
забезпечується безпека доступу до даних системи, а також можливість
визначення прав доступу кожного користувача.
bcrypt – бібліотека для хешування паролів, що забезпечує захист
паролів користувачів при зберіганні в базі даних.
multer – бібліотека для обробки файлів, яка дозволяє завантажувати
файли на сервер, що корисно для додавання зображень або документів
до заявок.
path та fs – вбудовані модулі Node.js для роботи з файловою
системою. Вони використовуються для обробки файлів і керування
файловою структурою на сервері.
cors – middleware для налаштування правил доступу між доменами,
що дозволяє клієнтській частині з’єднуватися із сервером.
body-parser – middleware для обробки даних форми (форматів JSON
або URL-encoded), що дозволяє легко отримувати та обробляти вхідні
дані.
mongoose – бібліотека для взаємодії з MongoDB. Вона забезпечує
зручний інтерфейс для роботи з базою даних, зокрема створення
моделей для колекцій MongoDB і зручне виконання CRUD-операцій.
Express у поєднанні з іншими бібліотеками надає стабільну й гнучку
основу для розробки серверної частини, що забезпечує високу продуктивність
46
ЧДТУ 241923.025 ПЗ
і легкість в управлінні запитами.
Для зберігання даних було обрано MongoDB Atlas – хмарний сервіс для
керування базами даних MongoDB. MongoDB – це нереляційна база даних, яка
використовує гнучкий формат JSON-подібних документів, що дозволяє легко
зберігати складні об’єкти, такі як заявки чи інформацію про користувачів.
MongoDB є масштабованою та надійною базою даних, яка добре підходить
для веб-застосунків, що потребують швидкого доступу до даних і високої
гнучкості в структурі даних [3].
MongoDB Atlas забезпечує легке розгортання та управління базою даних
у хмарі, що спрощує підтримку та обслуговування системи [3]. Також
MongoDB підтримує масштабування, яке дає можливість системі ефективно
обробляти зростаючий обсяг даних у випадку розширення проєкту.
Використання MongoDB у поєднанні з бібліотекою mongoose на серверній
стороні дозволяє зручно створювати моделі даних, здійснювати валідацію та
виконувати запити.
MongoDB Atlas, разом із Node.js та ReactJS, забезпечує надійну
архітектуру для розробки системи управління заявками, яка здатна швидко
обробляти запити, безпечно зберігати дані та забезпечувати зручний інтерфейс
користувача. Цей комплекс засобів реалізації є оптимальним вибором для
досягнення поставлених цілей проєкту.
3.1.2 Опис структурної, (функціональної) схеми
Структурна та функціональна схема системи управління заявками
відображає взаємозв’язки між основними компонентами та функціональними
елементами системи, що забезпечують роботу всіх процесів у системі: від
взаємодії користувача з інтерфейсом до збереження даних у базі. Ці схеми
показують, як різні частини системи об’єднуються для виконання основних
функцій — створення, обробки та перегляду заявок.
Структурна схема системи (рис 3.1) представляє її архітектуру та основні
компоненти, що включають клієнтську частину (Frontend), серверну частину
(Backend) та базу даних (Database). Кожен з цих компонентів відповідає за свою
47
ЧДТУ 241923.025 ПЗ
частину роботи в системі, що дозволяє розподілити функції та забезпечити
модульність архітектури.
Frontend – клієнтська частина системи, побудована на основі ReactJS,
включає компоненти, які забезпечують користувацький інтерфейс для взаємодії
з системою. Основні функціональні елементи клієнтської частини —
компоненти для реєстрації та входу в систему, створення заявки, перегляду
заявок, а також обробки відгуків від серверної частини.
Backend – серверна частина системи, розгорнута на платформі Node.js з
використанням фреймворка Express. Сервер приймає запити від Frontend,
обробляє їх і передає дані до бази даних. Backend відповідає за обробку запитів,
авторизацію користувачів за допомогою JWT-токенів, хешування паролів,
обробку файлів (зображень і документів, що додаються до заявки), а також за
реалізацію всіх бізнес-логік системи, пов'язаної з заявками.
Database – база даних, реалізована на MongoDB Atlas, відповідає за
зберігання даних про користувачів і заявки. У базі даних зберігаються всі
основні об’єкти системи, включаючи дані про кожну заявку (назва, опис,
статус, коментарі) та дані про користувачів (ім'я, електронна пошта, пароль у
хешованому вигляді).
Рисунок 3.1 – Структурна схема основних компонентів
48
ЧДТУ 241923.025 ПЗ
Кожен компонент взаємодіє з іншими через чітко визначені інтерфейси та
API-запити, що забезпечує незалежність компонентів та можливість їх
модифікації без значного впливу на інші частини системи.
Функціональна схема (рис 3.2) описує основні функції системи та
взаємодію між ними. Вона демонструє, як користувач виконує різні операції з
заявками через інтерфейс, а серверна частина і база даних забезпечують
виконання цих операцій у системі.
Основні функції:
реєстрація та автентифікація користувачів – користувач вводить свої
дані для реєстрації або входу в систему, після чого дані надсилаються
на сервер. Сервер здійснює перевірку автентичності, використовуючи
JWT для захищеного доступу користувачів до системи, а також bcrypt
для хешування паролів;
створення заявки – після автентифікації користувач заповнює форму
для створення нової заявки, вказуючи основну інформацію, таку як
назва, опис проблеми, файли або зображення, якщо це необхідно. Дані
заявки надсилаються на сервер, де відбувається їх перевірка, обробка,
а потім збереження у базі даних;
перегляд списку заявок та їх статусів – користувачі можуть
переглядати власні заявки або (у випадку технічних спеціалістів) усі
заявки в системі. Запит на перегляд надсилається на сервер, який
взаємодіє з базою даних для отримання потрібної інформації та
повертає її клієнтській частині для відображення;
оновлення заявки – технічний спеціаліст може оновлювати
інформацію про заявку, змінювати її статус (наприклад, з "Нова" на "В
обробці" або "Виконана"), додавати коментарі або нові файли. Ці
оновлення передаються на сервер, де перевіряються та зберігаються у
базі даних;
фільтрація та пошук заявок – користувачі можуть фільтрувати заявки
за статусом або типом проблеми, що дозволяє швидко знайти
49
ЧДТУ 241923.025 ПЗ
необхідну інформацію. Фільтрація здійснюється на рівні клієнтської
частини або на сервері, залежно від запиту;
видалення заявки – у разі необхідності користувач може видалити
заявку, яка більше не є актуальною. Сервер отримує запит на
видалення, перевіряє права доступу користувача та видаляє запис із
бази даних.
Рисунок 3.2 – Функціональна схема системи управління заявками
Користувачі взаємодіють з клієнтським інтерфейсом, де ReactJS обробляє
введення даних та ініціює HTTP-запити до серверної частини, побудованої на
Express. Сервер приймає ці запити, обробляє дані, взаємодіє з базою даних
MongoDB та повертає відповідь клієнтській частині, яка відображає результат
для користувача.
Наприклад, коли користувач створює заявку, дані форми передаються на
сервер за допомогою axios, де відбувається валідація та зберігання даних. У разі
успішного збереження сервер надсилає підтвердження назад на клієнт, і
користувач бачить оновлений статус у своєму інтерфейсі.
Сервер також виконує функцію контролю доступу, забезпечуючи, що
тільки авторизовані користувачі можуть взаємодіяти із системою. За
50
ЧДТУ 241923.025 ПЗ
допомогою JWT токенів кожен користувач отримує доступ лише до своїх даних
або до заявок, на які він має право. Це сприяє підвищенню безпеки в системі,
адже кожен запит перевіряється на рівні серверу.
Функціональна схема відображає також обробку запитів на перегляд і
оновлення заявок. Коли технічний спеціаліст переглядає список заявок або
оновлює їхній статус, сервер приймає запити, звертається до бази даних,
виконує потрібні дії та надсилає результат назад на клієнтську частину для
відображення.
3.1.3 Опис логічної схеми системи
Логічна схема системи управління заявками визначає основні компоненти
та їхні взаємозв’язки, а також обґрунтовує вибір архітектурного шаблону, на
якому базується програмне забезпечення. Система реалізована з використанням
архітектурного шаблону "клієнт-сервер" (client-server) у варіанті з розділеним
фронтендом та бекендом, що забезпечує гнучкість, масштабованість і
незалежність кожного з компонентів.
Шаблон "клієнт-сервер" є класичним підходом до побудови веб-
застосунків, де клієнтська частина відповідає за інтерфейс користувача, а
серверна частина виконує всі бізнес-логіку та обробку даних. У цьому випадку,
клієнт (frontend) і сервер (backend) є незалежними модулями, які взаємодіють
між собою через стандартизовані інтерфейси (API) за допомогою HTTP-запитів.
Така архітектура дозволяє легко змінювати або масштабувати кожен з
компонентів, не впливаючи на інші частини системи.
Клієнтська частина, реалізована на ReactJS, відповідає за відображення
інтерфейсу, забезпечення взаємодії з користувачем та обробку основних дій
(такі як створення, перегляд і редагування заявок). Вона взаємодіє з сервером
через API, надсилаючи HTTP-запити до бекенду для обробки інформації.
Сервер, реалізований на Node.js із фреймворком Express, приймає запити від
клієнта, виконує необхідні операції (зокрема, перевірку автентифікації
користувачів за допомогою JWT, хешування паролів за допомогою bcrypt,
обробку заявок тощо) та взаємодіє з базою даних MongoDB для зберігання та
51
ЧДТУ 241923.025 ПЗ
отримання інформації.
Компоненти логічної схеми:
Frontend (ReactJS): клієнтська частина системи складається з набору
компонентів React, які відповідають за інтерфейс користувача.
Основні компоненти включають реєстрацію, авторизацію, створення
та перегляд заявок. React працює із віртуальним DOM, що забезпечує
ефективне оновлення елементів на сторінці, надаючи користувачеві
швидкий і динамічний інтерфейс [14].
Backend (Node.js + Express): серверна частина відповідає за обробку
всіх запитів від клієнта, виконання бізнес-логіки та забезпечення
взаємодії з базою даних. Використання фреймворка Express дозволяє
зручно налаштовувати маршрути для роботи з API та забезпечує
легкість інтеграції з іншими компонентами. Сервер також включає
логіку авторизації, використовуючи JWT для забезпечення безпеки
доступу до системи. За допомогою bcrypt здійснюється хешування
паролів, що дозволяє зберігати дані безпечно.
Database (MongoDB Atlas): база даних у цій архітектурі виступає як
постійне сховище для даних про користувачів і заявки. MongoDB
Atlas, як хмарний сервіс MongoDB, забезпечує зручний доступ до бази
даних через інтернет та підтримує масштабованість [3]. MongoDB
зберігає дані в JSON-подібному форматі, що робить його добре
сумісним із JavaScript-орієнтованим середовищем Node.js. Для роботи
з MongoDB у Node.js використовується бібліотека mongoose, яка
дозволяє легко створювати моделі даних, забезпечувати валідацію і
проводити операції CRUD.
Логічна схема системи (рис. 3.3) підтримує розділення обов’язків між
клієнтом і сервером, що дає можливість незалежно розвивати кожну з частин.
Клієнтський інтерфейс зосереджується на взаємодії з користувачем, а сервер
виконує всю бізнес-логіку і доступ до бази даних. Це дозволяє швидко
оновлювати інтерфейс або додавати нові функції, не змінюючи основну логіку
52
ЧДТУ 241923.025 ПЗ
на сервері.
Архітектура також базується на принципі RESTful API для обміну даними
між клієнтом і сервером. Це забезпечує зручність у роботі з HTTP-запитами,
зокрема, для отримання (GET), створення (POST), оновлення (PUT) та
видалення (DELETE) даних. Такий підхід робить систему більш гнучкою та
дозволяє розширювати її функціональність за рахунок додавання нових
маршрутів API.
Рисунок 3.3 – Логічна схема проєкту системи управління заявками.
3.1.4 Розробка бази даних
Для системи управління заявками було обрано базу даних MongoDB,
оскільки вона забезпечує гнучку модель даних та добре інтегрується з
екосистемою Node.js. MongoDB є нереляційною базою даних, яка зберігає
інформацію у вигляді документів у JSON-подібному форматі [3]. Це дозволяє
зручно зберігати складні об’єкти, зокрема дані про заявки та користувачів, та
забезпечує можливість масштабування.
У базі даних було створено дві основні колекції: User Collection (колекція
53
ЧДТУ 241923.025 ПЗ
користувачів) та Ticket Collection (колекція заявок). Кожна з цих колекцій має
свою унікальну структуру, що відображає відповідні об'єкти в системі.
User Collection зберігає інформацію про користувачів, які мають доступ
до системи. Кожен користувач має унікальний обліковий запис, що містить
інформацію, необхідну для автентифікації та ідентифікації, а також права
доступу. Структура документів у User Collection містить такі поля:
_id: унікальний ідентифікатор користувача, автоматично створюється
MongoDB.
first_name: ім'я користувача.
last_name: прізвище користувача.
email: електронна пошта, яка також виступає як унікальний
ідентифікатор для входу.
password: хеш пароля користувача, збережений у захищеному вигляді
за допомогою бібліотеки bcrypt.
role: роль користувача в системі (наприклад, звичайний користувач
або технічний спеціаліст).
Ticket Collection зберігає інформацію про заявки, створені користувачами.
Кожна заявка містить інформацію про проблему, яку необхідно вирішити, а
також статус її обробки. Структура документів у Ticket Collection містить такі
поля:
_id: унікальний ідентифікатор заявки, автоматично створюється
MongoDB.
title: назва заявки, що коротко описує проблему.
description: детальний опис проблеми, наданий користувачем.
status: поточний статус заявки (наприклад, "Нова", "В обробці",
"Виконана", "Скасована").
user_id: посилання на користувача, який створив заявку, що дозволяє
зберігати зв’язок між заявкою та її автором.
comments: масив коментарів, доданих технічним спеціалістом під час
54
ЧДТУ 241923.025 ПЗ
обробки заявки.
attachments: масив файлів або зображень, які прикріплені до заявки.
date_created: дата створення заявки.
ER-діаграма (рис 3.4) відображає основні сутності системи та їх
взаємозв’язки. У даному випадку діаграма показує дві основні сутності: User і
Ticket. User має зв'язок "один до багатьох" з Ticket, оскільки один користувач
може створити багато заявок, але кожна заявка належить лише одному
користувачу. Крім того, Ticket може мати зв’язок з технічним спеціалістом
(assigned_to), що вказує, який спеціаліст обробляє заявку.
Рисунок 3.4 – Діаграма - модель «сутність-зв'язок»
3.1.5 Розробка інтерфейсу користувача
Інтерфейс користувача для системи управління заявками був створений
на основі бібліотеки ReactJS, що забезпечує динамічний і інтерактивний досвід
55
ЧДТУ 241923.025 ПЗ
для користувачів. Основними вимогами до інтерфейсу є простота, інтуїтивність
і зручний доступ до основних функцій системи, таких як створення заявок,
перегляд існуючих заявок і редагування профілю. Інтерфейс також має
підтримувати зручну навігацію для різних категорій користувачів, таких як
звичайні користувачі та технічні спеціалісти.
Головна сторінка після входу користувача містить вітальне повідомлення
і служить стартовою точкою для навігації по системі. Сторінка реєстрації та
входу надає можливість створити новий обліковий запис або виконати вхід у
систему. Під час реєстрації користувач вводить основні дані, такі як ім'я,
прізвище, електронну пошту та пароль, що надалі використовуються для
автентифікації. Сторінка профілю містить персональні дані користувача,
включаючи його ім’я, прізвище, електронну пошту та роль у системі, які можна
переглянути для підтвердження інформації.
Сторінка створення заявки дозволяє користувачу внести необхідні дані,
такі як назва заявки, опис проблеми, повідомлення, і, за потреби, прикріпити
файл. Після заповнення форми користувач відправляє заявку, яка зберігається в
базі даних та передається технічним спеціалістам для обробки. Сторінка
перегляду заявок дозволяє користувачам переглядати всі власні заявки, а
технічним спеціалістам — бачити всі заявки, що потребують обробки. Заявки
відображаються у вигляді таблиці з інформацією про назву, зміст, статус,
зображення та повідомлення, що полегшує роботу з заявками.
Інтерфейс підтримує фільтрацію заявок за статусом, таким як "Відкриті",
"Очікують" та "Закриті", що дозволяє швидко знаходити потрібні заявки,
особливо у великих масивах даних. Також передбачена функція пошуку за
назвою заявки для додаткової зручності. Крім того, є функціональність
додавання повідомлень до заявки, що сприяє покращенню комунікації між
користувачем і технічним спеціалістом, дозволяючи їм обмінюватися важливою
інформацією.
Дизайн інтерфейсу виконано у сучасному мінімалістичному стилі з
використанням бібліотек Bootstrap і Material-UI, що надає готові компоненти
56
ЧДТУ 241923.025 ПЗ
для створення зрозумілого і привабливого інтерфейсу. Адаптивний дизайн
забезпечує коректне відображення на різних пристроях, таких як мобільні
телефони та планшети. Елементи управління і кнопки на кожній сторінці
розташовані зручно та мають великі розміри, що спрощує взаємодію
користувачів із системою, навіть якщо вони користуються нею вперше.
Для обробки HTTP-запитів до серверної частини використовується
бібліотека axios, що дозволяє легко надсилати і отримувати дані, необхідні для
виконання функцій інтерфейсу. ReactJS, у свою чергу, забезпечує ефективне
оновлення інтерфейсу завдяки використанню віртуального DOM, що мінімізує
кількість змін у реальному DOM і підвищує продуктивність системи.
Компонентна архітектура ReactJS дозволяє розділити функціональність на
окремі модулі, що значно спрощує підтримку, розширення та масштабування
інтерфейсу.
Загалом, розроблений інтерфейс відповідає всім вимогам зручності та
простоти, що робить систему управління заявками легкою у використанні як
для звичайних користувачів, так і для технічних спеціалістів. Реалізація на
основі ReactJS у поєднанні з Bootstrap та Material-UI забезпечує інтуїтивний і
сучасний дизайн, завдяки якому користувачі можуть швидко й ефективно
виконувати необхідні операції.
Нижче (рис 3.5 – 3.10) пресдтавлено розроблений інтерфейс користувача:
Рисунок 3.5 – Сторінка реєстарції
57
ЧДТУ 241923.025 ПЗ
Рисунок 3.6 – Сторінка входу в обілковий запис
Рисунок 3.7 – Головна сторінка системи управління заявками
58
ЧДТУ 241923.025 ПЗ
Рисунок 3.8 – Сторінка додавання заявки
Рисунок 3.9 – Список заявок
59
ЧДТУ 241923.025 ПЗ
Рисунок 3.10 – Інформація про користувача
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів системи управління заявками
включала створення клієнтської та серверної частин, а також взаємодію з базою
даних. Основна мета — забезпечити ефективну обробку запитів користувачів,
зберігання й управління даними заявок, а також зручний інтерфейс для
взаємодії користувачів із системою. У цій системі були реалізовані різні
програмні компоненти, які взаємодіють між собою через чітко визначені
інтерфейси.
Серверна частина системи побудована на Node.js із використанням
фреймворка Express, що забезпечує легкість у налаштуванні маршрутизації та
обробки запитів. Серверна частина відповідає за отримання HTTP-запитів від
клієнта, виконання бізнес-логіки та взаємодію з базою даних MongoDB. За
допомогою бібліотеки mongoose, яка забезпечує зручний інтерфейс для
взаємодії з MongoDB, створено моделі даних для зберігання інформації про
користувачів і заявки. Наприклад, модель користувача містить поля для
зберігання імені, прізвища, електронної пошти, пароля та ролі користувача.
60
ЧДТУ 241923.025 ПЗ
Модель заявки містить поля для назви, опису, статусу, а також інформацію про
прикріплені файли та коментарі.
Серверні маршрути забезпечують доступ до основних функцій системи.
Маршрути для реєстрації та автентифікації користувачів дозволяють
створювати нові облікові записи та перевіряти надані дані під час входу до
системи. Вхід користувача в систему виконується через JSON Web Tokens
(JWT), що дозволяє здійснювати безпечну автентифікацію, а також дозволяє
зберігати й передавати інформацію про сесію користувача без необхідності
повторного входу.
Маршрути для управління заявками включають створення нової заявки,
оновлення статусу існуючої заявки, видалення заявки, а також перегляд усіх
заявок для адміністратора або заявок конкретного користувача. Всі ці операції
забезпечуються відповідними функціями, реалізованими у контролерах Node.js.
Наприклад, функція створення заявки отримує дані з форми, зберігає їх у
MongoDB і повертає відповідь клієнту. У разі оновлення статусу заявки сервер
отримує запит від технічного спеціаліста, змінює статус заявки в базі даних та
повертає оновлену інформацію на клієнт.
Клієнтська частина системи побудована на ReactJS і забезпечує
взаємодію користувачів із системою через інтерфейс, розроблений із
використанням компонентів Bootstrap і Material-UI. Клієнтські компоненти
дозволяють користувачам виконувати основні операції з заявками, такі як
створення, перегляд і фільтрація заявок, зміна їх статусу, а також додавання
коментарів. Наприклад, компонент створення заявки дозволяє користувачу
заповнити форму, після чого дані передаються на сервер для зберігання. Інший
компонент відповідає за відображення списку заявок з можливістю пошуку та
фільтрації, що допомагає користувачам зручно знаходити необхідні записи.
Для забезпечення зв’язку між клієнтом і сервером використовується
бібліотека axios, яка дозволяє надсилати HTTP-запити з клієнтської частини до
серверних маршрутів та отримувати необхідну інформацію. Наприклад, під час
входу користувача axios надсилає запит на сервер, який обробляє дані для
61
ЧДТУ 241923.025 ПЗ
автентифікації та повертає токен доступу, що дозволяє користувачу взаємодіяти
з іншими частинами системи. Крім того, розроблені компоненти були розділені
на окремі модулі, що забезпечує зручність у підтримці та розширенні системи.
Компонентна архітектура React дозволяє легко додавати нові функції, не
впливаючи на вже існуючі елементи інтерфейсу. Наприклад, додавання нового
компонента для пошуку заявок по імені або фільтрації за статусом може бути
реалізоване без значних змін у базовій структурі застосунку.
Таким чином, розробка програмних компонентів системи управління
заявками базувалася на створенні гнучкої і легко підтримуваної архітектури.
Серверна частина забезпечує надійну обробку запитів і зберігання даних,
клієнтська частина надає користувачам інтуїтивний інтерфейс для виконання
необхідних операцій, а бібліотеки axios і mongoose значно спрощують обробку
запитів і роботу з базою даних. Усі компоненти працюють узгоджено,
забезпечуючи стабільну і надійну роботу системи.
3.2 Тестування системи
Тестування системи управління заявками проводилось для перевірки її
функціональності, надійності та відповідності вимогам. Основною метою
тестування було виявлення та усунення помилок, забезпечення коректної
роботи кожного модуля системи, а також перевірка її працездатності в умовах
реального використання. Процес тестування включав як модульне тестування
окремих компонентів, інтеграційне, системне та приймальне тестування для
перевірки взаємодії між клієнтською і серверною частинами системи.
3.2.1 Модульне тестування
Модульне тестування системи управління заявками проводилось для
перевірки коректної роботи окремих компонентів і функцій системи в умовах
ізольованого виконання. Основною метою цього тестування було виявлення та
усунення помилок на ранніх етапах розробки, забезпечення стабільності
кожного модуля та підтвердження відповідності компонентів вимогам системи
[17]. Тестування здійснювалось з використанням бібліотек Jest для клієнтської
62
ЧДТУ 241923.025 ПЗ
частини, яка реалізована на ReactJS, та Mocha разом із Chai для серверної
частини на Node.js.
Клієнтська частина системи була протестована на рівні окремих
компонентів, щоб забезпечити коректне відображення та функціонування
інтерфейсу користувача. Наприклад, компонент реєстрації перевірявся на
здатність обробляти введення даних, перевіряти обов'язкові поля та коректність
електронної пошти. Компонент входу до системи тестувався на можливість
введення логіна та пароля, а також на обробку відповіді сервера після
надсилання запиту. Компонент створення заявки перевірявся на коректність
роботи з полями форми, включаючи валідацію та обробку помилок при
порожніх полях. Також тестувався компонент перегляду заявок для перевірки
коректного відображення даних, що надходять із сервера, а також
функціональності фільтрації заявок за статусом і пошуку за назвою.
Серверна частина на Node.js, реалізована з використанням Express, була
протестована на рівні функцій контролерів і маршрутизаторів. Це включало
перевірку коректності роботи маршруту для реєстрації, зокрема валідацію
введених даних, перевірку унікальності електронної пошти та хешування
пароля. Для маршруту входу в систему перевірялась обробка запиту на
автентифікацію користувача, включаючи перевірку електронної пошти та
пароля, а також створення JWT-токена для доступу. Маршрут створення заявки
тестувався на можливість зберігання даних у базі та обробку обов'язкових
полів, а маршрут перегляду заявок перевірявся на можливість отримання заявок
з бази даних із належним обмеженням доступу відповідно до ролі користувача.
Також тестувались можливості оновлення статусу заявки технічним
спеціалістом та обмеження прав доступу для забезпечення, що тільки
спеціалісти мають право змінювати статус заявки.
Результати модульного тестування підтвердили стабільну роботу кожного
компонента в ізольованих умовах. Під час тестування клієнтської частини були
виявлені незначні помилки у відображенні повідомлень про помилки, які
швидко виправили. У серверній частині тестування виявило кілька проблем із
63
ЧДТУ 241923.025 ПЗ
валідацією даних у маршрутах реєстрації та входу в систему, які також були
виправлені шляхом додавання детальних повідомлень про помилки та
покращеної перевірки даних. Модульне тестування забезпечило високу якість
коду та полегшило процес інтеграційного тестування і впровадження системи.
Нижче наведено розроблений модульний тест для тестування компоненту
реєстрації:
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import RegisterComponent from './RegisterComponent';
test('renders registration form with all fields', () => {
render(<RegisterComponent />);
expect(screen.getByLabelText(/First Name/i)).toBeInTheDocument();
expect(screen.getByLabelText(/Last Name/i)).toBeInTheDocument();
expect(screen.getByLabelText(/Email/i)).toBeInTheDocument();
expect(screen.getByLabelText(/Password/i)).toBeInTheDocument();
});
test('displays error message if required fields are empty', () => {
render(<RegisterComponent />);
fireEvent.click(screen.getByText(/Register/i));
expect(screen.getByText(/First Name is required/i)).toBeInTheDocument();
expect(screen.getByText(/Email is required/i)).toBeInTheDocument();
});
64
ЧДТУ 241923.025 ПЗ
test('submits form when fields are filled correctly', () => {
render(<RegisterComponent />);
fireEvent.change(screen.getByLabelText(/First Name/i), { target: { value:
'John' } });
fireEvent.change(screen.getByLabelText(/Last Name/i), { target: { value:
'Doe' } });
fireEvent.change(screen.getByLabelText(/Email/i), { target: { value:
'[email protected]' } });
fireEvent.change(screen.getByLabelText(/Password/i), { target: { value:
'password123' } });
fireEvent.click(screen.getByText(/Register/i));
expect(screen.queryByText(/First Name is required/i)).toBeNull();
expect(screen.queryByText(/Email is required/i)).toBeNull();
});
Рисунок 3.11 – Результат виконання модульного тесту
65
ЧДТУ 241923.025 ПЗ
Таблиця 3.1
Результати модульного тестування
№ Назва модуля Тестовий Очікуваний Фактичний Статус
сценарій результат результат
1 UserFunctions Тестування Користувач Користувач Пройдено
функції реєстрації успішно успішно
нового додається до бази додається до бази
користувача даних даних
2 UserFunctions Тестування Система повертає Система повертає Пройдено
функції токен доступу для токен доступу для
аутентифікації вірного логіна і вірного логіна і
користувача пароля пароля
3 TicketFunctions Тестування Заявка додається Заявка додається Пройдено
створення нової до бази даних до бази даних
заявки
4 TicketFunctions Тестування зміни Статус заявки Статус заявки Пройдено
статусу заявки оновлюється у оновлюється у
базі даних базі даних
5 TicketFunctions Тестування Коментар успішно Коментар успішно Пройдено
додавання додається до додається до
коментаря до відповідної заявки відповідної заявки
заявки
6 TicketShow Тестування Відображаються Відображаються Пройдено
відображення всі заявки всі заявки
списку заявок користувача користувача
7 TicketShow Тестування Відображається Відображається Пройдено
пошуку заявки за відповідна заявка відповідна заявка
ідентифікатором
8 UserFunctions Тестування Система повертає Система повертає Пройдено
отримання інформацію про інформацію про
профілю користувача користувача
користувача
66
ЧДТУ 241923.025 ПЗ
3.2.2 Інтеграційне тестування
Інтеграційне тестування системи управління заявками проводилося з
метою перевірки взаємодії між клієнтською і серверною частинами, а також для
забезпечення узгодженості роботи всіх основних компонентів системи в
комплексі. Основною метою було переконатися, що всі частини системи
правильно взаємодіють між собою, дані передаються і обробляються коректно,
а користувачі можуть безперешкодно виконувати необхідні операції [18].
Інтеграційне тестування охопило такі ключові функції: реєстрація та
автентифікація користувачів, створення заявок, отримання списку заявок,
оновлення статусу заявки, а також роботу з коментарями до заявок. Було
важливо забезпечити, щоб кожен процес, що включає декілька компонентів
(сервер, база даних, клієнтська частина), виконувався коректно і без помилок.
Наступним кроком було проведення тестовиї сценаріїв:
Тест 1: Реєстрація нового користувача.
Сценарій: користувач вводить правильні дані в форму реєстрації і
натискає кнопку для підтвердження. Очікуваний результат: дані передаються на
сервер, сервер виконує валідацію і зберігає новий обліковий запис у базі даних,
а клієнтська частина отримує повідомлення про успішну реєстрацію.
Результат: тест успішно пройдено. Користувач зареєстрований, сервер
повернув статус 201 і повідомлення "User registered successfully". Всі поля
заповнені правильно, помилок не виявлено.
Тест 2: Вхід користувача.
Сценарій: користувач вводить логін і пароль у форму входу і натискає
кнопку для підтвердження. Очікуваний результат: сервер перевіряє дані,
створює JWT-токен і повертає його клієнтській частині. Клієнт зберігає токен і
дозволяє користувачу отримати доступ до захищених розділів системи.
Результат: тест пройдено. Після правильного введення даних користувач
успішно автентифікований і отримав токен. Клієнтська частина зберегла токен,
користувач отримав доступ до основних функцій системи.
Тест 3: Створення заявки.
67
ЧДТУ 241923.025 ПЗ
Сценарій: авторизований користувач заповнює форму для створення
заявки, включаючи назву, опис і прикріплення файлів, і натискає кнопку
підтвердження. Очікуваний результат: клієнтська частина надсилає дані на
сервер, сервер перевіряє дані, зберігає заявку в базі і повертає повідомлення про
успішне створення.
Результат: тест успішно пройдено. Заявка створена, дані коректно
збереглися в базі, сервер повернув статус 201 і повідомлення "Ticket created
successfully". Користувач отримав підтвердження про створення заявки.
Тест 4: Оновлення статусу заявки.
Сценарій: технічний спеціаліст змінює статус заявки, наприклад, з
"Очікує" на "В обробці". Очікуваний результат: клієнтська частина надсилає
запит на оновлення статусу заявки, сервер обробляє запит, оновлює статус у
базі даних і повертає підтвердження.
Результат: тест успішно пройдено. Статус заявки було оновлено на
сервері, і оновлені дані відображені на інтерфейсі користувача. Користувач
побачив оновлений статус без необхідності перезавантаження сторінки.
Таблиця 3.2
Результати інтеграційного тестування
№ Тестова Сценарій Очікуваний Фактичний Статус
функція результат результат
1 Реєстрація Користувач Дані передаються Дані коректно Пройдено
користувача вводить на сервер, збережено у
правильні дані зберігаються у базі, сервер
у форму базі даних, повернув
реєстрації, повертається статус 201 і
натискає повідомлення відповідне
кнопку "User registered повідомлення.
підтвердження. successfully". Помилок не
виявлено.
68
ЧДТУ 241923.025 ПЗ
Продовження таблиці 3.2
2 Вхід Користувач Сервер перевіряє Сервер Пройдено
користувач вводить логін і дані, створює повернув
а пароль, JWT-токен, токен, клієнт
натискає повертає успішно
кнопку клієнтській отримав
підтвердження. частині, клієнт доступ до
зберігає токен. захищених
розділів
системи.
3 Створення Авторизований Сервер перевіряє Заявка Пройдено
заявки користувач дані, зберігає створена, дані
заповнює заявку в базі коректно
форму заявки і даних, повертає зберігаються у
натискає статус 201 і базі, клієнт
кнопку повідомлення отримав
підтвердження. "Ticket created підтвердження
successfully". .
4 Оновлення Технічний Сервер оновлює Статус заявки Пройдено
статусу спеціаліст статус заявки в успішно
заявки змінює статус базі даних, змінено, зміни
заявки через повертає коректно
інтерфейс підтвердження, відображені у
системи. клієнт бачить клієнтському
оновлений статус інтерфейсі.
без
перезавантаження.
69
ЧДТУ 241923.025 ПЗ
Продовження таблиці 3.2
5 Додавання Авторизований Сервер зберігає Коментар Пройдено
коментаря користувач коментар у базі, успішно
додає коментар повертає додано, дані
до існуючої підтвердження, коректно
заявки через коментар зберігаються і
відповідну відображається у відображаютьс
форму. списку я у
коментарів. клієнтському
інтерфейсі.
6 Отримання Користувач Сервер повертає Список заявок Пройдено
списку відкриває список заявок, що успішно
заявок сторінку зі зберігаються у отримано і
списком заявок базі, клієнт відображено,
через особистий відображає їх у жодних
кабінет. вигляді таблиці. помилок у
передачі даних
не виявлено.
3.2.3 Системне тестування
Системне тестування системи управління заявками проводилося для
перевірки повної відповідності функціональним та нефункціональним вимогам,
а також для оцінки стабільності роботи системи під навантаженням. Основною
метою цього етапу було переконатися, що вся система працює належним
чином, а її компоненти взаємодіють коректно у реальних умовах використання
[19]. Системне тестування включало перевірку функціональності,
продуктивності, безпеки та зручності використання.
Наступним кроком було розроблено та виконано сценарії системного
тестування:
70
ЧДТУ 241923.025 ПЗ
Тест 1: Функціональність
Сценарій: перевірка всіх основних функцій системи, включаючи
реєстрацію, вхід, створення заявки, перегляд і оновлення статусу заявки,
додавання коментарів, а також вихід із системи.
Очікуваний результат: усі функції виконуються без помилок, користувач
отримує очікувані повідомлення про успішне виконання операцій, і дані
коректно зберігаються у базі.
Результат: тест пройдено успішно. Кожна функція працює належним
чином, система правильно обробляє всі запити користувача, а дані зберігаються
та відображаються коректно. Користувачі можуть реєструватися, входити в
систему, створювати заявки, переглядати їх, оновлювати статус та додавати
коментарі без жодних збоїв.
Тест 2: Продуктивність під навантаженням
Сценарій: одночасно в систему входять кілька користувачів, створюються
заявки та оновлюється їхній статус. Тестування проводилося з імітацією
одночасної роботи 100 користувачів.
Очікуваний результат: система стабільно обробляє запити користувачів
без значних затримок у відповіді та збереженні даних.
Результат: тест пройдено. Система продемонструвала стійкість під
навантаженням і коректно обробляла запити, затримки виявилися незначними
(до 1-2 секунд), що є прийнятним для даної системи. Навіть при навантаженні у
100 користувачів система зберігала стабільність та працездатність без збоїв.
Тест 3: Безпека
Сценарій: перевірка захищеності даних користувачів та доступу до
заявок, включаючи обмеження доступу до функцій системи відповідно до ролей
користувачів. Тестування включало спроби доступу до захищених ресурсів без
автентифікації та спроби доступу до чужих заявок.
Очікуваний результат: неавторизовані користувачі не мають доступу до
захищених розділів системи, користувачі можуть переглядати лише свої заявки,
а технічні спеціалісти можуть переглядати всі заявки.
71
ЧДТУ 241923.025 ПЗ
Результат: тест пройдено успішно. Система належним чином захищає
доступ до захищених розділів, неавторизовані користувачі отримують
повідомлення про відмову в доступі, а кожен авторизований користувач бачить
лише ті заявки, до яких має доступ. Технічні спеціалісти мають можливість
переглядати та оновлювати статус усіх заявок, тоді як звичайні користувачі
можуть переглядати лише свої.
Таблиця 3.3
Результати системного тестування
№ Тестова функція Сценарій Очікуваний Фактичний Статус
результат результат
1 Функціональніст Перевірка Усі функції Усі функції Пройдено
ь реєстрації, виконуються без працюють
входу, помилок, дані належним чином,
створення зберігаються система обробляє
заявки, коректно, запити
перегляду, користувач користувачів,
оновлення отримує дані зберігаються
статусу, очікувані і відображаються
додавання повідомлення. коректно.
коментарів.
2 Продуктивність Одночасна Система Система успішно Пройдено
під робота 100 стабільно обробляє
навантаженням користувачів обробляє запити навантаження,
, які без значних затримки
створюють затримок, дані відповіді до 1-2
заявки, коректно секунд, дані
оновлюють зберігаються і коректно
їх статус. відображаються обробляються.
72
ЧДТУ 241923.025 ПЗ
Продовження таблиці 3.3
3 Безпека Перевірка Неавторизовані Система успішно Пройдено
доступу до користувачі не блокує доступ
захищених мають доступу, для
розділів без кожен бачить неавторизованих
автентифіка лише свої користувачів,
ції, доступу заявки, технічні забезпечує
до чужих спеціалісти доступність
заявок. мають доступ до даних відповідно
всіх. до ролей.
3.2.4 Приймальне тестування
Приймальне тестування проводилося з метою підтвердження того, що
система управління заявками повністю відповідає заявленим вимогам і готова
до використання у виробничому середовищі [20]. На цьому етапі здійснювалася
остаточна перевірка функціональності, стабільності, безпеки та відповідності
системи специфікаціям проекту. У ході приймального тестування перевірялася
робота всіх основних функцій системи, включаючи реєстрацію користувачів,
автентифікацію, створення і редагування заявок, управління статусами та
доступом до заявок.
Приймальне тестування включало тестування системи з боку кінцевих
користувачів (звичайних користувачів та технічних спеціалістів) для оцінки
зручності використання та правильності роботи системи. Було перевірено
доступ до основних функцій системи, зокрема можливість створювати та
переглядати заявки, змінювати статуси, додавати коментарі, а також отримали
доступ до своїх профілів. Усі тестові дії проводилися у звичайних робочих
умовах, що дозволило оцінити реальну продуктивність системи.
За результатами приймального тестування було підтверджено, що
система працює стабільно і відповідає всім функціональним і
нефункціональним вимогам. Усі основні функції працюють належним чином,
73
ЧДТУ 241923.025 ПЗ
інтерфейс системи інтуїтивно зрозумілий, а користувачі можуть легко отримати
доступ до всіх необхідних розділів і функцій.
Система також пройшла перевірку на відповідність вимогам безпеки:
неавторизовані користувачі не мають доступу до закритих розділів, а права
доступу для авторизованих користувачів визначаються відповідно до їхніх
ролей. Це гарантує, що технічні спеціалісти можуть працювати із заявками
користувачів, тоді як звичайні користувачі можуть переглядати тільки свої
заявки, що підвищує рівень захищеності даних.
Усі виявлені під час приймального тестування незначні недоліки були
виправлені в процесі тестування, після чого система пройшла повторну
перевірку. Загалом, приймальне тестування підтвердило повну відповідність
системи управління заявками технічним вимогам, її готовність до розгортання і
використання у виробничому середовищі.
Таблиця 3.4
Результати приймального тестування
№ Тестова Сценарій Очікуваний Фактичний Статус
функція результат результат
1 Реєстрація Користувач Користувач Реєстрація Пройдено
користувача вводить дані в зареєстрований, успішна,
форму отримано користувач
реєстрації та повідомлення про отримав
підтверджує дію успішну повідомлення
реєстрацію, дані "User registered
збережено в базі successfully"
2 Автентифікаці Користувач Користувач Успішна Пройдено
я вводить логін та автентифікований, автентифікація,
пароль у форму отримано доступ до клієнт отримав
входу і захищених розділів, токен, доступ до
підтверджує створено JWT- функцій
дію. токен системи надано
74
ЧДТУ 241923.025 ПЗ
Продовження таблиці 3.4
3 Створення Авторизований Заявку створено, Заявку створено Пройдено
заявки користувач дані коректно успішно, сервер
заповнює форму збережено в базі, повернув статус
заявки, додає користувач отримав 201 і
файли та підтвердження про повідомлення
підтверджує успішне створення. "Ticket created
дію. successfully"
3.3 Приклади впровадженого програмного комплексу
Після успішного завершення тестування системи управління заявками,
планується впровадження у відділ технічної підтримки невеликої компанії, що
потребує регулярного обслуговування і швидкої технічної допомоги. Система
забезпечує централізований спосіб управління технічними запитами та
дозволить спростити процес вирішення інцидентів, покращити комунікацію
між технічними спеціалістами і співробітниками.
Нижче наведу опис роботи системи в реальному середовищі:
Співробітники компанії, які потребують технічної допомоги, подають
заявки через веб-інтерфейс системи, вказуючи тип проблеми, опис, рівень
пріоритету та, за необхідності, прикріплюючи файли, що допомагають
зрозуміти суть проблеми (наприклад, скріншоти або документи з описом
помилки). Після відправки заявки вона автоматично з’являється в системі
технічної підтримки зі статусом "Нова", а технічні спеціалісти отримують
повідомлення про новий запит.
Технічні спеціалісти мають доступ до інтерфейсу, де вони бачать всі нові,
незавершені або виконані заявки. Для зручності роботи всі заявки можна
фільтрувати за статусом, пріоритетом або датою створення. При отриманні
заявки спеціаліст змінює статус на "В обробці", вказуючи, що він почав
працювати над вирішенням проблеми. Система також дозволяє спеціалістам
75
ЧДТУ 241923.025 ПЗ
залишати коментарі до заявок, де вони можуть надавати проміжну інформацію
про стан вирішення, уточнювати деталі з ініціатором запиту або повідомляти
про очікуваний час завершення.
76
ЧДТУ 241923.025 ПЗ
Висновки до розділу 3
Розглянуто процес розробки, тестування та впровадження програмного
комплексу для системи управління заявками. Було описано розробку основних
компонентів, включаючи серверну і клієнтську частини, базу даних та
інтерфейс користувача.
Під час розробки програмного комплексу використано сучасний стек
технологій, що забезпечує надійність і гнучкість системи. Серверна частина,
реалізована на основі Node.js з фреймворком Express, забезпечує стабільну
обробку запитів та управління бізнес-логікою, тоді як клієнтська частина,
створена за допомогою ReactJS, пропонує інтуїтивний та зручний інтерфейс для
користувачів. Взаємодія між клієнтською і серверною частинами реалізована
через RESTful API, що полегшує інтеграцію компонентів та дозволяє
масштабувати систему.
База даних, розроблена на основі MongoDB, забезпечує зберігання всіх
необхідних даних про користувачів та заявки. Гнучка модель даних MongoDB
дозволяє легко адаптувати структуру бази до змін у вимогах і розширювати її
для подальшого розвитку. Реалізація моделей даних із використанням
бібліотеки Mongoose спрощує роботу з базою даних, забезпечуючи зручну
валідацію і можливості для управління об’єктами.
Інтерфейс користувача, розроблений із використанням бібліотек Material-
UI і Bootstrap, забезпечує зручність і привабливість зовнішнього вигляду
системи, а також адаптивність для різних пристроїв. Інтуїтивний дизайн
дозволяє користувачам легко виконувати основні операції, такі як створення
заявки, перегляд статусу запитів та спілкування з технічними спеціалістами.
Використання компонентів ReactJS значно спрощує підтримку та розширення
інтерфейсу, що робить систему гнучкою для подальших удосконалень.
Проведені модульне, інтеграційне, системне та приймальне тестування
підтвердили, що розроблений програмний комплекс відповідає всім
функціональним та нефункціональним вимогам. Модульне тестування
дозволило переконатися в коректній роботі кожного окремого компонента,
77
ЧДТУ 241923.025 ПЗ
інтеграційне тестування підтвердило взаємодію між клієнтською і серверною
частинами, а системне тестування засвідчило стабільність та продуктивність
системи під навантаженням. Приймальне тестування остаточно підтвердило
готовність системи до впровадження.
Загалом, розроблений програмний комплекс є стабільною, гнучкою та
масштабованою системою, що відповідає всім вимогам та готова до
подальшого розвитку і розширення.
78
ЧДТУ 241923.025 ПЗ
ЗАГАЛЬНІ ВИСНОВКИ
У ході кваліфікаційної роботи бакалавра було розроблено програмний
комплекс для системи управління заявками, призначений для полегшення
процесу комунікації між співробітниками та технічною підтримкою в
організаціях. На основі проведеного аналізу існуючих аналогів і сучасних
технологій було обрано оптимальні засоби для створення системи, що
забезпечує продуктивність, масштабованість і зручність використання.
Розробка програмного комплексу здійснювалась з використанням
сучасного технологічного стека: серверну частину побудовано на Node.js та
Express, клієнтську частину на ReactJS, а для управління даними використано
MongoDB. Такий підхід забезпечив високу швидкість і стабільність роботи
системи та гнучкість у процесі адаптації до змінних умов експлуатації.
Програмний інтерфейс, створений із використанням компонентів Material-UI та
Bootstrap, забезпечив інтуїтивність і привабливий вигляд, що полегшує доступ
до основних функцій для користувачів.
Система пройшла комплексне тестування, що включало модульне,
інтеграційне, системне та приймальне тестування. Кожен компонент був
протестований окремо, що дозволило виявити і виправити помилки на ранніх
етапах розробки. Інтеграційне тестування підтвердило узгоджену роботу між
компонентами, а системне тестування продемонструвало стабільність системи
під навантаженням і відповідність вимогам безпеки та зручності використання.
Приймальне тестування засвідчило повну готовність системи до експлуатації та
відповідність технічним і функціональним вимогам.
Таким чином, розроблена система управління заявками відповідає
поставленим завданням, забезпечуючи стабільну та ефективну роботу. Вона є
гнучкою для подальшого розвитку, що дозволяє легко розширювати
функціональні можливості й адаптувати систему до нових вимог і потреб
користувачів.
79
ЧДТУ 241923.025 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 jwt-decode - [Електронний ресурс] - Режим доступу:
https://www.npmjs.com/ package/jwt-decode
2 react-router-dom - [Електронний ресурс] - Режим доступу:
https://www.npmjs.com/package/react-router-dom
3 MongoDB Documentation - [Електронний ресурс] - Режим доступу:
https://www.mongodb.com/docs/manual/
4 Jira Service Managment - [Електронний ресурс] - Режим доступу:
https://www.atlassian.com/software/jira/service-management/product-guide/
5 Zendesk - [Електронний ресурс] - Режим доступу:
https://www.zendesk.com/about/
6 Freshdesk - [Електронний ресурс] - Режим доступу:
https://www.freshworks.com/products/what-is-freshdesk/
7 Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра
для здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного
забезпечення» усіх форм навчання [Текст] /Укл.: Голуб С.В., Заспа Г.О.,
Півень О.Б. Катаєва Є.Ю., Салапатов В.І., Метелап В.В., Олексюк В.В.;
М-во освіти і науки України.
8 Розгортання програмного забезпечення - [Електронний ресурс] - Режим
доступу:
https://uk.wikipedia.org/wiki/Розгортання_програмного_забезпечення
9 Діаграма класів - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_класів
10 Діаграма пакетів – [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_пакетів
11 Діаграма компонентів – [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_компонентів
12 Діаграма діяльності - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_діяльності
13 Діаграма станів (UML) - [Електронний ресурс] - Режим доступу:
80
ЧДТУ 241923.025 ПЗ
https://uk.wikipedia.org/wiki/Діаграма_станів_(UML)
14 React Documentation - [Електронний ресурс] - Режим доступу:
https://reactjs.org/docs/getting-started.html
15 Node.js Documentation - [Електронний ресурс] - Режим доступу:
https://nodejs.org/en/docs/guides/getting-started-guide
16 Express.js - [Електронний ресурс] - Режим доступу:
https://expressjs.com/en/
17 Модульне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Модульне_тестування
18 Інтеграційне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Інтеграційне_тестування
19 Системне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Системне_тестування
20 Приймальне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Приймальне_тестування
81
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С. В.
___________________________
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ СИСТЕМИ УПРАВЛІННЯ ЗАЯВКАМИ
ДЛЯ ЗВ'ЯЗКУ З ПРАЦІВНИКАМИ ТЕХНІЧНОГО ВІДДІЛУ
ПІДПРИЄМСТВА
Специфікація
482.ЧДТУ.241923-025
Листів 2
Розробник ________________ Хвостик А. О.
Керівник ________________ Півень О.Б.
Н. Контроль ________________ Півень О.Б.
Черкаси 2024
ЧДТУ. 24 1923.025
Позначення Найменування Примітка
482.ЧДТУ. 241923-025 12-01 Лістинг програми
482.ЧДТУ. 241923-025 34-01 Інструкція користувача
482.ЧДТУ. 241923-025 90-01 Графічні матеріали
83
ДОДАТОК Б
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ СИСТЕМИ УПРАВЛІННЯ ЗАЯВКАМИ ДЛЯ
ЗВ'ЯЗКУ З ПРАЦІВНИКАМИ ТЕХНІЧНОГО ВІДДІЛУ ПІДПРИЄМСТВА
Лістинг програми
482.ЧДТУ.241923 12 01
Листів 34
Розробник ________________ Хвостик А. О.
Черкаси 2024
482.ЧДТУ.241923 12 01
Landing.js
import React, { Component } from 'react'
class Landing extends Component {
render() {
return (
<div className="container">
<div className="jumbotron mt-5">
<div className="col-sm-12 mx-auto">
<h1 className="text-center">Вітаємо у системі управління заявками</h1>
</div>
</div>
</div>
)
}
}
export default Landing
Login.js
import React, { Component } from 'react'
import { login } from './UserFunctions'
class Login extends Component {
constructor() {
super()
this.state = {
email: '',
password: '',
error: {}
}
this.onChange = this.onChange.bind(this)
85
482.ЧДТУ.241923 12 01
this.onSubmit = this.onSubmit.bind(this)
}
onChange(e) {
this.setState({ [e.target.name]: e.target.value })
}
onSubmit(e) {
e.preventDefault()
const user = {
email: this.state.email,
password: this.state.password
}
login(user).then(res => {
if (res) {
this.props.history.push(`/`)
}
})
}
render() {
return (
<div className="container">
<div className="row">
<div className="col-md-6 mt-5 mx-auto">
<form noValidate onSubmit={this.onSubmit}>
<h1 className="h3 mb-3 font-weight-normal">Please sign in</h1>
<div className="form-group">
<label htmlFor="email">Email address</label>
<input
type="email"
86
482.ЧДТУ.241923 12 01
className="form-control"
name="email"
placeholder="Enter email"
value={this.state.email}
onChange={this.onChange}
/>
</div>
<div className="form-group">
<label htmlFor="password">Password</label>
<input
type="password"
className="form-control"
name="password"
placeholder="Password"
value={this.state.password}
onChange={this.onChange}
/>
</div>
<button
type="submit"
className="btn btn-lg btn-primary btn-block"
>
Sign in
</button>
</form>
</div>
</div>
</div>
)
}
}
export default Login
87
482.ЧДТУ.241923 12 01
TicketFunctions.js
import axios from 'axios'
export const ticket = newTicket => {
return axios
.post('tickets/addTickets', {
name: newTicket.name,
img: this.state.file,
content: newTicket.content,
messages: newTicket.messages
})
.then(response => {
console.log('New ticket success')
})
}
export const getTicket = test => {
return axios
.get('tickets/getTicketAll', {
//headers: { Authorization: ` ${this.getToken()}` }
})
.then(response => {
console.log(response)
return response.data
})
.catch(err => {
console.log(err)
})
}
Navbar.js
import React, { Component } from 'react'
88
482.ЧДТУ.241923 12 01
import { Link, withRouter } from 'react-router-dom'
class Landing extends Component {
logOut(e) {
e.preventDefault()
localStorage.removeItem('usertoken')
this.props.history.push(`/`)
}
render() {
const loginRegLink = (
<ul className="navbar-nav">
<li className="nav-item">
<Link to="/login" className="nav-link">
Login
</Link>
</li>
<li className="nav-item">
<Link to="/register" className="nav-link">
Register
</Link>
</li>
</ul>
)
const userLink = (
<ul className="navbar-nav">
<li className="nav-item">
<Link to="/addTicket" className="nav-link">
AddTicket
</Link>
</li>
<li className="nav-item">
89
482.ЧДТУ.241923 12 01
<Link to="/tickets" className="nav-link">
Tickets
</Link>
</li>
<li className="nav-item">
<Link to="/userProfile" className="nav-link">
Profile
</Link>
</li>
<li className="nav-item">
<a href="" onClick={this.logOut.bind(this)} className="nav-link">
Logout
</a>
</li>
</ul>
)
return (
<nav className="navbar navbar-expand-lg navbar-dark bg-dark rounded">
<button
className="navbar-toggler"
type="button"
data-toggle="collapse"
data-target="#navbarsExample10"
aria-controls="navbarsExample10"
aria-expanded="false"
aria-label="Toggle navigation"
>
<span className="navbar-toggler-icon" />
</button>
<div
className="collapse navbar-collapse justify-content-md-center"
90
482.ЧДТУ.241923 12 01
id="navbarsExample10"
>
<ul className="navbar-nav">
<li className="nav-item">
<Link to="/" className="nav-link">
Home
</Link>
</li>
</ul>
{localStorage.usertoken ? userLink : loginRegLink}
</div>
</nav>
)
}
}
export default withRouter(Landing)
Register.js
import React, { Component } from 'react'
import { register } from './UserFunctions'
class Register extends Component {
constructor() {
super()
this.state = {
first_name: '',
last_name: '',
email: '',
password: '',
role:'',
errors: {}
}
91
482.ЧДТУ.241923 12 01
this.onChange = this.onChange.bind(this)
this.onSubmit = this.onSubmit.bind(this)
}
onChange(e) {
this.setState({ [e.target.name]: e.target.value })
}
onSubmit(e) {
e.preventDefault()
const newUser = {
first_name: this.state.first_name,
last_name: this.state.last_name,
email: this.state.email,
password: this.state.password,
role:this.state.role
}
register(newUser).then(res => {
this.props.history.push(`/login`)
})
}
render() {
return (
<div className="container">
<div className="row">
<div className="col-md-6 mt-5 mx-auto">
<form noValidate onSubmit={this.onSubmit}>
<h1 className="h3 mb-3 font-weight-normal">Register</h1>
<div className="form-group">
<label htmlFor="name">First name</label>
92
482.ЧДТУ.241923 12 01
<input
type="text"
className="form-control"
name="first_name"
placeholder="Enter your first name"
value={this.state.first_name}
onChange={this.onChange}
/>
</div>
<div className="form-group">
<label htmlFor="name">Last name</label>
<input
type="text"
className="form-control"
name="last_name"
placeholder="Enter your lastname name"
value={this.state.last_name}
onChange={this.onChange}
/>
</div>
<div className="form-group">
<label htmlFor="email">Email address</label>
<input
type="email"
className="form-control"
name="email"
placeholder="Enter email"
value={this.state.email}
onChange={this.onChange}
/>
</div>
<div className="form-group">
<label htmlFor="password">Password</label>
93
482.ЧДТУ.241923 12 01
<input
type="password"
className="form-control"
name="password"
placeholder="Password"
value={this.state.password}
onChange={this.onChange}
/>
</div>
<button
type="submit"
className="btn btn-lg btn-primary btn-block"
>
Register!
</button>
</form>
</div>
</div>
</div>
)
}
}
export default Register
TicketModel.js
const mongoose = require('mongoose')
const moment = require('moment-timezone');
const timeZone = moment.tz(Date.now(),"Europe/Cherkasy");
const Schema = mongoose.Schema
// Create Schema
const messages = new mongoose.Schema({
94
482.ЧДТУ.241923 12 01
text: {
type: String,
},
date: {
type: Date,
default: timeZone,
},
files: {
type: Array
}
})
const TicketSchema = new Schema({
name: {
type: String
},
date: {
type: Date,
default: timeZone,
},
content: {
type: String
},
messages: {
type: [messages]
},
status: {
type: Number,
default: 0
},
95
482.ЧДТУ.241923 12 01
img: {
type:String
},
})
module.exports = User = mongoose.model('ticket', TicketSchema)
Ticket.js
import React, { Component } from 'react'
import axios from 'axios'
class Ticket extends Component {
constructor() {
super()
this.state = {
name: '',
content: '',
messages:'',
status:'',
img:'',
file: '',
imagePreviewUrl: '',
errors: {}
}
this.onChange = this.onChange.bind(this)
this.onSubmit = this.onSubmit.bind(this)
}
onChange(e) {
this.setState({ [e.target.name]: e.target.value })
}
96
482.ЧДТУ.241923 12 01
_handleSubmit(e) {
e.preventDefault();
// TODO: do something with -> this.state.file
console.log('handle uploading-', this.state.file);
console.log('file burada');
}
_handleImageChange(e) {
e.preventDefault();
let reader = new FileReader();
let file = e.target.files[0];
reader.onloadend = () => {
this.setState({
file: file,
imagePreviewUrl: reader.result
});
}
reader.readAsDataURL(file)
}
onSubmit(e) {
e.preventDefault()
console.log("ONSUBMİTTE")
let formData = new FormData()
formData.append('img', this.state.file)
formData.append('name', this.state.name)
97
482.ЧДТУ.241923 12 01
formData.append('content', this.state.content)
formData.append('messages', this.state.messages)
axios({
method: 'post',
url: 'tickets/addTickets',
data: formData,
headers: {'Content-Type': 'multipart/form-data' }
})
.then(function (response) {
//handle success
console.log(response);
})
.catch(function (response) {
//handle error
console.log(response);
})
}
onChangeHandler=event=>{
console.log(event.target.files[0])
}
render() {
let {imagePreviewUrl} = this.state;
let $imagePreview = null;
if (imagePreviewUrl) {
$imagePreview = (<img src={imagePreviewUrl} />);
} else {
$imagePreview = (<div className="previewText">Please select an Image for Preview</div>);
}
98
482.ЧДТУ.241923 12 01
return (
<div className="container">
<div className="jumbotron mt-5">
<div className="col-sm-8 mx-auto">
<h1 className="text-center">ADD TICKET</h1>
</div>
<form encType="multipart/form-data" noValidate onSubmit={this.onSubmit} >
<div>
<label htmlFor="name" className="mx-3"><p>Ticket Name</p></label>
<input type="text" id="name" className="mx-2"placeholder="Enter ticket name"
value={this.state.name}
onChange={this.onChange} name="name" required ></input>
</div>
<br></br>
<div>
<label htmlFor="content" className="mx-3"><p>Content</p></label>
<textarea id="content" name="content" className="mx-4" rows="2" styles={{}}
placeholder="Enter content"
value={this.state.content}
onChange={this.onChange} required>
</textarea>
</div>
<br></br>
<div>
<label htmlFor="content" className="mx-3">Message</label>
<textarea id="messages" className="mx-3" name="messages" rows="2" className="mx-3"
placeholder="Enter Message"
value={this.state.messages.text}
onChange={this.onChange} required>
99
482.ЧДТУ.241923 12 01
</textarea>
</div>
<br></br>
<div className="previewComponent">
<form onSubmit={(e)=>this._handleSubmit(e)}>
<input className="fileInput"
type="file"
onChange={(e)=>this._handleImageChange(e)} />
<button className="submitButton"
type="submit"
onClick={(e)=>this._handleSubmit(e)}>Upload Image</button>
</form>
</div>
<br></br>
<div>
<button type="submit">Submit</button>
</div>
</form>
</div>
</div>
)
}
}
export default Ticket
TicketShow.js
import React, { Component , useState } from 'react'
import jwt_decode from 'jwt-decode'
import axios from 'axios'
import Table from '@material-ui/core/Table';
import TableBody from '@material-ui/core/TableBody';
100
482.ЧДТУ.241923 12 01
import TableCell from '@material-ui/core/TableCell';
import TableContainer from '@material-ui/core/TableContainer';
import TableHead from '@material-ui/core/TableHead';
import TableRow from '@material-ui/core/TableRow';
import { Dropdown,Badge,Modal} from 'react-bootstrap';
import Paper from '@material-ui/core/Paper';
import { Button } from 'react-bootstrap';
class ShowTickets extends Component {
constructor() {
super()
this.state = {
data:[],
show:false,
message:'',
id:'',
search:'',
}
this.handleChange = this.handleChange.bind(this)
}
getTicket = test => {
return axios
.get('tickets/getTicketAll', {
})
.then(response => {
this.setState({
data:response.data,
101
482.ЧДТУ.241923 12 01
})
let names=[]
response.data.map((item)=>{
names.push(item.name)
})
this.setState({
namesData:names
})
console.log(response.data)
return response.data
})
.catch(err => {
console.log(err)
})
}
handleChange(e) {
this.setState({[e.target.name]: e.target.value})
}
handleClose (id,messages){
this.setState({
show:false,
}
);
102
482.ЧДТУ.241923 12 01
}
editSearchTerm= (e)=>{
if(e.target.value){
this.setState({search:e.target.value})
const newData = this.state.data.filter((item) => {
const itemData = `${item.name.toUpperCase()} ${item.name.toUpperCase()}
${item.name.toUpperCase()}`;
const textData = e.target.value.toUpperCase();
return itemData.indexOf(textData) > -1;
});
this.setState({
data: newData,
});
}
else{
this.setState({
search:'',
});
this.getTicket()
}
}
handleAddMessage (id,messages){
this.addMessage(id,messages)
103
482.ЧДТУ.241923 12 01
this.setState({
show:false,
}
);
this.getTicket()
}
handleShow = (id) => this.setState({show:true,id:id});
componentDidMount() {
const token = localStorage.usertoken
const decoded = jwt_decode(token)
this.getTicket()
this.setState({
role: decoded.role,
})
}
changeStatus (id,status) {
return axios
.put('tickets/changeStatus', {
id,
status
})
104
482.ЧДТУ.241923 12 01
.then(response => {
this.getTicket()
return response.data
})
.catch(err => {
console.log(err)
})
}
statusFilter (status) {
return axios
.post('tickets/filterStatus', {
status
})
.then(response => {
this.setState({
data:response.data,
})
return response.data
})
.catch(err => {
console.log(err)
})
}
addMessage (id,messages) {
105
482.ЧДТУ.241923 12 01
return axios
.post('tickets/addMessages', {
id,messages
})
.then(response => {
this.setState({
data:response.data,
})
return response.data
})
.catch(err => {
console.log(err)
})
}
statusName(status) {
switch(status) {
case 0:
return <h5><Badge pill variant="primary">Opening</Badge></h5>
case 1:
return <h5><Badge pill variant="danger">Waiting</Badge></h5>
case 2:
return <h5><Badge pill variant="success">Closed</Badge></h5>
default:
return <h5><Badge pill variant="primary">Opening</Badge></h5>
}
}
106
482.ЧДТУ.241923 12 01
MakeItem = function(X) {
console.log(X)
return <option>{X}</option>;
};
render() {
return (
<div className="container">
{this.state.role === 1 ?
<div className="jumbotron mt-5">
<div className="col-sm-8 mx-auto">
<h1 className="text-center">ADMIN PAGE<br></br>TICKETS</h1>
</div>
<Button variant="primary" className="mx-1"
onClick={()=>this.statusFilter(0)}>Opening</Button>
<Button variant="danger" className="mx-1"
onClick={()=>this.statusFilter(1)}>Waiting</Button>
<Button variant="success" className="mx-1"
onClick={()=>this.statusFilter(2)}>Closed</Button>
<Button variant="dark" className="mx-1" onClick={()=>this.getTicket()}>ALL</Button>
<input style={{float:"right"}} value={this.state.search} placeholder="Search TicketName"
type="text" onChange={this.editSearchTerm}/>
<TableContainer component={Paper}>
<Table size="small" aria-label="a dense table">
<TableHead>
<TableRow>
<TableCell>TicketName</TableCell>
<TableCell align="right">Content</TableCell>
<TableCell align="right">İmage</TableCell>
107
482.ЧДТУ.241923 12 01
<TableCell align="right">Message</TableCell>
<TableCell align="right">Status</TableCell>
<TableCell align="right">Change Status</TableCell>
<TableCell align="right" >Add Message</TableCell>
</TableRow>
</TableHead>
<TableBody>
{this.state.data.length>0 && this.state.data.map((row,index)=>
<TableRow key={index}>
<TableCell component="th" scope="row">
{row.name}
</TableCell>
<TableCell align="right">{row.content}</TableCell>
<TableCell align="right"><a target="_parent"
href={`http://localhost:5000/public/${row.img}`}><img width="100px"
src={`http://localhost:5000/public/${row.img}`}></img></a></TableCell>
{row.messages.map((message)=>
<>
<span>{message.text}</span>
<br/>
</>
)}
<TableCell align="right">{this.statusName(row.status)}</TableCell>
<TableCell align="right"><Dropdown>
<Dropdown.Toggle size="sm" variant="success" id="dropdown-basic">
Change Status
</Dropdown.Toggle>
<Dropdown.Menu>
108
482.ЧДТУ.241923 12 01
<Dropdown.Item onClick={()=>this.changeStatus(row._id,0)}>Opening</Dropdown.Item>
<Dropdown.Item onClick={()=>this.changeStatus(row._id,1)}>Waiting</Dropdown.Item>
<Dropdown.Item onClick={()=>this.changeStatus(row._id,2)}>Closed</Dropdown.Item>
</Dropdown.Menu>
</Dropdown></TableCell>
<TableCell align="right"> <>
<Button name="addButton" size="sm" variant="primary"
onClick={()=>this.handleShow(row._id)}>
Add Message
</Button>
<Modal show={this.state.show} onHide={()=>this.handleClose()}>
<Modal.Header closeButton>
<Modal.Title>Add Message </Modal.Title>
</Modal.Header>
<Modal.Body><form>
<label>
Message :
<input type="text" name="message" value={this.state.message} onChange={this.handleChange} />
</label>
</form>
</Modal.Body>
<Modal.Footer>
<Button variant="secondary" onClick={()=>this.handleClose()}>
Close
</Button>
<Button variant="primary"
onClick={()=>this.handleAddMessage(this.state.id,this.state.message)}>
Add Message
</Button>
</Modal.Footer>
109
482.ЧДТУ.241923 12 01
</Modal>
</>
</TableCell>
</TableRow>
)} </TableBody>
</Table>
</TableContainer>
</div>:
<div className="jumbotron mt-5">
<div className="col-sm-8 mx-auto">
<h1 className="text-center">USER PAGE<br></br>TICKETS</h1>
</div>
<TableContainer component={Paper}>
<Table size="small" aria-label="a dense table">
<TableHead>
<TableRow>
<TableCell>TicketName</TableCell>
<TableCell align="right">Content</TableCell>
<TableCell align="right">İmage</TableCell>
<TableCell align="right">Message</TableCell>
<TableCell align="right">Status</TableCell>
<TableCell align="right" >Add Message</TableCell>
</TableRow>
</TableHead>
<TableBody>
{this.state.data.length>0 && this.state.data.map((row,index)=>
<TableRow key={index}>
110
482.ЧДТУ.241923 12 01
<TableCell component="th" scope="row">
{row.name}
</TableCell>
<TableCell align="right">{row.content}</TableCell>
<TableCell align="right"><a target="_parent"
href={`http://localhost:5000/public/${row.img}`}><img width="100px"
src={`http://localhost:5000/public/${row.img}`}></img></a></TableCell>
{row.messages.map((message)=>
<>
<span>{message.text}</span>
<br/>
</>
)}
<TableCell align="right">{this.statusName(row.status)}</TableCell>
<TableCell align="right"> <>
<Button name="addButton" size="sm" variant="primary"
onClick={()=>this.handleShow(row._id)}>
Add Message
</Button>
<Modal show={this.state.show} onHide={()=>this.handleClose()}>
<Modal.Header closeButton>
<Modal.Title>Add Message</Modal.Title>
</Modal.Header>
<Modal.Body><form>
<label>
Message :
<input type="text" name="message" value={this.state.message} onChange={this.handleChange} />
</label>
</form>
</Modal.Body>
111
482.ЧДТУ.241923 12 01
<Modal.Footer>
<Button variant="secondary" onClick={()=>this.handleClose()}>
Close
</Button>
<Button variant="primary"
onClick={()=>this.handleAddMessage(this.state.id,this.state.message)}>
Add Message
</Button>
</Modal.Footer>
</Modal>
</>
</TableCell>
</TableRow>
)} </TableBody>
</Table>
</TableContainer>
</div>
}
</div>
)
}
}
export default ShowTickets
UserFunctions.js
import axios from 'axios'
export const register = newUser => {
return axios
.post('users/register', {
112
482.ЧДТУ.241923 12 01
first_name: newUser.first_name,
last_name: newUser.last_name,
email: newUser.email,
password: newUser.password,
role:newUser.role
})
.then(response => {
console.log('Registered')
})
}
export const login = user => {
return axios
.post('users/login', {
email: user.email,
password: user.password,
})
.then(response => {
localStorage.setItem('usertoken', response.data)
return response.data
})
.catch(err => {
console.log(err)
})
}
export const getProfile = user => {
return axios
.get('users/profile', {
//headers: { Authorization: ` ${this.getToken()}` }
})
.then(response => {
console.log(response)
113
482.ЧДТУ.241923 12 01
return response.data
})
.catch(err => {
console.log(err)
})
}
UserModel.js
const mongoose = require('mongoose')
const Schema = mongoose.Schema
const moment = require('moment-timezone');
const dateTr = moment.tz(Date.now(), "Europe/Cherkasy");
// Create Schema
const UserSchema = new Schema({
first_name: {
type: String
},
last_name: {
type: String
},
email: {
type: String,
required: true
},
password: {
type: String,
required: true
},
role: {
type: Number,
114
482.ЧДТУ.241923 12 01
default:0
},
date: {
type: Date,
default: dateTr
}
})
module.exports = User = mongoose.model('users', UserSchema)
UserProfile.js
import React, { Component } from 'react'
import jwt_decode from 'jwt-decode'
class userProfile extends Component {
constructor() {
super()
this.state = {
first_name: '',
last_name: '',
email: '',
role:'',
errors: {}
}
}
componentDidMount() {
const token = localStorage.usertoken
const decoded = jwt_decode(token)
console.log(decoded)
this.setState({
first_name: decoded.first_name,
last_name: decoded.last_name,
115
482.ЧДТУ.241923 12 01
email: decoded.email,
role:decoded.role
})
}
render() {
return (
<div className="container">
<div className="jumbotron mt-5">
<div className="col-sm-8 mx-auto">
<h1 className="text-center">PROFILE</h1>
</div>
<table className="table col-md-6 mx-auto">
<tbody>
<tr>
<td>Fist Name</td>
<td>{this.state.first_name}</td>
</tr>
<tr>
<td>Last Name</td>
<td>{this.state.last_name}</td>
</tr>
<tr>
<td>Email</td>
<td>{this.state.email}</td>
</tr>
<tr>
<td>role</td>
<td>{this.state.role}</td>
</tr>
</tbody>
</table>
</div>
116
482.ЧДТУ.241923 12 01
</div>
)
}
}
export default userProfile
117
ДОДАТОК В
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ СИСТЕМИ УПРАВЛІННЯ ЗАЯВКАМИ ДЛЯ
ЗВ'ЯЗКУ З ПРАЦІВНИКАМИ ТЕХНІЧНОГО ВІДДІЛУ ПІДПРИЄМСТВА
Інструкція користувача
482.ЧДТУ.241923 34 01
Листів 3
Розробник ________________ Хвостик А. О.
Черкаси 2024
482.ЧДТУ.241923 34 01
1. Користувач має змогу зареєструватися в системі, перейшовши на
вкладку "Реєстрація" у верхньому меню. Для цього потрібно ввести своє ім'я,
прізвище, електронну адресу та пароль, після чого натиснути кнопку
"Зареєструватися" для створення облікового запису. Після реєстрації
користувач може увійти до системи, перейшовши на вкладку "Вхід". Для входу
необхідно ввести свою електронну адресу та пароль, а потім натиснути кнопку
"Увійти".
Рисунок В.1 – Сторінка реєстрації користувача
Рисунок В.2 – Сторінка входу в обліковий запис
119
482.ЧДТУ.241923 34 01
2. Після входу користувач побачить головну сторінку з привітанням,
що підтверджує успішний вхід у систему. Користувач має змогу переглядати
свій профіль, перейшовши на вкладку "Обліковий запис", де відображається
його ім'я, прізвище та електронна адреса.
Рисунок В.3 – Головна сторінка системи керування заявками
3. Для створення нової заявки користувач може перейти на вкладку
"Додати заявку", де потрібно ввести назву заявки, опис проблеми та текст
повідомлення. Також є можливість завантажити зображення, що стосується
проблеми, за допомогою кнопки "Завантажити зображення". Після заповнення
всіх полів користувач натискає кнопку "Підвтердити" для створення заявки.
Рисунок В.3 – Сторінка створення заявки
120
482.ЧДТУ.241923 34 01
4. Користувач має змогу переглядати всі свої заявки у вкладці
"Заявки". Тут відображаються назва, опис, зображення (за наявності), статус
заявки та можливість додати повідомлення до заявки за допомогою кнопки
"Відповісти".
Рисунок В.4 – Сторінка з заявками
5. Якщо технічному спеціалісту необхідно змінити статус заявки
(наприклад, з "Відкрито" на "Очікує" або "Завершено"), він може скористатися
випадаючим меню в стовпці "Зміна статусу" на сторінці перегляду заявок, де
потрібно обрати відповідний статус зі списку. Також для швидкого пошуку
конкретної заявки користувач має змогу скористатися полем пошуку, яке
розташоване у правій верхній частині сторінки з заявками.
Рисунок В.5 – Випадаюче меню для зміни статусу заявки та поле пошуку заявок
121
ДОДАТОК Г
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ СИСТЕМИ УПРАВЛІННЯ ЗАЯВКАМИ ДЛЯ
ЗВ'ЯЗКУ З ПРАЦІВНИКАМИ ТЕХНІЧНОГО ВІДДІЛУ ПІДПРИЄМСТВА
Графічні матеріали
482.ЧДТУ.241923-90 01
Листів 6
Розробник ________________ Хвостик А. О.
Черкаси 2024
482.ЧДТУ.241923-90 01
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
123
482.ЧДТУ.241923-90 01
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
124
482.ЧДТУ.241923-90 01
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
125
482.ЧДТУ.241923-90 01
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
126
482.ЧДТУ.241923-90 01
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
127
482.ЧДТУ.241923-90 01
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
128