Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9685| Назва: | Кабінет користувача та модуль управління замовленнями web-застосунку "Virtual Staging Home" |
| Автори: | Оксамитна, Любов Павлівна Добровольська, Ілона Михайлівна |
| Ключові слова: | WEB-ЗАСТОСУНОК;КАБІНЕТ КОРИСТУВАЧА;УПРАВЛІННЯ ЗАМОВЛЕННЯМИ;ІНТЕРФЕЙС КОРИСТУВАЧА;БАЗА ДАНИХ;ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;VIRTUAL STAGING HOME;ПРОЄКТУВАННЯ. |
| Дата публікації: | 10-чер-2026 |
| Короткий огляд (реферат): | В умовах стрімкого розвитку цифрових технологій сфера нерухомості та візуалізації простору зазнає великих змін. Особливого значення набувають платформи, що забезпечують користувачам можливість керування замовленнями, взаємодії з сервісом та отримання результатів у межах єдиного web- застосунку. Слід зазначити, що на українському ринку подібні web-застосунки практично відсутні або представлені в дуже обмеженій кількості. Це створює потребу розробки локалізованих, зручних та функціональних рішень. Метою кваліфікаційної роботи бакалавра є розробка кабінету користувача та модуля управління замовленнями web-застосунку «Virtual Staging Home» з урахуванням сучасних вимог щодо функціональності, зручності користування та логіки взаємодії користувачів із системою. Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції «День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9685 |
| Розташовується у зібраннях: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Пояснювальна записка_Добровольська Ілона_КН-2201_2025-2026.pdf Restricted Access | 2.45 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «Кабінет користувача та модуль управління замовленнями web-
застосунку «Virtual Staging Home»»
Виконав: студент 4 курсу, групи КН-2201
Спеціальності 122 − «Комп’ютерні науки»
(шифр і назва спеціальності)
Освітня програма «Комп’ютерні науки та
(назва освітньої програми)
прикладне програмування»
Ілона ДОБРОВОЛЬСЬКА
Керівник Любов ОКСАМИТНА
(ім’я та прізвище)
Рецензент Сергій СТАСЬ
(ім’я та прізвище)
Черкаси 2026 року
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 122 – Комп’ютерні науки
Освітня програма Комп’ютерні науки та прикладне програмування
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2026 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Добровольській Ілоні Михайлівні
(прізвище, ім‘я, по батькові)
1. Тема роботи Кабінет користувача та модуль управління замовленнями web-застосунку
«Virtual Staging Home»
Керівник роботи Оксамитна Л.П., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «12» березня 2026 р. №56/03-03.
2. Строк подання студентом роботи « 08 » червня 2026 року
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами. Робота з базами даних.
Звіт з виробничої практики. Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналітичний огляд існуючих аналогів.
4.2. Проєктування web-застосунку «Virtual Staging Home».
4.3. Розробка, реалізація та тестування web-застосунку «Virtual Staging Home».
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482. ЧДТУ. 62287-01.
5.2. Додаток Б. Лістинг коду програми.
5.3. Додаток В. Інструкція користувача.
5.4. Додаток Г. Апробація кваліфікаційної роботи бакалавра.
5.5 Презентація у вигляді 30 слайдів.
3
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
консультанта завдання видав завдання прийняв
7. Дата видачі завдання 12.01.2026 р.
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи бакалавра Строк виконання
етапів роботи Примітка
1 Видача завдання на кваліфікаційну роботу
бакалавра. 12.01.2026 Виконано
2 Аналіз літературних джерел, об’єкту та предмету
дослідження. до 08.02.2026 Виконано
3 Написання теоретичного розділу кваліфікаційної
роботи бакалавра. до 23.03.2026 Виконано
4 Написання аналітичного розділу (аналіз об’єкту
й предмету дослідження). до 06.04.2026 Виконано
5 Написання практичних розділів й висновків по
роботі. до 15.05.2026 Виконано
6 Передзахист кваліфікаційної роботи бакалавра
на засіданні кафедри КНСА. 26.05.2026 Виконано
7 Подання роботи завідувачу кафедри КНСА. до 10.06.2026 Виконано
8 Захист кваліфікаційної роботи бакалавра. 10.06.2026 Виконано
Студент Ілона ДОБРОВОЛЬСЬКА
(підпис)
Керівник роботи Любов ОКСАМИТНА
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 92 с., 26 рис., 1 таблицю, 6
використаних джерел, 4 додатки.
Актуальність теми. В умовах стрімкого розвитку цифрових технологій сфера
нерухомості та візуалізації простору зазнає великих змін. Особливого значення
набувають платформи, що забезпечують користувачам можливість керування
замовленнями, взаємодії з сервісом та отримання результатів у межах єдиного web-
застосунку. Слід зазначити, що на українському ринку подібні web-застосунки
практично відсутні або представлені в дуже обмеженій кількості. Це створює потребу
розробки локалізованих, зручних та функціональних рішень.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є
розробка кабінету користувача та модуля управління замовленнями web-застосунку
«Virtual Staging Home» з урахуванням сучасних вимог щодо функціональності,
зручності користування та логіки взаємодії користувачів із системою.
Для досягнення поставленої мети були сформовані такі завдання:
− проаналізувати предметну область та існуючі аналоги web-застосунків;
− дослідити функціональні вимоги до кабінету користувача;
− спроєктувати структуру кабінету користувача та модуля управління
замовленнями;
− розробити дизайн інтерфейсу основних елементів web-застосунку «Virtual
Staging Home»;
− реалізувати модуль управління замовленнями з урахуванням ролей
користувачів;
− протестувати розроблені компоненти.
Об’єкт дослідження: процеси розробки та функціонування кабінету
користувача і модуля управління замовленнями web-застосунку «Virtual Staging
Home».
Предмет дослідження: методи та технології реалізації кабінету користувача і
модуля управління замовленнями web-застосунку «Virtual Staging Home».
5
Методи дослідження. У роботі використано наукові та технічні джерела для
вивчення сучасних підходів до розробки web-застосунків. Проведено порівняльний
аналіз існуючих аналогів і сервісів з метою визначення їхніх переваг і недоліків.
Розроблено загальну архітектуру застосунку, структуру даних та користувацький
інтерфейс. Також застосовано практичну реалізацію та тестування web-застосунку
для перевірки коректності роботи і оцінки ефективності.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Публікації. І. М. Добровольська, Л. П. Оксамитна. Розробка кабінету
користувача та модуля управління замовленнями web-застосунку «Virtual Staging
Home» : Збірник тез доповідей студентської науково-практичної конференції ЧДТУ :
22-23 квітня 2026 / [упорядник Мельник І.В.]; Міністерство освіти і науки України,
Черкаський державний технологічний ун-т. Черкаси : ЧДТУ, 2026. С. 8.
Ключові слова: WEB-ЗАСТОСУНОК, КАБІНЕТ КОРИСТУВАЧА,
УПРАВЛІННЯ ЗАМОВЛЕННЯМИ, ІНТЕРФЕЙС КОРИСТУВАЧА, БАЗА ДАНИХ,
WEB-РОЗРОБКА, ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, СИСТЕМА, VIRTUAL
STAGING HOME, ПРОЄКТУВАННЯ.
ABSTRACT
The bachelor’s qualification thesis consists of: 92 pages, 26 illustrations, 1 table, 6
references, and 4 attachments.
Relevance of the topic. In the context of the rapid development of digital
technologies, the real estate sector and spatial visualization are undergoing significant
changes. Platforms that allow users to manage orders, interact with the service, and receive
results within a single web application are becoming particularly important. It should be
noted that such web applications are practically absent from the Ukrainian market or are
available in very limited numbers. This creates a need for the development of localized,
user-friendly, and functional solutions.
Purpose and tasks of the project. The purpose of this bachelor’s thesis is to develop
a user interface and an order management module for the Virtual Staging Home web
6
application, taking into account current requirements for functionality, user-friendliness, and
the logic of user interaction with the system.
To achieve the set goal, the following tasks were defined:
− analyze the subject area and existing similar web applications;
− investigate the functional requirements for the user dashboard;
− design the structure of the user dashboard and the order management module;
− develop the interface design for the system’s main elements «Virtual Staging
Home»;
− implement the order management module, taking user roles into account;
− test the developed components.
Object of study: the development and operation of the user dashboard and the order
management module in the «Virtual Staging Home» web application.
Subject of the study: methods and technologies for implementing the user dashboard
and order management module in the «Virtual Staging Home» web application.
Research Methods. This study uses scientific and technical sources to examine
modern approaches to web application development. A comparative analysis of existing
analogues and services was conducted to identify their strengths and weaknesses. The
overall system architecture, data structure, and user interface were developed. Practical
implementation and testing of the web application were also carried out to verify its correct
operation and evaluate its effectiveness.
Approval of the results of the project. The main findings and results of the
bachelor’s thesis were presented and discussed at the conference «Student Research Day of
the Department of KNSU», held on 22 April 2026 in Cherkasy, Ukraine.
Publications. I. M. Dobrovolska, L. P. Oksamytna. Development of the user
dashboard and order management module for the «Virtual Staging Home» web application:
Collection of abstracts from the Cherkasy State Technological University Student Scientific
and Practical Conference: 22–23 April 2026 / [edited by I. V. Melnyk]; Ministry of
Education and Science of Ukraine, Cherkasy State Technological University. Cherkasy :
Cherkasy State Technological University, 2026. p. 8.
7
Keywords: WEB-APPLICATION, USER DASHBOARD, ORDER
MANAGEMENT, USER INTERFACE, DATABASE, WEB-DEVELOPMENT,
SOFTWARE, SYSTEM, VIRTUAL STAGING HOME, DESIGN.
8
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ ...... 10
ВСТУП ................................................................................................................................ 11
1 АНАЛІТИЧНИЙ ОГЛЯД ІСНУЮЧИХ АНАЛОГІВ ................................................. 14
1.1 Аналіз предметної області Virtual Staging ............................................................ 14
1.2 Огляд та аналіз існуючих web-застосунків........................................................... 15
1.2.1 Аналіз платформи BoxBrownie.com ............................................................. 16
1.2.2 Аналіз сервісу Virtual Staging AI .................................................................. 17
1.2.3 Аналіз сервісу Stuccco.com ........................................................................... 18
1.3 Визначення функціональних можливостей та недоліків аналогів ..................... 20
1.4 Постановка задачі дослідження ............................................................................. 22
Висновки до розділу 1 .................................................................................................. 23
2 ПРОЄКТУВАННЯ WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME» ............. 25
2.1 Визначення вимог до розробки кабінету користувача та модуля управління
замовленнями web-застосунку «Virtual Staging Home» ................................................ 25
2.2 Розробка загальної архітектури web-застосунку ................................................. 26
2.2.1 Загальна структура системи .......................................................................... 27
2.2.2 Детальний опис компонентів системи ......................................................... 28
2.2.3 Сховище даних ............................................................................................... 30
2.2.4 Архітектурна схема взаємодії ....................................................................... 31
2.2.5 Принципи побудови архітектури ................................................................. 32
2.3 Проєктування кабінету користувача ..................................................................... 33
2.4 Проєктування модуля управління замовленнями ................................................ 34
2.5 Проєктування системи авторизації користувачів ................................................ 36
2.6 Проєктування інтерфейсу користувача ................................................................. 37
Висновки до розділу 2 .................................................................................................. 40
3 РОЗРОБКА, РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ WEB-ЗАСТОСУНКУ «VIRTUAL
STAGING HOME» ............................................................................................................. 42
3.1 Основний workflow web-застосунку ..................................................................... 42
9
3.2 Розробка клієнтської (фронтенд) частини web-застосунку ................................ 46
3.3 Розробка серверної (бекенд) частини web-застосунку ........................................ 49
3.4 Реалізація кабінету користувача ............................................................................ 54
3.5 Реалізація модуля управління замовленнями ....................................................... 56
3.6 Реалізація системи авторизації користувачів ....................................................... 61
3.7 Організація процесів тестування та розгортання web-застосунку «Virtual Staging
Home» ................................................................................................................................. 64
Висновки до розділу 3 .................................................................................................. 68
ВИСНОВКИ ....................................................................................................................... 70
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................................... 72
ДОДАТОК А. Cпецифікація 482.ЧДТУ.62287-01 .......................................................... 73
ДОДАТОК Б. Лістинг коду програми ............................................................................. 75
ДОДАТОК В. Інструкція користувача ............................................................................ 83
ДОДАТОК Г. Апробація кваліфікаційної роботи бакалавра ........................................ 89
10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
ПЗ – програмне забезпечення;
AI – Artificial Intelligence (штучний інтелект);
UI – User Interface (інтерфейс користувача);
UX – User Experience (досвід користувача);
Web – веб, пов’язаний із технологіями мережі Інтернет;
Frontend – клієнтська частина web-застосунку;
Backend – серверна частина web-застосунку;
Database (DB) – база даних;
CRUD – Create, Read, Update, Delete (основні операції роботи з даними);
JSON – JavaScript Object Notation (формат обміну даними);
Virtual Staging – віртуальний стейджинг, технологія цифрового оформлення
інтер’єрів.
11
ВСТУП
У сучасному світі інформаційні технології відіграють вирішальну роль у
розвитку бізнесу та наданні послуг у різних сферах діяльності. Web-застосунки стали
невід’ємною частиною цифрової трансформації. Вони забезпечують автоматизацію
бізнес-процесів, спрощують взаємодію користувачів із сервісами та підвищують
загальну ефективність роботи компаній.
Однією з перспективних сфер застосування web-технологій є галузь
нерухомості, зокрема напрям віртуального стейджингу (Virtual Staging), який
дозволяє візуалізувати інтер’єри приміщень із використанням цифрових
інструментів. Це значно підвищує якість презентації об’єктів нерухомості, сприяє
залученню клієнтів та оптимізації процесу продажу або оренди.
Актуальність теми. Актуальність теми кваліфікаційної роботи бакалавра
обумовлена стрімким розвитком web-технологій та зростаючою потребою у зручних
і функціональних онлайн-сервісах у сфері нерухомості. Сучасні web-застосунки в
галузі Virtual Staging часто мають обмежений функціонал кабінету користувача або
недостатньо ефективні механізми управління замовленнями, що ускладнює
взаємодію між клієнтами та сервісом. Тож виникає потреба в створенні зручних,
інтуїтивно зрозумілих і функціонально повноцінних рішень.
Питання розробки web-застосунків та організації взаємодії користувача із
системою досліджуються багатьма провідними ІТ-компаніями, такими як Adobe,
Autodesk, Matterport, а також науковцями та фахівцями в галузі програмної інженерії
та web-розробки. Значний внесок у розвиток підходів до проєктування інтерфейсів та
архітектури програмного забезпечення зробили такі спеціалісти, як Jakob Nielsen, Don
Norman та інші. Їхні дослідження зосереджені на підвищенні зручності використання
систем, оптимізації взаємодії користувача з інтерфейсом та побудові ефективних
інформаційних систем, що є особливо актуальним при розробці сучасних, інтуїтивно
зрозумілих web-застосунків.
Наразі світові напрямки розвитку цієї галузі зосереджені на підвищенні рівня
автоматизації, використанні хмарних технологій, інтеграції штучного інтелекту для
12
обробки зображень та персоналізації сервісів, а також покращенні користувацького
досвіду (UX/UI). Зокрема, зараз активно розвиваються рішення, що дозволяють
автоматизувати обробку замовлень, забезпечувати зручний доступ до історії взаємодії
з сервісом та надавати користувачам інструменти для самостійного управління своїми
даними. У контексті саме Virtual Staging це значно спрощує процес замовлення
послуг, підвищує швидкість обслуговування клієнтів та забезпечую більш прозору та
гнучку взаємодію із системою.
Тож, обрана тема кваліфікаційної роботи бакалавра відповідає сучасним
тенденціям розвитку web-технологій, враховує потреби ринку та має практичну
цінність для подальшого впровадження й розвитку конкурентоспроможних цифрових
сервісів у сфері віртуальної постановки інтер’єру.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи бакалавра є
розробка кабінету користувача та модуля управління замовленнями web-застосунку
«Virtual Staging Home» з урахуванням сучасних вимог щодо функціональності,
зручності користування та логіки взаємодії користувачів із системою.
Для досягнення поставленої мети були сформовані такі завдання:
− проаналізувати предметну область та існуючі аналоги web-застосунків;
− дослідити функціональні вимоги до кабінету користувача;
− спроєктувати структуру кабінету користувача та модуля управління
замовленнями;
− розробити дизайн інтерфейсу основних елементів web-застосунку «Virtual
Staging Home»;
− реалізувати модуль управління замовленнями з урахуванням ролей
користувачів;
− протестувати розроблені компоненти.
Об’єкт дослідження: процеси розробки та функціонування кабінету
користувача і модуля управління замовленнями web-застосунку «Virtual Staging
Home».
Предмет дослідження: методи та технології реалізації кабінету користувача і
модуля управління замовленнями web-застосунку «Virtual Staging Home».
13
Методи дослідження. У роботі використано наукові та технічні джерела для
вивчення сучасних підходів до розробки web-застосунків. Проведено порівняльний
аналіз існуючих аналогів і сервісів з метою визначення їхніх переваг і недоліків.
Розроблено загальну архітектуру web-застосунку, структуру даних та користувацький
інтерфейс. Також застосовано практичну реалізацію та тестування web-застосунку
для перевірки коректності роботи і оцінки ефективності.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на конференції
«День студентської науки кафедри КНСА», 22 квітня 2026 року, Черкаси, Україна.
Публікації. І. М. Добровольська, Л. П. Оксамитна. Розробка кабінету
користувача та модуля управління замовленнями web-застосунку «Virtual Staging
Home» : Збірник тез доповідей студентської науково-практичної конференції ЧДТУ :
22-23 квітня 2026 / [упорядник Мельник І.В.]; Міністерство освіти і науки України,
Черкаський державний технологічний ун-т. Черкаси : ЧДТУ, 2026. С. 8.
14
1 АНАЛІТИЧНИЙ ОГЛЯД ІСНУЮЧИХ АНАЛОГІВ
1.1 Аналіз предметної області Virtual Staging
Virtual Staging (віртуальна постановка) є сучасною технологією візуалізації
об’єктів нерухомості, яка полягає в цифровому облаштуванні інтер’єру приміщення.
Використовуючи спеціальне програмне забезпечення (ПЗ), дизайнери наповнюють
порожні простори меблями та декором на фото, що робить презентацію об’єкта
значно привабливішою та реалістичною. Віртуальний стейджинг замінює реальні
меблі та складну логістику цифровою візуалізацією. Це дозволяє створювати
професійні фото інтер’єрів без фактичного декорування приміщень, економлячи час і
бюджет.
Головне завдання Virtual Staging – викликати інтерес до об’єктів нерухомості
для потенційних покупців або орендарів через якісний візуальний контент.
Візуалізовані інтер’єри допомагають клієнтам краще уявити можливості
використання простору, що значно впливає на прийняття рішення щодо купівлі або
оренди. Особливо актуальним це є для порожніх кімнат або об’єктів без ремонту, де
покупцеві складно самостійно уявити фінальний вигляд інтер’єру.
Сучасні сервіси в цій сфері функціонують переважно у вигляді web-застосунків,
що забезпечують доступ користувачів до послуг через Інтернет. Основними
учасниками взаємодії є клієнти (замовники послуг), адміністратори та дизайнери
(виконавці), а також сама система, яка забезпечує обробку замовлень, збереження
даних та взаємодію між сторонами.
Останніми роками спостерігається активний розвиток сервісів, що базуються на
використанні технологій AI штучного інтелекту, які автоматично генерують варіанти
оформлення інтер’єру, підбирають меблі, стилі, кольори відповідно до заданих
параметрів. Це значно скорочує час обробки замовлень, проте часто не забезпечує
достатнього рівня контролю та прозорості для користувача.
До основних функціональних можливостей таких систем належать:
завантаження зображень приміщень, вибір стилю оформлення, формування та
відстеження замовлень, комунікація між користувачем і виконавцем, а також
15
управління особистими даними через кабінет користувача. Модуль управління
замовленнями також є важливою складовою, адже забезпечує створення,
редагування, обробку та контроль виконання замовлень.
Слід зазначити, що на українському ринку подібні web-застосунки практично
відсутні або представлені у дуже обмеженій кількості. Більшість доступних сервісів
розроблені іноземними компаніями, що ускладнює їх адаптацію до потреб
українських користувачів. Це створює потребу у розробці локалізованих, зручних та
функціональних web-рішень, орієнтованих одночасно на зовнішній і внутрішній
ринок.
Незважаючи на активний розвиток даної галузі, існує ряд проблем, пов’язаних
із реалізацією подібних web-застосунків. Серед них такі:
− недостатня зручність користувацьких інтерфейсів;
− обмежений функціонал кабінету користувача;
− складнощі при оформленні замовлення та контакті з дизайнерами;
− недостатня автоматизація взаємодії між користувачем і системою.
Крім того, навіть за наявності технологій штучного інтелекту, багато сервісів не
забезпечують достатнього рівня персоналізації та контролю результатів з боку
користувача.
Таким чином, сфера Virtual Staging є актуальною та перспективною для
дослідження, оскільки поєднує сучасні web-технології, інструменти обробки
зображень та використання штучного інтелекту. Саме тому для ринку нерухомості
важливо створювати прості та зручні сайти, які зможуть ефективно виконувати такі
складні завдання.
1.2 Огляд та аналіз існуючих web-застосунків
Аналізуючи сучасні web-застосунки в сфері віртуальної постановки будинку,
можна помітити, що ринок уже пропонує низку рішень, які спрямовані на візуалізацію
інтер’єрів та підвищення зацікавленості в об’єктах нерухомості. Водночас кожен із
наявних сервісів має власну специфіку, сильні сторони та певні недоліки, які
16
впливають на користувацький досвід. Для детальнішого аналізу було розглянуто такі
платформи: BoxBrownie.com, Virtual Staging AI та Stuccco.com.
1.2.1 Аналіз платформи BoxBrownie.com. Платформа BoxBrownie.com є
однією із найбільш популярних і перевірених рішень у сфері віртуального
стейджингу. Вона орієнтована переважно на професійних користувачів, таких як
рієлтори, девелопери, дизайнери та маркетингові агентства, і базується на поєднанні
цифрових інструментів разом із ручною роботою спеціалістів дизайнерів [1].
Основними особливостями платформи є:
− поєднання цифрових технологій із ручною роботою дизайнерів, що дозволяє
досягати високого рівня фотореалістичності;
− кабінет користувача в BoxBrownie.com забезпечує доступ до історії
замовлень, де користувач може переглядати активні та завершені проєкти,
завантажені матеріали та фінальні результати;
− модуль управління замовленнями дозволяє відстежувати статус виконання
кожного замовлення, що підвищує прозорість процесу.
Вигляд кабінету користувача платформи BoxBrownie.com показано на рис. 1.1.
Рисунок 1.1 – Кабінет користувача платформи BoxBrownie.com [1]
17
Незважаючи на низку переваг, платформа має і свої недоліки:
− функціональність кабінету користувача є обмеженою з точки зору
інтерактивності. Користувач не має можливості активно впливати на процес
виконання замовлення після його створення;
− сама інформаційна панель є досить перевантеженою великою кількістю
інформації. Це негативно впливає на зручність користування сервісом зі сторони
користувача.
1.2.2 Аналіз сервісу Virtual Staging AI. Іншим прикладом сучасного
інноваційного підходу є сервіс Virtual Staging AI. Він базується на використанні
технологій штучного інтелекту. Даний сервіс орієнтований на швидкість, простоту і
доступність, дозволяючи користувачам отримувати результати віртуального
стейджингу впродовж короткого часу [2].
Virtual Staging AI пропонує широкий вибір стилів інтер’єру та автоматизований
процес генерації дизайну, що робить сервіс зручним для користувачів без спеціальних
дизайнерських навичок. Також слід зазначити, що інтерфейс сервісу досить
привабливий та зрозумілий.
Вигляд кабінету користувача сервісу Virtual Staging AI показано на рис. 1.2.
Рисунок 1.2 – Кабінет користувача сервісу Virtual Staging AI [2]
18
Переваги сервісу:
− особистий кабінет надає доступ до швидкого створення нових замовлень,
вибору стилів та перегляду згенерованих результатів у межах одного інтерфейсу;
− модуль управління замовленнями є спрощеним і тісно інтегрованим з AI-
генерацією, що дозволяє користувачеві оперативно отримувати результати без
довготривалого очікування.
Проте, попри очевидні переваги швидкості та різноманітності, автоматизований
підхід не завжди забезпечує достатній рівень якості та індивідуального налаштування.
Разом з тим, спрощена структура кабінету користувача обмежує можливості роботи з
великою кількістю замовлень. Модуль управління замовленнями не передбачає
детальної системи статусів (на якому етапі перебуває робота), історії змін або
гнучкого редагування параметрів уже створених проектів. Це знижує зручність
використання сервісу для професійних користувачів, які потребують більшого
контролю над процесом.
1.2.3 Аналіз сервісу Stuccco.com. Наступний сервіс Stuccco.com займає
проміжне місце між ручним та автоматизованим підходами. Він пропонує
користувачам можливість обирати стилі віртуального стейджингу та отримувати
досить якісні візуалізації інтер’єрів. Основний акцент зроблено на естетичну складову
та адаптацію дизайну до певної цільової аудиторії [3].
Особливістю сервісу є організація процесу роботи з користувачем через
попередню взаємодію з дизайнером. Кожен проєкт розпочинається з безкоштовної 30-
хвилинної консультації, під час якої визначаються потреби користувача,
обговорюються всі деталі майбутнього дизайну, терміни виконання та вартість
послуг. Після цього користувачу пропонується декілька дизайнерів, з яких він може
обрати одного для подальшої співпраці. Такий підхід забезпечує більш
персоналізований процес створення дизайну та врахування індивідуальних побажань.
Вигляд кабінету користувача сервісу Stucco.com показано на рис. 1.3. Процес
бронювання консультації з дизайнером представлено на рисунку 1.4.
19
Рисунок 1.3 – Кабінет користувача сервісу Stucco.com [3]
Рисунок 1.4 – Процес бронювання консультації з дизайнером [3]
20
Сервіс Stuccco.com пропонує такі переваги:
− кабінет користувача в Stuccco.com дозволяє переглядати замовлення,
відстежувати їх статуси, отримувати фінальні матеріали та взаємодіяти з командою
сервісу в межах одного облікового запису;
− персоналізований підхід до виконання замовлень за рахунок взаємодії з
дизайнером та можливість обрати спеціаліста для роботи над проєктом;
− модуль управління замовленнями є більш структурованим, ніж у повністю
автоматизованих AI-сервісах, що забезпечує кращу організацію проектів і зрозумілу
навігацію.
Однак, функціональність кабінету користувача залишається обмеженою з точки
зору персоналізації та повторного використання замовлень. Модуль управління не
підтримує розширену аналітику, історію змін або інтеграцію з іншими
інструментами. Це ускладнює масштабування роботи з сервісом. Крім того, як і у
випадку з BoxBrownie, обробка замовлень може займати більше часу, ніж AI-
орієнтовані сервіси, що не завжди зручно при швидких маркетингових завданнях.
1.3 Визначення функціональних можливостей та недоліків аналогів
Аналізуючи web-застосунки BoxBrownie.com, Virtual Staging AI та Stucco.com,
можна зробити висновок, що сучасні сервіси в сфері віртуальної постановки мають
спільну функціональну основу, проте відрізняються підходами до реалізації
ключових можливостей кабінету користувача та модуля управління замовленнями.
На основі проведеного дослідження було визначено основні функції для таких
систем [1–3]. До них належать: завантаження зображень приміщення для подальшої
обробки, вибір стилю інтер’єру, формування замовлення, його обробка та отримання
результатів. Важливим елементом усіх сервісів є наявність кабінету користувача,
який забезпечує доступ до персональних даних, історії замовлень та отриманих
результатів. Також у кожному з розглянутих web-застосунків реалізовано модуль
управління замовленнями, щоб відстежувати процес виконання проєктів.
Разом з тим, порівняльний аналіз показав, що кожен із досліджуваних сервісів
21
має власні особливості, обумовлені обраним підходом:
− BoxBrownie.com орієнтований на досягнення високої якості результатів за
рахунок залучення професійних дизайнерів. Це гарантує високий рівень
фотореалістичності, але водночас збільшує час виконання замовлень.
− Virtual Staging AI, навпаки, базується на використанні технологій штучного
інтелекту, що значно скорочує час обробки та отримання результатів, проте може
обмежувати рівень індивідуалізації.
− Модель роботи Stucco.com побудована на поєднанні персоналізованого
підходу та використанні цифрових інструментів. Це забезпечує баланс між якістю та
зручністю, однак не позбавлене певних обмежень.
Незважаючи на наявність широкого функціоналу, в досліджуваних web-
застосунках виявлено ряд спільних недоліків. Зокрема, кабінети користувача в
більшості випадків мають обмежену функціональність і не забезпечують достатнього
рівня інтерактивності. Користувачі часто не мають можливості впливати на процес
виконання замовлення, наприклад редагувати його параметри після створення.
Окремої уваги заслуговує модуль управління замовленнями, який в багатьох
випадках реалізований спрощено. У проаналізованих сервісах майже відсутні
детальна система статусів, історія змін, можливість редагування або повторного
використання замовлень. Це значно ускладнює контроль за виконанням проєктів та
їх прозорістю.
Крім того, інтерфейси досліджуваних web-застосунків не завжди відповідають
сучасним вимогам до юзабіліті. Частина сервісів має перевантажений інтерфейс, у той
час як інші застосунки занадто спрощені, що обмежує можливості користувача.
Таким чином, жоден із аналогів не пропонує комплексного рішення, яке
поєднувало б високу швидкість, гнучкість керування замовленнями та зручний
користувацький інтерфейс. У більшості випадків кабінет користувача виконує
допоміжну функцію, а модуль управління замовленнями не забезпечує повного
контролю над усіма етапами роботи.
Підводячи підсумки, можна з упевненістю сказати, що існує реальний сенс в
розробці web-застосунку Virtual Staging Home з покращеною реалізацією кабінету
22
користувача та модуля управління замовленнями. Існуючі рішення, хоч і є корисними,
та мають недоліки, які можна усунути створивши більш продуманий та
функціональний продукт.
Основними напрямками вдосконалення є:
− розширення функціоналу кабінету користувача;
− впровадження гнучкого та багатофункціонального модуля управління
замовленнями;
− забезпечення прозорої системи статусів, історії змін та відстеження процесу
виконання;
− можливість повторного використання та редагування замовлень;
− покращення інтерфейсу користувача UI/UX та підвищення загальної
зручності взаємодії із системою;
− досягнення балансу між автоматизацією процесів і можливістю
персоналізації результатів.
1.4 Постановка задачі дослідження
У результаті проведеного аналізу предметної області та існуючих web-
застосунків у сфері Virtual Staging було встановлено, що сучасні сервіси справді
забезпечують базові можливості для створення візуалізацій інтер’єрів, проте мають
ряд суттєвих недоліків, пов’язаних із обмеженою функціональністю кабінету
користувача та недостатньо ефективним модулем управління замовленнями.
Зокрема, в більшості розглянутих систем відсутні гнучкі інструменти керування
замовленнями, не реалізовано повноцінну систему відстеження статусів, історії змін
та можливості редагування вже створених замовлень. Крім того, користувацькі
інтерфейси не завжди виконані на достатньому рівні зручності та інтуїтивності, що
ускладнює взаємодію користувача із системою.
Отже, справді існує потреба в розробці web-застосунку з більш досконалим
особистим кабінетом та модулем управління замовленнями. Нове рішення має
поєднати сучасні вимоги до функціональності, зручний інтерфейс та високу
23
швидкість обробки даних.
Метою даної роботи є розробка кабінету користувача та модуля управління
замовленнями web-застосунку «Virtual Staging Home», що забезпечить зручну
взаємодію користувача із системою, ефективне управління замовленнями та
покращений користувацький досвід.
Для досягнення поставленої мети необхідно вирішити такі задачі:
− проаналізувати предметну область галузі Virtual Staging;
− провести огляд та аналіз існуючих web-застосунків;
− визначити функціональні можливості та недоліки аналогів;
− сформувати вимоги до майбутнього web-застосунку;
− спроєктувати архітектуру web-застосунку;
− розробити структуру бази даних;
− реалізувати кабінет користувача;
− реалізувати модуль управління замовленнями;
− провести тестування розробленого web-застосунку;
− проаналізувати результати роботи web-застосунку.
Висновки до розділу 1
У першому розділі було проаналізовано предметну область галузі Virtual
Staging. Проведений порівняльний аналіз показав, що дана галузь є перспективною та
активно розвивається завдяки використанню сучасних web-технологій. Встановлено,
що віртуальний стейджинг робить нерухомість привабливішою для покупців,
спрощує презентацію об’єктів і допомагає швидше зацікавити потенційних клієнтів.
У ході дослідження було виконано огляд існуючих web-сервісів та платформ,
зокрема: BoxBrownie.com, Virtual Staging AI та Stucco.com. Проведений аналіз
показав, що розглянуті аналоги реалізують основні функції віртуального стейджингу,
проте відрізняються підходами до обробки замовлень та організацією взаємодії з
користувачем.
Було визначено основні функціональні можливості цих рішень: завантаження
24
зображень, вибір стилю інтер’єру, формування та обробка замовлень, використання
кабінету користувача.
Разом з тим, було виявлено ряд спільних недоліків, зокрема, обмежену
функціональність кабінету користувача, недостатньо можливостей для управління
замовленнями, відсутність системи статусів і історії змін, а також недосконалість
користувацького інтерфейсу.
Порівняльний аналіз показав, що жоден із розглянутих аналогів не забезпечує
комплексного рішення, яке б поєднувало високу швидкість обробки, зручний кабінет
користувача, багатофункціональний модуль управління замовленнями та достатній
рівень персоналізації результатів.
На основі отриманих результатів було сформовано постановку задачі
дослідження. Вона полягає в розробці web-застосунку «Virtual Staging Home» з
удосконаленим кабінетом користувача та модулем управління замовленнями, що
оптимізує ефективность взаємодії користувача із системою та покращить загальний
користувацький досвід.
25
2 ПРОЄКТУВАННЯ WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
2.1 Визначення вимог до розробки кабінету користувача та модуля
управління замовленнями web-застосунку «Virtual Staging Home»
Перед початком проєктування web-застосунку «Virtual Staging Home» було
сформовано перелік функціональних та нефункціональні вимоги до системи. Цей
етап є важливим для розробки ПЗ, оскільки дозволяє визначити основні можливості
майбутньої системи, забезпечити її відповідність потребам користувачів та створити
основу для подальшого проєктування архітектури й реалізації функціоналу.
Основна увага при розробці приділяється реалізації кабінету користувача та
модуля управління замовленнями, які гарантують ефективну взаємодію користувача
із системою, контроль життєвого циклу замовлень та зручне управління даними.
Додатковими складовими web-застосунку є система авторизації та головна сторінка,
які забезпечують первинний доступ до сервісу.
Web-застосунок «Virtual Staging Home» повинен забезпечувати реалізацію
наступних функціональних можливостей:
− доступ користувача до особистого кабінету;
− створення та управління замовленнями на віртуальний стейджинг;
− перегляд історії замовлень;
− відстеження статусу виконання замовлень;
− редагування параметрів замовлення;
− завантаження та зберігання зображень приміщень;
− отримання готових результатів обробки;
− асинхронну обробку довготривалих операцій;
− обробку помилок та повідомлення користувача про стан виконання
операцій;
− реєстрацію та авторизацію користувачів;
− підтримку автентифікації із використанням JWT токенів;
− взаємодію між frontend та backend компонентами через API.
26
До нефункціональних вимог web-застосунку належать вимоги щодо якості
роботи системи та особливостей її реалізації. Система повинна забезпечувати:
− високу продуктивність та швидкість обробки запитів;
− масштабованість архітектури для можливого розширення функціоналу;
− стабільну роботу при одночасній взаємодії великої кількості користувачів;
− безпечне зберігання та передачу даних користувачів;
− захист API та механізмів авторизації;
− ізоляцію бізнес-компонентів системи;
− надійне зберігання файлів та метаданих;
− зручний та інтуїтивно зрозумілий інтерфейс користувача;
− можливість подальшого супроводу та модернізації системи.
Особлива увага при проєктуванні системи приділяється забезпеченню
гнучкості архітектури, ефективному управлінню замовленнями та оптимізації
взаємодії користувача із web-застосунком. Для цього використовується
мікросервісний підхід, асинхронна обробка даних та централізоване управління
станами замовлень.
Таким чином, визначені функціональні та нефункціональні вимоги формують
основу для подальшого проєктування архітектури web-застосунку «Virtual Staging
Home» та реалізації його основних компонентів.
2.2 Розробка загальної архітектури web-застосунку
Проєктування архітектури web-застосунку є одним із ключових етапів розробки
програмного забезпечення. Оскільки основними функціональними компонентами
застосунку є кабінет користувача та модуль управління замовленнями, архітектура
має вирішувати одразу кілька завдань: витримувати навантаження при великій
кількості одночасних запитів, коректно працювати з асинхронними процесами,
ефективну, ефективна робота з файлами та можливість подальшого розширення
функціоналу системи.
Для втілення поставлених завдань було обрано підхід розподіленої
27
мікросервісної архітектури. Такий підхід дає змогу розділити систему на незалежні
компоненти, кожен із яких відповідає за окрему бізнес-функцію. Це спрощує
підтримку системи, забезпечує ізоляцію обов’язків та дозволяє незалежно
масштабувати окремі модулі системи.
Основною метою побудови архітектури є забезпечення таких ключових
властивостей:
− масштабованості системи;
− ізоляції бізнес-компонентів (відокремленості логіки кожного сервісу для
мінімізації зв’язності);
− гнучкого управління життєвим циклом замовлення;
− ефективної роботи з файлами та зображеннями;
− надійного зберігання даних;
− зручної взаємодії між frontend та backend компонентами.
Архітектура web-застосунку побудована навколо принципів розділення
відповідальностей, асинхронної взаємодії сервісів та централізованого управління
станами замовлень.
2.2.1 Загальна структура системи. Розроблена система організована у вигляді
семи логічних рівнів, кожний з яких виконує окремі функції та взаємодіє з іншими
через чітко визначені інтерфейси. Така ієрархічна структура відповідає принципу
поділу відповідальностей (Separation of Concerns) та дозволяє незалежно змінювавти
кожен рівень без впливу на решту системи.
Архітектура включає наступні логічні рівні:
− рівень доступу (NGINX);
− клієнтський рівень (Frontend);
− рівень автентифікації (Security Service);
− рівень бізнес-логіки (Orchestrator Service);
− рівень роботи з файлами (Asset Manager Service);
− рівень асинхронної обробки (Workers);
− рівень зберігання даних (PostgreSQL, Redis, AWS S3).
28
2.2.2 Детальний опис компонентів системи. Кожен компонент системи
відіграє чітко визначену роль у загальній архітектурі. Нижче наведено детальний опис
функціональних обов’язків, технологій та принципів роботи кожного з них.
NGINX (Gateway Layer):
NGINX виконує роль єдиного вхідного шлюзу до системи. Усі запити від
клієнтів, незалежно від їх типу та призначення, проходять через нього. Основними
задачами даного компонента є маршрутизація HTTP-запитів до відповідних сервісів,
балансування навантаження та оптимізація мережевої взаємодії.
Крім того, NGINX дозволяє централізувати обробку HTTPS-з’єднань (TLS
termination), що спрощує налаштування безпеки та зменшує навантаження на інші
компоненти системи. Також даний компонент може використовуватися для
кешування окремих відповідей та базової оптимізації мережевої взаємодії.
Frontend (Angular 18 + NgRx):
Клієнтська частина реалізована у вигляді Single Page Application (SPA) на базі
фреймворку Angular 18. SPA-підхід означає, що браузер завантажує застосунок один
раз, а подальша навігація між розділами відбувається без перезавантаження сторінки
завдяки клієнтській маршрутизації. Це забезпечує плавний досвід взаємодії.
Frontend відповідає за взаємодію користувача із системою та забезпечує роботу
основних функціональних модулів, зокрема:
− головної сторінки web-застосунку;
− системи авторизації та реєстрації;
− кабінету користувача;
− модуля управління замовленнями;
− перегляду статусів та результатів обробки.
Для управління станом застосунку використовується бібліотека NgRx, яка
реалізує патерн Redux. Застосування NgRx забезпечує централізоване управління
станом даних, що особливо важливо для роботи зі складними сценаріями управління
замовленнями.
29
Security Service (Рівень автентифікації):
Security Service відповідає за автентифікацію користувачів та управління
сесіями. При успішному вході в систему сервіс генерує JWT (JSON Web Token) –
підписаний токен, який містить ідентифікатор користувача, його ролі та термін дії.
Ключовою особливістю є те, що Security Service публікує публічний ключ, який
інші сервіси можуть отримати та використовувати для самостійної валідації токенів.
Це означає, що Orchestrator Service або Asset Manager Service можуть самостійно
перевірити підпис JWT без звернення до Security Service при кожному запиті, що
дозволяє уникнути постійної залежності від сервісу автентифікації та підвищує
загальну стабільність системи.
Виділення механізмів безпеки в окремий сервіс також забезпечує кращу
ізоляцію функціоналу та спрощує масштабування системи автентифікації.
Orchestrator Service (Бізнес-логіка):
Orchestrator Service є центральним компонентом усієї системи. Він реалізує
ядро бізнес-логіки та відповідає за управління повним життєвим циклом замовлення.
Ключовою концепцією є використання патерну State Machine: замовлення у будь-
який момент часу перебуває в одному з визначених станів (наприклад, «створено», «в
обробці», «завершено», «скасовано»), а переходи між станами відбуваються лише за
чітко визначеними правилами при настанні певних подій. Завдяки цьому у будь-який
момент можна визначити поточний стан замовлення та відновити послідовність
подій, які до нього призвели.
Orchestrator Service також забезпечує:
− збереження основної інформації про замовлення;
− взаємодію із сервісом роботи з файлами;
− запуск асинхронної обробки даних;
− контроль виконання довготривалих операцій;
− оновлення статусів замовлень.
30
Asset Manager Service (Управління файлами):
Asset Manager Service відповідає за роботу з файлами та зображеннями, які
використовуються в системі. Даний сервіс абстрагує фізичне файлове сховище та
надає доступ до файлів через унікальні ідентифікатори.
Для оптимізації продуктивності використовується дворівневе кешування: Redis
як первинний швидкісний кеш «ідентифікатор → фізичне розташування», та
PostgreSQL як резервне зберігання метаданих та мапінг файлів. Завдяки цьому
більшість запитів обслуговується з кешу без звернення до основної бази даних.
Такий підхід дозволяє забезпечити ефективну роботу із зображеннями, що є
особливо важливим для систем віртуальної постановки.
Async Workers (Асинхронна обробка):
Workers – це окремі процеси або сервіси, призначені для виконання
довготривалих операцій, які не можна або недоцільно виконувати в рамках
синхронного HTTP-запиту. Типовим прикладом є обробка зображень, зміна розміру,
конвертація формату, генерація результатів тощо. Такі операції можуть тривати від
секунд до хвилин і блокували б весь потік виконання при синхронному підході.
Workers отримують задачі через чергу повідомлень або іншу форму
асинхронної комунікації, виконують їх незалежно від основного потоку та
повідомляють про результат через механізм подій або оновлення стану в базі даних.
Винесення таких задач в окремі асинхронні процеси дозволяє уникнути блокування
основного потоку виконання та підвищує загальну продуктивність системи.
2.2.3 Сховище даних. Для забезпечення ефективної роботи web-застосунку
використовується 3 типи сховищ даних, кожне з яких виконує власну роль у системі.
PostgreSQL використовується як основне реляційне сховище для збереження
інформації про користувачів, замовлення та метадані. Дана система управління
базами даних забезпечує надійність зберігання інформації, підтримку транзакцій та
ефективну роботу зі складними структурами даних.
Redis використовується як високошвидкісний кеш та механізм distributed lock.
Це дозволяє прискорити доступ до часто використовуваних даних та забезпечити
синхронізацію між сервісами.
31
AWS S3 використовується як об’єктне сховище для файлів та зображень. Це
дозволяє ефективно працювати з великим обсягом медіаданих та забезпечує високу
доступність файлів.
Розділення сховищ відповідно до їх призначення забезпечує баланс між
продуктивністю, надійністю та масштабованістю системи.
2.2.4 Архітектурна схема взаємодії. Взаємодія між компонентами системи
організована таким чином, щоб мінімізувати зв’язність між сервісами та забезпечити
чіткий потік даних. На рисунку 2.1 представлена загальна схема архітектурної
взаємодії, яка відображає зв’язки між усіма рівнями системи.
Рисунок 2.1 – Архітектурна схема взаємодії компонентів системи
Представлена схема демонструє взаємодію між користувачем, клієнтською
частиною, backend сервісами та системами зберігання даних. Центральним
компонентом архітектури виступає Orchestrator Service, який координує виконання
32
бізнес-процесів та взаємодію між іншими сервісами. Такий підхід називається
асинхронним патерном і є стандартним рішенням для тривалих операцій у web-
системах.
2.2.5 Принципи побудови архітектури. Архітектура системи побудована на
основі сукупності взаємопов’язаних принципів, кожен із яких вирішує конкретну
проблему розробки та супроводу складних розподілених систем:
− мікросервісна декомпозиція – кожен сервіс відповідає виключно за одну
бізнес-функцію;
− асинхронна обробка довготривалих операцій – усі довготривалі операції
винесені у фонові процеси (Workers);
− state-driven підхід – життєвий цикл замовлення керується через state
machine;
− event-driven взаємодія між компонентами – зміни фіксуються як події для
забезпечення надійності;
− ізоляція даних та відповідальностей – кожен сервіс має власну модель
зберігання даних і не звертається напряму до бази даних іншого сервісу;
− весь зовнішній трафік проходить через NGINX, що спрощує управління
мережевою безпекою, моніторингом та конфігурацією;
− незалежність компонентів системи.
Використання зазначених принципів дає змогу створити гнучку архітектуру,
яка може бути адаптована до подальшого розширення функціоналу та збільшення
навантаження на систему.
Запропонована архітектура забезпечує гнучкість, масштабованість та
надійність системи. Поділ на мікросервіси дозволяє незалежно розвивати окремі
компоненти, а використання асинхронної обробки та state machine забезпечує
контрольований життєвий цикл замовлень.
33
2.3 Проєктування кабінету користувача
Кабінет користувача є одним із ключових компонентів web-застосунку «Virtual
Staging Home», оскільки саме через нього реалізується основна взаємодія користувача
із системою та модулем управління замовленнями. Тому при його проєктуванні
головний акцент робився на тому, щоб інтерфейс був не просто гарним, а справді
зручним — щоб користувач міг швидко знайти потрібний розділ і не витрачав час на
розбір логіки навігації.
За основу архітектури кабінету було взято класичний патерн «бічна навігаційна
панель + робоча область». Такий підхід є стандартом для SaaS-застосунків та
адміністративних панелей, адже забезпечує постійний доступ до навігації незалежно
від поточного розділу.
Бічна навігаційна панель забезпечує швидкий доступ до основних модулів web-
застосунку. У ній розташовані основні навігаційні елементи:
− Dashboard (панель управління);
− My Projects (мої проєкти);
− Projects History (історія проєктів);
− Payment (оплата);
− Notifications (повідомлення);
− Edit Profile (редагувати профіль).
Основна робоча область використовується для відображення актуального
вмісту залежно від вибраного розділу. На головному екрані кабінету користувача
відображається привітальний блок із кнопкою завантаження зображення (Upload
Image), через яку користувач може одразу перейти до створення нового замовлення.
Таким чином, спроєктований кабінет користувача забезпечує централізований
доступ до основних функцій web-застосунку та створює зручне середовище для
управління замовленнями. Завдяки чіткому розділенню інтерфейсу на функціональні
зони користувач одразу розуміє, де що знаходиться – а це напряму впливає на
зручність роботи з системою та загальний досвід взаємодії з платформою.
Загальна структура кабінету користувача представлена на рисунку 2.2.
34
Рисунок 2.2 – Структура кабінету користувача web-застосунку «Virtual Staging
Home»
2.4 Проєктування модуля управління замовленнями
Модуль управління замовленнями – це центр кабінету користувача web-
застосунку «Virtual Staging Home», адже саме тут відбувається вся основна бізнес-
взаємодія між клієнтом і сервісом. З точки зору проєктування модуль поділяється на
дві незалежні, але логічно пов’язані частини: перегляд наявних замовлень із
можливістю фільтрації і створення нового замовлення у форматі покрокового
майстра.
Розділ «My Projects» відповідає за перегляд усіх замовлень. На рівні
проєктування він вирішує задачу навігації у великому списку проєктів, надаючи
користувачу список фільтрів. Для цього передбачено одразу кілька інструментів
фільтрації: за ідентифікатором замовлення, фільтр за статусом (Pending, In progress,
Completed), фільтр за кількістю фотографій та фільтр за стилем оформлення.
Наявність одночасно кількох фільтрів зумовлена природою сервісу: клієнт, який
регулярно користується платформою, може мати десятки замовлень у різних станах,
і без зручних інструментів пошуку знайти потрібний проєкт у такому списку було б
справжньою проблемою.
Створення нового замовлення реалізовано у вигляді покрокового майстра
(wizard) з трьох етапів. Прогрес-індикатор у верхній частині екрана постійно показує
35
поточний крок і загальну кількість кроків, що усуває невизначеність щодо тривалості
процесу.
Структурна схема модуля управління замовленнями наведена на рис. 2.3.
Рисунок 2.3 – Структурна схема модуля управління замовленнями
Перший крок – вибір стилю меблювання. Користувач обирає загальний стиль
для всього замовлення з доступних варіантів: Transitional, Modern, Scandinavian,
Classic і т.д.
Другий крок – завантаження фотографій. Для кожної фотографії окремо
вказується файл, функція та тип кімнати, стиль меблювання (який може відрізнятися
від загального) та текстовий коментар із конкретними побажаннями до обробки.
Також тут передбачається можливість додати довільну кількість фото через кнопку,
що забезпечує гнучкість щодо обсягу замовлення.
Третій крок – додаткова інформація. На цьому етапі клієнт може залишити
загальні інструкції для команди дизайнерів, що стосуються всього замовлення в
36
цілому. Після натискання кнопки підтвердження система засвідчує прийом
замовлення екраном успіху з можливістю повернутись до списку проєктів. Екран
підтвердження виконує важливу психологічну функцію: він дає користувачу відчуття
завершеності дії та знімає невизначеність щодо того, чи було замовлення дійсно
відправлено.
2.5 Проєктування системи авторизації користувачів
Система авторизації є одним із фундаментальних компонентів web-застосунку
«Virtual Staging Home», оскільки саме вона контролює доступ до особистого кабінету
користувача та модулю управління замовленнями. Для цього в роботі реалізовано
багатокроковий процес створення облікового запису, який дозволяє поступово
виконувати необхідні етапи реєстрації та зменшує навантаження на користувача під
час першої взаємодії із системою.
Для досягнення балансу між цими вимогами було обрано триетапну модель
реєстрації з підтвердженням електронної пошти.
Перший етап – ініціювання реєстрації. На цьому кроці користувачу
пропонується обрати один із двох шляхів: зареєструватись через обліковий запис
стороннього провайдера (Apple або Google) або ввести власну адресу електронної
пошти вручну. Також на даному етапі передбачено можливість переходу до сторінки
входу в web-застосунок за допомогою кнопки «Have an account? Log in», що
забезпечить зручну навігацію між процесами реєстрації та авторизації.
Другий етап – підтвердження електронної пошти. Після введення адреси
система надсилає на неї листа з унікальним посиланням для підтвердження.
Передбачено також механізм повторного надсилання листа, оскільки листи
підтвердження можуть затримуватись або потрапляти до папки зі спамом.
Після успішного підтвердження електронної адреси користувач переходить до
третього етапу – заповнення профілю. Тут користувачу пропонується ввести повне
ім’я та встановити пароль для входу в систему. Після вдалого створення акаунту
користувач автоматично проходить автентифікацію та перенаправляється до свого
особистого кабінету.
37
Загалом спроєктована триетапна система авторизації вирішує одразу два
завдання: надійний захист від несанкціонованої реєстрації та зручний і зрозумілий
процес для звичайного користувача. Додаткова підтримка входу через Apple та
Google відповідає очікуванням сучасної аудиторії та скорочує час, необхідний для
початку роботи з застосунком.
Загальна схема процесу реєстрації та авторизації користувача представлена на
рисунку 2.4.
Рисунок 2.4 – Схема триетапного процесу реєстрації користувача
2.6 Проєктування інтерфейсу користувача
Одним із важливих етапів розробки стало проєктування інтерфейсу
користувача (UI/UX) та формування загальної концепції. Оскільки основною задачею
web-застосунку є робота із візуальним контентом та управління замовленнями,
38
особлива увага приділялася створенню сучасного, мінімалістичного та простого
інтерфейсу.
Для web-застосунку «Virtual Staging Home» було обрано нейтральні, переважно
світлі відтінки з контрастними темними акцентами. Основною задачею такої
кольорової схеми є забезпечення хорошого візуального сприйняття контенту та
концентрації уваги користувача на функціональних елементах системи.
Приклад використаної кольорової палітри представлений на рисунку 2.5.
Рисунок 2.5 – Приклад використаної кольорової палітри
Важливою складовою UI/UX дизайну є типографіка, оскільки саме вона формує
візуальну структуру інтерфейсу та впливає на сприйняття інформації. Текстові
елементи інтерфейсу повинні мати достатній рівень контрастності та оптимальний
розмір для забезпечення комфортного читання. Приклад використаної типографіки
представлений на рисунку 2.6.
Рисунок 2.6 – Приклад використаної типографіки
39
Для покращення користувацького досвіду в інтерфейсі також
використовуються інтерактивні елементи, зокрема:
− кнопки із hover-ефектами;
− плавні анімації переходів;
− інтерактивні картки;
− елементи порівняння зображень Before/After та відеоанімації;
− динамічні компоненти навігації.
Використання таких елементів дозволяє зробити взаємодію із web-застосунком більш
зрозумілою та візуально привабливою.
Окрім основних інтерфейсів системи, було додатково передбачено реалізацію
головної сторінки web-застосунку «Virtual Staging Home». Головна сторінка є першою
точкою контакту потенційного клієнта із сервісом, тому її проєктування
підпорядковане єдиній меті – максимально швидко і переконливо донести
пропозицію продукту та спонукати відвідувача до цільової дії.
Оскільки web-застосунок «Virtual Staging Home» орієнтований на сферу
віртуальної постановки та роботу із візуальним контентом, важливою складовою є
використання великої кількості графічних елементів, прикладів робіт та демонстрацій
результатів обробки інтер’єрів.
Головна сторінка web-застосунку «Virtual Staging Home» спроєктована за
принципом односторінкової структури із послідовним розташуванням інформаційних
блоків. Структура головної сторінки web-застосунку включає наступні основні
компоненти:
− навігаційну панель;
− презентаційний (hero) блок;
− блок демонстрації принципу роботи сервісу;
− секцію прикладів реалізованих проєктів;
− інформаційний блок зі статистикою сервісу;
− секцію доступних послуг;
− нижню частину сторінки (footer).
40
Таким чином, спроєктована головна сторінка забезпечує зручну навігацію. Її
структура орієнтована на швидке ознайомлення користувача із функціоналом web-
застосунку та подальший перехід до роботи із кабінетом користувача та модулем
управління замовленнями.
Загальна структура головної сторінки web-застосунку представлена на рис. 2.7.
Рисунок 2.7 – Структура головної сторінки web-застосунку «Virtual Staging Home»
Проєктування головної сторінки здійснювалося з урахуванням загальних
принципів UI/UX дизайну та не є центральним елементом системи.
Таким чином, спроєктований інтерфейс користувача гарантує зручну взаємодію
із web-застосунком «Virtual Staging Home», підтримує сучасний стиль дизайну та
створює позитивний користувацький досвід. Використання мінімалістичного
підходу, адаптивної структури та зрозумілої візуальної ієрархії спрощує управління
замовленнями у web-застосунку «Virtual Staging Home».
Висновки до розділу 2
У другому розділі виконано проєктування web-застосунку «Virtual Staging
Home» та визначено основні принципи побудови його архітектури, інтерфейсу й
функціональних компонентів. Центральними об'єктами проєктування стали кабінет
користувача та модуль управління замовленнями, оскільки саме вони забезпечують
основну взаємодію користувача з платформою.
На початковому етапі було визначено функціональні та нефункціональні
вимоги до системи, що дало змогу стабільну основу для подальших рішень.
41
Встановлено основні функції web-застосунку, серед яких: управління замовленнями,
робота із зображеннями, перегляд історії проєктів, контроль статусів обробки та
взаємодія користувача із сервісом через особистий кабінет.
Розроблено загальну архітектуру web-застосунку на основі мікросервісного
підходу. Це забезпечує ізоляцію бізнес-компонентів, можливість їх незалежного
масштабування та підтримку асинхронної обробки довготривалих операцій.
Центральне місце в архітектурі займає модуль управління замовленнями, який
реалізує основну логіку системи та контролює життєвий цикл замовлень.
Окремо спроєктовано систему авторизації з багатокроковим процесом
реєстрації, яка забезпечує безпечний і водночас зручний доступ до функціоналу
платформи.
Додатково приділено увагу проєктуванню головної сторінки та інтерфейсу
користувача. При розробці UI/UX використано принципи мінімалізму та інтуїтивної
навігації, що дозволяє користувачу швидко освоїтися в системі без зайвих пояснень.
Таким чином, за результатами другого розділу сформовано цілісну структуру
web-застосунку «Virtual Staging Home», яка створює готову основу для подальшої
реалізації кабінету користувача, модуля управління замовленнями та інших
допоміжних компонентів системи.
42
3 РОЗРОБКА, РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ WEB-ЗАСТОСУНКУ
«VIRTUAL STAGING HOME»
3.1 Основний workflow web-застосунку
Основний workflow web-застосунку «Virtual Staging Home» описує повний
життєвий цикл обробки замовлення – від моменту створення користувачем до
отримання фінального результату. Даний процес охоплює взаємодію між клієнтською
частиною web-застосунку, backend сервісами, файловим сховищем та асинхронними
модулями обробки даних.
Workflow системи є однією з ключових складових реалізованого web-
застосунку, оскільки саме він забезпечує координацію роботи всіх компонентів
архітектури та керує послідовністю виконання основних бізнес-процесів.
Діаграма послідовності основного workflow web-застосунку представлена на
рисунку 3.1.
Рисунок 3.1 – Діаграма послідовності основного workflow web-застосунку
43
З архітектурної точки зору workflow побудований на двох фундаментальних
концепціях. Перша – State Machine: замовлення протягом свого життєвого циклу
проходить через чітко визначену послідовність станів, і кожен перехід між ними є
визначеним та контрольованим. Друга – асинхронна обробка даних: найважча з
обчислювальної точки зору операція виконується у фоновому режимі окремими
Worker-процесами, завдяки чому інтерфейс користувача не блокується на час
виконання тривалих операцій і система не втрачає своєї продуктивності.
Процес розпочинається з автентифікації користувача. Коли клієнт вводить
облікові дані в застосунку, то запит на перевірку передається до Security Service. Цей
сервіс валідує надані дані, і у разі успіху генерує та повертає JWT-токен (JSON Web
Token), який використовується для подальших запитів до системи. Такий підхід
дозволяє реалізувати безпечну автентифікацію та забезпечує захищений доступ до
функціоналу web-застосунку.
Після проходження авторизації, користувач отримує доступ до кабінету
користувача та може створити нове замовлення через модуль управління
замовленнями. Запит на створення замовлення надходить із Frontend до Orchestrator
Service, який виконує роль центрального координатора бізнес-логіки системи.
Під час створення замовлення Orchestrator Service:
− створює новий запис у базі даних;
− генерує унікальний ідентифікатор замовлення (orderId);
− встановлює початковий стан замовлення CREATED;
− зберігає основні метадані замовлення.
Стан CREATED означає, що замовлення було успішно створене, однак файли для
подальшої обробки ще не завантажені.
Отримавши orderId, система переходить до наступного кроку – завантаження
файлів зображень. Запити на завантаження надходять безпосередньо до Asset Manager
Service, оминаючи Orchestrator, що відповідає принципу єдиної відповідальності:
Orchestrator керує бізнес-логікою, тоді як Asset Manager відповідає виключно за
операції з файлами.
44
Asset Manager Service виконує наступні функції:
− приймає файли від користувача;
− зберігає зображення у сховищі AWS S3 або локальному середовищі;
− генерує унікальні fileId для кожного файлу;
− зберігає мапінг між fileId та фізичним шляхом до файлу;
− забезпечує абстракцію файлового сховища для інших сервісів системи.
Після завершення процесу завантаження файлів Orchestrator Service оновлює
стан замовлення до UPLOADED. Цей стан означає, що всі необхідні файли успішно
отримані системою та замовлення готове до подальшої обробки.
Наступним етапом workflow є запуск асинхронної обробки даних. Для цього
Orchestrator Service ініціює виконання задачі через Async Workers. Воркери
виконують обробку зображень у фоновому режимі без блокування основного потоку
виконання системи. Асинхронна обробка включає:
− аналіз вхідних зображень;
− генерацію проміжних та фінальних результатів;
− підготовку метаданих обробки;
− оновлення інформації про стан замовлення.
Використання асинхронної моделі дозволяє значно покращити продуктивність
системи та забезпечує стабільну роботу web-застосунку навіть при виконанні
довготривалих операцій обробки зображень.
У процесі виконання Workers поступово оновлюють стан замовлення в базі
даних. Це озволяє відображати прогрес у реальному часі. Основними станами
обробки є:
1) PROCESSING – активна обробка замовлення;
2) PARTIAL_READY – частина результатів уже доступна користувачу;
3) READY – повне завершення обробки;
4) FAILED – виникнення помилки під час виконання workflow.
Стан PARTIAL_READY сигналізує про те, що частина зображень вже
оброблена та доступна для перегляду або завантаження, тоді як обробка решти файлів
ще триває. Підтримка цього стану є важливою UX-оптимізацією адже покращує
45
користувацький досвід та дозволяє швидше взаємодіяти із результатами роботи
системи.
Після завершення всіх етапів обробки Async Workers передають інформацію
про результати до Orchestrator Service, який оновлює стан замовлення у базі даних.
Якщо обробка виконана успішно, система переводить замовлення у стан READY та
формує повний набір результатів для користувача. У випадку виникнення помилки
workflow переходить у стан FAILED. Це дозволяє системі коректно обробляти
помилки та забезпечує контрольований життєвий цикл замовлення.
Для отримання актуальної інформації про стан замовлення Frontend періодично
виконує polling-запити до Orchestrator Service. При кожному такому запиті
Orchestrator зчитує поточний стан із бази даних та повертає його разом із доступними
на цей момент результатами. Завдяки цьому прогрес обробки відображається
користувачу динамічно в реальному часі та без необхідності повторного
завантаження сторінки.
Підсумовуючи, workflow системи реалізує п’ять ключових архітектурних
принципів:
1) асинхронність – обробка файлів не блокує користувацький інтерфейс;
2) state machine контроль – всі переходи між станами є явно визначеними і не
допускають обходу або пропускання проміжних кроків;
3) еvent-driven взаємодія – кожна зміна стану фіксується як подія, що може
ініціювати додаткові дії (наприклад, надсилання сповіщення);
4) поступова доставка результатів – підтримка PARTIAL_READY стану;
5) ізоляція сервісів – кожен компонент відповідає виключно за свою частину
процесу.
Таким чином, реалізований workflow охоплює повний цикл обробки замовлення
у web-застосунку «Virtual Staging Home» – від моменту створення користувачем до
отримання фінального результату. Поєднання state machine, асинхронної обробки та
мікросервісної архітектури дозволило побудувати систему, яка справляється з
навантаженням стабільно і передбачувано.
46
3.2 Розробка клієнтської (фронтенд) частини web-застосунку
Фронтенд частина web-застосунку «Virtual Staging Home» реалізує клієнтський
рівень взаємодії користувача з бекенд-сервісами та забезпечує формування,
відстеження й відображення стану замовлень. Основною метою фронтенд-
архітектури є забезпечення зручного користувацького інтерфейсу, контрольованого
керування станом застосунку та надійної взаємодії з серверною частиною. Клієнтська
частина є єдиним каналом комунікації між користувачем та бізнес-логікою системи,
тому від якості її реалізації безпосередньо залежить загальне враження від продукту.
Клієнтська частина реалізована як Single Page Application (SPA) –
односторінковий web-застосунок, що завантажується браузером один раз і надалі
функціонує без повного перезавантаження сторінки.
Основними функціями фронтенд частини є:
− автентифікація користувача;
− створення та управління замовленнями;
− завантаження зображень;
− відображення поточного стану обробки замовлення;
− перегляд результатів обробки;
− асинхронна взаємодія із backend сервісами через API;
− оновлення даних у режимі реального часу.
Для реалізації фронтенду використовувався сучасний стек технологій, який
забезпечує модульність, типізацію та підтримку реактивного програмування:
− Angular 18 – основна технологія розробки, яка використовується як
головний framework для побудови інтерфейсу web-застосунку;
− NgRx – бібліотека для централізованого управління станом застосунку, що
спрощує керування складною асинхронною логікою;
− RxJS – використовується для роботи із потоками асинхронних даних та
реалізації реактивного програмування;
− TypeScript – мова програмування клієнтської частини, яка забезпечує
статичну типізацію.
47
Архітектура фронтенду побудована за принципом розділення
відповідальностей та односпрямованого потоку даних. Ці два принципи разом
визначають чіткі правила: який шар відповідає за відображення, який за бізнес-логіку
і який за взаємодію з сервером. Таке розмежування робить кодову базу
передбачуваною: при виникненні помилки або необхідності внесення змін розробник
одразу знає, в якому саме шарі шукати відповідний код.
Основними рівнями фронтенд архітектури є:
− Presentation Layer (Components) – рівень відображення користувацького
інтерфейсу;
− State Management Layer (NgRx Store) – централізоване управління станом
застосунку;
− Effects Layer – реалізація асинхронної логіки та API-запитів;
− Service Layer – взаємодія із backend сервісами через HTTP API.
Для управління станом web-застосунку «Virtual Staging Home»
використовується NgRx Store. Ідея полягає в тому, що весь стан застосунку
зберігається в єдиному незмінному об’єкті (Store), а будь-яка його зміна відбувається
виключно через відправку Actions – простих об'єктів-описів того, що сталось.
Reducers – чисті функції без побічних ефектів – отримують Action та повертають
новий стан. Завдяки цьому кожна зміна стану є явною та відтворюваною. А сам стан
web-застосунку поділяється на декілька доменів: стан автентифікації, стан замовлень,
стан завантажених файлів, стан обробки.
Основний workflow фронтенд частини web-застосунку представлений на
рисунку 3.2. Взаємодія фронтенду з серверною частиною здійснюється виключно
через REST API. Основними типами API-запитів є:
− авторизація користувача;
− створення замовлення;
− завантаження файлів;
− отримання статусу замовлення;
− отримання результатів обробки.
48
Рисунок 3.2 – Основний workflow фронтенд частини web-застосунку
Усі HTTP-запити виконуються із використанням JWT токена для захищеної
взаємодії із бекендом системи, а вся асинхронна логіка фронтенду реалізована через
NgRx Effects, які є реактивними обробниками подій.
Оскільки обробка замовлень є довготривалою операцією, для відстеження її
прогресу реалізовано механізм polling. Тому, фронтенд періодично надсилає запити
до backend API для отримання актуального стану замовлення.
Polling-механізм забезпечує:
− періодичну перевірку статусу замовлення;
49
− динамічне оновлення інтерфейсу;
− відображення прогресу обробки у режимі реального часу.
Також Polling автоматично припиняється після переходу замовлення у фінальний
стан READY або FAILED.
Безпека фронтенду базується на коректному управлінні JWT-токенами. Токен
зберігається на клієнтській стороні і автоматично додається до кожного вихідного
HTTP-запиту. Перевірка токена відбувається на стороні бекенду при кожному запиті.
Security Service або окремі мікросервіси валідують підпис і термін дії токена: якщо
токен протермінований, користувач автоматично перенаправляється на сторінку
авторизації, а Auth State очищається.
Таким чином, реалізована клієнтська частина web-застосунку «Virtual Staging
Home» забезпечує ефективну взаємодію користувача із бекенд сервісами, підтримує
стабільну асинхронну обробку даних та створює основу для роботи кабінету
користувача й модуля управління замовленнями. Поєднання Angular 18, NgRx, RxJS
та TypeScript забезпечує структуровану, передбачувану та легко підтримувану кодову
базу.
3.3 Розробка серверної (бекенд) частини web-застосунку
Бекенд частина web-застосунку реалізує серверний рівень обробки даних,
бізнес-логіки та координації взаємодії між мікросервісами. Основною задачею
бекенду є забезпечення повного життєвого циклу (ЖЦ) замовлення. Крім того, бекенд
відповідає за асинхронну обробку даних, надійну роботи з файлами та зовнішніми
сховищами. Архітектура побудована на принципах мікросервісного підходу, де
кожен сервіс є незалежним компонентом із власною чітко визначеною зоною
відповідальності.
Реалізована backend архітектура складається з чотирьох основних сервісів:
1) Orchestrator Service – центральний координаційним сервіс, що реалізує
бізнес-логіку та управляє станом замовлень;
2) Asset Manager Service – відповідає виключно за операції з файлами;
50
3) Security Service – забезпечує автентифікацію та авторизацію, генеруючи та
валідуючи JWT-токени;
4) Async Workers – сервіси асинхронної обробки даних, що виконують
ресурсомісткі фонові операції, не блокуючи жоден з API-сервісів.
Технологічно сервіс реалізовано на базі Spring Boot, а як основне сховище даних
використовується PostgreSQL.
Ключовим механізмом в основі Orchestrator Service є state machine, який керує
життєвим циклом кожного замовлення. Такий підхід забезпечує суворий контроль
над переходами між станами замовлення. Кожен перехід фіксується у базі даних
разом із часовою міткою та ідентифікатором ініціатора зміни. В результаті
формується журнал, за яким можна простежити хронологію подій для будь-якого
замовлення. Схема state machine замовлення представлена на рисунку 3.3.
Рисунок 3.3 – State machine життєвого циклу замовлення
Після створення замовлення система переводить його у стан CREATED, після
чого користувач може завантажити необхідні файли. Після завершення завантаження
система переходить у стан UPLOADED та ініціює асинхронну обробку даних.
У процесі замовлення переходить через стани PROCESSING,
PARTIAL_READY та READY. У випадку помилки система переводить замовлення у
51
стан FAILED, що дозволяє коректно завершити процес обробки та забезпечити
контроль помилок.
Для роботи із файлами реалізовано окремий Asset Manager Service. Його
основною задачею є ізоляція файлової логіки від інших компонентів системи та
забезпечення абстракції файлового сховища. Основними функціями Asset Manager
Service є:
− завантаження та збереження файлів;
− генерація унікальних fileId;
− приховування фізичних шляхів до файлів;
− інтеграція із AWS S3 або локальним файловим середовищем;
− управління доступом до файлів.
Для оптимізації роботи з даними застосовується Redis як механізм кешування та
реалізації distributed lock, а PostgreSQL слугує резервним сховищем маппінгу.
Розподілений механізм блокування використовується для запобігання
одночасній зміні стану одного замовлення кількома процесами. Це дозволяє уникнути
race condition та гарантує консистентність даних під час виконання асинхронних
операцій. Принцип роботи полягає у трьох кроках. Перед початком будь-якої операції
зміни стану замовлення сервіс намагається отримати ексклюзивне блокування за
ключем, що містить orderId з обмеженим TTL (часом існування). Якщо блокування
отримане успішно – операція виконується і стан оновлюється. Після завершення
операції блокування знімається. Якщо інший процес вже тримує блокування по цьому
orderId – поточний процес або чекає, або повертає помилку доступу. TTL на
блокуванні гарантує, що навіть у разі аварійного завершення процесу, воно
автоматично звільниться через визначений час і система не заблокується назавжди.
Важливою складовою бекенд архітектури є Security Service, який відповідає за
автентифікацію користувачів. Його основна задача – генерація та перевірка JWT-
токенів, що використовуються для захищеної взаємодії між компонентами системи.
Завдяки цьому Orchestrator та Asset Manager можуть самостійно перевіряти підпис та
актуальність JWT-токена при кожному вхідному запиті, не звертаючись до SS. По
суті, це усуває Security Service як потенційну єдину точку відмови у процесі перевірки
52
авторизації: навіть якщо Security Service тимчасово недоступний, вже видані токени
продовжують валідуватись іншими сервісами, і користувачі не втрачають доступ до
системи.
Для виконання довготривалих процесів у системі використовуються Async
Workers. Воркери працюють асинхронно та виконують задачі обробки зображень
незалежно від основного потоку виконання системи.
У системі також реалізований event-driven підхід із використанням спрощеної
моделі подій (event sourcing light), яка передбачає фіксацію кожної значущої зміни
стану у вигляді окремо записаної події. Основними подіями системи є:
− OrderCreated;
− FilesRegistered;
− ProcessingStarted;
− ImageProcessed;
− OrderCompleted;
− OrderFailed.
Для досягнення балансу між продуктивністю, надійністю та масштабованістю
бекенд використовує три спеціалізованих типи сховищ відповідно до характеристик
даних, що в них зберігаються:
− PostgreSQL – основне реляційне сховище даних (замовлення, метадані
файлів, дані користувачів, журнал подій, маппінг);
− Redis – кешування та distributed lock механізм;
− AWS S3 – об’єктне сховище для файлів і зображень.
Таким чином, бекенд частина системи реалізує повноцінний серверний рівень
із чітким розподілом обов’язків між чотирма незалежними компонентами.
Orchestrator Service контролює життєвий цикл замовлення. Asset Manager абстрагує
фізичне зберігання файлів. Security Service втілює децентралізовану валідацію
токенів. Async Workers забезпечують масштабовану фонову обробку без блокування
API. Разом ці рішення формують надійну, масштабовану та підтримувану серверну
архітектуру.
У межах реалізації клієнтської частини web-застосунку також було створено
53
головну сторінку web-застосунку «Virtual Staging Home». Загальний вигляд головної
сторінки представлений на рисунку 3.4. Вона реалізована як додатковий компонент
системи. Її основне призначення – ознайомити потенційного клієнта з послугами
сервісу.
Рисунок 3.4 – Головна сторінка web-застосунку «Virtual Staging Home»
Сторінка складається з кількох послідовних секцій. Верхня частина (hero-
секція) містить заголовок, короткий опис сервісу, кнопку «Get Started» та
інтерактивний слайдер із прикладами робіт у форматі «до / після», який наочно
демонструє результат стейджингу.
Нижче секція «How it Works» із поясненням процесу роботи в три кроки – від
реєстрації до отримання готових зображень. Секція «Our Projects» показує приклади
виконаних робіт із фільтрацією за типом кімнати та стилем дизайну. Далі розміщено
54
блок із ключовими показниками компанії та секція «Services». Сторінку завершує
footer з навігаційними посиланнями та контактами.
3.4 Реалізація кабінету користувача
Кабінет користувача є центральним інтерфейсом застосунку «Virtual Staging
Home», адже саме через нього реалізується основна взаємодія користувача із
системою після проходження авторизації. Вигляд реалізованого кабінету користувача
представлений на рисунку 3.5.
Рисунок 3.5 – Реалізований інтерфейс кабінету користувача
Кабінет надає доступ до функціоналу управління замовленнями, перегляду
історії проєктів, налаштування профілю та отримання повідомлень.
При реалізації кабінету користувача основна увага зосереджувалася на
створенні зрозумілого інтерфейсу, швидкої навігації між функціональними блоками
та зручної взаємодії із системою. Інтерфейс побудований за принципами
55
мінімалістичного UI/UX дизайну.Завдяки цьому користувач миттєво орієнтується в
структурі web-застосунку та може виконувати потрібні дії без зайвих кроків.
Структурною основою інтерфейсу є фіксована бокова навігаційна панель
(sidebar), розташована у лівій частині екрану. Вона забезпечує швидкий доступ до
основних функціональних модулів системи та містить:
− логотип web-застосунку;
− навігацію між сторінками;
− блок сповіщень;
− налаштування профілю;
− інформацію про авторизованого користувача.
Компонент відображає навігаційне меню, розбите на дві логічні групи. Верхня
група містить основні робочі розділи:
− Dashboard;
− My Projects;
− Projects History;
− Payment.
Нижня група містить допоміжні налаштування акаунту: Notifications із
лічильником непрочитаних повідомлень, Edit Profile та блок поточного користувача з
іменем, аватаром і кнопкою виходу.
Розділ Dashboard є головною сторінкою кабінету користувача та виконує роль
центральної точки взаємодії із системою. У центрі інтерфейсу реалізовано
привітальний блок із коротким інформаційним повідомленням та кнопкою «Upload
Image», щоб швидко перейти до створення нового проєкту та завантаження зображень
для подальшої обробки. Використання окремої CTA-кнопки (Call To Action) акцентує
увагу користувача на основній функції системи – створенні нового замовлення.
Розділ My Projects призначений для відображення активних проєктів
користувача. Цей розділ і є модулем управління замовленнями, який буде описаний
далі.
Розділ Projects History реалізує функціонал перегляду завершених проєктів та
дозволяє отримати доступ до попередніх результатів обробки.
56
Розділ Payment призначений для роботи із платіжною інформацією та
подальшої інтеграції системи оплати послуг.
У нижній частині sidebar реалізовано блок Notifications, який відображає
кількість нових сповіщень користувача та інформує його про завершення обробки
замовлення, оновлення статусу проєкту та системні повідомлення.
Також у кабінеті користувача реалізовано модуль Edit Profile, щоб редагувати
персональні дані користувача та налаштування профілю.
Інтерфейс кабінету користувача побудовано на компонентному підході Angular
– кожен функціональний блок реалізовано як окремий компонент. Це забезпечує
модульність і можливість повторного використання готових елементів, а також
суттєво спрощує підтримку та подальший розвиток системи.
Підсумовуючи, можна сказати, що реалізований кабінет користувача надає
централізований доступ до основного функціоналу web-застосунку «Virtual Staging
Home» та створює зручне середовище для взаємодії користувача із системою.
3.5 Реалізація модуля управління замовленнями
Модуль управління замовленнями є функціонально найбільш розгалуженим
компонентом кабінету користувача. Він складається з двох основних частин: сторінки
«My Projects», де користувач бачить усі свої замовлення та може їх фільтрувати, і
покрокової форми створення нового замовлення, яка відкривається після натискання
кнопки «+ Create Order».
На сторінці «My Projects» (рис. 3.6) відображається список усіх замовлень
користувача. Кожен рядок списку містить номер замовлення, тип нерухомості
(наприклад, House, Apartment або Townhouse), кількість завантажених фотографій,
обраний стиль оформлення, поточний статус та дату створення.
57
Рисунок 3.6 – Сторінка My Projects зі списком замовлень та панеллю фільтрів
Над списком розташована панель фільтрів (рис. 3.7), яка дозволяє звузити
результати за кількома параметрами одночасно. Поле «Search by ID» призначене для
пошуку конкретного замовлення за його номером. Фільтр STATUS дає змогу
відображати лише замовлення з певними статусами – наприклад ті, що в роботі, або
вже завершені. Фільтр PHOTOS фільтрує замовлення за кількістю фотографій, а
фільтр STYLE – за обраним стилем меблювання. Поруч із панеллю фільтрів
відображається кількість знайдених результатів («3 results»). При цьому всі фільтри
можна комбінувати між собою в будь-якому поєднанні.
Рисунок 3.7 – Панель фільтрів
Створення нового замовлення реалізовано у форматі покрокового майстра з
трьох етапів. Після натискання кнопки «+ Create Order» користувач переходить до
першого кроку. У верхній частині екрана з’являється індикатор прогресу – він показує
58
поточний етап і відображає назви всіх кроків, щоб користувач одразу розумів, що на
нього чекає далі. Виконані кроки позначаються зеленою позначкою.
На першому кроці користувач обирає загальний стиль меблювання для всього
замовлення (рис. 3.8). На екрані відображаються всі варіанти у вигляді карток.
Додатково над картками є випадаючий список із тими ж варіантами – він зручний для
швидкого вибору. Система також підказує, що на наступному кроці стиль можна
змінити окремо для кожного фото. Це зручно, якщо в одному замовленні потрібні
різні стилі для різних кімнат. Перейти до наступного кроку без вибору стилю не
можна – кнопка «Next» залишається заблокованою.
Рисунок 3.8 – Крок 1: вибір стилю меблювання
Другий крок – завантаження фотографій (рис. 3.9). За замовчуванням на екрані
вже розгорнута форма для першого фото (Photo #1). Під кожним фото розміщено
п’ять полів для налаштування:
− FILE (завантаження файлу зображення з пристрою користувача);
− ROOM FUNCTION (тип кімнати: вітальня, спальня, кухня, ванна тощо);
59
− INCLUDE TV? (перемикач: чи потрібно включити телевізор у дизайн);
− FURNITURE STYLE (стиль меблювання для цього конкретного фото);
− COMMENT (текстове поле для побажань дизайнеру щодо цього фото).
Щоб додати ще одне фото до замовлення, треба натиснути кнопку «+ Add
photo» внизу. Таким чином, можна додати будь-яку кількість фотографій в одне
замовлення, і кожна матиме власні незалежні налаштування. Якщо для якогось фото
не завантажено файл або не вказано тип кімнати, система не дозволить перейти до
наступного кроку та покаже підказку безпосередньо під проблемним полем.
Рисунок 3.9 – Крок 2: завантаження та налаштування фотографій
На третьому кроці (рис. 3.10) розміщено одне текстове поле «Additional
Information» для будь-яких додаткових побажань щодо всього замовлення в цілому –
наприклад, особливі вимоги до кольорової гами, побажання щодо розміщення меблів
або інші інструкції для команди дизайнерів. Поле не є обов’язковим. На цьому кроці
60
замість кнопки «Next» відображається кнопка «Submit», що дає зрозуміти: це
фінальний крок перед відправкою.
Рисунок 3.10 – Крок 3: додаткові інструкції
Після натискання «Submit» замовлення відправляється на сервер. Якщо все
пройшло успішно, користувач бачить екран підтвердження (рис. 3.11) із заголовком
«Order submitted!» та повідомленням про те, що проєкт поставлено в чергу і
користувач отримає сповіщення, коли результати будуть готові. Кнопка «Back to
Projects» повертає до сторінки «My Projects».
Таким чином, модуль управління замовленнями реалізує повний цикл роботи
клієнта із замовленнями: від перегляду та пошуку існуючих проєктів до покрокового
створення нових із гнучким налаштуванням кожної фотографії. Інтерфейс
побудований так, щоб мінімізувати кількість дій з боку користувача і водночас дати
достатньо можливостей для точного налаштування параметрів кожного замовлення.
61
Рисунок 3.11 – Екран підтвердження після відправки замовлення
3.6 Реалізація системи авторизації користувачів
Система авторизації є одним із ключових компонентів web-застосунку «Virtual
Staging Home», оскільки забезпечує ідентифікацію користувачів та доступ до кабінету
користувача і модуля управління замовленнями. Реалізована система дозволяє
створювати облікові записи, входити в застосунок та забезпечує безпечну взаємодію
користувача із backend API.
При розробці авторизації головним орієнтиром була простота – мінімум кроків,
зрозумілий onboarding і жодних зайвих перешкод на шляху до початку роботи з
платформою. У результаті процес реєстрації було реалізовано покроковий майстер із
трьох основних етапів.
На першому етапі користувач отримує можливість створити новий обліковий
запис. Система підтримує декілька способів реєстрації:
− через Google акаунт;
62
− через Apple ID;
− через введення електронної пошти.
На сторінці першого кроку також розміщено навігаційне посилання «Have an
account? Log in» для користувачів, які вже мають зареєстрований обліковий запис або
потрапили на екран реєстрації помилково.
Інтерфейс першого етапу реєстрації представлений на рисунку 3.12.
Рисунок 3.12 – Перший етап реєстрації користувача (Create Account)
Після введення електронної пошти система автоматично надсилає лист
підтвердження на вказану email адресу користувача.
На другому етапі користувач отримує повідомлення про необхідність
підтвердження email адреси через лист, надісланий системою. Інтерфейс також
містить кнопку швидкого переходу до Gmail. Передбачено також механізм
повторного надсилання листа: у нижній частині екрана відображається кнопка «No
email in your inbox or spam folder? Let’s resend it» із відповідною дією. Це забезпечує
додатковий рівень безпеки.
Інтерфейс другого етапу представлений на рисунку 3.13.
63
Рисунок 3.13 – Етап підтвердження електронної пошти (Check Your Inbox)
Після підтвердження email адреси користувач переходить до завершального
етапу створення облікового запису – заповнення основної інформації профілю. На
цьому етапі користувач вводить повне ім’я та пароль для входу до системи. Після
заповнення даних та натискання кнопки створення акаунта система завершує процес
реєстрації та формує повноцінний обліковий запис користувача.
Як вже згадувалось раніше, після успішної авторизації або реєстрації
користувач отримує JWT токен для подальшої взаємодії із backend сервісами. Токен
автоматично додається до HTTP-запитів та забезпечує захищений доступ до
функціоналу системи.
Інтерфейс завершення реєстрації представлений на рисунку 3.14.
64
Рисунок 3.14 – Завершення створення профілю користувача (Complete Your Profile)
3.7 Організація процесів тестування та розгортання web-застосунку
«Virtual Staging Home»
Процес доставки програмного забезпечення та тестування web-застосунку
«Virtual Staging Home» побудований на основі принципів безперервної інтеграції та
доставки (CI/CD – Continuous Integration/Continuous Delivery). Ці принципи
передбачають, що будь-яка зміна коду автоматично проходить через
стандартизований ланцюжок перевірок і лише після їх успішного проходження може
бути розгорнута у виробниче середовище. Головна мета такого підходу – мінімізація
кількості помилок під час внесення змін до системи, забезпечення їх стабільності та
спрощення процесу доставки нових функціональних можливостей.
Архітектура delivery-процесу включає багаторівневу перевірку коду: кожен
наступний етап виконується лише за умови успішного завершення попереднього.
Якщо на будь-якому кроці виявляється помилка – пайплайн зупиняється, команда
отримує сповіщення і зміни не просуваються далі до production. Цей підхід ралізує
65
принцип «fail fast»: проблема виявляється якнайраніше, коли вартість її виправлення
мінімальна.
Загальна структура реалізованого CI/CD процесу представлена на рисунку 3.15.
Рисунок 3.15 – Загальна схема CI/CD процесу системи
CI/CD пайплайн системи складається з дев’яти послідовних етапів, які
охоплюють повний шлях змін коду від репозиторію до production середовища. Всі
66
етапи наведені в таблиці 3.1.
Таблиця 3.1 – Етапи CI/CD системи
Етап Призначення Основні дії
Git Push Ініціація процесу CI/CD. Будь-який push до репозиторію
автоматично запускає пайплайн.
Build Збірка ПЗ. Компіляція бекенду (Spring Boot),
збірка фронтенду (Angular),
створення Docker-образів сервісів.
Lint / Checkstyle Статичний аналіз коду. Статичний аналіз коду: стиль
написання, архітектурні правила,
відсутність помилок форматування.
Unit Tests Модульне тестування. Перевірка окремих компонентів
системи в ізольованому
середовищі.
Functional Tests Інтеграційне та Перевірка взаємодії між сервісами.
функціональне
тестування.
Deploy Test Розгортання тестового Автоматичне розгортання системи
середовища. для подальшого тестування.
Manual QA Ручне тестування. Перевірка UI/UX, бізнес-логіки та
функціональних сценаріїв.
Manual Approval Контроль перед Підтвердження готовності релізу.
production-релізом.
Deploy Production Production deployment. Розгортання стабільної версії
системи у production середовищі.
Представлена послідовність етапів дозволяє забезпечити контрольовану
доставку ПЗ та мінімізувати ризики потрапляння нестабільних змін у production
середовище.
Для забезпечення стабільної роботи web-застосунку використовується
багаторівнева модель тестування, яка охоплює як окремі компоненти системи, так і
повні бізнес-сценарії взаємодії користувача із платформою.
У процесі розробки використовувалися наступні типи тестування:
− Unit Testing (перевірка окремих модулів та компонентів системи в
67
ізольованому середовищі);
− Integration Testing (перевірка коректності API-контрактів та обміну даними
між сервісами);
− Functional Testing (перевірка роботи системи як єдиного цілого, включаючи
БД, кеш і сховище);
− Manual Testing (ручна перевірка бізнес-логіки, UI/UX інтерфейсу та
коректності роботи користувацьких сценаріїв).
Особлива увага приділялася тестуванню системи авторизації користувачів,
модуля управління замовленнями, механізмів завантаження файлів, polling-механізму
оновлення статусів, взаємодії між frontend та backend частинами. Тож таке
використання багаторівневого тестування дозволило мінімізувати кількість помилок
та забезпечити стабільність роботи web-застосунку.
Для забезпечення довгострокової стабільності процесу доставки в проєкті, під
час розробки були сформовані такі методичні принципи:
− використання незмінних Docker-артефактів для всіх середовищ, що
виключає розбіжності між test і production;
− чіткий поділ конфігурацій тестового та production середовищ запобігає
випадковому використанню тестових налаштувань у реальному оточенні;
− максимальна автоматизація перевірок скорочує час отримання зворотного
зв'язку після кожної зміни коду;
− збереження ручного підтвердження(manual approval) виключно для
production-релізів забезпечує баланс між швидкістю доставки та контролем
якості.
Впроваджений CI/CD процес повністю автоматизує процес перевірки та
доставки ПЗ від моменту внесення змін до розгортання у production. Багаторівнева
модель тестування дозволяє виявляти різні дефекти на найбільш ранньому і найменш
затратному етапі. При цьому автоматизовані перевірки не замінюють людський
контроль повністю: поєднання з ручним QA та обов'язковим manual approval дає
змогу знайти баланс між швидкістю випуску нових функцій і стабільністю релізів –
що особливо важливо для сервісу, яким користуються реальні клієнти.
68
Висновки до розділу 3
У третьому розділі кваліфікаційної роботи бакалавра розглянуто процес
розробки, реалізації та тестування web-застосунку «Virtual Staging Home». Основну
увагу приділено реалізації кабінету користувача та модуля управління замовленнями,
які є ключовими компонентами системи та забезпечують основну взаємодію
користувача із функціоналом платформи.
Основний workflow web-застосунку побудовано на State Machine з сімома чітко
визначеними станами замовлення та асинхронній обробці зображень через Async
Workers. Це гарантує контрольований і передбачуваний життєвий цикл кожного
замовлення без ризику потрапляння в некоректний стан, а фонова обробка файлів не
блокує інтерфейс користувача незалежно від того, скільки часу займає операція.
Клієнтська частина web-застосунку реалізована як SPA на Angular 18 із
централізованим управлінням станом через NgRx Store. Серверна частина побудована
на мікросервісній архітектурі з чотирма незалежними компонентами: Orchestrator
Service, Asset Manager Service, Security Service та Async Workers. Кожен сервіс має
власну зону відповідальності, що дозволяє підтримувати їх незалежно.
Створений кабінет користувача надає клієнту зручний доступ до функціоналу
web-застосунку через sidebar-навігацію з шістьма розділами. Модуль управління
замовленнями дозволяє переглядати й фільтрувати існуючі проєкти, а також
покроково створювати нові із можливістю індивідуального налаштування.
У межах розділу також розглянуто реалізацію системи авторизації користувачів
та головної сторінки web-застосунку «Virtual Staging Home». Реалізований інтерфейс
загалом відповідає сучасним стандартам UI/UX і забезпечує зручну та інтуїтивно
зрозумілу взаємодію з платформою.
Процес тестування та доставки організовано за принципами CI/CD із
дев’ятиетапним процесом. Автоматизовані перевірки поєднуються із ручним QA та
обов’язковим підтвердженням перед кожним production-релізом. Це дозволило
перевірити коректність роботи як окремих компонентів, так і повних бізнес-сценаріїв
системи.
69
Отже, в результаті виконання третього розділу реалізовано web-застосунок
«Virtual Staging Home», який забезпечує функціонування кабінету користувача та
модуля управління замовленнями, підтримує асинхронну обробку даних та сучасний
користувацький інтерфейс.
Таким чином, усі реалізовані компоненти web-застосунку утворюють цілісний,
технічно обґрунтований продукт.
70
ВИСНОВКИ
У ході написання кваліфікаційної роботи бакалавра було реалізовано кабінет
користувача та модуль управління замовленнями web-застосунку «Virtual Staging
Home». Створений web-застосунок призначений для організації процесу створення,
обробки та управління замовленнями в сфері Virtual Staging із використанням
сучасних web-технологій та мікросервісної архітектури.
У першому розділі було проведено аналіз предметної області віртуальної
постановки та досліджено існуючі web-застосунки, серед яких: BoxBrownie, Virtual
Staging AI та Stucco. На основі цього аналізу визначено основні функціональні
можливості сучасних сервісів, їх переваги та недоліки, а також сформовано вимоги
до розробки власного web-застосунку «Virtual Staging Home».
У другому розділі виконано проєктування всіх ключових компонентів web-
застосунку. Розроблено загальну мікросервісну архітектуру з сімома логічними
рівнями та описано взаємодію між компонентами. Спроєктовано триетапну систему
авторизації. Визначено структуру кабінету користувача, модуля управління
замовленнями та головної сторінки, обґрунтовано ключові UI/UX рішення
інтерфейсу.
У третьому розділі описано повну реалізацію web-застосунку «Virtual Staging
Home». Розроблено основний workflow web-застосунку, що забезпечує повний
життєвий цикл замовлення – від завантаження файлів до отримання фінального
результату обробки. Для реалізації даного процесу використано state machine та
механізми асинхронної обробки даних.
Було створено frontend, backend частини web-застосунку. Клієнтська частина
реалізована як Single Page Application на Angular 18 із централізованим управлінням
станом через NgRx Store. Серверна частина побудована на основі мікросервісної
архітектури із використанням Spring Boot, PostgreSQL, Redis та AWS S3.
У роботі реалізовано систему авторизації користувачів із підтримкою
реєстрації через email, Google та Apple акаунти. Також реалізовано кабінет
користувача, який забезпечує доступ до управління замовленнями, перегляду історії
71
проєктів, результатів обробки та налаштувань профілю.
Одним із ключових результатів роботи став модуль управління замовленнями,
який забезпечує перегляд і проєктів за чотирма параметрами та покрокове створення
нових замовлень через трикроковий wizard із можливістю індивідуального
налаштування кожної фотографії.
Також було організовано процес тестування та доставки на основі
дев’ятиетапного CI/CD пайплайну з обов’язковим ручним підтвердженням перед
кожним production-релізом. Побудована схема підвищує стабільність роботи web-
застосунку та спрощує подальшу підтримку проєкту.
Практичне значення роботи полягає у створенні функціонального web-
застосунку «Virtual Staging Home», який забезпечує зручний інтерфейс для
управління замовленнями та надійну серверну обробку файлів. Реалізований
застосунок відповідає сучасним стандартам web-розробки і може слугувати основою
для подальшого розвитку сервісу в сфері Virtual Staging.
72
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Платформа BoxBrownie.com. URL: https://www.boxbrownie.com/ (дата
звернення: 09.02.2026).
2. Сервіс Virtual Staging AI. URL: https://homedesigns.ai/ (дата звернення:
09.02.2026).
3. Сервіс Stuccco.com. URL https://stuccco.com/ (дата звернення: 09.02.2026).
4. Офіційна документація Angular URL:
https://v17.angular.io/docs?utm_source=chatgpt.com (дата звернення: 26.02.2026).
5. І. М. Добровольська, Л. П. Оксамитна. Розробка кабінету користувача та модуля
управління замовленнями web-застосунку «Virtual Staging Home» : Збірник тез
доповідей студентської науково-практичної конференції ЧДТУ : 22-23 квітня
2026 / [упорядник Мельник І.В.]; Міністерство освіти і науки України,
Черкаський державний технологічний ун-т. Черкаси : ЧДТУ, 2026. С. 8.
6. Методичні рекомендації для підготовки кваліфікаційної роботи бакалавра
здобувачів освітнього ступеня «бакалавр» зі спеціальності 122 (F3) –
«Комп’ютерні науки» усіх форм навчання [Електронний ресурс] / [упоряд.
Триус Ю.В., Оксамитна Л.П., Підгорний М.В.]; М-во освіти і науки України,
Черкас. держ. технол. ун-т. Черкаси: ЧДТУ, 2026. 53 с.
73
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2026 р.
КАБІНЕТ КОРИСТУВАЧА ТА МОДУЛЬ УПРАВЛІННЯ ЗАМОВЛЕННЯМИ
WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
Специфікація
482.ЧДТУ. 62287-01
Листів 2
Розробник ____________________ Ілона ДОБРОВОЛЬСЬКА
Керівник ____________________ Любов ОКСАМИТНА
Черкаси – 2026
74
482.ЧДТУ. 62287-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 62287-01 12 01 Лістинг коду програми
482.ЧДТУ. 62287-01 34 01 Інструкція користувача
482.ЧДТУ. 62287-01 90 01 Апробація
кваліфікаційної роботи
бакалавра
75
ДОДАТОК Б
КАБІНЕТ КОРИСТУВАЧА ТА МОДУЛЬ УПРАВЛІННЯ ЗАМОВЛЕННЯМИ
WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
Лістинг коду програми
482.ЧДТУ. 62287-01 12 01
Листів 8
Розробник _____________ Ілона ДОБРОВОЛЬСЬКА
Черкаси – 2026
76
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Homee</title>
<link
href="https://fonts.googleapis.com/css2?family=DM+Sans:ital,opsz,wght@0,9..40,400;0,9..40,500;0,9..4
0,600;0,9..40,700&display=swap" rel="stylesheet" />
<script src="https://unpkg.com/[email protected]/umd/react.development.js" integrity="sha384-
hD6/rw4ppMLGNu3tX5cjIb+uRZ7UkRJ6BPkLpg4hAu/6onKUg4lLsHAs9EBPT82L"
crossorigin="anonymous"></script>
<script src="https://unpkg.com/[email protected]/umd/react-dom.development.js" integrity="sha384-
u6aeetuaXnQ38mYT8rp6sbXaQe3NL9t+IBXmnYxwkUI2Hw4bsp2Wvmx4yRQF1uAm"
crossorigin="anonymous"></script>
<script src="https://unpkg.com/@babel/[email protected]/babel.min.js" integrity="sha384-
m08KidiNqLdpJqLq95G/LEi8Qvjl/xUYll3QILypMoQ65QorJ9Lvtp2RXYGBFj1y"
crossorigin="anonymous"></script>
<style>
*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
html, body, #root { height: 100%; }
body { font-family: 'DM Sans', sans-serif; background: #e8e8e8; color: #111; -webkit-font-smoothing:
antialiased; }
::-webkit-scrollbar { width: 5px; }
::-webkit-scrollbar-thumb { background: #d0d0d0; border-radius: 3px; }
.app { display: flex; height: 100vh; padding: 10px; gap: 10px; overflow: hidden; }
/* ── Sidebar ── */
.sidebar {
width: 248px; min-width: 248px;
background: #111;
border-radius: 18px;
display: flex; flex-direction: column;
overflow: hidden;
77
}
.sidebar-logo {
display: flex; align-items: center; gap: 12px;
padding: 22px 18px 18px;
}
.sidebar-logo-mark {
width: 34px; height: 34px; background: #fff; border-radius: 8px;
display: flex; align-items: center; justify-content: center; flex-shrink: 0;
}
.sidebar-logo-name { font-size: 17px; font-weight: 700; color: #fff; letter-spacing: -0.3px; }
.sidebar-nav { flex: 1; padding: 6px 10px; display: flex; flex-direction: column; gap: 2px; }
.user-ava {
width: 26px; height: 26px; border-radius: 50%;
background: rgba(255,255,255,0.12); color: rgba(255,255,255,0.65);
font-size: 11px; font-weight: 700;
display: flex; align-items: center; justify-content: center; flex-shrink: 0;
}
.logout-btn { margin-left: auto; cursor: pointer; opacity: 0.35; transition: opacity 0.15s; }
.logout-btn:hover { opacity: 0.85; }
/* ── Main ── */
.main {
flex: 1; overflow: hidden;
background: #fff;
border-radius: 18px;
display: flex; flex-direction: column;
}
/* ── Sidebar ── */
function Sidebar({ active, onNav, mobileOpen, onClose }) {
const nav = [
{ id:"dashboard", label:"Dashboard", icon:I.home },
{ id:"projects", label:"My Projects", icon:I.folder },
78
{ id:"history", label:"History", icon:I.clock },
{ id:"payment", label:"Payment", icon:I.wallet },
];
return (
<>
<div className={`sidebar-overlay ${mobileOpen?"show":""}`} onClick={onClose} />
<aside className={`sidebar ${mobileOpen?"mobile-open":""}`}>
<div className="sidebar-logo">
<div className="sidebar-logo-mark">
<Ico d={I.home} size={17} stroke="#111" />
</div>
<span className="sidebar-logo-name">Homee</span>
</div>
<nav className="sidebar-nav">
{nav.map(n => (
<div key={n.id} className={`snl ${active===n.id?"active":""}`} onClick={() => { onNav(n.id);
onClose(); }}>
<Ico d={n.icon} size={17} />
{n.label}
</div>
))}
</nav>
<div className="sidebar-bottom">
<div className="snl">
<Ico d={I.bell} size={17} />
Notifications
<span className="badge">5</span>
</div>
<div className="snl">
<Ico d={I.settings} size={17} />
Edit Profile
</div>
79
<div className="sidebar-user">
<div className="user-ava">T</div>
<span style={{flex:1}}>test</span>
<span className="logout-btn"><Ico d={I.logout} size={16} /></span>
</div>
</div>
</aside>
</>
);
/* ── Projects page ── */
const MOCK_ORDERS = [
{ id:"#40566", type:"House", style:"Modern", photos:6, date:"Apr 27, 2026", status:"done" },
{ id:"#40541", type:"Apartment", style:"Scandinavian", photos:3, date:"Apr 18, 2026", status:"progress"
},
{ id:"#40520", type:"Townhouse", style:"Classic", photos:5, date:"Apr 10, 2026", status:"pending" },
];
const STATUS_LABEL = { pending:"Pending", progress:"In progress", done:"Completed" };
function StatusPill({ s }) {
return (
<span className={`status-pill ${s==="done"?"done-pill":s}`}>
<span className="status-dot" />
{STATUS_LABEL[s]}
</span>
);
}
function ProjectsPage({ onCreateOrder, onEditOrder }) {
const [search, setSearch ] = useState("");
const [statusFilter,setStatusFilter] = useState("all");
const [photoFilter, setPhotoFilter ] = useState("all");
const [styleFilter, setStyleFilter ] = useState("all");
const [drawerOpen, setDrawerOpen ] = useState(false);
const STATUS_OPTS = [
80
{ val:"pending", label:"Pending" },
{ val:"progress", label:"In progress" },
{ val:"done", label:"Completed" },
];
const PHOTO_OPTS = [
{ val:"all", label:"Any" },
{ val:"1-3", label:"1–3" },
{ val:"4-6", label:"4–6" },
{ val:"7+", label:"7+" },
];
const STYLE_OPTS_F = [
{ val:"all", label:"All styles" },
{ val:"Modern", label:"Modern" },
{ val:"Scandinavian", label:"Scandinavian" },
{ val:"Classic", label:"Classic" },
{ val:"Transitional", label:"Transitional" },
];
const photoInRange = (count, range) => {
if (range === "all") return true;
if (range === "1-3") return count >= 1 && count <= 3;
if (range === "4-6") return count >= 4 && count <= 6;
if (range === "7+") return count >= 7;
return true;
};
const filtered = MOCK_ORDERS.filter(o => {
const q = search.trim().toLowerCase();
if (q && !o.id.toLowerCase().includes(q)) return false;
if (statusFilter !== "all" && o.status !== statusFilter) return false;
if (!photoInRange(o.photos, photoFilter)) return false;
if (styleFilter !== "all" && o.style !== styleFilter) return false;
81
return true;
});
const hasFilters = search || statusFilter !== "all" || photoFilter !== "all" || styleFilter !== "all";
const activeCount = (statusFilter!=="all"?1:0)+(photoFilter!=="all"?1:0)+(styleFilter!=="all"?1:0);
const clearAll = () => {
setSearch(""); setStatusFilter("all"); setPhotoFilter("all"); setStyleFilter("all");
};
return (
<div className="main">
<div className="page-header">
<h1 className="page-title">My Projects</h1>
<button className="btn btn-dark" onClick={onCreateOrder}>
<Ico d={I.plus} size={15} stroke="#fff" />
<span>Create Order</span>
</button>
</div>
{/* ── Filters bar ── */}
<div className="filters-bar">
<div className="filter-search">
<Ico d="M21 21l-4.35-4.35M17 11A6 6 0 115 11a6 6 0 0112 0z" size={14} stroke="#bbb" />
<input
placeholder="Search by ID…"
value={search}
onChange={e => setSearch(e.target.value)}
/>
</div>
<div className="filter-sep" />
{/* Status chips — hidden on mobile via CSS */}
82
<div className="filter-group">
<span className="filter-label">Status</span>
{STATUS_OPTS.map(opt => (
<button
key={opt.val}
className={`filter-chip ${statusFilter === opt.val ? "active" : ""}`}
onClick={() => setStatusFilter(statusFilter === opt.val ? "all" : opt.val)}
>
<span className="chip-dot" />
{opt.label}
</button>
))}
</div>
<div className="filter-sep" />
<div className="filter-group">
<span className="filter-label">Photos</span>
<select
className={`filter-sel ${photoFilter !== "all" ? "has-value" : ""}`}
value={photoFilter}
onChange={e => setPhotoFilter(e.target.value)}
>
<option value="all">Any photos</option>
{PHOTO_OPTS.slice(1).map(o => <option key={o.val} value={o.val}>{o.val}
photos</option>)}
</select>
</div>
83
ДОДАТОК В
КАБІНЕТ КОРИСТУВАЧА ТА МОДУЛЬ УПРАВЛІННЯ ЗАМОВЛЕННЯМИ
WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
ІНСТРУКЦІЯ КОРИСТУВАЧА
482.ЧДТУ. 62287-01 34 01
Листів 6
Розробник _____________ Ілона ДОБРОВОЛЬСЬКА
Черкаси – 2026
84
Web-застосунок «Virtual Staging Home» призначений для замовлення послуги
віртуального стейджингу нерухомості – професійної обробки фотографій порожніх
приміщень із додаванням меблів та декору у різних стилях. Застосунок дозволяє
завантажувати фотографії, обирати стиль оформлення та відстежувати стан
виконання замовлення в особистому кабінеті.
Для роботи із застосунком необхідний будь-який сучасний браузер із
підключенням до мережі Інтернет. Встановлення додаткового програмного
забезпечення не потрібне.
Для отримання доступу до особистого кабінету необхідно створити обліковий
запис. Процес реєстрації складається з трьох кроків.
1. Перейдіть на головну сторінку застосунку та натисніть кнопку «Get Started» або
«Log in» у верхньому правому куті.
2. На сторінці реєстрації оберіть спосіб створення акаунту: через обліковий запис
Google або Apple (швидкий вхід в один клік) або вручну, ввівши адресу
електронної пошти у відповідне поле. Натисніть «Continue».
3. Перевірте поштову скриньку – на вказану адресу надійде лист із посиланням
для підтвердження. Натисніть кнопку «Open Gmail» для швидкого переходу до
пошти або перейдіть до поштового клієнта вручну. Якщо лист не надійшов
протягом кількох хвилин, перевірте папку «Спам» або скористайтесь
посиланням «Let's resend it» для повторного надсилання.
4. Перейдіть за посиланням із листа. Введіть своє повне ім’я та пароль, після чого
натисніть «Creare account». Користувача буде автоматично перенаправлено до
особистого кабінету.
Примітка: Якщо користувач вже має обліковий запис, потрібно натиснути
«Have an account? Log in» на сторінці реєстрації та ввести email і пароль.
Після входу в систему користувач потрапляє до особистого кабінету (рис. В.1).
Ліворуч розташована навігаційна панель із такими розділами:
− Dashboard – стартова сторінка з кнопкою швидкого створення першого
замовлення;
− My Projects – список усіх активних замовлень користувача;
85
− Projects History – архів завершених проєктів;
− Payment – управління балансом та історія оплат;
− Notifications – сповіщення;
− Edit Profile – редагування особистих даних.
Рисунок В.1 – Особистий кабінет користувача (Dashboard)
Щоб створити нове замовлення, користувач має перейти до розділу «My
Projects» та натиснути кнопку «+ Create Order» у правому верхньому куті. Відкриється
покроковий процес із трьох кроків.
Крок 1 – вибір стилю меблювання (рис. В.2). Клацніть на картку з потрібним
стилем – вона виділиться рамкою. Стиль також можна обрати через випадаючий
список над картками. Натисніть «Next» для переходу до наступного кроку.
Примітка: Обраний стиль застосовується до всіх фотографій замовлення за
замовчуванням, але на наступному кроці його можна змінити окремо для кожного
фото.
86
Рисунок В.2 – Крок 1: вибір стилю меблювання
Крок 2 (рис. В.3) – завантажте фотографії приміщень та налаштуйте параметри
для кожної з них. Поля FILE та ROOM FUNCTION є обов’язковими для кожної
фотографії. Без їх заповнення перейти до наступного кроку не вдасться.
Рисунок В.3 – Крок 2: завантаження та налаштування фотографій
87
Крок 3 (рис. В.4) – додаткова інформація. За бажанням залиште загальні
інструкції для команди стейджингу в текстовому полі «Additional Information» –
наприклад, побажання щодо кольорової гами або розміщення меблів. Поле не є
обов’язковим. Після заповнення натисніть «Submit» для відправки замовлення.
Рисунок В.4 – Крок 3: додаткові інструкції
Після успішної відправки з’явиться екран підтвердження «Order submitted!» із
повідомленням про те, що ваш проєкт поставлено в чергу (рис. В.5). Натисніть «Back
to Projects» – щойно створене замовлення вже відображатиметься в списку зі статусом
Pending.
Рисунок В.5 – Екран підтвердження відправки замовлення
88
Усі замовлення користувача відображаються в розділі «My Projects» (рис. В.6).
Кожне замовлення містить його номер, тип нерухомості, кількість фотографій,
обраний стиль та поточний статус.
Для пошуку конкретного замовлення скористайтесь полем «Search by ID» або
застосуйте фільтри: за статусом (STATUS), кількістю фото (PHOTOS) чи стилем
(STYLE). Фільтри можна комбінувати. Поруч із панеллю фільтрів відображається
кількість знайдених результатів.
Якщо замовлення має статус Pending, ви можете його відредагувати – для цього
натисніть кнопку «Edit» праворуч від замовлення.
Рисунок В.6 – Розділ My Projects зі списком замовлень
89
ДОДАТОК Г
КАБІНЕТ КОРИСТУВАЧА ТА МОДУЛЬ УПРАВЛІННЯ ЗАМОВЛЕННЯМИ
WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
Апробація кваліфікаційної роботи бакалавра
482.ЧДТУ. 62287-01 90 01
Листів 4
Розробник _____________ Ілона ДОБРОВОЛЬСЬКА
Черкаси – 2026
90
91
РОЗРОБКА КАБІНЕТУ КОРИСТУВАЧА ТА МОДУЛЯ УПРАВЛІННЯ
ЗАМОВЛЕННЯМИ WEB-ЗАСТОСУНКУ «VIRTUAL STAGING HOME»
Добровольська І.М. (студент ФІТІС), Оксамитна Л.П., к.т.н., доц.
Черкаський державний технологічний університет
У сучасних web-застосунках визначальним чинником є забезпечення зручної
взаємодії користувача із системою, зокрема через персоналізований кабінет та
ефективну модель керування замовленнями. Для платформ у сфері віртуального
дизайну інтер’єру це особливо актуально, оскільки користувачі взаємодіють із
цифровими продуктами та послугами виключно дистанційно. У доповіді
розглядається розробка кабінету користувача та модуля управління замовленнями для
web-застосунку «Virtual Staging Home», що призначений для надання послуг
віртуальної постановки будинку. Досліджено сучасні підходи до проєктування
користувацьких інтерфейсів та визначено технічні вимоги до функціоналу майбутньої
системи. Клієнтська частина була реалізована з використанням технологій HTML,
CSS, JavaScript, а дизайн-макет спроєктовано у Figma з дотриманням сучасних
стандартів UX/UI дизайну. Розроблений кабінет користувача надає можливість
реєстрації, авторизації, керування персональними даними, а також доступ до архіву
замовлень. Модуль управління замовленнями охоплює процеси створення, обробки
та моніторингу статусу замовлень. Завдяки цьому вдалося покращити ефективність
сервісу та гарантувати прозорість взаємодії з користувачем. Запропоновані підходи
мають великий потенціал впровадження у web-застосунки у сфері нерухомості,
електронної торгівлі та цифрового дизайну. Як результат, розроблений функціонал
відповідає критеріям зручності, продуктивності та масштабованості. Подальший
розвиток досліджень передбачає розширення функціональності системи та
використання технологій штучного інтелекту для автоматизації роботи із
замовленнями.
92