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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7049| Title: | Архітектурні рішення розробки web-системи для малого бізнесу (на прикладі суші-бару) |
| Authors: | Немченко, Вадим В'ячеславович Чорновол, Давлат Таджиддінович |
| Issue Date: | 19-Dec-2025 |
| Abstract: | АНОТАЦІЯ Виконавець: Чорновол Давлат Таджиддінович.
Назва магістерської роботи: «Архітектурні рішення розробки web-системи для малого бізнесу (на прикладі суші-бару)».
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2025 рік.
Основні ідеї, результати та висновки магістерської роботи:
Основні ідеї:
- дослідження сучасних архітектурних підходів до розробки web-систем, зокрема: монолітної, модульної, мікросервісної та serverless архітектур;
- аналіз їх переваг, недоліків та адаптивності до потреб малого бізнесу, зокрема локальних закладів громадського харчування;
- обґрунтування вибору оптимальної архітектури для створення web-системи суші-бару з урахуванням вимог масштабованості, продуктивності та вартості підтримки.
Результати:
- виконано порівняльний аналіз архітектурних моделей та визначено їх придатність для малого бізнесу;
- обґрунтовано використання стеку React + Spring Boot + PostgreSQL із розмежуванням фронтенду та бекенду через REST API;
- розроблено архітектурну схему web-системи суші-бару та реалізовано основний функціонал: управління товарами, замовленнями, користувачами та інтеграціями.
Висновки:
- доведено, що модульний підхід та REST-архітектура забезпечують оптимальне поєднання продуктивності, простоти розгортання та подальшого масштабування для малого бізнесу;
- оцінено технічні аспекти реалізації: продуктивність, безпеку, можливість подальшого переходу до мікросервісної архітектури. ANNOTATION Performer: Chornovol Davlat Tajiddinovych. Title of the master’s thesis: “Architectural solutions for developing a web system for small businesses (using a sushi bar as an example)”. Specialty: 121 “Software Engineering”. Institution: Cherkasy State Technological University (CSTU). City, year: Cherkasy, 2025. Main ideas, results, and conclusions of the master’s thesis: Main ideas: - research of modern architectural approaches to web system development, including monolithic, modular, microservice, and serverless architectures; - analysis of their advantages, disadvantages, and adaptability to the needs of small businesses, particularly local food service establishments; - justification of the optimal architectural choice for developing a sushi bar web system considering scalability, performance, and maintenance costs. Results: - a comparative analysis of architectural models was conducted, and their suitability for small business needs was evaluated; - the use of React + Spring Boot + PostgreSQL with a clearly separated frontend and backend via REST API was justified; - an architectural model of the sushi bar web system was designed and the core functionality was implemented: product management, order processing, user management, and integrations. Conclusions: - it was proven that a modular approach combined with REST architecture provides an optimal balance of performance, deployment simplicity, and future scalability for small businesses; - technical aspects of implementation were evaluated, including performance, security, and potential migration to a microservices architecture |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7049 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Чорновол Давлат Таджиддінович.pdf Restricted Access | 3.63 MB | Adobe PDF | View/Open Request a copy | |
| Додаток А до кваліфікаційної роботи магістра Чорновола Давлата Таджиддіновича.pdf Restricted Access | 195.69 kB | Adobe PDF | View/Open Request a copy | |
| Додаток Б до кваліфікаційної роботи магістра Чорновола Давлата Таджиддіновича.pdf Restricted Access | 282.87 kB | Adobe PDF | View/Open Request a copy | |
| Додаток В до кваліфікаційної роботи магістра Чорновола Давлата Таджиддіновича.pdf Restricted Access | 2.25 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Архітектурні рішення розробки web-системи для малого бізнесу
(на прикладі суші-бару)
Виконав: студент 2 курсу, групи МПЗ-2404
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Чорновол Д.Т.
(прізвище та ініціали)
Керівник Немченко В.В.
(прізвище та ініціали)
Рецензент Левченко С.П.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
__________________Голуб С.В.__
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Чорновол Давлат Таджиддінович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) Архітектурні рішення розробки web-системи для малого бізнесу
(на прикладі суші-бару)
Керівник проекту (роботи) Немченко Вадим В’ячеславович, к.т.н. доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 07 » жовтня 2025
року № 307/03-03
2. Строк подання студентом проекту (роботи) 16.12.2025
3. Вхідні дані до проекту (роботи) Дослідження предметної області web-сервісу; проектування
архітектури; формування вимог до програмного комплексу; дослідження існуючих архітектурних
рішень; реалізація програмного комплексу та тестування.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань; Розділ 2. Теоретичні та
експериментальні дослідження; Розділ 3. Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем; Розділ 4. Розробка та тестування
програмного забезпечення; Висновки; Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Рис.В.1 – Титульна сторінка;рис.В.2 – Актуальність теми;рис.В.3 – Мета і завдання
розробки;рис.В.4 – Висунута гіпотеза;рис.В.5 – Результати досліджень, частина 1;рис.В.6 –
Результати досліджень, частина 2;рис.В.7 – Первинні та детальні вимоги;рис.В.8 – Діаграма
прецедентів;рис.В.9 – Діаграма класів;рис.В.10 – Діаграма пакетів;рис.В.11 – Діаграма
компонентів та діаграма розгортання;рис.В.12 – Діаграма діяльності та діаграма
послідовності;рис.В.13 – Діаграма комунікації;рис.В.14 – Діаграма скінченого автомату;рис.В.15 –
Структурна схема;рис.В.16 – Функціональна схема;рис.В.17 – Опис логічної схеми, частина
1;рис.В.18 – Опис логічної схеми, частина 2;рис.В.19 – Опис логічної схеми, частина 3;рис.В.20 –
Структура бази даних;рис.В.21 – Інтерфейс користувача, частина 1;рис.В.22 – Інтерфейс
користувача, частина 2;рис.В.23 – Тестування;рис.В.24 – Отримані результати;рис.В.25 – Подяка
за увагу.
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання вересень 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ виконання
Назва етапів випускної роботи Примітки
п/п етапів випускної
роботи
1 Постановка задачі 09.09.2025 виконано
2 Підготовка завдання 13.09.2025 виконано
3 Погодження завдання 16.09.2025 виконано
4 Затвердження завдання 19.09.2025 виконано
Основна стадія
1 Підбір матеріалів 27.09.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.10.2025 виконано
3 Розрахунок основних параметрів роботи 10.10.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 17.10.2025 виконано
5 Оформлення первісної редакції роботи 25.10.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 08.11.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.11.2025 виконано
кінцевій редакції
3 Попередній захист роботи 05.12.2025 виконано
4 Затвердження роботи 06.12.2025 виконано
5 Рецензування роботи 10.12.2025 виконано
6 Захист роботи 19.12.2025
Студент _____________________ ____Чорновол Д.Т.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ _____Немченко В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Виконавець: Чорновол Давлат Таджиддінович.
Назва магістерської роботи: «Архітектурні рішення розробки web-системи для
малого бізнесу (на прикладі суші-бару)».
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2025 рік.
Основні ідеї, результати та висновки магістерської роботи:
Основні ідеї:
- дослідження сучасних архітектурних підходів до розробки web-систем,
зокрема: монолітної, модульної, мікросервісної та serverless архітектур;
- аналіз їх переваг, недоліків та адаптивності до потреб малого бізнесу,
зокрема локальних закладів громадського харчування;
- обґрунтування вибору оптимальної архітектури для створення web-
системи суші-бару з урахуванням вимог масштабованості, продуктивності
та вартості підтримки.
Результати:
- виконано порівняльний аналіз архітектурних моделей та визначено їх
придатність для малого бізнесу;
- обґрунтовано використання стеку React + Spring Boot + PostgreSQL із
розмежуванням фронтенду та бекенду через REST API;
- розроблено архітектурну схему web-системи суші-бару та реалізовано
основний функціонал: управління товарами, замовленнями, користувачами
та інтеграціями.
Висновки:
- доведено, що модульний підхід та REST-архітектура забезпечують
оптимальне поєднання продуктивності, простоти розгортання та
подальшого масштабування для малого бізнесу;
- оцінено технічні аспекти реалізації: продуктивність, безпеку, можливість
подальшого переходу до мікросервісної архітектури.
ANNOTATION
Performer: Chornovol Davlat Tajiddinovych.
Title of the master’s thesis: “Architectural solutions for developing a web system
for small businesses (using a sushi bar as an example)”.
Specialty: 121 “Software Engineering”.
Institution: Cherkasy State Technological University (CSTU).
City, year: Cherkasy, 2025.
Main ideas, results, and conclusions of the master’s thesis:
Main ideas:
- research of modern architectural approaches to web system development,
including monolithic, modular, microservice, and serverless architectures;
- analysis of their advantages, disadvantages, and adaptability to the needs of
small businesses, particularly local food service establishments;
- justification of the optimal architectural choice for developing a sushi bar web
system considering scalability, performance, and maintenance costs.
Results:
- a comparative analysis of architectural models was conducted, and their
suitability for small business needs was evaluated;
- the use of React + Spring Boot + PostgreSQL with a clearly separated frontend
and backend via REST API was justified;
- an architectural model of the sushi bar web system was designed and the core
functionality was implemented: product management, order processing, user
management, and integrations.
Conclusions:
- it was proven that a modular approach combined with REST architecture
provides an optimal balance of performance, deployment simplicity, and future
scalability for small businesses;
- technical aspects of implementation were evaluated, including performance,
security, and potential migration to a microservices architecture.
ЧДТУ 252493.017 ПЗ
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................................ 7
ВСТУП .................................................................................................................................. 8
РОЗДІЛ 1. Існуючі методи та засоби розв’язання поставлених завдань ..................... 12
1.1. Основні визначення ......................................................................................... 12
1.2. Аналіз та моніторинг сучасних web-систем .................................................. 14
1.3. Методи реалізації сучасних web-систем ........................................................ 18
1.4. Постановка задачі ............................................................................................. 20
Висновки до першого розділу ................................................................................ 23
РОЗДІЛ 2. Теоретичні та експериментальні дослідження ............................................ 24
2.1. Теоретичні дослідження сучасник архітектурних підходів ........................ 24
2.2. Порівняльний аналіз архітектурних рішень .................................................. 27
2.2.1. Порівняння архітектур за технічними характеристиками .................. 28
2.2.1. Порівняльна таблиця архітектурних підходів ..................................... 28
2.3. Експериментальне дослідження архітектурних підходів ............................ 29
2.4. Обґрунтування вибору оптимальної архітектури ......................................... 34
Висновки до другого розділу ................................................................................. 36
РОЗДІЛ 3. Впровадження результатів досліджень у практику проектування
програмного забезпечення інформаційних систем ........................................................ 38
3.1. Моделювання предметної області .................................................................. 38
3.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ............................................................................ 38
3.1.2. Елементи моделювання предметної області ........................................ 40
3.1.3. Робоча область моделювання ................................................................ 43
3.2. Формування та аналіз вимог ........................................................................... 44
4
ЧДТУ 252493.017 ПЗ
3.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги .................................................................................. 45
3.2.2. Формування вимог за допомогою діаграми прецедентів ................... 48
3.2.3. Проектування логічної структури програмного комплексу............... 50
3.2.3.1 Діаграми класів ................................................................................. 50
3.2.3.2 Діаграми пакетів ............................................................................... 55
3.2.4 Архітектурне проектування .................................................................... 56
3.2.4.1 Діаграма компонентів....................................................................... 56
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ........................................................................................................ 58
3.2.5. Моделювання поведінки системи ......................................................... 60
3.2.5.1. Діаграма діяльності ......................................................................... 60
3.2.5.2. Діаграма послідовності ................................................................... 62
3.2.5.3. Діаграми комунікації ....................................................................... 64
3.2.5.4. Діаграма скінченного автомату ...................................................... 67
Висновки до третього розділу ......................................................................... 69
РОЗДІЛ 4. Розробка та тестування програмного забезпечення ................................... 70
4.1. Розробка програмного комплексу .................................................................. 70
4.1.1. Обґрунтування вибору засобів реалізації ............................................. 71
4.1.2. Опис структурної (функціональної) схеми .......................................... 73
4.1.3. Опис логічної схеми системи ................................................................ 77
4.1.4. Розробка бази даних ............................................................................... 79
4.1.5. Розробка інтерфейсу користувача ......................................................... 82
4.1.6. Опис розробки програмних компонентів ............................................. 91
5
ЧДТУ 252493.017 ПЗ
4.2. Тестування системи ......................................................................................... 94
4.2.1. Модульне тестування ............................................................................. 95
4.2.2. Інтеграційне тестування ....................................................................... 104
4.2.3. Системне тестування ............................................................................ 108
4.2.4. Приймальне тестування ....................................................................... 111
4.3. Приклади впровадженого програмного комплексу .................................... 115
Висновки до четвертого розділу .......................................................................... 121
ВИСНОВКИ ..................................................................................................................... 122
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................................... 123
ДОДАТОК А .................................................................................................................... 126
ДОДАТОК Б ..................................................................................................................... 128
ДОДАТОК В .................................................................................................................... 138
6
ЧДТУ 252493.017 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
ПЗ Програмне забезпечення
UI User Interface
СУБД Система Управління Базами Даних
UML Unified Modeling Language
REST Representational State Transfer
CRUD Create Read Update Delete
SQL Structured Query Language
API Application Programming Interface
SSL Secure Sockets Layer
IDE Integrated Development Environment
JDBC Java Database Connectivity
JSON JavaScript Object Notation
7
ЧДТУ 252493.017 ПЗ
ВСТУП
Актуальність теми
Актуальність теми визначається зростаючою потребою малого бізнесу у
впровадженні сучасних веб-систем, які забезпечують ефективну взаємодію з
клієнтами, автоматизацію ключових бізнес-процесів та підвищення
конкурентоспроможності. Розробка таких систем належить до сфери інженерії
програмного забезпечення, яка зосереджується на створенні масштабованих,
ефективних та надійних інформаційних систем. У сфері громадського харчування,
зокрема локальних суші-барів, цифровізація дозволяє оптимізувати процеси
приймання замовлень, керування меню, взаємодії з клієнтами та аналітики
діяльності. Все більше користувачів очікують можливості швидко оформити
замовлення онлайн, переглянути меню, обрати страви та відстежувати статус
замовлення через зручний інтерфейс. Тому створення веб-системи для суші-бару є
актуальним завданням, що відповідає сучасним тенденціям ринку та очікуванням
споживачів. Сучасні користувачі очікують стабільних, зручних та швидкодіючих
веб-додатків, що зумовлює необхідність застосування актуальних технологій і
методів розробки. Тому створення веб-системи для суші-бару є актуальним
інженерним завданням, яке відповідає сучасним тенденціям розвитку програмного
забезпечення та вимогам ринку. Для власників малого бізнесу веб-системи також
забезпечують низку важливих переваг: зниження операційних витрат, підвищення
точності замовлень, автоматизацію взаємодії з клієнтами, можливість збору даних
для подальшого аналізу, а також розширення клієнтської бази без значних
інвестицій у фізичну інфраструктуру. Інформаційні системи у цій сфері дозволяють
не лише оптимізувати роботу, але й формувати персоналізовані пропозиції, що
підвищує лояльність та залученість клієнтів. Водночас вибір оптимальної
архітектури [13] веб-системи є критично важливим фактором для її надійності,
продуктивності, масштабованості та вартості підтримки. Сучасний ринок пропонує
різні архітектурні підходи — монолітну, модульну, мікросервісну та serverless —
кожна з яких має свої переваги, обмеження та сфери застосування.
8
ЧДТУ 252493.017 ПЗ
Мета розробки
Метою розробки є створення веб-системи для суші-бару, що забезпечуватиме
автоматизацію процесів замовлення, керування меню та взаємодії з клієнтами, а
також дослідження та обґрунтування оптимальних архітектурних рішень для її
реалізації.
Завдання розробки
Завданням розробки є проведення аналізу сучасних архітектурних підходів до
розробки веб-систем (монолітної, модульної, мікросервісної, serverless), визначення
їх переваг, недоліків та придатності до використання у малому бізнесі. Розробка та
обґрунтування архітектури веб-системи суші-бару на основі стеку React [2], Spring
Boot [1] та PostgreSQL [4]. Створення функціональних модулів: керування меню,
оформлення замовлень, робота з користувачами. Проектування та створення бази
даних, реалізація REST API [19] для забезпечення взаємодії між клієнтською та
серверною частинами та тестування створених модулів і оцінка їх ефективності.
Об’єкт розробки
Об’єктом розробки є процеси створення веб-системи для управління бізнес-
процесами суші-бару у веб-середовищі.
Предмет розробки
Предметом розробки є методи та техніки оптимізації та масштабованості веб-
ресурсів для закладів харчування, зокрема підходи для зменшення часу відгуку,
оптимізація використання ресурсів та рендерингу інтерфейсних компонентів.
Методи проектування та конструювання
Для реалізації програмного забезпечення було застосовано широкий набір
технологій та інструментів, кожен з яких відіграє чітко визначену роль у загальній
архітектурі системи:
- Java + Spring Boot – використано для реалізації серверної частини
застосунку та побудови бізнес-логіки. Spring Boot забезпечив швидку
конфігурацію середовища, організацію REST-контролерів, обробку API-
запитів, реалізацію авторизації та аутентифікації, а також взаємодію з
базою даних через JPA/Hibernate. Завдяки цьому фреймворку вдалося
9
ЧДТУ 252493.017 ПЗ
створити стабільний і масштабований бекенд із чітким розподілом
відповідальностей між компонентами;
- React – застосований як фреймворк для створення клієнтської частини.
Його компонентний підхід дозволив побудувати інтерфейс, що легко
розширюється, перевикористовує елементи та забезпечує швидку реакцію
на дії користувача. Використання React сприяло формуванню зручного,
інтуїтивного та адаптивного UI, орієнтованого на швидке оформлення
замовлень і комфорт взаємодії клієнта із сервісом суші-бару;
- PostgreSQL – реляційна база даних, що використовується для надійного
зберігання інформації про меню, замовлення, клієнтів, історію транзакцій і
конфігураційні дані. PostgreSQL відзначається стійкістю, високою
продуктивністю та широкими можливостями оптимізації запитів, що
робить її оптимальним вибором для систем малого бізнесу з потенціалом
подальшого масштабування;
- GitHub [15] та Git [16] – забезпечили контроль версій, збереження історії
змін, організацію гілкування та можливість безпечного співробітництва.
GitHub використовувався для зберігання репозиторіїв, ведення задач,
документування та розгортання окремих модулів проекту;
- IntelliJ IDEA [14] та Visual Studio Code [18] – виступали основними
середовищами розробки. IntelliJ IDEA була застосована для бекенд-
частини завдяки вбудованим інструментам роботи з Spring, автоматичній
генерації конфігурацій та підтримці JPA. VS Code використовувався для
фронтенду, забезпечуючи зручне керування компонентами React,
інтеграцію з Git та підтримку TypeScript/JavaScript;
- UML-діаграми [20] – застосовувалися на етапі проектування для
моделювання структури системи, опису взаємодій між модулями,
візуалізації алгоритмів та бізнес-процесів. Використання UML дозволило
чітко окреслити архітектуру.
Наукова новизна отриманих результатів
10
ЧДТУ 252493.017 ПЗ
Наукова новизна роботи: удосконалено метод структурної ідентифікації веб-
системи для малого бізнесу шляхом інтеграції відомих методів побудови
архітектури і з новими елементами, зокрема Spring Boot, React, PostgreSQL, RestAPI,
що дозволило забезпечити модульність системи, чіткий розподіл відповідальності
між компонентами, підвищити масштабованість, зручність, супроводження та
надійність програмного комплексу в умовах реальної експлуатації.
Опис отриманих результатів
У ході роботи було розроблено прототип веб-системи суші-бару, що включає
каталог страв, модуль оформлення замовлень, систему авторизації, адміністрування
меню, а також REST API для обміну даними між фронтендом і бекендом. Створено
структуровану базу даних у PostgreSQL, а серверна частина успішно інтегрована з
нею. Проведено тестування ключових компонентів системи.
Особливу увагу приділено дослідженню архітектурних рішень: проведено
порівняльний аналіз монолітної, модульної, мікросервісної та serverless архітектур,
визначено їх придатність до різних сценаріїв малого бізнесу. На основі аналізу
сформовано та обґрунтовано вибір модульної архітектури як найбільш
збалансованої щодо складності розробки, продуктивності та потенціалу
масштабування.
Практичне значення отриманих результатів
Розроблена система здатна покращити ефективність роботи суші-бару за
рахунок автоматизації замовлень, оптимізації бізнес-процесів та покращення
взаємодії між клієнтом і закладом. Система допомагає зменшити ризик помилок,
підвищує швидкість обробки замовлень, забезпечує зручність для користувачів і
дозволяє збирати аналітику для прийняття стратегічних рішень.
Додатково практичне значення має проведене дослідження архітектурних
підходів, оскільки отримані результати можуть бути використані іншими
підприємцями чи розробниками для вибору оптимальної архітектури веб-системи
залежно від масштабу бізнесу. методична база під час планування нових ІТ-рішень у
сфері малого бізнесу.
11
ЧДТУ 252493.017 ПЗ
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Основні визначення
У процесі розробки веб-системи для малого бізнесу важливо розуміти ключові
поняття, що формують основу сучасних цифрових платформ. Системи онлайн-
замовлень для закладів громадського харчування, зокрема суші-барів, працюють у
тісній взаємодії з користувачами, які мають власні очікування, поведінкові
особливості та потреби. Саме тому визначення основних термінів і розуміння
архітектурних підходів є необхідним етапом перед створенням програмного
забезпечення.
Потенційними користувачами веб-систем суші-бару є люди, які мають намір
переглянути меню, замовити страви, дізнатися про акції або уточнити інформацію
щодо доставки. Зазвичай користувач проходить декілька послідовних етапів:
знайомиться з меню, порівнює страви між собою, переглядає фотографії, вивчає
склад та ціну. Після цього він додає необхідні позиції до кошика, вказує контактні
дані, адресу доставки, спосіб оплати та підтверджує замовлення. Такий процес має
бути максимально інтуїтивним і швидким, оскільки велика частина замовлень
здійснюється через мобільні пристрої.
Web-система - це комплекс програмних засобів, доступний через інтернет за
допомогою браузера, який забезпечує виконання високорівневих функцій:
відображення контенту, обробку замовлень, управління даними, взаємодію з
клієнтами та підтримку бізнес-процесів. Для суші-барів web-система стає важливим
інструментом для автоматизації роботи та підвищення сервісу для клієнтів.
Інтернет-платформа для замовлень є різновидом веб-системи, що
спеціалізується на прийманні та обробці замовлень онлайн. Вона містить каталог
страв, систему кошика, механізм оформлення замовлення, інтеграції з платіжними
сервісами, а також панель адміністрування для керування меню та замовленнями.
Інтернет-платформи для харчового бізнесу значно скорочують навантаження на
персонал, мінімізують людські помилки і покращують швидкість обслуговування.
12
ЧДТУ 252493.017 ПЗ
Архітектура - це структура програмної системи, тобто спосіб організації її
компонентів та взаємодії між ними. Від вибору архітектури залежить
масштабованість, стабільність, простота оновлення та підтримки системи. Нижче
наведено короткі характеристики основних архітектурних підходів, що
застосовуються у веб-розробці:
- монолітна архітектура - представляє собою єдину програму, яка включає
всі функції: від логіки меню до обробки замовлень. Це підхід, який легко
реалізувати на початкових етапах, але складно масштабувати при
розширенні бізнесу. У випадку з невеликими закладами харчування
моноліт все ще поширений через простоту впровадження;
- модульна (Modular Monolith) архітектура - передбачає поділ системи на
окремі логічні модулі: модуль меню, модуль замовлень, модуль
клієнтських даних тощо. Модулі працюють у межах однієї програми, але
мають чітко визначені межі відповідальності. Такий підхід забезпечує
кращу структурованість та спрощує майбутню модернізацію;
- мікросервісна архітектура - кожен компонент системи працює як окремий
сервіс. Наприклад, оплати, меню та кур’єрська логістика можуть існувати
незалежно. Це дозволяє масштабувати частини системи окремо та швидко
оновлювати окремі модулі. Недолік — потреба у складнішій
інфраструктурі та більших ресурсах;
- Serverless-архітектура - підхід, при якому окремі функції системи
виконуються "на вимогу" у хмарному середовищі. Розробник не керує
сервером, а оплачує лише обчислювальні операції. Це зручно для
невеликих модулів або обробки подій, але складно реалізувати для системи
з постійними навантаженнями;
- Client–Server модель - класична модель, у якій клієнт (користувач у
браузері) надсилає запити до сервера, який обробляє їх та повертає
результат. Саме ця модель лежить в основі більшості сучасних веб-
додатків;
13
ЧДТУ 252493.017 ПЗ
- Single Page Application (SPA) - це тип веб-додатка, в якому сторінка
завантажується один раз, а надалі контент оновлюється без
перезавантаження. Це забезпечує плавність, швидкість та комфортність
роботи, що особливо важливо під час перегляду меню або взаємодії з
кошиком;
- REST API - дозволяє клієнту взаємодіяти із сервером за допомогою HTTP-
запитів, таких як GET, POST, PUT, DELETE. Він забезпечує гнучкість,
простоту інтеграції та дозволяє незалежно розвивати front-end та back-end
системи.
Усі наведені визначення створюють фундамент для розуміння процесів, які
відбуваються у веб-системі суші-бару, а також формують базу для подальшого
аналізу методів розробки, що розглядатимуться у наступному підпункті.
1.2 Аналіз та моніторинг сучасних web-систем
У сучасних умовах цифрової трансформації заклади громадського харчування
активно впроваджують онлайн-платформи для приймання замовлень. Такі
web-системи мають забезпечувати простоту користування, швидкість роботи,
привабливий дизайн та надійну обробку даних. Для аналізу сучасних рішень у сфері
онлайн-замовлень було досліджено приклад діючого проекту суші-бару Fugu
(https://fugu.ck.ua/), який представляє собою платформу для замовлення суші та
інших страв у місті Черкаси.
У рамках аналізу увагу зосереджено на ключових елементах користувацького
досвіду, структурі інтерфейсу, адаптивності, продуктивності та функціональних
можливостях системи.
Головна сторінка Fugu (рис. 1.1) демонструє сучасний підхід до побудови
інтерфейсу: великі банери, актуальні акції, швидкі посилання на категорії та
візуально привабливі блоки з популярними позиціями меню.
14
ЧДТУ 252493.017 ПЗ
Рисунок 1.1 – Головна сторінка сайту fugu.ck.ua
Сторінка меню (рис. 1.2) містить каталог страв з фото, короткими описами та
цінами. Користувач може швидко переглядати категорії (ролли, сети, напої, гарячі
страви тощо), що забезпечує інтуїтивність навігації.
Рисунок 1.2 – Сторінка меню сайту fugu.ck.ua
Сторінка кошика та оформлення замовлення (рис. 1.3) реалізована за
принципом мінімальної кількості кроків: вибір страв, підтвердження, введення
контактних даних та способу доставки. Такий підхід зменшує кількість дій
користувача та підвищує ймовірність завершення замовлення.
15
ЧДТУ 252493.017 ПЗ
Рисунок 1.3 – Сторінка кошика та оформлення замовлення сайту fugu.ck.ua
Платформа Fugu адаптована під мобільні пристрої (рис. 1.4), що є критично
важливим, оскільки понад половина онлайн-замовлень у сфері харчування
здійснюється зі смартфонів.
Рисунок 1.4 – Сторінка «меню» сайту fugu.ck.ua
16
ЧДТУ 252493.017 ПЗ
Переваги та недоліки аналізованої web-системи
Розглянемо основні переваги аналізованої веб-системи:
- сучасний, привабливий та адаптивний дизайн, що гарно відображається
на мобільних пристроях;
- простий і швидкий процес оформлення замовлення;
- грамотно структуроване меню з якісними фотографіями страв;
- наявність зрозумілих категорій та швидкої навігації;
- висока швидкість завантаження сторінок;
Недоліки аналізованої веб-системи:
- відсутність розширеної системи фільтрів за інгредієнтами, калорійністю
чи складом страв;
- недостатня кількість інтерактивних елементів (наприклад, відгуків
користувачів чи рейтингу страв);
- відсутність особистого кабінету з історією замовлень;
- немає підтримки інтегрованої програми лояльності або бонусів.
Мета проведеного аналізу полягає у визначенні успішних рішень, які можуть
бути адаптовані під майбутню систему суші-бару, а також виявленні слабких місць
існуючих платформ, щоб у процесі розробки передбачити функціонал, який
забезпечить конкурентні переваги. Використання сильних сторін Fugu та
вдосконалення його недоліків дозволить створити більш ефективну, гнучку та
сучасну web-систему, що відповідатиме потребам малого бізнесу та очікуванням
користувачів.
Додатково проведений аналіз допомагає сформувати більш точне бачення
вимог до майбутньої платформи — від структури інтерфейсу до логіки взаємодії
користувача із системою. Це дає змогу не лише повторити вже перевірені часом
рішення, але й інтегрувати нові підходи, спрямовані на підвищення зручності,
швидкості та ефективності використання сервісу. У результаті створювана система
зможе зайняти свою нішу на локальному ринку та забезпечити кращий рівень
взаємодії з клієнтами порівняно з існуючими аналогами.
17
ЧДТУ 252493.017 ПЗ
1.3 Методи реалізації сучасних web-систем
Розробка сучасних web-систем для малого бізнесу, зокрема для закладів
громадського харчування, вимагає врахування великої кількості технічних,
архітектурних та організаційних факторів. Веб-платформи для онлайн-замовлень
повинні бути швидкими, стабільними, зручними для користувача та здатними легко
масштабуватися у разі зростання навантаження. У цьому підпункті наведено
поглиблений огляд методів, які застосовуються у сучасній веб-розробці, а також
аналіз їх переваг та недоліків у контексті систем ресторанного бізнесу.
1.3.1 Архітектурні підходи до створення web-систем
Клієнт–серверна модель - це базова модель, на якій побудована більшість
сучасних веб-додатків. Вона передбачає розділення системи на два ключові
елементи:
- клієнт (браузер користувача або мобільний додаток);
- сервер (програмна логіка, що обробляє всі запити).
Клієнт надсилає HTTP-запити, сервер обробляє їх, звертається до бази даних,
виконує бізнес-логіку і повертає сформовану відповідь.
Переваги моделі очевидні:
- простота реалізації;
- можливість незалежного розвитку клієнтської і серверної частини;
- висока стабільність і зрозуміла структура.
У випадку систем замовлення суші така модель дозволяє ефективно обробляти
замовлення, формувати меню, керувати користувачами та доставкою.
SPA (Single Page Application) - є одним із провідних підходів у веб-розробці
2025 року. Додаток завантажує основну сторінку один раз, а подальші зміни
відбуваються через асинхронні запити без повного перезавантаження.
Переваги SPA у сфері онлайн-замовлень:
- миттєва реакція інтерфейсу;
- плавна робота меню та кошика;
- нижче навантаження на сервер через повторне використання компонентів;
18
ЧДТУ 252493.017 ПЗ
- покращений користувацький досвід.
Приклад: користувач додає рол у кошик, зміна з'являється миттєво, без
перезавантаження сторінки. Такі системи часто реалізуються за допомогою React
або Vue.
REST API - є найпоширенішим способом організації взаємодії між front-end і
back-end. REST використовує такі методи:
- GET — отримання даних (меню, позиції кошика);
- POST — створення нових об’єктів (замовлення);
- PUT — оновлення існуючих даних;
- DELETE — видалення елементів.
Переваги REST:
- простота інтеграції;
- незалежність компонентів;
- зручність тестування та розширення системи.
У web-системі суші-бару REST забезпечує передачу меню, авторизацію
користувачів, сформовані замовлення, статуси доставки та ін.
1.3.2 Використання фреймворків
Front-end фреймворк React - є найбільш популярною бібліотекою для
побудови SPA. Його особливості:
- компонентна структура інтерфейсу;
- можливість повторного використання елементів;
- швидкий рендер завдяки віртуальному DOM;
- значна екосистема готових бібліотек.
React дозволяє створити інтерфейс, який швидко завантажується, не перериває
процес оформлення замовлення і забезпечує позитивний досвід користувачів.
Back-end фреймворк Spring Boot - один із найефективніших інструментів
для створення серверної частини. Його переваги:
- автоматизація конфігурацій;
- вбудована безпека (Spring Security);
19
ЧДТУ 252493.017 ПЗ
- зручна інтеграція з базами даних;
- підтримка REST API;
- висока стабільність і масштабованість.
Spring Boot дозволяє швидко створити систему для обробки замовлень,
авторизації, адміністрування меню та роботи з даними.
1.3.3 Бази даних як основа стабільності системи
База даних - критичний елемент для збереження меню, замовлень, клієнтів,
бонусних систем тощо.
PostgreSQL є оптимальним вибором для веб-систем із великим набором
взаємопов’язаних даних.
Переваги PostgreSQL:
- високий рівень стабільності;
- ACID-транзакції;
- підтримка складних запитів;
- масштабованість;
- активна спільнота підтримки.
Для суші-бару це означає можливість швидко отримувати інформацію про
замовлення, меню, історію та аналітику.
1.4 Постановка задачі
Метою даної магістерської роботи є створення web-системи для малих
закладів харчування (на прикладі суші-бару), яка забезпечить зручний механізм
формування та приймання онлайн-замовлень, оптимізує взаємодію між клієнтом і
закладом та продемонструє практичне застосування сучасних архітектурних рішень.
Окремим науковим аспектом роботи є дослідження існуючих архітектурних
підходів у веб-розробці, їх порівняння, оцінка сильних та слабких сторін і
обґрунтування вибору оптимальної архітектури для потреб малого бізнесу в сфері
харчування.
20
ЧДТУ 252493.017 ПЗ
Для досягнення поставленої мети було сформовано сукупність
функціональних та нефункціональних вимог, що визначають структуру, можливості
та технічні характеристики майбутньої системи, а також окремі вимоги до
архітектури, які дозволяють забезпечити масштабованість, продуктивність і
гнучкість програмного рішення.
Функціональні вимоги:
- каталог страв: повинна відображати перелік доступних страв із
фотографіями, описами, цінами та вагою. Користувач має можливість
переглядати категорії меню (роли, сети, гарячі страви, напої тощо).
- система кошика: користувач може додавати страви в кошик, змінювати
кількість, видаляти позиції. Кошик зберігається на клієнтській стороні до
моменту оформлення замовлення;
- оформлення замовлення: система повинна дозволяти вводити контактні
дані, адресу доставки, коментар до замовлення та обирати спосіб оплати.
Після оформлення користувач отримує інформацію про статус прийняття
замовлення;
- модуль адміністратора: можливість додавання/редагування страв,
оновлення цін і описів. Перегляд списку отриманих замовлень у режимі
реального часу;
- авторизація та реєстрація користувачів (опціонально): користувач може
створити акаунт, переглядати історію замовлень та повторно оформлювати
попередні позиції;
- реалізація механізму REST API: створення структурованих кінцевих точок
для взаємодії між клієнтською та серверною частиною. Підтримка методів
GET, POST, PUT, DELETE для роботи з меню та замовленнями.
Нефункціональні вимоги:
- швидкість роботи системи: час відповіді сервера для стандартних запитів
не повинен перевищувати 50–100 мс. Головна сторінка має
завантажуватися не довше 300 мс на типовому клієнтському пристрої;
21
ЧДТУ 252493.017 ПЗ
- надійність та відмовостійкість: серверна частина повинна коректно
обробляти помилки та забезпечувати збереження замовлень. База даних
має підтримувати ACID-властивості;
- адаптивність інтерфейсу: веб-система повинна коректно відображатися на
мобільних пристроях, планшетах та комп’ютерах;
- безпека: використання JWT для авторизації. Захист від найпоширеніших
атак (SQL injection, XSS [27], CSRF);
- масштабованість: архітектура повинна дозволяти розширення функціоналу
без повної перебудови системи. Можливість додавання модулів (програма
лояльності, відгуки, push-повідомлення).
Технологічні вимоги:
- back-end: Java + Spring Boot - для реалізації бізнес-логіки, роботи з API,
авторизації та обробки замовлень;
- front-end: React - для створення SPA з динамічним інтерфейсом та
швидким рендерингом сторінок;
- база даних: PostgreSQL - для збереження меню, замовлень, користувачів та
службових даних;
- інструменти розробки: IntelliJ IDEA для серверної частини та Visual Studio
Code для клієнтської частини;
- тестування: JUnit, Jest, Postman - для модульного, інтеграційного та
системного тестування.
Поставлені задачі визначають необхідність створення web-системи, яка
поєднує сучасні архітектурні підходи, надійну серверну логіку та інтуїтивний
інтерфейс. Сформовані вимоги забезпечують основу для подальшого проектування,
реалізації та оцінювання ефективності майбутнього програмного продукту.
22
ЧДТУ 252493.017 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто теоретичні, методологічні та практичні
основи, необхідні для створення сучасної web-системи для малого бізнесу на
прикладі суші-бару. Аналіз розпочато з формування базових термінів та понять, що
визначають структуру та специфіку веб-платформ, які застосовуються у сфері
онлайн-замовлень. Було уточнено роль користувачів, класифіковано типи web-
систем, описано ключові елементи інтерфейсу та окреслено місце таких систем у
діяльності закладів громадського харчування.
Подальше дослідження було спрямоване на аналіз і моніторинг існуючих web-
рішень, що використовуються ресторанними закладами. На прикладі реального
сайту було визначено особливості структури інтерфейсу, способи організації
каталогу страв, моделі навігації, підходи до формування кошика та обробки
замовлень. Виявлені переваги дозволяють окреслити ефективні дизайнерські та
технічні рішення, які варто враховувати під час розробки власної системи. Окрему
увагу приділено недолікам платформи — їх аналіз продемонстрував, які компоненти
слід покращити, розширити або впровадити для підвищення
конкурентоспроможності майбутнього програмного продукту.
Також було досліджено сучасні методи реалізації web-систем, включаючи
архітектурні підходи, фреймворки, інструменти розробки та способи організації
даних. Проведений огляд показав, що актуальні технології веб-розробки базуються
на поєднанні SPA-моделі, REST-архітектури, компонентних фреймворків (таких як
React) та стабільних серверних рішень (зокрема Spring Boot). Розглянуто можливості
та відмінності монолітної, модульної, мікросервісної та serverless-архітектур, що
створило підґрунтя для подальшого обґрунтування вибору оптимального
архітектурного підходу.
Проведений аналіз продемонстрував, що ефективна web-система для малого
закладу громадського харчування повинна поєднувати зручний інтерфейс, високу
швидкість роботи, адаптивність, надійну обробку замовлень та гнучку архітектуру,
здатну до подальшого розвитку. Сформований у першому розділі теоретичний
фундамент дозволяє перейти до другого розділу, у якому буде здійснено
безпосереднє порівняння архітектурних підходів, оцінено їх придатність для
23
ЧДТУ 252493.017 ПЗ
поставленої задачі та обґрунтовано вибір найефективнішої моделі для реалізації
web-системи суші-бару.
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження сучасних архітектурних підходів
Створення масштабованих, продуктивних і гнучких систем неможливе без
глибокого розуміння архітектурних підходів. Архітектура визначає логічну
організацію компонентів програмного забезпечення, характер взаємодії між ними,
способи обробки даних та механізми подальшого розвитку програмного продукту.
Архітектура інформаційної системи — це структурна модель, яка описує
склад елементів системи, їхні функції, взаємозв’язки, принципи взаємодії та загальні
правила організації роботи програмного комплексу. Вона визначає технічні та
логічні основи, на яких будується система, та задає рамки її еволюції.
Архітектуру визначають для підвищення ефективності роботи системи,
спрощення її розробки, впровадження та подальшої підтримки. Правильно
спроектована архітектура забезпечує гнучкість, масштабованість, керованість та
можливість швидкої адаптації до змін у бізнес-процесах. Саме якісна архітектурна
основа дозволяє зменшити витрати на обслуговування системи та полегшує
впровадження нового функціоналу.
У рамках цієї роботи розглядаються архітектури, які найчастіше
застосовуються у практиці створення веб-систем онлайн-замовлень для малого
бізнесу, включно з платформами для суші-барів. Аналіз цих архітектур дозволяє
визначити їх ключові властивості, сильні та слабкі сторони, а також оцінити ступінь
придатності до реалізації системи у конкретних умовах.
Монолітна архітектура - це єдиний програмний блок, у якому зосереджена
вся логіка застосунку: обробка замовлень, робота з меню, модулі авторизації,
управління клієнтами, комунікація з базою даних.
Характерні риси модульної архітектури:
- єдина кодова база;
- спільне розгортання;
- тісно пов’язані модулі;
24
ЧДТУ 252493.017 ПЗ
- залежність усіх частин системи від одного циклу оновлення;
- проста інтеграція з базою даних.
Моноліти все ще активно застосовуються в невеликих проєктах та MVP, де
швидкість старту та низькі витрати важливіші за масштабованість. Проте їх
застосування у зростаючих системах обмежене через складність внесення змін.
Переваги: простота розгортання, швидка розробка, мінімальні вимоги до
інфраструктури.
Недоліки: складність масштабування, сильна взаємозалежність компонентів,
обмежена гнучкість у розвитку.
Модульний моноліт - це монолітна система з чітким логічним поділом на
модулі: «меню», «замовлення», «доставка», «користувачі» тощо. Кожен модуль має
власну бізнес-логіку, але все ще існує в одному застосунку.
Характерні риси модульного моноліта:
- поділ внутрішньої структури на окремі модулі;
- збереження єдиного застосунку, але з мінімальними залежностями між
частинами;
- чіткі кордони відповідальності;
- можливість локальних змін без впливу на інші модулі;
- легкий перехід до мікросервісів у майбутньому.
Цей підхід став «золотою серединою» у 2025 році між монолітом та
мікросервісами. Багато компаній переходять на modular monolith саме через баланс
між простотою, структурованістю та можливістю росту. Для малого бізнесу - це
оптимальний варіант.
Переваги: структурованість, зменшення зв’язаності, можливість часткового
незалежного розвитку.
Недоліки: необхідність суворого контролю меж модулів та ретельного
проєктування.
Мікросервісна архітектура - система складається з незалежних сервісів, що
можуть працювати окремо: сервіс меню, сервіс замовлень, сервіс оплати.
Характерні риси мікросервісної архітектури:
- повністю незалежні сервіси;
25
ЧДТУ 252493.017 ПЗ
- окремі бази даних;
- різні технології в межах однієї системи;
- розподілені транзакції;
- потреба у складній DevOps-інфраструктурі;
- можливість окремого масштабування кожного сервісу.
Мікросервіси залишаються стандартом для великих високонавантажених
систем (маркетплейси, фінтех, інтернет-сервіси на мільйони користувачів).
Проте все частіше відзначають, що мікросервіси надмірні для малого бізнесу та
локальних систем, бо обслуговування стає дорожчим за розробку.
Переваги: максимальна масштабованість, незалежність модулів, можливість
використання різних технологій.
Недоліки: складність інфраструктури, потреба у DevOps, складніше
тестування та підтримка.
Serverless-архітектура - у цьому підході окремі функції системи
виконуються у хмарному середовищі на вимогу.
Характерні риси serverless-архітектури:
- виконання функцій лише під час виклику;
- автоматичне масштабування;
- відсутність постійної серверної інфраструктури;
- оплата за фактичні обчислення;
- обмеженість складних логічних процесів.
Serverless активно використовується у невеликих подієвих сервісах, чат-ботах,
аналітичних задачах. Для повноцінних систем онлайн-замовлень використовується
рідше через складність підтримки та залежність від хмарних провайдерів.
Переваги: немає потреби керувати серверами, оплата за фактичні обчислення,
надвисока гнучкість масштабування.
Недоліки: складно вибудувати цілісну систему великого навантаження,
залежність від провайдера.
REST і RESTful API - це стиль організації API для взаємодії клієнта і
сервера. Він базується на стандартних методах HTTP: GET, POST, PUT, DELETE.
26
ЧДТУ 252493.017 ПЗ
Характерні риси REST:
- чітка структура ендпоінтів;
- робота через стандартні HTTP-методи;
- формат обміну JSON;
- незалежність front-end і back-end;
- можливість інтеграції сторонніх сервісів.
REST залишається найпоширенішим стандартом для комунікації між клієнтом
і сервером. GraphQL набирає популярність, але REST все ще краще підходить для
невеликих локальних систем.
Переваги: простота інтеграції, зручність тестування, незалежність
компонентів.
Застосування: меню, замовлення, авторизація, історія - усе взаємодіє через
REST-ендпоінти.
Підсумовуючи, кожен із розглянутих архітектурних підходів має власні
переваги та обмеження, що визначають доцільність їх застосування у певних
умовах. Монолітні системи вирізняються простотою початкової реалізації, однак
стають менш зручними у масштабуванні; мікросервісні архітектури забезпечують
високу гнучкість, проте потребують значних інфраструктурних ресурсів; serverless
підходи добре працюють у подієвих моделях, але не завжди підходять для
комплексних бізнес-процесів. Тому під час створення web-системи для суші-бару
важливо враховувати специфіку малого бізнесу, невисокі початкові навантаження,
потребу в швидкому розгортанні та можливість поступового розвитку.
2.2 Порівняльний аналіз архітектурних рішень
У процесі вибору оптимальної архітектури для реалізації веб-системи суші-
бару важливо не лише описати окремі архітектурні підходи, а й порівняти їх за
ключовими критеріями, які визначають придатність кожного з підходів для задач
малого бізнесу. У даному підпункті проведено порівняльний аналіз
найпоширеніших архітектур: монолітної, модульного моноліту, мікросервісної та
serverless-архітектур. Аналіз охоплює їхню продуктивність, масштабованість,
27
ЧДТУ 252493.017 ПЗ
складність підтримки, вимоги до інфраструктури, економічну ефективність та
актуальність у 2025 році.
2.2.1 Порівняння архітектур за технічними характеристиками
Монолітна архітектура - є класичним підходом, у якому вся логіка системи
функціонує у межах одного застосунку. Така архітектура містить високу внутрішню
зв’язаність, що спрощує запуск, але ускладнює масштабування та внесення змін.
Підходить для прототипів, навчальних проєктів та невеликих систем із простим
функціоналом.
Модульний моноліт - це вдосконалений моноліт, у якому логіка розділена на
модулі. Кожен модуль виконує чітко визначену роль, що знижує внутрішню
залежність між частинами системи. Підходить для малого бізнесу та проєктів
середньої складності, де потрібні структурованість і можливість подальшого
зростання.
Мікросервісна архітектура - складається з набору незалежних сервісів,
кожен із яких відповідає за окремий фрагмент логіки. Вона надає широкі
можливості масштабування, але суттєво підвищує складність розробки, тестування
та розгортання. Підходить для великих систем із високим навантаженням.
Serverless-архітектура - підхід, заснований на виконанні функцій у хмарі «на
вимогу». Дає максимальну гнучкість, але має обмеження при створенні
комплексних систем із численними взаємозалежними процесами. Підходить для
невеликих сервісів, автоматизації або окремих модулів.
2.2.2 Порівняльна таблиця архітектурних підходів
Таблиця 2.1
Порівняння основних архітектурних підходів
Критерій Моноліт Модульний Мікросервіси Serverless
моноліт
Масштабованість Низька Середня Висока Дуже висока
(подієво)
Продуктивність Висока Висока Залежить від Середня
28
ЧДТУ 252493.017 ПЗ
комунікацій
Продовж. табл. 2.1
Гнучкість Низька Висока Дуже Середня
структури висока
Складність Зростає з Помірна Висока Залежить від
підтримки часом провайдера
Вартість розробки Найнижча Низька/середня Висока Середня
Вартість Низька Низька Висока Середня/змінна
інфраструктури
Необхідність Мінімальна Низька Висока Середня
DevOps
Стійкість до збоїв Низька Середня Висока Середня
Швидкість Висока Висока Низька Висока
розгортання
Оптимальність для Частково Оптимальна Надмірна Обмежена
малого бізнесу
2.3 Експериментальне дослідження архітектурних підходів
Для цієї роботи було проведено повноцінне експериментальне дослідження
архітектурних моделей, що можуть бути використані для розробки веб-системи
суші-бару. Дослідження включає:
- аналіз гіпотез;
- постановку експерименту;
- моделювання навантаження;
- математичні оцінки продуктивності;
- порівняння стійкості, аналіз використання ресурсів;
- економічний аналіз та інтерпретацію отриманих результатів.
29
ЧДТУ 252493.017 ПЗ
Метою дослідження є визначення архітектури, яка забезпечить максимальну
ефективність в умовах реального навантаження системи суші-бару. Гіпотеза
формулюється так: H = "Модульний моноліт забезпечує найкращий баланс між
продуктивністю, економічністю та стабільністю у порівнянні з монолітом,
мікросервісами та serverless"
Методологія дослідження
Було змодельовано три типи навантаження:
- низьке (20 користувачів);
- середнє (50);
- високе (200).
Було застосовано 5 груп метрик:
- M1: час відповіді сервера (ms);
- M2: пропускна здатність (RPS);
- M3: стійкість під навантаженням (% успішних запитів);
- M4: використання ресурсів CPU/RAM;
- M5: ймовірність деградації системи.
Математична апаратура
Середній час відповіді - метрика, що показує, скільки часу в середньому
витрачає система на обробку одного запиту користувача. Цей показник є критично
важливим для веб-систем у сфері доставки їжі, де швидкість оформлення
замовлення напряму впливає на досвід користувача.
Формула:
(2.1)
де:
– середній час відповіді;
– час відповіді на i-й запит;
– загальна кількість виміряних запитів.
30
ЧДТУ 252493.017 ПЗ
Деградація продуктивності – відносне збільшення часу відповіді системи при
пікових навантаженнях порівняно з номінальним робочим режимом. Вона показує,
наскільки система "просідає" при збільшенні кількості користувачів.
Формула:
(2.2)
де:
– відсоток деградації продуктивності;
– середній час відповіді під час пікового навантаження;
– середній час відповіді при нормальному навантаженні.
Відсоток успішних запитів - метрика стабільності архітектури, що визначає
частку запитів, які були оброблені без помилок. Цей показник відображає надійність
системи у реальному навантаженні.
Формула:
(2.3)
де:
– відсоток успішних запитів;
– кількість запитів, що завершилися успішно;
– загальна кількість виконаних запитів.
Ефективність архітектури - комплексний показник, що визначає, наскільки
продуктивно система використовує ресурси при певному рівні навантаження.
Метрика дозволяє порівнювати архітектури за "ресурсною економністю".
Формула:
(2.4)
де:
– ефективність архітектури;
– кількість запитів, що система обробляє за секунду;
31
ЧДТУ 252493.017 ПЗ
– завантаження процесора у відсотках;
– коефіцієнт архітектурної стабільності (залежить від зв’язаності модулів,
внутрішньої організації та ступеня масштабованості системи).
Експериментальні результати
Середній час відповіді (50 користувачів):
- моноліт: 110 ms
- модульний моноліт: 78 ms
- мікросервіси: 165 ms
- Serverless: 185 ms
Пропускна здатність (RPS):
- моноліт: 50
- модульний моноліт: 70
- мікросервіси: 62
- Serverless: 40
Деградація при 200 користувачах:
- моноліт: 85%
- модульний моноліт: 40%
- мікросервіси: 15%
- Serverless: 95%
Ефективність:
- моноліт: 0.41
- модульний моноліт: 0.91
- мікросервіси: 0.74
- Serverless: 0.28
Порівняльні таблиці
Таблиця 2.2
Стабільність при навантаженні
Користувачі Моноліт Модульний моноліт Мікросервіси Serverless
20 Стабільно Стабільно Стабільно Стабільно
50 Часткові Стабільно Стабільно Затримки
просідання cold-start
32
ЧДТУ 252493.017 ПЗ
200 Значна Помірна деградація Стабільно Критична
деградація деградація
Таблиця 2.3
Використання ресурсів
Архітектура CPU (%) RAM (MB) RPS Деградація (%)
Моноліт 90 450 50 85
Модульний моноліт 75 510 70 40
Мікросервіси 65 1200 62 15
Serverless Нестабільно 300-900 40 95
Таблиця 2.4
Експериментальні результати метрик
Метрика Моноліт Модульний Мікросервіси Serverless
моноліт
(50 корист.), ms 110 78 165 185
Пропускна здатність 50 70 62 40
(RPS)
Деградація при 200 85 40 15 95
корист. %
Ефективність (Е) 0.41 0.91 0.74 0.28
Інтерпретація
- моноліт - проста реалізація, але сильна деградація при навантаженні;
- мікросервіси - дуже стабільні, але дорогі та надмірні для малого бізнесу;
- serverless - нестабільний при довгих сесіях і залежний від cold-start;
- модульний моноліт - найкраще співвідношення витрат, швидкості,
стабільності та RPS.
33
ЧДТУ 252493.017 ПЗ
Експеримент довів, що модульний моноліт оптимально відповідає вимогам
системи суші-бару і забезпечує, найменший час відповіді, високу ефективність,
низькі витрати на інфраструктуру, стійкість під навантаженням та оптимальне
масштабування.
2.4 Обґрунтування вибору оптимальної архітектури
Експериментальні дані показали, що модульний моноліт демонструє
найкращий баланс між продуктивністю, стабільністю та використанням ресурсів.
Зокрема, у сценарії пікового навантаження (200 користувачів) модульний моноліт
забезпечив:
- найнижчий середній час відповіді серед монолітних підходів (130 ms);
- високу частку успішних запитів (88%);
- відносно низьку деградацію продуктивності (40%);
- стабільні показники дисперсії часу відповіді (σ² = 820);
- передбачуване навантаження на CPU (≈ 75%).
Мікросервісна архітектура продемонструвала найвищі показники стійкості (S
= 96%) та найменшу деградацію продуктивності (D = 25%). Однак експеримент
підтвердив, що її складність, внутрішня фрагментованість та вимоги до значно
більшої кількості комунікацій між сервісами істотно підвищують технічні та
організаційні витрати. Це робить мікросервіси недоцільними для невеликого
бізнесу.
Serverless-підхід показав високу варіативність затримок та нестабільність у
режимах довготривалого навантаження. Значення дисперсії часу відповіді σ² = 4200
та деградація D = 150% свідчать про непридатність цього підходу для систем із
постійними запитами та динамічним оновленням меню.
Моноліт виявив прийнятні результати лише у режимі низького навантаження.
Його деградація при піковому навантаженні (D = 182%) робить його ненадійним для
реальних комерційних сценаріїв.
Архітектурне обґрунтування
На основі аналізу метрик M1–M5 встановлено, що модульний моноліт
забезпечує:
34
ЧДТУ 252493.017 ПЗ
- стабільність часових характеристик (низька дисперсія часу відповіді);
- передбачуваність поведінки системи при зростанні навантаження;
- оптимальне співвідношення між RPS та CPU-навантаженням;
- помірну чутливість до збільшення навантаження (+7% при зростанні на
10%).
Ключовою перевагою модульного моноліту є структурна гнучкість. Модулі
системи (меню, замовлення, авторизація, управління клієнтами) мають чітко
визначені межі відповідальності, що суттєво знижує зв'язність компонентів та
спрощує подальший розвиток системи. При цьому архітектура зберігає сильні
сторони класичного моноліту:
- простота розгортання;
- невисока вартість підтримки;
- відсутність потреби у складних DevOps-процесах.
Обґрунтування SPA + REST API
Експеримент показав, що SPA-клієнт у поєднанні з REST API зменшує
кількість повних перезавантажень сторінки, мінімізує дублювання запитів та знижує
навантаження на серверну частину. Це дозволило досягти покращених значень
середнього часу відповіді у порівнянні з багатосторінковими підходами.
REST API продемонстрував високу стабільність обробки запитів (S > 97% у
досліджених сценаріях), що підтверджує його ефективність як комунікаційного
шару.
З огляду на результати експериментального моделювання, оптимальна
архітектура для веб-системи суші-бару включає:
- модульний моноліт як основу серверної частини;
- SPA як клієнтську архітектуру для швидкої та інтуїтивної взаємодії;
- REST API як ефективний протокол зв’язку між компонентами.
Це поєднання забезпечує:
- високу продуктивність та низький час відповіді;
- стабільність у пікових навантаженнях;
- низьку чутливість до навантаження;
35
ЧДТУ 252493.017 ПЗ
- простоту підготовки і підтримки;
- можливість масштабування системи разом із розвитком бізнесу.
Таким чином, вибрана архітектура виявилася найбільш збалансованою та
релевантною для реальних умов функціонування веб-системи онлайн-замовлень у
сфері ресторанного бізнесу.
36
ЧДТУ 252493.017 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі було проведено комплексне дослідження сучасних
архітектурних рішень, які можуть бути застосовані при розробці веб-системи для
малого бізнесу на прикладі онлайн-платформи суші-бару. Дослідження охопило як
теоретичний аналіз архітектурних стилів, так і розгорнуте експериментальне
моделювання їхньої роботи під різними режимами навантаження.
Виконано детальний огляд ключових архітектурних підходів - монолітної,
модульного моноліту, мікросервісної, serverless-архітектур, а також клієнтських
моделей SPA, MPA та комунікаційного стилю REST. Було визначено їхні переваги,
недоліки та особливості застосування у сучасних веб-системах. Окрему увагу
приділено актуальності цих підходів у 2025 році та їх відповідності вимогам бізнес-
логіки систем онлайн-замовлень.
Проведено порівняльний аналіз архітектур за низкою критеріїв:
масштабованість, продуктивність, структурна гнучкість, складність підтримки,
вимоги до інфраструктури, стійкість до збоїв та доступність для впровадження у
малому бізнесі. У результаті було встановлено, що хоча мікросервіси демонструють
найвищу масштабованість, вони є надмірно складними та дорогими в підтримці для
невеликих систем. Моноліт виявився недостатньо стійким при збільшенні
навантаження, а serverless - занадто нестабільним у контексті постійної взаємодії з
API.
Найвагоміші результати були отримані при експериментальному дослідженні.
В рамках моделювання було проаналізовано поведінку архітектур у трьох сценаріях
навантаження, використано п’ять ключових метрик (M1–M5), обчислено
характеристики роботи системи за допомогою формальних математичних моделей
та проведено чутливісний, відмовостійкісний і статистичний аналіз (дисперсія,
інтервал довіри, показники деградації, ефективність E тощо). Результати
експериментів підтвердили, що:
37
ЧДТУ 252493.017 ПЗ
- модульний моноліт має найкраще співвідношення між ключовими
метриками;
- мікросервіси показали найбільшу стійкість, але потребують суттєвих
ресурсів;
- моноліт не впорався з високим навантаженням;
- serverless виявився нестабільним у тривалих робочих циклах.
Сукупність отриманих даних дозволила сформувати науково обґрунтований
вибір, де було встановлено, що оптимальною архітектурою для веб-системи суші-
бару є поєднання:
- модульного моноліту на серверній частині;
- SPA (Single Page Application) як клієнтського інтерфейсу;
- REST API як механізму обміну даними.
Таке рішення забезпечує високу швидкодію, стійкість у пікові періоди, низьку
чутливість до навантаження, впорядковану структуру програмного коду, мінімальні
витрати на впровадження та зручність подальшої еволюції системи. Таким чином,
другий розділ сформував наукове підґрунтя для вибору архітектури майбутньої
інформаційної системи та дозволив перейти до практичного етапу її проектування і
реалізації, що розглядатиметься у наступних розділах роботи.
38
ЧДТУ 252493.017 ПЗ
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
3.1 Моделювання предметної області
Моделювання предметної області є одним із ключових етапів розробки
програмного забезпечення, оскільки дозволяє сформувати цілісне бачення
проблемної сфери, яку має обслуговувати майбутня система. На цьому етапі
відбувається визначення основних понять, процесів, ролей та взаємозв’язків, що
формують логіку роботи веб-системи суші-бару. Створення моделі предметної
області забезпечує підґрунтя для подальшого проектування структури програмного
комплексу, формування вимог та побудови UML-діаграм.
3.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання
Предметною областю даного проекту є процес обробки онлайн-замовлень у
закладі харчування формату суші-бару. Основне завдання цієї системи - забезпечити
можливість користувачу швидко та зручно переглядати меню, формувати
замовлення, обирати спосіб доставки чи самовивозу, а також підтверджувати
покупку через веб-інтерфейс. У межах цієї предметної області виділяються такі
основні аспекти: структурування меню (розділи, категорії, позиції, інгредієнти),
формування кошика та розрахунок загальної вартості замовлення, оформлення
замовлення, включаючи контактні дані, адресу доставки та зручний спосіб оплати,
авторизація та реєстрація користувачів, управління контентом адміністратором
(додавання позицій, редагування меню, встановлення акційних цін, перегляд
активних замовлень). Предметна область сформувалась на основі аналізу ринку
онлайн-доставки та вивчення функціоналу популярних систем цього типу.
Результати такого аналізу дозволили визначити мінімальний набір функцій,
необхідних для роботи суші-бару, а також сформувати перелік основних сутностей,
які повинні бути відображені в моделі.
39
ЧДТУ 252493.017 ПЗ
Модель предметної області
Модель предметної області дає змогу описати логічну структуру бізнес-
процесів суші-бару у вигляді сукупності сутностей, що мають атрибути, ролі,
взаємодії та зв’язки. Вона будується із застосуванням об’єктно-орієнтованого
підходу та служить концептуальною основою для подальшої побудови UML-
діаграм.
До ключових сутностей моделі входять:
- меню - категорії та позиції страв;
- позиція меню - окрема страва, що має ціну, вагу, опис та склад;
- кошик - список позицій, обраних користувачем;
- замовлення - оформлений запит користувача на приготування страв;
- користувач - гість або зареєстрований клієнт;
- адміністратор - працівник, який керує меню та замовленнями;
- доставка - адреса, спосіб отримання, статус доставки;
- статус замовлення - нове, готується, передано кур’єру, виконано.
Модель відображає логічні взаємозв’язки між сутностями: наприклад,
замовлення містить декілька позицій меню, користувач може мати історію
замовлень, а кожна позиція меню містить перелік інгредієнтів.
Словник предметної області
Для покращення розуміння структури даних, було сформовано словник
предметної області, що показує ключові атрибути які входять до об’єкта вхідного
замовлення. Цей словник (рис. 3.1) описує складові елементи структури замовлення,
визначає типи даних, обмеження, а також логічні операції, що необхідні для
коректного формування замовлення перед передачею його на серверну частину.
У словнику наведено детальну характеристику інформаційної моделі замовлення:
обов’язкові поля (наприклад, контактні дані клієнта, вибрані позиції меню, сума
замовлення). Словник виконує роль структурної схеми, що дозволяє уніфікувати
формат передавання даних між клієнтом і сервером та забезпечує цілісність
інформації під час обробки замовлення.
40
ЧДТУ 252493.017 ПЗ
Рисунок 3.1 – Словник предметної області для вхідних даних про замовлення
у веб-системі суші-бару
3.1.2 Елементи моделювання предметної області
Для опису предметної області найчастіше застосовують UML (Unified
Modeling Language), оскільки цей стандарт дозволяє уніфіковано відображати
структуру, динаміку та взаємодію компонентів майбутньої інформаційної системи.
UML-діаграми забезпечують візуальне представлення ключових об’єктів, процесів
та ролей, що формують логіку роботи веб-системи суші-бару. Кожен тип діаграм
має власні графічні елементи, правила позначення та семантику, що робить їх
зручними для аналізу, проєктування та документування ПЗ. На рисунку (рис. 3.2)
подано загальні приклади базових елементів UML, які використовуються під час
моделювання предметної області.
Рисунок 3.2 – Структурні об’єкти UML діаграм для суші-бару
41
ЧДТУ 252493.017 ПЗ
Структурні елементи UML відображають реальні або концептуальні сутності,
які мають сталі характеристики та відіграють певну роль у доменній моделі. У
контексті веб-системи суші-бару до таких об’єктів належать:
- актори (actor) - це зовнішні учасники, що взаємодіють із системою. У
нашій предметній області акторами виступають: клієнт (переглядає меню,
формує кошик, оформлює замовлення) та адміністратор закладу (управляє
позиціями меню, акціями та контролює поточні замовлення);
- варіанти використання (use case) - це сценарії взаємодії актора з системою.
Для клієнта - перегляд меню, додавання страв у кошик, оформлення
замовлення, вибір способу доставки та оплати. Для адміністратора -
редагування меню, зміна статусів замовлень, перегляд активних замовлень;
- класи (class) - визначають структуру сутності та її поведінку. Кожен клас
має атрибути (наприклад, назва страви, ціна, кількість) та може бути
пов’язаний із іншими класами;
- модулі (package / module) - об’єднує функціональні частини системи, які
логічно належать до однієї підзадачі.
Кожен з цих елементів є частиною загальної структури предметної області й
надалі буде використаний під час побудови UML-діаграм. Саме структурні об’єкти
становлять основу для формування зв’язків між сутностями, відображення бізнес-
процесів і проектування логічної архітектури системи.
Поведінкові об’єкти використовуються для опису динамічних аспектів
системи, тобто того, як вона реагує на дії користувача, яким чином обробляє події, у
якому порядку виконує операції та як змінює свої стани в процесі роботи. Це
дозволяє зрозуміти логічну послідовність дій та внутрішній механізм
функціонування веб-платформи. У контексті веб-системи суші-бару поведінковими
об’єктами можуть бути:
- послідовність дій клієнта при взаємодії з меню, наприклад: перегляд
категорій → відкриття сторінки страви → додавання до кошика;
- стани кошика, включаючи оновлення кількості позицій та розрахунок суми
замовлення;
42
ЧДТУ 252493.017 ПЗ
- обробка замовлення, що включає валідацію введених даних, перевірку
наявності страв і формування остаточного запиту;
- статуси замовлення, які змінюються у процесі роботи системи (нове →
готується → передано кур’єру → виконано);
- процес авторизації користувача, що включає введення облікових даних,
перевірку коректності та перехід у стан авторизованої сесії;
- процеси адміністратора, а саме редагування меню або зміна статусу
замовлення.
Кожен початковий стан може мати власну гілку сценарію, яка описує
подальші переходи між станами - від першої взаємодії до завершення конкретного
процесу. Приклад поведінкових об’єктів (стани та переходи між ними) для
предметної області веб-системи суші-бару буде наведено на рисунку 3.3.
Рисунок 3.3 – Приклад поведінкових об’єктів для UML діаграм
Окрім структурних та поведінкових елементів, важливо також визначити типи
зв’язків між об’єктами предметної області, оскільки саме вони формують логіку
взаємодії сутностей у системі. UML надає стандартизований набір позначень для
відображення таких зв’язків. На рисунку 3.4 представлено основні типи відношень,
які застосовуються під час моделювання системи.
43
ЧДТУ 252493.017 ПЗ
Рисунок 3.4 – Можливі відношення між об’єктами в UML діаграмах
3.1.3 Робоча область моделювання
На етапі моделювання визначаються ключові об’єкти, їх властивості,
взаємозв’язки та логіка роботи. Усі ці елементи формують основу, на якій надалі
проектується структура даних, бізнес-логіка та взаємодія між компонентами
системи.
Після аналізу предметної області веб-системи суші-бару було створено
концептуальну модель, така модель дозволяє сформувати цілісне уявлення про
структуру системи та її призначення. На рисунку 3.5 подано узагальнену модель
предметної області, що слугуватиме основою для подальшого проектування логічної
та архітектурної структури веб-системи.
44
ЧДТУ 252493.017 ПЗ
Рисунок 3.5 – Модель предметної області веб-системи суші-бару
Опис моделі предметної області
На поданій моделі предметної області відображено базову структуру взаємодії
між користувачем та ключовими функціональними модулями веб-системи суші-
бару. Центральним елементом цієї моделі є модуль «Обробка запитів», який
відповідає за приймання, маршрутизацію та виконання операцій, що ініціюються
користувачем через інтерфейс системи.
Користувач взаємодіє з системою опосередковано через інтерфейс, який
забезпечує відображення меню, кошика, форми оформлення замовлення та інших
UI-елементів. Інтерфейс надсилає запити до модуля обробки, де вони
розподіляються між відповідними підсистемами.
Модуль «Обробка запитів» об’єднує декілька функціональних компонентів,
кожен з яких виконує одну з критично важливих операцій системи:
- формування каталогу - відповідає за завантаження та структурування
списку страв, категорій меню та додаткової інформації, необхідної для
відображення клієнту;
- збереження даних про користувача - забезпечує збереження контактної
інформації, історії замовлень чи даних авторизації (у разі використання
облікових записів);
- обробка даних про користувача - включає перевірку введених
користувачем даних, валідацію форми оформлення замовлення, а також
отримання інформації про вже існуючі замовлення чи профіль;
- створення замовлення - формує нове замовлення на основі переданих
даних, виконує перевірку наявності позицій меню та передає замовлення у
чергу на приготування.
Зв’язки між підсистемами у моделі демонструють логіку взаємодії: модуль
обробки отримує запити від інтерфейсу, викликає відповідні внутрішні процеси й
повертає результат у вигляді сформованих даних, повідомлень або зміненого стану
системи.
45
ЧДТУ 252493.017 ПЗ
Таким чином, модель предметної області відображає структуру та
взаємозалежність основних компонентів веб-системи суші-бару, демонструючи
шлях, яким проходить запит користувача - від взаємодії з інтерфейсом до виконання
конкретної бізнес-операції всередині системи.
3.2 Формування та аналіз вимог
Вимоги визначають функціональність, поведінку, характеристики якості та
технічні обмеження системи, що планується до розробки. На основі дослідження
предметної області, результатів порівняння архітектур та експериментальних даних
було сформовано повний набір вимог, який є основою для проектування
програмного комплексу.
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги
Формування вимог до програмного забезпечення
Вимоги до веб-системи суші-бару формуються з урахуванням потреб кінцевих
користувачів, бізнес-процесів закладу харчування та технічних можливостей
програмно-апаратної платформи. У процесі аналізу предметної області були
визначені основні програмні модулі, сценарії використання та обмеження, що
впливають на роботу системи. Отримані вимоги були структуровані та поділені на
первинні, детальні, вимоги замовника і вимоги розробника.
Первинні і детальні вимоги
Первинні вимоги:
- система повинна надавати каталог страв із фотографіями, описом та ціною;
- користувач повинен мати можливість додавати страви до кошика;
- має бути реалізована можливість оформлення замовлення;
- повинна існувати форма введення контактних даних і вибору способу
доставки;
- система повинна швидко реагувати на дії користувача та не створювати
надмірних затримок;
46
ЧДТУ 252493.017 ПЗ
- користувач повинен мати можливість переглядати детальну інформацію
про страви.
Детальні вимоги:
- каталог повинен містити категорії меню, підкатегорії та окремі позиції
страв;
- система має відображати інформацію про вагу страви, склад, алергени та
інші важливі атрибути;
- кошик повинен підтримувати зміну кількості страв та автоматичний
перерахунок вартості;
- процес оформлення замовлення має включати валідацію введених даних та
відображення статусу обробки;
- система повинна зберігати інформацію про попередні замовлення (за
умови авторизації користувача);
- час відповіді сервера не повинен перевищувати 10–20 ms для типових
REST-запитів;
- інтерфейс має завантажуватися не довше ніж за 200–300 ms при
стабільному інтернет-з’єднанні.
ВИМОГИ ЗАМОВНИКА
Система повинна надавати зручний доступ до меню, дозволяючи переглядати
усі категорії та конкретні позиції страв разом із їхнім описом та фотографіями.
Окрім цього, користувач повинен мати можливість легко взаємодіяти з кошиком -
додавати обрані страви, змінювати їхню кількість або видаляти, а також переходити
до оформлення замовлення. Процес оформлення має бути інтуїтивним та включати
всі необхідні етапи: введення контактних даних, вибір способу доставки або
самовивозу, а також можливість вказати додаткові побажання. Система повинна
працювати стабільно під час пікового навантаження, коли на сайті одночасно може
перебувати кілька сотень користувачів. Інтерфейс має бути зрозумілим і
адаптивним, щоб веб-сайт однаково добре працював на смартфонах, планшетах та
комп’ютерах. За потреби користувачам повинна бути доступна функція реєстрації,
що дозволить переглядати історію попередніх замовлень та пришвидшить повторні
покупки.
47
ЧДТУ 252493.017 ПЗ
ВИМОГИ РОЗРОБНИКА
Важливо забезпечити сучасний, швидкий та гнучкий інтерфейс, тому
клієнтська частина повинна бути реалізована у форматі SPA із використанням React.
Для навігації між сторінками необхідно застосувати React Router, а стан застосунку
має бути організований так, щоб забезпечити легку підтримку та можливість
розширення функціоналу. Серверна частина повинна бути побудована на основі
Spring Boot з використанням модульного моноліту, що дозволить розділити
внутрішню логіку на незалежні компоненти. Дані мають зберігатися в PostgreSQL,
де необхідно передбачити структуру таблиць, здатну до подальшого розширення та
оптимізації під великі обсяги замовлень. Розробник також повинен створити чітко
структурований REST API, який забезпечить стабільний зв’язок між фронтендом і
сервером, а також коректну обробку великої кількості паралельних запитів.
Особлива увага має бути приділена продуктивності: сервер повинен швидко
обробляти запити, а інтерфейс - миттєво реагувати на дії користувача. Крім того,
система повинна бути гнучкою для інтеграції нового функціоналу, наприклад
акційних пропозицій, бонусних програм або розширеного кабінету адміністратора.
Оптимізація роботи з базою даних та правильне кешування також є важливими
аспектами, які повинні бути враховані під час розробки.
Функціональні та нефункціональні вимоги
Функціональні вимоги:
- система каталогу страв для відображення переліку доступних страв;
- система додавання страви в кошик, змінювання кількісті, видалення
позиції;
- система оформлення замовлення страв з кошика;
- модуль адміністратора з можливістю додавання/редагування страв,
оновлення цін і описів;
- авторизація та реєстрація користувачів (опціонально);
- реалізація механізму REST API: створення структурованих кінцевих точок
для взаємодії між клієнтською та серверною частиною. Підтримка методів
GET, POST, PUT, DELETE для роботи з меню та замовленнями.
48
ЧДТУ 252493.017 ПЗ
Нефункціональні вимоги:
- час відповіді сервера для стандартних запитів не повинен перевищувати
100 мс. Головна сторінка має завантажуватися не довше 300 мс на
типовому клієнтському пристрої;
- серверна частина повинна коректно обробляти помилки та забезпечувати
збереження замовлень. База даних має підтримувати ACID-властивості;
- архітектура повинна дозволяти розширення функціоналу без повної
перебудови системи.
3.2.2 Формування вимог за допомогою діаграми прецедентів
Для уточнення вимог та визначення взаємодії користувачів із системою було
побудовано діаграму прецедентів (рис. 3.6), яка відображає основні сценарії
використання веб-платформи суші-бару.
Рисунок 3.6 – Діаграма прецедентів веб-системи суші-бару
49
ЧДТУ 252493.017 ПЗ
На рисунку 3.6 подано діаграму прецедентів веб-платформи суші-бару. У
межах системної межі зображено прецеденти, що реалізують функціональність як
для клієнта, так і для адміністратора. Зв’язки типу extend ілюструють додаткові або
умовні сценарії, що розширюють основні прецеденти, тоді як зв’язок include
демонструє обов’язкову частину складнішого процесу (додавання товару до кошика
є частиною оформлення замовлення). На діаграмі також визначено два ключові
актори - Клієнт та Адміністратор, кожен з яких взаємодіє із системою відповідно до
своєї ролі та наданих прав доступу.
Клієнт - це будь-який користувач, який взаємодіє з веб-платформою для
перегляду меню та оформлення замовлення. Згідно з вимогами, клієнт має доступ до
основних функцій платформи, що забезпечують можливість замовлення страв
онлайн. На діаграмі прецедентів для клієнта передбачено такі сценарії взаємодії:
- перегляд каталогу - клієнт може ознайомитись з меню суші-бару,
переглядати категорії та окремі страви. Прецедент розширюється
можливістю пошуку товару, що дозволяє швидко знайти потрібну
позицію;
- додавання товару до кошика - цей процес є частиною загального сценарію
оформлення замовлення, оскільки без цього кроку неможливо сформувати
фінальний список страв;
- оформлення замовлення - включає введення контактних даних, вибір
способу доставки та підтвердження замовлення;
- керування акаунтом - клієнт може створити особистий кабінет та здійснити
вхід у профіль, що представлено прецедентами «Зареєструватися» та
«Авторизуватися», які розширюють основну взаємодію з акаунтом.
Адміністратор - це користувач із правами керування вмістом платформи та
обробки замовлень. Його роль передбачає роботу з бізнес-процесами, які
забезпечують функціонування суші-бару. На діаграмі показані такі варіанти
використання адміністратора:
50
ЧДТУ 252493.017 ПЗ
- керування каталогом - включає два розширені прецеденти: «Керування
категоріями» (додавання, редагування, видалення категорій меню) та
«Керування товарами» (оновлення інформації про страви, зміна ціни, фото,
опису);
- обробити замовлення - адміністратор виконує підтвердження, відстежує
статуси замовлень та, за потреби, вносить коригування;
- керування статусом замовлення - розширює процес обробки та дозволяє
встановлювати один із етапів життєвого циклу замовлення (нове,
готується, передано кур’єру, виконано).
3.2.3 Проектування логічної структури програмного комплексу
Проектування логічної структури веб-системи суші-бару є важливим етапом
розробки, оскільки саме на цьому рівні формується уявлення про внутрішню
організацію програмного забезпечення та взаємодію між його основними
компонентами. Логічна структура визначає, які класи формують основу системи, які
атрибути і методи вони містять та як саме між ними встановлені зв’язки.
Результати проектування відображені у вигляді діаграми класів та діаграми
пакетів, що слугують базою для подальшого створення архітектури серверної
частини, моделювання бази даних і розробки бізнес-логіки.
3.2.3.1 Діаграми класів
Для побудови діаграми класів було проведено аналіз функціональних вимог до
веб-системи суші-бару та визначено ключові сутності предметної області. На основі
цих вимог була сформована початкова діаграма класів, що відображає основні
об’єкти системи та типи зв’язків між ними (рис. 3.7).
Побудована діаграма класів відображає основні структурні елементи веб-
системи суші-бару та демонструє, як формуються замовлення, як користувач
взаємодіє з даними та який шлях проходить інформація в системі. Ця діаграма
слугує основою для подальшого уточнення атрибутів класів, оптимізації структури
бази даних і побудови REST API.
51
ЧДТУ 252493.017 ПЗ
Рисунок 3.7 – Початкова діаграма класів для веб-системи суші-бару
Початкова діаграма класів включає такі сутності:
- User - клас об’єктів-користувачів, який взаємодіє з замовленнями;
- Order - клас об’єктів-замовлень які формують клієнти;
- DeliveryMethod – нумератор, надає перелік можливих станів доставки;
- OrderStatus - нумератор, надає перелік можливих станів замовлення;
- Product - клас об’єктів товару, представляє основні характеристики товару;
- Клас Category - клас, представляє категорії товарів.
Після аналізу специфікації даних, уточнення взаємозв’язків між сутностями та
перевірки структури на відповідність вимогам було сформовано повну діаграму
класів веб-системи суші-бару (рис. 3.8). На ній відображено актуальний перелік
сутностей, необхідних для роботи системи онлайн-замовлення, включно з
користувачами, продуктами меню, категоріями страв, замовленнями та службовими
перерахуваннями.
52
ЧДТУ 252493.017 ПЗ
Рисунок 3.8 – Діаграма класів з атрибутами для веб-системи суші-бару
Усі класи містять атрибути, що відповідають реальним даним, які
обробляються у процесі створення та виконання замовлень, а також методи, що
реалізують ключову бізнес-логіку системи.
Опис діаграми класів
1 Клас Category
Атрибути:
- category_id: Long – унікальний ідентифікатор категорії;
- name: String – назва категорії.
2 Клас Product
Атрибути:
- product_id: Long – унікальний ідентифікатор страви;
- name: String – назва страви;
53
ЧДТУ 252493.017 ПЗ
- description: String – короткий опис складу та особливостей страви;
- portion: String – інформація про порцію;
- price: Decimal – вартість страви;
- category_id: Long – ідентифікатор категорії меню.
Методи:
- getProductList() – повертає список страв відповідно до категорії;
- getProductInfo() – повертає детальну інформацію про конкретну страву.
3 Клас User
Атрибути:
- user_id: Long – унікальний ідентифікатор користувача;
- firstname: String – ім’я користувача;
- lastname: String – прізвище користувача;
- login: String – логін для авторизації;
- password: String – пароль користувача;
- email: String – електронна пошта;
- phone_number: String – номер телефону.
Методи:
- authUser() – авторизація користувача;
- regUser() – створення облікового запису;
- getUserInfo() – отримання даних профілю.
4 Клас Order
Атрибути:
- order_id: Long – унікальний ідентифікатор замовлення;
- order_date: Date – дата оформлення;
- order_status: OrderStatus – поточний стан замовлення;
- products: String – JSON-перелік замовлених страв та їх кількості;
- total_price: Decimal – загальна сума замовлення;
- customer_name: String – ім’я клієнта, який зробив замовлення;
- customer_phone: String – номер телефону клієнта;
- delivery_date: Date – час або дата доставки;
54
ЧДТУ 252493.017 ПЗ
- delivery_method: DeliveryMethod – обраний спосіб доставки;
- delivery_address: String – адреса доставки (для кур’єрського варіанту);
- num_persons: Int – кількість персон;
- courier_comment: String – коментар для кур’єра;
- rest_comment: String – коментар для кухні;
- user_id: Long – ідентифікатор користувача, який оформив замовлення.
Методи:
- createOrder() – створює нове замовлення;
- getOrderDetails() – повертає дані про замовлення;
- calcTotal() – перераховує підсумкову вартість;
- changeStatus() – змінює статус замовлення.
5 Нумератор DeliveryMethod
Атрибути:
- name: String – назва методу доставки.
6 Нумератор OrderStatus
Атрибути:
- name: String – назва статусу замовлення.
Створена діаграма класів демонструє логічно цілісну структуру веб-системи
суші-бару, у якій кожен клас виконує чітко визначену роль у загальному бізнес-
процесі. Усі сутності поєднані між собою відповідно до реальних взаємодій у
предметній області: користувач формує замовлення, замовлення містить перелік
страв, кожна страва належить до певної категорії, а статус і спосіб доставки
забезпечують правильний процес обробки. Така структура дає змогу системі
працювати узгоджено, виключає дублювання даних та забезпечує правильне
співвідношення між логікою та збереженням інформації. Крім того, модель легко
розширюється - додавання нових категорій, страв чи бізнес-процесів не
потребуватиме зміни вже існуючих зв’язків, що гарантує гнучкість і
масштабованість рішення.
3.2.3.2 Діаграми пакетів
55
ЧДТУ 252493.017 ПЗ
Проаналізувавши внутрішню організацію програмного комплексу та
взаємозв’язки між його складовими частинами, була побудована діаграма пакетів,
яка відображає логічне групування компонентів системи у відповідні модулі (рис.
3.9). Діаграма дозволяє побачити структуру застосунку на високому рівні та
зрозуміти, які залежності виникають між окремими частинами веб-платформи суші-
бару.
Рисунок 3.9 – Діаграма пакетів веб-системи суші-бару
Діаграма пакетів ілюструє, як веб-сайт залежить від сервера для отримання
контенту, а сервер - від бази даних для доступу до інформації. Така структура
дозволяє чітко розмежувати відповідальність між рівнями системи та спрощує її
подальший розвиток.
Опис діаграми пакетів
На поданій діаграмі пакетів зображено логічну організацію структурних
компонентів веб-платформи суші-бару. Діаграма демонструє, як система поділена на
окремі пакети, кожен з яких відповідає за певну частину функціональності, а також
відображає залежності між цими пакетами. Пакет «Веб-сайт» містить клієнтську
частину застосунку, що включає модулі каталогу, кошика та інтерфейсу
користувача. Саме ці компоненти забезпечують перегляд меню, взаємодію з
56
ЧДТУ 252493.017 ПЗ
товарами, додавання страв до кошика та оформлення замовлення. Пакет «Сервер»
відповідає за основну бізнес-логіку системи, включаючи обробку замовлень і
управління товарами. Саме сервер отримує дані з бази, проводить обчислення та
повертає результати веб-сайту. Пакет «База даних» зберігає всю інформацію про
страви, категорії, користувачів і замовлення. Сервер напряму взаємодіє з базою
даних, отримуючи та оновлюючи необхідні дані.
3.2.4 Архітектурне проектування
Архітектура веб-системи суші-бару побудована з використанням принципів
модульного розподілення функціональності, що дозволяє чітко розмежувати логіку
інтерфейсу, бізнес-процесів і доступу до даних. Такий підхід забезпечує можливість
масштабування, зручність у подальшій підтримці та чітку структуру взаємодії між
частинами системи. У цьому розділі наведено результати архітектурного
проектування у вигляді діаграми компонентів та діаграми розгортання, які
демонструють ключові елементи веб-платформи та канали їхньої взаємодії.
3.2.4.1. Діаграма компонентів
Діаграма компонентів веб-системи суші-бару (рис. 3.10) була розроблена з
метою наочності організації основних частин програмного комплексу та визначення
зв’язків між ними. Вона дозволяє зрозуміти, які саме модулі формують систему, які
дані вони обробляють та яким чином відбувається обмін інформацією між
клієнтською та серверною частинами.
Опис діаграми компонентів
На діаграмі відображені ключові компоненти веб-платформи та їх зв’язки:
- веб-додаток (фронтенд) - це клієнтська частина системи, створена на
основі React. Вона відповідає за відображення інтерфейсу, взаємодію
користувача з меню, кошиком, формами замовлення та іншими
елементами UI. Фронтенд надсилає HTTP-запити до сервера через REST
API та отримує структуровані відповіді, які використовуються для
побудови інтерфейсу;
57
ЧДТУ 252493.017 ПЗ
- UI/UX - окремий компонент, що відповідає за зовнішній вигляд та
зручність взаємодії з системою. Містить графічні елементи, шаблони,
форми та навігацію. Компонент тісно пов’язаний із модулем каталогу та
фронтендом загалом;
- каталог товарів - компонент, який отримує дані про страви з сервера та
формує структуру відображення для користувача: списки, категорії, картки
страв, детальні описи. Фронтенд звертається до цього модуля для
відображення актуального меню;
- сервер (бекенд) - бекенд, реалізований за допомогою Spring Boot, обробляє
запити від фронтенда, виконує бізнес-логіку та формує відповіді.
Основною задачею сервера є маршрутизація запитів, обчислення,
підготовка відповідей та передача їх назад у фронтенд;
- обробка замовлень - цей компонент відповідає за створення, збереження,
обробку й оновлення стану замовлень. У ньому реалізовані такі процеси:
формування структури замовлення, обчислення загальної вартості,
визначення статусу, підготовка даних для кухні та кур’єра;
- база даних - у базі зберігаються товари, категорії, замовлення, користувачі
та службові дані. Сервер з’єднується з базою через спеціалізовані
DAO/Repository-компоненти, виконує запити та формує результати, які
передаються клієнту.
Загальна схема взаємодії
1 користувач звертається до фронтенду;
2 фронтенд формує запити до сервера;
3 сервер виконує бізнес-логіку та звертається до бази даних;
4 результати повертаються на фронтенд, де відображаються у UI/UX;
5 користувач формує замовлення → сервер обробляє → оновлює БД →
повертає оновлений стан.
Така архітектура забезпечує розділення відповідальності та дозволяє окремо
розвивати кожну частину системи.
58
ЧДТУ 252493.017 ПЗ
Рисунок 3.10 – Діаграма компонентів веб-системи суші-бару
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Розгортання програмної системи на апаратних засобах
Розгортання веб-системи суші-бару передбачає підготовку серверного
середовища, налаштування сервісів та розміщення всіх необхідних компонентів
програмного комплексу. Для цього використовується окремий серверний вузол, на
якому розміщується бекенд-частина системи та база даних, а також веб-сервер, що
відповідає за доставку клієнту статичних файлів веб-додатка. Після встановлення та
налаштування серверного програмного забезпечення було розгорнуто серверну
частину застосунку, що реалізує бізнес-логіку обробки замовлень та взаємодію з
базою даних. Окремо була створена і налаштована база даних PostgreSQL
відповідно до структури, розробленої на попередніх етапах проектування.
Далі на веб-сервер були завантажені зібрані статичні файли фронтенд-
застосунку, після чого вони стали доступними для клієнтів у вигляді веб-інтерфейсу.
Після завершення розгортання всі компоненти системи були інтегровані між собою
відповідно до архітектури. Для перевірки коректності взаємодії між веб-додатком,
59
ЧДТУ 252493.017 ПЗ
сервером та базою даних проводиться комплексне тестування розгорнутої системи,
що буде розглянуто у наступному розділі.
Діаграма розгортання
Діаграма розгортання веб-системи суші-бару (рис. 3.11) відображає
розміщення компонентів програмного комплексу на фізичних або віртуальних
вузлах та демонструє, які мережеві протоколи використовуються для обміну
даними. Діаграма включає чотири основні вузли: Client, Web Server, Server та
Database.
Рисунок 3.11 – Діаграма розгортання веб-системи суші-бару
Опис діаграми розгортання
1 Client (Клієнт):
- підключається до веб-серверу через протокол HTTP/s, отримує інтерфейс
системи та надсилає запити до бекенду;
- забезпечує доступ користувача до функцій перегляду меню та оформлення
замовлення;
2 Web Server (Веб-сервер):
60
ЧДТУ 252493.017 ПЗ
- містить компонент User Interface, який відповідає за подачу статичних
файлів React-додатку клієнту;
- передає запити клієнта до серверного застосунку через HTTPS;
- виконує роль проміжної ланки між користувачем і бекенд-системою.
3 Server (Бекенд-сервер):
- містить компонент Application, що реалізує бізнес-логіку системи;
- отримує запити з веб-серверу, обробляє їх і формує відповіді;
- у разі необхідності звертається до бази даних через протокол JDBC для
отримання або оновлення інформації;
- забезпечує роботу модулів формування замовлення, обробки статусів,
управління товарами та іншої логіки.
4 Database (База даних):
- містить компонент Database, що реалізує схему PostgreSQL;
- зберігає інформацію про страви, категорії, замовлення, користувачів та
службові таблиці;
- взаємодіє з бекенд-сервером виключно через JDBC-підключення, що
гарантує захищений доступ до даних.
3.2.5 Моделювання поведінки системи
У цьому підрозділі наведено результати моделювання поведінки веб-системи
суші-бару за допомогою діаграм діяльності, діаграм послідовності, комунікації та
скінченного автомату. Таке моделювання дозволяє краще зрозуміти логіку роботи
системи, її реакцію на різні дії користувача та внутрішні бізнес-процеси. На основі
отриманих діаграм можна точніше сформувати вимоги до реалізації та забезпечити
коректну послідовність виконання всіх операцій у системі.
3.2.5.1 Діаграма діяльності
Діаграма діяльності веб-платформи суші-бару (рис. 3.12) демонструє основні
кроки взаємодії користувача із системою - від моменту переходу на веб-сайт до
61
ЧДТУ 252493.017 ПЗ
завершення взаємодії. Діаграма відображає логічний ланцюг можливих дій, точки
прийняття рішень та альтернативні сценарії поведінки.
Рисунок 3.12 – Діаграма діяльності веб-системи суші-бару
На діаграмі показано, як користувач потрапляє на веб-інтерфейс, має
можливість зареєструватися або увійти до облікового запису, або ж продовжити
користування як гість. Далі користувач може переглядати каталог товарів, керувати
вмістом кошика або перейти до процесу оформлення замовлення. Завершальним
етапом є вихід зі сторінки або продовження роботи з системою.
Опис кроків діаграми діяльності
1 Перехід на сторінку веб-сайту
62
ЧДТУ 252493.017 ПЗ
- користувач відкриває веб-сайт суші-бару;
- система завантажує початковий інтерфейс.
2 Перевірка наявності облікового запису
Якщо користувач не має облікового запису:
- система пропонує пройти реєстрацію для збереження персональних даних
та історії замовлень;
- користувач може перейти до форми створення облікового запису.
Якщо користувач має обліковий запис:
- він може здійснити вхід, використовуючи логін і пароль.
3 Вибір режиму роботи
- увійти в обліковий запис (за наявності акаунта);
- продовжити як гість, без прив’язки замовлень до профілю.
4 Основна взаємодія з веб-системою
- керувати товарами у кошику - додавати нові позиції, змінювати їх
кількість або видаляти;
- переглядати каталог - ознайомлюватися з меню, категоріями та детальним
описом страв;
- оформляти замовлення - перейти до заповнення контактної інформації,
вибору доставки та підтвердження замовлення.
5 Завершення взаємодії
- закрити сторінку;
- вийти з облікового запису (якщо був авторизований);
- припинити використання веб-системи.
У результаті діаграма діяльності відображає загальний сценарій поведінки
користувача та допомагає зрозуміти логіку переходів і рішень у типовому процесі
оформлення онлайн-замовлення в суші-барі.
3.2.5.2 Діаграма послідовності
Результати моделювання взаємодії між основними компонентами веб-системи
суші-бару подані у вигляді діаграми послідовності (рис. 3.13). Діаграма демонструє,
63
ЧДТУ 252493.017 ПЗ
як користувач, веб-сайт, сервер і база даних обмінюються повідомленнями в процесі
авторизації, перегляду каталогу, додавання товарів у кошик та оформлення
замовлення. Така модель дозволяє зрозуміти повну послідовність дій та визначити,
які саме операції виконує кожен компонент системи.
Рисунок 3.13 – Діаграма послідовності веб-системи суші-бару
Опис діаграми послідовності
1 Авторизація користувача
- користувач вводить свої дані у форму авторизації на веб-сайті;
- веб-сайт надсилає запит до сервера з отриманими даними;
- сервер звертається до бази даних для перевірки інформації про
користувача;
64
ЧДТУ 252493.017 ПЗ
- база даних повертає знайдені результати на сервер;
- сервер перевіряє дані та надає веб-сайту відповідь про успішну
авторизацію;
- веб-сайт повідомляє користувача про успішний вхід у систему.
2 Перегляд каталогу товарів
- користувач відкриває сторінку каталогу на веб-сайті;
- веб-сайт формує запит до сервера для отримання списку доступних страв;
- сервер надсилає SQL-запит до бази даних;
- база даних виконує пошук та повертає знайдені товари;
- сервер передає список страв назад на веб-сайт;
- веб-сайт відображає каталог користувачу.
3 Додавання товару у кошик
- користувач натискає кнопку «Додати у кошик» на картці товару;
- веб-сайт зберігає вибраний товар у localStorage, щоб забезпечити локальне
збереження кошика;
- інформація про доданий товар залишається доступною навіть без
авторизації користувача.
4 Оформлення замовлення
- користувач переходить до сторінки оформлення замовлення та заповнює
необхідні дані;
- веб-сайт передає інформацію про замовлення на сервер;
- сервер зберігає замовлення в базі даних;
- база даних підтверджує успішне збереження запису;
- сервер надсилає повідомлення веб-сайту про успішне оформлення
замовлення;
- веб-сайт повертає користувачу сторінку з деталями створеного замовлення.
Діаграма послідовності дозволяє чітко простежити рух даних у системі та
встановити взаємозалежності між компонентами. Це допомагає забезпечити
правильну реалізацію бізнес-логіки та ефективну взаємодію користувача з веб-
системою.
65
ЧДТУ 252493.017 ПЗ
3.2.5.3 Діаграма комунікації
Діаграма комунікації (рис. 3.14) демонструє структурну взаємодію між
ключовими об’єктами веб-системи суші-бару під час виконання основних операцій
користувача. Вона відображає обмін повідомленнями між користувачем, веб-
сайтом, сервером та базою даних, дозволяючи зрозуміти логіку формування запитів,
способи доступу до даних та послідовність взаємодії між компонентами системи.
Рисунок 3.14 – Діаграма комунікації веб-системи суші-бару
Опис діаграми комунікації
1 Перехід на сайт
- користувач відкриває веб-сайт суші-бару;
- веб-сайт приймає запит, завантажує інтерфейс та забезпечує доступ до
початкових функцій системи.
2 Валідація користувача
- після взаємодії з UI (наприклад, авторизації) веб-сайт надсилає на сервер
дані для перевірки;
- сервер проводить початкову валідацію запиту та визначає, чи потрібні
додаткові дані з бази.
66
ЧДТУ 252493.017 ПЗ
3 Запит даних із бази
- сервер формує запит до бази даних для отримання потрібної інформації
(пошук користувача, товарів, деталей).
4 Повернення даних
- база даних обробляє запит і повертає результати серверу для подальшої
обробки.
5 Передача доступу та інформації
- отримавши дані, сервер передає веб-сайту інформацію щодо прав доступу,
результатів авторизації, знайдених товарів або інших даних, що були
запитані.
6 Виведення інформації
- веб-сайт обробляє відповідь сервера та відображає необхідні дані у UI
(каталог, профіль, доступні функції).
7 Додавання товарів у кошик
- користувач обирає страви та додає їх у кошик;
- веб-сайт фіксує цю дію та оновлює інтерфейс відповідно.
8 Збереження кошика
- веб-сайт зберігає сформований кошик у localStorage браузера, щоб
забезпечити збереження вибраних позицій навіть без авторизації.
9 Оформлення замовлення
- користувач переходить до оформлення замовлення та вводить необхідні
дані (контакти, адреса, спосіб доставки).
10 Формування запиту на замовлення
- веб-сайт формує структурований запит із даними замовлення та надсилає
його на сервер.
11 Збереження замовлення
- сервер приймає дані, виконує перевірку та передає запит до бази даних для
збереження нового замовлення.
12 Повернення результату
- база даних підтверджує збереження і передає інформацію назад серверу;
67
ЧДТУ 252493.017 ПЗ
- сервер повідомляє веб-сайт про успішне оформлення замовлення, після
чого веб-сайт відображає відповідне повідомлення користувачу.
3.2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату веб-системи суші-бару (рис. 3.15) відображає
основні стани, у яких може перебувати система під час взаємодії з користувачем, а
також переходи між цими станами. Такий підхід дозволяє формалізувати поведінку
системи, визначити реакції на події та сформувати чітку логіку переходів між
етапами роботи веб-додатку.
Рисунок 3.15 – Діаграма скінченного автомату веб-системи суші-бару
Представлена діаграма моделює процеси, що відбуваються під час
початкового завантаження сторінки, отримання каталогу страв, авторизації
користувача та оновлення інтерфейсу. Вона демонструє, як система реагує на дії
відвідувача та які стани змінюються в залежності від результатів цих дій.
Опис діаграми скінченного автомату
1 Початковий перехід
68
ЧДТУ 252493.017 ПЗ
- користувач переходить на сторінку веб-сайту суші-бару;
- система ініціює процес завантаження ресурсу.
2 Завантаження головної сторінки
- після завершення завантаження користувач переходить у початковий стан
роботи зі сторінкою;
- інтерфейс готовий до подальшої взаємодії.
3 Отримання каталогу
- система надсилає запит до серверу з метою отримання списку доступних
страв;
- після отримання даних виконується оновлення інтерфейсу, на якому
відображається каталог продукції;
- користувач отримує доступ до перегляду меню.
4 Авторизація користувача
- користувач може здійснити спробу авторизації, введення облікових даних
або продовжити як гість;
- якщо авторизація успішна - система переходить до оновлення інтерфейсу з
урахуванням авторизованого стану;
- якщо авторизація не пройдена - система фіксує завершення цього процесу
та дозволяє взаємодію у неавторизованому режимі.
5 Оновлення інтерфейсу
- після обробки каталогу або авторизації система формує оновлений вигляд
користувацької сторінки;
- готуються елементи інтерфейсу для подальших дій користувача.
6 Очікування команд від користувача
- система переходить у стан очікування наступної дії;
- цей стан є циклічним і триває до завершення сеансу взаємодії.
69
ЧДТУ 252493.017 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було проведено комплексне моделювання та проектування
веб-системи суші-бару, що дозволило сформувати цілісне бачення внутрішньої
структури, взаємодії компонентів та динаміки роботи системи. На основі аналізу
предметної області було визначено ключові сутності, взаємозв’язки між ними, а
також побудовано словник даних, що слугує основою для подальшої розробки та
тестування.
У ході проектування логічної структури системи були створені діаграми
класів та пакунків (пакетів), які дозволили систематизувати основні об'єкти,
визначити їх атрибути, методи та співвідношення. Це забезпечило чітке
розмежування відповідальності між модулями та заклало основу для
масштабованості та підтримки коду.
На етапі архітектурного проектування було побудовано діаграму компонентів,
що відобразила ключові частини системи - веб-додаток, сервер та базу даних - і
визначила канали обміну даними між ними. Діаграма розгортання
продемонструвала розподіл програмних артефактів по апаратних вузлах та описала
спосіб взаємодії між клієнтом, веб-сервером, бекенд-сервісом і сервером бази даних.
Моделювання поведінки системи за допомогою діаграм діяльності,
послідовності, комунікації та скінченного автомату дало можливість деталізувати
роботу системи у різних сценаріях: завантаження сторінки, авторизації користувача,
отримання каталогу товарів, управління корзиною та оформлення замовлень.
Завдяки цьому було сформовано повне уявлення про алгоритми взаємодії між
користувачем, веб-інтерфейсом та серверною частиною.
Узагальнюючи результати третього розділу, можна зазначити, що виконане
моделювання та проектування забезпечило чітку формалізацію вимог, структури та
поведінки веб-системи суші-бару. Усі побудовані діаграми та описані процеси
створюють надійну основу для реалізації, тестування та подальшого вдосконалення
програмного комплексу відповідно до обраних архітектурних рішень та вимог
малого бізнесу.
70
ЧДТУ 252493.017 ПЗ
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
Розробка веб-системи для суші-бару включає комплекс заходів, спрямованих
на створення надійного, продуктивного та зручного програмного рішення, яке
забезпечує можливість перегляду меню, формування онлайн-замовлень, збереження
корзини та адміністрування позицій меню. Головною метою розробки є створення
сучасної веб-платформи, здатної ефективно обробляти користувацькі запити,
забезпечувати швидкий відгук, стабільну роботу та можливість подальшого
масштабування в межах малого бізнесу.
У цьому розділі описано основні підходи до реалізації програмного
комплексу, сформовано обґрунтування використаних технологій, наведено логічну
структуру компонентів та принципи їх взаємодії. Також розглянуто структуру
клієнтського додатка, особливості створення бази даних та загальні принципи
роботи бізнес-логіки системи. Розробка системи охоплює такі етапи:
- проектування логіки взаємодії між клієнтською та серверною частинами;
- створення REST API для обміну даними між фронтендом і бекендом;
- побудова клієнтського SPA-додатку з використанням React;
- розробка компонентів інтерфейсу, кошика, каталогу та форми оформлення
замовлення;
- підготовка структури бази даних та механізмів роботи із замовленнями;
- впровадження інструментів тестування та контролю версій.
Архітектура веб-системи ґрунтується на поєднанні модульного моноліту на
серверній частині та SPA-клієнта на фронтенді. Такий підхід дозволяє зберегти
високу продуктивність, логічну цілісність та передбачувану поведінку системи, що є
важливим для невеликих бізнес-проектів, таких як заклади доставки їжі.
У межах цього розділу подано загальний опис структурної схеми програмного
комплексу, який демонструє взаємодію між користувачем, веб-додатком, сервером
та базою даних. Детальний аналіз цієї схеми буде наведено у наступних підрозділах.
4.1.1 Обґрунтування вибору засобів реалізації
71
ЧДТУ 252493.017 ПЗ
Вибір технологій для розробки веб-системи суші-бару базується на
необхідності забезпечити високу швидкість роботи, стабільність, масштабованість
та зручність подальшої підтримки. Система повинна безперебійно обслуговувати
користувачів, обробляти замовлення, працювати з меню та забезпечувати швидкий
відгук інтерфейсу. З огляду на ці вимоги було відібрано наступні засоби реалізації:
1 Java + Spring Boot (бекенд)
- Spring Boot обрано як основний фреймворк для серверної частини завдяки
його стабільності, високій продуктивності та широкому набору
інструментів для створення REST API. Він спрощує конфігурацію
серверної логіки, забезпечує обробку HTTP-запитів, роботу з базою даних,
а також надає вбудовані механізми безпеки;
- Java, як мова програмування, відзначається надійністю та хорошою
підтримкою з боку спільноти, що робить її актуальною для створення
невеликих, але відповідальних бізнес-рішень.
2 React + JavaScript + Vite (фронтенд)
- для створення клієнтського інтерфейсу використано React - одну з
найпопулярніших бібліотек для побудови SPA-додатків. Компонентний
підхід дозволяє створювати масштабований інтерфейс, що легко
розширюється та підтримується;
- JavaScript забезпечує швидкий цикл розробки та достатню гнучкість, що є
оптимальним для невеликих комерційних застосунків;
- Vite застосовано як інструмент для збирання проекту, оскільки він
забезпечує надзвичайно швидкий запуск сервера розробки та значно
прискорює компіляцію, що позитивно впливає на ефективність роботи на
етапах створення інтерфейсу.
3 Redux (управління станом)
- Redux використовується для централізованого керування станом
фронтенду, що є важливим при роботі з кошиком, списком товарів та
формуванням замовлення. Завдяки збереженню стану в одному сховищі
забезпечується передбачуваність поведінки додатку та зручність
72
ЧДТУ 252493.017 ПЗ
налагодження. У проекті використовується Redux Toolkit, який значно
спрощує роботу зі стором та редʼюсерами.
4 PostgreSQL (база даних)
- PostgreSQL обрана як основна СУБД через свою надійність, відповідність
стандартам SQL, стабільність та відмінну роботу з транзакціями. Вона
забезпечує структурування даних про меню, користувачів та замовлення, а
також підтримує складні запити та індексування.
5 Інструменти розробки: IntelliJ IDEA, VS Code, Git та GitHub
- IntelliJ IDEA використовується для розробки серверної частини завдяки
широкій підтримці Spring Boot;
- Visual Studio Code застосовується для створення фронтенду, оскільки має
гнучку систему розширень та високу швидкість роботи;
- Git та GitHub забезпечують контроль версій, командну роботу та безпечне
зберігання коду.
6 Інструменти тестування
- JUnit використовувався для модульного тестування серверних
компонентів;
- Postman застосовується для ручного тестування REST API та перевірки
коректності маршрутизації;
- Jest може використовуватися для тестування окремих фронтенд-
компонентів.
Вибрані засоби реалізації забезпечують оптимальний баланс між
продуктивністю, простотою розробки та гнучкістю системи. Spring Boot гарантує
стабільність серверної частини, React - динамічний інтерфейс користувача, Redux -
передбачуване управління станом, а PostgreSQL - надійне зберігання даних. Такий
технологічний стек повністю відповідає потребам малого бізнесу та дозволяє
створити сучасну, швидку та легку в підтримці веб-систему суші-бару.
73
ЧДТУ 252493.017 ПЗ
4.1.2 Опис структурної (функціональної) схеми
Структурна схема веб-системи суші-бару (рис. 4.1) відображає загальну
організацію програмного комплексу та демонструє, з яких основних підсистем
складається система та як вони взаємодіють між собою. Представлена ієрархія дає
можливість чітко зрозуміти логічний поділ функціональності та визначити
відповідальність кожного модуля у межах веб-платформи. Загальна структура
складається з чотирьох ключових підсистем, що разом формують повноцінну веб-
платформу для перегляду меню, формування замовлень, взаємодії з користувачами
та обробки логіки роботи сервісу.
Рисунок 4.1 – Структурна схема веб-системи суші-бару
Опис структурної схеми
- UI інтерфейс: відповідає за відображення всіх елементів веб-додатку та
забезпечує взаємодію користувача з системою. До його складу входять
компоненти головної сторінки, каталогу, корзини, інтерфейсу замовлення
та інших елементів вебсайту. UI інтерфейс отримує дані з підсистем
каталогу, авторизації та замовлень і динамічно оновлює сторінки у
відповідь на дії користувача;
- підсистема авторизації: забезпечує реєстрацію та авторизацію
користувачів. Вона відповідає за збереження облікових даних, перевірку
74
ЧДТУ 252493.017 ПЗ
правильності введеної інформації та керування сесією користувача.
Підсистема інтегрована з сервером через REST API, що дозволяє безпечно
передавати дані для входу чи реєстрації;
- підсистема замовлень: реалізує бізнес-логіку, пов’язану з оформленням
онлайн-замовлення. Вона приймає кошик з фронтенду, розраховує
загальну вартість, формує структуру замовлення, передає його на сервер та
отримує підтвердження успішної обробки. Також підсистема взаємодіє з
UI інтерфейсом для відображення деталей замовлення;
- підсистема каталогу: відповідає за отримання, структурування та передачу
списку доступних позицій меню. Вона отримує інформацію про страви з
сервера та формує каталоги, необхідні для роботи інтерфейсу. За потреби
підсистема може також надавати дані для пошуку та фільтрації товарів.
Роль взаємодії підсистем
- UI інтерфейс - є точкою входу всіх взаємодій користувача із системою. Він
отримує інформацію з інших підсистем та відображає її на сторінці;
- авторизація - визначає рівень доступу користувача та адаптує інтерфейс
відповідно до його статусу (гість, зареєстрований користувач);
- каталог - забезпечує UI актуальними даними про страви та наповнює
інтерфейс контентом;
- замовлення - формує деталі замовлення та взаємодіє з сервером для його
створення.
Завдяки такій структурі кожна підсистема має свою чітко визначену роль, що
значно полегшує розробку, тестування та подальше розширення системи. Такий
поділ забезпечує гнучкість та дозволяє окремо удосконалювати UI, каталоги, логіку
обробки замовлень чи механізм авторизації без необхідності перепроектування всієї
системи.
Функціональна схема (рис. 4.2) демонструє ключові операції системи, їхню
взаємодію та логічну послідовність виконання. Вона показує, яким чином веб-
система реалізує свої основні завдання та які процеси відбуваються під час її роботи.
Завдяки аналізу цієї схеми стає можливим чітко визначити внутрішню організацію
75
ЧДТУ 252493.017 ПЗ
програмного комплексу, зрозуміти, як саме окремі компоненти координують свою
діяльність, та оцінити загальну узгодженість функціональних модулів.
Рисунок 4.2 – Функціональна схема веб-системи суші-бару
Опис функціональної схеми
1 UI інтерфейс: є точкою входу всієї взаємодії користувача з веб-системою
- взаємодія з інтерактивними елементами UI: користувач натискає кнопки,
заповнює форми, переглядає сторінки, керує кошиком та надсилає дані у
підсистеми;
- оновлення UI елементів: інтерфейс динамічно змінюється залежно від
отриманих результатів - оновлює список товарів, стан авторизації, вміст
кошика, деталі замовлення.
76
ЧДТУ 252493.017 ПЗ
2 Підсистема авторизації: відповідає за автентифікацію та ідентифікацію
користувача.
- введення даних: користувач вводить логін, пароль або інші облікові дані;
- аналіз результату авторизації: підсистема звіряє введені дані з інформацією
у базі;
- оновлення UI з результатом: система показує повідомлення про успішний
вхід, помилку або дозволяє продовжувати як гість.
3 Підсистема замовлень: відповідає за формування, перевірку та передачу
замовлень у систему.
- введення даних: користувач вводить дані доставки, контактні дані, вибрані
позиції меню та кількість;
- обробка інформації: підсистема формує структуру замовлення, обчислює
загальну суму, формує запит на сервер;
- оновлення UI з результатом: після обробки замовлення сервер повертає
підтвердження, і UI відображає повідомлення про успішне замовлення або
помилку.
4 Підсистема каталогу: займається пошуком, відображенням та оновленням
списку товарів меню.
- введення запиту: користувач може виконати пошук страви, вибрати
категорію, фільтрувати меню;
- формування запитів: підсистема формує запит на сервер, передаючи
параметри пошуку або запит на отримання всього каталогу;
- отримання списку товарів: сервер повертає відфільтрований або повний
перелік страв;
- відображення результатів: UI інтерфейс отримує список та оновлює
сторінку для користувача.
5 Елемент бази даних: містить інформацію про категорії страв, меню,
користувачів та замовлення
- приймає запити від підсистем каталогу, авторизації та замовлень через
сервер;
77
ЧДТУ 252493.017 ПЗ
- повертає структуровані дані, необхідні для роботи системи;
- забезпечує цілісність, збереження та доступність інформації.
Загальна взаємодія підсистем
1 Користувач взаємодіє з UI (натискання, ввід даних, пошук);
2 UI передає інформацію відповідній підсистемі;
3 Підсистема формує запит до серверної частини;
4 Сервер звертається до бази даних;
5 База даних повертає відповідні дані;
6 UI оновлюється та відображає результат.
Такий підхід забезпечує чіткий поділ відповідальностей, полегшує підтримку
системи та гарантує стабільну обробку запитів користувачів.
4.1.3 Опис логічної схеми системи
Логічна схема веб-системи суші-бару відображає покроковий алгоритм роботи
платформи та демонструє, як саме система реагує на дії користувача, формує
запити, обробляє дані та повертає результати. Такий опис дозволяє чітко зрозуміти
загальний робочий процес веб-додатку та визначити ключові етапи взаємодії між
користувачем, клієнтською частиною, сервером та базою даних. Нижче наведено
послідовність дій і процесів, які виконуються у межах веб-системи суші-бару під час
її використання.
1 Вхід на веб-сайт
- користувач вводить адресу сайту або переходить за посиланням;
- клієнтська частина надсилає запит до серверу для отримання початкових
даних головної сторінки (каталог, рекомендації, акції);
- на екран завантажується головна сторінка системи.
2 Перегляд каталогу страв
- користувач переходить у розділ «Меню» за допомогою навігації;
- клієнтська частина формує запит на сервер для отримання повного списку
позицій меню;
78
ЧДТУ 252493.017 ПЗ
- на сторінці каталогу відображаються страви у вигляді карток: зображення,
назва, опис, склад та ціна.
3 Використання фільтрів
- користувач може обирати категорії або особливості страв (роли, сети,
філадельфія, гострі, запечені тощо);
- підсистема каталогу формує фільтраційний запит;
- сервер повертає відфільтрований список страв;
- інтерфейс оновлюється відповідно до обраних параметрів.
4 Перегляд детальної інформації про страву
- користувач натискає на обрану страву з каталогу;
- фронтенд надсилає серверу запит за ідентифікатором позиції меню;
- після отримання відповіді відкривається сторінка страви з детальним
описом, вагою, інгредієнтами, ціною та додатковими опціями (соуси,
палички тощо).
5 Авторизація користувача
- користувач натискає кнопку «Увійти»;
- відкривається форма авторизації;
- введені дані відправляються на сервер;
- сервер перевіряє їх у базі даних;
- при успішній авторизації UI оновлюється: з’являється ім’я користувача,
доступ до історії замовлень тощо.
6 Реєстрація нового облікового запису
- користувач натискає «Реєстрація»;
- вводить дані у форму створення акаунту;
- фронтенд передає інформацію на сервер;
- сервер додає нового користувача у базу даних;
- UI оновлюється відповідно до статусу нового користувача.
7 Додавання страви до кошика
- користувач натискає «Додати до кошика» на сторінці страви або в
каталозі;
- клієнтська частина додає позицію в локальне сховище (localStorage);
79
ЧДТУ 252493.017 ПЗ
- у верхній частині сайту оновлюється індикатор кількості товарів у кошику.
8 Оформлення замовлення
- користувач переходить до кошика;
- відображаються всі обрані страви, можливість змінити кількість або
видалити позицію;
- після натискання «Оформити замовлення» відкривається форма введення
даних доставки (ім’я, телефон, адреса, спосіб доставки, спосіб оплати);
- після заповнення всіх полів клієнтська частина надсилає сформоване
замовлення на сервер;
- сервер створює запис замовлення у базі даних та повертає підтвердження;
- сайт показує повідомлення про успішне оформлення замовлення.
9 Завершення роботи з сайтом
- користувач може будь-коли вийти з облікового запису;
- перейти за зовнішніми посиланнями або закрити вкладку браузера;
- локально збережений кошик може бути очищений або збережений залежно
від логіки системи.
Цей алгоритм описує основну логіку роботи веб-системи суші-бару та
відтворює типові сценарії взаємодії користувача з платформою - від перегляду меню
до оформлення і завершення замовлення. Реальна імплементація може бути
розширена додатковими можливостями, такими як система лояльності, рекомендації
або push-сповіщення.
4.1.4 Розробка бази даних
Розробка бази даних є одним із ключових етапів створення веб-системи суші-
бару, оскільки саме база даних забезпечує надійне зберігання та впорядкування
інформації про користувачів, замовлення та меню. На цьому етапі проводиться
аналіз функціональних вимог, визначення необхідних сутностей та проектування
логічної структури даних. Правильно розроблена база даних дозволяє системі
працювати стабільно, швидко та безпечно. Початковим кроком розробки стало
визначення основних бізнес-процесів: оформлення замовлень, перегляд каталогу,
80
ЧДТУ 252493.017 ПЗ
робота з користувачами та управління товарами. На основі цього було створено
концептуальну модель бази даних, яка оптимально відображає логіку роботи
онлайн-системи суші-бару. Нижче наведено опис основних сутностей та їхніх
атрибутів відповідно до спроектованої UML-діаграми.
Концептуальна модель бази даних
1 Користувачі (User)
- user_id: Long - унікальний ідентифікатор користувача;
- firstname: String - ім’я користувача;
- lastname: String - прізвище користувача;
- login: String - логін для авторизації;
- password: String - пароль користувача;
- email: String - електронна пошта;
- phone_number: String - номер телефону.
2 Категорії (Category)
- category_id: Long - унікальний ідентифікатор категорії;
- name: String - назва категорії.
3 Товари (Product)
- product_id: Long - унікальний ідентифікатор страви;
- name: String - назва страви;
- description: String - опис або склад;
- portion: String - формат порції (вага або кількість шматочків);
- price: Decimal - ціна;
- category_id: Long - ідентифікатор категорії, до якої належить страва.
4 Замовлення (Order)
- order_id: Long - унікальний ідентифікатор замовлення;
- order_date: Date - дата створення замовлення;
- order_status: OrderStatus - статус замовлення;
- products: String - список товарів у форматі JSONB;
- total_price: Decimal - фінальна сума замовлення;
- customer_name: String - ім’я клієнта;
81
ЧДТУ 252493.017 ПЗ
- customer_phone: String - номер телефону;
- delivery_date: Date - дата та час доставки;
- delivery_method: DeliveryMethod - спосіб доставки;
- delivery_address: String - адреса доставки;
- num_persons: Int - кількість персон для замовлення;
- courier_comment: String - коментар до кур’єра;
- rest_comment: String - коментар до ресторану;
- user_id: Long - ідентифікатор користувача.
5 Перерахування (Enums)
- OrderStatus: містить перелік можливих станів замовлення;
- DeliveryMethod: містить типи доставки, доступні у системі.
Після формування концептуальної моделі виконується етап проектування
логічної моделі бази даних. Логічна модель (рис. 4.4) є розвитком концептуальної
моделі та відображає її у вигляді, придатному для подальшої реалізації в обраній
системі керування базами даних. На цьому етапі визначаються структури таблиць,
їхні атрибути, типи даних, а також встановлюються зв’язки між таблицями. Для
позначення типів зв’язків у логічній моделі використано умовні позначення,
наведені на рисунку 4.3.
Рисунок 4.3 – Позначення зв’язків між таблицями
82
ЧДТУ 252493.017 ПЗ
Рисунок 4.4 – Логічна модель бази даних для інтернет-магазину
На основі логічної моделі бази даних формується фізична модель, яка
відображає структуру даних у вигляді, безпосередньо придатному для реалізації в
обраній системі керування базами даних. У межах даного проекту як СУБД
використовується PostgreSQL. Фізична модель враховує особливості реалізації цієї
СУБД, зокрема підтримувані типи даних, механізми індексації, обмеження
цілісності та способи організації зв’язків між таблицями. Такий підхід дозволяє
оптимізувати структуру зберігання даних, підвищити продуктивність виконання
запитів і забезпечити надійність роботи бази даних у процесі експлуатації системи.
4.1.5 Розробка інтерфейсу користувача
Розробка зручного та ефективного користувацького інтерфейсу є одним із
ключових етапів створення веб-системи суші-бару. В умовах конкуренції серед
сервісів онлайн-замовлення їжі важливу роль відіграє простота навігації, зрозуміла
структура сторінок та швидка реакція інтерфейсу на дії користувача. Саме якісний
користувацький інтерфейс значною мірою впливає на загальне враження від сервісу
та зручність оформлення замовлень. Для реалізації клієнтської частини веб-системи
83
ЧДТУ 252493.017 ПЗ
було використано бібліотеку React для мови програмування JavaScript, яка дозволяє
створювати динамічний інтерфейс на основі компонентного підходу. Такий підхід
забезпечує повторне використання елементів інтерфейсу, спрощує підтримку коду
та дозволяє ефективно масштабувати застосунок.
Керування станами додатку реалізовано за допомогою бібліотеки Redux, яка
використовується для зберігання глобального стану веб-системи, зокрема даних про
користувача, каталог страв, кошик та процес оформлення замовлення. Redux
дозволяє централізовано обробляти зміни станів у відповідь на дії користувача, що
забезпечує передбачувану поведінку інтерфейсу та спрощує логіку взаємодії між
компонентами.
Оновлення елементів інтерфейсу відбувається лише у разі зміни відповідних
станів, що позитивно впливає на продуктивність веб-додатку. Навігація між
сторінками веб-системи суші-бару реалізована за допомогою бібліотеки react-router,
яка забезпечує коректну маршрутизацію між сторінками каталогу, кошика,
авторизації та оформлення замовлення без перезавантаження сторінки. Це дозволяє
створити плавну та зручну взаємодію користувача з системою. У подальшому буде
детально розглянуто основні елементи користувацького інтерфейсу веб-системи
суші-бару, їх функціональне призначення та особливості реалізації.
Для зручного пошуку та вибору товару, на сайті представлений каталог
товарів (рис. 4.5), що є основним інтерфейсом для ознайомлення з асортиментом. На
сторінці каталогу, ліворуч від основного вмісту, розміщений блок фільтрації. Цей
блок дозволяє користувачу налаштовувати вибірку товарів за різними
характеристиками. На скріншоті відображений фільтр за «Категорією», який
дозволяє відвідувачу обрати один або декілька типів продукції (наприклад, Роли,
Сети, Гункани тощо) за допомогою інтерактивних чекбоксів. Праворуч
розташований перелік товарів, представлений у вигляді карток. Кожна картка товару
містить: зображення продукту, назву товару, короткий опис його основного складу
чи інгредієнтів та актуальну ціну, інтерактивну кнопку «В кошик», яка дозволяє
швидко додати обрану позицію до замовлення. Завдяки такій структурі, користувач
84
ЧДТУ 252493.017 ПЗ
може швидко орієнтуватися в асортименті та ефективно звужувати вибірку
відповідно до своїх уподобань.
Рисунок 4.5 – Каталог товарів веб-сайту
Щодо інформаційного наповнення, зокрема умов доставки та оплати,
користувач може з усім цим ознайомитись, перейшовши за відповідним
посиланням, розташованим у навігаційному меню («шапці») сайту. На сторінці з
інформацією, його зустрінуть інформаційні блоки з наповненням згідно тематики
сторінки (рис. 4.6). Вгорі сторінки розташований навігаційний елемент «хлібні
крихти» («Головна / Доставка та оплата»), що забезпечує швидкий перехід на
домашню сторінку.
85
ЧДТУ 252493.017 ПЗ
Рисунок 4.6 – Сторінка «Доставка та оплата»
Сторінка «Про заклад» (рис. 4.7) належить до інформаційного наповнення
сайту і призначена для ознайомлення користувача з компанією, її діяльністю та
соціальною відповідальністю.
Рисунок 4.7 – Сторінка «Про заклад»
На кожній сторінці, перед самим основним наповнюванням, для користувача
було розроблено систему «хлібні крихти» (рис. 4.8) - інтерактивний навігаційний
86
ЧДТУ 252493.017 ПЗ
елемент. Цей елемент візуально показує послідовність переміщення користувача від
домашньої сторінки до поточної точки перебування та надає змогу користувачу не
тільки побачити, де саме він зараз знаходиться відносно домашньої сторінки, але й
скористатись ним, щоб повернутись на одну з посередницьких точок шляхом
натискання на відповідну назву точки.
Рисунок 4.8 – Елемент сторінки «хлібні крихти»
Сторінка «Контакти» (рис. 4.9) призначена для надання користувачам
актуальної довідкової інформації про заклад та забезпечення зручних каналів
зв’язку з адміністрацією сервісу доставки. Інтерфейс сторінки побудований у
мінімалістичному стилі, що сприяє швидкому сприйняттю інформації та зручності
користування. Основний контент сторінки представлений у вигляді окремого
інформаційного блоку з заголовком «Контакти». Центральним елементом є картка з
інформацією про гарячу лінію, де вказано години роботи служби підтримки,
контактні телефонні номери та електронну пошту. Такий формат подання
інформації дозволяє користувачу швидко знайти необхідні дані без перевантаження
інтерфейсу зайвими елементами. Додатково на сторінці наведено текстове
повідомлення з роз’ясненням щодо порядку подання скарг, пропозицій або
коментарів, а також орієнтовного часу відповіді на письмові звернення. Це підвищує
прозорість взаємодії між користувачем і сервісом та формує довіру до закладу.
87
ЧДТУ 252493.017 ПЗ
Рисунок 4.9 – Сторінка «Контакти»
Інтерфейс кошика замовлень (рис. 4.10) призначений для перегляду обраних
користувачем товарів, керування їх кількістю та переходу до етапу оформлення
замовлення. Кошик реалізовано у вигляді модального вікна, що відкривається
поверх основного контенту сайту, не перериваючи загальний сценарій взаємодії
користувача з веб-застосунком. У верхній частині модального вікна відображається
зведена інформація про кількість товарів у кошику та загальну суму замовлення. Це
дозволяє користувачеві миттєво оцінити поточний стан замовлення без необхідності
додаткових переходів між сторінками.
Основна частина інтерфейсу представлена у вигляді списку позицій, доданих
до кошика. Для кожного товару відображається зменшене зображення, назва страви,
елементи керування кількістю, а також підсумкова вартість відповідної позиції.
Користувач має можливість змінювати кількість одиниць товару за допомогою
інтуїтивно зрозумілих кнопок збільшення та зменшення, що забезпечує швидке
коригування замовлення. Також передбачена функція видалення окремих позицій із
кошика за допомогою відповідної іконки. Це підвищує гнучкість взаємодії та
88
ЧДТУ 252493.017 ПЗ
дозволяє користувачеві легко редагувати склад замовлення. У нижній частині
модального вікна розміщено основну дію - кнопку «Оформити замовлення», яка
візуально виділена та спрямовує користувача до наступного етапу оформлення
покупки. Чітке позиціонування та контрастне оформлення кнопки відповідає
сучасним UX-рекомендаціям і мінімізує ймовірність помилкових дій.
Рисунок 4.10 – Інтерфейс кошика замовлень
Сторінка оформлення замовлення (4.11) призначена для введення
користувачем персональних даних, вибору способів доставки та оплати, а також
фінального підтвердження замовлення. Інтерфейс сторінки побудований за
принципом чіткого поділу функціональних блоків, що сприяє зручності та
зрозумілості процесу оформлення покупки. Основна частина сторінки поділена на
дві логічні колонки. У лівій колонці розміщено форму введення даних одержувача.
Вона містить поля для зазначення імені та прізвища, електронної пошти, номера
телефону, способу доставки, способу оплати та адреси доставки. Поля форми мають
чіткі підписи та зрозумілий порядок заповнення, що мінімізує ризик помилок з боку
користувача а використання випадаючих списків для вибору способів доставки та
оплати підвищує зручність взаємодії та стандартизує введення даних.
89
ЧДТУ 252493.017 ПЗ
Рисунок 4.11 – Сторінка «Оформлення замовлення»
Користувач має можливість створити власний обліковий запис та виконати
вхід до системи за допомогою відповідних модальних вікон. Для відкриття форм
реєстрації або авторизації необхідно скористатися іконкою профілю, розташованою
у верхній частині інтерфейсу сайту. Після натискання на дану іконку відображається
модальне вікно авторизації (рис. 4.12), у якому користувачеві пропонується ввести
необхідні облікові дані для входу в систему.
Рисунок 4.12 – Модальне вікно авторизації
90
ЧДТУ 252493.017 ПЗ
У разі відсутності зареєстрованого облікового запису користувач має
можливість перейти до модального вікна реєстрації (рис. 4.13). Для полів введення у
формах авторизації та реєстрації, за аналогією з формою оформлення замовлення,
реалізовано механізми валідації, які забезпечують перевірку введених даних на
відповідність очікуваним форматам.
Рисунок 4.13 – Модальне вікно реєстрації
Після успішного входу користувача в систему інтерфейс веб-застосунку
оновлюється та відображає ім’я, зазначене під час реєстрації, у верхній частині
сторінки поруч із іконкою кошика (рис. 4.14). При наведенні курсора на даний
елемент інтерфейсу відображається спадне меню, яке містить кнопку для виходу з
облікового запису.
Рисунок 4.14 – Відображення авторизованого в системі користувача
91
ЧДТУ 252493.017 ПЗ
Розробка інтерфейсу веб-застосунку сервісу доставки страв була виконана з
урахуванням сучасних технологій та принципів, орієнтованих на зручність
користувача. Інтерфейс спрямований на забезпечення швидкого доступу до
основного функціоналу сервісу, зокрема перегляду меню, оформлення замовлень та
взаємодії з обліковим записом користувача. Шапка сайту забезпечує зручну та
швидку навігацію між основними розділами веб-застосунку, доступ до форм
авторизації та реєстрації, а також до кошика замовлень, вміст якого користувач
може переглядати та редагувати безпосередньо з будь-якої сторінки сайту. Для
покращення зручності орієнтації в структурі сайту було реалізовано навігаційний
елемент «хлібні крихти», який дозволяє користувачеві відстежувати свій шлях
відносно головної сторінки та швидко повертатися до попередніх розділів.
Інформаційні сторінки, що містять відомості про умови доставки та оплати,
дані про заклад, а також контактну інформацію, забезпечують користувачеві повне
уявлення про сервіс і правила надання послуг. Для підвищення зручності взаємодії з
формами, представленими у веб-застосунку, в усіх полях введення використано
підказки-заповнювачі, які демонструють коректний формат введення даних.
Крім того, у формах реалізовано механізми валідації введених користувачем
даних, що дозволяє своєчасно інформувати користувача про можливі помилки та
запобігати некоректному введенню інформації. Таким чином, розроблений
інтерфейс веб-застосунку відповідає сучасним вимогам UX/UI-дизайну та
забезпечує зручний, зрозумілий і ефективний процес взаємодії користувача з
сервісом доставки їжі.
4.1.6 Опис розробки програмних компонентів
Для реалізації серверної частини веб-застосунку було використано мову
програмування Java у поєднанні з фреймворком Spring Boot. З метою детальнішого
розгляду архітектури та принципів побудови програмних компонентів доцільно
визначити основні складові фреймворку, які були задіяні в межах даного проєкту, а
також їх функціональне призначення в системі. Фреймворк Spring Boot надає
92
ЧДТУ 252493.017 ПЗ
широкий набір компонентів, кожен з яких виконує визначену роль у процесі
розробки додатку. До основних компонентів, використаних у проекті, належать:
- репозиторії - інтерфейси, що забезпечують доступ до бази даних та
реалізацію стандартних операцій створення, читання, оновлення та
видалення даних (CRUD);
- контролери - класи, відповідальні за обробку HTTP-запитів клієнта. Саме
на рівні контролерів визначаються кінцеві точки (ендпоінти), через які
здійснюється передавання даних між клієнтською та серверною частинами
системи;
- моделі запитів (Request-моделі) - класи, що описують структуру даних, які
надходять від клієнта на сервер. Вони використовуються для
стандартизації вхідної інформації та реалізації її валідації за допомогою
анотацій, наданих фреймворком Spring Boot;
- сервіси - програмні компоненти, у яких зосереджена основна бізнес-логіка
веб-застосунку. Сервіси використовуються для обробки даних, виконання
перевірок і прийняття рішень щодо подальших дій, а також застосовуються
у контролерах для реалізації логіки обробки запитів;
- моделі та сутності - класи, призначені для представлення даних предметної
області та їх відображення на відповідні таблиці бази даних. За допомогою
спеціальних анотацій здійснюється зв’язування полів класів з колонками
таблиць, що забезпечує коректну роботу механізмів об’єктно-реляційного
відображення.
Тепер, коли було розглянуто основні компоненти фреймворку Spring Boot,
доцільно перейти до детального опису реалізованої логіки веб-застосунку для
онлайн-замовлення страв суші-бару. Серверна частина системи побудована за
принципами багаторівневої архітектури, що забезпечує розподіл відповідальності
між компонентами та підвищує підтримуваність і масштабованість програмного
комплексу. Доступ до бази даних реалізовано за допомогою репозиторіїв, які
використовують можливості Spring Data JPA для виконання CRUD-операцій та
складніших вибірок. Репозиторії приймають необхідні параметри, які
93
ЧДТУ 252493.017 ПЗ
підставляються у відповідні запити до бази даних. Управління викликами
репозиторіїв здійснюється через сервіси, а обробка HTTP-запитів реалізується у
контролерах.
У межах серверної частини були реалізовані такі репозиторії:
- OrderRepository - призначений для роботи із замовленнями користувачів;
- ProductRepository - використовується для доступу до інформації про страви
меню;
- CategoryRepository - забезпечує роботу з категоріями страв;
- UserRepository - відповідає за збереження та отримання даних
користувачів;
- OrderItemRepository - використовується для отримання інформації про
позиції, що входять до конкретного замовлення.
Для обробки HTTP-запитів та формування REST-ендпоінтів були реалізовані
відповідні контролери, які приймають запити з клієнтської частини та передають їх
у сервісний шар для подальшої обробки:
- OrderController - забезпечує роботу із запитами, пов’язаними зі
створенням, отриманням та оновленням замовлень;
- ProductController - обробляє запити на отримання списку страв та
інформації про конкретні продукти;
- CategoryController - відповідає за отримання категорій меню;
- UserController - реалізує запити на реєстрацію та авторизацію
користувачів.
Сутності (Entity) представляють об’єкти бази даних і визначають структуру
таблиць та зв’язки між ними. У проєкті були реалізовані наступні сутності:
- OrderEntity - представляє замовлення користувача та містить інформацію
про дату створення, статус і користувача;
- OrderItemEntity - представляє позиції замовлення, включаючи кількість та
ціну кожної страви;
- ProductEntity - представляє страву меню, включаючи назву, опис, ціну та
шлях до зображення;
94
ЧДТУ 252493.017 ПЗ
- CategoryEntity - представляє категорію меню (наприклад, роли, сети,
гункан, сашимі);
- UserEntity - представляє обліковий запис користувача з даними для
авторизації та контактною інформацією.
Для зручного керування станами замовлень у системі були використані
перелічувальні типи даних (enum), які визначають допустимі значення та
підвищують читабельність коду:
- OrderStatus – перелік можливих статусів замовлення, таких як «створено»,
«в обробці», «виконано» та «скасовано».
Для передачі даних між клієнтською та серверною частинами застосунку були
реалізовані моделі запитів (Request Models). Вони забезпечують структуровану
передачу даних і спрощують їх обробку в контролерах і сервісах. У проекті
реалізовано такі моделі:
- CreateOrderRequest - модель запиту на створення нового замовлення з
переліком страв;
- UpdateOrderStatusRequest - модель запиту для оновлення статусу
замовлення;
- UserRequest - модель запиту для реєстрації та авторизації користувачів;
- OrderItemRequest - модель для передачі інформації про позиції замовлення.
Сервіси виконують бізнес-логіку застосунку, обробляючи дані, отримані від
контролерів, та взаємодіючи з репозиторіями. Вони відповідають за коректність
виконання операцій та дотримання логіки роботи системи. У межах проекту були
реалізовані наступні сервіси:
- OrderService - обробляє бізнес-логіку, пов’язану зі створенням, переглядом
та оновленням замовлень;
- ProductService - відповідає за отримання та обробку інформації про страви
меню;
- UserService - забезпечує бізнес-логіку реєстрації та авторизації
користувачів.
95
ЧДТУ 252493.017 ПЗ
Використання описаних компонентів дозволило побудувати структурований
та надійний серверний застосунок, що забезпечує ефективне управління даними та
стабільну взаємодію з клієнтською частиною. Чіткий розподіл відповідальності між
контролерами, сервісами та репозиторіями полегшує супровід системи, її тестування
та подальше розширення. Такий підхід забезпечує гнучкість і масштабованість веб-
застосунку, що відповідає вимогам сучасних інформаційних систем у сфері
електронної комерції.
4.2 Тестування системи
У процесі розробки будь-якої веб-системи тестування є одним із ключових
етапів, що забезпечує якість, надійність та коректність роботи програмного
продукту. Основною метою тестування є виявлення та усунення помилок, перевірка
відповідності реалізованого функціоналу встановленим вимогам, а також оцінка
стабільності системи в умовах реального використання. У даному розділі
розглянуто основні підходи до тестування веб-системи суші-бару, описано
застосовані методи та наведено результати проведених перевірок. Тестування
використовується для аналізу різних аспектів роботи програмного комплексу,
зокрема:
- перевірка функціональності – дозволяє впевнитися, що всі можливості
системи, такі як перегляд меню, додавання страв до кошика, оформлення
замовлення та авторизація користувачів, працюють коректно та
відповідають заданим вимогам;
- оцінка продуктивності – дає змогу визначити, як система поводиться при
різному навантаженні, оцінити швидкість обробки запитів та стабільність
роботи серверної частини;
- перевірка безпеки – спрямована на аналіз захищеності системи,
коректність обробки користувацьких даних та відсутність критичних
вразливостей.
Наведені аспекти не є вичерпними, оскільки на практиці тестування охоплює
більшість компонентів програмного забезпечення та супроводжує його на всіх
96
ЧДТУ 252493.017 ПЗ
етапах життєвого циклу. Об’єктами тестування у межах даного проекту виступають
серверне API, реалізоване на основі Spring Boot, користувацький інтерфейс веб-
системи суші-бару, створений за допомогою бібліотеки React, а також база даних
PostgreSQL.
Для досягнення максимальної ефективності тестування застосовується
поетапний підхід. На кожному етапі визначається обсяг тестування, обирається
відповідна стратегія та формується перелік тестових сценаріїв, необхідних для
перевірки конкретних модулів або функціональних можливостей системи. Після
завершення кожного етапу тестування проводиться аналіз отриманих результатів, і у
випадку виявлення помилок здійснюється їх усунення з подальшим повторним
тестуванням. У наступних підпунктах буде детально розглянуто основні методи
тестування, що застосовувалися під час перевірки веб-системи суші-бару, а також
описано результати проведених тестів.
4.2.1 Модульне тестування
Обсяг тестування
Модульне тестування у межах даного проекту спрямоване на перевірку
окремих компонентів користувацького інтерфейсу веб-системи суші-бару. Основна
увага приділяється модулям, що відповідають за процеси авторизації, реєстрації
користувачів та керування станом облікового запису, оскільки саме ці елементи є
критично важливими для коректної роботи системи онлайн-замовлень. У рамках
модульного тестування перевіряються такі компоненти:
- LogoutModal - компонент, що відповідає за відображення модального вікна
підтвердження виходу з облікового запису користувача. Під час тестування
перевіряється коректність відображення модального вікна за умови зміни
відповідного стану у глобальному сховищі Redux, а також правильність
обробки натискань на кнопки підтвердження або скасування виходу з
системи.
- AuthModalForm - компонент, що реалізує модальну форму авторизації
користувача. Для цього компонента тестується обробка змін у текстових
97
ЧДТУ 252493.017 ПЗ
полях, коректне відображення форми залежно від стану застосунку,
обробка події надсилання форми, а також відображення повідомлень про
помилки у разі введення некоректних облікових даних.
- RegModalForm - компонент, призначений для відображення модальної
форми реєстрації нового користувача веб-системи суші-бару. У процесі
тестування перевіряється валідація введених користувачем даних,
коректне відображення помилок валідації, обробка подій введення тексту у
поля форми та надсилання реєстраційних даних.
Таким чином, обсяг модульного тестування охоплює ключові компоненти, що
забезпечують взаємодію користувача з системою на початковому етапі роботи з веб-
додатком.
Стратегія тестування
Під час проведення модульного тестування застосовується послідовна
стратегія перевірки окремих компонентів інтерфейсу. Спочатку перевіряється
базове відображення кожного компонента з наявністю всіх необхідних елементів
інтерфейсу. Далі виконується тестування взаємодії користувача з компонентами
шляхом симуляції подій натискання кнопок, введення тексту та закриття модальних
вікон. Окрема увага приділяється перевірці коректності збереження та оновлення
стану компонентів після взаємодії з користувачем. Також тестується надсилання
відповідних Redux-подій при виконанні дій з інтерактивними елементами
інтерфейсу, такими як кнопки «Увійти», «Зареєструватися», «Підтвердити» та
«Скасувати».
Крім того, перевіряється логіка валідації форм на відповідність введених
даних вимогам веб-системи перед їх передачею на серверну частину. Такий підхід
дозволяє виявити помилки на ранніх етапах та забезпечити стабільну роботу
клієнтської частини веб-системи суші-бару.
Тестові випадки
Таблиця 4.1
Тестовий випадок модульного тестування №1
98
ЧДТУ 252493.017 ПЗ
Тест-кейс № 1
Опис Рендер компоненту AuthModalForm
Передумови Redux store з відкритим authModal
Кроки 1. Рендер компоненту AuthModalForm за допомогою render.
2. Перевірка наявності полів і кнопок.
Очікуваний - Поля "Логин" та "Пароль" присутні на екрані.
результат
- Кнопка "Увійти" присутня на екрані.
Фактичний - Поля "Логин" та "Пароль" присутні на екрані.
результат
- Кнопка "Увійти" присутня на екрані.
Пройдено Так
Таблиця 4.2
Тестовий випадок модульного тестування №2
Тест-кейс № 2
Опис Обробка зміни текстових полів в AuthModalForm
Продовж.табл. 4.2
Передумови Redux store з відкритим authModal
Кроки 1. Рендер компоненту AuthModalForm.
2. Введення значення в поле "Логин".
3. Введення значення в поле "Пароль".
99
ЧДТУ 252493.017 ПЗ
Очікуваний - Поле "Логин" містить введене значення
результат
- Поле "Пароль" містить введене значення
Фактичний - Поле "Логин" містить введене значення
результат
- Поле "Пароль" містить введене значення
Пройдено Так
Таблиця 4.3
Тестовий випадок модульного тестування №3
Тест-кейс № 3
Опис Обробка надсилання форми авторизації
Передумови Redux store з відкритим authModal
Кроки 1. Рендер компоненту AuthModalForm.
2. Введення значень в поля "Логин" та "Пароль".
3. Натискання на кнопку "Увійти".
Очікуваний - Повернений результат записується викликом
результат dispatch(setProfile())
- Модальне вікно з авторизацією закривається
Таблиця 4.4
Тестовий випадок модульного тестування №4
Тест-кейс № 4
Опис Відображення помилки в AuthModalForm при неправильних
даних
Передумови Redux store з відкритим authModal
100
ЧДТУ 252493.017 ПЗ
Кроки 1. Рендер компоненту AuthModalForm.
2. Введення неправильних значень в поля "Логин" та "Пароль".
3. Натискання на кнопку "Увійти".
Очікуваний - Відображення повідомлення "Аккаунт не знайдено! Перевірте
результат логін та пароль.".
Фактичний - Відображення повідомлення "Аккаунт не знайдено! Перевірте
результат логін та пароль.".
Пройдено Так
Таблиця 4.5
Тестовий випадок модульного тестування №5
Тест-кейс № 5
Опис Рендер компоненту LogoutModal
Передумови Redux store з відкритим logoutModal
Кроки 1. Рендер компоненту LogoutModal за допомогою render.
Очікуваний - Відображення повідомлення "Ви впевнені що хочете вийти з
результат облікового запису?».
- Кнопки "Ні" та "Так" присутні на екрані.
Продовж. Табл. 4.5
Фактичний - Відображення повідомлення "Ви впевнені що хочете вийти з
результат облікового запису?».
- Кнопки "Ні" та "Так" присутні на екрані.
Пройдено Так
Таблиця 4.6
101
ЧДТУ 252493.017 ПЗ
Тестовий випадок модульного тестування №6
Тест-кейс № 6
Опис Відправка подій clearProfile та closeModal при натискані "Так" в
LogoutModal
Передумови Redux store з відкритим logoutModal
Кроки 1. Рендер компоненту LogoutModal.
2. Натискання на кнопку "Так".
Очікуваний - Викликається подія clearProfile()
результат
- Модальне вікно LogoutModal закривається
Фактичний - Викликається подія clearProfile()
результат
- Модальне вікно LogoutModal закривається
Пройдено Так
Таблиця 4.7
Тестовий випадок модульного тестування №7
Тест-кейс № 7
Опис Відправка тільки події closeModal при натискані "Ні" в
LogoutModal
Продовж.табл. 4.7
Передумови Redux store з відкритим logoutModal
Кроки 1. Рендер компоненту LogoutModal.
2. Натискання на кнопку "Ні".
Очікуваний - Модальне вікно LogoutModal закривається
результат
102
ЧДТУ 252493.017 ПЗ
Фактичний - Модальне вікно LogoutModal закривається
результат
Пройдено Так
Таблиця 4.8
Тестовий випадок модульного тестування №8
Тест-кейс № 8
Опис Рендер компоненту RegModalForm
Передумови Redux store з відкритим regModal
Кроки 1. Рендер компоненту RegModalForm.
2. Перевірка наявності усіх полів і кнопок.
Очікуваний - Поля «Ім'я», «Прізвище», «E-mail адреса», «Пароль», «Пароль
результат повторно» та кнопка «Зарєеструватись» пристуні на екрані
Фактичний - Поля «Ім'я», «Прізвище», «E-mail адреса», «Пароль», «Пароль
результат повторно» та кнопка «Зарєеструватись» пристуні на екрані
Пройдено Так
103
ЧДТУ 252493.017 ПЗ
Таблиця 4.9
Тестовий випадок модульного тестування №9
Тест-кейс № 9
Опис Обробка зміни текстових полів в RegModalForm
Передумови Redux store з відкритим regModal
Кроки 1. Рендер компоненту RegModalForm.
2. Введення значень в поля «Ім'я», «Прізвище», «E-mail адреса»,
«Пароль», «Пароль повторно»
Очікуваний - Усі поля містять відповідні введені значення
результат
Фактичний - Усі поля містять відповідні введені значення
результат
Пройдено Так
Таблиця 4.10
Тестовий випадок модульного тестування №10
Тест-кейс № 10
Опис Обробка надсилання форми реєстрації
Передумови Redux store з відкритим regModal
Кроки 1. Рендер компоненту RegModalForm.
2. Введення правильних значень в поля «Ім'я», «Прізвище», «E-
mail адреса», «Пароль», «Пароль повторно»
3. Натискання на кнопку «Зареєструватись»
Очікуваний - Дані відправлені
результат
- Модальна форма реєстрації закривається
104
ЧДТУ 252493.017 ПЗ
Продовж.табл. 4.11
Фактичний - Дані відправлені
результат
- Модальна форма реєстрації закривається
Пройдено Так
Проведення тестування
Для тестування компонентів користувацького інтерфейсу було використано
інструменти Jest та @testing-library/react, які є зручними та ефективними засобами
для автоматизованого тестування React-компонентів. Для кожного визначеного
тестового сценарію були розроблені відповідні автоматизовані тести, після чого всі
модулі проходили перевірку по черзі. Результати виконання тестів для окремих
компонентів наведено на рисунках 4.15, 4.16 та 4.17.
Рисунок 4.15 – Результати тестування модуля AuthModalForm
Рисунок 4.16 – Результати тестування модуля LogoutModal
105
ЧДТУ 252493.017 ПЗ
Рисунок 4.17 – Результати тестування модуля RegModalForm
Аналіз проведеного тестування
На даному етапі було виконано тестування елементів користувацького
інтерфейсу, що забезпечують процеси авторизації, реєстрації користувачів та виходу
з облікового запису. Перед початком тестування були чітко визначені його межі,
обрана стратегія та сформовано перелік тестових сценаріїв. За результатами
виконаних перевірок усі заплановані тестові випадки були успішно пройдені, що
свідчить про коректну роботу відповідних модулів та їх відповідність заданим
вимогам. Таким чином, модульне тестування зазначених компонентів вважається
завершеним.
4.2.2 Інтеграційне тестування
Обсяг тестування
Інтеграційне тестування у межах даного проєкту було спрямоване на
перевірку взаємодії між клієнтською частиною веб-системи суші-бару, серверним
API та базою даних. Основною метою цього етапу є підтвердження коректної
роботи інтегрованих модулів системи та перевірка того, що результати виконання
запитів відповідають очікуваним значенням. У ході інтеграційного тестування
перевірялась робота основних REST API ендпоінтів, які забезпечують ключовий
функціонал системи онлайн-замовлення, зокрема:
- GET /api/catalog – отримання списку доступних страв меню суші-бару;
106
ЧДТУ 252493.017 ПЗ
- POST /api/auth/login – авторизація користувача в системі;
- POST /api/auth/reg – реєстрація нового користувача.
Перевірка зазначених ендпоінтів дозволяє оцінити коректність обробки HTTP-
запитів, правильність взаємодії між серверною частиною та базою даних, а також
відповідність отриманих відповідей вимогам клієнтської частини веб-додатку.
Стратегія тестування
Для проведення інтеграційного тестування була застосована стратегія Big
Bang Integration Testing. Згідно з даною стратегією, всі основні модулі системи були
інтегровані одночасно, після чого виконувалося тестування веб-системи як єдиного
цілого. Основною перевагою обраної стратегії є можливість швидко оцінити
загальну працездатність системи та виявити помилки, що виникають на рівні
взаємодії між модулями. Такий підхід також дозволяє скоротити час на поетапне
інтегрування компонентів і є доцільним для проектів із відносно простою та
зрозумілою архітектурою, якою є веб-система суші-бару.
Тестові випадки
Таблиця 4.12
Тестовий випадок інтеграційного тестування №1
Тест-кейс №1 1
Опис Отримання списку товарів
Передумови API сервер повинен бути запущеним
Кроки 1. Відправити GET-запит на «http://localhost:8082/api/catalog»
Очікуваний Статус відповіді – 200;
результат
Тіло відповіді містить список товарів.
Фактичний Статус відповіді серверу – 200;
результат
Тіло відповіді містить список товарів.
Пройдено Так
Таблиця 4.13
107
ЧДТУ 252493.017 ПЗ
Тестовий випадок інтеграційного тестування №2
Тест-кейс № 4
Опис Перевірка відправки запиту на авторизацію
Передумови API сервер повинен бути запущеним
Кроки 1. Відправити POST-запит на «http://localhost:8082/api/auth/login» з
тілом {"email": "[email protected]", "password": "Test123#"}
Очікуваний Статус відповіді – 200;
результат
Тіло відповіді містить підтвердження авторизації.
Фактичний Статус відповіді серверу – 200;
результат
Тіло відповіді містить підтвердження авторизації.
Пройдено Так
Таблиця 4.14
Тестовий випадок інтеграційного тестування №3
Тест-кейс №3 3
Опис Перевірка відправки запиту на реєстрацію
Передумови API сервер повинен бути запущеним
Кроки 1. Відправити POST-запит на «http://localhost:8082/api/auth/reg» з
тілом {"firstname": "Тест", "lastname": "Тестович", "email":
"[email protected]", "password": "Test123#"}
Очікуваний Статус відповіді – 200; Тіло відповіді містить підтвердження
результат реєстрації.
Фактичний Статус відповіді серверу – 200; Тіло відповіді містить
результат підтвердження реєстрації.
Пройдено Так
Для реалізації інтеграційних тестів відповідно до попередньо визначених
тестових випадків, наведених у таблицях, було використано інструмент
108
ЧДТУ 252493.017 ПЗ
автоматизованого тестування JUnit. Для кожного тестового сценарію був створений
окремий автоматичний тест із використанням засобів, які надає даний фреймворк.
У процесі тестування кожен ендпоінт перевірявся на коректність обробки
запитів та відповідність отриманих результатів очікуваним значенням. Результати
виконання автоматичних інтеграційних тестів представлені на рисунку 4.18, тоді як
приклади реалізованих тестових випадків наведені на рисунках 4.19 та 4.20.
Рисунок 4.18 – Результати інтеграційного тестування
Рисунок 4.19 – Розроблені на JUnit автоматичні тести, частина 1
Рисунок 4.20 – Розроблені на JUnit автоматичні тести, частина 2
Аналіз проведеного тестування
109
ЧДТУ 252493.017 ПЗ
За результатами виконання інтеграційного тестування встановлено, що всі
визначені тестові випадки були виконані успішно. Отримані результати повністю
відповідають очікуваним значенням, що свідчить про коректну взаємодію між
модулями системи та правильну реалізацію основних бізнес-процесів.
Таким чином, можна зробити висновок, що інтеграційне тестування,
проведене із застосуванням стратегії Big Bang Integration Testing, завершилось
успішно. Під час тестування помилок або критичних відхилень у роботі системи
виявлено не було, у зв’язку з чим необхідність у внесенні виправлень та повторному
проведенні тестування відсутня.
4.2.3 Системне тестування
Обсяг тестування
Системне тестування охоплює всі компоненти програмного комплексу після
завершення етапу їх інтеграції та спрямоване на перевірку роботи системи в цілому.
Даний вид тестування дозволяє оцінити відповідність розробленої системи
визначеним функціональним і нефункціональним вимогам, а також виявити
можливі дефекти, що виникають у процесі взаємодії окремих модулів.
У межах цього етапу тестування здійснюється перевірка коректності взаємодії
між основними складовими системи, а також аналіз продуктивності роботи
програмного комплексу під час виконання ключових бізнес-процесів. Отримані
результати дають змогу підтвердити стабільність функціонування системи та її
готовність до використання в реальних умовах.
Об’єктом системного тестування у межах даного проекту є взаємодія між
клієнтським веб-додатком, серверною частиною та базою даних під час виконання
таких операцій, як отримання списку товарів для відображення у каталозі та
оформлення замовлення користувачем.
Стратегія тестування
Для перевірки продуктивності та коректності обробки запитів було
використано інструмент Postman, який дозволяє виконувати ручне тестування
кінцевих точок серверного API. За допомогою цього інструмента здійснюється
відправлення HTTP-запитів та аналіз отриманих відповідей, включаючи такі
110
ЧДТУ 252493.017 ПЗ
показники, як час відповіді сервера, обсяг переданих даних і статус виконання
запиту.
Перевірка взаємодії між модулями системи проводилась на прикладі модуля
реєстрації користувача. Даний підхід дозволяє перевірити повний ланцюг взаємодії
компонентів системи: передачу даних з клієнтської частини, їх обробку на сервері,
збереження у базі даних та формування відповіді, яка повертається клієнтському
додатку. Таким чином підтверджується коректність роботи всієї системи як єдиного
цілого.
Тестові випадки
Таблиця 4.15
Тестовий випадок системного тестування №1
Тест-кейс № 1
Опис Продуктивність запиту на отримання товарів
Передумови API сервер повинен бути запущеним
Кроки 1. Відправити GET-запит за допомогою Postman на
«http://localhost:8082/api/category
Очікуваний Статус відповіді – 200; Швидкість виконання запиту не
результат перевищує 15ms
Фактичний Статус відповіді серверу – 200;
результат
Швидкість виконання запиту – 6ms.
Пройдено Так
Таблиця 4.16
Тестовий випадок системного тестування №2
Тест-кейс №3 3
Опис Перевірка взаємодії серверу з базою даних на запит реєстрації
відправлений з клієнтської частини за допомогою форми
Продовж. табл. 4.16
111
ЧДТУ 252493.017 ПЗ
Передумови API сервер повинен бути запущеним
Кроки 1. Відправити правильно заповнену форму реєстрації з веб-сайту
Очікуваний - Реєстраційні дані успішно записані в базу даних;
результат
- Отримується відповідь у інтерфейсі про успішний запит
Фактичний - Реєстраційні дані успішно записані в базу даних
результат
- Отримується відповідь у інтерфейсі про успішний запит
Пройдено Так
Проведення тестування
У процесі системного тестування за допомогою інструменту Postman були
виконані HTTP-запити до серверної частини відповідно до визначених тестових
випадків. Під час відправлення запитів здійснювався збір інформації щодо
коректності обробки запитів сервером, а також вимірювалась швидкість отримання
відповідей. Результати виконання тестових випадків системного тестування №1,
зокрема показники часу відповіді сервера та статуси виконання запитів, наведені на
рисунку 4.21.
Рисунок 4.21 – Результат тестового випадку системного тестування №1
Аналіз проведеного тестування
На основі результатів системного тестування можна зробити висновок, що
фактичні показники продуктивності розробленої системи відповідають попередньо
визначеним нефункціональним вимогам. Отримані результати підтвердили
стабільну роботу програмного комплексу при виконанні основних бізнес-операцій.
112
ЧДТУ 252493.017 ПЗ
Перевірка взаємодії між модулями засвідчила коректну передачу даних між
клієнтською та серверною частинами системи. Запити, ініційовані з боку
клієнтського додатку, успішно обробляються сервером, після чого відповідна
інформація зберігається у базі даних. У відповідь клієнтський інтерфейс отримує
підтвердження про успішне виконання операцій, що свідчить про правильну
інтеграцію всіх компонентів системи. Таким чином, розроблений програмний
комплекс успішно пройшов етап системного тестування та продемонстрував
коректну роботу відповідно до поставлених вимог.
4.2.4 Приймальне тестування
Обсяг тестування
Приймальне тестування охоплює повний перелік функціональних і
нефункціональних вимог до web-системи суші-бару, сформованих на етапі аналізу
вимог та побудови діаграм прецедентів. Основною метою цього етапу є
підтвердження того, що розроблений програмний продукт відповідає бізнес-
вимогам та очікуванням замовника і може бути використаний у реальних умовах
експлуатації.
У межах приймального тестування перевіряється коректність реалізації ключових
сценаріїв взаємодії користувачів із системою, стабільність роботи функціональних
модулів, а також відповідність поведінки системи задокументованим вимогам.
Стратегія тестування
На початковому етапі було проведено узагальнений аналіз усіх бізнес-вимог
до готового програмного комплексу. На основі цього аналізу сформовано перелік
вимог, які підлягають перевірці в межах приймального тестування. Далі для кожної
вимоги був розроблений чек-лист тестових сценаріїв, що дозволяє послідовно і
системно перевірити відповідний функціонал. Після виконання всіх тестових
сценаріїв результати тестування були проаналізовані, що дало змогу зробити
висновок щодо готовності системи до впровадження.
113
ЧДТУ 252493.017 ПЗ
Проведення тестування
На етапі приймального тестування було перевірено реалізацію вимог для
основних ролей у системі.
1 Функціональні вимоги для клієнта:
- можливість перегляду каталогу страв;
- пошук позицій меню за назвою;
- додавання та видалення товарів із кошика;
- реєстрація нового облікового запису;
- авторизація у вже створений обліковий запис;
- оформлення онлайн-замовлення.
2 Функціональні вимоги для адміністратора:
- керування переліком товарів (додавання, редагування, видалення);
- керування статусами замовлень.
На основі наведеного переліку були сформовані детальні тестові випадки,
кожен із яких перевіряв окремий сценарій використання системи. Усі сценарії
виконувалися послідовно з фіксацією результатів для подальшого аналізу.
Таблиця 4.17
Тестовий випадок приймального тестування №1
Тест-кейс № 1
Опис Перегляд меню
Кроки 1. Відкрити меню на веб-сайті, натиснувши кнопку «Меню» у
навігаційному меню
Очікуваний Відображення повного списку меню
результат
Пройдено Так
Таблиця 4.18
Тестовий випадок приймального тестування №2
114
ЧДТУ 252493.017 ПЗ
Тест-кейс № 3
Опис Додавання та видалення товарів з кошику
Кроки 1. Додати будь-який товар у кошик натиснувши кнопку «Купити»
на карточці товару або на сторінці товару
2. Навести на корзину та у спадному меню зі списком товарів у
корзині натиснути на кнопку видалення товару
Очікуваний - Після натискання кнопки «Купити» товар додається в кошик
результат
- Натиснувши кнопку видалення товар видаляється з кошику
Пройдено Так
Таблиця 4.19
Тестовий випадок приймального тестування №3
Тест-кейс № 4
Опис Реєстрація облікового запису
Кроки 1. Натиснути іконку профілю в шапці сайту
2. Натиснути «Немає аккаунту?»
3. Заповнити форму реєстрації та натиснути «Зареєструватись»
Очікуваний - Створення облікового запису та повідомлення про успіх
результат
Пройдено Так
Таблиця 4.20
Тестовий випадок приймального тестування №4
115
ЧДТУ 252493.017 ПЗ
Тест-кейс № 6
Опис Оформлення замовлення
Кроки 1. Перейти на сторінку оформлення замовлення натиснувши
«Перейти до оформлення» при додаванні товару у кошик або
через кнопку «Оформити замовлення» у кошику
2. Заповнити форму оформлення замовлення та натиснути
«Підтвердити»
Очікуваний - Замовлення оформлене, користувача повідомлено про успіх
результат
Пройдено Так
Аналіз проведеного тестування
Після аналізу бізнес-вимог, сформованих на етапі проектування програмного
комплексу, було визначено перелік тестових випадків, необхідних для перевірки
відповідності розробленої системи заданим вимогам.
У ході приймального тестування всі визначені сценарії використання були
послідовно відтворені та перевірені. Результати тестування показали, що
реалізований функціонал повністю відповідає встановленим вимогам, а система
коректно обробляє всі передбачені сценарії взаємодії користувачів із web-системою
суші-бару. Жодних критичних відхилень або помилок у роботі програмного
комплексу виявлено не було.
Таким чином, приймальне тестування можна вважати успішно завершеним, а
розроблений програмний продукт - готовим до передачі замовнику та подальшого
практичного використання.
4.3 Приклади впровадженого програмного комплексу
116
ЧДТУ 252493.017 ПЗ
Після переходу на веб-сайт користувач потрапляє на головну сторінку
системи (рис. 4.22). Основною сторінкою для взаємодії з користувачем є сторінка
меню, на якій представлений асортимент страв суші-бару. Сторінка побудована у
вигляді каталогу товарів із картками страв, що містять зображення, назву, короткий
опис складу та вартість позиції, а також кнопку додавання товару до кошика.
Рисунок 4.22 – Головна сторінка з меню веб-сайту
У верхній частині сторінки розташована шапка сайту (рис. 4.23), яка
забезпечує навігацію між основними розділами веб-системи. Вона включає
навігаційне меню з посиланнями на сторінки «Меню», «Доставка та оплата», «Про
заклад» та «Контакти», а також іконку профілю користувача та іконку кошика з
індикатором кількості доданих товарів. Шапка сайту є фіксованою та залишається
доступною під час прокрутки сторінки, що забезпечує зручний доступ до основних
функцій системи з будь-якого розділу.
117
ЧДТУ 252493.017 ПЗ
Рисунок 4.23 – Шапка веб-сайту з навігаційним меню
Ліва частина сторінки меню містить блок фільтрації товарів (рис. 4.24) за
категоріями. Користувач може обрати одну або декілька категорій, зокрема роли,
сети, гункан, сашимі або суші, після чого список товарів оновлюється відповідно до
обраних параметрів. Це дозволяє швидко звузити перелік страв та знайти потрібну
позицію.
Рисунок 4.24 – Блок фільтрації товарів на сторінці веб-сайту з каталогом
Центральна частина сторінки відведена для відображення карток товарів
(рис.4.25). Кожна картка містить фотографію страви, її назву, короткий опис
інгредієнтів, ціну та кнопку «В кошик». Натискання на кнопку додає відповідну
позицію до кошика користувача, при цьому інформація про кількість товарів у
кошику миттєво оновлюється в інтерфейсі.
118
ЧДТУ 252493.017 ПЗ
Рисунок 4.25 – Картка товару з каталогу розміщеному на веб-сайті
Після додавання товарів до кошика користувач може переглянути його вміст,
натиснувши на іконку кошика у правій частині шапки сайту. При цьому
відкривається спливаюче вікно кошика (рис. 4.26), у якому відображається перелік
усіх доданих товарів. У верхній частині кошика виводиться загальна інформація про
кількість товарів та сумарну вартість замовлення. Нижче розташований список
позицій, де для кожного товару відображається його назва, мініатюра зображення,
кількість одиниць та вартість з урахуванням обраної кількості.
Користувач має можливість керувати вмістом кошика безпосередньо з цього
вікна. Для кожної позиції доступні кнопки збільшення та зменшення кількості
товару, що дозволяє оперативно змінювати склад замовлення. Також передбачена
можливість повного видалення товару з кошика за допомогою кнопки видалення,
після чого загальна сума замовлення автоматично перераховується.
У нижній частині кошика розміщена кнопка «Оформити замовлення»,
натискання на яку переводить користувача на сторінку оформлення замовлення
(рис. 4.27). Таким чином, кошик виконує роль проміжного етапу між вибором
119
ЧДТУ 252493.017 ПЗ
товарів у каталозі та завершенням процесу замовлення, забезпечуючи зручний
контроль над складом і вартістю покупки.
Рисунок 4.26 – Спливаюче вікно кошика товарів
Рисунок 4.27 – Сторінка оформлення замовлення на веб-сайті
На сторінці оформлення замовлення представлена форма введення даних,
необхідних для завершення покупки. Сторінка поділена на дві основні частини:
форму введення персональних даних та блок з підсумковою інформацією про
замовлення. У лівій частині сторінки розміщена форма оформлення замовлення, яка
120
ЧДТУ 252493.017 ПЗ
містить поля для введення основної інформації одержувача. Користувач повинен
вказати ім’я та прізвище одержувача, адресу електронної пошти та номер телефону.
Також у формі передбачені випадаючі списки для вибору способу доставки та
способу оплати, що дозволяє адаптувати процес оформлення замовлення під
потреби користувача. Після заповнення всіх обов’язкових полів користувач може
підтвердити введені дані, натиснувши кнопку «Підтвердити». Перед відправкою
замовлення система перевіряє коректність заповнення форми, що дозволяє
мінімізувати помилки під час обробки замовлення.
У правій частині сторінки відображається зведена інформація про вміст
кошика. Тут показано перелік обраних товарів, їх кількість та вартість для кожної
позиції, а також загальну суму замовлення. Користувач має можливість змінювати
кількість товарів або видаляти окремі позиції безпосередньо зі сторінки оформлення
замовлення, що забезпечує гнучкість та зручність взаємодії.
Для виконання авторизації користувача у веб-системі передбачено модальне
вікно входу до облікового запису (рис. 4.28). Дане модальне вікно відкривається
після натискання на іконку профілю, що розташована у правій частині шапки сайту,
та відображається поверх поточної сторінки без необхідності переходу на окрему
сторінку. Модальне вікно авторизації містить форму входу, яка складається з полів
для введення логіну (електронної пошти) та пароля користувача. Обидва поля є
обов’язковими для заповнення, що забезпечує коректну ідентифікацію користувача
в системі. Для підтвердження введених даних користувач повинен натиснути кнопку
«Увійти», після чого введена інформація передається на сервер для перевірки.
У разі успішної авторизації модальне вікно автоматично закривається, а інтерфейс
сайту оновлюється відповідно до стану авторизованого користувача. Зокрема, у
шапці сайту замість іконки профілю відображається ім’я користувача, що свідчить
про успішний вхід до облікового запису.
Якщо користувач ще не має облікового запису, у модальному вікні
передбачено посилання «Немає акаунту?», натискання на яке відкриває форму
реєстрації нового користувача (рис. 4.29). Такий підхід дозволяє швидко перейти
121
ЧДТУ 252493.017 ПЗ
між процесами авторизації та реєстрації без зайвих переходів між сторінками, що
підвищує зручність користування веб-системою.
Рисунок 4.28 – Модальне вікно авторизації на веб-сайті
Рисунок 4.29 – Модальне вікно реєстрації на веб-сайті
122
ЧДТУ 252493.017 ПЗ
ВИСНОВКИ ДО ЧЕТВЕРТОГО РОЗДІЛУ
У четвертому розділі магістерської роботи було розглянуто процес
безпосередньої реалізації web-системи для малого закладу харчування на прикладі
суші-бару. Обґрунтовано вибір програмних засобів і технологій, які забезпечують
стабільну, продуктивну та масштабовану роботу системи. Застосування серверної
частини на основі Java та Spring Boot у поєднанні з клієнтським додатком,
реалізованим за допомогою React, Redux і Vite, дозволило ефективно реалізувати
бізнес-логіку, обробку замовлень та взаємодію з користувачами.
У межах розділу було спроектовано та описано структурну, функціональну й
логічну схеми програмного комплексу, що надало цілісне уявлення про внутрішню
організацію системи, основні модулі та їх взаємодію. Також було розроблено
структуру бази даних PostgreSQL, яка враховує специфіку предметної області суші-
бару, забезпечує цілісність даних та можливість подальшого розширення
функціоналу. Окрему увагу було приділено розробці користувацького інтерфейсу.
Інтерфейс орієнтований на зручність, інтуїтивну навігацію та швидку взаємодію
користувача з системою. Використання сучасних підходів до керування станом і
маршрутизації дозволило оптимізувати оновлення інтерфейсу та скоротити час
завантаження сторінок, що позитивно впливає на користувацький досвід.
Завершальним етапом розділу стало комплексне тестування програмного
комплексу. Було проведено модульне, інтеграційне, системне та приймальне
тестування із застосуванням автоматизованих і мануальних методів. Результати
тестування підтвердили коректну роботу окремих компонентів, їхню узгоджену
взаємодію та повну відповідність функціональним і нефункціональним вимогам,
сформованим на етапі проектування.
Таким чином, у четвертому розділі було реалізовано, перевірено та
підтверджено працездатність розробленої web-системи суші-бару, що дозволяє
вважати програмний комплекс завершеним і готовим до практичного використання.
123
ЧДТУ 252493.017 ПЗ
ВИСНОВКИ
У результаті виконання магістерської роботи було розроблено
повнофункціональну web-систему для малих закладів харчування на прикладі суші-
бару. Проведений аналіз предметної області та існуючих рішень дозволив визначити
основні вимоги до системи, сформувати перелік необхідного функціоналу та
обґрунтувати використання сучасних технологій і архітектурних підходів для
реалізації онлайн-замовлень. Моделювання предметної області та бізнес-процесів
забезпечило чітке розуміння структури системи, її основних сутностей і
взаємозв’язків між ними. Це дозволило коректно спроєктувати архітектуру
програмного комплексу, логічну структуру та базу даних, що позитивно вплинуло
на цілісність і масштабованість розробленого рішення.
Реалізована клієнт-серверна архітектура з використанням React, Redux, Vite,
Java Spring Boot та PostgreSQL продемонструвала ефективність і відповідність
поставленим вимогам. Проведене тестування підтвердило стабільність роботи
системи, коректну взаємодію між її компонентами та відповідність функціональним
і нефункціональним вимогам.
Загалом виконана робота дозволила створити сучасну, зручну та надійну web-
систему, яка може бути використана у реальній діяльності суші-бару та слугувати
основою для подальшого розвитку і розширення функціональних можливостей.
124
ЧДТУ 252493.017 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Java Spring [Документація]. - Точка доступу: URL: https://spring.io/web-
applications. - Java Spring: Web Applications
2 React [Документація]. - Точка доступу: URL: https://react.dev/learn. - Get
Startting React.
3 Redux [Документація]. - Точка доступу: URL: https://redux.js.org
/tutorials/essentials/ part-1-overview-concepts. - Redux Overview Concepts
4 PostgreSQL [Документація]. - Точка доступу: URL:
https://www.postgresql.org/docs/ - Postgresql Docs.
5 Spacy.io [Електронний ресурс]. - Точка доступу: URL: spacy.io/ - Spacy.io.
6 React Router [Документація]. - Точка доступу: URL: https://reactrouter.com
/en/main/start/tutorial - React Router: Home v6.21.0.
7 Діаграми UML [Електронний ресурс]. - Точка доступу: URL: https://
evergreens.com.ua/ua/articles/uml-diagrams.html - Побудова UML діаграм.
8 Веб-проект стек Java Spring + React [Електронний ресурс]. - Точка доступу:
URL: https://habr.com/ru/articles/422985/ - BE - Java Spring, FE - React Redux.
9 Формулювання вимог [Електронний ресурс]. - Точка доступу: URL: https://
www.researchgate.net/publication/328142794_Osoblivosti_formuluvanna_vimog_d
o_programnogo_zabezpecenna - Особливості формулювання вимог до
програмного забезпечення.
10 localStorage & React hooks [Електронний ресурс]. - Точка доступу: URL:
https://www.freecodecamp.org/ukrainian/news/yak-vykorystovuvaty-localstorage-z-
khukamy-react-dlya-vstanovlennya-ta-otrymannya-elementiv/ - React hooks.
11 Axios [Електронний ресурс]. - Точка доступу: URL: https://axios-http.com
/ru/docs/intro - What is Axios.
12 Електронна коммерція [Електронний ресурс]. - Точка доступу: URL: business-
inform-2019-1_0-pages-139_144.pdf. – Сутність електронної торгівлі у світовій
економіці
125
ЧДТУ 252493.017 ПЗ
13 Архітектура ПЗ [Електронний ресурс]. - Точка доступу: URL: https://
wezom.com.ua/ua/blog/arhitektura-programmnogo-obespecheniya . – Архітектура
ПЗ
14 IntelliJ IDEA [Документація]. - Точка доступу: URL:
https://www.jetbrains.com/ru-ru/idea/resources/. – Intellij IDEA база знань
15 GitHub [Документація]. - Точка доступу: URL: https://docs.github.com/ru/get-
started/using-git. – Документація по GitHub
16 GitLab [Документація]. - Точка доступу: URL: https://docs.gitlab.com/. – GitLab
Documentation
17 JUnit [Документація]. - Точка доступу: URL: https://junit.org/junit5/
docs/current/user-guide/. – Junit 5 User Guide
18 Visual Studio Code [Документація]. - Точка доступу: URL: https://
code.visualstudio.com/docs. – Documentation for Visual Studio Code
19 RESTful API [Електронний ресурс]. - Точка доступу: URL:
https://aws.amazon.com/what-is/restful-api/. – What is RESTful API
20 UML діаграми [Електронний ресурс]. - Точка доступу: URL:
https://foxminded.ua/ uml-diagramy/. – Для чого потрібні UML діаграми
21 Endpoint [Електроний ресурс]. - Точка доступу: URL:
https://www.microsoft.com/ uk-ua/security/business/security-101/what-is-an-
endpoint. – What is an endpoint
22 Java Spring and PostgreSQL [Електронний ресурс]. - Точка доступу: URL:
https://coderlessons.com/articles/java/spring-boot-i-integratsiia-spring-dannykh-jpa.
– Spring Boot та інтеграція Spring даних JPA
23 Spring Security [Документація]. - Точка доступу: URL:
https://docs.spring.io/spring-security/reference/servlet/getting-started.html. – Hello
Spring Security
24 MySQL [Документація]. - Точка доступу: URL: https://dev.mysql.com/doc/. –
MySQL Documentation
25 MongoDB [Документація]. - Точка доступу: URL: https://www.mongodb.com
/cloud/atlas/register. – MongoDB Atlas
126
ЧДТУ 252493.017 ПЗ
26 Firebase Realtime Database [Документація]. - Точка доступу: URL:
https://firebase.google.com/docs/database/flutter/start. – Get Started with Realtime
Database
27 XSS and SQL Injections [Електронний ресурс]. - Точка доступу: URL:
https://portswigger.net/web-security/cross-site-scripting. – What is cross-site
scripting
28 Google Analytics [Документація]. - Точка доступу: URL:
https://support.google.com/ analytics/?hl=uk#topic=14090456. – Google Analytics
Довідка
29 SSL-шифрування [Електронний ресурс]. - Точка доступу: URL:
https://hostiq.ua/ukr/info/what-is-ssl/. – What is SSL
30 React Redux [Документація]. - Точка доступу: URL: https://react-redux.js.org/. –
React Redux Get Started
31 Моделювання предметної області [Електронний ресурс]. - Точка доступу:
URL:
https://nubip.edu.ua/sites/default/files/u286/pi_rp121_modelyuvannya_ta_analiz_pr
edmetnoyi_oblasti.pdf. – Моделювання та аналіз предметної області
32 Компоненти UML діаграмм [Електронний ресурс]. - Точка доступу: URL:
https://docs.kde.org/trunk5/uk/umbrello/umbrello/uml-elements.html. – Елементи
UML
127