Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9668
Назва: Web-сервіс «Подарунок»
Автори: Метелап, Володимир Володимирович
Прудиус, Вікторія Миколаївна
Ключові слова: інженерія програмного забезпечення;Wishlist;Next.Js;Typescript;Prisma Orm;парсинг даних;Smart Link Parsing;Web-Сервіс;UML-моделювання;бронювання подарунків.;software engineering;Wishlist;Next.Js;Typescript;Prisma Orm;data parsing;Smart Link Parsing;Web Service;UML modeling;gift booking
Дата публікації: 17-чер-2026
Короткий огляд (реферат): АНОТАЦІЯ Об’єкт розробки: процес розробки для програмного забезпечення створення web-орієнтованих інформаційних систем для автоматизації керування споживчими перевагами та списками бажань. Предмет розробки: процес побудови програмного забезпечення методів, алгоритмів, технології проектування та розробки ПЗ (зокрема технологія Smart Link Parsing) та програмні засоби побудови web-сервісу «Подарунок». Мета роботи: спроектувати та розробити сучасний web-сервіс, який дозволяє користувачам ефективно структурувати свої ідеї для подарунків, автоматизувати додавання подарунків (товарів, послуг) через парсинг посилань і додаванням нових полів, та безпечно ділитися списками для координації з оточенням. Методи проектування та стек технологій: Архітектурне моделювання: використано мову UML длястворення діаграм прецедентів, класів, компонентів та послідовностей. Frontend: фреймворк Next.js (App Router), бібліотека React та моваTypeScript. Backend та база даних: PostgreSQL із використанням Prisma ORMдля управління реляційними даними. Автоматизація збору даних: бібліотеки Cheerio та Puppeteer дляреалізації гібридного методу web-парсингу метатегів (Open Graph, JSON-LD) та динамічного контенту. Інфраструктура: хмарна платформа Supabase для автентифікаціїкористувачів через JWT та збереження профілів. Отримані результати. У ході роботи розроблено повнофункціональний web-сервіс із модульною архітектурою. Реалізовано унікальний модуль «Smart Link Parsing», що дозволяє автоматично вилучати назву, актуальну ціну та зображення товару за URL-посиланням з будь-яких маркетплейсів. Впроваджено механізм бронювання подарунків гостями списку, що виключає ризик дублювання подарунків, зберігаючи при цьому ефект сюрпризу для власника. Система підтримує гнучкі налаштування приватності через генерацію унікальних криптографічних ключів доступу (Access Keys). Практичне значення. Створено готовий до експлуатації інструмент, який вирішує проблему отримання небажаних подарунків та оптимізує процес агрегації даних з різних платформ електронної комерції. Результати тестування підтвердили стабільність системи, її адаптивність до мобільних пристроїв та високу швидкість обробки запитів.
ABSTRACT Object of development: the process of creating web-oriented information systems for managing consumer preferences and wish lists. Subject of development: methods, algorithms (specifically Smart Link Parsing technology), and software tools for developing the "Gift" web service. Purpose of the work: designing and developing a modern web service that allows users to efficiently structure their gift ideas, automate the addition of items via link parsing, and securely share lists to coordinate with their circle. Design methods and technology stack: Architectural modeling: the UML language was used to create use case,class, component, and sequence diagrams. Frontend: Next.js framework (App Router), React library, and TypeScriptlanguage. Backend and database: PostgreSQL utilizing Prisma ORM to managerelational data. Data collection automation: Cheerio and Puppeteer libraries forimplementing a hybrid web parsing method for meta tags (Open Graph, JSON-LD) and dynamic content. Infrastructure: Supabase cloud platform for user authentication via JWTtokens and profile storage. Obtained results: During the work, a fully functional web service with a modular architecture was developed. A unique "Smart Link Parsing" module was implemented, allowing for the automatic extraction of the item's name, current price, and image via a URL link from any marketplaces. A gift booking mechanism for list guests was introduced, eliminating the risk of duplicate presents while maintaining the element of surprise for the owner. The system supports flexible privacy settings through the generation of unique cryptographic access keys (Access Keys). Practical significance: A ready-to-use tool was created that solves the problem of receiving unwanted gifts and optimizes the process of aggregating data from various e-commerce platforms. Testing results confirmed the system's stability, its adaptability to mobile devices, and high request processing speed.
URI (Уніфікований ідентифікатор ресурсу): https://er.chdtu.edu.ua/handle/ChSTU/9668
Розташовується у зібраннях:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:
Файл Опис РозмірФормат 
Кваліфікаційна робота бакалавра Прудиус Вікторія Миколаївна.pdf
  Restricted Access
6.11 MBAdobe PDFView/Open Request a copy


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

Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
на тему: Web-сервіс «Подарунок» 
Виконав: студент 4 курсу, групи ПЗ-2204 
спеціальності  
121 «Інженерія програмного забезпечення» 
(шифр і назва напряму підготовки) 
Студент Прудиус В.М. 
(прізвище та ініціали) 
Керівник Метелап В.В. 
(прізвище та ініціали) 
Рецензент Захарова М.В. 
(прізвище та ініціали) 
Черкаси 2026
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
Освітній рівень бакалавр 
Спеціальність 121 «Інженерія програмного забезпечення» 
Освітня програма Інженерія програмного забезпечення 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
С. Голуб 
«___» _______________ 2026 року 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Прудиус Вікторія Миколаївна 
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) Web-сервіс «Подарунок»
Керівник проекту (роботи) Метелап Володимир Володимирович к.т.н. доцент 
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «12»  березня 
2026року №56/03-03 
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи)
Персональний комп’ютер на базі процесора x64 (AMD Ryzen 5 5500H з інтегрованою 
графікою Radeon Graphics) та 16 ГБ оперативної пам'яті.  
Інструментальні засоби розробки: Мови програмування TypeScript та JavaScript (середовище 
виконання Node.js), фреймворки для розробки web-застосунків (Next.js, React), інструменти 
взаємодії з базами даних (Prisma ORM) та бібліотеки для автоматизації і парсингу web-
сторінок (Puppeteer, Cheerio). 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань 
Розділ 2 Впровадження результатів досліджень у практику проектування програмного 
забезпечення інформаційних систем 
Розділ 3 Розробка та тестування програмного забезпечення 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
Додаток В – Рис В.1 – В.21 – Слайди презентації кваліфікаційної роботи. 
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1 
2 
3 
Дата видачі завдання 23.01.2026 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів випускної Примітки 
п/п 
роботи 
1 Постановка задачі 23.01.2026 виконано 
2 Підготовка завдання 30.01.2026 виконано 
3 Погодження завдання 04.02.2026 виконано 
4 Затвердження завдання 09.02.2026 виконано 
Основна стадія виконано 
1 Підбір матеріалів 23.02.2026 виконано 
2 Аналіз шляхів вирішення поставленої задачі 05.03.2026 виконано 
3 Розрахунок основних параметрів роботи 20.03.2026 виконано 
4 Вибір кінцевого варіанту проектного рішення 02.04.2026 виконано 
5 Оформлення первісної редакції роботи 16.04.2026 виконано 
Заключна стадія виконано 
1 Узгодження прийнятих проектних рішень з 25.04.2026 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 10.05.2026 виконано 
кінцевій редакції 
3 Попередній захист роботи 20.05.2026 виконано 
4 Затвердження роботи 25.05.2026 виконано 
5 Рецензування роботи 28.05.2026 виконано 
6 Захист роботи 01.06.2026 
Студент _____________________  Прудиус В.М. 
(підпис) (прізвище та ініціали) 
Керівник проекту (роботи) _____________________ Метелап В.В. 
(підпис) (прізвище та ініціали) 
АНОТАЦІЯ 
Об’єкт розробки: процес розробки для програмного забезпечення 
створення web-орієнтованих інформаційних систем для автоматизації керування 
споживчими перевагами та списками бажань. 
Предмет розробки: процес  побудови програмного забезпечення методів, 
алгоритмів, технології проектування та розробки ПЗ (зокрема технологія Smart 
Link Parsing) та програмні засоби побудови web-сервісу «Подарунок». 
Мета роботи: спроектувати та розробити сучасний web-сервіс, який 
дозволяє користувачам ефективно структурувати свої ідеї для подарунків, 
автоматизувати додавання подарунків (товарів, послуг) через парсинг посилань 
і додаванням нових полів, та безпечно ділитися списками для координації з 
оточенням. 
Методи проектування та стек технологій: 
 Архітектурне моделювання: використано мову UML для
створення діаграм прецедентів, класів, компонентів та послідовностей. 
 Frontend: фреймворк Next.js (App Router), бібліотека React та мова
TypeScript. 
 Backend та база даних: PostgreSQL із використанням Prisma ORM
для управління реляційними даними. 
 Автоматизація збору даних: бібліотеки Cheerio та Puppeteer для
реалізації гібридного методу web-парсингу метатегів (Open Graph, JSON-
LD) та динамічного контенту. 
 Інфраструктура: хмарна платформа Supabase для автентифікації
користувачів через JWT та збереження профілів. 
Отримані результати. У ході роботи розроблено повнофункціональний 
web-сервіс із модульною архітектурою. Реалізовано унікальний модуль «Smart 
Link Parsing», що дозволяє автоматично вилучати назву, актуальну ціну та 
зображення товару за URL-посиланням з будь-яких маркетплейсів. Впроваджено 
механізм бронювання подарунків гостями списку, що виключає ризик 
дублювання подарунків, зберігаючи при цьому ефект сюрпризу для власника. 
Система підтримує гнучкі налаштування приватності через генерацію 
унікальних криптографічних ключів доступу (Access Keys). 
Практичне значення. Створено готовий до експлуатації інструмент, який 
вирішує проблему отримання небажаних подарунків та оптимізує процес 
агрегації даних з різних платформ електронної комерції. Результати тестування 
підтвердили стабільність системи, її адаптивність до мобільних пристроїв та 
високу швидкість обробки запитів. 
Ключові слова: інженерія програмного забезпечення, Wishlist, Next.Js, 
Typescript, Prisma Orm, парсинг даних, Smart Link Parsing, Web-Сервіс, UML 
моделювання, бронювання подарунків.
ABSTRACT 
Object of development: the process of creating web-oriented information systems 
for managing consumer preferences and wish lists.  
Subject of development: methods, algorithms (specifically Smart Link Parsing 
technology), and software tools for developing the "Gift" web service. 
Purpose of the work: designing and developing a modern web service that allows 
users to efficiently structure their gift ideas, automate the addition of items via link 
parsing, and securely share lists to coordinate with their circle. 
Design methods and technology stack: 
 Architectural modeling: the UML language was used to create use case,
class, component, and sequence diagrams. 
 Frontend: Next.js framework (App Router), React library, and TypeScript
language. 
 Backend and database: PostgreSQL utilizing Prisma ORM to manage
relational data. 
 Data collection automation: Cheerio and Puppeteer libraries for
implementing a hybrid web parsing method for meta tags (Open Graph, JSON-LD) 
and dynamic content. 
 Infrastructure: Supabase cloud platform for user authentication via JWT
tokens and profile storage. 
Obtained results: 
During the work, a fully functional web service with a modular architecture was 
developed. A unique "Smart Link Parsing" module was implemented, allowing for the 
automatic extraction of the item's name, current price, and image via a URL link from any 
marketplaces. A gift booking mechanism for list guests was introduced, eliminating the 
risk of duplicate presents while maintaining the element of surprise for the owner. The 
system supports flexible privacy settings through the generation of unique cryptographic 
access keys (Access Keys). 
Practical significance: 
A ready-to-use tool was created that solves the problem of receiving unwanted gifts 
and optimizes the process of aggregating data from various e-commerce platforms. 
Testing results confirmed the system's stability, its adaptability to mobile devices, and 
high request processing speed. 
Keywords: software engineering, Wishlist, Next.Js, Typescript, Prisma Orm, 
data parsing, Smart Link Parsing, Web Service, UML modeling, gift booking. 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................... 7 
ВСТУП ....................................................................................................................... 11 
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................. 13 
1.1 Аналіз предметної області та актуальних проблем планування 
подарунків ................................................................................................ 13 
1.2 Огляд існуючих систем та web-додатків для створення вішлистів
 ..................................................................................................................... 13 
1.3 Аналіз методів автоматизованого збору даних (парсингу) з web-
сторінок електронної комерції ............................................................. 16 
1.4 Обґрунтування необхідності розробки власного програмного 
рішення ...................................................................................................... 16 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................. 20 
2.1 Моделювання предметної області ....................................................... 20 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області .......................................................... 20 
2.1.2 Елементи моделювання предметної області ................................ 20 
2.1.3 Робоча область моделювання ........................................................ 23 
2.2 Формування та аналіз вимог ................................................................ 26 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні 
та нефункціональні вимоги. ........................................................... 26 
2.2.2 Формування вимог за допомогою діаграми прецедентів ........... 30 
2.3 Проектування логічної структури програмного комплексу.......... 33 
2.3.1 Діаграма класів ................................................................................ 34
ЧДТУ 262258.019 ПЗ 
Змн. Арк. № докум. Підпис Дата 
 Розроб. Прудиус В.М. Літ. Лист Листів 
 Перевір. Метелап В.В. 4 
Рецензент Захарова М.В. Web-сервіс «Подарунок» 
 Н. Контр. Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗ-2204 
 Затверд. Голуб С.В. 
2.3.2 Діаграми пакетів ............................................................................. 39 
2.4 Архітектурне проектування ....................................................... 40
2.4.1 Діаграма компонентів ...................................................................... 42 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ...................................................................................... 44 
2.5 Моделювання поведінки системи ........................................................ 46 
2.5.1 Діаграми діяльності ......................................................................... 46 
2.5.2 Діаграма послідовності .................................................................... 48 
2.5.3 Діаграма комунікації ....................................................................... 50 
2.5.4  Діаграма скінченного автомату ..................................................... 51 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ .................................................................................................... 56 
3.1 Розробка програмного комплексу ....................................................... 56 
3.1.1 Обґрунтування вибору засобів реалізації ...................................... 56 
3.1.2 Опис структурної (функціональної) схеми ................................... 57 
3.1.3 Опис логічної схеми системи.......................................................... 61 
3.1.4 Розробка бази даних ........................................................................ 62 
3.1.5 Розробка інтерфейсу користувача .................................................. 66 
3.1.6 Опис розробки програмних компонентів ...................................... 72 
3.2 Тестування системи ................................................................................ 72 
3.2.1 Модульне тестування ...................................................................... 73 
3.2.2 Інтеграційне тестування .................................................................. 73 
3.2.3 Системне тестування ....................................................................... 75 
3.2.4 Приймальне тестування ................................................................... 76 
3.3 Приклади впровадженого програмного комплексу ........................ 76 
ВИСНОВКИ ............................................................................................................. 79 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................ 81 
ДОДАТОК А . ........................................................................................................... 83
ДОДАТОК Б . ........................................................................................................... 85 
ДОДАТОК В . .......................................................................................................... 93
ДОДАТОК Г .......................................................................................................... 102 
ЧДТУ 262258.019 ПЗ 
Змн. Арк. № докум. Підпис Дата 
ЧДТУ.262258.019 ПЗ  
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
Access Key (Ключ доступу) - унікальний криптографічний ідентифікатор, 
що генерується системою для надання доступу до приватних списків бажань. 
API (Application Programming Interface) - прикладний програмний 
інтерфейс, що дозволяє різним компонентам системи взаємодіяти між собою. 
BaaS (Backend-as-a-Service) - хмарна інфраструктура, що надає готові 
сервіси для бекенду (наприклад, бази даних та сервіси авторизації). 
DOM (Document Object Model) - об'єктна модель документа, яка 
представляє внутрішню структуру HTML-сторінки. 
Frontend / Backend - клієнтська (Frontend) та серверна (Backend) частини 
програмного комплексу. 
HTML (HyperText Markup Language) - стандартизована мова розмітки 
документів для перегляду webсторінок у браузері. 
HTTP / HTTPS (HyperText Transfer Protocol Secure) - протокол передачі 
даних (зашифрований), що використовується для мережевої взаємодії між 
клієнтом та сервером. 
JSON (JavaScript Object Notation) - текстовий формат обміну даними, що 
базується на синтаксисі JavaScript та використовується для передачі 
структурованої інформації. 
JWT (JSON Web Token) - стандарт безпечного передавання інформації між 
двома сторонами, який використовується в системі для автентифікації та 
підтримання сесії. 
ORM (Object-Relational Mapping) – об'єктно-реляційне відображення; 
технологія, яка створює віртуальну об'єктну базу даних, дозволяючи 
маніпулювати даними в реляційній базі за допомогою об'єктно-орієнтованих 
парадигм. 
SEO (Search Engine Optimization) – пошукова оптимізація. 
Smart Link Parsing – технологія автоматизації збору метаданих про товари 
(ціна, фото, назва) за їхнім URL-посиланням. 
7 
ЧДТУ.262258.019 ПЗ  
SPA (Single Page Application) - односторінковий webдодаток, який 
завантажує єдиний HTML-документ і динамічно оновлює його під час взаємодії 
користувача без перезавантаження сторінки. 
SSR (Server-Side Rendering) - технологія рендерингу (відображення) 
webсторінок на стороні сервера для оптимізації продуктивності та SEO. 
UI/UX (User Interface / User Experience) - користувацький інтерфейс та 
користувацький досвід. 
UML (Unified Modeling Language) - уніфікована мова моделювання для 
візуалізації, визначення та конструювання архітектури об'єктно-орієнтованих 
систем. 
URL (Uniform Resource Locator) - уніфікований покажчик ресурсу 
(посилання на сторінку інтернет-магазину). 
Web-сервіс (Webдодаток) - програмна система, доступ до якої 
здійснюється користувачем через webбраузер та мережу Інтернет. 
БД – база даних. 
Вішлист (Подарунок) - віртуальна колекція збережених товарів або послуг, 
які користувач бажає отримати як подарунок, з можливістю налаштування рівнів 
доступу. 
Безголовий браузер (Headless Browser) – web-браузер без графічного 
інтерфейсу користувача, що керується програмно та використовується системою 
для автоматизованого доступу до web-сторінок і парсингу даних. 
Валідність (Валідність даних) – ступінь відповідності введених або 
отриманих системою даних (наприклад, посилань на товари) встановленим 
правилам, форматам та архітектурним обмеженням. 
Верстка (Web-верстка) - процес створення візуальної структури та 
оформлення web-сторінки за допомогою мов розмітки (HTML) та каскадних 
таблиць стилів (CSS). 
Десктопний додаток (Desktop Application) - повноцінне програмне 
забезпечення, призначене для встановлення та виконання на локальному 
персональному комп'ютері користувача. 
8 
ЧДТУ.262258.019 ПЗ  
Комунікація - у контексті розробки: процес обміну даними між різними 
програмними модулями (наприклад, між клієнтською та серверною частинами) 
або між користувачем і системою. 
Консистентність даних (Data Consistency) - властивість системи та бази 
даних, що гарантує цілісність, актуальність, точність та узгодженість збереженої 
інформації у будь-який момент часу, незалежно від кількості паралельних 
запитів. 
Контент - інформаційне наповнення web-сторінки (тексти, зображення, 
описи товарів, ціни тощо), яке генерується системою або збирається за 
допомогою парсингу. 
Кооперація - спільна взаємодія кількох архітектурних об'єктів, модулів або 
сервісів системи для виконання єдиної складної задачі (наприклад, спільна 
робота парсера, бази даних та клієнтського інтерфейсу). 
Користувач (User) - суб'єкт, який взаємодіє з програмним забезпеченням. 
У межах розробленої системи поділяється на ролі: власник списку бажань або 
гостьовий відвідувач. 
Маркетплейс (Marketplace) - платформа електронної комерції, яка надає 
єдиний web-простір для продажу товарів і послуг від безлічі незалежних 
продавців, звідки система може автоматично витягувати дані. 
Метатег (Meta tag) - спеціальний HTML-тег, що не відображається на самій 
сторінці, але містить структуровані службові метадані (заголовок, опис, 
зображення), які використовуються парсером для отримання інформації про 
товар. 
Парсинг (Parsing) - процес синтаксичного аналізу коду та 
автоматизованого видобування структурованих даних із web-сторінок. 
ПЗ - програмне забезпечення. 
Рендеринг (Rendering) - процес перетворення програмного коду (HTML, 
CSS, JavaScript) та даних у візуальне відображення інтерфейсу web-сторінки в 
браузері користувача. 
9 
ЧДТУ.262258.019 ПЗ  
Ритейл / Ритейлер (Retail / Retailer) - роздрібна торгівля / компанія, що 
здійснює роздрібний продаж товарів кінцевому споживачеві (наприклад, 
інтернет-магазини, товари з яких зберігаються у список). 
Скрейпінг (Web Scraping) - автоматизований метод збору даних із web-
сайтів за допомогою спеціалізованого програмного забезпечення (часто 
використовується як синонім до web-парсингу). 
Шеринг (Sharing) - процес надання спільного доступу до інформаційних 
ресурсів (у контексті проєкту - поширення унікального посилання на створений 
список бажань для інших осіб). 
  
10 
ЧДТУ.262258.019 ПЗ  
ВСТУП 
Актуальність теми. Визначається потребою у розробці спеціалізованого 
програмного забезпечення для вирішення проблеми хаотичного зберігання ідей 
для подарунків та оптимізації процесу їх дарування. Розробка web-сервісу 
«Подарунок» актуальна завдяки впровадженню технології Smart Link Parsing для 
автоматизації збору даних про товари з популярних українських маркетплейсів 
та унікальної системи приватних ключів доступу. 
Мета і завдання розробки. Мета роботи полягає у проєктуванні та 
реалізації новітнього web-сервісу «Подарунок», який надасть користувачам 
зручний інструмент для структурування побажань, автоматизованого імпорту 
товарів та захищеного поширення списків серед друзів. 
Для досягнення мети виконувались такі завдання: 
‒ провести аналіз предметної області та існуючих аналогів; 
‒ сформулювати функціональні вимоги до системи, включаючи 
механізми приватності та бронювання; 
‒ спроектувати архітектуру системи за допомогою UML-діаграм 
(прецедентів, класів, компонентів, розгортання тощо); 
‒ оцінити ефективність алгоритмів парсингу даних через технічний 
експеримент; 
‒ програмно реалізувати клієнтську та серверну частини з 
використанням сучасного стека технологій; 
‒ виконано комплексне тестування створеного продукту на відповідність 
заявленим вимогам. 
Об’єкт розробки: є процес розробки для програмного забезпечення та 
створення web-орієнтованих інформаційних систем для автоматизації керування 
споживчими потребами (перевагами та списками бажань). 
Предмет розробки: процес побудови програмного забезпечення є методи, 
алгоритми (зокрема Smart Link Parsing) та програмні засоби побудови web-
сервісу «Подарунок». 
Методи проєктування та конструювання. 
11 
ЧДТУ.262258.019 ПЗ  
Для реалізації системи обрано наступний інструментарій: 
1 Next.js (App Router) та TypeScript: використані для створення 
продуктивної клієнтської частини та забезпечення типізації коду. 
2 Supabase (PostgreSQL): хмарна реляційна база даних та система 
автентифікації для безпечного зберігання інформації. 
3 React Context API: для управління глобальним станом авторизації та 
даних списків. 
4 UML та Figma: засоби візуального моделювання архітектури та UI/UX 
дизайну. 
Опис отриманих результатів.  
У ході роботи розроблено повнофункціональний web-сервіс, що включає 
адаптивний інтерфейс під різні платформи, систему автоматичного отримання 
метаданих товару та захищений механізм взаємодії через приватні посилання. 
Спроектовано та впроваджено модульну архітектуру, що дозволяє незалежну 
розробку окремих сервісів. 
Практичне значення отриманих результатів. 
Практичне значення полягає у створенні готового інструменту, який 
вирішує проблему отримання бажаних подарунків та автоматизує збір даних з 
вітчизняних платформ електронної комерції. Впровадження функції 
бронювання, яка надає можливість запрошеним користувачам зручно 
координувати вибір презентів, гарантовано уникаючи ситуацій придбання 
однакових подарунків (речей, послуг). 
Особистий внесок автора: автором проведено повний цикл розробки ПЗ  
від соціологічного дослідження та доменного аналізу до проектування 
архітектури та програмної реалізації всіх модулів системи «Подарунок». 
  
12 
ЧДТУ.262258.019 ПЗ  
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Аналіз предметної області та актуальних проблем планування 
подарунків 
Підготовка до свят постійно стикається з організаційним хаосом. Люди 
пересилають посилання на товари у різних месенджерах або записують ідеї до 
неструктурованих текстових нотаток. Згодом учасники обговорення просто 
втрачають потрібні лінки серед десятків інших повідомлень. 
Відсутність прозорої координації неминуче призводить до дублювання 
подарунків. Іменинник часто розпаковує кілька абсолютно однакових речей від 
різних гостей. Розв'язати цю комунікаційну кризу здатна лише повноцінна 
цифрова система. 
Сучасний web-сервіс має стати єдиним простором для планування подій. 
Якісний сервіс бере на себе всі рутинні завдання. Програма самостійно витягує 
актуальну інформацію з маркетплейсів, керує приватним доступом та надійно 
блокує зарезервовані позиції, захищаючи друзів від повторних покупок. 
Купівля подарунків наосліп часто перетворюється на марнотратство. 
Отримувачам дістаються непотрібні речі, а фінанси витрачаються неефективно. 
Саме тому електронні вішлисти (Подарунок) стали популярним інструментом 
для розв'язання цієї проблеми. 
Предметна область цього дослідження - агрегація товарних даних із різних 
e-commerce платформ у межах однієї системи. Сучасним користувачам бракує 
часу на довгу комунікацію. Їхні бажані товари зазвичай розпорошені по десятках 
різних інтернет-магазинів, від Rozetka і Comfy до нішевих локальних брендів. 
Збирати масиви URL-адрес у звичайних нотатках чи месенджерах вкрай 
незручно. Сухий текст позбавлений візуального контексту: гості не бачать ні 
актуальної ціни, ні фотографії товару. До того ж такий формат ускладнює 
координацію - з'являється ризик подарувати одне й те саме. 
13 
ЧДТУ.262258.019 ПЗ  
Як наслідок, необхідна повноцінна інформаційна система. Вона має не 
просто зберігати лінки, а автоматично витягувати метадані сторінок. Головна 
мета - чітка структуризація контенту та надання зручного інтерфейсу, де гості 
зможуть легко переглядати список і "бронювати" обрані позиції. 
1.2 Огляд існуючих систем та web-додатків для створення вішлистів 
Для визначення функціональних вимог до проектованої системи було 
проведено аналіз існуючих на ринку аналогів. Розглянуто як глобальні 
платформи, так і спеціалізовані рішення: 
1 MyWishBoard 
Провідний сервіс управління списками подарунків, архітектура якого 
містить виражену соціальну складову. 
Переваги:  
 привабливий та естетичний інтерфейс користувача; 
 можливість підписуватися на інших користувачів та переглядати 
стрічку їхніх бажань; 
 присутність широкого вбудованого асортименту подарункових ідей. 
Недоліки: 
‒ агресивна монетизація: велика кількість реклами в безкоштовній версії 
та обмеження функціоналу; 
‒ відсутність повноцінного автоматичного парсингу для більшості 
українських маркетплейсів (дані часто доводиться вводити вручну); 
‒ наявність зайвого соціального функціоналу, що обтяжує процес 
стандартного обміну списками з іншими користувачами. 
2 Giftster 
Популярний міжнародний сервіс, орієнтований на сімейний та груповий 
обмін подарунками. 
Переваги: 
‒ потужний функціонал для створення закритих груп (сімей, колег); 
14 
ЧДТУ.262258.019 ПЗ  
‒ вбудована функція проведення жеребкування "таємний санта" (secret 
santa); 
‒ високий рівень приватності та контроль доступу до списків. 
Недоліки: 
‒ застарілий дизайн інтерфейсу (ui), який не відповідає сучасним 
стандартам web-розробки; 
‒ неадаптованість платформи до специфіки українського ринку 
електронної комерції та відсутність відповідного перекладу 
інтерфейсу; 
‒ складний процес додавання товарів за зовнішніми посиланнями без 
автоматичного витягування зображень. 
3 Вбудовані вішлисти маркетплейсів (наприклад, Amazon Wish List або 
списки бажань на Rozetka) 
Провідні маркетплейси та онлайн-магазини зазвичай пропонують 
користувачам інтегровані механізми для фіксації та збереження обраних позицій. 
Переваги: 
‒ ідеальна інтеграція з екосистемою магазину (додавання товару в один 
клік); 
‒ автоматичне відстеження зміни ціни та наявності товару; 
‒ висока надійність та швидкість роботи. 
Недоліки: 
‒ "вендор-лок" ( прив'язка до одного продавця). користувач не може 
додати в список на rozetka товар з іншого магазину (наприклад, з 
intertop чи локального instagram-магазину); 
‒ обмежені можливості кастомізації самого списку; 
4 Додаток "Moons" (або інші локальні українські стартапи) 
Нові рішення на локальному ринку, які намагаються вирішити проблему 
збору бажань в одному місці. 
Переваги: 
15 
ЧДТУ.262258.019 ПЗ  
‒ сучасний мобільний підхід (орієнтація на використання зі смартфонів); 
‒ підтримка бронювання подарунків друзями (щоб уникнути 
дублювання); 
‒ можливість збирати кошти на великі подарунки (банки/спільна оплата). 
Недоліки: 
‒ часто існують лише у вигляді мобільних додатків (відсутність 
повноцінної web-версії); 
‒ проблеми з парсингом: алгоритми розпізнавання товарів за 
посиланнями часто працюють нестабільно або потребують ручного 
коригування фотографій та цін. 
1.3 Аналіз методів автоматизованого збору даних (парсингу) з web-
сторінок електронної комерції 
Щоб реалізувати головну функцію системи - автоматичне додавання 
товарів за посиланням - потрібно дослідити підходи до веб-парсингу. Оскільки 
сучасні інтернет-магазини мають складну архітектуру та активно посилюють 
захист від ботів, витягувати звідти назви, ціни та зображення стає нетривіальною 
задачею. 
Загалом можна виділити чотири основні методи збору даних: 
1 Синтаксичний аналіз HTML DOM. Суть методу полягає у завантаженні 
вихідного коду сторінки та пошуку потрібних фрагментів через CSS-селектори. 
Це працює швидко і майже не навантажує сервер. Проте є суттєвий мінус: якщо 
контент генерується динамічно через JavaScript (як у більшості сучасних SPA-
додатків), цей підхід безсилий. Крім того, найменша зміна у верстці сайту одразу 
ламає парсер. 
2 Безголові браузери (Headless Browsers). Йдеться про програмне 
керування реальним браузером у фоновому режимі (наприклад, за допомогою 
Playwright або Puppeteer). Головна перевага - можливість повноцінно виконувати 
JS-код. Це дозволяє обходити базовий захист і без проблем читати динамічні 
16 
ЧДТУ.262258.019 ПЗ  
сайти. Але ціна такого рішення висока: сервер споживає забагато ресурсів, а 
запити виконуються значно повільніше, ніж звичайні HTTP-виклики. 
3 Читання мікроданих та метатегів (Open Graph, JSON-LD). Для кращої 
SEO-оптимізації маркетплейси часто розміщують структуровану інформацію у 
тегах <meta property="og:..."> або скриптах application/ld+json. Витягувати дані 
звідти зручно і надійно, адже метадані змінюються набагато рідше, ніж 
візуальний дизайн. Основна проблема лише в тому, що магазини не завжди 
віддають повну картину - наприклад, можуть приховувати поточну ціну чи 
розмір знижки. 
4  Реверс-інжиніринг внутрішніх API. Метод базується на перехопленні 
мережевих запитів браузера під час завантаження сторінки, щоб знайти прямі 
звернення до бекенду. Це дає найчистіший JSON із блискавичною швидкістю. 
Втім, на практиці реалізувати його складно через механізми авторизації, токени 
та динамічні підписи запитів. 
Щоб парсинг працював максимально стабільно, найкраще використати 
комбінований підхід. Спочатку система намагається знайти інформацію у 
стандартизованих метатегах (Open Graph чи JSON-LD). Якщо ж потрібних даних 
там немає, вмикається резервний механізм - DOM-аналіз на базі унікальних 
селекторів, написаних під кожен конкретний магазин. 
1.4 Обґрунтування необхідності розробки власного програмного 
рішення 
На основі проведеного аналізу предметної області та недоліків існуючих 
рішень було сформовано чіткі задачі для проєктування власного програмного 
забезпечення. 
Розроблювана система повинна відповідати наступним критеріям: 
‒ дозволяти зручне створення та управління списками бажань; 
‒ підтримувати додавання товарів за прямим URL-посиланням;автоматично; 
‒ отримувати метадані товару (назву, ціну, зображення) через вбудований 
модуль парсингу; 
17 
ЧДТУ.262258.019 ПЗ  
‒ підтримувати гнучкі налаштування приватності (доступ за посиланням або 
згенерованим ключем); 
‒ містити функціонал бронювання подарунків гостями для уникнення 
дублювання; 
‒ бути повністю адаптивною для мобільних та десктопних пристроїв. 
На основі проведеного огляду існуючих систем управління списками 
бажань та аналізу методів парсингу даних, було виявлено низку суттєвих 
недоліків у наявних на ринку продуктах. Жодна з проаналізованих платформ не 
забезпечує комплексного задоволення потреб користувачів, зокрема: 
‒ відомі міжнародні сервіси, такі як giftster чи mywishboard, не мають 
належної адаптації до специфіки українського електронного 
маркетингу. Їхні вбудовані алгоритми парсингу не здатні коректно 
витягувати дані з популярних українських маркетплейсів, що змушує 
користувача заповнювати інформацію про товар вручну; 
‒ системи внутрішніх вішлистів великих рітейлерів обмежують 
користувача асортиментом лише одного магазину, позбавляючи 
можливості створення єдиного агрегованого списку бажань; 
‒ переважна кількість існуючих на ринку рішень характеризується 
неактуальним візуальним дизайном (UI) та вузьким функціоналом 
резервування товарів, що часто супроводжується наявністю 
надлишкових соціальних модулів і нав'язливих стратегій монетизації.  
Зважаючи на вищезазначене, розробка власного web-сервісу є 
обґрунтованою та своєчасною. Розроблена система (Подарунок) має вирішити 
описані проблеми шляхом реалізації унікального модуля розпізнавання 
посилань, який цілеспрямовано розроблений та глибоко адаптований під 
архітектуру локальних українських інтернет-магазинів та їхні специфічні 
системи захисту від ботів. 
Створення єдиної, зручної платформи з функціями парсингу, спільного 
доступу та системою бронювання значно спростить процес координації 
подарунків між користувачами.  
18 
ЧДТУ.262258.019 ПЗ  
ВИСНОВКИ ДО РОЗДІЛУ 1 
У межах першого розділу здійснено глибокий аналіз цільової предметної 
області, а також комплексно розглянуто специфіку підбору та вручення 
презентів у реаліях сьогодення.  
Виконано огляд існуючих програмних рішень для створення електронних 
вішлистів, виявлено їхні переваги та недоліки. Встановлено, що ключовою 
проблемою більшості платформ є відсутність якісної адаптації алгоритмів збору 
даних для специфічних українських інтернет-магазинів.  
Здійснено огляд ключових технологій автоматичного збору інформації з 
web-сторінок, за результатами якого доведено, що поєднання парсингу DOM-
структури та вилучення метаданих (гібридний метод) є найефективнішим 
інструментом для реалізації цілей цього проекту. 
 На основі виявлених недоліків існуючих систем обґрунтовано доцільність 
і необхідність розробки власного web-сервісу, який забезпечить зручне 
агрегування товарів з різних локальних майданчиків, автоматизацію збору даних 
та зручні інструменти спільного доступу.  
19 
ЧДТУ.262258.019 ПЗ  
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
2.1 Моделювання предметної області 
Архітектура будь-якого програмного продукту формується навколо 
чіткого опису предметної області. Замість миттєвого переходу до написання 
коду, інженер спершу створює логічну модель системи. Отримана абстракція 
розкриває ключові модулі сервісу та алгоритми взаємодії між ними. 
Платформа Подарунок має комплексну бізнес-логіку, тому вимагає 
глибокого попереднього аналізу. Найбільшої уваги потребує механізм 
автоматичної агрегації товарів із зовнішніх маркетплейсів. Паралельно 
розробник формує структуру бази даних для збереження користувацьких 
профілів та управління подарунковими списками. Замикає архітектурне ядро 
самостійний модуль безпеки та розмежування прав доступу. 
Візуалізація згаданих процесів через графічні схеми майже повністю 
виключає ризик фундаментальних помилок. Відповідно, програміст витрачає 
набагато менше ресурсів на переписування логіки під час активної фази 
кодування чи фінального релізу. 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметна область моделювання. Аналіз предметної області охоплює 
чотири головні напрямки. Наш сервіс керує колекціями бажань, збирає 
інформацію з маркетплейсів, налаштовує приватність та забезпечує соціальну 
взаємодію між гостями. Відвідувачі створюють нові позиції вручну або просто 
імпортують їх через URL-посилання. Паралельно платформа самостійно генерує 
криптографічні ключі для закритих профілів та обробляє алгоритми бронювання.  
Модель предметної області. Архітектура даних спирається на тісну 
взаємодію шести базових сутностей: User (Користувач), Wishlist (Список 
20 
ЧДТУ.262258.019 ПЗ  
бажань), Item (Товар), AccessKey (Ключ доступу), Booking (Бронювання) та 
Parser (Модуль збору даних).  
Ядром інформаційної моделі виступає об'єкт Wishlist. Цей контейнер 
завжди підпорядковується конкретному власнику (User) і зберігає масив 
цільових речей (Item). Спеціальний токен AccessKey надійно захищає приватні 
добірки від сторонніх очей. Натомість сутність Booking безперервно відстежує 
дії аудиторії та миттєво блокує вже зарезервовані подарунки. 
Щоб уникнути неоднозначностей під час проектування, необхідно 
зафіксувати словник предметної області. У межах платформи Подарунок ми 
оперуємо кількома базовими поняттями: 
 список бажань (Подарунок) - персональна добірка товарів чи послуг. 
власник формує її для майбутніх покупок або як підказку друзям щодо 
подарунків. кожній такій колекції можна призначити окремий рівень 
приватності: зробити повністю відкритою, приховати від усіх або 
дозволити перегляд лише за спеціальним лінком; 
 парсер (Parser) - спеціальний програмний модуль. він приймає url-адресу з 
інтернет-магазину, читає вихідний код сторінки та самостійно витягує 
звідти корисну інформацію. сюди входять назва позиції, її вартість та 
головне фото; 
 бронювання (Booking) - механізм закріплення подарунка. коли гість обирає 
певну річ, база даних одразу фіксує зміну статусу. завдяки цьому інші 
відвідувачі бачать, що товар вже зайнятий, і не купують його вдруге; 
 JSON Web Token (JWT) - криптографічний стандарт. наш додаток генерує 
такі токени для безпечної авторизації. вони допомагають серверу 
підтверджувати особу клієнта і підтримувати активну сесію без 
повторного введення пароля; 
 ORM (Object-Relational Mapping) - підхід до роботи з базами даних. 
інструмент перетворює таблиці postgresql на звичайні програмні об'єкти. 
програміст отримує змогу маніпулювати записами через методи класів, 
повністю уникаючи написання прямих sql-запитів; 
21 
ЧДТУ.262258.019 ПЗ  
 ключ доступу (Access Key) - унікальний зашифрований маркер. бекенд 
створює його для конкретного закритого вішлиста. якщо неавторизована 
людина переходить за посиланням із таким ключем, вона отримує 
тимчасові права на перегляд і бронювання; 
 користувач (User) - будь-яка людина або зовнішній сервіс, що 
безпосередньо взаємодіє з системою. залежно від наданих прав, суб'єкт 
може виступати в ролі адміністратора, власника профілю або звичайного 
гостя. 
2.1.2 Елементи моделювання предметної області  
Головним інструментом для проектування архітектури у цій роботі 
виступає UML. Unified Modeling Language давно закріпилася як світовий 
стандарт в інженерії програмного забезпечення. Графічний синтаксис цієї мови 
допомагає однозначно показати статику і динаміку об'єктно-орієнтованого коду. 
Завдяки цьому інші розробники зможуть без проблем прочитати створені схеми. 
UML чудово підходить для візуалізації концептуальних і логічних моделей веб-
додатка. 
У таблиці 2.1 зібрано ключові елементи моделювання. Саме з них 
складатимуться діаграми в наступних розділах проекту. Стандартні позначення 
роблять складну архітектуру прозорою. На графіках одразу видно, як 
клієнтський інтерфейс взаємодіє з модулем парсингу або звертається до хмарної 
бази даних. 
 
Таблиця 2.1 
Елементи моделювання предметної області 
Графічний 
Назва елемента Опис використання в проекті 
символ (Тип) 
Відображає сутності, які взаємодіють із 
Дійова особа системою: кінцевих користувачів (Гість, 
Користувач 
(User) Авторизований користувач, Адміністратор) 
або системні фонові процеси системи.  
22 
ЧДТУ.262258.019 ПЗ  
Продовження таблиці 2.1 
Описує конкретну бізнес-функцію системи, 
Варіант яку ініціює Користувач (наприклад, 
Овал використання «Створити новий список бажань», «Додати 
(Use Case) товар за посиланням», «Забронювати 
подарунок»).  
Використовується для групування логічно 
Прямокутник з пов'язаних класів, компонентів або 
Пакет (Package) 
вкладкою директорій коду (наприклад, пакети 
lib/parser, app/api, components).  
Описує програмні абстракції та сутності 
реляційної бази даних (User, Подарунок, 
Прямокутник 
Клас (Class) Item) з їхніми атрибутами (полями) та 
(3 секції) 
доступними методами обробки даних (згідно 
з визначеною схемою Prisma).  
Прямокутник з Компонент Відображає фізичні або логічні модулі 
іконкою (Component) системи, які можна замінювати або 
оновлювати незалежно (React-компоненти 
інтерфейсу, парсери конкретних магазинів, 
API-контролери).  
Відображає фізичні, апаратні або хмарні 
обчислювальні ресурси, на яких 
Куб Вузол (Node) розгортається система та виконуються її 
компоненти (локальний сервер додатку, 
кластери Supabase).  
Відображає поточний стан конкретного 
Прямокутник із 
об'єкта в певний момент часу (наприклад, 
закругленими Стан (State) 
стан товару: «Доступний», «Заброньовано», 
кутами 
або стан виконання алгоритму парсингу).  
23 
ЧДТУ.262258.019 ПЗ  
Продовження таблиці 2.1 
Показує проміжок часу на діаграмах 
Пунктирна Лінія життя послідовності, протягом якого об'єкт або 
лінія (Lifeline) Користувач бере активну участь в 
інформаційній взаємодії.  
Вказує на умовні переходи та перевірки в 
Розгалужувач алгоритмах (наприклад, перевірка чи є товар 
Ромб 
(Decision) в наявності, чи вірний пароль, чи валідний 
секретний ключ доступу до списку).  
Відображає семантичний або структурний 
Відношення зв'язок між двома сутностями бази даних 
Суцільна лінія 
асоціації (наприклад, зв'язок типу "один-до-багатьох" 
між Користувачем та Списком).  
Вказує, що зміна одного архітектурного 
Пунктирна Відношення елемента може безпосередньо вплинути на 
стрілка залежності працездатність іншого (наприклад, 
залежність UI від формату відповіді API).  
 
2.1.3 Робоча область моделювання  
Архітектура розроблюваного веб-додатка базується на шести ключових 
інформаційних потоках. У комплексі наведені етапи формують повний життєвий 
цикл обробки користувацьких даних: 
1 Автентифікація клієнта. Захищений сервіс Supabase Auth приймає 
облікові дані через зашифрований канал і генерує сесійний JWT-токен. 
Згенерований маркер надалі використовується сервером для безперервної 
верифікації всіх наступних API-запитів. 
2 Отримання вхідних параметрів. Клієнтська частина інтерфейсу фіксує 
дії відвідувача, починаючи від створення нового списку бажань до 
введення URL-посилання на конкретний товар. Зібраний пакет 
конфігурацій ініціює звернення до сервера для виконання бізнес-логіки. 
24 
ЧДТУ.262258.019 ПЗ  
3 Парсинг маркетплейсів. Отримавши лінк, сервер активує компонент 
lib/parser для виконання серії асинхронних HTTP-запитів до цільових 
платформ формату Rozetka чи Comfy. Програмний скрипт обходить 
системи захисту, аналізує HTML-структуру сторінки та витягує актуальну 
ціну, точну назву і посилання на фотографію. 
4 Збереження результатів. Сирі дані після парсингу проходять етап 
нормалізації та приведення до строгих типів згідно з моделями Prisma 
ORM. Опрацьована інформація записується в таблиці PostgreSQL із 
паралельним формуванням необхідних реляційних зв'язків. 
5 Синхронізація інтерфейсу. Бекенд відправляє структуровану відповідь 
формату JSON назад на фронтенд. Отриманий результат дозволяє оновити 
стан додатка в реальному часі без примусового перезавантаження 
сторінки. 
6 Бронювання та управління доступом. Програмна підсистема валідує 
унікальні Access Keys для відкриття приватних списків. У момент 
бронювання подарунка гостем база даних миттєво фіксує статус booked, а 
власник профілю одразу бачить оновлену статистику у власному кабінеті. 
Схема основних потоків інформації системи представлена на рис. 2.1.  
 
 
Рисунок 2.1 – Інформаційні потоки розроблюваної системи 
25 
ЧДТУ.262258.019 ПЗ  
2.2 Формування та аналіз вимог 
Успішна розробка програмного забезпечення завжди спирається на 
глибокий аналіз вимог. Інженер повинен чітко бачити кінцеві завдання системи 
та умови її майбутньої експлуатації. Саме етап збору специфікацій диктує 
функціональне наповнення та встановлює жорсткі архітектурні межі проєкту. 
Проектування платформи Подарунок супроводжувалося детальним 
дослідженням потреб цільової аудиторії. Базова ідея полягає у створенні 
зручного інструменту, де відвідувачі зможуть централізовано зберігати бажані 
товари. Головною конкурентною перевагою нашого додатка виступає модуль 
автоматичного парсингу. Скрипт самостійно витягує назви, фотографії та 
актуальні цінники зі сторінок інтернет-магазинів. Користувачам більше не 
доведеться витрачати час на ручне копіювання цих параметрів. 
Зібрана інформаційна база потребує суворої класифікації. Загальний масив 
завдань ми поділили на три фундаментальні категорії: первинні бізнес-вимоги, 
функціональні специфікації та нефункціональні обмеження. 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги. 
Первинні вимоги фіксують глобальні цілі продукту та відображають 
вимоги замовника. Згідно з технічним завданням, система виконує чотири базові 
бізнес-функції: 
 управління профілем. реєстрація та безпечна авторизація відвідувачів; 
 робота зі списками. створення, редагування та безповоротне видалення 
вішлистів. кожен етап супроводжується налаштуванням приватності; 
 наповнення колекцій. користувач додає товари вручну або передає 
парсеру готовий url; 
 соціальна взаємодія. відвідувачі шукають профілі друзів, переглядають 
відкриті добірки та бронюють подарунки. 
26 
ЧДТУ.262258.019 ПЗ  
Архітектурні межі та зовнішні зв'язки описує діаграма варіантів 
використання (Use Case Diagram). Схема чітко показує наявні ролі та доступні їм 
прецеденти. Графічне відображення бізнес-функцій наведено на рисунку 2.2. 
Глобальні цілі диктують конкретні технічні завдання для етапу кодування, 
які складають вимоги розробника. Платформа Подарунок отримала наступний 
перелік детальних вимог: 
 адаптивний фронтенд. інтерфейс будується за принципами responsive 
web design. верстка автоматично підлаштовується під монітори, 
планшети і смартфони; 
 захищена авторизація. сервер генерує сесійні JWT-токени. база даних 
зберігає виключно криптографічні хеші паролів; 
 модульний парсинг. алгоритм збору інформації має гнучку структуру. 
розробник отримує змогу підключати нові інтернет-магазини без 
втручання в основне ядро; 
 рівні доступу. власник списку самостійно керує видимістю колекції. 
додаток підтримує три статуси: публічний, прихований або доступний 
за зашифрованим лінком (Access Key); 
 інтернаціоналізація (i18n). клієнтська частина підтримує динамічне 
перемикання мов. локалізація інтерфейсу розширює потенційну 
аудиторію сервісу. 
У контексті проектування системи вимоги розподіляють на два 
взаємопов'язані рівні: 
‒ вимоги замовника фокусуються на бізнес-логіці та кінцевому 
користувацькому досвіді (UX). Вони визначають загальний вектор 
розвитку продукту: надання зручного сервісу для ведення списків 
бажань, автоматизація збору даних про товари (щоб користувачу не 
доводилося вносити інформацію вручну), гнучке керування 
приватністю для захисту особистих даних; 
27 
ЧДТУ.262258.019 ПЗ  
‒ вимоги розробника трансформують цілі замовника у конкретні технічні 
обмеження, стек технологій та архітектурні стандарти. Вони 
передбвачають використання фреймворку Next.js для оптимального 
рендерингу (SSR/ISR) та побудови API, СУБД PostgreSQL та Prisma 
ORM для надійної роботи з даними, інтеграції автентифікації через 
Supabase Auth, а також створення стійкої системи автоматичного 
парсингу веб-сторінок з обходом засобів захисту від ботів. 
Функціональні вимоги 
Технічний функціонал додатка охоплює п'ять логічних підсистем, кожна з 
яких обробляє специфічні запити користувачів та внутрішні події: 
– облікові записи. Модуль забезпечує реєстрацію нових профілів із 
обов'язковою валідацією пошти та пароля. Бекенд відповідає за 
безпечну авторизацію, гарантоване знищення сесії при виході та 
механізм відновлення доступу. У налаштуваннях кабінету клієнт 
редагує власне ім'я, завантажує аватарку та обирає мову інтерфейсу; 
– списки бажань. Підсистема дозволяє формувати нові колекції із 
зазначенням назви, опису та рівня приватності. Створені записи 
підтримують подальше редагування або повне видалення з бази даних. 
Щоб обмежити видимість прихованих списків, сервер генерує 
унікальний ідентифікатор Access Key для надання прав доступу 
конкретним особам; 
– управління товарами. Логіка платформи підтримує автоматичний 
імпорт подарунків через передачу URL-адреси обраного маркетплейсу. 
Замість автоматизації користувач має змогу заповнити форму вручну, 
вказавши назву, вартість, валюту та посилання на зображення. 
Збережені позиції вільно переміщуються між колекціями або повністю 
видаляються з профілю; 
– автоматизований парсинг. Компонент розпізнає цільовий інтернет-
магазин за доменним ім'ям та ініціює асинхронні HTTP-запити з 
28 
ЧДТУ.262258.019 ПЗ  
емуляцією браузера. Вбудовані алгоритми оминають Anti-Bot захист 
популярних e-commerce платформ і аналізують DOM-структуру 
сторінки. На фінальному етапі скрипт витягує чисті метадані, 
включаючи актуальну ціну, назву, головне фото та статус наявності 
товару; 
– соціальна взаємодія. Блок містить систему пошуку публічних профілів 
та механізм доступу до приватних вішлистів через введення Access 
Key. Запрошені гості маркують обрані позиції статусом 
«Заброньовано», що миттєво відображається в статистиці власника 
колекції. Разом з тим кожен учасник переглядає список власних 
обіцяних подарунків в окремому розділі кабінету. 
Нефункціональні вимоги 
Нефункціональні вимоги визначають атрибути якості розроблюваної 
програмної системи, її системні обмеження, продуктивність та ключові вимоги 
до архітектури: 
1 Продуктивність (Performance)  
Серверна частина додатку повинна забезпечувати швидку обробку 
стандартних API-запитів (до 500 мс). Час очікування результатів автоматичного 
парсингу під час додавання товару за посиланням не повинен перевищувати 
прийнятні межі (у середньому до 5-10 секунд на один товар). Клієнтський 
інтерфейс має миттєво реагувати на дії користувача, використовуючи механізми 
оптимістичного оновлення інтерфейсу (Optimistic UI). 
2 Безпека (Security) 
 Усі передачі даних між клієнтським пристроєм та сервером мають 
здійснюватися виключно за зашифрованим протоколом HTTPS. Паролі 
користувачів суворо заборонено зберігати у відкритому вигляді. Маршрути API, 
які виконують мутації в базі даних (створення, оновлення, видалення), повинні 
29 
ЧДТУ.262258.019 ПЗ  
бути захищені обов'язковою перевіркою валідності токена доступу на стороні 
сервера. 
3 Надійність та відмовостійкість (Reliability and Fault Tolerance) 
Підсистема збору даних має бути стійкою до непередбачуваних змін у 
розмітці інтернет-магазинів. У разі неможливості автоматично вилучити дані за 
наданим посиланням, система не повинна викликати критичний збій (Crash). У 
такій ситуації система зобов'язана безпечно перехопити програмний виняток 
(Exception), зафіксувати відповідний запис у журналі подій (логах) та надати 
користувачу альтернативний інтерфейс для ручного заповнення інформації про 
товар. 
4 Масштабованість (Scalability) 
Програмна архітектура повинна дозволяти горизонтальне масштабування 
серверної частини у хмарному середовищі у разі збільшення навантаження. Крім 
того, структура коду має підтримувати легке додавання нових парсерів для 
інших магазинів через реалізацію стандартизованого інтерфейсу. 
5 Ергономічність та зручність використання (Usability) 
Інтерфейс користувача повинен відповідати сучасним стандартам UX/UI 
дизайну. Навігація системою має бути логічною та передбачуваною. 
Обов'язковою вимогою є коректна робота функціоналу на сенсорних екранах 
мобільних пристроїв, оскільки значна частина користувачів взаємодіятиме зі 
списками бажань за допомогою смартфонів. 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
Створені діаграми (рисунки 2.2 та 2.3) демонструють чотири основні ролі. 
Кожен актор отримує власну зону відповідальності всередині платформи: 
 нереєстрований гість. Відвідувач працює виключно з відкритим 
інтерфейсом. Базовий функціонал охоплює перегляд загальної стрічки 
подарунків (Discover), пошук чужих профілів та відкриття приватних 
вішлистів за наявності секретного ключа. Також людина ініціює 
реєстрацію, авторизацію чи процедуру відновлення пароля. 
30 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.2 – Діаграма варіантів використання (частина 1) системи 
31 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.3 – Діаграма варіантів використання (частина 2) 
32 
ЧДТУ.262258.019 ПЗ  
1 Учасники системи та їхні ролі 
 авторизований користувач. Клієнт успадковує всі можливості гостя та 
переходить до особистого кабінету. Власник профілю створює, редагує 
або видаляє власні колекції. Інтерфейс дозволяє додавати товари 
вручну або запускати автоматичний імпорт за URL-адресою. 
Додатково учасник керує пріоритетністю подарунків, залишає нотатки 
та бронює позиції в чужих списках; 
 адміністратор. Профіль із розширеними правами на базі звичайного 
користувача. Робота такого актора зосереджена в окремій панелі для 
налагодження алгоритмів (Debug) та примусового оновлення товарних 
даних у базі; 
 автоматизований парсер. Зовнішній системний учасник. Програмний 
модуль фоново виконує прецедент збору інформації (цінники, 
фотографії) безпосередньо зі сторінок інтернет-магазинів. 
2 Логічні зв'язки між прецедентами 
Внутрішня архітектура спирається на дві стандартні UML-залежності. 
Вони деталізують поведінку окремих модулів: 
 залежність <<include>> (Включення). Базовий прецедент додавання 
товару за посиланням завжди викликає парсинг даних. Аналогічний 
жорсткий зв'язок існує для примусового оновлення інформації. Процес 
автоматичного витягування метаданих залишається невід'ємним 
кроком під час обробки будь-яких зовнішніх URL-адрес; 
 залежність <<extend>> (Розширення). Механізм застосовується для 
необов'язкових сценаріїв. Наприклад, логіка створення чи редагування 
списку розширюється генерацією Access Key лише тоді, коли автор 
вмикає приватний режим видимості. Іншим прикладом слугує 
скидання пароля, яке відбувається виключно після успішної 
верифікації запиту системою. 
Побудована модель варіантів використання закриває етап проєктування 
високорівневої логіки. Отримані результати виступають базою для розробки 
структури реляційної бази даних та написання коду бекенд-сервісів. 
33 
ЧДТУ.262258.019 ПЗ  
3 Проектування логічної структури програмного комплексу 
Перехід від узгоджених вимог до реалізації продукту завжди починається 
з логічного проєктування. Розробник заздалегідь продумує внутрішню будову 
сервісу, формати збереження інформації і взаємодію між окремими модулями. 
Статичну структуру платформи Подарунок найкраще передають дві UML-
схеми: діаграма класів та діаграма компонентів. Попередня візуалізація 
архітектури допомагає грамотно налаштувати базу даних. Відповідно, 
програміст повністю уникає серйозних логічних конфліктів безпосередньо під 
час написання коду. 
2.3.1 Діаграма класів 
Графічне представлення класів розкриває об'єктно-орієнтовану структуру 
сервісу. Схема показує таблиці бази даних, внутрішні атрибути, типи колонок та 
методи взаємодії. Оскільки бекенд працює через інструмент ORM, побудована 
діаграма фактично є прямою проєкцією реляційної бази. На рисунку 2.4 
зображено діаграму класів. 
Загальна архітектура спирається на три головні моделі: 
– user (Користувач). Головний блок збереження облікових даних. Запис 
вміщує унікальний ідентифікатор, пошту, ім'я клієнта, лінк на аватарку 
та дату реєстрації. Додатково логіка містить функції оновлення 
профілю та перевірки прав доступу; 
– Подарунок (Список). Контейнер для агрегації подарунків. Таблиця 
фіксує назву добірки, текстовий опис, параметри видимості та 
згенерований Access Key. Окремий користувач вільно створює безліч 
незалежних колекцій завдяки зв'язку «один-до-багатьох»; 
– item (Товар). Опис конкретної збереженої речі. Структура включає 
URL-адресу маркетплейсу, цінник, назву, фотографію та поточний стан 
бронювання. Позиція завжди належить конкретному вішлисту. 
Паралельно запис зберігає посилання на гостя, який готує подарунок; 
34 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.4 – Діаграма класів системи (таблиця із користувачами – у кожного 
користувача може бути багато списків побажань) 
 
Надійна база даних потребує точного підбору типів колонок для кожної 
моделі. Суворі формати гарантують цілісність збереженої інформації та помітно 
прискорюють виконання SQL-запитів. Програмна частина проєкту взаємодіє зі 
сховищем через інструмент ORM. Відповідно, розробник описує архітектуру 
таблиць виключно декларативно. Таблиці 2.2 – 2.4 містять вичерпну 
специфікацію головних сутностей сервісу. 
35 
ЧДТУ.262258.019 ПЗ  
Таблиця 2.2 
Опис атрибутів реляційної моделі User (Користувач) 
Назва Тип даних Властивості та 
Призначення атрибута 
поля БД обмеження 
id UUID Primary Key (PK), Унікальний ідентифікатор 
Unique користувача в системі. 
name VARCHAR Not Null Ім'я користувача для 
відображення в інтерфейсі. 
username VARCHAR Unique, Not Null Унікальний нікнейм 
користувача. 
email VARCHAR Unique, Not Null Електронна пошта для 
авторизації та відновлення 
пароля. 
password VARCHAR Not Null Зашифрований (хешований) 
пароль для авторизації. 
avatar VARCHAR Nullable Посилання на зображення 
(Опціонально) профілю користувача. 
bio TEXT Nullable Коротка інформація про 
(Опціонально) користувача ("Про себе"). 
isAdmin BOOLEAN Default(False) Прапорець, що визначає 
наявність прав адміністратора. 
createdAt TIMESTAMP Default(Now) Системна дата та час 
створення облікового запису. 
updatedAt TIMESTAMP  Системна дата та час 
останнього оновлення 
профілю. 
36 
ЧДТУ.262258.019 ПЗ  
Таблиця 2.3  
Опис атрибутів реляційної моделі Подарунок (Список бажань) 
Назва Тип даних Властивості та 
Призначення атрибута 
поля БД обмеження 
id UUID Primary Key (PK), Унікальний ідентифікатор 
Unique списку бажань. 
userId UUID Foreign Key (FK), Вказує на автора списку. 
Not Null Зв'язок з таблицею User. 
name VARCHAR Not Null Назва списку (наприклад, 
"Подарунки на День 
Народження"). 
description TEXT Nullable Детальний опис списку або 
(Опціонально) побажання автора для гостей. 
isPrivate BOOLEAN Default(False) Прапорець приватності. 
Визначає, чи прихований 
список. 
emoji VARCHAR Nullable Іконка (емоджі) для візуального 
(Опціонально) виділення списку. 
accessKey VARCHAR Unique, Nullable Згенерований криптографічний 
ключ для доступу за приватним 
посиланням. 
createdAt TIMESTAMP Default(Now) Системна дата та час створення 
списку. 
updatedAt TIMESTAMP  Системна дата та час 
останнього оновлення списку. 
37 
ЧДТУ.262258.019 ПЗ  
Таблиця 2.4 
Опис атрибутів реляційної моделі Item (Товар) 
Назва поля Тип даних Властивості та Призначення 
БД обмеження атрибута 
id UUID Primary Key (PK), Unique Унікальний 
ідентифікатор 
конкретного товару. 
ПодарунокId UUID Foreign Key (FK), Not Null Вказує, до якого списку 
належить цей товар. 
url VARCHAR Nullable (Опціонально) Посилання на товар у 
зовнішньому інтернет-
магазині. 
title VARCHAR Not Null Назва товару. 
price DECIMAL Nullable (Опціонально) Актуальна ціна товару. 
oldPrice DECIMAL Nullable (Опціонально) Стара ціна товару (до 
знижки). 
image VARCHAR Nullable (Опціонально) Посилання на 
зображення товару. 
store VARCHAR Nullable (Опціонально) Назва магазину, де 
продається товар. 
priority INTEGER Default(0) Пріоритет бажаності 
подарунка (наприклад, 
від 1 до 5). 
notes TEXT Nullable (Опціонально) Додаткові нотатки до 
товару (розмір, колір, 
специфікації). 
isBooked BOOLEAN Default(False) Статус бронювання 
товару (щоб уникнути 
дублювання 
подарунків). 
38 
ЧДТУ.262258.019 ПЗ  
Продовження таблиці 2.4 
bookedById UUID Foreign Key (FK), Nullable Вказує на користувача 
(гостя), який 
забронював цей товар. 
 
2.3.2 Діаграми пакетів 
Щоб уникнути хаосу під час масштабування коду, розробники звертаються 
до пакетного проєктування. Відповідна UML-схема групує класи, модулі та 
інтерфейси у незалежні логічні блоки. Такий розподіл створює чіткий простір 
імен і наочно демонструє зв'язки між внутрішніми підсистемами сервісу. 
Платформа Подарунок працює на базі фреймворку Next.js. Ця технологія 
диктує суворий розподіл логіки між фронтендом, серверним ядром та шаром 
бази даних. Саме тому ми побудували окрему структурну модель для кожного 
архітектурного рівня. 
Організація клієнтської частини (Front-end) 
Клієнтський рівень відповідає виключно за рендеринг інтерфейсу, 
локальний стан та пряму взаємодію з відвідувачем. Директорії коду тут розділені 
суворо за функціональним призначенням: 
– каталог app/ (Pages & Routes). Головна точка входу для відображення UI. 
Тут лежать готові сторінки профілю, вікна авторизації та публічні стрічки 
подарунків; 
– каталог components/. Сховище незалежних візуальних елементів. 
Програміст складає фінальний інтерфейс із дрібних готових блоків: 
кнопок, форм, карток товарів та модальних вікон; 
– каталог hooks/. Блок інкапсульованої React-логіки. Написані тут функції 
керують спливаючими сповіщеннями або перевіряють тип пристрою 
користувача (мобільний чи десктоп); 
– каталог styles/. Директорія зберігає загальні правила візуального 
оформлення та конфігураційні файли CSS-фреймворку Tailwind. 
39 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.5 – Діаграма пакетів клієнтської частини 
 
2.4 Архітектурне проектування 
Архітектурне проєктування визначає загальну логічну та фізичну 
структуру програмної системи, склад її основних компонентів, способи взаємодії 
між клієнтською та серверною частинами. 
Для веб-сервісу «Подарунок» архітектура побудована за сучасним клієнт-
серверним принципом. Як фундаментальні технології обрано Next.js для 
побудови інтерфейсу та API-маршрутів, Supabase Auth для управління сесіями, 
хмарну БД PostgreSQL та інструмент Prisma ORM для об'єктно-реляційного 
відображення. Окремим незалежним вузлом виступає модуль автоматичного 
парсингу товарів. 
 На рисунках 2.6 – 2.7 зображено діаграму пакетів. 
Організація серверної частини (Back-end) 
Серверне ядро бере на себе всю бізнес-логіку, перевірки безпеки та 
інтеграцію із зовнішніми API. Оскільки проєкт працює на базі Next.js, бекенд 
функціонує через систему API Routes та вбудовані модулі Node.js. Серверні 
директорії отримали чіткий розподіл: 
– каталог app/api/. Маршрутизація бекенд-запитів. Контролери 
приймають HTTP-виклики від фронтенду, реєструють відвідувачів, 
повертають списки та обробляють бронювання; 
40 
ЧДТУ.262258.019 ПЗ  
– каталог lib/parser/. Ізольоване середовище для збору товарної 
інформації. Директорія ховає всередині скриптове ядро парсера та 
окремі конфігураційні файли під кожен маркетплейс (у папці sites/); 
– каталог utils/supabase/. Набір допоміжних інструментів. Написані тут 
Middleware-функції валідують сесійні JWT-токени та жорстко 
перевіряють рівень авторизації ще до виконання основного коду. 
 
 
Рисунок 2.6 – Діаграма пакетів серверної частини 
 
Організація шару доступу до даних (Data Access Layer) 
Шар доступу виконує три фундаментальні функції. Програмний код 
безпечно зберігає, кешує та швидко витягує інформацію зі сховища. Розробники 
навмисно ізолюють цю логіку в окремі директорії. Жорстка сегрегація коду 
створює додатковий бар'єр безпеки. Завдяки цьому інженер зможе вільно 
змінити провайдера бази у майбутньому, взагалі не чіпаючи основні бізнес-
процеси додатка. 
41 
ЧДТУ.262258.019 ПЗ  
Взаємодія з інформаційним ядром відбувається через три ключові 
компоненти: 
– каталог prisma/. Центр управління об'єктно-реляційним 
відображенням. Внутрішні файли описують декларативну схему бази 
(Data Schema). Додатково папка зберігає налаштування інструменту 
ORM та історію всіх міграцій; 
– файл lib/db.ts. Точка ініціалізації клієнта бази. Скрипт створює єдине 
підключення і підтримує стабільний пул з'єднань (Connection Pool) для 
захисту сервера від перевантажень; 
– файл lib/auth.ts. Налаштування зовнішньої авторизації. Модуль 
безпосередньо керує інтеграцією з BaaS-провайдером Supabase. 
 
 
Рисунок 2.7 – Діаграма пакетів рівня даних 
 
2.4.1 Діаграма компонентів 
Діаграма компонентів (Component diagram) ілюструє фізичну структуру 
розробленого програмного забезпечення, показуючи організацію його модулів, 
бібліотек, виконуваних файлів та залежності між ними. Для webдодатку 
управління списками бажань архітектуру побудовано за принципом клієнт-
серверної взаємодії з використанням сучасних фреймворків та хмарних сервісів. 
42 
ЧДТУ.262258.019 ПЗ  
Програмний комплекс складається з наступних ключових компонентів: 
‒ модуль користувацького інтерфейсу (frontend ui) спроєктовано та 
побудовано із застосуванням сучасного технологічного стека, основу 
якого складають бібліотека react та фреймворк next.js. відповідає за 
відображення сторінок додатку, форм авторизації, каталогів товарів та 
управління станом на стороні клієнта. взаємодіє із сервером шляхом 
відправлення асинхронних http-запитів; 
‒ компонент «api сервер» (backend api) - серверна частина системи, 
реалізована за допомогою механізму next.js api routes. цей модуль 
включає контролери, що відповідають за реалізацію системної бізнес-
логіки: адміністрування сесій користувачок (процеси реєстрації та 
авторизації), формування вішлистів, генерування індивідуальних 
ключів доступу, а також опрацювання транзакцій резервування 
подарунків; 
‒ компонент «модуль парсингу» (parser component) - спеціалізований 
ізольований модуль (підсистема), який відповідає за автоматизований 
збір даних. отримуючи url-посилання від api сервера, цей компонент 
звертається до зовнішніх інтернет-магазинів, аналізує html-структуру 
сторінок та витягує метадані про товар (назву, актуальну ціну, 
зображення); 
‒ компонент «ORM та доступ до даних» (prisma client) - проміжний шар 
(middleware), що забезпечує об'єктно-реляційне відображення. він 
транслює виклики з api сервера у sql-запити та керує міграціями; 
‒ вузол «база даних» (database) - хмарне сховище на базі postgresql 
(наприклад, supabase), де фізично зберігаються всі таблиці системи 
(користувачі, списки, товари). 
Залежності між компонентами реалізовано через чітко визначені 
інтерфейси. Клієнтська частина спілкується з API через протокол HTTPS (REST-
подібні запити), API Сервер взаємодіє з базою даних через захищене TCP/IP 
з'єднання за допомогою ORM, а модуль парсингу здійснює зовнішні HTTP- 
43 
ЧДТУ.262258.019 ПЗ  
запити до сторонніх ресурсів. 
На Рисунку 2.8 наведено діаграму компонентів розробленої програмної 
системи, яка візуалізує описану архітектуру. 
 
 
Рисунок 2.8 – Діаграма компонентів 
 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання  
Візуальне моделювання значно спрощує розуміння архітектури та 
допомагає розв'язувати складні інженерні задачі. Розробник отримує дієвий 
інструмент для глибокого аналізу прихованих технічних перепон. Без 
попередньої побудови графічної схеми серйозні перешкоди часто хибно 
44 
ЧДТУ.262258.019 ПЗ  
здаються тривіальними на старті проєкту. Рисунок 2.9 безпосередньо демонструє 
діаграму розгортання (Deployment Diagram) платформи Подарунок. 
 
 
Рисунок 2.9 – Діаграма розгортання програмної системи 
 
Запропонована модель розкриває гібридну локально-хмарну архітектуру. 
Інфраструктура додатка спирається на три головні апаратні та програмні вузли: 
 клієнтський пристрій (Client Device). Апаратне забезпечення кінцевого  
45 
ЧДТУ.262258.019 ПЗ  
відвідувача. Середовище охоплює персональні комп'ютери, планшети 
або смартфони. Браузер завантажує та рендерить інтерфейс (UI). 
Програміст створює візуальну частину завдяки бібліотеці React та 
фреймворку Next.js; 
 локальний сервер додатку (Local Application Server). Фізична машина 
для розміщення бекенду. Середовище Node.js обробляє API-маршрути 
та генерує сторінки на стороні сервера (SSR) заради максимальної SEO-
оптимізації. Паралельно ядро запускає ізольовані скрипти парсингу для 
витягування товарів з маркетплейсів формату Rozetka чи Comfy; 
 хмарна інфраструктура Supabase. Стороння платформа формату 
Backend-as-a-Service. Інтеграція охоплює два ключові компоненти. 
База даних PostgreSQL надійно зберігає таблиці користувачів, колекції 
бажань та актуальні статуси бронювання. Модуль Supabase Auth 
повністю керує автентифікацією та генерує безпечні JWT-токени для 
активних сесій. 
Фізичні та логічні вузли обмінюються пакетами виключно через 
зашифрований протокол HTTPS. Надійну комунікацію між сервером Node.js та 
віддаленим сховищем PostgreSQL забезпечує об'єктно-реляційний інструмент 
Prisma ORM. 
2.5 Моделювання поведінки системи 
2.5.1 Діаграми діяльності 
Динаміку складних бізнес-процесів найкраще розкриває діаграма 
діяльності. Інженер використовує цю схему для візуалізації кроків алгоритму, 
точок розгалуження та паралельних потоків виконання. 
Найскладніший процес платформи Подарунок — автоматичний імпорт 
подарунка за URL-адресою. Скрипт проходить кілька рівнів перевірок та активно 
звертається до зовнішніх ресурсів. 
На рисунку 2.10 зображено діаграму діяльності. 
Покроковий сценарій парсингу виглядає так: 
 клієнт вставляє лінк у поле вводу; 
46 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.10 – Діаграма діяльності процесу автоматизованого додавання товару 
47 
ЧДТУ.262258.019 ПЗ  
 фронтенд миттєво перевіряє структурний формат посилання. 
Невалідний текст одразу зупиняє процес і викликає попередження на 
екрані; 
 бекенд отримує правильне посилання і визначає конкретний 
маркетплейс (Rozetka, Comfy тощо); 
 сервер надсилає асинхронний HTTP-запит до цільового ресурсу. 
Тут графік показує головне логічне розгалуження: 
 сценарій відмови. Захисні системи магазину блокують з'єднання. 
Сервер зупиняє парсинг, записує подію в лог і повертає статус 
помилки. Інтерфейс інформує людину про збій; 
 успішний шлях. Сторінка віддає HTML-код. Сервер запускає модуль 
синтаксичного аналізу; 
 парсер читає DOM-дерево і копіює цінник, точну назву та лінк на 
фотографію; 
 бекенд нормалізує типи даних і зберігає новий запис у реляційній базі 
з прив'язкою до вішлиста; 
 клієнтський додаток отримує позитивну відповідь і малює картку 
товару в колекції. 
Проєктування цього блоку вимагало особливої уваги. Сучасний e-
commerce активно впроваджує динамічний рендеринг та жорсткий Anti-Bot 
захист. Тому побудована діаграма охоплює не лише ідеальний шлях (Happy 
Path), а й надійну обробку винятків. Наприклад, логіка перехоплює помилки 
таймауту. Замість аварійного падіння програма м'яко активує резервний сценарій 
і пропонує користувачу заповнити характеристики речі вручну. 
2.5.2 Діаграма послідовності 
На противагу діаграмі діяльності, схема послідовності фокусується на 
часовій шкалі. Графік показує хронологічний обмін повідомленнями між 
окремими об'єктами під час виконання конкретного прецеденту. На рисунку 2.11 
зображено діаграму послідовності. 
48 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 2.11 – Діаграма послідовності процесу бронювання товару 
 
Платформа Подарунок пропонує механізм бронювання подарунків. 
Функція вимагає ідеальної синхронізації між фронтендом, контролером 
авторизації та базою даних. Розробник має повністю виключити стан гонки (Race 
Condition). Помилка виникає тоді, коли кілька гостей одночасно клікають на 
одну позицію. 
Хронологія успішного бронювання виглядає так: 
 гість натискає кнопку «Забронювати» біля чужого товару; 
 клієнтський застосунок формує POST-запит і передає ідентифікатор 
позиції на сервер; 
 бекенд звертається у сервіс авторизації. Модуль перевіряє права гостя 
та розшифровує сесійний JWT-токен; 
49 
ЧДТУ.262258.019 ПЗ  
 після валідації прав сервер запитує актуальний статус речі у базі 
PostgreSQL через інструмент ORM; 
 сховище повертає значення AVAILABLE (Доступний); 
 сервер відкриває транзакцію, змінює маркер на BOOKED 
(Заброньовано) і фіксує ідентифікатор гостя; 
 база даних успішно зберігає оновлену таблицю; 
 бекенд генерує статус 200 OK і віддає його назад; 
 інтерфейс миттєво перемальовує кнопку. 
Транзакційна цілісність виступає головним архітектурним викликом 
алгоритму. Побудована схема розбиває захист від стану гонки на кілька шарів. 
Сервер жорстко валідує права і повторно перевіряє статус речі за мілісекунди до 
запису в таблицю. Додатково фронтенд впроваджує патерн Optimistic UI 
(Оптимістичне оновлення). Браузер змінює дизайн кнопки миттєво після кліку. 
Користувач не чекає фінальної відповіді сервера, тому додаток відчувається 
максимально швидким. 
2.5.3 Діаграма комунікації 
Модель комунікації (Communication Diagram) візуалізує структурну 
організацію об'єктів. Програміст бачить чітку мережу передачі повідомлень під 
час виконання конкретного завдання. Схема повністю ігнорує хронологію подій 
і фокусується виключно на архітектурних зв'язках компонентів. На рисунку 2.12 
зображено діаграму комунікації. 
Платформа Подарунок ідеально демонструє такий тип взаємодії під час 
відкриття приватного списку. Алгоритм зчитує унікальний Access Key і поєднує 
дії відвідувача, фронтенду, бекенду та реляційної бази. 
Кроки доступу до закритої колекції: 
– гість вводить секретний ключ у спеціальне текстове поле; 
– візуальна форма доступу збирає рядок і відправляє HTTP-запит на 
серверний маршрут; 
– бекенд перевіряє формат отриманого ключа. Далі контролер ініціює 
запит через інструмент ORM для пошуку потрібної колекції; 
50 
ЧДТУ.262258.019 ПЗ  
– сховище сканує таблиці. База даних повертає знайдений вішлист разом 
із вкладеними товарами або генерує помилку доступу; 
– серверна логіка структурує зібраний масив. Бекенд пакує результат у 
серіалізований JSON-об'єкт і віддає фінальну відповідь; 
– клієнтський інтерфейс розпізнає позитивний статус і миттєво малює 
картки закритих подарунків на екрані. 
 
 
Рисунок 2.12 – Діаграма комунікації процесу отримання доступу до списку 
 
2.5.4  Діаграма скінченного автомату 
Діаграма станів (State Machine Diagram) моделює, як саме платформа 
реагує на дії користувача. Схема фіксує всі можливі режими роботи сервісу та 
події-тригери, що ініціюють перехід між ними. 
Правильне керування станом - головний архітектурний виклик для нашого 
веб-додатка. Ми розділили життєвий цикл сервісу на два великі рівні: Гість 
(неавторизований стан) та Власник (авторизований стан). Кожен із них працює 
за багаторівневою структурою і вміщує низку специфічних підстанів. 
Вичерпну характеристику всіх режимів роботи додатка ми зібрали у 
таблиці 2.5. 
51 
ЧДТУ.262258.019 ПЗ  
Таблиця 2.5 
Опис глобальних станів web-додатку 
Назва стану Тип стану Опис та доступні функції 
Загальний стан системи для 
Неавторизований неідентифікованих відвідувачів. 
Композитний 
стан Доступна лише публічна частина 
додатку. 
Головна сторінка Початковий стан очікування після 
Простий 
(Landing) відкриття сайту. 
Стан взаємодії з формами входу або 
Аутентифікація Простий реєстрації. Система очікує введення 
валідних облікових даних. 
Загальний стан після успішної 
Авторизований стан Композитний перевірки токена доступу. Надає доступ 
до закритої бізнес-логіки. 
Базовий стан авторизованого 
Особистий кабінет користувача. Відображає перелік 
Простий 
(Dashboard) власних списків та заброньованих 
товарів. 
Стан редагування метаданих: створення 
Управління 
Простий нового списку, зміна назви, 
списками 
налаштування приватності. 
Стан активного додавання товару 
Робота з товарами 
Простий виключно за допомогою автоматичного 
(Парсинг) 
парсингу URL-посилання. 
Стан перегляду контенту інших 
Взаємодія з чужими 
Простий користувачів із можливістю ініціювати 
списками 
транзакцію бронювання подарунка. 
52 
ЧДТУ.262258.019 ПЗ  
Для того щоб система могла динамічно реагувати на дії користувача, 
передбачено матрицю переходів. У таблиці 2.6 деталізовано основні переходи 
між станами розроблюваної системи 
. 
Таблиця 2.6  
Матриця переходів між станами системи 
Подія Наступний Системна дія під час 
Поточний стан 
(Тригер) стан переходу 
Головна Натискання Рендеринг компонента форми 
Аутентифікація 
сторінка «Увійти» входу. 
Успішна Збереження сесійного JWT-
Особистий 
Аутентифікація валідація токена, перенаправлення на 
кабінет 
даних закритий маршрут. 
Вибір Відкриття модального вікна 
Особистий Управління 
«Створити створення/редагування списку. 
кабінет списками 
список» 
Запуск модуля парсингу для 
Управління Передача Робота з 
вилучення метаданих (ціна, 
списками URL товару товарами 
фото, назва). 
Завершення Запис об'єкта в БД (при успіху) 
Робота з парсингу Управління або виведення помилки та 
товарами (Успіх/ списками скасування операції. 
Помилка) 
Перевірка валідності ключа, 
Особистий Введення 
Чужі списки завантаження публічних даних 
кабінет Access Key 
іншого користувача. 
Натискання Знищення JWT-токена, 
Будь-який Головна 
«Вийти» блокування доступу до 
авторизований сторінка 
(Logout) приватних маршрутів. 
53 
ЧДТУ.262258.019 ПЗ  
На основі розроблених табличних специфікацій було побудовано графічну 
візуалізацію логіки зміни станів. Діаграму скінченного автомату глобальної 
роботи додатку наведено на рис. 2.13. 
 
 
Рисунок 2.13 - Діаграма скінченного автомату глобальних станів системи 
54 
ЧДТУ.262258.019 ПЗ  
ВИСНОВКИ ДО РОЗДІЛУ 2 
Другий розділ кваліфікаційної роботи бакалавра підсумовує етап 
архітектурного проєктування нашої платформи. Ми пройшли шлях від аналізу 
бізнес-вимог до створення повної UML-моделі системи. 
Що саме вдалося реалізувати: 
 визначено хмарну архітектуру. Ми змоделювали життєвий цикл даних: 
від клієнтського браузера до бази PostgreSQL у хмарі Supabase. Це дало 
змогу виділити критичні вузли: парсинг маркетплейсів та 
багаторівневий контроль доступу; 
 побудовано ієрархію вимог. Діаграма прецедентів (Use Case) чітко 
розмежувала зони відповідальності гостей та зареєстрованих 
учасників; 
 розроблено статику системи. Діаграми класів та компонентів задали 
структуру бази даних і модульну організацію бекенду; 
 модельовано динаміку процесів. Завдяки діаграмам діяльності, 
послідовності та комунікації ми детально описали алгоритми: 
бронювання товарів, захист від стану гонки та роботу скриптів-
скрейперів; 
 проєктування завершено. Результати розділу створюють надійний 
фундамент для написання коду, фінального тестування та розгортання 
робочого сервісу Подарунок; 
  
55 
ЧДТУ.262258.019 ПЗ  
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
Третій розділ повністю присвячений етапу практичної реалізації та 
комплексній перевірці працездатності продукту. Ми проходимо шлях від вибору 
технологічного стека до фінального тестування готової системи. 
3.1 Розробка програмного комплексу 
Написання коду завжди починається із затвердження інструментарію. 
Спочатку ми аналізуємо обрані мови програмування, фреймворки та середовища 
розробки. Інженер має зважити переваги та недоліки кожної технології, щоб 
підтвердити їхню відповідність бізнес-вимогам проєкту. 
Після фіксації стека увага переходить до архітектурних моделей. Ми 
деталізуємо функціональну будову додатка, зв'язки між модулями та загальний 
потік даних в алгоритмах. 
Наступні етапи охоплюють конкретні технічні кроки реалізації: 
 база даних: проєктування таблиць, підбір типів колонок та 
налаштування реляційних зв'язків; 
 клієнтський інтерфейс (UI): побудова візуальних елементів, 
налаштування навігації та забезпечення максимальної зручності для 
відвідувачів; 
 серверна частина: написання бізнес-логіки бекенду, створення 
маршрутів та конфігурація основних програмних модулів. 
Фінальна частина розділу розкриває методологію випробувань. Щоб 
гарантувати стабільність сервісу, ми застосовуємо чотири рівні перевірок: 
модульні (Unit), інтеграційні, системні та приймальні тестування. Зрештою, 
текст містить детальний огляд уже готового до розгортання програмного 
продукту. 
3.1.1 Обґрунтування вибору засобів реалізації 
56 
ЧДТУ.262258.019 ПЗ  
Головним інструментом для розробки платформи Подарунок став 
фреймворк Next.js у зв'язці з React. Увесь програмний код написаний мовою 
TypeScript. 
Перевагу було віддано Next.js через його архітектуру. Фреймворк «з 
коробки» підтримує серверний рендеринг (SSR) та зручну маршрутизацію (App 
Router). Своєю чергою, TypeScript змушує дотримуватися суворої типізації. 
Такий підхід відсікає сотні потенційних помилок ще до етапу компіляції проєкту. 
Збереження інформації та керування даними спирається на дві пов'язані 
технології: 
 postgresql. Надійна реляційна СУБД. Двигун гарантує високу 
швидкість обробки складних зв'язків між профілями користувачів та 
їхніми подарунками; 
 prisma ORM. Сучасний міст між сервером та сховищем. Інструмент 
самостійно генерує типізовані інтерфейси під TypeScript. Програміст 
отримує стовідсоткову синхронізацію: логіка коду ніколи не 
розходиться зі структурою реальних таблиць. 
Окремим архітектурним викликом стала розробка модуля парсингу для 
українського e-commerce сегмента. Тут бекенд комбінує два рішення: 
 cheerio. Утиліта для блискавичного розбору статики. Скрипт миттєво 
витягує потрібні метадані з простих HTML-сторінок; 
 puppeteer. Інструмент для обходу динамічного рендерингу (SPA). 
Бібліотека запускає повноцінний емулятор браузера. Фактично, це 
єдиний надійний спосіб зібрати актуальні цінники з перевантажених 
скриптами сайтів формату Rozetka чи Comfy. 
3.1.2 Опис структурної (функціональної) схеми 
Щоб платформа працювала швидко і вільно масштабувалася, ми 
застосували багаторівневий функціональний підхід. Таке архітектурне рішення 
гарантує жорсткий розподіл зон відповідальності (Separation of Concerns). 
Звичайний опис вихідного коду фіксує лише статику. Натомість 
функціональна схема розкриває справжню динаміку сервісу. Графік показує 
57 
ЧДТУ.262258.019 ПЗ  
живий рух інформації (data pipeline). Інженер бачить безперервне спілкування 
фронтенду з API-маршрутами, незалежними скриптами та шаром бази даних. 
Рисунок 3.1 наочно демонструє цю взаємодію. Схема описує спільну 
роботу всіх вузлів системи як під час реальних дій користувача, так і під час 
фонових процесів. 
 
Рисунок 3.1 - Функціональна схема інформаційної взаємодії компонентів 
сервісу «Подарунок» 
Опис логіки функціонального пайплайну системи: 
1 Клієнтський рівень (Браузер / Next.js): Ініціює взаємодію із системою, 
відправляючи асинхронні HTTP-запити у форматі JSON (наприклад, 
при автентифікації, створенні вішлиста або додаванні товару). 
2 Серверний рівень (API Routes): Виступає єдиною точкою входу для 
бізнес-логіки. Обробляє запити, валідує сесії користувачів через JWT 
та маршрутизує потоки даних. 
3 Підсистема автоматизованого збору даних (Модуль парсингу): 
Окремий ізольований сервіс, який викликається серверними API-
маршрутами, коли користувач передає URL-посилання на товар. 
Модуль здійснює завантаження та синтаксичний аналіз веб-сторінок e-
commerce платформ за допомогою бібліотек Cheerio або Puppeteer і 
повертає структуровані метадані назад до API. 
58 
ЧДТУ.262258.019 ПЗ  
4 Шар об'єктно-реляційного відображення (Prisma Client): Приймає дані 
від API, транслює високорівневі методи TypeScript у оптимізовані SQL-
запити та забезпечує типізацію на рівні взаємодії з базою даних. 
5 Рівень збереження даних (БД PostgreSQL): Кінцева реляційна база 
даних, яка виконує транзакції, забезпечує консистентність, цілісність 
реляційних зв'язків та фізично зберігає інформацію про сутності 
системи. 
Файлова структура web-сервісу Подарунок має таку структуру: 
[Подарунок] 
├── app/ 
│ ├── api/ 
│ │ ├── auth/ 
│ │ ├── items/ 
│ │ ├── parse/ 
│ │ ├── admin/ 
│ │ ├── swagger/ 
│ │ ├── user/ 
│ │ └── Подарунокs/ 
│ ├── discover/ 
│ ├── list/ 
│ ├── profile/ 
│ ├── globals.css 
│ └── layout.tsx 
├── components/ 
│ ├── ui/ 
│ ├── add-item-modal.tsx 
│ ├── masonry-grid.tsx 
│ ├── navbar.tsx 
│ └── product-card.tsx 
├── lib/ 
│ ├── parser/ 
59 
ЧДТУ.262258.019 ПЗ  
│ │ ├── sites/ 
│ │ ├── index.ts 
│ │ └── browser-manager.ts 
│ ├── db.ts 
│ ├── anti-blocking.ts 
│ ├── redis-cache.ts 
│ └── validation.ts 
├── prisma/ 
│ └── schema.prisma 
├── public/ 
│ ├── flags/ 
│ └── placeholder.svg 
├── middleware.ts 
└── package.json 
Архітектура робочого простору суворо дотримується стандартів Next.js. Увесь 
програмний код розділений на спеціалізовані логічні блоки: 
1 Каталог app/. Фундамент системи маршрутизації (App Router). Фронтенд-
сторінки профілю чи загальної стрічки лежать поруч із серверною логікою. 
Остання захована у підпапці api/, де запрограмовані REST-маршрути для 
обміну даними. 
2 Каталог components/. Сховище незалежних React-елементів. Прості 
візуальні деталі, такі як кнопки чи поля вводу, згруповані у директорії ui/. 
Більш комплексні деталі (модальні вікна, картки товарів) програміст 
залишає прямо в корені. 
3 Каталог lib/. Концентратор бізнес-логіки. Вкладена папка parser/ керує 
алгоритмами витягування цінників з маркетплейсів. Сусідній файл db.ts 
піднімає з'єднання зі сховищем, тоді як скрипт validation.ts проганяє вхідну 
інформацію через жорсткі схеми бібліотеки Zod. 
60 
ЧДТУ.262258.019 ПЗ  
4 Каталог prisma/. Робоче середовище для інструменту ORM. Папка виділена 
під ключовий файл schema.prisma, який декларативно фіксує фізичну 
архітектуру таблиць бази даних. 
5 Каталог public/. Збірник статичного контенту. Розробник завантажує сюди 
іконки прапорів для перемикача мов та різноманітні дефолтні зображення. 
6 Файл middleware.ts. Глобальний перехоплювач HTTP-запитів. Скрипт 
миттєво перевіряє авторизацію відвідувача і блокує доступ до захищених 
сторінок без валідного токена. 
3.1.3 Опис логічної схеми системи 
 
 
Рисунок 3.2 – Опис логічної схеми системи 
61 
ЧДТУ.262258.019 ПЗ  
Клієнтська частина (Front-end) 
Візуальна оболонка платформи. Браузер малює списки бажань, картки 
подарунків та форми реєстрації. Фронтенд спілкується з бекендом виключно 
через стандартні HTTP-запити. 
Серверний API (Back-end) 
Головний контролер бізнес-логіки. Сервер приймає виклики від клієнта, 
жорстко валідує вхідні пакети та перевіряє права доступу. Також ядро керує 
скриптами парсингу і відправляє команди у сховище. 
База даних (PostgreSQL) 
Реляційне сховище інформації. Двигун надійно фіксує профілі 
відвідувачів, структурує колекції бажань та миттєво оновлює статуси 
бронювання товарів. 
Модуль парсингу 
Автономний скриптовий вузол. Алгоритм обробляє зовнішнє посилання, 
запускає емулятор браузера та зчитує сторінки інтернет-магазинів. Скрипт 
цілеспрямовано витягує з чужого HTML актуальні цінники, заголовки та лінки 
на фотографії. 
3.1.4 Розробка бази даних 
Фундаментом збереження інформації виступає СУБД PostgreSQL. 
Програмний код платформи взаємодіє з таблицями через інструмент Prisma 
ORM. Розробник отримує зручне об'єктно-реляційне відображення та миттєву 
генерацію TypeScript-інтерфейсів. Інженер пише суворо типізований код, а 
фреймворк самостійно генерує SQL-міграції. 
Архітектура фізичної моделі суворо дотримується правил нормалізації. 
Програміст повністю виключає дублювання записів. Словник бази спирається на 
три головні сутності. Вони щільно пов'язані між собою і закривають усі потреби 
сервісу вішлистів. Рисунок 3.2 детально розкриває схему сховища: типи колонок 
та реляційні зв'язки формату «один-до-багатьох». 
62 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 3.3 - Структура реляційної бази даних програмного комплексу 
Детальний опис сутностей розробленої бази даних: 
1. Сутність User (Користувач) Ця таблиця призначена для зберігання 
облікових даних та профілів: 
1 name (ім'я); 
2 username (унікальне ім'я користувача для URL); 
3 e-mail (електронна пошта); 
4 password (хешований пароль); 
5 avatar (посилання на фото профілю); 
6 bio (коротка біографія). 
63 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 3.4 - База даних «User» 
 
2. Сутність Подарунок (Список бажань) Таблиця відповідає за логічне 
групування товарів. Пов'язана із сутністю User відношенням «багато-до-одного» 
(кожен список належить одному власнику через зовнішній ключ userId): 
1 name (назва списку); 
2 description (опис списку); 
3 emoji (іконка списку); 
4 isPrivate (статус приватності); 
5 accessKey (унікальний згенерований ключ доступу, що 
використовується для надання обмеженого перегляду приватного 
списку бажань); 
6 userId (ідентифікатор власника). 
64 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 3.5 - База даних «Подарунок» 
 
3. Сутність ПодарунокItem (Товар) Таблиця зберігає метадані про 
конкретний подарунок, отримані в результаті парсингу, а також статус його 
бронювання: 
1 id (унікальний ідентифікатор); 
2 title (назва товару); 
3 price (поточна ціна); 
4 oldPrice (стара ціна для вирахування знижки); 
5 image (посилання на зображення); 
6 store (назва магазину); 
7 url (пряме посилання на товар); 
8 priority (пріоритет: низький, середній, високий); 
9 isBooked (статус бронювання); 
10 bookedById (ідентифікатор користувача, який забронював товар); 
11 ПодарунокId (ідентифікатор списку, до якого належить товар). 
65 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 3.6 - База даних «ПодарунокItem» 
 
3.1.5 Розробка інтерфейсу користувача 
Візуальна частина платформи працює за принципом односторінкового 
додатка (SPA). Розробник побудував інтерфейс із незалежних React-компонентів 
та стилізував їх інструментами Tailwind CSS. Головним пріоритетом проєкту 
стала інтуїтивна навігація. Відвідувач має миттєво зчитувати логіку сервісу та 
максимально швидко створювати нові записи. 
66 
ЧДТУ.262258.019 ПЗ  
Ключові архітектурні рішення фронтенду: 
Адаптивність. Дизайн самостійно підлаштовує власні пропорції під екран 
пристрою. Браузер однаково коректно малює блоки як на широких десктопних 
моніторах, так і на компактних смартфонах. 
Модальні вікна. Платформа генерує нові списки та додає подарунки 
виключно через спливаючі діалоги (Dialogs). Гість залишається на поточній 
сторінці і взагалі не втрачає візуального контексту. 
Сітка Masonry. Каталог речей використовує формат динамічного 
«водоспаду». Архітектура гарантує естетичне компонування карток, навіть якщо 
завантажені фотографії мають кардинально різні пропорції. 
Користувацький інтерфейс: 
 
 
Рисунок 3.7 – Головна сторінка сервісу 
67 
ЧДТУ.262258.019 ПЗ  
 
Рисунок 3.8 – Сторінка реєстрації та авторизації 
 
 
Рисунок 3.9 – Сторінка реєстрації та авторизації 
68 
ЧДТУ.262258.019 ПЗ 
Рисунок 3.10 – Персональний профіль користувача, що містить усі створені ним 
колекції бажань 
Рисунок 3.11 – Модальне вікно створення нового списку 
69 
ЧДТУ.262258.019 ПЗ 
Рисунок 3.12 – Інтерфейс додавання товару через URL (Парсинг) 
Рисунок 3.13 – Відображення товарів у списку (Masonry Grid) 
70 
ЧДТУ.262258.019 ПЗ 
Рисунок 3.14 – Режим перегляду списку гостем та кнопка "Забронювати" 
Рисунок 3.15 – Вікно введення ключа доступу для приватного списку 
Рисунок 3.16 – Інтерфейс редагування профілю користувача 
71 
ЧДТУ.262258.019 ПЗ 
3.1.6 Опис розробки програмних компонентів 
Основні програмні компоненти web-додатка Подарунок: 
1. Ініціалізація та підключення:
‒ завантаження конфігурацій (next.js config); 
‒ ініціалізація клієнта prisma для забезпечення прямого зв'язку з базою 
даних postgresql; 
‒ налаштування middleware для перевірки jwt-токенів при спробі доступу 
до закритих сторінок. 
2. API Маршрути (Controllers):
‒ парсинг вхідних запитів (наприклад, реєстрація, створення списку);
‒ перевірка прав доступу користувача;
‒ виклик функцій для запису або читання даних з бд.
3. Підсистема парсингу (lib/parser):
– створення каналу зв'язку із системою redis для подальшого кешування
інформаці;
‒ маршрутизація url-посилання до відповідного адаптера (rozetkaparser,
comfyparser тощо);
‒ запуск headless-браузера (puppeteer) для сайтів зі складним клієнтським
рендерингом, або використання cheerio для швидкого вилучення даних.
4. База даних Prisma:
‒ обробка транзакцій та запитів на читання/запис (crud);
‒ каскадне видалення (cascade delete) товарів при видаленні списку або
профілю.
3.2 Тестування системи 
У поточному підрозділі наведено детальний опис тестових сценаріїв та 
методик перевірки, реалізованих на етапах розробки та налагодження системи. 
По-перше, розглянемо модульні тести, які перевіряють правильність 
роботи окремих модулів або компонентів системи. Потім описані інтеграційні 
тести, які перевіряють взаємодію між різними модулями. Наступним кроком є 
72 
ЧДТУ.262258.019 ПЗ  
опис системного тесту, який перевіряє роботу всієї системи. Нарешті, описується 
процес приймальних випробувань для підтвердження того, що система 
відповідає вимогам. 
3.2.1 Модульне тестування 
Для тестування було перевірено коректність виконання окремих 
ізольованих функцій та модулів системи. 
 
Таблиця 3.1  
Компоненти з їхніми функціями та результати 
Модулі Функції / Команди Результат 
Функція працює належним чином, 
Реєстрація, Логін, 
Auth валідація відхиляє невірні формати 
Відновлення 
email. 
Функція працює належним чином і 
Створення, Редагування, 
Подарунок зберігає необхідну інформацію в 
Видалення 
базі даних. 
Функція працює належним чином, 
Parser Core parseProduct(url) розпізнає домен і делегує задачу 
правильному парсеру. 
Функція працює правильно, дані 
Redis Cache getFromCache, saveToCache зчитуються без повторного HTTP-
запиту. 
Функція працює нормально, 
Store Parsers Rozetka, Allo, Comfy, Brain 
коректно витягує поля price та title. 
Функція працює правильно, 
Validation Zod схеми для форм 
блокує відправку порожніх полів. 
 
Усі необхідні функції успішно пройшли тести та продемонстрували 
очікуваний результат. 
3.2.2 Інтеграційне тестування 
73 
ЧДТУ.262258.019 ПЗ 
Цей вид перевірки спрямований на тестування безперебійної взаємодії 
системних сервісів, включаючи API, зі сховищем даних PostgreSQL. 
Таблиця 3.2 
Тестування правильного збереження та оновлення інформації 
API Ендпоінт / Дія Результати 
Маршрут працює належним чином, та правильно 
POST /api/auth/signup 
заносить інформацію в базу даних. 
Маршрут працює належним чином, генерує 
POST /api/Подарунокs accessKey та заносить інформацію в базу даних. 
Маршрут працює належним чином, зберігає 
POST /api/parse 
результати парсингу в Redis кеш. 
PATCH Маршрут працює належним чином, оновлює статус 
/api/items/[id]/book isBooked та зберігає bookedById в базі даних. 
Маршрут працює належним чином, та видаляє 
DELETE /api/items/[id] 
інформацію з бази даних. 
Маршрут працює належним чином, та правильно 
PATCH /api/user оновлює дані профілю (біографію, аватар) в базі 
даних. 
Таблиця 3.3 
Таблиця правильного зчитування інформації 
API Ендпоінт / Дія Результати 
Маршрут працює належним чином, та виводить 
GET /api/Подарунокs 
список вішлистів користувача з бази даних. 
Маршрут працює належним чином, та виводить 
GET /api/shared/[key] інформацію приватного списку з бази даних при 
співпадінні ключа. 
Маршрут працює належним чином, та виводить 
GET /api/user/booked-items 
список заброньованих подарунків з бази даних. 
74 
ЧДТУ.262258.019 ПЗ 
Усі маршрути, що працюють з базою даних, продемонстрували результати, 
необхідні для зберігання та читання інформації як всередині, так і за межами бази 
даних. 
3.2.3 Системне тестування 
Цей етап передбачає глобальний аналіз повністю зінтегрованої системи, 
головним завданням якого є верифікація виконання всіх поставлених 
функціональних вимог. 
Таблиця 3.4 
Системне тестування 
Системні Протестован
Працює Опис дії 
функція о 
Реєстрація, вхід у систему та обробка 
Авторизація Так Так 
JWT токенів. 
Управління Створення публічних та приватних 
Так Так 
списками вішлистів, їх редагування. 
Автоматичне вилучення ціни та фото 
Парсинг товарів Так Так товару за введеним посиланням. 
Можливість гостям натиснути 
Бронювання Так Так "Забронювати" для уникнення 
дублікатів подарунків. 
Приватність Блокування доступу до списку без 
Так Так 
доступу наявності правильного accessKey. 
Коректне відображення сітки товарів 
Адаптивність UI Так Так 
на мобільних пристроях. 
Кожен елемент функціоналу успішно витримав етап системних перевірок. 
Розроблений комплекс цілком задовольняє як функціональні, так і 
нефункціональні критерії проекту. 
75 
ЧДТУ.262258.019 ПЗ  
3.2.4 Приймальне тестування 
Фінальні випробування мали на меті оцінити продукт очима звичайного 
відвідувача. Ми перевірили логіку роботи та зібрали ідеї для майбутніх оновлень. 
Тестування ключового функціоналу: 
 реєстрація та профіль. Гість вільно створює обліковий запис, а бекенд 
миттєво генерує робоче персональне посилання формату /u/username; 
 імпорт подарунків. Скрипт-парсер безпомилково витягує метадані зі 
сторінок магазинів. Інструменти ручного редагування також 
функціонують без збоїв; 
 резервування позицій. Відвідувач успішно бронює чужу річ. Фронтенд 
одразу блокує візуальну картку для решти аудиторії, тоді як власник 
списку бачить лише оновлений статус та ім'я автора бронювання; 
 рівні доступу. Сервіс надійно приховує закриті колекції від загальної 
стрічки. Механізм гостьового входу за секретним ключем спрацьовує з 
першого разу. 
Перевірка нефункціональних вимог: 
 швидкість відгуку. Інтеграція кешування через Redis гарантує 
блискавичний парсинг абсолютної більшості маркетплейсів; 
 надійність архітектури. Локальне середовище розгортання легко 
витримує масив паралельних транзакцій без жодних зависань бази 
даних; 
 ергономіка UI. Новачки інтуїтивно розуміють механіку створення 
списків та легко діляться посиланнями. 
Зворотний зв'язок та план розвитку 
Загальна оцінка підтверджує стабільність розробленої платформи. 
Продукт Подарунок повністю закриває початкове технічне завдання. Водночас 
тестувальники сформували список ідей для майбутніх версій: 
 соціальний логін. Інтеграція провайдерів Google та Apple кардинально 
прискорить процес реєстрації; 
76 
ЧДТУ.262258.019 ПЗ 
 email-сповіщення. Платформа надсилатиме власнику анонімного
листа, щойно хтось зарезервує його бажання;
 масштабування парсера. Написання нових скриптів дозволить
обробляти західні гіганти формату Amazon чи AliExpress.
3.3 Приклади впровадженого програмного комплексу 
Фінальний підрозділ розкриває технічний потенціал нашої кваліфікаційної 
роботи. Зараз готовий продукт працює виключно всередині локального 
середовища. Таке інженерне рішення гарантує безперебійну демонстрацію 
результатів під час захисту та повністю відсікає ризики, пов'язані з раптовим 
падінням сторонніх хмарних серверів. 
Поточна збірка містить робочий парсер, стійку реляційну базу, адаптивний 
дизайн та захищений алгоритм бронювання. Ці модулі забезпечують винятково 
позитивний досвід взаємодії та перетворюють платформу на зручний інструмент 
для планування свят. 
Водночас закладена архітектура готова до агресивного масштабування. 
Наступний логічний крок — перенесення бекенду на повноцінний хмарний 
хостинг та вихід на реальний ринок електронної комерції. Звісно, комерційний 
реліз вимагатиме фінансових інвестицій для оренди потужних серверів, тому 
розробник виносить цей етап за рамки поточного локального тестування. 
77 
ЧДТУ.262258.019 ПЗ 
ВИСНОВОК ДО РОЗДІЛУ 3 
У цьому розділі детально описуються практичні аспекти розробки та 
тестування програмного забезпечення Подарунок. Розглядалися питання, 
пов'язані з вибором інструментів реалізації (Next.js, Prisma, PostgreSQL), 
структурним і логічним проєктуванням системи, розробкою бази даних і 
користувальницьких інтерфейсів, а також створенням модуля парсингу даних. 
Ключовий акцент у роботі зроблено на проведенні комплексних перевірок 
- від модульних та інтеграційних до системних і приймальних тестів, що
виступають фундаментальною основою контролю якості програмних продуктів. 
Отримані під час випробувань дані підтверджують безперебійну роботу 
розробленого комплексу та його повну відповідність початковому технічному 
завданню. 
78 
ЧДТУ.262258.019 ПЗ 
ВИСНОВКИ 
У ході виконання кваліфікаційної роботи бакалавра було проведено 
повний цикл проєктування та програмної реалізації web-сервісу «Подарунок». 
Результати роботи дозволяють сформулювати наступні підсумкові висновки: 
1 Результати аналізу предметної області. 
Дослідження сучасного ринку електронної комерції та систем планування 
покупок виявило суттєву проблему розрізненості даних: користувачі змушені 
зберігати посилання у месенджерах, нотатках або кошиках різних магазинів. 
Спроєктована система вирішує цю проблему, виступаючи єдиним агрегатором, 
що спеціалізовано адаптований під специфіку українського ритейлу та гарантує 
безперебійний парсинг національних маркетплейсів. 
2 Архітектурне проєктування. 
На основі системного підходу та стандартів UML було розроблено 
архітектурну модель сервісу. Використання діаграм прецедентів, класів та 
послідовностей дозволило чітко розмежувати логіку взаємодії користувача з 
системою, механізми доступу через приватні ключі та алгоритми бронювання 
товарів. Це забезпечило високу модульність системи та її готовність до 
подальшої модифікації. 
3 Інноваційність технічних рішень. 
Ключовою особливістю роботи є реалізація технології «Smart Link 
Parsing». Завдяки поєднанню бібліотек Cheerio (для статичного аналізу метатегів 
Open Graph) та Puppeteer (для обробки динамічного контенту), вдалося досягти 
високої точності автоматичного вилучення даних (назва, ціна, зображення) з 
будь-яких web-ресурсів, що мінімізує ручне введення даних користувачем. 
4 Програмна реалізація та стек технологій. 
Основою проєкту став актуальний Fullstack: використання Next.js 
гарантувало високу швидкість завантаження сторінок та ефективну SEO-
оптимізацію, застосування TypeScript забезпечило строгу типізацію та 
стабільність кодової бази, тоді як інтеграція PostgreSQL із Prisma ORM дала 
змогу побудувати масштабовану архітектуру даних. Створений клієнтський 
79 
ЧДТУ.262258.019 ПЗ  
інтерфейс відрізняється повною кросплатформною адаптивністю та слідує 
передовим принципам UI/UX. 
Верифікація результатів. 
Виконаний комплекс перевірок, що складався з функціонального, 
модульного та UI-тестування, повністю засвідчив надійну роботу платформи за 
умов різноманітних сценаріїв навантаження. 
Окрему увагу було приділено безпеці даних - впроваджена система 
приватних посилань надійно захищає списки користувачів від 
несанкціонованого перегляду, зберігаючи при цьому зручність для запрошених 
гостей. 
5 Практична цінність та перспективи. 
Створений програмний продукт «Подарунок» має високу практичну 
цінність для кінцевих користувачів, оскільки автоматизує культуру дарування 
подарунків та усуває проблему дублювання презентів. Проєкт успішно 
реалізовано, розгорнуто та оптимізовано для роботи в локальному середовищі, 
що забезпечує максимальну стабільність та незалежність архітектури. 
Подальший розвиток проєкту вбачається у розширенні аналітичного модуля для 
відстеження динаміки цін та інтеграції системи push-сповіщень про оновлення в 
списках. 
  
80 
ЧДТУ.262258.019 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Bcrypt NPM Package [Електронний ресурс] / npm, Inc. - Режим 
доступу: https://www.npmjs.com/package/bcrypt (дата звернення: 20.03.2026). 
2 Cheerio API Documentation [Електронний ресурс]. - Режим доступу: 
https://cheerio.js.org/docs/api/ (дата звернення: 20.03.2026). 
3 i18next Documentation [Електронний ресурс]. - Режим доступу: 
https://www.i18next.com/ (дата звернення: 20.03.2026). 
4 Intro to State Management with Next.js App Router [Електронний 
ресурс] / ProNextJS. - Режим доступу: https://www.pronextjs.dev/tutorials/state-
management/intro-to-state-management-with-next-js-app-router (дата звернення: 
20.03.2026). 
5 Lucide React Guide [Електронний ресурс]. - Режим доступу: 
https://lucide.dev/guide/react/ (дата звернення: 20.03.2026). 
6 Managing State in React [Електронний ресурс] / React. - Режим 
доступу: https://react.dev/learn/managing-state (дата звернення: 20.03.2026). 
7 Next.js app directory / App Router i18n [Електронний ресурс] / Locize 
Blog. - Режим доступу: https://www.locize.com/blog/next-app-dir-i18n/ (дата 
звернення: 20.03.2026). 
8 Next.js Documentation [Електронний ресурс]. - Режим доступу: 
https://nextjs.org/docs (дата звернення: 20.03.2026). 
9 Prisma Documentation [Електронний ресурс] / Prisma Data, Inc. - 
Режим доступу: https://www.prisma.io/docs (дата звернення: 20.03.2026). 
10 Puppeteer Documentation [Електронний ресурс] / OpenJS Foundation. - 
Режим доступу: https://pptr.dev (дата звернення: 20.03.2026). 
11 Radix UI Primitives Introduction [Електронний ресурс] / WorkOS. - 
Режим доступу: https://www.radix-ui.com/primitives/docs/overview/introduction 
(дата звернення: 20.03.2026). 
12 React Documentation [Електронний ресурс] / Meta Platforms, Inc. - 
Режим доступу: https://react.dev (дата звернення: 20.03.2026). 
81 
ЧДТУ.262258.019 ПЗ 
13 React Hook Form [Електронний ресурс]. - Режим доступу: 
https://react-hook-form.com (дата звернення: 20.03.2026). 
14 React Hook Form – Get Started [Електронний ресурс]. - Режим 
доступу: https://react-hook-form.com/get-started (дата звернення: 20.03.2026). 
15 Redis Documentation [Електронний ресурс] / Redis Ltd. - Режим 
доступу: https://redis.io/docs/latest/ (дата звернення: 20.03.2026). 
16 Redis Getting Started [Електронний ресурс] / Redis Ltd. - Режим 
доступу: https://redis.io/docs/latest/get-started/ (дата звернення: 20.03.2026). 
17 State Management with Next.js [Електронний ресурс] / ProNextJS. - 
Режим доступу: https://www.pronextjs.dev/tutorials/state-management (дата 
звернення: 20.03.2026). 
18 Supabase Documentation [Електронний ресурс] / Supabase. - Режим 
доступу: https://supabase.com/docs (дата звернення: 20.03.2026). 
19 Swagger UI [Електронний ресурс] / SmartBear Software. - Режим 
доступу: https://swagger.io/tools/swagger-ui/ (дата звернення: 20.03.2026). 
20 Tailwind CSS Documentation [Електронний ресурс] / Tailwind Labs 
Inc. - Режим доступу: https://tailwindcss.com/docs/installation/using-vite (дата 
звернення: 20.03.2026). 
21 TypeScript Handbook [Електронний ресурс] / Microsoft. - Режим 
доступу: https://www.typescriptlang.org/docs/handbook/intro.html (дата звернення: 
20.03.2026). 
22 Zod Documentation [Електронний ресурс]. - Режим доступу: 
https://zod.dev (дата звернення: 20.03.2026). 
82 
ДОДАТОК А 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2026 р. 
Web-сервіс «Подарунок» 
Специфікація 
482 ЧДТУ 262258.019 
Листів 2 
Розробник ________________ Прудиус В.М. 
Керівник ________________ Метелап В.В. 
2026 
482 ЧДТУ 262258.019 
Позначення Найменування Примітка 
482 ЧДТУ 262258 12 01 Лістинг програм 
482 ЧДТУ 262258 90 01 Графічні матеріали 
482 ЧДТУ 262258 34 01 Інструкція  користувачеві 
84 
ДОДАТОК Б 
Web-сервіс «Подарунок» 
Лістинг програм 
482 ЧДТУ 262258.019 12 01 
Листів 8 
Розробник  ________________  Прудиус В.М. 
2026
482 ЧДТУ 262258 12 01 2 
ЗМІСТ 
Лістинг Б.1 – Архітектура бази даних (Prisma ORM)..................................................3 
Лістинг Б.2 – Реалізація RESTful API (Створення списку бажань) ...........................4 
Лістинг Б.3 – Глобальне управління станом (React Context API) ..............................5 
Лістинг Б.4 – Патерн "Фабрика" (Factory) для парсингу товарів...............................6 
86 
482 ЧДТУ 262258 12 01 3 
Лістинг Б.1 – Архітектура бази даних (Prisma ORM) 
// Модель Користувача 
model User { 
  id String   @id @default(cuid()) 
  name String 
  username  String   @unique 
  email String   @unique 
  password  String 
  avatar String   @default("/placeholder-user.jpg") 
  wishlists   Wishlist[] 
  bookedItems WishlistItem[] @relation("BookedItems") 
  createdAt DateTime @default(now()) 
  updatedAt DateTime @updatedAt 
} 
// Модель Списку бажань 
model Wishlist { 
  id String   @id @default(cuid()) 
  name String 
  description String   @default("") 
  emoji String   @default("��")
  isPrivate   Boolean  @default(false) 
  accessKey   String?  @unique 
  userId String 
  user User @relation(fields: [userId], references: 
[id], onDelete: Cascade) 
  items WishlistItem[] 
  createdAt   DateTime @default(now()) 
  updatedAt   DateTime @updatedAt 
} 
// Модель Елементу списку (Товару) 
model WishlistItem { 
  id String @id @default(cuid()) 
  title String 
  price Float  @default(0) 
  url String @default("") 
  image String @default("") 
  priority String @default("medium") 
  wishlistId String 
  wishlist   Wishlist @relation(fields: [wishlistId], references: 
[id], onDelete: Cascade) 
87 
482 ЧДТУ 262258 12 01 4 
  isBooked   Boolean @default(false) 
  bookedById String? 
  bookedBy   User?   @relation("BookedItems", fields: 
[bookedById], references: [id], onDelete: SetNull) 
} 
Лістинг Б.2 – Реалізація RESTful API (Створення списку бажань) 
import { NextResponse } from "next/server" 
import { prisma } from "@/lib/db" 
import { getAuthUserId } from "@/lib/auth" 
function generateAccessKey(): string { 
const chars = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789" 
const part1 = Array.from({ length: 3 }, () => 
chars[Math.floor(Math.random() * chars.length)]).join("") 
const part2 = Array.from({ length: 3 }, () => 
chars[Math.floor(Math.random() * chars.length)]).join("") 
return `WISH-${part1}-${part2}` 
} 
// POST /api/wishlists - Create a new wishlist 
export async function POST(req: Request) { 
try { 
const userId = await getAuthUserId() 
if (!userId) { 
return NextResponse.json({ error: "Unauthorized" }, { 
status: 401 }) 
} 
const { name, description, emoji, isPrivate } = await 
req.json() 
if (!name) { 
return NextResponse.json({ error: "Name is required" 
}, { status: 400 }) 
} 
const wishlist = await prisma.wishlist.create({ 
data: { 
name, 
description: description || "", 
emoji: emoji || "��",
isPrivate: isPrivate ?? false, 
accessKey: isPrivate ? generateAccessKey() : 
null, 
userId, 
}, 
88 
482 ЧДТУ 262258 12 01 5 
include: { items: true }, 
}) 
return NextResponse.json({ wishlist }, { status: 201 }) 
} catch (error) { 
console.error("Create wishlist error:", error) 
return NextResponse.json({ error: "Internal server error" 
}, { status: 500 }) 
} 
}
Лістинг Б.3 – Глобальне управління станом (React Context API) 
"use client" 
import { createContext, useContext, useState, useEffect, 
useCallback, type ReactNode } from "react" 
import type { User, Wishlist, WishlistItem } from "./types" 
// Визначення інтерфейсу стану додатку 
interface AppState { 
user: User | null; 
isLoading: boolean; 
wishlists: Wishlist[]; 
createWishlist: (data: any) => Promise<Wishlist>; 
addItemToWishlist: (wishlistId: string, item: any) => 
Promise<void>; 
// ... інші методи 
} 
const AppContext = createContext<AppState | undefined>(undefined) 
export function AppProvider({ children }: { children: ReactNode 
}) { 
const [user, setUser] = useState<User | null>(null) 
const [wishlists, setWishlists] = useState<Wishlist[]>([]) 
const [isLoading, setIsLoading] = useState(true) 
// Завантаження даних з API 
const fetchWishlists = useCallback(async () => { 
try { 
const res = await fetch("/api/wishlists") 
if (res.ok) { 
const data = await res.json() 
setWishlists(data.wishlists) 
   } 
} catch (error) { 
console.error("Failed to fetch wishlists:", error) 
} 
89 
482 ЧДТУ 262258 12 01 6 
}, []) 
// Відстеження зміни користувача 
useEffect(() => { 
if (user) { 
fetchWishlists() 
} else { 
setWishlists([]) 
} 
}, [user, fetchWishlists]) 
// Приклад методу зміни стану 
const createWishlist = async (data: any) => { 
const res = await fetch("/api/wishlists", { 
method: "POST", 
headers: { "Content-Type": "application/json" }, 
body: JSON.stringify(data), 
}) 
const result = await res.json() 
setWishlists((prev) => [result.wishlist, ...prev]) 
return result.wishlist 
} 
return (
<AppContext.Provider value={{ user, isLoading, wishlists, 
createWishlist, addItemToWishlist }}> 
{children} 
</AppContext.Provider> 
) 
} 
// Кастомний хук для використання сховища 
export function useApp() { 
const context = useContext(AppContext) 
if (context === undefined) { 
throw new Error("useApp must be used within an 
AppProvider") 
} 
return context 
}
Лістинг Б.4 – Патерн "Фабрика" (Factory) для парсингу товарів 
import type { ProductData, ProductParser } from "./types" 
import { fetchHtml, getStoreName, getCachedParse, setCachedParse 
} from "./utils" 
import { getFromRedisCache, saveToRedisCache } from "./redis-
cache" 
import { UniversalParser } from "./universal" 
90 
482 ЧДТУ 262258 12 01 7 
import { RozetkaParser } from "./sites/rozetka" 
import { ComfyParser } from "./sites/comfy"  
// ... інші парсери 
/** 
* Фабричний метод для вибору парсера на основі URL
*/
function getParser(url: string): ProductParser { 
const domain = new URL(url).hostname.toLowerCase() 
if (domain.includes("rozetka")) return new RozetkaParser() 
if (domain.includes("comfy.ua")) return new ComfyParser() 
// ... логіка вибору для інших магазинів 
return new UniversalParser() // Парсер за замовчуванням 
} 
/** 
* Головна функція парсингу з дворівневим кешуванням
*/
export async function parseProduct(url: string): 
Promise<ProductData> { 
// 1. Перевірка кешу в пам'яті (швидкий доступ) 
const cached = getCachedParse(url) 
if (cached) return cached 
// 2. Перевірка кешу Redis (постійне зберігання) 
const redisCached = await getFromRedisCache(url) 
if (redisCached) { 
setCachedParse(url, redisCached) 
return redisCached 
} 
// 3. Завантаження HTML сторінки 
const html = await fetchHtml(url, false) 
// 4. Отримання відповідного парсера та вилучення даних 
const parser = getParser(url) 
const data = parser.parse(url, html) 
const result = { 
...data, 
source_url: data.source_url || url, 
store_name: data.store_name || getStoreName(url), 
} 
// 5. Збереження результату в кеш 
if (result.title || result.price > 0) { 
setCachedParse(url, result) 
91 
482 ЧДТУ 262258 12 01 8 
await saveToRedisCache(url, result) 
} 
return result 
} 
92 
ДОДАТОК В 
Web-сервіс «Подарунок» 
Інструкція користувачеві  
482 ЧДТУ 262258 34 01 
Листів 9 
Розробник  ________________  Прудиус В.М. 
2026 
482 ЧДТУ 262258 34 01 2 
Для доступу до функціоналу створення власного простору та збереження 
бажань користувач повинен увійти в систему. На сторінці авторизації необхідно 
ввести прив'язану електронну пошту та пароль. Також передбачена можливість 
відновлення доступу за допомогою кнопки «Забули пароль?».  
Рисунок В.1 - Сторінка авторизації користувача 
Якщо користувач ще не має власного акаунту, він може перейти до форми 
створення нового облікового запису. На сторінці реєстрації необхідно вказати 
своє ім'я, прізвище, електронну пошту, унікальний нікнейм та надійний пароль 
для захисту даних. 
94 
482 ЧДТУ 262258 34 01 3 
Рисунок В.2 – Форма реєстрації нового облікового запису 
Головна сторінка (Landing page) веб-сервісу презентує ключові можливості 
застосунку: збереження улюблених товарів з будь-яких магазинів, шеринг 
безпечними лінками з друзями та зручна організація процесу дарування. Звідси 
користувач може швидко перейти до створення власного вишлісту.  
95 
482 ЧДТУ 262258 34 01 4 
Рисунок В.3 - Головна сторінка веб-сервісу 
Після успішної авторизації відкривається особистий кабінет («Мій 
простір»). У верхній частині відображається інформація профілю: аватар, ім'я, 
нікнейм та загальна статистика (кількість списків, бажань та їхня сумарна 
вартість). У вкладці «Мої вишлісти» користувач може переглядати свої створені 
списки у вигляді карток та створювати нові. 
96 
482 ЧДТУ 262258 34 01 5 
Рисунок В.4 - Особистий кабінет (вкладка «Мої вишлісти») 
Для пошуку ідей передбачено розділ «Цікаве» (сторінка «Надихайся»). Тут 
можна переглядати публічні бажання інших користувачів, користуватися 
зручним рядком пошуку за брендами та товарами, а також застосовувати фільтри 
для сортування пропозицій.  
97 
482 ЧДТУ 262258 34 01 6 
Рисунок В.5 – Сторінка пошуку та натхнення («Цікаве») 
Сервіс підтримує багатомовний інтерфейс. У верхній навігаційній панелі 
користувач може відкрити випадаючий список і змінити мову системи, обравши 
один із запропонованих варіантів (наприклад, Українська, English, Polski тощо).  
Рисунок В.6 – Меню вибору мови інтерфейсу 
98 
482 ЧДТУ 262258 34 01 7 
При переході до конкретного вишлісту відкривається сторінка з його 
деталями. Всі додані товари відображаються у вигляді списку з фотографіями, 
актуальними цінами та посиланнями на магазини. На цій сторінці доступні 
інструменти для редагування списку, додавання нових бажань або генерації 
посилання для поширення.  
Рисунок В.7 – Сторінка перегляду конкретного списку бажань 
Додавання нового товару відбувається через спеціальне модальне вікно. 
Користувачу достатньо вставити лінк на товар, після чого система спробує 
автоматично завантажити деталі. Також можна вказати пріоритетність бажання 
(наприклад, «Треба на вчора» чи «Дуже хочу») та додати власні текстові нотатки 
(розмір, колір, модель).  
99 
482 ЧДТУ 262258 34 01 8 
Рисунок В.8 – Модальне вікно додавання товару у вишліст 
Після збереження даних новий товар миттєво з'являється у списку. 
Відображається його назва, магазин, ціна та завантажене зображення, після чого 
він стає доступним для перегляду та бронювання.  
Рисунок В.9 – Відображення доданого товару у списку 
100 
482 ЧДТУ 262258 34 01 9 
Для перегляду приватних списків, якими поділилися інші користувачі, 
використовується вкладка «Поділилися зі мною». Тут знаходиться поле для 
введення унікального ключа доступу (наприклад, WISH-88X-J92), який дозволяє 
розблокувати захищений вишліст.  
Рисунок В.10 – Введення ключа доступу до приватного вишлісту 
У вкладці «Заброньовані мною» відображаються подарунки з чужих 
списків, які користувач вирішив придбати. Система бронювання працює 
відкрито: статус бронювання не приховується, що дозволяє власнику вишлісту 
бачити актуальні статуси та знати, які товари вже заброньовано. З цієї вкладки 
можна також скасувати своє бронювання за потреби.  
Рисунок В.11 – Вкладка товарів, заброньованих користувачем 
101 
ДОДАТОК Г 
Web-сервіс «Подарунок» 
Графічні матеріали  
482 ЧДТУ 262258 90 01 
Листів 13 
Розробник  ________________  Прудиус В.М. 
2026
482 ЧДТУ 262258 90 01 2 
ЗМІСТ 
Рис. В.1 – Титульний слайд презентації…………………………………………………………3 
Рис. В.2 – Мета та завдання..……………………………………………………………………..3 
Рис. В.3 – Аналіз предметної області…………….………………………………………………4 
Рис. В.4 – Актуальність…………………...………………………………………………………4 
Рис. В.5 – Аналіз методів вирішення……………………………………………………………..5 
Рис. В.6 – Постановка задачі……………………………………………………………………...5 
Рис. В.7 – Аналіз вимог…………….……………………………………………………………..6 
Рис. В.8 – Детальні вимоги……………..………………………………………………………...6 
Рис. В.9 – Діаграма Прецедентів….……………………………………………………………...7 
Рис. В.10 – Логічна структура…………………………………………………. ………………..7 
Рис. В.11 – Архітектура ситсеми……………………………………………………………... …8 
Рис. В.12 – Моделювання поведінки (частина 1)…………….……………………………….....8 
Рис. В.13 – Моделювання поведінки (частина 2)….…………………………………………….9 
Рис. В.14 – Стек технологій……..………………………………………………………………...9 
Рис. В.15 – Структурна та функціональна схеми…..…………………………………………...10 
Рис. В.16 – Логічна схема…….………………………………………………………………......10 
Рис. В.17 – Структура Бази Даних……….………………………………………………………11 
Рис. В.18 – Інтерфейс користувача……...……………………………………………………….11 
Рис. В.19 – Тестування……………………………………………………………………………12 
Рис. В.20 – Висновки…………………………………..………………………………………….12 
Рис. В.21 – Дякую за увагу………………………..………………………………………………13 
103 
482 ЧДТУ 262258 90 01 3 
Рис. В.1 – Титульний слайд презентації 
Рис. В.2 – Мета та завдання 
104 
482 ЧДТУ 262258 90 01 4 
Рис. В.3 – Аналіз предметної області 
Рис. В.4 – Актуальність 
105 
482 ЧДТУ 262258 90 01 5 
Рис. В.5 – Аналіз методів вирішення 
Рис. В.6 – Постановка задачі 
106 
482 ЧДТУ 262258 90 01 6 
Рис. В.7 – Аналіз вимог 
Рис. В.8 – Детальні вимоги 
107 
482 ЧДТУ 262258 90 01 7 
Рис. В.9 – Діаграма прецедентів 
Рис. В.10 – Логічна структура 
108 
482 ЧДТУ 262258 90 01 8 
Рис. В.11 – Архітектурна система 
Рис. В.12 – Моделювання поведінки (1 частина) 
109 
482 ЧДТУ 262258 90 01 9 
Рис. В.13 – Моделювання поведінки (2 частина) 
Рис. В.14 – Стек технологій 
110 
482 ЧДТУ 262258 90 01 10 
Рис. В.15 – Структурна та функціональна схема 
Рис. В.16 – Логічна схема 
111 
482 ЧДТУ 262258 90 01 11 
Рис. В.17 – Структура Бази Даних 
Рис. В.18 – Інтерфейс користувача 
112 
482 ЧДТУ 262258 90 01 12 
Рис. В.19 – Тестування 
Рис. В.20 – Висновки 
113 
482 ЧДТУ 262258 90 01 13
4
Рис. В.21 – Дякую за увагу 
114