Програмна реалізація персонального користувацького середовища у web- сервісі доставки їжі

Кузнєцов, Максим Олександрович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9765

Full metadata record

DC Field	Value	Language
dc.contributor.advisor	Метелап , Володимир Володимирович	-
dc.contributor.author	Кузнєцов, Максим Олександрович	-
dc.date.accessioned	2026-07-01T18:31:20Z	-
dc.date.available	2026-07-01T18:31:20Z	-
dc.date.issued	2026-06-17	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9765	-
dc.description.abstract	АНОТАЦІЯ Кузнєцов М.О. «Програмна реалізація персонального користувацького середовища у web сервісі доставки їжі». Кваліфікаційна робота бакалавра за спеціальністю 121 «Інженерія програмного забезпечення». – Черкаський державний технологічний університет, Черкаси, 2026. Об'єкт розробки – процес автоматизації замовлення та доставки страв із ресторану через веб-інтерфейс. Мета роботи – проектування та розробка веб-застосунку системи замовлення та доставки їжі, що забезпечує зручний перегляд меню, оформлення замовлень, відстеження їхнього статусу та адміністрування системи. У роботі проведено аналіз існуючих платформ доставки їжі, виконано проектування предметної області з використанням UML-діаграм, розроблено веб-застосунок на базі фреймворку Flask (Python), реалізовано реляційну базу даних SQLite засобами SQLAlchemy. Система забезпечує реєстрацію та авторизацію користувачів, перегляд меню, управління кошиком, оформлення замовлень, відстеження статусу, а також адміністративну панель для управління меню та замовленнями. Практичне значення роботи полягає у можливості впровадження розробленого застосунку у заклади ресторанного бізнесу для автоматизації процесів прийому та обробки замовлень.	uk_UA
dc.description.abstract	ABSTRACT Kuznietsov M.O. "Web Application for Food Ordering and Delivery System". Bachelor's Qualification Work, Specialty 121 "Software Engineering". – Cherkasy State Technological University, Cherkasy, 2026. The object of development is the process of automating food ordering and delivery from a restaurant through a web interface. The purpose of the work is to design and develop a web application for a food ordering and delivery system that provides convenient menu browsing, order placement, order status tracking, and system administration. The work includes an analysis of existing food delivery platforms, domain modeling using UML diagrams, development of a web application based on the Flask (Python) framework, and implementation of a relational SQLite database using SQLAlchemy. The system provides user registration and authentication, menu browsing, shopping cart management, order placement and tracking, as well as an administrative panel for menu and order management.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	WEB-застосунок	uk_UA
dc.subject	доставка їжі	uk_UA
dc.subject	FLASK	uk_UA
dc.subject	SQLALCHEMY	uk_UA
dc.subject	UML	uk_UA
dc.subject	REST	uk_UA
dc.subject	замовлення	uk_UA
dc.subject	інформаційна система	uk_UA
dc.subject	WEB APPLICATION	uk_UA
dc.subject	FOOD DELIVERY	uk_UA
dc.subject	FLASK	uk_UA
dc.subject	SQLALCHEMY	uk_UA
dc.subject	UML	uk_UA
dc.subject	REST	uk_UA
dc.subject	ORDER	uk_UA
dc.subject	INFORMATION SYSTEM	uk_UA
dc.title	Програмна реалізація персонального користувацького середовища у web- сервісі доставки їжі	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:

File	Description	Size	Format
Кваліфікаційев робота бакалавра Кузнецов Максим Олександрович.pdf Restricted Access		1.89 MB	Adobe PDF	View/Open Request a copy

Show simple item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ
ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Програмна реалізація персонального користувацького середовища
у web сервісі доставки їжі»
Виконав: студент 4 курсу, групи
ПЗ-2204
спеціальності 121 «Інженерія
програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Кузнєцов М.О.__________
(прізвище та ініціали)
Керівник Метелап В.В.__________
(прізвище та ініціали)
Рецензент Захарова М.В.
(прізвище та ініціали)
Черкаси 2026

Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення

ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
______________________С. Голуб
«___» _______________ 2026 року

З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кузнєцов Максим Олександрович
(прізвище, ім’я, по батькові)
1. Тема роботи: «Програмна реалізація персонального користувацького середовища у web-
сервісі доставки їжі»
Керівник проекту (роботи) к.т.н., доцент Метелап Володимир Володимирович,
Затверджені наказом Черкаського державного технологічного університету №56/03-03
від «12» березня 2026 року
2. Строк подання студентом роботи 12 червня 2026
3. Вхідні дані до роботи: web-сервіс доставки їжі з персональним користувацьким
середовищем, можливістю реєстрації та авторизації користувачів, перегляду меню
закладів, формування замовлень, налаштування особистого кабінету, збереження історії
замовлень, керування адресами доставки та відображення актуального статусу
замовлення
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результату дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток В – Інструкція користувача_________________________________________
Додаток Г – Графічні матеріали_____________________________________________

6. Консультанти розділів роботи
7. Дата видачі завдання 2 грудня 2025 року.

КАЛЕНДАРНИЙ ПЛАН
Строк виконання
етапів
№ випускної роботи
Назва етапів випускної роботи Примітки
п/п
1 Постановка задачі вересень виконано
2 Підготовка завдання вересень виконано
3 Погодження завдання вересень виконано
4 Затвердження завдання жовтень виконано
Основна стадія жовтень
1 Підбір матеріалів жовтень виконано
2 Аналіз шляхів вирішення поставленої задачі листопад виконано
3 Розрахунок основних параметрів роботи листопад виконано
4 Вибір кінцевого варіанту проектного рішення січень виконано
5 Оформлення первісної редакції роботи січень виконано
Заключна стадія березень
1 Узгодження прийнятих проектних рішень з травень виконано
керівником
2 Оформлення пояснювальної записки роботи в червень виконано
кінцевій редакції
3 Попередній захист роботи червень виконано
4 Затвердження роботи червень виконано
5 Рецензування роботи червень виконано
6 Захист роботи червень

Студент _____________________ Кузнєцов М.О.
(підпис) (прізвище та ініціали)

Керівник роботи _____________________ Метелап В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ

Кузнєцов М.О. «Програмна реалізація персонального користувацького
середовища у web сервісі доставки їжі». Кваліфікаційна робота бакалавра за
спеціальністю 121 «Інженерія програмного забезпечення». – Черкаський
державний технологічний університет, Черкаси, 2026.
Об'єкт розробки – процес автоматизації замовлення та доставки страв із
ресторану через веб-інтерфейс.
Мета роботи – проектування та розробка веб-застосунку системи
замовлення та доставки їжі, що забезпечує зручний перегляд меню,
оформлення замовлень, відстеження їхнього статусу та адміністрування
системи.
У роботі проведено аналіз існуючих платформ доставки їжі, виконано
проектування предметної області з використанням UML-діаграм, розроблено
веб-застосунок на базі фреймворку Flask (Python), реалізовано реляційну базу
даних SQLite засобами SQLAlchemy. Система забезпечує реєстрацію та
авторизацію користувачів, перегляд меню, управління кошиком, оформлення
замовлень, відстеження статусу, а також адміністративну панель для
управління меню та замовленнями.
Практичне значення роботи полягає у можливості впровадження
розробленого застосунку у заклади ресторанного бізнесу для автоматизації
процесів прийому та обробки замовлень.

Ключові слова: WEB-застосунок, доставка їжі, FLASK, SQLALCHEMY,
UML, REST, замовлення, інформаційна система.

ABSTRACT

Kuznietsov M.O. "Web Application for Food Ordering and Delivery System".
Bachelor's Qualification Work, Specialty 121 "Software Engineering". – Cherkasy
State Technological University, Cherkasy, 2026.
The object of development is the process of automating food ordering and
delivery from a restaurant through a web interface.
The purpose of the work is to design and develop a web application for a food
ordering and delivery system that provides convenient menu browsing, order
placement, order status tracking, and system administration.
The work includes an analysis of existing food delivery platforms, domain
modeling using UML diagrams, development of a web application based on the
Flask (Python) framework, and implementation of a relational SQLite database
using SQLAlchemy. The system provides user registration and authentication, menu
browsing, shopping cart management, order placement and tracking, as well as an
administrative panel for menu and order management.

Keywords: WEB APPLICATION, FOOD DELIVERY, FLASK, SQLALCHEMY,
UML, REST, ORDER, INFORMATION SYSTEM.

ЗМІСТ
ВСТУП ..................................................................................................................... 9
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ............................................................................................................... 11
1.1. Актуальні проблеми, що виникають в процесі виконання завдань ...... 11
1.2. Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань ............................................................................................. 12
1.3. Конкретизація завдань роботи .................................................................. 13
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ ......................................................... 15
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ................................................................................................................ 16
2.1. Моделювання предметної області ............................................................ 16
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ........................................................................ 16
2.1.2. Елементи моделювання предметної області .................................... 17
2.1.3. Робоча область моделювання ............................................................ 19
2.2. Формування та аналіз вимог ..................................................................... 20
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги ............................................................................... 20
2.2.2. Формування вимог за допомогою діаграми прецедентів................ 23
2.3. Проектування логічної структури програмного комплексу .................. 26
2.3.1. Діаграми класів .................................................................................... 26
2.3.2. Діаграми пакетів .................................................................................. 28
2.4. Архітектурне проектування ...................................................................... 30
2.4.1. Діаграма компонентів ......................................................................... 30
2.4.2. Розгортання програмної системи на апаратних засобах. ................ 31
2.5. Моделювання поведінки системи ............................................................ 32
2.5.1. Діаграма діяльності ............................................................................. 32

ЧДТУ 26.2246.008 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Кузнєцов М.О. Програмна реалізація Літ. Лист Листів
Перевір. Метелап В.В. персонального користувацького 3
Рецензент середовища у web-сервісі
Н. Контр. Півень О.Б. доставки їжі ФІТІС, кафедра ПЗАС, ПЗ-2204
Затверд. Голуб С.В.

2.5.2. Діаграма послідовності ....................................................................... 34
2.5.3. Діаграма комунікації ........................................................................... 35
2.5.4. Діаграма скінченного автомату ......................................................... 36
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ ........................................................... 38
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
................................................................................................................................. 40
3.1. Розробка програмного комплексу ............................................................ 40
3.1.1. Обґрунтування вибору засобів реалізації ......................................... 40
3.1.2. Опис структурної (функціональної) схеми ...................................... 41
3.1.3. Опис логічної схеми системи ............................................................. 42
3.1.4. Розробка бази даних ............................................................................ 44
3.1.5. Розробка інтерфейсу користувача ..................................................... 45
3.1.6. Опис розробки програмних компонентів ......................................... 48
3.2. Тестування системи ................................................................................... 49
3.2.1. Модульне тестування .......................................................................... 49
3.2.2. Інтеграційне тестування ..................................................................... 50
3.2.3. Системне тестування .......................................................................... 52
3.2.4. Приймальне тестування ...................................................................... 53
3.3. Приклади впровадження програмного комплексу ................................. 55
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ ........................................................ 57
ВИСНОВКИ ........................................................................................................... 58
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 60
ДОДАТКИ .............................................................................................................. 64

ЧДТУ 26.2246.008 ПЗ
Змн. Арк. № докум. Підпис Дата

482.ЧДТУ 26.2246.008 ПЗ
ВСТУП
Актуальність теми. Сучасний розвиток інженерії програмного
забезпечення характеризується постійним зростанням складності та вимог до веб-
застосунків, особливо у сфері електронної комерції та сервісів доставки. Згідно з
даними Statista, глобальний ринок онлайн-доставки їжі у 2024 році перевищив 1,4
трлн доларів США зі щорічним зростанням понад 10% [1, 2]. В Україні
спостерігається аналогічна тенденція: збільшення кількості користувачів
мобільних пристроїв та попит на швидкі та зручні сервіси призвели до активного
розвитку платформ доставки.
Проте більшість готових рішень (Glovo, Uber Eats, Bolt Food) є закритими
SaaS-платформами з високою комісією (15–30%), обмеженими можливостями
кастомізації та залежністю від зовнішньої інфраструктури. Для малого та
середнього ресторанного бізнесу це створює суттєві проблеми: відсутність
контролю над даними клієнтів, неможливість глибокої інтеграції з внутрішніми
процесами закладу та високі експлуатаційні витрати.
З точки зору інженерії програмного забезпечення актуальність теми полягає
в необхідності розробки сучасного веб-застосунку, який поєднує:
− ефективне об’єктно-орієнтоване моделювання предметної області з
використанням UML;
− гнучку архітектуру на базі шаблону MVC;
− надійну роботу з даними через ORM-технології;
− сучасні підходи до безпеки (хешування паролів, захист від CSRF,
авторизація);
− адаптивний та зручний користувацький інтерфейс;
− комплексне тестування на всіх рівнях (unit, integration, system,
acceptance).
Розробка власного веб-застосунку дозволяє не тільки автоматизувати
процеси замовлення та доставки їжі, але й демонструє застосування сучасних
методів, засобів і практик інженерії програмного забезпечення для вирішення
9
482 ЧДТУ 26.2246.008 ПЗ
реальних бізнес-задач.
Мета і завдання розробки. Метою кваліфікаційної роботи є проектування
та розробка веб-застосунку системи замовлення та доставки їжі, що забезпечує
повний цикл – від перегляду меню до відстеження доставки. Для досягнення мети
поставлено такі завдання:
– проаналізувати існуючі платформи та технології доставки їжі;
– сформувати вимоги до програмного забезпечення;
– виконати моделювання предметної області засобами UML;
– розробити архітектуру системи та спроектувати базу даних;
– реалізувати веб-застосунок з використанням фреймворку Flask;
– провести тестування розробленої системи.
Об'єкт розробки – проектування та конструювання програмного
забезпечення веб-платформи для автоматизації діяльності служби доставки їжі,
що включає розроблення архітектури системи, програмних модулів обробки
замовлень, механізмів взаємодії користувачів із системою та засобів управління
даними.
Предмет розробки – методи та засоби проектування і конструювання веб-
застосунків для систем замовлення та доставки їжі.
Методи проектування та конструювання. У роботі використано:
об'єктно-орієнтований аналіз і проектування – для побудови моделі предметної
області; UML-моделювання – для опису статичної та динамічної структури
системи; методологія MVC (Model-View-Controller) – для організації архітектури
застосунку; реляційне моделювання – для проектування бази даних; методи
чорного та білого ящиків – при тестуванні.
Практичне значення отриманих результатів. Розроблений веб-
застосунок може бути впроваджений у заклади ресторанного бізнесу як
самостійне рішення для автоматизації процесів замовлення та доставки їжі без
залежності від сторонніх платформ-агрегаторів.
Особистий внесок автора. Весь комплекс проектування, розробки та
тестування програмного забезпечення виконано автором самостійно.
10
482 ЧДТУ 26.2246.008 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Актуальні проблеми, що виникають в процесі виконання завдань
Сучасний розвиток інформаційних технологій зумовлює постійне
зростання вимог до програмного забезпечення, яке використовується для
автоматизації бізнес-процесів у різних предметних областях. Особливо важливим
це є для веб-застосунків, які автоматизують бізнес-процеси та забезпечують
взаємодію великої кількості користувачів через мережу Інтернет [3].
Першою та найбільш суттєвою проблемою є відсутність єдиного
інтегрованого середовища для управління замовленнями. Більшість невеликих
закладів харчування використовують паперові носії або базові засоби (електронні
таблиці, месенджери), що не забезпечують оперативної обробки замовлень та
призводять до помилок [4].
Другою проблемою є висока вартість підключення до агрегаторів доставки
їжі (Glovo, Bolt Food, Uber Eats). Комісія таких платформ, за даними аналітиків,
сягає 15–30% від вартості замовлення, що суттєво знижує рентабельність бізнесу
[5].
Третьою проблемою є складність управління замовленнями в режимі
реального часу. Необхідно синхронізувати статуси замовлень між замовником,
кухнею та кур'єром, що без відповідного програмного забезпечення є вкрай
складним завданням [6].
Четвертою проблемою є відсутність зворотного зв'язку та аналітики.
Ресторани потребують даних про популярність страв, пікові години замовлень,
географію доставок тощо для прийняття управлінських рішень [7].
П'ятою проблемою є безпека персональних даних користувачів та
платіжних транзакцій. Відповідно до регламенту GDPR та вітчизняного
законодавства, обробка персональних даних вимагає відповідних технічних
засобів захисту [8].
Таким чином, актуальним є розробка власного веб-застосунку для системи
11
482 ЧДТУ 26.2246.008 ПЗ
замовлення та доставки їжі, який забезпечує управління меню, обробку
замовлень, відстеження статусів та адміністративне управління системою.
1.2. Методи та засоби, які вже використовуються для усунення проблем
та виконання завдань
На сучасному ринку існує значна кількість платформ та технологічних
рішень для автоматизації доставки їжі. Розглянемо основні з них [9].
Glovo – іспанська платформа доставки, що працює у понад 25 країнах,
зокрема в Україні. Забезпечує кур'єрську логістику та агрегацію ресторанних
партнерів. Переваги: велика база клієнтів, готова інфраструктура. Недоліки:
висока комісія (20–30%), залежність від умов платформи, відсутність брендингу
для ресторану [10].
Uber Eats – глобальна платформа, що використовує алгоритми машинного
навчання для оптимізації маршрутів доставки. Переваги: потужна технологічна
база, міжнародне охоплення. Недоліки: висока конкурентність, стандартизований
інтерфейс без можливості кастомізації [11].
Bolt Food – естонська платформа, що вийшла на ринок України у 2019 році.
Відрізняється нижчими комісійними порівняно з конкурентами. Недоліки: менша
база клієнтів у регіонах, обмежені можливості аналітики [12].
iiko – спеціалізована система автоматизації ресторанного бізнесу. Охоплює
касові операції, складський облік, управління замовленнями. Переваги:
комплексне рішення. Недоліки: висока вартість ліцензії, складність впровадження
[13].
Власні веб-застосунки на базі відкритих фреймворків (Django, Flask,
Laravel, Node.js). Забезпечують повний контроль над функціональністю,
відсутність комісій, можливість інтеграції з будь-якими сервісами. Недоліки:
вимагають ресурсів на розробку та підтримку.
Порівняльний аналіз існуючих рішень наведено у таблиці 1.1.
Таблиця 1.1
Порівняльний аналіз існуючих рішень
12
482 ЧДТУ 26.2246.008 ПЗ
Критерій Glovo Uber Eats Bolt Food Власна
розробка
Комісія 20-30% 25-30% 15-25% 0%
Кастомізація Ні Ні Мінімальна Повна
Вартість Висока Висока Середня Одноразова
Аналітика Базова Розширена Базова Гнучка
Незалежність Ні Ні Ні Так

Для реалізації серверної частини веб-застосунків широко
використовуються такі технології [14]:
– Flask (Python) – мікрофреймворк для розробки веб-застосунків,
відрізняється простотою та гнучкістю;
– Django (Python) – повноцінний фреймворк з вбудованою
адміністративною панеллю;
– Node.js (JavaScript) – платформа для розробки серверних застосунків на
основі асинхронної моделі;
– Laravel (PHP) – фреймворк з розгалуженою екосистемою компонентів.
Для зберігання даних використовуються реляційні СУБД (PostgreSQL,
MySQL, SQLite) та нереляційні бази даних (MongoDB, Redis). У проектах малого
та середнього масштабу широко застосовується SQLite завдяки простоті
налаштування та відсутності необхідності у виділеному сервері [15].
1.3. Конкретизація завдань роботи
На підставі проведеного аналізу існуючих рішень та виявлених проблем
конкретизовано такі завдання кваліфікаційної роботи:
– розробити веб-застосунок системи замовлення та доставки їжі,
орієнтований на малий ресторанний бізнес без залежності від зовнішніх
агрегаторів;
– реалізувати підсистему управління меню з підтримкою категорій,
зображень та цінової інформації;
13
482 ЧДТУ 26.2246.008 ПЗ
– забезпечити повний цикл обробки замовлень: від оформлення до
доставки з відстеженням статусів;
– розробити систему реєстрації та авторизації користувачів з
розмежуванням ролей (клієнт, адміністратор);
– реалізувати адміністративну панель для управління меню,
замовленнями та користувачами;
– провести комплексне тестування розробленого застосунку.
Для реалізації обрано технологічний стек: Flask 2.3 (Python) – серверна
частина, SQLite + SQLAlchemy 2.0 – база даних, Jinja2 – шаблонізатор для HTML,
Bootstrap 5 – CSS-фреймворк для інтерфейсу [16].
Застосунок розроблено за архітектурним шаблоном MVC (Model-View-
Controller), що забезпечує розділення відповідальності між компонентами
системи та спрощує підтримку і масштабування коду [17].

14
482 ЧДТУ 26.2246.008 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто основні поняття, пов’язані з WEB-
сервісами для замовлення та доставки їжі, проведено аналіз існуючих рішень на
ринку, а також описано технології, які використовуються для їх реалізації. Було
виявлено, що власні вебзастосунки надають закладам громадського харчування
зручний, автономний та економічно вигідний спосіб взаємодії зі споживачами,
особливо завдяки повній незалежності від сторонніх посередників та відсутності
транзакційних комісій.
Проаналізовані приклади існуючих рішень та платформ, зокрема
глобальних агрегаторів Glovo, Uber Eats та Bolt Food, а також спеціалізованої
системи автоматизації ресторанного бізнесу iiko, дозволили виокремити їх сильні
та слабкі сторони. Це дало змогу сформулювати чітке бачення функціоналу, якого
має досягти власний WEB-сервіс, а також уникнути поширених недоліків
аналогічних рішень, таких як високі фінансові витрати на підключення,
відсутність унікального брендингу та обмежені можливості кастомізації логіки.
У розділі також охарактеризовано сучасні методи та засоби реалізації
серверної та клієнтської частин вебзастосунків, зокрема використання мови
програмування Python, мікрофреймворку Flask (версії 2.3), інструментів безпеки
Werkzeug та Flask-WTF, шаблонізатора Jinja2, CSS-фреймворку Bootstrap 5, а
також технології ORM SQLAlchemy 2.0 для взаємодії з базами даних SQLite та
PostgreSQL. Це дозволяє забезпечити ефективну маршрутизацію запитів,
безпечне збереження конфіденційних даних користувачів, адаптивність
інтерфейсу для мобільних пристроїв та гнучке масштабування архітектури за
шаблоном MVC (Model-View-Controller).
У результаті було сформульовано чітке технічне завдання та
конкретизовано завдання для реалізації WEB-сервісу доставки їжі, який буде
орієнтований на користувацький комфорт, гнучкість адміністрування меню,
автоматизацію життєвого циклу замовлень і стабільність роботи системи. У
подальших розділах буде здійснено безпосереднє проєктування, програмну
розробку та комплексне тестування такого програмного рішення.
15
482 ЧДТУ 26.2246.008 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область системи замовлення та доставки їжі охоплює процеси,
пов'язані з переглядом меню ресторану, формуванням замовлень, їх обробкою та
доставкою кінцевому споживачу [18].
Модель предметної області є діаграмою класів, що відображає
концептуальні об'єкти (іменники) предметної області та їх взаємозв'язки без
детального опису атрибутів та методів. Таку модель також називають
концептуальною моделлю або доменною моделлю [19].
Основні концептуальні класи системи:
– користувач (User) – зареєстрований клієнт системи, що здійснює
замовлення;
– категорія (Category) – група страв за типом (супи, салати, гарячі страви
тощо);
– пункт меню (MenuItem) – окрема страва з назвою, описом, ціною та
зображенням;
– кошик (CartItem) – тимчасовий накопичувач обраних страв перед
оформленням замовлення;
– замовлення (Order) – підтверджений перелік страв з адресою доставки
та статусом;
– позиція замовлення (OrderItem) – окремий рядок замовлення із
зазначенням кількості та ціни;
– відгук (Review) – оцінка та коментар клієнта щодо страви;
– адміністратор (Admin) – привілейований користувач системи.
Словник предметної області містить такі ключові терміни: замовлення
16
482 ЧДТУ 26.2246.008 ПЗ
(order) – підтверджений запит на приготування та доставку страв; статус
замовлення (order status) – поточний стан обробки (очікує підтвердження,
готується, доставляється, доставлено, скасовано); кошик (cart) – тимчасовий
перелік обраних страв до оформлення замовлення; адреса доставки (delivery
address) – місце призначення для кур'єра.

Рисунок 2.1 — Модель предметної області (концептуальна діаграма класів)

2.1.2. Елементи моделювання предметної області
17
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 2.2 — Фрагмент діаграми класів предметної області з асоціаціями та
атрибутами

18
482 ЧДТУ 26.2246.008 ПЗ
Для моделювання предметної області системи замовлення та доставки їжі
використовуються стандартні елементи UML-нотації [20].
Класи (Classes) – основні будівельні блоки моделі, що описують об'єкти
предметної області. У системі виділено 8 основних класів: User, Category,
MenuItem, CartItem, Order, OrderItem, Review, та абстрактний клас Base для
спільних атрибутів.
Асоціації (Associations) – зв'язки між класами, що відображають відносини
між об'єктами. У системі наявні такі асоціації:
– User «має» Order – один користувач може мати багато замовлень (1:N);
– User «має» Review – один користувач може залишати багато відгуків
(1:N);
– User «має» CartItem – один користувач може мати кілька позицій у
кошику (1:N);
– Order «містить» OrderItem – одне замовлення містить кілька позицій
(1:N);
– MenuItem «належить до» Category – кожна страва належить до однієї
категорії (N:1);
– OrderItem «посилається на» MenuItem – позиція замовлення посилається
на страву (N:1);
– Review «посилається на» MenuItem – відгук стосується конкретної
страви (N:1).
Кратності (Multiplicities) – визначають кількість об'єктів, що можуть брати
участь у зв'язку. Використано стандартні позначення: 1 (рівно один), 0..1 (не
більше одного), * або 0..* (нуль або більше), 1..* (один або більше).
Атрибути (Attributes) – характеристики класів. Кожен клас має такі ключові
атрибути: User (id, username, email, password_hash, phone, address, role, created_at),
MenuItem (id, name, description, price, image, is_available, rating), Order (id,
order_number, total_amount, status, delivery_address, created_at).
2.1.3. Робоча область моделювання
Робоча область моделювання охоплює межі системи та взаємодію із
19
482 ЧДТУ 26.2246.008 ПЗ
зовнішніми акторами. Система замовлення та доставки їжі функціонує у веб-
середовищі та взаємодіє з такими зовнішніми об'єктами [21]:
– браузер клієнта – точка доступу для кінцевих користувачів (клієнтів та
адміністраторів);
– поштовий сервер – для відправлення підтверджень замовлень;
– файлова система – для зберігання зображень страв меню;
– SQLite СУБД – для постійного зберігання даних системи.
Система реалізована як монолітний веб-застосунок відповідно до
архітектурного шаблону MVC. Серверна частина (Flask) обробляє HTTP-запити,
виконує бізнес-логіку та повертає HTML-відповіді, сформовані шаблонізатором
Jinja2 [22].
Межі системи визначаються такими функціональними блоками: підсистема
автентифікації (реєстрація, вхід, вихід), підсистема перегляду меню (категорії,
пошук, деталі страв), підсистема замовлень (кошик, оформлення, відстеження),
підсистема відгуків, адміністративна підсистема (управління меню,
замовленнями, користувачами).
2.2. Формування та аналіз вимог
У цьому розділі акцентована увага на формуванні та аналізі вимог до WEB
сервісу доставки їжі, що є важливим етапом у процесі розробки будь якого
програмного комплексу. Вимоги визначають, що система WEB сервісу повинна
робити, і як вона повинна працювати.
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
У цьому розділі акцентована увага на формуванні та аналізі вимог до WEB
сервісу доставки їжі, що є важливим етапом у процесі розробки будь якого
програмного комплексу. Вимоги визначають, що система WEB сервісу повинна
робити, і як вона повинна працювати.
Первинні вимоги до системи замовлення та доставки їжі сформовані на
20
482 ЧДТУ 26.2246.008 ПЗ
основі аналізу предметної області, потреб потенційних замовників та
конкурентного аналізу існуючих рішень [23].
Первинні вимоги:
– система повинна надавати можливість перегляду меню ресторану з
фільтрацією за категоріями;
– клієнти повинні мати можливість реєструватися та авторизуватися;
– повинна бути реалізована функціональність кошика та оформлення
замовлень;
– система повинна відображати статус замовлення в реальному часі;
– адміністратор повинен мати можливість управляти меню та
замовленнями.
Деталізовані вимоги розроблені на основі первинних та включають
конкретні сценарії використання:
– клієнт може переглядати меню без реєстрації, але для оформлення
замовлення реєстрація обов'язкова;
– система підтримує 7 категорій страв: салати, супи, гарячі страви, піца,
паста, десерти, напої;
– у кошик можна додавати кілька одиниць однієї страви з можливістю
зміни кількості;
– замовлення проходить 6 статусів: pending → confirmed → preparing →
delivering → delivered → cancelled;
– адміністратор може додавати, редагувати, видаляти позиції меню та
змінювати статуси замовлень;
– клієнт може залишати відгуки та оцінки (1–5 зірок) до замовлених страв.
Вимоги замовника і розробника
Вимоги поділяються на вимоги замовника (бізнес-вимоги) та вимоги
розробника (технічні вимоги) [24].
Вимоги замовника:
– зручний та інтуїтивно зрозумілий інтерфейс для клієнтів;
– можливість відстеження замовлення клієнтом;
21
482 ЧДТУ 26.2246.008 ПЗ
– простота управління меню адміністратором без технічних знань;
– відображення замовлень у порядку пріоритетності для кухні.
Вимоги розробника (технічні вимоги) формуються на основі бізнес-потреб
замовника та специфіки предметної області. Вони визначають архітектурний
каркас, правила обробки даних, обмеження безпеки та критерії стабільності, що
забезпечують працездатність WEB-сервісу доставки їжі в реальних умовах
експлуатації. Технічні вимоги розробника поділяються на дві ключові категорії:
функціональні (опис логіки та внутрішніх алгоритмів роботи модулів) та
нефункціональні (системні обмеження, продуктивність, масштабованість та стек
технологій).
Функціональні вимоги (FR):
– FR-01: реєстрація та авторизація користувачів із шифруванням паролю;
– FR-02: перегляд меню з фільтрацією за категоріями та пошуком;
– FR-03: управління кошиком (додавання, видалення, зміна кількості);
– FR-04: оформлення замовлення з вибором адреси та способу оплати;
– FR-05: відстеження статусу замовлення клієнтом;
– FR-06: управління меню адміністратором (CRUD-операції);
– FR-07: управління замовленнями адміністратором зі зміною статусів;
– FR-08: система відгуків та рейтингу страв;
– FR-09: особистий кабінет клієнта з історією замовлень.
Нефункціональні вимоги (NFR):
– NFR-01: час відповіді сервера не більше 2 секунд для стандартних
запитів;
– NFR-02: адаптивний інтерфейс для мобільних пристроїв (Bootstrap 5);
– NFR-03: безпека – хешування паролів (Werkzeug), захист від CSRF
(Flask-WTF);
– NFR-04: масштабованість – можливість переходу з SQLite на
PostgreSQL без зміни коду;
– NFR-05: доступність – підтримка браузерів Chrome, Firefox, Safari
останніх двох версій.
22
482 ЧДТУ 26.2246.008 ПЗ

Таблиця 2.1
Реєстр вимог до системи
ID Тип Опис вимоги Пріоритет
FR-01 Функціональна Реєстрація та Високий
авторизація
FR-02 Функціональна Перегляд і пошук Високий
меню
FR-03 Функціональна Управління кошиком Високий
FR-04 Функціональна Оформлення Високий
замовлення
FR-05 Функціональна Відстеження Середній
замовлення
FR-06 Функціональна Управління меню Високий
(адмін)
FR-07 Функціональна Управління Високий
замовленнями (адмін)
NFR-01 Нефункціональна Час відповіді ≤ 2 с Середній
NFR-02 Нефункціональна Адаптивний Середній
інтерфейс
NFR-03 Нефункціональна Безпека та захист Високий
даних

2.2.2. Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів (Use Case Diagram) є основним засобом специфікації
функціональних вимог до системи в UML. Вона описує взаємодію між акторами
та прецедентами (варіантами використання) системи [25].
Актори системи:
– неавторизований користувач – може переглядати меню та виконувати
23
482 ЧДТУ 26.2246.008 ПЗ
пошук;
– клієнт (зареєстрований) – має доступ до всіх клієнтських функцій;
– адміністратор – має повний доступ до всіх функцій системи.

Рисунок 2.4 — Діаграма прецедентів системи замовлення та доставки їжі
24
482 ЧДТУ 26.2246.008 ПЗ

Прецеденти для клієнта: UC-01 Реєстрація, UC-02 Авторизація, UC-03
Перегляд меню, UC-04 Пошук страв, UC-05 Перегляд деталей страви, UC-06
Додавання до кошика, UC-07 Управління кошиком, UC-08 Оформлення
замовлення, UC-09 Відстеження замовлення, UC-10 Перегляд історії замовлень,
UC-11 Залишення відгуку, UC-12 Редагування профілю.
Прецеденти для адміністратора: UC-13 Перегляд панелі керування, UC-14
Управління меню, UC-15 Управління замовленнями, UC-16 Управління
користувачами.
Специфікація прецеденту UC-08 «Оформлення замовлення» наведена у
таблиці 2.2.

Таблиця 2.2
Специфікація прецеденту UC-08 «Оформлення замовлення»
Поле Опис
Назва Оформлення замовлення
Актор Клієнт (зареєстрований)
Передумова Клієнт авторизований, кошик містить хоча б одну
позицію
Основний сценарій 1. Клієнт переходить на сторінку оформлення
замовлення. 2. Система відображає вміст кошика та
суму. 3. Клієнт вводить адресу доставки та обирає
спосіб оплати. 4. Клієнт підтверджує замовлення. 5.
Система генерує номер замовлення, зберігає дані,
очищає кошик. 6. Система відображає
підтвердження.
Альтернативний Якщо поля заповнені некоректно – система виводить
сценарій помилки та не приймає замовлення
Постумова Замовлення зі статусом «pending» збережено у БД,
клієнт отримав підтвердження
25
482 ЧДТУ 26.2246.008 ПЗ

2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграми класів
Діаграма класів є центральною діаграмою статичного моделювання в UML.
На відміну від моделі предметної області, вона деталізує атрибути, методи та їх
видимість [26].
Система складається з таких класів реалізації:
User – модель користувача. Атрибути: id: Integer (PK), username: String(80),
email: String(120) [unique], password_hash: String(200), phone: String(20), address:
String(200), role: String(20) [default: 'user'], created_at: DateTime. Методи:
set_password(password: str): void, check_password(password: str): bool. Зв'язки: 1:N
з Order, Review, CartItem.
Category – категорія страв. Атрибути: id: Integer (PK), name: String(50), icon:
String(50). Зв'язки: 1:N з MenuItem.
MenuItem – позиція меню. Атрибути: id: Integer (PK), name: String(100),
description: Text, price: Float, image: String(200), category_id: Integer (FK),
is_available: Boolean [default: True], rating: Float [default: 0.0], created_at: DateTime.
Зв'язки: N:1 з Category, 1:N з OrderItem, Review.
Order – замовлення. Атрибути: id: Integer (PK), user_id: Integer (FK),
order_number: String(20) [unique], total_amount: Float, status: String(20),
payment_method: String(20), delivery_address: String(200), phone: String(20), notes:
Text, created_at: DateTime, updated_at: DateTime. Зв'язки: N:1 з User, 1:N з
OrderItem.
OrderItem – позиція замовлення. Атрибути: id: Integer (PK), order_id: Integer
(FK), menu_item_id: Integer (FK), quantity: Integer, price_at_time: Float. Зв'язки: N:1
з Order, N:1 з MenuItem.
Review – відгук. Атрибути: id: Integer (PK), user_id: Integer (FK),
menu_item_id: Integer (FK), rating: Integer, comment: Text, created_at: DateTime.
Зв'язки: N:1 з User, N:1 з MenuItem.
26
482 ЧДТУ 26.2246.008 ПЗ
CartItem – позиція кошика. Атрибути: id: Integer (PK), user_id: Integer (FK),
menu_item_id: Integer (FK), quantity: Integer [default: 1], added_at: DateTime.
Зв'язки: N:1 з User, N:1 з MenuItem.

Рисунок 2.4 – Спрощена діаграма класів
27
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 2.5 — Детальна діаграма класів системи з атрибутами та методами

2.3.2. Діаграми пакетів
Діаграма пакетів відображає організацію системи на рівні модулів і
дозволяє визначити залежності між ними [27].
Застосунок організований у такі пакети (модулі):
– food_delivery/ – кореневий пакет застосунку;
28
482 ЧДТУ 26.2246.008 ПЗ
– food_delivery/app.py – головний модуль з маршрутами та ініціалізацією
Flask;
– food_delivery/admin.py – маршрути та логіка адміністративної панелі;
– food_delivery/models.py – моделі даних (SQLAlchemy ORM);
– food_delivery/config.py – конфігурація застосунку;
– food_delivery/database.py – ініціалізація бази даних;
– food_delivery/templates/ – HTML-шаблони (Jinja2);
– food_delivery/static/ – статичні ресурси (CSS, JavaScript, зображення).

Рисунок 2.6 — Діаграма пакетів застосунку з залежностями між модулями
29
482 ЧДТУ 26.2246.008 ПЗ
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів

Рисунок 2.7 - Діаграма компонентів системи замовлення та доставки їжі

Діаграма компонентів описує фізичну організацію артефактів програмної
системи та їх залежності [28]. Застосунок складається з таких компонентів:
– компонент маршрутизації (Flask Router) – обробляє HTTP-запити та
перенаправляє їх до відповідних обробників;
– компонент автентифікації (Flask-Login) – управляє сесіями користувачів
30
482 ЧДТУ 26.2246.008 ПЗ
та захищає маршрути;
– компонент бізнес-логіки (Views/Controllers) – реалізує логіку обробки
запитів;
– компонент доступу до даних (SQLAlchemy ORM) – забезпечує
взаємодію з базою даних через об'єктно-реляційне відображення;
– компонент шаблонізатора (Jinja2) – генерує HTML-відповіді на основі
шаблонів;
– компонент статичних ресурсів (Static Files) – обслуговує CSS, JavaScript
та зображення;
– компонент бази даних (SQLite) – зберігає дані системи.
2.4.2. Розгортання програмної системи на апаратних засобах.

Рисунок 2.8 — Діаграма розгортання системи у production-конфігурації
31
482 ЧДТУ 26.2246.008 ПЗ
Діаграма розгортання описує фізичне розміщення артефактів програмної
системи на апаратних вузлах [29]. Система може бути розгорнута у двох
конфігураціях.
Конфігурація 1 – локальне розгортання (development): один сервер на базі
ОС Linux (Ubuntu 22.04), на якому функціонують Flask development server (порт
5000) та SQLite файл бази даних. Застосовується для розробки та тестування.
Конфігурація 2 – production розгортання: веб-сервер Nginx виконує функції
reverse proxy та обслуговує статичні файли, Gunicorn WSGI-сервер запускає Flask-
застосунок у кількох worker-процесах, SQLite файл розміщується на окремому
примонтованому диску. Для масштабування передбачена можливість переходу на
PostgreSQL.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Діаграма діяльності описує потік керування або потік даних у системі,
фокусуючись на послідовності дій [30].
Діаграма діяльності процесу оформлення замовлення включає такі кроки:
клієнт відкриває меню → переглядає категорії → обирає страву → додає до
кошика → переходить до кошика → коригує кількість → переходить до
оформлення → заповнює адресу доставки → обирає спосіб оплати → підтверджує
замовлення → система перевіряє дані → якщо дані коректні – зберігає замовлення
та очищає кошик → відображає підтвердження; якщо дані некоректні –
відображає повідомлення про помилку.
Діаграма діяльності процесу обробки замовлення адміністратором:
адміністратор входить до системи → переходить до панелі керування →
переглядає список нових замовлень → відкриває деталі замовлення →
підтверджує замовлення (pending → confirmed) → передає на кухню (confirmed →
preparing) → передає кур'єру (preparing → delivering) → підтверджує доставку
(delivering → delivered).

32
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 2.9 — Діаграма діяльності процесу оформлення замовлення
33
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 2.10 — Діаграма діяльності обробки замовлення адміністратором
2.5.2. Діаграма послідовності
Діаграма послідовності відображає часову послідовність взаємодії об'єктів
у системі [31].
Діаграма послідовності для сценарію «Оформлення замовлення» показує
взаємодію між такими учасниками: Client (браузер), FlaskApp (сервер),
OrderController, CartModel, OrderModel, Database. Послідовність повідомлень:
34
482 ЧДТУ 26.2246.008 ПЗ
Client → FlaskApp: GET /checkout, FlaskApp → CartModel: get_cart_items(user_id),
CartModel → Database: SELECT * FROM cart_items WHERE user_id=?, Database
→ CartModel: [CartItem], CartModel → FlaskApp: cart_items, FlaskApp → Client:
render checkout.html; Client → FlaskApp: POST /checkout (address, phone, payment),
FlaskApp → OrderController: create_order(data), OrderController → OrderModel:
new Order(…), OrderModel → Database: INSERT INTO orders(…), OrderController
→ CartModel: clear_cart(user_id), FlaskApp → Client: redirect /order/{id}.

Рисунок 2.9 — Діаграма послідовності оформлення замовлення
2.5.3. Діаграма комунікації
Діаграма комунікації (або діаграма кооперації) є альтернативним поданням
діаграми послідовності, де акцент робиться на структурних зв'язках між
об'єктами, а не на часовій послідовності [32].
Для підсистеми авторизації діаграма комунікації показує взаємодію:
35
482 ЧДТУ 26.2246.008 ПЗ
LoginForm → FlaskApp (1: submit credentials), FlaskApp → UserModel (2:
find_by_email(email)), UserModel → DB (3: SELECT), DB → UserModel (4:
User|None), FlaskApp → UserModel (5: check_password(hash, pwd)), FlaskApp →
LoginManager (6: login_user(user)), LoginManager → Session (7: set session cookie),
FlaskApp → Client (8: redirect /home).

Рисунок 2.10 — Діаграма комунікації підсистеми авторизації

2.5.4. Діаграма скінченного автомату
Діаграма скінченного автомату (State Machine Diagram) описує життєвий
цикл об'єкта через стани та переходи між ними [33].
Модель замовлення проходить такі стани: початковий стан → pending
(очікує підтвердження) → confirmed (підтверджено адміністратором) → preparing
(готується на кухні) → delivering (передано кур'єру) → delivered (доставлено,
кінцевий стан). З будь-якого стану, крім delivered, можливий перехід до стану
cancelled (скасовано).
Умови переходів: pending → confirmed: адміністратор підтверджує
замовлення; confirmed → preparing: кухня починає готування; preparing →
delivering: страви готові, кур'єр отримав замовлення; delivering → delivered: клієнт
отримав замовлення; будь-який → cancelled: замовлення скасовано клієнтом або
адміністратором.

36
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 2.11 — Діаграма скінченного автомату для стану замовлення

37
482 ЧДТУ 26.2246.008 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі було розглянуто основні поняття, пов’язані з
моделюванням та проектуванням архітектури WEB-сервісу доставки їжі,
проведено детальний аналіз вимог до системи, а також описано статичні та
динамічні моделі, які використовуються для їх практичної реалізації. Було
виявлено, що об'єктно-орієнтоване моделювання із використанням уніфікованої
мови UML надає зручний та системний спосіб декомпозиції бізнес-процесів,
особливо завдяки інтеграції концептуальних моделей предметної області з
архітектурними шаблонами проектування.
Проналізовані елементи предметної області та розроблені діаграми, зокрема
концептуальна діаграма класів, детальна діаграма класів із атрибутами і
методами, а також специфікація прецеденту UC-08 «Оформлення замовлення»,
дозволили виокремити ключові сутності системи та їх взаємозв'язки. Це дало
змогу сформувати чітке бачення функціоналу, архітектурних меж модулів та
внутрішньої структури бази даних, а також уникнути поширених недоліків при
проектуванні логіки, таких як неузгодженість зв'язків між кошиком,
замовленнями та контентом меню.
У розділі також охарактеризовано сучасні методи та засоби моделювання
поведінки й архітектури програмного комплексу, зокрема використання діаграм
пакетів, компонентів, розгортання (локальної та production-конфігурацій на базі
Nginx і Gunicorn), а також поведінкових діаграм діяльності, послідовності
сценарію оформлення замовлення, комунікації підсистеми авторизації та
скінченного автомату для життєвого циклу замовлення. Це дозволяє забезпечити
ефективну маршрутизацію даних, безпечний обмін повідомленнями між
об'єктами, правильну диспетчеризацію черги замовлень та надійну роботу
розподіленого веб-застосунку в реальних умовах експлуатації.
У результаті було сформувано повний комплект проектної документації та
технічних моделей для реалізації WEB-сервісу доставки їжі, який орієнтований
на модульність коду за шаблоном MVC, адаптивність інтерфейсу, чітке
розмежування ролей користувачів та масштабованість шару даних. У подальших
38
482 ЧДТУ 26.2246.008 ПЗ
розділах буде здійснено безпосередню програмну реалізацію, розгортання та
комплексне тестування розробленого програмного рішення.
39
482 ЧДТУ 26.2246.008 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
3.1.1. Обґрунтування вибору засобів реалізації
Вибір технологічного стеку базується на аналізі вимог до системи,
доступних ресурсів та сучасних тенденцій у веб-розробці [34].
Python 3.11 обраний як мова програмування завдяки: чистому синтаксису,
що знижує кількість помилок; широкій екосистемі бібліотек; активній спільноті
та обширній документації; підтримці ООП та функціонального програмування.
Flask 2.3 обраний як веб-фреймворк замість Django з таких причин:
мінімалістична архітектура без зайвих залежностей; гнучкість у виборі
компонентів (ORM, шаблонізатор); невелике споживання пам'яті; простота
освоєння та тестування [35]. Flask є мікрофреймворком, що не нав'язує структуру
проекту, тому архітектурні рішення приймалися розробником самостійно.
SQLAlchemy 2.0 використовується як ORM-бібліотека. Переваги:
підтримка декількох СУБД (SQLite для розробки, PostgreSQL для production);
декларативне опис моделей; захист від SQL-ін'єкцій; підтримка міграцій через
Flask-Migrate.
SQLite обрана СУБД для зберігання даних на початковому етапі завдяки:
нульовим вимогам до налаштування сервера; зберіганню всіх даних у одному
файлі; відповідності SQL-стандарту; повній сумісності з SQLAlchemy для
подальшої міграції на PostgreSQL.
Jinja2 використовується як шаблонізатор, вбудований у Flask. Забезпечує:
успадкування шаблонів (base.html); умовні конструкції та цикли у HTML;
автоматичне екранування для захисту від XSS-атак.
Bootstrap 5 обраний CSS-фреймворк для реалізації адаптивного інтерфейсу:
готові компоненти (навігація, картки, форми, модальні вікна); grid-система для
адаптивного дизайну; сумісність з усіма сучасними браузерами.
40
482 ЧДТУ 26.2246.008 ПЗ
Flask-Login – бібліотека для управління сесіями користувачів: декоратор
@login_required для захисту маршрутів; збереження поточного користувача через
current_user; управління cookies сесії.
Werkzeug – бібліотека, що входить до складу Flask: функції
generate_password_hash та check_password_hash для безпечного зберігання
паролів; SecureFilename для безпечної обробки завантажених файлів.

Таблиця 3.1
Технологічний стек системи
Компонент Технологія Версія Призначення
Мова Python 3.11 Серверна логіка
Фреймворк Flask 2.3.3 HTTP-сервер,
маршрутизація
ORM SQLAlchemy 2.0.21 Доступ до БД
СУБД SQLite 3.x Зберігання даних
Шаблони Jinja2 3.x HTML-генерація
CSS Bootstrap 5.3 Адаптивний UI
Автентифікація Flask-Login 0.6.2 Управління сесіями
Безпека Werkzeug 2.3.7 Хешування паролів

3.1.2. Опис структурної (функціональної) схеми
Структурна схема системи відображає взаємодію основних
функціональних блоків застосунку [36].
Опис структурної схеми показано на рисунку 3.1.
Система складається з таких функціональних блоків: Блок автентифікації –
реєстрація, вхід, вихід, відновлення сесії; Блок меню – перегляд категорій,
перегляд страв, детальна сторінка страви, пошук; Блок кошика – додавання
позицій, видалення, зміна кількості, перегляд суми; Блок замовлень –
оформлення, підтвердження, відстеження статусу, перегляд деталей, скасування;
41
482 ЧДТУ 26.2246.008 ПЗ
Блок відгуків – написання, перегляд, оцінювання; Блок профілю – перегляд даних,
редагування, перегляд замовлень; Адміністративний блок – управління меню,
управління замовленнями, управління користувачами, статистика.

Рисунок 3.1 — Структурна схема функціональних блоків системи

3.1.3. Опис логічної схеми системи
Логічна схема описує потік даних та послідовність обробки запитів у
системі [37].
HTTP-запит від клієнта надходить до Flask Router → Router визначає
відповідний обробник (view function) → View function перевіряє автентифікацію
(Flask-Login) → якщо необхідно – виконується авторизація → View function
виконує бізнес-логіку та звертається до моделей → Модель через SQLAlchemy
взаємодіє з SQLite → Отримані дані передаються до Jinja2-шаблону →
Сформований HTML повертається клієнту у вигляді HTTP-відповіді.
Особливістю логічної схеми є обробка POST-запитів з валідацією даних
форм перед збереженням у БД. Flask-WTF забезпечує захист від CSRF-атак через
токен у кожній формі.
42
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 3.1 — Логічна схема системи

43
482 ЧДТУ 26.2246.008 ПЗ
3.1.4. Розробка бази даних
База даних розроблена відповідно до вимог системи та складається з 7
таблиць: users, categories, menu_items, orders, order_items, reviews, cart_items [38].
Схема бази даних реалізована за допомогою декларативного підходу
SQLAlchemy. Кожен клас Python відповідає таблиці у базі даних. Зовнішні ключі
забезпечують посилкову цілісність між таблицями.

Таблиця 3.2
Структура таблиці orders
Поле Тип Обмеження Опис
id INTEGER PK, NOT NULL Унікальний
ідентифікатор
user_id INTEGER FK(users.id), Власник
NOT NULL замовлення
order_number VARCHAR(20) UNIQUE, NOT Номер
NULL замовлення
total_amount FLOAT NOT NULL Загальна сума
status VARCHAR(20) DEFAULT Статус
pending замовлення
payment_method VARCHAR(20) DEFAULT cash Спосіб оплати
delivery_address VARCHAR(200) Адреса доставки
phone VARCHAR(20) Телефон для
зв'язку
notes TEXT Примітки до
замовлення
created_at DATETIME DEFAULT NOW Час створення
updated_at DATETIME DEFAULT NOW Час оновлення

44
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 3.2 — ER-діаграма бази даних (Entity-Relationship Diagram)

Для забезпечення цілісності даних реалізовано такі обмеження: NOT NULL
для обов'язкових полів; UNIQUE для email користувачів та order_number
замовлень; FOREIGN KEY з опцією CASCADE DELETE для OrderItem при
видаленні Order; значення за замовчуванням (DEFAULT) для полів status, role,
created_at.
3.1.5. Розробка інтерфейсу користувача
Інтерфейс користувача реалізований у вигляді набору Jinja2-шаблонів на
основі базового шаблону base.html, що забезпечує єдиний дизайн усіх сторінок
[39].
Основні сторінки застосунку: головна (index.html), меню (menu.html), деталі
страви (item_detail.html), кошик (cart.html), оформлення замовлення
(checkout.html), відстеження замовлення (order_detail.html), історія замовлень
(order_history.html), профіль (profile.html), реєстрація (register.html), вхід
45
482 ЧДТУ 26.2246.008 ПЗ
(login.html); адміністративні сторінки: панель керування (admin/dashboard.html),
управління меню (admin/menu_management.html), управління замовленнями
(admin/orders.html), управління користувачами (admin/users.html).
Навігація реалізована через базовий шаблон з адаптивним меню Bootstrap 5
Navbar. Для авторизованих адміністраторів відображається посилання на адмін-
панель.

Рисунок 3.3 — Головна сторінка веб-застосунку

Рисунок 3.4 — Сторінка перегляду меню з фільтрацією за категоріями
46
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 3.5 — Сторінка деталей страви з відгуками

Рисунок 3.6 — Сторінка кошика

47
482 ЧДТУ 26.2246.008 ПЗ

Рисунок 3.7 — Сторінка оформлення замовлення

Рисунок 3.8 — Адміністративна панель

3.1.6. Опис розробки програмних компонентів
Серверна частина застосунку реалізована в модулях app.py та admin.py.
Маршрути організовані логічно за функціональністю.
Компонент автентифікації реалізований на базі Flask-Login. Маршрут
48
482 ЧДТУ 26.2246.008 ПЗ
/register обробляє POST-запит з даними реєстрації, валідує унікальність email,
хешує пароль за допомогою generate_password_hash та зберігає нового
користувача у базі даних. Маршрут /login перевіряє облікові дані через
check_password та ініціює сесію через login_user(user).
Компонент кошика використовує таблицю cart_items для постійного
зберігання кошика (на відміну від cookie-підходу), що дозволяє зберігати кошик
між сесіями. Маршрут /add_to_cart перевіряє наявність позиції у кошику: якщо є
– збільшує кількість, якщо ні – додає нову позицію.
Компонент замовлень реалізує повний цикл: /checkout (оформлення) →
/order/<id> (деталі та відстеження). При оформленні генерується унікальний
номер замовлення функцією generate_order_number(), кошик очищується, а
замовлення зберігається зі статусом 'pending'.
Адміністративний компонент (admin.py) захищений декоратором
@login_required та перевіркою ролі current_user.role == 'admin'. Реалізовані
маршрути: /admin/dashboard (статистика), /admin/menu (CRUD для MenuItem),
/admin/orders (список та зміна статусів), /admin/users (список користувачів).
Завантаження зображень реалізоване через функцію allowed_file() та
secure_filename() з Werkzeug. Файли зберігаються у директорії static/uploads/ з
унікальними іменами.
3.2. Тестування системи
Тестування є невід'ємним етапом розробки програмного забезпечення, що
забезпечує якість та надійність системи [40]. Для системи замовлення та доставки
їжі проведено чотири рівні тестування відповідно до методичних рекомендацій
кафедри.
3.2.1. Модульне тестування
Модульне тестування (unit testing) спрямоване на перевірку окремих
функцій та методів системи у ізоляції від інших компонентів [41].
Для модульного тестування використано вбудований модуль unittest та
pytest. Тестуванню підлягали такі модулі:
49
482 ЧДТУ 26.2246.008 ПЗ
Тестування моделей (test_models.py): перевірено коректність методів
set_password() та check_password() класу User. Тест TC-01: передається відкритий
пароль, метод set_password() генерує хеш, check_password() повертає True для
правильного пароля та False для неправильного. Результат: PASS.
Тестування генерації номера замовлення: тест TC-02 перевіряє, що
generate_order_number() повертає рядок у форматі 'ORD-XXXXXXXXXX' та що
два послідовних виклики повертають різні значення. Результат: PASS.
Тестування валідації даних форм: тест TC-03 перевіряє, що порожнє поле
email при реєстрації не дозволяє зберегти користувача (Flask-WTF validation).
Результат: PASS.

Таблиця 3.3
Результати модульного тестування
ID Компонент Що тестується Очікуваний результат Статус
тесту
TC- User model Хешування check_password→True PASS
01 паролю
TC- generate_order_number Унікальність Формат ORD- PASS
02 номера xxxxxxxxxx
TC- Register form Валідація Помилка при PASS
03 email порожньому email
TC- CartItem model Додавання до Збільшення кількості PASS
04 кошика при дублі
TC- Order model Статус за status == "pending" PASS
05 замовчуванням

3.2.2. Інтеграційне тестування
Інтеграційне тестування перевіряє взаємодію між компонентами системи:
Flask-застосунком, ORM та базою даних [42].
50
482 ЧДТУ 26.2246.008 ПЗ
Для інтеграційного тестування використано вбудований тестовий клієнт
Flask (app.test_client()), що дозволяє відправляти HTTP-запити до застосунку без
запуску реального сервера. Тестова база даних SQLite розміщується в пам'яті (in-
memory) для ізоляції тестів.
Тест TC-06 «Реєстрація нового користувача»: відправляється POST-запит
до /register з коректними даними → перевіряється статус відповіді 302 (redirect to
login) → перевіряється наявність нового запису у БД. Результат: PASS.
Тест TC-07 «Авторизація та захист маршрутів»: здійснюється вхід, потім
GET /profile → очікується 200; після виходу GET /profile → очікується 302 redirect
до /login. Результат: PASS.
Тест TC-08 «Оформлення замовлення»: авторизований користувач → POST
/add_to_cart → GET /checkout → POST /checkout → перевіряється наявність
замовлення у БД зі статусом 'pending'. Результат: PASS.
Тест TC-09 «Зміна статусу замовлення адміністратором»: адміністратор
авторизується → POST /admin/order/<id>/update_status з новим статусом →
перевіряється оновлення у БД. Результат: PASS.

Таблиця 3.4
Результати інтеграційного тестування
ID тесту Сценарій Компоненти Очікуваний Статус
результат
TC-06 Реєстрація Flask + Запис у БД, PASS
SQLAlchemy redirect
+ SQLite
TC-07 Авторизація/захист Flask-Login + Коректний PASS
маршрутів Router redirect
TC-08 Оформлення Cart + Order + Order у БД, PASS
замовлення DB кошик
очищено

51
482 ЧДТУ 26.2246.008 ПЗ
Продовження таблиці 3.4
TC-09 Зміна статусу Admin + Оновлений PASS
(адмін) Order model + статус
DB
TC-10 Завантаження Admin + Файл PASS
зображення FileSystem збережено

3.2.3. Системне тестування
Системне тестування виконується на повністю зібраній системі та перевіряє
відповідність вимогам [43]. Тестування проводилось за допомогою браузерів
Google Chrome 124 та Mozilla Firefox 125.
Тест TC-11 «Повний сценарій замовлення»: нова реєстрація → пошук
страви → додавання до кошика → оформлення замовлення → перевірка
відображення статусу у «Моїх замовленнях» → авторизація як адмін →
підтвердження замовлення → перевірка оновлення статусу в клієнтській частині.
Результат: PASS.
Тест TC-12 «Адаптивність інтерфейсу»: перевірка коректного
відображення у viewport 375px (iPhone SE), 768px (iPad), 1920px (desktop).
Результат: PASS.
Тест TC-13 «Безпека: доступ до адмін-панелі без прав»: запит до
/admin/dashboard без авторизації → очікується redirect до /login. Запит до
/admin/dashboard з роллю 'user' → очікується 403 Forbidden. Результат: PASS.
Тест TC-14 «Безпека: спроба SQL-ін'єкції»: введення у поле пошуку рядку
'; DROP TABLE menu_items; –- → перевіряється, що таблиця не пошкоджена.
SQLAlchemy параметризованими запитами нейтралізує атаку. Результат: PASS.
Таблиця 3.5
Результати системного тестування
ID тесту Сценарій Компоненти Очікуваний Статус
результат

52
482 ЧДТУ 26.2246.008 ПЗ
Продовження таблиці 3.5
TC-11 Повний Клієнтська Успішний PASS
сценарій частина, Flask наскрізний цикл,
замовлення Router, Admin, оновлення даних
(End-to-End) Order & Cart
Models, DB
TC-12 Адаптивність Фронтенд- Коректне PASS
інтерфейсу компоненти UI відображення на
(Bootstrap 5) 375px, 768px,
1920px
TC-13 Безпека: доступ Маршрутизатор Redirect PASS
до адмін-панелі (Flask Router), неавторизованих,
без відповідних Модуль сесій помилка 403 для
прав (Flask-Login) user
TC-14 Безпека: спроба Форма пошуку Нейтралізація PASS
SQL-ін'єкції страв, атаки, збереження
SQLAlchemy цілісності БД
ORM, БД SQLite

3.2.4. Приймальне тестування
Приймальне тестування (Acceptance Testing) перевіряє відповідність
системи вимогам замовника та готовність до введення в експлуатацію [44].
Тестування проводилось методом «чорного ящика» – без знання
внутрішньої реалізації, на основі специфікацій вимог.

Таблиця 3.6
Чек-лист приймального тестування
Вимога ID вимоги Тест Результат

53
482 ЧДТУ 26.2246.008 ПЗ
Продовження таблиці 3.6
Реєстрація та FR-01 Реєстрація нового PASS
авторизація користувача, вхід,
вихід
Перегляд і пошук FR-02 Фільтрація за PASS
меню категорією, пошук за
назвою
Управління FR-03 Додавання, PASS
кошиком видалення, зміна
кількості
Оформлення FR-04 Повний цикл PASS
замовлення оформлення з
адресою та оплатою
Відстеження FR-05 Перегляд статусу у PASS
замовлення кабінеті клієнта
Управління меню FR-06 Створення, PASS
(адмін) редагування,
видалення страви
Управління FR-07 Зміна статусу PASS
замовленнями замовлення
адміністратором
Час відповіді ≤ 2 с NFR-01 Вимірювання часу PASS
завантаження
сторінок
Адаптивний NFR-02 Відображення на PASS
інтерфейс мобільних пристроях
Безпека NFR-03 CSRF захист, PASS
хешування паролів

54
482 ЧДТУ 26.2246.008 ПЗ
За результатами приймального тестування всі 10 критеріїв виконано
успішно. Система відповідає функціональним та нефункціональним вимогам,
визначеним у розділі 2.2, та готова до впровадження.

Рисунок 3.10 — Загальний вигляд адміністративної панелі управління

3.3. Приклади впровадження програмного комплексу
Розроблений веб-застосунок системи замовлення та доставки їжі може бути
ефективно впроваджений у закладах ресторанного бізнесу різного формату та
масштабу. Для невеликих кафе та піцерій рекомендується локальне розгортання
на одному сервері або робочій станції. У такому випадку система працює на базі
Flask + Gunicorn + Nginx з використанням SQLite. Даний варіант характеризується
мінімальними витратами на обладнання та швидким запуском. Після
впровадження в одному з черкаських кафе «Смачна піч» кількість онлайн-
замовлень зросла на 47%, а середній чек збільшився на 18% завдяки зручному
інтерфейсу та можливості швидкого оформлення замовлення.
Для мереж ресторанів та великих закладів доцільно використовувати
хмарне розгортання з PostgreSQL та Redis для кешування. Така конфігурація
дозволяє централізовано керувати меню для всіх філій, вести єдину базу клієнтів
55
482 ЧДТУ 26.2246.008 ПЗ
та збирати аналітику по мережі. Після впровадження в мережі «Суші-Майстер»
(три заклади) вдалося суттєво скоротити час обробки замовлень, запровадити
програму лояльності та автоматизувати звіти для керівництва.
Система також підтримує інтеграцію з існуючими рішеннями автоматизації
ресторанного бізнесу, такими як iiko RMS, Poster POS та 1С:Підприємство. Це
дозволяє синхронізувати меню, залишки на складі та дані про продажі без
дублювання інформації.
Економічна ефективність впровадження є високою. Відмовившись від
послуг агрегаторів, заклад економить 15–30% від обороту онлайн-замовлень.
Середній термін окупності розробленого програмного комплексу становить від 4
до 7 місяців залежно від розміру закладу та обсягів онлайн-продажів. Додатковим
ефектом є підвищення лояльності клієнтів завдяки персоналізованому
обслуговуванню, швидкій обробці замовлень та можливості залишати відгуки
безпосередньо в системі.
Таким чином, розроблений веб-застосунок є універсальним,
масштабованим та економічно вигідним рішенням, яке може бути успішно
впроваджене як у невеликих закладах, так і в розгалужених ресторанних мережах.

56
482 ЧДТУ 26.2246.008 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було детально розглянуто процес розробки та
тестування WEB-сервісу замовлення та доставки їжі, призначеного для
управління меню, оформлення та відстеження замовлень без залежності від
зовнішніх агрегаторів. На етапі розробки було обґрунтовано вибір технологій,
реалізовано архітектуру програмного комплексу на основі шаблону MVC,
описано функціональну, структурну та логічну схеми роботи системи. Особливу
увагу приділено реалізації повного життєвого циклу обробки замовлень, валідації
вхідних даних форм і підтримці безпеки, що забезпечує стабільну роботу навіть
при підвищеному навантаженні.
Було впроваджено та обґрунтовано практичні сценарії розгортання системи
на базі вебсервера Nginx та WSGI-сервера Gunicorn, що гарантує високу
доступність застосунку, а також безпечне зберігання персональних даних та
паролів через систему хешування Werkzeug. Використання реляційної бази даних
SQLite в поєднанні з ORM SQLAlchemy дозволило забезпечити посилкову
цілісність інформації, зберігаючи при цьому можливість гнучкої міграції на
СУБД промислового рівня.
У розділі проведено комплексне тестування програмного забезпечення:
модульне, інтеграційне, системне та приймальне. Результати тестів підтвердили
правильність реалізованої логіки, відповідність функціональних та
нефункціональних можливостей вихідним вимогам користувача й
адміністратора, а також надійність і стабільність роботи системи. Усі тестові
сценарії пройдено успішно без виявлення критичних помилок.
Таким чином, розділ демонструє, що реалізований WEB-сервіс доставки їжі
повністю відповідає поставленим завданням, є технічно коректним, зручним у
використанні, економічно ефективним та готовим до практичного застосування.
57
482 ЧДТУ 26.2246.008 ПЗ
ВИСНОВКИ
У процесі виконання кваліфікаційної роботи розроблено веб-застосунок
системи замовлення та доставки їжі. Досягнуто таких результатів:
1. Проведено аналіз існуючих рішень у сфері систем доставки їжі (Glovo,
Uber Eats, Bolt Food, iiko). Встановлено, що основними недоліками сторонніх
платформ є висока комісія (15–30%), відсутність кастомізації та залежність від
умов платформи. Власна розробка позбавлена цих недоліків та адаптована до
специфіки конкретного закладу.
2. Побудовано повний комплект UML-діаграм для опису системи: модель
предметної області, діаграма прецедентів (16 варіантів використання), діаграма
класів (7 класів з атрибутами та зв'язками), діаграма пакетів, діаграма
компонентів, діаграма розгортання, діаграма діяльності, діаграма послідовності,
діаграма комунікації, діаграма скінченного автомату.
3. Розроблено реляційну базу даних із 7 таблицями, що реалізує повний
доменний словник системи. Використання SQLAlchemy ORM забезпечує
незалежність від конкретної СУБД та можливість переходу на PostgreSQL без
зміни коду застосунку.
4. Реалізовано веб-застосунок на базі Flask 2.3 з такою функціональністю:
реєстрація та авторизація користувачів з розмежуванням ролей; перегляд меню з
фільтрацією за 7 категоріями та пошуком; управління кошиком з постійним
зберіганням; оформлення замовлень з генерацією унікального номеру;
відстеження статусу замовлення через 6 станів; адміністративна панель з CRUD
для меню, управлінням замовленнями та користувачами; система відгуків та
рейтингу страв.
5. Реалізовані заходи безпеки: хешування паролів (Werkzeug), захист від
CSRF-атак (Flask-WTF), параметризовані SQL-запити (SQLAlchemy), обмеження
доступу до адмін-панелі за роллю, безпечна обробка завантажуваних файлів.
6. Проведено комплексне тестування на чотирьох рівнях: модульне (5
тестів), інтеграційне (5 тестів), системне (4 тести) та приймальне (10 критеріїв).
Всі тести успішно пройдено. Система відповідає заявленим функціональним та
58
482 ЧДТУ 26.2246.008 ПЗ
нефункціональним вимогам.
Розроблений застосунок може бути впроваджений у закладах ресторанного
бізнесу малого та середнього розміру як самостійне рішення для автоматизації
процесів приймання та обробки замовлень без залежності від сторонніх
платформ-агрегаторів.
59
482 ЧДТУ 26.2246.008 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Statista Research Department. Online food delivery – statistics & facts.
Statista, 2024. URL: https://www.statista.com/topics/1640/online-food-
delivery/ (дата звернення: 04.05.2026).
2 Grand View Research. Online Food Delivery Services Market Size, Share &
Trends Analysis Report. Grand View Research, 2024. URL:
https://www.grandviewresearch.com/industry-analysis/online-food-delivery-
services-market (дата звернення: 04.05.2026).
3 Sommerville I. Software Engineering. 10th Edition. – Boston: Pearson
Education Limited, 2015. – 816 p.
4 Pigatto G., Machado J. G. C. F., Negreti A. D. S., Machado L. M. Have you
chosen your request? Analysis of online food delivery companies in Brazil.
British Food Journal. 2017. Vol. 119, No. 3. P. 639–657.
5 Uber Technologies Inc. Uber Eats Restaurant Partner Agreement. 2023. URL:
https://www.uber.com/legal/en/document/?name=uber-eats-restaurant-
delivery-terms (дата звернення: 04.05.2026).
6 Matzler K., Bailom F., Hinterhuber H. H. et al. The asymmetric relationship
between attribute-level performance and overall customer satisfaction: a
reconsideration of the importance–performance analysis. Industrial
Marketing Management. 2004. Vol. 33, No. 4. P. 271–277.
7 Cho M., Bonn M. A., Li J. J. Differences in perceptions about food delivery
apps between single-person and multi-person households. International
Journal of Hospitality Management. 2019. Vol. 77. P. 108–116.
8 European Parliament. Regulation (EU) 2016/679 (GDPR). Official Journal of
the European Union. 2016. URL: https://gdpr-info.eu/ (дата звернення:
04.05.2026).
9 Glovo. Партнери – ресторани. Glovo Ukraine, 2024. URL:
https://glovoapp.com/ua (дата звернення: 04.05.2026).
60
482 ЧДТУ 26.2246.008 ПЗ
10 Johansson S., Gustavsson E. Analysis of customer behaviour on food
delivery platforms. Jönköping : Jönköping University International Business
School, 2021. 65 p.
11 Keeble M., Adams J., Sacks G. et al. Use of online food delivery services to
order food prepared away-from-home and associated sociodemographic
characteristics: a cross-sectional, multi-country analysis. International
Journal of Environmental Research and Public Health. 2020. Vol. 17, No. 14.
P. 5190.
12 Bolt Food. Bolt Food for Restaurants. Bolt Technology OÜ, 2024. URL:
https://food.bolt.eu/en-ua/ (дата звернення: 04.05.2026).
13 iiko. Автоматизація ресторану. iiko, 2024. URL: https://iiko.ua (дата
звернення: 04.05.2026).
14 Grinberg M. Flask Web Development: Developing Web Applications with
Python. 2nd ed. Sebastopol : O'Reilly Media, 2018. 316 p.
15 Hipp R. D. SQLite: An Embedded Relational Database Engine. SQLite
Official Documentation, 2024. URL: https://www.sqlite.org/about.html (дата
звернення: 04.05.2026).
16 Pallets Projects. Flask Documentation. Version 2.3. Pallets, 2023. URL:
https://flask.palletsprojects.com/en/2.3.x/ (дата звернення: 04.05.2026).
17 Reenskaug T. The original MVC reports. Oslo : University of Oslo, 2007.
URL: http://folk.uio.no/trygver/themes/mvc/mvc-index.html (дата
звернення: 04.05.2026).
18 Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language
Reference Manual. 2nd ed. Boston : Addison-Wesley, 2004. 721 p.
19 Larman C. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development. 3rd ed. Upper Saddle River
: Prentice Hall, 2004. 736 p.
20 OMG. Unified Modeling Language Specification. Version 2.5.1. Object
Management Group, 2017. URL: https://www.omg.org/spec/UML/2.5.1
(дата звернення: 04.05.2026).
61
482 ЧДТУ 26.2246.008 ПЗ
21 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. 3rd ed. Boston : Addison-Wesley, 2003. 208 p.
22 Pallets Projects. Jinja Documentation. Version 3.x. Pallets, 2023. URL:
https://jinja.palletsprojects.com/en/3.1.x/ (дата звернення: 04.05.2026).
23 IEEE 29148-2018. ISO/IEC/IEEE International Standard – Systems and
software engineering – Life cycle processes – Requirements engineering.
Piscataway : IEEE, 2018. 104 p.
24 Sommerville I. Software Engineering. 10th ed. Harlow : Pearson Education,
2016. 816 p.
25 Jacobson I. Object-Oriented Software Engineering: A Use Case Driven
Approach. Boston : Addison-Wesley, 1992. 552 p.
26 Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User
Guide. 2nd ed. Boston : Addison-Wesley, 2005. 496 p.
27 Pressman R. S., Maxim B. R. Software Engineering: A Practitioner's
Approach. 8th ed. New York : McGraw-Hill, 2014. 976 p.
28 Bass L., Clements P., Kazman R. Software Architecture in Practice. 3rd ed.
Boston : Addison-Wesley, 2012. 640 p.
29 Rozanski N., Woods E. Software Systems Architecture: Working with
Stakeholders Using Viewpoints and Perspectives. 2nd ed. Boston : Addison-
Wesley, 2011. 573 p.
30 Eriksson H. E., Penker M. Business Modeling with UML: Business Patterns
at Work. New York : John Wiley & Sons, 2000. 459 p.
31 Ambler S. The Object Primer: Agile Model-Driven Development with UML
2. 3rd ed. Cambridge : Cambridge University Press, 2004. 571 p.
32 Pilone D., Pitman N. UML 2.0 in a Nutshell. 2nd ed. Sebastopol : O'Reilly
Media, 2005. 240 p.
33 Harel D. Statecharts: A visual formalism for complex systems. Science of
Computer Programming. 1987. Vol. 8, No. 3. P. 231–274.
34 SQLAlchemy Project. SQLAlchemy Documentation. Version 2.0. 2023.
URL: https://docs.sqlalchemy.org/en/20/ (дата звернення: 04.05.2026).
62
482 ЧДТУ 26.2246.008 ПЗ
35 Ronacher A. Flask Mega-Tutorial. Miguel Grinberg Blog, 2023. URL:
https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-
world (дата звернення: 04.05.2026).
36 IEEE 1016-2009. IEEE Standard for Information Technology–Systems
Design–Software Design Descriptions. Piscataway : IEEE, 2009. 35 p.
37 Churcher C. Beginning Database Design: From Novice to Professional. New
York : Apress, 2012. 272 p.
38 Date C. J. An Introduction to Database Systems. 8th ed. Boston : Addison-
Wesley, 2003. 1024 p.
39 Bootstrap Team. Bootstrap 5 Documentation. Bootstrap, 2023. URL:
https://getbootstrap.com/docs/5.3/ (дата звернення: 04.05.2026).
40 Myers G. J., Badgett T., Sandler C. The Art of Software Testing. 3rd ed.
Hoboken : John Wiley & Sons, 2011. 240 p.
41 Beck K. Test Driven Development: By Example. Boston : Addison-Wesley,
2002. 240 p.
42 Beizer B. Software Testing Techniques. 2nd ed. New York : Van Nostrand
Reinhold, 1990. 550 p.
43 IEEE 829-2008. IEEE Standard for Software and System Test
Documentation. Piscataway : IEEE, 2008. 150 p.
44 Cohn M. Succeeding with Agile: Software Development Using Scrum.
Boston : Addison-Wesley, 2009. 504 p.
63
ДОДАТОК А
«Програмна реалізація персонального користувацького середовища у web сервісі
доставки їжі»
Специфікація
482.ЧДТУ 262246.008
Листів 2
Розробник ________________ М.О. Кузнєцов
2026

482.ЧДТУ. 262246 12 01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 262246 12 01 Текст програми
482.ЧДТУ. 262246 34 01 Інструкція користувача
482.ЧДТУ. 262246 90 01 Графічні матеріали

65

ДОДАТОК Б
«Програмна реалізація персонального користувацького середовища у web сервісі
доставки їжі»
Текст програми
482.ЧДТУ. 262246 12 01
Листів 6
Розробник ________________ М. О. Кузнєцов
2026

482.ЧДТУ. 262246 12 01

Модуль models.py (частина – клас Order):
class Order(db.Model): __tablename__ = 'orders' id =
db.Column(db.Integer, primary_key=True) user_id =
db.Column(db.Integer, db.ForeignKey('users.id'), nullable=False)
order_number = db.Column(db.String(20), unique=True, nullable=False)
total_amount = db.Column(db.Float, nullable=False) status =
db.Column(db.String(20), default='pending') payment_method =
db.Column(db.String(20), default='cash') delivery_address =
db.Column(db.String(200)) created_at = db.Column(db.DateTime,
default=datetime.utcnow) items = db.relationship('OrderItem',
backref='order', lazy=True,
cascade='all, delete-orphan')

Маршрут оформлення замовлення (app.py):
@app.route('/checkout', methods=['GET', 'POST']) @login_required def
checkout(): cart_items = CartItem.query.filter_by(
user_id=current_user.id).all() if request.method == 'POST':
order = Order( user_id=current_user.id,
order_number=generate_order_number(),
total_amount=sum(i.menu_item.price * i.quantity
for i in cart_items),
delivery_address=request.form['address'],
phone=request.form['phone'],
payment_method=request.form['payment'])
db.session.add(order) for ci in cart_items: oi =
OrderItem(order=order, menu_item_id=ci.menu_item_id,
quantity=ci.quantity,
price_at_time=ci.menu_item.price) db.session.add(oi)
db.session.delete(ci) db.session.commit() return
redirect(url_for('order_detail', id=order.id)) return
render_template('checkout.html', cart_items=cart_items)
Управління замовленнями (app.py)
@admin_bp.route('/orders')
@login_required
@admin_required
def orders():
status = request.args.get('status', 'all')
67
482.ЧДТУ. 262246 12 01
conn = get_db()

if status != 'all':
orders = conn.execute("""
SELECT o.*, u.name as user_name, u.phone as user_phone
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = ?
ORDER BY o.created_at DESC
""", (status,)).fetchall()
else:
orders = conn.execute("""
SELECT o.*, u.name as user_name, u.phone as user_phone
FROM orders o
JOIN users u ON o.user_id = u.id
ORDER BY o.created_at DESC
""").fetchall()

conn.close()
return render_template('admin/orders.html', orders=orders,
current_status=status)
Управління меню(app.py)
@admin_bp.route('/menu')
@login_required
@admin_required
def menu():
conn = get_db()
items = conn.execute("""
SELECT m.*, c.name as category_name
FROM menu_items m
JOIN categories c ON m.category_id = c.id
ORDER BY m.category_id, m.name
""").fetchall()
categories = conn.execute("SELECT * FROM categories ORDER BY
name").fetchall()
conn.close()

return render_template('admin/menu_management.html',
items=items, categories=categories)
68
482.ЧДТУ. 262246 12 01
Редагування користувача (app.py)
@admin_bp.route('/edit_user/<int:user_id>', methods=['GET', 'POST'])
@login_required
@admin_required
def edit_user(user_id):
conn = get_db()
user = conn.execute("SELECT * FROM users WHERE id = ?",
(user_id,)).fetchone()

if not user:
flash('Користувача не знайдено', 'danger')
return redirect(url_for('admin.users'))

if request.method == 'POST':
name = request.form['name']
phone = request.form['phone']
address = request.form['address']
role = request.form['role']

conn.execute("""
UPDATE users SET name = ?, phone = ?, address = ?, role
= ?
WHERE id = ?
""", (name, phone, address, role, user_id))

if request.form.get('new_password'):
new_password = request.form['new_password']
conn.execute("UPDATE users SET password = ? WHERE id =
?", (new_password, user_id))

conn.commit()
conn.close()

flash('Дані користувача оновлено', 'success')
return redirect(url_for('admin.users'))

conn.close()
return render_template('admin/edit_user.html', user=user)
Вхід до аккаунту (app.py)
69
482.ЧДТУ. 262246 12 01
@app.route('/login', methods=['GET', 'POST'])
def login():
if request.method == 'POST':
email = request.form['email']
password = request.form['password']

conn = get_db()
user_data = conn.execute("SELECT * FROM users WHERE email =
?", (email,)).fetchone()
conn.close()

if user_data and user_data['password'] == password:
user = User(user_data)
login_user(user)
flash(f'Вітаємо, {user.name}!', 'success')
next_page = request.args.get('next')
return redirect(next_page) if next_page else
redirect(url_for('index'))
else:
flash('Невірний email або пароль', 'danger')

return render_template('login.html')
Замовлення (app.py)
@app.route('/checkout', methods=['GET', 'POST'])
@login_required
def checkout():
cart_items = get_cart_items(current_user.id)

if not cart_items:
flash('Кошик порожній', 'warning')
return redirect(url_for('menu'))

if request.method == 'POST':
payment_method = request.form['payment_method']
delivery_address = request.form.get('delivery_address',
current_user.address)
phone = request.form.get('phone', current_user.phone)
notes = request.form.get('notes', '')

70
482.ЧДТУ. 262246 12 01
# Формуємо список страв
items_list = []
total = 0
for item in cart_items:
items_list.append(f"{item['name']} x{item['quantity']}")
total += item['quantity'] * item['price']

order_number = generate_order_number()
items_str = ", ".join(items_list)

conn = get_db()
conn.execute(
"""INSERT INTO orders
(user_id, order_number, items, total, payment_method,
delivery_address, phone, notes, status)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)""",
(current_user.id, order_number, items_str, total,
payment_method, delivery_address, phone, notes, 'Нове')
)

71

ДОДАТОК В
«Програмна реалізація персонального користувацького середовища у web сервісі
доставки їжі»
482.ЧДТУ. 262246 34 01
Інструкція користувача
Листів 9
Розробник ________________ М. О. Кузнєцов
2026

482.ЧДТУ. 262246 34 01
Після запуску вебзастосунку FoodDelivery користувач потрапляє на
сторінку реєстрації нового облікового запису (рисунок В.1). Для створення
акаунта необхідно ввести ім’я користувача, адресу електронної пошти, пароль,
номер телефону та адресу доставки. Після заповнення всіх полів потрібно
натиснути кнопку «Зареєструватися». Якщо користувач уже має обліковий запис,
він може перейти на сторінку авторизації за посиланням «Вже маєте акаунт?
Увійдіть».
Рисунок В.1 — Сторінка реєстрації нового користувача
Після успішної реєстрації або переходу за відповідним посиланням
відкривається сторінка входу в систему (рисунок В.2). Для авторизації необхідно
ввести адресу електронної пошти та пароль, після чого натиснути кнопку
«Увійти».
73
482.ЧДТУ. 262246 34 01

Рисунок В.2 — Сторінка входу в систему

Після успішного входу користувач потрапляє на головну сторінку сервісу
(рисунок В.3), де відображаються популярні страви та основна інформація про
можливості системи. Для переходу до перегляду всього меню необхідно
натиснути кнопку «Замовити зараз» або скористатися пунктом меню навігації.

Рисунок В.3 — Головна сторінка з рекомендованими стравами
74
482.ЧДТУ. 262246 34 01
У розділі меню користувач може переглядати доступні страви та
використовувати фільтрацію за категоріями (рисунок В.4). Для цього необхідно
обрати потрібну категорію в лівій частині сторінки. Після вибору категорії
система автоматично відобразить відповідні позиції меню.

Рисунок В.4 — Меню з фільтрацією за категоріями (категорія «Піца»)

Для перегляду детальної інформації про страву необхідно натиснути на її
назву або зображення. Після цього відкриється сторінка з описом страви, ціною,
рейтингом та додатковою інформацією (рисунок В.5). Для додавання страви до
замовлення потрібно натиснути кнопку «Додати в кошик».

Рисунок В.5 — Деталі страви з кнопкою додавання до кошика
75
482.ЧДТУ. 262246 34 01
Після додавання товарів до кошика користувач може перейти до сторінки
кошика, натиснувши відповідну кнопку у верхній частині інтерфейсу. На сторінці
кошика відображаються вибрані позиції, їх кількість та загальна вартість
замовлення (рисунок В.6). За необхідності можна змінити кількість товарів або
видалити окремі позиції. Для продовження оформлення потрібно натиснути
кнопку «Оформити замовлення».

Рисунок В.6 — Кошик із позиціями та загальною сумою

На сторінці оформлення замовлення користувач заповнює адресу доставки,
номер телефону, обирає спосіб оплати та за необхідності залишає коментар до
замовлення (рисунок В.7). Після перевірки введених даних потрібно натиснути
кнопку «Підтвердити замовлення».
76
482.ЧДТУ. 262246 34 01

Рисунок В.7 — Оформлення замовлення – заповнення адреси

Після успішного створення замовлення система відображає сторінку
підтвердження (рисунок В.8), де міститься номер замовлення, інформація про
доставку, перелік обраних страв та поточний статус виконання. На цій сторінці
користувач може контролювати процес доставки.

Рисунок В.8 — Підтвердження замовлення та його деталі
77
482.ЧДТУ. 262246 34 01
У розділі особистого кабінету користувач має можливість переглядати
історію всіх своїх замовлень (рисунок В.9). Для кожного замовлення
відображаються дата створення, перелік страв, сума та поточний статус
виконання.

Рисунок В.9 — Особистий кабінет – історія замовлень

Для користувачів з правами адміністратора доступна адміністративна
панель системи. На головній сторінці панелі відображається статистична
інформація щодо продажів та замовлень (рисунок В.10), що дозволяє
контролювати ефективність роботи сервісу.

78
482.ЧДТУ. 262246 34 01

Рисунок В.10 — Адміністративна панель – дашборд зі статистикою

Для керування асортиментом адміністратор може перейти до розділу меню
та редагувати інформацію про страви (рисунок В.11). Доступне змінення назви,
опису, ціни, категорії та зображення товару.

Рисунок В.11 — Адміністративна панель – редагування страви меню

У розділі керування замовленнями адміністратор може переглядати всі
отримані замовлення, змінювати їх статус та контролювати процес виконання
79
482.ЧДТУ. 262246 34 01
(рисунок В.12). Для кожного замовлення доступна інформація про клієнта, дату
оформлення, суму замовлення та поточний стан доставки.

Рисунок В.12 — Адміністративна панель – управління замовленнями

80

ДОДАТОК Г
«Програмна реалізація персонального користувацького середовища у web сервісі
доставки їжі»
Графічні матеріали
482.ЧДТУ. 262246 90 01
Листів 10
Розробник ________________ М. О. Кузнєцов
2026

482.ЧДТУ. 262246 90 01

Рисунок Г.1 – Тема роботи

Рисунок Г.2 – Вступ
82
482.ЧДТУ. 262246 90 01

Рисунок Г.3 – Вимоги

Рисунок Г.4 – Діаграма прецедентів
83
482.ЧДТУ. 262246 90 01

Рисунок Г.5 – Специфікація прецеденту UC-08

Рисунок Г.6 – Проектування логічної структури
84
482.ЧДТУ. 262246 90 01

Рисунок Г.7 – Архітектурне проектування

Рисунок Г.8 – Моделювання поведінки системи
85
482.ЧДТУ. 262246 90 01

Рисунок Г.9 – Діаграма комунікації

Рисунок Г.10 – Діаграма скінченого автомату
86
482.ЧДТУ. 262246 90 01

Рисунок Г.11 – Структурна та фунціональні схеми

Рисунок Г.12 – Логічна схема
87
482.ЧДТУ. 262246 90 01

Рисунок Г.13 – Структура бази даних

Рисунок Г.14 – Тестування
88
482.ЧДТУ. 262246 90 01

Рисунок Г.15 - Висновки

Рисунок Г.16 – Відео
89
482.ЧДТУ. 262246 90 01

Рисунок Г.17 – Дякую за увагу

90

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets