Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9786
Title: Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за кодами помилок
Authors: Півень , Олександр Борисович
Макаріхін, Олег Олегович
Keywords: діагности автомобіля;OBD-II;DTC;WEB-сервіс;REST API;NODE.JS;EXPRESS.JS;POSTGRESQL;BCRYPT;автентифікація;UML;car diagnostics;OBD-II;DTC;WEB-service;REST API;NODE.JS;EXPRESS.JS;POSTGRESQL;BCRYPT;authentication;UML
Issue Date: 17-Jun-2026
Abstract: АНОТАЦІЯ Макаріхін О.О., кваліфікаційна робота бакалавра на тему «Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за кодами помилок». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2026. Мета виконання кваліфікаційної роботи бакалавра: проектування та конструювання програмного забезпечення для інтелектуального аналізу й інтерпретації технічних кодів несправностей автомобілів (стандарт OBD-II) з наданням користувачам адаптивного інтерфейсу та автоматизованого ведення індивідуального журналу пошукових запитів. Завдання при проектуванні програмного забезпечення: провести аналіз існуючих методів та програмних засобів комп'ютерної діагностики авто; визначити переваги та недоліки наявних рішень; сформувати комплекс функціональних та нефункциональних вимог до системи; розробити логічну й архітектурну структуру сервісу та відобразити взаємодію його компонентів за допомогою UML-діаграм; обґрунтувати вибір засобів реалізації; спроектувати реляційну базу даних та розробити пошуковий алгоритм із пріоритезацією за марками авто; впровадити контур автентифікації та захисту даних; провести модульне, інтеграційне та системне тестування розробленого програмного забезпечення. Об’єкт роботи: процес автоматизації комп’ютерної діагностики транспортних засобів та інтерпретації технічних ідентифікаторів поломок. Предмет розробки: методи та засоби створення адаптивного вебсервісу автомобільної діагностики, що включає модулі безпечної автентифікації, валідації вхідних даних, інтелектуального пошуку рішень за кодами DTC та ведення історії запитів. Вирішено наступні поставлені задачі: 1 Проаналізовано існуючі аналоги та програмні засоби ідентифікації технічних проблем автомобілів. 2 Визначено основні недоліки наявних рішень, такі як платна основа, інтерфейсна складність та відсутність мобільної оптимізації. 3 Сформовано вимоги до швидкодії (відгук до 300 мс), безпеки адаптивності інтерфейсу вебсервісу під ОС Android та iOS. 4 Розроблено логічну структуру та поведінкову модель системи за допомогою UML-діаграм послідовності та станів. 5 Реалізовано серверне програмне забезпечення (REST API) на базі платформи Node.js та Express.js із впровадженням алгоритму нормалізації вхідних рядків. 6 Спроектовано та розгорнуто реляційну базу даних у СКБД PostgreSQL з підтримкою ACID-транзакцій для надійного збереження технічних довідників та профілів користувачів. 7 Реалізовано алгоритм інтелектуального пошуку DTC з пріоритезацією брендів, контур безпеки (bcrypt) та підсистему ведення персонального журналу запитів за допомогою сесій. 8 Проведено комплексне багаторівневе тестування стабільності процесів автентифікації та обробки запитів в умовах інфраструктурного розгортання. Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки, таблиці, джерела в списку посилань, додатки.
ANNOTATION Makarihin O.O., Bachelor's thesis on the topic "Development of a web service for online car diagnostics with search by error codes". Field of study 121 “Software Engineering”, ChSTU, Cherkasy, 2026. The purpose of the bachelor’s qualification thesis is the design and development of software for intelligent analysis and interpretation of vehicle diagnostic trouble codes (OBD-II standard), providing users with an adaptive web interface and automated tracking of a personal search history log. The tasks in software design are: to analyze existing methods and software tools for computer-based vehicle diagnostics; to determine the advantages and disadvantages of current solutions; to formulate a comprehensive set of functional and non-functional requirements for the system; to develop the logical and architectural structure of the service and represent its component interactions using UML diagrams; to justify the choice of implementation tools; to design a relational database and develop a search algorithm with prioritization by car brands; to integrate a security and user authentication framework; to conduct unit, integration, and system testing of the developed software. The object of the work is the process of automating computer-based vehicle diagnostics and troubleshooting code interpretation. The following tasks were solved: 1. Existing software solutions and analogues for identifying vehicle technical malfunctions were analyzed. 2. The main disadvantages of existing solutions, such as paid basis, complex interface, and lack of mobile optimization, were identified. 3. Requirements for server performance (response time up to 300 ms), security, and interface adaptability for Android and iOS devices were formulated. 4. The architectural structure and system behavioral models were developed using UML sequence and state diagrams. 5. Server-side software (REST API) based on Node.js and Express.js platforms was implemented, featuring an input string normalization algorithm. 6. A relational database structure was designed and deployed in PostgreSQL DBMS with ACID transaction support for reliable technical reference and user profile storage. 7. An intelligent DTC search algorithm with car brand prioritization, a security framework (bcrypt), and a session-based personal request logging subsystem were implemented. 8. Comprehensive multi-level testing (unit, integration, system) of authentication processes and database request handling was conducted under infrastructure deployment conditions. The scope of the bachelor’s qualification thesis includes 3 sections, figures, tables, sources in the reference list, and appendices.
URI: https://er.chdtu.edu.ua/handle/ChSTU/9786
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:
File Description SizeFormat 
Кваліфікаційна робота бакалавра Макаріхін Олег Олегович.pdf
  Restricted Access
6.86 MBAdobe PDFView/Open Request a copy


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

Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ 
ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем Кафедра програмного 
забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи бакалавра 
на тему: «Розробка веб-сервісу для онлайн-діагностики автомобілів із 
пошуком за кодами помилок» 
 
 
Виконав: студент 4 курсу, групи ПЗ-2204 
спеціальності  
121 «Інженерія програмного 
забезпечення» 
(шифр і назва напряму підготовки) 
 
 
Студент Макаріхін О.О. 
(прізвище та ініціали) 
Керівник Півень О.Б. 
(прізвище та ініціали) 
Рецензент Захарова М.В. 
(прізвище та ініціали) 
 
 
 
 
 
 
 
 
 
Черкаси 2026 
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет  інформаційних технологій і систем 
Кафедра  програмного забезпечення автоматизованих систем  
Освітній рівень бакалавр 
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма  Інженерія програмного забезпечення 
 
 
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
 С. Голуб 
« »  2026 року 
 
 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Макаріхіна Олега Олеговича 
(прізвище, ім’я, по батькові) 
1. Тема проекту (роботи): Розробка веб-сервісу для онлайн-діагностики автомобілів із 
пошуком за кодами помилок 
Керівник проекту (роботи): Півень Олександр Борисович к.ф.-м.н., доцент 
Затверджені наказом Черкаського державного технологічного університету від « 12 »березня 
2026 року №56/03-03 
3. Вхідні дані до проекту (роботи): Серверна платформа Node.js, вебфреймворк Express.js, 
клієнтська бібліотека React, мова програмування JavaScript (стандарт ES6+), система керування 
базами даних PostgreSQL, пакет express-session (керування сесіями), бібліотека bcrypt (хешування 
конфіденційних даних), діагностичний протокол OBD-II, стандартизована класифікація технічних кодів
 несправностей (DTC). 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити): 
Вступ. Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань. Розділ 2. Впровадження 
результатів досліджень у практику проектування програмного забезпечення інформаційних систем. 
Розділ 3. Розробка та тестування програмного забезпечення. Висновки. Список використаних джерел. 
Додатки 
5. Перелік графічного матеріалу : Слайд 1, слайд 2, слайд 3 , слайд 4, слайд 5, слайд 6, слайд 7, 
слайд 8, слайд 9, слайд 10, слайд 11, слайд 12, слайд 13, слайд 14, слайд 15, слайд 16, слайд 17, слайд 
18, слайд 19, слайд 20, слайд 21. 
6. Консультанти розділів роботи 
 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
Дата видачі завдання грудень 2025 
 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів випускної Примітки 
п/п роботи 
1 Постановка задачі 23.01.2026 виконано 
2 Підготовка завдання 30.01.2026 виконано 
3 Погодження завдання 04.02.2026 виконано 
4 Затвердження завдання 09.02.2026 виконано 
 Основна стадія  виконано 
1 Підбір матеріалів 23.02.2026 виконано 
2 Аналіз шляхів вирішення поставленої задачі 05.03.2026 виконано 
3 Розрахунок основних параметрів роботи 20.03.2026 виконано 
4 Вибір кінцевого варіанту проектного рішення 02.04.2026 виконано 
5 Оформлення первісної редакції роботи 16.04.2026 виконано 
 Заключна стадія  виконано 
1 Узгодження прийнятих проектних рішень з 25.04.2026 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 10.05.2026 виконано 
кінцевій редакції 
3 Попередній захист роботи 20.05.2026 виконано 
4 Затвердження роботи 25.05.2026 виконано 
5 Рецензування роботи 28.05.2026 виконано 
6 Захист роботи 05.06.2026 виконано 
 
 
Студент  Макаріхін О.О 
 (підпис) (прізвище та ініціали) 
Керівник проекту (роботи) ____________________  Півень О.Б. 
(підпис) (прізвище та ініціали) 
АНОТАЦІЯ 
Макаріхін О.О., кваліфікаційна робота бакалавра на тему «Розробка веб-
сервісу для онлайн-діагностики автомобілів із пошуком за кодами помилок». 
Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 
2026. 
Мета виконання кваліфікаційної роботи бакалавра: проектування та 
конструювання програмного забезпечення для інтелектуального аналізу й 
інтерпретації технічних кодів несправностей автомобілів (стандарт OBD-II) з 
наданням користувачам адаптивного інтерфейсу та автоматизованого ведення 
індивідуального журналу пошукових запитів. 
Завдання при проектуванні програмного забезпечення: провести аналіз 
існуючих методів та програмних засобів комп'ютерної діагностики авто; 
визначити переваги та недоліки наявних рішень; сформувати комплекс 
функціональних та нефункциональних вимог до системи; розробити логічну й 
архітектурну структуру сервісу та відобразити взаємодію його компонентів за 
допомогою UML-діаграм; обґрунтувати вибір засобів реалізації; спроектувати 
реляційну базу даних та розробити пошуковий алгоритм із пріоритезацією за 
марками авто; впровадити контур автентифікації та захисту даних; провести 
модульне, інтеграційне та системне тестування розробленого програмного 
забезпечення. 
Об’єкт роботи: процес автоматизації комп’ютерної діагностики 
транспортних засобів та інтерпретації технічних ідентифікаторів поломок. 
Предмет розробки: методи та засоби створення адаптивного вебсервісу 
автомобільної діагностики, що включає модулі безпечної автентифікації, 
валідації вхідних даних, інтелектуального пошуку рішень за кодами DTC та 
ведення історії запитів. 
Вирішено наступні поставлені задачі: 
1 Проаналізовано існуючі аналоги та програмні засоби ідентифікації 
технічних проблем автомобілів. 
2 Визначено основні недоліки наявних рішень, такі як платна основа, 
інтерфейсна складність та відсутність мобільної оптимізації. 
3 Сформовано вимоги до швидкодії (відгук до 300 мс), безпекит а 
адаптивності інтерфейсу вебсервісу під ОС Android та iOS. 
4 Розроблено логічну структуру та поведінкову модель системи за 
допомогою UML-діаграм послідовності та станів. 
5 Реалізовано серверне програмне забезпечення (REST API) на базі 
платформи Node.js та Express.js із впровадженням алгоритму нормалізації 
вхідних рядків. 
6 Спроектовано та розгорнуто реляційну базу даних у СКБД PostgreSQL з 
підтримкою ACID-транзакцій для надійного збереження технічних довідників та 
профілів користувачів. 
7 Реалізовано алгоритм інтелектуального пошуку DTC з пріоритезацією 
брендів, контур безпеки (bcrypt) та підсистему ведення персонального журналу 
запитів за допомогою сесій. 
8 Проведено комплексне багаторівневе тестування стабільності процесів 
автентифікації та обробки запитів в умовах інфраструктурного розгортання. 
Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки, таблиці, 
джерела в списку посилань, додатки. 
Ключові слова: діагности автомобіля, OBD-II, DTC, WEB-сервіс, REST 
API, NODE.JS, EXPRESS.JS, POSTGRESQL, BCRYPT, автентифікація, UML. 
ANNOTATION 
Makarihin O.O., Bachelor's thesis on the topic "Development of a web service 
for online car diagnostics with search by error codes". Field of study 121 “Software 
Engineering”, ChSTU, Cherkasy, 2026. 
The purpose of the bachelor’s qualification thesis is the design and 
development of software for intelligent analysis and interpretation of vehicle diagnostic 
trouble codes (OBD-II standard), providing users with an adaptive web interface and 
automated tracking of a personal search history log. 
The tasks in software design are: to analyze existing methods and software 
tools for computer-based vehicle diagnostics; to determine the advantages and 
disadvantages of current solutions; to formulate a comprehensive set of functional and 
non-functional requirements for the system; to develop the logical and architectural 
structure of the service and represent its component interactions using UML diagrams; 
to justify the choice of implementation tools; to design a relational database and 
develop a search algorithm with prioritization by car brands; to integrate a security and 
user authentication framework; to conduct unit, integration, and system testing of the 
developed software. 
The object of the work is the process of automating computer-based vehicle 
diagnostics and troubleshooting code interpretation. 
The following tasks were solved: 
1. Existing software solutions and analogues for identifying vehicle technical 
malfunctions were analyzed. 
2. The main disadvantages of existing solutions, such as paid basis, complex 
interface, and lack of mobile optimization, were identified. 
3. Requirements for server performance (response time up to 300 ms), security, 
and interface adaptability for Android and iOS devices were formulated. 
4. The architectural structure and system behavioral models were developed 
using UML sequence and state diagrams. 
5. Server-side software (REST API) based on Node.js and Express.js platforms 
was implemented, featuring an input string normalization algorithm. 
6. A relational database structure was designed and deployed in PostgreSQL 
DBMS with ACID transaction support for reliable technical reference and user profile 
storage. 
7. An intelligent DTC search algorithm with car brand prioritization, a security 
framework (bcrypt), and a session-based personal request logging subsystem were 
implemented. 
8. Comprehensive multi-level testing (unit, integration, system) of 
authentication processes and database request handling was conducted under 
infrastructure deployment conditions. 
The scope of the bachelor’s qualification thesis includes 3 sections, figures, 
tables, sources in the reference list, and appendices. 
Keywords: car diagnostics, OBD-II, DTC, WEB-service, REST API, NODE.JS, 
EXPRESS.JS, POSTGRESQL, BCRYPT, authentication, UML. 
 
ВСТУП ........................................................................................................................ 7 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ.................................................................................................................... 10 
1 1. Характеристика процесу комп’ютерної діагностики сучасних автомобілів 10 
1.2. Огляд існуючих методів та програмних засобів розв’язання поставлених 
завдань ......................................................................................................................... 11 
1.2.1. Веб-портал OBD-Codes.com ......................................................................... 11 
1.2.2. Платформа Car Scanner ELM OBD2 ............................................................ 12 
1.2.3. Професійні бази даних (на кшталт Autodata або Alldata) .......................... 12 
1.3. Порівняльний аналіз аналогів ............................................................................ 13 
1.4. Обґрунтування вибору технологічного стеку розробки .................................. 13 
1.4.1. Вибір серверної платформи (Node.js) ......................................................... 13 
1.4.2. Вибір клієнтської бібліотеки (React.js) ....................................................... 14 
1.4.3. Вибір системи управління базами даних (PostgreSQL) ............................. 14 
1.5. Формулювання вимог до розроблюваного веб-сервісу ................................... 14 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ................................................................... 16 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ..................................................................................................................... 17 
2.1. Моделювання предметної області ..................................................................... 17 
2.1.1. Предметна область моделювання. Модель предметної області. Словник 
предметної області .................................................................................................. 17 
2.1.2. Елементи моделювання предметної області .............................................. 20 
2.1.3. Робоча область моделювання ...................................................................... 22 
     
     ЧДТУ 262249.011 ПЗ 
Змн. Арк. № докум. Підпис Дата 
Розроб. Макаріхін О.О.   
 Літ. Лист Листів 
Перевір. Півень О.Б   Розробка веб-сервісу для онлайн-    3  
Рецензент    діагностики автомобілів із пошуком за 
Н. Контр.    кодами помилок ФІТІС, кафедра ПЗАС, ПЗ-2204 
Затверд. Голуб С.В.   
2.2. Формування та аналіз вимог .............................................................................. 23 
2.2.1. Формування вимог до програмного забезпеченняю. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги ...................................................................................................................... 23 
2.2.2. Формування вимог за допомогою діаграм прецедентів ............................ 26 
2.3. Проектування структури програмного комплексу ....................................... 30 
2.3.1. Діаграма класів ........................................................................................... 30 
2.3.2. Діаграма пакетів ......................................................................................... 33 
2.4. Архітектурне проектування ............................................................................ 35 
2.4.1. Діаграма компонентів ................................................................................ 35 
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ........................................................................................................... 37 
2.5. Моделювання поведінки системи ................................................................... 39 
2.5.1. Діаграма діяльності .................................................................................... 39 
2.5.2. Діаграма послідовності .............................................................................. 42 
2.5.3. Діаграма комунікацій ................................................................................ 45 
2.5.4. Діаграма скінченного автомату ................................................................ 49 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ .................................................................... 52 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
. .................................................................................................................................... 53 
3.1. Програмно-апаратне забезпечення реалізації ................................................... 53 
3.1.1. Обґрунтування вибору засобів реалізації ................................................... 53 
3.1.2. Опис структурної (функціональної) системи ............................................. 54 
3.1.3. Опис логічної схеми системи ....................................................................... 59 
3.1.4. Розробка структури бази даних ................................................................... 61 
3.1.5. Розробка програмного інтерфейса користувача ......................................... 63 
3.1.6. Опис розробки програмних компонентів ................................................... 67 
     
     ЧДТУ 262249.011ПЗ 
Змн. Арк. № докум. Підпис Дата 
3.2. Тестування системи ............................................................................................ 68 
3.2.1. Модальне тестування .................................................................................... 68 
3.2.2. Інтеграційне тестування ............................................................................... 71 
3.2.3. Системне тестування .................................................................................... 73 
3.2.4. Приймальне тестування ................................................................................ 75 
3.3. Приклади впровадження програмного комплексу ........................................... 77 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ .................................................................. 79 
ВИСНОВОК ................................................................................................................ 80 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................. 82 
ДОДАТОК А . .............................................................................................................86 
ДОДАТОК Б ...............................................................................................................88 
ДОДАТОК В ............................................................................................................. 100 
ДОДАТОК Г ............................................................................................................. 105 
ЧДТУ 262249.011 ПЗ 
Змн. Арк. № докум. Підпис Дата 
 
ЧДТУ 262249.011 ПЗ 
ВСТУП 
Актуальність теми. Дана робота бакалавра розглядається зі спеціальності 
інженерія програмного забезпечення. В даній роботі розглянуто з точки зору 
інженерії програмного забезпечення розглянуто технології та розроблено веб-
додаток з використанням мов програмування JavaScript, Node.js та інші. Сьогодні 
існує гостра потреба у створенні ефективних вебплатформ, які дозволяють 
власникам авто, або майстрам оперативно ідентифікувати несправності за OBD-II 
кодами, зберігати історію перевірок та отримувати розгорнуті технічні довідки 
про стан окремих вузлів автомобіля. 
Дослідження ринку програмних аналогів виявило суттєві недоліки наявного 
софту: більшість сервісів є комерційними або мають перевантажений інтерфейс, 
не оптимізований для смартфонів. У зв'язку з цим, проектування безкоштовного 
веб-сервісу з адаптивним дизайном, гнучкою системою фільтрації та 
персоналізованим журналом запитів є своєчасним і важливим науково-
практичним завданням для ІТ-сфери та індустрії автотехобслуговування. 
Мета розробки: шляхом розробки програмного забезпечення для онлайн-
інтерпретації кодів помилок бортових систем автомобіля (OBD-II), яка 
відповідатиме потребам користувачів. 
Для досягнення поставленої мети необхідно вирішити такі завдання: 
1 Проаналізувати існуючі методи та програмні засоби діагностики 
автомобілів. 
2 Спроектувати архітектуру веб-сервісу та структуру бази даних для 
зберігання технічної інформації. 
3 Реалізувати серверне програмне забезпечення на базі Node.js та 
клієнтську частину з використанням бібліотеки React. 
4 Інтегрувати систему з базою даних PostgreSQL для ефективного 
пошуку та збереження даних. 
5 Провести тестування функціоналу та надійності розробленого сервісу. 
Завдання розробки: у межах кваліфікаційної роботи вирішується 
 7 
 
ЧДТУ 262249.011 ПЗ 
комплексне завдання з побудови архітектури та безпосереднього створення 
прикладного програмного забезпечення для автодіагностики. Проєкт спрямований 
на побудову інформаційного каталогу автомобільних дефектів, який підтримує 
динамічне відсіювання даних за критеріями конкретної марки авто чи специфіки 
ЕБК. Важливою складовою є розробка пошукового алгоритму, здатного 
обробляти запипи користувачів за кодом помилки або ключовими словами. 
Кінцева програмна реалізація вебсервісу дозволяє надавати автовласникам 
розгорнуті інструкції з ремонту, а також забезпечує збереження результатів 
сканування в індивідуальному профілі користувача. 
Об’єкт розробки: процес створення програмного забезпечення та 
інфраструктури, що забезпечують ефективну та зручну дистанційну діагностику 
транспортних засобів. 
Предмет розробки: побудова програмного забезпечення для створення веб-
сервісу з базою даних автомобільних кодів помилок та алгоритмами їх обробки. 
Методи проектування та конструювання: для досягнення мети 
застосовано такі методи: порівняння та спостереження — під час вивчення 
існуючих підходів до побудови діагностичних сервісів; системний аналіз та 
моделювання — при проектуванні архітектури бази даних та логіки взаємодії 
клієнт-сервер; експеримент і синтез — при безпосередній програмній реалізації 
модулів пошуку, реєстрації та тестуванні їх працездатності. 
Для реалізації проекту було обрано сучасний стек технологій, що забезпечує 
швидку обробку даних та високу інтерактивність інтерфейсу: 
1 JavaScript (JS) — основна мова програмування, яка використовується 
для написання як клієнтської, так і серверної частин додатка. Завдяки екосистемі 
JS забезпечується висока швидкість розробки та можливість використання 
єдиного формату даних (JSON) на всіх рівнях системи. 
2 Node.js — програмна платформа, що перетворює JavaScript на мову 
загального призначення. Ця платформа обралась для розробки серверної частини 
(backend) через свою подієво-орієнтовану архітектуру та неблокуюче 
введення/виведення, що дозволяє ефективно обробляти велику кількість 
 8 
 
ЧДТУ 262249.011 ПЗ 
одночасних запитів від користувачів, які шукають розшифровку кодів помилок; 
3 Express.js — мінімалістичний фреймворк для Node.js, що 
використовується для створення маршрутизації та обробки HTTP-запитів. 
4 PostgreSQL [4] — потужна об'єктно-реляційна система управління 
базами даних. Вибір пав на PostgreSQL завдяки її надійності та здатності 
працювати зі складними структурами даних. У проекті вона використовується для 
зберігання великих довідників кодів помилок (DTC), технічних характеристик 
автомобілів та історії запитів користувачів. 
5 Sequelize — ORM-бібліотека для Node.js, яка спрощує взаємодію з 
PostgreSQL. Вона дозволяє описувати структуру бази даних у вигляді JavaScript-
об’єктів, що автоматизує створення таблиць та виконання складних SQL-запитів. 
6 React — для розробки інтерфейсу користувача. Вона дозволяє створити 
динамічну форму пошуку кодів помилок, яка моментально реагує на введення 
тексту користувачем без перезавантаження сторінки. 
7 Tailwind CSS — утилітарний CSS-фреймворк для швидкої верстки 
адаптивного дизайну. Він забезпечує коректне відображення сервісу на мобільних 
пристроях, що важливо для водіїв, які проводять діагностику безпосередньо біля 
авто. 
8 VS Code [18] — основне середовище розробки, обране за його гнучкість, 
швидкість роботи та величезну кількість плагінів для роботи з Node.js, SQL та 
React. 
Опис отриманих результатів: розроблено комплексне програмне 
забезпечення для онлайн-діагностики автомобілів, яке включає в себе весь 
необхідний функціонал: систему каталогу з фільтрацією по характеристикам, 
пошуку, особистий кабінет користувача з історією запитів. Спроектовано та 
створено базу даних, яка забезпечує швидкий доступ до інформації про технічні 
коди несправностей (DTC), їх причини та можливі методи ремонту. Додаток 
відображатиме коди помилок, реєстрацію користувачів, збереження результатів 
діагностики та надання технічних довідників. Сервер було успішно інтегровано з 
базою даних PostgreSQL, тож це дозволяє серверу ефективно обробляти запити на 
 9 
 
ЧДТУ 262249.011 ПЗ 
читання та запис даних. Також було проведено тестування окремих функцій та 
модулів для забезпечення його надійності та стабільності. 
Практичне значення отриманих результатів: розроблене програмне 
забезпечення для онлайн-сервісу діагностики надає користувачам зручний та 
ефективний спосіб самостійної ідентифікації технічних проблем автомобіля без 
обов’язкового відвідування сервісного центру на початковому етапі. Система 
також автоматизує процес збору та систематизації технічної інформації про 
типові поломки конкретних марок авто. Це зменшує навантаження на технічних 
спеціалістів та економить час автовласників. Завдяки інтеграції з базою даних, 
система може збирати корисні дані про найбільш розповсюджені несправності 
серед користувачів та тримати в собі інформацію про кожен профіль користувача. 
 10 
ЧДТУ 262249.011 ПЗ 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1. Характеристика процесу комп’ютерної діагностики сучасних 
автомобілів 
Сучасний транспортний засіб є складною технічною системою, 
функціонування якої забезпечується великою кількістю електронних блоків 
керування (ECU - Electronic Control Units). Еволюція автомобільної 
промисловості призвела до того, що програмне забезпечення стало невід’ємною 
часткою механічних вузлів автомобілів, контролюючи параметри роботи 
двигуна, гальмівної системи, безпеки пасажирів і водія та комфорту. 
Основним стандартом, що забезпечує взаємодію з електронними 
системами автомобіля, є протокол OBD-II (On-Board Diagnostics). Протокол був 
запроваджений у середині 90-х років для уніфікації методів спостерігання за 
екологічними показниками, але згодом трансформувався у повноцінну систему 
самодіагностики. Система працює типом постійного опитування датчиків; у разі 
виходу показників за межі норми, система записує у пам’ять ЕБК 
(ЕЛЕКТРОННИЙ БЛОК КЕРУВАННЯ) спеціальний п’ятизначний код 
несправності -DTC (Diagnostic Trouble Code) (рис 1.1). 
Структура коду DTC є строго регламентованою: 
1 Перша літера позначає систему (P -двигун та трансмісія, B -кузов, C - 
шасі, U -мережеві помилки). 
2 Другий символ вказує, чи є код загальним (0) або специфічним для 
виробника (1). 
3 Третій символ деталізує вузол (наприклад, 1 -паливна система, 3 - 
система запалювання). 
4 Останні два символи вказують на конкретний тип поломки. 
11 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 1.1 - Схема структури коду DTC 
 
Актуальність розробки веб-сервісу для інтерпретації цих кодів зумовлена 
тим, що звичайний водій, побачивши індикатор «Check Engine» на приладовій 
панелі, часто не має доступу до детальної інформації про серйозність проблеми. 
Існуючі паперові довідники є неактуальними, а професійне обладнання - занадто 
дорогим. Веб-сервіс, доступний через браузер смартфона, вирішує проблему 
оперативного інформування власника про технічний стан авто. 
1.2. Огляд існуючих методів та програмних засобів розв’язання 
поставлених завдань 
Для визначення функціональних вимог до проектованої системи було 
проведено аналіз найбільш популярних рішень у сфері автомобільної 
діагностики. 
1.2.1. Веб-портал OBD-Codes.com 
Переваги: даний ресурс є одним із найстаріших англомовних довідників. 
Його основна перевага -величезна база даних, що наповнювалася десятиліттями. 
Недоліки: застарілий інтерфейс користувача, відсутність адаптивної версії 
для зручного читання з мобільних пристроїв, відсутність персоналізації 
(неможливо зберегти дані про своє авто). 
12 
ЧДТУ 262249.011 ПЗ 
  
Рисунок 1.2 -Головна сторінка сайту OBD-codes.com 
 
1.2.2. Платформа Car Scanner ELM OBD2 
Переваги: мобільний додаток, що працює через адаптери ELM327. Він 
надає потужний функціонал для зчитування даних у реальному часі. 
Недоліки: сервіс орієнтований на роботу в парі з «залізом». Якщо 
користувач просто хоче знайти інформацію про код, який йому назвали на СТО, 
додаток не є оптимальним інструментом. Крім того, більшість розширених 
описів доступні лише у платній версії. 
13 
ЧДТУ 262249.011 ПЗ 
1.2.3. Професійні бази даних (на кшталт Autodata або Alldata) 
Переваги: це платні системи, якими користуються сертифіковані 
автосервіси. Вони містять покрокові інструкції з ремонту та електросхеми. 
Недоліки: надзвичайно висока ціна підписки та складність інтерфейсу, 
що робить їх непридатними для звичайних автовласників. 
1.3. Порівняльний аналіз аналогів 
На основі проведеного огляду було складено порівняльну таблицю 
(таблиця 1.1). 
Порівняння функціональних можливостей діагностичних сервісів 
 
Таблиця 1.1 
Таблиця порівняння 
Критерій порівняння OBD- Car Професійні Проектований 
Codes Scanner БД сервіс 
Доступність через Так Ні Так Так 
браузер 
Безкоштовний доступ Так Частково Ні Так 
Особистий кабінет Ні Так Так Так 
Історія діагностики Ні Так Так Так 
Адаптивність Ні Так (app) Ні Так 
(Tailwind UI) 
 
Аналіз показав, що на ринку існує ніша для легкого, безкоштовного веб-
сервісу, який поєднує глибину інформації професійних баз із простотою 
використання споживчих додатків. 
1.4. Обґрунтування вибору технологічного стеку розробки 
Вибір інструментів реалізації проекту ґрунтується на необхідності 
забезпечення високої швидкості роботи системи при роботі з великими обсягами 
14 
ЧДТУ 262249.011 ПЗ 
технічних текстів. 
1.4.1. Вибір серверної платформи (Node.js) 
Для розробки Backend-частини було обрано середовище виконання Node.js. 
Переваги: подійна модель (Event Loop) дозволяє обробляти велику кількість 
одночасних запитів без блокування потоків, використання JavaScript як на 
клієнті, так і на сервері спрощує архітектуру проекту. Величезна екосистема 
пакетів (NPM), зокрема для роботи з базами даних та автентифікацією. 
1.4.2. Вибір клієнтської бібліотеки (React.js) 
Для створення інтерфейсу було обрано бібліотеку React від компанії 
Meta. 
Переваги: компонентний підхід дозволяє створювати інтерфейс, що 
легко масштабується. Virtual DOM мінімізує кількість операцій з оновлення 
сторінки, що критично для мобільних пристроїв зі слабким сигналом інтернету. 
Використання Tailwind CSS дозволяє реалізувати сучасний «mobile-first» дизайн, 
що автоматично підлаштовується під будь-який екран. 
1.4.3. Вибір системи управління базами даних (PostgreSQL) 
Оскільки дані про коди помилок мають чітку структуру (код, опис, 
причина, рішення), було обрано реляційну СУБД PostgreSQL. 
Переваги: надійність та відповідність принципам ACID. Потужні 
можливості повнотекстового пошуку, що дозволить користувачу знаходити 
помилку не лише за кодом, а й за ключовими словами в описі. Підтримка 
складних зв’язків між таблицями «Марка авто» - «Модель» - «Електронний 
блок». 
1.5. Формулювання вимог до розроблюваного веб-сервісу 
На основі аналізу предметної області визначено такі вимоги. 
Функціональні вимоги: користувач відправляє запит на пошук коду 
помилки або симптому через веб-інтерфейс. Веб-інтерфейс передає запит на 
сервер додатків. Сервер додатків виконує пошук у базі даних. База даних 
15 
ЧДТУ 262249.011 ПЗ 
повертає результати пошуку на сервер додатків. Сервер формує дані для 
відображення і відправляє їх веб-інтерфейсу. Користувач переглядає деталі 
помилки та рекомендовані рішення. При бажанні користувач може переглянути 
історію пошуку, що обробляється сервером і зберігається у базі даних. 
 
 
Рисунок 1.3 -Взаємодія користувача та сервера 
 
Діаграма послідовності зображає взаємодію між учасниками системи під 
час сценарію Учасники: користувач - авторизований або гість, потім Веб-
інтерфейс(UI) - відображає дані користувачу. Сервер додатків (AppServer) -
обробляє бізнес-логіку, включно з пошуком і керуванням вибраним, а база даних 
- зберігає користувачів, коди помилок, симптоми, рішення. 
16 
ЧДТУ 262249.011 ПЗ 
Нефункціональні вимоги: час відгуку сервера на пошуковий запит не 
повинен перевищувати 300 мс. Повна адаптивність інтерфейсу для роботи на 
смартфонах. Безпека збереження паролів користувачів через хешування. 
17 
ЧДТУ 262249.011 ПЗ 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі було проведено детальний аналіз галузі автомобільної 
діагностики. Виявлено, що стандарт OBD-II є основою для сучасної комунікації з 
авто. Аналіз аналогів підтвердив відсутність зручних безкоштовних веб-рішень з 
українською локалізацією та системою збереження історії. Обґрунтовано 
використання сучасного стеку (Node.js, React, PostgreSQL), що забезпечить 
продуктивність та гнучкість системи. Сформовані вимоги стануть основою для 
подальшого проектування архітектури веб-сервісу. 
 
18 
ЧДТУ 262249.011 ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
2.1. Моделювання предметної області 
Для визначення предметної області було зосереджено на ключових 
аспектах, які забезпечують швидкий та точний пошук інформації. А саме: 
введення ідентифікатора несправності користувачем, перевірка синтаксису 
вписаного коду, звернення до бази даних, де заздалегідь збережені помилки, їх 
описи та інформація про те як усунути несправність, отримання відповідного 
запису та зображуємо структурованої інформації користувачу. 
Наступним етапом у моделюванні буде визначення взаємодій між 
компонентами. Першим компонентом є Інтерфейс вводу. Важливим аспектом є 
попереднє вилучення даних: система прибирає зайві відступи та перетворює 
символи у верхній регістр, щоб не виникало розбіжностей з даними в базі даних. 
Запит обробляється у тимчасовій пам'яті (Buffer), а потім передається до 
Контролера запитів (Query Controller). 
Після очищення коду відбувається процес зіставлення (Matching). Система 
виконує запит до таблиці помилок (ErrorCode Table), де в кожному коду вже 
присвоєно чіткий опис та ідея ремонту (Solution). Якщо код, який вписали існує в 
базі даних, система отримує повні дані. Додатково використовується фільтрація 
марок автомобільних, щоб серед варіантів, які знайшли обрали той, що підходить 
специфікаціям виробника. 
Останнім кроком є робота компонента відображення (View Component). На 
основі отриманих із бази даних значень (0 або 1, де 1 -успішне знаходження коду, 
0 -відсутність інформації в базі), система формує сторінку, або інформує 
користувача про потребу конкретизації запиту. Це забезпечує просту та надійну 
роботу сервісу як довідкової системи. 
2.1.1. Предметна область моделювання. Модель предметної області. 
19 
ЧДТУ 262249.011 ПЗ 
Словник предметної області. 
Предметна область моделювання. Для визначення предметної області 
було сконцентровано увагу на основних моментах, які забезпечують швидкий і 
точний пошук інформації про технічний стан автомобіля. Введення DTC-коду за 
допомогою строки пошуку, перевірка синтаксису коду, який було введено, 
звернення до бази даних, де вже записані та збережені описи та рішення 
помилок, отримання відповідного запису та система сповіщення користувача про 
результати аналізу. 
Наступним кроком в моделюванні є визначення взаємодії між 
компонентами системи. Першим компонентом у моделюванні є процес обробки 
запиту. Важлива складова в процесі введення є мінімізація помилок, що 
досягається за допомогою логічного регулятора (валідатора), який 
використовується для контролю рівня коректності вводу: видалення зайвих 
пробілів, автоматичне перетворення символів у верхній регістр та перевірка на 
відповідність стандарту OBD-II (наприклад, P0101). Запис та первинна обробка 
запиту відбуваються у тимчасовій пам’яті, з цілю оптимізації використання 
ресурсів сервера та уникнення зайвих звернень до бази даних при некоректних 
запитах. Потім дані з буфера йдуть на контролер для порівняння з базою. 
Після отримання обробленого коду відбувається процес поділу даних для 
пошуку. Прямий запит до таблиці помилок виконує система, де кожному 
унікальному коду присвоєно чіткий опис поломок та детальний опис їх усунення. 
Якщо введений код знайдено в базі даних, система витягує всі дані, які пов’язані 
з цим кодом помилок. Також, на цьому етапі спрацьовує фільтрація за маркою 
авто. Це дозволяє надати користувачу рекомендації, які відповідають технічним 
нормам і допускам саме обраного транспортного засобу. 
Останнім етапом відбувається класифікація знайденої помилки за ступенем 
її впливу на безпеку руху автомобіля. В якості вхідних даних використовуються 
атрибути знайденого запису та категорія системи транспортного засобу (двигун, 
гальма, електроніка). На виході система формує індикатор (значення від 0 до 
3), де значення, наближене до 3, класифікує несправність як критичну, що 
20 
ЧДТУ 262249.011 ПЗ 
вимагає негайної зупинки автомобіля, а значення, ближче до 0 -як повідомлення з 
інформацією, про некритичну несправність, яка не потребує термінового 
втручання. 
Модель предметної області. Модель предметної області представляє 
структуру веб-сервісу для ідентифікації та інтерпретації кодів помилок 
автомобіля. Інтерфейс користувача (User Interface) є первинним входом для 
взаємодії з користувачем, який дозволяє доступ до налаштувань профілю та 
параметрів діагностичної сесії. Налаштування параметрів необхідне для надання 
інфомрації про марки авто, що дозволяє компоненту вводу даних (Diagnostic Data 
Input) точно формувати запит до бази даних. 
Після отримання введеного коду, дані передаються до аналізатора (Request 
Analyzer), який відповідає за початковий аналіз коду та його підготовку до 
подальшого порівняння. Аналізатор включає етапи попередньої обробки, такі як 
очищення рядка від зайвих пробілів, нормалізація регістру символів та 
синтаксична перевірка на відповідність формату DTC. 
Після первинної валідації дані передаються до модуля пошуку в базі даних 
(Database Search Engine), який відповідає за безпосередню роботу з таблицями 
несправностей. Цей компонент використовує алгоритми фільтрації для вибору 
відповідних записів із завчасно заповненої бази даних на основі ідентифікованого 
коду помилки. Модуль забезпечує зв’язок між технічним кодом та текстовим 
описом і інструкцією з ремонту. 
Завершальним етапом є менеджер відображення результатів (Response 
Manager), який інформує користувача про підсумки пошуку. Це включає 
формування сторінки з описом помилки, виведення порад щодо усунення 
поломок та помилок або надсилання повідомлення про відсутність конкретного 
коду в базі знань. 
Таким чином, додаток інтегрується зі стандартами автомобільної 
самодіагностики, використовує спеціалізовані компоненти для обробки текстових 
запитів та взаємодіє з користувачем через систему динамічних технічних 
звітів, що забезпечує зручний інтерфейс для отримання інформації про стан 
21 
ЧДТУ 262249.011 ПЗ 
автомобіля. 
Словник предметної області. Словник предметної області включає в 
себе наступні базові класи, що формують модель системи (таблиця 2.1): 
 
Таблиця 2.1 
Словник предметної області 
№ Назва(укр.) Назва(англ.) Опис 
1 Користувач USER суб’єкт, який ініціює взаємодію із сервісом, 
надає вхідні дані для діагностики та отримує 
результати аналізу 
2 Автомобіль CAR об’єкт реального світу, технічний стан якого 
підлягає аналізу. Характеризується унікальним 
VIN-кодом та технічними специфікаціями 
3 Код помилки ErrorCode Стандартизований цифро-буквений 
ідентифікатор несправності, що відповідає 
протоколам самодіагностики автомобіля 
4 Рішення Solution Концептуальний опис методу усунення 
несправності, що включає базу даних із 
покроковими алгоритмами дій 
 
2.1.2. Елементи моделювання предметної області 
Одним із етапів моделювання предметної області є визначення графічних 
символів, що будуть використовуватись при побудові UML-діаграм для опису 
структури та логіки веб-сервісу (таблиця 2.2). Обрані елементи дозволяють 
зобразити як статичну архітектуру бази даних, так і динаміку взаємодії 
користувача з пошуковими алгоритмами. 
 
Таблиця 2.2 
Графічні символи UML-діаграм, що плануються до використання 
22 
ЧДТУ 262249.011 ПЗ 
Графічний символ Назва Елемента 
Дійова особа (Actor) 
 
Варіант використання (Use 
Case) 
 
Коментар (Note) 
 
Клас (Class) 
 
Пакет (Package) 
 
Компонент (Component) 
 
Головна програма (Main system) 
 
Ресурс (Resource) 
 
 
Наступним кроком опишемо єднальні елементи UML, що плануються до 
використання для відображення потоків даних та логічних залежностей (таблиця 
2.3). 
 
Таблиця 2.3 
Єднальні елменти UML 
23 
ЧДТУ 262249.011 ПЗ 
Графічний символ Назва елемента 
Односпрямована асоціація 
(Unidirectional association) 
 
Анотація до пункту (Anchor note to 
item) 
 
Посилання на об’єкт (Object link) 
 
Посилання на себе (Link to Self) 
 
Зворотне повідомлення (Return 
message) та пряме повідомлення (Link 
message) 
 
 
2.1.3. Робоча область моделювання 
В якості робочої області моделювання розглядається клієнт-серверне веб-
середовище для пошуку та інтерпретації кодів помилок автомобіля (DTC). 
Користувач відкриває веб-інтерфейс сервісу через браузер, де йому дається 
можливість введення ідентифікатора несправності. 
Система автоматично ініціює процес обробки запиту: спочатку виконується 
24 
ЧДТУ 262249.011 ПЗ 
перевірка введених даних на відповідність синтаксису (наявність префікса та 
числової послідовності). За необхідності система пропонує користувачу уточнити 
параметри автомобіля (марку) для забезпечення відповідності результатів. Після 
отримання валідного коду, веб-сервіс перетворює текстовий запит у SQL-запит 
до реляційної бази даних, аналізує наявність збігів у таблицях «ErrorCode» та 
«Solution», та надає готову розшифровку технічного стану. 
Результат пошуку відображається користувачу у вигляді структурованого 
звіту, що містить опис поломки, ступінь його критичності (від 0 до 3) та 
інформацію щодо вирішення проблеми. Додатково користувач може переглядати 
історію попердніх пошукових запитів. Робоча область проектування охоплює 
повний цикл від ініціації запиту клієнтом до отримання кінцевого технічного 
рішення з бази знань. 
2.2. Формування та аналіз вимог 
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги. 
Первинні і детальні вимоги 
Для початку сформуємо первинні вимоги, що дасть можливість більш 
точно описати інші типи специфікацій. Веб-сервіс призначений для роботи через 
сучасні браузери та пропонує функціонал, заснований на взаємодії користувача з 
базою даних діагностичних кодів помилок. Після завантаження головної сторінки 
сервіс надає поле для введення коду. Отримавши вхідні дані, додаток забезпечує 
можливість запуску процесу пошуку. Після завершення обробки запиту сервіс 
автоматично класифікує знайдену несправність за рівнем критичності (критична 
або інформаційна). Додатково користувач має можливість отримати детальну 
інструкцію щодо усунення помилки. Сервіс також надає можливість збереження 
історії запитів. 
Вимоги замовника і розробника 
Наступним кроком опишемо вимоги замовника. Веб-сервіс має виступати 
25 
ЧДТУ 262249.011 ПЗ 
єдиним точковим джерелом істини для інтерпретації стандартних діагностичних 
кодів несправностей (DTC). Замовник наполягає на тому, щоб база даних містила 
не лише назву помилки, а й зрозуміле пояснення для водія, який не має 
професійної технічної освіти. Це включає опис симптомів, можливих причин 
виникнення та потенційних наслідків ігнорування проблеми. Однією з ключових 
вимог є відсутність необхідності завантаження важких додатків. Сервіс має 
працювати миттєво через веб-браузер на будь-якому пристрої (смартфон, 
планшет, ноутбук). Користувач, перебуваючи в дорозі або в гаражі, повинен мати 
змогу ввести код і отримати результат за мінімальну кількість натискань на 
пристрої. Також замовник вимагає відсутності перевантаження інтерфейсу 
зайвими елементами. Головна сторінка повинна зосереджувати увагу користувача 
виключно на полі вводу коду. Результат пошуку має бути структурованим: 
окремо назва помилки, рівень небезпеки та покрокова інструкція. Колірна 
індикація (зелений, жовтий, червоний) повинна візуально підказувати 
користувачеві ступінь критичності ситуації. Система має бути «розумною» та 
запобігати помилкам користувача. Якщо водій випадково вводить некоректний 
набір символів (наприклад, замість латинської «P» кириличну «Р» або 
помиляється у кількості цифр), сервіс має автоматично корегувати ввід або 
видавати підказку про правильність формату OBD-II. Це критично для 
зменшення кількості невдалих запитів до бази даних. Замовник вказує на 
необхідність врахування специфіки різних автовиробників. Оскільки один і той 
самий код може мати різні розшифровки для автомобілів марок BMW, Toyota або 
Ford, система повинна мати механізм вибору марки авто. Це дозволить видавати 
найбільш правильне технічне рішення, що значно підвищує цінність сервісу для 
користувача. Вимогою розробника, погодженою із замовником, є використання 
реляційної структури бази даних, яка дозволяє легко додавати нові коди помилок 
та оновлювати існуючі інструкції без зміни програмного коду самого сервісу. 
Система повинна стабільно працювати при одночасному зверненні великої 
кількості користувачів. Оскільки сервіс є інформаційним, замовник вимагає 
мінімального збору персональних даних. Пошук кодів повинен бути анонімним. 
26 
ЧДТУ 262249.011 ПЗ 
Дані про транспортний засіб, які вводить користувач (марка), мають 
використовуватися лише в межах поточної сесії для фільтрації результатів і не 
повинні зберігатися у відкритому доступі. Таким чином, вимоги замовника 
фокусуються на створенні інформаційного мосту між електронним блоком 
управління автомобіля (через код помилки) та власником авто, механіком або 
простим користувачем забезпечуючи швидку, зрозумілу та безкоштовну 
первинну діагностику. 
Функціональні та нефункціональні вимоги 
Для декомпозиції загальних специфікацій та чіткого структурування логіки 
майбутнього сервісу розіб'ємо вимоги на дві обов'язкові категорії: функціональні 
(що саме повинна робити система) та нефункціональні (як саме вона має це 
виконувати з технічної точки зору). 
Функціональні вимоги до веб-сервісу 
Модуль автентифікації та профілів: система повинна забезпечувати 
можливість реєстрації нових користувачів, безпечний вхід (авторизацію) та вихід 
із системи з руйнуванням поточної сесії. 
Модуль інтелектуального пошуку: сервіс має приймати введені 
користувачем символи, проводити автоматичну нормалізацію рядка (видалення 
пробілів, переведення у верхній регістр) та здійснювати запит до бази даних. 
Модуль пріоритезації брендів: при виконанні пошукового SQL-запиту 
логіка бази даних повинна спочатку виводити специфічне (заводське) 
трактування коду DTC для обраної марки авто, а за його відсутності — повертати 
стандартне загальне («Generic») рішення. 
Модуль класифікації станів: система зобов'язана аналізувати знайдену 
помилку та присвоювати їй числовий індекс критичності від 0 до 3, що відповідає 
низькому, помірному або критичному рівням небезпеки. 
Модуль автоматичного збереження історії: для авторизованих 
користувачів сервіс повинен у фоновому режимі записати кожен діагностичний 
запит до бази даних та миттєво оновлювати Sidebar без перезавантаження 
сторінки. 
27 
ЧДТУ 262249.011 ПЗ 
Нефункціональні вимоги до веб-сервісу 
Продуктивність та швидкість відгуку: час обробки діагностичного 
запиту на сервері Node.js та виконання SQL-вибірки в PostgreSQL не повинен 
перевищувати 300 мс (фактичний показник при тестуванні склав менше 150 мс). 
Надійність та цілісність даних: архітектура бази даних має суворо 
відповідати принципам ACID; використання зовнішніх ключів (Foreign Keys) 
повинно унеможливлювати появу некоректних даних у журналі пошуків. 
Безпека: конфіденційні дані (паролі користувачів) категорично заборонено 
зберігати у відкритому вигляді. Обов'язковим є використання криптографічного 
алгоритму незворотного хешування bcrypt. 
Адаптивність та сумісність: користувацький інтерфейс має бути повністю 
адаптивним (Mobile-First) завдяки фреймворку Tailwind CSS для стабільної та 
коректної роботи у сучасних веб-браузерах на смартфонах під керуванням iOS та 
Android. 
Масштабованість: архітектура системи повинна дозволяти розширювати 
базу технічних довідників (додавати нові коди та марки автомобілів) шляхом 
простого внесення записів до таблиць БД без необхідності рефакторингу або 
зміни серверного коду. 
2.2.2. Формування вимог за допомогою діаграм прецедентів 
Один із підходів формування діаграм прецедентів є розкладання діаграм за 
функціональним призначенням. Розділимо функціонал веб-сервісу на декілька 
ключових груп, для кожної з яких створимо діаграму прецедентів (Use Case 
Diagram). Для проектування діаграм використаємо програмний інструментарій 
(наприклад, Visual Paradigm або StarUML), який дає можливість спроектувати 
необхідні діаграми, групувати їх за допомогою пакетів та забезпечити наочність 
архітектурних рішень. Виділимо три окремих, але пов’язаних між собою 
функціональні блоки, а саме: авторизація та налаштування профілю, процес 
пошуку коду несправності та генерація звіту. Сформуємо діаграми та опис до них 
поетапно. 
Першим кроком сформуємо діаграму прецедентів процесу пошуку та 
28 
ЧДТУ 262249.011 ПЗ 
ідентифікації коду помилки, що зображена на рисунку 2.1, та додаємо пояснення 
до кожного з елементів діаграми, охоплюючи акторів та їх взаємодію із 
сценаріями використання. 
 
 
Рисунок 2.1 – Діаграма прецедентів процесу пошуку та ідентифікації 
 
Користувач (User) взаємодіє з наступними прецедентами: 
1 Введення коду помилки - ініціює процес взаємодії із системою 
шляхом введення текстового ідентифікатора несправності. 
2 Вибір марки автомобіля - надає системі додатковий контекст для 
фільтрації специфічних (заводських) кодів помилок. 
3 Запуск пошуку - активує процес звернення до бази даних через 
натискання відповідного елемента інтерфейсу. 
4 Перегляд результатів - отримує від системи розшифровку коду та 
рівень його критичності. 
5 Перехід до деталей – ініціює відкриття динамічної сторінки з 
покроковою інструкцією щодо усунення несправності. 
6 Збереження звіту - опціональна дія для авторизованих користувачів 
щодо додавання результату до історії діагностики. 
7 Серверна частина / База даних (System/DB) бере участь у: 
8 Валідація вводу - автоматично перевіряє відповідність введеного коду 
стандарту OBD-II перед відправкою запиту. 
9 Пошук у базі даних - здійснює зіставлення введеного ідентифікатора із 
записами в реляційній базі даних. 
10 Класифікація критичності - на основі знайдених даних присвоює 
29 
ЧДТУ 262249.011 ПЗ 
помилці індекс небезпеки для візуалізації в інтерфейсі. 
Наступним кроком створюємо діаграму прецедентів процесу обробки 
технічних даних та пошуку рішень у базі даних (рисунок 2.2) та наведемо 
пояснення кожного з елементів діаграми. Цей етап моделювання описує 
внутрішню логіку системи після того, як користувач ініціював запит. 
 
 
Рисунок 2.2 – Діаграма прецедентів обробки запиту та взаємодії з БД 
 
Підсистема візуалізації (UI Visualization System) пов'язана з прецедентами 
Відображення статусу пошуку (Show Search Status) та Анімація процесу обробки 
(Animate Processing State). Ця підсистема відповідає за інформування користувача 
про поточний стан виконання запиту: від моменту звернення до сервера до 
отримання фінальної класифікації помилки. Обробник запитів (Query Processor) 
відповідає за автоматичну перевірку наявності коду у базі даних та керує 
прецедентом Скасування або Початок пошуку (Cancel / Start Search). Даний 
компонент контролює життєвий цикл запиту, забезпечуючи чітке з'єднання з 
30 
ЧДТУ 262249.011 ПЗ 
реляційними таблицями та передачу отриманих технічних інструкцій до 
інтерфейсу користувача. База даних безпосередньо взаємодіє з прецедентом 
Вибірка технічного рішення, забезпечуючи систему необхідними даними щодо 
алгоритмів ремонту та опису помилок відповідно до обраної марки автомобіля. 
Наступним кроком сформуємо діаграму прецедентів ідентифікації та 
класифікації технічних станів (рисунок 2.3) та надаємо пояснення кожного 
елементу діаграми. На даному етапі здійснюється аналіз отриманих з бази даних 
технічних характеристик та їх інтерпретація для кінцевого користувача. 
 
 
Рисунок 2.3 – Діаграма прецедентів ідентифікації та класифікації 
 
Модуль класифікації (Classification Engine) та Аналізатор технічних даних 
(Technical Data Analyzer) є ключовими у процесі Ідентифікації несправності 
(Identify Fault). Вони аналізують отриманий код помилки та використовують 
логічні моделі для визначення ступеня її критичності (від 0 до 1). Підсистема 
сповіщень (Notification System) взаємодіє з прецедентами Візуалізація результату 
(Visualize Result) та Індикація рівня небезпеки (Indicate Danger Level). Вона 
відповідає за інформування користувача про завершення аналізу та виведення 
відповідного графічного маркування (колірна індикація статусу). 
Зауважимо, що з метою ізоляції діаграм та зручності проектування 
архітектури було використано пакети (Packages) (рисунок 2.4). Це, у свою чергу, 
дозволило повторно використовувати певні елементи діаграми, наприклад, 
актора «Користувач», та гнучко поєднати різні рівні логіки веб-сервісу між 
собою. 
 
31 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.4 - Структура пакетів діаграми прецедентів 
 
В процесі розробки діаграм прецедентів зроблено заключення, що 
використання пакетів, чітке розмежування ролей акторів та деталізація сценаріїв 
використання дозволить значно знизити час на написання модульних та 
інтеграційних тестів. Це, у свою чергу, зменшить час на загальне тестування 
проекту та оптимізує використання бюджету на розробку веб-сервісу. 
2.3. Проектування структури програмного комплексу 
2.3.1. Діаграма класів 
Наступним етапом спроектуємо та опишемо діаграму класів, що дозволить 
зробити зручнішим процес розробки і кодування в наступних етапах. Створемо 
діаграму класів, що зображена на рисунку 2.5, та додаємо пояснення до кожного 
компонента, зв’язку та прикладу використання. 
32 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.5– Діаграма класів (без атрибутів) 
 
 
Рисунок 2.6– Діаграма класів (з атрибутами) 
33 
ЧДТУ 262249.011 ПЗ 
Основні компоненти діаграми класів: 
Web Interface - керує аспектами інтерфейсу користувача, такими як 
відображення форм пошуку, списку брендів авто, індикаторів завантаження та 
виведення фінальних результатів діагностики. 
Input Validator - контролює правильність введення коду DTC, перевіряючи 
його на відповідність стандарту OBD-II (регулярні вирази, перевірка першого 
символу та довжини рядка). 
Search Controller - є центральним вузлом, що координує потік даних між 
інтерфейсом та логікою. Він ініціює запити та обробляє відповіді сервера. 
DTC Processor - приймає валідований код та марку авто , яку обрали, 
здійснює логічне поєднання цих даних для формування точного запиту до бази 
даних. 
Database Manager - відповідає за безпосередню взаємодію з реляційною 
базою даних: встановлення з'єднання, виконання SQL-запитів та повернення 
знайдених технічних описів. 
Classification Engine - інкапсулює логіку аналізу отриманих даних, 
відповідає за розрахунок індексу критичності несправності (від 0 до 1) та 
визначення рівня небезпеки. 
Result Notifier - відповідає за керування системою сповіщень користувача, 
включаючи колірну індикацію рівня небезпеки та виведення повідомлень про 
успіх або відсутність даних у базі. 
Зв’язки між класами та основні дії: 
Web Interface з'єднується з Input Validator для миттєвої перевірки коректності 
введених символів перед відправкою форми. 
Web Interface через Search Controller ініціює процес пошуку в базі даних 
після вибору користувачем марки автомобіля. 
Search Controller передає параметри запиту до DTC Processor, який 
структурує дані для пошуку. 
DTC Processor взаємодіє з Database Manager для отримання технічної 
інформації та одночасно з Classification Engine для проведення аналізу 
34 
ЧДТУ 262249.011 ПЗ 
критичності знайденої помилки. 
Classification Engine передає оброблені результати (індекс та опис) до Result 
Notifier, який формує фінальний вигляд звіту для користувача. 
Web Interface оновлює стан екрана на основі даних, отриманих від Result 
Notifier. 
Приклади використання: 
1 Web Interface виконує валідацію вводу через Input Validator. 
2 Після успішної перевірки Search Controller ініціює звернення до бази. 
3 Database Manager повертає технічний текст, який передається в 
Classification Engine для оцінки ризиків. 
4 Вихідні дані (текст + рівень небезпеки) подаються в Result Notifier для 
візуалізації. 
5 Користувач бачить на екрані розшифровку коду та рекомендації щодо 
ремонту. 
Слід зауважити, що використання діаграми класів дозволяє чітко 
представити взаємодії та залежності між модулями веб-сервісу, спрощуючи 
процес розробки та допомагаючи уникнути логічних помилок на етапі кодування. 
Проте, діаграма класів може зазнати змін після початку реалізації програмного 
коду, особливо в частині інтеграції з конкретними фреймворками. Вважаємо, що 
проектування структури є обов'язковим етапом, який дозволяє мінімізувати час 
на рефакторинг у майбутньому. 
2.3.2. Діаграма пакетів 
Наступним кроком представимо діаграму пакетів на рисунку 2.6, яка 
демонструє високорівневу архітектуру веб-сервісу та групування його 
компонентів за функціональними ознаками. 
Діаграма включає чотири основні пакети, які з’єднані спрямованими 
асоціаціями, що вказують на їхні взаємозв'язки та ієрархію взаємодії: 
Analysis & Classification - це пакет, що містить бізнес-логіку для 
інтерпретації кодів помилок та їх класифікації за ступенем критичності (індекс 
від 0 до 3). Він аналізує отримані дані на основі технічних параметрів 
35 
ЧДТУ 262249.011 ПЗ 
несправності та формує рекомендації щодо ремонту. 
 
 
Рисунок 2.6 – Діаграма пакетів 
 
User Interface - це пакет, що відповідає за компоненти графічного веб-
інтерфейсу (форми вводу, адаптивні таблиці результатів, модальні вікна). Він 
дозволяє користувачеві взаємодіяти з сервісом. Пакет має двосторонню асоціацію 
з пакетом класифікації, оскільки він надсилає запити на аналіз та отримує 
структуровані результати для візуалізації. 
Data Validation - це пакет, що взаємодіє із пакетом користувацького 
інтерфейсу та управляє коректністю вхідних даних. Він перевіряє введені коди на 
відповідність синтаксису стандарту OBD-II, запобігаючи виконанню некоректних 
запитів до серверної частини. 
Data Management - це пакет, що займається безпосередньою взаємодією з 
базою даних. Він виконує пошук відповідних описів та технічних рішень у 
реляційних таблицях, які потім направляються для логічного аналізу в пакет 
класифікації. 
2.4. Архітектурне проектування 
36 
ЧДТУ 262249.011 ПЗ 
2.4.1. Діаграма компонентів 
На етапі архітектурного проектування було сформовано діаграму 
компонентів (рисунок 2.7), яка відображає фізичну структуру веб-сервісу, 
побудованого на платформі Node.js. Кожен компонент представляє окремий 
логічний модуль або набір файлів JavaScript, що взаємодіють між собою для 
забезпечення пошуку та класифікації кодів OBD-II. 
 
 
Рисунок 2.7 – Діаграма компонентів 
 
Основні елементи діаграми компонентів: 
1 Компонент: User Interface (Клієнтська частина) Файл: App.js / index.html; 
Опис: Відповідає за рендеринг інтерфейсу в браузері, обробку 
подій натискання кнопок та динамічне оновлення сторінки без її 
перезавантаження (AJAX/Fetch). 
2 Компонент: InputValidator (Валідатор) Файл: validator.service.js; 
Опис: Містить регулярні вирази для перевірки синтаксису коду 
DTC. Повертає помилку, якщо ввід не відповідає стандарту 
(наприклад, містить кирилицю). 
3 Компонент: API Controller (Контролер запитів) Файл: search.controller.js; 
37 
ЧДТУ 262249.011 ПЗ 
Опис: Приймає вхідні HTTP-запити від фронтенду, витягує 
параметри(код, марка авто) та передає їх далі в бізнес-логіку Node.js. 
4 Компонент: DTC Service (Сервіс обробки) Файл: dtc.service.js; 
Опис: Основний вузол бізнес-логіки. Координує роботу між базою 
даних та модулем аналізу. 
5 Компонент: DB Manager (Менеджер бази даних) Файл: db.config.js; 
Опис: Використовує драйвери (наприклад, mysql2 або pg) для виконання 
асинхронних запитів до бази даних OBD-II. 
6 Компонент: Classification Logic (Логіка класифікації) Файл: classifier.js; 
Опис: Обчислює рівень критичності несправності (0 або 1) на 
основі отриманих технічних описів. 
7 Компонент: Config Manager (Конфігурація) Файл: .env / config.js; 
Опис: Зберігає змінні середовища, такі як порти сервера та 
реквізити доступу до бази даних. 
Залежності та Зв’язки: 
User Interface надсилає дані до InputValidator перед відправкою запиту; 
Валідовані дані передаються до API Controller, який є "точкою входу" на 
бекенді. 
API Controller використовує методи DTC Service, який, у свою чергу, 
звертається до DB Manager для отримання даних. Після отримання відповіді з 
бази, DTC Service передає дані в Classification Logic для фінальної обробки. 
Результат повертається на фронтенд у форматі JSON. 
Діаграма компонентів допоможе оцінити час, який в подальшому буде 
витрачено на кодування програми. Також, діаграма буде корисною в якості 
документації, оскільки відображає зв’язки та залежності між компонентами. 
Дану діаграму можна використовувати для опису модулів, які будуть не 
залежними один від одного, проте зможуть використовувати необхідні методи 
для роботи. 
Але, слід зауважити, що ймовірність змін в діаграмі дуже висока на етапі 
розробки, особливо за умови великої ймовірності зміни початкових умов, або 
38 
ЧДТУ 262249.011 ПЗ 
застосування гнучкого підходу до розробки програми. 
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Визначення конфігурації розгортання дозволяє зобразити фізичне 
розміщення програмних компонентів на апаратному забезпеченні. Для веб-
сервісу обрано модель прямого розгортання, де серверне середовище 
налаштовується безпосередньо під потреби Node.js додатка. На рисунку 2.8 
відображено основні вузли системи та зв’язки між ними. 
Опис елементів діаграми: 
1 Workstation (Developer PC) - робоча станція розробника, на якій 
відбувається написання коду, локальне тестування та підготовка релізу. 
Передача програмних файлів на сервер здійснюється напряму через 
протоколи передачі даних (наприклад, SSH/FTP). 
2 Production Server (Hosting) - фізичний або віртуальний сервер, на 
якому розгорнуто операційну систему (на базі Linux/Windows) та 
середовище виконання Node.js. Це основний обчислювальний вузол, де 
функціонує логіка веб-сервісу. 
3 Node.js Runtime - середовище виконання, у якому запущено додаток . 
Програма працює як активний процес, що прослуховує певний порт для 
обробки вхідних запитів від користувачів через протокол HTTP/HTTPS. 
4 NPM Dependencies - набір зовнішніх бібліотек, що встановлюються 
безпосередньо на сервері. Вони забезпечують роботу серверного 
функціоналу, такого як маршрутизація, робота з файловою системою та 
з’єднання з базою даних. 
5 Database Server - віддалений сервер бази даних, що містить довідники 
кодів OBD-II та діагностичну інформацію. Сервер додатку взаємодіє з 
базою даних через мережеві запити, отримуючи необхідні дані для 
формування відповідей користувачам. 
 
39 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.8 – Діаграма розгортання 
 
Опис з’єднань: 
Зв'язок між робочою станцією розробника та Production-сервером 
реалізується через захищений протокол передачі даних. Це відображає процес 
ручного або напівавтоматичного розгортання, де підготовлений та протестований 
локально код переноситься безпосередньо у робоче середовище. Після 
копіювання файлів на сервері ініціюється процес оновлення залежностей за 
допомогою менеджера пакетів. Це гарантує, що середовище виконання Node.js 
містить усі необхідні бібліотеки для коректної роботи веб-сервісу. Запуск 
програми здійснюється безпосередньо в операційній системі сервера, що 
забезпечує мінімальні накладні витрати на віртуалізацію та високу швидкість 
обробки запитів. 
Виробничий сервер підтримує постійне та стабільне з’єднання з сервером 
бази даних. Це дозволяє сервісу в реальному часі отримувати актуальні дані з 
бази діагностичних кодів OBD-II та обробляти запити користувачів без затримок. 
Слід зауважити, що обраний підхід до розгортання напряму через Node.js 
забезпечує повний контроль над конфігурацією сервера та процесами в середині 
40 
ЧДТУ 262249.011 ПЗ 
самої системи. Така архітектура є оптимальною для проектів, що потребують 
високої продуктивності при роботі з системними ресурсами. Надійність 
функціонування системи в такому випадку залежить від точності налаштування 
серверного середовища та регулярності оновлення бази даних відповідно до 
нових стандартів автомобільної діагностики. 
Процес супроводу та частота оновлень можуть змінюватися в залежності 
від розширення функціоналу програмного продукту, обсягу нових діагностичних 
даних та необхідної інтенсивності випуску релізів. 
2.5. Моделювання поведінки системи 
2.5.1. Діаграма діяльності 
Наступним етапом процесу проектування є формування діаграми 
діяльності. Вона дозволяє зобразити послідовність дій користувача та 
внутрішніх процесів системи від моменту введення даних до отримання 
результату. Сформуємо діаграму (рисунок 2.9) та її опис. 
 
 
Рисунок 2.9 - Діаграма діяльності користувача та процесу діагностики 
41 
ЧДТУ 262249.011 ПЗ 
Опис елементів діаграми діяльності користувача та пошуку коду: 
1 Відображення головного екрану - початкова активність, де користувач 
бачить інтерфейс вибору марки автомобіля та поле пошуку. 
2 Вибір марки та введення коду (Select Brand & Input Code) - користувач 
обирає виробника авто та вводить код несправності DTC. 
3 Валідація вводу (Validate Input) - система перевіряє введений текст на 
відповідність стандарту OBD-II (регулярні вирази). 
4 Рішення (Decision) - логічне розгалуження, засноване на результатах 
валідації. 
При варіанті «Валідно» (ТАК): 
1 Анімація процесу пошуку (Animate Search Process) - показ індикатора 
завантаження (spinner), що сигналізує про звернення до бази даних. 
2 Запит до бази даних (Request to Knowledge Base) - система ініціює 
асинхронний запит до БД для пошуку опису помилки. 
3 Паралельні процеси (Fork): Одночасно із отриманням тексту помилки 
запускається модуль аналізу критичності. 
4 Класифікація несправності (Classify Fault) - система визначає ступінь 
небезпеки (0 або 3) на основі технічних даних. 
5 Злиття (Join) - об'єднання результатів пошуку тексту та результатів 
класифікації в єдиний об'єкт даних. 
Результат операції: 
1 Пошук успішний (Search Successful) - стан, що вказує на успішне 
знаходження інформації в базі даних. 
2 Відображення детального звіту (Display Detailed Report) - перехід на 
сторінку з описом помилки, інструкціями та колірним індикатором 
небезпеки. 
3 Показ повідомлення про відсутність даних (Display "No Data Found") - у 
випадку, якщо код валідний, але відсутній у базі, користувачеві 
пропонується уточнити марку авто або перевірити код. 
При варіанті «Невалідно» (НІ): 
42 
ЧДТУ 262249.011 ПЗ 
1 Показ помилки формату (Display Format Error) - відображення 
повідомлення про те, що код введено некоректно (наприклад, 
пропущені цифри або використана кирилиця). 
2 Очікування повторного вводу (Wait for Correction) - система повертає 
фокус на поле вводу для виправлення помилки користувачем. 
Вважаємо, що діаграма діяльності є особливо важливою в процесі реалізації 
фронтенд-частини та поєднання логіки Node.js сервера, оскільки вона наочно 
демонструє тісний зв'язок між станами інтерфейсу та серверними запитами. 
Також це дозволяє оцінити складність модуля пошуку та розділити задачу 
реалізації на простіші частини (валідація, запит до БД, класифікатор). Додатково 
діаграма спрощує процес тестування, оскільки одразу видно всі можливі сценарії: 
від успішного знаходження коду до обробки помилок вводу. 
2.5.2. Діаграма послідовності 
Наступним кроком спроектуємо та опишемо діаграму послідовності 
(рисунок 2.10), яка деталізує часовий порядок взаємодії об'єктів системи. 
Сфокусуємось на етапі ініціації пошуку коду несправності та отриманні 
результатів від сервера Node.js. 
Опис об'єктів: Користувач (User): актор, який вводить дані та обирає марку 
авто. Веб-інтерфейс (Web Interface): клієнтська частина застосунку (Frontend), що 
обробляє події вводу. API Контролер (API Controller): Серверна частина на 
Node.js, що приймає HTTP-запити. База даних (Database): реляційне сховище, де 
зберігається інформація про коди OBD-II. 
Послідовність взаємодії: 
1 Користувач надсилає повідомлення (selectBrand/inputCode) до веб-
інтерфейсу. 
2 Веб-інтерфейс виконує внутрішню перевірку та надсилає повідомлення 
(sendSearchRequest) до API Контролера; 
3 API Контролер надсилає запит (executeQuery) до Бази даних для пошуку 
відповідної розшифровки. 
4 База даних повертає об'єкт із технічними даними (returnData) назад до 
43 
ЧДТУ 262249.011 ПЗ 
контролера. 
5 Якщо дані знайдено: API Контролер надсилає повідомлення 
(sendJSONResponse) до інтерфейсу, яке містить опис помилки та рівень 
її критичності. 
6 Веб-інтерфейс викликає метод (renderResultPage) для відображення 
детальної інструкції користувачу; 
7 Якщо дані відсутні: API Контролер надсилає повідомлення 
(sendError404) до інтерфейсу. 
 
 
Рисунок 2.10 - Діаграма послідовності процесу пошуку та ідентифікації коду 
 
Веб-інтерфейс активує сценарій (displayNotFoundMessage), інформуючи 
користувача про необхідність перевірки введених даних або вибору іншої марки 
авто. 
Наступним кроком спроектуємо та опишемо діаграму послідовності 
обробки запиту, аналізу коду та ідентифікації рівня небезпеки (рисунок 2.11). Ця 
44 
ЧДТУ 262249.011 ПЗ 
діаграма відображає динаміку взаємодії внутрішніх сервісів системи після 
отримання вхідних даних від користувача. 
Опис об'єктів 
Веб-інтерфейс (Web Interface): забезпечує навігацію та інформаційний 
обмін з користувачем, відображаючи стан обробки запиту. API Контролер (API 
Controller): компонент Node.js, що відповідає за отримання даних та координацію 
роботи внутрішніх сервісів. Сервіс аналізу (DTC Analyzer): клас, що виконує 
обробку отриманих даних, взаємодіє з БД та готує інформацію для модуля 
класифікації. Модуль класифікації (Classification Engine): логічний блок, що 
аналізує технічні параметри та визначає критичність несправності. 
 
 
Рисунок 2.11 - Діаграма послідовності обробки, аналізу та класифікації помилок 
 
Послідовність взаємодії: 
1 Користувач підтверджує пошук, що ініціює повідомлення (startSearch) 
45 
ЧДТУ 262249.011 ПЗ 
до API Контролера. 
2 API Контролер запускає процес обробки і відправляє поточний статус 
(requestAccepted) назад до інтерфейсу. 
3 Веб-інтерфейс відображає анімацію процесу завантаження та пошуку. 
4 API Контролер передає параметри (код та марку) до сервісу аналізу 
через повідомлення (analyzeDTC). 
5 Сервіс аналізу звертається до бази даних, структурує отримані дані та 
готує їх для оцінки ризиків. 
6 Отримані структуровані дані відправляються в модуль класифікації 
через повідомлення (runClassification). 
7 Модуль класифікує несправність за рівнем небезпеки 
(критична/поточна) і відправляє результат (identificationResult) назад до 
сервісу аналізу. 
8 Сервіс аналізу передає фінальні результати та інструкції до веб-
інтерфейсу через повідомлення (displayResult). 
Веб-інтерфейс відображає користувачу результати ідентифікації, надаючи 
візуальну відповідь (колірний індикатор) та вказівки щодо подальших дій з 
ремонту. 
Діаграма послідовності дозволяє зрозуміти життєвий цикл кожного з 
об’єктів та є особливо корисною на етапі створення класів та оптимізації роботи 
з пам’яттю в середовищі Node.js. Це досягається шляхом створення об’єктів 
тільки в момент необхідності їх використання (lazy loading), що критично для 
високонавантажених веб-сервісів. 
Також діаграми послідовності дозволяють розділити функціонал на менші, 
ізольовані за обов’язками модулі. Це спрощує реалізацію в коді, дозволяє 
відокремити класи в окремі npm-модулі та знизити кількість помилок при 
кодуванні. У свою чергу, діаграми будуть одночасно пов’язаними, але 
архітектурно незалежними, що значно спрощує процес написання 
автоматизованих юніт-тестів для окремих функцій та інтеграційних тестів для 
всього ланцюжка обробки запиту. 
46 
ЧДТУ 262249.011 ПЗ 
2.5.3. Діаграма комунікацій 
Діаграма комунікації, зображена на рисунку 2.12, відображає структурну 
організацію об'єктів та повідомлення, що передаються між ними. На відміну від 
діаграми послідовності, цей тип діаграми акцентує увагу на зв'язках між 
компонентами системи під час обробки запиту. 
Об'єкти: 
1 Webinterface: WebInterface – клієнтський інтерфейс, через який 
користувач вводить код DTC та обирає марку авто. 
2 InputValidator: InputValidator – модуль валідації, що контролює 
коректність введених даних. 
3 SearchController: SearchController – контролер Node.js, що керує логікою 
пошуку та запитами до бази. 
4 DtcService: DTCService – сервіс обробки технічних даних, що проводить 
пошук та форматування інформації. 
5 ClassificationEngine: ClassificationEngine – логічний модуль для 
визначення критичності несправності. 
6 DbConnector: DBConnector -компонент для взаємодії з базою даних 
SQL. 
7 NotificationManager: NotificationManager – модуль сповіщень, що 
виводить результати та помилки користувачу. 
Взаємодія при ініціації пошуку: 
1 WebInterface надсилає повідомлення validateInput до inputValidator. 
2 InputValidator відповідає повідомленням validationStatus назад до 
webInterface. 
Залежно від результату: 
1 Якщо дані коректні, webinterface надсилає повідомлення initiatesearch до 
searchcontroller. 
2 Якщо дані невалідні, webinterface відображає помилку за 
допомогою повідомлення showformaterror до notificationmanager. 
 
47 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.12 – Діаграма комунікацій 
 
Взаємодія під час обробки (Backend): 4. searchController активує процес і 
відсилає статус завантаження updateUIStatus до webInterface. 5. searchController 
відсилає параметри запиту fetchDTCInfo до dtcService. 6. dtcService надсилає 
повідомлення executeQuery до dbConnector для отримання даних з бази. 
Взаємодія під час аналізу та класифікації: 7. dtcService отримує відповідь 
від БД та проводить внутрішню обробку, відсилаючи повідомлення formatData 
собі; 8. Після підготовки даних dtcService відсилає токен даних analyzeSeverity до 
classificationEngine; 9. classificationEngine обробляє технічні параметри та 
визначає індекс небезпеки, відсилаючи результат classificationResult назад до 
48 
ЧДТУ 262249.011 ПЗ 
dtcService. 
Виведення результату: 10. dtcService через контролер відсилає 
повідомлення displayFullReport до webInterface для відображення результату 
користувачу; 11. webInterface використовує повідомлення notifyUser до 
notificationManager для фінального сповіщення про успіх або критичність 
знайденої помилки. 
Діаграма станів менеджера доступу та сесій 
Наступним кроком спроектуємо діаграму станів менеджера доступу 
(рисунок 2.13). У веб-сервісі він відіграє роль контролера сесій та валідатора прав 
доступу до API. Це гарантує, що запити до бази даних OBD-II виконуються 
коректно, а система захищена від зловмисних автоматизованих запитів. Ця логіка 
забезпечує контроль над станом підключення користувача та безпеку даних. 
Стани: 
1 Бездіяльність (Idle) - початковий стан, коли сесія ще не ініціалізована 
або очікується введення першого запиту. 
2 Перевірка токена/сесії (VerifyingAccess) - стан, у якому система 
перевіряє наявність активної сесії або валідність тимчасового токена 
доступу до API. 
3 Доступ надано (AccessGranted) - стан, що вказує на успішну перевірку, 
дозволяючи системі перейти до виконання пошукових запитів. 
4 Доступ відхилено (AccessDenied) - стан, що активується у разі помилки 
автентифікації або перевищення ліміту запитів. 
Переходи: 
Від бездіяльності до перевірки: ініціюється при спробі надіслати запит на 
пошук коду. 
Від перевірки до надання доступу: відбувається, коли система підтверджує 
можливість виконання операції. 
Від перевірки до відмови: активізується, якщо сесія застаріла або запит 
заблоковано системою безпеки. 
 
49 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.13 -Діаграма станів менеджера доступу 
 
Останнім кроком спроектуємо (рисунок 2.14) та опишемо діаграму станів 
для класу аналізу кодів несправностей (DTCAnalyzer). 
Стани: 
1 Очікування (Waiting) - початковий стан, у якому клас чекає на 
отримання валідного коду OBD-II від контролера. 
2 Аналіз даних (AnalyzingData) - стан, у якому сервіс обробляє отриманий 
код, звертається до бази даних та співставляє технічні параметри. 
3 Успішна ідентифікація (AnalysisSuccessful) - стан, який сигналізує про 
повне знаходження опису помилки та розрахунок її критичності. 
4 Помилка ідентифікації (AnalysisFailed) - стан, який вказує на відсутність 
коду в базі або неможливість коректно інтерпретувати технічні дані. 
Переходи: 
Із очікування до аналізу: відбувається, коли сервіс отримує підтверджені 
дані для обробки. 
Із аналізу до успішного завершення: активізується, коли знайдено 
відповідність у базі та сформовано звіт. 
Із аналізу до помилки: відбувається у випадку, коли отримані дані є 
50 
ЧДТУ 262249.011 ПЗ 
суперечливими або опис коду відсутній у глобальному реєстрі. 
 
 
Рисунок 2.14 – Діаграма станів сервісу аналізів кодів 
 
2.5.4. Діаграма скінченного автомату 
Одним із етапів проектування є створення діаграми скінченного автомату 
(діаграми станів). Оскільки складність діаграми напряму залежить від кількості 
компонентів та розгалуженості логіки, важливим кроком є розділення станів 
системи на логічні частини. Зокрема, розглянемо діаграму станів 
користувацького інтерфейсу (Web Interface), яка відображає життєвий цикл 
взаємодії користувача з формою пошуку та сервером Node.js. Спроектуємо 
51 
ЧДТУ 262249.011 ПЗ 
діаграму (рисунок 2.15) та опишемо її складові. 
Стани: 
1 Ініціалізовано (Initialized) - стан представляє момент завантаження веб-
сторінки, коли інтерфейс готовий до введення даних користувачем. 
2 Валідація вводу (ValidatingInput) - інтерфейс перебуває в режимі 
перевірки введеного коду DTC на відповідність формату перед 
відправкою запиту на сервер. 
3 Стан помилки формату (InvalidFormatState) - активується, якщо 
введений код не відповідає стандарту OBD-II. Відображається підказка 
щодо коректного формату вводу. 
4 Очікування відповіді (AwaitingResponse) - стан відображається під час 
активного HTTP-запиту до сервера, коли користувач бачить анімацію 
завантаження. 
5 Процес класифікації (ClassifyingUI) - стан відображається під час 
аналізу отриманих технічних даних та визначення рівня критичності 
несправності. 
Відображення результату (ResultUI) – фінальний стан, що показує 
розшифрований код, інструкції та колірну індикацію небезпеки. 
Переходи: 
1 Із стану "Ініціалізовано" до "Валідація вводу" -цей перехід відбувається 
автоматично після натискання користувачем кнопки "Пошук". 
2 Із "Валідація вводу" до "Очікування відповіді" -активізується, коли 
формат коду визнано коректним і дані відправлено на бекенд. 
3 Із "Валідація вводу" до "Стан помилки формату" -якщо регулярний 
вираз виявив помилку в написанні коду. 
4 Із "Очікування відповіді" до "Процес класифікації" -цей перехід 
відбувається, коли сервер успішно отримав дані з бази даних. 
5 Із "Процес класифікації" до "Відображення результату" -по завершенню 
розрахунку індексу критичності та формування звіту. 
52 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 2.15 – Діаграма станів інтерфейсу користувача веб-сервісу 
53 
ЧДТУ 262249.011 ПЗ 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
В процесі проектування, моделювання архітектури та моделювання 
поведінки системи прийшов до висновків, що процес проектування програмного 
забезпечення це складний процес, який на мою думку потребує значної уваги від 
розробника, проте в довгостроковій перспективі дозволяє зменшити час на 
розробку програмного забезпечення, зменшенні кількості багів та можливість 
подальшого розширення. 
Слід зауважити, що деякі із діаграм, на етапі розробки, можуть 
змінюватись, оскільки не можливо спроектувати програмне забезпечення, без 
подальшого покращення та змін, оскільки популярним є Agile підхід, що 
дозволяє розширювати продукт і швидко додавати та змінювати функціонал. 
 
54 
ЧДТУ 262249.011 ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
У даному розділі представлено детальний опис практичної реалізації 
розробленої системи веб додатку. Розглянуто обґрунтування вибору 
технологічного стеку, архітектурні рішення, структуру бази даних, опис 
алгоритмів взаємодії клієнтської та серверної частин, а також особливості 
проектування користувацького інтерфейсу. 
3.1. Програмно-апаратне забезпечення реалізації 
3.1.1. Обґрунтування вибору засобів реалізації 
Вибір програмних засобів для розробки веб сервісу діагностики 
здійснювався з урахуванням вимог до швидкодії, масштабованості та 
забезпечення надійного захисту персональних даних. Ключовим завданням було 
створення системи, що не лише знаходить опис помилок, а й забезпечує 
персоналізацію через збереження історії запитів. 
Серверна частина (Backend): 
Node.js: Обрано як основне середовище виконання. Завдяки подійній 
моделі введення-виведення (non-blocking I/O) платформа дозволяє обробляти 
асинхронні запити до бази даних без затримок. Це критично для UX, оскільки 
при кожному пошуку система виконує паралельні дії: вибірку результату та (для 
авторизованих користувачів) запис в історію. 
Express.js: Використано як мінімалістичний вебфреймворк. Він забезпечує  
ефективне  налаштування  REST  API  маршрутів  (/api/check, /api/history), 
що дозволяє клієнтській частині отримувати дані у форматі JSON без 
перезавантаження сторінки. 
Система керування базами даних (СКБД): 
PostgreSQL: На відміну від NoSQL-рішень, ця реляційна СКБД була обрана через 
необхідність чіткої структуризації зв’язків. У системі реалізовано відношення 
«один-до-багатьох» (один користувач -багато записів історії), що потребує 
55 
ЧДТУ 262249.011 ПЗ 
підтримки  ACID-транзакцій та строгій типізації. Використання PostgreSQL 
гарантує цілісність даних: запис в історію неможливий без існуючого ID 
користувача, що виключає появу «сирітських» даних у таблиці search_history. 
Клієнтська частина (Frontend): 
HTML5 та CSS3: застосовано для створення адаптивної оболонки. 
Використання CSS Variables (змінних) дозволило реалізувати фірмову «VIP-
стилістику» з неоновими акцентами та глибокими темними тонами, що відповідає 
преміальному позиціонуванню сервісу. 
Vanilla JavaScript (ES6+): обрано для забезпечення максимальної 
продуктивності. Використання асинхронних функцій (async/await) та Fetch API 
дозволяє динамічно оновлювати блок історії в бічній панелі (sidebar) одразу після 
отримання результатів аналізу, забезпечуючи відчуття роботи з нативним 
додатком. 
Font Awesome: інтегровано для візуалізації технічних параметрів та 
статусів, що спрощує сприйняття діагностичної інформації. 
Безпека та контроль станів: 
1 Bcrypt: бібліотека для незворотного хешування паролів. Забезпечує 
захист облікових даних: навіть у разі отримання доступу до БД, 
зловмисник не зможе відновити паролі у відкритому вигляді. 
2 Express-session: ключовий інструмент для реалізації історії. Дозволяє 
серверу «впізнавати» користувача за ідентифікатором сесії, що 
зберігається в куках. Саме це робить можливим функціонал 
автоматичного збереження кожного успішного пошуку в персональний 
журнал без необхідності повторного введення логіна. 
Апаратне середовище: розробка та тестування проводилися на робочій 
станції з архітектурою x64 (16 ГБ RAM, SSD). Це забезпечило швидкий відгук 
локального сервера та миттєву індексацію запитів у PostgreSQL. Продукт є 
кросплатформним і оптимізованим для сучасних браузерів, що важливо для 
автовласників, які можуть скористатися сервісом безпосередньо в дорозі через 
мобільний пристрій. 
56 
ЧДТУ 262249.011 ПЗ 
3.1.2. Опис структурної (функціональної) системи 
На рисунку 3.1 зображено функціональну схему роботи інтелектуальної 
системи діагностики. Функціонал сервісу побудований на клієнт-серверній 
архітектурі, де взаємодія між користувачем, сервером додатків та базою даних 
реалізована через три основні логічні контури: діагностику, авторизацію та 
керування історією запитів. 
 
 
Рисунок 3.1 - Функціональна схема системи діагностики 
 
Процес діагностичного аналізу та логіка пошуку: процес запускається 
користувачем  через  інтерфейс  клієнтської  частини.  Скрипт-обробник  на 
57 
ЧДТУ 262249.011 ПЗ 
стороні фронтенду виконує попередню перевірку DTC-коду (перевірка на 
порожнечу, анімація «shake» при помилці) та нормалізацію даних. Після цього 
формується асинхронний HTTP-запит до API сервера. 
Особливістю алгоритму пошуку на рівні СКБД є використання 
пріоритетності за брендом. SQL-запит сконструйований таким чином, що система 
спочатку шукає специфічне трактування коду для обраної марки автомобіля,  а  
у  разі  його  відсутності  -загальне  значення  за  протоколом «Generic». Це 
забезпечує максимальну точність діагностики для конкретних авто (наприклад, 
BMW або VAG). 
Контур автоматичного збереження історії: Нововведенням у 
функціональній схемі є механізм асинхронної персистенції пошуків. Після 
успішного отримання результату діагностики, фронтенд-частина ініціює 
додатковий фоновий запит до /api/history. Якщо сервер ідентифікує користувача 
як авторизованого (через активну сесію), дані про пошук (код, бренд, назва 
помилки та час) автоматично записуються в таблицю search_history. Це дозволяє 
користувачу бачити свої попередні запити в Sidebar без необхідності повторного 
введення даних. 
Авторизація та безпека: Процес керування профілем працює через 
інтерактивну бічну панель (Sidebar). Серверна частина виконує криптографічну 
перевірку паролів за допомогою бібліотеки bcrypt та створює активну сесію через 
express-session. Стан авторизації є «наскрізним»: при завантаженні сторінки запит 
до /api/me автоматично відновлює профіль користувача та підтягує його 
персональну історію пошуків. 
Всі описані процеси зображають структуровану взаємодію, де 
використання реляційної бази даних не лише надає довідкову інформацію, а й 
виступає персоналізованим сховищем знань користувача. Такий підхід 
забезпечує високу швидкість відгуку та створює цілісний UX (User Experience). 
Опис структурної схеми 
На рисунку 3.2 зображено структурну схему програмного комплексу, яка 
ілюструє статичну організацію модулів, компонентну топологію системи та 
58 
ЧДТУ 262249.011 ПЗ 
архітектурні зв'язки між ними. На відміну від функціональної схеми, яка описує 
динаміку інформаційних потоків, структурна схема визначає ієрархію побудови 
програмного забезпечення та взаємодію рівнів у межах класичної триланкової 
архітектури (клієнт — сервер додатків — база даних). 
 
 
Рисунок 3.2 – Структурна схема системи діагностики 
59 
ЧДТУ 262249.011 ПЗ 
Структурно програмне забезпечення розподілено на три автономні, але 
взаємопов'язані підсистеми. 
Рівень представлення даних (Client-Side / Frontend) реалізований на базі 
бібліотеки React з використанням інструментарію Tailwind CSS для побудови 
адаптивної модульної сітки. Структура фронтенд-частини містить три ключові 
компоненти: 
1 Модуль UI-компонентів (SearchForm, ResultCard, HistorySidebar) - 
відповідає за рендеринг графічних елементів, текстових полів та 
колірну індикацію рівнів критичності помилок. 
2 Блок клієнтської валідації та нормалізації рядків - програмний 
прошарок, що виконує первинну перевірку введених символів та їх 
переведення у верхній регістр. 
3 Менеджер мережевих запитів (Fetch API Client) - здійснює асинхронну 
відправку HTTP-запитів до бекенду та обробку JSON-відповідей. 
Рівень бізнес-логіки (Server-Side / Backend) побудований як REST API за 
допомогою серверної платформи Node.js та вебфреймворку Express.js. Це 
центральний керуючий вузол системи, який структурно складається з таких 
модулів: 
1 Маршрутизатор запитів (Router) - координує вхідні точки доступу 
(/api/check, /api/auth, /api/history). 
2 Контролер автентифікації та сесій (Auth Service) - взаємодіє з 
бібліотекою bcrypt для перевірки криптографічних хешів паролів та 
керує станом користувача за допомогою express-session. 
3 Пошуково-діагностичний двигун (DTC Engine) - реалізує алгоритми 
інтерпретації кодів OBD-II та формує логіку пріоритезації брендів 
автомобілів. 
Рівень збереження даних (Data-Tier / Database) представлений реляційною 
системою керування базами даних PostgreSQL, доступ до якої з боку бекенду 
забезпечується через ORM-прошарок Sequelize (або драйвер node-postgres). На 
структурному рівні БД організована у вигляді трьох взаємопов’язаних таблиць, 
60 
ЧДТУ 262249.011 ПЗ 
об’єднаних зовнішніми ключами (Foreign Keys): 
1 users — зберігає облікові дані користувачів (ідентифікатори, email, 
хешовані паролі). 
2 dtc_directory — глобальний довідник технічних помилок, що містить 
коди, описи, прив’язку до брендів, симптоми та інструкції з ремонту. 
3 search_history — журнал персональних запитів, пов’язаний 
відношенням «багато до одного» з таблицею користувачів для 
збереження хронології діагностики. 
Завдяки чіткому структурному поділу та слабкій зв’язності (Loose Coupling) 
компонентів, розроблена структура забезпечує високу масштабованість системи. 
Будь-який модуль (наприклад, база даних) може бути модернізований або 
перенесений на іншу інфраструктуру без необхідності перебудови чи  е 
факторингу коду рівнів представлення або бізнес-логіки. 
3.1.3. Опис логічної схеми системи 
Процес функціонування системи базується на подієво-орієнтованій моделі 
взаємодії між клієнтською частиною, сервером додатків та реляційним сховищем. 
Логіка системи організована як послідовність асинхронних операцій, що 
забезпечують безперервність UX (User Experience). 
На рисунку 3.2 зображено блок-схему логічної роботи системи. Алгоритм 
роботи системи включає наступні етапи: 
1 Ініціалізація та конфігурація. При запуску сервера Node.js створюється 
пул з’єднань з PostgreSQL. Активується middleware для парсингу JSON 
та ініціалізується механізм express-session, що створює унікальний 
ідентифікатор сесії для кожного підключеного клієнта. 
2 Обробка вхідних параметрів та валідація. Користувач вводить DTC-код. 
Логіка JavaScript на стороні клієнта миттєво нормалізує ввід 
(toUpperCase). Якщо поле порожнє, спрацьовує візуальний тригер 
«shake». Тільки після успішної валідації ініціюється fetch-запит до API. 
3 Логіка вибірки з приорітетом. Сервер отримує запит і виконує 
спеціалізований SQL-запит до таблиці dtc_codes. Логіка реалізована 
61 
ЧДТУ 262249.011 ПЗ 
через конструкцію ORDER BY CASE: система спочатку перевіряє 
наявність коду для конкретного бренду, а за його відсутності - повертає 
загальне («Generic») трактування. 
 
 
Рисунок 3.2 -Блок-схема логічної роботи веб-сервісу діагностики 
 
Логіка вибірки з приорітетом. Сервер отримує запит і виконує 
спеціалізований SQL-запит до таблиці dtc_codes. Логіка реалізована через 
конструкцію ORDER BY CASE: система спочатку перевіряє наявність коду для 
конкретного бренду, а за його відсутності -повертає загальне («Generic») 
трактування. 
Класифікація та мапінг. Отриманий числовий індекс критичності (severity: 0, 
1, 2) на стороні фронтенду мапиться на об'єкт станів. Це дозволяє динамічно 
змінювати клас CSS (low, medium, high) та текстовий маркер («Критично», 
«Помірно» тощо), адаптуючи інтерфейс під рівень загрози несправності. 
62 
ЧДТУ 262249.011 ПЗ 
Асинхронна персистенція історії. Це ключовий логічний розгалужувач: 
якщо сервер підтверджує наявність активної сесії користувача, після 
відображення результату діагностики фронтенд автоматично надсилає POST-
запит на /api/history. Дані про пошук записуються в БД, а блок історії в Sidebar 
оновлюється без перезавантаження сторінки. 
Динамічна візуалізація. Система використовує метод scrollIntoView для 
плавного фокусування користувача на результаті аналізу та методах усунення 
несправності, що забезпечує логічне завершення діагностичного циклу. 
Завершення сесії. При ініціалізації виходу (Logout) об'єкт сесії на сервері 
знищується (session.destroy()), а фронтенд скидає стан інтерфейсу до режиму 
«Гість», приховуючи персональні дані та історію. 
3.1.4. Розробка структури бази даних 
Для забезпечення надійного зберігання діагностичних даних, профілів 
користувачів та їхньої персональної активності у системі використано реляційну 
СКБД PostgreSQL. Вибір цієї системи дозволив реалізувати строгу цілісність 
даних через механізм зовнішніх ключів (Foreign Keys), що є критично важливим 
для коректного відображення історії пошуків конкретного користувача. 
Проєктування бази даних виконано за класичним підходом, що включає 
опис фізичної моделі даних, яка складається з трьох взаємопов'язаних таблиць. 
 
Таблиця 3.1 
Користувачі(Users) 
Назва поля Тип даних Опис 
Id Seiral Унікальний ідентифікатор користувача 
Email Varchar(255) Електронна пошта (унікальне поле) 
Password Text Хешований пароль (алгоритм bcrypt) 
Created_at TimeStamp Дата та час реєстрації акаунта 
 
Таблиця 3.2 
63 
ЧДТУ 262249.011 ПЗ 
Довідник помилок(dtc_codes) 
Назва поля Тип даних Опис 
Id Serial Унікальний ідентифікатор запису 
Code Varchar(10) Стандартизований код помилки (напр., P0300) 
Brand Varchar(50) Марка авто або значення 'generic' (загальний) 
Description Text Розгорнутий опис несправності 
Advice Text Рекомендації щодо усунення (кроки ремонту) 
Severity Integer Рівень критичності (0 -низький, 1 -середній, 2 -
високий) 
 
Таблиця 3.3 
Історія пошуків(search_history) 
Назва поля Тип даних Опис 
Id Serial Унікальний ідентифікатор запису 
User_id Integer ID користувача (Foreign Key до таблиці users) 
Code Varchar(10) Код, який було знайдено 
Brand Varchar(50) Марка автомобіля, за якою вівся пошук 
Name Varchar(255) Назва помилки на момент пошуку 
Severity Integer Рівень критичності 
Searched_at Timestamp Дата та час здійснення запиту 
 
Використання прямих SQL-запитів замість ORM-фреймворків у даній 
роботі обґрунтовано потребою в максимальній продуктивності та повному 
контролі над вибіркою. Зокрема, реалізований алгоритм пошуку використовує 
механізм пріоритезації через конструкцію ORDER BY CASE. Це дозволяє 
системі за один цикл звернення до БД обрати найбільш релевантний опис: якщо 
для коду знайдено специфічне трактування від бренду, воно стає першим у 
видачі, інакше -повертається загальне значення. 
Зв'язок між таблицями users та search_history реалізовано за принципом 
«один-до-багатьох». Це гарантує, що при видаленні акаунта користувача (за 
64 
ЧДТУ 262249.011 ПЗ 
потреби) його історія може бути каскадно видалена або збережена для аналітики, 
що забезпечує гнучкість управління даними. 
Така структура дозволяє легко масштабувати систему: додавання 
підтримки нових марок автомобілів або розширення бази кодів потребує лише 
внесення нових рядків до таблиці dtc_codes без жодних змін у логіці серверних 
скриптів. 
 
 
Рисунок 3.3 -ER-діаграма бази даних 
 
3.1.5. Розробка програмного інтерфейса користувача 
Проектування архітектури API є ключовим етапом розробки, оскільки саме 
програмний інтерфейс забезпечує безшовну взаємодію між клієнтською 
частиною (Frontend) та серверною логікою. Добре спроектоване API гарантує 
масштабованість системи, дозволяючи в майбутньому легко підключати нові 
модулі (наприклад, мобільний додаток) без зміни ядра системи. 
Розроблене API побудоване за принципами REST (Representational State 
Transfer), де кожен ресурс має свій унікальний шлях (endpoint), а обмін даними 
відбувається у форматі JSON. Це забезпечує легкість інтеграції та високу 
65 
ЧДТУ 262249.011 ПЗ 
швидкість обробки запитів. 
Основні компоненти програмного інтерфейсу: 
1 Управління діагностичними запитами 
Це ядро системи, що забезпечує пошук інформації про несправності. API 
обробляє вхідні параметри (код DTC та бренд авто) та повертає структурований 
об’єкт даних. 
Метод GET /api/check/:code/:brand: ініціює алгоритм пошуку з 
пріоритезацією. Як зображено на рисунку 3.3, сервер перевіряє наявність коду в 
базі даних та повертає його опис, рівень критичності та поради щодо ремонту. 
 
 
Рисунок 3.3 – Частина програмного інтерфейсу (обробка діагностичного запиту) 
 
2 Керування профілями користувачів 
API забезпечує повний цикл автентифікації. Використання методів POST 
дозволяє безпечно передавати конфіденційні дані в тілі запиту, що мінімізує 
66 
ЧДТУ 262249.011 ПЗ 
ризики перехоплення інформації. 
Методи register та login: забезпечують створення облікового запису та 
перевірку існуючих сесій. Як зображено на рисунку 3.4, API взаємодіє з 
бібліотекою bcrypt для перевірки відповідності паролів. 
 
 
Рисунок 3.4 –Частина програмного інтерфейсу (автентифікація користувача) 
 
3 Модуль управління історією 
Цей сегмент API відповідає за збереження та вибірку активності 
користувача. Він автоматично пов’язує кожен успішний запит із конкретним ID 
користувача через сесію. 
Методи GET /api/history та POST /api/history: дозволяють отримувати 
список попередніх пошуків та записувати нові результати. Це реалізовано через 
асинхронні виклики, що не блокують основний потік роботи користувача. 
67 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 3.5 –Частина програмного інтерфейсу (робота з персональною 
історією) 
 
4 Система контролю станів та сесій 
API надає можливість перевіряти поточний стан авторизації клієнта. Метод 
/api/me дозволяє фронтенду ініціалізувати профіль користувача при кожному 
завантаженні сторінки, забезпечуючи «безшовний» доступ до системи. 
 
 
Рисунок 3.6 –Частина програмного інтерфейсу (перевірка активної сесії) 
 
5 Механізми обробки винятків 
Важливою частиною API є уніфікована система повернення статусів. 
Кожна відповідь сервера містить прапор success, що дозволяє клієнтській частині 
коректно реагувати на успіх операції або виникнення помилок (наприклад, 
відсутність коду в базі або невірний пароль). 
3.1.6. Опис розробки програмних компонентів 
У розробленій системі діагностики реалізовано модульну архітектуру, що 
68 
ЧДТУ 262249.011 ПЗ 
забезпечує чіткий розподіл відповідальності між компонентами обробки даних, 
безпеки та інтерфейсу. Основною точкою входу є серверний додаток на базі 
Node.js, який координує взаємодію всіх модулів. 
Основними програмними компонентами системи є: 
Контролер діагностики - центральний модуль серверної частини, що 
відповідає за обробку вхідних DTC-кодів. Він реалізує логіку взаємодії з базою 
даних, формує SQL-запити з першочерговістю брендів та структурує відповідь 
для клієнта. 
Database Access Object (DAO) - компонент, побудований на базі модуля pg 
(PostgreSQL client). Він керує групою з’єднань з базою даних, забезпечуючи 
стабільний доступ до таблиць з кодами помилок, користувачами та історією 
користувачів, мінімізуючи навантаження на ресурси сервера. 
Authentication Manager (Менеджер автентифікації) -програмний модуль, що 
відповідає за безпеку. Він включає логіку хешування паролів за допомогою 
алгоритму bcrypt та управління сесіями через express-session. Цей компонент 
забезпечує розподіл прав доступу між гостями та авторизованими користувачами. 
History Persistence Engine (Модуль збереження історії) -компонент, що 
реалізує механізм автоматичного логування запитів. Він неодночасно відстежує 
успішні пошуки та зберігає їх у персональному журналі користувача, пов’язуючи 
дані через ідентифікатори сесій. 
UI Rendering Engine (Клієнтський двигун візуалізації) -набір функцій на 
стороні фронтенду (renderResult, loadHistory), що відповідають за динамічне 
оновлення DOM-дерева. Він перетворює отримані JSON-дані у візуальні блоки з 
відповідною кольоровою індикацією критичності. 
Status Monitor (Монітор статусів) -допоміжний компонент, що відображає 
стан підключення до системи (status bar) та інформує користувача про процес 
аналізу за допомогою анімаційних індикаторів (Spinners). 
Sidebar Controller (Контролер бічної панелі) -програмний модуль, що керує 
інтерфейсом профілю. Контролер забезпечує переключення між формами входу 
або реєстрації та динамічне завантаження списку історії пошуків без 
69 
ЧДТУ 262249.011 ПЗ 
перезавантаження всієї сторінки. 
3.2. Тестування системи 
3.2.1. Модальне тестування 
Для забезпечення стабільності роботи системи «DR.AUTO VIP» та 
перевірки коректності логіки обробки DTC-кодів було проведено модульне 
(юніт) тестування. Основним інструментом тестування обрано фреймворк Jest, 
який є стандартом для Node.js додатків завдяки своїй продуктивності та 
вбудованим засобам створення звітів. 
Тести розроблялися згідно з методологією AAA (Arrange, Act, Assert), що 
дозволяє структурувати кожен тест на три логічні етапи: 
Arrange - підготовка вхідних даних (наприклад, створення тестового коду 
помилки). 
Act - виконання конкретної функції або запиту до API. Assert - порівняння 
отриманого результату з очікуваним. 
Нижче представлено опис ключових тестів, реалізованих у файлі api.test.js: 
1 Тестування валідації та нормалізації даних. Перевірка того, що 
фронтенд-скрипти правильно приводять ввід користувача до верхнього регістру 
та відхиляють порожні запити. 
 
 
Рисунок 3.8 - Уривок коду (Тестування нормалізації DTC-коду) 
 
2 Тестування логіки пріоритетності пошуку. Імітація запиту до бази 
даних, де для одного коду існують записи «BMW» та «Generic». Тест 
70 
ЧДТУ 262249.011 ПЗ 
підтверджує, що система першим повертає опис бренду. 
 
 
Рисунок 3.9 - Тестування алгоритму пріоритезації (Brand vs Generic) 
 
3 Тестування обробки відсутності даних. Перевірка реакції API на 
неіснуючий код помилки. Очікуваний результат -статус 404 та повідомлення про 
відсутність інформації. 
 
 
Рисунок 3.10 - Тестування обробки сценарію «Код не знайдено» 
 
4 Тестування механізму автентифікації. Перевірка функцій хешування 
паролів та створення токена сесії для користувача. 
71 
ЧДТУ 262249.011 ПЗ 
 
Рисунок 3.11 - Метод для тестування криптографічної перевірки пароля 
 
5 Тестування збереження історії. Перевірка асинхронного запису 
результату діагностики в таблицю search_history для авторизованого користувача. 
 
 
Рисунок 3.12 - Тестування інтеграції з модулем історії 
 
У таблиці 3.4 представлені кінцеві результати модульного тестування 
основних компонентів системи. 
 
Таблиця 3.4 
Результати модального тестування 
Об’єкт Вхідні дані Очікуваний Фактичний Статус 
тестування результат результат 
Нормалізація P0300 P0300 P0300 Pass 
 
 
 
72 
ЧДТУ 262249.011 ПЗ 
Продовження таблиці 3.4 
Пріорітет Код:P0420, Опис можливого Опис можливого Pass 
бренду Бренд: BMW рішення проблеми рішення проблеми, 
та критичність 
помилки 
Відсутній код P9999 Повідомлення про «Код P9999 не Pass 
відсутність коду в знайдено. Перевірте 
БД правильність коду 
або спробуйте 
"Загальний". 
Авторизація Вірна пошта Success: true + сесія Вхід до профілю з Pass 
та пароль можливістю 
перегляду пошуку 
помилок 
Історія Бути Успішний пошук, Дані відображаются Pass 
авторизован після авторизації в в історії пошуку 
им та профіль, 
виконати збереження даних в 
пошук коду історію пошуку 
 
3.2.2. Інтеграційне тестування 
Інтеграційне тестування було спрямоване на перевірку взаємодії між 
ключовими компонентами веб-додатка: клієнтським інтерфейсом, API-сервером 
та реляційною базою даних PostgreSQL. Метою тестування було виявлення 
помилок, які можуть виникнути при передачі даних між шарами архітектури, та 
перевірка цілісності бізнес-логіки в умовах реальних запитів. 
Тестування почалося з перевірки базових ланцюжків взаємодії: відправка 
форми діагностики, обробка запиту сервером, отримання даних з БД, динамічне 
оновлення DOM-дерева на клієнті. Кожен з цих ланцюжків перевірявся для того, 
щоб переконатися, що неодночасні виклики fetch правильно обробляють різні 
73 
ЧДТУ 262249.011 ПЗ 
стани сервера (успіх, помилка 404, помилка сервера 501). 
Під час інтеграційного тестування особлива увага приділялася взаємодії 
модуля автентифікації та модуля історії. Тести перевіряли, чи правильно сервер 
ідентифікує користувача через об'єкт req.session при спробі збереження нового 
пошуку. Важливо було забезпечити, щоб дані в таблиці search_history 
створювалися лише за наявності активної сесії та коректного user_id. 
Для тестування використовувалися сценарії «end-to-end» (E2E) взаємодії. 
Результати показали стабільну роботу системи, хоча на початкових етапах було 
виявлено проблему із втратою стану сесії при швидкому перезавантаженні 
сторінки. Проблему було вирішено шляхом коректного налаштування resave: 
false у конфігурації express-session. 
У результаті інтеграційного тестування, результати якого наведено в 
таблиці 3.5, було підтверджено, що всі компоненти (Frontend, Backend, DB) 
правильно взаємодіють між собою, забезпечуючи цілісність даних та прозорість 
діагностичного процесу. 
 
Таблиця 3.5 
Результати інтеграційного тестування 
Сценарій 
інтеграційного Очікуваний результат Отриманий результат 
тесту 
Пошук DTC-коду Сервер повертає JSON із даними Дані отримано, 
для конкретного бренду, фронтенд показує картку інтерфейс оновлено 
бренду результату згідно зі 
специфікацією 
Авторизація та Після входу запит до /api/me Сесія активна, історія 
доступ до історії повертає дані користувача, Sidebar успішно завантажена з 
завантажує історію БД та відображена 
 
 
 
74 
ЧДТУ 262249.011 ПЗ 
Продовження таблиці 3.5 
Збереження Фронтенд відображає результат, але Запит відхилено (401), 
пошуку в режимі запит до /api/history ігнорується або запис у БД не створено 
"Гість" відхиляється 
Реєстрація з Сервер повертає статус Отримано статус 409, 
існуючим 
Email 409, фронтенд показує помилку виведено відповідне 
"Email вже зареєстровано" повідомлення 
Коректність При отриманні історії кожен запис Дані історії 
зв'язку таблиць містить правильний код та бренд, що відповідають 
(Join) відповідає user_id ідентифікатору 
поточної сесії 
Обробка розриву При зупинці PostgreSQL сервер Клієнт отримав статус 
з'єднання з БД повертає статус 500, клієнт показує 500 та вивів 
повідомлення про помилку попередження через 
підключення alert 
 
3.2.3. Системне тестування 
Системне тестування є фінальним етапом забезпечення якості, на якому 
перевіряється відповідність усього програмного комплексу початковим 
технічним вимогам та сценаріям використання. Після успішного завершення 
інтеграційних перевірок було проведено повне тестування веб-сервісу як єдиного 
цілого. 
Для проведення системного тестування було розроблено набір сценаріїв, 
що імітують реальну поведінку користувача власника авто або майстра СТО. 
Тестування охоплювало повний життєвий цикл роботи з додатком: від першого 
звернення до бази даних несправностей до управління персональним профілем та 
історією діагностики. 
Сценарій повної діагностики: тестувальник перевірив наскрізний процес: 
введення специфічного коду (наприклад, P0300), вибір марки автомобіля та 
75 
ЧДТУ 262249.011 ПЗ 
отримання результату. Перевірялося, що система точно відображає не лише опис, 
а й поради щодо усунення несправності, а також змінює колір індикатора 
критичності (severity badge). 
Управління профілем та безпека: системна перевірка включала тестування 
механізмів реєстрації, входу та виходу з системи. Особлива увага приділялася 
збереженню стану сесії. Перевірялося, що після перезавантаження сторінки 
авторизований користувач залишається в системі, а його персональні дані та 
кнопка профілю відображаються коректно. 
Функціонування персонального журналу (Історія): тестувалася здатність 
системи автоматично накопичувати дані. Перевірялося, що кожен новий 
успішний запит миттєво з'являється у профілі (бічній панелі) без потреби 
оновлювати сторінку вручну. Також було підтверджено коректність роботи 
функції «Повторний пошук» при натисканні на попердній запит. 
Стійкість до некоректних даних та помилок: тестувальник перевірив 
реакцію системи на критичні сценарії - спробу реєстрації з порожніми полями, 
введення неіснуючих кодів DTC та роботу сервісу при відсутності з’єднання з 
базою даних. Система продемонструвала стабільність, видаючи зрозумілі 
користувачеві сповіщення (валидація, shake-анімація інпутів, alert-повідомлення). 
Результати тестування: всі загрозливі сценарії пройшли перевірку успішно. 
Під час тестування не було виявлено помилок, що заважають використанню 
сервісу. Система продемонструвала високу швидкість відгуку (менше 200 мс на 
запит до БД) та коректну роботу фронтенд-логіки на різних роздільних 
спроможностях екрана. 
Системне тестування підтвердило, що веб-сервіс повністю відповідає 
функціональним вимогам, є стабільним та готовим до розгортання в реальних 
умовах експлуатації. 
3.2.4. Приймальне тестування 
Приймальне тестування програмного забезпечення було проведене з метою 
підтвердження готовності продукту до фінальної експлуатації кінцевими 
користувачами. Основна увага приділялася перевірці відповідності 
76 
ЧДТУ 262249.011 ПЗ 
сервісу бізнес-цілям: швидкості пошуку помилок або несправностей, точності 
наданих рекомендацій, щодо усунення помилок та зручності інтерфейсу для 
користувачів. 
Під час приймального тестування були перевірені всі ключові аспекти 
роботи системи: 
Функціональність: точність відпрацювання алгоритму пріоритезації (видача 
специфічних описів брендів перед загальними); 
Продуктивність: швидкість завантаження історії пошуків та обробки 
запитів до бази даних PostgreSQL (середній час відповіді склав менше 150 мс); 
Надійність: коректне збереження сесій користувачів та захищеність 
персональних даних (хешування паролів). 
Після завершення внутрішніх перевірок систему було впроваджено у 
тестову експлуатацію на базі набору реальних логів діагностичних сканерів 
(DTC-логів). У процесі цього етапу підтверджено відповідність системи потребам 
цільової аудиторії. На рисунку 3.14 зображено інтерфейс системи під час 
фінального приймального тестування, де проводився аналіз серії помилок 
системи упорскування. 
 
 
Рисунок 3.14  -Інтерфейс системи під час приймального тестування 
77 
ЧДТУ 262249.011 ПЗ 
Рисунок 3.15 – Інтерфейс системи після вводу коду 
 
 
Рисунок 3.16 – Зображення історії пошуку помилок 
 
На прикладі реалізації сервісу продемонстровано його практичні 
можливості. Зокрема, через інтерфейс було успішно опрацьовано запити на 
78 
ЧДТУ 262249.011 ПЗ 
складні коди помилок (наприклад, серії P0420, P0300), продемонстровано 
динамічне відображення рівнів критичності та миттєве оновлення персональної 
історії пошуків. Система коректно обробила сценарії одночасної роботи кількох 
авторизованих користувачів, забезпечуючи ізоляцію їхніх даних. 
За результатами приймального тестування веб-сервіс отримав позитивний 
висновок та рекомендації до впровадження. Система визнана придатною для 
масштабування (додавання нових марок автомобілів та розширення бази даних), 
що дозволяє використовувати її як надійний інструмент для швидкої первинної 
діагностики автомобілів, значно знижуючи час на пошук причин несправностей. 
3.3. Приклади впровадження програмного комплексу 
Проект розроблений за принципами відкритого коду (Open Source), що 
дозволяє масштабувати базу діагностичних кодів та адаптувати функціонал під 
потреби конкретних СТО або спільнот автовласників. Весь вихідний код, 
включаючи  серверні  скрипти,  фронтенд-частину  та  схему  бази  даних, 
розміщено у репозиторії на платформі GitHub, що спрощує процес спільної 
розробки та оновлення системи. 
Для розгортання системи веб-додатку у локальному середовищі або на 
віддаленому сервері необхідно виконати наступні кроки: 
Клонування репозиторію: завантаження вихідного коду з GitHub на цільову 
машину. 
Налаштування середовища: встановлення платформи Node.js та системи 
керування базами даних PostgreSQL. 
Інсталяція залежностей: використання пакетного менеджера npm для 
завантаження необхідних бібліотек (express, pg, bcrypt, express-session), що 
вказані у файлі package.json. 
Конфігурація бази даних: виконання SQL-скриптів для створення таблиць 
users, dtc_codes та search_history, а також імпорт початкового довідника кодів 
помилок. 
Налаштування з'єднання: редагування параметрів підключення у файлі 
server.js (host, user, password, database) відповідно до налаштувань встановленої 
79 
ЧДТУ 262249.011 ПЗ 
СУБД. 
Після виконання цих кроків запуск сервера здійснюється командою node 
server.js, що робить систему доступною за адресою http://localhost:3000. 
Таким чином, розгортання системи потребує мінімальних зусиль, що 
робить сервіс легким у впровадженні та дозволяє зосередитись на наповненні 
діагностичної бази знань без необхідності розробки базової інфраструктури з 
нуля. 
80 
ЧДТУ 262249.011 ПЗ 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
У третьому розділі було проведено повний цикл проектування, розробки та 
тестування веб-сервісу інтелектуальної діагностики автомобілів «DR.AUTO 
VIP». Було виконано проектування: Розроблено фізичну модель бази даних у 
складі трьох взаємопов'язаних таблиць, що забезпечує стабільне зберігання 
профілів користувачів та їхньої історії пошуку. Створено програмний інтерфейс 
(API) на базі Node.js, який реалізує алгоритм інтелектуального пошуку DTC-кодів 
з пріоритезацією за маркою автомобіля. Проведено комплексне тестування 
системи (модульне, інтеграційне та системне). Результати підтвердили 
стабільність роботи механізмів автентифікації, коректність обробки запитів до 
БД та високу продуктивність інтерфейсу. Описано процес розгортання системи та 
підтверджено її готовність до роботи в реальних умовах. 
В результаті розробки можна зробити висновок, що створений вебсервіс 
повністю відповідає технічним вимогам, забезпечує зручний доступ до 
діагностичної інформації та має потенціал для подальшого масштабування. 
 
81 
ЧДТУ 262249.011 ПЗ 
ВИСНОВОК 
У межах бакалаврської роботи було успішно реалізовано повний цикл 
проектування, розробки та верифікації веб-сервісу онлайн-діагностики 
автомобілів. У результаті виконано аналіз предметної області, опрацьовано 
сучасні архітектурні підходи та створено конкурентоспроможне програмне 
забезпечення, що дозволяє швидко інтерпретувати коди помилок бортових 
систем автомобіля (OBD-II) відповідно до актуальних запитів користувачів. 
Розроблене рішення успішно минає недоліки існуючих платних чи інтерфейсно 
складних аналогів, забезпечуючи безкоштовний і мобільно-адаптований доступ 
до діагностичних даних. 
На етапі теоретичного дослідження було детально охарактеризовано 
процес комп’ютерної діагностики сучасного транспорту та специфіку 
формування п'ятизначних кодів DTC. Було виражено технічні, функціональні та 
нефункціональні вимоги дозволили чітко окреслити критерії швидкодії (час 
відгуку до 300 мс), безпеки (хешування паролів за допомогою bcrypt) та 
адаптивності інтерфейсу під мобільні операційні системи Android та iOS. 
Обґрунтований вибір сучасного технологічного стеку — середовища виконання 
Node.js, вебфреймворку Express.js, реляційної БД PostgreSQL та інструментів 
Vanilla JavaScript (ES6+) — заклав міцний фундамент для побудови асинхронної, 
продуктивної та масштабованої системи. 
У процесі проєктування було детально змодельовано предметну область за 
допомогою інструментарію UML, зокрема побудовано діаграми послідовності 
взаємодії та діаграми станів сервісу аналізу кодів. Особливу увагу приділено 
розробці логічних модулів для зменшення помилок введення (попередня 
перевірка, очищення відступів та нормалізація регістру рядка) та математичній 
класифікації критичності виявлених поломок\несправностей за ступенем їхнього 
впливу на безпеку руху автомобілю. Спроектована реляційна структура бази  
даних та словник базових сутностей («Користувач», «Автомобіль», «Код 
помилки», «Рішення») забезпечили логічну цілісність зв'язків між технічними 
ідентифікаторами та інструкціями з ремонту. 
82 
ЧДТУ 262249.011 ПЗ 
На етапі практичної реалізації розроблено стійкий програмний інтерфейс 
(REST API) та спроектовано базу даних у складі трьох взаємопов'язаних таблиць, 
які повністю підтримують ACID-транзакції та виключають появу некоректних 
або ізольованих записів. Впроваджено надійний контур безпеки облікових даних 
через механізми незворотнього хешування паролів та керування активними 
сесіями (express-session), що дозволило реалізувати інтелектуальну функцію 
автоматичного фонового збереження історії пошуків у персональний журнал 
користувача. Особливістю розробленого пошукового алгоритму стала гнучка 
пріоритезація запитів на рівні БД: система спочатку здійснює пошук 
специфічного трактування помилки для конкретного бренду авто, і лише за його 
відсутності звертається до загального протоколу Generic. Інтерфейс користувача 
отримав адаптивне оформлення у темних тонах із використанням CSS Variables 
для забезпечення унікальної стилістики. 
Програмний продукт пройшов комплексне тестування (модульне, 
інтеграційне та системне), що підтвердило стабільність процесів засвідчення, 
точність обробки запитів до БД, відсутність затримок завдяки non-blocking I/O 
архітектурі та повну готовність до експлуатації користувачами в реальних 
умовах. 
Таким чином, розроблений веб-сервіс є технічно готовим, надійним, 
функціональним та безпечним програмним забезпеченням. Проект повністю 
виконує поставлені завдання, автоматизує процеси збору й систематизації 
діагностичної інформації, забезпечує високу персоналізацію для автовласників 
та володіє потенціалом для подальшого розширення бази знань помилок та 
несправностей і масштабування інфраструктури. 
 
83 
ЧДТУ 262249.011 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Pressman, R. S. Software Engineering: A Practitioner’s Approach. 8th 
Edition. – McGraw-Hill Education, 2014. – https://www.mheducation.com/ 
2 Sommerville, I. Software Engineering. 10th Edition. – Pearson, 2015. – 
https://www.pearson.com/ 
3 Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling 
Language. – Addison-Wesley, 2003. https://martinfowler.com 
/books/uml.html 
4 Object Management Group. Unified Modeling Language Specification, 
Version 2.5.1. – OMG, 2017. – https://www.omg.org/spec/UML/2.5.1/About-
UML 
5 ISO/IEC/IEEE 12207:2017. Systems and software engineering — Software 
life cycle processes. – https://www.iso.org/standard/63712.html 
6 ISO/IEC 25010:2011. Systems and software engineering — Systems and 
software Quality Requirements and Evaluation. – https://www.iso.org/ 
standard/35733.html 
7 Node.js Documentation. Official API Reference. – https://nodejs.org/api/ 
8 Express.js Documentation. Fast, unopinionated, minimalist web framework 
for Node.js. – https://expressjs.com/ 
9 React Documentation. Official Reference and Guides. – https://react.dev/ 
10 PostgreSQL Documentation. Official Reference for PostgreSQL Database 
Management System. – https://www.postgresql.org/docs/ 
11 Node-Postgres (pg) Documentation. Non-blocking PostgreSQL client for 
Node.js. – https://node-postgres.com/ 
12 Sequelize ORM Documentation. Feature-rich ORM for Node.js and 
PostgreSQL. – https://sequelize.org/ 
13 Tailwind CSS Documentation. Utility-first CSS framework for rapid UI 
development. – https://tailwindcss.com/docs 
14 MDN Web Docs. Fetch API Guide. – Mozilla Developer Network. – 
84 
ЧДТУ 262249.011 ПЗ 
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API 
15 MDN Web Docs. Express-session middleware documentation. – Mozilla 
Developer Network. – https://developer.mozilla.org/en-US/docs/Learn/Server 
-side/Express_Nodejs/sessions 
16 bcrypt Documentation. Password hashing library for Node.js. – npm 
registry. – https://www.npmjs.com/package/bcrypt 
17 SAE International. On-Board Diagnostics (OBD-II) Standard Specifications 
and Communication Protocols. – https://www.sae.org/ standards/content/ 
j1979_201702/ 
18 Jest Documentation. Delightful JavaScript Testing Framework for Node.js 
and React. – https://jestjs.io/docs/getting-started 
19 Visual Studio Code Documentation. – https://code.visualstudio.com/docs 
20 Reddit - https://www.reddit.com 
21 Repository at ChSTU - https://er.chdtu.edu.ua/handle/ChSTU/9027 
22 GitHub – github.com 
 
85 
ДОДАТОК А 
 
ЗАТВЕРДЖЕНО 
Зав. кафедри ПЗАС, професор 
 С.В. Голуб 
« »  2026 року 
 
 
 
 
 
«Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за 
кодами помилок» 
 
 
 
 
 
Специфікація 
482.ЧДТУ 262249 011 
Листів 2 
 
 
 
 
 
 
Розробник Макаріхін О.О. 
 
(підпис) (прізвище та ініціали) 
 
Керівник Півень О.Б. 
 
(підпис) (прізвище та ініціали) 
 
 
 
Черкаси 2026 
 
 
482 ЧДТУ 2 62249 011 
Позначення Найменування Примітка 
 Документація  
482.ЧДТУ 26.2249 12 01 Текст програми  
482. ЧДТУ 26 2249 34 01 Інструкція користувача  
482.ЧДТУ 26. 2249 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
87 
 
ДОДАТОК Б 
«Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за кодами 
помилок» 
Текст програми 
482.ЧДТУ 262249 12 01 
Листів 12 
Розробник Макаріхін О.О. 
(підпис) (прізвище та ініціали) 
Черкаси 2026 
482.ЧДТУ 262249 12 01 2 
<!DOCTYPE html> 
<html lang="uk"> 
<head> 
<meta charset="UTF-8"> 
<meta name="viewport" content="width=device-width, initial-scale=1.0"> 
<title>DR.AUTO — Інтелектуальна діагностика</title> 
<link 
href="https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@300;400;500;60 
0;700&family=JetBrains+Mono:wght@400;500;700&display=swap" rel="stylesheet"> 
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-
awesome/6.0.0/css/all.min.css"> 
<link rel="stylesheet" href="style.css"> 
</head> 
<body> 
<div class="glow-top"></div> 
<div class="wrapper"> 
<header> 
<div class="logo-row"> 
<div class="logo-icon"> 
<i class="fas fa-car-crash"></i> 
</div> 
<div class="logo-text"> 
<h1>DR.AUTO <span>VIP</span></h1> 
<div class="sub">OBD-II Diagnostic Engine</div> 
</div> 
</div> 
<div class="status-bar"> 
<div class="status-dot"></div> 
<span>Система онлайн · Готова до роботи</span> 
</div> 
<!-- Кнопка профілю --> 
<button class="btn-profile" id="btn-open-sidebar" onclick="openSidebar()"> 
<i class="fas fa-user-circle"></i> 
<span id="btn-profile-label">Увійти</span> 
</button> 
</header> 
<!-- SEARCH FORM --> 
<div class="card search-card"> 
<div class="section-label"> 
<i class="fas fa-sliders-h" style="color:var(--accent); font-size:10px;"></i> 
Параметри запиту 
</div> 
<div class="field"> 
<label><i class="fas fa-industry"></i> Марка автомобіля</label> 
<div class="input-wrap"> 
<select id="car-brand"> 
<option value="generic">Загальний (Generic)</option> 
<option value="bmw">BMW Group</option> 
<option value="vag">VAG Group (Audi / VW / Porsche)</option> 
<option value="ford">Ford</option> 
</select> 
<i class="fas fa-chevron-down select-arrow"></i> 
</div> 
</div> 
<div class="field"> 
<label> 
89 
482.ЧДТУ 262249 12 01 3 
<i class="fas fa-barcode"></i> Код помилки DTC 
<span class="info-tip" title="Формат: Axxxx, напр. 
P0300">?</span> 
</label> 
<div class="input-wrap"> 
<input type="text" id="dtc-code" placeholder="P0300" maxlength="5" 
spellcheck="false"> 
</div> 
</div> 
<button class="btn-primary" id="search-btn"> 
<i class="fas fa-microchip"></i> 
<span>Запустити діагностику</span> 
</button> 
</div> 
<!-- RESULT CARD --> 
<div class="card result-card hidden" id="result-container"> 
<div class="section-label"> 
<i class="fas fa-file-medical-alt" style="color:var(--accent); font-
size:10px;"></i> 
Результат аналізу 
</div> 
<div class="result-header"> 
<div class="result-code"> 
<div class="code-badge" id="res-code">P0300</div> 
<div class="code-sub">Діагностичний код несправності</div> 
</div> 
<div class="severity-badge"> 
<div class="sev-label" id="severity-badge">Критично</div> 
</div> 
</div> 
<div class="result-section"> 
<div class="result-section-title"> 
<i class="fas fa-info-circle"></i> Опис несправності 
</div> 
<p class="result-text" id="res-description"></p> 
</div> 
<div class="divider"></div> 
<div class="result-section" style="margin-top:18px;"> 
<div class="result-section-title"> 
<i class="fas fa-tools"></i> Рекомендації щодо усунення 
</div> 
<div class="advice-box"> 
<p id="res-advice"></p> 
</div> 
</div> 
</div> 
<footer> 
&copy; 2026 Макаріхін Олег Олегович &nbsp;·&nbsp; Дипломний проєкт 
</footer> 
</div> 
<!-- SIDEBAR OVERLAY --> 
<div class="sidebar-overlay hidden" id="sidebar-overlay" 
90 
482.ЧДТУ 262249 12 01 4 
onclick="closeSidebar()"></div> 
<!-- SIDEBAR --> 
<div class="sidebar hidden" id="sidebar"> 
<div class="sidebar-close" onclick="closeSidebar()"> 
<i class="fas fa-times"></i> 
</div> 
<!-- Гість --> 
<div id="sidebar-guest"> 
<div class="sidebar-logo"> 
<i class="fas fa-user-shield" style="color:var(--accent); font-size:28px;"></i> 
<div class="sidebar-title">Акаунт</div> 
<div class="sidebar-subtitle">Увійдіть або зареєструйтесь</div> 
</div> 
<div class="sidebar-tabs"> 
<button class="tab-btn active" id="tab-login" 
onclick="switchTab('login')">Вхід</button> 
<button class="tab-btn" id="tab-register" 
onclick="switchTab('register')">Реєстрація</button> 
</div> 
<!-- LOGIN --> 
<div id="form-login"> 
<div class="field"> 
<label>Email</label> 
<div class="input-wrap"> 
<input type="email" id="login-email" placeholder="[email protected]"> 
</div> 
</div> 
<div class="field"> 
<label>Пароль</label> 
<div class="input-wrap"> 
<input type="password" id="login-password" placeholder="••••••••"> 
</div> 
</div> 
<div class="sidebar-error hidden" id="login-error"></div> 
<button class="btn-primary" onclick="doLogin()"> 
<i class="fas fa-sign-in-alt"></i><span>Увійти</span> 
</button> 
</div> 
<!-- REGISTER --> 
<div id="form-register" class="hidden"> 
<div class="field"> 
<label>Email</label> 
<div class="input-wrap"> 
<input type="email" id="reg-email" placeholder="[email protected]"> 
</div> 
</div> 
<div class="field"> 
<label>Пароль</label> 
<div class="input-wrap"> 
<input type="password" id="reg-password" placeholder="Мінімум 6 символів"> 
</div> 
</div> 
<div class="field"> 
<label>Повторіть пароль</label> 
<div class="input-wrap"> 
<input type="password" id="reg-password2" placeholder="••••••••"> 
</div> 
91 
482.ЧДТУ 262249 12 01 5 
</div> 
<div class="sidebar-error hidden" id="reg-error"></div> 
<button class="btn-primary" onclick="doRegister()"> 
<i class="fas fa-user-plus"></i><span>Зареєструватись</span> 
</button> 
</div> 
</div> 
<!-- Авторизований --> 
<!-- Панель профілю (для авторизованого) --> 
<div id="sidebar-user" class="hidden"> 
<div class="sidebar-logo"> 
<div class="profile-circle" id="profile-circle">U</div> 
<div class="sidebar-title" id="profile-email-display">[email protected]</div> 
<div class="sidebar-subtitle" id="profile-since">Учасник з —</div> 
</div> 
<div class="profile-divider"></div> 
<div class="profile-info-row"> 
<i class="fas fa-envelope"></i> 
<div> 
<div class="info-label">Email</div> 
<div class="info-value" id="profile-email-val">—</div> 
</div> 
</div> 
<div class="profile-info-row"> 
<i class="fas fa-calendar-alt"></i> 
<div> 
<div class="info-label">Дата реєстрації</div> 
<div class="info-value" id="profile-date">—</div> 
</div> 
</div> 
<div class="profile-divider"></div> 
<!-- ІСТОРІЯ ПОШУКІВ --> 
<div class="history-section"> 
<div class="history-header"> 
<i class="fas fa-history" style="color:var(--accent);"></i> Історія пошуків 
</div> 
<div id="history-list"> 
<div class="history-empty">Історія порожня</div> 
</div> 
</div> 
<div class="profile-divider"></div> 
<button class="btn-logout" onclick="doLogout()"> 
<i class="fas fa-sign-out-alt"></i> Вийти з акаунту 
</button> 
</div> 
<script src="script.js"></script> 
</body> 
</html> 
Script.js 
const btn = document.getElementById('search-btn'); const input = 
document.getElementById('dtc-code'); 
const resultContainer = document.getElementById('result-container'); 
input.addEventListener('input', () => { input.value = input.value.toUpperCase(); 
92 
482.ЧДТУ 262249 12 01 6 
}); 
input.addEventListener('keydown', (e) => { if (e.key === 'Enter') btn.click(); 
}); 
btn.addEventListener('click', async () => { 
const code = input.value.trim().toUpperCase(); 
const brand = document.getElementById('car-brand').value; if (!code) { 
shake(input); return; } 
setLoading(true); 
try { 
const res = await fetch(`/api/check/${code}/${brand}`); const result = await 
res.json(); 
if (result.success) { renderResult(result.data); 
} else { 
showError(result.message); 
} 
} catch (err) { 
showError('Не вдалося підключитися до сервера.'); 
} finally { 
setLoading(false); 
} 
}); 
// ── Рендер результату ──────────────────────────────────────────────────────── 
function renderResult(data) { 
document.getElementById('res-code').textContent = data.code; 
document.getElementById('res-description').textContent = data.description; 
document.getElementById('res-advice').textContent = data.advice; 
const badge = document.getElementById('severity-badge'); const map = { 
0: { label: 'Несуттєво', cls: 'low' }, 
1: { label: 'Помірно', cls: 'medium' }, 
2: { label: 'Крити', cls: 'high' }, 
}; 
const sev = map[data.severity] ?? map[1]; badge.textContent = sev.label; 
badge.classNameчно = 'sev-label ' + sev.cls; 
resultContainer.classList.remove('hidden'); resultContainer.scrollIntoView({ 
behavior: 'smooth', block: 'nearest' }); 
// Зберігаємо в історію якщо користувач авторизований saveToHistory(data); 
} 
// ── Допоміжні функції ──────────────────────────────────────────────────────── 
function setLoading(on) { 
btn.disabled = on; btn.innerHTML = on 
? '<div class="spinner"></div><span>Аналіз...</span>' 
: '<i class="fas fa-microchip"></i><span>Запустити діагностику</span>'; 
} 
function shake(el) { 
el.style.borderColor = 'var(--accent)'; el.focus(); 
setTimeout(() => el.style.borderColor = '', 1200); 
} 
function showError(msg) { resultContainer.classList.add('hidden'); alert(msg); 
} 
// ── SIDEBAR ────────────────────────────────────────────────────────────────── 
93 
482.ЧДТУ 262249 12 01 7 
function openSidebar() { 
document.getElementById('sidebar').classList.remove('hidden'); 
document.getElementById('sidebar-overlay').classList.remove('hidden'); 
} 
function closeSidebar() { 
document.getElementById('sidebar').classList.add('hidden'); 
document.getElementById('sidebar-overlay').classList.add('hidden'); 
} 
function switchTab(tab) { 
document.getElementById('form-login').classList.toggle('hidden', tab !== 'login'); 
document.getElementById('form-register').classList.toggle('hidden', tab !== 
'register'); 
document.getElementById('tab-login').classList.toggle('active', tab === 'login'); 
document.getElementById('tab-register').classList.toggle('active', tab === 
'register'); 
} 
// ── АВТОРИЗАЦІЯ ────────────────────────────────────────────────────────────── 
function setLoggedIn(user) { 
document.getElementById('sidebar-guest').classList.add('hidden'); 
document.getElementById('sidebar-user').classList.remove('hidden'); 
const letter = user.email[0].toUpperCase(); 
const date = new Date(user.created_at).toLocaleDateString('uk-UA', { day: 
'numeric', month: 'long', year: 'numeric' 
}); 
document.getElementById('profile-circle').textContent = letter; 
document.getElementById('profile-email-display').textContent = user.email; 
document.getElementById('profile-since').textContent = `Учасник з 
${date}`; 
document.getElementById('profile-email-val').textContent = user.email; 
document.getElementById('profile-date').textContent = date; 
document.getElementById('btn-profile-label').textContent = 
user.email.split('@')[0]; 
// Завантажуємо історію loadHistory(); 
} 
function setLoggedOut() { 
document.getElementById('sidebar-guest').classList.remove('hidden'); 
document.getElementById('sidebar-user').classList.add('hidden'); 
document.getElementById('btn-profile-label').textContent = 'Увійти'; 
} 
async function doLogin() { 
const email = document.getElementById('login-email').value.trim(); const password 
= document.getElementById('login-password').value; const errEl = 
document.getElementById('login-error'); 
errEl.classList.add('hidden'); 
const res = await fetch('/api/login', { method: 'POST', 
headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ email, 
password }) 
}); 
const data = await res.json(); 
if (data.success) { setLoggedIn(data.user); closeSidebar(); 
} else { 
errEl.textContent = data.message; errEl.classList.remove('hidden'); 
94 
482.ЧДТУ 262249 12 01 8 
} 
} 
async function doRegister() { 
const email = document.getElementById('reg-email').value.trim(); const password = 
document.getElementById('reg-password').value; 
const password2 = document.getElementById('reg-password2').value; const errEl = 
document.getElementById('reg-error'); 
errEl.classList.add('hidden'); 
if (password !== password2) { 
errEl.textContent = 'Паролі не співпадають.'; errEl.classList.remove('hidden'); 
return; 
} 
const res = await fetch('/api/register', { method: 'POST', 
headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ email, 
password }) 
}); 
const data = await res.json(); 
if (data.success) { setLoggedIn(data.user); closeSidebar(); 
} else { 
errEl.textContent = data.message; errEl.classList.remove('hidden'); 
} 
} 
async function doLogout() { 
await fetch('/api/logout', { method: 'POST' }); setLoggedOut(); 
closeSidebar(); 
} 
// ── ІСТОРІЯ ПОШУКІВ 
─────────────────────────────────────────────────────────── async function 
saveToHistory(data) { 
try { 
await fetch('/api/history', { method: 'POST', 
headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ 
brand: data.brand, code: data.code, 
name: data.name, severity: data.severity, 
}) 
}); 
loadHistory(); 
} catch (err) { 
console.error('Помилка збереження історії:', err); 
} 
} 
async function loadHistory() { 
const container = document.getElementById('history-list'); if (!container) return; 
try { 
const res = await fetch('/api/history'); 
const data = await res.json(); 
if (!data.success || data.history.length === 0) { container.innerHTML = '<div 
class="history-empty">Історія 
порожня</div>'; 
return; 
} 
const sevMap = { 
95 
482.ЧДТУ 262249 12 01 9 
0: { label: 'Несуттєво', cls: 'low' }, 
1: { label: 'Помірно', cls: 'medium' }, 
2: { label: 'Критично', cls: 'high'}, 
}; 
container.innerHTML = data.history.map(item => { const sev = sevMap[item.severity] 
?? sevMap[1]; 
const date = new Date(item.searched_at).toLocaleDateString('uk-UA', 
{ 
day: 'numeric', month: 'short', hour: '2-digit', minute: '2-digit' 
}); 
return ` 
<div class="history-item" onclick="repeatSearch('${item.code}', '${item.brand}')"> 
<div class="history-top"> 
<span class="history-code">${item.code}</span> 
<span class="sev-label ${sev.cls}" style="font-size:10px; padding:2px 
8px;">${sev.label}</span> 
</div> 
<div class="history-name">${item.name || '—'}</div> 
<div class="history-meta"> 
<i class="fas fa-car" style="font-size:10px;"></i> 
${item.brand.toUpperCase()} 
&nbsp;·&nbsp; 
<i class="fas fa-clock" style="font-size:10px;"></i> ${date} 
</div> 
</div>`; 
}).join(''); 
} catch (err) { 
container.innerHTML = '<div class="history-empty">Помилка завантаження</div>'; 
} 
} 
function repeatSearch(code, brand) { document.getElementById('dtc-code').value = 
code; const select = document.getElementById('car-brand'); if 
([...select.options].some(o => o.value === brand)) { 
select.value = brand; 
} 
closeSidebar(); document.getElementById('search-btn').click(); 
} 
// ── Перевірка сесії при завантаженні ──────────────────────────────────────── 
(async () => { 
const res = await fetch('/api/me'); const data = await res.json(); 
if (data.success) setLoggedIn(data.user); 
})(); 
server.js 
const express = require('express'); const { Pool } = require('pg'); const bcrypt = 
require('bcrypt'); 
const session = require('express-session'); 
const app = express(); const PORT = 3000; 
// ── Підключення до PostgreSQL ──────────────────────────────────────────────── 
const pool = new Pool({ 
host: 'localhost', 
port:5432, 
user: 'postgres', password: 'postgre', database: 'drauto1', 
}); 
pool.connect() 
.then(() => console.log(' DataBase підключено успішно')) 
96 
482.ЧДТУ 262249 12 01 10 
.catch(err => console.error('Помилка підключення до БД:', err.message)); 
app.use(express.static( dirname)); app.use(express.json()); app.use(session({ 
secret: 'drauto_secret_key', resave: false, saveUninitialized: false, 
cookie: { maxAge: 1000 * 60 * 60 * 24 } 
})); 
// ── ДІАГНОСТИКА ────────────────────────────────────────────────────────────── 
app.get('/api/check/:code/:brand', async (req, res) => { 
const code = req.params.code.trim().toUpperCase(); const brand = 
req.params.brand.trim().toLowerCase(); 
try { 
const result = await pool.query( 
`SELECT * FROM dtc_codes WHERE code = $1 
AND (brand = $2 OR brand = 'generic') 
ORDER BY CASE WHEN brand = $2 THEN 0 ELSE 1 END LIMIT 1`, 
[code, brand] 
); 
if (result.rows.length === 0) { return res.status(404).json({ 
success: false, 
message: `Код ${code} не знайдено. Перевірте правильність коду або спробуйте 
"Загальний".` 
}); 
} 
const row = result.rows[0]; res.json({ 
success: true, data: { 
code: row.code, 
name:row.name, description: row.description, advice: row.advice, severity: 
row.severity, brand: row.brand, 
} 
}); 
}); 
} catch (err) { 
console.error('DB error:', err.message); 
res.status(500).json({ success: false, message: 'Помилка бази даних.' 
} 
}); 
// ── РЕЄСТРАЦІЯ ─────────────────────────────────────────────────────────────── 
app.post('/api/register', async (req, res) => { 
const { email, password } = req.body; 
if (!email || !password) { 
return res.status(400).json({ success: false, message: 'Заповніть всі поля.' }); 
} 
if (password.length < 6) { 
return res.status(400).json({ success: false, message: 'Пароль мінімум 6 символів.' 
}); 
} 
try { 
const existing = await pool.query('SELECT id FROM users WHERE email = 
$1', [email]); 
if (existing.rows.length > 0) { 
return res.status(409).json({ success: false, message: 'Цей email вже 
зареєстровано.' }); 
97 
482.ЧДТУ 262249 12 01 11 
} 
const hashed = await bcrypt.hash(password, 10); const result = await pool.query( 
`INSERT INTO users (email, password) VALUES ($1, $2) 
RETURNING id, email, created_at`, [email, hashed] 
); 
req.session.user = result.rows[0]; 
res.json({ success: true, user: result.rows[0] }); 
} catch (err) { 
console.error('Register error:', err.message); 
res.status(500).json({ success: false, message: 'Помилка сервера.' }); 
} 
}); 
// ── ВХІД ───────────────────────────────────────────────────────────────────── 
app.post('/api/login', async (req, res) => { 
const { email, password } = req.body; 
try { 
const result = await pool.query('SELECT * FROM users WHERE email = $1', [email]); 
if (result.rows.length === 0) { 
return res.status(401).json({ success: false, message: 'Невірний email або пароль.' 
}); 
} 
const user = result.rows[0]; 
const match = await bcrypt.compare(password, user.password); if (!match) { 
return res.status(401).json({ success: false, message: 'Невірний email або пароль.' 
}); 
} 
req.session.user = { id: user.id, email: user.email, created_at: user.created_at }; 
res.json({ success: true, user: req.session.user }); 
} catch (err) { 
console.error('Login error:', err.message); 
res.status(500).json({ success: false, message: 'Помилка сервера.' }); 
} 
}); 
// ── ВИХІД ──────────────────────────────────────────────────────────────────── 
app.post('/api/logout', (req, res) => { 
req.session.destroy(); res.json({ success: true }); 
}); 
// ── ПОТОЧНИЙ КОРИСТУВАЧ 
─────────────────────────────────────────────────────── app.get('/api/me', (req, 
res) => { 
if (!req.session.user) return res.status(401).json({ success: false }); res.json({ 
success: true, user: req.session.user }); 
}); 
// ── ЗБЕРЕГТИ ПОШУК ─────────────────────────────────────────────────────────── 
app.post('/api/history', async (req, res) => { 
if (!req.session.user) return res.status(401).json({ success: false }); 
const { brand, code, name, severity } = req.body; try { 
await pool.query( 
`INSERT INTO search_history (user_id, brand, code, name, severity) VALUES ($1, $2, 
$3, $4, $5)`, 
[req.session.user.id, brand, code, name, severity] 
98 
482.ЧДТУ 262249 12 01 12 
); 
res.json({ success: true }); 
} catch (err) { 
console.error('History save error:', err.message); res.status(500).json({ success: 
false }); 
} 
}); 
// ── ОТРИМАТИ ІСТОРІЮ ───────────────────────────────────────────────────────── 
app.get('/api/history', async (req, res) => { 
if (!req.session.user) return res.status(401).json({ success: false }); 
try { 
const result = await pool.query( 
`SELECT * FROM search_history 
WHERE user_id = $1 
ORDER BY searched_at DESC 
LIMIT 20`, 
[req.session.user.id] 
); 
res.json({ success: true, history: result.rows }); 
} catch (err) { 
console.error('History fetch error:', err.message); 
res.status(500).json({ success: false }); 
} 
}); 
app.listen(PORT, () => 
console.log(`Сервер запущено → http://localhost:${PORT}`) 
); 
99 
ДОДАТОК В 
«Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за 
кодами помилок» 
Інструкція користувачу 
482. ЧДТУ 26 2249 34 01
Листів 5 
Розробник  _____________ Макаріхін О.О. 
(підпис) (прізвище та ініціали) 
Черкаси 2026 
482. ЧДТУ 262249 34 01     2 
Для початку роботи з веб-сервісом для онлайн діагностики автомобілів за 
кодами помилок користувачу потрібно потрапити на головну сторінку (Рисунок 
В.1). 
 
 
Рисунок В.1 – Головна сторінка веб-додатку 
 
 
 
Для пошуку рішення помилки нам потрібно вписати DTC код (Рисунок 
В.2) та обрати марку авто (Рисунок В.3) з запропонованих варіантів. 
 
 
Рисунок В.2 – Приклад коду DTC 
 
 101 
482. ЧДТУ 262249 34 01 3 
Рисунок В.3 – Вибір марки автомобілю 
Після натискання кнопки «Запустити діагностику» система опрацьовує 
код та отримує з бази знань інформацію про способи усунення помилки 
(Рисунок В.4). Якщо відповідний код не знайдено, програма пропонує змінити 
тип коду на загальний (Generic) або повідомляє про відсутність такого DTC-
коду в базі 
Рисунок В.4 – Успішна обробка запиту 
102
482. ЧДТУ 262249 34 01 4 
Рисунок В.5 – Результат написання неправильного DTC коду 
Також користувач може зареєструватися за допомогою кнопки «Увійти» 
(Рисунок В.6). Після натискання кнопки входу зліва спливе сайдбар (Рисунок 
В.7), де користувач зможе зареєструватися або увійти у вже створений акаунт і 
отримати доступ до особистого кабінету для ефективнішого пошуку помилок. 
Після реєстрації або входу та подальшого пошуку помилок історія запитів 
зберігається в кабінеті користувача (Рисунок В.8), тож він може швидко знайти 
та перевірити попередні помилки, з якими стикався» 
Рисунок В.6 – Кнопка входу в профіль 
Рисунок В.7 – Вікно входу та реєстрації 
103
482. ЧДТУ 262249 34 01 5 
Рисунок В.8 – Історія пошуку користувача в особистому кабінеті 
104
ДОДАТОК Г 
 
 
 
 
 
 
 
 
«Розробка веб-сервісу для онлайн-діагностики автомобілів із пошуком за кодами 
помилок» 
 
 
 
 
Графічні матеріали 
482. ЧДТУ 262249 90 01 
Листів 14 
 
 
 
 
 
 
Розробник        Макаріхін О.О. 
(підпис)  (прізвище та ініціали) 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2026 
 
 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.1 – Тема роботи 
 
 
 
 
Рисунок Г.2 – Актуальність теми 
 
 
 106 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.3 – OBD codes 
 
 
 
 
 
Рисунок Г.4 – Car Scanner 
 
 107 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.5 – ALL Data 
 
 
Рисунок Г.6 – Засоби розробки 
 
 108 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.7 – Постановка задачі 
 
 
 
 
 
Рисунок Г.8 – Моделювання предметної області 
 
 109 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.9 – Вимоги до системи 
 
 
 
 
Рисунок Г.10 – Функціональні та нефункціональні вимоги 
 
 110 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.11 – Діаграма прецендентів 
 
 
 
 
 
Рисунок Г.12– Діаграма класів 
 
 111 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.13 – Діаграма пакетів 
 
 
 
 
 
Рисунок Г.14 – Діаграма компонентів 
 
 112 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.15 – Діаграма розгортання 
 
 
 
 
 
Рисунок Г.16 – Діаграма діяльності 
 
 113 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.17 – Діаграма послідовності 
 
 
 
 
Рисунок Г.18 – Діаграма комунікацій та скінченого автомата 
 
 114 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.19 – Структурна схема 
 
 
 
 
 
Рисунок Г.20 – Функціональна та логічна схема 
 
 
 
 
 
 
 115 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.21 – Er-діаграма 
 
 
 
 
Рисунок Г.22 – Результати тестування 
 
 116 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.23 – Відео роботи додатку 
 
 
 
 
Рисунок Г.24 – Висновки 
 
 117 
482. ЧДТУ 262249 90 01 
 
Рисунок Г.25 – Дякую 
 118