1. Repository at ChSTU
  2. Випускні кваліфікаційні роботи
  3. Магістр
  4. 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/8929
Повний запис метаданих
Поле DCЗначенняМова
dc.contributor.advisorНемченко, Вадим В'ячеславович-
dc.contributor.authorЛевченко, Сергій Петрович-
dc.date.accessioned2026-03-22T11:31:50Z-
dc.date.available2026-03-22T11:31:50Z-
dc.date.issued2023-12-19-
dc.identifier.urihttps://er.chdtu.edu.ua/handle/ChSTU/8929-
dc.description.abstractАНОТАЦІЯ Левченко С. П. Інформаційна система з поліагентним функціоналом 121 «Інженерія програмного забезпечення» Черкаський державний технологічний університет Черкаси 2023 В даній роботі представлені етапи проектування та реалізації інформаційної система з поліагентним функціоналом. Описані архітектура системи та спосіб комунікації з агентами який був реалізований для створення даного програмного продукту. Дана система буде досить зручною у використанні як досвідченим так і звичайним користувачам ПК.uk_UA
dc.description.abstractANNOTATION Levchenko S. P. Information system with multi-agent functionality 121 "Software engineering" Cherkasy State Technological University Cherkasy 2023 This paper presents the design and implementation of the information system with multi-agent functionality. The architecture of the system and the method of communication with agents, which was implemented to create this software product, are described. This system will be very convenient to use as an experienced and regular PC users.uk_UA
dc.language.isoukuk_UA
dc.subjectМОНОЛІТНА АРХІТЕКТУРАuk_UA
dc.subjectМІКРОСЕРВІСНА АРХІТЕКТУРАuk_UA
dc.subjectПОЛІАГЕНТНИЙ ФУНКЦІОНАЛuk_UA
dc.subjectКОМУНІКАЦІЯ З АГЕНТАМИuk_UA
dc.subjectMONOLITHIC ARCHITECTUREuk_UA
dc.subjectMICROSERVICE ARCHITECTUREuk_UA
dc.subjectPOLYAGENT FUNCTIONALITYuk_UA
dc.subjectCOMMUNICATION WITH AGENTSuk_UA
dc.titleІнформаційна система з поліагентним функціоналомuk_UA
dc.typeMaster Thesisuk_UA
Розташовується у зібраннях:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:
Файл Опис РозмірФормат 
Кваліфікаційна робота магістра Левченко Сергій Петрович.pdf
  Restricted Access		2.18 MBAdobe PDFПереглянути/Відкрити    Запит копії
Показати базовий опис матеріалу Перегляд статистики


Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
 
на тему:  Інформаційна система з поліагентним функціоналом 
 
 
Виконав: студент 2 курсу, групи МПЗ-2204 
Напряму підготовки  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Левченко С.П. 
 (прізвище та ініціали) 
Керівник  Немченко В.В. 
 (прізвище та ініціали) 
Рецензент  Паньковецький А.В. 
 (прізвище та ініціали) 
 
 
 
 
 
 
Черкаси 2023 
АНОТАЦІЯ 
Левченко С. П. 
Інформаційна система з поліагентним функціоналом  
121 «Інженерія програмного забезпечення» 
Черкаський державний технологічний університет 
Черкаси 2023 
В даній роботі представлені етапи проектування та реалізації 
інформаційної система з поліагентним функціоналом. Описані архітектура 
системи та спосіб комунікації з агентами який був реалізований для створення 
даного програмного продукту. Дана  система буде досить зручною у 
використанні як досвідченим так і звичайним користувачам ПК.  
Ключові слова: МОНОЛІТНА АРХІТЕКТУРА, МІКРОСЕРВІСНА 
АРХІТЕКТУРА, ПОЛІАГЕНТНИЙ ФУНКЦІОНАЛ, КОМУНІКАЦІЯ З 
АГЕНТАМИ. 
ANNOTATION 
Levchenko S. P. 
Information system with multi-agent functionality 
121 "Software engineering" 
Cherkasy State Technological University 
Cherkasy 2023 
This paper presents the design and implementation of the information system 
with multi-agent functionality. The architecture of the system and the method of 
communication with agents, which was implemented to create this software product, 
are described. This system will be very convenient to use as an experienced and regular 
PC users. 
Keywords: MONOLITHIC ARCHITECTURE, MICROSERVICE 
ARCHITECTURE, POLYAGENT FUNCTIONALITY, COMMUNICATION WITH 
AGENTS. 
 
ЧДТУ.232230.014 ПЗ 
 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ............................................................. 6 
ВСТУП ............................................................................................................... 7 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................... 10 
1.1 Огляд існуючих методів та засобів ...................................................... 10 
1.2 Аналіз існуючих в світі аналогів інформаційних технологій ........... 15 
Висновки до розділу .................................................................................... 20 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 21 
2.1 Дослідження архітектури інформаційних систем .............................. 21 
2.2 Дослідження способів комунікації з агентами ................................... 27 
2.3 Дослідження типів оцінки моделей ..................................................... 31 
2.4 Експериментальні дослідження комунікації агентів ......................... 33 
Висновки до розділу .................................................................................... 40 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЬ ТА 
ПРОЕКТУВАННЯ СИСТЕМИ ............................................................................... 41 
3.1 Моделювання предметної області ....................................................... 41 
3.1.1 Модель предметної області. Словник предметної області.......... 41 
3.1.2 Елементи моделювання предметної області................................. 42 
3.1.3 Робоча область моделювання ......................................................... 44 
3.2 Формування та аналіз вимог ................................................................ 45 
3.2.1 Первинні вимоги замовника ........................................................... 46 
3.2.2 Детальні вимоги розробника .......................................................... 46 
3.2.3 Функціональні вимоги .................................................................... 47 
3 
 
ЧДТУ.232230.014 ПЗ 
 
3.2.4 Нефункціональні вимоги ................................................................ 48 
3.3 Формування вимог за допомогою діаграми прецедентів .................. 48 
3.4 Проектування логічної структури програмного комплексу.............. 49 
3.4.1 Діаграми класів ................................................................................ 50 
3.4.2 Діаграми пакетів .............................................................................. 51 
3.5 Архітектурне проектування.................................................................. 53 
3.5.1 Діаграма компонентів ..................................................................... 54 
3.5.2 Розгортання програмної системи. Діаграма розгортання ........... 55 
3.6 Моделювання поведінки системи ........................................................ 57 
3.6.1 Діаграма діяльності ......................................................................... 57 
3.6.2 Діаграма послідовності ................................................................... 59 
3.6.3 Діаграма комунікації ....................................................................... 60 
3.6.4 Діаграма скінченного автомату ..................................................... 61 
Висновки до розділу .................................................................................... 62 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ...................................................................................................... 63 
4.1 Розробка програмного комплексу........................................................ 63 
4.1.1 Обґрунтування вибору засобів реалізації ..................................... 63 
4.1.2 Опис структурної (функціональної) схеми ................................... 65 
4.1.3 Опис логічної схеми системи ......................................................... 68 
4.1.4 Розробка бази даних ........................................................................ 70 
4.1.5 Розробка інтерфейсу користувача ................................................. 76 
4.1.6 Опис розробки програмних компонентів ..................................... 77 
4.2 Тестування системи ............................................................................... 80 
4 
 
ЧДТУ.232230.014 ПЗ 
 
4.2.1 Модульне тестування ...................................................................... 80 
4.2.2 Інтеграційне тестування ................................................................. 81 
4.2.3 Системне тестування....................................................................... 81 
4.2.3 Приймальне тестування .................................................................. 87 
4.3 Приклади впровадженого програмного комплексу ........................... 87 
Висновки до розділу .................................................................................... 88 
ВИСНОВКИ .................................................................................................... 89 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ...................................................... 91 
ДОДАТОК А ................................................................................................... 93 
ДОДАТОК Б .................................................................................................... 95 
ДОДАТОК B ................................................................................................... 97 
 
5 
 
ЧДТУ.232230.014 ПЗ 
 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
IC  Інформаційна система 
RDBMS Реляційні бази даних  
JADE Java Agent Development Framework 
FIPA  Foundation for Intelligent Physical Agents 
UI  User interface 
Core  Головна Backend частина 
Unit  Модуль  
 
 
  
6 
 
ЧДТУ.232230.014 ПЗ 
 
ВСТУП 
Сучасний світ переживає стрімкий розвиток інформаційних технологій та 
збільшення обсягів інформації, що щоденно генерується і обробляється. 
Інформаційні системи вже не є просто інструментами для обробки даних, а 
стають складними, інтелектуальними системами, які можуть розуміти та 
взаємодіяти з користувачами та іншими системами.  
Актуальність роботи. Актуальність ІС з поліагентним функціоналом 
полягає в потужному потенціалі для вирішення складних завдань. Який 
забезпечується завдяки ефективній співпраці різних агентів, що можуть діяти 
автономно та спільно вирішувати завдання. Концепція поліагентного 
функціоналу є важливим інструментом у розвитку штучного інтелекту, адже 
вона дозволяє моделювати складні взаємодії для спільного прийняття рішень, 
використовуючи  розумних агентів.  
Використання агентів у інформаційних системах дозволяє створювати 
автономні програмні сутності, які можуть взаємодіяти між собою та з 
користувачами для досягнення конкретних цілей. Ця концепція поліагентності 
надає системам властивість адаптуватися до змінних умов, забезпечуючи більшу 
гнучкість та швидкість реакції [1, 2]. 
У цьому контексті інформаційні системи з поліагентним функціоналом 
стають особливо актуальними. 
Метою даної роботи є розробка інформаційної системи з поліагентним 
функціоналом, що дозволить динамічно поєднувати між собою агенти та 
забезпечувати процес їх побудови та використання. 
Завдання дослідження: 
- проектування  архітектури системи, яка підвищить відмовостійкість та 
забезпечить прозоре масштабування; 
- проектування та реалізація способу комунікації системи з агентами, 
який дозволить зменшити пряму взаємодію між агентами та зробить систему 
більш гнучкою та масштабованою. 
7 
 
ЧДТУ.232230.014 ПЗ 
 
Об‘єктом дослідження є інформаційна система з поліагентним 
функціоналом для забезпечення процесу її вивчення та аналізу можливостей, 
характеристик та результатів використання. 
Предметом дослідження є конкретні архітектурні рішення для побудови 
системи та способи комунікації системи з різними агентами, а також їх вплив на 
функціонування системи в цілому. 
Методи досліджень. Для досягнення поставленої мети застосовано такі 
методи: порівняння і спостереження – під час вивчення існуючих типів 
архітектур та способів комунікації сервісів; моделювання, системний підхід та 
формалізація – при побудові моделі проектованої системи; декомпозиція – при 
розбитті системи на підсистеми, для аналізу властивостей кожної з підсистем.  
Наукова новизна отриманих результатів полягає в можливості 
динамічного поєднання різної кількості агентів для аналізу різнотипних вхідних 
даних. При цьому підготовка та формування вхідних масивів даних для агентів 
буде здійснювати сама система на основі налаштувань користувача. 
Практичне значення одержаних результатів. Описані рішення можуть 
бути використані для проектування та реалізації систем будь-якої складності та 
в багатьох галузях. 
Розглянуті архітектурні підходи дозволять спроектувати різного роду 
інформаційні системи, з врахуванням складності системи та наявних ресурсів. 
Способи комунікації сервісів дають можливість до масштабування систем, 
які повинні витримувати велике навантаження. 
Особистий внесок автора. Всі результати, що подані в даній роботі, 
отримані автором особисто. До особистих досягнень можна віднести архітектуру 
системи з впровадженими алгоритмами та побудову інтерфейсу комунікації між 
сервісами. 
Участь в I Міжнародній науково-практичній конференція “SCIENCE AND 
SOCIETY: MODERN TRENDS IN A CHANGING WORLD”, 18-20.12.2023 на 
8 
 
ЧДТУ.232230.014 ПЗ 
 
тему: "Aгентно-орієнтована інформаційна система на основі генеративних 
нейронних мереж" (результати конференції у формі тез). 
Кваліфікаційна робота складається з вступу, чотирьох розділів, висновків, 
списку використаних джерел в кількості 20. Робота містить 64 рисунки, 4 таблиці 
та 3 додатки. Загальний обсяг роботи викладено на 99 сторінках. 
  
9 
 
ЧДТУ.232230.014 ПЗ 
 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Огляд існуючих методів та засобів 
Розв'язання завдань, пов'язаних з інформаційними системами з 
поліагентним функціоналом, може вимагати різних методів та підходів, залежно 
від конкретної задачі і сфери застосування. Далі наведені  деякі існуючі методи 
розв'язання таких завдань: 
Розробка агентних архітектур – створення архітектури системи з 
визначенням ролей та взаємодії агентів [8]. Розробка моделей агентів та їх 
функціональності. Агентна архітектура визначає структуру та організацію 
агентів у системі, їх функціональні ролі, способи взаємодії та спрямована на 
досягнення конкретних цілей. Далі буде описано деталізовану інформація про 
розробку агентних архітектур: 
1 Визначення цілей та вимог. Перший крок у розробці агентної 
архітектури – це чітке визначення цілей системи та вимог, які повинні бути 
задоволені. Це може включати в себе функціональні, продуктивність, безпеку, 
масштабованість тощо. 
2 Ідентифікація агентів. Потім потрібно ідентифікувати агентів, які 
будуть взаємодіяти в системі. Кожен агент повинен мати чітку роль та 
функціональність. 
3 Архітектурний дизайн. Розробка архітектури системи, включаючи 
розміщення та зв'язки між агентами. Це включає в себе вибір архітектурного 
стилю (наприклад, централізована, розподілена, багаторівнева) та паттернів для 
організації агентів. 
4 Визначення способів взаємодії. Розробка протоколів та механізмів для 
взаємодії між агентами. Це може включати в себе комунікацію, координацію та 
обмін повідомленнями. 
10 
 
ЧДТУ.232230.014 ПЗ 
 
5 Вибір технологій. Вибір технологій та інструментів, які 
використовуються для реалізації агентів та агентної архітектури. Це може 
включати в себе мови програмування, платформи, фреймворки та інші 
інструменти. 
6 Розробка агентів. Створення агентів, включаючи їхню програмну 
реалізацію та взаємодію. Кожен агент повинен мати логіку та знання, які 
дозволяють йому виконувати свої функції. 
Розробка агентних архітектур є важливим етапом у створенні 
інформаційної системи з поліагентним функціоналом і вимагає уважного 
проектування, вибору технологій та тестування для забезпечення ефективності 
та функціональності системи. 
Керування агентами – визначення стратегій та правил для керування 
агентами в системі, включаючи реакцію на зміни у середовищі [9]. Детальніше 
розглянемо, що означає керування агентами: 
1 Визначення ролей та взаємодії агентів. Керування агентами 
передбачає визначення ролей та функцій кожного агента у системі. Потрібно 
розуміти, які завдання кожен агент повинен виконувати, і як вони взаємодіють 
між собою та з іншими складовими системи. 
2 Планування та координація. Керування агентами включає в себе 
планування їх дій та координацію виконання завдань. Наприклад, як агенти 
приймають рішення щодо вибору завдань для виконання, як вони реагують на 
зміни в середовищі та як вони співпрацюють для досягнення спільних цілей. 
3 Автоматизація та саморегуляція. Керування агентами може 
включати в себе створення механізмів для автоматизації деяких процесів та 
можливість агентів реагувати на зміни у системі та середовищі без прямого 
втручання користувача. 
4 Прийняття рішень. Агенти можуть приймати рішення на основі 
доступної інформації та алгоритмів. Керування агентами включає в себе 
11 
 
ЧДТУ.232230.014 ПЗ 
 
визначення стратегій та правил, за якими агенти приймають рішення щодо 
виконання завдань. 
5 Взаємодія з користувачами та іншими системами. Керування 
агентами також включає в себе механізми для взаємодії агентів з користувачами 
та іншими інформаційними системами. Потрібно  визначити, як агенти 
обмінюються інформацією та взаємодіють з іншими додатками. 
6 Моніторинг та звітність. Керування агентами може включати в себе 
моніторинг їх стану та функціонування. Ви можете розглядати, як збирати дані 
про роботу агентів та генерувати звіти для аналізу та вдосконалення системи. 
Комунікація агентів – розробка протоколів та механізмів для комунікації 
агентів, обміну повідомленнями та даними. Комунікація агентів є важливим 
аспектом в агентних системах і грає ключову роль у забезпеченні взаємодії та 
спільної роботи між агентами. Комунікація між агентами передбачає обмін 
інформацією, повідомленнями та даними з метою досягнення спільних цілей або 
розв'язання завдань. Ця комунікація може відбуватися в реальному часі або 
асинхронно, в залежності від специфікацій системи. 
Основні аспекти даного поняття: 
1 Моделі комунікації. Існують різні моделі комунікації агентів, такі як 
прямий обмін повідомленнями (одному до одного), групова комунікація (один 
до багатьох), обмін повідомленнями через посередника (брокера), розподілена 
комунікація тощо. 
2 Протоколи та формати повідомлень. Існують стандартизовані 
протоколи та формати повідомлень, які використовуються для комунікації між 
агентами. Наприклад, FIPA (Foundation for Intelligent Physical Agents) розробив 
стандарти для агентних систем. 
3 Способи адресації та ідентифікації. Важливо визначити, як агенти 
ідентифікують один одного та як вони адресують повідомлення. Це може 
включати в себе використання унікальних ідентифікаторів агентів та механізмів 
розпізнавання. 
12 
 
ЧДТУ.232230.014 ПЗ 
 
4 Забезпечення безпеки та конфіденційності. Комунікація агентів 
також повинна бути забезпечена заходами безпеки. До яких входять методи 
шифрування, автентифікації та авторизації для захисту інформації, що 
передається між агентами. 
5 Механізми реакції на помилки. В такого роду системах, не виключені 
помилки в комунікації. Тому дуже важливим є виявлення та відновлення в разі 
втрати повідомлень або збоїв в комунікації. 
Розподілені системи – використання розподілених технологій та мереж 
для створення розподілених інформаційних систем з агентами. Такий підхід 
дозволяє створити систему, в якій агенти розташовані на різних вузлах мережі і 
взаємодіють один з одним для вирішення завдань 
Переваги використання розподілених технологій: 
1 Розподілена обробка даних. Однією з ключових переваг розподілених 
систем є можливість обробки даних на різних вузлах мережі. В інформаційних 
системах з агентами, розподілена обробка даних дозволяє агентам працювати 
паралельно і оптимізувати роботу системи. 
2 Забезпечення доступності та надійності. Розподілені технології 
дозволяють створити систему, яка є більш надійною та відмовостійкою. Якщо 
один вузол системи виходить з ладу, інші можуть продовжувати працювати. Це 
важливо для систем, які не можуть припиняти роботу. 
3 Скорочення навантаження на сервер. Розподілені системи 
дозволяють рівномірно розподілити навантаження між різними вузлами мережі. 
Це допомагає запобігти перевантаженням сервера та забезпечити ефективну 
обробку запитів агентів. 
4 Масштабованість. Розподілені технології дозволяють легко 
масштабувати систему. При збільшенні обсягу даних або завдань можна 
додавати нові вузли для обробки. Це особливо важливо в сучасних динамічних 
середовищах. 
13 
 
ЧДТУ.232230.014 ПЗ 
 
Загалом, використання розподілених технологій та мереж для створення 
розподілених інформаційних систем з агентами дозволяє створити ефективні, 
надійні та масштабовані системи, які можуть вирішувати складні завдання в 
різних галузях, включаючи логістику, управління мережами, штучний інтелект, 
автоматизацію виробництва та багато інших. 
Бази даних та сховища даних – використання баз даних або сховищ даних 
допомагає зберігати та управляти інформацією, яку обробляють агенти [10].  
Система з поліагентним функціоналом може вимагати використання 
різних баз даних та сховищ даних для збереження та управління інформацією. 
Важливо обрати відповідні бази даних та сховища даних, щоб задовольнити 
потреби системи та забезпечити швидкий та надійний доступ до даних агентів. 
Короткий опис деяких актуальних БД: 
1 Реляційні бази даних (RDBMS). Реляційні бази даних, такі як MySQL, 
PostgreSQL, Oracle, або Microsoft SQL Server, часто використовуються для 
збереження структурованих даних, які вимагають складних запитів та зв'язків 
між таблицями. Це може бути корисним для збереження конфігураційних даних, 
історії агентів та інших даних, що потребують складних запитів; 
2 NoSQL бази даних. NoSQL бази даних, такі як MongoDB, Cassandra  
підходять для збереження неструктурованих або напівструктурованих даних. 
Вони можуть бути корисними для збереження журналів подій, даних сесій 
агентів або графових структур, які важко виразити у реляційних базах даних; 
3 Графові бази даних. Графові бази даних, такі як Neo4j, підходять для 
збереження даних, які мають складні зв'язки та відносини між об'єктами. Це 
може бути корисним для моделювання взаємодії агентів та їхніх відносин; 
4 Ключ-значення сховища. Ключ-значення сховища, такі як Redis або  
Amazon DynamoDB, використовуються для збереження пар "ключ-значення" та 
можуть бути корисними для збереження швидкодійних даних, таких як стан 
агентів або розподілені ресурси. 
14 
 
ЧДТУ.232230.014 ПЗ 
 
1.2 Аналіз існуючих в світі аналогів інформаційних технологій 
Аналіз існуючих аналогів і технологій дозволить визначити, які підходи та 
рішення вже існують на ринку, які можливості вони пропонують та може надати 
ідеї для вдосконалення та розширення проекту даної роботи з поліагентним 
функціоналом.  
Нижче проведено огляд найпопулярніших технологій побудови 
мультиагентних систем. 
JADE (Java Agent Development Framework) – це фреймворк та середовище 
розробки для створення, розгортання та управління агентними системами на 
мові програмування Java [11]. JADE розроблений для підтримки агентно-
орієнтованого програмування та досліджень в галузі розподілених 
інтелектуальних систем. Даний фреймворк складається з різних компонентів та 
модулів, які допомагають розробникам створювати, керувати та взаємодіяти з 
агентами. Архітектура платформи представлена на рис. 1.1. 
 
 
Рисунок 1.1 – Архітектура JADE 
 
Проаналізувавши даний фреймворк, можна виокремити такі головні 
компоненти: 
Агенти (Agents). Агенти - це основні суб'єкти в JADE, які виконують 
завдання та приймають рішення. Кожен агент має власну інформацію, навички 
та поведінку. Вони можуть спілкуватися один з одним, обмінюватися 
повідомленнями та взаємодіяти з іншими агентами в середовищі. 
15 
 
ЧДТУ.232230.014 ПЗ 
 
Цикл життя агента JADE відповідає циклу, запропонованому FIPA. Ці 
агенти проходять через різні стани, визначені як: 
– initiated – агент створено, але ще не зареєстрований в AMS; 
– active – агент зареєстрований і має ім’я – у такому стані він може 
спілкуватися з іншими агентами; 
– suspended – агент зупиняється, оскільки його потік зупинено; 
– waiting – агент заблокований в очікуванні події; 
– deleted – агент закінчив роботу, і його потік завершився, в AMS його 
більше немає; 
– transit – агент змінює місцезнаходження. 
Контейнери (Containers). Контейнери - це середовища, в яких працюють 
агенти. Кожен контейнер може містити один або декілька агентів, і вони можуть 
взаємодіяти між собою. JADE дозволяє створювати різні типи контейнерів, такі 
як контейнери агентів або контейнери для мобільних агентів. 
Протоколи (Protocols). JADE надає можливість визначати та 
використовувати агентні протоколи для стандартизації комунікації між 
агентами. Протоколи дозволяють агентам взаємодіяти відповідно до певних 
сценаріїв та стандартів. 
Служби (Services). Служби JADE надають функціональність для агентів, 
таку як реєстрація та пошук інших агентів, керування ресурсами, безпека тощо. 
Ці служби спрощують розробку та керування агентними системами. 
Також можна виокремити такі головні принципи JADE: 
– відкритий вихідний код JADE, тобто це вільно розповсюджуване 
програмне забезпечення з відкритим вихідним кодом, що дозволяє розробникам 
вільно використовувати та модифікувати його для своїх потреб. Це сприяє 
широкому поширенню фреймворку та спільному розвитку; 
– підтримка стандартів FIPA, JADE відповідає стандартам та 
специфікаціям, розробленим FIPA (Foundation for Intelligent Physical Agents), 
міжнародною організацією, що розробляє стандарти для агентних технологій. Це 
16 
 
ЧДТУ.232230.014 ПЗ 
 
дозволяє взаємодіяти з іншими агентними системами, що відповідають цим 
стандартам; 
– мобільність, JADE підтримує мобільних агентів, які можуть 
переміщатися між різними агентними платформами та середовищами. Це 
дозволяє агентам рухатися та виконувати завдання в різних середовищах; 
– гнучкість та розширюваність – JADE розроблений так, щоб бути 
гнучким та розширюваним. Розробники можуть додавати власні компоненти, 
розширювати функціональність та адаптувати його до своїх потреб. 
JADE дозволяє розробникам створювати розподілені агентні системи для 
різних завдань, від управління ресурсами до автоматизації процесів та аналізу 
даних. Цей фреймворк спрощує розробку та керування агентними системами та 
надає різноманітні інструменти для реалізації агентно-орієнтованих додатків. 
SPADE (Smart Python multi-Agent Development Environment) – це 
фреймворк для розробки та дослідження агентних систем на мові програмування 
Python [12]. Архітектура платформи представлена на рис. 1.2. 
 
 
Рисунок 1.2 – Архітектура SPADE 
 
Основні характеристики SPADE включають наступне: 
Мультиагентність. SPADE підтримує розробку систем, де багато агентів 
працюють спільно та взаємодіють між собою. Це дозволяє моделювати та 
створювати складні системи з агентами, які виконують різні ролі та завдання. 
17 
 
ЧДТУ.232230.014 ПЗ 
 
Python. Фреймворк використовує мову програмування Python для 
реалізації агентів та їх поведінки. Python є популярною та дружньою мовою 
програмування, що робить SPADE доступним для широкого кола розробників. 
Асинхронність. Він підтримує асинхронну комунікацію між агентами. Це 
дозволяє агентам взаємодіяти паралельно та ефективно обробляти повідомлення 
в режимі реального часу. 
Відкритий вихідний код. Тобто є вільно розповсюджуваним програмним 
забезпеченням з відкритим вихідним кодом, що дозволяє розробникам вільно 
використовувати, модифікувати та розширювати його. 
Підтримка стандартів FIPA. Відповідає стандартам та специфікаціям, 
розробленим FIPA (Foundation for Intelligent Physical Agents. 
SPADE, з використанням мови програмування Python, робить його 
популярним інструментом для розробки агентних систем, особливо в 
дослідженнях та розробці розподілених, мультиагентних додатків. 
JADEX – це ще одна платформа для розробки агентних систем, яка 
спеціалізується на створенні агентних додатків [13]. Вона дозволяє розробникам 
створювати та керувати агентами, які приймають рішення та взаємодіють між 
собою та іншими агентами.  
Ключові характеристики JADEX: 
Агентність. JADEX орієнтований на розробку агентних систем, де агенти 
представляють собою основні суб'єкти, які приймають рішення та взаємодіють в 
середовищі. Вони можуть мати власні навички, знання та поведінку. 
Багатоагентність. Платформа підтримує створення систем з багатьма 
агентами, які співпрацюють та взаємодіють між собою. Це дозволяє моделювати 
складні взаємодії та розподілити завдання між агентами. 
Прозорість. JADEX надає інструменти для відстеження та відладки 
агентів у режимі реального часу. Розробники можуть спостерігати за внутрішнім 
станом агентів та їхньою взаємодією. 
18 
 
ЧДТУ.232230.014 ПЗ 
 
Підтримка BDI (Beliefs, Desires, Intentions). Тобто побудований на основі 
концепції BDI, яка моделює агентів на основі їх переконань (beliefs), бажань 
(desires) та намірів (intentions). Ця модель дозволяє агентам приймати рішення на 
основі їхньої внутрішньої структури. 
Гнучкість та розширюваність. JADEX надає можливість розробникам 
визначати та розширювати функціональність агентів та їх поведінку за 
допомогою спеціальних модулів. 
Графічний інтерфейс. Платформа має графічний інтерфейс для 
створення, конфігурування та керування агентами. 
Розглянута система дозволяє розробникам створювати агентні системи з 
гнучкістю та деталізацією, спрощуючи розробку та керування агентами. Він 
знаходить застосування в різних галузях, де агенти приймають рішення та 
взаємодіють між собою для досягнення поставлених завдань. 
  
19 
 
ЧДТУ.232230.014 ПЗ 
 
Висновки до розділу 
Отже виходячи з теми роботи та поставленої мети були визначені 
призначення та область застосування проекту. Проведений огляд способів і 
засобів вирішення поставлених задач. Проаналізовані переваги та недоліки 
аналогів програмного продукту, взяті до уваги ті переваги, які були б корисними 
в створюваній системі та ті недоліки, які є небажаними.  
Проаналізувавши існуючі системи можна зробити висновок, що вони не 
задовольняють деякі потреби користувачів, тому є необхідність реалізації нового 
рішення, яке дасть можливість користувачеві взаємодіяти із системою в 
максимально зрозумілому інтерфейсі. А також дасть змогу розмістити систему 
як незалежні одиниці в хмарних платформах, що забезпечить більшу надійність 
та гнучкість. Та буде мати можливість до масштабування. 
Таблиця 1.1 
Переваги та недоліки розглянутих аналогів 
Критерій JADE SPADE JADEX 
Переваги 
Розширю ваність Розширена Придатність для Додаткові 
функціональність, використання можливості, які 
підтримка FIPA ACL Python, простота підвищують JADE 
Спільнота Активна спільнота Менш активна, Обмежена 
користувачів та але є кількість 
розробників зацікавленість користувачів 
Незалежність від Реалізована на Java Робота з Python, Розширення JADE 
платформи можливість з додатковими 
швидкого старту можливостями 
Недоліки 
Витрата ресурсів Потенційні Можливі Обмежені 
проблеми проблеми з можливості 
управлінням продуктивністю 
ресурсами 
Стабільність Певні проблеми Менша Менша 
стабільності під час стабільність популярність, 
розробки можливі проблеми 
з підтримкою 
20 
 
ЧДТУ.232230.014 ПЗ 
 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1 Дослідження архітектури інформаційних систем 
Для проведення дослідження даного пункту варто зазначити, що таке 
архітектура інформаційної системи, які вони бувають, які мають переваги та 
недоліки. Та в яких випадках варто використовувати те чи інше архітектурне 
рішення. Не завжди складна архітектура є доцільною в певних типах проектів. 
Архітектура інформаційної системи – це структурна організація елементів 
програмного забезпечення, їх взаємодія та взаємозв'язок з апаратними 
компонентами, базами даних, іншими системами та користувачами. Вона 
визначає загальну концепцію, засоби та правила реалізації та функціонування 
системи.  
Архітектура системи визначається для покращення ефективності роботи 
системи, спрощення її розробки, впровадження та підтримки. Добре 
спроектована архітектура допомагає забезпечити гнучкість та масштабованість 
системи та полегшує управління нею в майбутньому.  
До розгляду беруться наступні архітектурні рішення:  
Монолітна архітектура – це підхід до розробки програмних систем, де 
весь функціонал програми об'єднаний в одному цілому, великому за розміром 
додатку [3]. В такій системі усі компоненти (наприклад, інтерфейс користувача, 
бізнес-логіка, база даних) зазвичай розгорнуті разом, на одному сервері або 
платформі. 
Основні риси монолітної архітектури: 
– цілісність – усі компоненти системи об'єднані в єдиному блоку 
програмного коду; 
– однорівневість – весь функціонал, логіка та розгортання разом на 
одному рівні; 
– одноцільовий додаток – додаток зазвичай розгортається на одній 
платформі або сервері; 
21 
 
ЧДТУ.232230.014 ПЗ 
 
– єдиний технологічна стек – використання одного комплексу технологій 
та мов програмування для всіх компонентів; 
– спільна база даних – у монолітних системах зазвичай використовується 
одна централізована база даних для усіх функцій. 
– залежність компонентів – компоненти можуть бути сильно зв'язаними 
один з одним, що може ускладнювати зміни або розширення. 
Монолітна архітектура має як переваги, так і недоліки, які важливо 
враховувати при її використанні [5]. 
Переваги монолітної архітектури: 
1 Простота розробки. У монолітних додатках весь код зазвичай 
розміщений в одному проекті, що спрощує розробку та тестування. 
2 Простота встановлення. Оскільки весь додаток - це один блок, 
встановлення та розгортання може бути менш складним. 
3 Менша складність. В монолітних системах відсутній складний код для 
управління взаємозв'язками між різними службами, що спрощує розробку та 
розгортання. 
Недоліки монолітної архітектури: 
1 Масштабування. У монолітних додатках складно масштабувати окремі 
компоненти незалежно, оскільки вони зазвичай пов'язані між собою. 
2 Розвиток та підтримка. Зміни в одному компоненті можуть мати вплив 
на всю систему, що може ускладнити розвиток та підтримку. 
3 Недостатня гнучкість. Монолітна архітектура може обмежувати 
гнучкість у виборі технологій та швидкість впровадження нових функцій. 
4 Ризики витрат. Зміна або покращення одного фрагмента може вимагати 
збільшення витрат на весь проект. 
5 Нестійкість. Якщо один елемент системи несправний, це може 
призвести до недоступності всього додатку. 
Хоча монолітна архітектура (рис. 2.1) проста для розробки та розгортання, 
вона може мати обмеження, особливо щодо масштабованості, гнучкості та 
22 
 
ЧДТУ.232230.014 ПЗ 
 
швидкості впровадження змін. Багато організацій переходять до більш 
модульних, розподілених або мікросервісних архітектур для полегшення 
розвитку, масштабованості та підтримки програмних систем. 
 
 
Рисунок 2.1 – Схема монолітної архітектури 
 
Мікросервісна архітектура – це підхід до розробки програмних систем, 
де додаток розбивається на невеликі, незалежні та автономні сервіси, які 
функціонують окремо один від одного [4]. Кожен сервіс відповідає за виконання 
конкретного функціоналу та має свою власну базу коду, базу даних або немає БД 
взагалі та інші ресурси.  
Основні риси мікросервісної архітектури: 
– розподілена система – додаток розбивається на невеликі, самодостатні 
та розподілені сервіси; 
23 
 
ЧДТУ.232230.014 ПЗ 
 
– незалежність сервісів – кожен сервіс може бути розгорнутий, 
оновлений та масштабований незалежно від інших; 
– різнорідні технології – різні сервіси можуть використовувати різні 
технології та мови програмування в залежності від їх конкретних потреб; 
– ізоляція помилок – помилки або збої в одному сервісі зазвичай не 
впливають на решту системи, оскільки вони функціонують незалежно один від 
одного; 
– гнучкість та масштабованість – легкість впровадження нових функцій 
або змін, а також можливість масштабування окремих сервісів відповідно до 
навантаження; 
– контейнеризація – використання контейнерів, таких як Docker, для 
розгортання та управління сервісами 
Мікросервісна архітектура має свої переваги та недоліки, які варто 
враховувати при розгляді її впровадження [5]. 
Переваги мікросервісної архітектури: 
1 Гнучкість та швидкість впровадження змін. Відокремлені сервіси 
дозволяють швидко внести зміни в окремі компоненти без впливу на інші. 
2 Скасування невдач. Якщо один сервіс відмовляє, це не призводить до 
відмови усієї системи. Інші сервіси можуть продовжувати працювати. 
3 Масштабованість. Можливість масштабування та управління 
ресурсами окремих сервісів незалежно від інших. 
4 Різнорідність технологій. Кожен сервіс може використовувати 
найбільш підходящі технології для своїх потреб. 
Недоліки мікросервісної архітектури: 
1 Складність управління. Розгортання та керування багатьма невеликими 
сервісами може бути складним завданням. 
2 Координація та комунікація. Необхідність забезпечення взаємодії та 
спільної роботи різних сервісів. 
24 
 
ЧДТУ.232230.014 ПЗ 
 
3 Тестування та відлагодження. Складність тестування та відлагодження, 
оскільки система складається з багатьох різних частин. 
4 Конфігурація та моніторинг. Потреба у ефективному моніторингу та 
керуванні конфігураціями всіх сервісів. 
5 Безпека. Збільшується кількість точок входу для потенційних атак, що 
може потребувати більш складних заходів забезпечення безпеки.  
Обираючи мікросервісну архітектуру (рис. 2.2), важливо враховувати ці 
аспекти та збалансувати переваги з вимогами та складнощами, які вона може 
створити для конкретного проекту. 
 
 
Рисунок 2.2 – Схема мікросервісної архітектури 
25 
 
ЧДТУ.232230.014 ПЗ 
 
Дослідивши переваги та недоліки обох типів архітектурних підходів, 
можна сформувати  порівняльну таблицю монолітної та мікросервісної 
архітектури. 
В підсумку – мікросервісна архітектура є більш складнішою та потребує 
більше часу на реалізацію. Проте, вона дозволяє підвищити відмовостійкість та 
забезпечити прозоре як вертикальне, так і горизонтальне масштабування. 
 
Таблиця 2.1 
Порівняльна таблиця монолітної та мікросервісної архітектури 
Особливість Монолітна Мікросервісна архітектура 
архітектура 
Розмір додатку Одне ціле додаткове Додаток розділений на невеликі 
зібране в одному місці. сервіси, що мають власний 
контекст та функціональність. 
Масштабованість Вимагає поновлення Може бути масштабований 
всього додатку для незалежно для кожного сервісу, 
масштабування. що спрощує горизонтальне 
масштабування. 
Розвиток Зазвичай потребує Легше для розвитку та 
більше часу на рефакторингу завдяки 
внесення змін. розділенню на окремі сервіси. 
Надійність Одна помилка може Помилки менше впливають на 
призвести до збою весь додаток, тому що вони 
всього додатку. локалізовані в окремих сервісах. 
Залежності Сильні залежності між Більш слабкі залежності, що 
компонентами дозволяє змінювати та 
додатку. оновлювати сервіси без впливу 
на інші. 
 
26 
 
ЧДТУ.232230.014 ПЗ 
 
Продовження таблиці 3.2 
Розгортання Єдиний модуль для Розгортання окремих сервісів 
розгортання. можливе без впливу на інші. 
Комунікація Внутрішня комунікація Залежно від архітектури може 
простіша та швидша. потребувати складнішої 
внутрішньої комунікації через 
мережу. 
Управління Код централізований та Розподілений код зменшує 
кодом складний у великих складність та полегшує 
монолітах. управління. 
2.2 Дослідження способів комунікації з агентами 
Однією з основних проблем, характерних для систем, що мають 
поліагентний функціонал, є проблема комунікації з агентами. Це обумовлюється 
тим, що форма комунікації з агентами, впливає на характеристики і властивості 
системи. 
Вхідні параметри для агентів у системі можуть бути передані через 
різноманітні канали та механізми для забезпечення взаємодії та обміну 
інформацією. 
Мережеві запити. Вхідні параметри можуть бути передані агентам через 
мережеві запити (рис. 2.3), використовуючи протоколи, такі як HTTP або TCP/IP. 
З агентами можна взаємодіяти через HTTP методи, такі як GET, POST, PUT, 
DELETE. Наприклад, POST може використовуватися для створення нових 
ресурсів, а GET для отримання інформації. Використання HTTP комунікації 
доцільно, якщо це синхронні операції [14]. 
Також з агентами можна взаємодіяти через TCP/IP сокети. Вони 
дозволяють агентам здійснювати двосторонній потік даних через мережу. Це 
може бути корисно для реального часу та потокової передачі даних. 
27 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 2.3 – Схема роботи мережевих запитів 
 
Використання баз даних. Вхідні параметри можуть бути збережені у базі 
даних, до якої агенти мають доступ для отримання цих даних (рис. 2.4).  
При використанні спільної бази даних, всі сервіси мають доступ до однієї 
бази даних. Це дозволяє зручно обмінюватися даними, але може призвести до 
залежності між сервісами і ускладнити розгортання змін. 
 
Рисунок 2.4 – Схема роботи з використанням БД 
28 
 
ЧДТУ.232230.014 ПЗ 
 
Файловий обмін. Це один із способів передачі даних між агентами, коли 
параметри або інші дані зберігаються у вигляді файлів на спільному ресурсі, до 
якого мають доступ різні агенти (рис. 2.5). Це може бути використано для 
спільного обміну інформацією між окремими частинами системи. 
Особливості використання файлів для передачі даних між агентами: 
– доступність та простота. Файли можуть бути легко створені, 
збережені та оновлені на спільному ресурсі, що дозволяє різним агентам 
отримувати доступ до необхідних даних; 
– прозорість та читабельність. Файли можуть бути простими у читанні 
та редагуванні, що спрощує взаємодію між агентами, якщо дані можуть бути 
викладені в чіткому та зрозумілому форматі; 
– синхронізація даних. Агенти можуть періодично перевіряти та 
оновлювати дані у файлах для отримання найсвіжішої інформації; 
– можливість помилок. Потенційні конфлікти та помилки можуть 
виникнути, якщо два або більше агентів спробують змінити файл одночасно. 
Використання файлів для передачі даних може бути досить простим 
рішенням, але варто враховувати можливість конфліктів при одночасній зміні 
файлів кількома агентами. 
 
Рисунок 2.5 – Схема роботи через файловий обмін 
 
29 
 
ЧДТУ.232230.014 ПЗ 
 
Використання Message Broker. Message Broker – це посередник, який 
отримує, розподіляє та обробляє повідомлення в системі, спрощуючи 
комунікацію між різними компонентами, такими як агенти [15]. 
Ось як Message Broker може бути використаний для взаємодії з агентами: 
– посередництво в обміні повідомленнями. Message Broker приймає 
повідомлення від одного агента і маршрутизує його до відповідного агента або 
групи агентів. Це спрощує процес комунікації, оскільки агентам не потрібно 
звертатися один до одного безпосередньо; 
– маршрутизація повідомлень. Message Broker може допомагати 
визначати, які агенти повинні отримати певні повідомлення, використовуючи 
правила маршрутизації, які можуть бути налаштовані для конкретних типів 
повідомлень; 
– гарантована доставка. Message Broker може забезпечити гарантовану 
доставку повідомлень, що важливо для систем, де надійність та цілісність даних 
має значення; 
– публікація/підписка. Використання патерну "публікація/підписка" 
дозволяє агентам підписатися на певні типи повідомлень, що спрощує процес 
реакції на вхідні дані чи події; 
– масштабованість та продуктивність. Message Broker може 
допомагати у розподіленні навантаження між агентами та забезпечити 
масштабованість системи; 
– підтримка різних протоколів та форматів повідомлень. Message 
Broker може підтримувати різні протоколи та формати повідомлень, що дозволяє 
агентам взаємодіяти, незалежно від їхніх технічних характеристик. 
Використання Message Broker дозволяє зменшити пряму взаємодію між 
агентами та робить систему більш гнучкою та масштабованою. Важливо обрати 
відповідний Message Broker та правильно налаштувати його, щоб забезпечити 
ефективну роботу агентів та надійну комунікацію в системі. Далі наведена схема 
комунікації з використанням брокера повідомлень (рис. 2.6) 
30 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 2.6 – Схема роботи через Message Broker 
2.3 Дослідження типів оцінки моделей 
Порівнявши можливі архітектури системи, а саме, агентів та Core, а також 
проаналізувавши способи комунікації з агентами, ще варто дослідити основні 
типи оцінки моделей. За допомогою яких Core система буде ідентифікувати 
результати роботи агентів. 
Для визначення найкращих моделей, які повинні бути побудовані різними 
агентами, варто розглянути можливі критерії селекції моделей. Вибір критерія 
здійснюється в залежності від задачі, яка розв’язується. Досвід багатьох 
дослідників свідчить, що найпоширеніше застосування мають наступні зовнішні 
критерії.  
Критерій регулярності потребує, щоб середньоквадратична помилка, 
розрахована за даними частини таблиці B , була мінімальна [16] (рис. 2.7): 
 
��
∑ �� 2
2 (��табл−��м)
∆ (��) = ��=0 ��
�� → ������           (2.1) 
∑ ��(�� )2
��=0 табл ��
 
31 
 
ЧДТУ.232230.014 ПЗ 
 
де (����абл)�� – табличні значення вихідної змінної в точці ���� таблиці даних B, 
�� = 1, … ����; (����)�� – значення вихідної змінної в точці ���� таблиці даних B, 
�� = 1, … ����, що розраховане за моделлю, що була отримана за даними частини 
таблиці А. 
 
 
Рисунок 2.7 – Розрахунок критерію регулярності: 
x - точки частини таблиці даних А, ° - точки частини таблиці даних В 
 
Критерій мінімуму зсуву потребує, щоб моделі, які отримані на частинах 
таблиці A і B , якомога менше відрізнялися одна від одної на інтервалі 
екстраполяції (��1;  ������) [16] (рис. 2.8) 
 
∑���� (�� −�� )2
��2 ��=1 �� �� ��
зсуву =
��∙∑�� 2 → ������  (2.2) 
��=1(��табл)��
 
де (����абл)�� – табличні дані вихідної змінної в усіх точках таблиці даних 
�� = 1, … �� (�� = ���� + ����); ���� – модель отримана на частині таблиці даних А; 
32 
 
ЧДТУ.232230.014 ПЗ 
 
(����)�� – значення вихідної змінної, розраховане по моделі ���� в точці �� = 1, … ����; 
���� – модель, отримана на частині таблиці даних В; (����)�� – значення вихідної 
змінної, розраховане по моделі ���� в точці �� = 1, … ����; �� – коефіцієнт 
екстраполяції, який приймає значення �� = 1,0 ÷ 3,0. 
 
 
Рисунок 2.8 – Розрахунок критерію мінімуму зсуву: 
х - точки частини таблиці даних А, ° - точки частини таблиці даних В 
 
Після даного дослідження варто зауважити, що критерій мінімуму зсуву 
використовується майже в усіх алгоритмах самоорганізації моделей. Критерій 
регулярності використовується, як правило, в комбінації з критерієм мінімуму 
зсуву. 
2.4 Експериментальні дослідження комунікації агентів 
Базуючись на попередньому пункті про різні види комунікації з агентами 
було вирішено провести експериментальні дослідження подання даних агентам 
за допомогою черги повідомлень. 
Для проведення даних експериментальних досліджень було реалізовано 
підсистему, яка дала можливість надсилати повідомлення різного розміру до 
33 
 
ЧДТУ.232230.014 ПЗ 
 
одного агенту та отримувати від нього відповідь. Дана підсистема дасть 
можливість перевірити чи всі дані доходять до агенту та назад, тобто немає 
ніяких втрат під час пересилки. А також проаналізувати розмір даних, які будуть 
передаватися та час за який ці дані доходять. 
Спочатку варто розглянути структуру повідомлення до агенту від Core 
системи: 
 
 
const data = { 
  processId: 'ID', 
  processStructureId: 'ID', 
  configuration: {}, //  
  training: { 
    inputs: [ 
      { name: 'nameX1', data: [1, 2, 3, 4] }, 
      { name: 'nameX2', data: [1, 2, 3, 4] }, 
      { name: 'nameX3', data: [1, 2, 3, 4] }, 
    ], 
    outputs: [{ name: 'nameY', data: [1, 2, 3, 4] }], 
  }, 
  checking: { 
    inputs: [ 
      { name: 'nameX1', data: [1, 2, 3, 4] }, 
      { name: 'nameX2', data: [1, 2, 3, 4] }, 
      { name: 'nameX3', data: [1, 2, 3, 4] }, 
    ], 
    outputs: [{ name: 'nameY', data: [1, 2, 3, 4] }], 
  }, 
}; 
 
Кожне повідомлення буде містити processId та processStructureId – це 
ідентифікатори за допомогою яких, агент та Core зможуть розуміти до яких саме 
структур відноситься це повідомлення. 
training та checking – це набори даних, які необхідні для тренування та 
перевірки моделей. Кожен з цих наборів має вхідні дані (тобто Х, які приймають 
участь в розрахунку У) inputs та outputs дані (У, які потрібно отримати). 
 Для дослідження буде проведено певну кількість експериментів при цьому 
в кожному наступному експерименті буде збільшена кількість даних, які ми 
34 
 
ЧДТУ.232230.014 ПЗ 
 
будемо надсилати агенту. На рис. 2.9. представлена частина коду, для кращого 
розуміння, як саме будуть формуватися дані для експериментів. 
 
 
Рисунок 2.9 – Приклад коду формування даних для експериментів 
 
Метод generateInputOutput на виході поверне масив об’єктів наступної 
структури: 
 
{ 
  name: string; 
  data: number[]; 
} 
 
 
де – name назва, data – дані необхідні для побудови моделі. Даний метод приймає  
наступні параметри: 
– name – назва, яка приймає участь у формування поля name в кожному 
об’єкті вихідного масиву; 
– count – кількість елементів вихідного масиву; 
– dataCount – кількість, випадково згенерованих значень, масиву data в 
кожному елементі вихідного масиву. 
На рис. 2.10 показаний приклад результату роботи методу 
generateInputOutput по генерації даних. Для всіх експериментів буде 
використано однакові кількості даних, для training та checking наборів. 
Посилка запиту на обробку буде відбуватися за допомогою Postman. 
35 
 
ЧДТУ.232230.014 ПЗ 
 
 
 
Рисунок 2.10 – Результати генерації даних 
 
Експеримент 1 (рис. 2.11) 
Кількість елементів вихідного масиву inputs – 10, outputs – 1. 
Кількість, випадково згенерованих значень, масиву data – 10. 
 
 
Рисунок 2.11 – результати експерименту 1 
36 
 
ЧДТУ.232230.014 ПЗ 
 
Експеримент 2 (рис. 2.12) 
Кількість елементів вихідного масиву inputs – 10, outputs – 1. 
Кількість, випадково згенерованих значень, масиву data – 100. 
 
 
Рисунок 2.12 – Результати експерименту 2 
 
Експеримент 3 (рис. 2.13) 
Кількість елементів вихідного масиву inputs – 100, outputs – 10. 
Кількість, випадково згенерованих значень, масиву data – 100. 
 
 
Рисунок 2.13 – Результати експерименту 3 
 
Експеримент 4 (рис. 2.14) 
Кількість елементів вихідного масиву inputs – 100, outputs – 10. 
Кількість, випадково згенерованих значень, масиву data – 1000. 
 
37 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 2.14 – Результати експерименту 4 
 
Експеримент 5 (рис. 2.15) 
Кількість елементів вихідного масиву inputs – 100, outputs – 10. 
Кількість, випадково згенерованих значень, масиву data – 10000. 
 
 
Рисунок 2.15 – Результати експерименту 5 
 
Експеримент 6 (рис. 2.16) 
Кількість елементів вихідного масиву inputs – 100, outputs – 10. 
Кількість, випадково згенерованих значень, масиву data – 100000. 
 
 
Рисунок 2.16 – Результати експерименту 6 
38 
 
ЧДТУ.232230.014 ПЗ 
 
 
Експеримент 7 (рис. 2.17) 
Кількість елементів вихідного масиву inputs – 500, outputs – 10. 
Кількість, випадково згенерованих значень, масиву data – 100000. 
 
 
Рисунок 2.17 – Результати експерименту 7 
 
В результаті проведення експериментальних досліджень з’ясовано, що 
жодного байту інформації не було втрачено. Це можна побачити, звернувши 
увагу на Request size (mb) та Job size, які мають однакові показники на всіх 7 
експериментах. Тобто незалежно від об’єму даних – інформація не втрачається. 
Наступне на що варто звернути увагу, це те, що при збільшенні об’єму 
даних, збільшується час передачі. Це логічна закономірність але навіть при 
передачі по 110 масивів, де в кожному є 100000 значень для training та 
checking – час становить приблизно 3 секунди.  
  
39 
 
ЧДТУ.232230.014 ПЗ 
 
Висновки до розділу 
Виходячи з проведеного дослідження та поставленого завдання було 
вирішено проектувати мікросервісну архітектуру системи. Тому що саме це  
архітектурне рішення наддасть максимальну гнучкість та швидкість 
впровадження змін, буде мати хорошу можливість масштабування. А також при 
даній архітектурі можна використовувати найбільш підходящі технології для 
кожного сервісу. 
При даній архітектурі буде реалізовано кожен агент як сервіс. Також 
виникає необхідність в Core сервісі, який буде забезпечувати вхідними даними 
агентів та обробляти результати роботи кожного з агентів. З подальшим 
збереженням синтезованих агентами моделей, для можливості їх використання 
на нових масивах даних. 
Для комунікації Core сервісу з агентами було вирішено використати 
Message Broker, який дозволяє зменшити пряму взаємодію агентів з  Core 
сервісом та дозволить бути системі більш гнучкою та масштабованою.  
В результаті проведення експериментальних досліджень з’ясовано, що при 
використанні брокера повідомлень, як способу комунікації, жодного байту 
інформації не було втрачено. Також було з’ясовано, що при збільшенні об’єму 
даних, які передаються, збільшується час передачі. Це логічна закономірність 
але навіть при передачі досить великих масивів даних час становить декілька 
секунд. Тому можна вважати даний спосіб передачі даних від Core до агентів 
таким, що задовольняє умови даної роботи.  
40 
 
ЧДТУ.232230.014 ПЗ 
 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЬ ТА 
ПРОЕКТУВАННЯ СИСТЕМИ 
3.1 Моделювання предметної області 
Дуже важливим етапом проектування системи є моделювання предметної 
області, тобто створення спрощеної абстракції, з метою дослідження та 
розуміння системи в цілому. Цей процес передбачає створення моделей, які 
відображають ключові аспекти, властивості та залежності в реальній системі. 
Моделі можуть бути в різних формах, включаючи математичні, комп'ютерні, 
фізичні, вербальні та інші. 
3.1.1 Модель предметної області. Словник предметної області 
На даному етапі потрібно створити візуальну модель, що полегшить  
розуміння створюваної системи та допоможе вирішити складні проблеми в її 
побудові. Завдяки моделі предметної області можна побачити та проаналізувати 
певні складності реалізації системи, що на перший погляд, виглядали досить 
простими. На рис. 3.1 відображена загальна діаграма класів системи. 
На діаграмі помічені основні класи системи, а саме: 
– Server 
– Core 
– Auth 
– Error Handler 
– Request Sender 
– Receiver 
– Notifier 
– DB Connection 
Словник предметної області – це поняття, які найчастіше згадують в 
процесі аналізу та проектування. До словника предметної області можна 
віднести: поліагентний функціонал, архітектура системи, моноліт, мікросервіси, 
Message broker, структури, сценарій. 
41 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 3.1 – Загальна діаграма класів системи 
3.1.2 Елементи моделювання предметної області 
Для моделювання предметної області та при проектування всієї системи, в 
даній роботі буде використовуватися мова UML [7]. Далі будуть представлені 
основні елементи моделювання (таблиця 3.1 та  таблиця 3.2), які можна буде 
побачити на UML діаграмах в наступних пунктах роботи. 
Таблиця 3.1 
Графічний символ Назва елемента 
дійова особа (актор) 
 
варіант використання 
 
пакет 
 
клас 
 
 
42 
 
ЧДТУ.232230.014 ПЗ 
 
Продовження таблиці 3.1 
компонент 
 
вузол 
 
компонент 
 
стан 
 
лінія життя, фокус управління 
 
початковий і кінцевий стан 
 
логічний з’єднувач, розгалужувач 
 
паралельний з’єднувач, розгалужувач 
 
 
Таблиця 3.2 
Графічний символ Назва елемента 
відношення асоціації 
 
 
43 
 
ЧДТУ.232230.014 ПЗ 
 
Продовження таблиці 3.2 
відношення залежності 
 
заміна 
 
межа 
 
простий потік управління 
 
виклик 
 
рекурсія 
 
повернути 
 
агрегація 
 
 
3.1.3 Робоча область моделювання 
Детально проаналізувавши інформаційну модель системи було 
виокремленні наступні потоки інформації:  
1 Аутентифікація вхідного запиту – перевірка облікових даних 
механізмом контролю доступу. 
2 Отримання вхідних даних – обробка запиту що містить певні 
параметри, необхідні для їхньої подальшої обробки. 
3 Обробка даних – аналіз та підготовка отриманих даних, для подальшої 
відправки агентам. 
4 Відправка даних – формування структури та відправка даних на 
обробку агентам. 
5 Отримання результатів – отримання опрацьованої інформації від 
агентів в певній структурі. 
44 
 
ЧДТУ.232230.014 ПЗ 
 
6 Збереження даних – збереження даних в БД, після їхнього отримання 
від агентів. 
Схема потоків інформації показана на рис. 3.2. 
 
Рисунок 3.2 – Інформаційні потоки 
 
3.2 Формування та аналіз вимог 
Формування та аналіз вимог – це важливий етап в процесі розробки 
програмного забезпечення та проектування систем. Вимоги представляють 
собою опис того, що система чи програмне забезпечення повинні робити і як 
вони повинні працювати. Процес формування та аналізу вимог допомагає 
зрозуміти потреби та очікування користувачів і визначити, як система повинна 
бути розроблена. 
45 
 
ЧДТУ.232230.014 ПЗ 
 
3.2.1 Первинні вимоги замовника 
Спочатку вимоги отримуються від замовників, включаючи їхні потреби, 
очікування та обмеження. Це може бути зроблено за допомогою інтерв'ю, анкети, 
аналізу існуючих документів та інших методи. Зібрані вимоги документуються в 
структурованій формі, яка включає опис функціональних вимог (що система має 
робити) та нефункціональних вимог (як система має працювати, наприклад, 
вимоги до безпеки, продуктивності, надійності).  
Вимоги аналізуються, щоб зрозуміти, чи вони консистентні, повні та 
реалістичні. Якщо з'являються суперечності або непорозуміння, вони 
виправляються через комунікацію із замовником.  
Після аналізу і виправлень вимоги затверджуються. Затверджені вимоги 
стають основою для подальшої розробки системи чи програмного забезпечення. 
Вони служать контрактом між командою розробників та замовником. 
Первинна вимога замовника до системи: 
Core частина повинна містити в своєму складі алгоритми побудови 
системи для моделювання, їх комбінація. Має посилати запити на “ноди” для 
проведення моделювання і отримувати з них інформацію 
3.2.2 Детальні вимоги розробника 
Для побудови системи були сформовані наступні вимоги: 
1 Можливість аутентифікація вхідного запиту – перевірка чи запит 
прийшов від сервісу, який може їх надсилати саме в цю систему. 
2 Можливість отримання вхідних даних – система повинна мати 
функціонал, що дає змогу приймати запити від інших сервісів. 
3 Можливість обробляти дані – обробка даних, що були отримані від 
стороннього сервісу. Обробка має відбуватися, базуючись на чітко визначеній 
логікі та алгоритмах. 
46 
 
ЧДТУ.232230.014 ПЗ 
 
4 Можливість відправляти дані – система повинна мати функціонал для  
відправки даних іншим сервісам (агентам). Для того, щоб інші сервіси могли 
проаналізувати ці дані та виконати всю поставлену перед ними роботу. 
5 Можливість отримувати результати – після виконання певної роботи 
агентами, система повинна мати можливість отримати результати роботи цих 
агентів. 
6 Можливість зберігати/відавати результати – збереження результатів 
роботи агентів та видача цих результатів кінцевому користувачу (сервісу, що 
ініціював цей процес). 
7 Можливість використання моделей – прорахунок даних базуючись на 
побудованих раніше моделях та нових масивах даних. 
3.2.3 Функціональні вимоги 
Функціональні вимоги описують поведінку системи і сервіси (функції), які 
вона повинна виконувати. При цьому виходять з усебічного аналізу проблемної 
(предметної) області. Розглядаються різноманітні варіанти поведінки, що 
визначаються різними даними і станами зовнішнього середовища. 
В даній системі можна виокремити наступні функціональні вимоги: 
1 Отримання та опрацювання запитів від стороннього сервісу (наприклад 
UI). 
2 Аутентифікація вхідного запиту. 
3 Отримання та збереження даних в БД. 
4 Обробка отриманих даних. 
5 Підготовка даних для відправки агентам. 
6 Відправка даних агентам. 
7 Отримання результатів від агентів та їхнє збереження. 
8 Пересилка даних до стороннього сервісу, який ініціював певні дії. 
47 
 
ЧДТУ.232230.014 ПЗ 
 
3.2.4 Нефункціональні вимоги 
Нефункціональні вимоги належать до характеристик системи та її 
зовнішнього оточення, критеріїв ефективності і безпеки. Додатково можуть 
перераховуватися обмеження, що накладаються на дії і функції системи, а також 
на умови розробки. 
В даній системі можна виокремити наступні нефункціональні вимоги: 
1 Загалом вся система має бути розбита на різні сервіси: UI, Core 
(частина, яка розробляться в даній роботі) та агенти. 
2 Core повинен мати можливість комунікації з агентами на UI. 
3 Незалежність від інших сервісів. 
4 Відокремлена БД. 
5 Документація до системи. 
6 Масштабованість. 
7 Наявність системи захисту інформації. 
8 Простота використання. 
3.3 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів дає можливість отримати уявлення, яке буде 
представлене візуально, про вимоги замовника та поведінку системи з точки зору 
кінцевого користувача.  
Базуючись на вимогах до системи, була побудована діаграма прецедентів 
(рис. 3.3). 
На ній дійовими особами є агенти та кінцеві користувачі. Обидва можуть 
ініціалізувати виклик того чи іншого функціоналу системи. 
Окрім того, дана діаграма відображає процес перетворення інформації від 
її надходження до обробки і представлення кінцевого результату. 
 
48 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 3.3 – Діаграма прецедентів інформаційної система з поліагентним 
функціоналом 
 
3.4 Проектування логічної структури програмного комплексу 
Проектування логічної структури програмного комплексу – це процес 
створення абстрактної моделі системи чи програми, яка визначає, як будуть 
взаємодіяти її компоненти та як вони будуть вирішувати поставлені завдання. Це 
один із етапів в розробці програмного забезпечення, який передує фазі розробки. 
Проектування логічної структури допомагає визначити загальну архітектуру 
системи та логічні взаємозв'язки між її складовими частинами. 
Проектування включає в себе також визначення інтерфейсів між 
компонентами, що дозволяє їм взаємодіяти та обмінюватися даними. Це 
допоможе в розробці механізмів комунікації між різними сервісами. 
49 
 
ЧДТУ.232230.014 ПЗ 
 
Система може бути розбита на окремі модулі або компоненти, які 
відповідають конкретним функціям. Це сприяє модульності та полегшує 
розробку, тестування та обслуговування. 
Під час проектування логічної структури, слід враховувати можливість 
майбутнього масштабування та розширення системи. Це допоможе забезпечити 
стійкість та гнучкість системи. Даний аспект стає дуже актуальним, якщо 
система отримує велике навантаження (наприклад велику кількість 
користувачів).  
Правильно спроектована логічна структура допомагає забезпечити 
ефективність, надійність та легкість обслуговування системи. 
3.4.1 Діаграми класів 
Діаграми класів є одним із типів діаграм в уніфікованій мові моделювання 
(UML), які використовуються для візуалізації структури класів в програмному 
забезпеченні та їхніх взаємозв'язків. Вони надають графічний спосіб 
представлення об'єктно-орієнтованої моделі системи та дозволяють до 
подробиць описати класи, їхні атрибути, методи та спадкування між ними.  
Діаграми класів включають наступні елементи:  
– класи; 
– атрибути; 
– методи; 
– спадкування; 
– асоціації; 
– коментарі 
Дані діаграми використовуються для моделювання структури програм та 
систем, визначення інтерфейсів між класами, а також для документування 
архітектури програмного забезпечення. Діаграму класів системи можна 
побачити на рис. 3.4. 
 
50 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 3.4 – Діаграма класів інформаційної система з поліагентним 
функціоналом 
 
3.4.2 Діаграми пакетів 
Діаграма пакетів – це тип діаграми в уніфікованій мові моделювання 
(UML), який використовується для візуалізації структури та організації 
компонентів, класів та підсистем в програмному забезпеченні. Діаграма пакетів 
допомагає групувати компоненти в логічні пакети, що полегшує архітектурне 
проектування та розуміння великих систем. 
Діаграми пакетів включають наступні елементи:  
– пакети; 
– залежності між пакетами; 
– вкладеність пакетів; 
– ієрархія пакетів. 
Діаграми пакетів допомагають розробникам та архітекторам програмного 
забезпечення краще розуміти структуру системи та її організацію. Вони є 
корисним інструментом для проектування, моделювання та документування 
51 
 
ЧДТУ.232230.014 ПЗ 
 
архітектури програмного забезпечення. Діаграму пакетів системи можна 
побачити на рис. 3.5. 
 
 
Рисунок 3.5 – Діаграма пакетів інформаційної система з поліагентним 
функціоналом 
 
Короткий опис пакетів, що представлені на діаграмі (рис. 3.5): 
Auth (пакет аутентифікації) – надає можливість аутентифікації вхідних 
запитів, від сервісу, який забезпечує комунікацію системи з кінцевим 
користувачам. 
Analyzer (пакет аналізу) – надає можливість аналізувати вхідні дані, що 
надходять до системи. 
Core (пакет головної логіки) – надає можливість опрацювання вхідних 
даних, підготовки даних для передачі агентам, встановлення необхідних 
налаштувань. Детальніша діаграма даного пакету зображена на рис. 3.6. 
Request Sender (пакет відправки запитів) – надає можливість відправляти 
запити. Тобто формувати за ставити задачі кожному з агентів. 
52 
 
ЧДТУ.232230.014 ПЗ 
 
Receiver (пакет отримування результатів) – надає можливість отримувати 
результати роботи агентів. 
DB connection (пакет взаємодії з БД) – надає можливість взаємодіяти з БД. 
Виконувати різного роду запити до бази даних. 
Error Handler (пакет обробки помилок) – надає можливість обробляти 
помилки що виникають в системі під час роботи. 
Logger (пакет логування) – надає можливість логувати всю необхідну 
інформацію. 
Notifier (пакет сповіщень) – надає можливість відправляти сповіщення до 
сервісу з UI. 
Діаграму пакетів Core можна побачити на рис. 3.6. 
 
 
Рисунок 3.6 – Діаграма Core пакету системи 
3.5 Архітектурне проектування 
Архітектурне проектування грає важливу роль у розробці інформаційних 
систем з поліагентним функціоналом, оскільки воно визначає фундаментальну 
структуру та організацію системи, що впливає на її ефективність, надійність та 
здатність відповідати потребам користувачів.  
53 
 
ЧДТУ.232230.014 ПЗ 
 
Проектування архітектури досить складний процес, який потребує 
хорошого розуміння предметної області. Та достатніх технічних знань для 
реалізації програмної частини системи. В контексті роботи проектування 
визначає загальну структуру системи, організацію агентів та їхню взаємодію, що 
допомагає досягти мети та створити ефективну систему. Розробка архітектури 
включає в себе ідентифікацію агентів, які будуть частиною системи, та 
визначення їхніх функцій і взаємозв'язків. 
Важливим етапом проектування архітектури являється визначення 
механізмів взаємодії між агентами та системою, включаючи способи обміну 
повідомленнями, синхронізацію та керування агентами.  
Також спроектована архітектура повинна враховувати аспекти безпеки та 
конфіденційності даних у системі з поліагентним функціоналом. Це включає в 
себе механізми автентифікації, авторизації та шифрування даних. 
Якщо система пов'язана з іншими існуючими інформаційними системами, 
то архітектурний проект повинен включати в себе план інтеграції та обміну 
даними з цими системами. 
Ще одним із важливих аспектів проектування архітектури є 
масштабованість та продуктивність. Архітектура повинна бути спроектована з 
урахуванням масштабованості та продуктивності системи. Вона повинна бути 
здатною працювати ефективно навіть у великих масштабах. 
3.5.1 Діаграма компонентів 
Діаграма компонентів – це тип діаграми в уніфікованій мові моделювання 
(UML), який використовується для візуалізації фізичної архітектури системи, 
організації та зв'язків між компонентами програмного забезпечення та іншими 
ресурсами. Дані діаграми дозволяють розглядати програмну систему на більш 
високому рівні абстракції, зосереджуючись на її складових, компонентах та їхніх 
взаємозв'язках (рис. 3.7).  
 
54 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 3.7 – Діаграма компонентів системи 
 
Діаграма компонентів допомагає команді розробників та архітекторам 
більш ясно розуміти архітектурну структуру програмної системи, організацію 
компонентів та їхні взаємозв'язки. Вона може бути використана для аналізу та 
документування архітектури програмного забезпечення, а також для спілкування 
із замовниками та іншими учасниками проекту. 
3.5.2 Розгортання програмної системи. Діаграма розгортання 
Розгортання системи – є важливим етапом запуску будь-якого програмного 
продукту. Для того щоб система працювала в продакшн-оточенні потрібно 
провести планування, вибір апаратних ресурсів, встановлення необхідного 
середовища та бібліотек для роботи системи. 
Для того щоб розгорнути програмний продукт. Потрібно чітко розуміти, з 
яких вузлів складається система та які саме параметри середовища є 
обов’язковими для їхньої коректної роботи. Наприклад, прості системи можуть 
потребувати всього одного фізичного комп’ютера із встановленою операційною 
системою. Тоді як для коректної роботи складних систем може бути потрібно 
55 
 
ЧДТУ.232230.014 ПЗ 
 
декілька фізичних серверів, сервер бази даних, постійний та стабільний доступ 
до мережі Інтернет і тд. 
Діаграма розгортання – це вид діаграми, яка моделює фізичне розміщення 
компонентів програмної системи та їх взаємодію на різних апаратних пристроях. 
Вона відображає, як компоненти програми, такі як сервери, бази даних, 
програмне забезпечення, розташовані на апаратному середовищі та спілкуються 
один з одним.  
Основні елементи діаграми розгортання включають: 
– вузли, представлення апаратних пристроїв (серверів, комп'ютерів, 
смартфонів тощо), на яких розгорнуті програмні компоненти; 
– компоненти, програмні частини системи, які розгорнуті на апаратних 
пристроях, такі як додатки, бази даних, сервіси тощо; 
– зв'язки, показують, як компоненти взаємодіють між собою, а також з 
апаратними пристроями (наприклад, мережеві з'єднання). 
Діаграма розгортання системи зображена на рис. 3.8. 
 
 
Рисунок 3.8 – Діаграма розгортання системи 
56 
 
ЧДТУ.232230.014 ПЗ 
 
На діаграма розгортання жирним виділені ті вузли, які розроблялися в 
даній роботі. Інші частини, такі як UI та Agents, розроблялися колегами в рамках 
інших робіт. 
3.6 Моделювання поведінки системи 
Моделювання поведінки системи – це процес створення абстрактних 
моделей, які відображають спосіб, яким система взаємодіє зі своїм оточуючим 
середовищем та внутрішніми компонентами. Під час моделювання поведінки 
системи враховуються різноманітні аспекти, такі як обробка подій, реакція на 
зміни в стані системи, взаємодія з іншими системами та користувачами. 
3.6.1 Діаграма діяльності 
Діаграма діяльності – це вид діаграми в рамках мови моделювання UML, 
яка відображає послідовність дій, процесів або операцій, що відбуваються 
всередині системи або певної функції. Ця діаграма використовується для 
моделювання бізнес-процесів, логіки виконання завдань та послідовності 
операцій. Дані діаграми використовуються для візуального представлення логіки 
функцій, процесів чи процедур у системі, що дозволяє аналізувати та 
оптимізувати послідовність операцій, а також для виявлення можливих шляхів 
взаємодії та виконання дій всередині системи. 
На даній діаграмі представлено основні процеси, які відбуваються в Core 
системі. За допомогою даної діаграми можна з легкістю побачити логіку, а саме, 
послідовність операцій та функцій.  
Розглянувши діаграму діяльності можна виокремити 2 складніші частини: 
1 Збереження вхідних даних, побудова структури та побудова сценарію. 
2 Отримання результатів, аналіз та вибір найкращих результатів та 
збереження результатів. 
Нижче наведено діаграму діяльності для ІС з поліагентним функціоналом, 
яка була реалізована в межах даної роботи (рис. 3.9). 
57 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 3.9 – Діаграма діяльності системи 
58 
 
ЧДТУ.232230.014 ПЗ 
 
3.6.2 Діаграма послідовності 
Діаграма послідовності в рамках мови моделювання UML – це вид 
діаграми, яка відображає взаємодію між об'єктами чи компонентами системи в 
конкретному часовому порядку. Ця діаграма показує послідовність повідомлень, 
які передаються між об'єктами та порядок їх виконання. 
Діаграма послідовності (рис. 3.10) використовується для моделювання та 
візуалізації того, як об'єкти спілкуються у певній послідовності в рамках 
виконання певної функції чи процесу. Це дозволяє аналізувати та оптимізувати 
взаємодію системних компонентів. 
 
 
Рисунок 3.10 – Діаграма послідовності системи 
59 
 
ЧДТУ.232230.014 ПЗ 
 
3.6.3 Діаграма комунікації 
Діаграма комунікації – це вид діаграми в рамках мови моделювання UML, 
яка відображає взаємодію між об'єктами чи компонентами системи на певному 
часовому відрізку. Ця діаграма подібна до діаграми послідовності, але звертає 
більше уваги на комунікацію та передачу повідомлень між об'єктами. 
Діаграми комунікації допомагають у візуалізації, аналізі та розумінні 
взаємодії між різними компонентами системи. Вони дозволяють легше 
сприймати та аналізувати обмін повідомленнями та комунікацію між об'єктами 
під час виконання конкретних функцій або процесів. 
Діаграма комунікації зображена на рис. 3.11 та рис. 3.12 
 
 
Рисунок 3.11 – Діаграма комунікації системи (загальна) 
 
 
Рисунок 3.12 – Діаграма комунікації системи (Core) 
60 
 
ЧДТУ.232230.014 ПЗ 
 
3.6.4 Діаграма скінченного автомату 
Діаграма скінченного автомату (часто відома як діаграма станів) – це 
графічне представлення скінченного автомату, який моделює поведінку системи 
з обмеженим набором станів та переходів між ними (рис. 3.13).  Дана діаграма є 
важливим інструментом для моделювання реакції системи на події або зміни, 
дозволяючи краще розуміти її роботу, передбачати можливі стани та перехід між 
ними. Це допомагає у відлагодженні та аналізі роботи системи. 
 
 
Рисунок 3.13 – Діаграма скінченого автомата системи 
 
  
61 
 
ЧДТУ.232230.014 ПЗ 
 
Висновки до розділу 
В даному розділі було проведено моделювання інформаційної система з 
поліагентним функціоналом. Спроектовано та представлено загальний 
структурний опис системи, охарактеризовані основні компоненти, необхідні для 
роботи системи.  
Також були сформовані та проаналізовані вимоги до проекту. А саме, 
первинні вимоги замовника, детальні вимоги розробника, функціональні вимоги, 
нефункціональні вимоги. Що дало змогу краще зрозуміти як саме система 
повинна бути спроектована та розроблена. 
Представлені основні модулі та їхня характеристика. Це все було 
проілюстровано діаграмами відповідно до вимог.  
Були побудовані наступні діаграми: 
- діаграми класів; 
- діаграми пакетів; 
- діаграма компонентів; 
- діаграма розгортання; 
- діаграма діяльності; 
- діаграма послідовності; 
- діаграма комунікації; 
- діаграма скінченного автомату. 
Базуючись на побудованих діаграмах отримано розуміння того, як має 
працювати система, її основні модулі, як система має спілкуватися з іншими 
сервісами та елементами.  
  
62 
 
ЧДТУ.232230.014 ПЗ 
 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
4.1 Розробка програмного комплексу 
4.1.1 Обґрунтування вибору засобів реалізації 
Вибір середовища програмування залежить від специфіки задачі, що 
розв'язується. Для реалізація системи було обрано Node.js – це відкрите 
середовище для виконання JavaScript поза браузером. В основі Node.js лежить 
двигун V8, розроблений Google для виконання JavaScript у браузері Chrome. 
Node.js дозволяє виконувати JavaScript на сервері, що відкриває можливості для 
розробки веб-застосунків та додатків [17]. 
Основні особливості Node.js: 
– платформа на основі подій. Node.js працює за принципом асинхронного 
програмування та використовує модель подій, що дозволяє ефективно обробляти 
багатопотокові запити; 
– пакетний менеджер npm. Node.js поставляється з менеджером пакетів 
npm (Node Package Manager), який дозволяє встановлювати різноманітні пакети 
та бібліотеки для розробки; 
– застосування на сервері. Node.js використовується для розробки 
серверної частини веб-додатків, розробки API, виконання операцій вводу/виводу 
тощо; 
– підтримка модульності. Додатки на Node.js можуть бути побудовані на 
основі модульної структури, що сприяє рефакторингу та розширенню додатків. 
Node.js відкриває широкі можливості для розробки веб-додатків та є 
популярним серед розробників завдяки своїй швидкості та ефективності в 
опрацюванні запитів.  
Для реалізації системи було використано NestJS [18] – це фреймворк для 
створення масштабованих та ефективних веб-додатків на базі Node.js. Він 
63 
 
ЧДТУ.232230.014 ПЗ 
 
використовує TypeScript і базується на концепції Angular для створення 
структурованих, модульних та легко масштабованих додатків на сервері. 
В якості бази даних для системи було обрано PostgreSQL – це потужна, 
відкрита об'єктно-реляційна система керування базами даних (СКБД), яка надає 
широкий набір функцій та можливостей для зберігання та операцій з даними.  
Основні аргументи що підтверджують доцільність використання 
PostgreSQL [19]: 
– надійність та стабільність. PostgreSQL має репутацію надійної системи 
з високим рівнем стабільності, довгими циклами розвитку та підтримки; 
– розширюваність та гнучкість. Підтримка широкого спектру функцій, 
включаючи розширення, власні типи даних, функції та можливість використання 
зовнішніх розширень; 
– підтримка ACID. PostgreSQL підтримує ACID (Atomicity, Consistency, 
Isolation, Durability) для забезпечення надійності та цілісності даних; 
– високий рівень функціональності: Велика кількість вбудованих 
функцій та розширень для роботи з даними, включаючи географічні дані, JSON, 
XML, текстовий пошук та багато іншого; 
– підтримка SQL. Хороша підтримка мови SQL дозволяє виконувати 
складні операції з базою даних шляхом стандартних запитів; 
– велика спільнота та документація. PostgreSQL має активну спільноту 
користувачів та обширну документацію, що полегшує використання та 
вирішення проблем. 
Відкритий код та безкоштовність. Будучи відкритою системою, 
PostgreSQL є безкоштовною для використання та розповсюдження. 
Для комунікації Core із агентами було обрано механізм черг. А саме 
використовувся Bull – це бібліотека, яка надає можливість робити операції з 
чергами завдань (job queues) в Node.js та використовується для асинхронної 
обробки завдань у веб-додатках. Bull може працювати з декількома робочими 
64 
 
ЧДТУ.232230.014 ПЗ 
 
процесами або навіть на різних серверах, що дозволяє створити розподілену 
систему обробки завдань. 
Дані засоби реалізації дають змогу реалізувати гнучку, надійну, систему. 
Яка при необхідності буде мати можливість масштабування. 
4.1.2 Опис структурної (функціональної) схеми 
Виходячи з поставленого завдання була розроблена структурна схема 
інформаційної система з поліагентним функціоналом, яка включає в себе всі 
основні модулі, необхідні для підтримки всіх потрібних функцій та коректної 
роботи системи в цілому [7]. Дана схема представлена на рис. 4.1. (загальна 
схема системи) та рис. 4.2. (Core система, яка реалізована в межах даної роботи). 
  
Рисунок 4.1 – Структурна схема системи (загальна) 
 
  
Рисунок 4.2 – Структурна схема системи (Core) 
65 
 
ЧДТУ.232230.014 ПЗ 
 
Core система складається за таких основних модулів: 
– створення структури (рис. 4.3) ; 
– створення сценарію (рис. 4.4) ; 
– запуск сценарію (рис. 4.5) ; 
– збереження найкращих моделей структури (рис. 4.6). 
 
 
Рисунок 4.3 – Модуль створення структури 
 
 
Рисунок 4.4 – Модуль створення сценарію 
 
66 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 4.5 – Модуль запуск сценарію 
 
 
Рисунок 4.6 – Модуль збереження найкращих моделей структури 
67 
 
ЧДТУ.232230.014 ПЗ 
 
4.1.3 Опис логічної схеми системи 
Для того щоб показати роботу інформаційної система з поліагентним 
функціоналом, була побудована логічна схема роботи системи загалом (рис. 4.7) 
та окремо Core частини (рис. 4.8), яка і була реалізована в межах даної роботи. 
 
 
Рисунок 4.7 – Логічна схема системи (загальна) 
68 
 
ЧДТУ.232230.014 ПЗ 
 
 
 
Рисунок 4.8 – Логічна схема системи (Core) 
 
В загальній логічній схемі представлено 3 основні об’єкти системи.  
1 Інтерфейс користувача – взаємодія клієнтів з системою. Клієнт може 
авторизуватися, створити собі проєкт, завантажити в нього дані і провести 
моделювання. Результати моделювання представити у вигляді графіків, таблиць. 
69 
 
ЧДТУ.232230.014 ПЗ 
 
2 Core система – система, що проектується та розробляється в даній 
роботі. Містить в своєму складі алгоритми побудови системи для моделювання, 
їх комбінація. Має посилати запити Агентам для проведення моделювання і 
отримувати від них інформацію. 
3 Агенти – отримують дані з Core і будують модель. Результати 
повертають на Core. Можуть як проводити моделювання, так і повертати дані на 
основі раніше згенерованої моделі 
В логічній схемі Core системи представлено такі основні об’єкти:  
1 Перевірка доступу – дає можливість перевірити чи певний користувач 
(сервіс) має права на роботу з системою. 
2 Збереження вхідних даних – дає можливість зберігати дані проектів, які 
будуть надходити з UI. 
3 Побудова структури – дає можливість побудувати структуру. 
Базуючись на якій, будуть збиратися дані для відправки агентам. 
4 Побудова сценарію – дає можливість підготувати дані для відправки 
агентам 
5 Підготовка даних для агентів – безпосередньо процес підготовки 
даних, який базується на структурі та сценарію. 
6 Відправка даних агентам – безпосередньо процес відправки даних. 
7 Отримання результатів – дає можливість отримати результати від 
агентів. 
8 Аналіз та вибір найкращих результатів – дає можливість 
проаналізувати та вибрати найкращий результат. Тобто зрозуміти, який з агентів 
повернув найкращий результат. 
9 Збереження результатів – дає можливість зберегти результати роботи 
агентів для подальшого використання. 
4.1.4 Розробка бази даних 
Для успішної роботи системи необхідна база даних, котра буде зберігати 
всю інформацію пов’язану із роботою додатка. База даних – це інформаційна 
70 
 
ЧДТУ.232230.014 ПЗ 
 
модель, що дозволяє упорядковано зберігати дані про групу об'єктів, що 
володіють однаковим набором властивостей. Інформація в базах даних 
зберігається в упорядкованому вигляді, завдяки чому досягається висока 
швидкість обробки даних. 
На першому етапі моделювання бази даних створюється концептуальна 
модель бази даних (рис. 4.9.). Вона значно допомагає дослідити поняття 
проблемної області з точки зору замовника. 
 
 
Рисунок 4.9 – Концептуальна модель бази даних 
 
На основі концептуальної моделі бази даних можна побудувати фізичну 
модель. Для цього необхідно для кожної таблиці визначити зовнішній ключ, 
котрий буде пов’язувати записи у різних таблицях. Таким чином фізична модель 
буде значною мірою відрізнятись від концептуальної моделі. Всі ці перетворення 
необхідні для зменшення розміру бази даних, зокрема для раціонального 
71 
 
ЧДТУ.232230.014 ПЗ 
 
використання пам’яті комп’ютера. Фізична модель бази даних представлена на 
рис. 4.10. 
 
Рисунок 4.10 – Фізична модель бази даних 
 
Описана вище база даних буде знаходитись у третій нормальній формі, так 
як: 
1 Кожна таблиця має основний ключ: мінімальний набір колонок, які 
ідентифікують запис. 
2 Кожен атрибут має лише одне значення. 
3 Всі дані, що повторно з'являються в декількох колонках винесені в 
окремі таблиці. 
4 Всі поля, що залежать від основного ключа та від будь якого іншого 
поля, винесені в окрему таблицю.  
Перший та другий пункт відповідає за те, що база даних знаходиться в 
першій нормальній формі. Третій пункт відповідає, за те що база даних 
72 
 
ЧДТУ.232230.014 ПЗ 
 
знаходиться в другій нормальній формі, а четвертий пункт відповідає за те, що 
база даних знаходиться в третій нормальній формі. 
У базі даних буде зберігатися інформація про різні сутності, які необхідні 
для підготовки даних агентам. Далі буде наведено опис основних таблиць 
проекту.  
project_data – таблиця для збереження даних проекту (рис. 4.11). В даній 
таблиці будуть зберігатися масиви даних, які Core отримає з UI. І з яких в 
подальшому будуть формуватися структури даних для агентів. 
 
 
Рисунок 4.11 – Таблиця project_data 
 
project_data_columns – таблиця для збереження назв колонок (рис. 4.12), які 
в подальшому будуть використовуватися, щоб відобразити які саме колонки 
користувач хоче включити в структуру даних для передачі агентам. 
 
 
Рисунок 4.12 – Таблиця project_data_columns 
73 
 
ЧДТУ.232230.014 ПЗ 
 
agent_types – таблиця для збереження різних типів агентів (рис. 4.13). Дана 
таблиця також буде мати конфігурацію кожного типу агента. 
 
 
Рисунок 4.13 – Таблиця agent_types 
 
project_scenarios – таблиця для збереження сценаріїв (рис. 4.14). Згідно 
сценарію дані будуть готуватися для відправки агентам. 
 
 
Рисунок 4.14 – Таблиця project_scenarios 
 
project_scenarios_items – таблиця для збереження різних елементів 
сценарію (рис. 4.15). Кожен елемент може мати свою конфігурацію, яка 
базується на можливій конфігурації типу агенту. Згідно даної конфігурації дані 
будуть відправлятися агентам. 
74 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 4.15 – Таблиця project_scenarios_items 
 
project_structures – таблиця для збереження різних структур даних (рис. 
4.16). Базуючись на структурі даних, будуть збиратися дані для відправки 
агентам. 
 
 
Рисунок 4.16 – Таблиця project_structures 
 
project_structure_inputs – таблиця для збереження колонок (рис. 4.17), які 
будуть використовуватися як вхідні дані. Базуючись на даній таблиці система 
зможе структурувати дані, які гратимуть роль вхідних даних для агентів. 
 
75 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 4.17 – Таблиця project_structure_inputs 
 
project_structure_process – таблиця для збереження відправлених даних до 
агентів (рис. 4.18). Дана таблиця буде оновлюватися, коли будуть отримані 
відповіді з результати від агентів. 
 
 
Рисунок 4.18 – Таблиця project_structure_process 
 
Також система має ще додаткові системні таблиці, необхідні для її 
коректної роботи. 
4.1.5 Розробка інтерфейсу користувача 
Дана система є серверним додатком, тому вона не має інтерфейсу 
користувача. 
76 
 
ЧДТУ.232230.014 ПЗ 
 
4.1.6 Опис розробки програмних компонентів 
Система складається з певної кількості модулів, більшість з яких мають 
певну структуру. Файли які відносяться до конкретного модуля представлені на 
рис. 4.19. 
 
 
Рисунок 4.19 – Файлова структура модуля 
 
Якщо розглянути файли, то можна побачити що модуль містить файл 
модуля, контролер, сервіс, а також файли сутностей (директорія entities) та типи 
даних для даного модуля (директорія dto). 
Дана система має досить багато сервісів для CRUD операцій, томі всі 
сервіси наслідують  абстрактний сервіс BaseService. 
Лістинг даного базового абстрактного сервісу: 
export abstract class BaseService<T extends Record<string, 
any>> { 
  constructor(private readonly repository: Repository<T>) {} 
 
  findAll(): Promise<T[]> { 
    return this.repository.find(); 
  } 
 
  findBy(options: FindOptionsWhere<T> | 
FindOptionsWhere<T>[]): Promise<T[]> { 
    return this.repository.findBy(options); 
  } 
 
  findOneBy( 
    options: FindOptionsWhere<T> | FindOptionsWhere<T>[], 
  ): Promise<T | undefined> { 
    return this.repository.findOneBy(options); 
77 
 
ЧДТУ.232230.014 ПЗ 
 
  } 
 
  async create(data: DeepPartial<T>): Promise<T> { 
    return this.repository.save(this.repository.create(data)); 
  } 
 
  // INFO use this approach for avoiding "Cannot query across 
one-to-many for property" issue 
  async update(criteria: FindOptionsWhere<T>, data: 
Partial<T>): Promise<T> { 
    const entity = await this.repository.findOneBy(criteria); 
    if (!entity) throw new InternalServerErrorException('Not 
Record Found.'); 
 
    const payload = Object.assign(entity, data); 
 
    const res = await this.repository.save(payload); 
 
    return res && this.findOneBy(criteria); 
  } 
 
  async updateDirectly( 
    criteria: FindOptionsWhere<T>, 
    data: Partial<T>, 
  ): Promise<UpdateResult> { 
    return this.repository.update(criteria, data); 
  } 
 
  async delete(criteria: T['id'] | FindOptionsWhere<T>): 
Promise<boolean> { 
    const { affected } = await 
this.repository.delete(criteria); 
 
    return affected > 0; 
  } 
 
  async save(data: DeepPartial<T>): Promise<T> { 
    return this.repository.save(data); 
  } 
 
  async saveMany(data: DeepPartial<T>[]): Promise<T[]> { 
    return this.repository.save(data); 
  } 
} 
 
Ще варто звернути увагу на метод одного з сервісів, який відповідає за 
створення моделей. Даний метод розбиває вхідні дані, готує набори даних для 
агентів та створює задачі для агентів. Для кожної із підзадач реалізований 
окремий метод, який в свою чергу може також викликати інші методи. 
78 
 
ЧДТУ.232230.014 ПЗ 
 
Лістинг методу: 
async startModelCreation( 
  projectStructureId: string, 
  data: ModelCreationRequestDto, 
): Promise<boolean> { 
  // get all necessary data 
  const structure = await super.findOneBy({ id: projectStructureId 
}); 
  const scenario = await this.projectScenariosService.findOneBy({ 
    id: data.projectScenarioId, 
  }); 
 
  if (!structure) { 
    throw new NotFoundException('structure not found'); 
  } 
 
  if (!scenario) { 
    throw new NotFoundException('scenario not found'); 
  } 
 
  if (structure.projectId !== scenario.projectId) { 
    throw new InternalServerErrorException( 
      'projectId in structure and scenario should be the same', 
    ); 
  } 
  // split data on training and checking 
  const splittingData = await this.getSequencesSplittingData( 
    structure.projectId, 
    scenario.sequencesSplittingMethod, 
  ); 
 
  // prepare inputs and outputs 
  const preparedInputsOutputs = await this.prepareInputsOutputs( 
    structure, 
    splittingData, 
  ); 
 
  // make tasks for agents 
  await this.sendAgentTasks( 
    structure, 
    scenario.projectScenariosItems, 
    preparedInputsOutputs, 
  ); 
 
  return true; 
} 
79 
 
ЧДТУ.232230.014 ПЗ 
 
4.2 Тестування системи 
Етап тестування є досить важливим так, як тестування допомагає 
впевнитися, що програмний продукт відповідає вимогам, працює належним 
чином та виправдовує очікування користувачів. Це важливо для забезпечення 
якості і надійності системи.  
Даний етап допомагає ідентифікувати та виправляти помилки в системі на 
ранніх стадіях розробки. Чим раніше виявляються помилки, тим легше та 
дешевше їх виправляти. Також тестування допомагає виявити проблеми з 
продуктивністю та ефективністю програми, що дозволяє виправити їх та 
забезпечити оптимальну роботу системи. 
Ще варто зазначити, що процес тестування допомагає розробникам 
виявити та виправити проблеми у коді, покращуючи його читабельність, 
підтримуваність та ефективність. 
4.2.1 Модульне тестування 
Модульне тестування – це вид тестування, який перевіряє окремі 
компоненти (модулі) програми, щоб переконатися в їх коректності та 
працездатності. Модуль в даному випадку може бути функцією, класом, методом 
або іншою окремою частиною програми, яка має свою власну функціональність. 
Основна мета модульного тестування – перевірка правильності роботи 
окремих частин програми без урахування їх взаємодії з іншими компонентами. 
Воно дозволяє ізолювати конкретний модуль від решти системи та перевіряти 
його функціонування при різних вхідних даних. 
В даній роботі, під час розробки логіки, були написані також певна 
кількість Unit тестів для перевірки роботи конкретних контролерів та сервісів. 
Після запуску модульних тестів, можна переконатися, що всі тести 
проходять без помилок, а це означає – що було перевірено всі внутрішні 
структури і потоки даних у кожному модулі (для яких були написані тести). 
Результат проходження тестів представлено на рис. 4.20. 
80 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 4.20 – Результати модульного тестування 
 
4.2.2 Інтеграційне тестування 
Даний тип тестування не виноситься в окремий пункт, так як частина 
інтеграційне тестування буде частиною системного тестування, яке 
представлене в наступному пункті документу. 
4.2.3 Системне тестування 
Так як в даній роботі розроблялася частина іншої великої системи, а саме, 
серверна частина. То окремого інтерфейсу, за допомогою якого можна 
протестувати функціонал системи, в даній роботі не було реалізовано. Для 
тестування використовувався Postman, в якому була створена колекція запитів 
(рис. 4.21), за допомогою яких можна перевірити роботу сервісу. 
81 
 
ЧДТУ.232230.014 ПЗ 
 
 
Рисунок 4.21 – Postman колекція 
 
Для запуску всіх необхідних додаткових сервісів (рис. 4.22) системи 
потрібно виконати команду docker-compose up -d. В результаті виконання даної 
команди будуть запущені наступні сервіси: 
− база даних (labs-api-database); 
− ключ-значення сховище (labs-api-redis); 
− UI для  ключ-значення сховища (labs-redis-commander). 
 
 
Рисунок 4.22 – Результат запуску додаткових сервісів 
 
82 
 
ЧДТУ.232230.014 ПЗ 
 
Після того як додаткові сервіси системи запустилися, можна запускати сам 
Core сервіс. Для цього необхідно виконати команду yarn run start:dev.  
В результаті виконання даної команди буде запущений Core сервіс, в 
консолі можна побачити успішний запуск (рис. 4.23). 
 
 
Рисунок 4.23 – Результат запуску Core сервісу 
 
Після того як все запущено, можна посилати запити (додатку Б). Для цього 
можна використати запити з Postman колекції. 
Спробуємо виконати кілька запитів на створення деяких елементів та 
отримання інформації від Core. 
GET / agent-types – отримання інформації про типи агентів в системі. 
Результат виконання даного запиту представлений на рис. 4.24. 
 
 
Рисунок 4.24 – Результат виконання запиту отримання інформації про типи 
агентів 
83 
 
ЧДТУ.232230.014 ПЗ 
 
 
POST /project-data – збереження даних певного проекту. Результат 
виконання даного запиту представлений на рис. 4.25.  
 
Рисунок 4.25 – Результат виконання запиту збереження даних певного проекту 
 
POST /project-structures – створення структури. Результат виконання 
даного запиту представлений на рис. 4.26.  
 
 
Рисунок 4.26 – Результат виконання запиту створення структури 
84 
 
ЧДТУ.232230.014 ПЗ 
 
POST /project-scenarios  – створення сценарію. Результат виконання даного 
запиту представлений на рис. 4.27.  
 
 
Рисунок 4.27 – Результат виконання запиту створення сценарію 
 
POST /project-structures/[projectStructuId]/start-model-creation – створення 
моделей.  
Даний етап тестування варто розглянути уважніше. На цьому етапі дані 
готуються та відправляються агентам. Перш ніж даний метод розпочне 
працювати, статус певної структури даних має значення PENDING (рис. 2.28). 
Після відправки даних агентам статус буде змінений на IN_PROGRES. 
 
 
Рисунок 4.28 – Початковий стан структури даних 
 
Також в іншій таблиці, яка відповідає за збереження інформації про 
відправку даних певним агентам буде створено по одному запису на кожного 
агенту (зі статусом IN_PROGRES), кому було відправлено задачі. І коли буде 
85 
 
ЧДТУ.232230.014 ПЗ 
 
отримано відповідь від агенту статус буде змінено на COMPLETED або ERROR, 
в залежності від результатів роботи агенту (рис. 4.29). 
 
 
Рисунок 4.29 – Інформації про відправку даних агентам 
 
У випадку помилки обробки певної задачі, в черзі задач можна 
спостерігати помилку представлену на рис. 4.30. 
 
 
Рисунок 4.30 – Помилка обробки задачі 
 
Якщо всі агенти успішно опрацюють свої задачі, статуси будуть мати 
значення COMPLETED (рис. 4.31). Що й сталося при тестуванні системи. 
 
 
Рисунок 4.31 – Всі задачі успішно завершені 
 
86 
 
ЧДТУ.232230.014 ПЗ 
 
Також буде змінено статус в таблиці структури. При успішному виконанні 
статус також  буде COMPLETED (рис. 4.32). Також в даній таблиці буде 
збережено ідентифікатор агенту, який показав найкращий результат та його 
конфігурацію. 
 
 
Рисунок 4.32 – Стан структури даних, після успішного завершення 
роботи агентів 
 
В результаті тестування можна зробити висновок, що даний програмний 
продукт повністю відповідає поставленим вимогам та працює коректно. 
4.2.3 Приймальне тестування 
Цей вид тестування на даний момент провести неможливо, так як 
приймальне тестування проводиться організацією, що відповідає за інсталяцію, 
а система ще не є впровадженою. 
4.3 Приклади впровадженого програмного комплексу 
Додаток, що розроблявся в даній роботі є частиною іншої, більшої системи. 
Яка складається в декількох підсистем. І всі підсистеми на даний момент 
знаходяться на етапі активної розробки та вдосконалення і мають бути 
впровадженні в найближчому майбутньому.  
  
87 
 
ЧДТУ.232230.014 ПЗ 
 
Висновки до розділу 
В даному розділі було обґрунтовано вибір засобів реалізації. Для реалізації 
даної системи було використано Node.js, а саме, NestJS та TypeScript. В якості 
бази даних використано PostgreSQL. 
Була розроблена структурна схема інформаційної система, на базі якої, 
можна чітко зрозуміти, які основні модулі має система. Також детально описано 
логічну схему додатку, що дає можливість прослідкувати внутрішні зв’язки 
системи. 
Була розроблена концептуальна модель бази даних. Та на базі неї 
спроектована фізична модель. Додано опис основних таблиць, та надано 
пояснення необхідності кожної з них. Ще варто зазначити, що БД знаходиться у 
третій нормальній формі, що підтверджує правильність проектування БД. 
Завершальним етапом було тестування системи. Тестування проводилося 
як модульне так і системне, для максимальної перевірки коректності роботи 
додатку. Даний етап дав можливість впевнитися, що програмний продукт 
відповідає поставленим вимогам та працює належним чином.  
 
  
88 
 
ЧДТУ.232230.014 ПЗ 
 
ВИСНОВКИ 
У магістерській роботі вирішено актуальну задачу розробки інформаційної 
система з поліагентним функціоналом. Було розроблено Core підсистему, яка є 
частиною більш глобальної евристична система моделювання. 
Проведено теоретичні та експериментальні дослідження на основі яких 
було вирішено, який тип архітектури та спосіб комунікації найкраще підходить 
для проектованого додатку. Виконані дослідження дають підставу зробити такі 
висновки: 
1 Для побудови системи даного типу найкраще підходить мікросервісна 
архітектура, так як вона дає можливість швидко та ефективно проваджувати 
зміни в окремі компоненти без впливу на інші. Також завдяки даній  архітектурі 
система має можливість масштабування та управління ресурсами окремих 
сервісів незалежно від інших. 
2 Для комунікації Сore сервісу з агентами кращим рішенням є Message 
Broker, який дозволяє зменшити пряму взаємодію агентів з Сore сервісом та 
дозволить бути системі більш гнучкою та масштабованою. 
3 В результаті проведення експериментальних досліджень з’ясовано, що 
при використанні брокера повідомлень, як способу комунікації, жодного байту 
інформації не було втрачено. Також було з’ясовано, що при збільшенні об’єму 
даних, які передаються, збільшується час передачі, що не є критичним в даній 
роботі.  
Проведено моделювання інформаційна система з поліагентним 
функціоналом. Спроектовано та представлено загальний структурний опис 
системи, характеристики основних компонентів та модулів. Також 
проілюстровано діаграмами відповідно до вимог. 
 Виконано моделювання та проектування бази даних додатку, яка дає 
можливість покрити весь необхідний функціонал. Описана концептуальна 
модель бази даних, та на її основі побудована фізична модель. Надано короткий 
опис всіх основних таблиць БД для пояснення їхньої необхідності. 
89 
 
ЧДТУ.232230.014 ПЗ 
 
Розроблено додаток, який містить в своєму складі алгоритми побудови 
системи для моделювання, їх комбінації. Посилає запити агентам для проведення 
моделювання і отримує від них інформацію. Додаток реалізовано за допомогою 
Node.js, а саме, NestJS та TypeScript. В якості бази даних використано 
PostgreSQL. 
Проведено тестування системи за допомогою модульного тестування та 
системного, яке підтверджує коректність роботи  інформаційної системи в 
цілому та її окремих модулів. 
  
90 
 
ЧДТУ.232230.014 ПЗ 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Holub S., Kunytska S. Profiling of Clusters in Information Technologies of 
Intellectual Monitoring. Mathematical Modeling and Simulation of Systems 
(MODS'2020). Advances in Intelligent Systems and Computing / S. Shkarlet, A. 
Morozov, A. Palagin (eds). Springer, Cham. 2020. Vol. 1265. P. 227–236. 
2 Голуб С. В. Побудова ешелонів у поліагентних функціоналах для 
прогнозування кількості захворювань на covid-19 в Україні / С. В. Голуб, С. Ю. 
Куницька. // Математичні машини і системи. – 2021. – №2. – С. 45–51. 
3 Pattern: Monolithic Architecture [Електронний ресурс]. – Точка доступу: 
URL: https://microservices.io/patterns/monolithic.html 
4 Adopting Microservices at Netflix [Електронний ресурс]. – Точка 
доступу: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-
practices/ 
5 Microservices vs. Monolithic [Електронний ресурс]. – Точка доступу: 
URL: https://ncube.com/microservices-vs-monolithic-which-architecture-suits-best-
for-your-project/ 
6 Бідюк П.І., Корошевнюк Л.О. проєктування комп'ютерних 
інформацйних систем підтримки прийняття рішень: Навчальний посібник – 
Київ: ННК"ІПСА" НТУУ "КПІ", 2010. – 340 с. 
7 Авраменко В. С. Авраменко С. А. Проектування інформаційних систем 
/ В. С. Авраменко, А. С. Авраменко. – Черкаси: Чабаненко Ю. А, 2017. – 434 с. 
8 Agent-Oriented Software Engineering: Reflections on Architectures, 
Methodologies, Languages, and Frameworks / Onn Shehory (Editor), Arnon Sturm. 
Publisher: Springer; 2014th edition (June 24, 2014), 345 pages. 
9 Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence 
/ Jacques Ferber. Publisher: Addison-Wesley; 1st edition (January 1, 1999), 509 pages. 
10 Бази даних в інформаційних системах / Володимир Гайдаржи, Ігор 
Ізварін; за ред. Університет "Україна" – 2018. – 418 с. 
91 
 
ЧДТУ.232230.014 ПЗ 
 
11 Java Agent Development Framework [Електронний ресурс]. – Точка 
доступу (URL): https://en.wikipedia.org/wiki/Java_Agent_Development_Framework  
12 SPADE’s documentation [Електронний ресурс]. – Точка доступу (URL): 
https://spade-mas.readthedocs.io/en/latest/  
13 Jadex documentation [Електронний ресурс]. – Точка доступу (URL): 
https://www.activecomponents.org/index.html#/docs/overview  
14 RESTful Web APIs: Services for a Changing World / Leonard Richardson, 
Mike Amundsen, Sam Ruby. Publisher:  O'Reilly 2013, 406 pages. 
15 Enterprise Integration Patterns: Designing, Building, and Deploying 
Messaging Solutions / Gregor Hohpe, Bobby Woolf. Publisher: Addison-Wesley 
Professional; 1st edition (October 10, 2003), 736 pages. 
16 Стеценко І.В. Моделювання систем: навч. посіб. / І.В. Стеценко. М-во 
освіти і науки України, Черкас. держ. технол. ун-т. – Черкаси : ЧДТУ, 2010. – 399 
с. 
17 Node.js Design Patterns / Mario Casciaro, Luciano Mammino. Publisher:  
Packt Publishing; 2nd edition (July 18, 2016), 777 pages. 
18 A progressive Node.js framework [Електронний ресурс]. – Точка доступу 
(URL): https://nestjs.com/  
19 PostgreSQL: Up and Running / Regina Obe, Leo Hsu. Publisher: O'Reilly 
Media; 3rd edition (November 28, 2017), 312 pages. 
20 Севідов П.М. Прийняття колективних рішень в мультиагентних 
системах / П. М. Севідов. // Міжнародний науковий журнал "Інтернаука". – 2018. 
– №7. – С. 81–101. 
  
92 
 
ДОДАТОК А  
  
 ЗАТВЕРДЖЕНО:  
 Зав. кафедрою ПЗАС, професор   
_____________ Голуб С.В.  
 „____” _________________ 2023 р.  
  
  
  
  
Інформаційна система з поліагентним функціоналом 
  
  
  
Специфікація  
482.ЧДТУ.232230-01 
Листів 2  
  
  
Розробник  ________________   Левченко С.П.  
 
Керівник  ________________   Немченко В.В.  
 
Контроль  ________________   Півень О.Б. 
 
 
 
 
   
2023  
 482.ЧДТУ.232230-01  2 
 
Позначення  Найменування  Примітка  
482.ЧДТУ.232230-01 34 01 Інструкція користувача    
482.ЧДТУ.232230-01 12 01 Лістинг програми   
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
   
94 
 
ДОДАТОК Б 
  
 
 
 
  
  
  
Інформаційна система з поліагентним функціоналом 
  
  
  
Інструкція користувача 
482.ЧДТУ.232230-01 34 01 
Листів 2  
  
  
  
Розробник  ________________   Левченко С.П.  
 
 
 
 
 
 
   
 
 
 
2023  
 482.ЧДТУ.232230-01 34 01  2 
 
Для запуску всіх необхідних додаткових сервісів (рис. Б.1) системи 
потрібно виконати команду docker-compose up -d. В результаті виконання даної 
команди будуть запущені наступні сервіси: 
− база даних (labs-api-database); 
− ключ-значення сховище (labs-api-redis); 
− UI для  ключ-значення сховища (labs-redis-commander). 
 
 
Рисунок Б.1 – Результат запуску додаткових сервісів 
 
Після того як додаткові сервіси системи запустилися, можна запускати сам 
Core сервіс. Для цього необхідно виконати команду yarn run start:dev.  
В результаті виконання даної команди буде запущений Core сервіс, в 
консолі можна побачити успішний запуск (рис. Б.2). 
 
 
Рисунок Б.2 – Результат запуску Core сервісу 
 
  
96 
 
ДОДАТОК B  
  
 
 
 
  
  
  
Інформаційна система з поліагентним функціоналом 
  
  
  
Лістинг програми 
482.ЧДТУ.232230-01 12 01 
Листів 3  
  
  
  
Розробник  ________________   Левченко С.П.  
 
 
 
 
 
 
   
 
 
 
2023  
 482.ЧДТУ.232230-01 12 01  2 
 
System: 
GET [URL]/system/enums 
 
Projects: 
GET [URL]/projects/[ID]/data 
GET [URL]/projects/[ID]/structures 
GET [URL]/projects/[ID]/scenarios 
 
Agent types: 
GET [URL]/agent-types 
GET [URL]/agent-types/[ID] 
POST [URL]/agent-types 
PUT [URL]/agent-types/[ID] 
DELETE [URL]/agent-types/[ID] 
 
Project data: 
GET [URL]/project-data 
GET [URL] project-data/[ID] 
POST [URL]/project-data 
PUT [URL]/project-data/[ID] 
DELETE [URL]/project-data/[ID] 
 
Project scenarios: 
GET [URL]/project-scenarios 
GET [URL]/project-scenarios/[ID] 
POST [URL]/project-scenarios 
PUT [URL]/project-scenarios/[ID] 
DELETE [URL]/project-scenarios/[ID] 
 
98 
 
 482.ЧДТУ.232230-01 12 01  3 
 
Project structures: 
GET [URL]/project-structures 
GET [URL]/project-structures/[ID] 
POST [URL]/project-structures 
PUT [URL]/project-structures/[ID] 
DELETE [URL]/project-structures/[ID] 
POST [URL]/project-structures/[ID]/start-model-creation 
99