Репозиторій ЧДТУ

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
 
на тему:  Розробка клієнт-серверної архітектури для інформаційної 
системи з поліагентним функціоналом 
 
 
Виконав: студент 2 курсу, групи МПЗ-2204 
Напряму підготовки  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Огніченко І.А. 
 (прізвище та ініціали) 
Керівник Немченко В.В. 
 (прізвище та ініціали) 
Рецензент Смоляр Д.А. 
 (прізвище та ініціали) 
 
Черкаси 2023
ЧДТУ.232229.021 ПЗ 
ЗМІСТ 
ПЕРЛІК УМОВНИХ ПОЗНАЧЕНЬ 6	
ВСТУП 7	
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ 10	
1.1 Основні визначення 10	
1.2 Аналіз та моніторинг сучасних інформаційних систем з поліагентним функціоналом11	
1.3 Види сучасних для інформаційних систем з поліагентним функціоналом 12	
1.4 Методи реалізації  сучасних інформаційних систем з поліагентним функціоналом. 
Огляд вимог і рішень 14	
Висновки до розділу 16	
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 17	
2.1 Теоретичні дослідження клієнт-серверної архітектури 17	
2.1.1 Різновиди клієнт - серверної архітектури 19	
2.1.2 Дослідження та аналіз основних вразливостей системи 32	
2.2 Експериментальні дослідження 36	
Висновки до розділу 41	
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЬ У ПРАКТИКУ ТА 
ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ 42	
3.1 Моделювання предметної області 42	
3.1.1 Модель предметної області 42	
3.1.2 Словник предметної області 43	
3.1.3 Елементи моделювання предметної області 44	
3.1.4 Робоча область моделювання 46	
3.2 Формування та аналіз вимог 47	
3.2.1 Первинні вимоги замовника 47	
3.2.2 Детальні вимоги розробника 48	
3.2.3 Функціональні вимоги 49	
3.2.4 Нефункціональні вимоги 50	
3.2.5 Формування вимог за допомогою діаграми прецедентів 50	
3.4 Проєктування логічної структури програмного комплексу 52	
3.4.1. Діаграми класів 53	
3.4.2 Діаграми пакетів 55	
3.5 Архітектурне проєктування 57	
3.5.1 Діаграма компонентів 58	
4 
ЧДТУ.232229.021 ПЗ 
 
3.5.2 Розгортання програмної системи. Діаграма розгортання 60	
3.6 Моделювання поведінки системи 62	
3.6.1 Діаграма діяльності 62	
3.6.2 Діаграма послідовності 64	
3.6.3 Діаграма комунікації 65	
3.6.4 Діаграма скінченного автомату 67	
Висновки до розділу 69	
РОЗДІЛ 4 КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 70	
4.1 Розробка програмного комплексу 70	
4.1.1 Обґрунтування вибору засобів реалізації 70	
4.1.2 Вибір методу розробки системи 72	
4.1.3 Опис структурної (функціональної) схеми 74	
4.1.4. Опис логічної схеми системи 77	
4.1.5 Розробка бази даних 80	
4.1.6 Розробка інтерфейсу користувача 84	
4.1.7 Опис розробки програмних компонентів 91	
4.2 Тестування системи 94	
4.2.1 Модульне тестування 95	
4.2.2 Інтеграційне тестування 96	
4.2.3 Системне тестування 98	
4.2.3 Кросбраузерне тестування 100	
4.2.3 Приймальне тестування 100	
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 105	
ДОДАТОК А 105 
ДОДАТОК Б 105	
 
 
  
5 
 
ЧДТУ.232229.021 ПЗ 
 
ПЕРЛІК УМОВНИХ ПОЗНАЧЕНЬ 
UI     – графічний інтерфейс користувача 
API     – програмний інтерфейс додатку.  
MVP     – шаблон проєктування  
MVC    – шаблон проєктування  
 MVVM    – шаблон архітектури 
XML     – розширювана мова розмітки  
Валідація    – перевірка коректності  
Firebase Authentication  – зовнішній програмний продукт 
ІС     – Інформаційна система  
БД     – база даних  
  
6 
 
ЧДТУ.232229.021 ПЗ 
 
ВСТУП 
Актуальність роботи. Актуальність роботи на тему "Розробка клієнт-
серверної архітектури для інформаційної системи з поліагентним функціоналом" 
визначається в сучасному контексті стрімкої еволюції інформаційних технологій. З 
усіляко зростаючим обсягом даних та складністю завдань, постає необхідність у 
вдосконаленні інформаційних систем. Поліагентний підхід, що досліджується у 
дипломній роботі, стає ключовим у розв'язанні завдань співпраці та координації між 
компонентами системи. Розробка ефективної клієнт-серверної архітектури, яка 
використовує поліагентний функціонал, відповідає потребам сучасних 
інформаційних систем, сприяючи підвищенню їхньої продуктивності та 
адаптивності. Дана робота вносить важливий внесок у розвиток області, надаючи 
нові підходи до взаємодії та обміну інформацією між агентами. Особливий акцент 
на розробці ефективних механізмів комунікації та співпраці агентів робить її 
відмінною в контексті поточних викликів інформаційного суспільства. 
Мета і завдання дослідження. Мета дослідження полягає в розробці та 
вдосконаленні архітектурного підходу до побудови інформаційних систем, що 
використовують поліагентний функціонал. Основна мета - створення ефективної 
структури, яка забезпечує оптимальну взаємодію та співпрацю між різними 
компонентами системи на основі агентної парадигми.  
Завдання дослідження включають:  
- проєктування клієнт-серверної архітектури: розробка архітектурної 
концепції, яка ефективно використовує клієнт-серверний підхід для 
оптимізації взаємодії агентів у системі;  
- оптимізація обміну інформацією: впровадження механізмів для 
оптимізації обміну інформацією між агентами з метою підвищення 
ефективності та швидкості комунікації;  
- аналіз та дослідження: проведення експериментів та аналіз результатів для 
визначення рівня безпечності розробленої архітектури у реальних умовах 
експлуатації. 
7 
 
ЧДТУ.232229.021 ПЗ 
 
Об’єктом дослідження є структура та взаємодія компонентів цієї архітектури, 
а також розробка механізмів, що забезпечують ефективну комунікацію та співпрацю 
агентів у різних частинах інформаційної системи. Архітектура та її функціонал 
виступають об’єктом уваги дослідження з метою вдосконалення та оптимізації 
їхньої роботи в контексті використання поліагентного підходу. 
Предметом дослідження виступають моделі та механізми, які дозволяють 
агентам взаємодіяти та співпрацювати з оптимальною ефективністю в рамках 
клієнт-серверної архітектури із застосуванням поліагентного підходу. 
В якості основних методів дослідження використаних в роботі, 
застосовувалися методи системного аналізу, методи розробки графічного 
інтерфейсу, методи обробки табличних даних, методи авторизації користувача. 
Наукова новизна отриманих результатів. Впровадження отриманих 
результатів дозволить аналізувати унікальні кастомізовані дані та вирішить задачу 
візуального відображення цих даних. 
Практичне значення одержаних результатів. Запропоновані рішення 
можуть бути використані для впровадження позитивних змін у функціонуванні 
інформаційних систем та можливість їхнього успішного застосування в різних 
галузях та областях діяльності. Також практичне значення одержаних результатів 
включає: 
- ефективність інформаційних систем: розроблена архітектура дозволяє 
підвищити продуктивність та швидкість взаємодії між компонентами 
системи, що безпосередньо впливає на ефективність роботи інформаційної 
системи;  
- гнучкість та адаптивність: розроблені механізми дозволяють системі легше 
адаптуватися до змінних умов та вимог, що робить її більш гнучкою та 
відзивчивою до змін в середовищі;  
- подальший розвиток технологій: результати дослідження можуть служити 
основою для подальших наукових досліджень та розвитку поліагентних 
технологій у сфері інформаційних технологій. 
8 
 
ЧДТУ.232229.021 ПЗ 
 
Особистий внесок автора виражений у всіх наукових результатах, 
представлених у дипломній роботі, які є особистим досягненням автора. До 
досягнень автора входять наступні елементи: архітектура програмного 
застосування, розроблені алгоритми, клієнтська частина програми та серверна 
частина програми. 
Участь в I Міжнародній науково-практичній конференція “SCIENCE AND 
SOCIETY: MODERN TRENDS IN A CHANGING WORLD”, 18-20.12.2023 на тему: 
"Aгентно-орієнтована інформаційна система на основі генеративних нейронних 
мереж" (результати конференції у формі тез).  
9 
 
ЧДТУ.232229.021 ПЗ 
 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Основні визначення 
Архітектура клієнт-сервер є моделлю організації комп'ютерних систем, де 
функції та завдання системи розділені між двома взаємодіючими типами 
комп'ютерів: клієнтами і серверами. Клієнти ініціюють запити до серверів для 
отримання ресурсів або послуг, тоді як сервери відповідають на ці запити, надаючи 
необхідні функції чи ресурси. 
Основні характеристики клієнт-серверної архітектури включають:  
- розподілена природа: клієнтські та серверні компоненти можуть 
знаходитися на різних фізичних пристроях або мережевих вузлах; 
-  зрізання функцій: клієнти та сервери виконують різні функції, ініціюючи 
або виконуючи запити відповідно;  
- асинхронність: взаємодія відбувається асинхронно, що дозволяє ефективно 
керувати ресурсами та забезпечувати реактивність системи; 
- масштабованість: система може бути легко масштабована, додаванням 
нових клієнтів чи серверів; 
- забезпечення послуг: сервери забезпечують ресурси чи послуги, а клієнти 
взаємодіють з ними, запитуючи чи використовуючи ці ресурси.  
Класичний приклад клієнт-серверної архітектури - це веб-сервер (сервер) і 
веб-браузер (клієнт), де браузери надсилають запити на сервер для отримання веб-
сторінок чи ресурсів. 
Поліагентний функціонал - набір функцій, які виконуються або 
обслуговуються агентами в інформаційній системі, побудованій на основі агентної 
архітектури. Агенти у такій системі представляють невеликі, автономні 
обчислювальні сутності, які діють від імені користувача чи системи, реагуючи на 
події та виконуючи завдання.  
Основні риси поліагентного функціоналу включають:  
10 
 
ЧДТУ.232229.021 ПЗ 
 
- автономія: агенти можуть діяти автономно, маючи внутрішні правила та 
стратегії прийняття рішень;  
- колективна діяльність: агенти можуть взаємодіяти та співпрацювати, 
об'єднуючи свої зусилля для виконання складних завдань; 
- самоорганізація: система може самоорганізовуватися за умови, що агенти 
можуть динамічно реагувати на зміни в середовищі чи завдання;  
- взаємодія з середовищем: агенти можуть взаємодіяти з іншими агентами, 
користувачами та середовищем, виконуючи визначені завдання;  
- підтримка завдань користувача: агенти можуть виконувати завдання 
відповідно до потреб користувача або системи;  
- функціональна спеціалізація: різні агенти можуть мати спеціалізовані 
функції або вміння для ефективного виконання конкретних завдань.  
Поліагентний функціонал широко використовується в галузях, де потрібна 
гнучкість, автономність та здатність до колективної діяльності, таких як 
інформаційні системи, штучний інтелект, автоматизовані системи управління та 
інші. 
1.2 Аналіз та моніторинг сучасних інформаційних систем з поліагентним 
функціоналом  
Аналіз та моніторинг сучасних інформаційних систем з поліагентним 
функціоналом є важливим завданням для забезпечення їх ефективності, безпеки та 
відповідності вимогам користувачів та ринку. Нижче подано основні аспекти, які 
можна розглядати при такому аналізі:  
- ефективність та продуктивність: оцінка швидкодії та продуктивності 
системи з поліагентним функціоналом. Вивчення часу відгуку, обсягів 
обробки даних та розподілення завдань між агентами;  
- безпека: аналіз системи на предмет вразливостей та заходів безпеки. 
Оцінка механізмів аутентифікації, авторизації та шифрування для захисту 
конфіденційності та цілісності даних;  
11 
 
ЧДТУ.232229.021 ПЗ 
 
- масштабованість: вивчення можливості системи масштабуватися для 
обробки зростаючої кількості користувачів, об'єму даних або великої 
кількості агентів;  
- взаємодія та співпраця агентів: дослідження механізмів взаємодії агентів 
між собою та їх співпраця. Оцінка ефективності механізмів комунікації та 
обміну інформацією;  
- функціональність: аналіз функціональності, яку надає система. Вивчення 
можливостей поліагентного функціоналу для оптимізації різних завдань та 
бізнес-процесів;  
- підтримка технологій та стандартів: перевірка, чи відповідає система 
актуальним технологіям та стандартам у галузі розробки програмного 
забезпечення та інформаційних технологій;  
- доступність та надійність: оцінка доступності системи та її надійності. 
Вивчення механізмів резервування, відновлення та управління помилками;  
- експлуатаційна простота та управління: дослідження, наскільки просто 
систему можна експлуатувати та управляти. Вивчення інтерфейсів 
управління та систем адміністрування;  
- задоволення вимог користувачів: оцінка того, наскільки система відповідає 
потребам та вимогам користувачів. Збір відгуків та аналіз їхнього впливу 
на подальший розвиток;  
- моніторинг та аналіз логів: розгляд системи моніторингу та аналізу логів 
для виявлення проблем, відслідковування дій користувачів та агентів.  
1.3 Види сучасних для інформаційних систем з поліагентним 
функціоналом 
Давайте розглянемо кілька прикладів сучасних клієнт-серверних архітектур 
для інформаційних систем з поліагентним функціоналом:  
- система онлайн-маркетплейсу: приклад: Amazon. У системі можуть діяти 
агенти, які відповідають за персоналізовані рекомендації товарів, 
12 
 
ЧДТУ.232229.021 ПЗ 
 
оптимізацію ціноутворення, та інші аспекти електронної комерції. Агенти 
можуть рекомендовувати продукти, а клієнт-серверна архітектура 
забезпечує обробку та виведення інформації про товари; 
- фінансова інформаційна система: приклад: Bloomberg Terminal. Агенти 
можуть використовуватися для збору та аналізу фінансової інформації, 
надання рекомендацій та автоматизації торгівельних операцій. Фінансові 
платформи для управління портфелями, де агенти допомагають в 
оптимізації інвестицій та прийнятті рішень; 
- система логістичного управління: приклад: UPS. Агенти можуть 
використовуватися для визначення оптимальних маршрутів доставки, 
оптимізації складського управління та координації логістичних процесів. 
Системи управління логістикою використовують агентів для оптимізації 
маршрутів, складського управління та координації транспортних засобів; 
- система управління здоров'ям: приклад: Cerner. Агенти можуть допомагати 
в управлінні електронними медичними записами, наданні рекомендацій 
щодо лікування та взаємодії з іншими медичними системами;  
- система розумного дому: приклад: Google Home. Агенти можуть 
використовуватися для керування побутовою технікою, освітленням, 
температурою, безпекою та іншими системами забезпечення комунікації 
між різними пристроями та надання інтелектуальних послуг;  
- онлайн-освітня платформа: приклад: edX. Агенти можуть надавати 
персоналізовані рекомендації для навчання, взаємодіяти з користувачами 
та оптимізувати процеси навчання, сприяють ефективній організації 
навчального процесу; 
- системи інтелектуальних транспортних систем (ITS): приклад - системи 
управління та моніторингу транспорту, де агенти допомагають в 
оптимізації трафіку, плануванні маршрутів та розподілі ресурсів; 
13 
 
ЧДТУ.232229.021 ПЗ 
 
- системи управління виробництвом: приклад - виробничі системи, де агенти 
використовуються для планування виробничих процесів, оптимізації 
ресурсів та вирішення проблем у виробництві.  
Ці приклади демонструють різноманітність застосування поліагентного 
функціоналу у різних галузях. У кожному випадку агенти можуть виконувати різні 
завдання для оптимізації та автоматизації процесів відповідно до конкретного 
контексту використання. 
1.4 Методи реалізації  сучасних інформаційних систем з поліагентним 
функціоналом. Огляд вимог і рішень 
Сучасні методи реалізації інформаційних систем з поліагентним 
функціоналом включають в себе різноманітні технології та підходи для 
забезпечення ефективної взаємодії та оптимізації функціональності агентів. Ось 
деякі з сучасних методів:  
- мультиагентні системи (MAS): опис: MAS використовуються для 
реалізації агентів, які можуть діяти автономно та співпрацювати для 
досягнення спільних цілей. Вони забезпечують ефективний спосіб 
моделювання складних систем з розподіленими агентами. Технології: 
JADE (Java Agent Development Framework), AgentSpeak, FIPA (Foundation 
for Intelligent Physical Agents) стандарти; 
- клієнт-серверні архітектури: опис: використання агентів для оптимізації 
взаємодії між клієнтами та серверами. Агенти можуть служити 
посередниками, полегшуючи комунікацію та обробку даних. Технології: 
сучасні мови програмування, такі як Java, Python, а також фреймворки для 
реалізації клієнт-серверних архітектур;  
- хмарні сервіси: опис: використання хмарних технологій для розгортання 
інформаційних систем з поліагентним функціоналом. Це дозволяє легко 
масштабувати та управляти агентами. Технології: Amazon Web Services 
14 
 
ЧДТУ.232229.021 ПЗ 
 
(AWS), Microsoft Azure, Google Cloud Platform, Docker для 
контейнеризації;  
- великі дані та аналітика: опис: використання агентів для обробки великих 
обсягів даних та забезпечення аналітичної функціональності. Технології: 
Apache Hadoop, Apache Spark, системи потокової обробки даних 
(наприклад, Apache Flink); 
- інтеграція API та Мікросервіси: опис: використання агентів для взаємодії з 
різними службами через API та реалізація мікросервісної архітектури. 
Технології: RESTful API, GraphQL, Docker та Kubernetes для оркестрації 
мікросервісів;  
- інтелектуальні системи та машинне навчання: опис: використання агентів 
для реалізації інтелектуальних функцій, таких як прийняття рішень на 
основі аналізу даних. Технології: Бібліотеки машинного навчання 
(наприклад, TensorFlow, PyTorch), інструменти для інтеграції 
інтелектуальних агентів.  
Ці методи можуть комбінуватися в залежності від конкретних вимог проєкту 
та вибору розробників. 
Поставлено задачі на дослідження: 
- аналіз існуючих досліджень з клієнт-серверної архітектури; 
- опис принципів роботи клієнт-серверної архітектури в контексті 
інформаційних систем; 
- розгляд інструментів та підходів до моделювання клієнт-серверних систем 
з поліагентним функціоналом; 
- aналіз проблем та викликів, пов'язаних із безпекою та масштабованістю 
такої архітектури. 
  
15 
 
ЧДТУ.232229.021 ПЗ 
 
Висновки до розділу 
У першому розділі проведено моніторинг та аналіз  різних сучасних реалізацій 
інформаційних систем з поліагентним функціоналом. Детальніше був розглянутий 
клієнт - серверний метод реалізації, тому що саме цей метод являється оптимальним 
для подальшої розробки  даної роботи, адже він покриває головні вимоги до 
подібних систем: 
- ефективність та продуктивність: оцінка швидкодії та продуктивності 
системи з поліагентним функціоналом. Вивчення часу відгуку, обсягів 
обробки даних та розподілення завдань між агентами;  
- безпека: аналіз системи на предмет вразливостей та заходів безпеки. 
Оцінка механізмів аутентифікації, авторизації та шифрування для захисту 
конфіденційності та цілісності даних;  
- масштабованість: вивчення можливості системи масштабуватися для  
обробки зростаючої кількості користувачів, об'єму даних або великої 
кількості агентів. 
Аналіз дозволив проаналізовані основні недоліки інших запропонованих 
програмних та інтерфейсних рішень. Насамперед, аналіз показав, що деякі системи 
мають проблеми з масштабованістю при великій кількості агентів, що може 
обмежити їх потенційне застосування в областях з високим обсягом даних та 
великою кількістю користувачів. Щодо інтерфейсів, деякі рішення мають недоліки 
у зручності використання та інтуїтивності, що ускладнює навігацію користувачів та 
може викликати труднощі в освоєнні системи. На позитивній ноті, виявлені недоліки 
визначають чіткі напрямки для подальших вдосконалень. Рекомендації включають 
в себе проведення додаткових досліджень з метою покращення масштабованості та 
стабільності систем, а також акцент на розробці користувацьких інтерфейсів, що 
враховують принципи безпеки, зручності та ергономіки. Подальші вдосконалення у 
цих аспектах покращать загальну ефективність та прийнятність інформаційних 
систем з поліагентним функціоналом у реальних умовах експлуатації.  
16 
 
ЧДТУ.232229.021 ПЗ 
 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1 Теоретичні дослідження клієнт-серверної архітектури 
Гіпотеза: "Під час роботи буде вивчено існуючі методи побудови самої 
архітектури,  обробки та передачі даних між клієнтом і сервером, а також аналіз 
засобів захисту від SQL-ін'єкцій. Окрема увага буде приділена важливості основ 
безпеки даних та відмінностям в їх обробці в різних типах клієнт-серверних систем, 
таких як веб-додатки. В результаті дослідження будуть запропоновані рекомендації 
для підвищення рівня безпеки в системах клієнт-серверної архітектури." 
Задачею дослідження є визначення ефективних засобів захисту від SQL-
ін'єкцій у системах клієнт-серверної архітектури.  
Отже, згідно із задачею дослідження, розглянемо принцип роботи клієнт-
серверної архітектури полягає у створенні доступу користувачів до баз даних, і в 
рамках багаторівневого подання систем для обчислення можна ідентифікувати три 
групи функцій, спрямованих на вирішення різних підзадач [5]: 
- функції введення і відображення даних, які забезпечують взаємодію з 
користувачем; 
- прикладні функції, бізнес логіка; 
- функції управління ресурсами.  
Виконання цих завдань головним чином реалізується за допомогою 
програмних ресурсів, які можна уявити у вигляді взаємопов'язаних 
компонентів (рис. 2.1), де: 
- компонент представлення відповідальний за користувальницький 
інтерфейс (presentation layer);  
- прикладний компонент реалізовує алгоритм вирішення конкретного 
поставленого завдання (application layer);  
- компонент управління ресурсами, забезпечує доступ до потрібних даних 
та ресурсів (data layer). 
17 
 
ЧДТУ.232229.021 ПЗ 
 
 Система, що працює в автономному режимі, тобто комп'ютер, який не 
з'єднаний з мережею, містить усі вказані компоненти на різних рівнях, включаючи 
рівень додатків. Аналогічно, коли ця система підключена до мережі, вона також 
включає всі вказані компоненти, але, в загальному випадку, ці компоненти 
розподілені між вузлами. Основним завданням є забезпечення мережевої взаємодії 
між цими компонентами [4]. 
 
 
Рисунок 2.1 – Компоненти клієнт-серверної архітектури 
 
Архітектура клієнт-сервер встановлює загальні принципи роботи та взаємодії 
вузлів у мережі, де сервери виконують певні функції, вузли відповідають за надання 
конкретних послуг, а клієнти використовують ці послуги. 
Зазвичай рівень користувацького інтерфейсу реалізується на пристроях 
користувачів. На цьому рівні розташовані програми, які дозволяють самому 
користувачеві взаємодіяти з додатком. Важливо відзначити, що додатки, які 
складають користувацький інтерфейс, можуть мати різний рівень складності. 
18 
 
ЧДТУ.232229.021 ПЗ 
 
2.1.1 Різновиди клієнт - серверної архітектури 
Однорівнева архітектура. Відмінність між однорівневою, дворівневою і 
трирівневою архітектурою залежить від способу поділу цих компонентів на частини. 
В однорівневій архітектурі всі вони є частинами одного програмного забезпечення. 
У дворівневій архітектурі ці компоненти розділені на дві окремі частини. У 
трирівневій архітектурі компоненти поділені на три окремі частини.  
Найбільш простий і перший використаний на практиці варіант клієнт-
серверної архітектури - це однорівнева архітектура (рис. 2.2). У цій архітектурі 
клієнт відображає лише інформацію, яка надходить від сервера, який несе всю 
обчислювальну навантаження [19]. 
 
 
Рисунок 2.2 – Однорівнева архітектура клієнт-сервер 
 
В якості прикладу цієї архітектури можна розглядати доступ до віддаленого 
сервера через термінал або віддалений робочий стіл. Централізована архітектура 
може вважатися окремим випадком однорівневої клієнт-серверної архітектури. 
Aрхітектура з виділеним сервером: 
У разі підключення до мережі більше ніж 10 користувачів, однорангова 
мережа, де комп'ютери виконують як роль клієнтів, так і серверів, може виявитися 
менш продуктивною. Тому більшість мереж використовують виділені сервери. 
19 
 
ЧДТУ.232229.021 ПЗ 
 
Виділені сервери функціонують виключно як сервери і оптимізовані для ефективної 
обробки запитів від мережних клієнтів та управління файлами і каталогами. Ці 
виділені сервери є стандартом у сучасних мережах, забезпечуючи централізоване 
сховище мережевих ресурсів і об'єднуючи централізоване забезпечення безпеки та 
управління доступом. На відміну від однорангових мереж, де відсутнє 
централізоване забезпечення безпеки та управління, сервери виступають як 
спеціалізовані системи, які надають послуги мережі іншим клієнтським 
комп'ютерам чи іншим процесам [13]. 
Кожна мережа з виділеним сервером також надає облікові записи для своїх 
клієнтів, включаючи їхні імена користувачів і паролі. Наприклад, операційна 
система Windows, зокрема NT, використовує концепцію доменної реалізації для 
управління клієнтами, групами та машинами, а також контролю над доступом до 
мережевих ресурсів. Перед тим як користувач матиме доступ до Інтернет-мережі, 
він повинен передати своє ім'я користувача та пароль серверу для перевірки 
відповідності імені та пароля в облікових записах контролера домену, який 
проводить перевірку у базі даних. Доступ до конкретних мережевих ресурсів буде 
наданий лише у випадку відповідності імені та паролю реєстрації, і тоді контролер 
домену встановить відповідні права. Лише адміністратор цієї мережі може внести 
зміни у цей процес. Цей підхід став популярним в корпоративних мережах, оскільки 
він забезпечує централізовану безпеку і надає можливість зміни контролю доступу 
та управління відповідно до потреб і важливості [11]. 
Дворівнева архітектура. У будь-якій сучасній мережі, яка використовує 
сучасні технології, присутні елементи взаємодії клієнт-сервер. З однорівневої 
архітектури вона еволюює в дворівневу, оскільки між клієнтом та сервером 
необхідно розподілити три основні компоненти: інтерфейс взаємодії з користувачем, 
бізнес-логіку та управління ресурсами (рис. 2.3). 
20 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 2.3 – Дворівнева архітектура клієнт-сервер 
 
У дворівневій архітектурі вона використовується у клієнт-серверних додатках, 
де сервер відповідає на клієнтські запити безпосередньо і в повному обсязі, 
використовуючи лише власні ресурси. Іншими словами, сервер не викликає сторонні 
мережеві програми і не звертається до сторонніх ресурсів для виконання будь-якої 
частини запиту [13]. 
В рамках дворівневої архітектури важливу роль відіграє розташування 
компонентів як на стороні клієнта, так і на стороні сервера, визначаючи основні 
моделі їх взаємодії. З удосконаленням та впровадженням на рівні сервера бази 
даних, з'явилася нова концепція, відома як активний сервер баз даних. У цій 
реалізації частина функціональної реалізації прикладного компонента виконується 
у вигляді збережених процедур, які виконуються на серверній стороні. Інша 
прикладна логіка реалізується на стороні клієнта. Протокол взаємодії між ними 
відповідає відповідному діалогу мови SQL. 
Переваги такого підходу: 
- здатність до централізованого адміністрування прикладного програмного 
інтерфейсу; 
- зменшення витрат на систему за рахунок використання сервера в режимі 
тимчасового обігу, замість його придбання; 
21 
 
ЧДТУ.232229.021 ПЗ 
 
- суттєве зменшення обсягу трафіку в мережі, оскільки передаються лише 
виклики збережених процедур.  
Недоліки такого підходу: 
- управління цією системою потребує від кваліфікованого фахівця; 
- відмова сервера може призвести до непрацездатності всієї обчислювальної 
мережі; 
- бізнес-логіка додатків залишається в програмному забезпеченні клієнта; 
- високовартісне обладнання. 
Багаторівнева архітектура. Багаторівнева архітектура є варіацією клієнт-
серверної архітектури, в якій обробка даних відбувається на одному або кількох 
окремих серверах. Це дозволяє розподіляти функції зберігання, обробки і 
відображення даних для більш ефективного використання ресурсів як серверів, так 
і клієнтів. Ця архітектура також відзначається зростанням використання систем для 
розподілених обчислень. Реалізація цих систем відбувається на частині сервера, де 
додаток, який знаходиться у мережі, розподіляється на кілька розділів, кожен з яких 
може бути реалізований на окремих вузлах. У багаторівневій архітектурі клієнт-
сервер найпоширенішою є трирівнева архітектура. Виділені частини додатків 
взаємодіють одна з одною, обмінюючись повідомленнями та даними у заздалегідь 
визначеному форматі. [14] У цьому випадку дворівнева клієнт-серверна архітектура 
переходить до трирівневої (рис. 2.4). 
 
 
Рисунок 2.4 – Трирівнева архітектура клієнт-сервер 
22 
 
ЧДТУ.232229.021 ПЗ 
 
Зазвичай у трирівневій архітектурі третій рівень виконує роль сервера 
додатків. Таким чином, компоненти можуть бути розподілені за наступною схемою: 
- oбробка та відображення даних відбуваються повністю на стороні клієнта; 
- прикладний компонент виконується на виділеному сервері додатків; 
- керування ресурсами здійснюється на сервері бази даних, який надає 
необхідні дані для відповіді. 
Переваги такого підходу: 
- масштабованість і розподіленість; 
- високий рівень безпеки, оскільки можна встановити власний принцип 
захисту на кожному рівні; 
- високу продуктивність, оскільки всі завдання розподіляються. 
Недоліки такого підходу: 
- високі вимоги до швидкості каналу; 
- збільшена складність розробки додатків; 
- збільшена складність у впровадженні та адмініструванні; 
- значніі вимоги до продуктивності серверів додатків та сервера бази даних, 
що призводить до високої вартості серверного обладнання. 
Трирівнева архітектура може бути розширена до багаторівневої шляхом 
введення додаткових серверів для кожного рівня. Кожен із цих серверів 
представлятиме свої власні сервіси та надасть можливість користувачам 
скористатися послугами інших серверів на різних рівнях. [3]  
Абстрактний приклад багаторівневої моделі клієнт-сервер представлений на 
риcунку 2.5. 
 
 
Рисунок 2.5 –  Багаторівнева архітектура клієнт-сервер 
23 
 
ЧДТУ.232229.021 ПЗ 
 
Щоб уникнути різних проблем, пов'язаних з елементами архітектури, можна 
проводити обробку та синтез даних на одній із сторін - на сервері. Це призводить до 
виникнення двох концепцій: "тонкий" клієнт, коли обробка відбувається на сервері, 
і "товстий" клієнт, коли частина обробки відбувається на стороні клієнта. Кожен з 
цих підходів має свої плюси та мінуси. В разі "товстого" клієнта може виникнути 
проблема зайвої навантаженості мережі, оскільки передається необроблена 
інформація, тобто зайві дані. Крім того, обслуговування такої системи та її 
оновлення може бути складними, оскільки зміни в алгоритмі обчислень чи 
виправлення помилок можуть вимагати повної заміни інтерфейсного обладнання, 
що призводить до можливих серйозних проблем. З іншого боку, використання 
"тонкого" клієнта, де вся обробка відбувається на сервері, може викликати проблеми 
з описом та налагодженням вбудованих процедур. Оскільки мова реалізації 
вбудованих процедур часто є декларативною, це може ускладнити покрокове 
налагодження. Перенесення системи з обробкою інформації на сервері на іншу 
платформу також може стати серйозним недоліком такої архітектури [19]. 
Більшість сучасних інструментів швидкої розробки додатків (RAD), які 
взаємодіють з різними базами даних, реалізують першу стратегію, а саме "товстий" 
клієнт, який забезпечує взаємодію з сервером бази даних за допомогою вбудованого 
SQL. Такий спосіб реалізації системи з "товстим" клієнтом, окрім вищезазначених 
недоліків, часто призводить до неприпустимо низького рівня безпеки. Крім того, 
перехід цієї системи на веб-технології практично неможливий через використання 
спеціалізованого клієнтського програмного забезпечення для доступу до сервера 
бази даних [3]. 
Тонкі клієнти – це компактні пристрої без внутрішніх жорстких дисків, 
обчислювальна потужність та обсяг пам'яті яких залежать від завдань користувача. 
Ці пристрої підключаються до серверів для виконання обчислювальних завдань та 
використання протоколів віддаленого відображення для доступу до жорстких 
дисків, розташованих у захищених центрах обробки даних. Технологія тонкого 
клієнта-сервера базується на трьох основних складових:  
24 
 
ЧДТУ.232229.021 ПЗ 
 
- стовідсоткове виконання прикладних завдань на термінальному сервері; 
- операційна система, розрахована на багато користувачів;  
- технологія розподіленого відображення для надання користувачеві 
інтерфейсу додатків. 
Клієнти можуть одночасно увійти в систему та запускати програми на сервері 
в різних, взаємно захищених сесіях сервера. У системі, яка використовує тонкий 
клієнт через мережу або при віддаленому підключенні до сервера, передаються 
сигнали від клієнта, які відображають натискання клавіш або рухи миші. Сервер 
виконує відповідні дії, формує відповідь та внесені зміни для екрану користувача, 
які потім передаються тонкому клієнту (рис. 2.6). 
По-перше, ця технологія є ефективним інструментом для заміни персональних 
комп'ютерів, що сприяє миттєвому доступу до віртуальних робочих станцій та 
програм, а також надає централізовані можливості обчислювальної техніки. 
Оновлення програмного забезпечення та зміни програм можна легко виконати в 
центрі обробки даних. Продуктивність робочого місця зростає, оскільки ІТ-
командам не потрібно вирішувати проблеми на місці робочого столу кінцевого 
користувача. Крім того, централізована система резервного копіювання для робочих 
станцій та пристроїв доступу клієнтів спрощує завдання адміністратора [14]. 
Користувачі не мають можливості копіювати інформацію на свій диск або 
зберігати її в інших місцях, окрім сервера. Встановлення несанкціонованого 
програмного забезпечення або програм на особистих пристроях неможливе, що 
захищає компанії від атак зловмисного програмного забезпечення та спроб 
порушення даних. Все це сприяє захисту інтелектуальної власності та забезпечує 
конфіденційність даних. У виборі пристроїв ідеально враховувати ті, які 
використовують операційну систему на базі Linux і автоматично отримують 
рекомендовані оновлення безпеки. Оскільки Linux вважається однією з найбільш 
орієнтованих на безпеку операційних систем на ринку, такі пристрої стають менш 
вразливими до можливих підробок. 
25 
 
ЧДТУ.232229.021 ПЗ 
 
Ці тонкі клієнти представляють найбільш доступні та екологічно стійкі 
рішення на сучасному етапі. Зазначено, що ця технологія є обчислювальною 
моделлю, заснованою на сервері, що призводить до зниження вартості обладнання. 
У цьому варіанті програми запускаються на віддаленому сервері та відображаються 
на настільних пристроях. Користувачі можуть отримати доступ до набору програм з 
будь-якого пристрою, підключеного до сервера, і це не вимагає встановлення 
додатків на окремих пристроях за допомогою ІТ [18]. 
Крім того, при наявності обмежених рухаючихся деталей, обмеженої пам'яті 
та мікропроцесорних можливостей, цей пристрій споживає приблизно 8-20 Вт, що 
значно менше, ніж ПК, який може працювати від 170 Вт до 800 Вт. Такий підхід 
різко знижує викиди вуглецю, і компанії можуть реінвестувати економію витрат на 
електроенергію в інших напрямках. 
 
Рисунок 2.6 – Принцип роботи тонкого клієнту 
 
26 
 
ЧДТУ.232229.021 ПЗ 
 
 Тонкі клієнти стають ефективним рішенням для досягнення рівномірності на 
робочому столі в організації. Для багатьох підприємств важко забезпечити однакові 
конфігурації обладнання, навіть якщо постачальник може задовольнити їхні потреби 
для кількох одиниць. Уявіть сценарій, де існує 30 різних зображень, що охоплюють 
355 настільних комп'ютерів та 78 серверів від чотирьох різних постачальників. 
Використання тонких клієнтів спрощує цю ситуацію, дозволяючи розповсюджувати 
універсальне зображення робочого столу через мережу. Це також вирішує проблему 
вибору окремих конфігурацій, навіть у випадку, коли користувач використовує 
відносно унікальний жорсткий диск чи графічний адаптер.[7] 
Переваги використання тонких клієнтів включають:  
- уніфікація пристроїв: Усі клієнти об'єднують однаковий набір 
програмного забезпечення;  
- зниження витрат: Мінімальні вимоги до конфігурації призводять до 
зниження початкових витрат на придбання;  
- енергоефективність: Типовий тонкий клієнт відрізняється низьким 
споживанням енергії;  
- простота реалізації завдань: Централізоване управління клієнтами усуває 
необхідність налаштовування кожного комп'ютера окремо;  
- економія часу системного адміністратора: Обслуговування однакових 
комп'ютерів зменшує ймовірність поломок, а всі програми встановлені на 
сервері;  
- захист від витоків інформації;  
- масштабованість: Один раз створений образ системи для всієї групи 
користувачів дозволяє ефективно масштабувати мережу.  
Недоліки технології тонких клієнтів головним чином пов'язані з високими 
вимогами до сервера та вартістю серверного обладнання: 
- висока вартість термінального сервера;  
27 
 
ЧДТУ.232229.021 ПЗ 
 
- залежність від доступу до Інтернету;  
- вимоги до високої швидкості мережевого каналу. 
Товстий клієнт, навпаки, виконує основну частину обробки в програмах 
клієнт-сервер. У відміну від тонкого клієнта, товстому клієнту не потрібна постійна 
взаємодія з сервером, оскільки він переважно передає серверу інформацію для 
архівного зберігання. Термін "товстий клієнт" часто використовується як вказівка на 
програмне забезпечення, але також може вказувати на сам мережевий комп'ютер. У 
випадку, якщо вашим програмам необхідні мультимедійні компоненти або велика 
пропускна здатність, розгляд можливості використання товстих клієнтів також є 
важливим [19]. Однією з основних переваг товстих клієнтів є можливість впоратися 
з операційними системами та програмним забезпеченням, які неспроможні 
працювати на тонких клієнтах, оскільки товстий клієнт має власні ресурси (рис. 2.7). 
 
Рисунок 2.7 – Приклад роботи тонкого і товстого клієнту  
 
 Також, у наш час, все частіше використовується ще один термін, який 
називається "rich-клієнт". Розробники rich-клієнтів виявили компроміс між товстим 
і тонким клієнтом. Схожий на тонкий клієнт, rich-клієнт також включає графічний 
інтерфейс, який описується за допомогою мови розмітки XML і має деяку 
28 
 
ЧДТУ.232229.021 ПЗ 
 
функціональність, що характерна для товстих клієнтів, таку як інтерфейс, вкладки, 
множинні вікна та випадаючі меню [6].  
Прикладна логіка цих клієнтів, подібно до тонких клієнтів, реалізована на 
сервері. Весь обмін даними відбувається у стандартному форматі, базуючись на 
XML та використовуючи стандартні протоколи, і потім відображається на 
клієнтському обладнанні. 
Переваги використання товстих клієнтів:  
- більш багата функціональність в порівнянні з тонкими клієнтами;  
- можливість багатокористувальської роботи;  
- здатність до роботи навіть без доступу до Інтернету;  
- швидка робота інтерфейсу. 
Недоліки використання товстих клієнтів:  
- великий розмір дистрибутиву; 
- складність встановлення і налаштування;  
- складність оновлення системи на стороні клієнта;  
- можливість застарівання даних до проведення оновлень. 
Модель клієнт-сервер у мережі охоплює різні служби Інтернету, такі як 
сервери баз даних (наприклад, FTP) або веб-сервери, які надають послуги відповідно 
до концепції клієнт-сервер. Клієнт і сервер взаємодіють через різні протоколи, такі 
як SMTP, FTP, HTTP і інші, але процес взаємодії залишається аналогічним: клієнт 
ініціює запит, сервер обробляє його і, за необхідності, надсилає відповідь клієнту. 
Цей процес може повторюватися кілька разів або виконуватися одноразово [18].  
Для взаємодії клієнта і сервера за протоколом HTTP (рис. 2.8), на сервері 
повинен бути встановлений веб-сервер, а на комп'ютері користувача – клієнт, 
наприклад, веб-браузер. Процес починається з введення користувачем URL-адреси 
в адресному рядку браузера. Коли користувач натискає Enter, браузер перевіряє 
наявність домену з введеним ім'ям. Якщо домен існує, браузер отримує IP-адресу 
сервера, пов'язаного з цим доменом, і відправляє HTTP-запит на цей сервер. У цьому 
запиті браузер вказує домен, кукі, свою назву, бажані формати даних і інші 
29 
 
ЧДТУ.232229.021 ПЗ 
 
параметри. Сервер отримує ці дані і на їхній основі формує відповідь, що містить 
заголовки відповіді та тіло у форматі JSON. Клієнт отримує цю інформацію і 
виводить її на екран користувача [19]. 
 
Рисунок 2.8 – Взаємодія клієнта і сервера по HTTP 
 
 Найважливішою особливістю обчислювальної моделі клієнт-сервер є розподіл 
прикладних завдань між клієнтами і серверами. У загальному випадку цей розподіл 
представлений на рисунку 2.5. Як для клієнтів, так і для серверів, базовим 
програмним забезпеченням є операційна система. Важливо зауважити, що апаратні 
платформи і операційні системи клієнтів та серверів можуть відрізнятися. Фактично, 
в єдиному оточенні можуть використовуватися різні типи клієнтських і серверних 
платформ і операційних систем. Однак ці відмінності не мають значення, якщо 
сервер і клієнт використовують одні й ті самі комунікаційні протоколи і 
підтримують однакові додатки [18].  
Взаємодія між клієнтом і сервером реалізується за допомогою 
комунікаційного програмного забезпечення, такого як, наприклад, набір протоколів 
TCP/IP згідно з протоколами OSI та різні фірмові архітектури, як показано на 
рисунку 2.9. 
Додатки з архітектурою клієнт-сервер, такі як веб-сервери чи браузери, 
використовують стек протоколів TCP/IP для обміну даними. Ці інтернет-додатки 
здійснюють обмін даними у мережах TCP/IP, використовуючи інтерфейс сокетів. 
Інтерфейс сокетів реалізований з бібліотек стандартних програм, які розробник 
30 
 
ЧДТУ.232229.021 ПЗ 
 
додатку може використовувати для розробки додатків, здатних взаємодіяти та 
обмінюватися даними з іншими додатками через Інтернет [2]. 
 
Рисунок 2.9 – Клієнт-сервер в моделі OSI 
 
Додатки з архітектурою клієнт-сервер, такі як веб-сервери чи браузери, 
використовують стек протоколів TCP/IP для обміну даними. Ці інтернет-додатки 
здійснюють обмін даними у мережах TCP/IP, використовуючи інтерфейс сокетів. 
Інтерфейс сокетів реалізований з бібліотек стандартних програм, які розробник 
додатку може використовувати для розробки додатків, здатних взаємодіяти та 
обмінюватися даними з іншими додатками через Інтернет [2]. 
Процес обміну даними між додатками клієнт-сервер за допомогою стеку 
протоколів TCP/IP включає наступні етапи:  
- cтворення сокету: якщо сокет ще не існує, виконується створення нового 
сокету;  
- прив'язка IP-адреси і порта до сокету: сокет пов'язується з конкретною IP-
адресою та портом, що дозволяє іншим додаткам знаходити його в мережі.  
- пошук запитів на з'єднання (для сервера): якщо додаток виступає у ролі 
сервера, він очікує запитів на з'єднання використовуючи потоковий сокет.  
- встановлення з'єднання (для клієнта): якщо додаток виступає у ролі 
клієнта, він встановлює з'єднання з сервером, використовуючи потоковий 
сокет.  
31 
 
ЧДТУ.232229.021 ПЗ 
 
- обмін даними: після встановлення з'єднання, клієнт та сервер обмінюються 
даними через відкритий сокет.  
- закриття сокету: після завершення обміну даними сокет закривається, щоб 
звільнити ресурси.  
Цей процес дозволяє ефективно взаємодіяти між клієнтським і серверним 
додатком у мережевому середовищі, використовуючи стек протоколів TCP/IP [18].  
Розглянувши всі переваги та недоліки можливих комбінацій, було вирішено 
використовувати  багаторівневу клієнт-серверну  архітектуру на основі принципу 
роботи тонкого клієнту, що має забезпечити достатній рівень ефективності та 
продуктивності, безпеки та масштабованості системи. 
2.1.2 Дослідження та аналіз основних вразливостей системи 
Із трьох основних вимог до клієнт-серверної архітектури для ІС з 
поліагентним функціоналом, які були обгрунтовані у першому розділі, основною є 
вимога забезпечення захисту даних та безпеки обміну даними. Критичним є 
завданням для забезпечення конфіденційності, цілісності та доступності інформації.  
Ось кілька шляхів захисту даних у серверній архітектурі, разом із зазначенням 
деяких ключових формул:  
Шифрування даних в стані спокою та в руху: захист даних в спокої (дані на 
сервері): використовується шифрування для захисту збережених даних на сервері:  
 
                   EncryptedData = Encrypt(Data, Key) (2.1) 
 
Захист даних в русі (передача даних між клієнтом і сервером): використовуйте 
SSL/TLS для шифрування трафіку: 
  
             EncryptedTransmission = Encrypt(Data, SSL/TSL Key) (2.2) 
 
У даній роботі реалізовано захищення каналу обміну даними між сервером 
PostgreSQL і базою даних за допомогою TLS (Transport Layer Security) сертифікату. 
32 
 
ЧДТУ.232229.021 ПЗ 
 
Використання захищеного з'єднання є важливим для забезпечення конфіденційності 
та цілісності даних, які передаються між сервером та базою даних. Ймовірність 
взлому сайта без TLS (Transport Layer Security) може бути визначена за допомогою 
різних факторів, таких як рівень безпеки, вразливості, доступність заходів захисту 
та інші. Загальна формула може виглядати приблизно так: 
 
�� = Кількість	вразливостей
взлому	без	*+, 	× 	Ступінь	експлуатованості          (2.3) 
Загальна	кількість	запитів
 
де: 
 ��взлому	без	*+, - ймовірність взлому сайту без використання TLS.  
Кількість	вразливостей - кількість вразливостей в системі.   
Загальна	кількість	запитів - загальна кількість атак, які можуть бути 
виконані на сайті.  
Ступінь	експлуатованості - ймовірність успішного використання SQL-
ін'єкцій, що може залежати від рівня безпеки, знань атакуючого і т.д. 
Кроки для використання TLS в PostgreSQL:  
- підготовка сертифікатів: згенеровані сертифікати для сервера та клієнта. 
(використовувався інструмент OpenSSL для створення самопідписаних або 
підписаних сертифікатів) 
- конфігурація PostgreSQL: внесено зміни у файл конфігурації PostgreSQL 
(зазвичай postgresql.conf). Встановлено параметри, пов'язані з TLS, такі як 
ssl, ssl_cert_file, ssl_key_file, ssl_ca_file. 
ssl = on 
ssl_cert_file = '/path/to/server.crt' 
ssl_key_file = '/path/to/server.key' 
ssl_ca_file = '/path/to/root.crt' 
Використання механізмів аутентифікації: використання токенів, двофакторної 
аутентифікації і т. д.  
 
             AuthenticationToken = GenerateToken(UserCredentials) (2.4) 
33 
 
ЧДТУ.232229.021 ПЗ 
 
 
Основні кроки включають в себе використання Firebase для аутентифікації та 
отримання JWT токена, який потім передається на бекенд для подальшої авторизації. 
Цей токен включений у кожен HTTP запит до бекенду у заголовку Authorization. 
Бекенд отримує JWT токен від клієнта при кожному запиті. Він перевіряє підпис та 
достовірність токена за допомогою публічного ключа Firebase. Якщо токен 
валідний, бекенд дозволяє доступ до ресурсів або виконання операцій, інакше 
відправляє відповідь з помилкою авторизації. JWT токен має обмежений термін дії 
(на даному етапі встановлено 1 година).  
Захист від SQL-ін'єкцій: використання формул ймовірності використання 
SQL-ін'єкцій, які допомагають оцінити, враховуючи різні фактори, такі як рівень 
безпеки системи, вплив введеного користувача на запит та інші обставини. Зазвичай, 
ймовірність визначається у контексті конкретного додатку або веб-сайту.  
Ось загальна формула, яка може бути використана для оцінки ймовірності 
виникнення SQL-ін'єкцій:параметризованих запитів для запобігання SQL-ін'єкціям: 
 
					�� Кількість	вразливостей
,;+	ін!єкції = 	× 	Ступінь	експлуатованості  (2.5) 
Загальна	кількість	запитів
 
де: 
 ��,;+	ін!єкції - ймовірність виникнення SQL-ін'єкцій.  
Кількість	вразливостей - кількість місць, де можливі SQL-ін'єкції.   
Загальна	кількість	запитів - загальна кількість SQL-запитів, які 
обробляються системою.  
Ступінь	експлуатованості - ймовірність успішного використання SQL-
ін'єкцій, що може залежати від рівня безпеки, знань атакуючого і т.д. 
Ймовірність CSRF (Cross-Site Request Forgery) атаки визначається: 
 
							�� = Кількість	вразливостей
?,@A 	× 	Ступінь	експлуатованості   (2.6) 
Загальна	кількість	запитів
34 
 
ЧДТУ.232229.021 ПЗ 
 
де: 
 ��?,@A - ймовірність виникнення CSRF-атаки.  
Кількість	вразливостей - кількість місць, де можливі CSRF-атаки.   
Загальна	кількість	запитів - загальна кількість HTTP-запитів, які 
обробляються системою.  
Ступінь	експлуатованості - ймовірність успішного використання CSRF-атак, 
що може залежати від рівня безпеки, знань атакуючого і т.д. 
Боротьба з SQL-ін’єкціями - досить об’ємний етап роботи. Детально буде 
розглянутий у пункті “Експерементальні дослідження”. 
Захист від атак на переповнення буфера: валідація та обмеження введених 
даних для запобігання переповнення буфера. 
 
ValidateInput (Input) (2.7) 
 
Всі дані, які вводяться користувачем, валідуються, зокрема, електроннa поштa 
та пароль, щоб уникнути введення некоректних або зловмисних даних. 
 
Захист від вразливостей веб-додатків: Використання механізмів захисту, 
таких як виявлення та захист від атак Cross-Site Scripting (XSS) та Cross-Site Request 
Forgery (CSRF) 
 
                                            SanitizeInput(Input)  (2.8) 
 
Для вирішення таких вразливостей було вирішено використовувати 
фреймворк VueJS, який має вбудовані заходи безпеки і використовує виведення в 
безпечному форматі. Також всі форми на створення здійснюються за допомогою 
запиту POST a оновлення за допомогою запиту PATH. 
35 
 
ЧДТУ.232229.021 ПЗ 
 
2.2 Експериментальні дослідження 
Після проведення теоретичних досліджень постало питання налагодження 
процесу забезпечення безпеки даних, які здаходяться в БД.  
 Найбільш “слизьким” і вразливим до SQL-ін'єкцій місцем в БД є таблиця 
“Project”, де зберігаються всі проєкти користувачів. 
 SQL-ін'єкція — це тип атаки на безпеку, коли зловмисник використовує 
некоректно оброблені SQL-запити для отримання несанкціонованого доступу до 
бази даних. Ця проблема може виникнути як у клієнтському коді, так і у серверному 
коді. 
 
import { getConnection } from 'typeorm'; 
 
const id = "19a656d0-92e3-4dab-90d1-98fbf954892f' OR '1'='1"; 
const query = `SELECT * FROM project WHERE id = '${id}'`; 
const result = await getConnection().query(query); 
 
У наведеному коді є потенційна вразливість до SQL ін'єкцій. Проблема 
полягає в тому, що дані введені користувачем (IdInput) не екрануються чи не 
параметризуються перед використанням у SQL-запиті. Це може призвести до 
небажаних наслідків, якщо користувач вводить дані з метою виконання SQL-коду.  
Після інтерпретації попередній SQL-запит буде виглядати наступним чином: 
 
SELECT * FROM project  
WHERE id='19a656d0-92e3-4dab-90d1-98fbf954892f' OR '1'='1'; 
 
Це призвело до вибору всіх проєктіву таблиці, оскільки умова '1'='1' завжди 
істинна. 
[ 
  { 
    "id": "19a656d0-92e3-4dab-90d1-98fbf954892f", 
36 
 
ЧДТУ.232229.021 ПЗ 
 
    "name": "Object 1", 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672531199, 
    "updatedAt": 1672531299, 
    "deletedAt": null, 
    "createdById": "a05a83e5-820d-4b06-9f77-3a9a2ebc4c82", 
    "updatedById": "a05a83e5-820d-4b06-9f77-3a9a2ebc4c82" 
  }, 
  { 
    "id": "2a8b695b-29d7-4a8e-8c3a-5c82561a1c72", 
    "name": "Object 2", 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672532399, 
    "updatedAt": 1672532499, 
    "deletedAt": null, 
    "createdById": "9f0a746f-6223-4c9a-8a82-cd44c8a5a193", 
    "updatedById": "9f0a746f-6223-4c9a-8a82-cd44c8a5a193" 
  }, 
  { 
    "id": "3e4a3ec2-26f1-4e20-a3c5-156b53f13b57", 
    "name": "Object 3", 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672533599, 
    "updatedAt": 1672533699, 
    "deletedAt": null, 
    "createdById": "30bf256d-950d-4cb8-aeb2-8306d23c1f45", 
    "updatedById": "30bf256d-950d-4cb8-aeb2-8306d23c1f45" 
  }, 
  { 
    "id": "4f40d983-5f04-4f62-8fb8-8c7bf673799f", 
    "name": "Object 4", 
37 
 
ЧДТУ.232229.021 ПЗ 
 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672534799, 
    "updatedAt": 1672534899, 
    "deletedAt": null, 
    "createdById": "90e88962-bb86-4f61-bd95-8132f9cfb368", 
    "updatedById": "90e88962-bb86-4f61-bd95-8132f9cfb368" 
  }, 
  { 
    "id": "5ec8efb4-9a33-4c8e-90f5-4d71d0c72c4c", 
    "name": "Object 5", 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672535999, 
    "updatedAt": 1672536099, 
    "deletedAt": null, 
    "createdById": "e3c15939-7a0e-4f37-8b7d-1ebc571c39e5", 
    "updatedById": "e3c15939-7a0e-4f37-8b7d-1ebc571c39e5" 
  }, 
  { 
    "id": "6d82db0b-e2fe-4a23-8bf8-05c0e9a63b88", 
    "name": "Object 6", 
    "data": {"key1": "value1", "key2": "value2"}, 
    "columns": {"column1": "value1", "column2": "value2"}, 
    "inoutIndexes": {"index1": "value1", "index2": "value2"}, 
    "outputIndexes": {"output1": "value1", "output2": "value2"}, 
    "options": {"option1": "value1", "option2": "value2"}, 
    "createdAt": 1672537199, 
    "updatedAt": 1672537299, 
    "deletedAt": null, 
    "createdById": "7c16839e-eb38-41b5-8b0f-ae991f6a965a", 
    "updatedById": "7c16839e-eb38-41b5-8b0f-ae991f6a965a" 
  }, 
] 
 
38 
 
ЧДТУ.232229.021 ПЗ 
 
Для захисту від SQL ін'єкцій було вирішено використовувати параметризовані 
запити. Ось приклад з використанням параметризованого запиту з TypeORM, який є 
ORM (Object-Relational Mapping) для TypeScript та JavaScript, надає безпечний 
спосіб взаємодії з базою даних та вбудовані механізми захисту від SQL-ін'єкцій. 
введемо аналогічний SQL-запит:  
const id = '19a656d0-92e3-4dab-90d1-98fbf954892f' OR '1'='1'; 
const result = await getConnection() 
  .createQueryBuilder() 
  .select() 
  .from('projects') 
  .where('id = :id', { id }) 
  .getMany(); 
 
Запит інтерпретується наступним чином 
SELECT * FROM project  
WHERE id='19a656d0-92e3-4dab-90d1-98fbf954892f\'  
OR \'1\'=\'1'; 
 
В результаті даного запита нам повернувся пустий масив: 
[] 
Розглянемо детальніше інші типи SQL-ін’єкцій. Вони представлені у таблиці 
2.2. 
Таблиця 2.2 
Порівняльна таблиця можливих ін’єкцій 
Тип SQL-
ін'єкції Приклад Наслідки Вразливість Заходи захисту 
SELECT * FROM 
Одинарна users WHERE ' OR '1'='1' -- може Недостатня Використання 
username = 'admin' призвести до отримання обробка введених параметризованих 
кавичка AND password = всієї таблиці users. даних у SQL-запиті запитів, валідація 
'1234'; даних 
SELECT 
username, email ' UNION SELECT null, Невірне Використання 
Union- FROM users table_name FROM оброблення параметризованих 
ін'єкція WHERE username information_schema.table конкатенації в запитів, обмеження 
= 'admin'; s SQL-запиті прав доступу 
 
39 
 
ЧДТУ.232229.021 ПЗ 
 
Продовження таблиці 2.2 
SELECT * FROM ' OR IF(1=1, SLEEP(5), 
users WHERE 0) -- може Невірне Використання 
Time-based username = 'admin' використовувати використання параметризованих 
Blind AND password = затримку для рядка в умовах запитів, обмеження 
'1234'; визначення правдивості SQL-запиту часових операцій 
умови. 
INSERT INTO 
Системна users (username, ' ; DROP TABLE users; - Використання Використання 
введених даних для параметризованих 
команда password) - може викликати 
VALUES ('admin', видалення таблиці users. виконання команд запитів, обмеження 
'1234'); системи прав доступу 
SELECT * FROM Використання 
Out-of- users WHERE Ін'єкція з Використання 
username = 'admin' використанням DNS- інших каналів параметризованих 
Band запитів, використання 
AND password = запитів або інших комунікації з 
'1234'; мережевих засобів. атакуючим безпечних каналів 
зв'язку 
 
У цій оновленій таблиці Стовпець "Вразливість" вказує на конкретні аспекти 
системи, які стають джерелом вразливостей для кожного типу SQL-ін'єкції. 
Стовпець "Заходи захисту" надає загальні заходи безпеки, які можуть бути прийняті 
для запобігання або мінімізації можливих атак. 
В результаті проведення експериментального дослідження було проведено 
оптимізацію запитів для забезпечення безпеки даних та захисту від SQL-ін’єкцій. 
TypeORM підходить для реалізації у зв’зку з підтримкою PostgreSQL, яку було 
обрано як СУБД. Оптимізація запитів може великою мірою вплинути на 
продуктивність.  
  
40 
 
ЧДТУ.232229.021 ПЗ 
 
Висновки до розділу 
На основі проведеного дослідження та сформованих вимог було прийнято 
рішення розробити багаторівневу клієнт-серверну архітектуру з тонким клієнтом 
для клієнт-серверної архітектури для ІС з поліагентним функціоналом. Це 
архітектурне вирішення обрано через його спроможність забезпечити максимальну 
гнучкість та швидкість впровадження змін, а також його високий потенціал 
масштабування.  
При такій архітектурі можна використовувати оптимальні підходи 
“спілкування” між різними модулями системи, що дозволяє зменшити пряму 
взаємодію агентів із ядровим сервісом і надає системі більшу гнучкість та 
масштабованість. 
Також у розрізі проведення експерементальних досліджень було проведено 
аналіз та оптимізацію запитів для забезпечення максимальної безпеки даних в БД та 
підвищення загальної продуктивності системи. 
  
41 
 
ЧДТУ.232229.021 ПЗ 
 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЬ У 
ПРАКТИКУ ТА ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
3.1 Моделювання предметної області 
Створення моделі інформаційної системи є одним із ключових та 
ресурсомістких етапів. Ця модель може бути відображена у вигляді візуального 
представлення концептуальних класів чи об'єктів, що існують у конкретній 
предметній області.  
3.1.1 Модель предметної області 
Першим пунктом моделювання системи є створення візуальної моделі, яка 
сприятиме кращому розумінню розроблюваної системи та допоможе вирішити 
складні завдання у її побудові.  
За допомогою моделі предметної області можна виявити та проаналізувати 
труднощі у реалізації системи, які на перший погляд можуть здатися простими. 
Моделювання предметної області клієнт-серверної архітектури для ІС з 
поліагентним функціоналом включає розробку абстракційної репрезентації 
взаємодії та взаємозв'язків між клієнтами та серверами у системі.  
 
Рисунок 3.1 – Загальна схема функціонування системи 
 
42 
 
ЧДТУ.232229.021 ПЗ 
 
На рисунку 3.1 відображена схема функціонування системи в цілому. Вона 
описує матеріали, стандарти та дані, що використовуються та оброблюються 
системою загалом. Перша стрілка показує вхідні дані системи, а саме вхідні дані для 
проєкту. Остання стрілка результат роботи системи – оцифровані дані для 
користувача.  
3.1.2 Словник предметної області 
 Словник предметної області для клієнт-серверної архітектури з поліагентним 
функціоналом:  
Клієнт-серверна архітектура: Модель взаємодії, де є розподілений обмін 
інформацією між клієнтами і серверами. Клієнти ініціюють запити, а сервери 
надають відповіді.  
Поліагентний функціонал: Система, яка має агенти - автономні 
обчислювальні сутності, що діють в інтересах користувача або системи в цілому.  
Агент: Автономний суб'єкт, обладнаний власною логікою прийняття рішень і 
можливістю взаємодії з іншими агентами та компонентами системи.  
Спільнота агентів: Група агентів, які працюють разом для досягнення 
спільних цілей або вирішення конкретних завдань.  
Комунікація агентів: Обмін інформацією між агентами для вирішення 
конкретних завдань або досягнення спільних цілей.  
Сервер: Централізована частина системи, яка обробляє запити від клієнтів, 
забезпечуючи доступ до ресурсів та послуг.  
Клієнт: Кінцева точка взаємодії користувача з системою. Ініціює запити до 
сервера та обробляє відповіді.  
Проксі-агент: Агент, який працює від імені іншого агента, забезпечуючи 
додатковий шар абстракції або безпеки.  
Інтелектуальний агент: Агент, обладнаний здатністю вирішувати завдання, 
використовуючи штучний інтелект та самостійне навчання.  
Інтерфейс користувача: Місце, де користувачі взаємодіють з системою, 
подаючи запити та отримуючи результати.  
Безпека: Заходи, що забезпечують конфіденційність, цілісність та доступність 
інформації та ресурсів в системі. 
43 
 
ЧДТУ.232229.021 ПЗ 
 
3.1.3 Елементи моделювання предметної області 
Для відтворення предметної області та при розробці всієї системи в цьому 
дослідженні буде використовуватися мова моделювання UML. У подальших 
частинах роботи будуть представлені основні складові моделювання (див. таблицю 
3.1 та таблицю 3.2), які будуть відображені на UML-діаграмах 
 
Таблиця 3.1 
Таблиця складових моделювання 
Графічний символ Назва елемента 
Дійова особа (Actor): Представляє користувача або 
зовнішню систему, яка взаємодіє з системою. 
 
Варіант використання (Use Case): Представляє конкретну 
функціональність або можливість системи. 
 
Пакет (Package): Контейнер, який групує пов'язані елементи 
моделі разом для забезпечення більшої організації та 
 зрозумілості.  
Клас (Class): Представляє структурні аспекти системи та 
містить атрибути та методи. 
 
 Kомпонент (Component): Eлемент, який представляє 
фізичний або логічний модуль або підсистему системи. Він 
може включати в себе класи, інтерфейси, бібліотеки та інші 
елементи системи. 
Стан (State): Показує конкретний стан об'єкта або системи. 
 
Лінія життя: представляє життєвий цикл об'єкта або 
компонента системи. 
 
Початковий і кінцевий стан. 
 
44 
 
ЧДТУ.232229.021 ПЗ 
 
Продовження таблиці 3.1 
Логічний з’єднувач, розгалужувач: Логічний з'єднувач 
представляє зв'язок між елементами моделі та вказує на 
взаємодію між ними. 
 
Паралельний з’єднувач, розгалужувач: Елементи діаграм, 
що вказують на одночасне виконання паралельних шляхів 
 або процесів у системі. 
 
Таблиця 3.2 
Таблиця елементів моделювання 
Графічний символ Назва елемента 
Відношення асоціації: З'єднує класи, але не має стрілок чи 
 напрямку. Використовується для моделювання взаємодій, 
коли важливий сам факт з'єднання. 
Відношення залежності: показує, що один елемент моделі 
 впливає на інший. Зміни в залежному елементі можуть 
впливати на залежний елемент. 
Заміна: використовується для позначення можливості 
 замінити один елемент моделі іншим без порушення 
функціональності системи. 
Межа:  використовується для виділення меж системи, 
 підсистеми чи контексту, щоб визначити, які елементи 
знаходяться всередині, а які знаходяться ззовні цих меж. 
Прстий потік управління. 
 
Виклик: вказуває на взаємодію між об'єктами, класами чи 
 іншими елементами системи 
Рекурсія: вказує на ситуацію, коли об'єкт взаємодіє сам з 
 собою або коли елемент системи викликає сам себе в 
процесі виконання. 
Повернути: використання діаграм послідовності та 
 діаграм класів для відображення повернень вздовж 
викликів методів. 
 
45 
 
ЧДТУ.232229.021 ПЗ 
 
Продовження таблиці 3.2 
Агрегація: вказує на часткове або повне відношення ціле-
 частина між класами. Це означає, що один клас може 
містити інший клас як свій компонент. 
 
3.1.4 Робоча область моделювання 
Проаналізувавши діаграму основних вузлів системи було виділено основні 
потоки інформації: 
1 Отримання вхідних даних для авторизації - обробка запиту, що містить 
параметри нового користувача для подальшої їх обробки інтегрованим 
модулем Firebase Authentication. 
2 Отримання вхідних даних для аутентифікації - обробка запиту, що містить 
параметри нового користувача для подальшої їх обробки інтегрованим  
модулем Firebase Authentication. 
3 Отримання вхідних даних для створення проєкту - обробка запиту, що містить 
параметри та дані для нового проєкту, збереження даних в БД. 
4 Обробка даних – аналіз та підготовка отриманих даних, для подальшої 
відправки зовнішньому сервісу. 
5 Відправка оброблених даних зовнішньому сервісу. 
6 Отримання результатів - отримання опрацьованої інформації від зовнішнього 
сервісу у вигляді ID - номеру для перевірки логів. 
7 Відображення результатів - знаходження у логах зовнішнього сервісу 
потрібних для відображення даних по ID - номеру. 
Схема потоків інформації для клієнт-серверної архітектури визначає шляхи, 
якими дані переміщаються між клієнтами та серверами під час їх взаємодії. 
Схема потоків інформації показана на pисунку 3.2. Ця схема відображає основні 
етапи обміну інформацією між клієнтами та серверами у клієнт-серверній 
архітектурі. Залежно від конкретної реалізації та вимог проєкту, можуть бути 
додаткові етапи чи особливості. 
46 
 
ЧДТУ.232229.021 ПЗ 
 
 
 
Рисунок 3.2 – Інформаційні потоки 
3.2 Формування та аналіз вимог 
 Аналіз вимог включає визначення потреб і умов, які ставляться перед новим 
або зміненим продуктом, при врахуванні можливо конфліктних вимог різних 
замовників, таких як користувачі.  
Вимоги для інформаційних систем представляють собою набір вимог, що 
стосуються властивостей, якості та функцій системи, що розробляється або 
знаходиться в розробці. Це концентроване відображення потреб зацікавлених у 
створенні системи замовників, користувачів і розробників.  
3.2.1 Первинні вимоги замовника 
Виділяють дві категорії вимог: вимоги замовника (первинні) і вимоги 
розробника (детальні). Вони відрізняються рівнем деталізації обробки та 
представлення вимог.  
47 
 
ЧДТУ.232229.021 ПЗ 
 
Спочатку вимоги отримуються від клієнтів, включаючи їхні потреби, 
очікування та обмеження. Зібрані вимоги документуються в структурованій формі, 
що включає опис функціональних вимог (тобто те, що система повинна робити) та 
нефункціональних вимог (тобто те, як система повинна працювати, наприклад, 
вимоги до безпеки, продуктивності, надійності).  
Вимоги аналізуються з метою забезпечення їхньої консистентності, повноти 
та реалізованості. Якщо виникають суперечності або непорозуміння, вони 
виправляються через взаємодію з клієнтом. Після аналізу та виправлень вимоги 
підтверджуються.  
Затверджені вимоги виступають основою для подальшого розвитку системи 
чи програмного забезпечення і служать узгодженим контрактом між розробницькою 
командою та клієнтом. 
Цей етап забезпечує впевненість розробникові у тому, що всі потреби 
користувача зрозумілі, перш ніж розпочнеться їхнє втілення.  
Первинні вимоги документують бажання і потреби замовника і 
відображаються діаграмою прецедентів (варіантів використання, Use Case). Перед 
побудовою діаграми вони описуються мовою, яка є зрозумілою для замовника. 
Детальні вимоги документуються за допомогою структурованої мови за допомогою 
діаграм діяльності та діаграм взаємодій. Вони розробляють та конкретизують 
первинні вимоги. 
Первинна вимога замовника до системи: 
Реалізувати UI частину системи, імплементувати авторизацію та 
аутентифікацію для користувачів (JWT токен має бути також імплементований). 
Також необхідно реалізувати можливість користувача створювати проєкти, 
кастомізувати їх та відправляти їх у вигляді вхідних даних для іншої частини 
системи (External Service). Система має отримувати id для ідентифікації резудльтатів 
по id. 
3.2.2 Детальні вимоги розробника 
Були виокремлені наступні вимoги: 
48 
 
ЧДТУ.232229.021 ПЗ 
 
1 Можливість отримання вхідних даних для авторизації - перевірка запиту, чи 
містить він всі необхідні параметриа для подальшої їх обробки інтегрованим 
модулем Firebase Authentication. 
2 Можливість отримання вихідних даних для аутентифікації - створення 
системою JWT токена, який необхідний для підтвердження валідності 
користувача для внутрішніх модулівта зовнішніх сервісів. 
3 Можливість отримання вхідних даних для створення проєкту - система 
повинна мати змогу приймати запити на створення проєктів на основі 
параметрів наконфігурованих користувачем. 
4 Можливість обробляти дані – аналіз та підготовка отриманих даних, для 
подальшої відправки зовнішньому сервісу. 
5 Можливість отримання результатів - система повинна мати функціонал, який 
дозволяє обробляти дані отримані від зовнішнього сервісу. 
6 Можливість опрацювання результатів - система має перевіряти логи на 
наявність потрібних результатів та опрацьовувати для представлення 
кінцевому користувачу. 
3.2.3 Функціональні вимоги 
Функціональні вимоги надають опис поведінки системи та послуг (функцій), 
які вона має виконувати. Це випливає із всебічного аналізу предметної області. 
Розглядаються різні сценарії поведінки, які визначаються різноманітними даними та 
станами зовнішнього середовища. 
В реалізуємій системі можна виокремити наступні функціональні вимоги: 
- реалізація UI частини проєкту; 
- отримання та опрацювання запитів від стороннього користувача;  
- валідація отриманих даних (JWT токен); 
- аутентифікація вхідного запиту; 
- отримання та збереження даних в БД; 
- створення проєктів та їх конфігурування; 
49 
 
ЧДТУ.232229.021 ПЗ 
 
- завантаження та обробка xlxs файлу; 
- підготовка даних для відправки на Зовнішній Сервіс; 
- відправка даних Зовнішньому Сервісу; 
- отримання результатів від агентів Зовнішньому Сервісу; 
- опрацювання вхідних даних від Зовнішнього Сервісу; 
- відображення отриманих результатів. 
3.2.4 Нефункціональні вимоги 
Нефункціональні вимоги включають у себе характеристики системи та її 
зовнішнього середовища, критерії ефективності і безпеки. Крім того, можуть бути 
визначені обмеження, які стосуються дій та функцій системи, а також умови 
розробки. 
В даній системі можна виокремити такі нефункціональні вимоги: 
- документація до системи; 
- взаємодія із Зовнішнім Сервісом (поліагентним); 
- динамічна конфігурація; 
- ефективна комунікація: Використання розроблених протоколів обміну 
повідомленнями для передачі даних; 
- безпека та аутентифікація: Реалізація механізмів безпеки та аутентифікації 
через JWT, щоб забезпечити конфіденційність та ідентифікацію 
користувачів;  
- відокремлена БД; 
- масштабованість; 
- зручність та простота використання; 
- 3апам’ятовуваність; 
- робота з усіма браузерами (Chrome, Opera, FireFox, Enternet Explorer). 
3.2.5 Формування вимог за допомогою діаграми прецедентів 
Розглянемо детальніше багаторівневу клієнт-серверні архітектуру, тому що 
саме вона використовуватиметься при реалізації. Оскільки такий підхід є 
оптимальним при наших вхідних умовах. Розглянемо архітектуру клієнт-сервер, яка 
використовуватиметься при розробці (рис. 3.3). 
50 
 
ЧДТУ.232229.021 ПЗ 
 
 
 
Рисунок 3.3 – Багаторівнева архітектура клієнт-сервер 
 
 Кожен клієнт містить лише реалізацію користувацького інтерфейсу та не 
займається безпосередніми маніпуляціями базою даних. При настанні необхідності 
виконання певних дій, що потребують втручання у віддалену частину системи, 
виконується запит до серверу додатків, що містить всю необхідну бізнес-логіку для 
обробки даних. Сервер додатків в свою чергу делегує виконання безпосередніх 
операцій над даними в БД серверу баз даних, що займається виконанням необхідних 
команд над інформацією, яка міститься в базі даних. Таким чином, кожен рівень 
відповідає лише за окремий функціонал та делегує виконання повноважень, які йому 
не належать, іншому рівню. Це надає можливість паралельної розробки кожного 
рівня, легкого масштабування проєкту за необхідністю та окремого тестування 
кожного з незалежних частин програми. Для подальшого відображення даних, які 
знаходяться на рівні бази даних, використовується інший програмній засіб. 
Створюється підключення до сервера бази даних та забезпечується доступ до даних. 
Після усіх підключень налаштовується відображення інформації для інтуїтивно-
логічного розуміння та подальшого використання. 
Діаграма прецедентів надає змогу візуально представити вимоги замовника та 
поведінку системи з погляду кінцевого користувача. 
На основі цих вимог створено натупну діаграму прецедентів (рис. 3.4). На даній 
діаграмі Актори - це користувач за Зовнішній Сервіс - інформаційна система з 
поліагентним функціоналом. 
51 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 3.4 – Діаграма прецедентів  
 
Прецеденти: вхід в систему: Передбачає процес аутентифікації користувача 
(FireBase Auth), всі маніпуляції по створенню та кастомізації проєктів, отимання 
результатів від Зовнішнього Сервісу. 
Зв'язки: стрілки вказують на взаємодію між акторами та прецедентами. 
3.4 Проєктування логічної структури програмного комплексу 
Проєктування логічної структури програмного комплексу – це етап розробки, 
на якому створюється абстрактна модель системи або програми. Ця модель визначає 
взаємодію компонентів і способи вирішення поставлених завдань.  
52 
 
ЧДТУ.232229.021 ПЗ 
 
Проєктування логічної структури передує фазі розробки та включає 
визначення інтерфейсів між компонентами для забезпечення їх взаємодії та обміну 
даними. Під час проєктування визначаються логічні взаємозв'язки між 
компонентами системи, розбивається система на модулі або компоненти, кожен з 
яких відповідає конкретним функціям.  
Це сприяє модульності, полегшує розробку, тестування та обслуговування. 
При проєктуванні логічної структури важливо враховувати можливість 
масштабування та розширення системи в майбутньому. Це дозволяє забезпечити 
стійкість та гнучкість системи, особливо у випадках великого навантаження або 
зростання кількості користувачів.  
Коректно спроєктована логічна структура гарантує ефективність, надійність 
та легкість обслуговування системи. 
3.4.1. Діаграми класів 
Діаграми класів є важливою частиною уніфікованої мови моделювання 
(UML). Вони використовуються для візуалізації структури класів у програмному 
забезпеченні та їхніх взаємозв'язків. Ці діаграми забезпечують графічний засіб 
подання об'єктно-орієнтованої моделі системи, надаючи докладний опис класів, 
їхніх атрибутів, методів і відносин спадкування між ними. 
Діаграми класів використання можуть бути корисним інструментом для 
аналізу вимог і визначення функціональності системи з точки зору користувача. 
Вони включають наступні елементи: 
- класи: представлення концепцій або об'єктів в системі. Кожен клас містить 
атрибути (змінні) та методи (функції);  
- атрибути: змінні, що належать класу. Вони описують властивості класу;  
- методи: функції, які виконуються класом. Вони описують поведінку класу; 
- спадкування (наслідування): відносини між класами, де один клас 
успадковує атрибути та методи іншого класу; 
53 
 
ЧДТУ.232229.021 ПЗ 
 
- асоціації: зв'язки між класами, які вказують на взаємодію або залежність 
між ними;  
- агрегації та композиції: спеціальні види асоціацій, що вказують на 
відносини "частина-ціле" між класами; 
- інтерфейси: контракти, які визначають, як класи можуть взаємодіяти один 
з одним; 
- пакети: групи класів для організації великих систем та полегшення їхнього 
аналізу.  
Діаграма класів (рис. 3.5) допомагають моделювати структуру системи та її 
взаємодії, що є важливим етапом у розробці програмного забезпечення. 
Діаграма класів клієнт-серверної архітектури може служити ефективним 
інструментом для візуалізації структури системи та взаємодії між класами на рівні 
програмного коду. 
Загалом, діаграма класів є важливим інструментом для розуміння та 
моделювання архітектурних рішень в програмному забезпеченні, включаючи 
клієнт-серверні системи. 
Основним класом системи є клас Modeling - саме він забезпечує створення 
проєктів та навігацію по пректам користувача. 
Діаграма класів клієнт-сервер дозволяє вам візуально відобразити структуру 
системи та її компонентів, а також взаємодію між ними. У цій діаграмі кожен клас 
представлений прямокутником, який містить ім'я класу, його атрибути та методи. 
Відносини між класами також можуть бути показані, вказуючи напрямок взаємодії 
та тип цієї взаємодії (наприклад, асоціація, агрегація, композиція). 
Можемо виділити наступні основні класи системи: 
- app - модуль для реєстрації інших модулів; 
- modeling - модуль основної бізнес-логіки. Слугує для локальної взаємодії; 
- між модулями та для взаємодії із Зовнішнім Сервіcом (поліагентним); 
- shared - модуль для взаємодії з БД; 
54 
 
ЧДТУ.232229.021 ПЗ 
 
- user - модуль описує стратегію валідації JWT токену FireBase та слугує для 
створення внутрішнього юзера для взаємодії з іншими сутностями; 
- auth - модуль описує базову логіку авторизації користувачів для CRUD 
операцій; 
- helthCheck - модуль для перевірки стану АРІ та БД системи; 
- error Handler - модуль для відловлювання та обробки помилок системи. 
 
Рисунок 3.5 – Діаграма класів інформаційної система з поліагентним 
функціоналом 
3.4.2 Діаграми пакетів 
Діаграма пакетів в Unified Modeling Language (UML) використовується для 
візуалізації та організації структури системи за допомогою групування елементів в 
пакети. Пакети допомагають у логічній організації, розподілі та управлінні 
елементами системи.  
Основні компоненти діаграми пакетів включають:  
55 
 
ЧДТУ.232229.021 ПЗ 
 
- пакети (packages): пакети представляють групи пов'язаних елементів 
системи. Вони можуть містити класи, інші пакети, інтерфейси тощо; 
- вміст пакета (package contents): це елементи, які містяться всередині 
пакета. Це може бути класи, інтерфейси, підпакети, та інші елементи; 
- взаємодія між пакетами (dependencies): показує залежності або взаємодії 
між пакетами. Наприклад, якщо один пакет використовує функції іншого;  
- розміщення (location): вказує на фізичне або логічне розміщення пакета у 
системі; 
- простір імен (namespace): пакет може слугувати простором імен, де імена 
класів та інших елементів є унікальними всередині пакета.  
Діаграма пакетів (рис 3.6) допомагає в логічному та фізичному організації 
коду, забезпечуючи структурну чіткість та полегшуючи розуміння системи. Вона 
особливо корисна великим проєктам, де важливо управляти складністю та 
взаємодією між компонентами системи. 
 
Рисунок 3.6 – Діаграма пакетів  
 
Короткий опис пакетів, що представлені на діаграмі (рис. 3.6): 
- аuth (пакет аутентифікації) дозволяє проводити аутентифікацію вхідних 
запитів від сервісу, що забезпечує взаємодію системи з кінцевими 
користувачами;  
56 
 
ЧДТУ.232229.021 ПЗ 
 
- analyzer (пакет аналізу) надає можливість аналізувати вхідні дані, які 
надходять до системи; 
- project creation (пакет логіки пакетів) дозволяє опрацьовувати вхідні дані, 
готувати дані для передачі зовнішньому сервісу, а також встановлювати 
необхідні налаштування; 
- request sender (пакет відправки запитів) надає можливість відправляти 
запити, тобто формулювати і поставляти завдання кожному з агентів;  
- receiver (пакет отримання результатів) дозволяє отримувати результати 
роботи агентів;  
- DB connection (пакет взаємодії з БД) забезпечує можливість взаємодії з 
базою даних та виконання різноманітних запитів до неї;  
- error handler (пакет обробки помилок) надає можливість обробляти 
помилки, які виникають в системі під час її роботи;  
- logger (пакет логування) забезпечує можливість реєструвати необхідну 
інформацію;  
- notifier (пакет сповіщень) дозволяє відправляти повідомлення до сервісу із 
користувацьким інтерфейсом; 
- result displayer (пакет результатів) дозволяє надавати кінцевому 
користувачу результуючий лог. 
3.5 Архітектурне проєктування 
Архітектурне проєктування відіграє ключову роль у розробці клієнт-серверної 
арітектури для інформаційної системи з поліагентним функціоналом, визначаючи 
фундаментальну структуру та організацію системи, що впливає на її ефективність, 
надійність та здатність задовольняти потреби користувачів.  
Проєктування архітектури є складним процесом, який вимагає глибокого 
розуміння предметної області та достатніх технічних знань для реалізації 
програмної частини системи.  
57 
 
ЧДТУ.232229.021 ПЗ 
 
У контексті клієнт-серверної арітектури для інформаційної системи з 
поліагентним функціоналом, проєктування визначає загальну структуру системи, 
організацію модулів та їх взаємодію для досягнення мети та створення ефективної 
системи.  
Це включає ідентифікацію користувачів, створення проєктів та обробку 
результатів. Важливим етапом проєктування архітектури є визначення механізмів 
взаємодії між зовнішнім сервісом та  системою, включаючи обмін повідомленнями. 
Архітектура також повинна враховувати аспекти безпеки та конфіденційності 
даних, використовуючи механізми автентифікації, авторизації та шифрування. 
Оскільки система взаємодіє з іншими існуючими інформаційними системами, 
архітектурний проєкт повинен включати план інтеграції та обміну даними з цими 
системами. Масштабованість та продуктивність також є важливими аспектами 
проєктування архітектури, з урахуванням їх здатності ефективно працювати навіть 
у великих масштабах. 
Необхідно представити етап архітектурного проєктування клієнт-серверної 
архітектури для інформаційної системи з поліагентним функціоналом, 
використовуючи опис процесу об'єктно-орієнтованої декомпозиції системи до рівня 
переліку підсистем та їх взаємозв'язків. Також важливо надати опис логічної 
структури системи у вигляді пакетів компонентів за допомогою діаграми 
компонентів. 
3.5.1 Діаграма компонентів 
Діаграма компонентів є однією з видів діаграм в уніфікованій мові 
моделювання (UML) та використовується для візуалізації та моделювання структури 
компонентів, їхніх взаємозв'язків та взаємодії в системі.  
Елементи діаграми компонентів включають: 
- компоненти (components): це основні структурні одиниці системи. 
Компоненти можуть бути фізичними частинами програмного забезпечення 
або логічними блоками функціональності;  
58 
 
ЧДТУ.232229.021 ПЗ 
 
- інтерфейси (interfaces): це точки контакту між компонентами, які 
визначають, як компоненти можуть взаємодіяти або обмінюватися 
інформацією;  
- взаємозв'язки (relationships): вказують зв'язки та залежності між 
компонентами. Наприклад, асоціації, залежності, агрегації; 
- кластери (clusters): групи компонентів, які мають спільний контекст або 
взаємодіють між собою;  
- зовнішні компоненти (external components): представлення сторонніх 
частин, які взаємодіють з системою, але не розглядаються детально. 
Діаграма компонентів (рис. 3.7) дозволяє організувати та відобразити 
архітектурні взаємозв'язки та залежності між компонентами системи, спрощуючи 
розуміння структури програмного забезпечення. 
Діаграма компонентів (рис. 3.7) сприяє чіткому розумінню команди 
розробників та архітекторами архітектурної структури програмної системи, 
організації компонентів та їх взаємозв'язків. Вона може бути використана для 
аналізу та документування архітектури програмного забезпечення, а також для 
взаємодії з замовниками та іншими учасниками проєкту. 
Основні компоненти: 
Клієнтська сторона: GUI компоненти: включають інтерфейси користувача, 
такі як веб-інтерфейси або мобільні додатки. 
Серверна Сторона: 
Додаткові Серверні Компоненти: Включають бізнес-логіку, служби та інші 
компоненти, які виконуються на сервері. 
Комунікаційні Зв'язки: 
Стрілки вказують на зв'язки та обмін даними між компонентами. 
59 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 3.7 – Діаграма компонентів системи 
 
3.5.2 Розгортання програмної системи. Діаграма розгортання 
Діаграма розгортання - це вид діаграми уніфікованої мови моделювання 
(UML), який використовується для візуалізації та моделювання фізичного 
розташування компонентів програмної системи та їх взаємодії на апаратному рівні. 
Ця діаграма вказує, як програмні та апаратні компоненти розташовані і взаємодіють 
між собою в реальному середовищі.  
Елементи діаграми розгортання включають:  
- вузли (nodes): представляють фізичні або віртуальні апаратні пристрої, на 
яких розташовані компоненти системи. Це можуть бути сервери, 
комп'ютери, мобільні пристрої тощо;  
- компоненти (components): представляють програмні модулі або сервіси, 
які розгортаються на вузлах. Це можуть бути веб-сервери, бази даних, 
додатки тощо; 
60 
 
ЧДТУ.232229.021 ПЗ 
 
- взаємозв'язки (connections): вказують на зв'язки та способи взаємодії між 
вузлами. Це може включати мережеві з'єднання, комунікаційні канали та 
інші види зв'язків;  
- артефакти (artifacts): це файли або ресурси, які використовуються або 
генеруються системою. Наприклад, це може бути конфігураційні файли, 
лог-файли тощо. Використання артефактів: Вказує, які артефакти 
використовуються компонентами системи.  
 Вузли, які розроблялися в даній роботі не включають Foreign Service та Agent. 
Вони розроблялися колегами як окремі дипломні роботи. 
Діаграма розгортання (рис. 3.8) допомагає командам розробників та 
архітекторам зрозуміти, як програмні та апаратні компоненти взаємодіють між 
собою та як система розташована в реальному середовищі. 
Так, діаграма розгортання є важливим інструментом в інженерії програмного 
забезпечення, особливо при роботі з розподіленими системами та архітектурою 
клієнт-сервер. 
 
Рисунок – 3.8 Діаграма розгортання системи 
61 
 
ЧДТУ.232229.021 ПЗ 
 
3.6 Моделювання поведінки системи 
Моделювання поведінки системи є процесом створення абстрактних моделей, 
які ілюструють спосіб, яким система взаємодіє із своїм оточуючим середовищем та 
внутрішніми компонентами. Під час моделювання поведінки системи враховуються 
різноманітні аспекти, такі як обробка подій, реакція на зміни в стані системи, 
взаємодія з іншими системами та користувачами. 
3.6.1 Діаграма діяльності 
Діаграми діяльності є графічними інструментами моделювання, які 
використовуються для візуалізації послідовності дій або процесів у системі. Вони 
надають можливість уявно представити, як об'єкти взаємодіють між собою та 
виконують конкретні дії.  
Основна мета діаграм діяльності - це деталізація та уточнення логіки 
виконання конкретних завдань або бізнес-процесів.  
Основні елементи діаграм діяльності:  
- дія (action): Представляє окрему дію чи операцію, яку виконує система чи 
об'єкт;  
- вузол рішення (decision node): Позначає вузол у діаграмі, де приймається 
рішення, і в залежності від умови обирається один або інший шлях;  
- рішення (secision/merge): Вказує на вузол, в якому відбувається прийняття 
рішення;  
- функціональна область (partition): Групує дії та об'єкти для позначення 
функціональних областей в системі;  
- вхід/вихід (initial/final node): Позначають початок та завершення діаграми 
відповідно;  
- вузол об'єднання (join node): Вказує на точку, де декілька шляхів 
об'єднуються;  
- об'єкт (object): Представляє конкретний об'єкт або екземпляр класу в 
системі;  
62 
 
ЧДТУ.232229.021 ПЗ 
 
- стійка (swimlane): Використовується для розділення діаграми на логічні 
групи для кращого розуміння взаємодії між об'єктами.  
Ці елементи допомагають створювати докладні та зрозумілі діаграми діяльності, що 
полегшує аналіз та розробку систем та бізнес-процесів. Нижче наведено діаграму 
діяльності для клієнт-серверної арітектури для інформаційної системи з 
поліагентним функціоналом, яка розробляється в рамках даної роботи (pис. 3.9). 
 
 
Рисунок 3.9 – Діаграма діяльності системи 
63 
 
ЧДТУ.232229.021 ПЗ 
 
 
3.6.2 Діаграма послідовності 
Діаграма послідовності - це вид діаграми UML, яка відображає взаємодію 
об'єктів у певній системі в рамках конкретного виконання сценарію чи функціоналу. 
Діаграма послідовності зображує, як об'єкти взаємодіють один з одним у певний 
період часу, показуючи послідовність повідомлень, що передаються між ними.  
Основні елементи діаграми послідовності включають:  
- об'єкти (participants): об'єкти або учасники взаємодії, які беруть участь у 
сценарії. Об'єкти зображуються вертикальними прямокутниками з ім'ям 
або ідентифікатором;  
- лінії життя (lifelines): вертикальні лінії, що представляють тривалість 
існування об'єкта. Вони простягаються вздовж вісі часу та вказують, 
скільки часу об'єкт існує; 
- послідовність повідомлень (messages): стрілки, що вказують послідовність 
повідомлень між об'єктами. Повідомлення може бути синхронним (виклик 
методу, коли чекається відповідь) чи асинхронним (відправка 
повідомлення без очікування відповіді);  
- опціональні конструкції (optional constructs): можливості для додаткового 
визначення сценарію, такі як умовні оператори (alt), ітерації (loop) тощо.  
Діаграма послідовності (pис. 3.10) допомагає візуалізувати взаємодію між 
об'єктами та порядок передачі повідомлень у системі на високому рівні. 
Діаграма послідовності є особливо корисним інструментом для моделювання 
взаємодії між клієнтом і сервером у клієнт-серверних системах. 
Дани й вид UML діаграм дозволяє уявити та продумати загальну бізнес логіку 
системи та закласти необхідні процеси на етапі моделювання для уникнення 
критичних помилок в майбутньому.  
64 
 
ЧДТУ.232229.021 ПЗ 
 
На діаграмі (pис. 3.10) зображено  об’єкт - Зовнішній Сервіс - це інформаційна 
система з поліагентним функціоналом, яка паралельно розробляється колегою-
розробником. 
 
Рисунок 3.10 – Діаграма послідовності системи 
 
3.6.3 Діаграма комунікації 
Діаграма комунікації – це специфічний тип діаграми в мові моделювання 
UML, який відтворює взаємодію між об'єктами чи компонентами системи протягом 
конкретного періоду часу.  
Подібна до діаграми послідовності, вона акцентує увагу на взаємодії та 
передачі повідомлень між компонентами. Діаграми комунікації сприяють 
візуалізації, аналізу та розумінню взаємодії між різними частинами системи. Вони 
полегшують сприйняття та аналіз обміну повідомленнями та комунікації між 
65 
 
ЧДТУ.232229.021 ПЗ 
 
об'єктами під час виконання конкретних функцій чи процесів. Зображена на Рис. 
3.11, діаграма комунікації надає графічне відображення взаємодії між компонентами 
системи, що сприяє більш легкому розумінню та аналізу їхньої взаємодії.  Діаграма 
комунікацій включає наступні елементи:  
- об'єкти (об'єкт): представлення конкретних об'єктів або компонентів 
системи, між якими відбувається взаємодія;  
- лінії життя (lifeline): відображення тимчасового існування об'єкта під час 
виконання конкретної функції чи процесу. Лінії життя представляють 
часовий інтервал, протягом якого об'єкт активний;  
- повідомлення (message): інтеракції між об'єктами виражаються 
повідомленнями. Вони показують обмін інформацією чи виклик методів 
між об'єктами;  
- активації та деактивації (activation/deactivation): позначення періодів 
активності та неактивності об'єкта на лінії життя. Активації вказують на 
час виконання операцій, тоді як деактивації – на період неактивності; 
- фрейми (frame): загальне обрамлення або контейнер, який групує 
повідомлення та об'єкти для логічної організації діаграми; 
- комбіновані фрагменти (combined fragment): частини діаграми, які 
вказують на альтернативні або паралельні виконання операцій; 
- оператори (operator): спеціальні символи або позначення, які додають 
семантику до повідомлень або фрагментів.  
Ці елементи дозволяють створювати структуроване та інформативне 
відображення взаємодії між компонентами системи на діаграмі комунікації. 
 
 
Рисунок 3.11 – Діаграма комунікації системи 
66 
 
ЧДТУ.232229.021 ПЗ 
 
3.6.4 Діаграма скінченного автомату 
Діаграма скінченого автомату - це графічне представлення скінченного 
автомата, математичної моделі, яка може перебувати в обмеженій кількості станів 
та переходити між ними в залежності вхідних подій.  
Основні елементи ДСА включають:  
- стани (states): кожен стан представляє конкретний стан автомата. На 
діаграмі кожен стан зображується еліпсом або прямокутником з назвою 
стану всередині; 
- переходи (transitions): стрілки, які з'єднують стани та позначають, як 
автомат переходить від одного стану до іншого під впливом вхідних подій 
чи умов;  
- початковий стан (initial state): спеціальний стан, з якого починається робота 
автомата. Його зазвичай відзначають стрілкою, що вказує на початок 
виконання;  
- кінцеві стани (final states або accepting states): стани, які позначають 
завершення роботи автомата. Зазвичай вони позначаються подвійними 
еліпсами або прямокутниками; 
- події (events): зовнішні події або сигнали, які спричиняють переходи між 
станами. Вони позначаються на стрілках або біля стрілок;  
- умови (conditions): умови, які потрібно виконати для того, щоб відбувся 
перехід. Це може бути позначено на стрілці між станами або поруч із 
стрілкою.  
Діаграма скінченого автомату (рис. 3.12) надає інтуїтивно зрозуміле та 
візуальне представлення поведінки системи у вигляді станів та переходів між ними. 
Оскільки у загальної системи є окремі модулі, то діаграма може бути змінена 
в залежності від майбутніх конкретних потреб загальної системи з поліагентним 
функціоналом. 
67 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 3.12 – Діаграма скінченого автомата системи 
  
68 
 
ЧДТУ.232229.021 ПЗ 
 
Висновки до розділу 
За результатами виконання даного розділу Було виконано моделювання 
системи, де кожен етап моделювання ілюстровано відповідними діаграмами 
відповідно до установлених вимог.  
Описано послідовність дій в проєктованому об'єкті, яка призводить до 
визначених результатів. Здійснено моделювання предметної області та 
сформульовано вимоги до програмного забезпечення.  
Проведено проєктування логічної структури та архітектурне проєктування. На 
основі отриманих діаграм отримано чітке уявлення про те, як система повинна 
функціонувати та реагувати на різні ситуації, як повинні взаємодіяти компоненти 
системи. 
В майбутньому аналіз результатів може слугувати для внесення змін в модель, 
для поліпшення її точності та релевантності.   
69 
 
ЧДТУ.232229.021 ПЗ 
 
РОЗДІЛ 4 КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
4.1 Розробка програмного комплексу 
4.1.1 Обґрунтування вибору засобів реалізації 
Даний проєкт буде реалізований з використанням фреймворків та бібліотек 
мови програмування JavaScript таких як NestJS + Typescript та Vue.js. JavaScript 
ідеально підходить для розробки веб-додатків, демонструючи надійність та високу 
швидкість.  JavaScript – це мова програмування для створення та керування 
динамічним вмістом веб-сайту. Це означає, що всі рухомі, оновлювані або інакше 
змінювані елементи на вашому екрані можуть відбуватися без необхідності ручного 
перезавантаження веб-сторінки. 
JavaScript є досить стислою, але водночас дуже гнучкою мовою. Розробники 
створили значну кількість інструментів, що доповнюють основну мову JavaScript, 
розкриваючи широкий спектр додаткових можливостей з мінімальними зусиллями.  
API додатка, які вбудовані в браузери, надають різноманітні функціональні 
можливості, такі як динамічне створення HTML і встановлення CSS стилів, 
захоплення та маніпулювання відеопотоком, взаємодія з веб-камерою користувача 
або генерація 3D графіки і аудіо семплів.  
Зовнішні API дозволяють розробникам інтегрувати функціональність в свої 
веб-сайти від інших розробників, також можна використовувати сторонні 
фреймворки і бібліотеки для HTML, що сприяє прискоренню розробки веб-сайтів і 
додатків [14].  
Кожна мова програмування має свої недоліки і слабкі сторони. Однією з 
причин виникнення проблем є популярність мови. Коли мова, як JavaScript, стає 
надто популярною, вона привертає підвищений інтерес з боку хакерів, шахраїв та 
інших зловживань, які намагаються знайти уразливості та слабкі місця в безпеці. 
Деякі з цих слабкостей включають:  
70 
 
ЧДТУ.232229.021 ПЗ 
 
- вразливість до експлойтів, які використовують уразливості програмного 
забезпечення;  
- можливість запуску шкідливого коду на комп'ютері користувача;  
- непідтримка деякими браузерами або пристроями;  
- розмір фрагментів JS-коду може бути значним;  
- різна відображеність на різних пристроях, що може порушувати цілісність. 
 Для спрощеної та зручної розробки використовувався фреймворк Vue.js. 
Vue.js є бібліотекою JavaScript для створення веб-інтерфейсів, що використовує 
шаблон архітектури MVM (Model-View-ViewModel).  
Оскільки Vue працює лише на рівні уявлення і не використовується для 
проміжного програмного забезпечення та бекенда, його легко можна інтегрувати з 
іншими проєктами та бібліотеками. Vue.js має обширний набір функцій для рівня 
уявлень і може використовуватися для створення потужних односторінкових веб-
додатків.  
Основні функції Vue.js включають:  
- реактивні інтерфейси; 
- декларативний рендеринг; 
- зв'язування даних; 
- директиви (усі директиви мають префікс «v-». У директиву передається 
значення стану, а в якості аргументів використовуються HTML атрибути 
або події Vue.js); 
- логіка шаблонів; 
- компоненти; 
- обробка подій; 
- властивості;  
- переходи та анімація CSS;  
- фільтри. 
 Vue найкраще підходить для розробки рішень, які використовують зовнішні 
API для обробки даних. Vue не має проблем із зазначеним, оскільки він 
71 
 
ЧДТУ.232229.021 ПЗ 
 
використовує прозору систему спостереження за залежностями з асинхронною 
постановкою в чергу. Усі зміни запускаються незалежно, якщо вони не мають явних 
відносин залежності [21].  
4.1.2 Вибір методу розробки системи 
Для даного проєкту була обрана клієнт-серверна архітектура з трьома 
ланками, що включає наступні компоненти [15]:  
- клієнтський рівень – це частина додатку, яка розроблена для взаємодії з 
користувачем (User Interface); 
- сервер – це частина програми, де міститься вся бізнес-логіка додатку. 
Клієнтський рівень може отримати доступ до функцій серверу через 
жорстко визначений інтерфейс; 
- data layer – це рівень роботи з базою даних, який забезпечує серверу доступ 
до бази даних.  
Обрана архітектура має ряд переваг, таких як: високий рівень захищеності 
системи, висока масштабованість та гнучкість, висока продуктивність. 
 Приведення архітектури до моделі клієнт-сервер є основою архітектурного 
стилю REST для розробки API. Це обмеження додає системі такі бажані 
характеристики, як продуктивність, простота, гнучкість, масштабованість, 
адаптивність, портативність та надійність [11]. Розмежування потреб є ключовим 
принципом цієї архітектури.  
Відокремлення потреб інтерфейсу клієнта від потреб серверної частини, що 
зберігає дані, підвищує портативність та переносимість коду клієнтської програми 
на інші платформи.  
Спрощення серверної частини також покращує масштабованість всієї 
системи, дозволяючи окремим частинам розвиватися незалежно. Трирівнева клієнт-
серверна архітектура включає представлення даних (User Interface), прикладний 
компонент (проміжне програмне забезпечення, що забезпечує прошарок між 
сервером додатку та рівнем бази даних) та рівень керування ресурсами (доступ до 
бази даних).  
72 
 
ЧДТУ.232229.021 ПЗ 
 
API REST використовує методи HTTP-запиту, такі як GET, POST, PUT і 
DELETE, що визначені в RFC 2616. Такий підхід дозволяє взаємодіяти клієнту і 
серверу без угод про протоколи.  
GET використовується для запиту ресурсів  
POST - для оновлення або зміни стану ресурсу  
PUT - для створення нових ресурсів або заміни існуючих 
DELETE - для видалення ресурсів [11] 
Після надходження запиту GET на сервер, користувач отримує відповідь у 
форматі JSON. 
Для проєктування системи був вибраний архітектурний шаблон MVC. MVC 
представляє собою схему розподілення рівнів додатку, включаючи рівень даних, 
інтерфейсу користувача та логіки додатку, розміщуючи їх у трьох окремих та 
незалежних компонентах.  
Такий підхід дозволяє внесення змін в кожен з компонентів незалежно, що 
призводить до переваг у портативності та масштабованості системи [17].  
Розглянемо компоненти MVC докладніше:  
- модель (model): надає дані для обробки та відображення і реагує на 
команди контролера, змінюючи свій власний стан;  
- представлення (view): відповідає за відображення даних, які надає модель 
користувачу, реагуючи на зміни у моделі;  
- контролер (controller): реагує на дії користувача та сповіщає модель про 
необхідність змін.  
Основною ідеєю використання цього підходу є розмежування бізнес-логіки 
(Model) від її візуального представлення (View). Це розділення сприяє принципу 
повторного використання коду. Крім того, це особливо корисно в ситуаціях, коли 
користувач має можливість бачити одні й ті ж дані одночасно, але в різних 
контекстах чи з різних точок зору. 
Модель надає дані та методи для їх обробки, такі як запити до бази даних та 
перевірка коректності отриманих даних. Вона є незалежною від представлення і не 
73 
 
ЧДТУ.232229.021 ПЗ 
 
знає, як візуалізувати ці дані. Модель також повністю ізольована від контролера і не 
має жодних точок взаємодії з користувачем, просто надаючи доступ до даних та їх 
управління [17]. Модель є абсолютною абстракцією. Вона вміє виконувати корисні 
функції, і користувач має певні потреби, які можна задовольнити за допомогою цієї 
програми. При цьому з'являються фахівці, які "знають", як використовуючи цю 
програму, здійснити те, що користувач прагне отримати.  
Ця концепція MVC принесла очевидну перевагу у чіткому розподілі логіки 
представлення (інтерфейсу користувача) і логіки програми. Коли модель публікує 
зміни, її не цікавить для кого ці зміни призначені. Вона нічого не знає про View. На 
тому кінці може бути інша підсистема, яка працює разом або окремо від View [19]. 
4.1.3 Опис структурної (функціональної) схеми 
Для відображення функціонування клієнт-серверної арітектури для 
інформаційної системи з поліагентним функціоналом, була створена структурна 
схема програми, яка зображена на відповідному рисунку (рис. 4.1). 
 
Рисунок 4.1 – Структурна схема роботи системи клієнт-серверної 
архітектури для ІС з поліагентним функціналом 
 
Структурна схема програми клієнт-серверного додатку представлена 
виглядом блок-схеми, де блоки представляють основні компоненти програми, а 
74 
 
ЧДТУ.232229.021 ПЗ 
 
стрілки показують потік управління або дані між цими компонентами. Враховуючи 
клієнт-серверну архітектуру, частина компонентів відноситься дло клієнта, частина 
до сервера. 
Cистема складається за таких основних модулів: 
- підсистема авторизації/аутентифікації (рис. 4.2); 
- підсистема створення проєкту (рис. 4.3); 
- підсистема відправлення вхідних даних на Зовнішній Сервіс (рис. 4.4); 
- підсистема опрацювання вихідних даних від Зовнішнього Сервісу 
(поліагентного) (рис. 4.5). 
 Приклад валідного кейсу для реєстрації користувача: 
Клієнт: користувач вводить свої реєстраційні дані у форму. 
Сервер: Сервер отримує запит з даними реєстрації від клієнта. 
Бізнес-логіка: Сервер перевіряє правильність введених даних, виконує перевірки. 
Сервер: Відправляє підтвердження або відмову про успішну реєстрацію клієнту. 
Клієнт: Отримує підтвердження та повідомлення про успішну або невдалу 
реєстрацію. 
 
Рисунок 4.2 –  Структурна схема роботи підсистеми авторизації/аутентифікації з 
використанням JWT 
75 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.3 – Структурна схема роботи підсистеми створення проєкту 
 
 
Рисунок 4.4 – Структурна схема роботи підсистеми відправлення вхідних даних на 
Зовнішній Сервіс 
76 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.5 – Структурна схема роботи підсистеми отримання даних з 
Зовнішнього Сервісу 
 
4.1.4. Опис логічної схеми системи 
Щоб продемонструвати функціонування клієнт-серверної арітектури для 
інформаційної системи з поліагентним функціоналом, було розроблено логічну 
схему роботи системи в цілому (рис. 4.6) і окремої частини "Інтерфейс користувача" 
(рис. 4.7), яка була втілена в рамках даного проєкту. 
В загальній логічній схемі представлено три основні компоненти системи:  
- інтерфейс користувача: цей компонент відображає взаємодію клієнтів із 
системою. Клієнт може здійснювати авторизацію, створювати проєкти, 
завантажувати дані в проєкт та виконувати моделювання. Результати 
моделювання будуть  представлені користувачу; 
- сore система: цей компонент є об'єктом проєктування та розробки в рамках 
даної роботи. Включає в себе алгоритми для побудови системи 
моделювання та їх комбінацію. Основна функція полягає в направленні 
77 
 
ЧДТУ.232229.021 ПЗ 
 
запитів Агентам для проведення моделювання та отриманні від них 
інформації; 
- агенти: ці компоненти отримують дані від Core та будують модель. 
Результати моделювання повертаються на Core. Агенти можуть 
виконувати моделювання та повертати дані на основі раніше згенерованої 
моделі. 
 
Рисунок 4.6 – Логічна схема системи (загальна) 
78 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.7 – Логічна схема роботи інтерфейсу користувача 
 
 В логічній схемі роботи інтерфейсу користувача представлено такі основні 
об’єкти:  
1 Перевірка валідності вхідних даних від зовнішнього користувача – дає 
можливість перевірити чи певний користувач має права на роботу з 
системою. 
2 Створення проєкту – дає можливість зберігати дані проєктів, які будуть 
надходити з UI. 
3 Відправка даних зі створеного проєкту Зовнішньому Сервісу. 
79 
 
ЧДТУ.232229.021 ПЗ 
 
4 Отримання та збереження результатів – дає можливість зберегти 
результати роботи агентів для подальшого використання. 
 Діаграма активності надає високорівневий огляд логічної структури 
клієнтського додатку та демонструє основні кроки взаємодії та обробки даних на 
стороні клієнта. Вона може бути деталізована або розширена відповідно до 
конкретних потреб майбутнього масштабованого проєкту. 
4.1.5 Розробка бази даних 
Для зберігання інформації використовувалася реляційна система керування 
базами даних (СКБД) PostgreSQL. PostgreSQL є відкритою програмою, написаною 
на мові програмування С, та широко використовується в високонавантажених 
системах, які вимагають надійних механізмів транзакцій та реплікації. 
Особливістью є легка інтеграція з PHP та розширений набір типів, що дозволяє 
ефективно працювати з різноманітними форматами даних, включаючи JSON. 
PostgreSQL, як і інші реляційні бази даних, підтримує функції, тригери, індексацію, 
успадкування, а також можливості партіціювання та реплікації. 
Процес проєктування бази даних може бути розбитий на три основні етапи:  
-  концептуальне, логічне і фізичне проєктування БД. 
- концептуальне проєктування – створення інформаційної моделі 
підприємства, незалежній від умов реалізації, побудова ER – діаграми; 
 
 
Рисунок 4.8 – Концептуальна модель предметної області 
80 
 
ЧДТУ.232229.021 ПЗ 
 
- логічне проєктування – конструювання інформаційної моделі 
підприємства на основі існуючих конкретних моделей даних, але без або з 
урахуванням використовуваної СУБД і інших умов фізичної реалізації, 
проведення нормалізації відносин.; 
- фізичне проєктування – опис конкретної реалізації БД, що розміщується в 
зовнішній пам'яті, опис базових відносин, організацію файлів і склад 
індексів, використовуваних для організації ефективного доступу до даним, 
а також регламентація всіх обмежень цілісності і міри захисту. 
На рисунку 4.8 представлено концептуальну модель бази даних. На основі 
концептуальної моделі бази даних створена фізична модель. Вона включає 
визначення зовнішніх ключів для кожної таблиці, які будуть встановлювати зв'язки 
між записами у різних таблицях. Таким чином, фізична модель може виявитися 
суттєво відмінною від концептуальної моделі. Усі ці трансформації спрямовані на 
зменшення обсягу бази даних, зокрема для ефективного використання обсягу пам'яті 
комп'ютера. Фізична модель бази даних представлена на рисунку 4.9. 
 
 
Рисунок 4.9 – Фізична модель бази даних 
81 
 
ЧДТУ.232229.021 ПЗ 
 
Кожна таблиця має свій основний ключ, який є мінімальним набором колонок 
для ідентифікації запису. Кожен атрибут володіє лише одним значенням. Усі 
повторювані дані, які з'являються у різних колонках, винесені в окремі таблиці. Усі 
поля, що залежать від основного ключа та будь-якого іншого поля, виділені в окрему 
таблицю. Перший та другий пункти гарантують, що база даних відповідає першій 
нормальній формі. Третій пункт вказує на відповідність другій нормальній формі, а 
четвертий пункт - на відповідність третій нормальній формі. Ця база даних 
міститиме інформацію про різні сутності, яка є необхідною для підготовки даних 
для агентів. Нижче наведено опис основних таблиць проєкту. 
User (рис. 4.10)– таблиця для збереження даних користувачів. В даній таблиці 
будуть зберігатися Identity data, які система отримає з UI від користувача. 
 
 
Рисунок 4.10 – Таблиця user 
82 
 
ЧДТУ.232229.021 ПЗ 
 
Project (рис. 4.11) – таблиця для збереження даних проєкту. В даній таблиці 
будуть зберігатися масиви даних, які система отримає з UI. І з яких в подальшому 
будуть формуватися структури даних для Зовнішнього Сервісу. 
Project_user_users (рис. 4.12) - таблиця для збереження даних проєкту. В даній 
таблиці будуть зберігатися статуси та логи по конкретному проєкту.  Ця таблиця є 
розв’язуючою для попередніх двох таблиць, тут зберігаються агругуючі результати 
вибірки для користувача, забезпечуючи цілісність даних. 
 
 
Рисунок 4.11 – Таблиця project 
83 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.12 – Таблиця project_users_user 
 
4.1.6 Розробка інтерфейсу користувача 
Після запуску, користувач потрапляє на сторінку авторизації. Після цього 
користувач має можливість або увійти в систему, або зареєструватися. Перехід на 
сторінку реєстрації передбачає заповнення всіх полів, які представлені на 
рисунку 4.13. 
 Модуль авторизації/аутентифікації представлений інтегрованим компонетом 
FireBase Authentication. Його було вирішено використати через ряд переваг: 
- простота інтеграції: Firebase Authentication надає простий та легкий у 
використанні API для автентифікації користувачів. Це спрощує процес 
інтеграції автентифікації в додаток або веб-сайт;  
- різноманітні методи автентифікації: Firebase Auth підтримує різноманітні 
методи автентифікації, такі як електронна пошта та пароль, Google, 
Facebook, Twitter та інші. Це дає користувачам можливість обирати 
зручний для них спосіб входу;  
84 
 
ЧДТУ.232229.021 ПЗ 
 
- безпека: Firebase Authentication забезпечує безпеку та захист від атак, таких 
як перехоплення сесій, шахрайство та інші загрози безпеки. Додаткова 
шарована безпека забезпечується токенами доступу;  
- соціальна автентифікація: з можливістю використання соціальних мереж 
для автентифікації, Firebase Auth спрощує процес реєстрації та входу для 
користувачів. Керування сесіями: Firebase надає зручний механізм для 
керування сесіями користувачів, що включає в себе автоматичне 
продовження сесії та вихід;  
- інструменти моніторингу та аналітики: Firebase Authentication інтегрована 
з іншими сервісами Firebase, такими як Firebase Analytics, що дозволяє 
отримувати важливі дані про активність користувачів та взаємодію з 
автентифікацією.  
В цілому, використання Firebase Authentication сприяє прискоренню розробки, 
полегшує керування автентифікацією та забезпечує безпеку вхідних даних 
користувачів. 
 
 
Рисунок 4.13 – Вікно авторизації 
85 
 
ЧДТУ.232229.021 ПЗ 
 
 Після успішного створення облікового запису та логіну - головна сторінка 
програми відкриваєтся (рис. 4.14). Дві вкладки: Home і Projects відображаються у 
веб-додатку.  
 
Рисунок 4.14 – Головне вікно програми 
 
Home вкладка: Містить статистику по проєктам користувича ("активні 
проєкти” та “всі проєкти” метрики) відображаються на вкладці Home (рис. 4.14). 
Projects вкладка: При виборі Projects вкладки - сторінка з кнопкою ‘Create 
project’ відкривається (рис. 4.15). Після натиснення на кнопку ‘Create project’ на 
вкладці відображається форма з чотирма степами: Upload, Select Data, Configuration 
i Process (рис. 4.16).  
 
 
Рисунок 4.15 – Projects вкладка 
86 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.16 – Сторінка Projects форма зі степами 
 
Перехід до наступного кроку можливе лише після проходження попереднього 
кроку і заповнення всіх необхідних полів. 
На першому кроці Upload (рис. 4.17) оберіть файл для завантаження і 
натисніть кнопку "Click to upload". Після цього програмне забезпечення 
автоматично прочитає вміст файлу, визначить назви стовпців з даними та дані 
будуть відображені на UI (рис. 4.18).  
 
 
Рисунок 4.17 – Перший крок створення проєкту 
87 
 
ЧДТУ.232229.021 ПЗ 
 
У разі відсутності необхідної інформації у файлі або якщо файл має інший 
формат, ніж .xlsx чи .xls, користувач буде сповіщений повідомленням про помилку. 
 
 
Рисунок 4.18 – Відображення завантажених даних 
 
 На другому кроці Select Data - система запропонує вам вибрати необхідні 
стовпці, дані з яких будуть відправлені для подальшого опрацювання до 
Зовнішнього Сервісу, який розробляється колегою по дипломному проєкту. Також 
обрати стовпці для результуючої таблиці (рис. 4.19). 
 
 
Рисунок 4.19 – Відображення кроку Select Data 
88 
 
ЧДТУ.232229.021 ПЗ 
 
 
 На третьому кроці Configuration (рис. 4.20) відкривається форма налаштувань 
проєкту. Де можливо налаштувати такі параметри як: Кількість спроб, Критерій 
регулярності, Дубльованість рівнів, обрати Метод синтезу, Метод розбиття 
послідовності, Тип оцінки моделі та відмітити чекбоксом чи опитувати дубльовані 
рівні.  
 
 
Рисунок 4.20 – Відображення кроку Configuration 
 
 Обраний Метод синтезу можна налаштувати за допомогою спливаючих 
модальних вікон, відмічаючи чекбоксами необхідні параметри та вводячи їх 
значення у поля (рис. 4.21, рис.  4.22)   
 
89 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рисунок 4.21 – Налаштування Метод синтезу  
 
 
Рисунок 4.22 – Налаштування Метод синтезу  
 
Kрок Process відображає прогрес мапу (рис. 4.23) після того як пройдуть всі 
етапи прогрусу і прогрус отримає статус Done - результат обробки відображається 
на екрані. 
90 
 
ЧДТУ.232229.021 ПЗ 
 
 
 
Рисунок 4.23 – Відображення кроку Process 
 
4.1.7 Опис розробки програмних компонентів 
Проєкт має frontend та backend частини. Кожна частина системи складається з 
різної кількості компонентів чи модулів, організованих у визначену структуру. 
Файлова структура frontend частини зображено на рисунку 4.24. 
 
 
91 
 
ЧДТУ.232229.021 ПЗ 
 
Рисунок 4.26 –  Свагер та ендпоінти системи 
Також для ефективної взаємодії з сервером було реалізовано свагер (рис. 4.26). 
Swagger допомагає зробити роботу з веб-сервісами більш ефективною, 
консистентною та легкою для розуміння. 
 
 
Рисунок 4.24 – Файлова структура компонентів frontend частини 
 
Файлова структура backend частини зображено на рис. 4.25. 
92 
 
ЧДТУ.232229.021 ПЗ 
 
 
Рис. 4.25 –  Файлова структура модулів backend чатини 
 
Нижче представлено лістинг основного модуля проєкту - ProjectService. 
Забезпечено створення проєктів, редагування проєктів та пошук проєкту для 
користувача. 
 
@Injectable() 
export class ProjectService { 
  @InjectRepository(ProjectEntity) 
  private readonly projectRepository: Repository<ProjectEntity>; 
 
  @Inject() 
93 
 
ЧДТУ.232229.021 ПЗ 
 
  private readonly polyAgentService: PolyAgentService; 
 
  findOne(id: string) { 
    return this.projectRepository.findOne({ 
      where: { id }, 
    }); 
  } 
 
  findAllForUser(user: UserEntity) { 
    return this.projectRepository.find({ 
      where: { 
        createdBy: { id: user.id }, 
      }, 
      relations: ['createdBy'], 
    }); 
  } 
 
  async create(project: Partial<ProjectEntity>, user: UserEntity) { 
    await this.polyAgentService.createProject(project); 
 
    return this.projectRepository.save({ 
      ...project, 
      createdBy: user, 
    }); 
  } 
 
  update(id: string, project: Partial<ProjectEntity>) { 
    const current = this.projectRepository.findOne({ where: { id } }); 
    return this.projectRepository.save({ ...current, ...project }); 
  } 
} 
 
 
4.2 Тестування системи 
Тестування програмного забезпечення – це процес, який спрямований на 
визначення відповідності фактичного програмного продукту очікуваним вимогам та 
забезпечення відсутності дефектів. Цей процес включає в себе виконання 
програмних та системних компонентів за допомогою ручних або автоматизованих 
94 
 
ЧДТУ.232229.021 ПЗ 
 
інструментів для оцінки однієї або кількох властивостей, що представляють 
інтерес [18]. 
Етап тестування нового програмного забезпечення є важливим етапом в 
процесі його розробки та впровадження. 
4.2.1 Модульне тестування 
Модульне тестування, відоме також як "Unit testing", є методом тестування 
програмного забезпечення, який передбачає індивідуальне тестування кожного 
модуля програмного коду [15]. У цьому дослідженні для виконання тестування 
програмного додатку було вибрано використання фреймворку Jest. Jest є 
платформою для тестування JavaScript, розробленою для забезпечення правильності 
будь-якої кодової бази JavaScript. Він дозволяє писати тести за допомогою зручного, 
знайомого та функціонально багатого API, який швидко надає результати [16]. 
Під час розробки програмного додатку був впроваджений ефективний 
алгоритм для зміни послідовності елементів. Також були розроблені тести, які 
перевіряють правильність роботи цього алгоритму. Файл "reorder-elements.spec.ts" 
містить приклади коду для проведення цих тестів: 
 
import { reorderObjs } from '@root/utils/reorder-elements'; 
describe('Test reorder algorithm', () => {  
it('test case 1 inverse start order', () => {  
const ordList = [1, 2, 3, 4, 5];  
const objs = [{ id: 1, ord: 5 },{ id: 2, ord: 4 },{ id: 3, ord: 3 },{ id: 
4, ord: 2 },{ id: 5, ord: 1 }] 
 
Першою лінією коду імпортується файл, який включає в себе реалізацію 
алгоритму. Наступний рядок містить команду describe('Test reorder algorithm', що 
визначає набір тестів. Далі, другим аргументом функції describe, передається 
функція, в якій описані окремі тест-кейси. Лінія коду it('test case 1 inverse 
start order') оголошує конкретний тест-кейс. У даному прикладі це тест, який 
перевіряє роботу алгоритму при повністю інвертованій послідовності у вихідному 
95 
 
ЧДТУ.232229.021 ПЗ 
 
масиві. Далі відбувається ініціалізація змінних із тестовими вхідними даними. 
const ordList = [1, 2, 3, 4, 5] представляє собою масив послідовності 
ідентифікаторів об'єктів, який очікується після виконання алгоритму. const objs 
= [{ id: 1, or...] - це початковий масив об'єктів у визначеній послідовності. 
Далі відбувається виклик функції reorderObjs та перевірка результату її виконання. 
Приведено приклад коду:  
reorderObjs(ordList, objs);  
const expectedObj = [ { id: 1, ord: 1 }, { id: 2, ord: 2 }, { id: 3, ord: 
3 },{ id: 4, ord: 4 },{ id: 5, ord: 5 }];  
expectedObj.forEach(obj => expect(objs).toContainEqual(obj));}); 
 
 У першому рядку викликається функція reorderObjs(ordList, objs). На 
наступному рядку оголошується змінна з очікуваним масивом, який має бути в 
результаті правильного виконання функції. Останньою лінією тест-кейсу є 
expectedObj.forEach(o..., де проводиться перевірка, чи відповідає отриманий об'єкт 
очікуваному. Якщо це так, тест вважається успішно виконаним; у протилежному 
випадку тест вважається невдалим, що відображається в логу під час виконання всіх 
тестів. У процесі тестування було розроблено 6 тест-кейсів. 
4.2.2 Інтеграційне тестування 
У цьому дослідженні, окрім проведення модульного тестування, також 
розроблені автоматичні тести для інтеграційного тестування. Інтеграційне 
тестування визначається як тип тестування, при якому програмні модулі логічно 
поєднані та піддавані тестуванню як єдина група. У звичайному програмному 
проєкті, що складається з різних програмних модулів, що кодуються різними 
розробниками, цей рівень тестування спрямований на виявлення дефектів у 
взаємодії між цими програмними модулями під час їхньої інтеграції [17]. 
Оскільки у програмному додатку присутній сервер, що надає конкретний 
REST API для взаємодії, важливо розробити тести, які перевіряють правильність 
функціонування кожного запиту. Це набуває особливого значення, оскільки у 
майбутньому можуть бути розроблені нові клієнти для взаємодії з системою. У 
96 
 
ЧДТУ.232229.021 ПЗ 
 
випадку, якщо REST API не відповідає специфікаціям, після виявлення та 
виправлення помилки в його роботі, слід буде внести зміни у всі наявні клієнти.  
При реалізації інтеграційних тестів необхідно запускати сервер в ізольованому 
середовищі так, щоб попередній запуск тестів не впливав на наступний. У процесі 
вирішення цієї проблеми виникла складність щодо збереження запитів з 
попереднього запуску тестів. Одним з можливих вирішень цієї проблеми є очищення 
бази даних перед початком тестування. Однак видалення даних з продакшн бази 
даних заради тестів може бути небезпечним, тому для цілей тестування буде 
використовуватися інша база даних. Вирішено скористатися можливістю ORM 
бібліотеки Sequelize, яка сумісна з різними системами управління базами даних. 
Нижче подано приклад коду ініціалізації Sequelize у файлі db.ts: [код ініціалізації 
Sequelize] 
import config from '@root/config';  
const sequelize = config.SEQUELIZE.dialect  
? new Sequelize(config.SEQUELIZE.dialect, config.SEQUELIZE.config) : new 
Sequelize(config.SEQUELIZE.config);  
export default sequelize; 
 
В даному прикладі імпортується конфіг для ініціалізації, та відбувається 
створення нового екземпляру класу Sequelize. Опис кофінгу для ініціалізації файл 
config.ts: 
switch (env) {  
case 'test': return { dialect: 'sqlite::memory',  
config: {...ormConfig, storage: process.env.TEST_DB_STORAGE}  
default: 
 
У даному прикладі змінна "env" містить значення стандартної змінної 
оточення вузла. Залежно від значення цієї змінної, конфігурація, за якою 
ініціалізується бібліотека Sequelize, змінюється. У прикладі, параметр "dialect" 
вказаний як "sqlite::memory", що представляє одну з можливостей бібліотеки 
97 
 
ЧДТУ.232229.021 ПЗ 
 
Sequelize. Приведений нижче є приклад реалізації одного з тест-кейсів REST API у 
файлі "index.spec.ts":  
it('Create user', async () => { 
const userData = { ...MockUserData };  
const createResult = await request(app)  
.post('/api/auth/signup').send(userData)  
.expect(200);  
const id = createResult.body.user.id;  
const userResult = await User.findOne({ where: { id } }); 
expect(userResult).toMatchObject({ ...MockUserData }); }); 
 
У цьому прикладі проводиться перевірка правильності виконання запиту на 
створення нового користувача за адресою "/api/auth/signup". Змінна "MockUserData" 
містить дані тестового користувача.  
Функція "request(app)" отримує в якості аргументу екземпляр класу express, 
який реалізує REST API. Ця функція повертає об'єкт із зручними методами для 
виклику необхідних запитів. У наступних двох рядках відбувається відправлення 
запиту із вказаними даними. Рядок ".expect(200)" показує, що цей запит очікується 
виконатися із статусом 200. Потім, в наступних двох рядках, виконується запит до 
бази даних для отримання інформації про користувача, якого має створити 
перевіряємий запит. З останнім рядком здійснюється перевірка правильності 
отриманих даних користувача. 
У ході виконання дипломної роботі було реалізовано 4 набори тестів, та 21 
тест кейс. Всі тести проходять успішно. 
4.2.3 Системне тестування 
У цьому дослідженні була розроблена лише частина великої системи, 
конкретно - UI частина та модуль авторизації FireBase Auth.  
98 
 
ЧДТУ.232229.021 ПЗ 
 
Велика кількість людей буде використовувати продукт, і першим етапом їх 
взаємодії буде модуль авторизації. Отже, першою функціональністю, яку буде 
перевірено, буде модуль авторизації.  
Перевірка функціоналу клієнтської частини виконувалася вручну. Під час 
кожного тесту проводилася перевірка роботи клієнта на популярних браузерах 
сьогодення, таких як Chrome, Firefox та Safari. Неавторизований користувач, 
переходячи за посиланням, повинен завжди потрапляти на екран авторизації, 
незалежно від того, який шлях в URL вказаний.  
Було проведено перевірку переходу неавторизованим користувачем за 
посиланнями. У всіх випадках клієнт відповідав коректно, і відображався екран 
авторизації. Перевірка обробки невірних даних авторизації включала кілька спроб 
авторизації за допомогою різних неправильних даних. У всіх ситуаціях клієнт 
відповідав вимогам, а саме виводив повідомлення про помилку (рис. 4.27). 
 
 
Рисунок 4.27 – Повідомлення системи при спробі авторизуватися 
неавторизованим користувачем 
99 
 
ЧДТУ.232229.021 ПЗ 
 
 
 Перевірка функціоналу авторизації із валідними даними для входу до системи 
включала авторизацію за допомогою різних користувачів. У всіх випадках клієнт 
взаємодіяв з системою коректно: після авторизації відображався головний екран із 
списком дошок, доступних конкретному авторизованому користувачу (рис. 4.28).  
 
 
Рисунок 4.28 – Головний екран програми 
 
4.2.3 Кросбраузерне тестування 
Згідно вказаних нефункціональних вимог даний додаток має працювати у 
таких браузерах: Chrome, Opera, FireFox, Enternet Explorer. Було проведено смоук 
тестування основних модулів у цих браузерах. Тестування пройшло успішно, 
відхилень не виявлено. Додоток працює ідентично в усіх браузерах для тестування. 
4.2.3 Приймальне тестування 
Наразі неможливо здійснити цей тип тестування, оскільки приймальне 
тестування проводиться організацією, відповідальною за інсталяцію, і система ще не 
була впроваджена. 
100 
 
ЧДТУ.232229.021 ПЗ 
 
 4.3 Приклади впровадження програмного комплексу 
Розроблений у цьому проєкті додаток є частиною більшої системи, яка 
складається з кількох підсистем. Усі ці підсистеми наразі перебувають на етапі 
інтенсивної розробки та вдосконалення і передбачається їх впровадження в 
найближчому майбутньому. 
  
101 
 
ЧДТУ.232229.021 ПЗ 
 
ВИСНОВКИ 
Основна мета даної дипломної роботи досягнута – розроблено клієнт-серверну 
архітектуру для інформаційної системи з поліагентним функціоналом. Cтворенo 
ефективну структуру, яка забезпечує оптимальну взаємодію та співпрацю між 
різними компонентами системи на основі агентної парадигми. Оскільки реалізована 
система являється окремим MVP модулем, який інтегруватиметься у глобальну 
систему i в розрізі даної роботи повністю реалізовано UI частину глобальної системи 
- то імплементована клієнт-серверна архітектура дозволяє поєднати модулі та 
оптимізувати взаємодію агентів у системі та обмін інформацією. 
В якості основних результатів магістерської роботи можна виділити наступні: 
проведено моніторинг та аналіз  різних сучасних реалізацій інформаційних систем з 
поліагентним функціоналом. Детальніше був розглянутий клієнт-серверний метод 
реалізації, тому що саме цей метод являється оптимальним для подальшої розробки  
даної роботи, адже він покриває головні вимоги до подібних систем: 
- ефективність та продуктивність: оцінка швидкодії та продуктивності 
системи з поліагентним функціоналом. Вивчення часу відгуку, обсягів 
обробки даних та розподілення завдань між агентами;  
- безпека: аналіз системи на предмет вразливостей та заходів безпеки. 
Оцінка механізмів аутентифікації, авторизації та шифрування для захисту 
конфіденційності та цілісності даних;  
- масштабованість: вивчення можливості системи масштабуватися для 
обробки зростаючої кількості користувачів, об'єму даних або великої кількості 
агентів. 
Аналіз дозволив проаналізувати основні недоліки інших запропонованих 
програмних та інтерфейсних рішень. Насамперед, аналіз показав, що деякі системи 
мають проблеми з масштабованістю при великій кількості агентів, що може 
обмежити їх потенційне застосування в областях з високим обсягом даних та 
великою кількістю користувачів.  
102 
 
ЧДТУ.232229.021 ПЗ 
 
На основі проведеного дослідження та виділених вимог було прийнято 
рішення розробити багаторівневу клієнт-серверну архітектуру з тонким клієнтом 
для клієнт-серверної архітектури для ІС з поліагентним функціоналом. Це 
архітектурне вирішення обрано через його спроможність забезпечити максимальну 
гнучкість та швидкість впровадження змін, а також його високий потенціал 
масштабування.  
При такій архітектурі можна використовувати оптимальні підходи 
“спілкування” між різними модулями системи, що дозволяє зменшити пряму 
взаємодію агентів із ядровим сервісом і надає системі більшу гнучкість та 
масштабованість. 
Також у розрізі проведення експерементальних досліджень було проведено 
оптимізацію запитів для забезпечення максимальної безпеки даних в БД та 
підвищення загальної продуктивності системи. 
Було виконано моделювання системи, де кожен етап моделювання 
ілюстровано відповідними діаграмами відповідно до установлених вимог. Описано 
послідовність дій в проєктованому об'єкті, яка призводить до визначених 
результатів. Здійснено моделювання предметної області та сформульовано вимоги 
до програмного забезпечення. Проведено проєктування логічної структури та 
архітектурне проєктування. На основі отриманих діаграм отримано чітке уявлення 
про те, як система повинна функціонувати та реагувати на різні ситуації, як повинні 
взаємодіяти компоненти системи. 
В майбутньому, коли модулі будуть зібрані у глобальну систему -  аналіз 
результатів може слугувати для внесення змін в модель, для поліпшення її точності 
та релевантності.  
Також було виконано проєктування та моделювання бази даних для додатку, 
яке повністю охоплює всі необхідні функціональні вимоги. Була розроблена 
концептуальна модель бази даних, на основі якої було побудовано фізичну модель з 
повним описом всіх таблиць. 
103 
 
ЧДТУ.232229.021 ПЗ 
 
Розроблений додаток взаємодіє з Зовнішнім поліагентним сервісом, 
відправляючи запити та отримуючи від них відповіді.  
Для Впровадження додатку використовувало технології NestJS та TypeScript 
для бекенду, VueJS, TypeScript, Ant Design Vue для фронтенду та стилізації, 
PostgreSQL було обрано в якості системи управління базами даних.FireBase Auth - 
для реєстрації аунтетифікації та авторизації з JWT токеном, JS xls reader для 
зчитування xls файлу з даними. 
Проведено тестування системи, включаючи модульне тестування, системне 
тестування, кросбраузерне тестування. Результати тестування підтверджують 
правильність роботи інформаційної системи в цілому та окремих її модулів. 
  
104 
 
ЧДТУ.232229.021 ПЗ 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Авраменко В. С., Голуб С. В.,  Салапатов В. І. Виконання та оформлення 
випускних робіт. Освітній ступінь «Магістр» : навчально-методичний посібник. 
Черкаси: Черкаський національний університет ім. Б. Хмельницького, 2018. 242 с. 
2. Xiang, Y. A Survey of Active and Passive Defence Mechanisms against DDoS 
Attacks : Technical Report, TR C04/02 I Y. Xiang, W. Zhou, M. Chowdhury. –  Deakin 
University, Australia, 2004. 
3. MittaI, P. Defense against Distributed Denial of Service Attacks : a seminar report. 
– Department of Computer Science and Engineering. Indian Institute of Technology, 2005. 
– 20 p. 
4. Mirkovic J. A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms: 
Technical report #020018 I J. Mirkovic, J. Martin, P. Reiher. – Computer Science 
Department. University of California, 2002. – 16 p. 
5. Erik Nygren The Akamai Network: A Platform for High-Performance Internet 
Applications Ramesh K. Sitaraman, and Jennifer Sun. – ACM SIGOPS Operating Systems 
Review, vol. 44, no. 3, July 2010. 
6. Cabrera, J.B.D. Proactive detection of distributed denial of service attacks using mib 
traffic variables – a feasibility study I J.B.D. Cabrera, L. Lewis, X. Qin et al. II Proc.of 
International Symposium on Integrated Network Management. Seattle, 14–18 May. 2001. 
– Piscataway: IEEE, 2001. – P. 609– 622. 
7. Ioannidis, J. Implementing Pushback: Router-Based Defense Against DDoS Attacks 
I J. loannidis, S.M. Bellovin II Proc. of Symposium of Network and Distributed Systems 
Security (NDSS). San Diego, 6-8 February 2002. − [S. 1.: s. п.], 2002.-P. 57-71. 
8. Manajan, R. Controlling High Bandwidth Aggregates in the Network: ICSI 
Technical Report I R. Manajan, S.M. Bellovin, S. Floyd et al. − ICSI, 2001.-16. 
9. CoIIins, M. An Empirical Analysis of Target-Resident DoS Filters I M. Collins, 
M.K. Reiter If Proc. of  2004 IEEE Symposium on Security and Privacy (S&P'04). 
Oakland, May  9 –12, 2004. – Piscataway: IEEE, 2004. – P. 103–114. 
105 
 
ЧДТУ.232229.021 ПЗ 
 
10. Krishnamurthy, B. On network-aware clustering of Web clients I B. Krishnamurthy, 
J. Wang II Proc. of ACM SIGCOMM 2000. Stockholm 28 August – 1 September, 2000. – 
[USA]: ACM publishing, 2000. – P. 97–110. 
11. Jin, C. Hop-count filtering: An effective defense against spoofed DDoS traffic I C. 
Jin, H. Wang, K.G. Shin II Proc. of 10th ACM Conference on Computer and 
Communications Security. Washington, October 27-30, 2003.–[USA]: ACM publishing, 
2003. -P. 30-41. 
12. Xuan, D. A Gateway-Based Defense System for Distributed DoS Attacks in High 
Speed Networks I D. Xuan, R. Bettati, W. Zhao II Proc. of 2nd IEEE SMC Information 
Assurance Workshop. West Point, NY, June, 2001.–Piscataway : IEEE, 2001.-P. 212-219. 
13. Kang, J. Protect E-Commerce against DDoS Attacks with Improved DWARD 
Detection System I J. Kang, Z. Zhang, J. Ju II Proc. of 2005 IEEE International Conference 
on e-Technology, e-Commerce and e-Service. HongKong, 29 March − 1 April, 2005. − 
Piscataway: IEEE, 2005.–P. 100-105. 
14. Mirkovic, J. A Taxonomy of DDoS Attacks and Defense Mechanisms / J.Mirkovic, 
P. Reiher II ACM SIGCOMM Computer Communications Review. − 2004.–Vol. 34; no. 
2.–P. 643-666. 
15. Cisco Guard DDoS Mitigation Appliances URL: http://www.cisco.com/web/RU/pr
oducts/ps5888/index.html 
16. Iptables Tutorial 1.2.2 URL: https://www.frozentux.net/iptables-tutorial/iptables-
tutorial.html 
17. Модуль ngx_http_limit_zone_module URL: http://nginx.org/ru/docs/http/ngx_http
_limit_zone_module.html 
18. mod_evasive – защита от DOS и DDoS-атак URL: 
http://muff.kiev.ua/content/modevasive-zashchita-ot-dos-i-ddos-atak 
19. DDOS Deflate URL: http://deflate.medialayer.com/ 
20. DDoS-атаки URL: http://localname.ru/soft/atakitipa-otkaz-v-obsluzhivanii-dos-i-
raspredelennyiy-otkaz-v-obsluzhivaniiddos.html 
106 
 
ЧДТУ.232229.021 ПЗ 
 
21. Предотвращение атак с распределенным отказом в обслуживании 
(DDoS): URL: http://www.cisco.com/web/RU/products/ps5887/products_white_paper09
00aec d8011e927_.html 
22. DDoS-атаки в третьому кварталі 2018 року. URL: https://securelist.ru/ddos-
report-in-q3-2018/92512/ 
23. Microservices vs. Monolithic [Електронний ресурс]. – Точка доступу: URL: 
https://ncube.com/microservices-vs-monolithic-which-architecture-suits-best-for-your-
project/ 
107