Розробка та оптимізація WEB-сервісу для пошуку рідкісних та цікавих автомобілів

Сергієнко, Олександр Сергійович
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9089
Повний запис метаданих
Поле DC	Значення	Мова
dc.contributor.advisor	Олексюк, Вадим Володимирович	-
dc.contributor.author	Сергієнко, Олександр Сергійович	-
dc.date.accessioned	2026-03-25T14:01:39Z	-
dc.date.available	2026-03-25T14:01:39Z	-
dc.date.issued	2024	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9089	-
dc.description.abstract	Сергієнко О.С. – «Розробка та оптимізація WEB-сервісу для пошуку рідкісних та цікавих автомобілів.» кваліфікаційні робота бакалавра з спеціальності 121 – « Інженерія програмного забезпечення » ЧДТУ, м.Черкаси 2024 рік. В даній кваліфікаційній роботі бакалавра розроблено веб-сервіс для пошуку рідкісних та цікавих автомобілів, який відповідає вимогам сучасного ринку та потребам користувачів. Веб-сервіс надає розширений пошуковий функціонал, що дозволяє користувачам швидко знаходити автомобілі за різними параметрами. Кожне оголошення містить детальну інформацію про автомобіль, технічні характеристики та контактні дані продавця. Основні функції включають також можливість взаємодії між покупцями та продавцями, зручний та інтуїтивно зрозумілий інтерфейс, що забезпечує комфортне використання для всіх категорій користувачів. Результатом роботи буде впровадження веб-сервісу, який стане необхідним інструментом для ефективної та зручної покупки та продажу автомобілів, сприяючи розвитку автомобільного ринку та задоволенню потреб його учасників.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	РІДКІСНІ АВТОМОБІЛІ	uk_UA
dc.subject	ПОШУК АВТОМОБІЛІВ	uk_UA
dc.subject	ВЕБ- СЕРВІС	uk_UA
dc.subject	ОНЛАЙН-ПЛАТФОРМА	uk_UA
dc.subject	ПРОДАЖ АВТОМОБІЛІВ	uk_UA
dc.subject	РОЗШИРЕНИЙ ПОШУК	uk_UA
dc.title	Розробка та оптимізація WEB-сервісу для пошуку рідкісних та цікавих автомобілів	uk_UA
dc.type	Bachelor Thesis	uk_UA
Розташовується у зібраннях:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Файли цього матеріалу:
Файл	Опис	Розмір	Формат
Bakalavr_Diplom_Serhienko_2024.pdf Restricted Access		50.69 MB	Adobe PDF	Переглянути/Відкрити Запит копії
Показати базовий опис матеріалу Перегляд статистики
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
   
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
 
 
На тему:  Розробка та оптимізація WEB-сервісу для пошуку рідкісних та 
цікавих автомобілів.  
 
 
Виконав: студент 4 курсу, групи ПЗ-2004 
спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Сергієнко О.С. 
 (прізвище та ініціали) 
Керівник Олексюк В.В. 
 (прізвище та ініціали) 
Рецензент Алесін О.В. 
 (прізвище та ініціали) 
 
 
 
 
 
 
 
 
Черкаси 2024 
 
 
 
 
 
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем  
Кафедра  програмного забезпечення автоматизованих систем  
Освітній рівень  бакалавр  
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення 
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
____________________ Голуб С.В. 
«___» ______________ 2024 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Сергієнко Олександр Сергійович 
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) Розробка та оптимізація WEB-сервісу для пошуку рідкісних та 
цікавих автомобілів.  
Керівник проекту (роботи) Олексюк Вадим Володимирович к.т.н.,старший викладач  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого 
2024 року №60/04 
2. Строк подання студентом проекту (роботи) 4 червня 2024р.   
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; 
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління 
ресурсами  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Вступ; 
Розділ 1. Теоретичний аналіз поняття веб-сервісу і особливості їх застосування;  
Розділ 2. Розробка концепції проекту;  
Розділ 3. Розробка та оптимізація WEB-сервісу для пошуку рідкісних та цікавих автомобілів. 
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Рисунок 2.4 – Діаграма прецедентів;  
Рисунок 2.5 – Діаграма класів;  
Рисунок 2.7 – Діаграма пакетів;  
Рисунок 2.8 – Діаграма компонентів;  
Рисунок 2.9 – Діаграма розгортання;  
Рисунок 2.10 – Діаграма комунікації;  
Рисунок 2.11 – Діаграма скінченного автомату.  
 
 
 
 
 
 
6. Консультанти розділів роботи 
 
Розділ Прізвище, ініціали та Підпис, дата 
 посади консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02 грудня 2023 р. 
 
КАЛЕНДАРНИЙ ПЛАН 
№ Строк виконання 
п/ Назва етапів випускної роботи етапів 
 
п кваліфікаційної Примітки 
 роботи 
1 Постановка задачі 05.12.2023 виконано 
2 Підготовка завдання 13.12.2023 виконано 
3 Погодження завдання 16.12.2023 виконано 
4 Затвердження завдання 19.02.2024 виконано 
 Основна стадія   
1 Підбір матеріалів 27.02.2024 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.02.2024 виконано 
3 Розрахунок основних параметрів роботи 10.03.2024 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2024 виконано 
5 Оформлення первісної редакції роботи 25.03.2024 виконано 
 Заключна стадія  виконано 
1 Узгодження прийнятих проектних рішень з 31.04.2024 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 13.05.2024 виконано 
кінцевій редакції 
3 Попередній захист роботи 15.05.2024 виконано 
4 Затвердження роботи 25.05.2024 виконано 
5 Рецензування роботи 30.05.2024 виконано 
6 Захист роботи 04.06.2024 виконано 
 
Студент _____________________   Сергієнко О.С. 
(підпис)   (прізвище та ініціали) 
 
Керівник роботи _____________________  Олексюк В.В. 
(підпис)   (прізвище та ініціали) 
 
 
 
 
 
 
 
АНОТАЦІЯ 
Сергієнко О.С. – «Розробка та оптимізація WEB-сервісу для пошуку 
рідкісних та цікавих автомобілів.» кваліфікаційні робота бакалавра з 
спеціальності 121 – « Інженерія програмного забезпечення » ЧДТУ, м.Черкаси 
2024 рік.  
В даній кваліфікаційній роботі бакалавра розроблено веб-сервіс для пошуку 
рідкісних та цікавих автомобілів, який відповідає вимогам сучасного ринку та 
потребам користувачів. Веб-сервіс надає розширений пошуковий функціонал, що 
дозволяє користувачам швидко знаходити автомобілі за різними параметрами. 
Кожне оголошення містить детальну інформацію про автомобіль, технічні 
характеристики та контактні дані продавця. 
Основні функції включають також можливість взаємодії між покупцями та 
продавцями, зручний та інтуїтивно зрозумілий інтерфейс, що забезпечує 
комфортне використання для всіх категорій користувачів. 
Результатом роботи буде впровадження веб-сервісу, який стане необхідним 
інструментом для ефективної та зручної покупки та продажу автомобілів, 
сприяючи розвитку автомобільного ринку та задоволенню потреб його учасників. 
Ключові слова: РІДКІСНІ АВТОМОБІЛІ, ПОШУК АВТОМОБІЛІВ, ВЕБ-
СЕРВІС, ОНЛАЙН-ПЛАТФОРМА, ПРОДАЖ АВТОМОБІЛІВ, РОЗШИРЕНИЙ 
ПОШУК. 
 
 
 
 
 
 
 
  
 
 
 
 
ANNOTATION  
Serhiienko O.S. – "Development and optimization of a WEB service for finding 
rare and interesting cars." Bachelor's qualifying work on specialty 121 – "Software 
engineering" ChSTU, Cherkasy, 2024. 
In this bachelor's thesis, a web service for finding rare and interesting cars was 
developed, which meets the requirements of the modern market and the needs of users. 
The web service provides advanced search functionality that allows users to quickly find 
cars by various parameters. Each ad contains detailed information about the car, 
technical specifications and contact details of the seller. 
The main functions also include the possibility of interaction between buyers and 
sellers, a convenient and intuitive interface that ensures comfortable use for all 
categories of users. 
The result of the work will be the implementation of a web service, which will 
become a necessary tool for the efficient and convenient purchase and sale of cars, 
contributing to the development of the automotive market and meeting the needs of its 
participants. 
Keywords: RARE CARS, CAR SEARCH, WEB SERVICE, ONLINE 
PLATFORM, CAR SALE, ADVANCED SEARCH. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Зміст 
Вступ .......................................................................................................................... 5 
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань ................ 7 
1.1 Аналіз способу вирішення задачі .................................................................... 7 
1.1.1 Визначення веб-сервісу ................................................................................. 7 
1.1.2 Як працюють веб-сервіси .............................................................................. 7 
1.1.3 Види веб-сервісів ........................................................................................... 8 
1.1.4 Опис архітектури RESTful веб-сервісу ....................................................... 9 
1.2 Аналіз існуючих аналогів .................................................................................. 11 
1.3 Специфікація вимог до розроблюваного веб-сервісу ..................................... 16 
Розділ 2 Впровадження результатів досліджень у практику проектування 
програмного забезпечення інформаційних систем ............................................... 19 
2.1 Моделювання предметної області .................................................................... 19 
2.1.1Предметна область моделювання. Модель предметної області. Словник 
предметної області .................................................................................................... 19 
2.1.2 Елементи моделювання предметної області ................................................. 21 
2.1.3 Робоча область моделювання  ........................................................................ 22 
2.2 Формування та аналіз вимог .............................................................................. 23 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги ........................................................................................................................ 23 
2.2.2 Формування вимог за допомогою діаграми прецедентів ............................ 26 
2.3 Проектування логічної структури програмного комплексу ........................... 28 
2.3.1 Діаграми класів ................................................................................................ 28 
2.3.2 Діаграми пакетів .............................................................................................. 32 
  
 
Змн Лист № докум. Підпис Дата ЧДТУ. 242058-011ПЗ 
Ро. зро б.  Сергієнко О.С.   «Розробка та оптимізація WEB- Літ. Лист Листів 
 Керівник  Олексюк В.В.    
 сервісу  для  пошуку  рідкісних  та   3  
   
 
Н.контр. Півень О.Б. цікавих  автомобілів..»    ФІІТІІС,,  ккаафееддрраа  ПЗЗАС,,  
 ПЗ-2004 
Затв.  Голуб С.В. Пояснювальна записка З-2004 
     
 
 
 
2.4 Архітектурне проектування ............................................................................... 33 
2.4.1 Діаграма компонентів ...................................................................................... 34 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ............................................................................................................... 35 
2.5 Моделювання поведінки системи ..................................................................... 36 
2.5.1 Діаграма діяльності ......................................................................................... 36 
2.5.2 Діаграма послідовності ................................................................................... 37 
2.5.3 Діаграма комунікації ....................................................................................... 39 
2.5.4 Діаграма скінченного автомату ...................................................................... 39 
Розділ 3. Розробка та тестування програмного забезпечення .............................. 42 
3.1 Розробка програмного комплексу ..................................................................... 42 
 3.1.1 Обґрунтування вибору засобів реалізації ..................................................... 42 
 3.1.2 Опис структурної (функціональної) схеми .................................................. 51 
 3.1.3 Опис логічної схеми системи ........................................................................ 52 
 3.1.4 Розробка бази даних ....................................................................................... 55 
 3.1.5 Розробка інтерфейсу користувача ................................................................. 59 
 3.1.6 Опис розробки програмних компонентів ..................................................... 64 
3.2 Тестування системи ............................................................................................ 66 
 3.2.1 Модульне тестування ..................................................................................... 66 
 3.2.2 Інтеграційне тестування ................................................................................. 67 
 3.2.3 Системне тестування ...................................................................................... 68 
 3.2.4 Приймальне тестування ................................................................................. 70 
3.3 Приклади впровадженого програмного комплексу ........................................ 72 
Висновки .................................................................................................................... 81 
Список використаних джерел .................................................................................. 82 
Додатки ...................................................................................................................... 85 
 
 
 Лист 
ЧДТУ. 242058-011ПЗ  4 
Зм Лист № докум. Підпис Дата 
 докум    
 
 
 
 
 
ВСТУП 
Актуальність теми викликана необхідністю розробки програмного 
забезпечення інформаційної технології пошуку рідкісних та цікавих автомобілів. 
Тому створення системи ПЗ, що дозволить користувачам легко та ефективно 
взаємодіяти з такою системою пошуку буде корисною та необхідною. 
Головна мета і завдання цієї кваліфікаційної бакалаврської роботи є 
розробка програмного забезпечення, яке забезпечить користувачам можливість 
швидкого та зручного пошуку автомобілів з унікальними характеристиками та 
історією.  
Для досягнення мети виконувались такі завдання. 
1 Визначити існуючі методи і засоби поставленої задачі. Аналіз 
результатів інформаційного пошуку. Формалізація поставлених задач. 
2 Вибрати і застосувати технології проектування ПЗ. 
3 Вибрати та застосувати конструювання ПЗ. 
4 Вибрати та застосувати технологію тестування ПЗ. 
5 Використати отримані результати в практику створення ІС. 
Об'єкт розробки  
Становить собою процес створення програмного забезпечення 
інформаційної технології для контекстного пошуку. 
Предметом розробки  
Є процес розробки програмного забезпечення для модуля пошуку цікавих 
та рідкісних автомобілів.  
Методи проектування та конструювання  
Для проектування було використано об’єктно орієнтований підхід до 
створення ІС. 
Мова програмування була обрана Python[9], що використовується для 
створення серверного середовища. Для серверного рішення використано Flask 
Framework [10], REST API, Flask-Security, SQLAlchemy та база даних PostgreSQL. 
Для клієнтської частини було використано HTML5, CSS, JavaScript, Bootstrap.  
Опис отриманих результатів  
 
 
 
В процесі розробки вдалось досягти прийнятих результатів що 
забезпечують досягнення мети. Було розроблено ІС для пошуку рідкісних та 
цікавих автомобілів. 
В процесі розробки були пройдені такі етапи як: 
- сформульовані вимоги до ПЗ; 
- спроектована база даних; 
- створено клієнтську частину для взаємодії із сервером; 
- створено серверну частину що забезпечує бізнес-логіку ІС. 
На основі спроектованого ПЗ було представлено діаграми, а в процесі 
тестування ІС було пройдено всі етапи що продемонструють виконання ПЗ 
відповідно до вимог що були представленні перед нею. 
Практичне значення досягнутих результатів  
Було побудовано програмну систему для пошуку рідкісних та цікавих 
автомобілів. Головною необхідністю при використанні системи є пристрій з 
доступом до мережі Інтернет та браузером. 
Особистий внесок автора  
В процесі розробки було застосовано об’єктно орієнтоване програмування 
що полегшило представлення бази даних та класів. Також у комплексному 
дослідженні сфери автомобільного ринку, аналізі потреб покупців та продавців 
автомобілів. Автор активно займався усіма етапами проекту, починаючи від 
вивчення вимог користувачів та аналізу конкурентного середовища, й 
завершуючи розробкою та тестуванням веб-сервісу.  
 
 
 
 
 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Веб-сервіс 
1.1.1 Визначення веб-сервісу 
Веб-сервіс це – ідентифікована веб-адресою програмна система зі 
стандартизованими інтерфейсами. Веб-служби можуть взаємодіяти один з одним 
і зі сторонніми додатками за допомогою повідомлень, заснованих на певних 
протоколах. У побуті веб-сервісами називають послуги, що надаються в Інтернеті. 
Розбір що таке веб-сервіси та їх види взяти на основі інформації з веб сайту 
[1]. 
У визначенні веб-сервісу вище згадано що основною метою веб-сервісу є 
надання послуг в Інтернеті. Моєю послугою є надання можливості пошуку 
рідкісних авто та зробити пошук зручним для користувача. 
Основні характеристики веб-сервісів: 
- доступність: доступні через інтернет з будь-якого місця та пристрою; 
- простота: використання не потребує знання спеціальних мов 
програмування; 
- масштабованість: легко масштабується для обробки великого 
навантаження; 
- гнучкість: застосовуються для різних завдань. 
 
1.1.2 Як працюють веб-сервіси 
Подальший опис як працюють веб-сервіси сформований на інформації 
поданій в джерелі[2]. 
Веб-сервіси дозволяють різним організаціям або програмам з різних джерел 
спілкуватися без необхідності обмінюватися конфіденційними даними чи ІТ-
інфраструктурою. Натомість уся інформація переміщується через програмний 
інтерфейс у мережі. Потім цей інтерфейс можна додати до графічного інтерфейсу, 
 
 
 
наприклад веб-сторінки, щоб надати користувачам певну функціональність. Це 
означає, що веб-сервіси не є специфічними для однієї мови програмування чи 
операційної системи (ОС) і не вимагають використання браузерів або мови 
гіпертекстової розмітки (HTML). 
Більшість веб-служб працюють за типовою поведінкою клієнт-сервер. 
Програма, яка працює на клієнтському комп’ютері або мобільному пристрої, має 
доступ до мережі, наприклад Інтернету. Сервер надає дані та обчислювальні 
можливості. 
Процес складається з трьох наступних кроків: 
- клієнт надсилає запит на сервер, який містить деталі та дані, необхідні 
веб-службі. дані можуть бути в будь-якому загальноприйнятому 
форматі, наприклад у javascript object notation (json) або xml; 
- сторона сервера отримує та автентифікує запит, аналізує необхідні 
деталі, обробляє запит і отримує доступ до будь-яких відповідних 
результатів; 
- сервер отримує доступ до будь-яких відповідних результатів і надсилає 
їх назад клієнтській програмі, яка відображає їх у формі та стилі, які 
відповідають програмі; 
Ключ до цього процесу полягає в тому, що клієнтська програма слабко 
пов’язана, тобто не має жодного зв’язку, із сервером або службами даних. Веб-
служба дозволяє клієнту спілкуватися з сервером. Як наслідок, багато програм, 
написаних незліченною кількістю розробників і компаній, можуть 
використовувати веб-служби для доступу до обчислювальних або даних. 
Прикладом таких клієнтських програм є веб-сайти, які використовують веб-
служби для доступу та відображення картографічних даних із основної служби, 
як-от Google Maps. Жоден із цих веб-сайтів не знає та не цікавиться, як працюють 
Google Maps. Це веб-служба, яка надає загальні засоби взаємодії з Google Maps 
для отримання даних Google Maps. 
 
 
 
 
1.1.3 Види веб-сервісів 
Веб-сервіси варіюються від основних послуг, таких як керування 
сховищами та управління взаємовідносинами з клієнтами, до більш обмежених 
послуг, таких як надання біржових котирування та перевірки ставок для предмета 
на аукціону. 
Користувачі можуть отримати доступ до деяких веб-служб через 
однорангову домовленість, а не через центральний сервер. Деякі служби можуть 
спілкуватися з іншими службами. Проміжне програмне забезпечення зазвичай 
забезпечує такий обмін процедурами та даними. Потреба у веб-сервісах виникла, 
оскільки всі основні платформи мали доступ до Інтернету, але різні платформи не 
могли взаємодіяти одна з одною. Веб-сервіси вивели платформи на новий рівень, 
опублікувавши функції, повідомлення, програми та об’єкти в решті Інтернету. 
Подальший аналіз видів веб-сервісів та твердження в цьому розділі 
сформовані на інформації поданій в джерелі [2]. 
Види веб-сервісів: 
- soap-based веб-сервіси: використовують протокол soap (simple object 
access protocol) для обміну повідомленнями; 
- restful веб-сервіси: використовують архітектурний стиль rest 
(representational state transfer) та протокол http для взаємодії з клієнтами; 
- xml-rpc веб-сервіси: використовують xml (extensible markup language) 
для обміну даними між клієнтом та сервером; 
- json-rpc веб-сервіси: використовують json (javascript object notation) для 
обміну даними між клієнтом та сервером; 
- graphql веб-сервіси: використовують мову запитів graphql для 
забезпечення гнучкості та ефективності у взаємодії з клієнтами; 
Веб-сервіс, який я розробляю, може бути класифікований як RESTful веб-
сервіс, оскільки він використовує принципи REST для створення ефективного та 
легкозрозумілого API для взаємодії з клієнтами. 
 
 
 
1.1.4 Опис архітектури RESTful веб-сервісу 
Опис архітектури RESTful заснований на джерелі [3]. 
RESTful API - це інтерфейс, що використовуються двома комп'ютерними 
системами для безпечного обміну інформацією через Інтернет. Більшість бізнес-
додатків повинні взаємодіяти з іншими внутрішніми та сторонніми програмами 
для виконання різних завдань. Наприклад, щоб генерувати щомісячні платіжні 
відомості, ваша внутрішня бухгалтерська система повинна обмінюватися даними 
з банківською системою вашого клієнта, щоб автоматизувати виставлення 
рахунків та взаємодіяти з внутрішнім додатком для обліку робочого часу. RESTful 
API підтримують такий обмін інформацією, оскільки вони дотримуються 
безпечних, надійних та ефективних стандартів програмної взаємодії. 
Архітектура RESTful (Representational State Transfer) - це стиль архітектури, 
який використовується для створення веб-сервісів, які пропонують 
стандартизовані інтерфейси та підтримують простоту, масштабованість та 
надійність.  
Основні принципи та властивості архітектури RESTful включають: 
- resources: ключовим поняттям в архітектурі restful є ресурси - це 
конкретні об'єкти або дані, які можуть бути доступні через api. кожен 
ресурс має свій унікальний ідентифікатор, який використовується для 
доступу до нього; 
- uri (uniform resource identifier): кожен ресурс ідентифікується за 
допомогою uri, який є унікальним ідентифікатором ресурсу. uri 
використовується для адресації ресурсів та виконання операцій з ними; 
- http methods: restful використовує стандартні http методи, такі як get, post, 
put, patch та delete, для виконання операцій з ресурсами. наприклад, get 
використовується для отримання ресурсу, а post - для створення нового 
ресурсу; 
 
 
 
- representation of resources: ресурси можуть мати різні представлення, такі 
як json, xml або html. клієнти можуть вибирати представлення, яке 
найбільше відповідає їхнім потребам; 
- statelessness: сервер не зберігає жодної інформації про стан клієнта між 
запитами. кожен запит вважається незалежним і не залежить від 
попередніх запитів; 
- caching: система може використовувати кешування для збереження 
ресурсів на стороні клієнта або проксі-сервера для покращення 
продуктивності та зниження навантаження на сервер; 
- uniform interface: всі ресурси використовують однорідний інтерфейс для 
взаємодії з ними, що спрощує розробку та розуміння api; 
- layered system: клієнти не мають інформації про внутрішню структуру 
системи та можуть взаємодіяти з різними рівнями абстракції; 
- code on demand: сервер може надсилати клієнту код для виконання на 
його стороні, що розширює функціональність клієнтської програми. 
Архітектура RESTful надає зручний та ефективний спосіб створення веб-
сервісів, які можуть взаємодіяти з різними клієнтами та пристроями через 
Інтернет. Цей підхід дозволяє створювати розширювані та гнучкі системи, які 
легко масштабуються та підтримуються. 
1.2 Аналіз існуючих аналогів 
Виходячи з мети та завдань роботи було проаналізовано аналогічні 
застосунки, а також існуючі рішення та веб-технології. Основним аналогом 
подібної системи є Autoria. Сервіс надає можливість користувачам легко шукати 
транспорті засоби залежно від їх вподобань. Крім того, за бажанням, користувач 
може обрати вид транспортного засобу. На сайті існує система розширеного 
пошуку який відображається на іншій сторінці (рис. 1.1). Також, на головній 
сторінці представлені авто які можуть зацікавити користувача (рис. 1.2). 
 
 
 
 
Рисунок 1.1 – Інтерфейс розширеного пошуку  
 
 
 
 
Рисунок 1.2 – Головна сторінка Autoria 
 
Таблиця 1.1    
Опис аналогу Auto.ria 
Назва Autoria 
Архітектура 3tier web application 
Розробник Приватна компанія 
Мова JavaScript,Python 
розробки 
Переваги Велика база даних автомобілів 
Зручний пошук 
Широкий спектр функцій 
Висока популярність 
 
Недоліки Не фокусується на рідкісних та цікавих автомобілях 
Складний інтерфейс 
Наявність реклами 
Веб-сайт https://auto.ria.com/uk/ 
 
 
 
Ще одним з аналогів подібної системи є сайт RST. Це сервіс як autoria надає 
можливість користувачам легко шукати авто, але сайт не має розширеного 
пошуку і це зменшує ефективний та точний пошук рідкісного транспорту (рис. 
1.3). 
  
 
Рисунок 1.3 – Головна сторінка RST 
 
Таблиця 1.2    
Опис аналогу RST 
Назва RST 
Архітектура 3tier web application 
Розробник Приватна компанія 
Мова розробки JavaScript,Python 
Переваги Широкий вибір автомобілів 
Зручний пошук 
Можливість зв'язатися з продавцем 
Відгуки про продавців 
 
 
 
 
 
Продовження таблиці 1.2 
Недоліки Немає можливості перевірити історію автомобіля 
Пошук не має достатньої кількості фільтрів для 
ефективного пошуку рідкісного авто 
Наявність реклами 
Можуть бути шахраї 
Веб-сайт https://rst.ua/ukr/ 
 
Також аналогом подібної системи є сайт OLX так як крім продажу різних 
речей він має розділ для пошуку авто. Цей розділ для пошуку має більший фільтр 
пошуку авто ніж RST для того щоб легко шукати авто, але сайт має погану 
оптимізацію та пошук часто працює неправильно. Фільтр є зручним в 
використанні та має мінімалістичний вигляд.(рис. 1.4). 
 
 
Рисунок 1.4 – Головна сторінка розділу для пошуку авто на OLX 
 
 
 
Таблиця 1.3    
Опис аналогу OLX 
Назва OLX 
Архітектура 3tier web application 
Розробник Приватна компанія 
Мова розробки JavaScript,Python 
Переваги Великий вибір автомобілів 
Можливість зв'язатися з продавцем 
Відгуки про продавців 
Детальна інформація про автомобілі 
Недоліки Немає можливості перевірити історію автомобіля 
Пошук не має достатньої кількості фільтрів для ефективного 
пошуку рідкісного авто 
Наявність реклами 
Можуть бути шахраї 
Недостатній контроль якості 
Веб-сайт https://www.olx.ua/uk/transport/legkovye-avtomobili/ 
 
1.3 Специфікація вимог до розроблюваного веб-сервісу 
Веб-сервіс, що розробляється представляє собою веб-сайт для пошуку 
рідкісних та цікавих авто. Сервіс призначений для користувачів, які бажають 
знайти рідкісні авто, але не можуть цього зробити через те, що не знають де їх 
шукати. 
Основні ролі користувачів: 
– гість – звичайний користувач який може шукати авто користуючись 
пошуком, зареєструватися в системі, дод/підписку на повідомлення про 
надходження товару; 
– адміністратор – користувач з повним набором прав доступу, який має ті 
самі можливості, що і гість, але крім того, може редагувати контент 
сайту, додавати та видаляти авто, керувати коментарями.  
Функціональні вимоги: 
- можливість пошуку автомобілів за різними критеріями, такими як 
марка, модель, рік випуску, ціновий діапазон тощо; 
- фільтрація результатів пошуку за різними параметрами; 
 
 
 
- перегляд детальної інформації про кожен автомобіль, включаючи 
фотографії, характеристики, історію обслуговування та власності; 
- можливість додавання оголошень про продаж автомобілів; 
- реєстрація та авторизація користувачів; 
- можливість відправки повідомлень між користувачами для обговорення 
деталей продажу або питань щодо автомобілів. 
 
Нефункціональні вимоги: 
- швидкодія: система повинна бути швидкою та ефективною в обробці 
запитів користувачів; 
- масштабованість: здатність системи масштабуватися для обробки 
зростаючої кількості користувачів та даних; 
- безпека: захист особистих даних користувачів, безпечне зберігання та 
передача інформації; 
- надійність: система повинна бути надійною та стабільною, без відмов та 
збоїв в роботі; 
- доступність: сервіс повинен бути доступний для користувачів з різних 
географічних місць та забезпечувати швидкий доступ до інформації про 
автомобілі. 
 
Інтеграційні вимоги: 
- api для інтеграції з іншими системами: забезпечення можливості 
інтеграції з іншими сервісами або додатками, наприклад, платіжними 
системами або соціальними мережами; 
- механізми аутентифікації та авторизації: інтеграція з механізмами 
аутентифікації користувачів та забезпечення доступу до захищених 
ресурсів; 
 
Вимоги до інтерфейсу користувача: 
 
 
 
- зручний та інтуїтивно зрозумілий інтерфейс: Розробка зручного та 
легкого в користуванні інтерфейсу для швидкого пошуку та перегляду 
інформації про автомобілі; 
Ці вимоги допоможуть забезпечити створення веб-сервісу, який 
задовольнить потреби користувачів у пошуку рідкісних та цікавих автомобілів, 
забезпечуючи високу якість обслуговування та безпеку даних. 
 
 
 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі дослідив що таке веб-сервіс та які його є види. Провів 
аналіз існуючих аналогів який підкреслив важливість розробки нового веб-
сервісу, який би відповідав потребам сучасних автолюбителів та забезпечував їм 
зручний та швидкий доступ до інформації про цікаві та рідкісні автомобілі. 
Отримані результати підтвердили актуальність нашого дослідження і 
відзначили попит на зручний та ефективний інструмент для пошуку рідкісних 
автомобілів. На підставі проведеного аналізу визначено основні вимоги до веб-
сервісу. Розробка такого сервісу має великий потенціал для задоволення потреб 
користувачів та сприяння розвитку автомобільної індустрії. 
Загалом, результати першого розділу підкреслюють необхідність 
подальшого вивчення та розробки веб-сервісу для пошуку рідкісних та цікавих 
автомобілів, що є актуальним та перспективним напрямком в сучасній 
інформаційній технології. 
 
 
 
 
 
 
 
 
 
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
2.1 Моделювання предметної області 
Моделювання предметної області є невід'ємною частиною процесу 
розробки веб-сервісу для пошуку рідкісних та цікавих автомобілів. Це 
дозволить створити логічну та структуровану модель системи, визначити її 
основні компоненти, їх взаємодію та функціональність. На основі цієї моделі 
можна буде ефективно планувати та реалізовувати систему, зменшуючи ризик 
помилок та забезпечуючи високу якість кінцевого продукту. 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області  
Предметна область моделювання в даному проекті охоплює всі аспекти 
створення веб-сервісу для пошуку рідкісних та цікавих автомобілів. Цей веб-
сервіс дозволяє користувачам здійснювати пошук автомобілів за різними 
критеріями, переглядати детальну інформацію про автомобілі, зв'язуватися з 
продавцями та керувати своїми акаунтами. 
Основними елементами предметної області є користувачі, автомобілі, 
продавці та повідомлення. Кожен з цих елементів має свої атрибути та функції, 
які забезпечують повноцінну роботу системи. Важливими аспектами предметної 
області є забезпечення безпеки даних, швидкий пошук та відображення 
інформації, а також підтримка зручного та інтуїтивного інтерфейсу користувача. 
 Модель предметної області 
Модель предметної області описує структуру даних та взаємодію між 
основними компонентами системи. Нижче представлена узагальнена модель 
предметної області у вигляді класів: 
1 Користувач (User); 
2 Автомобіль (Car); 
3 Продавець (Seller); 
 
 
 
4 Повідомлення (Message). 
Словник предметної області 
Словник предметної області містить визначення основних термінів, що 
використовуються в моделі: 
Користувач (User): Особа, яка використовує веб-сервіс. Користувачі можуть 
бути зареєстрованими (з правами доступу до персоналізованих функцій) або 
незареєстрованими. 
Автомобіль (Car): Основний об'єкт системи, що містить всю необхідну 
інформацію про транспортний засіб, який можна знайти через веб-сервіс. 
Продавець (Seller): Особи або організації, що пропонують автомобілі на 
продаж через веб-сервіс. Продавці мають свої контактні дані, які зберігаються в 
системі. 
Повідомлення (Message): Звернення користувачів до системи або до 
продавців, що містять текстову інформацію (запитання, пропозиції, коментарі). 
 
 
Рисунок 2.1 – Основні графічні символи UML[30] 
 
 
 
 
 
Рисунок 2.2 – Єднальні елементи UML[30] 
 
 
Рисунок 2.3 – Модель предметної області представлена діаграмою класів 
 
2.1.2 Елементи моделювання предметної області  
Елементи моделювання предметної області включають користувачів, 
автомобілі, продавців та повідомлення, кожен з яких відображає важливі аспекти 
веб-сервісу для пошуку рідкісних та цікавих автомобілів. Користувачі є 
ключовими акторами, які взаємодіють із системою, маючи можливість шукати, 
переглядати та взаємодіяти з автомобілями. Автомобілі представляють собою 
об'єкти, які можуть бути знайдені та переглянуті користувачами, і мають різні 
характеристики, такі як марка, модель, ціна тощо. 
 
 
 
Продавці виступають як постачальники автомобілів та забезпечують 
інформацію про автомобілі, що їх продають. Кожен продавець має свій 
унікальний ідентифікатор та контактні дані. Повідомлення дозволяють 
користувачам спілкуватися між собою або з продавцями для отримання 
додаткової інформації про автомобілі або узгодження умов угоди. 
Ці елементи разом утворюють модель предметної області, яка визначає 
основні сутності та їх взаємозв'язки у системі. Вони служать основою для 
розробки функціональності та структури веб-сервісу, що допомагає користувачам 
знаходити та взаємодіяти з рідкісними та цікавими автомобілями в онлайн 
середовищі. 
2.1.3 Робоча область моделювання  
Для використання веб-сервісом для пошуку авто не є обов’язковим 
авторизація. Він може перейти на головну сторінку, де може здійснювати 
різноманітні дії. Однією з цих дій є перехід на сторінку "Cars", де користувач 
може скористатися фільтрами для пошуку автомобілів за різними 
характеристиками, такими як марка, модель, ціна, рік випуску тощо. 
Після використання фільтра користувач отримує результати пошуку, які 
відображаються на екрані. Користувач може переглянути список автомобілів, які 
відповідають його критеріям пошуку, та переходить до подальшого дослідження 
кожного автомобіля. 
Обравши конкретний автомобіль, користувач може переглянути детальну 
інформацію про нього та контактувати з продавцем. Зазвичай на сторінці деталей 
автомобіля вказані контактні дані продавця, такі як електронна пошта або номер 
телефону, за допомогою яких користувач може зв'язатися з ним для отримання 
додаткової інформації або узгодження умов покупки. 
Таким чином, робоча область моделювання охоплює весь процес від 
пошуку автомобілів до контакту з продавцем, забезпечуючи зручність та 
ефективність взаємодії користувачів з веб-сервісом. 
2.2 Формування та аналіз вимог  
 
 
 
Аналіз вимог - це процес розгляду потреб і цілей користувачів, їх 
класифікації та перетворення на конкретні вимоги до системи, обладнання та 
програмного забезпечення. Це також включає встановлення та вирішення 
конфліктів між вимогами, визначення пріоритетів, меж системи та принципів 
взаємодії з оточуючим середовищем. Це визначення взято з основане на 
джерелі[4]. 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги 
Формування загальних вимог до ПЗ складається з формування первинних і 
детальних вимог, які ми перерахуємо нижче. При розробці веб-сервісу для 
пошуку рідкісних та цікавих автомобілів важливо визначити і сформулювати 
первинні вимоги, які зможуть відобразити основні функціональні та 
нефункціональні вимоги для розроблюваного проекту. Виділимо загальні 
первинні вимоги, які виникають при створенні веб-сервісу: 
1 Авторизація та аутентифікація користувачів: Сервіс повинен 
забезпечити можливість реєстрації та входу користувачів, а також 
перевірку їх ідентифікації для забезпечення безпеки і доступу до 
особистої інформації.  
2 Пошук автомобілів: Користувач повинен мати можливість швидко та 
зручно здійснювати пошук автомобілів за різними критеріями, такими 
як марка, модель, ціновий діапазон, рік випуску тощо.  
3 Перегляд деталей автомобіля: Кожен знайдений автомобіль повинен 
мати сторінку з детальною інформацією, яка включає фотографії, 
технічні характеристики та контактні дані продавця.  
4 Зв'язок з продавцем: Сервіс повинен забезпечити можливість зв'язку 
користувача з продавцем для отримання додаткової інформації про 
автомобіль або узгодження умов покупки.  
 
 
 
5 Адаптивний дизайн: Веб-сервіс повинен мати адаптивний дизайн, що 
дозволяє користувачам зручно переглядати і використовувати його на 
різних пристроях, включаючи комп'ютери, планшети та смартфони. 
6 Безпека даних: Сервіс повинен забезпечити захист конфіденційної 
інформації користувачів, включаючи їх особисті дані та історію пошуку, 
від несанкціонованого доступу та зловживання. 
7 Відгук: Користувачі повинні мати можливість залишати відгуки, що 
допомагає іншим адміністраторам покращити веб-сервіс. 
Вимоги замовника та розробника можуть виявитися різними за своєю 
природою та акцентами. Ось ключові вимоги, які можуть бути визначені з 
кожного боку: 
Вимоги замовника: 
1 Функціональність: Замовник може визначити функціональні вимоги 
щодо того, які конкретні можливості повинен мати веб-сервіс. Це може 
включати можливість швидкого та зручного пошуку автомобілів, 
можливість зв'язку з продавцями, можливість фільтрації результатів 
тощо. 
2 Дизайн та користувацький досвід: Замовник може висунути вимоги 
щодо дизайну веб-сайту та користувацького досвіду, наприклад, вимоги 
до адаптивності до різних пристроїв, зручності навігації, естетичного 
вигляду тощо. 
3 Безпека і конфіденційність: Замовник може мати вимоги щодо захисту 
даних користувачів, забезпечення безпеки платежів та транзакцій, а 
також захисту від кібератак. 
Вимоги розробника: 
1 Технічні вимоги: Розробник може визначити технічні вимоги до 
програмного забезпечення, такі як використання певних технологій та 
інструментів розробки, структура бази даних, архітектура веб-сервісу 
тощо. 
 
 
 
2 Продуктивність та масштабованість: Розробник може встановити 
вимоги щодо продуктивності веб-сервісу, такі як час відповіді на запити 
користувачів, швидкість завантаження сторінок та масштабованість 
системи для обробки великої кількості запитів. 
3 Сумісність та тестування: Розробник може вимагати забезпечення 
сумісності веб-сервісу з різними веб-браузерами та операційними 
системами, а також вимоги до тестування, включаючи автоматизовані 
тести, модульне тестування та тестування безпеки. 
Функціональні вимоги визначають, як система повинна працювати, які 
функції вона повинна виконувати. Функціональні вимоги для веб-сервісу пошуку 
автомобілів: 
1 Реєстрація та авторизація користувачів: Система повинна забезпечити 
можливість реєстрації нових користувачів і авторизації вже 
зареєстрованих користувачів. 
2 Пошук автомобілів: Користувачі повинні мати можливість здійснювати 
пошук автомобілів за різними критеріями, такими як марка, модель, рік 
випуску, ціновий діапазон тощо. 
3 Перегляд деталей автомобіля: Після пошуку користувач повинен мати 
можливість переглядати детальну інформацію про кожен знайдений 
автомобіль, таку як характеристики, фотографії, контактні дані 
продавця. 
4 Контактування з продавцем: Система повинна надати засоби для 
зручного зв'язку користувача з продавцем автомобіля, наприклад, через 
електронну пошту або телефон. 
5 Управління оголошеннями: Користувачі, які розмістили оголошення 
про продаж автомобіля, повинні мати можливість редагувати, 
оновлювати або видаляти свої оголошення. 
Нефункціональні вимоги описують якісні характеристики системи та 
вимоги до її реалізації. Ось деякі нефункціональні вимоги для веб-сервісу пошуку 
автомобілів: 
 
 
 
1 Продуктивність: Система повинна бути швидкою та ефективною, з 
низьким часом завантаження сторінок та швидким відгуком на запити 
користувачів. 
2 Безпека: Забезпечення безпеки особистих даних користувачів та захист 
від кібератак, включаючи шифрування даних та використання захисних 
механізмів. 
3 Надійність: Система повинна бути надійною та стабільною, без збоїв або 
відмов в роботі. 
4 Сумісність: Система повинна бути сумісною з різними веб-браузерами 
та пристроями, забезпечуючи однакову якість користувацького досвіду 
для всіх користувачів. 
5 Інтерфейс: Користувацький інтерфейс системи повинен бути зручним та 
інтуїтивно зрозумілим, забезпечуючи комфортну навігацію та взаємодію 
з користувачем. 
Ці функціональні та нефункціональні вимоги є важливими для успішного 
проектування та реалізації веб-сервісу для пошуку автомобілів. 
2.2.2 Формування вимог за допомогою діаграми прецедентів  
Діаграма прецедентів (Рисунок 2.4) відображає різноманітні сценарії 
взаємодії між акторами (користувачами) та прецедентами (випадками 
використання). Вона служить для опису функціональних аспектів системи, 
включаючи бізнес-логіку. 
Діаграми прецедентів є важливим інструментом не лише для комунікації 
між збирачами вимог та користувачами, але й як джерельна інформація для 
учасників розробки проекту на всіх його етапах. Вони містять детальні 
специфікації прецедентів, які можуть легко перетворитися на тестові випадки. 
Елементи діаграми прецедентів включають: 
- акторів – користувачів; 
- прецеденти - випадки використання, дії, позначені овалами; 
 
 
 
- граничні межі системи, що охоплюють всі випадки використання, 
позначені прямокутниками; 
Визначення та опис діаграми прецедентів на основі джерела [15]. 
 
 
Рисунок 2.4 – Діаграма прецедентів 
 
2.3 Проектування логічної структури програмного комплексу 
Створення логічної структури програмного комплексу полягає у 
визначенні взаємозв'язків між різними компонентами програми для досягнення 
певного функціонального або бізнесового мети. Цей процес включає в себе 
розробку концептуальної схеми програми, яка визначає, як дані та операції 
пов'язані між собою. 
2.3.1 Діаграми класів 
 
 
 
Діаграми класів – це форма структурної діаграми, яка використовується 
для моделювання об'єктно-орієнтованих систем. Вони демонструють класи, їх 
атрибути, методи та зв'язки між класами. Діаграми класів дозволяють розглядати 
систему на рівні окремих компонентів і розуміти, як вони взаємодіють між 
собою. 
Діаграми класів широко використовуються у розробці програмного 
забезпечення, і основні їх застосування включають такі: 
1 Моделювання системи: Діаграми класів допомагають розглянути 
складну систему як сукупність окремих компонентів і визначити 
взаємозв'язки між ними. Це допомагає розробникам отримати загальне 
уявлення про структуру системи. 
2 Проектування системи: Діаграми класів використовуються для 
проектування об'єктно-орієнтованих систем, допомагаючи визначити 
необхідні класи, їх атрибути та методи перед початком фази реалізації. 
3 Аналіз системи: Діаграми класів допомагають зрозуміти, як система 
працює, та виявити можливі проблеми або невідповідності у структурі 
системи. 
Означення що таке діаграма класів та застосування описане за допомогою 
джерела[6]. 
Ця діаграма класів (Рисунок 2.5) відображає структуру моделі предметної 
області для веб-сервісу пошуку рідкісних та цікавих автомобілів. Основний клас 
FlaskApp представляє додаток Flask, який управляє основною логікою та 
підключенням до бази даних. У цьому класі знаходяться ряд атрибутів, таких як 
з'єднання з базою даних та дані для підключення. 
Крім того, діаграма включає класи для кожної сутності в системі: User, Car, 
Seller та Message. Кожен з цих класів має атрибути, які відображають 
характеристики відповідної сутності. Наприклад, клас Car містить атрибути, що 
описують різні характеристики автомобіля, такі як марка, модель, тип кузова 
тощо. 
 
 
 
Діаграма також відображає зв'язки між класами, вказуючи, що клас 
FlaskApp управляє різними сутностями, такими як користувачі, автомобілі, 
продавці та повідомлення. Це вказує на те, що додаток взаємодіє з цими класами 
для виконання різних операцій, таких як збереження даних, відображення 
сторінок тощо. 
 
 
 
Рисунок 2.5 – Діаграма класів 
 
Тепер розпишемо логіку наповнення даної діаграми (Рисунок 2.6). 
User (Користувач): 
- username: str — ім'я користувача; 
- password: str — пароль користувача; 
- role: str — роль користувача (наприклад, адміністратор або звичайний 
користувач); 
CarBrand (Бренд автомобіля): 
- brand_id: int — унікальний ідентифікатор бренду; 
- brand_name: str — назва бренду; 
CarModel (Модель автомобіля): 
- model_id: int — Унікальний ідентифікатор моделі; 
- brand_id: int — Ідентифікатор бренду, до якого належить модель; 
- car_model: str — Назва моделі автомобіля; 
- body_type: str — Тип кузова; 
- number_doors: int — Кількість дверей; 
 
 
 
- price_range: float — Ціновий діапазон; 
- year: int — Рік випуску; 
- mileage: int — Пробіг автомобіля; 
- transmission: str — Тип трансмісії; 
- fuel_type: str — Тип палива; 
- color: str — Колір автомобіля; 
- technical_condition: str — Технічний стан; 
- customs_cleared: bool — Митне оформлення; 
- driven_from: str — Звідки пригнаний автомобіль; 
- engine_size: float — Об'єм двигуна; 
- engine_name: str — Назва двигуна; 
- engine_hp: int — Кінські сили двигуна; 
- location: str — Місцезнаходження автомобіля; 
- seller_id: int — Ідентифікатор продавця. 
Seller (Продавець): 
- seller_id: int — Унікальний ідентифікатор продавця; 
- seller_name: str — Ім'я продавця; 
- seller_email: str — Електронна пошта продавця; 
- seller_phone: str — Телефон продавця; 
- seller_location: str — Місцезнаходження продавця. 
Message (Повідомлення): 
- name: str — Ім'я відправника повідомлення; 
- subject: str — Тема повідомлення; 
- message: str — Текст повідомлення. 
Взаємозв’язки між класами 
- User "1" -- "many" CarModel: Користувач може переглядати багато 
моделей автомобілів; 
- User "1" -- "many" Message: Користувач може надсилати багато 
повідомлень; 
 
 
 
- CarBrand "1" -- "many" CarModel: Один бренд може мати багато 
моделей автомобілів; 
- Seller "1" -- "many" CarModel: Один продавець може продавати багато 
моделей автомобілів. 
 
 
Рисунок 2.6 – Діаграма класів з наповненням атрибутами 
 
2.3.2 Діаграми пакетів 
Діаграма пакетів - це тип діаграми, який використовується для візуалізації 
структури програмного забезпечення шляхом групування його компонентів у 
логічні пакети або модулі. Кожен пакет представляє собою колекцію класів, 
інтерфейсів або інших елементів програми, які мають спільний функціонал або 
пов'язані між собою. Діаграми пакетів допомагають візуально організувати 
програму, щоб полегшити розуміння та управління її складовими частинами. 
 
 
 
Ця діаграма (Рисунок 2.7) пакетів відображає зв'язки між різними 
компонентами проекту веб-сервісу для пошуку рідкісних та цікавих 
автомобілів. 
- пакети Views, Models, API Endpoints та Utilities взаємодіють один з 
одним через стрілочки, що вказують на залежності між ними. 
- Views використовує компоненти з пакетів Models, API Endpoints та 
Utilities для відображення веб-сторінок та обробки даних. 
- Models та API Endpoints взаємодіють з базою даних, яка представлена 
в пакеті Database. 
- Utilities надає різноманітні допоміжні функції, які можуть 
використовуватись іншими компонентами проекту. 
 
 
Рисунок 2.7 – Діаграма пакетів 
 
 
 
 
2.4 Архітектурне проектування  
Архітектурне проектування описує перший етап процесу розробки, на 
якому визначаються підсистеми, управління структурою та їх взаємодія. Основна 
мета полягає в створенні опису архітектури програмного забезпечення, що 
служить містком між процесом проектування та розробки вимог до системи. 
Існують різні підходи до архітектурного проектування, які варіюються в 
залежності від досвіду та інтуїції розробників. Однак, можна виділити кілька 
загальних етапів для всіх процесів архітектурного проектування. 
- структурування: представлення системи як сукупності незалежних 
підсистем та визначення їх взаємодії; 
- моделювання управління: розроблення базової моделі управління 
взаємодіями між компонентами системи; 
- модульна декомпозиція: розділення підсистеми на окремі модулі, 
визначення їх типів та взаємозв'язків. 
Визначення архітектурного проектування основане на джерелі [7]. 
2.4.1 Діаграма компонентів 
Діаграма компонентів  надає концептуальне уявлення про взаємодію різних 
систем. Вона може описувати як логічні, так і фізичні аспекти моделювання, і 
компоненти в ній є автономними. Ці елементи є модульними та можуть бути 
замінені альтернативними. Вони містять будь-які конструкції складності та є 
самодостатніми, а їх взаємодія з іншими компонентами відбувається лише через 
інтерфейси. Крім того, компоненти мають власні інтерфейси, але можуть 
взаємодіяти з операціями та службами інших компонентів за допомогою їхніх 
інтерфейсів. На діаграмах компонентів інтерфейси відображають зв'язки та 
залежності в архітектурі програмного забезпечення. 
Визначення діаграми компонентів сформовано за допомогою джерела [8]. 
 
 
 
У цій діаграмі компонентів (Рисунок 2.8) веб-сервісу для пошуку 
автомобілів відображені основні компоненти та їх взаємозв'язки:  
- користувач за допомогою браузера взаємодіє з веб-сервісом, 
відправляючи HTTP-запити. 
- FlaskApp отримує запити від браузера та взаємодіє з базою даних для  
отримання необхідної інформації. 
- компонент SearchPage відповідає за відображення сторінки пошуку 
автомобілів, де користувач може використовувати фільтри. 
- фільтр (Filter) дозволяє користувачеві вибирати критерії пошуку. 
- компонент CarListing відображає список автомобілів, які відповідають 
обраним критеріям. 
- при виборі конкретного автомобіля компонент CarDetails показує 
детальну інформацію про нього. 
- SellerContact надає можливість зв'язатися з продавцем обраного 
автомобіля. 
 
 
Рисунок 2.8 – Діаграма компонентів 
 
 
 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Backend-частина На сервері перед тим повинен бути попередньо 
встановлений PostgreSQL. Далі нам потрібно створити базу даних «sampledb0» за 
допомогою SQL-команди: 
create database sampledb0; Наступним кроком ми описуємо конфігурацію 
з’єднання з базою даних у файлі app.py 
import psycopg2 
import psycopg2.extras 
  
app = Flask(__name__) 
app.secret_key = "caircocoders-ednalan" 
  
# Database configuration 
DB_HOST = "localhost" 
DB_NAME = "sampledb0" 
DB_USER = "postgres" 
DB_PASS = "password" 
  
conn = psycopg2.connect(dbname=DB_NAME, user=DB_USER, password=DB_PASS, 
host=DB_HOST) 
 
В даному проекті використовується Flask. Для розгортання системи на 
localhost необхідно виконати наступні дії: 
set FLASK_APP=app 
flask run 
 
Рисунок 2.9 – Діаграма розгортання системи 
 
 
 
2.5 Моделювання поведінки системи 
Моделювання поведінки системи дозволяє розуміти, як система взаємодіє з 
користувачами та іншими складовими, які процеси відбуваються всередині 
системи та як вони впливають на її функціонування. Це важлива частина розробки 
програмного забезпечення, яка допомагає виявити та вирішити проблеми ще до 
реального впровадження системи. 
2.5.1 Діаграма діяльності 
Діаграма діяльності - це графічний засіб для моделювання послідовності дій 
або процесів у системі. Основна мета діаграми діяльності - візуалізувати 
послідовність дій та рішень, що приймаються в рамках певного процесу.  
У цій діаграмі (Рисунок 2.10) показано, що користувач перевіряє 
інформацію про автомобіль і при необхідності зв'язується з продавцем. Після 
цього він може вирішити, чи хоче він здійснити покупку. Якщо так, то процес 
завершується, а якщо ні, то користувач продовжує пошук. 
 
 
Рисунок 2.10 – Діаграма діяльності 
 
 
 
2.5.2 Діаграма послідовності  
Ця діаграма послідовності (Рисунок 2.11) представляє взаємодію 
користувача з веб-сервісом пошуку автомобілів. Основні кроки взаємодії 
включають доступ користувача до веб-сайту, вибір автомобіля, перегляд списку 
доступних автомобілів, перегляд деталей кожного автомобіля, а також контакт з 
продавцем 
 
.  
Рисунок 2.11 – Діаграма послідовності 
 
- доступ до веб-сайту: користувач починає взаємодію, звертаючись до 
веб-сайту через свій веб-браузер. 
 
 
 
- вибір автомобіля: після доступу до веб-сайту користувач вибирає опцію 
перегляду автомобілів, натискаючи відповідний елемент інтерфейсу. 
- перегляд списку автомобілів: після вибору опції перегляду автомобілів, 
веб-сайт відображає список доступних автомобілів, які можуть 
відповідати критеріям користувача. 
- перегляд деталей автомобіля: користувач переглядає детальну 
інформацію про кожен автомобіль, натискаючи на відповідний елемент 
списку. 
- контакт з продавцем: якщо користувач зацікавлений автомобілем, він 
може зв'язатися з продавцем, заповнивши контактну форму або 
використавши інші доступні контактні дані. 
У цій діаграмі послідовності показано основні кроки, які користувач 
виконує під час взаємодії з веб-сервісом для пошуку автомобілів. 
2.5.3 Діаграма комунікації  
У цій діаграмі комунікації (Рисунок 2.12) відображено взаємодію 
користувача з веб-додатком. Користувач спочатку отримує доступ до веб-сайту та 
відправляє HTTP-запит через свій веб-браузер. Веб-додаток отримує цей запит, 
обробляє його та повертає відповідь у вигляді HTML-сторінки, яку браузер 
відображає користувачу. Після цього користувач може взаємодіяти з веб-
сторінкою, наприклад, натискати кнопки або заповнювати форми. Кожна така 
взаємодія генерує новий HTTP-запит, який надсилається до веб-додатка для 
обробки. Після кожного запиту веб-додаток повертає оновлену HTML-сторінку, 
яку браузер відображає користувачу, і процес взаємодії повторюється. 
 
 
Рисунок 2.12 – Діаграма комунікації 
 
 
 
2.5.4 Діаграма скінченного автомату  
Ця діаграма скінченного автомату (Рисунок 2.13) ілюструє основні стани та 
переходи веб-сервісу для пошуку рідкісних та цікавих автомобілів. Давайте 
розглянемо кожен стан та перехід:  
 
 
Рисунок 2.13 – Діаграма скінченного автомату 
 
Домашня сторінка (Home): 
Це початковий стан, у якому користувач потрапляє при відвідуванні веб-
сервісу. З цього стану користувач може перейти до перегляду доступних 
автомобілів або до сторінки автентифікації. 
Перегляд автомобілів (ViewCars): 
У цьому стані користувач може переглядати список доступних автомобілів. 
Він може перейти до детальної інформації про конкретний автомобіль або 
застосувати фільтри для пошуку певних автомобілів. 
Деталі автомобіля (ViewCarDetails): 
 
 
 
Користувач може перейти до цього стану, щоб переглянути детальну 
інформацію про конкретний автомобіль. Після перегляду деталей він може 
повернутися до списку автомобілів або перейти до сторінки автентифікації. 
Фільтрація автомобілів (FilterCars): 
Користувач може застосувати фільтри до списку автомобілів, щоб знайти 
певні моделі, за певними критеріями. Після застосування фільтрів він може 
повернутися до списку автомобілів або перейти до сторінки автентифікації. 
Автентифікація (Auth): 
Цей стан дозволяє користувачеві увійти в систему або зареєструватися. 
Після автентифікації користувач може повернутися до попередньої сторінки або 
перейти на домашню сторінку. 
 
 
 
 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
У другому розділі дослідив розробку веб-сервісу за допомогою різних 
діаграм. Провів аналіз діаграм який підкреслив основні класи та компоненти 
розробки веб-сервісу, який би відповідатиме потребам сучасних автолюбителів та 
забезпечував їм зручний та швидкий доступ до інформації про цікаві та рідкісні 
автомобілі. 
Отримані результати підтвердили основні класи та їх взаємодії між собою. 
На підставі проведеного аналізу визначено основну логічну структуру 
програмного комплексу. Розробка такого сервісу розробку моделей поведінки для 
правильного проектування. 
Загалом, результати другого розділу підкреслюють необхідність якісного 
проектування програмного забезпечення за допомогою діаграм які відображають 
різні сторони поведінки програми для пошуку рідкісних та цікавих автомобілів. 
 
 
 
 
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1 Розробка програмного комплексу  
Розробка програмного комплексу для веб-сервісу з пошуку рідкісних та 
цікавих автомобілів включає кілька ключових етапів, які забезпечують успішну 
реалізацію проекту. Ці етапи включають проектування архітектури, вибір 
технологій, реалізацію основних функцій, тестування та впровадження системи. 
3.1.1 Обґрунтування вибору засобів реалізації  
Засобами розробки були обрані Python [9] зі Flask Framework [10] на бекенді 
та HTML5/CSS, JavaScript, Bootstrap на фронтенді, система керування базами 
даних було обрано PostgreSQL. Загальна схема використаних технологій та 
засобів показана на (Рисунок 3.1). 
 
 
Рисунок 3.1 – Загальна схема використаних технологій 
 
 
 
Python — це потужна мова програмування, яка проста у вивченні. Вона має 
ефективні структури даних високого рівня та простий, але ефективний підхід до 
об'єктно-орієнтованого програмування. Елегантний синтаксис і динамічна 
типізація Python разом з інтерпретованою природою роблять її ідеальною мовою 
для створення сценаріїв і швидкої розробки додатків у багатьох сферах на 
більшості платформ. 
Перевагами Python рахують 
Простоту та легкість у вивченні:  
Python має зрозумілий та читабельний синтаксис, що робить його 
доступним для початківців. Мінімальна кількість синтаксичних правил дозволяє 
швидко освоїти основи програмування. 
 Велика кількість бібліотек та фреймворків: 
Існує багато готових бібліотек для різних завдань, таких як наука про дані 
(NumPy, pandas), веб-розробка (Django, Flask), машинне навчання (TensorFlow, 
scikit-learn), автоматизація (Selenium), тощо. Це дозволяє зменшити час розробки 
та зосередитись на вирішенні конкретних завдань. 
Портативність: 
Python кросплатформенний, тобто може працювати на різних операційних 
системах (Windows, macOS, Linux). Це спрощує перенесення програм між різними 
середовищами. 
Велика спільнота та підтримка: 
Велика спільнота розробників Python постійно створює нові інструменти, 
вирішує проблеми та ділиться знаннями. Багато навчальних матеріалів, 
документації та форумів допомагають швидко знайти відповіді на запитання. 
Інтерпретована природа: 
Python не потребує компіляції, що дозволяє швидко тестувати та 
відлагоджувати код. Це зручно для розробки сценаріїв та швидкої розробки. 
Недоліки Python виражаються в: 
- швидкості виконання: 
 
 
 
- Python повільніший у порівнянні з компільованими мовами, такими 
як C або C++. Це може бути критичним у додатках, де важлива 
продуктивність, як-от обробка великих обсягів даних в реальному 
часі. 
Використання пам'яті: 
Динамічна типізація та висока абстракція можуть призводити до більшого 
споживання пам'яті. Це може бути проблемою для ресурсомістких додатків. 
Мультипоточність: 
Глобальна блокування інтерпретатора (GIL) обмежує продуктивність 
багатопоточних програм, що працюють з CPU-bound задачами.Для таких задач 
рекомендується використовувати багатопроцесорність або інші мови 
програмування. 
Обмежені можливості для мобільної розробки: 
Хоча існують інструменти для розробки мобільних додатків на Python (Kivy, 
BeeWare), вони менш поширені і розвинуті порівняно з нативними інструментами 
для Android та iOS. Це може ускладнювати розробку високоякісних мобільних 
додатків. 
Менша ефективність для низькорівневих завдань: 
Python не підходить для завдань, що потребують низькорівневого доступу 
до пам'яті або апаратного забезпечення. У таких випадках краще використовувати 
мови програмування низького рівня, такі як C або C++. 
Flask називають мікрофреймворком, тому що для нього не потрібні 
спеціальні інструменти чи бібліотеки. Він не має рівня абстракції для операцій з 
базою даних, перевірки форм або інших компонентів, які використовують 
бібліотеки сторонніх розробників для забезпечення загальної функціональності. 
Однак Flask підтримує розширення, які надають додаткову функціональність, так 
само, якби Flask мав це з самого початку. Розширення включають об’єктно-
реляційне зв’язування, перевірку форми, керування навантаженням, підтримку 
різних відкритих технологій автентифікації та кілька популярних інструментів 
фреймворку. Розширення оновлюються частіше аніж базовий код. 
 
 
 
"Flask-Security" - це розширення (extension) для фреймворку Flask, яке надає 
додаткові засоби і функції для забезпечення безпеки в Flask-додатках . Це 
розширення допомагає розробникам вирішити різні аспекти безпеки, такі як 
аутентифікація, авторизація, захист від атак на введення та інші загрози безпеки. 
Важливо вказати, що Flask-Security - це окремий проект, розроблений спільнотою, 
і він не входить до складу офіційної документації Flask. Одним з основних засобів 
захисту веб додатків є керування ролями у Flask, зазвичай передбачає визначення 
ролей користувачів і обмеження доступу до певних частин програми на основі цих 
ролей. Ви можете використовувати розширення Flask, такі як Flask-Security або 
Flask-Principal, щоб реалізувати керування ролями. 
Опис фрейморку Flask було взято з джерела [11], [12]. 
 
Рисунок 3.2 – Архітектура Flask Framework[27] 
 
HTML (Hypertext Markup Language) - це мова, яка використовується для 
структурування та відображення веб-сторінок і їхнього контенту. Наприклад, 
контент може бути організований у вигляді параграфів, списків, зображень або 
таблиць даних. У цій статті ми розглянемо основи HTML та його функції. HTML 
не є мовою програмування; це мова розмітки, яка вказує браузеру, як відображати 
веб-сторінки. Його складність може варіюватися від простого до складного, 
залежно від потреб веб-дизайнера. HTML складається з елементів, що 
використовуються для обгортання або структурування різних частин контенту, 
щоб надати йому певний вигляд або функціональність. Теги HTML можуть 
перетворити слово або зображення на посилання, зробити текст курсивом, 
змінити розмір шрифту тощо. 
Опис що таке HTML засновано на джерелі [13]. 
 
 
 
CSS (Cascading Style Sheets) - це мова, яка використовується для стилізації 
веб-сторінки. Основи CSS допоможуть вам зрозуміти, що необхідно для початку 
роботи. Ми розглянемо такі питання, як: Як змінити колір тексту на чорний або 
червоний? Як розмістити контент у певному місці на екрані? Як прикрасити веб-
сторінку за допомогою фонових зображень та кольорів? Як і HTML, CSS не є 
мовою програмування. Це також не мова розмітки - це мова таблиць стилів. Вона 
дозволяє вибірково застосовувати стилі до елементів у документах HTML. 
Наприклад, щоб вибрати всі абзаци на HTML-сторінці і змінити колір тексту з 
чорного на червоний, ви повинні написати такий CSS-код [14]. 
JavaScript (JS) — це динамічна, об'єктно-орієнтована прототипна мова 
програмування, що відповідає стандарту ECMAScript. Вона найчастіше 
використовується для створення скриптів на вебсторінках, дозволяючи на стороні 
клієнта (пристрої користувача) взаємодіяти з користувачем, керувати браузером, 
асинхронно обмінюватися даними з сервером, а також змінювати структуру та 
вигляд вебсторінки. JavaScript класифікується як прототипна (різновид об'єктно-
орієнтованої) скриптова мова програмування з динамічною типізацією. Окрім 
прототипної парадигми, JavaScript частково підтримує інші підходи до 
програмування, зокрема імперативну та частково функціональну парадигми. 
Деякі її архітектурні характеристики включають динамічну та слабку типізацію, 
автоматичне керування пам'яттю, прототипне наслідування та функції як об'єкти 
першого класу. 
 У браузері JavaScript може: 
- додавати новий html-код на сторінку, змінювати існуючий вміст, 
модифікувати стилі. 
- реагувати на дії користувача, такі як натискання миші, переміщення 
курсору, натискання клавіш. 
- надсилати мережеві запити на віддалені сервери, завантажувати та 
відвантажувати файли (технології ajax та comet). 
- отримувати та встановлювати куки, ставити запитання користувачу, 
показувати повідомлення. 
 
 
 
- запам'ятовувати дані на клієнті («local storage»). 
Чого не може JavaScript у браузері? 
Можливості JavaScript у браузері обмежені для забезпечення безпеки 
користувача. Це необхідно для запобігання доступу зловмисних веб-сторінок до 
особистої інформації або завдання шкоди користувачам. 
Приклади таких обмежень: 
- javascript на веб-сторінці не може читати або записувати довільні файли 
на жорсткому диску, копіювати або запускати програми. він не має 
прямого доступу до системних функцій ос. 
- сучасні браузери дозволяють йому працювати з файлами, але з 
обмеженим доступом, і тільки якщо користувач виконує певні дії, такі 
як перетягування файлу у вікно браузера або його вибір за допомогою 
тега <input>. 
- взаємодія з камерою/мікрофоном та іншими пристроями можлива, але 
тільки за явного дозволу користувача. тобто, сторінка з javascript не 
може непомітно включити веб-камеру і спостерігати за користувачем. 
- різні вікна/вкладки не мають доступу одне до одного. javascript з однієї 
сторінки не може отримати доступ до іншої, якщо вони знаходяться на 
різних сайтах (інший домен, протокол чи порт). 
Опис мови JavaScript та її можливостей засновані на джерелі[15],[16]. 
Bootstrap — це безкоштовна платформа з відкритим кодом для створення 
веб-сайтів і веб-додатків. Призначений для адаптивної розробки мобільних веб-
сайтів, Bootstrap пропонує набір синтаксису для створення шаблонів дизайну. 
Як фреймворк, Bootstrap містить основи адаптивної веб-розробки, 
дозволяючи розробникам використовувати попередньо визначену систему сіток 
для вставки коду. Інфраструктура Bootstrap базується на HTML, CSS та JavaScript. 
Використовуючи Bootstrap, веб-розробники можуть значно прискорити процес 
створення веб-сайтів, уникаючи написання базових команд і функцій з нуля. 
Bootstrap реалізує адаптивний веб-дизайн, дозволяючи веб-сторінкам або 
додаткам автоматично підлаштовуватися під розмір і орієнтацію екрана 
 
 
 
користувача. Завдяки підходу, орієнтованому на мобільні пристрої, Bootstrap 
забезпечує відповідність веб-дизайну сучасним технологіям, зокрема 
смартфонам, планшетам та спеціалізованим мобільним додаткам. Bootstrap 
включає компоненти інтерфейсу користувача, макети, інструменти JavaScript та 
структуру реалізації. Платформа доступна як у попередньо скомпільованому 
вигляді, так і у вигляді вихідного коду[17]. 
Системою керування базами даних я обрав PostgreSQL. PostgreSQL — 
потужна об’єктно-реляційна база даних з відкритим вихідним кодом, яка 
розширює мову SQL та забезпечує безпечне зберігання і масштабування складних 
даних. Її розвиток розпочався в 1986 році як частина проекту POSTGRES у 
Каліфорнійському університеті в Берклі, і на сьогодні вона має понад 35 років 
активного вдосконалення. 
PostgreSQL здобула міцну репутацію завдяки надійній архітектурі, 
цілісності даних, багатофункціональності, розширюваності та підтримці 
спільноти з відкритим кодом, яка постійно забезпечує ефективні та інноваційні 
рішення. PostgreSQL працює на всіх основних операційних системах, сумісна з 
ACID з 2001 року та має потужні додаткові модулі, такі як PostGIS для роботи з 
геопросторовими даними. Через це PostgreSQL є вибором для багатьох людей та 
організацій як реляційна база даних з відкритим вихідним кодом. 
PostgreSQL пропонує багато функцій для розробників, адміністраторів і 
користувачів, незалежно від розміру даних. Окрім того, що PostgreSQL є 
безкоштовною та з відкритим вихідним кодом, вона дуже розширювана. Ви 
можете створювати власні типи даних, функції та навіть писати код різними 
мовами без необхідності перекомпіляції бази даних. 
PostgreSQL прагне відповідати стандарту SQL, якщо це не суперечить 
традиційним функціям або не призводить до невдалих архітектурних рішень. 
Багато функцій стандарту SQL підтримуються, іноді з дещо відмінним 
синтаксисом або функціоналом. Станом на версію 16 (випущену у вересні 2023 
року), PostgreSQL відповідає принаймні 170 із 179 обов’язкових функцій для 
SQL:2023 Core. 
 
 
 
Основні можливості PostgreSQL: 
Типи даних: 
- примітивні: ціле, числове, рядкове, логічне; 
- структуровані: дата/час, масив, діапазон/багатодіапазон, uuid; 
- документ: json/jsonb, xml, ключ-значення (hstore); 
- геометрія: точка, лінія, коло, багатокутник; 
- кастомні: композитні, спеціальні типи. 
цілісність даних: 
- унікальні ключі, первинні ключі, зовнішні ключі; 
- обмеження виключення; 
- явні та рекомендаційні блокування. 
одночасність та продуктивність: 
- різні методи індексування (b-дерево, багатостовпцеве, gist, sp-gist, gin, 
brin); 
- складний планувальник/оптимізатор запитів; 
- підтримка транзакцій та multi-version concurrency control (mvcc); 
- розпаралелювання запитів та побудова індексів. 
надійність та аварійне відновлення:  
- журналування з випереджальним записом (wal); 
- реплікація: асинхронна, синхронна, логічна; 
- відновлення на певний момент часу (pitr). 
безпека:  
- підтримка різних методів автентифікації (gssapi, sspi, ldap, scram-sha-
256); 
- система контролю доступу; 
- безпека на рівні стовпців і рядків; 
- багатофакторна аутентифікація. 
розширюваність: 
- збережені функції та процедури; 
 
 
 
- процедурні мови: pl/pgsql, perl, python, tcl та інші через розширення 
(java, javascript, r, lua, rust); 
- інтерфейси для підключення до інших баз даних; 
- велика кількість розширень, включаючи postgis інтернаціоналізація та 
текстовий пошук: 
- підтримка міжнародних наборів символів; 
- повнотекстовий пошук. 
Опис PostgreSQL заснований на джерелі [18]. 
 
 
Рисунок 3.3 – PostgreSQL архітектура[28] 
 
3.1.2 Опис структурної (функціональної) схеми  
Для побудови веб-сервісу для пошуку рідкісних та цікавих автомобілів 
використовується клієнт-серверна архітектура, що дозволяє ефективно 
 
 
 
розподіляти завдання між клієнтською частиною та серверною частиною. Сервер 
обробляє запити від клієнтів, виконує необхідні обчислення та взаємодію з базою 
даних, а потім надсилає відповіді назад на клієнт. Це забезпечує гнучкість, 
масштабованість та зручність управління даними, оскільки вся важка обробка 
даних та зберігання відбуваються на сервері, а клієнт займається лише 
відображенням даних та взаємодією з користувачем. 
В архітектурі веб-сервісу застосовується широко поширений архітектурний 
шаблон Model-View-Controller (MVC). Цей шаблон розділяє логіку програми на 
три взаємодіючі компоненти: Модель (Model), Вигляд (View) та Контролер 
(Controller).[19] Модель відповідає за управління даними та логікою бізнесу; вона 
отримує дані з бази даних, зберігає їх та обробляє. Контролер служить 
посередником між Моделлю та Вигляд; він обробляє запити від користувачів, 
викликає відповідні методи Моделі для обробки даних і передає їх у Подання для 
відображення. Подання відповідає за представлення даних користувачеві та 
забезпечує зручний інтерфейс для взаємодії.  
 
 
Рисунок 3.4 – Функціональна схема веб-сервісу 
 
 
 
В коді програми можна бачити реалізацію різних частин MVC-архітектури. 
Наприклад, маршрути в Flask (на кшталт @app.route('/cars') або @app.route('/login', 
methods=['GET', 'POST'])) виступають як Контролери, обробляючи запити від 
клієнтів та викликаючи відповідні дії. Шаблони HTML, такі як index.html чи 
cars.html, представляють Вигляд, яке відображає дані користувачам. Модель, 
представлена у вигляді запитів до бази даних (PostgreSQL) через psycopg2, 
забезпечує збереження та отримання даних. Цей підхід забезпечує чисту 
розподілену структуру коду, що полегшує її підтримку та розширення. 
3.1.3 Опис логічної схеми системи  
Архітектуру додатку відображено на (Рисунок 3.5). На рисунку відображено 
взаємодію модулів програми між собою. 
Front-end (Клієнтська частина): 
- HTML: Відповідає за структуру веб-сторінок. Визначає основні 
елементи інтерфейсу користувача; 
- CSS: Відповідає за стилізацію веб-сторінок, робить інтерфейс 
користувача привабливим та зручним; 
- JavaScript: Забезпечує динамічну поведінку веб-сторінок, дозволяє 
реагувати на події та взаємодію користувача без необхідності 
перезавантаження сторінок; 
- Templates: Шаблони, що використовуються для відображення 
динамічного вмісту, формуються з використанням HTML та CSS, а 
також підтримують інтеграцію з JavaScript. 
Back-end (Серверна частина): 
- Flask: Веб-фреймворк, який забезпечує маршрутизацію запитів, обробку 
HTTP-запитів та взаємодію з клієнтською частиною; 
- Controllers: Обробники запитів, що реалізують логіку маршрутизації та 
взаємодію з моделями. Вони отримують дані від клієнтів, обробляють їх 
та передають до моделей або повертають результати у вигляді 
відповідей; 
 
 
 
- Models: Моделі, що представляють дані та забезпечують взаємодію з 
базою даних. Вони містять логіку зберігання та отримання даних, 
виконують SQL-запити через psycopg2; 
- Views: Відповідають за формування відповіді, що відправляється 
клієнту. Вони взаємодіють з шаблонами для відображення динамічного 
вмісту. 
Database (База даних):  
- PostgreSQL: Реляційна база даних, що зберігає всі дані системи; 
- carmodels: Таблиця, що містить інформацію про моделі автомобілів; 
- carbrands: Таблиця, що містить інформацію про бренди автомобілів; 
- users: Таблиця, що містить інформацію про користувачів; 
- messages: Таблиця для зберігання повідомлень, відправлених 
користувачами; 
- sellers: Таблиця, що містить інформацію про продавців автомобілів. 
Веб-сервіс розроблено за допомогою Visual Studio Code — це легкий, але 
потужний редактор коду, який доступний для Windows, macOS та Linux. Він має 
вбудовану підтримку для JavaScript, TypeScript і Node.js, а також пропонує багату 
екосистему розширень для інших мов програмування та середовищ виконання, 
таких як C++, C#, Java, Python, PHP, Go і .NET[20]. Проект містить в собі файли 
які відображені на рисунку 3.6. 
 
 
Рисунок 3.5 – MVC архітектура веб-сервісу 
 
 
 
 
Рисунок 3.6 – Файли проекту 
 
3.1.4 Розробка бази даних 
Розробка бази даних для веб-сервісу, що призначений для пошуку рідкісних 
та цікавих автомобілів, включає створення структури даних, визначення зв'язків 
між таблицями та забезпечення ефективного доступу до інформації. У цій секції 
детально розглянуто процес проектування бази даних. 
Для даного проекту використовується реляційна база даних PostgreSQL. 
Вибір PostgreSQL обумовлений тим що я маю досвід роботи та під час 
використання вона для мене вирізняється поміж інших СУБД високою 
 
 
 
продуктивністю, надійністю та підтримкою складних запитів та транзакцій, що 
робить її ідеальною для розроблюваного веб-сервісу. Проектування бази даних 
включає визначення основних таблиць, їх атрибутів, а також зв'язків між ними. 
Основні таблиці бази даних включають таблиці для зберігання інформації про 
користувачів, автомобілі, продавців та повідомлення. 
 
 
Рисунок 3.7 – ERD діаграма бази даних 
 
Таблиця 3.1 User зберігає інформацію про користувачів, які можуть 
взаємодіяти з веб-сервісом. 
 
 
 
Таблиця 3.1 
Структура таблиці User 
Поле Тип Опис 
id int Первинний ключ 
username varchar Ім'я користувача 
password varchar Пароль користувача 
role varchar Роль користувача 
 
Таблиця 3.2 Car зберігає інформацію про автомобілі, які доступні для 
пошуку та перегляду у веб-сервісі. 
 
Таблиця 3.2 
Структура таблиці Car 
Поле Тип Опис 
id int Первинний ключ 
brand_id int Ідентифікатор марки автомобіля 
car_model varchar Модель автомобіля 
body_type varchar Тип кузова 
number_doors int Кількість дверей 
price_range float Ціновий діапазон 
year int Рік випуску 
mileage int Пробіг 
transmission varchar Трансмісія 
fuel_type varchar Тип палива 
color varchar Колір 
technical_condition varchar Технічний стан 
customs_cleared bool Чи пройшов митне очищення 
driven_from varchar Звідки пригнаний 
engine_size int Об'єм двигуна 
   
 
 
 
Продовження таблиці 3.2 
engine_name varchar Назва двигуна 
engine_hp int Потужність двигуна 
location varchar Місцезнаходження автомобіля 
seller_id int Ідентифікатор продавця 
 
Таблиця 3.3 Seller зберігає інформацію про продавців автомобілів. 
 
Таблиця 3.3    
Структура таблиці Seller 
Поле Тип Опис 
seller_id int Первинний ключ 
seller_name varchar Ім'я продавця 
seller_email varchar Електронна пошта 
seller_phone varchar Телефон 
seller_location varchar Місцезнаходження 
 
Таблиця 3.4 Message зберігає повідомлення, надіслані користувачами через 
контактну форму веб-сервісу. 
Таблиця 3.4    
Структура таблиці Message 
Поле Тип Опис 
id int Первинний ключ 
name varchar Ім'я відправника 
subject varchar Тема повідомлення 
message text Текст повідомлення 
 
3.1.5 Розробка інтерфейсу користувача  
При розробці інтерфейсу користувача я брав натхнення з сайтів аналогів з 
мінімалістичним дизайном та блогами про автоспорт, авто-підбір, авто-культуру 
 
 
 
і т.д. на рисунку 3.8 та 3.9 відображено верхню та нижню частину початкової 
сторінки веб-сайту. 
 
 
Рисунок 3.8 – Верхня частина сайту 
 
 
Рисунок 3.9 – Нижня частина сайту 
 
 
 
На рисунку 3.10, 3.11 відображено сторінки з формою логіну та формою 
реєстрації.  
 
 
Рисунок 3.10 – Нижня частина сайту 
 
 
Рисунок 3.11 – Нижня частина сайту 
 
 
 
 
На рисунку 3.12 відображено головну по функціоналу сторінку Cars де 
користувач може знайти автомобіль за допомогою запропонованих фільтрів 
пошуку. 
 
 
Рисунок 3.12 – Сторінка Cars з фільтром пошуку авто 
 
Коли користувач вибрав характеристики пошуку та натиснув кнопку Filter 
Cars з’являється список авто які відповідають заданим параметрам (Рисунок 3.13). 
 
 
Рисунок 3.13 – Сторінка Cars з фільтром пошуку авто 
 
 
 
Також користувач після реєстрації може додати авто натиснувши кнопку 
Add Car для продажу чи полегшенню заходження авто для інших (Рисунок 3.14). 
 
 
Рисунок 3.14 – Меню для додавання авто 
 
При виявленні проданого авто чи авто яке не відповідає своєму опису авто. 
Адміністратор має змогу видалити авто з пошуку(Рисунок 3.15). 
 
 
Рисунок 3.15 – Відображення кнопки видалення в адміністратора 
 
 
 
Для покращення сайту та зворотного зв’язку з користувачами на сайті є 
спеціальна сторінка Contact Us з формою для відправлення повідомлень 
адміністраторам (Рисунок 3.16). 
 
 
Рисунок 3.15 – Сторінка Contact Us  
 
3.1.6 Опис розробки програмних компонентів 
Технології: HTML, CSS, JavaScript, Bootstrap 
Клієнтська частина веб-сервісу реалізована за допомогою HTML для 
створення структури сторінок, CSS для їх стилізації, JavaScript для додавання 
інтерактивності та Bootstrap для швидкої розробки адаптивного дизайну. Основні 
компоненти включають: 
- головна сторінка: відображає загальну інформацію про сервіс і навігацію 
до інших розділів; 
 
 
 
- сторінка авторизації/реєстрації: забезпечує вхід та реєстрацію 
користувачів; 
- сторінка списку автомобілів: дозволяє користувачам переглядати 
доступні автомобілі з можливістю фільтрації за різними 
характеристиками; 
- сторінка деталей автомобіля: відображає детальну інформацію про 
вибраний автомобіль; 
- контактна сторінка: надає користувачам можливість надіслати 
повідомлення адміністрації веб-сервісу. 
Серверна частина (Back-end)Технології: Python, Flask 
Серверна частина веб-сервісу розроблена на Python з використанням Flask, 
легкого фреймворка для веб-розробки. Основні компоненти включають: 
- обробка запитів: Flask обробляє HTTP-запити від клієнта та повертає 
відповідні HTML-сторінки або дані у форматі JSON; 
- управління сесіями: забезпечує авторизацію користувачів і збереження 
їхнього стану на сервері; 
- API: реалізовані RESTful API для взаємодії з клієнтською частиною та 
маніпулювання даними автомобілів, продавців та користувачів; 
- утиліти: функції для хешування паролів, перевірки введених даних, 
керування сесіями та відображення повідомлень. 
Модель данихТехнології: SQLAlchemy (ORM для Python) 
Для взаємодії з базою даних використовується SQLAlchemy, який 
забезпечує ORM (Object-Relational Mapping), що дозволяє працювати з базою 
даних як з об'єктами Python. Основні компоненти: 
- моделі: визначають структуру таблиць бази даних і відносини між ними; 
- сесії: забезпечують транзакційний менеджмент для взаємодії з базою 
даних; 
- запити: функції для створення, читання, оновлення та видалення записів 
у базі даних. 
База данихТехнології: PostgreSQL 
 
 
 
База даних зберігає інформацію про користувачів, автомобілі, продавців та 
повідомлення. Основні компоненти: 
- таблиця user: зберігає інформацію про користувачів (логін, пароль, 
роль); 
- таблиця car: зберігає інформацію про автомобілі (марка, модель, 
характеристики); 
- таблиця seller: зберігає інформацію про продавців (ім'я, контакти, 
місцезнаходження); 
- таблиця message: зберігає повідомлення від користувачів. 
3.2 Тестування системи  
Тестування програмного забезпечення (ПЗ) — це процес перевірки 
програмного продукту для виявлення дефектів, помилок і недоліків перед його 
випуском на ринок або введенням в експлуатацію. Цей процес включає запуск 
програми з різними вхідними даними та умовами, а також аналіз її реакції на ці 
дані. Основна мета тестування — підтвердити правильність роботи програми 
відповідно до вимог, а також забезпечити високу якість і надійність програмного 
продукту. Тестування ПЗ може проводитися вручну або за допомогою 
автоматизації. Обидва підходи мають свої переваги та недоліки, які слід 
враховувати при плануванні тестових стратегій. 
3.2.1 Модульне тестування  
Модульне тестування - це процес тестування кожної окремої 
функціональності додатку в ізольованому середовищі, що штучно створене. Для 
успішного проведення модульних тестів необхідні навички в автоматизації 
тестування програмного забезпечення та розуміння основ програмування. Для 
створення ізольованого середовища для модуля часто використовуються 
драйвери та заглушки[26]. 
Для модульного тестування Flask-додатків використовую бібліотеку unittest 
(вбудована в Python) або pytest. Крім цього, використовую Flask-Testing для 
створення контексту додатку і роботи з тестовою базою даних. 
 
 
 
Таблиця 3.5    
Модульне тестування 
 
Модулі Результат 
app.py Успішний запуск 
main.js Успішне завантаження залежностей 
plugins.js Успішне завантаження залежностей 
datepicker.js Успішне завантаження залежностей 
Index.html Успішне завантаження залежностей 
Cars.html Успішне завантаження залежностей 
Login.html Успішне завантаження залежностей 
Register.html Успішне завантаження залежностей 
About-us.html Успішне завантаження залежностей 
 
3.2.2 Інтеграційне тестування  
Інтеграційне тестування - це вид тестування, де перевіряється взаємодія 
модулів та підсистем, коли вони об'єднуються в єдину систему. Це включає 
перевірку того, як компоненти співпрацюють між собою, а також перевірку 
інтерфейсів між ними. Для цього використовуються компоненти, які вже пройшли 
модульне тестування і групуються для спільної перевірки відповідно до плану 
тестування[23]. 
 
Таблиця 3.6    
Інтеграційне тестування 
Інтегровані Компоненти Результат 
index + App Успішне завантаження залежностей 
register + login + cars Успішне завантаження залежностей 
 
 
 
 
 
Продовження Таблиці 3.6 
register + login Успішне завантаження залежностей 
Main + app Успішне завантаження залежностей 
 
- index + App: Успішне завантаження залежностей - Це означає, що 
компонент index та App успішно інтегрувалися, і всі необхідні 
залежності для їх роботи були успішно завантажені. 
- register + login + cars: Успішне завантаження залежностей - Це показує, 
що компоненти register, login та cars також успішно інтегрувалися, і всі 
необхідні залежності для їх роботи були успішно завантажені. 
- register + login: Успішне завантаження залежностей - Тут теж 
зазначається успішна інтеграція двох компонент: register та login. 
- Main + app: Успішне завантаження залежностей - В цьому випадку, 
швидше за все, мається на увазі інтеграція головного файлу програми 
(Main) і самої програми (app), і вони також успішно завантажили всі 
потрібні залежності. 
Ці результати демонструють, що всі компоненти програми успішно 
інтегрувалися один з одним і їх залежності були належним чином оброблені. 
3.2.3 Системне тестування  
Системне тестування - це процес перевірки програмного забезпечення на 
відповідність вихідним вимогам, як функціональним, так і не функціональним, на 
повній, інтегрованій системі[24]. 
 
Таблиця 3.7    
Системне тестування 
Функціональність/Сценарій Результат 
RegistrationModule Виконання успішне 
LoginModule Виконання успішне 
FlaskApplication Успішний запуск 
 
 
 
Продовження таблиці 3.7 
FilterCars Виконання успішне 
AddCar Виконання успішне 
 
Пояснення результатів системного тестування для кожного сценарію: 
- RegistrationModule (Модуль реєстрації): Виконання успішне - Це 
означає, що підсистема або модуль реєстрації в програмі пройшов 
тестування і працює належним чином. 
- LoginModule (Модуль входу в систему): Виконання успішне - Тут також 
підтверджується, що модуль для входу в систему виконується коректно. 
- FlaskApplication (Додаток Flask): Успішний запуск - Це показує, що весь 
додаток Flask, включаючи всі компоненти та маршрути, успішно 
запускається. 
- FilterCars (Фільтрація автомобілів): Виконання успішне - Це свідчить 
про те, що функціонал фільтрації автомобілів працює правильно, і 
система правильно відображає відфільтровані результати. 
- AddCar (Додавання автомобіля): Виконання успішне - Тут 
підтверджується, що можливість додавання нового автомобіля також 
працює належним чином. 
Ці результати свідчать про те, що вся система, включаючи реєстрацію, вхід 
в систему, додавання автомобілів, фільтрацію та запуск додатку, проходить 
тестування успішно і готова до використання.  
3.2.4 Приймальне тестування  
Приймальне тестування - це процес, який відбувається на етапі передачі 
готового продукту або його частини замовнику. Його мета полягає в тому, щоб 
визначити, чи готовий продукт відповідає вимогам, встановленим у специфікації 
програмного забезпечення, через виконання тестових сценаріїв та випадків[25]. 
 
 
 
 
 
Таблиця 3.8    
Приймальне тестування 
Ендпоінт Очікуваний результат 
POST /filter 200 
POST /login 200 
POST /register 200 
POST /addcar 200 
POST /deletecar 200 
GET /sellers 200 
POST /send-message 200 
 
Результати по кожному ендпоінту: 
- POST /filter: Очікуємий результат - 200. Це означає, що при надсиланні 
запиту на фільтрацію автомобілів очікується успішна обробка запиту 
сервером і повернення статусу 200, що підтверджує успішне виконання 
операції. 
- POST /login: Очікуємий результат - 200. При спробі входу в систему 
через ендпоінт /login очікується успішна автентифікація користувача і 
повернення статусу 200. 
- POST /register: Очікуємий результат - 200. При спробі реєстрації нового 
користувача через ендпоінт /register очікується успішне створення 
облікового запису і повернення статусу 200. 
- POST /addcar: Очікуємий результат - 200. При спробі додати новий 
автомобіль через ендпоінт /addcar очікується успішне додавання 
автомобіля до бази даних і повернення статусу 200. 
- POST /deletecar: Очікуємий результат - 200. При спробі видалити 
існуючий автомобіль через ендпоінт /deletecar очікується успішне 
видалення автомобіля з бази даних і повернення статусу 200. 
- GET /sellers: Очікуємий результат - 200. При спробі отримати  
 
 
 
- інформацію про продавця через ендпоінт /sellers очікується успішне 
отримання даних про продавця і повернення статусу 200. 
- POST /send-message: Очікуємий результат - 200. При спробі надіслати 
повідомлення через ендпоінт /send-message очікується успішна обробка 
повідомлення і повернення статусу 200. 
Усі ці очікувані результати свідчать про те, що функціонал програми 
відповідає вимогам і може бути прийнятий замовником або користувачем. 
 
Таблиця 3.8    
Приймальне тестування 
№ Опис тесту Очікуваний результат Фактичний результат Статус 
1 POST /filter Повернення списку авто Повернення списку авто Пройдено 
2 POST /login Користувач Користувач Пройдено 
авторизувався авторизувався 
3 POST Користувач Користувач Пройдено 
/register зареєструвався зареєструвався 
4 POST Користувач додав авто Користувач додав авто Пройдено 
/addcar 
5 POST Користувач видалив авто Користувач видалив Пройдено 
/deletecar авто 
6 GET /sellers Користувач отримав Користувач отримав Пройдено 
інформацію про інформацію про 
продавців продавців 
7 POST /send- Користувач відправив Користувач відправив Пройдено 
message повідомлення повідомлення 
 
Таблиця представляє результати тестування для кожного ендпоінту 
програми: 
- POST /filter: Очікуваний результат - Повернено список авто. Фактичний 
результат - Повернено список авто. Статус – Пройдено; 
 
 
 
- POST /login: Очікуваний результат - Користувач авторизувався. 
Фактичний результат - Користувач авторизувався. Статус – Пройдено; 
- POST /register: Очікуваний результат - Користувач зареєструвався. 
Фактичний результат - Користувач зареєструвався. Статус – Пройдено; 
- POST /addcar: Очікуваний результат - Користувач додав авто. 
Фактичний результат - Користувач додав авто. Статус – Пройдено; 
- POST /deletecar: Очікуваний результат - Користувач видалив авто. 
Фактичний результат - Користувач видалив авто. Статус – Пройдено; 
- GET /sellers: Очікуваний результат - Користувач отримав інформацію 
про продавців. Фактичний результат - Користувач отримав інформацію 
про продавців. Статус – Пройдено; 
- POST /send-message: Очікуваний результат - Користувач відправив 
повідомлення. Фактичний результат - Користувач відправив 
повідомлення. Статус - Пройдено. 
Всі тести пройшли успішно, і функціонал програми відповідає очікуванням. 
3.3 Приклади впровадженого програмного комплексу  
Головна сторінка (Рисунок 3.16)  та всі подальші як і меню реалізоване в 
мінімалістичному стилі. В правому верхньому куті знаходяться кнопки логіну та 
реєстрації, а також ми бачимо кнопки меню під логотипом де можемо побачити 
кнопки About us, Cars, Contact Us 
Рисунок 3.16 – Головна сторінка 
 
 
 
Також користувач може зареєструватись (Рисунок 3.17)  та авторизуватись 
в систему (Рисунок 3.18). 
 
 
Рисунок 3.17 – Сторінка реєстрації 
 
 
Рисунок 3.18 – Сторінка авторизації 
 
В футері(нижня частина сторінки) (Рисунок 3.19)  кожної сторінки 
реалізовані додаткові переходи по сторінкам веб-сервісу, а також відображено 
інформацію для контактування з розробником та посилання на його сторінки в 
соціальні мережі. 
 
 
 
 
 
Рисунок 3.19 – Футер 
 
На сторінці Cars (Рисунок 3.20) реалізовано пошук авто, додавання авто та 
видалення. 
 
Рисунок 3.20 – Сторінка Cars 
 
Після введення параметрів пошуку та натиску на кнопку Filter Cars 
відображаються результати пошуку (Рисунок 3.21). 
 
 
 
 
Рисунок 3.21 – Результати пошуку 
 
Результати пошуку відображають авто (Рисунок 3.22)  його фото та 
характеристики та при натиску на кнопку Show Seller Info відображає інформацію 
про продавця. Адміністратор має право видаляти авто на кнопку Delete Car. 
 
 
Рисунок 3.22 – Відображення авто 
 
 
 
Користувач має можливість додавати авто до бази даних авто. (Рисунок 
3.23) 
 
 
Рисунок 3.23 – Форма додавання авто 
 
На сторінці About Us (Рисунок 3.24) відображається інформація про для 
кого створений веб-сервіс. 
 
 
Рисунок 3.24 – Сторінка About Us 
 
 
 
На сторінці Contact us (Рисунок 3.25) користувач може відправляти 
повідомлення з відгуками про веб-сервіс за допомогою форми (Рисунок 3.26) для 
покращення його функціоналу. 
 
 
Рисунок 3.25 – Сторінка Contact us 
 
 
Рисунок 3.26 – форма для надсилання відгуків 
 
 
 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
Під час виконання третього розділу було обґрунтовано вибір засобів 
реалізації, описана функціональна схема та логічна схема системи. На основі 
повної діаграми класів була створена база даних.  
При дослідженні аналогів розроблюваного веб-сервісу та тематичних 
джерел розроблено дизайн та інтерфейс користувача. Під час розробки веб-
сервісу було проведено різні типи тестування системи. Модульне тестування 
дозволило виправляти помилки на ранніх етапах розробки, що посприяло 
підвищенню надійності кінцевого результату. Інтеграційне тестування було 
критичним етапом при розробці так як цей вид тестування перевіряє взаємодію 
між різними модулями та компонентами системи. За його допомогою було 
виявлено дефекти при інтеграції окремих модулів в веб-сервіс. 
Системне тестування допомогло перевірити систему на відповідність 
заданим вимогам. Приймальне тестування стало заключним етапом тестування 
веб-сервісу. За його допомогою я зміг перевірити систему на відповідність всім 
бізнес-вимогам. 
Отже, результати третього розділу відображають всю структуру 
розроблюваного веб-сервісу від технологій розробки до тестування. 
 
 
 
 
ВИСНОВКИ 
У ході виконання бакалаврської роботи було досягнуто мети розробки та 
впровадження високоефективного веб-сервісу для пошуку рідкісних та цікавих 
автомобілів. Виконані дослідження та реалізація проєкту підтвердили 
актуальність та перспективність розробки такого сервісу для задоволення потреб 
сучасних автолюбителів. 
У першому розділі було проведено аналіз існуючих аналогів та досліджено 
основні принципи функціонування веб-сервісів. Це дозволило визначити основні 
вимоги до розроблюваного сервісу та обґрунтувати його актуальність на ринку. 
Другий розділ був присвячений детальному проектуванню веб-сервісу, 
включаючи створення функціональної та логічної схем системи, розробку бази 
даних та дизайну інтерфейсу користувача. Це забезпечило створення структури, 
що відповідає сучасним вимогам та стандартам веб-розробки. 
У третьому розділі було описано процес розробки та тестування веб-сервісу. 
Модульне, інтеграційне, системне та приймальне тестування дозволили 
забезпечити високу якість та надійність кінцевого продукту, виявити та виправити 
дефекти на різних етапах розробки. 
Таким чином, результати виконаної роботи підтвердили, що розроблений 
веб-сервіс є функціональним, зручним та ефективним інструментом для пошуку 
рідкісних та цікавих автомобілів. Сервіс забезпечує користувачам швидкий 
доступ до необхідної інформації, що сприяє розвитку ринку ексклюзивних 
автомобілів та задоволенню потреб автолюбителів. Робота має практичне 
значення та може бути корисною як для покупців, так і для продавців, створюючи 
зручну платформу для їх взаємодії. 
 
 
 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Що таке веб-сервіс та їх види? [Електронний ресурс]. - Режим 
доступу: https://2ip.ua/ua/blog/web-services. 
2 Що таке веб-сервіс та їх види? [Електронний ресурс]. - Режим 
доступу: https://2ip.ua/ua/blog/web-services. 
3 What are Web services? [Електронний ресурс]. - Режим доступу: 
https://www.techtarget.com/searchapparchitecture/definition/Web-
services. 
4 What is a RESTful API? [Електронний ресурс]. - Режим доступу: 
https://aws.amazon.com/ru/what-is/restful-api/. 
5 LPU аналіз вимог [Електронний ресурс]. - Режим доступу: 
https://comp.ucoz.net/TSPP/KursRob/LPUAnalizVymog15.pdf. 
6 UML діаграми випадків використання [Електронний ресурс]. - Режим 
доступу: https://lvivqaclub.blogspot.com/2008/10/use-case-uml-
diagram.html. 
7 Діаграми класів [Електронний ресурс]. - Режим доступу: 
https://ua5.org/oop/392-diagrami-klasiv.html. 
8 Теоретичні основи UML діаграм [Електронний ресурс]. - Режим 
доступу: https://studfile.net/preview/16869580/page:5/. 
9 UML діаграми компонентів [Електронний ресурс]. - Режим доступу: 
https://www.mindonmap.com/uk/blog/uml-component-diagram/. 
10 Документація Python [Електронний ресурс]. - Режим доступу: 
https://www.python.org/doc/. 
11 Flask документація [Електронний ресурс]. - Режим доступу: 
https://flask.palletsprojects.com/en/3.0.x/. 
12 Куницька С. Ю., Сергієнко О. С. Аспекти та практичне використання 
засобів і функцій flask framework для забезпечення web-додатку. 
[Електронний ресурс]. - Режим доступу: https://sci-conf.com.ua/wp-
content/uploads/2023/11/GLOBAL-SCIENCE-PROSPECTS-AND-
INNOVATIONS-2-4.11.23.pdf. 
 
 
 
13 Сергієнко О.С., Потапенко Л.В. Usage of Flask framework tools and 
functions for user’s communication with a web application. [Електронний 
ресурс]. - Режим доступу: 
http://csbc.edu.ua/documents/student/110424.pdf. 
14 Основи HTML [Електронний ресурс]. - Режим доступу: 
https://developer.mozilla.org/ru/docs/Learn/Getting_started_with_the_we
b/HTML_basics. 
15 Основи CSS [Електронний ресурс]. - Режим доступу: 
https://developer.mozilla.org/ru/docs/Learn/Getting_started_with_the_we
b/CSS_basics. 
16 JavaScript [Електронний ресурс]. - Режим доступу: 
https://uk.wikipedia.org/wiki/JavaScript. 
17 Вступ до JavaScript [Електронний ресурс]. - Режим доступу: 
https://uk.javascript.info/intro. 
18 Що таке Bootstrap? [Електронний ресурс]. - Режим доступу: 
https://www.techtarget.com/whatis/definition/bootstrap. 
19 Про PostgreSQL [Електронний ресурс]. - Режим доступу: 
https://www.postgresql.org/about/. 
20 Модель-Vid-Контроллер [Електронний ресурс]. - Режим доступу: 
https://uk.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D
0%BB%D1%8C-%D0%B2%D0%B8%D0%B4-
%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%
D0%B5%D1%80. 
21 Документація Visual Studio Code [Електронний ресурс]. - Режим 
доступу: https://code.visualstudio.com/docs. 
22 Кваліфікаційна робота бакалавра (нове ПЗАС 2023) [Електронний 
ресурс]. 
23 Що таке тестування програмного забезпечення? [Електронний 
ресурс]. - Режим доступу: https://university.sigma.software/what-is-
software-testing/. 
 
 
 
24 Інтеграційне тестування [Електронний ресурс]. - Режим доступу: 
https://qalight.ua/baza-znaniy/integratsijne-testuvannya/. 
25 Системне тестування [Електронний ресурс]. - Режим доступу: 
https://qalight.ua/baza-znaniy/sistemne-testuvannya/. 
26 Приймальне тестування [Електронний ресурс]. - Режим доступу: 
https://qalight.ua/baza-znaniy/prijmalne-testuvannya/. 
27 Модульне тестування [Електронний ресурс]. - Режим доступу: 
https://qalight.ua/baza-znaniy/modulne-testuvannya/. 
28 Launch your own REST API using Flask and Python [Електронний 
ресурс]. - Режим доступу: https://towardsdatascience.com/launch-your-
own-rest-api-using-flask-python-in-7-minutes-c4373eb34239. 
29 Архітектура PostgreSQL [Електронний ресурс]. - Режим доступу: 
https://www.educba.com/postgresql-architecture/.  
30 Методичні рекомендації до підготовки кваліфікаційної роботи 
бакалавра для здобувачів вищої освіти зі спеціальності 121 «Інженерія 
програмного забезпечення» усіх форм навчання [Текст] /Укл.: Голуб 
С.В., Заспа Г.О., Куницька С.Ю., Півень О.Б. Катаєва Є.Ю., Салапатов 
В.І., Метелап В.В., Олексюк В.В.; М-во освіти і науки України, 
Черкас, держ. технол. ун-т. - Черкаси : ЧДТУ, 2023. - 96 с. 
 
 
 
 
ДОДАТОК А 
  
 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2024 р. 
 
 
 
 
 
Розробка та оптимізація веб-сервісу для пошуку рідкісних та цікавих 
автомобілів. 
 
Специфікація 
482. ЧДТУ 24 2058.011 
Листів 2 
Розробник
 
________________
 
 
Сергієнко О.С. 
Керівник
 
________________
 
Олексюк В. В. 
 
 
2024 
 
 
 
 
Позначення Найменування Примітка 
 Документація  
482.ЧДТУ. 24 2058 12 01 Текст програми  
482.ЧДТУ. 24 2058 34 01 Інструкція користувачеві  
482.ЧДТУ. 24 2058 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 
 
 
ДОДАТОК Б  
  
  
  
  
  
  
  
  
Розробка та оптимізація веб-сервісу для пошуку рідкісних та цікавих 
автомобілів.  
   
  
  
  
  
Текст програми  
482.ЧДТУ. 24 2058 12 01 
Листів 12 
  
  
  
Розробник    ________________  Сергієнко О.С.  
 
  
  
 
 
2024 
 
 
 
 
from flask import Flask, render_template, jsonify, redirect, request, session, flash 
import psycopg2 
import psycopg2.extras 
 
app = Flask(__name__) 
app.secret_key = "caircocoders-ednalan" 
 
# Database configuration 
DB_HOST = "localhost" 
DB_NAME = "sampledb0" 
DB_USER = "postgres" 
DB_PASS = "password" 
 
conn = psycopg2.connect(dbname=DB_NAME, user=DB_USER, password=DB_PASS, 
host=DB_HOST) 
 
 
@app.route('/') 
def index(): 
    # Check if the user is logged in 
    if 'username' in session: 
        username = session['username'] 
        role = session['role'] 
        return render_template('index.html', username=username, role=role) 
    else: 
        return render_template('index.html') 
 
@app.route('/contact', methods=['GET', 'POST']) 
def contact(): 
    if 'username' in session: 
        username = session['username'] 
        role = session['role'] 
        return render_template('contact.html', username=username, role=role) 
    else: 
 
 
 
        return render_template('contact.html') 
     
    if request.method == 'POST': 
        return send_message() 
    else: 
        return render_template('contact.html') 
 
 
@app.route('/cars') 
def cars(): 
     
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
    cur.execute("SELECT * FROM carbrands ORDER BY brand_id") 
    carbrands = cur.fetchall() 
    if 'username' in session: 
        username = session['username'] 
        role = session['role'] 
        return render_template('cars.html', username=username, role=role) 
    else: 
        return render_template('cars.html', carbrands=carbrands) 
 
 
 
@app.route('/car-details') 
def car_details(): 
    return render_template('car-details.html') 
 
 
@app.route('/about-us') 
def about_us(): 
     if 'username' in session: 
        username = session['username'] 
        role = session['role'] 
        return render_template('about-us.html', username=username, role=role) 
 
 
 
     else: 
        return render_template('about-us.html') 
 
 
 
@app.route('/login', methods=['GET', 'POST']) 
def login(): 
    if request.method == 'POST': 
        username = request.form.get('username') 
        password = request.form.get('password') 
 
        # Check if the username and password are valid 
        if username and password: 
            cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
            cur.execute("SELECT * FROM users WHERE username = %s AND password = %s", 
(username, password)) 
            user = cur.fetchone() 
            cur.close() 
 
            if user: 
                # Store the user's information in the session 
                session['username'] = user['username'] 
                session['role'] = user['role'] 
                flash('Logged in successfully!', 'success') 
                return redirect('/') 
            else: 
                flash('Invalid username or password', 'error') 
                return redirect('/login') 
        else: 
            flash('Please enter both username and password', 'error') 
            return redirect('/login') 
    else: 
        return render_template('login.html') 
 
 
 
 
 
@app.route('/register', methods=['GET', 'POST']) 
def register(): 
    if request.method == 'POST': 
        username = request.form.get('username') 
        password = request.form.get('password') 
        confirm_password = request.form.get('confirm_password') 
 
        # Check if the username and password are provided and if the passwords match 
        if username and password and password == confirm_password: 
            cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
            # Check if the username is already taken 
            cur.execute("SELECT * FROM users WHERE username = %s", (username,)) 
            existing_user = cur.fetchone() 
 
            if existing_user: 
                flash('Username already exists', 'error') 
                return redirect('/register') 
            else: 
                # Create a new user 
                cur.execute("INSERT INTO users (username, password, role) VALUES (%s, %s, %s)", 
                            (username, password, 'user')) 
                conn.commit() 
                flash('Registered successfully! Please login.', 'success') 
                return redirect('/login') 
        else: 
            flash('Please enter a valid username and password, and make sure the passwords match', 
'error') 
            return redirect('/register') 
    else: 
        return render_template('register.html') 
 
@app.route("/carbrand", methods=["POST"]) 
 
 
 
def car_brand(): 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
    brand_id = request.form.get('brand_id') 
 
    if brand_id: 
        cur.execute("SELECT * FROM carmodels WHERE brand_id = %s ORDER BY car_model 
ASC", [brand_id]) 
        cars = cur.fetchall() 
        car_characteristics = [] 
 
        for car in cars: 
            car_characteristics.append({ 
                'model_id': car['model_id'], 
                'car_model': car['car_model'], 
            }) 
 
        return jsonify(car_characteristics) 
 
    return jsonify([]) 
@app.route("/carcharacteristics", methods=["POST"]) 
def car_characteristics(): 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
    brand_id = request.form.get('brand_id') 
    model_id = request.form.get('model_id') 
 
    if brand_id and model_id: 
        cur.execute("SELECT * FROM carmodels WHERE brand_id = %s AND model_id = %s", 
[brand_id, model_id]) 
        car = cur.fetchone() 
 
        if car: 
            car_characteristics = { 
 
 
 
                'car_photo': car['car_photo'], 
                'brand_name': car['brand_name'], 
                'model_id': car['model_id'], 
                'car_model': car['car_model'], 
                'body_type': car['body_type'], 
                'number_doors': car['number_doors'], 
                'price_range': car['price_range'], 
                'year': car['year'], 
                'mileage': car['mileage'], 
                'transmission': car['transmission'], 
                'fuel_type': car['fuel_type'], 
                'color': car['color'], 
                'technical_condition': car['technical_condition'], 
                'customs_cleared': car['customs_cleared'], 
                'driven_from': car['driven_from'], 
                'engine_size': car['engine_size'], 
                'engine_name': car['engine_name'], 
                'engine_hp': car['engine_hp'], 
                'location': car['location'], 
                'seller_id': car['seller_id'] 
            } 
 
            return jsonify(car_characteristics) 
 
    return jsonify({}) 
 
 
@app.route("/filter", methods=["POST"]) 
def filter_cars(): 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
    brand_id = request.form.get('brand_id') 
    model_id = request.form.get('model_id') 
    transmission = request.form.get('transmission') 
 
 
 
    body_type = request.form.get('body_type') 
    number_doors = request.form.get('number_doors') 
    min_price = request.form.get('min_price') 
    max_price = request.form.get('max_price') 
    min_year = request.form.get('min_year') 
    max_year = request.form.get('max_year') 
    min_mileage = request.form.get('min_mileage')   
    max_mileage = request.form.get('max_mileage') 
    engine_size = request.form.get('engine_size')  
    engine_name = request.form.get('engine_name')  
    engine_hp = request.form.get('engine_hp')    
    location = request.form.get('location') 
 
    query = "SELECT * FROM carmodels WHERE 1=1" 
    params = [] 
 
    if brand_id: 
        query += " AND brand_id = %s" 
        params.append(brand_id) 
    if model_id: 
        query += " AND model_id = %s" 
        params.append(model_id) 
    if transmission: 
        query += " AND transmission = %s" 
        params.append(transmission) 
    if body_type: 
        query += " AND body_type = %s"  
        params.append(body_type) 
    if number_doors: 
        query += " AND number_doors = %s"  
        params.append(number_doors) 
    if min_price: 
        query += " AND price_range >= %s" 
        params.append(min_price) 
 
 
 
    if max_price: 
        query += " AND price_range <= %s" 
        params.append(max_price) 
    if min_year: 
        query += " AND year >= %s" 
        params.append(min_year) 
    if max_year: 
        query += " AND year <= %s" 
        params.append(max_year) 
    if min_mileage: 
        query += " AND mileage >= %s" 
        params.append(min_mileage) 
    if max_mileage: 
        query += " AND mileage <= %s" 
        params.append(max_mileage) 
    if engine_size: 
        query += " AND engine_size = %s" 
        params.append(engine_size) 
    if engine_name: 
        query += " AND engine_name = %s" 
        params.append(engine_name) 
    if engine_hp: 
        query += " AND engine_hp = %s" 
        params.append(engine_hp) 
    if location: 
        query += " AND location = %s" 
        params.append(location)   
 
    query += " ORDER BY car_model ASC" 
    cur.execute(query, params) 
    cars = cur.fetchall() 
 
    filtered_cars = [] 
    for car in cars: 
 
 
 
        filtered_cars.append({ 
            'car_photo': car['car_photo'], 
            'model_id': car['model_id'], 
            'car_model': car['car_model'], 
            'body_type': car['body_type'], 
            'number_doors': car['number_doors'], 
            'price_range': car['price_range'], 
            'year': car['year'], 
            'mileage': car['mileage'], 
            'transmission': car['transmission'], 
            'fuel_type': car['fuel_type'], 
            'color': car['color'], 
            'technical_condition': car['technical_condition'], 
            'customs_cleared': car['customs_cleared'], 
            'driven_from': car['driven_from'], 
            'engine_size': car['engine_size'], 
            'engine_name': car['engine_name'], 
            'engine_hp': car['engine_hp'], 
            'location': car['location'], 
            'seller_id': car['seller_id'] 
        }) 
 
    return jsonify(filtered_cars) 
@app.route("/addcar", methods=["POST"]) 
def add_car(): 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
    brand_id = request.form.get('brand_id') 
    car_model = request.form.get('car_model') 
    body_type = request.form.get('body_type') 
    number_doors = request.form.get('number_doors') 
    price_range = request.form.get('price_range') 
    year = request.form.get('year') 
    mileage = request.form.get('mileage') 
 
 
 
    transmission = request.form.get('transmission') 
    fuel_type = request.form.get('fuel_type') 
    color = request.form.get('color') 
    technical_condition = request.form.get('technical_condition') 
    customs_cleared = request.form.get('customs_cleared') 
    driven_from = request.form.get('driven_from') 
    engine_size = request.form.get('engine_size') 
    engine_name = request.form.get('engine_name') 
    engine_hp = request.form.get('engine_hp') 
    location = request.form.get('location') 
    seller_id = request.form.get('seller_id') 
 
    query = "INSERT INTO carmodels (brand_id, car_model, body_type, number_doors, 
price_range, year, mileage, transmission, fuel_type, color, technical_condition, customs_cleared, 
driven_from, engine_size, engine_name, engine_hp, location, seller_id) VALUES (%s, %s, %s, %s, 
%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)" 
     
    cur.execute(query, (brand_id, car_model, body_type, number_doors, price_range, year, mileage, 
transmission, fuel_type, color, technical_condition, customs_cleared, driven_from, engine_size, 
engine_name, engine_hp, location, seller_id)) 
    conn.commit() 
    return redirect('/cars') 
@app.route("/deletecar", methods=["POST"]) 
def delete_car(): 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
    model_id = request.form.get('model_id') 
    query = "DELETE FROM carmodels WHERE model_id = %s" 
    cur.execute(query, [model_id]) 
    conn.commit() 
    return redirect('/cars') 
 
@app.route('/sellers', methods=['GET']) 
def get_seller_info(): 
    model_id = request.args.get('model_id')  
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
 
 
 
     
    query = "SELECT s.seller_name, s.seller_email, s.seller_phone, s.seller_location FROM sellers s 
INNER JOIN carmodels c ON s.seller_id = c.seller_id WHERE c.model_id = %s"    
    try: 
        cur.execute(query, (model_id,)) 
        seller_info = cur.fetchone() 
        if seller_info: 
            response = { 
                'seller_name': seller_info['seller_name'], 
                'seller_email': seller_info['seller_email'], 
                'seller_phone': seller_info['seller_phone'], 
                'seller_location': seller_info['seller_location'] 
            } 
        else: 
            response = { 
                'seller_name': 'Seller not found', 
                'seller_email': 'N/A', 
                'seller_phone': 'N/A', 
                'seller_location': 'N/A' 
            } 
        cur.close() 
        conn.commit() 
 
        return jsonify(response) 
    except Exception as e: 
        cur.close() 
        conn.rollback() 
        return str(e), 500 
     
@app.route('/send-message', methods=['POST']) 
def send_message(): 
    if 'message_sent' in session: 
        flash('You have already sent a message!', 'warning') 
        return redirect('/contact') 
 
 
 
 
    name = request.form.get('name') 
    subject = request.form.get('subject') 
    message = request.form.get('message') 
 
    cur = conn.cursor(cursor_factory=psycopg2.extras.DictCursor) 
    cur.execute("INSERT INTO messages (name, subject, message) VALUES (%s, %s, %s)", 
                (name, subject, message)) 
    conn.commit() 
    cur.close() 
    session['message_sent'] = True 
    flash('Message sent successfully!', 'success') 
    return redirect('/contact') 
 
@app.route('/logout') 
def logout(): 
    # Clear the session data 
    session.clear() 
    flash('Logged out successfully!', 'success') 
    return redirect('/') 
 
if __name__ == "__main__": 
    app.run(debug=True) 
 
 
 
ДОДАТОК В   
  
 
  
  
  
  
  
Розробка та оптимізація веб-сервісу для пошуку рідкісних та цікавих 
автомобілів.    
  
  
  
  
Інструкція користувачеві  
482. ЧДТУ 24 2058 34 01  
Листів 6 
  
  
  
  
Розробник    ________________   Сергієнко О.С.  
  
  
  
 
  
 
 2024 
 
 
 
На головній сторінці є кнопка справа зверху зараєструватись треба 
натиснути туди(Рисунок В 1). 
Рисунок В 1 – Головна сторінка 
 
Відкриється вікно реєстрації (Рисунок В 2) після того як вона пройде успішно 
потрібно вийти на головне меню та авторизуватись через логін (Рисунок В 3). 
 
Рисунок В 2– Сторінка реєстрації 
 
 
 
 
 
Рисунок В 3– Сторінка логіну 
 
На сторінці Cars (Рисунок В 4) реалізовано пошук авто, додавання авто та 
видалення. 
 
Рисунок В 4– Сторінка Cars 
 
Після введення параметрів пошуку та натиску на кнопку Filter Cars 
відображаються результати пошуку (Рисунок В 5). 
 
 
 
 
Рисунок В 5– Результати пошуку 
 
Результати пошуку відображають авто (Рисунок В 6)  його фото та характеристики 
та при натиску на кнопку Show Seller Info відображає інформацію про продавця. 
Адміністратор має право видаляти авто на кнопку Delete Car. 
 
Рисунок В 6– Відображення авто 
 
 
 
 
 
Користувач має можливість додавати авто до бази даних авто. (Рисунок В 7) 
 
Рисунок В 7– Форма додавання авто 
 
На сторінці About Us (Рисунок В 8) відображається інформація про для кого 
створений веб-сервіс. 
 
Рисунок В 8– Сторінка About Us 
 
 
 
На сторінці Contact us (Рисунок В 9) користувач може відправляти повідомлення 
з відгуками про веб-сервіс за допомогою форми (Рисунок В 10) для покращення 
його функціоналу. 
 
Рисунок В 9– Сторінка Contact us 
 
 
Рисунок В 10– форма для надсилання відгуків 
 
 
 
В футері(нижня частина сторінки) (Рисунок В 11)  кожної сторінки реалізовані 
додаткові переходи по сторінкам веб-сервісу, а також відображено інформацію 
для контактування з розробником та посилання на його сторінки в соціальні 
мережі. 
 
Рисунок В 11– Футер 
 
 
 
 
ДОДАТОК Г 
  
  
  
  
  
  
Розробка та оптимізація WEB-сервісу для пошуку рідкісних та цікавих 
автомобілів.  
 
   
  
Графічні матеріали  
482.ЧДТУ. 24 2058 90 01  
Листів 9  
  
  
  
  
 Розробник    ________________      Сергієнко О.С. 
  
  
 
   
 
 
 
 
2024 
 
 
 
 
 
Рисунок Г 1 – Слайд 1 
 
 
Рисунок Г 2 – Слайд 2 
 
 
 
 
 
Рисунок Г 3 – Слайд 3 
 
 
Рисунок Г 4 – Слайд 4 
 
 
 
 
 
Рисунок Г 5 – Слайд 5 
 
 
Рисунок Г 6 – Слайд 6 
 
 
 
 
 
Рисунок Г 7 – Слайд 7 
 
 
Рисунок Г 8 – Слайд 8 
 
 
 
 
 
Рисунок Г 9 – Слайд 9 
 
Рисунок Г 10 – Слайд 10 
 
 
 
 
 
Рисунок Г 11 – Слайд 11 
 
 
Рисунок Г 12 – Слайд 12 
 
 
 
 
 
 
Рисунок Г 13 – Слайд 13 
 
 
Рисунок Г 14 – Слайд 14 
 
 
 
 
 
Рисунок Г 15 – Слайд 15 
 
 
Рисунок Г 16 – Слайд 16
Репозиторій ЧДТУ
