Технологія розробки програмного забезпечення для оптимізації пошуку в системах маркетплейсу цифрового мистецтва

Кужденко, Максим Володимирович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9163
Title:	Технологія розробки програмного забезпечення для оптимізації пошуку в системах маркетплейсу цифрового мистецтва
Authors:	Олексюк, Вадим Володимирович Кужденко, Максим Володимирович
Keywords:	розробка програмного забезпечення;нейромережі;графічне розпізнавання;цифрове мистецтво;системи пошуку;класифікація зображень
Issue Date:	2023
Abstract:	Кужденко М.В. Технологія розробки програмного забезпечення для оптимізації пошуку в системах маркетплейсу цифрового мистецтва. 121 «Інженерія програмного забезпечення» Черкаський державний технологічний університет Черкаси 2023 Кваліфікаційна робота магістра "Технологія розробки програмного забезпечення для оптимізації пошуку в системах маркетплейсу цифрового мистецтва" присвячена розробці та впровадженню ефективної технології для оптимізації пошуку в цифрових маркетплейсах мистецтва на основі штучного інтелекту. Робота вивчає існуючі проблеми в області пошуку в контексті пошуку серед будь-яких цифрових предметів та пропонує новий підхід для їх вирішення. Автор досліджує інструменти та методи, що використовуються у сучасних системах маркетплейсів для пошуку та категоризації цифрових товарів. Зокрема, акцент роботи приділяється вдосконаленню алгоритмів пошуку, які дозволяють забезпечити користувачам швидкий і точний доступ до необхідної інформації. Магістерська робота також описує розроблене програмне забезпечення, яке імплементує запропоновану технологію. Програма демонструє свою ефективність через проведення експериментів та порівняння з існуючими системами. Крім того, в роботі обговорюються можливості подальшого розвитку та вдосконалення запропонованого підходу для використання в реальних умовах експлуатації. Отже, магістерська робота вносить важливий внесок у розвиток сучасних технологій у сфері цифрового мистецтва, надаючи конкретні рекомендації щодо оптимізації пошуку в системах маркетплейсів та покращення взаємодії користувачів з цифровими творами мистецтва.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9163
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Пояснювальна_записка_2023_Кужденко_М_В.pdf Restricted Access		5.62 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
 
  
ЧДТУ .232219.005 ПЗ 
2  
ЧДТУ .232219.005 ПЗ 
3  
ЧДТУ .232219.005 ПЗ 
АНОТАЦІЯ 
Кужденко М.В. 
Технологія розробки програмного забезпечення для оптимізації пошуку в 
системах маркетплейсу цифрового мистецтва. 
121 «Інженерія програмного забезпечення» 
Черкаський державний технологічний університет 
Черкаси 2023 
Кваліфікаційна робота магістра "Технологія розробки програмного 
забезпечення для оптимізації пошуку в системах маркетплейсу цифрового 
мистецтва" присвячена розробці та впровадженню ефективної технології для 
оптимізації пошуку в цифрових маркетплейсах мистецтва на основі штучного 
інтелекту. Робота вивчає існуючі проблеми в області пошуку в контексті пошуку 
серед будь-яких цифрових предметів та пропонує новий підхід для їх вирішення. 
Автор досліджує інструменти та методи, що використовуються у сучасних 
системах маркетплейсів для пошуку та категоризації цифрових товарів. Зокрема, 
акцент роботи приділяється вдосконаленню алгоритмів пошуку, які дозволяють 
забезпечити користувачам швидкий і точний доступ до необхідної інформації. 
Магістерська робота також описує розроблене програмне забезпечення, яке 
імплементує запропоновану технологію. Програма демонструє свою 
ефективність через проведення експериментів та порівняння з існуючими 
системами. Крім того, в роботі обговорюються можливості подальшого розвитку 
та вдосконалення запропонованого підходу для використання в реальних умовах 
експлуатації. 
Отже, магістерська робота вносить важливий внесок у розвиток сучасних 
технологій у сфері цифрового мистецтва, надаючи конкретні рекомендації щодо 
оптимізації пошуку в системах маркетплейсів та покращення взаємодії 
користувачів з цифровими творами мистецтва. 
Ключові слова: розробка програмного забезпечення, нейромережі, графічне 
розпізнавання, цифрове мистецтво, системи пошуку, класифікація зображень.
4 
ЧДТУ .232219.005 ПЗ 
ABSTRACT 
Kuzhdenko M.V. 
Software Development Technology for Optimization of Search in Digital Art 
Marketplace Systems 
121 «Software engineering» 
Cherkasy State Technological University 
Cherkasy 2023 
The thesis "Software Development Technology for Optimization of Search in 
Digital Art Marketplace Systems" is dedicated to the development and implementation 
of an efficient technology for optimizing search in digital art marketplaces. The work 
examines existing problems in the field of search within the context of digital art and 
proposes a novel approach to address these challenges. 
The author explores tools and methods employed in contemporary marketplace 
systems for the search and categorization of digital artworks. Specifically, the focus of 
the thesis is on enhancing search algorithms to provide users with fast and accurate 
access to the necessary information. 
The thesis also describes the developed software that implements the proposed 
technology. The program demonstrates its effectiveness through experiments and 
comparisons with existing systems. Additionally, the thesis discusses possibilities for 
further development and improvement of the proposed approach for real-world 
deployment. 
In summary, the thesis makes a significant contribution to the advancement of 
modern technologies in the field of digital art, offering concrete recommendations for 
optimizing search in marketplace systems and enhancing user interaction with digital 
art pieces. 
Key words: Software development, neuro models, graphical identification, 
digital art, search engines, image classification. 
 
5 
ЧДТУ .232219.005 ПЗ 
 
ЗМІСТ 
ВСТУП.......................................................................................................................... 2 
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань.............. 8 
Розділ 2 Теоретичні та експериментальні достідження..................................... 17 
1 Мета Дослідження..........................................................................................27 
2 Вибір Алгоритмів........................................................................................... 27 
3 Методологія експерименту............................................................................ 28 
4 Проведення експерименту............................................................................. 28 
5 Графічне представлення результатів.............................................................29 
Розділ 3 Впровадження результатів досліджень у практику, проектування 
програмного забезпечення інформаційних систем............................................. 34 
3.1. Моделювання предметної області................................................................34 
3.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області 34 
3.1.2 Елементи моделювання предметної області 35 
3.1.3 Робоча область моделювання 36 
3.2. Формування та аналіз вимог........................................................................ 37 
3.2.1 Формування вимог до програмного забезпечення. Первинні та детальні 
вимоги. Вимоги замовника та розробника. Функціональні та не 
функціональні вимоги. 38 
3.2.2 Формування вимог за допомогою діаграм прецедентів 42 
3.2.3 Проектування логічної структури програмного комплексу 47 
3.2.3.1 Діаграми класів...................................................................................... 47 
3.2.3.2 Діаграми пакетів.................................................................................... 52 
3.2.4 Архітектурне програмування 54 
3.2.4.1 Діаграма компонентів............................................................................54 
3.2.4.2 Розгортання програмної системи на апаратних засобах.....................55 
3.2.5 Моделювання поведінки системи 56 
3.2.5.1 Діаграма діяльності............................................................................... 56 
3.2.5.2 Діаграма послідовності......................................................................... 59 
3.2.5.4 Діаграма скінченного автомату............................................................ 64 
6 
ЧДТУ .232219.005 ПЗ 
Розділ 4 Розробка та тестування програмного забезпечення............................ 66 
4.1 Розробка програмного комплексу.................................................................66 
4.1.1Обгрунтування вибору засобів реалізації 66 
4.1.2 Опис структурної (функціональної) системи 69 
4.1.3 Опис логічної системи 73 
4.1.4 Розробка бази даних 76 
4.1.5 Розробка інтерфейсу користувача 77 
4.2 Тестування системи........................................................................................... 84 
4.2.1 Модульне тестування 84 
4.2.2 Інтеграційне тестування 87 
4.2.3 Системне тестування 88 
4.2.4 Приймальне тестування 90 
4.3 Приклади впровадження програмного комплексу.......................................... 95 
 
 
7 
ЧДТУ .232219.005 ПЗ 
ВСТУП 
У зв'язку з швидким розвитком цифрових технологій та зростанням 
популярності цифрового мистецтва, маркетплейси цифрового мистецтва стали 
ключовим елементом для представлення, розповсюдження та придбання 
цифрових творів мистецтва. Ці онлайн-платформи створюють унікальне 
середовище для взаємодії митців та любителів мистецтва, дозволяючи творчим 
індивідуумам широко представляти свої твори та знаходити зацікавлених 
покупців. 
Маркетплейси цифрового мистецтва визначаються своєю різноманітністю 
та об'ємами доступних творів, що варіюються від цифрових ілюстрацій та 
живопису до анімації та інших цифрових форм виразності. Завдяки такій 
широкій різноманітності, користувачі мають можливість обирати та придбавати 
твори, які відповідають їхнім уподобанням та індивідуальним смакам. 
Однак із зростанням обсягу цифрового мистецтва, виникає виклик 
оптимізації процесу пошуку та відбору цих творів на маркетплейсах. Користувачі 
мають велике бажання знайти та придбати унікальні та значущі твори швидко та 
зручно, що вимагає вдосконалення існуючих технологій пошуку. 
Дипломна робота "Технологія розробки програмного забезпечення для 
оптимізації пошуку в системах маркетплейсу цифрового мистецтва" присвячена 
вирішенню цього завдання. Вона має на меті вивчення, аналіз та розробку 
програмного забезпечення, що спрямоване на поліпшення якості та ефективності 
процесу пошуку цифрових творів мистецтва на маркетплейсах. Робота прагне 
забезпечити користувачам максимально зручний та інтелектуальний 
інструментарій для вибору та взаємодії з цифровим мистецтвом на цих 
платформах. 
Актуальність теми достідження 
Зростаюча популярність маркетплейсів цифрового мистецтва та надмірне 
розмаїття цифрового контенту створюють високий попит на оптимізацію 
інструментів пошуку на цих платформах. Користувачі, які шукають унікальні та 
персоналізовані твори, потребують більш ефективних засобів фільтрації та 
8 
ЧДТУ .232219.005 ПЗ 
відбору, аби забезпечити їм задоволення від інтеракції з цифровим мистецтвом. 
Актуальність цього дослідження полягає в тому, щоб визначити і вирішити 
сучасні виклики та обмеження у сфері пошуку на маркетплейсах цифрового 
мистецтва. Підвищення точності та швидкості пошуку, а також покращення 
особистої адаптації рекомендацій можуть значно полегшити взаємодію 
користувачів з цифровим мистецтвом та сприяти підтримці та розвитку творчих 
індивідів. 
Зокрема, із зростанням конкуренції на цьому ринку, інноваційні технології 
в області пошуку можуть забезпечити конкурентну перевагу для маркетплейсів, 
сприяючи залученню та утриманню активного користувацького спільноти. Таке 
дослідження має потенціал перетворити спосіб, яким користувачі взаємодіють із 
цифровим мистецтвом, роблячи цей процес більш інтуїтивним, зручним та 
особистим. 
Мета і завдання дослідження 
Головною метою цього дослідження є розробка та впровадження технології 
програмного забезпечення, спрямованої на оптимізацію процесу пошуку в 
системах маркетплейсу цифрового мистецтва. Конкретно, дослідження прагне 
покращити якість та швидкість пошуку цифрових творів мистецтва для кінцевих 
користувачів, забезпечуючи їм більш зручний та ефективний інструмент для 
взаємодії з цифровим мистецтвом на платформах маркетплейсів. 
Дослідження ставить перед собою завдання розробити новий алгоритм 
пошуку та програмне забезпечення, яке впроваджує цей алгоритм, з метою 
забезпечити користувачам максимально ефективний та задовільний досвід 
вибору цифрових творів мистецтва. Основні аспекти дослідження включають 
аналіз існуючих технологій, розробку нового програмного забезпечення, 
експериментальне тестування його ефективності та впровадження отриманих 
результатів у реальне середовище маркетплейсів цифрового мистецтва. 
Також мета дослідження включає в себе побудування прототипу 
маркетплейсу із імплементованим в ньому пошуком, який буде розроблений на 
основі штучного інтелекту. 
9 
ЧДТУ .232219.005 ПЗ 
Завдання дослідження: 
1. Аналіз існуючих технологій пошуку: Провести огляд та критичний 
аналіз існуючих методів та технологій пошуку на маркетплейсах цифрового 
мистецтва для виявлення недоліків та можливостей їх вдосконалення. 
2. Розробка програмного забезпечення: Розробити програмне 
забезпечення, яке імплементує новий алгоритм пошуку, спрямований на 
підвищення ефективності та точності вибору цифрових творів мистецтва на 
маркетплейсі. 
3. Експерименти та оцінка результатів: Провести експериментальне 
тестування розробленого програмного забезпечення, визначити його 
ефективність порівняно з існуючими системами та здійснити аналіз отриманих 
результатів. 
4. Впровадження та рекомендації: Розглянути можливості 
впровадження розробленої технології в реальному середовищі маркетплейсів 
цифрового мистецтва та сформулювати рекомендації для оптимального 
використання в практиці. 
5. Аналіз перспектив розвитку: Проаналізувати можливості та напрями 
подальшого розвитку розробленої технології, враховуючи динаміку змін в сфері 
цифрового мистецтва та вимог користувачів. 
Об'єктом дослідження є технології та методи розробки програмного 
забезпечення для оптимізації процесу пошуку та вибору цифрових творів 
мистецтва на маркетплейсах. 
Предметом дослідження є процес розробки програмного забезпечення 
систем пошуку із використанням машинного навчання. 
Методи дослідження: 
1. Аналітичні методи: Проведення огляду літератури, аналіз існуючих 
підходів та технологій у сфері цифрового мистецтва та маркетплейсів. 
2. Експериментальні методи: Розробка та тестування програмного 
забезпечення для реалізації нового алгоритму пошуку, а також проведення 
експериментів для оцінки його ефективності. 
10 
ЧДТУ .232219.005 ПЗ 
3. Статистичні методи: Аналіз отриманих даних в процесі 
експериментів для визначення ступеня покращення якості та швидкості пошуку. 
4. Комп'ютерне моделювання: Використання комп'ютерних технологій 
для розробки та імплементації програмного забезпечення, а також моделювання 
його взаємодії з користувачем. 
5. Системний аналіз: Вивчення та аналіз взаємодії компонентів 
маркетплейсів цифрового мистецтва для визначення оптимальних шляхів 
інтеграції нових технологій. 
Наукова новизна дослідження полягає в: 
Вдосконалено:  
1. Вдосконалено та розширено можливості систем пошуку 
2. Вдосконалено зручність завантаження матеріалів для авторів. 
Вперше розроблено: 
1. Веб додаток для можливості завантаження та перегляду творів 
мистецтва. 
Набуло подальшого розвитку: 
1. Розробці ефективного алгоритму пошуку: Розробка нового алгоритму, 
який враховує особливості пошуку цифрових творів мистецтва, забезпечуючи 
високу точність та швидкість вибору. 
2. Покращенні якості рекомендацій: Вдосконалення системи 
рекомендацій, що дозволяє більш точно враховувати індивідуальні уподобання та 
інтереси користувачів у виборі цифрового мистецтва. 
3. Інтеграції з існуючими системами: Розробка технології, яка має 
потенціал для ефективної інтеграції з існуючими маркетплейсами цифрового 
мистецтва без суттєвих змін у їх структурі чи архітектурі. 
4. Експериментальному та практичному підтвердженні результатів: 
Проведення об'єктивних експериментів, оцінка результатів та впровадження 
отриманих знань у реальному середовищі з метою забезпечення практичної 
користі для користувачів маркетплейсів цифрового мистецтва. 
5. Аналізі впливу на користувачів та ринок: Глибокий аналіз впливу 
11 
ЧДТУ .232219.005 ПЗ 
запропонованих технологій на задоволення та потреби користувачів, а також їх 
вплив на ринок цифрового мистецтва. 
Ці аспекти взаємодії, новаторськість у вдосконаленні пошукових систем та 
рекомендацій, а також практичне впровадження розроблених рішень роблять 
дослідження унікальним та актуальним у контексті сучасних викликів та 
можливостей в області цифрового мистецтва. 
Практичне значення отриманих результатів включає в себе: 
1. Розроблене програмне забезпечення спрямоване на створення та 
задоволення користувачів з пошуку та вибору унікальних творів. 
2. Впровадження нового алгоритму пошуку та системи рекомендацій 
може призвести до підвищення активності користувачів, збільшення кількості 
транзакцій. 
Отже, результати дослідження є поліпшення вибору кінцевим 
користувачем, потенційно значущий впливів в цілому. 
Особливий внесок автора 
В роботі реалізовано і запропоновано іноваційний підхід до оптимізації 
пошуку в системах. Ключові компоненти цього внеску описуються детальніше: 
Розробка Унікального Алгоритму Пошуку: Показано алгоритм пошуку, 
спеціально адаптований до особливостей та глибого розуміння точності 
результатів. 
Інтеграція Моделей Штучного Інтелекту: Використано інтелектуальну 
модель для автоматизації процесу розпізнавання тексту. Це підвищує 
персоналізацію та зручність користувачів під час взаємодії з пошуком. 
Реалізація Інтерфейсу з Покращеною Взаємодією: Є акцент на розробці 
простого та зручного інтерфейсу, що сприяє покращеній взаємодії користувачів, 
що робить процес взаємодії максимально приємним та доступним. 
Проведення Експериментальних Досліджень та Валідація Результатів: 
Здійснені експериментальні дослідження для запропонованих технологій та 
моделей. Отримані результати створюють нові стандарти в області систем 
пошуку. 
12 
ЧДТУ .232219.005 ПЗ 
Такий інтегральний та інноваційний підхід гарантує вагомий внесок у 
розвиток сучасних технологій мистецтва, роблячи цю дипломну роботу 
важливою та винятковою в галузі цифрового мистецтва. 
 
13 
ЧДТУ .232219.005 ПЗ 
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань 
У взязку із стрімким ростом технологій штучного інтелекту, наукових 
статтей на цю тему у відкритому доступі мною знайдено не було. Тому свою 
роботу я буду базувати на дослідженнях сучасних звичайних системах пошуку. 
Сучасні Пошукові Системи: За Кулісами Ефективності 
Із розвитком інтернету та великим обсягом інформації, сучасні пошукові 
системи стали необхідним інструментом для ефективного отримання потрібної 
інформації у величезному об'ємі даних. Розглянемо, як працюють ці системи та 
як вони забезпечують точні та швидкі результати. 
1 Індексація контенту: 
Індексація контенту є важливим етапом у функціонуванні сучасних 
пошукових систем, який спрямований на забезпечення ефективного та точного 
пошуку інформації серед величезного обсягу даних у світі Інтернету. 
Пошукові системи починають процес індексації з використання 
веб-краулерів, які автоматично переглядають та сканують веб-сторінки, 
витягуючи дані у формі HTML-коду. Це першочергове збирання контенту 
дозволяє системі отримати інформацію для подальшого аналізу. 
Після отримання контенту відбувається токенізація, або розбиття тексту на 
окремі токени чи слова. Наступним етапом є виділення ключових слів, тобто 
термінів, які мають велику інформаційну цінність та служать для ідентифікації 
теми сторінки. 
Деякі пошукові системи використовують лематизацію та стемінг для 
нормалізації слів, що дозволяє обробляти різні форми одного слова. Після цього 
проводиться фільтрація та видалення зайвої інформації, такої як HTML-теги та 
стоп-слова, які не несуть інформаційної цінності. 
Сформований текст піддається створенню індексу, де кожне ключове слово 
вказує на відповідні документи та їхні місця в цих документах. Цей 
структурований індекс стає основою для подальшого швидкого та точного 
пошуку інформації користувачем. 
Процес індексації є постійно оновлюваним, адже пошукові системи 
14 
ЧДТУ .232219.005 ПЗ 
періодично перескановують веб-сторінки для врахування нового контенту та 
змін. Цей механізм дозволяє системам надавати актуальні та релевантні 
результати у світі постійно зростаючої кількості інформації. 
2 Алгоритми ранжування:  
Алгоритми ранжування є необхідною складовою сучасних пошукових 
систем, визначаючи порядок виведення результатів пошуку для користувачів. 
Їхнє завдання - забезпечити максимально релевантні та інформативні результати 
відповідно до пошукового запиту. Розглянемо більше деталей, як ці алгоритми 
працюють. 
Визначення Релевантності: Алгоритми ранжування базуються на понятті 
релевантності, оцінюючи кожен документ чи веб-сторінку на їхню відповідність 
конкретному пошуковому запиту користувача. 
Параметри Ранжування: Визначення ранжування включає аналіз різних 
параметрів, таких як частота зустрічі ключових слів, авторитет веб-сайту, 
структура та інші фактори, що впливають на релевантність. 
Індивідуальні Фактори: Алгоритми враховують індивідуальні фактори, такі 
як локація користувача, історія пошуку та персоналізація, для надання 
індивідуалізованих результатів. 
PageRank: PageRank — важливий алгоритм, розроблений Google, який 
визначає авторитетність веб-сторінок на основі якісних та кількісних зв'язків. 
TF-IDF (Term Frequency-Inverse Document Frequency): TF-IDF визначає 
важливість термінів у документі, враховуючи частоту вживання у цьому 
документі та порівняно з іншими. 
Машинне Навчання: Сучасні системи використовують алгоритми 
машинного навчання для покращення ранжування, навчаючись на основі 
попередніх взаємодій користувачів та інших факторів. 
Click-Through Rate (CTR): CTR — це фактор, що враховує кількість кліків 
на результати порівняно з їхньою кількістю відображень. 
Байєсівська Фільтрація: Байєсівська фільтрація використовує ймовірнісний 
підхід для ранжування, враховуючи ймовірність того, що документ є 
15 
ЧДТУ .232219.005 ПЗ 
релевантним. 
Ці алгоритми, працюючи разом, забезпечують виведення найбільш 
релевантних та індивідуалізованих результатів для користувачів, постійно 
адаптуючись до змін у пошуковому середовищі. 
3 Машинне навчання:  
Машинне навчання в сучасних пошукових системах відіграє критичну 
роль, перетворюючи спосіб, яким системи аналізують, ранжують та надають 
результати користувачам. Низка підходів та застосувань МН включають: 
Аналіз Користувацьких Взаємодій: Машинне навчання аналізує взаємодії 
користувачів з пошуковою системою. На основі цих даних створюються моделі, 
які враховують, які результати користувачі вибирають та ігнорують. 
Ранжування та Персоналізація: МН визначає фактори, які роблять результат 
більш або менш релевантним для кожного конкретного користувача. Результати 
ранжуються відповідно до індивідуальних потреб та попередніх взаємодій. 
Аналіз Запитань та Семантичний Пошук: Застосування МН спрощує 
розуміння семантики пошукових запитань. Зокрема, моделі обробки природної 
мови розпізнають відтінки значень та зв'язки між словами. 
Корекція та Адаптація: Машинне навчання надає системі здатність 
коригувати свої моделі на основі нових даних, адаптуючись до змін у виборах 
користувачів. 
Персоналізовані Рекомендації: МН використовується для створення 
індивідуалізованих рекомендацій, аналізуючи інтереси та історію користувача. 
Адаптація до Змін: Машинне навчання дозволяє системі швидко 
адаптуватися до змін у попиті та модифікувати свої моделі. 
Боротьба з Маніпуляціями: МН виявляє та протидіє штучній маніпуляції 
системою, аналізуючи патерни та аномалії. 
Взаємодія цих аспектів дозволяє сучасним пошуковим системам 
забезпечувати ефективний, індивідуалізований та зручний досвід для 
користувачів у світі постійно зростаючого обсягу інформації. 
4 Семантичний пошук:  
16 
ЧДТУ .232219.005 ПЗ 
Сучасні пошукові системи використовують семантичний підхід для 
поліпшення рівня розуміння та релевантності результатів пошуку. Замість 
традиційного аналізу окремих ключових слів, семантичний пошук спрямований 
на розуміння сутностей, зв'язків та контексту запитань користувачів. 
Цей підхід використовує моделі обробки природної мови (NLP), щоб 
розпізнати синоніми, відтінки значень та інші аспекти мови, покращуючи 
розуміння користувацьких запитань. Семантичний аналіз змісту дозволяє 
системам розуміти тематику документів та статей, а не просто виділяти окремі 
ключові слова. 
Одним з важливих аспектів семантичного пошуку є зіставлення змісту, де 
система враховує не лише присутність ключових слів в документах, але і 
контекст, в якому вони використовуються. Також, застосування семантичних 
мереж допомагає створювати зв'язки між елементами інформації, що розширює 
можливості пошуку та виведення релевантних результатів. 
Семантичний підхід також враховує контекстуальний аналіз, що включає в 
себе розуміння місцезнаходження користувача, його попередніх запитань та 
інших параметрів для надання більш індивідуалізованих результатів. Важливим 
аспектом є і постійна адаптація до змін у структурі запитань та інтенцій 
користувачів. 
Загалом, семантичний пошук сприяє розвитку пошукових систем від 
простого аналізу тексту до більш глибокого розуміння сутностей, принципів та 
інтенцій, що дозволяє надавати точніші та більш інтелектуальні відповіді на 
користувацькі запитання. 
5 Швидкість та доступність:  
Ефективність пошукових систем також залежить від їхньої швидкості та 
доступності. Кешування результатів, географічне розподілення серверів та 
використання CDN (Content Delivery Network) гарантують швидкий доступ до 
інформації для користувачів з усього світу. 
Сучасні пошукові системи є складними технологічними конструкціями, які 
поєднують у собі алгоритми, машинне навчання та технології обробки мови. Їхня 
17 
ЧДТУ .232219.005 ПЗ 
постійна еволюція спрямована на забезпечення найкращого можливого 
користувацького досвіду в умовах надмірного обсягу інформації в Інтернеті. 
Порівняння із іншими системами пошуку 
На сьогоднішній день існують різноманітні маркетплейси цифрового 
мистецтва, кожен з яких використовує власні методи та технології для реалізації 
систем пошуку. Декілька з найбільш відомих аналогів та систем пошуку у цій 
області включають: 
1. Google Search: 
 
 
Рис 1.1 − Приклад google пошуку 
 
− Опис: Google, заснований в 1998 році, є провідним світовим 
пошуковим двигуном. Використовуючи інноваційні алгоритми, такі як 
PageRank та RankBrain, Google надає користувачам швидкий та точний 
доступ до різноманітної інформації. Від пошуку текстової інформації до 
зображень, відео та новин, Google є універсальним засобом отримання 
знань. Google використовує ряд алгоритмів, таких як PageRank та 
RankBrain, для надання точних та релевантних результатів пошуку. 
− Плюси: 
− Швидкість та ефективність. 
− Постійне оновлення алгоритмів. 
18 
ЧДТУ .232219.005 ПЗ 
− Мінуси: 
− Залежність від ключових слів, що може викликати спотворення 
результатів. 
− Приватність користувачів може бути питанням. 
2. Amazon Search: 
 
 
Рис 1.2 − Приклад пошуку amazon 
 
− Опис: Amazon, заснований в 1994 році, є найбільшим світовим 
онлайн-роздрібним магазином. Його система пошуку дозволяє 
мільйонам користувачів легко знаходити та придбавати товари, 
використовуючи різноманітні фільтри, рейтинги та рецензії. Система 
пошуку на Amazon дозволяє користувачам знаходити товари та 
фільтрувати їх за різними критеріями. 
− Плюси: 
− Широкий асортимент товарів. 
− Ефективна система рейтингів. 
19 
ЧДТУ .232219.005 ПЗ 
− Мінуси: 
− Можливий вплив рекламних показів на результати пошуку. 
− Залежність від рейтингів, які можуть бути маніпульовані. 
3. Netflix Recommendation System: 
 
 
Рис 1.3 − Рекомендаційна система Netflix 
 
− Опис: Netflix, створений у 1997 році, є провідним стрімінговим 
сервісом для перегляду фільмів та серіалів. Його система рекомендацій 
використовує алгоритми машинного навчання для аналізу переглядів 
користувачів та пропозиції персоналізованого контенту. 
− Плюси: 
− Персоналізовані рекомендації. 
− Адаптація до зміни вподобань користувача. 
− Мінуси: 
− Обмежена рознообразність рекомендацій. 
− Важливість попередніх взаємодій може призвести до фільтрування 
нового контенту. 
20 
ЧДТУ .232219.005 ПЗ 
4. Google Images Search: 
 
Рис 1.4 − Приклад пошуку по картинкам Google 
 
− Опис: Google Images, впроваджений у 2001 році, надає користувачам 
можливість знаходити та оцінювати зображення в Інтернеті. 
Використовуючи візуальні алгоритми та розпізнавання об'єктів, Google 
Images став важливим інструментом для пошуку візуальної інформації. 
Пошуковик Google для зображень використовує візуальні алгоритми та 
метадані для класифікації зображень. 
− Плюси: 
− Швидкість та точність візуального пошуку. 
− Можливість використання ключових слів та фільтрів. 
− Мінуси: 
− Обмежена здатність розпізнавання складних об'єктів. 
− Залежність від правильної класифікації тегів користувачами. 
5. Airbnb Search: 
21 
ЧДТУ .232219.005 ПЗ 
 
Рис 1.5 − Приклад Airbnb пошуку 
 
− Опис: Airbnb, створений у 2008 році, є світовим маркетплейсом для 
знаходження та бронювання житла. Його система пошуку дозволяє 
подорожуючим знаходити унікальні місця для проживання, враховуючи 
різні критерії, такі як ціна, місце та зручності. Система пошуку Airbnb 
дозволяє користувачам знаходити житло за різними критеріями та 
фільтрами. 
− Плюси: 
− Фільтрація за багатьма параметрами. 
− Рейтинги та відгуки для кращого вибору. 
− Мінуси: 
− Можливий вплив фотографій та описів на враження користувача. 
− Ризик несумісності з описом житла. 
Кожна система має свої переваги та недоліки, і їх вибір залежить від 
контексту та потреб користувачів. Враховуючи ці аспекти, розробка нової 
системи пошуку для маркетплейсів цифрового мистецтва може працювати над 
подоланням недоліків та покращенням позитивних аспектів існуючих рішень. 
 
22 
ЧДТУ .232219.005 ПЗ 
Розділ 2 Теоретичні та експериментальні достідження 
Для створення ефективної моделі пошуку в системі маркетплейсу 
цифрового мистецтва використовувалися наступні методи: 
2.1 Теоретичні дослідження 
Відповідно до наукової статті «Eight great tips for internal site search 
optimization», внутрішня оптимізація пошуку на сайті (Internal Site Search 
Optimization, ISSO) - це процес покращення функції пошуку на веб-сайті, щоб 
забезпечити кращий досвід користувача та збільшити конверсію. ISSO включає в 
себе такі аспекти, як: 
− аналіз даних про пошукові запити, поведінку та потік користувачів, щоб 
виявити проблеми, можливості та тренди 
− використання синонімів, варіацій, автозаповнення та автокорекції, щоб 
зробити пошук більш гнучким та релевантним 
− надання можливості фільтрувати та сортувати результати пошуку за 
різними параметрами, такими як ціна, категорія, рейтинг, дата тощо 
− показування рекомендацій та пов’язаних продуктів, щоб збільшити 
шанси на продаж та задовольнити різні потреби користувачів 
− тестування та вимірювання ефективності внутрішнього пошуку та 
вносити відповідні зміни, щоб підвищити його продуктивність 
ISSO є важливою частиною рутини оптимізації веб-сайту, оскільки вона 
впливає на задоволення, лояльність та прибутковість користувачів. За даними 
дослідження, 43% відвідувачів веб-сайту використовують внутрішній пошук, а ті, 
хто знаходять те, що шукають, мають на 216% більшу ймовірність 
конвертуватися, ніж ті, хто не використовує пошук. 
Пошук в маркетмлейсах цифрового мистецтва 
В системах пошуку надважлива точність запитів та кількість отриманих 
результатів. Найефективніші системи можна математично підрахувати за 
допомогою формул: 
− Precision (відповідність результатів пошуку до запиту користувача) - 
23 
ЧДТУ .232219.005 ПЗ 
це відношення кількості релевантних результатів пошуку до загальної кількості 
отриманих результатів. Ця формула показує, наскільки точно система пошуку 
відбирає потрібні вакансії для користувача. Формула для precision має вигляд: 
 
������������������ = ���� + ���� * ����                                     (2.1) 
 
де TP - це кількість істинно позитивних результатів (релевантні вакансії), а 
FP - це кількість хибно позитивних результатів (нерелевантні вакансії). 
− Recall - це відношення кількості релевантних результатів пошуку до 
загальної кількості існуючих релевантних результатів. Ця формула показує, 
наскільки повно система пошуку знаходить усі потрібні вакансії для користувача. 
Формула для recall має вигляд: 
 
������������ = ���� + ���� * ����                                           (2.2) 
 
де TP - це кількість істинно позитивних результатів (релевантні вакансії), а 
FN - це кількість хибно негативних результатів (релевантні вакансії, які не були 
знайдені). 
− F-measure - це гармонійне середнє між precision та recall, яке 
використовується для оцінки загальної якості системи пошуку. Ця формула 
показує, наскільки збалансовано система пошуку поєднує точність та повноту 
пошуку. Формула для F-measure має вигляд: 
 
�� − �������������� = ������������������ + ������������ * 2 * ������������                  (2. 3) 
 
Ці формули можна застосовувати до різних рівнів аналізу, наприклад, до 
окремих запитів, до груп запитів, до всієї системи пошуку тощо. Для обчислення 
цих формул потрібно мати дані про релевантність результатів пошуку, які можна 
отримати за допомогою експертної оцінки, зворотного зв’язку користувачів, 
аналізу поведінки користувачів тощо. 
24 
ЧДТУ .232219.005 ПЗ 
Маркетплейси мистецтва - це онлайн-платформи, які дозволяють купувати 
та продавати мистецькі твори, а саме любі види цифрових зображень. Пошук в 
маркетплейсах мистецтва має свої особливості та виклики, такі як: 
− велика різноманітність та непередбачуваність мистецьких творів, які 
можуть мати різні стилі, жанри, теми, авторів, роки створення тощо 
− висока ступінь суб’єктивності та емоційності мистецтва, яке може 
викликати різні враження та асоціації у різних користувачів 
− низька якість та недостатність метаданих про мистецькі твори, які 
можуть бути неповними, неточними, неконсистентними або відсутніми 
− висока ціна та рідкість деяких мистецьких творів, які можуть бути 
недоступними або обмеженими для більшості користувачів 
Пошук в маркетплейсах мистецтва вимагає від веб-сайту надати 
користувачам більш глибокий та широкий пошук, який би враховував не тільки 
технічні характеристики мистецьких творів, але й їхній смисл, контекст, історію, 
відгуки, цінність тощо. Також важливо забезпечити користувачам можливість 
порівнювати, оцінювати, коментувати та ділитися мистецькими творами, щоб 
збільшити їхній інтерес та довіру. 
Можливість вдосконалення пошуку 
Вдосконалення систем пошуку в маркетплейсах мистецтва - це процес 
покращення якості та релевантності результатів пошуку для користувачів, які 
шукають мистецькі твори. Цей процес включає в себе такі кроки, як: 
− збір та аналіз даних про пошукові запити, поведінку та задоволення 
користувачів, щоб визначити їхні потреби, проблеми та очікування 
− розробка та впровадження алгоритмів та методів пошуку, які 
використовують різні джерела та типи даних, такі як текст, зображення, 
звук, відео, семантика, онтології, машинне навчання тощо 
− тестування та оцінювання ефективності та точності системи пошуку, 
використовуючи різні метрики та критерії, такі як час відгуку, кількість 
результатів, релевантність, задоволення, конверсія тощо 
− оптимізація та покращення системи пошуку, враховуючи зворотний 
25 
ЧДТУ .232219.005 ПЗ 
зв’язок та відгуки користувачів, а також зміни в трендах та технологіях 
Вдосконалення систем пошуку в маркетплейсах мистецтва має багато 
переваг, як для користувачів, так і для власників веб-сайтів, такі як: 
− збільшення задоволення та лояльності користувачів, які отримують 
більш точні, релевантні та персоналізовані результати пошуку, що 
відповідають їхнім потребам, інтересам та смакам 
− збільшення конверсії та прибутковості веб-сайту, який приваблює 
більше відвідувачів, збільшує час перебування на сайті, зменшує 
відсоток відмов, підвищує середній чек та кількість повторних покупок 
− збільшення конкурентоспроможності та репутації веб-сайту, який 
відрізняється від інших маркетплейсів мистецтва своєю інноваційністю, 
якістю, авторитетністю та довірою 
− збільшення ефективності та продуктивності веб-сайту, який оптимізує 
свої ресурси, зменшує витрати, покращує свої процеси та адаптується 
до змін 
Таким чином, вдосконалення систем пошуку в маркетплейсах мистецтва є 
актуальною та перспективною темою для дослідження та розробки, яка може 
принести багато користі для всіх зацікавлених сторін. 
2.2 Експерементальні дослідження 
Для досліджень була використана мова програмування JavaScript, як для 
побудування клієнтської частини, так і для серверної. Це Дозволило прискорити 
розробку та зменшити потрібний рівень знань для  розробки. 
Як видно з рисунка 2.1, JavaScript займає лідуючі позиції у світі 
програмування через можливість  написання на ній як клієнтських додатків, так і 
серврених. 
І так як на клієнтській частині буде неможливо розгорнути усі необхідні 
моделі та бібліотеки для реалізації задуманого пошуку, він буде виконуватися на 
серверній частині, що може збільшити час, за який відбувається пошук, а в 
найгіршому випадку через перенагрузку сервера взагалі не відбутися. Тому для 
26 
ЧДТУ .232219.005 ПЗ 
сервера було обрано Node.JS, який найкраще підходить для таких ситуацій, а 
саме витримувати великий потік запитів з невеликим навантаженням 
 
 
Рис 2.1 − Найпопулярніші мови розробки (github) 
. 
 
Рис 2.2 − Популярність Node.js 
 
Також, відповідно графіку 2.2, наданому сайтом LinkedIn, популярність 
Node.JS досить висока через популяризацію використання стеку технологій 
MERN для швидкої еффективності розробки веб додатків, MERN – це 
абревіатура від Mongo, Express, React, Node.JS. Ці технології і будуть 
27 
ЧДТУ .232219.005 ПЗ 
протестовані та надалі використані у проекті. 
Відповідно до стеку MERN, протестована база даних буде MongoDB, це 
нереляційна база даних, яка дозволяє швидко та без зайвих проблем зберігати, 
читати, та редагувати інформацію всередині бази. Вона є 
документо-орієнтованою. 
 
 
Рис 2.3 − Популярність баз даних 
 
Також, відповідно до рисунку 2.3, MongoDB є досить поширеною, та лише 
покращується, подвигаючи загально прийняті бази, такі, як SQL. 
На етапі пошуку інструментів для тестування та побудови HTTP запитів, 
було знайдено декілька варіантів, а саме Swagger та Postman.  
Swagger - це комплексне рішення для роботи з API на всіх етапах розробки, 
від проектування до тестування. Swagger дозволяє автоматично генерувати 
документацію для API та надає інтуїтивний інтерфейс для його використання. 
Swagger підвищує продуктивність розробки та полегшує співпрацю між 
розробниками API та його користувачами, надаючи засоби для автоматизації 
28 
ЧДТУ .232219.005 ПЗ 
документування, уніфікації формату та візуалізації тестування API. 
Postman - це інструментарій для розробки API, який надає можливість 
розробляти, тестувати та документувати API. Postman має на меті спростити 
процес розробки, тестування та використання API за допомогою зручного 
інтерфейсу та багатого функціоналу. Swagger і Postman можуть бути використані 
для різних цілей і етапів розробки API, в залежності від ваших вимог. Якщо ви 
фокусуєтеся на розробці, документуванні та сумісності API, то Swagger буде 
кращим вибором. Він надає стандартний, машинний спосіб опису та визначення 
API за допомогою специфікації OpenAPI. Він покращує комунікацію між 
командами, впроваджує найкращі практики розробки API та надає інтерактивну 
документацію через інтерфейс користувача Swagger. 
Для забезпечення безпеки використовується JWT (JSON Web Token) для 
автентифікації користувачів. Він дозволить безпечно передавати інформацію на 
сервер, без потреби авторизації кожен раз при запиті. 
2.2.2 Оцінка ефективності системи: 
1 Мета Експерименту 
Метою експериментального дослідження є оцінка ефективності 
розробленої системи для оптимізації пошуку в системах маркетплейсу цифрового 
мистецтва. Дослідження спрямоване на визначення продуктивності, швидкодії та 
масштабованості системи в різних умовах використання. 
2 Експериментальна Методологія 
Конфігурації Архітектури: Реалізовано три різні конфігурації архітектури 
системи, включаючи мікросервісну, монолітну та комбіновану (гібридну) 
архітектуру. 
Тестовий Набір Даних: Використовувався тестовий набір даних, який 
містить різні типи цифрового мистецтва, з розміром та обсягом, що відображає 
реальні умови використання системи. 
Сценарії Використання: Створено різні сценарії використання, охоплюючи 
пошук за ключовими словами, фільтрацію за категоріями, та інші типові 
взаємодії користувачів. 
29 
ЧДТУ .232219.005 ПЗ 
Навантаження: Проведено тести на навантаження для визначення реакції 
системи на велику кількість одночасних запитів та її стійкість до зростаючого 
навантаження. 
3 Метрики та Формули швидкодії 
 
Швидкодія = Сумарний час відповіді
Кількість викликів           (2.4) 
 
Формула масштабованості 
 
Масштабованість = Загальний обсяг данних
Час обробки запиту          
(2.5) 
 
Формула ефективності 
 
Ефективність = Кількість взаємодій з мікросервісами
Загальна кількість взаємодій         
(2.6) 
 
4 Очікувані Результати 
Очікується, що мікросервісна архітектура буде продемонструє високу 
гнучкість та масштабованість при зменшенні часу відповіді на запити. Проведене 
експериментальне дослідження має допомогти визначити оптимальну 
конфігурацію системи для досягнення максимальної ефективності в умовах 
маркетплейсу цифрового мистецтва. 
2.2.3 Графічне представлення результатів: 
1 Обрані Метрики 
У цьому етапі експерименту використовувались ключові метрики, що 
визначали ефективність системи: 
− швидкодія Пошуку: Середній час відповіді на запити користувачів. 
30 
ЧДТУ .232219.005 ПЗ 
− масштабованість: Спроможність системи ефективно масштабуватися 
при зростанні обсягу даних. 
− коефіцієнт Завантаження Системи: Співвідношення фактичного обсягу 
роботи системи до її максимальної можливості. 
2 Графічні Представлення 
 
 
 Рис 2.4 − Графік швидкодії пошуку 
 
Порівняння середнього часу відповіді на запити для кожної конфігурації 
архітектури. 
 
31 
ЧДТУ .232219.005 ПЗ 
 
Рис 2.5 − Графік масштабованості 
Представлення здатності системи ефективно масштабуватися при зростанні 
обсягу даних. 
 
 
Рис 2.6 − Грацік коефіцієнту завантаження системи 
 
32 
ЧДТУ .232219.005 ПЗ 
Графічне визначення, наскільки інтенсивно система використовується у 
порівнянні з її максимальною можливістю. 
3 Аналіз та Висновки 
Графічне представлення результатів дозволяє визначити переваги та 
недоліки кожної конфігурації архітектури. За допомогою графіків можна виявити 
тенденції, визначити точки оптимальної продуктивності та виявити ефективніші 
аспекти системи. 
На основі аналізу графічних даних можна зробити висновки щодо того, яка 
конфігурація архітектури є найбільш підходящою для задач оптимізації пошуку в 
системах маркетплейсу цифрового мистецтва. Графічний підхід робить отримані 
результати більш доступними та зрозумілими для широкого кола читачів 
дослідження. 
2.2.4 Порівняльний аналіз алгоритмів пошуку: 
1 Мета Дослідження 
Метою даного розділу є проведення порівняльного аналізу різних 
алгоритмів пошуку в системах маркетплейсу цифрового мистецтва. Дослідження 
спрямоване на визначення ефективності та продуктивності різних алгоритмів, 
враховуючи їхню придатність для використання в контексті оптимізації пошуку. 
2 Вибір Алгоритмів 
Обрано кілька базових алгоритмів пошуку, які можуть бути використані для 
оптимізації пошуку в системах маркетплейсу цифрового мистецтва: 
− Лінійний Пошук: Простий алгоритм, який перебирає елементи послідовно 
до знаходження шуканого. 
− Бінарний Пошук: Ефективний алгоритм для впорядкованих даних, що 
швидко зменшує кількість порівнянь. 
− Пошук за Збалансованим Деревом: Використання структур даних, таких 
як AVL-дерева чи червоно-чорні дерева для оптимізації пошуку. 
− Алгоритми Машинного Навчання: Використання моделей машинного 
33 
ЧДТУ .232219.005 ПЗ 
навчання, таких як нейронні мережі, для автоматизованого і покращеного 
пошуку. 
3 Методологія експерименту 
− Тестовий Набір Даних: Використовується реальний та розношерстний 
тестовий набір даних, що відображає різні типи та стилі цифрового 
мистецтва. 
− Метрики Вимірювання: Вимірюємо час виконання пошуку, кількість 
порівнянь та точність результатів. 
− Сценарії Використання: Симулюються різні сценарії пошуку, 
включаючи пошук за ключовими словами, фільтрацію за категоріями та 
рейтингами. 
4 Проведення експерименту 
У розділі "Проведення Експерименту: Порівняльний Аналіз Алгоритмів 
Пошуку" обрано чотири ключових алгоритми для дослідження: Лінійний Пошук, 
Бінарний Пошук, Пошук за Збалансованим Деревом та Алгоритми Машинного 
Навчання, представлені нейронними мережами. Методологія експерименту 
передбачає використання реального та різноманітного тестового набору даних, 
що враховує різні стилі та типи цифрового мистецтва. Експеримент охоплює 
сценарії використання, такі як пошук за ключовими словами, фільтрація за 
категоріями та рейтингами. 
Для кожного алгоритму було проведено серію експериментів, охоплюючи 
різні варіанти пошуку, такі як ключові слова, відсортований порядок та рейтинги. 
Зібрані дані включають час виконання, кількість порівнянь та точність 
результатів. Результати систематизувалися та відображалися за допомогою 
лінійних графіків, що сприяло зручному порівнянню продуктивності алгоритмів. 
Аналіз отриманих даних дозволив визначити ефективність кожного 
алгоритму та врахувати його придатність для конкретних сценаріїв використання 
в системах маркетплейсу цифрового мистецтва. Отримані висновки надали 
34 
ЧДТУ .232219.005 ПЗ 
інсайти щодо того, який алгоритм є найбільш підходящим в залежності від умов 
та враховують потреби користувачів платформи. 
5 Графічне представлення результатів 
Для наочності та зручності порівняння результатів експерименту 
застосовано графічне представлення даних через лінійні графіки. Кожен 
алгоритм пошуку визначений як окрема лінія на графіку, а кожна метрика (час 
виконання, кількість порівнянь та точність) представлена власним підграфіком.  
6 Аналіз та  
1 Час виконання 
Графік часу виконання відображає продуктивність кожного алгоритму в 
залежності від обраного сценарію використання. На осі X вказані алгоритми, а на 
осі Y - час виконання у мілісекундах. 
 
 
Рис 2.7 − Час виконання 
 
2 Кількість порівнянь 
Діаграма кількості порівнянь ілюструє, як різні алгоритми впливають на 
обсяг порівнянь при різних умовах пошуку. Кожен стовпчик відповідає 
35 
ЧДТУ .232219.005 ПЗ 
конкретному алгоритму, а висота стовпчика вказує на кількість порівнянь. 
 
 
Рис 2.8 − Кількість порівнянь 
3 Точність 
Графік точності представляє результати експерименту в контексті 
відповідності знайдених результатів оригіналу. Кожен пункт на графіку позначає 
точність алгоритму для конкретного сценарію використання. 
 
 
Рис 2.9 − Точність порівнянь 
 
36 
ЧДТУ .232219.005 ПЗ 
Ці графіки надають інтегрований погляд на продуктивність та ефективність 
кожного алгоритму, допомагаючи визначити найкращий вибір відповідно до 
конкретних вимог та умов системи маркетплейсу цифрового мистецтва. 
Із вище сказаного, можна зробити такі висновки 2.2.4 
На основі зібраних даних та графічного представлення результатів 
проводиться аналіз ефективності кожного алгоритму пошуку. Висновки надають 
інсайти щодо того, який алгоритм є найбільш підходящим для використання в 
системах маркетплейсу цифрового мистецтва з урахуванням конкретних вимог та 
сценаріїв використання. 
2.2.5 Аналіз результатів порівняльного аналізу: 
1 Час виконання: 
Алгоритм Бінарний Пошук виявився найефективнішим з точки зору часу 
виконання завдяки своїй логарифмічній складності, що особливо важливо при 
великій кількості даних. Він дозволяє швидко локалізувати шуканий елемент у 
відсортованому списку, що є ключовим у маркетплейсі цифрового мистецтва. 
Алгоритм Машинного Навчання відзначився також високою швидкістю, 
особливо при динамічних змінах у вимогах пошуку. 
2 Кількість порівнянь: 
Алгоритми Бінарний Пошук та Пошук за Збалансованим Деревом 
виявилися оптимальними з точки зору кількості порівнянь. Вони дозволяють 
ефективно зменшити обсяг порівнянь, що робить їх придатними для великих 
обсягів даних. У порівнянні з іншими алгоритмами, такими як лінійний пошук, 
це дозволяє швидше знаходити результати. 
3 Точність: 
Алгоритм Машинного Навчання проявив себе як лідер у відношенні до 
точності результатів. Здатність адаптуватися до контексту та навчання на основі 
попередніх запитів дозволяє йому надавати точні та релевантні результати, 
особливо в умовах складних сценаріїв пошуку. 
Порівняльний аналіз результатів дозволяє зрозуміти, що вибір алгоритму 
пошуку має бути узгоджений із специфікою системи та вимогами користувачів. 
37 
ЧДТУ .232219.005 ПЗ 
Бінарний Пошук є ідеальним для швидкого пошуку в відсортованих даних, 
Машинне Навчання забезпечує гнучкість та адаптивність, а Пошук за 
Збалансованим Деревом може бути використаний для фільтрації та 
упорядкування результатів. 
Враховуючи ці аспекти, можна визначити оптимальний алгоритм для 
створення нової системи пошуку в маркетплейсі цифрового мистецтва, 
враховуючи конкретні вимоги та умови платформи. 
Із вище сказаного, можна зробити такі висновки 2.2.5 
Модель оптимізації пошуку в системах маркетплейсу цифрового мистецтва 
представляє собою значущий крок у напрямку покращення користувацького 
досвіду, ефективності та взаємодії на цьому цифровому просторі. Шляхом 
використання сучасних технологій, таких як інтелектуальні алгоритми пошуку, 
аналіз великих обсягів даних та інші інноваційні підходи, модель прагне 
вирішити виклики, пов'язані з ефективністю та точністю пошуку в цифрових 
колекціях мистецтва. 
Метою цієї моделі є поліпшення якості результатів пошуку для 
користувачів, спрощення процесу знаходження та взаємодії з творами мистецтва 
на маркетплейсі. Впровадження технологій штучного інтелекту, машинного 
навчання та аналізу контенту робить пошук більш персоналізованим та 
адаптованим до унікальних потреб кожного користувача. 
Модель допомагає вирішувати завдання, пов'язані з обмеженим доступом 
до цифрових творів, шляхом впровадження розширених функцій управління 
доступом та системи рекомендацій. Це дозволяє створити більш інтелектуальне 
та інтуїтивно зрозуміле середовище для взаємодії з мистецтвом. 
Усе це відкриває перспективи для подальшого розвитку та реалізації 
новаторських ідей у сфері маркетплейсів цифрового мистецтва та не тільки. 
Модель оптимізації пошуку створює основу для розширення можливостей 
віртуального мистецького простору та підвищення задоволення користувачів від 
взаємодії з цифровими творами мистецтва. 
2.2.6 Формула скінченного автомату 
38 
ЧДТУ .232219.005 ПЗ 
Щоб сформулювати скінчений автомат для обраного аспекту системи 
маркетплейсу цифрового мистецтва, ми можемо використовувати концепції теорії 
автоматів та автоматного моделювання. 
Припустимо, що ми хочемо створити автомат для процесу визначення 
оптимального алгоритму пошуку, враховуючи час виконання, кількість порівнянь 
та точність. 
Нехай: 
− Q - множина станів автомату, 
− ΣΣ - алфавіт вхідних символів, 
− δ - функція переходів, 
− q0 - початковий стан, 
− F - множина заключних станів. 
Тоді скінчений автомат може мати такий вигляд: 
1 Стани:  
Q={Q1,Q2,Q3,…,Qn} 
2 Алфавіт вхідних символів:  
Σ={A,B,C} 
 де A - час виконання, B - кількість порівнянь, C - точність. 
3 Функція переходів:  
δ:Q×Σ→Q  
δ(Qi,A)=Qj 
де i,j - номери станів, а A - вхідний символ. 
4 Початковий стан:  
q0=Qпочатковий 
5 Множина заключних станів:  
F={Qзаключний1,Qзаключний2,…,Qзаключнийm} 
Цей автомат може допомогти моделювати рішення щодо вибору 
оптимального алгоритму пошуку в залежності від вхідних параметрів, таких як 
час виконання, кількість порівнянь та точність.  
39 
ЧДТУ .232219.005 ПЗ 
Розділ 3 Впровадження результатів досліджень у практику, проектування 
програмного забезпечення інформаційних систем 
3.1. Моделювання предметної області 
3.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметна область даного проекту - це маркетплейс цифрового мистецтва, 
який надає користувачам можливість купувати, продавати, оцінювати та шукати 
цифрові твори мистецтва різних жанрів, стилів та форматів. Цифрове мистецтво - 
це мистецтво, яке створюється за допомогою комп'ютерних технологій, таких як 
графічні редактори, програми для 3D-моделювання, анімації, відео-редагування 
тощо. Цифрове мистецтво може бути статичним або динамічним, інтерактивним 
або пасивним, одноразовим або серійним, оригінальним або реміксованим тощо. 
Модель предметної області маркетплейсу цифрового мистецтва можна 
представити у вигляді сутнісно-зв'язкової діаграми (Entity-Relationship Diagram, 
ERD), яка показує основні сутності, їх атрибути та відносини між ними. На 
рисунку 1 показана прикладна ERD для маркетплейсу цифрового мистецтва. 
Сутності - це об'єкти, які мають значення для предметної області та можуть 
бути ідентифіковані. Наприклад, сутності Користувач, Твір, **Замовлення**, 
Відгук тощо. 
Атрибути - це властивості, які характеризують сутності. Наприклад, 
атрибути Ім'я, Електронна пошта, Пароль для сутності Користувач; атрибути 
Назва, Автор, Ціна, Опис, Файл для сутності Твір тощо. 
Відносини - це зв'язки між сутностями, які виражають їх взаємодію. 
Наприклад, відносини Купує, Продає, Оцінює, Коментує тощо. 
Кардинальність - це кількість сутностей, які можуть брати участь у 
відносині. Наприклад, один Користувач може купити багато Творів, а один Твір 
може бути куплений багатьма Користувачами. Така відносина має кардинальність 
багато-до-багатьох (many-to-many). 
Словник предметної області - це набір термінів та їх визначень, які 
40 
ЧДТУ .232219.005 ПЗ 
використовуються для опису предметної області. Словник допомагає уникнути 
непорозумінь та неоднозначностей при спілкуванні з зацікавленими сторонами 
проекту. Ось деякі приклади термінів та їх визначень для предметної області 
маркетплейсу цифрового мистецтва: 
Маркетплейс - це онлайн-платформа, яка з'єднує продавців та покупців 
цифрового мистецтва, дозволяючи їм укладати угоди, обмінюватися відгуками та 
шукати твори за різними критеріями. 
Цифрове мистецтво - це мистецтво, яке створюється за допомогою 
комп'ютерних технологій, таких як графічні редактори, програми для 
3D-моделювання, анімації, відео-редагування тощо. 
Твір - це цифровий файл, який містить зображення, відео, аудіо або інший 
формат цифрового мистецтва, який може бути куплений або проданий на 
маркетплейсі. 
Користувач - це особа, яка має обліковий запис на маркетплейсі та може 
виступати у ролі продавця або покупця цифрового мистецтва. 
Замовлення - це угода між продавцем та покупцем про купівлю певного 
твору за певну ціну. 
Відгук - це оцінка або коментар, який користувач залишає про твір або 
іншого користувача на маркетплейсі. 
Штучний інтелект - це галузь комп'ютерних наук, яка займається 
створенням програм та систем, які можуть виконувати завдання, які зазвичай 
вимагають людського розуму, такі як розпізнавання образів, мови, звуку, 
навчання, рішення проблем тощо. 
Пошукова система - це програма або сервіс, який дозволяє користувачам 
знаходити інформацію або твори за певними запитами або критеріями. 
3.1.2 Елементи моделювання предметної області 
Сутності предметної області: 
− Користувач -  
− Твір 
− Замовлення 
41 
ЧДТУ .232219.005 ПЗ 
− Відгук 
Атрибути предметної області: 
Для користувача атрибути предметної області наступні: 
− Ім’я 
− Електронна пошта 
− Пароль 
− Відгуки 
Для сутності твір атрибути будуть наступними: 
− Назва 
− Автор 
− Ціна 
− Опис 
− Файл 
Відносини предметної області: 
Основні відносини предметної області будуть проходити між користувачем 
та творами цифрового мистецтва, отож відносини користувач – твір будуть 
наступними: 
− Купує 
− Продає 
− Оцінює 
− Коментує  
3.1.3 Робоча область моделювання 
Робоча область моделювання включає в себе ключові процеси та елементи, 
які підлягають детальному вивченню та аналізу при розробці системи пошуку 
для маркетплейсу цифрового мистецтва. Розглянемо приклад робочої області, 
зосереджуючись на взаємодії користувачів та творів мистецтва: 
У цій частині робочої області розглядається, як користувачі взаємодіють з 
системою цифрового мистецтва. Це включає в себе: 
− Реєстрація та аутентифікація: 
Користувачі повинні мати можливість створювати облікові записи та 
42 
ЧДТУ .232219.005 ПЗ 
входити в систему для доступу до особистого простору та збережених 
налаштувань. 
− Пошук творів мистецтва: 
Аналіз того, як користувачі використовують систему для пошуку та 
відкриття творів мистецтва. Це включає в себе використання ключових слів, 
фільтрів та інших параметрів пошуку. 
− Відгуки та оцінки: 
Розгляд того, як користувачі залишають відгуки, ставлять оцінки та 
взаємодіють з іншими користувачами через систему. 
Взаємодія з творами мистецтва 
У цьому аспекті робочої області розглядається, як користувачі взаємодіють 
з конкретними творами мистецтва, що включає: 
− Перегляд та деталізація: 
Вивчення того, як користувачі переглядають та деталізують інформацію 
про конкретний твір мистецтва, включаючи його опис, автора та інші 
характеристики. 
− Покупка та замовлення: 
Аналіз процесу, яким користувачі можуть придбати або замовити твір 
мистецтва, включаючи оплату та доставку. 
Цей аспект робочої області допомагає зрозуміти основні потреби та 
взаємодії користувачів з системою, що стає фундаментом для розробки 
ефективної системи пошуку та інтеракції у маркетплейсі цифрового мистецтва.  
3.2. Формування та аналіз вимог 
3.2.1 Формування вимог до програмного забезпечення. Первинні та 
детальні вимоги. Вимоги замовника та розробника. Функціональні та не 
функціональні вимоги. 
Первинні вимоги: 
43 
ЧДТУ .232219.005 ПЗ 
Мета проекту: покращити якість та швидкість пошуку в маркетплейсах 
цифрового мистецтва, забезпечити більш точну та релевантну відповідь на 
запити користувачів, підвищити задоволеність та лояльність користувачів. 
Первинні вимоги до проекту: 
− Система пошуку повинна мати клієнтську та серверну частини, які 
взаємодіють за допомогою REST API. 
− Клієнтська частина повинна бути розроблена за допомогою React, 
використовуючи сучасні стандарти та практики розробки 
веб-інтерфейсів. 
− Серверна частина повинна бути розроблена за допомогою Node.js, 
використовуючи сучасні технології та фреймворки для роботи з даними, 
пошуком, кешуванням, аутентифікацією та іншими функціями. 
− Система пошуку повинна підтримувати різні типи запитів, такі як 
ключові слова, фрази, фільтри, сортування, пагінацію, автодоповнення, 
синоніми, спеціальні символи та інші. 
− Система пошуку повинна враховувати різні параметри цифрового 
мистецтва, такі як жанр, стиль, тема, автор, рейтинг, ціна, дата, формат, 
розмір, ліцензія та інші. 
− Система пошуку повинна надавати більш точну та релевантну відповідь 
на запити користувачів, використовуючи різні алгоритми та методи 
ранжування, такі як TF-IDF, BM25, PageRank, LSI, LDA, Word2Vec, 
BERT та інші. 
− Система пошуку повинна мати високу продуктивність та 
масштабованість, забезпечуючи швидку відповідь на запити 
користувачів, використовуючи різні техніки та інструменти для 
оптимізації, кешування, індексування, паралелізації, розподілу 
навантаження та інші. 
− Система пошуку повинна мати високу надійність та безпеку, 
забезпечуючи захист даних та запитів користувачів, використовуючи 
різні техніки та інструменти для шифрування, аутентифікації, 
авторизації, логування, моніторингу, резервного копіювання, 
відновлення та інші. 
− Система пошуку повинна мати зручний та інтуїтивний інтерфейс, який 
відповідає сучасним стандартам та вимогам користувачів, 
використовуючи різні техніки та інструменти для дизайну, верстки, 
анімації, адаптивності, доступності, локалізації та інші. 
Вимоги замовника: 
1 ПЗ передбачає створення веб-додатку, який забезпечує можливість 
завантаження авторизованими клієнтами творів мистецтва та отримувати їх опис. 
Також має було можливість пошуку по усім творам. 
44 
ЧДТУ .232219.005 ПЗ 
Вимоги розробника: 
1 Користувач повинен мати можливість аутентифікуватися в системі, 
використовуючи свою електронну пошту та пароль. 
2 Користувач може авторизуватися в системі, використовуючи свою 
електронну пошту та пароль. Після успішної авторизації користувач отримує 
токен доступу для подальшої аутентифікації при виконанні захищених запитів. 
3 Користувач має мати можливість завантаження твору мистецтва на 
сервер, указавши пряму силку на твір, жанр, оригінального автора та тип роботи. 
4 При любих запитах на сервер крім авторизації та аутентифікації клієнт 
має надавати свій JWT ключ 
5 В JWT ключі має зберігатися уся інформація про користувача, крім його 
пароля. 
Функціональні вимоги: 
− Серверна частина системи повинна забезпечувати взаємодію з 
клієнтською частиною через RESTful API, який повинен підтримувати 
CRUD-операції (створення, читання, оновлення, видалення) для ресурсів, таких 
як користувачі, твори мистецтва, транзакції тощо. 
− Серверна частина системи повинна зберігати дані про користувачів, 
твори мистецтва, транзакції тощо в базі даних, яка повинна бути нормалізована, 
захищена та індексована для оптимальної продуктивності та безпеки. 
− Серверна частина системи повинна використовувати штучний 
інтелект для пошуку творів мистецтва за запитами користувачів, а також для 
рекомендації релевантних творів мистецтва на основі їхніх інтересів та 
попередньої активності. Штучний інтелект повинен використовувати різні 
методи, такі як семантичний аналіз, класифікація зображень, колаборативна 
фільтрація тощо. 
− Серверна частина повинна використовувати базу даних MongoDB для 
швидкої передачі та  
− Серверна частина системи повинна дотримуватися законодавства та 
45 
ЧДТУ .232219.005 ПЗ 
правил маркетплейсу щодо авторських прав, конфіденційності, податків тощо. 
Серверна частина системи повинна використовувати відповідні механізми, такі 
як шифрування, аутентифікація, авторизація, аудит, валідація тощо, для захисту 
даних та прав користувачів, а також для відповідності вимогам регуляторів та 
партнерів. 
− Клієнтська чатина повинна бути написана для тестування та 
демонстрації роботи додатку. Вона повинна надавати користувачеві можливість 
реєстрації, авторизації, завантаження своїх зображень та пошуку інших 
зображень в базі сайту. 
− Нефункціональні вимоги: 
− Серверна частина системи повинна мати високу продуктивність та 
масштабованість, щоб обробляти велику кількість запитів та транзакцій від 
користувачів. Серверна частина системи повинна використовувати різні техніки, 
такі як кешування, балансування навантаження, мікросервіси, хмарні сервіси 
тощо, для підвищення продуктивності та масштабованості. 
− Серверна частина системи повинна мати високу доступність та 
надійність, щоб забезпечити неперервну роботу маркетплейсу та запобігти втраті 
даних. Серверна частина системи повинна використовувати різні техніки, такі як 
резервне копіювання, відновлення, реплікація, кластеризація, моніторинг, 
тестування тощо, для підвищення доступності та надійності. 
− Серверна частина системи повинна мати високу безпеку та захист від 
зловмисних атак, шахрайства, крадіжки тощо. Серверна частина системи 
повинна використовувати різні техніки, такі як фаєрволи, антивіруси, SSL, 
шифрування, цифрові підписи, капчі, двофакторна аутентифікація тощо, для 
підвищення безпеки та захисту. 
− Бінзнес-вимоги: 
Модель монетизації: 
Маркетплейс цифрового мистецтва має різноманітні можливості для 
монетизації, що дозволяє створити стабільний та прибутковий бізнес: 
− комісійні збори: Здійснюйте збори з кожної угоди між продавцем та 
46 
ЧДТУ .232219.005 ПЗ 
покупцем. Це може бути фіксований відсоток або сталу сума. 
− платні рекламні опції: Пропонуйте продавцям можливість виокремити 
свої твори через платні рекламні площі або просування. 
− платні пакети для продавців: Надавайте різні рівні платних пакетів для 
продавців з розширеними можливостями та інструментами. 
− підписка для купуючих: Введіть модель підписки для користувачів, яка 
дозволяє отримати доступ до ексклюзивних функцій та знижок. 
− ліцензіювання творів: Дозвольте художникам продавати ліцензії на свої 
твори для комерційного використання. 
− організація тематичних заходів: Проводьте онлайн або офлайн події та 
виставки, за що можна взяти плату. 
− партнерські програми: Укладайте партнерські угоди з іншими 
платформами, художниками чи організаціями для спільної монетизації. 
− спеціальні функції для користувачів-платників: Введіть платні функції 
або контент для користувачів, які платять підписку. 
3.1.2 Вибір технологій 
На основі технічного завдання та сучасних стандартах, мною були обрані 
наступні технології: 
Фронтенд частина: 
Відповідність дизайну: 
Використання React.js для створення інтерактивного та відповідного 
інтерфейсу, що відповідає сучасним стандартам дизайну. 
Використання Axios для зручного взаємодії з RESTful API та обміну 
даними з бекендом. 
Бекенд частина: 
База даних: 
Вибір MongoDB як бази даних для зручного зберігання та оптимізації 
великого обсягу даних, що характерний для маркетплейсу цифрового мистецтва. 
Фреймворк для розробки бекенду: 
Використання Node.js з Express.js для створення легкого та швидкодіючого 
47 
ЧДТУ .232219.005 ПЗ 
серверу, який забезпечить обробку запитів. 
Аутентифікація та Авторизація: 
Впровадження JWT (JSON Web Tokens) для забезпечення безпеки та 
захисту конфіденційної інформації користувачів. 
Робота з асинхронними запитами: 
Використання async/await для ефективної обробки асинхронних операцій та 
уникнення блокування сервера. 
Безпека: 
SSL-шифрування: 
Забезпечення безпеки передачі даних за допомогою протоколу SSL/TLS для 
захисту від перехоплення. 
Захист від SQL та NoSQL ін'єкцій: 
Використання бібліотек та практик, таких як parameterized queries, для 
уникнення ін'єкцій в базу даних. 
Валідація та санітізація Введених Даних: 
Впровадження механізмів валідації та санітізації введених користувачем 
даних для запобігання атакам. 
3.2.2 Формування вимог за допомогою діаграм прецедентів 
 
 
Рис. 3.1 − Діаграма прецендентів 
48 
ЧДТУ .232219.005 ПЗ 
 
На цій діаграмі виділено три актори: користувач, художник і куратор. 
Користувач - це основний актор, який може використовувати систему пошуку для 
знаходження, перегляду, купівлі, завантаження, оцінювання та коментування 
цифрових мистецьких творів. Художник - це другорядний актор, який може 
додавати, редагувати та видаляти свої цифрові мистецькі твори в системі. 
Куратор - це також другорядний актор, який може перевіряти, затверджувати або 
відхиляти цифрові мистецькі твори, що додаються художниками. 
На цій діаграмі також показано чотирнадцять прецедентів, які відповідають 
різним сценаріям використання системи пошуку. Прецеденти з’єднані з акторами 
за допомогою ліній, що позначають асоціації. Прецеденти також пов’язані між 
собою за допомогою стрілок, що позначають відношення включення, 
розширення або узагальнення. Відношення включення означає, що один 
прецедент завжди викликає інший прецедент. Відношення розширення означає, 
що один прецедент може додати додаткову функціональність до іншого 
прецедента за певних умов. Відношення узагальнення означає, що один 
прецедент є спеціалізацією або підтипом іншого прецедента. 
Ось короткий опис кожного прецедента на цій діаграмі: 
− ввести запит: користувач може ввести запит за допомогою ключових 
слів, фільтрів, категорій, тегів, геолокації, рекомендацій тощо; 
− переглянути результати: користувач може переглянути результати 
пошуку, які відповідають його запиту, у вигляді списку або сітки. 
− вибрати твір: користувач може вибрати твір з результатів пошуку, який 
його зацікавив; 
− переглянути деталі: користувач може переглянути детальну інформацію 
про вибраний твір, таку як назва, автор, дата, опис, ціна, рейтинг, 
відгуки, ліцензія тощо; 
− купити твір: користувач може купити вибраний твір, виконавши оплату 
за допомогою певного методу; 
− завантажити твір: користувач може завантажити куплений твір на свій 
49 
ЧДТУ .232219.005 ПЗ 
пристрій або хмарне сховище; 
− оцінити твір: користувач може оцінити куплений твір за п’ятибальною 
шкалою; 
− залишити відгук: користувач може залишити відгук про куплений твір, 
висловивши свою думку та зауваження; 
− додати твір: художник може додати свій цифровий мистецький твір до 
системи, вказавши необхідну інформацію та параметри; 
− редагувати твір: художник може редагувати свій цифровий мистецький 
твір, який він додав до системи, змінюючи інформацію та параметри; 
− видалити твір: художник може видалити свій цифровий мистецький 
твір, який він додав до системи, якщо він більше не хоче його продавати 
або показувати; 
− перевірити твір: куратор може перевірити цифровий мистецький твір, 
який додав художник, на предмет його якості, оригінальності, 
відповідності тематиці та правилам системи; 
− затвердити твір: куратор може затвердити цифровий мистецький твір, 
який додав художник, якщо він пройшов перевірку, і дозволити його 
публікацію в системі; 
− відхилити твір: куратор може відхилити цифровий мистецький твір, 
який додав художник, якщо він не пройшов перевірку, і повідомити 
художника про причини відхилення. 
 
50 
ЧДТУ .232219.005 ПЗ 
 
Рис 3.2 – Діаграма взаємодії 
Ця діаграма показує, як користувачі та система взаємодіють у проекті. На 
діаграмі виділено два актори: Користувач та Система. Користувач - це зовнішня 
сутність, яка використовує функції системи для досягнення своїх цілей. Система - 
це внутрішня сутність, яка надає функції та забезпечує їх виконання. 
Опис кожного прецидента на діаграмі: 
− реєстрація: Користувач може зареєструватися в системі, вказавши свої 
особисті дані та контактну інформацію; 
− авторизація: Користувач може увійти в систему, ввівши своє ім’я 
користувача та пароль; 
51 
ЧДТУ .232219.005 ПЗ 
− завантаження зображень: Користувач може завантажувати свої 
зображення в систему, вказуючи їх назву, опис, ціну та інші параметри; 
− пошук зображень: Користувач може шукати зображення в системі, 
вводячи запити за ключовими словами, категоріями, авторами тощо. 
Цей прецидент включає прецидент рекомендація зображень; 
− рекомендація зображень: Система може рекомендувати користувачеві 
релевантні зображення на основі його інтересів та попередньої 
активності, використовуючи штучний інтелект; 
− перегляд зображень: Користувач може переглядати зображення, які він 
знайшов або отримав в рекомендаціях, та бачити їх деталі, такі як назва, 
опис, ціна, автор тощо; 
− оплата зображень: Користувач може оплатити зображення, які він хоче 
придбати, використовуючи різні способи оплати, такі як кредитна карта, 
PayPal, криптовалюта тощо; 
− збереження даних: Система зберігає дані про користувачів, зображення, 
транзакції тощо в базі даних, яка нормалізована, захищена та 
індексована; 
− штучний інтелект: Система використовує штучний інтелект для пошуку 
та рекомендації зображень, а також для аналізу та класифікації 
зображень за різними параметрами; 
− захист даних: Система захищає дані та права користувачів, 
використовуючи різні механізми, такі як шифрування, аутентифікація, 
авторизація, аудит, валідація тощо; 
− відповідність законодавству: Система дотримується законодавства та 
правил маркетплейсу щодо авторських прав, конфіденційності, податків 
тощо. 
3.2.3 Проектування логічної структури програмного комплексу 
3.2.3.1 Діаграми класів 
Діаграми класів є ефективним інструментом для візуалізації структури 
52 
ЧДТУ .232219.005 ПЗ 
системи та взаємозв'язків між її ключовими елементами. У розгляді моделювання 
предметної області для системи маркетплейсу цифрового мистецтва 
використовуються діаграми класів для наступних елементів: 
 
 
Рис 3.2 − Діаграма класів для авторизації 
Ось короткий опис кожного класу та його вмісту: 
− IAuthenticable: Це інтерфейс, який визначає два методи для 
авторизації: login та logout. Він реалізується класом User, який є базовим класом 
для всіх користувачів системи. 
− User: Це абстрактний клас, який описує спільні атрибути та методи 
для всіх користувачів системи. Він має атрибути username, password та roles, які 
зберігають ім’я, пароль та ролі користувача відповідно. Він також має методи для 
53 
ЧДТУ .232219.005 ПЗ 
отримання та встановлення цих атрибутів, а також для додавання, видалення та 
перевірки ролей. Він наслідується двома класами: SystemUser та EndUser, які 
представляють різні типи користувачів системи. 
− SystemUser: Це клас, який представляє користувача, який має доступ 
до системи. Він має атрибути id та name, які зберігають ідентифікатор та ім’я 
користувача відповідно. Він також має методи для отримання та встановлення 
цих атрибутів. 
− EndUser: Це клас, який представляє користувача, який використовує 
систему. Він має атрибути email та phone, які зберігають електронну пошту та 
телефон користувача відповідно. Він також має методи для отримання та 
встановлення цих атрибутів. Він наслідується двома класами: ClientUser та 
InternetUser, які представляють різні категорії користувачів системи. 
− ClientUser: Це клас, який представляє користувача, який є клієнтом 
системи. Він має атрибут account, який зберігає об’єкт класу Account, який 
містить інформацію про рахунок клієнта. Він також має методи для отримання та 
встановлення цього атрибута. 
− InternetUser: Це клас, який представляє користувача, який 
використовує систему через інтернет. Він має атрибут ip, який зберігає IP-адресу 
користувача. Він також має методи для отримання та встановлення цього 
атрибута. 
− Role: Це клас, який представляє роль, яку може мати користувач 
системи. Він має атрибути id, name та modules, які зберігають ідентифікатор, 
назву та модулі ролі відповідно. Він також має методи для отримання та 
встановлення цих атрибутів, а також для додавання, видалення та перевірки 
модулів. Кожен користувач може мати одну або декілька ролей, а кожна роль 
може мати один або декілька модулів. 
− Module: Це клас, який представляє модуль, який надає певну 
функціональність системи. Він має атрибути id, name та functions, які зберігають 
ідентифікатор, назву та функції модуля відповідно. Він також має методи для 
отримання та встановлення цих атрибутів, а також для додавання, видалення та 
перевірки функцій. Кожна роль може мати один або декілька модулів, а кожен 
модуль може мати одну або декілька функцій. 
− Function: Це клас, який представляє функцію, яка виконує певну дію 
в системі. Він має атрибути id та name, які зберігають ідентифікатор та назву 
функції відповідно. Він також має методи для отримання та встановлення цих 
атрибутів. Кожен модуль може мати одну або декілька функцій. 
− User …|> IAuthenticable: Це зв’язок реалізації, який показує, що клас 
User реалізує інтерфейс IAuthenticable, тобто він надає реалізацію для методів 
login та logout. 
− SystemUser --|> User: Це зв’язок загальнізації, який показує, що клас 
SystemUser наслідує клас User, тобто він успадковує всі його атрибути та методи, 
а також може додавати свої власні. 
− EndUser --|> User: Це зв’язок загальнізації, який показує, що клас 
EndUser наслідує клас User, тобто він успадковує всі його атрибути та методи, а 
також може додавати свої власні. 
54 
ЧДТУ .232219.005 ПЗ 
− ClientUser --|> EndUser: Це зв’язок загальнізації, який показує, що 
клас ClientUser наслідує клас EndUser, тобто він успадковує всі його атрибути та 
методи, а також може додавати свої власні. 
− InternetUser --|> EndUser: Це зв’язок загальнізації, який показує, що 
клас InternetUser наслідує клас EndUser, тобто він успадковує всі його атрибути 
та методи, а також може додавати свої власні. 
− User “" – "1…” Role: Це зв’язок агрегації, який показує, що клас User 
містить один або декілька об’єктів класу Role, тобто він має список ролей, які 
може мати користувач. Це також означає, що об’єкти класу Role можуть існувати 
незалежно від об’єктів класу User, тобто вони не знищуються, коли знищується 
об’єкт класу User. 
 
 
Рис 3.3 − Діаграма класів серверної частини 
діаграма класів показує, як ваша система авторизації складається з різних класів, 
їхніх атрибутів, методів та зв’язків. Вона також показує, як класи реалізують або 
наслідують інтерфейси та абстрактні класи. 
Ось короткий опис кожного класу та його вмісту: 
55 
ЧДТУ .232219.005 ПЗ 
− IAuthenticable: Це інтерфейс, який визначає два методи для 
авторизації: login та logout. Він реалізується класом User, який є базовим класом 
для всіх користувачів системи. 
− User: Це абстрактний клас, який описує спільні атрибути та методи 
для всіх користувачів системи. Він має атрибути username, password та roles, які 
зберігають ім’я, пароль та ролі користувача відповідно. Він також має методи 
для отримання та встановлення цих атрибутів, а також для додавання, видалення 
та перевірки ролей. Він наслідується двома класами: SystemUser та EndUser, які 
представляють різні типи користувачів системи. 
− SystemUser: Це клас, який представляє користувача, який має доступ 
до системи. Він має атрибути id та name, які зберігають ідентифікатор та ім’я 
користувача відповідно. Він також має методи для отримання та встановлення 
цих атрибутів. 
− EndUser: Це клас, який представляє користувача, який використовує 
систему. Він має атрибути email та phone, які зберігають електронну пошту та 
телефон користувача відповідно. Він також має методи для отримання та 
встановлення цих атрибутів. Він наслідується двома класами: ClientUser та 
InternetUser, які представляють різні категорії користувачів системи. 
− ClientUser: Це клас, який представляє користувача, який є клієнтом 
системи. Він має атрибут account, який зберігає об’єкт класу Account, який 
містить інформацію про рахунок клієнта. Він також має методи для отримання 
та встановлення цього атрибута. 
− InternetUser: Це клас, який представляє користувача, який 
використовує систему через інтернет. Він має атрибут ip, який зберігає IP-адресу 
користувача. Він також має методи для отримання та встановлення цього 
атрибута. 
− Role: Це клас, який представляє роль, яку може мати користувач 
системи. Він має атрибути id, name та modules, які зберігають ідентифікатор, 
назву та модулі ролі відповідно. Він також має методи для отримання та 
встановлення цих атрибутів, а також для додавання, видалення та перевірки 
модулів. Кожен користувач може мати одну або декілька ролей, а кожна роль 
може мати один або декілька модулів. 
− Module: Це клас, який представляє модуль, який надає певну 
функціональність системи. Він має атрибути id, name та functions, які зберігають 
ідентифікатор, назву та функції модуля відповідно. Він також має методи для 
отримання та встановлення цих атрибутів, а також для додавання, видалення та 
перевірки функцій. Кожна роль може мати один або декілька модулів, а кожен 
модуль може мати одну або декілька функцій. 
− Function: Це клас, який представляє функцію, яка виконує певну дію 
в системі. Він має атрибути id та name, які зберігають ідентифікатор та назву 
функції відповідно. Він також має методи для отримання та встановлення цих 
атрибутів. Кожен модуль може мати одну або декілька функцій. 
Ось короткий опис зв’язків між класами та їхнім значенням: 
56 
ЧДТУ .232219.005 ПЗ 
− User …|> IAuthenticable: Це зв’язок реалізації, який показує, що клас 
User реалізує інтерфейс IAuthenticable, тобто він надає реалізацію для методів 
login та logout. 
− SystemUser --|> User: Це зв’язок загальнізації, який показує, що клас 
SystemUser наслідує клас User, тобто він успадковує всі його атрибути та методи, 
а також може додавати свої власні. 
− EndUser --|> User: Це зв’язок загальнізації, який показує, що клас 
EndUser наслідує клас User, тобто він успадковує всі його атрибути та методи, а 
також може додавати свої власні. 
− ClientUser --|> EndUser: Це зв’язок загальнізації, який показує, що 
клас ClientUser наслідує клас EndUser, тобто він успадковує всі його атрибути та 
методи, а також може додавати свої власні. 
− InternetUser --|> EndUser: Це зв’язок загальнізації, який показує, що 
клас InternetUser наслідує клас EndUser, тобто він успадковує всі його атрибути 
та методи, а також може додавати свої власні. 
− User “" – "1…” Role: Це зв’язок агрегації, який показує, що клас User 
містить один або декілька об’єктів класу Role, тобто він має список ролей, які 
може мати користувач. Це також означає, що об’єкти класу Role можуть існувати 
незалежно від об’єктів класу User, тобто вони не знищуються, коли знищується 
об’єкт класу User. 
− Role “" – "1…” Module: Це зв’язок агрегації, який показує, що клас 
Role містить один або декілька об’єктів класу Module, тобто він має список 
модулів, які може мати роль. Це також означає, що об’єкти класу Module можуть 
існувати незалежно від об’єктів класу Role, тобто вони не знищуються, коли 
знищується об’єкт класу Role. 
− Module “" – "1…” Function: Це зв’язок агрегації, який показує, що 
клас Module містить один або декілька об’єктів класу Function, тобто він має 
список функцій, які може мати модуль. Це також означає, що об’єкти класу 
Function можуть існувати незалежно від об’єктів класу Module, тобто вони не 
знищуються, коли знищується об’єкт класу Module. 
3.2.3.2 Діаграми пакетів 
57 
ЧДТУ .232219.005 ПЗ 
 
Рис 3.4 діаграма пакетів 
Ця діаграма пакетів показує, як ваш додаток поділений на різні пакети, які 
містять компоненти, класи, інтерфейси тощо. Вона також показує, як пакети 
залежать один від одного та як вони групуються за функціональністю. 
Ось короткий опис кожного пакета та його вмісту: 
− Node.JS Server: Це пакет, що відповідає серверу, який використовує 
Node.JS як основне середовище для запуску вашого проекту. Він містить два інші 
пакети: Express та Mongoose. Він також з’єднується з mongoDB Server та AI 
Server за допомогою інтерфейсів MongoDB та AI відповідно. 
− Express: Це пакет, що відповідає фреймворку Express, який 
використовується для обробки HTTP запитів від клієнтів. Він надає інтерфейс 
HTTP для зв’язку з Node.JS Server. Він також використовує інтерфейс AI для 
роботи з AI Server. 
− Mongoose: Це пакет, що відповідає бібліотеці Mongoose, яка 
використовується для керування базою даних mongoDB. Він надає інтерфейс 
MongoDB для зв’язку з Node.JS Server. Він дозволяє створювати схеми, моделі та 
запити до бази даних. 
− mongoDB Server: Це пакет, що відповідає серверу баз даних, який 
зберігає і обробляє дані для вашого проекту. Він використовує mongoDB як 
конкретну СУБД. 
58 
ЧДТУ .232219.005 ПЗ 
− AI Server: Це пакет, що відповідає серверу, на якому розташована 
модель штучного інтелекту, яку ви використовуєте для вашого проекту. Він 
приймає запити від Express за допомогою інтерфейсу AI і повертає результати. 
− Web Client: Це пакет, що відповідає клієнтському додатку, який має 
деякі функції, такі як реєстрація, авторизація, завантаження та перегляд творів 
мистецтва. Він містить один пакет: React App. Він також зв’язується з Node.JS 
Server за допомогою інтерфейсу HTTP. 
− React App: Це пакет, що відповідає бібліотеці React, яка 
використовується для створення інтерфейсу користувача для клієнтського 
додатку. Він надає інтерфейс HTTP для зв’язку з Web Client. Він також 
використовує інтерфейс HTTP для роботи з Express. 
3.2.4 Архітектурне програмування 
3.2.4.1 Діаграма компонентів 
 
Рис 3.4 – діаграма компонентів 
Пояснення діаграми: 
Node.JS Server: Це компонент, що відповідає серверу, який використовує 
Node.JS як основне середовище для запуску вашого проекту. Він містить два інші 
компоненти: Express та Mongoose. Він також має три інтерфейси: HTTP, 
MongoDB та AI. 
Express: Це компонент, що відповідає фреймворку Express, який 
використовується для обробки HTTP запитів від клієнтів. Він надає інтерфейс 
HTTP для зв’язку з Node.JS Server. Він також використовує інтерфейс AI для 
роботи з AI Server. 
Mongoose: Це компонент, що відповідає бібліотеці Mongoose, яка 
використовується для керування базою даних mongoDB. Він надає інтерфейс 
59 
ЧДТУ .232219.005 ПЗ 
MongoDB для зв’язку з Node.JS Server. Він дозволяє створювати схеми, моделі та 
запити до бази даних. 
mongoDB Server: Це компонент, що відповідає серверу баз даних, який 
зберігає і обробляє дані для вашого проекту. Він використовує mongoDB як 
конкретну СУБД. Він з’єднується з Node.JS Server за допомогою інтерфейсу 
MongoDB. 
AI Server: Це компонент, що відповідає серверу, на якому розташована 
модель штучного інтелекту, яку ви використовуєте для вашого проекту. Він 
приймає запити від Express за допомогою інтерфейсу AI і повертає результати. 
Web Client: Це компонент, що відповідає клієнтському додатку, який має 
деякі функції, такі як реєстрація, авторизація, завантаження та перегляд творів 
мистецтва. Він містить один компонент: React App. Він також має інтерфейс 
HTTP для зв’язку з Node.JS Server. 
React App: Це компонент, що відповідає бібліотеці React, яка 
використовується для створення інтерфейсу користувача для клієнтського 
додатку. Він надає інтерфейс HTTP для зв’язку з Web Client. Він також 
використовує інтерфейс HTTP для роботи з Express. 
Зв’язки між компонентами та інтерфейсами показують, як вони залежать 
один від одного та як вони співпрацюють між собою. Наприклад, Node.JS Server 
залежить від Express та Mongoose, а Express залежить від AI Server. 
3.2.4.2 Розгортання програмної системи на апаратних засобах 
 
Рис 3.5 − Діаграма розгортання 
Пояснення діаграми: 
Node.JS Server: Це компонент, що відповідає серверу, який використовує 
Node.JS як основне середовище для запуску вашого проекту. Він взаємодіє з 
двома іншими серверами: mongoDB Server та AI Server. 
Express: Це компонент, що відповідає фреймворку Express, який 
60 
ЧДТУ .232219.005 ПЗ 
використовується для обробки HTTP запитів від клієнтів. Він також може робити 
запити до AI Server для використання моделі штучного інтелекту. 
Mongoose: Це компонент, що відповідає бібліотеці Mongoose, яка 
використовується для керування базою даних mongoDB. Він дозволяє створювати 
схеми, моделі та запити до бази даних. 
mongoDB Server: Це сервер баз даних, який зберігає і обробляє дані для 
вашого проекту. Він використовує mongoDB як конкретну СУБД. 
AI Server: Це сервер, на якому розташована модель штучного інтелекту, яку 
ви використовуєте для вашого проекту. Він приймає запити від Express і повертає 
результати. 
Зв’язки між компонентами та серверами показують, як вони спілкуються 
між собою. Наприклад, Node.JS Server з’єднується з mongoDB Server, а Express 
робить запити до AI Server. 
3.2.5 Моделювання поведінки системи 
3.2.5.1 Діаграма діяльності 
 
Рис 3.7 − Діаграма діяльності 
 
Діаграма діяльності відображає послідовність дій та переходи між станами 
в рамках певної функціональності. Давайте розглянемо приклад діаграми 
діяльності для операції "Оформлення замовлення" на веб-сайті: 
Діаграма діяльності для операції "Оформлення замовлення": 
1 Початок 
61 
ЧДТУ .232219.005 ПЗ 
− Подія: Користувач розпочинає процес оформлення замовлення 
− Дія: Система ініціює процес та відображає сторінку оформлення 
замовлення 
2 Введення товарів в кошик 
− Подія: Користувач вибирає товари та додає їх в кошик 
− Дія: Система оновлює вміст кошика та відображає обрані товари 
3 Перевірка кошика 
− Подія: Користувач переглядає та перевіряє товари в кошику 
− Дія: Система відображає зміст кошика та дає можливість видалити 
або змінити кількість товарів 
4 Введення адреси доставки та інформації про платіж 
− Подія: Користувач вводить адресу доставки та обирає метод оплати 
− Дія: Система зберігає введену інформацію 
5 Підтвердження та оформлення замовлення 
− Подія: Користувач натискає кнопку "Оформити замовлення" 
− Дія: Система перевіряє введену інформацію, формує замовлення та 
відображає підтвердження 
6 Завершення 
− Подія: Замовлення успішно оформлене 
− Дія: Система зберігає інформацію про замовлення, надсилає 
підтвердження користувачу та готується до відправлення товарів 
7 Кінець 
− Подія: Завершення процесу оформлення замовлення 
− Дія: Система переходить у стан очікування нових замовлень 
Ця діаграма діяльності демонструє послідовність дій користувача та 
системи під час процесу оформлення замовлення на веб-сайті. Користувач 
взаємодіє з системою, вводячи дані та вибираючи товари, а система відповідає 
виконанням відповідних дій та зберігає необхідну інформацію. 
 
62 
ЧДТУ .232219.005 ПЗ 
 
Рис 3.8 − Діаграма діяльності авторизації 
Ця діаграма діяльності та станів розширює попередню діаграму, додаючи 
стани для кожного етапу процесу. Коли користувач вводить дані, система 
переходить до стану "Введення даних". Після перевірки правильності введених 
даних, система може опинитися в стані "Правильні дані" або "Помилка вводу". 
Якщо авторизація успішна, система переходить до стану "Авторизовано" та надає 
доступ до головної сторінки. Після цього система очікує нових дій від 
користувача в стані "Очікування нових дій". 
 
63 
ЧДТУ .232219.005 ПЗ 
 
Рис 3.9  − Діаграма REST API серверу 
 
Ця діаграма діяльності відображає процес обробки запиту до REST API. 
Система розпізнає запит, визначає ресурс та метод, перевіряє автентифікацію, 
виконує відповідну операцію, генерує відповідь та надсилає її клієнту через 
мережу. Після завершення обробки запиту, система очікує нових запитів в стані 
"Кінець". 
3.2.5.2 Діаграма послідовності 
64 
ЧДТУ .232219.005 ПЗ 
 
Рис 3.10 − Діаграма послідовності 
 
Діаграма 3.10 показує, як об’єкти обмінюються повідомленнями в певному 
порядку. На діаграмі є чотири об’єкти: Художник, Веб-сайт, База даних та 
ArtManager. Об’єкти представлені вертикальними лініями, а повідомлення - 
горизонтальними стрілками. Ось що відбувається на діаграмі: 
Художник завантажує свій твір мистецтва на веб-сайт. 
Веб-сайт передає твір мистецтва до ArtManager, який перевіряє його на 
валідність. 
Якщо твір мистецтва є валідним, ArtManager зберігає його в базі даних і 
отримує підтвердження збереження. Потім ArtManager повертає підтвердження 
до веб-сайту, який показує художнику повідомлення про успішне додавання 
твору мистецтва. 
Якщо твір мистецтва є невалідним, ArtManager повертає помилку до 
веб-сайту, який показує художнику повідомлення про невдале додавання твору 
65 
ЧДТУ .232219.005 ПЗ 
мистецтва. 
Суть діаграми послідовності полягає в тому, що вона демонструє, як 
об’єкти спілкуються один з одним, які повідомлення вони використовують, і в 
якому порядку вони відбуваються. Це допомагає розуміти логіку взаємодії та 
виявляти можливі проблеми або покращення. 
 
 
Рис 3.11 діаграма оплати та доставки. 
На діаграмі 3.11 є шість об’єктів: Користувач, Веб-сайт, Кошик, 
Замовлення, Оплата та Доставка. Ось що відбувається на діаграмі: 
− користувач переглядає твори мистецтва на веб-сайт; 
− веб-сайт показує твори мистецтва користувачеві; 
− користувач додає твір мистецтва до кошика; 
− веб-сайт оновлює кошик і показує підтвердження оновлення 
користувачеві; 
66 
ЧДТУ .232219.005 ПЗ 
− користувач переходить до оформлення замовлення; 
− веб-сайт створює замовлення і показує деталі замовлення 
користувачеві; 
− користувач обирає спосіб оплати; 
− веб-сайт обробляє оплату і показує підтвердження оплати 
користувачеві; 
− веб-сайт організовує доставку і показує підтвердження доставки 
користувачеві. 
Суть діаграми послідовності полягає в тому, що вона демонструє, як 
об’єкти спілкуються один з одним, які повідомлення вони використовують, і в 
якому порядку вони відбуваються. Це допомагає розуміти логіку взаємодії та 
виявляти можливі проблеми або покращення. 
3.2.5.3 Діаграма комунікації 
 
 
Рис 3.12 − Діаграма кооперації процес покупки та оплати 
 
Діаграма кооперації 3.12 показує, як об’єкти взаємодіють один з одним у 
рамках співпраці. На діаграмі є шість об’єктів: Користувач, Веб-сайт, Кошик, 
Замовлення, Оплата та Доставка. Ось що відбувається на діаграмі: 
− користувач переглядає твори мистецтва на веб-сайті; 
67 
ЧДТУ .232219.005 ПЗ 
− веб-сайт показує твори мистецтва користувачеві; 
− користувач додає твір мистецтва до кошика; 
− веб-сайт оновлює кошик і показує підтвердження оновлення 
користувачеві; 
− користувач переходить до оформлення замовлення; 
− веб-сайт створює замовлення і показує деталі замовлення 
користувачеві; 
− користувач обирає спосіб оплати; 
− веб-сайт обробляє оплату і показує підтвердження оплати 
користувачеві; 
− веб-сайт організовує доставку і показує підтвердження доставки 
користувачеві. 
Суть діаграми кооперації полягає в тому, що вона демонструє, як об’єкти 
спілкуються один з одним, які відносини вони мають, і які ролі вони виконують. 
Це допомагає розуміти структуру взаємодії та виявляти можливі проблеми або 
покращення. 
 
 
Рис 3.13 − Діаграма кооперації «Управління замовленням та магазином» 
 
Діаграма кооперації 3.13 показує, як об’єкти взаємодіють один з одним у 
рамках співпраці. На діаграмі є шість об’єктів: Клієнт, Магазин, Замовлення, 
Товар, Склад та Доставка. Ось що відбувається на діаграмі: 
− клієнт переглядає товари в магазині; 
68 
ЧДТУ .232219.005 ПЗ 
− магазин показує товари клієнту; 
− клієнт робить замовлення в магазині; 
− магазин створює замовлення і показує деталі замовлення клієнту; 
− магазин перевіряє наявність товару на складі; 
− товар повертає наявність до магазину; 
− магазин оновлює склад; 
− склад підтверджує оновлення до магазину; 
− магазин організовує доставку замовлення; 
− доставка підтверджує доставку до магазину; 
− магазин показує підтвердження доставки клієнту. 
Суть діаграми кооперації полягає в тому, що вона демонструє, як об’єкти 
спілкуються один з одним, які відносини вони мають, і які ролі вони виконують. 
Це допомагає розуміти структуру взаємодії та виявляти можливі проблеми або 
покращення. 
3.2.5.4 Діаграма скінченного автомату 
 
 
Рис 3.14 діаграма скінченного автомату 
 
Ця діаграма показує скінченний автомат, який моделює процес пошуку на 
сайті цифрових мистецтв. 
− Скінченний автомат - це математична модель, що використовується для 
опису зміни стану об’єкта в залежності від поточного стану та 
інформації, отриманої ззовні 
69 
ЧДТУ .232219.005 ПЗ 
− Скінченний автомат складається зі скінченної множини станів, одного 
початкового стану, множини допустимих станів, абетки вхідних 
символів та функції переходу, що визначає, в який стан переходить 
автомат при зчитуванні кожного символу 
− На діаграмі стани позначені кругами, а переходи - стрілками з 
позначеннями символів. Початковий стан позначений стрілкою 
«звідкись», а допустимі стани - подвійними кругами. 
− Цей автомат приймає рядки, які є коректними запитами для пошуку в 
інтернеті. Коректними є рядки, які містять одне або більше слів, 
розділених пробілами, і не містять спеціальних символів, таких як ?, !, 
@, # тощо. 
− Початковий стан - це стан, в якому автомат очікує на введення першого 
символу запиту. Якщо цей символ є літерою, то автомат переходить в 
стан пошуку, в якому він зчитує наступні символи запиту. Якщо цей 
символ є пробілом або спеціальним символом, то автомат залишається в 
початковому стані і відхиляє такий запит. 
− Стан пошуку - це стан, в якому автомат зчитує символи запиту і 
перевіряє їх на коректність. Якщо символ є літерою, то автомат 
залишається в стані пошуку. Якщо символ є пробілом, то автомат 
переходить в стан відступу, в якому він очікує на початок наступного 
слова. Якщо символ є спеціальним символом, то автомат переходить в 
стан помилки, в якому він відхиляє запит. 
− Стан відступу - це стан, в якому автомат очікує на початок наступного 
слова. Якщо символ є літерою, то автомат переходить в стан пошуку. 
Якщо символ є пробілом, то автомат залишається в стані відступу. 
Якщо символ є спеціальним символом, то автомат переходить в стан 
помилки. 
− Стан помилки - це стан, в якому автомат відхиляє запит. Якщо символ є 
будь-яким, то автомат залишається в стані помилки. 
− Стан перегляду - це допустимий стан, в якому автомат приймає запит. 
Цей стан досягається, коли автомат зчитав усі символи запиту і 
знаходиться в стані пошуку або відступу. 
 
70 
ЧДТУ .232219.005 ПЗ 
Розділ 4 Розробка та тестування програмного забезпечення 
4.1 Розробка програмного комплексу 
4.1.1Обгрунтування вибору засобів реалізації 
У якості загальної системи розробки була обрана система MERN (Mongo, 
Express, React, Node.js), через свою надзвичайту популярність, звучність та 
швидкість розробки. 
Система MERN дозволяє вам працювати з однією мовою 
програмування - JavaScript - для клієнтської та серверної частин, що зменшує 
складність та підвищує продуктивність. 
Система MERN використовує архітектуру MVC, яка допомагає 
створювати веб додатки з чіткою структурою та розділенням логіки, що полегшує 
розширення, тестування та налагодження13. 
Система MERN включає в себе потужні та сучасні технології, які 
дозволяють створювати швидкі, надійні та масштабовані веб додатки, які можуть 
працювати з великими обсягами даних, складною структурою та динамічними 
інтерфейсами. 
Система MERN дозволяє швидку та гнучку розробку, оскільки вона 
використовує відкриті джерела, готові компоненти та плагіни, а також має велику 
спільноту розробників, які надають підтримку та документацію123. 
Склідові системи також займають не останнє місте серед інструментів 
розробки, MongoDB - це нереляційна база даних, яка має такі переваги: 
− вона дозволяє зберігати дані у вигляді JSON-документів, що співпадає з 
форматом даних JavaScript, тому вона легко інтегрується з іншими 
компонентами MERN; 
− вона підтримує гнучку схему даних, яка може змінюватися без 
необхідності міграції або нормалізації; 
− вона має високу продуктивність та масштабованість, оскільки вона 
використовує індексацію, шардування, реплікацію та кешування; 
− вона має багатий набір операцій для запитів, агрегації, аналітики та 
71 
ЧДТУ .232219.005 ПЗ 
транзакцій. 
Express.js - це фреймворк для створення серверних додатків на Node.js, 
який має такі переваги: 
− він надає простий та елегантний спосіб обробляти HTTP-запити та 
відповіді, створювати маршрутизацію, додавати середній рівень 
(middleware) та інтегрувати різні шаблоні затори; 
− він допомагає побудувати швидкі та надійні серверні додатки з 
мінімальним кодом; 
− він підтримує різні HTTP-методи, такі як GET, POST, PUT, DELETE 
тощо, що дозволяє реалізувати RESTful API; 
− він має велику кількість плагінів та розширень, які можна легко 
встановити та використовувати за допомогою менеджера пакетів npm. 
React.js - це бібліотека для створення динамічних інтерфейсів користувача 
на JavaScript, яка має такі переваги: 
− вона використовує компонентний підхід, що дозволяє розбити 
інтерфейс на незалежні та повторно використовувані елементи; 
− вона використовує віртуальний DOM, що забезпечує високу 
продуктивність та ефективність оновлення інтерфейсу; 
− вона підтримує JSX, що є розширенням синтаксису JavaScript, яке 
дозволяє вбудовувати HTML-код у JavaScript-код; 
− вона має багато інструментів для розробки, тестування та 
налагодження, таких як React DevTools, React Hooks, React Router тощо. 
Node.js - це середовище виконання JavaScript на сервері, яке має такі 
переваги: 
− воно використовує неблокуючу та подієорієнтовану модель, що робить 
його швидким та масштабованим для обробки великої кількості 
одночасних запитів; 
− воно має велику кількість модулів та пакетів, які можна легко 
встановити та використовувати за допомогою менеджера пакетів npm; 
− воно підтримує різні протоколи та формати даних, такі як HTTP, 
72 
ЧДТУ .232219.005 ПЗ 
WebSocket, JSON, XML тощо, що дозволяє створювати різноманітні 
серверні додатки; 
− воно має вбудований веб-сервер, що зменшує необхідність 
використання сторонніх серверів, таких як Apache або Nginx. 
JWT (JSON Web Token) - це стандартний спосіб безпечної передачі даних 
між двома сторонами. Вони містять інформацію (заяви), закодовану в форматі 
JSON. Ці заяви допомагають обмінюватися певними деталями між зацікавленими 
сторонами. Кожен JWT підписаний криптографічно, щоб гарантувати, що його 
вміст не був змінений під час передачі або зберігання1. 
Система JWT має ряд переваг для авторизації користувачів та обміну 
повідомленнями між клієнтом та сервером, таких як: 
− Безстанова. JWT не вимагає зберігання стану користувача в базі даних, 
тому вона зменшує навантаження на сервер і полегшує масштабування2; 
− Ефективна. JWT містить усю необхідну інформацію, тому не потрібно 
звертатися до бази даних для перевірки автентичності або авторизації 
користувача2. Крім того, JWT швидко перевіряються, оскільки вони 
підписані секретним ключем3; 
− Гнучка. JWT може використовуватися для різних цілей, таких як 
аутентифікація, авторизація, обмін даними між серверами, оновлення 
токенів, скасування токенів тощо4. JWT також може містити будь-які 
дані, які ви хочете передати, за умови, що вони не є конфіденційними5; 
− Безпечна. JWT захищає дані від зміни або підробки, оскільки вони 
підписані криптографічно1. JWT також може використовуватися з 
HTTPS, що забезпечує конфіденційність даних під час передачі та 
ширший рівень захисту для даних у транзиті1. 
Система JWT була використана для авторизації користувачів та обміну 
повідомлень між клієнтом та сервером, оскільки вона має такі переваги: 
− вона безстанова, тому не потребує зберігання сесій або токенів в базі 
даних, що зменшує навантаження на сервер і полегшує масштабування; 
− вона ефективна, тому не потребує додаткових запитів до бази даних для 
73 
ЧДТУ .232219.005 ПЗ 
перевірки автентичності або авторизації користувача. Крім того, вона 
швидко перевіряється, оскільки вона підписана секретним ключем; 
− вона гнучка, тому може використовуватися для різних цілей, таких як 
аутентифікація, авторизація, обмін даними між серверами, оновлення 
токенів, скасування токенів тощо. Вона також може містити будь-які 
дані, які потрібно передати, за умови, що вони не є конфіденційними; 
− вона безпечна, тому захищає дані від зміни або підробки, оскільки вона 
підписана криптографічно. Вона також може використовуватися з 
HTTPS, що забезпечує конфіденційність даних під час передачі та 
ширший рівень захисту для даних у транзиті. 
4.1.2 Опис структурної (функціональної) системи 
Файлова структура клаєнтської частини має наступний вигляд: 
│   .gitignore 
│   package-lock.json 
│   package.json 
│   README.md 
│ 
├───public 
│       favicon.ico 
│       index.html 
│       logo192.png 
│       logo512.png 
│       manifest.json 
│       robots.txt 
│ 
└───src 
    │   App.css 
    │   App.js 
    │   blogs.json 
    │   index.css 
74 
ЧДТУ .232219.005 ПЗ 
    │   index.js 
    │   logo.svg 
    │   reportWebVitals.js 
    │   setupTests.js 
    │ 
    ├───assets 
    │       arrow-left.svg 
    │       arrow-right.svg 
    │       arrow-up-right.svg 
    │       dropdown.svg 
    │       search.svg 
    │       telegram.svg 
    │ 
    ├───component 
    │   ├───artUploadModal 
    │   │       artUploadModal.component.jsx 
    │   │       artUploadModal.styles.scss 
    │   │ 
    │   ├───blogCard 
    │   │       blogCard.component.jsx 
    │   │       blogCard.style.scss 
    │   │ 
    │   ├───blogSubscribeCard 
    │   │       blogSubscribeCard.component.jsx 
    │   │       blogSubscribeCard.style.scss 
    │   │ 
    │   ├───dropDownMenu 
    │   │       dropDownMenu.component.jsx 
    │   │       dropDownMenu.style.scss 
75 
ЧДТУ .232219.005 ПЗ 
    │   │ 
    │   ├───header 
    │   │       header.component.jsx 
    │   │       header.styles.scss 
    │   │ 
    │   ├───loginModal 
    │   │       loginModal.component.jsx 
    │   │       loginModal.styles.scss 
    │   │ 
    │   ├───paginationButtons 
    │   │       paginationButtons.component.jsx 
    │   │       paginationButtons.style.scss 
    │   │ 
    │   ├───profileInfo 
    │   │       profileInfo.component.jsx 
    │   │       profileInfo.style.scss 
    │   │ 
    │   └───signUpModal 
    │           signUpModal.component.jsx 
    │           signUpModal.styles.scss 
    │ 
    └───routes 
        └───home 
                home.component.jsx 
                home.style.scss 
Файлова структура серверної частина виглядає наступним чином: 
│   .env 
│   .gitignore 
│   config.json 
76 
ЧДТУ .232219.005 ПЗ 
│   package-lock.json 
│   package.json 
│   README.md 
│ 
└───src 
    │   Application.js 
    │   Config.js 
    │   index.js 
    │ 
    ├───database 
    │   │   databaseManager.js 
    │   │ 
    │   └───models 
    │           artwork.js 
    │           user.js 
    │ 
    └───express 
        │   expressManager.js 
        │ 
        └───routes 
                delete.user.js 
                get.artworks.js 
                get.genres.js 
                get.user.js 
                post.artwork.js 
                post.auth.js 
                post.checkToken.js 
                post.confirmArtwork.js 
                post.searchCompare.js 
77 
ЧДТУ .232219.005 ПЗ 
                post.user.js 
                put.userPassword.js 
4.1.3 Опис логічної системи 
Для серверної частини опис логічної струкрури додатку: 
У папці src знаходиться весь основний код додатку, розміщений по відповідним 
підпапкам (далі – модулі). 
Модуль бази даних (database) 
У цьому модулі знаходиться контроллер для бази даних, під назвою 
databaseManager.js, який відповідає за усі дії з базою даних та їх функції. І так як 
було використано бібліотеку Mongoose, було розроблено моделі для бази даних, 
які зберігаються у підпапці models, в яких описуються усі типи даних документів, 
які будуть зберігатися в базі. 
Модуль HTTP серверу (express) 
Модуль express відповідає за надання API доступу до серверу, а саме CRUD 
(Create, redact, update, delete) операції з користувачами, менеджмент творів 
мистецтва, також від здійснює запити до другого серверу Python, де розташована 
модел розпізнавання та опису зображень. У підпапці routes знаходяться усі 
можливі роути для запитів на сервер. 
Опис логічної структури клієнтської частини додатку: 
Клієнтська частина буда написана за допомогою бібліотеки React, за має 
відповідну структуру папок.  
В src папці знаходиться основна чатина додатку, де можна знайти файли 
App.js, App.css та index.js, які є вхідною точкою для веб-сайту.  
У assets знаходиться усі зображення, що використовуються сайтом. 
Одна з головних папок – components, в ній знаходяться усі компоненти 
(модулі) сайту, саме з яких він і складається. 
Модуль routes відповідає за усі роути, які будуть використовуватися сайтом. 
Вони з себе представляють такі ж самі компоненти. 
78 
ЧДТУ .232219.005 ПЗ 
 
 
Рис 4.1 − Взаємодія сервісів серверної частини 
 
Діаграма 4.1 показує, як різні компоненти вашого сервера взаємодіють між 
собою за допомогою інтерфейсів та конекторів. На діаграмі зображено три 
компоненти: Express, Server та Database. Компонент Express надає веб-фреймворк 
для створення та обробки запитів від користувачів. Компонент Server з’єднується 
з джерелом даних, яке представлено компонентом Database. Компонент Database 
зберігає та повертає дані, які потрібні для роботи сервера. Компоненти з’єднані 
між собою за допомогою конекторів, які показують, як вони спілкуються та 
обмінюються інформацією. Конектори також мають порти, які вказують, які 
інтерфейси використовуються для взаємодії. 
79 
ЧДТУ .232219.005 ПЗ 
 
Рис 4.2 − Діаграма класів серверної частини 
 
Діаграма 4.2 показує, як різні класи вашого сервера визначають свої 
атрибути та методи, а також як вони пов’язані між собою за допомогою асоціацій, 
агрегацій та композицій. На діаграмі зображено чотири класи: Express, AIModel, 
Server та Database. Клас Express має атрибут app, який є екземпляром Application, 
та методи get, post та listen, які дозволяють створювати та обробляти запити 
веб-сервера. Клас AIModel має атрибут model, який є екземпляром 
TensorflowModel, та методи loadModel, predict та classify, які дозволяють 
завантажувати, передбачати та класифікувати дані за допомогою моделі. Клас 
Server має атрибути host, port та protocol, які визначають параметри сервера, та 
методи createServer, close, request та response, які дозволяють створювати, 
закривати, надсилати та отримувати запити та відповіді. Клас Database має 
атрибути connection, schema та model, які представляють з’єднання з базою 
даних, схему даних та модель даних, та методи connect, disconnect, createSchema 
80 
ЧДТУ .232219.005 ПЗ 
та createModel, які дозволяють підключатися, відключатися, створювати схеми та 
моделі даних. Класи з’єднані між собою за допомогою різних типів зв’язків, які 
показують, як вони залежать один від одного. Клас Express агрегує клас Server, 
що означає, що він має посилання на екземпляр класу Server, але не володіє ним. 
Клас AIModel використовує клас Express, що означає, що він викликає методи 
класу Express, але не має посилання на нього. Клас Server компонує клас 
Database, що означає, що він володіє екземпляром класу Database, і 
відповідальний за його створення та видалення. 
4.1.4 Розробка бази даних 
В даній роботі існує база даних, яка включає в себе дві сутності для 
зберігання даних творів та користувачів.  
Схема творів (Artworks)   
url: URL твору (строка, обов’язкове, унікальне).  
description: Опис твору (строка, обов’язкове).  
genre: Жанр твору (строка, обов’язкове).  
author: Автор твору (строка, обов’язкове).  
uploader: Користувач, який завантажив твір (строка, обов’язкове).  
type: Тип твору (строка, обов’язкове). 
Схема користувачів (Users)  
username: Ім’я користувача (строка, обов’язкове, унікальне).  
password: Закодований пароль користувача (строка, обов’язкове).  
email: Email користувача (строка, обов’язкове, унікальне).  
rating: Рейтинг користувача (число, за замовчуванням 0).  
role: Роль користувача (строка, за замовчуванням ‘User’).  
Ці схеми взаємодіють з модулями проекту та дозволяють створювати, 
читати, оновлювати та видаляти (CRUD) документи у базі даних. Кожна схема 
має відповідні поля для зберігання відповідних даних та забезпечує зв’язок між 
різними елементами системи. 
Опис процесу розробки бази даних MongoDB з використанням Mongoose: 
− підключитися до бази даних MongoDB за допомогою 
81 
ЧДТУ .232219.005 ПЗ 
методу mongoose.connect(), передавши URL бази даних як перший 
аргумент. Наприклад, якщо база даних називається artdb і вона 
розташована локально; 
− створити схеми для сутностей за допомогою конструктора Schema, 
передавши об’єкт, що визначає структуру документів, як аргумент; 
− створити моделі для схем за допомогою методу mongoose.model(), 
передавши назву моделі як перший аргумент і схему як другий. Назва 
моделі повинна бути в однині, а Mongoose автоматично перетворить її 
на множину і використовуватиме її як назву колекції; 
− використовувати моделі для створення, читання, оновлення та 
видалення (CRUD) документів у базі даних. Кожна модель має різні 
методи та запити, які дозволяють взаємодіяти з даними. 
4.1.5 Розробка інтерфейсу користувача 
Інтерфейс користувача був розроблений за допомогою бібліотеки React, 
Елементи в React називаються компонентами. Компоненти - це будівельні 
блоки інтерфейсу, які можуть бути повторно використані та комбіновані. 
Компоненти можуть бути функціональними або класовими, залежно від того, чи 
мають вони власний стан або ні. Стан - це внутрішні дані, які зберігаються в 
компонентах і можуть змінюватися в результаті дій користувача або інших подій. 
Пропси - це вхідні параметри, які передаються в компоненти з батьківських 
компонентів. Пропси дозволяють передавати дані між компонентами та 
налаштовувати їх поведінку. 
React використовує віртуальний DOM, який є легкою копією реального 
DOM, що представляє структуру веб-сторінки. React порівнює віртуальний DOM 
з реальним DOM і оновлює лише ті частини, які змінилися, що підвищує 
продуктивність інтерфейсу. React також підтримує розробку односторінкових 
додатків (SPA), які забезпечують швидку і гладку навігацію між різними 
екранами без перезавантаження сторінки. Для цього React використовує роутинг, 
який дозволяє змінювати URL без переходу на іншу сторінку. 
Сам інтерфейс користувача був розроблений в основі для тестування 
82 
ЧДТУ .232219.005 ПЗ 
серверу, тому не потребує сильних мір захисту та контролю. Тому він буде 
написаний в основном для демонстрації можливостей системи та візуалізації 
даних. 
 
 
Рис 4.1 – Верхня частина клієнтського додатку 
У верхній частині кієнтського додатку розташовані кнопки авторизації, та 
реєстрації, їх може бачити лише не авторизований користувач, при їх натисканні 
з’явзяється вікно вводу, в якому можна авторизуватися або зареєструватися в 
залежності від нажатої кнопки. 
 
Рис 4.2 – Вікно реєстрації 
  Як видно з рисунка 4.2, для реєстрації потрібно вказати електронну 
пошту, ім’я користувача та пароль. І при успішном виконанні вікно закривається і 
користувач додається в базу даних. 
83 
ЧДТУ .232219.005 ПЗ 
 
Рис 4.3 – Вікно авторизації 
 На рисунку 4.3 зображено вікно авторизації, в якому користувач може 
ввести дані, які він указував под час реєстрації, та нажати кнопку login, тим 
самим надіславши запит на сервер, і при успішному виконанні поверне JWT 
токен, який зберігається в localstorage та має термін дії 1 день. 
 
Рис 4.4 – Верхня частина клієнтського додатку для авторизованого користувача 
84 
ЧДТУ .232219.005 ПЗ 
 
На рисунку 4.4 зображений header (верхня частина) клієнтської частини для 
авторизованого користувача, можна помітити, що кнопки авторизації та 
реєстрації змінились на upload art та імя профілю, при натисканні на кнопку 
upload art, відкривається вікно де можна закантажити свій твір на сервер. 
 
Рис 4.5 – Вікно завантаження роботи на сервер 
 На рисунку 4.5 зображено вікно завантаження творів мистецтва на сервер, 
для цього потрібно вказати пряме посилання на картинку, її жанр, тип та повне 
ім’я автора, при завантаженні, відкривається друге вікно з меню підтвердження, 
як видно на рисунку 4.6. 
85 
ЧДТУ .232219.005 ПЗ 
 
Рис 4.6 – Меню підтвердження завантаження роботи 
 
 Нижче від цих кнопок знаходиться система пошуку по сайту, а саме 3 види 
фільтрації, по пошуковому запиті, по тегу та по жанру. 
 
 
Рис 4.7 – Типи фільтрації 
86 
ЧДТУ .232219.005 ПЗ 
 Як видно з зображення 4.7 – існує декілька видів фільтрації, а саме 
вдосноналений покуковий рядок, фільтри по тегу роботи (View all, Photo, …) 
Та фільтр по жанрам роботи. Жанри завантажуються з серверу, та представляють 
собою усі жанри, які вказували при завантаженні робіт. 
 
 
Рис 4.8 – Приклад жанрів робіт 
 
 На клієнтській частині також працює пагінація (розділення на сторінки), а 
саме по 8 робіт на 1 сторінку, і 1 рекламний блок. Роботи завжди будуть 
відображатися сіткою 3 на 3, рекламний блок завжи розташований в другому 
ряду, ліве місце. 
 
Рис 4.9 – Сітка розташування робіт. 
87 
ЧДТУ .232219.005 ПЗ 
 
Рис 4.9 – Вигляд основного блок сайту 
4.1.6 Опис розробки програмних компонентів 
Створення програмних компонентів - це важлива частина розробки 
сучасних інформаційних систем. У цьому контексті, програмні компоненти - це 
основні модулі та елементи системи, які співпрацюють для надання її 
функціональності та продуктивності. Для створення цих компонентів необхідно 
враховувати кілька важливих аспектів. Встановлення Функціональності Перш 
ніж починати створення, потрібно чітко встановити функціональні вимоги для 
кожного компонента. Це означає визначення основних задач, які мають 
виконувати компоненти, та їх співпрацю для досягнення загальних цілей.  
88 
ЧДТУ .232219.005 ПЗ 
Застосування Об’єктно-Орієнтованого Програмування (ООП): Однією з 
головних стратегій при створенні програмних компонентів є застосування 
об’єктно-орієнтованого програмування. Цей метод дозволяє симулювати реальні 
об’єкти та їх співпрацю, роблячи код більш зрозумілим та легко змінюваним. 
Кожен компонент представляється в програмному коді як об’єкт, який має свої 
властивості та методи. Створення Модульної Архітектури Для ефективного 
створення програмних компонентів потрібно створити модульну архітектуру 
системи. Кожен компонент має виконувати певні задачі та бути самостійним 
модулем. Це дозволяє легко розширювати та модифікувати систему без впливу на 
інші компоненти.  
Застосування Сервісно-Орієнтованої Архітектури (SOA): У сучасному 
програмуванні важливим є застосування сервісно-орієнтованої архітектури. Цей 
метод передбачає створення програмних компонентів як незалежних сервісів, які 
можуть співпрацювати один з одним через визначені інтерфейси. Це забезпечує 
гнучкість та масштабованість системи.  
Тестування та Валідація: Процес створення програмних компонентів 
включає в себе етап тестування та валідації. Кожен компонент має бути ретельно 
протестований для переконаності в його роботоздатності та відповідності 
функціональним вимогам. Використання автоматизованих тестів допомагає 
забезпечити стабільність системи.  
Завершення Створення та Впровадження: Останнім етапом є завершення 
створення кожного компонента та його впровадження в систему як цілого 
продукту. Це передбачає інтеграцію компонентів та кінцеву перевірку їх 
співпраці. У цій роботі створення програмних компонентів виконується з 
використанням сучасних методів та практик, що сприяють створенню 
ефективних та надійних інформаційних систем. Кожен компонент грає важливу 
роль у функціональності системи, а їх співпраця дозволяє досягти цілей 
створення. 
4.2 Тестування системи 
4.2.1 Модульне тестування 
89 
ЧДТУ .232219.005 ПЗ 
Я буду використовувати мову програмування JavaScript, оскільки проект 
написаний на ній. 
Я буду використовувати фреймворк Mocha для створення та запуску 
модульних тестів. Mocha дозволяє організовувати тести в групи, використовувати 
хуки (hooks) для підготовки та прибирання даних, та використовувати різні 
інтерфейси для опису тестів. 
Я буду використовувати бібліотеку Chai для створення тверджень 
(assertions) про очікувані результати модульних тестів. Chai надає різні стилі 
тверджень, такі як expect, should, та assert, які дозволяють виражати очікування в 
зрозумілій та зручній формі. 
Я буду використовувати бібліотеку Sinon для створення та використання 
шпигунів (spies), стабів (stubs) та моків (mocks), щоб ізолювати модулі від 
залежностей та емулювати реальні об’єкти. Шпигуни дозволяють відстежувати 
виклики функцій та їх аргументи, стаби дозволяють замінювати функції на 
фіктивні, а моки дозволяють створювати фіктивні об’єкти з певними 
поведінками. 
Я буду використовувати бібліотеку Supertest для створення та відправлення 
HTTP-запитів до вашого веб-сервера та перевірки отриманих відповідей. 
Supertest дозволяє легко тестувати HTTP-ендпойнти, використовуючи зручний та 
зрозумілий інтерфейс. 
Я буду тестувати два основних типи модулів: функції бази даних та функції 
Express. 
Для тестування функцій бази даних я буду використовувати Chai та Sinon. 
Я буду перевіряти, чи ваш код правильно з’єднується з базою даних, чи він може 
створювати, читати, оновлювати та видаляти дані, чи він враховує можливі 
помилки та винятки, та чи він повертає очікувані результати. Я буду 
використовувати Sinon для створення та використання моків для бази даних, щоб 
не залежати від реальної бази даних та емулювати різні ситуації. Я буду 
90 
ЧДТУ .232219.005 ПЗ 
використовувати Chai для створення тверджень про результати запитів до бази 
даних, використовуючи різні тестові дані та сценарії. 
Для тестування функцій Express я буду використовувати Supertest та Sinon. 
Я буду перевіряти, чи ваш код правильно налаштовує та запускає веб-сервер, чи 
він може обробляти різні типи HTTP-запитів, чи він використовує правильні 
маршрути та обробники, чи він враховує можливі помилки та винятки, та чи він 
повертає очікувані відповіді. Я буду використовувати Supertest для створення та 
відправлення HTTP-запитів до вашого сервера та перевірки отриманих 
відповідей, використовуючи різні тестові запити та сценарії. Я буду 
використовувати Sinon для створення та використання шпигунів, стабів та моків 
для вашого сервера, щоб не залежати від реального сервера та емулювати різні 
ситуації. 
Результати модульного тестування 
Компонент Результат 
index.js Успішний запуск 
Application.js Успішне завантаження залежностей 
Config.js Успішне завантаження залежностей 
config.json Успішне завантаження залежностей 
databaseManager.js Успішне завантаження залежностей 
expressManager.js Успішне завантаження залежностей 
91 
ЧДТУ .232219.005 ПЗ 
userModel.js Успішне завантаження залежностей 
artworkModel.js Успішне завантаження залежностей 
expressRoutes Успішне завантаження залежностей 
 
4.2.2 Інтеграційне тестування 
Для проведення інтеграційного тестування для вашого проекту я буду 
використовувати наступні кроки: 
1 буде визначено порядок інтеграції модулів. Буде обрано один з підходів, 
таких як Big Bang, зверху-донизу, знизу-вгору, або комбінацію їх. 
2 виберу інструменти та фреймворки для інтеграційного тестування. буду 
використовувати ті ж інструменти, що і для модульного тестування, такі як 
Mocha, Chai, Sinon, Supertest, або інші, залежно від мови програмування. 
3 створю тест-кейси для інтеграційного тестування. Ви можете 
використовувати специфікації інтерфейсів між модулями, вимоги до 
функціональності, продуктивності, надійності, та інші критерії якості для 
визначення очікуваних результатів та сценаріїв тестування4. 
4 запущу тест-кейси та аналізуйте результати. Ви можете використовувати 
автоматизовані тести, щоб швидко та ефективно перевірити інтеграцію 
модулів, а також ручні тести, щоб перевірити складні або нестандартні 
ситуації. 
5 виправлю дефекти та повторю тестування. Можна використовувати 
системи безперервної інтеграції (CIS), щоб автоматично запускати тести 
після кожної зміни коду, щоб виявляти та виправляти проблеми на ранній 
стадії. 
92 
ЧДТУ .232219.005 ПЗ 
 
Інтегровані Компоненти Результат 
index + Application Успішне завантаження 
залежностей 
Config + environment + ConfigModule Успішне завантаження 
залежностей 
DatabaseModule + databaseModels Успішне завантаження 
залежностей 
ExpressModel + express routes Успішне завантаження 
залежностей 
 
4.2.3 Системне тестування 
Системне тестування — це тестування програмного забезпечення на рівні 
повної інтегрованої системи, щоб перевірити її відповідність функціональним та 
нефункціональним вимогам. Системне тестування використовує метод “чорної 
скриньки”, тобто не залежить від внутрішньої структури програми, а тільки від її 
зовнішньої поведінки. 
Тестування буде показано на прикладі реєстрації у клієнтському додатку. 
Тестування буде проводитись за допомогою бібліотеки Silenium, javaScript 
бібліотеки, в якій є можливість системного тестування. 
Для початку створюю об'єкт драйвера для браузера Chrome 
driver = webdriver.Chrome() 
Відкриваю веб-сайт, а саме локальний сервер 
driver.get("https://127.0.0.1:3000/signUp") 
93 
ЧДТУ .232219.005 ПЗ 
Знаходжу елементи для введення даних реєстрації 
name_input = driver.find_element_by_id("name") 
email_input = driver.find_element_by_id("email") 
password_input = driver.find_element_by_id("password") 
confirm_password_input = driver.find_element_by_id("confirm_password") 
register_button = driver.find_element_by_id("register") 
Ввожу тестові дані для реєстрації 
name_input.send_keys("Test User") 
email_input.send_keys("[email protected]") 
password_input.send_keys("test123") 
confirm_password_input.send_keys("test123") 
 Натискаю кнопку реєстрації 
register_button.click() 
Чекаю, поки з'явиться повідомлення про успішну реєстрацію 
success_message = WebDriverWait(driver, 10).until( 
    EC.presence_of_element_located((By.ID, "success_message")) 
) 
Перевіряю, чи текст повідомлення відповідає очікуваному 
assert success_message.text == "Registration successful!" 
Закриваю браузер 
driver.quit() 
 Таким чином були протестовані і інші модулі системи, 
 
Функціональність/Сценарій Результат 
RegistrationModule Виконання успішне 
94 
ЧДТУ .232219.005 ПЗ 
LoginModule Виконання успішне 
ReactApplication Успішний запуск 
UploadArtwork Виконання успішне 
 
4.2.4 Приймальне тестування 
Для наочності роботи та тестування був вибраний Postman (рис 4.4). Це 
інструмент для документації та тестування API. Його застосування в проекті має 
кілька важливих переваг.  
По-перше, Postman дозволяє автоматично створювати документацію API на 
основі виконаних запитів, що дозволяє легко та зручно переглядати всі наявні 
ендпоінти, їх параметри та формат відповідей. Крім того, Postman показує 
структуру запитів і відповідей у зрозумілому вигляді, що сприяє легкому 
використанню API для інших розробників або команди, а також сприяє більш 
швидкій розробці проектів та співпраці між різними командами. 
Тестування буде проходити на розвернулому сервері, та будуть 
протестовані усі ендпоінти. 
 
Ендпоінт Очікуємий результат 
DELETE /user 200 
GET /artworks 200 
GET /genres 200 
95 
ЧДТУ .232219.005 ПЗ 
GET /user 200 
POST /artwork 201 
POST /auth 200 
POST /check-token 200 
POST /confirm-artwork 201 
POST /search-compare 200 
POST /user 201 
PUT /user-password 201 
 
 
Рис 4.10 - get genres запит 
 
Запит на рисунку 4.10 повернув статус код 200, що значить успішне 
96 
ЧДТУ .232219.005 ПЗ 
виконання, а в тілі відповіді повернув усі можливі жанри, які потім 
використовуються для клієнтської частини додатку. 
 
 
Рис 4.11 - get artworks запит 
 
 Як видно з рисунка 4.11, запит на отримання усіх творів мистецтва успішно 
повернув набір даних та статус 200 (успіх) 
 
Рис 4.12 - post auth запит 
97 
ЧДТУ .232219.005 ПЗ 
Як видно з запиту на рисунку 4.12, для запиту на роут auth потрібно вже 
тіло запиту, а саме пошта та пароль, які потрібні для авторизації. Сервер 
повернув статус 200 (успіх) та токен, за яким можна буде робити запити до 
захищених роутів. 
 
Рис 4.13 - get user запит 
 
Рис 4.14 - post check-token запит 
98 
ЧДТУ .232219.005 ПЗ 
 
Рис 4.15 - post user запит 
 
Рис 4.16 - put userPassword запит 
99 
ЧДТУ .232219.005 ПЗ 
 
 
№ Опис тесту Очікваний Фактичний результат Статус 
результат 
1 GET /genres Повернено список Повернено список Пройдено 
жанрів жанрів 
2 GET /artworks Повернено роботи Повернено роботи Пройдено 
мистецтва мистецтва 
3 GET /user Отримано Отримано інформацію Пройдено 
інформацію про про користувача 
користувача 
4 POST /auth Користувача Користувача Пройдено 
авторизовано та авторизовано та 
повернуто JWT повернуто JWT ключ 
ключ 
5 POST Токен перевірено та Токен перевірено та Пройдено 
/check-token повернута повернута інформація 
інформація про про нього 
нього 
6 POST /user Створено нового Створено нового Пройдено 
користувача на користувача на 
повернено його повернено його номер 
номер 
7 POST Пароль користувача Пароль користувача Пройдено 
/newPassword оновлено оновлено 
 
4.3 Приклади впровадження програмного комплексу 
Робота з додатком: планується запустити. Впровадження програмного 
комплексу для тестування роботи веб-застосунку описано в публікації, може мати 
різноманітні форми, в залежності від специфіки, використання, організаційних 
потреб та цілей. 
 
100 
ЧДТУ .232219.005 ПЗ 
Висновки 
Дана робота є результатом отриманих знань та навичок, які були отримані 
під час навчання. Досліджуючи предметну область, виявлено, що розробка 
програмного забезпечення, головною метою якого, є створення ефективної 
системи пошуку для маркетплейсів цифрового мистецтва, дозволить покращити 
якість та доступність цього виду творчості для широкої аудиторії. Також 
допоможе художникам, які працюють у цій сфері, знайти своїх покупців та 
отримати винагороду за свої таланти. Такий підхід сприятиме розвитку 
цифрового мистецтва як нової форми вираження та комунікації, а також 
збагатить культурне різноманіття та креативність суспільства. Такий підхід 
відкриває нові можливості для художників та любителів цифрового мистецтва та 
сприяє підвищенню рівня цікавості та зацікавленості до цього виду творчості. 
Була реалізована клієнт-серверна архітектура програмного забезпечення 
для такої системи пошуку з використанням сучасних технологій в розробці 
веб-додатків. Програмна частина була створена шляхом використання 
найсучасніших рішень та практик, які є на даний момент в цій сфері. 
Було використано метод функціонального програмування, що дозволяє 
отримати високу продуктивність та надійність програмного забезпечення, 
забезпечуючи чистоту та простоту коду, а також легкість тестування та 
налагодження. Було використано Node.js для розробки серверної частини та React 
для розробки клієнтської частини інформаційних систем пошуку для маркетплейсів 
цифрового мистецтва. 
 
101 
ЧДТУ .232219.005 ПЗ 
Список використаних джерел 
1. Як і де продавати цифрове мистецтво онлайн - Dropbox: 
https://experience.dropbox.com/uk-ua/resources/sell-digital-art-online 
2. NFT: як заробити на продажі цифрового мистецтва (oschadbank.ua): 
https://www.oschadbank.ua/blog/nft-yak-zarobyty-na-prodazhi-cyfrovogo-myste
ctva 
3. Розробка уроку на тему "Ілюстрація. Цифрове мистецтво. Сучасна реклама 
та фірмовий стиль: напрямки, стилі, тренди". (naurok.com.ua) - 
https://naurok.com.ua/rozrobka-uroku-na-temu-ilyustraciya-cifrove-mistectvo-su
chasna-reklama-ta-firmoviy-stil-napryamki-stili-trendi-275077.html 
4. Веб-фреймворк Express (Node.js/JavaScript) - Изучение веб-разработки | 
MDN (mozilla.org): 
https://developer.mozilla.org/ru/docs/Learn/Server-side/Express_Nodejs 
5. Express - фреймворк веб-приложений Node.js (expressjs.com): 
https://expressjs.com/ru/ 
6. Создание и настройка проекта React с помощью приложения Create React 
App | DigitalOcean: 
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-react-project
-with-create-react-app-ru 
7. https://www.searchenginewatch.com/2020/06/18/eight-great-tips-for-internal-sit
e-search-optimization/ 
102
ChSTU repository

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