Ідентифікація звукових повідомлень програмним агентом

Білоніг, Анатолій Вікторович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9073
Title:	Ідентифікація звукових повідомлень програмним агентом
Authors:	Голуб, Сергій Васильович Білоніг, Анатолій Вікторович
Keywords:	Аналіз;алгоритм перетворення Фур`є;нейронна мережа;TensorFlow;синтезатор моделей;програмний агент
Issue Date:	23-Dec-2022
Abstract:	АНОТАЦІЇ Білоніг Анатолій Вікторович, кваліфікаційна робота магістра на тему: “Ідентифікація звукових повідомлень програмним агентом”. Напрям підготовки 121 “Інженерія програмного забезпечення”, ЧДТУ, Черкаси 2022. В даній кваліфікаційній роботі магістра проводиться дослідження процесу ідентифікації звукового повідомлення, способи виконання задачі, необхідні інструменти та засоби, можливості покращення ефективності процесу та точності отриманих результатів. Розроблюється система, що за допомогою використання програмних агентів, алгоритмів перетворення та моделей нейронних мереж буде виконувати процес розпізнавання особи-джерела звукового повідомлення, від початкового звукового файлу до результату у вигляді текстового повідомлення з результатом ідентифікації. Обсяг роботи – 109 сторінок, вона містить 4 розділи, 47 ілюстрацій, 5 таблиць, 25 джерел в переліку посилань, 3 додатки. Використані програмні засоби – JetBrains PyCharm, Git, Draw Io, IBM Rational Rose.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9073
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота магістра Білоніг Анатолій Вікторович.pdf Restricted Access		1.54 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
на тему: Ідентифікація звукових повідомлень програмним агентом 
Виконав: cтудент 2 курсу, групи МПЗ-2104 
Напряму підготовки: 
121“Інженерія програмного забезпечення” 
(шифр і назва напряму підготовки) 
___              
 Студент     _____Білоніг А.В.___________ 
(прізвище та ініціали)  -----      
 Керівник    _____Голуб С.В. ___________ 
(прізвище та ініціали)  ----- 
 Рецензент  __________________________ 
(прізвище та ініціали)  ----- 
Черкаси 2022 
ЧДТУ 222127.001 МПЗ 
АНОТАЦІЇ 
Білоніг Анатолій Вікторович, кваліфікаційна робота магістра на тему: 
“Ідентифікація звукових повідомлень програмним агентом”. Напрям підготовки 
121 “Інженерія програмного забезпечення”, ЧДТУ, Черкаси 2022. 
В даній кваліфікаційній роботі магістра проводиться дослідження 
процесу ідентифікації звукового повідомлення, способи виконання задачі, 
необхідні інструменти та засоби, можливості покращення ефективності процесу 
та точності отриманих результатів. 
Розроблюється система, що за допомогою використання програмних 
агентів, алгоритмів перетворення та моделей нейронних мереж буде 
виконувати процес розпізнавання особи-джерела звукового повідомлення, від 
початкового звукового файлу до результату у вигляді текстового повідомлення 
з результатом ідентифікації. 
Обсяг роботи – 109 сторінок, вона містить 4 розділи, 47 ілюстрацій, 5 
таблиць, 25 джерел в переліку посилань, 3 додатки. 
Використані програмні засоби – JetBrains PyCharm, Git, Draw Io, IBM 
Rational Rose. 
Ключові слова 
Аналіз, алгоритм перетворення Фур`є, нейронна мережа, TensorFlow, 
синтезатор моделей, програмний агент. 
2 
  ЧДТУ 222127.001 МПЗ  
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ..................................................................................... 5 
ВСТУП ........................................................................................................................................... 6 
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ .... 8 
1.1 Методи розв’язання задач з перетворення звукового повідомлення ..................... 8 
1.2 Методи розв’язання задач агентного прогрвмування ............................................ 11 
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ................................... 16 
2.1 Теоретичні дослідження ................................................................................................ 16 
2.2 Експериментальні дослідження ................................................................................... 21 
2.3 Висновки до розділу ....................................................................................................... 25 
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ ПРОЕКТУВАННЯ       
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ ............................ 27 
3.1 Моделювання предметної області ............................................................................... 27 
3.1.1 Предметна область моделювання. Модель предметної  області. Словник предметної 
області ................................................................................................................ 27 
3.1.2 Елементи моделювання предметної області ................................................... 28 
3.1.3 Робоча область моделювання ........................................................................ 29 
3.2 Формування та аналіз вимог ........................................................................................ 30 
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні вимоги. 
Вимоги замовника і розробника. Функціональні та не функціональні вимоги. ......... 31 
3.2.2 Формування вимог за допомогою діаграми прецедентів ................................. 33 
3.2.3 Проектування логічної структури програмного комплексу ............................. 35 
    3.2.3.1 Діаграма класів...................................................................................... 35 
    3.2.3.1 Діаграма пакетів .................................................................................... 35 
3.3.Архітектурне проектування ......................................................................................... 40 
3.3.1 Діаграма компонентів ................................................................................... 40 
3.3.2 Розгортання програмної системи на апаратних засобах. Діаграма розгортання . 41 
3.3.3 Моделювання поведінки системи .................................................................. 42 
    3.2.3.1 Діаграма діяльності ............................................................................... 42 
    3.2.3.2 Діаграма послідовності .......................................................................... 46 
 
ЧДТУ 222127.001 МПЗ 
Зм. Лист  № документа Підпис Дата  
Розроб. Білоніг А.В. 
Ідентифікація звукових повідомлень Літ. Лист Листів 
Керівник Голуб С.В. Н 3 109 
програмним агентом 3 
ФІТІС,  
Н.контр.  Півень  О.Б. Пояснювальна записка 
Кафедра ПЗАС, МПЗ-2104 
Затв.  
С, 
 
 ЧДТУ 222127.001 МПЗ  
 
    3.2.3.3 Діаграма комунікації ............................................................................. 48 
    3.2.3.4 Діаграма скінченного автомату ............................................................... 49 
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ....................... 51 
4.1 Розробка програмного комплексу ............................................................................... 51 
4.1.1 Обґрунтування вибору засобів реалізації ....................................................... 51 
4.1.2 Опис структурної (функціональної) схеми ..................................................... 52 
4.1.3 Опис логічної схеми системи ........................................................................ 55 
4.1.4 Розробка бази даних ..................................................................................... 56 
4.1.5 Розробка інтерфейсу користувача.................................................................. 57 
4.1.6 Опис розробки програмних компонентів ....................................................... 59 
4.2 Тестування системи ....................................................................................................... 61 
4.2.1 Модульне тестування ................................................................................... 61 
4.2.2 Інтеграційне тестування ............................................................................... 62 
4.2.3 Системне тестування .................................................................................... 63 
4.2.4 Приймальне тестування ................................................................................ 67 
4.3.Приклади впровадженого програмного комплексу ................................................ 68 
ВИСНОВКИ ............................................................................................................................... 71 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ............................................................................... 74 
Додаток А .................................................................................................................................... 76 
Додаток Б .................................................................................................................................... 78 
Додаток В .................................................................................................................................. 102 
 
 
  
ЧДТУ 222127.001 МПЗ 
Зм. Лист № документа Підпис Дата 
Розроб. Білоніг А.В. Літ. Лист Листів 
Керівник Голуб С.В. Ідентифікація звукових повідомлень 
Н 4 1409  
програмним агентом  
 ФІТІС, 
Н.контр. Півень  О.Б. Пояснювальна записка 
Кафедра ПЗАС, МПЗ-2104 
Затв.  
С, 
 ЧДТУ 222127.001 МПЗ  
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
1. ДПФ – Дискретне Перетворення Фур`є; 
2. ШПФ – Швидке Перетворення Фур`є; 
3. API – (Application Programming Interface) – набір підпрограм та методів 
для взаємодії різних компонентів; 
4. Гц – Герц, одиниця вимірювання в системі SІ частоти періодичних 
процесів; 
5. ПЗ – Програмне забезпечення; 
6. ООП – Об`єктно-Орієнтоване Програмування; 
7. UML – Unified Modeling Language (Унфікована Мова Моделювання); 
8. IDE – Integrated development environment (Інтегроване Середовище 
Розробки); 
9. UI – User Interface (Інтерфейс Користувача); 
 
  
5 
 
 ЧДТУ 222127.001 МПЗ  
ВСТУП 
 Аналіз звукових повідомлень відіграє важливу роль у сучасному світі. Від 
можливості віддавати команди новітнім інтелектуальним системам та 
приладам, домашнім роботам чи стаціонарним системам, до аналізу особи-
джерела повідомлення у військовій сфері чи сфері державної безпеки. На даний 
момент було розроблено декілька працездатних варіантів даних систем, але як і 
в багатьох інших сферах, існують широкі можливості для покращення 
ефективності та надійності. 
 Обрана тема дослідження напряму пов’язана із науковою програмою 
напряму підготовки “Інженерія програмного забезпечення”, оскільки 
проводиться дослідження, проектування та створення програмного комплексу 
для виконання поставлених задач.  
 Мета дослідження - удосконалення процесу формування вимог до 
програмного агента шляхом дослідження процесу ідентифікації звукових 
повідомлень. 
Завдання дослідження - провести інформаційний пошуків методів та 
способів розв`язання задачі, дослідити процес перетворення звукового 
повідомлення до форми масиву вхідних даних, визначення впливу результатів 
дослідження на процес формування вимог до формування ПЗ(агента), 
реалізація отриманих результатів у формі технології агентного програмування 
для побудови засобу ідентифікації звукових повідомлень. 
Об`єкт дослідження - технологія агентного програмування, алгоритм 
перетворення звукового запису. 
Предмет дослідження - процес формування вимог до програмного 
забезпечення для побудови засобу ідентифікації звукових повідомлень.  
Для досягнення поставленої задачі використовується системний підхід до 
дослідження, з теоретичних методів було вирішено обрати індукцію та аналіз. 
Під час виконання роботи подальшого розвитку набуло використання 
методу перетворення Фур’є в процесі перетворення звукового сигналу на 
числові дані, визначено ефективність використання тих чи інших отриманих 
6 
 
 ЧДТУ 222127.001 МПЗ  
даних в процесі ідентифікації. Удосконалено процес навчання моделей 
нейронних мереж, шляхом динамічної зміни параметрів під час процесу 
навчання набору моделей. 
 Щодо практичних значень одержаних результатів можна відмітити: 
 розроблено програмні засоби для аналізу та розпізнавання звукових 
повідомлень; 
 проаналізовано алгоритм перетворення Фур`є та розроблено відповідні 
моделі для ефективної роботи алгориту; 
  перевірено та протестовано ефективність роботи розробленого 
програмного агенту. 
Усі наукові результати, подані у роботі, одержані здобувачем особисто. У 
друкованих працях, опублікованих у співавторстві, внесок здобувача 
наступний: досліджено можливості використання альтернативних способів для 
забезпечення захисту зв’язку та передачі даних [1], досліджено використання 
агентів та їх відмінності від стандартних програм на прикладі системи для 
ідентифікації звукових повідомлень [2], запропоновано модель програмного  
агенту для проведення атрибуції звукових повідомлень[2].  
Результати досліджень було оприлюднено: 
 Дванадцята міжнародна науково-технічна конференція 2022 року 
“Сучасні напрями розвитку інформаційно-комунікаційних технологій та засобів 
управління” . 
  П’ятнадцята міжнародна науково-практична конференція 2022 року 
“Інтегровані інтелектуальні робототехнічні комплекси”. 
Було опубліковано тези дослідження: “Ідентифікація звукових 
повідомлень програмним агентом” [1], “Профілізація бібліотек віртуального 
робота-аналізатора звукових повідомлень” [2]. 
  
7 
 
 ЧДТУ 222127.001 МПЗ  
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ 
 Розпізнавання голосу – процедура, результат якої має бути якомога 
точним, для ефективного використання функції чи програми, де ця функція 
використовується. Одним із найважливіших етапів процесу розпізнавання 
голосу є процес перетворення звукового сигналу в числові данні, а допомогою 
яких у подальшому буде можливо провести ідентифікацію. 
1.1 Методи розв`язання задач з перетворення звукового повідомлення 
Одним із найбільш відомих та найчастіше використовуваним є метод 
перетворення названий на честь математика Жозефа Фур`є.  
Перетворення Фур’є – це математичне перетворення, яке розкладає 
функції, залежні від простору або часу, на відповідні функції, залежні від 
просторової або часової частоти. Такий процес ще називають аналізом. Термін 
«перетворення Фур’є» відноситься як і до частотного представлення, так і до 
математичної операції, що пов’язує частотне представлення з функцією часу 
або простору. 
Суть перетворення Фур’є полягає в розкладанні сигналу на суму синусоїд 
різних частот.  Якщо ці синусоїди в резульаті можна підсумувати до початкової 
форми сигналу, то результат і є визначенням перетворення Фур’є. Графічне 
уявлення перетворення Фур'є - це діаграма, яка відображає амплітуду та 
частоту кожної з визначених синусоїд. 
 Перетворення Фур’є розрізняє різні частотні синусоїди (і їхні відповідні 
амплітуди), які об’єднуються, утворюючи довільну форму сигналу. 
Перетворення та обернене перетворення Фур'є функції f(t) математично 
визначається як функція f(ω), що задається наступними виразами: 
 
 
8 
 
 ЧДТУ 222127.001 МПЗ  
Основою перетворення Фур'є є використання рядів Фур'є, тобто коли 
складна функція представляється (перетворються) сумою більш-простих 
функцій, кількість яких може бути необмеженою. В такому випадку, чим 
більше подібних функцій було використано при обрахунках тим більшою буде 
остаточна точність бажаної функції. 
У випадку перетворення Фур'є, ми отримаємо суму певної кількості 
простих хвиль, що в математичному представлення будуть виглядати як 
функції синусів чи косинусів. Отже, перетворення Фур'є це окремий випадок 
рядів, коли період функції подовжений і наближається до нескінченності. 
Використавши визначені властивості синусів і косинусів, можна 
отримати амплітуду кожної хвилі ряду за допомогою інтегралів. Також у 
багатьох випадках можна використовувати формулу Ейлера, що стверджує, що 
для будь-якого дійсного числа виконується наступна рівність: 
 
а значить, що ряд Фур'є можна відобразити через елементи базових хвиль. 
Представлення синусів і косинусів як комплексних експонент приводить 
до того, що отримані після перетворення Фур'є коефіцієнти є комплексними 
значеннями. Зазвичай такі значення інтерпретують так, що вони описують 
амплітуду хвилі, тобто розмір, що є складовою заданої функції, та фазу хвилі, 
тобто її початковий кут. 
 Широкого ж розповсюдження набув метод дискретного перетворення 
Фур`є (ДПФ), а якщо бути більш-точним, дискретне перетворення Фур’є 
масиву дійсних чисел за допомогою ефективного алгоритму під назвою 
Швидке перетворення Фур’є (ШПФ), принцип дії якого зображено на рисунку 
(Рис. 1.1). 
Швидке перетворення Фур’є є широко використовуваним способом 
обробки сигналів і концепцією аналіу інформації. Завдяки наявності апаратного 
забезпечення спеціального призначення як у комерційному, так і у військовому 
9 
 
 ЧДТУ 222127.001 МПЗ  
секторах було створено ріноманітні складні систем обробки сигналів на основі 
функцій ШПФ. 
 
Рис. 1.1 – Графічне відображення процесу Швидкого перетворення Фур’є 
 Реалізація відповідних алгоритмів в складних системах зробила раніше 
неможливі способи вирішення задач, легко досяжними [3]. Розповсюдження 
персональни комп'ютерів спричинило ще більше поширення та використання 
програм в основі яких був алгоритм ШПФ. Для студента, працівника-
професіонала, що працює вдома, інженерів ріних галузей, програмістів і 
аналітиків, ШПФ став безцінним інструментом для вирішення різноманітних 
проблем. 
 Про популярність ШПФ свідчить широкий спектр застосування методу в 
різних областях. На додаток до традиційних пристроїв таких як: радари, засоби 
зв’язку, гідролокації та перетворення мови в сигнал, поточні сфери 
використання ШПФ включають біомедичну інженерію, візуалізацію, аналіз 
даних фондового ринку, спектроскопію, металургійний аналіз, аналіз 
нелінійних систем, механічний аналіз, геофізичний аналіз, моделювання, 
музичний синтез і тд. 
 Отже, якщо підсумувати ШПФ є важливим методом дискретного 
перетворення оскільки, як видно  назви він є швидким у обчисленні того, що 
здається повільним на перший погляд [4]. Дискретне переворення Фур’є, в 
свою чергу, є важливим з декількох причин: 
 ДПФ займає центральне місце в цифровій обробці сигналів. Це один із 
найважливіших інструментів для аналізу сигналів і систем у цифровому світі та 
10 
 
 ЧДТУ 222127.001 МПЗ  
є основою мови, що використовується для опису сигналів і різноманітного 
маніпулювання ними; 
 Обчислення згорток (витків) за допомогою ДПФ набагато ефективніше, 
ніж використання безпосереднього визначення. Згортки зустрічаються в 
багатьох місцях, таких як поліноміальне множення та зміна систем у сферичних 
координатах (наприклад, в електромагнетиці); 
 Перетворення, подібні до ДПФ, і їх можна обчислити за допомогою 
ШПФ. Множення матриці-вектора, яке можна перетворити як таке 
перетворення, робить його набагато ефективнішим у використанні в алгоритмі. 
Іншими словами, якщо певний алгоритм потребує множення матриці-вектора 
на кожному кроці, це має величезну різницю у часі виконання, щоб 
перетворити множення матриці-вектора як ШПФ-подібне перетворення. 
 Що стосується різноманітних програм та ресурсів для перетворення 
звукового сигналу в текст, існує певна кількість розроблених систем, що 
використовуються в тому чи іншому вигляді для різних цілей, побудованих за 
різними принципами. 
1.2 Методи розв`язання задач агентного програмування 
Агентно-орієнтоване програмування (АОП) — це парадигма 
програмування, де побудова програмного забезпечення зосереджена на 
концепції програмних агентів. На відміну від іншої популярної парадигми 
об’єктно-орієнтованого програмування, в основі якого є об’єкти, в основі АОП 
є агенти, визначені ззовні, що мають інтерфейси та можливості обміну 
повідомленнями. Їх можна розглядати як певні абстракції об’єктів. 
Повідомлення, якими вони обмінюються, інтерпретуються спеціальними 
приймаючимими "агентами" у спосіб, що буде специфічним для його класу 
агентів. 
Термін «агент» походить від латинського дієслова «agere», що означає 
«діяти», «рухати», «правити», «керувати». В словниках можна знайти наступні 
11 
 
 ЧДТУ 222127.001 МПЗ  
визначення терміну: агент – Представник, довірена особа організації, установи і 
т. ін., що виконує різні доручення, завдання [5]. 
Це визначення досить коректно виражає суть і сучасних інформаційних 
агентів, що можуть працювати автономно від імені свого власника (особи-
користувача або іншої обчислювальної системи) і вирішувати різноманітні 
завдання з обробки інформації[6].  
Саме поняття агенту, як такого, може мати декілька різних визначень:  з 
одного боку, агенти у різних фізичних представленнях, що розташовані у тому 
чи іншому вигляді, наприклад, на фабриках – роботи, агенти, розташовані у  
комп’ютерних мережах – софт-боти, призначені для виконання конкретних 
завдань – таск-боти і різноманітні автономні, або мобільні агенти, що 
працюють у динамічних або невизначених середовищах. З іншого боку, агенти 
можуть відігравати багато ролей, наприклад, персональні помічники, що 
володіють експертними знаннями в певній, визначеній області [7]. 
Для успішної та коректної роботи агент повинен володіти достатніми 
інтелектуальними здібностями, повинен мати можливість взаємодіяти з 
власником(користувачем) для отримання завдань і передачі результатів, 
повинен орієнтуватися в середовищі свого існування і повинен приймати 
необхідні рішення, відносно ситуацій, що виникають. 
Дві базові характеристики – автономність і цілеспрямованість дозволяють 
відрізняти агенти від інших програмних чи апаратних об’єктів (модулей, 
підпрограм, процедур, тощо). Наявність доцільності поведінки вимагає, щоб 
інформаційний агент володів властивістю реактивності. Такий рівень інтелекту 
може відповідати рефлекторній поведінці тварини. Якщо ж агент володіє 
знаннями про середовище, власні цілі та способи їх досягнення, то такий агент 
може бути названий розумним. 
Таким чином, може бути проведена межа між інтелектуальними і не 
інтелектуальними агентами 
Відповідно базових характеристик можна визначити наступні властивості 
агенту, що були представлені М.Вулдриджом и Н.Дженнінгсом[8]: 
12 
 
 ЧДТУ 222127.001 МПЗ  
 автономність - здатність функціонувати без прямого втручання людей або 
інших комп'ютерних засобів і при цьому здійснювати контроль над власними 
діями та внутрішніми станами; 
 громадську поведінку (social ability), тобто здатність взаємодії з іншими 
агентами або користувачами, обмінюючись повідомленнями за допомогою 
різноманітних способів комунікації; 
 реактивність, тобто здатність сприймати стан середовища (фізичного 
світу, користувача)  через інтерфейс користувача, сукупності інших агентів, 
мережі інтернет, або відразу всі ці компоненти зовнішнього середовища); 
 цілеспрямована активність (pro-activity) – здатність агентів не просто 
реагувати на команди, що надходять із середовища, а й здійснювати 
цілеспрямовану поведінку, проявляючи ініціативу. 
Відповідно, якщо розглянути певну систему абстрактних полярних шкал 
типу “пасивний – активний”, або “залежний–автономний” та помістити на них 
об'єкти та агенти, то стане зрозумілоо, що об'єкти будуть перебувати на лівих 
полюсах, а агентиповинні бути розташовані правіше, ближче до полюсів 
“активний”, “автономний”[8]. 
Таким чином, агентно-орієнтований підхід в інформатиці та штучному 
інтелекті є розвитком вже відомих підходів, заснованих на поняттях об'єктів та 
акторів, але водночас має низку важливих відмінностей. 
Об'єкт має єдине ім'я, свої власні дані та процедури. Об'єкт може 
складатися з кількох так само визначених об'єктів і в свою чергу може бути 
частиною більшого об'єкта. Об'єкти містять слоти, які у свою чергу можуть 
складатися із фактів. Слот може бути просто атрибутом чи ставленням. Всі дії в 
ООП виконуються через повідомлення (проте повідомлення вказують об'єкту, 
що робити, але не як робити).  
Об'єкти не можуть аналізувати свою поведінку, визначати характер своїх 
зв'язків з іншими об'єктами або природою адресованих ним повідомлень. Їх 
13 
 
 ЧДТУ 222127.001 МПЗ  
механізм отримання повідомлень зводиться до виклику процедури. А головне, 
вони не можуть самостійно формувати цілі. 
Для коректного розуміння та ефективної роботи необхідно провести 
класифікацію агентів, але відразу виникне питання за якими критеріями 
проводити класифікацію? 
Можна запропонувати чимало варіантів для побудови класифікацій 
агентів. Найбільш очевидними є критерії класифікації, схожі на раніше  згадані 
полярні шкали, «природне-штучне» та «матеріальне-ідеальне». За першим 
критерієм, виділяються натуральні агенти (тварини, люди, групи організмів, 
колективи людей) та штучні агенти (роботи, колективи автоматів, складні 
комп'ютерні програми). Але предметом обговорення цієї роботи власне є лише 
штучні агенти, тому необхідно більш зосередитися на їх класифікації. 
Після розгляду певної кількості варіантів можна виділити класифікацію, 
що була побудована по наступним двом ознакам: ступінь розвитку 
внутрішнього уявлення зовнішнього світу та  спосіб поведінки [8]. 
 
Рис. 1.2 – Класифікація агентів 
Когнітивні агенти мають більш багате представлення зовнішнього 
середовища, ніж реактивні. Це досягається за рахунок наявності у них бази 
знань та механізму вирішення. Також досить важливою відмінністю є те, що 
реактивні агенти мають дуже обмежений діапазоном передбачення. Вони 
14 
 
 ЧДТУ 222127.001 МПЗ  
практично не здатні планувати свої дії, оскільки реактивність у чистому вигляді 
означає таку структуру зворотного зв'язку, яка не містить механізмів прогнозу, 
тобто передбачення. У той же час когнітивні агенти, завдяки розвиненим 
внутрішнім уявленням зовнішнього середовища та можливостям міркувань 
можуть запам'ятовувати та аналізувати різні ситуації, передбачати можливі 
реакції на свої дії, робити з цього висновки, корисні для подальших дій і, в 
результаті планувати власну поведінку. 
За типом поведінки інтелектуальні агенти поділяються на інтенціональні 
та рефлекторні, а реактивні – на спонукаючі та трофічні. 
Більшість інтелектуальних (когнітивних) агентів можна віднести до 
інтенціональних. Подібні агенти наділені власними механізмами мотивації. Це 
означає, що в них так чи інакше моделюються внутрішні переконання, бажання, 
наміри та мотиви, що породжують цілі, та які визначають їх дії. У свою чергу, 
модульні або рефлекторні агенти не мають внутрішніх джерел мотивації та 
власних цілей, а їхня поведінка характеризується найпростішими висновками 
чи автоматизмами. 
У свою чергу, реактивні агенти містять скомпіловані знання по 
необхідним діях: їм не треба будувати докладне внутрішнє уявлення 
зовнішнього середовища, оскільки цілком достатніми є набір реакцій на набір 
ситуацій, тобто. Характер реакції визначається лише поточною інформацією. За 
складністю цих реакцій та походженням джерел мотивації реактивні агенти 
поділяються на спонукаючі та трофічних агентів. У разі трофічних агентів 
поведінка визначається найпростішими трофічними зв'язками. Фактично воно 
зводиться до відповіді стимули, що надходять із довкілля (власних мотивів і 
цілей немає), тобто. повністю визначається її локальним станом. 
Подібна класифікація допомагає краще розуміти внутрішні процеси та 
принципи роботи тих чи інших програмних агентів та ще сильніше побачити їх 
відмінності з іншими парадигмами програмування, щоб в результаті 
розроблювати ефективні системи для коректного виконання різноманітних 
задач.  
15 
 
 ЧДТУ 222127.001 МПЗ  
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1 Теоретичні дослідження 
Для успішної ідентифікації звукового повідомлення необхідна коректна 
взаємодія декількох процесів. 
Насамперед звукове повідомлення необхідного формату та задовільної 
якості.  
На даний момент часу існує велика кількість форматів, що 
використовуються у різних галузях та з різними цілями, від популярних, що 
зустрічаються кожного дня до вузькоспеціалізованих, що використовуються 
лише, наприклад, у наукових цілях.  
Такі формати як MP3, M4A, MP4 є досить популярними для збереження 
аудіо записів, але існує досить значна проблема, якщо дивитися зі сторони 
аналізу такого файлу. Такі формати поєднує стиснення аудіо. У 90-х люди 
швидко зрозуміли, що зберігати на носіях або надсилати нестиснені файли 
через Інтернет було неефективно та повільно − а часто й неможливо, тому 
формати, що виносять стиснення на передній план, стали популярні. З 
розвитком технологій ця популярність не зникла, оскільки не зважаючи на те, 
що сучасна швидкість передачі даних в мережі суттєво зросла, зберігати на 
серверах чи носіях великі файли недоцільно або занадто дорого. 
Але при стисненні файлу з`являється проблема з якістю. Для точного 
аналізу звукового сигналу нам необхідний файл з мінімальним стисненням, 
щоб відмічати навіть мінімальні зміни чи відмінності між різними записами. 
Тому, найоптимальнішим буде використання формату WAV або Waveform 
Audio File, що зберігає дані форми сигналу запису. Характерним для WAV 
формату є відсутність стиснення взагалі. Дані зберігаються у повному 
оригінальному форматі, що не потребує подальшої розшифровки. У процесі 
запису та відтворення майже не відбувається суттєвих втрат якості звуку. Це 
забезпечує величезну універсальність, що дозволяє чудово редагувати та 
маніпулювати такими записами. 
16 
 
 ЧДТУ 222127.001 МПЗ  
Далі для процесу ідентифікації необхідна система для перетворення 
звукового повідомлення в набір придатних для подальшої обробки числових 
даних. 
На початку обробки звукового файлу його необхідно розділити на 
проміжки рівної довжини, від кількості проміжків та їх тривалості буде  
залежати точність кінцевого результату, але в той же час кількість проміжків 
впливає на кінцеву тривалість обробки, оскільки збільшується загальну 
кількість даних. 
Як було визначено раніше перетворення файлів буде відбуватися за 
допомогою швидкого перетворення Фур’є. Процес перетворення буде 
проводитися над кожним проміжком отриманим після розбиття початкового 
файлу. З отриманих результатів нас цікавлять відношення Частота-Амплітуда 
та Частота-Фаза для проміжку. Дані організовуються у прийнятний до 
подальшої обробки вигляд. 
Кінцевим етапом процесу ідентифікації буде побудова ефективної моделі 
для обробки, аналізу даних та подальшого прогнозування результату. 
Для проведення досліджень було вирішено побудувати модель за 
алгоритмом методу групового урахування аргументів. 
Подібні алгоритми є ефективним засобом розв’язання задач 
прогнозування, структурно-параметричної ідентифікації, побудови моделей 
об'єктів і процесів за даними спостережень в умовах невизначеності та низького 
рівня апріорних знань про модельований об’єкт. Особливість цих алгоритмів 
МГУА полягає в тому, що вони знаходять оптимальну структуру моделі в 
результаті мінімізації помилки прогнозування на скінченній множині моделей 
різної структури [9]. 
Комбінаторний алгоритм МГУА заснований на повному переборі 
варіантів структур моделей для пошуку найефективнішої в заданій ситуації та з 
заданими параметрами. Проте алгоритм обмежений у практичному 
застосуванні, оскільки потребує великих витрат обчислюваних ресурсів і часу 
та без використання спеціальних засобів не дозволяє розв’язувати задачі з 
17 
 
 ЧДТУ 222127.001 МПЗ  
більш ніж 30-ма вхідними змінними (аргументами) навіть на сучасних 
комп’ютерах. 
Перевагою і тим  на що варто звернути увагу при подальшій роботі над 
поставленою задачею є те, що перебірні алгоритми МГУА дають можливість 
ефективно розв’язувати актуальні проблеми штучного інтелекту, оскільки 
автоматично знаходять закономірності, що діють в системі, та дозволяють 
зменшити безпосередній вплив користувача на кінцеві результати 
моделювання. 
Для застосування безпосередньо у дослідницькій системі було вирішено 
використовувати нейронні мережі, а якщо більш точно то моделі побудовані на 
основі згорткових нейронних мереж, що використовуються для класифікації і 
розпізнавання різноманітних об`єктів, у нашому ж випадку це буде особа-автор 
голосу на аудіо записі. 
Згорткові нейронні мережі – один з класів штучних нейронних мереж, що 
побудований на біологічному процесі зорової кори тварин. Окремі нейрони 
реагують на певні стимули, тобто впливи, лише у своїй області поля зору, 
відомій під назвою рецептивного поля, такі поля у загальному вигляді частково 
перекриваються, що дозволяє, в свою чергу, перекрити усе все поле зору [10]. 
Згорткові нейронні мережі, розроблені так, щоб використовувати 
стандартний багатошаровий перцептрон (Рис. 2.1), що виконує задачу лінійного 
розділення нелінійних множин за допомогою елементів, що надають певні 
сигнали, до асоціативних елементів, які в свою чергу передають їх до 
реагуючих. Проте з метою використання мінімального обсягу попередньої 
обробки. 
Такий тип нейронних мереж складається з різних типів шарів: входу, 
виходу та прихованих шарів, що в свою чергу, частіше всього складаються зі 
шарів нормалізації, згорткових шарів, агрегувальних шарів та повноз'єднаних 
шарів. 
 
18 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 2.1 – Приклад багатошарового перцептрона 
Згорткові шари застосовують до вхідних даних операцію, що імітує 
реакцію певного окремого нейрону на зоровий стимул, у такому випадку 
кожний згортковий нейрон обробляє дані лише для свого рецептивного поля, 
тобто лише певний набір параметрів. 
Агрегувальні шари можуть бути присутні в згорткових нейронних 
мережах, такі шари об'єднують виходи кластерів нейронів одного шару до 
одного нейрону для обробки в наступному шарі. Існують декілька виглядів 
агрегування, наприклад максимізаційне, що обирає максимальне значення, або 
усередню вальне, що відповідно бере середнє значення. 
Повноз'єднані шари, так само як і в стандартній нейронній мережі 
багатошарового перцептрону, поєднують кожен нейрон попереднього шару з 
нейроном наступного шару. 
В системі було вирішено використати набір бібліотек для машинного 
навчання TensorFlow, велика кількість особливостей, інтеграції сторонніх 
бібліотек та можливість використовувати бібліотеки на різних мовах 
програмування роблять цей набір інструментів ідеальним для вирішення 
поставлених задач. 
Отже, отримана інформація дозволяє сформулювати наступну гіпотезу: 
при правильному перетворенні звукового сигналу в набір числових даних, 
19 
 
 ЧДТУ 222127.001 МПЗ  
коректній обробці даних та їх подальшому застосуванні у налаштованій моделі 
можливо ідентифікувати особу-джерело звукового сигналу. 
На основі вищеописаних даних можна побудувати схематичну 
структурну модель досліджуваної системи: 
 
Рис. 2.2 – Модель розроблюваної системи 
 Після побудови дослідницької системи необхідно скласти план та 
провести математичні дослідження для визначення можливості та ефективності 
роботи обраних методів та інструментів їх виконання. Визначення оптимальної 
довжини відрізку звукового файлу для збільшення точності подальшої 
ідентифікації, виявлення частотних діапазонів використання яких буде 
найбільш ефективним, та допоможе виключити дані, що мало впливають на 
кінцевий результат, що допоможе збільшити швидкість роботи системи шляхом 
20 
 
 ЧДТУ 222127.001 МПЗ  
зменшення загальної кількості даних для обрахунків. Проведення тестових 
перетворень та визначення ефективності застосованих методів, для отримання 
інформації щодо оптимізації роботи програми. 
2.2 Експериментальні дослідження 
 Після визначення загального алгоритму роботи було проведено певну 
кількість експериментальних досліджень, суть яких полягає у проходженні 
повного циклу роботи системи та визначення її ефективності, виявлення 
недоліків та можливих покращень. 
 Першим етапом дослідження є вибір певної кількості аудіо записів, де 
один або декілька записів будуть належати одній особі, що у подальшому буде 
помічена як “свій” для дослідницької системи, та аудіо записів з голосами 
інших осіб чи сторонніми звуками для використання при навчанні як “чужий”. 
 Обрані аудіо записи розділяються на частини для збільшення точності 
кінцевих даних, та для виявлення більшої кількості відмінностей між записами 
чи їх частинами. Хоча в системі передбачене довільне задання тривалості 
проміжків найкраще себе показали проміжки тривалістю в 1000 та 500 
мілісекунд, 1 та 0,5 секунди відповідно. Зменшення тривалості проміжків хоч і 
надає більше даних для подальшого обчислення але не завжди збільшення їх 
кількості сприятливо позначається на результаті, кінцева точність збільшується, 
але не досить значно. В свою чергу, збільшується тривалість роботи додатку, 
що в результаті призводить до зменшення загальної кількості робочих циклів 
системи і зменшення кількості кінцевих результатів. 
 Отримані відрізки зберігаються системою та перетворюються на числові 
дані. 
 Для перетворення використовується алгоритм швидкого перетворення 
Фур`є, поданий у вигляді програмного методу із бібліотеки numpy для мови 
Python. У разі необхідності запис перевіряється на одноканальність чи 
двоканальність та перетворюється на сприятливий формат. Метод використовує 
алгоритм перетворення та дозволяє в результаті отримати пари даних частота – 
фаза та частота – амплітуда для кожного відрізку раніше перетвореного запису. 
21 
 
 ЧДТУ 222127.001 МПЗ  
 Для перетворення обирається набір відрізків, що були отримані після 
розбиття почтакового файлу, вказується частотний діапазон, в межах якого дані 
буде записано для подальшої обробки та додається вказівник свій чи чужий у 
числовому вигляді де свій це 100 а чужий 0, вказівник необхідний для 
подальшого навчання моделі. 
Отримані числові дані групуютсья, форматуються до сприятливого 
вигляду та записуються у зовнішні файли Excel формату. Після перетворення 
дані мають наступний вигляд: 
 
Рис. 2.3 – Числові амплітудні дані звукових файлів 
 
Рис. 2.4 – Числові фазові дані звукових файлів 
 Подібні набори числових даних формуються для кожного аудіо запису, 
що буде використано під час навчання моделі для ідентифікації. 
 Після перетворення аудіо записів на числові дані відбувається створення 
набору даних, що буде поєднувати певну кількість числових описів в один 
файл, придатний до використання. 
 Для цього необхідно лише обрати необхідні файли, обрати назву нового 
файлу, що утвориться після об`єднання та вказати на необхідний тип кінцевого 
файлу, амплітуда та фаза разом чи окремо. 
 У першому випадку файл буде досить схожий на файли для окремих 
записів, дві сторінки, відповідно для амплітудних та фазових даних. 
22 
 
 ЧДТУ 222127.001 МПЗ  
 У другому випадку файл матиме лише одну сторінку, але після переліку 
амплітудних даних на цій же сторінці будуть розміщуватися фазо-частотні дані. 
 Файл матиме наступний вигляд: 
 
Рис. 2.5 – Набір даних для навчання нейронної мережі 
 Для навчання та використання нейронних мереж було використано засоби 
та бібліотеки із набору бібліотек TensorFlow. Основою є інструмент, що 
дозволяє навчити набір моделей, що будуть мати досить схожу структуру, але 
будуть відрізнятися за параметрами шарів, їх кількістю, нормалізацією, 
методами згладжування, тощо. 
 Інструмент отримує в якості вхідного параметру набір даних з 
попереднього етапу та проводить навчання та тестування моделей, якщо 
ефективність моделі, тобто точність здогадок відносно набору тестових даних 
перевищує заданий параметр, модель зберігається у готовому до подальшої 
роботи стані. 
23 
 
 ЧДТУ 222127.001 МПЗ  
 Процес навчання моделі виглядає наступним чином: 
 
Рис. 2.6 – Параметри моделі 
 Під час процесу навчання ми можемо спостерігати як початкову точність, 
тобто кількість правильно ідентифікованих записів, так і процес постійного 
покращення результатів  кожною пройденою епохою навчання (Рис. 2.7). 
 Після завершення процесу навчання відбувається внутрішнє тестування 
за допомогою тестового набору даних, що є дещо зміненим, за допомогою 
математичних перетворень, початковим набором. В результаті вказується 
точність переведена у відсотки та назви ідентифікованих файлів, як зазначалося 
раніше, якщо точність моделі перевищує заданий поріг, модель зберігається для 
використання. 
24 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 2.7 – Процес навчання 
 Після завершення процесу навчання моделі зберігаються та готові до 
використання.  
 Під час використання обирається модель та набір даних, що отримується 
після перетворення аудіо запису особи, що ми бажаємо ідентифікувати. Після 
виконання процесу додаток видає результат “свій”, у разі якщо модель успішно 
розпізнала автора повідомлення, чи “чужий”, якщо особу не розпізнано. 
2.3 Висновки до розділу 
Під час дослідження було проведено багаторазові повторення різних 
етапів експерименту для виявлення оптимальних параметрів роботи системи, та 
було зроблено наступні висновки: 
 збільшення числа індивідуально навчених моделей з різними 
параметрами навчання дозволяє збільшити кількість задовільних результатів 
ефективності та обрати найкращі а в деяких випадках і набір найкращих для 
використання; 
 збільшення числа параметрів не завжди позитивно впливає на кінцевий 
результат  (точність) ідентифікації, оскільки були присутні випадки при яких 
додаткові параметри негативно впливали та призводили до помилок; 
25 
 
 ЧДТУ 222127.001 МПЗ  
 при використанні моделей поєднання фазо-частотних та амплітудо-
частотних характеристик показало більшу ефективність ніж окреме їх 
використання. Після проведення процесу ідентифікації 100 разів для кожного 
типу характеристик відсоток коректних результатів для комбінації 
характеристик склав 94%, для амплітуди 86%, для фази 89%. 
 
  
26 
 
 ЧДТУ 222127.001 МПЗ  
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ       ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
 В основі процесу проектування будь-якої інформаційної системи лежить 
процес моделювання предметної області, що створюється з метою, насамперед,  
мати повне, цілісне представлення моделі, що відображатиме всі деталі 
функціонування майбутньої системи. В такому випадку, модель предметної 
області – система, що імітує структуру або(та) функціонування предметної 
області, що досліджується і є адекватною цій галузі. 
3.1 Моделювання предметної області  
 Моделювання предметної області виконане заздалегідь дозволяє 
економити час проведення подальших робіт та отримати більш якісний проект 
в кінці. Цей процес запобігає виникненню великої кількості помилок у 
вирішенні різноманітних питань, що в подальшому запобігає виникненню 
додаткових затрат та необхідності перепроводити процес проектування. 
 Зазвичай моделям предметних областей ставляться наступні вимоги: 
 Формалізація, для однозначного опису структури предметної області; 
 Зрозумілість,  у вигляді застосування графічних засобів відображення 
моделі, що полегшує її розуміння для замовників і розробників; 
 Реалізація, тобто можливість фізичної реалізації моделі предметної 
області в інформаційній системі; 
 Забезпечення оцінки ефективності реалізації моделі предметної області на 
основі певних методів і обчислюваних показників. 
Для реалізації перерахованих вимог, як правило, будується система 
моделей, що відображає різні аспекти функціонування предметної області. 
3.1.1 Предметна область моделювання. Модель предметної  області. 
Словник предметної області 
Модель предметної області – це організований та структурований опис 
певної проблеми. Модель предметної області має представляти словниковий 
27 
 
 ЧДТУ 222127.001 МПЗ  
запас і ключові поняття проблемної області, а також визначати зв’язки між 
усіма об’єктами в межах області [12]. 
Сама модель предметної області може бути зображена візуальною 
схемою, прикладами коду або в деяких випадках письмовим описом  проблеми. 
Важливо, щоб модель предметної області була доступною та зрозумілою 
кожному, хто бере участь у проекті. 
У більшості випадків модель предметної області ілюструється набором 
діаграм класів, що можуть відображати: об'єкти предметної області або 
концептуальні класи, асоціації між концептуальними класами,атрибути 
концептуальних класів. 
3.1.2 Елементи моделювання предметної області  
 Для моделювання предметної області було вирішено використати мову 
UML, як широко поширену та, в результаті, зрозумілою широкому колу 
користувачів. 
 В мові UML для використання в діаграмах існують 3 види умовних, 
візуальних позначень: різноманітні графічні символи, зв`язки (стрілки та лінії), 
текст. 
 Найчастіше вживані елементи діаграм виглядають наступним чином: 
 
Рис. 3.1 – Елементи мови UML 
28 
 
 ЧДТУ 222127.001 МПЗ  
Найчастіше вживані типи зв`язків, що використовуються у діаграмах 
виглядають наступним чином: 
 
 Рис. 3.2 – Зв`язки мови UML 
 Проте, варто зауважити, що деякі діаграми мають свій перелік унікальних 
елементів, що вживаються в тому чи іншому типі діаграм. 
3.1.3 Робоча область моделювання  
 Модель предметної області для розроблюваного додатку  (Рис. 3.3) 
відображує загальну структуру системи та класи, що будуть зустрічатися та 
взаємодіяти один з одним. Користувач буде взаємодіяти з внутрішніми класами 
через інтерфейс, що в свою чергу, буде передавати ті чи інші результати, 
отримані в результаті обробки, користувачеві. Процес може проходити як 
послідовно від початкового класу, або одного  тих, що обере користувач, до 
кінця, або користувач може працювати лише над окремими задачами, або 
використовувати уже готові дані відразу у кінцевому процесі, якщо дані були 
приготовані раніше, або  в іншій системі. 
29 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 3.3 – Модель предметної області 
3.2 Формування та аналіз вимог  
Вимога – це умова чи можливість, якій повинна відповідати система. 
Основна задача етапу визначення вимог – знайти, обговорити і зафіксувати, що 
дійсно вимагається від системи у зрозумілій формі як клієнтам, так і членам 
команди розробників. Ще вимогами, зазвичай, називають опис функцій та 
обмежень, що накладаються на створювану систему чи додаток.  
Варто відмітити, що вимоги відображають те, що система повинна робити 
а не способи виконання бажаних функцій. 
Вимоги можливо відобразити по-різному, з різних точок зору та у різній 
формі. Для опису вимог та процесів, що відбуваються під час розробки 
зазвичай застосовують Уніфіковану мову моделювання (UML). Діаграми, 
зображені за допомогою подібної мови можуть відображати елементи, з яких 
складається система, або відображати процеси, що протікають під час розробки 
додатку, чи безпосередньо під час його роботи. Варто відмітити, що одні й ті ж 
типи діаграм можуть використовуватися для різних цілей. 
Розрізняють дві категорії представлення вимог: первинні та вторинні або 
вимоги замовника та вимоги розробника. Первинні вимоги відображають 
30 
 
 ЧДТУ 222127.001 МПЗ  
бажання і потреби замовника і формуються та зображуються так, щоб було 
зрозуміло навіть людині, що не розуміється у самому процесі розробки чи 
проектування. Роботу із такими вимогами називають формуванням вимог. На 
стадії проектування вимоги відображаються а допомогою різноманітних 
діаграм. Детальні вимоги зображуються у спеціальній, структурованій формі, і 
вони більш  деталізовані у порівнянні до первинних вимог. Такий етап є 
аналізом вимог. 
Також, ще одним видом зображення вимог є відображення 
функціональних та  не функціональних вимог. Функціональні вимоги описують 
поведінку системи і функції, які вона повинна виконувати. Не функціональні 
вимоги належать до характеристик системи та її взаємодії із зовнішнім 
середовищем, ефективності системи та її безпеки.  
3.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та не 
функціональні вимоги.  
 Вимоги замовника (первинні) 
 ПЗ повинно забезпечити розпізнавання особи-джерела звукового запису 
(повідомлення) у вигляді свій-чужий. 
Вимоги розробника (Вторинні) 
 Користувач повинен мати змогу власноруч вказувати на місце 
розташування звукового файлу в системі. 
 Користувач повинен мати змогу власноруч вказувати глибину розбиття 
файлу (довжину відрізків, що будуть перетворюватися в числові дані). 
 Користувач повинен мати змогу власноруч вказувати діапазон 
досліджуваних частот для звукових файлів. 
 Користувач вказує місце розташування для всіх файлів, що будуть 
отримані в результаті роботи додатку. 
 Користувач задає вказівник, що буде визначати особу-джерело як свій чи 
чужий. 
31 
 
 ЧДТУ 222127.001 МПЗ  
 Користувач обирає у якому вигляді отримати числові дані для подальшої 
обробки окремо (по категоріям) чи разом (поєднані у один масив даних). 
 Користувач отримує результат у вигляді слів свій або чужий та 
відсоткової ефективності роботи моделі для ідентифікації. 
Функціональні вимоги 
 Система повинна працювати із аудіо файлами формату WAV. 
 Система повинна мати змогу ділити початковий аудіо файл на аудіо 
файли-відрізки з наперед вказаною довжиною.  
 Система повинна мати можливість для задання частотних проміжків в 
межах яких буде виведено дані для відповідних файлів. 
 Система повинна мати можливість для збереження вказівника для 
позначення свій-чужий для відповідних аудіо файлів. 
 Вказівник свій-чужий повинен мати вигляд цілого числа в межах від     -
100 до 100 відповідно. 
 Система повинна зберігати числові дані у форматі xlsx. 
 Система повинна мати змогу зберігати числові дані у двох виглядах: 
окрема сторінка для відповідної категорії даних, або поєднання даних на одній 
сторінці файлу. 
 Для процесу ідентифікації система повинна мати словник моделей для 
подальшого аналізу та вибору моделей з найкращою ефективністю. 
Не функціональні вимоги 
Вимоги до продукту 
Кінцевий продукт повинен мати вигляд .exe файлу та мати можливість 
працювати на ОС Windows без встановлення додаткових модулів чи бібліотек. 
Організаційні вимоги 
Розробка системи проводиться на мові програмування Python з 
використанням бібліотек для використання нейронних мереж. 
Зовнішні вимоги 
32 
 
 ЧДТУ 222127.001 МПЗ  
Система не повинна розкривати будь-якої конфіденційної інформації, та 
не порушувати будь-яких законів існуючого законодавства. 
3.2.2 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів або варіантів використання (Use Case) візуально 
зображає різноманітні сценарії взаємодії між акторами (користувачами) і 
прецедентами (випадками використання), описує функціональні аспекти 
системи (бізнес логіку). Мета використання такої діаграми продемонструвати 
список акторів і показати який актор бере участь у кожному із прецедентів [12, 
26]. 
В результаті аналізу вимог було створено наступні діаграми 
використання, відповідно до основних процесів, що відбуватимуться в 
розробленій системі: 
 
 
Рис. 3.4 – Діаграма “Розбиття аудіо файлу на частини” 
 На вищезазначеній діаграмі відображається сценарій взаємодії 
користувача та системи при якому відбувається розбиття аудіо файлу на 
частини. Користувач через відповідні форми та поля введення вказує місце 
розташування початкового аудіо файлу та бажану довжину проміжків і власне 
розбиває файл на частини, попередньо обрав місце збереження файлів, що 
користувач отримає у результаті виконання процесу. 
 
33 
 
 ЧДТУ 222127.001 МПЗ  
 
 
Рис. 3.5 – Діаграма “ Перетворення аудіо файлу на числові дані” 
 На вищезазначеній діаграмі відображається сценарій взаємодії 
користувача та системи при якому відбувається перетворення аудіо файлу на 
числові дані. Користувач через відповідні форми та поля введення вказує місце 
розташування аудіо файлів, бажаний діапазон частот, вказівник свій чи чужий і 
власне перетворює файли на файл з числовими даними, попередньо обрав місце 
збереження файлу, що користувач отримає у результаті виконання процесу. 
 
Рис. 3.6 – Діаграма “Створення набору даних” 
На вищезазначеній діаграмі відображається сценарій взаємодії 
користувача та системи при якому відбувається створення набору даних. 
Користувач через відповідні форми та поля введення вказує місце 
розташування файлів з числовими даними, бажаний вид набору даних і власне 
створює набір даних придатного формату до подальшого використання у 
навчальних моделях, попередньо обрав місце збереження файлу, що користувач 
отримає у результаті виконання процесу. 
34 
 
 ЧДТУ 222127.001 МПЗ  
 
 
 
Рис. 3.7 – Діаграма “Робота з моделями” 
На вищезазначеній діаграмі відображається сценарій взаємодії 
користувача та системи при якому відбувається робота з моделями. Користувач 
через відповідні форми та поля введення вказує місце розташування файлів з 
наборами даних як для навчання так і для використання, навчає, тестує та 
зберігає найефективніші моделі за довільними параметрами тестування і після 
цього використовує готові моделі для ідентифікації бажаних аудіозаписів на 
прикладі  конкретних наборів даних.  
3.2.3 Проектування логічної структури програмного комплексу  
3.2.3.1 Діаграми класів 
Діаграма класів визначає типи класів системи і різного роду статичні 
зв'язки, які існують між ними. На діаграмах класів зображуються також 
атрибути класів, операції класів та обмеження, які накладаються на зв'язок між 
класами.  Клас є головним елементом діаграми навколо якого організуються 
інші елементи, що або належать класам, або приєднані до них [12, 25].  
Атрибути описують властивості об'єктів класу. Більшість об'єктів в класі 
отримують свою індивідуальність через відмінності в їх атрибутах і 
взаємозв'язки з іншими об'єктами. Однак існує можливість створити об'єкти з 
ідентичними значеннями атрибутів і взаємозв'язків. Тобто індивідуальність 
35 
 
 ЧДТУ 222127.001 МПЗ  
об'єктів визначається самим фактом їх існування, а не відмінностями в їх 
властивостях. Ім'я атрибута повинно бути унікально в межах класу. 
В результаті аналізу поставленої задачі було створено декілька діаграм 
класів, відповідно створених пакетів: класи Processing, TensorDataProcessing 
пакету FileProcession, клас Main пакету Interface, класи ModelsStudy, 
ModelsTesting пакету Models. 
 
Рис. 3.8 – Пакет “File procession” 
 Клас Processing складається з методу splitAudioFile(), що розділяє аудіо 
файл на проміжки, processAudio(), що перетворює файл-відрізок на числові 
данні, exportData(), що виводить числові дані в файл формату Excel, 
processFiles(), що реалізовує цикл обробки для декількох файлів. 
 Клас TensorDataProcessing складається з методу createDataSet(), що 
створює набір данних, createCombinedDataSet (), що створює набір данних з їх 
комбінуванням, getSingleSheetDataSet() та getMultipleSheetDataSet(), що 
отримують набір даних та перетворюють його у вигляд, придатній для 
подальшої обробки. 
 Вищезазначені класи входять до пакету “File procession” та 
використовуються в пакеті “Interface”, де присутні методи, що реалізують 
взаємодію користувача з внутрішніми методами інших класів. 
36 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 3.9 – Пакет “ Interface” 
Клас Main складається з методу __init__(), що відповідно ініціалізує 
змінні та методи класу, innitalFileProcessionTab(), що відповідає за вкладку з 
елементами інтерфейсу для початкової обробки файлу, 
numericalDataProcessionTab (), що відповідає за вкладку з елементами 
інтерфейсу для перетворення файлів в числові дані, dataSetProcessionTab (), що 
відповідає за вкладку з елементами інтерфейсу для створення наборів даних, 
neuralModelsTab (), що відповідає за вкладку з елементами інтерфейсу для 
навчання, тестування та подальшої роботи з моделями нейронних 
мереж,методи showWindowInfo() відповідають за вікна з інформацією для 
користувача, enterChunkLength(), відповідає за поле введення довжини відрізку 
аудіо файлу, enterRange(), відповідає за поле введення частотного діапазону,  
enterPointer(), відповідає за поле введення вказівнику свій-чужий,  
getInitialFileFolder(), відповідає за отримання шляху до папки з початковим 
37 
 
 ЧДТУ 222127.001 МПЗ  
файлом,   getFilesFolderPath(), відповідає за отримання шляху до папки з 
перетвореними файлами,    getExcelFilesFolderPath(), відповідає за отримання 
шляху до папки з файлом типу Excel,    getDataFilePath(), відповідає за 
отримання шляху до папки з наборами даних,    processFile(), відповідає за 
взаємодію елементів інтерфейсу та методів обробки початкового аудіофайлу,    
processAudioFiles(), відповідає за взаємодію елементів інтерфейсу та методів 
обробки аудіо файлів, createDataSet(), відповідає за взаємодію елементів 
інтерфейсу та методів створення наборів даних, createCombinedDataSet(), 
відповідає за взаємодію елементів інтерфейсу та методів створення наборів 
даних з комбінованими даними, studyModels(), відповідає за взаємодію 
елементів інтерфейсу та методів навчання моделей,  useModel(),  відповідає за 
взаємодію елементів інтерфейсу та методів використання моделей для 
ідентифікації, showExceptionBox(), відповідає за елементи інтерфейсу, що 
відображають неочікувані помилки, що можуть виникнути під час роботи, 
uncaughtHook() відповідає за обробку таких помилок. 
 
Рис. 3.10 – Пакет “Models ” 
Клас ModelsStudy складається з методу countGuesses(), що підраховує 
кількість правильних здогадок моделі, saveModel (), що зберігає навчану 
38 
 
 ЧДТУ 222127.001 МПЗ  
модель, loadModel(),що завантажує навчану модель, studyFirstTypeModels(), що 
відповідає за навчання набору моделей першого типу, 
studySecondTypeModels(), що відповідає за навчання набору моделей другого 
типу. 
Клас ModelsUsage складається з методу loadModel(),що завантажує 
навчану модель, saveModel(), що зберігає модель у разі змін та useModel(), що 
використовує завантажені моделі для ідентифікації. 
3.2.3.2 Діаграми пакетів 
Діаграма пакетів необхідна, в першу чергу, для організації елементів в 
групи по будь-якою ознакою з метою спрощення структури і організації роботи 
з моделлю системи. 
Діаграма пакетів використовуються у великих за розмірами системах для 
представлення картини залежностей між основними елементами системи. Такі 
діаграми добре відповідають загальноприйнятим програмним структурам. 
Пакет (package) - це інструмент групування, який дозволяє взяти будь-яку 
конструкцію UML і об'єднати її елементи в одиниці високого рівня. В 
основному пакети служать для об'єднання класів в групи за пов`язаним 
функціоналом чи схожою темою. У моделі UML кожен клас може входити 
лише до одного пакету. Пакети можуть також входити до складу інших пакетів, 
тому ієрархічна структурі зберігається. Пакети верхнього рівня розпадаються 
на підпакети зі своїми власними підпакетами, і так далі, до самого низу ієрархії. 
Пакет може містити і підпакети, і класи  [12, 36]. 
В розроблюваній системі можна виділити 3 основні пакети: Interface, що 
відповідає за побудову інтерфейсу користувача та поєднує методи інших класів 
для їх взаємодії як один з одним так і з власне користувачем, File Procession, що 
має класи, що відповідають за обробку різноманітних даних: розбиття аудіо 
файлів, перетворення даних із звукових в числові та формування наборів даних 
як для подальшої обробки так і для навчання моделей нейронних мереж, та 
пакет Models, де знаходяться власне класи для роботи з нейронними мережами, 
їх навчанням та використанням. 
39 
 
 ЧДТУ 222127.001 МПЗ  
 
 
Рис. 3.11 – Діаграма пакетів  
3.3.Архітектурне проектування 
3.3.1 Діаграма компонентів 
Діаграма компонентів дозволяє створити фізичне відображення поточної 
моделі. Діаграма компонентів показує організацію й взаємозв'язок програмних 
компонентів, представлених у вихідному коді, двійкових або виконуваних 
файлах  [12, 32]. 
 Компонент (англ. Component) - це фізична частина системи. Компоненти, 
що представляють собою файли з вихідним кодом класів, бібліотеки, 
виконувані модулі і т.п., які повинні володіти узгодженим набором інтерфейсів 
та правил. 
 Компоненти можуть мати такі стандартні стереотипи: 
 «file» - будь-який файл, крім таблиці; 
 «executable» - програма (виконуваний файл); 
 «library» - статична або динамічна бібліотека; 
40 
 
 ЧДТУ 222127.001 МПЗ  
 «source» - файл з вихідним текстом програми; 
 «document» - інші файли (наприклад, файл довідки); 
 «table» - таблиця бази даних. 
По суті, діаграми компонентів являють собою не що інше, як діаграми 
класів,що сфокусовані на системних компонентах. Також варто зазначити,що 
діаграма компонентів відображає лише структурні характеристики. 
Діаграма компонентів для розроблюваної системи виглядає наступним 
чином: 
 
Рис. 3.12 – Діаграма компонентів 
3.3.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
 Діаграма розгортання UML — це діаграма, на якій відображаються 
конфігурації вузлів під час роботи додатку. Діаграми розгортання — це 
різновид структурної діаграми, яка використовується для моделювання 
фізичних аспектів об’єктно-орієнтованої системи. Вони часто 
використовуються для моделювання статичного вигляду розгортання системи 
(топології апаратного забезпечення). 
41 
 
 ЧДТУ 222127.001 МПЗ  
 Діаграми розгортання важливі для візуалізації, специфікації та 
документування вбудованих, клієнт/серверних і розподілених систем, а також 
для керування виконуваними системами за допомогою прямого та зворотного 
проектування. 
Діаграма розгортання — це лише особливий вид діаграми класів, яка 
фокусується на вузлах системи. Графічно діаграма розгортання — це набір 
вершин і дуг.  
Діаграма розгортання для розроблюваної системи виглядає наступним 
чином: 
 
Рис. 3.13 – Діаграма розгортання 
Користувач взаємодіє із внутрішніми методами програми завдяки 
користувацькому інтерфейсу. Методи в свою чергу взаємодіють між собою для 
виконання поставлених задач, використовуючи в процесі обрані аудіо файли та 
файли з даними. 
3.3.3 Моделювання поведінки системи  
3.3.3.1 Діаграма діяльності 
Діаграма діяльності - в UML, візуальне представлення графу діяльностей. 
Граф діяльностей є різновидом графу станів, головною метою якого є 
42 
 
 ЧДТУ 222127.001 МПЗ  
візуалізація алгоритму виконання операцій класів [12, 31]. Кожен стан в такому 
випадку може позначати певну операцію якогось класу системи, що дає змогу 
використовувати таку діаграму для опису реакцій на внутрішні зміни в системі. 
В результаті аналізу поставлених задач було створено декілька діаграм 
діяльності (Рис. 3.14, Рис. 3.15). 
На діаграмах зображена очікувана послідовність дій користувача при 
роботі над створенням набору даних: 
 після запуску програми, користувач, в залежності від наявних даних може 
обрати послідовність своїх дій; 
 при відсутності готових даних користувач може створити власний набір 
даних за допомогою перетворення аудіо файлів та подальшої обробки числових 
даних; 
 при відсутності готових аудіо файлів користувач може розбити 
початковий аудіо файл на проміжки із заданою довжиною; 
 при наявності аудіо файлів користувач задає місце їх розташування, 
бажаний діапазон частот, задає вказівник свій-чужий та місце для збереження 
результату; 
 потім користувач обирає файли з числовими даними та створює словник 
ознак необхідного йому типу. 
 
 
43 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 3.14 – Діаграма “Створення набору даних” частина 1 
 
Рис. 3.15 – Діаграма “Створення набору даних” частина 2 
44 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 3.16 – Діаграма “Робота з моделями”  
На вищезазначеній діаграмі зображена очікувана послідовність дій 
користувача при роботі з моделями нейронних мереж в системі: 
 після запуску програми, користувач, в залежності від наявних даних може 
обрати послідовність своїх дій; 
45 
 
 ЧДТУ 222127.001 МПЗ  
 при відсутності готових до практичного використання моделей 
користувач завантажує набори даних та за їх допомогою навчає набір моделей 
для подальшого використання; 
 при наявності моделей користувач задає місце їх розташування, шлях до 
набору даних та використовує готові моделі для ідентифікації аудіо записів, 
перетворених у набори даних. 
3.3.3.2 Діаграма послідовності 
Діаграма послідовності — відображає послідовність обміну 
повідомленнями між ролями, що імплементують поведінку системи. Зокрема, 
такі діаграми відображають задіяні об'єкти та послідовність відправлених 
повідомлень. Діаграми послідовностей можна використовувати для уточнення 
діаграм прецедентів, більш детального опису логіки сценаріїв використання 
[12, 27].  
В результаті аналізу поставленої задачі було створено декілька діаграм 
послідовності. 
 
Рис. 3.17 – Діаграма послідовності “ Робота з моделями”  
46 
 
 ЧДТУ 222127.001 МПЗ  
На рисунку (Рис. 3.17), описаний повний процес роботи з моделями, від 
навчання початкового набору моделей, до використання моделей для власне 
ідентифікації. 
На наступному рисунку (Рис. 3.18), описаний повний процес створення 
набору даних, готових до подальшого використання під час навчання моделей. 
Варто відмітити, що описано очікувану послідовність даних користувачем, що 
розпочинає роботу, маючи у наявності лише аудіо файл. У разі наявності 
необхідних даних, можна пропустити відповідні етапи. 
 
Рис. 3.18 – Діаграма послідовності “Створення набору даних”  
47 
 
 ЧДТУ 222127.001 МПЗ  
3.3.3.3 Діаграма комунікації 
 Діаграма комунікації (кооперації) моделює об’єкти та зв’язки, що 
відіграють значну роль всередині міжсистемних взаємодій. Варто зазначити, що 
об’єкти відображені на діаграмі мають сенс лише в контексті який представляє 
взаємодія, відображена на діаграмі. Роль класифікатора описує об’єкт системи, 
роль асоціації описує зв’яок у взаємодії [12, 29]. 
 Діаграма комунікації відображає відповідні ролі у ваємодії у вигляді 
геометричних фігур, де повідомлення відображаються як стрілки, що поєднані з 
лініями відносин між  класифікаторами. Послідовність повідомлень та 
посилань поначається номерами, що знаходяться біля повідомлень. 
Для системи, відповідно до процесів, було розроблено декілька діаграм 
комунікацій:  
 
Рис. 3.19 – Діаграма кооперації “Розбиття початкового аудіо файлу”  
 
Рис. 3.20 – Діаграма кооперації “Створення первинного опису”  
48 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 3.21 – Діаграма кооперації “Створення набору даних”  
 
Рис. 3.22 – Діаграма кооперації “Навчання моделей”   
 
Рис. 3.23 – Діаграма кооперації “Використання моделей”   
3.3.3.4 Діаграма скінченного автомату  
Діаграма скінченного автомату, або діаграма станів — це графічне 
представлення кінцевого автомату. Діаграми станів показують модель 
49 
 
 ЧДТУ 222127.001 МПЗ  
поведінки, що складається зі станів, переходів станів і дій. Діаграми стану UML 
засновані на концепції діаграм стану Девіда Гарела. Діаграми станів 
зображують дозволені стани та переходи, а також події, які впливають на ці 
переходи. 
Діаграми стану зазвичай використовуються у сфері вбудованих систем. 
Діаграми стану допомагають візуалізувати весь життєвий цикл об’єктів і, таким 
чином, допомагають краще зрозуміти системи, засновані на ріноманітних 
станах. 
 
Рис. 3.24 – Діаграма скінченного автомату для розроблюваної системи  
 На вищезазначеній діаграмі зображено кінцевий автомат для системи з 
ідентифікації звукових повідомлень. Робота починається із запуску додатку, 
після чого програма знаходиться в стані очікування вибору операції 
користувачем. Після того як операцію обрано, користувач вводить необхідні 
для роботи дані і якщо вони коректні відбувається обробка обраної операції, у 
випадку коли дані необхідні для використання у інших процесах, вони 
зберігаються, у іншому випадку, дані виводяться візуально. Після завершення 
роботи процесу програма повертається до стану очікування, якщо користувач 
бажає продовжити роботу він знову обирає операцію, якщо ні, програму можна 
завершити. 
50 
 
 ЧДТУ 222127.001 МПЗ  
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
4.1 Розробка програмного комплексу 
4.1.1 Обґрунтування вибору засобів реалізації 
 Для розробки ПЗ було вирішено обрати мову програмування Python, що є 
об’єктно-орієнтованою, зрозумілою в користуванні, швидкою та потужною при 
роботі та обчисленнях. Досить схожими до Python є мови Perl, Ruby, Scheme 
або Java [13]. 
 Також, на вибір повпливала велика кількість особливостей мови, серед 
яких: 
 Використання простого та зручного елегантний синтаксису, що полегшує 
розуміння програм; 
 простота та зрозумілість мови у загальному вигляді, що дозволяє швидко 
створювати програми для виконання різноманітних задач; 
 стандартна бібліотека, що підтримує виконання великої кількості базових 
завдань програмування, підключення до веб-серверів, регулярні вирази, робота 
з файлами; 
 можливість легко розширювати функціонал за допомогою підключення 
додаткових модулів; 
 можливість вбудувати в програму для надання програмованого 
інтерфейсу; 
 багатоплатформність, що дозволяє працювати на Mac OS X, Windows, 
Linux і Unix, також існують неофіційні збірки для Android та iOS. 
Варто зазначити, що завантаження чи використання мови Python, а також 
його включення у програми є безкоштовним, та не потребує додаткових витрат 
на платну ліцензію. Python також можна вільно модифікувати та повторно 
поширювати, оскільки, хоча мова захищена авторським правом, вона доступна 
за ліцензією з відкритим кодом. 
Що стосується особливостей саме мови програмування, то тут можна 
виділити наступні функції: 
51 
 
 ЧДТУ 222127.001 МПЗ  
 Доступні різні основні типи даних: числа (з плаваючою комою, складні та 
довгі цілі необмеженої довжини), рядки (як ASCII, так і Unicode), списки та 
словники; 
 підтримка ООП з класами, матодами, тощо та множинним 
успадкуванням; 
 групування написаного коду в модулі, пакети, біблотеки; 
 підтримка створення та перехоплення програмних винятків для 
забезпечує обробки помилок; 
 сувора та динамічна типізація даних. Відстежування несумісних типів за 
допомогою винятків; 
 розширені функції програмування, такі як наприклад генератори та 
різноманітні обробники списків; 
 автоматичне керування пам’яттю дозволяє розробнику не витрачати час 
на виділення чи звільнення пам’яті у коді. 
Середовищем розробки було обрано PyCharm IDE (integrated development 
environment), тобто, інтегроване середовище розробки.  
IDE це взаємопов`язаний набір елементів та інструментів для розробки 
програмного забезпечення у вигляді однієї програми. Зазвичай, складається з 
редактора коду, інструментів для автоматизації процесу збору програм в єдине 
ціле та пошуку помилок і їх виправлення. Більшість сучасних середовищ 
розробки мають можливість автодоповнення коду, тобто допомагають 
програмісту в написані програм  [14].  
PyCharm, в свою чергу, IDE розроблене для використання з мовою 
Python, допомагає як професійним розробникам так і початківцям завдяки 
безкоштовній версії PyCharm Community Edition. Середовище підтримує весь 
робочий процес, включаючи взаємодію з веб-фреймворками, інтерфейсними 
технологіями, базами даних і різноманітними інструментами для наукової 
обробки даних[15]. 
4.1.2 Опис структурної (функціональної) схеми 
52 
 
 ЧДТУ 222127.001 МПЗ  
 Створення та подальше відображення структурної та функціональної 
схем необхідне для розуміння розробником власне структури ПЗ, його 
програмних компонентів та та зв'язків між ними. 
Структурна схема розроблюваного програмного забезпечення це схема, 
що зображує склад і взаємодію з управління елементів розроблюваного 
програмного забезпечення [16]. Вони необхідні насамперед для розуміння того 
навіщо взагалі той чи інший елемент програми, як він працює та як елементи 
взаємодіють між собою. 
Структурна схема для розроблюваної системи виглядає наступним чином: 
 
Рис. 4.1 – Структурна схема 
 Відповідно вищезазначеної схеми користувач починає роботу з системою 
та за допомогою інтерфейсу взаємодіє з підсистемами для виконання різних 
задач, підсистеми працюють незалежно одна від одної, але дані отримані в 
результаті роботи однієї підсистеми використовуються у роботі іншої.  
Функціональна схема являє собою схему взаємодії компонентів програми 
з описом інформаційних потоків, складу даних в потоках і вказівкою 
використовуваних файлів і пристроїв [17]. 
На відміну від вищеописаних структурних схем, функціональні схеми 
несуть в собі більше інформації. Окрім загального опису підсистем та їх 
взаємозв`язків на функціональних схемах також відображуються додаткові 
53 
 
 ЧДТУ 222127.001 МПЗ  
елементи, наприклад, збереженні дані, що позначають таблиці чи інші 
структури даних, пристрій, що запам`ятовує дані які зберігаються в 
оперативній пам`яті чи магнітних дисках, документ, що позначає дані які 
виводяться на друк, ручне введення, що позначає ручне введення даних з 
клавіатури та дисплей, що позначає данні які виводяться на дисплей 
комп`ютера. 
Функціональна схема для розроблюваної системи виглядає наступним 
чином: 
 
Рис. 4.2 – Функціональна схема 
 Відповідно вищезазначеної схеми користувач при роботі з інтерфейсом 
мануально обирає необхідну йому функцію та вводить необхідні дані, після 
чого, відповідно обраної функції, будуть виведені повідомлення щодо прогресу 
роботи, файли, отримані в результаті роботи, буде збережено в пам`яті 
комп`ютера або в вигляді документу. 
54 
 
 ЧДТУ 222127.001 МПЗ  
4.1.3 Опис логічної схеми системи  
Логічна схема системи, на відміну від функціональної та структурної 
схем, описує послідовність дій користувача, що в результаті, призведуть до 
того чи іншого ефекту або результату. 
Робота починається із запуску додатку та вибору однієї із підсистем, 
відповідно до наявності даних, для подальшої роботи: 
 Якщо користувач не має в наявності нічого, окрім аудіо файлу, робота 
починається з розбиття аудіо файлу на частини. Користувач вказує шлях до 
файлу для розбиття, вводить довжину відрізків та вказує місце збереження 
результатів; 
 якщо користувач має розбитий на частини аудіо файл, наступним кроком 
користувача буде перетворення звукових файлів на числові дані. Користувач 
вказує шлях до звукових файлів, вказує діапазон виведення даних, додає 
вказівник свій/чужий та вказує місце збереження результату; 
 якщо користувач має декілька файлів з числовими даними користувач 
може створити набір даних для подальшого використання під час навчання 
моделей нейронних мереж. Користувач вказує шлях до файлів для 
перетворення, вказує назву нового файлу, місце збереження результату та тип 
набору даних; 
 якщо користувач має набір даних, наступним кроком буде навчання 
моделі. Користувач вказує шлях до набору даних та вказує місце збереження 
результату; 
 при наявності навчених моделей користувач вказує шлях до папки з 
моделлю та обирає файл з числовими даними, отриманий після перетворення 
звукових файлів на числовий та проводить ідентифікацію і отримує результат. 
Будь-який з вищеописаних етапів може бути повторений довільну 
кількість разів відповідно до необхідності користувача та наявності тих чи 
інших, готових до роботи файлів. Підготовлені на одному з етапів файли можна 
використати пізніше, або в додатку на іншій системі. 
55 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 4.3 – Логічна схема 
4.1.4 Розробка бази даних  
 У зв`язку із характером розроблюваної системи було вирішено не 
використовувати бази даних. Робота в системі ведеться із звуковими файлами, 
56 
 
 ЧДТУ 222127.001 МПЗ  
що записуються у різних форматам та потім перетворюються на необхідний для 
роботи та зберігаються у пам`яті комп`ютера.  
Числові дані як після початкового перетворення так і у вигляді наборів 
даних зберігаються у вигляді файлів формату Excel, що дозволяє швидко 
читати і записувати дані. Великі обсяги даних, що утворилися б при постійному 
використанні системи з базами даних призвели б до сповільнення роботи та 
необхідності очистки даних, що перестали бути необхідними, що також 
займало певні проміжки часу. Також важливим є те, що використання файлів 
для збереження даних дозволяє без жодних проблем передавати їх різними 
системами та носіями.  
Навчані моделі, в свою чергу, зберігаються у вигляді папок з усіма 
необхідними для роботи елементами, та аналогічно із файлами з числовими 
даними, у разі необхідності, можуть бути використані в іншій системі чи з 
носія. 
4.1.5 Розробка інтерфейсу користувача 
Інтерфейс системи розроблювався за допомогою бібліотеки PyQt5 для 
мови Python.  Qt — це набір крос-платформних бібліотек написаних на мові 
C++, що реалізують API високого рівня для доступу до багатьох аспектів 
сучасних настільних комп`ютерних і мобільних систем.  
PyQt5, в свою чергу,  це комплексний набір інструментів Qt v5 для мови  
Python. Він реалізований у вигляді більш ніж 35 модулів розширення та 
дозволяє використовувати Python як альтернативну мову розробки додатків 
C++ на всіх підтримуваних платформах, включаючи iOS і Android [18].  
 Основною метою при створені інтерфейсу було зробити його простим та 
зрозумілим для будь-якого користувача. 
 Для розробки інтерфейсу спочатку було створено макет (Рис. 4.4), де 
схематично відображується загальна структуру інтерфейсу системи та 
структуру окремих елементів, без урахування графічних деталей та 
особливостей, потім по макетам було розроблено власне елементи інтерфейсу 
та  їх дизайн (Рис. 4.5). 
57 
 
 ЧДТУ 222127.001 МПЗ  
 
 
Рис. 4.4 – Макет вікон інтерфейсу 
 На макеті схематично зображено вигляд головного вікна додатку, вікна з 
інформацією та приклад одного з вікон для реалізації підсистем. На рисунку 
58 
 
 ЧДТУ 222127.001 МПЗ  
(Рис. 4.5) зображено приклади реалізації інтерфейсу, що було розроблено 
відповідно кожній підсистемі, що потребує взаємодії з користувачем. 
 
Рис. 4.5 – Реалізація інтерфейсу користувача 
4.1.6 Опис розробки програмних компонентів  
Програмна компонента – елемент програмного забезпечення, що 
виконується в системі та в межах одного процесу і надає певний список 
функцій, що використовуються через зовнішній інтерфейс іншими 
програмними компонентами, що виконуються на цій же системі та на 
віддалених комп'ютерах [19, 138]. 
Основні компоненти з яких складається програма розділені на пакети та 
класи [Розділ 3.2.3.1, Розділ 3.2.3.2]. 
Пакет File procession, що складається з класів Processing та 
TensorDataProcessing, пакет Models, що складається з класів ModelsStudy, 
ModelsUsage, та пакет Interface де розміщений клас Main.  
59 
 
 ЧДТУ 222127.001 МПЗ  
Клас Processing відповідає за різноманітну обробку звукових файлів від 
розбиття на частини до перетворення на числові дані, запису до файлу та 
збереження [Додаток Б, Розділ 1]. Має наступні методи: splitAudioFile(), що 
розбиває файл на частини, processAudio(), що перетворює файл на набір 
числових даних, exportData(), що записує числові дані до файлу Excel формату, 
processFiles(), що займається виконанням вищезазначених методів для множини 
файлів. 
Клас TensorDataProcessing відповідає за методи перетворення даних на 
придатні до їх використання під час роботи  моделями та їх читування [Додаток 
Б, Розділ 2]. Має наступні методи: createDataSet(), що займається 
перетворенням файлів у набір даних, createCombinedDataSet() виконує функцію 
аналогічну попередньому методу, але поєднує дані амплітуди та фази на 
одному листі, getMultipleSheetDataSet() читає дані з файлів з багатьма листами 
та перетворює їх у масиви даних, придатні для використання у навчанні 
моделей, getSingleSheetDataSet() читає дані з файлів з одним листом та 
перетворює їх у масиви даних, придатні для використання у навчанні моделей. 
Клас ModelsStudy відповідає за методи навчання моделей різного типу, 
підрахунку результатів, збереження та завантаження моделей [Додаток Б, 
Розділ 3]. Має наступні методи: studyFirstTypeModels() та 
studySecondTypeModels() займаються навчанням моделей, але відрізняються 
структурою самих моделей, countGuesses() займається підрахунком коректних 
відповідей, saveModel() та loadModel() зберігають та завантажують моделі. 
Клас ModelsUsage відповідає за методи використання моделей та методи 
збереження і завантаження моделей [Додаток Б, Розділ 4]. Має наступні 
методи: saveModel() та loadModel(), що зберігають та завантажують моделі, 
useModel(), що використовує завантажені моделі для процесу ідентифікації. 
Клас Main відповідає за об’єднання підсистем в єдину систему, шляхом 
використання різноманітних методів використання елементів інтерфейсу 
[Додаток Б, Розділ 5]. Має наступні методи: initialFileProcessionTab(), 
numericalDataProcessionTab(), dataSetProcessionTab(), neuralModelsTab(), що 
60 
 
 ЧДТУ 222127.001 МПЗ  
відповідають за відповідні підсистеми та розміщенням різних елементів, 
showFirstWindowInfo(), showSecondWindowInfo(), showThirdWindowInfo(), 
showFourthWindowInfo(), що відповідають за вікна із інформацією, 
getInitialFileFolder(), getFilesFolderPath(), getExcelFilesFolderPath(), 
getDataFilePath(), getModelFilePath(), getIdentificationDataFilePath(), що 
відповідають за вікна вибору файлів та папок, enterChunkLength(),  enterRange(), 
enterPointer(), що відповідають за введення додаткових, необхідних для роботи, 
даних, processFile(), що відповідає за розбиття файлу на частини, 
processAudioFiles(), що відповідає за перетворення файлів на числові дані, 
createDataSet(), що відповідає за створення набору даних, 
createCombinedDataSet(), що відповідає за створення об`єднанного набору 
даних,  studyModels(), що відповідає за навчання моделей,  useModel(), що 
відповідає за використання моделей, show_exception_box(),що викликає вікно з 
повідомленням у разі виникнення помилки, exception_hook(), що відстежує 
неочікуванні помилки. 
4.2 Тестування системи  
 Тестування – це вид діяльності, що проводиться для оцінки якості 
продукції різного типу та для її покращення в результаті виявлення дефектів і 
проблем чи різноманітних, навіть незначних, помилок. 
Взагалі процес тестування програмного забезпечення складається з 
динамічної перевірки поведінки програми на скінченному наборі тестових 
випадків, тобто ситуацій використання тих чи інших функцій, належним чином 
вибраних із зазвичай нескінченної області виконання, порівняно з їх 
очікуваною поведінкою [20]. 
Варто відмітити, що тестування програмного забезпечення також 
пов’язане з процесом конструювання ПЗ. Модульне та інтеграційне тестування, 
в свою чергу, тісно пов’язані зі створенням програмного забезпечення, якщо 
взагалі не є його частиною. 
4.2.1 Модульне тестування 
61 
 
 ЧДТУ 222127.001 МПЗ  
 Модульний тест (Unit Test) – це спосіб тестування блоку – найменшого 
фрагмента коду, який можна логічно виділити в системі. У більшості мов 
програмування це функція, підпрограма, метод або властивість [21]. 
 Призначення одного модульного тесту – це тестування певної, 
визначеної, поведінки тієї чи іншої функції, всередині коду. Успіх чи невдача 
такого тесту є валідацією обраного блоку коду. Коректно написані тести 
створюють середовище, чи сценарій роботи, що є незалежним від зовнішніх 
умов і дозволяє виконати певну функцію і перевірити на певний, очікуваний,  
результат[22]. 
 Важливим при побудові Unit тестів є те, що вони повинні уникати появи 
залежностей з другими тестами, та бути короткими і зрозумілими. Починаючи 
від простих функцій і постійно ускладнюючи їх, модульні тести дозволяють 
перевіряти досить складні, комплексні системи.  
Для перевірки функціональності елементів програми було розроблено 
певну кількість модульних тестів. Приклад розроблених тестів виглядає 
наступним чином: 
 
Рис. 4.6 – Приклади модульних тестів 
4.2.2 Інтеграційне тестування  
 Інтеграційне тестування – це етап тестування програмного забезпечення, 
на якому окремі, в деяких випадках, самостійні модулі розробленого 
62 
 
 ЧДТУ 222127.001 МПЗ  
програмного забезпечення об’єднуються та тестуються як група елементів. Таке 
тестування проводиться для оцінки відповідності системи або компонента 
визначеним на ранніх етапах функціональним вимогам. 
 Мета інтеграційного тестування полягає у перевірці функціоналу, 
продуктивності та вимог надійності, що були встановлені для системи [23]. 
 Зазвичай інтеграційне тестування застосовується для перевірки веб-
систем, їх зв`язків та баз даних, оскільки розроблювана система є десктопним 
за стосунком при інтеграційному тестуванні було перевірено взаємодію 
декількох модулів системи. 
Приклад розроблених тестів виглядає наступним чином: 
 
Рис. 4.7 – Приклад інтеграційного тесту 
4.2.3 Системне тестування  
 Системне тестування – тестовий рівень, який зосереджується на перевірці 
того, що система в цілому відповідає визначеним вимогам [24]. 
63 
 
 ЧДТУ 222127.001 МПЗ  
 Як вхідні дані, тобто елементи, що потребують тестування, системне 
тестування приймає всі інтегровані компоненти, що пройшли попередні етапи 
тестування та представляють собою єдиний, готовий до роботи програмний 
комплекс. У цьому випадку ми проходимо (переглядаємо) усі необхідні модулі 
програми та перевіряємо, чи коректно працюють кінцеві функції і тестуємо 
продукт як систему в цілому [25]. 
 Тести було проведено для кожної з підсистем, що виконували конкретні 
функції та для системи в цілому. 
Тести, проведені на даному етапі виглядають наступним чином: 
Тестування підсистеми розбиття аудіо запису       Таблиця №4.1 
Тест Тест 
№ Опис тесту 
пройдено провалено 
Виведення вікна з інформацією при 
1 +  
натисканні відповідної кнопки 
При натисканні відповідної кнопки 
2 відкривається вікно для вибору аудіо +  
запису 
При виборі аудіо запису чи вказівні інших 
3 даних вони відображаються у відповідних +  
полях 
При натисканні відповідної кнопки та 
4 заповненні відповідного поля користувач +  
може вказати бажану довжину відрізку 
При натисканні відповідної кнопки із 
заповненими полями аудіо файлу та 
5 +  
довжини відрізку користувач може обрати 
місце збереження відрізків та розбити файл  
При натисканні відповідної кнопки, але без 
6 заповнення відповідних полів буде +  
виведено повідомлення про помилку 
При спробі ввести некоректну довжину 
7 відрізку буде виведено повідомлення про +  
помилку 
При спробі обрати некоректний файл для 
8 розбиття буде виведено повідомлення про +  
помилку 
Можливість вільного переходу до інших 
9 +  
функцій системи 
64 
 
 ЧДТУ 222127.001 МПЗ  
Тестування підсистеми отримання числових даних    Таблиця №4.2 
Тест Тест 
№ Опис тесту 
пройдено провалено 
Виведення вікна з інформацією при 
1 +  
натисканні відповідної кнопки 
При натисканні відповідної кнопки 
2 відкривається вікно для вибору шляху до +  
файлів для перетворення 
При виборі шляху чи введенні інших даних 
3 вони відображуються у відповідних полях +  
інтерфейсу 
При натисканні відповідної кнопки та 
заповненні відповідних полів користувач 
4 +  
може вказати бажаний частотний діапазон, 
у якому буде виведено перетворені дані 
При натисканні відповідної кнопки та 
заповненому відповідному полі користувач 
5 +  
може додати до числових даних вказівник 
свій чи чужий, у числовому вигляді  
При натисканні відповідної кнопки із 
заповненими полями шляху до файлів, 
6 діапазону даних та вказівником користувач +  
може обрати місце збереження файлу з 
даними та перетворити звукові файли  
При натисканні відповідної кнопки, але без 
7 заповнення відповідних полів буде +  
виведено повідомлення про помилку 
При спробі ввести некоректні дані у 
8 відповідні поля буде виведено +  
повідомлення про помилку 
При спробі обрати некоректний шлях до 
9 файлів буде виведено повідомлення про +  
помилку 
Можливість вільного переходу до інших 
10 +  
функцій системи 
Тестування підсистеми формування первинного опису   Таблиця №4.3 
Тест Тест 
№ Опис тесту 
пройдено провалено 
Виведення вікна з інформацією при 
1 +  
натисканні відповідної кнопки 
При натисканні відповідної кнопки 
2 відкривається вікно для вибору шляху до +  
файлів для об’єднання 
65 
 
 ЧДТУ 222127.001 МПЗ  
Продовження Таблиця №4.3 
При виборі шляху чи введенні інших даних 
3 вони відображуються у відповідних полях +  
інтерфейсу 
При заповнені відповідного поля 
4 користувач може вказати назву для нового +  
файлу 
При натисканні однієї з відповідних кнопок 
із заповненими полями шляху до файлів, та 
вказаною назвою нового файлу користувач 
5 +  
може обрати місце збереження файлу 
набору з даними та перетворити звукові 
файли  
При натисканні відповідної кнопки, але без 
6 заповнення відповідних полів буде +  
виведено повідомлення про помилку 
При спробі ввести некоректні дані у 
7 відповідні поля буде виведено +  
повідомлення про помилку 
При спробі обрати некоректний шлях до 
8 файлів буде виведено повідомлення про +  
помилку 
Можливість вільного переходу до інших 
9 +  
функцій системи 
Тестування підсистеми роботи з моделями    Таблиця №4.4 
Тест Тест 
№ Опис тесту 
пройдено провалено 
Виведення вікна з інформацією при 
1 +  
натисканні відповідної кнопки 
При натисканні відповідної кнопки 
2 відкривається вікно для вибору шляху до +  
файлів  даними для навчання моделей  
При натисканні відповідної кнопки із 
заповненим полем шляху до файлу 
3 користувач може обрати місце збереження +  
файлів  даними моделей та запустити 
процес навчання 
При виборі шляху чи введенні інших даних 
4 вони відображуються у відповідних полях +  
інтерфейсу 
При натисканні відповідної кнопки 
5 відкривається вікно для вибору шляху до +  
папки з навчаною моделлю  
66 
 
 ЧДТУ 222127.001 МПЗ  
Продовження Таблиця №4.4 
При натисканні відповідної кнопки 
6 відкривається вікно для вибору шляху до +  
файлів для розпізнавання 
При натисканні відповідної кнопки із 
заповненими полями шляху до необхідних 
7 файлів, діапазону даних та вказівником +  
користувач може провести ідентифікацію 
та отримати результат у відповідному полі 
При натисканні відповідних кнопок для 
отримання результатів, але без заповнення 
8 +  
відповідних полів буде виведено 
повідомлення про помилку 
При спробі обрати некоректний шлях до 
9 файлів буде виведено повідомлення про +  
помилку 
Можливість вільного переходу до інших 
10 +  
функцій системи 
Тестування можливості системи в цілому    Таблиця №4.5 
Тест Тест 
№ Опис тесту 
пройдено провалено 
При наявності готових даних користувач 
1 може пропустити той чи інший етап роботи +  
та перейти відразу до бажаного 
Можливість працювати з даними 
2 +  
створеними в іншій системі    
Можливість багаторазового запуску тієї чи 
3 +  
іншої функції системи 
4.2.4 Приймальне тестування 
 Приймальне тестування – тестовий рівень, який зосереджується на 
визначенні того, чи виконуються вимоги специфікації або контракту та чи 
приймати систему, чи повертати розробникам на допрацювання [24]. 
 Даний етап фокусується на тестуванні функціоналу розробленої системи, 
виконання визначених у вимогах функцій чи поставлених задач. Зазвичай на 
такому етапі тестування проводиться, так зване, тестування чорної скрині 
(Black Box Testing), при якому коректність функціоналу системи перевіряється 
без знання чи доступу до внутрішньої структури програмного продукту, 
деталей реалізації функцій, методів чи класів та внутрішніх шляхів. 
67 
 
 ЧДТУ 222127.001 МПЗ  
 Функції, що тестувалися на даному етапі аналогічні тестовим випадкам 
попереднього [Таблиці 4.1 – 4.5], відмінність заклечається у проходженні тестів 
на іншій робочій машині та особою, що не займалася розробкою системи. 
 В результаті було успішно пройдено всі тести описані у таблицях, 
результати співпадають із результатами, отриманими в попередньому етапі та 
задовольняють встановлені до системи вимоги. 
4.3. Приклади впровадженого програмного комплексу 
 Робота користувача з додатком починається з вікна із функцією розбиття 
початкового файлу: 
 
Рис. 4.9 – вікно “розбиття початкового файлу”  
 Тут, як і у подальших вікнах, користувачу рекомендується натиснути на 
кнопку “Інформація по процесу”, де буде очікуваний порядок дій користувача з 
обраною функцією та деяка корисна інформація стосовно даних для введення. 
Після натискання кнопки відкриється вікно (Рис. 4.10), після ознайомлення, 
вікно можна спокійно закривати та переходити до роботи з функцією. 
68 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 4.10 – вікно з інформацією 
 Після ознайомлення з рекомендованим порядком роботи, користувач 
заповнює необхідні поля, вибір файлу через інтерактивне вікно та введення 
довжини відрізку через текстове поле. Після заповнення відповідних полів (Рис. 
4.11), користувач натискає кнопку “Розбити файл”, обирає у вікні, що 
відкриється місце для збереження результатів та очікує поки програма 
завершить розбиття. Після завершення процесу користувач отримує 
відповідний напис (Рис. 4.11) та може повторити процес для інших файлів або 
перейти до наступного. 
 
Рис. 4.11 – вікно із заповненими полями 
69 
 
 ЧДТУ 222127.001 МПЗ  
 
Рис. 4.12 – вікно після завершення процесу 
 Загальний порядок дій у системі в цілому аналогічний до дій під час 
роботи з першою функцією, ознайомлення з інформацією по процесу, вибір 
файлу або файлів для роботи, введення додаткових параметрів, вибір місця для 
збереження результату та спостереження за роботою. 
 Окрема варто відмітити фінальне вікно додатку, “Робота з моделями” 
(Рис. 4.13), де відбувається навчання та використання моделей. 
 
Рис. 4.13 – вікно “Робота з моделями” 
70 
 
 ЧДТУ 222127.001 МПЗ  
 Під час даного етапу користувач для навчання моделей обирає набір 
даних створений на попередньому етапі (Формування первинного опису), та 
обирає місце для збереження моделей, варто відмітити, що моделі будуть 
збережені у вигляді папок із файлами та те, що їх навчання займе певний час. 
 Після завершення навчання користувач обирає одну з навчених моделей 
та числові дані одного з перетворених аудіо файлів, натискає відповідну кнопку 
та отримує результат ідентифікації: 
 
Рис. 4.14 – результат роботи моделі 
 Користувач може повторювати будь-яку з функцій системи необмежену 
кількість разів, отримані у результаті роботи файли можуть бути використані в 
інших копіях системи на інших машинах. 
 
 
 
 
71 
 
 ЧДТУ 222127.001 МПЗ  
ВИСНОВКИ 
 В ході виконання кваліфікаційної роботи магістра було досліджено 
процес ідентифікації звукових повідомлень за допомогою програмних агентів, 
загальний алгоритм процесу та зупинилися на етапах, що до нього входять. 
Побудова подібної системи необхідна як для різноманітних досліджень так і 
для використання з метою забезпечення безпеки у різних сферах життя, від 
побутового до, навіть військового застосування, що буде ефективно та 
актуально в наш час. 
 Було розглянуто алгоритм перетворення Фур’є, що використовується для 
ефективного перетворення звукових хвиль на необхідні користувачу чи 
досліднику числові значення, його особливості, можливості та принципи 
застосування, переваги, що має алгоритм у порівнянні з іншими варіантами 
виконання поставленої задачі та його реалізації як у математичному вигляді так 
і у програмному середовищі. Було визначено спосіб оптимальний застосування 
алгоритму у програмному комплексі, та, варто відмітити, що результат 
перетворення буде напряму залежати від якості перетворюваного файлу, чим 
краще запис тим точніше результат. Щодо числових даних, було визначено, що 
використання фазо-частотних характеристик є ефективнішим ніж використання 
амплітудо-частотних. Використання отриманих, після перетворення, даних 
було розглянуто та використано нейронні мережі для власне процесу 
ідентифікації, визначено, що для більш ефективного навчання моделей 
необхідно проводити процес багато разів та з різними параметрами шарів 
мереж. 
 В результаті було отримано систему з певним набором функцій, що 
можна використовувати як окремо так і комплексно для проходження повного 
циклу роботи програми від декількох звукових файлів до готової моделі 
нейронної мережі, за допомогою якої можна проводити процес ідентифікації. 
  Перевагами розробленої системи є можливість окремого використання її 
функцій, що дозволяє використовувати її частково або в інших випадках 
72 
 
 ЧДТУ 222127.001 МПЗ  
використовувати дані отримані в одній системі як елементи іншої. Варто 
відмітити спосіб навчання моделей нейронних мереж, що, у порівнянні з 
аналогами, навчає велику кількість моделей з різними параметрами та дозволяє 
обирати не лише найкращий результат, але і переглядати певну кількість 
альтернатив, якщо звісно вони пройшли поріг ефективності. Система має 
значну кількість можливостей для покращення як в області перетворення та 
використання числових даних та і в області використання нейронних мереж, що 
дозволить підтримувати та покращувати систему для отримання нових 
результатів. 
  
 
 
  
73 
 
 ЧДТУ 222127.001 МПЗ  
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Тези доповідей дванадцятої міжнародної науково-технічної конференції 
27 – 28 квітня 2022 року Том 1. Баку – Харків – Жиліна – 2022. С. 90. URL: 
https://nure.ua/wp-content/uploads/conf-2022-akov/telecom_2022_volume_1.pdf 
2. Збірка тез п’ятнадцятої міжнародної науково-практичної конференції 17–
18 травня 2022 року Том 1. Київ – 2022. С. 23 
3. Brigham, E. Oran. The fast Fourier transform and its applications. Englewood 
Cliffs, N.J.: Prentice Hall. 1988. – 448c. ISBN 978-0-13-307505-2. URL: 
http://sar.kangwon.ac.kr/gisg/FFT_book.pdf 
4. Sami Smaili. When might you use a fast Fourier transform in computer 
science? Стаття в мережі Інтернет. Sami Smaili // Quora.  URL: 
https://www.quora.com/When-might-you-use-a-fast-Fourier-transform-in-computer-
science 
5. Академічний тлумачний словник української мови» (або СУМ-11). 1970 – 
1980. URL: http://sum.in.ua 
6. А. Н. Швецов Агентно-Орієнтовані системи: Від формальних моделей до 
промислових систем. Вологда – 101с. URL: https://studylib.ru/doc/2300445/ 
agentno-orientirovannye-sistemy--ot-formal._nyh-modelej-k 
7. Нвана Х. Програмні агенти: Огляд. Knowledge Engineering Review. 
Cambridge University Press. Vol. 11, No 3, pp.1-40, Sept 1996. URL: 
http://agents.umbc.edu/introduction/ao/ 
8. Тарасов В.Б. Агенти, багатоагентні системи, віртуальні співтовариства: 
стратегічний напрямок в інформатиці і штучному інтелекті URL: 
https://science.donntu.edu.ua/ius/kirgaev/library/Tarasov-vb-agenty-mnogoagentnye-
sistemy-virtualnye-soobschestva-strategicheskoe-napravlenie-v-informatike-i-
iskusstvennom-intellekte.pdf 
9. О.Г. Мороз, В.С. Степашко. Порівняльний аналіз генераторів структур 
моделей у перебірних алгоритмах МГУА, Стаття в мережі Інтернет., 
URL:http://www.mgua.irtc.org.ua/attach/IMCS/2016_8/11.%D0%9C%D0%BE%D1
%80%D0%BE%D0%B7_C%D1%82%D0%B5%D0%BF%D0%B0%D1%88%D0%
BA%D0%BE_%D0%9E%D0%9A.pdf 
10. Convolutional Neural Networks (LeNet) – DeepLearning 0.1 
documentation. DeepLearning 0.1. LISA Lab. Стаття в мережі Інтернет.  URL: 
https://web.archive.org/web/0171228091645/http://deeplearning.net/tutorial/lenet.ht
ml 
11. What is the Domain Model in Domain Driven Design? Стаття в мережі 
Інтернет. URL: https://www.culttt.com/2014/11/12/domain-model-domain-driven-
design/ 
74 
 
 ЧДТУ 222127.001 МПЗ  
12. Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling 
Language Reference Manual - Addison-Wesley, 2000. – 550 с. ISBN 0-201-30998-
X, URL: https://people.ucalgary.ca/~far/Lectures/SENG609-23/PDF/uml_refman.pdf 
13. Python overview. Стаття в мережі Інтернет.  URL: https://wiki.python 
.org/moin/BeginnersGuide/Overview 
14. Geertjan Wielenga. Beginning NetBeans IDE: For Java Developers. 
Apress – 2015, 280 c. ; 
15.  Jetbrains corporate overview. Презентація. URL:   https://resources 
.jetbrains.com/storage/products/jetbrains/docs/corporate-overview/en-us/jetbrains_сo 
rporate_overview.pdf 
16. Структурна схема – Studfile. Стаття в мережі Інтернет. – URL: 
https://studfile.net/preview/5484923/; 
17.  Функціональна схема – Studopedia. Стаття в мережі Інтернет. – 
URL: https://studopedia.info/1-113607/; 
18. PyQt5. Документація продукту. Огляд. URL:  
https://pypi.org/project/PyQt5/ 
19. Виктор Батоврин. Толковый словарь по системной и программной 
инженерии. ДМК Пресс – 2012, 280с. ; 
20. IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 
2004, 335 c. URL: https://cs.fit.edu/~kgallagher/Schtick/Serious/SWEBOKv3.pdf 
21. What is Unit Testing. Стаття в мережі Інтернет. 
URL:https://smartbear.com/learn/automated-testing/what-is-unit-testing/ 
22. Paul Hamill. Unit Test Frameworks: Tools for High-Quality Software 
Development. O’Reilly – 2004, 212c. URL:  
https://books.google.com.ua/books?id=2ksvdhhnWQsC&printsec=frontcover&hl=ru
#v=onepage&q&f=false 
23. British Computer Society. Working Group on Testing. Testing in 
Software Development. Cambridge University Press – 1986, - 124c. URL:   
https://books.google.com.ua/books?id=utFCImZOTEIC&pg=PA73&dq=integration+
test&hl=en&sa=X&ei=4EpTVOvJMayu7Aak5YCIDA&redir_esc=y#v=onepage&q=
integration%20test&f=false 
24.         International Software Testing Qualification Board. Словник. URL:    
https://glossary.istqb.org/en/search/System%20testing 
25.  System Testing. Стаття в мережі Інтернет. URL:    
https://www.javatpoint.com/system-testing 
 
75
ChSTU repository

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