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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/8844| Title: | Інформативність масиву вхідних даних програмного агента |
| Authors: | Немченко, Вадим В'ячеславович Загородній, Владислав Миколайович |
| Keywords: | інформативність даних;класифікація звуків вхідних даних;нейронні мережі;звукові повідомлення;інтелектуальний програмний агент;аналіз сигналів;data informativeness;classification of input sounds;neural networks;sound messages;signal analysis;intelligent software agent |
| Issue Date: | 18-Dec-2024 |
| Abstract: | АНОТАЦІЯ
Кваліфікаційна робота «Інформативність масиву вхідних даних програмного агента» присвячена підвищенню ефективності аналізу та класифікації звукових повідомлень за допомогою інтелектуальних програмних агентів. У роботі висвітлено актуальність автоматизованого розпізнавання сигналів у контексті інформаційних технологій безпеки комунікацій.
Метою дослідження є вдосконалення методів формування масиву вхідних даних (МВД) для класифікації звукових шляхів підвищення їх інформативності. Завдання включає аналіз існуючих методів, розробку нових алгоритмів для класифікації звуків, побудови моделей на основі нейронних мереж та експериментальну перевірку ефективності розроблених рішень.
Наукова новизна роботи полягає у запропонованих підходах до оптимізації та аналізу МВД, що дозволяє зменшити похибки класифікації та підвищення адаптації програмного агента до роботи з різними типами звукових сигналів. Практичне значення полягає у впровадженні запропонованих рішень для розробки програмного забезпечення метою класифікації аудіоданих.
Дослідження та експерименти підтвердили, що використання вдосконаленого формування МВД дозволяє досягти точності класифікації понад 80%. ABSTRACT The qualification work "Informativeness of the input data array of a software agent" is devoted to increasing the efficiency of analysis and classification of sound messages using intelligent software agents. The work highlights the relevance of automated signal recognition in the context of information technologies for communication security. The purpose of the research is to improve the methods of forming an input data array (IDA) for classifying sound paths and increasing their informativeness. The task includes the analysis of existing methods, the development of new algorithms for classifying sounds, building models based on neural networks and experimentally testing the effectiveness of the developed solutions. The scientific novelty of the work lies in the proposed approaches to optimizing and analyzing the IDA, which allows reducing classification errors and increasing the adaptation of the software agent to work with different types of sound signals. The practical significance lies in the implementation of the proposed solutions for developing software for classifying audio data. Research and experiments have confirmed that the use of improved MVD formation allows achieving classification accuracy of over 80%. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/8844 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Загородній Владислав Миколайович.pdf Restricted Access | 2.78 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Інформативність масиву вхідних даних програмного агента
Виконав: магістрант 2 курсу, групи МПЗ-2304
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва спеціальності)
Магістрант Загородній В.М.
(прізвище та ініціали)
Керівник Немченко В.В.
(прізвище та ініціали)
Черкаси 2024
ЧДТУ.232219.024 ПЗ
ЗМІСТ
ЗМІСТ ......................................................................................................................... 3
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ..................................................................... 6
ВСТУП ....................................................................................................................... 7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................... 9
1.1. Визначення актуальних проблем .................................................................. 9
1.2. Аналіз існуючих методів та засобів .............................................................. 9
1.3. Аналіз існуючих аналогів програмного забезпечення.............................. 17
Висновки до розділу ............................................................................................ 22
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРЕМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ........ 23
2.1. Теоретичні дослідження .............................................................................. 23
2.1.1. Математична постановка задачі класифікації ..................................... 23
2.1.2. Гіпотеза про інформативні ознаки ........................................................ 25
2.1.3. Метод аналізу та перетворення звукових ознак .................................. 27
2.1.4. Тип моделі-класифікатора нейромережі, топологія, структура ........ 30
2.1.5. Функціональна та структурна схеми .................................................... 32
2.1.6. Характеристики якості моделей ............................................................ 34
2.2. Експериментальні дослідження .................................................................. 38
2.2.1. Опис звукових повідомлень .................................................................. 38
2.2.2. Опис процесу декомпозиції повідомлення, обґрунтування тривалості
вікна ................................................................................................................... 39
2.2.3. Опис процесу побудови навчальних класів звукових повідомлень .. 39
2.2.4. Опис тестового класу звукових повідомлень ...................................... 40
2.2.5. Опис процесу формування масиву вхідних даних із зазначенням
точок спостереження ........................................................................................ 41
2.2.6. Результати експериментів...................................................................... 42
Висновки до розділу ............................................................................................ 44
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ .................................................................................................................. 45
3
ЧДТУ.232219.024 ПЗ
3.1. Моделювання предметної області .............................................................. 45
3.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ............................................................................ 46
3.1.2. Елементи моделювання предметної області........................................ 47
3.1.3. Робоча область моделювання ................................................................ 49
3.2. Формування та аналіз вимог ........................................................................ 49
3.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги .................................................................................. 50
3.2.2. Формування вимог за допомогою діаграм прецедентів ..................... 51
3.2.3. Проектування логічної структури програмного комплексу .............. 57
3.2.3.1. Діаграма класів .................................................................................... 57
3.2.3.2. Діаграма пакетів .................................................................................. 59
3.2.4. Архітектурне проектування................................................................... 60
3.2.4.1. Діаграма компонентів ......................................................................... 60
3.2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ....................................................................................................... 63
3.2.5. Моделювання поведінки системи ......................................................... 65
3.2.5.1. Діаграма діяльності ............................................................................. 65
3.2.5.2. Діаграма послідовності ....................................................................... 67
3.2.5.3. Діаграма комунікації ........................................................................... 71
3.2.5.4. Діаграма скінченого автомату ............................................................ 73
Висновки до розділу ............................................................................................ 77
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
................................................................................................................................... 79
4.1 Розробка програмного комплексу ................................................................ 79
4.1.1 Розробка програмного комплексу ......................................................... 79
4.1.1.1 Обґрунтування вибору засобів реалізації .......................................... 79
4.1.1.2 Опис структурної (функціональної) схеми ........................................ 81
4.1.1.3 Опис логічної схеми системи .............................................................. 84
4.1.1.4 Розробка бази даних ............................................................................. 85
4.1.1.5 Розробка інтерфейсу користувача ...................................................... 87
4
ЧДТУ.232219.024 ПЗ
4.1.1.6 Опис розробки програмних компонентів .......................................... 88
4.1.2 Тестування системи ................................................................................. 90
4.1.2.1 Модульне тестування ........................................................................... 92
4.1.2.2 Інтеграційне тестування....................................................................... 94
Продовження таблиці 4.2 ................................................................................. 94
4.1.2.3 Системне тестування ............................................................................ 95
4.1.2.4 Приймальне тестування ....................................................................... 96
4.1.3 Приклади впровадженого програмного комплексу ............................. 96
ВИСНОВКИ .......................................................................................................... 100
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 101
ДОДАТОК А ......................................................................................................... 111
ДОДАТОК Б .......................................................................................................... 113
5
ЧДТУ.232219.024 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
FFT швидке перетворення фур’є (fast
Fourier transform)
IOS операційна система для iPhone
(iPhone operation system)
LSTM довга короткотривала пам’ять (long
short-term memory), архітектура
нейронної мережі
UML уніфікована мова моделювання
(unified modelling language)
UI інтерфейс користувача (user interface)
6
ЧДТУ.232219.024 ПЗ
ВСТУП
Актуальність теми: У зв'язку зі зростаючою кількістю цифрових
комунікацій, особливо у мобільних платформах, виникає потреба в розробці
ефективних інструментів для аналізу та класифікації звукових повідомлень.
Розробка аналізатора, здатного відрізняти свої та чужі повідомлення, є
ключовою для забезпечення конфіденційності та безпеки інформації.
У сфері інформаційної безпеки, автоматизоване виявлення
неавторизованих або потенційно шкідливих звукових повідомлень може
відіграти важливу роль у захисті особистих даних користувачів та
корпоративної інформації. Такий підхід може бути ефективним у боротьбі з
кіберзлочинністю, зокрема із розповсюдженням шкідливого програмного
забезпечення через аудіо-повідомлення.
Мета і завдання дослідження: Підвищення інформативності масиву
вхідних даних програмного агенту для аналізу звукових повідомлень.
Для досягнення цієї мети треба виконати такі завдання:
провести інформаційний пошук методів та засобів розв’язання
поставлених задач;
дослідити методи аналізу та класифікації звукових повідомлень з
метою виявлення напрямків підвищення інформативності масиву
вхідних даних (МВД) ;
вдосконалити метод формування МВД для класифікації звукових
повідомлень;
спроектувати та програмно реалізувати програмний продукт аналізу і
класифікації звукового повідомлення.
Об’єкт дослідження: Процес класифікації звукових повідомлень
програмними агентами.
Предмет досліджень: Процес формування масиву вхідних даних
програмного агента для аналізу звукових повідомлень.
Методи дослідження: Для досягнення поставленої мети було
застосовано такі методи: аналіз у процесі декомпозиції повідомлення на
7
ЧДТУ.232219.024 ПЗ
складові частини, синтез – під час побудови словника ознак звукового
повідомлення; формалізація – в процесі визначення процесів підвищення
інформативності ознак та алгоритмів для аналізу і класифікації звуків.
Наукова новизна одержаних результатів: Удосконалено метод
побудови масиву вхідних даних для аналізу і класифікації звукових
повідомлень, що підвищує інформативність масиву вхідних даних і збільшує
кількість правильно класифікованих звуків.
Практичне значення отриманих результатів: Удосконалений метод
формування масиву вхідних даних впроваджено у практику розробки
програмного забезпечення моніторингового агента для класифікації звукових
повідомлень. Створено алгоритм проектування програмного агента. Програмно
реалізовано метод аналізу і класифікації звукових повідомлень.
Особистий внесок автора: Всі відображені в роботі результати
представлені автором особисто.
8
ЧДТУ.232219.024 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Визначення актуальних проблем
Існує кілька ключових проблем, які слід розглянути.
Першою є проблема визначення довжини аудіо запису для аналізу.
Визначення оптимальної довжини звукових файлів є критично важливим.
Занадто короткі фрагменти можуть не містити достатньо інформації для
точного аналізу, в той час як занадто довгі можуть включати зайвий шум або
нерелевантні звукові події [1]. Також необхідно врахувати баланс між
достатньою кількістю даних для класифікації та обмеженнями на обробку в
реальному часі, особливо на мобільних пристроях [2].
Наступною є проблема фільтрації сигналу за частотою. Фільтрація звуку
в діапазоні 16 - 349 ГЦ дозволяє виокремити основні характеристики людського
голосу. Однак, існує ризик втрати важливої інформації, яка може бути
розташована поза цим діапазоном. Важливо розробити механізм фільтрації,
який би ефективно виділяв необхідні характеристики голосу, не втрачаючи при
цьому інші важливі звукові сигнали [3].
Додатково слід виділити перетворення у фазо-амплітудні
характеристики, а саме використання швидкого перетворення Фур'є (FFT) для
трансформації звукових сигналів у фазо-амплітудні характеристики є
ключовим для аналізу. Цей процес дозволяє ефективно розділити звук на його
складові частоти [4]. Однак, застосування перетворення може бути викликом з
точки зору обчислювальної складності та точності аналізу, особливо при
обробці даних в реальному часі.
Також важливим питанням є використання нейромережі для
класифікації. Розробка і навчання нейронної мережі для розпізнавання голосу
як "Свій" або "Чужий" вимагає великого обсягу навчальних даних.
Забезпечення різноманітності та репрезентативності цих даних є важливим для
точності моделі [5].
1.2. Аналіз існуючих методів та засобів
9
ЧДТУ.232219.024 ПЗ
Питання визначення оптимальної довжини аудіо запису для аналізу є
ключовим в аудіо обробці та класифікації. Оптимальна довжина фрагмента
залежить від цілей аналізу та специфіки звукового повідомлення. Їх можливо
розділити на декілька основних складнощів та варіантів їх рішення [6], що
зображені в таблиці 1.1.
Таблиця 1.1
Проблеми та рішення визначення довжини звукового повідомлення
Опис проблеми Опис рішення
Аугментації даних
Занадто короткі фрагменти
Об'єднання фрагментів
Занадто довгі фрагменти Поділ на менші фрагменти
Оптимізація алгоритмів
Обмеження обробки в реальному часі Хмарні обчислення
Полегшені моделі
Більш детально зупинимося на кожному із варіантів рішення проблеми,
для розуміння наявності можливостей для використання і покращення.
Аугментація є процесом зміни існуючих звукових повідомлень для
створення нових варіацій, які можуть бути використані для тренування
машинного навчання та глибоких нейронних мереж. Це особливо корисно, коли
маємо справу з короткими фрагментами аудіо, які можуть не містити достатньо
інформації для ефективного навчання [7].
Один із методів аугментації включає зміну швидкості відтворення аудіо
без зміни висоти тону, що допомагає мережі адаптуватися до різних темпів
мовлення. Інший підхід полягає у додаванні шуму, включаючи фоновий шум
або інші звукові ефекти, для підвищення стійкості моделі до шумних умов.
Частотно-часове маскування, яке видаляє певні частоти або часові інтервали,
змушує мережу зосередитися на різних частинах аудіо сигналу, покращуючи
розпізнавання при втраті інформації. Зміна висоти тону аудіо допомагає моделі
10
ЧДТУ.232219.024 ПЗ
краще адаптуватися до варіацій у висоті голосу, тоді як застосування ефектів
реверберації створює акустичне середовище, підвищуючи ефективність
розпізнавання звуків у різних акустичних умовах [8] (табл. 1.2 та 1.3).
Таблиця 1.2
Ефекти Зміни Швидкості Відтворення
Швидкість Відтворення Вплив на Аудіо
Повільне Розтягнення
Швидке Стиснення
Таблиця 1.3
Види Шуму
Тип Шуму Характеристика
Білий шум Рівномірний по всіх частотах
Шум навколишнього середовища Реалістичні шумові умови
В свою чергу, процес поділу довгих аудіозаписів на коротші фрагменти
сприяє ефективнішому виявленню ознак та точності класифікації. На практиці,
це може означати ізоляцію окремих слів для розпізнавання мови або
виокремлення унікальних елементів звуку для ідентифікації музичних творів.
Вдосконалення алгоритмів включає налаштування параметрів та вибір
ефективних моделей для підвищення точності розпізнавання, що може бути
ілюстровано здатністю систем розрізняти між подібними фразами в мовленні
або відокремлювати музичні інструменти у комплексних композиціях [9].
Хмарні обчислення відіграють ключову роль у масштабуванні
обчислювальних ресурсів, надаючи необхідну потужність для аналізу об'ємних
дата сетів. У сфері музичного трансляції, хмарні сервіси можуть
використовуватися для розробки рекомендаційних систем, які базуються на
аналізі великих обсягів даних користувацьких прослуховувань [10]. Нарешті,
розробка легких моделей дозволяє впроваджувати розпізнавання мови та інші
11
ЧДТУ.232219.024 ПЗ
функції безпосередньо на кінцевих пристроях, зменшуючи залежність від
хмарних ресурсів та забезпечуючи більшу незалежність та приватність у
вбудованих системах, таких як смарт-колонки або інтерактивні іграшки [11].
Частота використання варіантів рішення [12] вказані в таблиці 1.4.
Таблиця 1.4
Частота використання методів оптимізації довжини повідомлення
Метод Частота використання
Поділ на менші фрагменти Висока
Оптимізація алгоритмів Середня
Хмарні обчислення Зростаюча
Розробка полегшених моделей Низька
Фільтрація сигналу за частотою є важливою частиною обробки звукових
повідомлень. Цей процес включає виокремлення певних частот зі звукового
сигналу, що має значний вплив на якість та розуміння вихідного аудіо.
Особливий інтерес представляє діапазон частот 16 - 349 ГЦ, який відіграє
ключову роль у виділенні основних характеристик людського голосу. Цей
діапазон був обраний на підставі досліджень, що вказують на його значимість
у мовленні [13].
Однак, існує виклик, пов'язаний з втратою важливої інформації, яка може
бути розташована поза цим діапазоном. Наприклад, вищі гармоніки та емоційні
нюанси голосу, які відіграють важливу роль у сприйнятті та інтерпретації
мовлення, часто знаходяться за межами цього діапазону [14]. Відтак, постає
завдання розробки механізму фільтрації, який би дозволяв виділяти необхідні
характеристики голосу, не втрачаючи при цьому інші важливі звукові сигнали
[15].
Розглядаючи теоретичні аспекти фільтрації сигналу, зосередимо увагу на
важливості правильного підходу до обробки звукових даних. Фільтрація
сигналу передбачає відділення певних частотних компонентів зі звукового
12
ЧДТУ.232219.024 ПЗ
сигналу, що виконується за допомогою специфічних математичних операцій
[16]. Одна з ключових формул у фільтрації сигналу є формула фільтрації:
��(��) = ��(��) ∙ ��(��), (1.1)
де:
��(��) - вихідний сигнал,
��(��) – функція передачі фільтра,
��(��) – вхідний сигнал.
Ця формула ілюструє, як фільтр модифікує вхідний сигнал, змінюючи
його спектральний склад. Уявімо ситуацію, коли потрібно видалити шум
низької частоти з аудіозапису. Використовуючи фільтр нижніх частот із
заданою частотою зрізу, можна значно знизити небажані низькочастотні
компоненти сигналу [17]. Важливу роль в обробці сигналу відіграє
використання вікна Гаммінга, яке допомагає зменшити спотворення на краях
часового вікна перед виконанням швидкого перетворення Фур'є (FFT).
2����
��(��) = 0.54 − 0.46 ∙ cos( ) , (1.2)
�� − 1
де:
N – кількість кроків вікна,
n – поточний відлік.
Це вікно сприяє згладжуванню переходів, тим самим знижуючи
спектральний витік та покращуючи точність спектрального аналізу [18].
У процесі практичного застосування теоретичних засад фільтрації
сигналу стикаємося з різноманітними викликами та складнощами. Розвиток та
імплементація адаптивних фільтрів є одним з основних напрямків у цій області.
Адаптивні фільтри відрізняються здатністю динамічно змінювати свої
параметри залежно від особливостей аналізованого сигналу. Наприклад, в
13
ЧДТУ.232219.024 ПЗ
залежності від визначених характеристик голосу, система може автоматично
коригувати частоту зрізу фільтра, що дозволяє зберігати значимі елементи
сигналу, які можуть включати важливі нюанси мовлення [19].
Значну роль у вдосконаленні фільтрації відіграє застосування методів
машинного навчання. Алгоритми машинного навчання здатні виявляти складні
патерни в звукових сигналах, що сприяє підвищенню точності визначення
оптимальних параметрів фільтрації для кожного окремого випадку [20].
Використання таких алгоритмів може значно підсилити здатність системи до
точного аналізу звукових повідомлень, зокрема при ідентифікації та
виокремленні специфічних особливостей мовлення.
Основним викликом у процесі фільтрації сигналу є ризик втрати важливої
інформації, яка не входить у вибраний діапазон частот. Це особливо актуально,
коли йдеться про емоційні нюанси та додаткові акустичні особливості
мовлення, які можуть бути важливими для повного розуміння змісту
повідомлення. Іншим аспектом є врахування різноманітності мовленнєвих
особливостей різних осіб, що може включати відмінності в інтонації, тембрі та
інших характеристиках мовлення. Така різноманітність вимагає гнучкого
підходу до фільтрації, щоб забезпечити збереження всіх необхідних елементів
аудіо сигналу [21].
У таблицях 1.5 та 1.6, представлено характеристики різних типів фільтрів
та спектральні особливості людського голосу. Ці дані демонструють важливість
вибору відповідних параметрів фільтрації, щоб оптимально обробляти звукові
сигнали з урахуванням їхніх унікальних характеристик [22]. Застосування цих
знань і технік дозволяє досягнути більш детального та точного аналізу звукових
повідомлень.
Таблиця 1.5
Характеристики фільтрів
Тип Фільтра Частота Зрізу (ГЦ) Спад (ДБ/октава)
Нижніх частот 20 - 250 12, 24, 48
14
ЧДТУ.232219.024 ПЗ
Верхніх частот 3000 - 8000 12, 24, 48
Смуговий 250 - 3000 12, 24
Таблиця 1.6
Спектральні характеристики людського голосу
Характеристика Частотний Діапазон (ГЦ)
Основний тон 85 – 180
Форманти 300 – 3400
Вищі гармоніки 3400 – 8000
Фільтрація сигналу вимагає точного балансу між виділенням ключових
характеристик голосу та збереженням інших важливих звукових сигналів.
Використання адаптивних фільтрів і методів машинного навчання може
покращити цей процес, забезпечуючи глибший аналіз аудіо даних. Однак,
важливо враховувати різноманітність мовленнєвих особливостей і ризик втрати
важливої інформації [23].
Майбутні напрями досліджень можуть включати розвиток алгоритмів
глибокого навчання для більш точного розпізнавання і обробки мовленнєвих
сигналів. Індивідуальна адаптація фільтрації, що враховує особливості мовця та
контекст мовлення, також є перспективним напрямком. Крім того, інтеграція
фільтрації з іншими технологіями обробки звуку та розпізнавання мовлення
може призвести до створення комплексних та вдосконалених систем.
В цілому, фільтрація частотного сигналу для аналізу звукових
повідомлень є складним завданням, що вимагає глибокого розуміння звукових
сигналів та їх обробки [24]. Продовження досліджень у цій області відкриває
можливості для покращення якості обробки аудіо даних, що сприятиме
ефективнішому розумінню мовлення та підвищенню якості комунікації.
Наступним кроком розглянемо швидкі перетворення Фур’є (FFT). Воно
відіграє ключову роль у класифікації звукових повідомлень, що є важливою
частиною багатьох сучасних технологічних застосувань, від обробки музики до
15
ЧДТУ.232219.024 ПЗ
розпізнавання мови. Ефективність FFT полягає у його здатності швидко
перетворювати сигнали з часового домену в частотний, дозволяючи точно
визначити частотні компоненти звуку [25].
Однією з ключових проблем у використанні FFT для класифікації аудіо
сигналів є потреба у збалансуванні між детальністю аналізу та швидкістю
обробки. Це особливо важливо для додатків, що працюють в реальному часі, де
швидка обробка сигналів є критичною. Ще однією проблемою є обробка
сигналів з нерегулярною кількістю кроків, що може спричинити спотворення в
FFT аналізі [26].
FFT є основоположним інструментом у багатьох застосуваннях,
включаючи аналіз звукових хвиль, таких як мовлення, музика або навіть шумові
сигнали. Наприклад, у розпізнаванні мови, FFT використовується для
визначення характерних особливостей мовлення, які можуть бути
класифіковані за допомогою алгоритмів машинного навчання. У музичній
індустрії, FFT використовується для аналізу музичних творів, класифікації
жанрів або навіть у створенні цифрових музичних інструментів [27].
��−1 ����
��(��) = ∑ ��(��) ∙ ��−2����
�� , (1.3)
��=0
де:
X(��) – FFT сигнал,
��(��) – вхідний сигнал,
N – кількість кроків.
Значною проблемою є відсутність спеціалізованих реалізацій FFT. Це
створює труднощі для розробників, які намагаються створювати ефективні
додатки для класифікації звуків на пристроях Apple, хоча і представлені різні
алгоритми на інших платформах (табл. 1.7). Розробка оптимізованих рішень
для FFT потребує додаткових ресурсів та інноваційних підходів, щоб
компенсувати обмеження платформи та забезпечити якісну обробку звуку [28].
16
ЧДТУ.232219.024 ПЗ
Таблиця 1.7
Порівняльний аналіз різних реалізацій FFT
Оптимальне
Алгоритм Швидкість Точність
застосування
Cooley-Tukey Висока Висока Загальне
Нерівномірні
Bluestein's Середня Висока
частини
Ефективність
Split-Radix Висока Висока
пам'яті
Попри ці виклики, FFT залишається важливим інструментом у розробці
систем класифікації звукових повідомлень. Подальші дослідження та розвиток
в цій області мають велике значення для покращення якості та точності
класифікації звуків, особливо в контексті мобільних додатків та розумних
пристроїв.
Окрім того, існують питання ефективності та оптимізації FFT, які
потребують подальших досліджень. Зокрема, розробка більш ефективних
алгоритмів для зменшення витоку частоти та підвищення точності аналізу є
ключовими напрямками майбутніх досліджень. Це може включати створення
адаптивних алгоритмів FFT, які можуть оптимізувати обробку для конкретних
типів звукових сигналів, забезпечуючи таким чином більш точну та швидку
класифікацію [29].
1.3. Аналіз існуючих аналогів програмного забезпечення
Для початку визначимо критерії для пошуку аналогів програмного
забезпечення. Першим критерієм буде доступність, що включає в себе
наявність мобільного додатку в магазині додатків AppStore. Наступним
критерієм є функціональні можливості, такі як можливість запису звукового
повідомлення для класифікації через мікрофон телефону, робота додатку без
17
ЧДТУ.232219.024 ПЗ
доступу до інтернету, можливість класифікації звукового повідомлення з
високою точністю, швидкість обробки. Важливим аспектом є простота
користувацького інтерфейсу та ціноутворення. Узагальнені критерії
відображено в таблиці 1.8.
Таблиця 1.8
Критерії пошуку аналогів
Критерій Опис
Доступність AppStore
Функціональні можливості Класифікація, мікрофон, без інтернету, швидка
обробка
Простота інтерфейсу Apple Guidelines
Ціноутворення Умовно безкоштовно
Було знайдено декілька мобільних додатків, які співпадають по більшості
із критеріїв.
Перший в списку, це додаток Merlin Bird ID, розроблений Корнельською
лабораторією орнітології, високо оцінений користувачами за здатність
ідентифікувати птахів. Дозволяє класифікувати звук птахів із звукового
повідомлення використовуючи мікрофон, або раніше збережений запис.
Додаток безкоштовно доступний в AppStore, працює без доступу до інтернету,
має простий і зрозумілий інтерфейс (рисунок 1.1), класифікує звуки великої
кількості птахів. Серед переваг, можна відзначити, наявність історії аудіо
записів та успішних класифікацій. Серед недоліків – відсутня можливість
додавати власну класифікацію, фактично додатково навчати модель. Точність
класифікації дуже чутлива до шумів, та інших звуків птахів [30].
Наступний це додаток Sound Hound, розроблений компанією SoundHound
AI, яка спеціалізується на рішеннях пов’язаних із роботою із голосом, який
зображено на рисунку 1.2. Дозволяє класифікувати звук пісень із звукового
повідомлення використовуючи мікрофон. Додаток безкоштовно доступний в
18
ЧДТУ.232219.024 ПЗ
AppStore, не працює без доступу до інтернету та класифікує звуки великої
кількості пісень. Серед переваг наявність успішних класифікацій. Серед
недоліків – відсутня можливість додавати власну класифікацію, додатково
навчати моделі та працювати без доступу до інтернету [31].
Рисунок 1.1 - Інтерфейс запису додатку Merlin Bird ID
Варто відзначити факт розпізнавання птахів у реальному часі, без
доступу до інтернету. Це є важливим, в ситуаціях, коли інтернет не доступний,
без додаткових записів, лише з мікрофоном.
Кожен із додатків має свої переваги та недоліки, тому розмістимо їх в
порівняльну таблицю (табл. 1.9).
19
ЧДТУ.232219.024 ПЗ
Рисунок 1.2 - Інтерфейс запису додатку Sound Hound
Таблиця 1.9
Порівняння додатків класифікації звуків
Критерій Merlin Bird ID Sound Hound
Наявність в AppStore Так Так
Ціна Безкоштовно Безкоштовно
20
ЧДТУ.232219.024 ПЗ
Чутливість до шумів Так Ні
Необхідність доступу до Ні Ні
інтернету
Історія класифікацій Так Так
До навчання моделі Ні Ні
21
ЧДТУ.232219.024 ПЗ
Висновки до розділу
В процесі визначення актуальних та аналізу існуючих проблем та
програмних засобів, прийшов до наступних висновків.
Довжина аудіо запису, який використовується для процесу класифікації є
критично важливим для точності ідентифікації та класифікації свій або чужий,
оскільки впливають на характеристики та процес навчання моделі, та потребує
додаткових досліджень, що дозволять підвищити точність ідентифікації,
наприклад, за допомогою експериментів.
Фільтрація вхідного сигналу від шумів є наступною важливою
проблемою, яку до кінця не вирішено в науковому світі, оскільки відсутній
автоматичний механізм визначення важливості полоси частот, що необхідно
відфільтрувати. Це можливо вирішити за допомогою вибору користувачем, в
процесі первинного налаштування типу класифікації (голос, музика, певні
звуки).
Не менш важливим етапом є реалізація моделі нейромережі для
класифікації, оскільки важливим є різні фактори, як швидкодія, точність
класифікації, дата сет і його розміри. Якщо вирішити проблему зменшення
кількості аудіо повідомлень, це дозволить швидше реалізовувати нові моделі
для використання. Ця проблема досі не вирішена, оскільки точність моделі
напряму залежить від кількості даних, та їх якості, в процесі тренування.
Не вдалось виявити публічних мобільних додатків, які дозволяють
класифікувати голосові повідомлення як свій або чужий, а тому ця область
розробки і дослідження є доцільним.
22
ЧДТУ.232219.024 ПЗ
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРЕМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1. Теоретичні дослідження
2.1.1. Математична постановка задачі класифікації
Математичною постановкою задачі класифікації є задача бінарної
класифікації. Для класифікації звукових повідомлень на свій та чужий
передбачається визначення інформаційних ознак та розробку моделі, яка може
аналізувати характеристики звуку та вирішувати, чи належить він до певного
класу, свій або чужий.
Метою класифікації є передбачення категоріальних міток класів нових
екземплярів на основі минулих спостережень з найбільшою впевненістю. Дані
в задачі класифікації поділяються на ознаки �� і цільову змінну ��, де остання -
це мітка класифікації [32]. Ознаки, об’єднані між собою являють простір ознак,
що представлений у вигляді ��-вимірний масив, в якому знаходяться дані для
класифікації. Кожен вимір представляє характеристику даних. Будь-який
екземпляр можна представити у вигляді [33]:
�� = (��1, ��2, … , ����) (2.1)
де:
�� – екземпляр у наборі даних,
���� – ознака,
�� – кількість ознак.
Опишемо модель або функцію класифікації, як відображення з простору
ознак на множину міток класів, яку можна представити у вигляді формули:
�� ∶ ���� → �� (2.2)
де: �� – функція класифікації або модель,
���� – простір ознак,
→ - функція дії, що відображає трансформацію,
23
ЧДТУ.232219.024 ПЗ
�� – множина можливих міток.
Функція класифікації інкапсулює алгоритмічну методологію, яка на
основі вхідного вектору прогнозує мітку класу на виході. По суті, вона втілює
вивчені закономірності та взаємозв'язки, виявлені в навчальних даних, що
дозволяє робити прогнози на нових даних. Позначення ���� означає, що кожна
точка даних у просторі є вектором, що складається з �� ознак або атрибутів.
Кожен вимір у цьому просторі відповідає певній характеристиці даних.
Наприклад, у наборі даних, де кожен екземпляр характеризується трьома
ознаками, �� дорівнюватиме 3, а простір ознак буде тривимірним і
позначатиметься як ��3.
У задачах класифікації �� зазвичай складається з дискретних,
категоріальних міток. Для бінарної класифікації �� може містити два елементи,
наприклад, {0, 1}, що представляють два різні класи. У багато класових
сценаріях, �� може містити ширший набір міток класів [34].
Наступним кроком опишемо функцію втрат за допомогою формули:
��(��, ��) = −[�� log(��) + (1 − ��) log(1 − ��)] (2.3)
де:
�� – функція втрат,
�� – актуальна мітку точки даних,
�� – прогнозована ймовірність.
Вона вимірює різницю між фактичним значенням мітки класифікації �� та
прогнозованою ймовірністю ��. Функція втрат є невід’ємною частиною процесу
навчання моделі, керуючи оптимізацією параметрів моделі. В свою чергу ��
представляє фактичну мітку точки даних, яка представляє собою 0 або 1 та є
метою передбачення. Слід зазначити, що �� обмежена між 0 та 1 і обраховується
із результату класифікації моделі.
Функція втрат у машинному навчанні є важливим інструментом для
кількісної оцінки моделі. Чим менше значення функції втрат, тим краща
24
ЧДТУ.232219.024 ПЗ
модель, тобто прогнози ближчі до істинних міток. Мінімізація цієї функції
втрат у процесі навчання є ключовим фактором для підвищення точності
прогнозів моделі [35].
В якості підсумку, задачу класифікації можна описати у вигляді формули,
що включає всі раніше описані етапи.
��(��) = arg ��������∈�� ��(��|��) (2.4)
де:
��(��) – модель або функція класифікації,
arg ������ - оператор, який знаходить значення змінної, що максимізує
задану функцію,
�� - перебирає всі можливі мітки класів у множині ��,
�� - представляє множину всіх можливих міток класів у задачі
класифікації,
��(��|��) - умовна ймовірність, яка кількісно виражає ймовірність того, що
точка даних з ознаками �� буде віднесена до класу ��.
У задачі класифікації основною метою є розробка моделі, яка може точно
передбачити мітку класу для заданих вхідних даних на основі вивчених
шаблонів з навчальних даних. Для цього модель обчислює ймовірності для
кожної потенційної мітки класу на основі вхідних даних, а потім вибирає мітку
з найвищою ймовірністю для прогнозування. Цей процес передбачає розуміння
та використання взаємозв'язків між векторами ознак та відповідними їм
мітками класів у навчальних даних. Узагальнена формула відображає суть
цього процесу прийняття рішень, підкреслюючи основну мету - знайти
найбільш ймовірну мітку класу для заданого набору ознак [36].
2.1.2. Гіпотеза про інформативні ознаки
У сучасному світі обробки аудіо даних значну увагу приділяється
виявленню та аналізу ключових ознак, які дозволяють класифікувати аудіо
повідомлення. В рамках даної роботи, висунуто гіпотезу, що амплітуда, фаза,
25
ЧДТУ.232219.024 ПЗ
довжина звукової частини та частотний діапазон є ключовими ознаками для
класифікації звукових повідомлень, зокрема голосових.
Перш за все, амплітуда звуку може надавати інформацію про
інтенсивність та енергетичний рівень звукового сигналу. Вона відіграє ключову
роль у розрізненні гучних і тихих звуків, що може бути важливим у контексті
голосових повідомлень [37].
Фаза звуку допомагає фіксувати часові характеристики звукових хвиль,
що є критичним для розуміння ритму та мелодії мовлення. Вона може
вказувати на особливості артикуляції та інтонації, які є визначальними для
ідентифікації та класифікації голосових повідомлень [38].
Довжина звукової частини, такої як склади чи слова, може відображати
особливості мовлення та інтонації мовця. Вона має потенціал виявлення
емоційного забарвлення або навіть діалектних особливостей у голосових
повідомленнях [39].
Нарешті, частотний діапазон дозволяє розрізнити звуки на основі їх
висоти та тембру. Ця ознака є фундаментальною для класифікації аудіо
сигналів, оскільки вона відображає спектральні характеристики звуку [40].
Враховуючи це, розглянуто гіпотезу, що базується на припущенні, що
комбінація цих чотирьох ознак забезпечить основу для класифікації аудіо
повідомлень, зокрема забезпечить точне визначення голосових та інших
повідомлень у різноманітних аудіозаписах, та є інформативним та описані в
таблиці 2.1.
Таблиця 2.1
Інформативні ознаки
Ознака Опис
Сегментація повідомлення Від 0.5 секунди
Частотна фільтрація 16-350 ГЦ для голосових повідомлень
Частотний діапазон Від 1 ГЦ
Продовження таблиці 2.1
26
ЧДТУ.232219.024 ПЗ
Амплітуда Для кожного із частотних діапазонів
Фаза Для кожного із частотних діапазонів
2.1.3. Метод аналізу та перетворення звукових ознак
Опишемо метод аналізу, що визначає систематичний підхід до
перетворення звукових характеристик з метою класифікації аудіо повідомлень.
Він базується на сегментації аудіо на менші частини, перетворенні цих
сегментів у числові представлення амплітуди та фази за допомогою швидкого
перетворення Фур'є (FFT) та застосуванні фільтрації за частотними
діапазонами.
Першим кроком опишемо метод сегментації аудіо повідомлення на
менші частини. Припустимо, що дано звукове аудіо повідомлення, довжина
якого більше 1 секунди. Сегментація даного аудіо повідомлення можливо
описати наступною формулою [41]:
��(��, ��) = [��[0 ∶ ��], ��[�� ∶ 2��], … , ��[(�� − 1)�� ∶ ��]] (2.5)
де:
�� – аудіо сигнал,
�� – довжина сегменту (секунди),
�� – загальна довжина аудіо сигналу,
�� - кількість повних сегментів,
��[�� ∶ ��] – позначає відрізок аудіо з ��-ї до ��-ї секунди.
Ця функція �� поділяє аудіо сигнал на відрізки довжиною ��, за винятком
останнього відрізка, який забирає решту аудіо, якщо він коротший за ��.
Наступним кроком опишемо метод перетворення сегментованого
відрізку аудіо сигналу у числові значення амплітуди та частоти. Для цього
використаємо швидке перетворення Фур’є, що дозволяє отримати числове
значення для кожного із діапазону частот, починаючи з 1 ГЦ, що представляє
собою послідовність дійсних чисел. FFT можна представити у вигляді формули
27
ЧДТУ.232219.024 ПЗ
[42]:
�� − 1 ��2��
��(��) = ∑ ��(��) ∙ ��− ���� ��
�� , �� = 0, 1, … , (2.6)
�� = 0 2
де:
��(��) – представляє числову послідовність виходу FFT,
�� – загальна кількість зразків,
��(��) – дійсне значення вхідного сигналу, в часовій області,
�� - представляє уявну одиницю, яка визначається як √−1,
�� – номер частотного діапазону.
В результаті чого отримаємо послідовність дійсних числових значень,
розподілених за частотою, які необхідно відфільтрувати, для цікавого для нас
діапазону частот. Із отриманих дійсних числових значень можемо отримати
амплітуду та фазу, для кожного із діапазону частот, що може бути представлено
у вигляді формули [43]:
��(��) = √��2 + ��2 (2.7)
де:
��(��) – амплітуда для окремо взятого частотного діапазону,
�� – номер частотного діапазону,
�� – дійсна частина числової послідовності виходу FFT для окремого
діапазону,
�� – уявна частина числової послідовності виходу FFT для окремого
діапазону.
В свою чергу фаза дає інформацію про зсув частотної складової відносно
точки відліку в часі і для кожної частотної складової може бути представлена у
вигляді формули [44]:
28
ЧДТУ.232219.024 ПЗ
��(��) = ������������2(��, ��) (2.8)
де:
��(��) – фаза для окремо взятого частотного діапазону,
�� – номер частотного діапазону,
������������2 - чотириквадрантний обернений тангенс, який враховує знаки
дійсної та уявної частин для визначення правильного квадранта кута,
�� – дійсна частина числової послідовності виходу FFT для окремого
діапазону,
�� – уявна частина числової послідовності виходу FFT для окремого
діапазону.
Останнім кроком відфільтруємо отримані амплітуди і фази за частотним
діапазоном, що можна представити у вигляді формули:
�� �� ∙��
��′ = {�� ∶ ��[��] ���������� ≤ �� ≤ ������ } (2.9)
���� ����
де:
��′ - словник отриманий після фільтрації, де ключ являє собою номер
частотного діапазону, а значенням є числові значення амплітуди і частоти
у вигляді кортежу,
�� – номер частотного діапазону,
�� – вхідний словник, який складається з аналогічних ключів та значень,
що і вихідний словник після фільтрації,
������������ – початкове значення діапазону частот для фільтрації, наприклад 16
ГЦ, для голосових повідомлень,
�������� – кінцеве значення діапазону частот для фільтрації, наприклад 350
ГЦ, для голосових повідомлень,
29
ЧДТУ.232219.024 ПЗ
���� – частот дискретизації звукового повідомлення, наприклад для запису
аудіо повідомлення з мікрофону - 44100 ГЦ,
�� - довжина сигналу в часовій області в термінах кількості дискретних
точок даних, які він містить.
Таким чином ми отримаємо масив послідовностей числових значень
амплітуди і частоти, для кожного із частотних діапазонів сегментованих
сигналів, що будуть використані для подальшої класифікації.
2.1.4. Тип моделі-класифікатора нейромережі, топологія, структура
Опишемо детальніше нейронну мережу-класифікатор голосових
повідомлень. Для виконання поставленої задачі було обрано рекурентний тип
нейронної мережі (RNN), та шари Long Short-Term Memory (LSTM), на базі
використання моделі «Sequential» з Keras [45] та високорівневого API
TensorFlow [46]. Ця модель спеціально розроблена для обробки часових рядів
даних, необхідних для обробки звукових записів для ідентифікації голосу [47].
Вони призначені для вирішення проблеми зникання градієнтів, яка є типовою
для традиційних рекурентних мереж.
Топологія мережі (табл. 2.2) включає шар довгої короткострокової
пам’яті LSTM з 90-ю нейронами. Його було обрано за здатність
запам’ятовувати шаблони з часом, що має вирішальне значення для аналізу
особливостей звуку [48]. Цей шар приймає вхідні дані, що визначаються
часовими відрізками та характеристиками, де перші відповідають кількості
коротких часових міток звуку, а останні представляють амплітудні та фазові
характеристики звуку.
Після кожного шару LSTM накладається шар відсіву з коефіцієнтом 0.5.
Він допомагає запобігти надмірному пристосуванню, випадковим чином
встановлюючи частину вхідних одиниць на 0 при кожному оновленні під час
навчання [49]. Додано ще два шари LSTM, кожен з яких містить 50 нейронів.
Перший з цих LSTM-шарів зберігає послідовність для наступного LSTM-шару.
Останній LSTM-шар готує вихідні дані для останнього шару.
30
ЧДТУ.232219.024 ПЗ
В якості компілятора моделі було обрано оптимізатор адаптивної оцінки
моменту (adam) популярного для додатків глибокого навчання завдяки його
ефективності в роботі з розрідженими градієнтами та адаптивності [50]. Обрано
функція втрат (binary cross entropy), яка підходить для задач бінарної
класифікації [51]. Основною метрикою для оцінки моделі є точність, яка
забезпечує пряму інтерпретацію моделі в правильній класифікації голосів.
Характеристики, що подаються на вхід моделі, можуть бути представлені
комбінаціям амплітуду, амплітуди і фази, або лише фазу звуку, що вилучену із
звукового повідомлення. Така гнучкість дозволяє проводити комплексні
експерименти, щоб зрозуміти вплив різних характеристик звуку на точність
ідентифікації голосу [52].
Таблиця 2.2
Топологія нейромережі
№ Тип шару Значення основного Додаткові параметри
шару параметру
1 LSTM 90 return_sequences: true
2 Dropout 0.5 -
3 LSTM 50 return_sequences: true
4 Dropout 0.5 -
5 LSTM 50 return_sequences: false
6 Dropout 0.5 return_sequences: true
7 Dense 1 activation='sigmoid'
Додатково розглянемо структуру нейромережі, яка складається з:
вхідних даних у вигляді кількості частотних діапазонів і
послідовності ознак, для кожної з них;
шарів LSTM та Dropout, як описано вище;
вихідного шару Dense, який використовується для завершення
класифікації;
функції втрат (binary_crossentropy), оптимізатора (adam) та метрики
(accuracy), для відстеження точності класифікації для кожного класу;
31
ЧДТУ.232219.024 ПЗ
2.1.5. Функціональна та структурна схеми
Функціональна схема відображує процес створення моделі нейронної
мережі класифікатора (рисунок 2.1). Наступним кроком опишемо її.
Процес починається з отримання звукових повідомлень, які є вхідними
даними для системи. Отримані звукові повідомлення сегментуються на частини
фіксованої довжини, що дозволяє стандартизувати подальшу обробку даних.
Кожен сегмент звукового повідомлення перетворюється в числові значення.
Цей процес може включати аналіз частотних характеристик за допомогою
швидкого перетворення або інших методів аналізу сигналів. Після
перетворення сигналів відбувається фільтрація частот, яка зосереджує увагу на
певному діапазоні частот, що є найбільш інформативним для завдання
класифікації. Отримані числові дані після фільтрації використовуються для
тренування машинної моделі. У цьому етапі модель навчається розрізняти між
різними категоріями звукових повідомлень. Після тренування модель
проходить етап тестування та валідації, де нові, раніше не бачені звукові дані
використовуються для оцінки точності класифікації.
Рисунок 2.1 – Функціональна схема створення моделі
32
ЧДТУ.232219.024 ПЗ
На рисунку 2.2 представлена структурна схема процесу тренування
моделі машинного навчання для класифікації звукових повідомлень. Опис
схеми відповідно до компонентів представлено нижче.
Рисунок 2.2 - Структурна схема створення моделі
Звукові повідомлення представляють собою початковий набір звукових
даних, який використовується як вхід для системи. Використовуючи бібліотеку
pydub для розділення звукових повідомлень на менші частини для подальшої
обробки. Наступним кроком відбувається збереження сегментованих звукових
даних у локальному файловому сховищі. Застосовуючи швидке перетворення
Фур'є (FFT) з бібліотеки numpy відбувається перетворення раніше
33
ЧДТУ.232219.024 ПЗ
сегментованих звукових повідомлень [53] у характеристики частоти та
амплітуди. Використовуючи функціонал Scikit-learn розділяємо набір даних на
тренувальні та тестові набори [54]. Використовуючи tensorflow keras будуємо
та компілюємо модель нейронної мережі. Наступним кроком тренуємо та
валідуємо модель за допомогою функції fit та evaluate, з фреймворку tensorflow.
Завершальним кроком зберігаємо кінцеву модель в форматі saved model [55].
Кожен крок на схемі представлений у вигляді блоку, який вказує на певну
операцію чи використання певного інструменту. Стрілки показують напрямок
потоку даних і послідовність процесів, що слідують один за одним [56]. Схема
ілюструє структуру робочого процесу від отримання сирих звукових даних до
збереження готової до використання моделі.
2.1.6. Характеристики якості моделей
Визначимо характеристики якості моделей для звукових повідомлень, де
кожне повідомлення розділено на сегменти тривалістю однакової тривалості,
кожен сегмент можем мітку чужий або свій, і рішення про класифікацію всього
повідомлення залежить від певного відсотка сегментів, що визначаються як
свій. Перед початком визначення характеристик слід визначити механізм
розрахунку порогового значення для класифікації сегменту повідомлення, як
свій. Для цього опишемо його за допомогою формули:
C �� + ��
Θ = + (2.10)
2 2
де:
Θ - фінальне порогове значення для класифікації,
�� - константа, яка в даному випадку дорівнює сумі ідеальних значень для
класів свій або чужий,
�� - нижня межа ймовірності, при якій сегмент відноситься до класу
чужий,
�� - верхня межа ймовірності, при якій сегмент все ще відноситься до
класу чужий.
34
ЧДТУ.232219.024 ПЗ
Цей підхід забезпечує простий і елегантний спосіб розрахунку
порогового значення, зберігаючи при цьому гнучкість для адаптації до різних
наборів даних і ситуацій класифікації [57].
Наступним кроком визначимо характеристики якості моделі, які будуть
актуальні для класифікації звукових повідомлень свій або чужий. Оскільки
наразі використовується два класи, актуальними будуть характеристики
представлені в таблиці 2.3.
Таблиця 2.3
Характеристики якості моделі
№ Характеристика (укр.) Характеристика (англ.)
1 Точність Accuracy
2 Істинно позитивний рівень True Positive Rate
3 Влучність Precision
Точність є однією з основних характеристик для оцінки загальної
ефективності моделі класифікації. Вона вимірює відсоток випадків, коли
модель правильно класифікує об'єкти (як свої, так і чужі) [58]. Описується
формулою:
���� + ����
�� = (2.11)
���� + ���� + ���� + ����
де:
���� - кількість випадків, коли модель правильно класифікувала
позитивний об'єкт,
���� - кількість випадків, коли модель правильно класифікувала
негативний об'єкт,
���� - кількість випадків, коли модель невірно класифікувала негативний
об'єкт як позитивний,
35
ЧДТУ.232219.024 ПЗ
���� - кількість випадків, коли модель невірно класифікувала позитивний
об'єкт як негативний.
Також дає змогу зрозуміти, яка частка прогнозів моделі була загалом
вірною. Чим вище значення точності, тим краще модель загалом впоралася з
класифікацією об'єктів на свій та чужий.
Наступною характеристикою є істинно позитивний рівень (TPR) є однією
із метрик в оцінці якості моделей, особливо для визначення здатності
правильно ідентифікувати позитивні випадки. Високе значення означає, що
модель ефективно виявляє позитивні випадки, зменшуючи кількість помилково
негативних результатів [59]. Описується формулою:
����
������ = (2.12)
���� + ����
де:
���� - кількість випадків, коли модель правильно класифікувала
позитивний об'єкт,
���� - кількість випадків, коли модель невірно класифікувала позитивний
об'єкт як негативний.
Останньою характеристикою є влучність, вона вимірює відсоток
правильно ідентифікованих позитивних випадків серед усіх випадків, які
модель класифікувала як позитивні [60]. Описується формулою:
����
�� = (2.13)
���� + ����
де:
���� - кількість випадків, коли модель правильно класифікувала
позитивний об'єкт,
���� - кількість випадків, коли модель невірно класифікувала негативний
об'єкт як позитивний.
36
ЧДТУ.232219.024 ПЗ
Висока точність означає, що серед усіх випадків, які модель визначила як
свій, більшість дійсно є своїми.
В процесі теоретичних досліджень прийшов до висновків, що для
класифікації звукових повідомлень які свій або чужий, важливим на мою
думку, є визначення інформативних ознак, які будуть використані для
подальшої класифікації та прогнозування за допомогою нейромережової
моделі. Наступним важливим етапом, в процес класифікації, є ідентичність
перетворення звукового повідомлення в числові значення амплітуди, фази та
частотного діапазону за допомогою швидкого перетворення Фур’є, як під час
навчання моделі, так і в процесі класифікації. Якщо процес перетворення не
буде ідентичним, це призведе до неконтрольованого та не коректного
прогнозування.
Не менш важливим є процес фільтрації частотного діапазону в процесі
навчання, в залежності від типу звукових повідомлень. Наприклад, для
голосових повідомлень, існує фіксований діапазон частот, на якому слід
сконцентруватися, в процесі фільтрація даних. Якщо дані не фільтрувати,
припускається, що модель буде не можливо навчити існуючим способами.
Архітектура нейромережі відграє не менш важливу роль, проте обмежена
застосуванням певних класів і підходів, які визначені для класифікації
послідовних даних звукових повідомлень.
Інтерпретація результатів класифікації є найскладнішим етапом і буде
залежати від кількості правильно класифікованих повідомлень свій або чужий.
Є ймовірність хибних класифікації, оскільки звукове повідомлення
розділяється на менші частини.
На мою думку, при виборі шляхом довжини сегментації звукового
повідомлення в діапазоні 0.5 – 2 секунди, інформаційних характеристик
амплітуди і фази, лише амплітуди або лише фази, за умов фільтрації в
залежності від типу звукового повідомлення, наприклад голосу, в діапазоні 16
– 349Гц, дасть точність прогнозування для кожного із сегментів вищу 80%.
Саме це і буде розглянуто в експериментальній частині.
37
ЧДТУ.232219.024 ПЗ
2.2. Експериментальні дослідження
2.2.1. Опис звукових повідомлень
Розглянемо звукові повідомлення, які було використано для
експериментальних досліджень. Було використано 9 звукових повідомлень, на
яких записано голос у вигляді тексту англійською мовою, які зачитані різними
авторами. Тривалість звукових повідомлень різна, від 7 до 37 секунд. В якості
джерела звукових повідомлень було використано публічні аудіо записи
зачитування тексту з ресурсу Sample Swap, з різною інтонацією та записи
тексту з мікрофону мобільного телефону [61]. Детальніше, по кожному із
звукових повідомлень, в таблиці 2.4.
Таблиця 2.4
Опис звукових повідомлень
Довжина
№ Короткий опис Мітка
(сек.)
1 37 Текст про жінок військових Чужий
2 47 Текст реклами взуття Чужий
3 12 Текст інтерв’ю про роботів Чужий
4 21 Текст інтерв’ю про складові частини роботів Чужий
5 7 Текст опису представлення співака і пісні Чужий
6 17 Текст виступу президента США Свій
7 10 Текст виступу президента США, друга частина Свій
8 19 Текст преамбули конституції США Свій
9 10 Текст преамбули конституції США, друга частина Свій
Детально по кожній із колонок. Перша колонка номер вказує на номер
звукового повідомлення по порядку. Стовпчик довжина вказує на тривалість
звукового повідомлення. Короткий опис вказує опис звукового повідомлення,
38
ЧДТУ.232219.024 ПЗ
це дозволяє розрізнити різноманітність звукових повідомлень. Мітка вказує на
клас, який може бути використано при тренуванні моделі.
2.2.2. Опис процесу декомпозиції повідомлення, обґрунтування
тривалості вікна
До етапу початку перетворення у числові значення, для кожного із
звукових повідомлень необхідно зробити декомпозицію, на менші сегменти. Це
дозволить збільшити точність класифікації та має спростити процес
класифікації за рахунок аугментації шляхом збільшення кількості даних і
послідовностей для класифікації свій або чужий [62].
Кожне із звукових повідомлень буде розділено використовуючи формулу
під номером 2.5, яка описана в теоретичній частині раніше, де кінець першого
сегменту являє собою початок наступного. Всі сегменти рівні між собою, окрім
можливо останнього, оскільки довжина звукового повідомлення не завжди дати
можливість декомпозувати на рівні звукові проміжки, якщо довжина
повідомлення не кратна довжині вікна.
Оскільки в якості звукових повідомлень було обрано голосові
повідомлення, не очікується висока частота змін, в результаті чого можливо
обрати довжину вікна довшого зразку в діапазоні 0.25 – 1 секунда.
Основними перевагами такого вибору є стабільність розпізнавання,
оскільки враховується більше контексту для ідентифікації унікальних
особливостей голосу. Також це дозволяє зменшити вплив шумів, ефектів
віддаленості або інших фонових звуків, оскільки враховується більше
інформації для визначення унікальних характеристик конкретного голосу [63].
2.2.3. Опис процесу побудови навчальних класів звукових повідомлень
Для побудови навчальних класів, згідно описаних раніше звукових
повідомлень в таблиці 2.4, після розділення кожного із звукових повідомлень,
перетворимо кожен і сегментів звукового повідомлення, за допомогою
швидкого перетворення Фур’є та розрахунку амплітуди та частоти, що описані
39
ЧДТУ.232219.024 ПЗ
в розділі теоретичних досліджень формулами 2.6, 2.7, 2.8, у числові значення
для кожного із діапазону частот.
Кожен сегмент звукового повідомлення відмітимо мітками 0 та 1,
відповідно до таблиці 2.4, де перше значення це чужий, а наступне значення це
свій. В результаті отримаємо два масиви значень, де перший стовпчик це
маркування Свій або Чужий, з другого і по останній, це значення амплітуди або
частоти відповідно для кожного із діапазону частот, з кроком 1ГЦ. В свою
чергу, кожен рядок значень буде відповідати сегменту аудіо повідомлення. Це
дасть змогу виконати навчання на основі кожного із звукових повідомлень,
послідовно подаючи значення на вхід моделі.
Таблиця 2.5
Опис формату для навчальних класів
Назва колонки Опис
Назва сегменту Назва звукового файлу та № сегменту по порядку, в
форматі: номер повідомлення, назва, номер сегменту
Мітка Сегменту, 0 або 1, де 0 – чужий, 1 - свій
№ діапазону Від 1 до останнього значення частоти звукового
повідомлення, що містить числове значення амплітуди або
частоти.
Не існує єдиного правила, щодо кількості повідомлень, достатніх для
стійкого результату навчання моделей. Це можливо визначити
експериментальним шляхом, поступово збільшуючи кількість даних,
аналізуючи покращення результатів моделі.
2.2.4. Опис тестового класу звукових повідомлень
Основною метою тестового класу є забезпечення достатньої
репрезентативності та різноманітності у звукових даних, щоб модель могла
ефективно вчитися та узагальнювати нові випадки. Необхідно врахувати
наступні моменти [64]:
40
ЧДТУ.232219.024 ПЗ
кількість зразків у кожній категорії має бути приблизно однаковою
для уникнення упередженості моделі, що дозволить створити баланс
між категоріями;
процес визначення кількості даних може включати серію
експериментів, під час яких аналізуються показники моделі при різній
кількості даних.
потрібно брати до уваги обмеження у вигляді обчислювальних
можливостей та часу, що доступний для обробки та аналізу даних, що
дозволить уникнути ресурсних обмежень.
використання достатньої кількості даних допомагає зменшити
помилки, пов'язані з переоснащенням або недостатнім узагальненням.
Зазвичай, для спрощення процесу оцінки корисності отриманої моделі,
використовують метод довільного тестування на 20% від вхідних даних. Таким
чином модель тренується на 80% від вхідних даних, а тестується на 20% даних,
що залишились. Даний варіант є найкращим, на мою думку, оскільки дозволяє
контролювати мінімальну кількість даних необхідних для навчання моделі
необхідних характеристик. Для реалізації такого розділення використаємо
функцію train_test_split, та експериментально перевіримо мінімальну кількість
даних, необхідну для тренування та тестування.
2.2.5. Опис процесу формування масиву вхідних даних із зазначенням
точок спостереження
Як раніше було зазначено, масив вхідних даних формується завдяки
сегментації звукових повідомлень на менші, однакові за довжиною частини, які
відфільтровуються за частотою 16 – 349 ГЦ, та перетворюються у числові
значення амплітуди та частоти для кожного із діапазону частот з однаковим
кроком.
Точками спостереження є кожні із сегментів, який класифікується як свій
або чужий із певною впевненістю. Якщо рівень впевненості для класифікації,
наприклад свій, вище ніж певне значення, наприклад 70%, для більшості із
41
ЧДТУ.232219.024 ПЗ
сегментів, таке повідомлення класифікується в загальному, як свій. Такий
варіант спостереження відмінно зарекомендує для звукових повідомлень, які
неможливо класифікувати як свій та чужий одночасно, наприклад запис двох
голосів, один із яких свій, а один – чужий.
2.2.6. Результати експериментів
В процесі досліджень було проведено декілька експериментів. Перший із
яких, це визначення розміру вікна сегментації звукового повідомлення. Було
обрано звукові повідомлення із записом голосу і зачитуванням англомовного
тексту, що представлені раніше в таблиці 2.4. Було проведено 3 експерименти,
з однаковою кількість звукових повідомлень, проте із різною довжиною вікна,
а саме 0.25, 0.5 та 1 секунди. Було використано частотну фільтрація діапазону
16-349 ГЦ, розмір частотного діапазону для перетворення в числові значення
рівний 1Гц, 20% масиву вхідних даних використано для тестування якості
моделі. Метою експерименту було обрати найкращу довжину вікна
спостерігаючи за процесом навчання та результатами тестування. Деталі
представлені у таблиці 2.6. За результатами експерименту було визначено, що
найкращий розмір вікна, для представлених звукових повідомлень, є вікно
довжиною 0.5 секунди.
Обрана довжина вікна дозволить знизити кількість епох тренування та
дає можливість отримати найкращу відносну кількість правильно
класифікованих об’єктів, при рівних істино позитивних рівнях.
Таблиця 2.6
Результати експерименту визначення розміру вікна
Довжина К-сть епох К-сть прав. Помилки першого Помилки
вікна (шт.) об. (%) роду (%) другого роду
(сек.) (%)
0.25 10 89 0 18
0.5 3 91 0 0
42
ЧДТУ.232219.024 ПЗ
Продовження таблиці 2.6
1 3 91 0 18
Наступним кроком було проведено експеримент із різною кількістю
звукових повідомлень для навчання та тестування моделі. Обрано дані, взявши
за основу звукові повідомлення описані раніше в таблиці 2.4. Кожен новий етап
експерименту – різне відношення даних навчання і тестування, починаючи із
рівнозначного. Результати представлені в таблиці 2.7.
Таблиця 2.7
Результати експерименту визначення кількості звукових повідомлень
Точок для Точок для К-сть прав. Помилки Помилки
навчання (%) тренування об. (%) першого роду другого роду
(%) (%) (%)
50 50 55 0 20
60 40 70 0 10
70 30 74 0 8
80 20 88 0 0
В результаті експерименту та отриманих даних, можна прийти до
висновку, що 80% даних тренування достатньо для отримання високої точності
прогнозування.
Останнім кроком було проведено експеримент із різними ознаками, при
використанні амплітудної і фазової характеристики, лише амплітудної, лише
фазової з урахуванням наступних параметрів:
розмір вікна сегментації 0.5 секунди;
звукові повідомлення із раніше визначених в таблиці 2.4;
дані тренування – 80%, дані навчання 20%;
фільтрування за частотою 16 – 349ГЦ;
43
ЧДТУ.232219.024 ПЗ
частотний крок при перетворенні 1ГЦ.
Результати експерименту представлені у таблиці 2.8.
Таблиця 2.8
Результати експерименту при використанні різних ознак, точок
Істино
Точність Влучність
Характеристики позитивний
(%) (%)
рівень (%)
Амплітуда 80 63 63
Амплітуда та
92 85 91
фаза
Фаза 44 41 41
Висновки до розділу
В процесі теоретичних і експериментальних досліджень було зроблено
висновок, що процес класифікації звукових повідомлень потребує
інформативних вхідних даних, відфільтрованих за частотою, сегментованих за
однаковою довжиною вікна та вільна від шумів та тиші.
На мою думку, гіпотеза, щодо фільтрації звукового повідомлення за
діапазоном частот, може мати покращення у вигляді автоматичного
фільтрування лише актуальної частоти, в залежності від типу повідомлення,
голос
Оскільки точність фактично ідентифікованих повідомлень, при
використанні лише амплітудної або лише фазової ознаки, нижча ніж при
використанні амплітудно-фазової ознаки, останню слід використовувати для
навчання, перевірки та прогнозування даних, що й буде використано на
практиці.
44
ЧДТУ.232219.024 ПЗ
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
3.1. Моделювання предметної області
Для визначення предметної області було зосереджено на ключових
аспектах, які впливають на аналіз аудіо повідомлень. А саме: запис аудіо
повідомлення за допомогою мікрофону пристрою, розбиття аудіо запису на
частини для аналізу, фільтрація аудіо сигналу за частотою, перетворення у
фазо-амплітудні характеристики, використання моделі нейромережі для
класифікації повідомлень, механізм інформування користувача про результати
аналізу та класифікації.
Наступним кроком в моделюванні буде визначення взаємодії між
компонентами. Першим компонентом в моделюванні буде процес запису аудіо
повідомлення за допомого мікрофону мобільного телефона. Важливим
аспектом в процесі запису буде зменшення кількості шумів, це буде досягнуто
за допомогою регулятора (Fader), що використовується для контролю рівня
сигналу мікрофону та уникнення додаткових шумів. Запис відбуватиметься в
буфер, з метою зменшення використання пам’яті та ресурсу процесору. Із
буферу буде збережено файл в тимчасову папку, для подальшої обробки та
використання.
Після процесу запису повідомлення, наступним кроком відбуватиметься
процес сегментації повідомлення на менші частини, однакові за довжиною,
окрім останнього. Після чого, за допомого швидкого перетворення Фур’є,
відбудеться процес перетворення кожного із повідомлень у числові ознаки
амплітуди та фази, для кожного із діапазону частот, рівному 1ГЦ. Додатково
застосовуватиметься фільтрація отриманих значень за частотним діапазоном,
важливим для певного типу повідомлення, для голосових повідомлень це
діапазон 16 – 349 ГЦ.
Останнім кроком відбувається класифікація сегменту повідомлення, як
свій або чужий, за допомогою заздалегідь навченої моделі. В якості вхідних
45
ЧДТУ.232219.024 ПЗ
даних кількість ознак та значення амплітуди і частоти, для кожного із сегментів.
На виході значення від 0 до 1, де значення наближене до 1 класифікує
повідомлення як свій, ближче до 0, як чужий.
3.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Сформуємо словник предметної області (табл. 3.1) та опишемо доменні
об’єкти, які будуть використані при створення моделі предметної області у
вигляді діаграми класів.
Таблиця 3.1
Словник предметної області
№ Назва (укр.) Назва (англ.) Опис
1 Інтерфейс User Interface Інтерфейс користувача, через який
користувача відбувається взаємодія з програмою.
2 Менеджер Permission Компонент, який управляє доступом до
доступів Manager мікрофону та запису
3 Записуючий Audio Інструмент для запису звуку.
пристрій Recorder
4 Аналізатор Sound Компонент, який аналізує звукові дані,
Analyzer отримані з мікрофона.
5 Модель Neural Модель нейронної мережі, яка
нейромережі Network Model використовується для класифікації
звуків.
6 Менеджер Notification Система управління повідомленнями,
інформування Manager яка інформує користувача про
результати аналізу звуків.
7 Налаштування Settings Налаштування програми, які
користувач може змінювати.
46
ЧДТУ.232219.024 ПЗ
Модель предметної області представляє структуру додатка для
класифікації звукових повідомлень. Інтерфейс користувача (User Interface) є
первинним входом для взаємодії з користувачем, який дозволяє доступ до
налаштувань (Settings) та управління дозволами (Permission Manager).
Управління дозволами необхідне для надання додатку доступу до мікрофону
через компонент аудіозапису (Audio Recorder).
Після отримання дозволу аудіозапису, записані звукові дані передаються
до аналізатора звуку (Sound Analyzer), який відповідає за первинний аналіз
аудіо та його підготовку до подальшої обробки. Аналізатор звуку може
включати етапи попередньої обробки, такі як фільтрація шуму, нормалізація
гучності та інші алгоритми обробки сигналу.
Після первинного аналізу звуку дані передаються до моделі нейронної
мережі (Neural Network Model), яка відповідає за класифікацію звуків. Цей
компонент використовує алгоритми машинного навчання для розпізнавання та
класифікації аудіо сигналів на основі заздалегідь навченої моделі.
Завершальним етапом є менеджер повідомлень (Notification Manager),
який інформує користувача про результати класифікації. Це може включати
надсилання сповіщень або інші методи повідомлення користувачів про статус
та результати аналізу звуків.
Таким чином, додаток інтегрується з системою дозволів операційної
системи, використовує спеціалізовані компоненти для обробки та аналізу аудіо
та взаємодіє з користувачем через систему повідомлень, що забезпечує зручний
інтерфейс для класифікації звукових повідомлень.
3.1.2. Елементи моделювання предметної області
Одним із етапів моделювання предметної області є визначення графічних
символів, що будуть використовуватись при побудові UML діаграм (табл. 3.2).
Таблиця 3.2
Графічні символи UML діаграм, що плануються до використання
47
ЧДТУ.232219.024 ПЗ
Графічний символ Назва елемента
Дійова особа (Actor)
Варіант використання (Use Case)
Коментар (Note)
Клас (Class)
Пакет (Package)
Об’єкт
Компонент (Component)
Головна програма (Main program)
Ресурс (Resource)
Наступним кроком опишемо єднальні елементи UML, що плануються до
використання, що зображені у таблиці 3.3.
48
ЧДТУ.232219.024 ПЗ
Таблиця 3.3
Єднальні елементи UML, що плануються до використання
Графічний символ Назва елемента
Односпрямована асоціація
(Unidirectional association)
Анотація до пункту (Ancor note
to item)
Посилання на об’єкт (Object
link)
Посилання на себе (Link to Self)
Пряме повідомлення (Link
message)
Зворотне повідомлення (Return
message)
3.1.3. Робоча область моделювання
В якості робочої області моделювання розглянемо мобільний додаток для
для запису та аналізу звукових повідомлень. Користувач запускає мобільний
додаток, який автоматично запускає запис звуків навколо. За необхідності
запитує дозвіл на автоматичний запис та використання мікрофону. Після запису
звуку, мобільний додаток перетворює звукове повідомлення в набір цифрових
даних, аналізує їх за допомогою раніше сформованої моделі нейронної мережі,
та надає класифікацію «свій» або «чужий». Результат повідомлення
відображається користувачу у вигляді інформаційного повідомлення.
Додаткового користувач може змінити налаштування, такі як доступ до
мікрофону і автоматичний запис звуку при запуску додатку.
3.2. Формування та аналіз вимог
49
ЧДТУ.232219.024 ПЗ
3.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
Для початку сформуємо первинні вимоги, це дасть можливість більш
детально описати інші типи вимог. Програмний агент пропонує функціонал,
заснований на використанні мікрофону пристрою для запису звуків. Після
інсталяції та запуску додатку, він запитує у користувача дозвіл на доступ до
мікрофону. Отримавши підтвердження доступу, додаток надає можливість
запускати запис звуку. Завершивши запис, додаток автоматично класифікує
звуки, визначаючи їх як свої або чужі. Додатково, користувач має можливість
отримати деталізовану інформацію про класифікацію кожного інтервалу
звукового запису. Додаток також надає можливість налаштування
автоматичного запису та зміну довжини запису.
Наступним кроком визначимо вимоги замовника. Програмний агент має
класифікувати звукове повідомлення, як свій або чужий, без доступу до
інтернету. Вимоги розробника більш розширені. Користувач має змогу
запустити додаток, та натиснути кнопку початку запису. Перед початком
запису має відбуватися запит на доступ до мікрофону. Якщо користувач
заборонить доступ, запис не має відбуватися, із відповідним інформаційним
повідомленням. Після надання доступу до мікрофону має розпочатися запис
звукового повідомлення. Користувач має мати змогу зупинити запис звукового
повідомлення на допомогою кнопки відміни. Після успішного запису,
користувач має мати змогу побачити результат загальної класифікації. При
натисканні кнопки деталей він має мати змогу побачити розгорнуту деталізації
класифікації за кожний інтервал класифікації.
Функціональні вимоги, починаємо з опису інтерфейсу користувача, який
має бути мінімалістичним. Після завантаження програми, в центрі головного
екрану має відображатися текст, що повідомляє про необхідність натиснути,
щоб розпочати. Після натискання, за умови наявності доступу до мікрофону,
має відбутися зміна стану кнопки (вона має бути прихована після натискання),
50
ЧДТУ.232219.024 ПЗ
та в центрі екрана з’явитися анімація аудіо амплітуди, яка має зображати зміну
амплітуди весь час запису аудіо. Зліва вгорі має з’явитися кнопка відміни, яка
доступна увесь час запиту і відображення анімації.
Після закінчення запису, в залежності від налаштувань, від 5 секунд, має
відобразитись екран результату класифікації з текстом, Свій або Чужий. Справа
вгорі, має відображатись кнопка деталей. При натисканні на кнопку деталей,
екран результату класифікації має приховатися, а новий екран з деталями
класифікації за часовими проміжками, з’явитися.
Новий екран з деталями має відображати початок відрізку в секунда, з
точністю до сотих секунди, відсоток впевненості у класифікації, маркування
Свій або Чужий, для даного відрізку. Справа вгорі має бути кнопка закриття
екрану деталей.
Опишемо не функціональні вимоги, для мобільного додатку класифікації
звукових повідомлень. Додаток має обробляти результати запису аудіо
повідомлення не більше ніж за 0.5 секунди. Запис аудіо повідомлення має
видалятись автоматично і не має бути доступним для інших додатків.
Класифікація має працювати без доступу до інтернету. Персональні дані
користувача не мають зберігатися чи аналізуватися будь-яким чином. Має бути
можливість використати будь-яку іншу модель. Має бути можливість
масштабувати на класифікацію декількома моделями одночасно.
3.2.2. Формування вимог за допомогою діаграм прецедентів
Одним із підходів, щодо формування діаграм прецедентів, є
декомпозиція діаграм за функціональним призначенням. Розділимо функціонал
програми на декілька ключових функцій, для кожної із якої створимо діаграму
прецедентів. Для проектування діаграм використаємо програмний комплекс
Rational Rose, який дає можливість спроектувати більшість необхідних діаграм,
групувати їх використовуючи пакети та автоматизувати процес розробки в
подальшому. Виділимо три окремих, проте пов’язаних між собою,
функціонали, а саме: отримання дозволів, процес запису та ідентифікація звуку.
Сформуємо діаграми та опис до них поетапно.
51
ЧДТУ.232219.024 ПЗ
Першим кроком сформуємо діаграму прецедентів отримання дозволів,
що зображена на рисунку 3.1, та додаємо пояснення до кожного із елементів
діаграми поетапно охоплюючи акторів та їх взаємодію із сценаріями
використання.
Рисунок 3.1 – Діаграма прецедентів отримання дозволів
Користувач (User) взаємодіє з:
відкриттям додатку (Open App) та ініціює процес використання
додатку;
запитом на дозвіл (Request Permission) та отримує запит від додатку
для надання дозволу на запис звуку;
наданням та відмовою дозволу (Grant / Deny Permission) та вирішує,
чи надати додатку дозвіл на запис звуку;
скасуванням та початком Запису (Cancel / Start Recording) та
контролює процес запису звуку;
52
ЧДТУ.232219.024 ПЗ
переходом до налаштувань програмного агента та контролює
переходи до налаштувань системи для зміни дозволів;
зміною дозволу у налаштуваннях (Change Permission in Settings) та
модифікує налаштування дозволів у системі;
конфігурацією налаштувань (Configure Settings) та налаштовує
параметри додатку.
система iOS (iOS System) бере участь у:
наданні/Відмові Дозволу (Grant/Deny Permission) та керує
процесом надання дозволів на рівні системи;
переході до налаштувань iOS (Navigate to iOS Settings) та зміні
дозволу у налаштуваннях (Change Permission in Settings) і дозволяє
користувачеві модифікувати налаштування дозволів.
Наступним кроком сформуємо діаграму прецедентів запису звукових
повідомлень (рис. 3.2) та пояснення кожного з елементів діаграми.
Система сповіщень (Notification System) зв'язана з автоматичним
початком запису (Auto Start Recording) та анімацією стану запису (Animate
Recording State) та інформує користувача про стан запису та ідентифікації
звуку. Записувач Звуку (Sound Recorder) відповідає за автоматичний початок
запису (Auto Start Recording) та скасування і початок запису (Cancel / Start
Recording) керує процесом запису звуку.
53
ЧДТУ.232219.024 ПЗ
Рисунок 3.2 - Діаграма прецедентів запису звукових повідомлень
Наступним кроком сформуємо діаграму прецедентів ідентифікації
звукових повідомлень (рис. 3.3) та пояснення кожного з елементів діаграми.
Нейромережева модель (Neural Network Model) та аналізатор даних (Data
Analyzer) є ключовими у ідентифікації звуку (Identify Sound), що аналізують
записаний звук і використовують моделі для ідентифікації. Система сповіщень
(Notification System) зв'язана з автоматичним початком запису (Auto Start
Recording) та анімацією стану запису (Animate Recording State) та інформує
користувача про стан запису та ідентифікації звуку.
Зауважимо, що з метою ізоляції діаграм було використано пакети
(Packages) в Rational Rose (рис. 3.4). Це в свою черго дозволило повторно
54
ЧДТУ.232219.024 ПЗ
використовувати певні елементи діаграми, наприклад актор користувача, та
гнучко поєднати їх між собою.
Рисунок 3.3 - Діаграма прецедентів ідентифікації звуку
В процесі розробки діаграм прецедентів зроблено висновок, що
використання пакетів, окремих акторів та детальних пояснень дозволить
55
ЧДТУ.232219.024 ПЗ
знизити час на написання автоматичних тестів та зменшити час на тестування
проекту, що зменшить використання бюджету на розробку.
Рисунок 3.4 - Структура пакетів діаграми прецедентів
56
ЧДТУ.232219.024 ПЗ
3.2.3. Проектування логічної структури програмного комплексу
3.2.3.1. Діаграма класів
Наступним кроком спроектуємо та опишемо діаграму класів, що
дозволить полегшити процес розробки і кодування в наступних етапах.
Сформуємо діаграму класів, що зображена у рисунку 3.5, та додаємо пояснення
до кожного компонента, зв’язку та прикладу використання.
Рисунок 3.5 - Діаграма класів
Основні компоненти діаграми класів:
User Interface - керує аспектами користувацького інтерфейсу, такими
як відображення анімацій, станів помилок та навігації до
налаштувань;
Permission Manager - контролює все, що пов'язано з дозволом на запис
аудіо, включаючи запит та перевірку стану цих дозволів;
57
ЧДТУ.232219.024 ПЗ
Audio Recorder: Відповідає за керування процесом запису аудіо. Це
включає початок, зупинку та скасування записів;
Sound Analyzer - приймає записані аудіо дані, аналізує їх та розділяє
на керовані сегменти для подальшої обробки;
Neural Network Model - інкапсулює модель нейромережі,
відповідальну за ідентифікацію звуків з оброблених аудіо даних;
Settings - управління налаштуваннями користувача, такими як
тривалість запису та чутливість;
Notification Manager - відповідає за керування повідомленнями
користувачу, включаючи успіх або невдачу ідентифікації звуку.
Зв’язки між класами та основні дії:
User Interface з'єднується з Permission Manager для перевірки та запиту
дозволів;
User Interface ініціює Audio Recorder для початку або зупинки запису
в залежності від дій користувача та статусу дозволів;
Audio Recorder передає записані дані до Sound Analyzer для розбивки
звуку на аналізовані сегменти;
Sound Analyzer попередньо обробляє аудіо та потім взаємодіє з Neural
Network Model для ідентифікації звуку;
Neural Network Model повертає результати ідентифікації, які потім
сповіщають користувача через Notification Manager;
User Interface також дає доступ до Settings, де користувачі можуть
налаштовувати параметри застосунку.
Приклади використання:
User Interface запитує дозвіл на запис через Permission Manager;
після надання дозволу, Audio Recorder починає запис;
записані дані передаються в Sound Analyzer для сегментації та
аналізу;
58
ЧДТУ.232219.024 ПЗ
вихідні дані Sound Analyzer подаються в Neural Network Model для
розпізнавання звуку;
результати від Neural Network Model використовуються для
повідомлення користувача про результат через Notification Manager;
Settings дозволяє регулювати процес запису.
Слід зауважити, що використання діаграми класів дозволяє чітко
представити взаємодії та залежності класів, спрощуючи процес розробки та
допомагаючи уникнути можливих непорозумінь в процесі. Проте, діаграма
класів, скоріш за все, може мати зміни після початку процесу реалізації
програмного коду. Вважаємо, що це процес, який не можливо пропустити,
проте можливо зменшити, у випадку більш детального проектування.
3.2.3.2. Діаграма пакетів
Наступним кроком представимо діаграму пакетів на рисунку 3.6.
Рисунок 3.6 – Діаграма пакетів
Діаграма включає чотири пакети, які з’єднані спрямованими асоціаціями,
що вказують на їхні взаємозв'язки та взаємодію:
59
ЧДТУ.232219.024 ПЗ
Classification, це пакет, що містить логіку для класифікації звукових
повідомлень як свій або чужий за ознаками амплітуди, фази та діапазону
частот;
User Interface, це пакет, що відповідає за компоненти графічного
користувацького інтерфейсу, які дозволяють користувачеві взаємодіяти з
додатком. Він має двосторонню асоціацію з пакетом класифікації,
оскільки він як надсилає дані до пакету Класифікації, так і отримує
результати класифікації;
Permissions, це пакет, що взаємодіє із пакетом користувацького
інтерфейсу і управляє доступом до ресурсів пристрою, наприклад,
запитує в користувача дозвіл на використання мікрофона для запису
повідомлень;
Recording, це пакет, що займається фіксацією звукових повідомлень, які
потім направляються для їх аналізу в пакет класифікації.
3.2.4. Архітектурне проектування
3.2.4.1. Діаграма компонентів
Одним із етапів процесу проектування, є формування діаграми
компонентів. Сформуємо діаграму (рис. 3.7) та її опис.
Основні елементів діаграми компонентів:
компонент: User Interface (Користувацький Інтерфейс);
swift-файл: UserInterface.swift;
вивід: взаємодіє безпосередньо з користувачем;
опис: Управління всіма взаємодіями з користувачем та
оновленнями інтерфейсу.
компонент: PermissionManager (менеджер дозволів);
swift-файл: PermissionManager.swift;
вивід: статус дозволу для AudioRecorder;
опис: керує запитами на дозвіл та статусом для доступу до
мікрофона.
60
ЧДТУ.232219.024 ПЗ
компонент: AudioRecorder (аудіо записувач);
swift-файл: AudioRecorder.swift;
вивід: файл sound.wav;
опис: запис та управління сеансами аудіозапису.
компонент: SoundAnalyzer (Аналізатор Звуків);
swift-файл: SoundAnalyzer.swift;
вивід: архів sounds.zip;
опис: аналізує записаний звук та підготовує дані для нейронної
мережі.
компонент: NeuralNetworkModel (Модель Нейронної Мережі);
swift-файл: NeuralNetworkModel.swift;
вивід: файл моделі model.tflite та результати results.csv;
опис: охоплює логіку ідентифікації звуку машинного навчання.
компонент: Settings (Налаштування);
swift-файл: Settings.swift;
вивід: конфігураційні дані для інших компонентів;
опис: зберігає та витягує налаштування користувача та
конфігураційні параметри.
компонент: NotificationManager (Менеджер Сповіщень);
swift-файл: NotificationManager.swift
вивід: візуальні та звукові сповіщення для UserInterface
опис: керує відображенням повідомлень та сповіщень
користувачу.
Залежності та Зв’язки:
UserInterface спілкується з PermissionManager для отримання статусу
дозволу і з NotificationManager для показу сповіщень;
PermissionManager взаємодіє з AudioRecorder для запуску запису,
коли отримано дозвіл;
61
ЧДТУ.232219.024 ПЗ
AudioRecorder генерує файл sound.wav та передає його до
SoundAnalyzer;
SoundAnalyzer обробляє звук і створює архів sounds.zip, який
використовується NeuralNetworkModel;
NeuralNetworkModel обробляє дані звуку та генерує файл моделі
model.tflite та результати.
Рисунок 3.7 - Діаграма компонентів
62
ЧДТУ.232219.024 ПЗ
Вважаємо, що діаграма компонентів допоможе оцінити час, який
подальшому буде витрачено на кодування програми. Також, діаграма буде
корисною в якості документації, оскільки відображає зв’язки та залежності між
компонентами.
Також, діаграму можна використовувати для опису модулів, яку будуть
не залежними один від одного, проте зможуть використовувати необхідні
методи для роботи.
Проте, слід зауважити, що ймовірність змін в діаграмі дуже висока на
етапі розробці, особливо за умови великої ймовірності зміни початкових умов,
або застосування гнучкого підходу до розробки програм.
3.2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Одним із важливих кроків, для мобільних додатків, це визначення
діаграми розгортання. Сформуємо діаграму (рисунок 3.8) та опишемо основні
компоненти та їх взаємодію.
Опис елементів:
GitHub - це платформа для управління версіями коду, де зберігається
вихідний код додатку. Він використовується для співпраці,
відстеження змін та ревізії коду;
GitHub Actions - це інструмент CI/CD, який інтегрований з GitHub. Він
автоматизує робочі процеси для тестування, збірки та розгортання
коду, коли відбуваються зміни у репозиторії;
Fastlane - це набір інструментів для автоматизації багатьох аспектів
розробки мобільних додатків, включаючи збірку, тестування і
розгортання додатків на платформах бета-тестування та виробництва;
Firebase - це платформа від Google для розробки мобільних та веб-
додатків. Вона може використовуватися для бета-тестування,
надаючи інструменти для відстеження збоїв, аналітики та інших;
63
ЧДТУ.232219.024 ПЗ
Appstore Connect - це інтерфейс Apple для розробників, де вони
можуть розгортати свої додатки для продажу в App Store. Тут
завантажується фінальна версію додатку, налаштовуємо метадані та
можемо відслідковувати доступність додатку для завантаження.
Рисунок 3.8 - Діаграм розгортання
Опис з’єднань:
від GitHub до GitHub Actions іде з’єднання, яке показує, що при
певних тригера, наприклад створення нової гілки для релізу, GitHub
Actions запускає процеси CI/CD;
GitHub Actions пов’язаний з Fastlane, що символізує автоматизацію
процесів збірки та розгортання після успішного виконання робочих
процесів GitHub Actions;
із Fastlane розходяться два шляхи: один веде до Firebase, що означає
можливість розгортання бета-версій для тестування, інший – до
64
ЧДТУ.232219.024 ПЗ
Appstore Connect, що вказує на розгортання виробничої версії додатку
для релізу в AppStore;
Слід зауважити, що процес автоматизації може змінюватись в залежності
від змін в програмному продукті, кількості розробників, та необхідності
частоти релізів (release train).
3.2.5. Моделювання поведінки системи
3.2.5.1. Діаграма діяльності
Наступним етапом процесу проектування, є формування діаграми
діяльності. Сформуємо діаграму (рисунок 3.9) та її опис.
Опис елементів діаграми діяльності користувача та запису звуку:
відображення головного екрану (Display Home Screen) – це початкова
активність, де користувач бачить головний інтерфейс додатку після
його запуску;
запит дозволу на запис (Request Permission for Recording) – це
діалогове вікно запиту дозволу на доступ до мікрофону
відображається для користувача;
дозвіл отримано (Permission Granted) - користувач надає додатку
дозвіл на запис звуку, і система переходить в стан "Дозвіл отримано";
рішення (Decision) - береться рішення засноване на виборі
користувача.
При варіанті "ТАК":
анімація отримання дозволу (Animate Permission Granted) - показ
анімації, що підтверджує надання дозволу користувачем;
дозвіл дозволений (Permission Allowed) - система визнає, що дозвіл
надано і переходить до запису звуку;
показ анімації запису (Show Recording Animation). Одночасно з
початком запису, на екрані відображається анімація, яка сигналізує
про процес запису;
початок запису звуку (Start Recording Sound). Система розпочинає
процес запису звуку;
65
ЧДТУ.232219.024 ПЗ
злиття (Join) – це об'єднання паралельних процесів запису звуку та
відображення анімації.
Рисунок 3.9 - Діаграм діяльності користувача та запису звуку
запис успішний (Recording Successful). Стан, що вказує на успішне
завершення запису звуку;
показ успішної анімації (Display Successful Animation) - якщо запис
було успішно здійснено, на екрані з'являється анімація успіху;
показ повідомлення про невдачу та опції повторного спроби (Display
Failure Message and Retry Options). У випадку невдачі, користувачеві
показується повідомлення з можливістю повторної спроби.
При варіанті "НІ":
66
ЧДТУ.232219.024 ПЗ
показ помилки відсутності дозволу (Display Permissions Denied Error).
Відображається повідомлення про помилку, яке інформує
користувача, що для роботи додатку необхідний дозвіл на запис.
дозвіл відхилений (Permission Denied). Система визнає, що дозвіл
користувачем не надано і завершується спроба запису звукового
повідомлення.
Вважаємо, що діаграма діяльності буде особливо важливою в процесі
реалізації слоїв візуального представлення та поєднання логіки мобільного
додатку, оскільки дозволяє зрозуміти, що стани, інтерфейс користувача і логіка
тісно пов’язані.
Також, дозволяє зрозуміти складність конкретного модулю, та допомогти
розділити задачу реалізації на більш прості частини, оскільки модуль буде на
пряму залежати від діаграм.
Додатково діаграми спростять процес тестування, оскільки одразу видно
всі можливі стани та активності.
3.2.5.2. Діаграма послідовності
Наступним кроком спроектуємо та опишемо діаграму послідовності (рис.
3.10) та її опис. Сфокусуємось на етапі початку запису та отриманні доступів.
Опис об'єктів:
Користувач (User): Актор, який взаємодіє з системою;
Інтерфейс Додатку (App Interface): Керує введенням користувача та
відповідями додатку;
Менеджер Дозволів (Permission Manager): Обробляє запити на
дозволи та їх стани;
Системні Налаштування (System Settings): Представляє інтерфейс
системних налаштувань програмного агента iOS;
Послідовність взаємодії:
користувач надсилає повідомлення (openApp) до інтерфейсу додатку;
інтерфейс додатку надсилає повідомлення (requestPermission) до
менеджера дозволів;
67
ЧДТУ.232219.024 ПЗ
Рисунок 3.10 - Діаграма послідовності користувача та запису звуку
менеджер дозволів надсилає повідомлення (displayRequestUI) до
користувача, запитуючи дозвіл;
користувач відповідає повідомленням (grantPermission) або
(denyPermission) назад до менеджера дозволів;
якщо дозвіл надано, менеджер дозволів надсилає повідомлення
(startRecording) до інтерфейсу додатку, яке ініціює запис;
якщо дозвіл відхилено, менеджер дозволів надсилає повідомлення
(displayErrorState) до інтерфейсу додатку, а також повідомлення
68
ЧДТУ.232219.024 ПЗ
(navigateToSettings) до користувача, направляючи його до системних
налаштувань.
Наступним кроком спроектуємо та опишемо діаграму послідовності
запис, аналізу та ідентифікації повідомлень (рис. 3.11).
Рисунок 3.11 - Діаграм послідовності запису, аналізу та ідентифікації
повідомлень
Опис об'єктів:
Інтерфейс додатку (App Interface): Представляє користувацький
інтерфейс, що забезпечує навігацію та інформаційний обмін з
користувачем;
Рекордер (Recorder): Клас, відповідальний за запис звуку з мікрофону
пристрою;
69
ЧДТУ.232219.024 ПЗ
Аналізатор звуків (Sound Analyzer): Клас, що виконує обробку
записаних звукових даних і їх аналіз з використанням нейронної
мережі.
Послідовність взаємодії:
користувач натискає кнопку для початку запису, що ініціює
повідомлення (startRecording) до рекордера;
рекордер починає запис звуку і відправляє поточний статус
(recordingStarted) назад до інтерфейсу додатку;
інтерфейс додатку відображає анімацію процесу запису;
після закінчення встановленого часу запису, рекордер відправляє
звукові дані (audioData) до аналізатора звуків через повідомлення
(analyzeAudio);
аналізатор звуків обробляє звукові дані, розбиваючи їх на сегменти і
застосовуючи алгоритми для визначення амплітуди та фази;
отримані дані відправляються в модель нейронної мережі через
повідомлення (runNeuralNetworkModel);
модель класифікує звуки на свій та чужий і відправляє результат
(identificationResult) назад до аналізатора звуків;
аналізатор звуків передає результати аналізу до інтерфейсу додатку
через повідомлення (displayResult);
інтерфейс додатку відображає користувачу результати ідентифікації,
надаючи візуальну відповідь або вказівки на подальші дії.
На мою думку діаграм діяльності дозволяє зрозуміти життєвий цикл
кожного з об’єктів та є особливо корисною на етапі створення об’єктів та
оптимізації роботи з пам’яттю. Це можна досягається, шляхом створення
об’єктів тільки в момент їх необхідності використання (lazy loading).
Також, діаграми діяльності розділяються на менші, за функціоналом та
зв’язками об’єктів, що дозволяє спростити реалізацію в коді, ізолювати класи в
модулі, та знизити кількість помилок при кодуванні. В свою чергу діаграми
70
ЧДТУ.232219.024 ПЗ
будуть одночасно пов’язані, але ізольовані. Це спрошує процес написання
автоматизованих тестів для класів та інтеграційних тестів для модулів.
3.2.5.3. Діаграма комунікації
Зображена на рисунку 3.12. Опис складається з декількох частин та
представлений з опису об’єктів та їх взаємодій.
Об'єкти:
`userInterface: UserInterface` - користувацький інтерфейс, через який
користувач взаємодіє з додатком;
`permissionManager: PermissionManager` - управління дозволами,
котре контролює доступ до мікрофону;
`audioRecorder: AudioRecorder` - запис звуку, відповідає за захоплення
аудіо даних;
`soundAnalyzer: SoundAnalyzer` - аналіз звуку, проводить обробку та
аналіз аудіо;
`neuralNetworkModel: NeuralNetworkModel` - нейронна мережа, яка
використовується для ідентифікації звуку;
`settings: Settings` - налаштування, зберігає конфігураційні параметри
для аналізу;
`notificationManager: NotificationManager` - управління сповіщеннями,
виводить повідомлення користувачу.
Взаємодія при запуску додатку:
`userInterface` надсилає повідомлення `requestPermission` до
`permissionManager`;
`permissionManager` відповідає повідомленням `verifyPermission`
назад до `userInterface`;
в залежності від результату:
якщо дозвіл надано, `userInterface` надсилає повідомлення
`startRecording` до `audioRecorder`;
71
ЧДТУ.232219.024 ПЗ
якщо дозвіл відхилено, `userInterface` відображає помилку за
допомогою повідомлення `showError` до `notificationManager`.
Рисунок 3.12 – Діаграма комунікації
Взаємодія під час запису:
72
ЧДТУ.232219.024 ПЗ
`audioRecorder` починає запис і відсилає токен даних `updateStatus` до
`userInterface`;
після завершення запису, `audioRecorder` відсилає токен даних
`sendAudioData` до `soundAnalyzer`.
Взаємодія під час аналізу:
`soundAnalyzer` отримує аудіо дані та проводить аналіз, відсилаючи
повідомлення `analyzeSound` собі;
`soundAnalyzer` потім надсилає повідомлення `getSettings` до
`settings` для отримання параметрів аналізу;
після аналізу, ̀ soundAnalyzer` підготовлює дані і відсилає токен даних
`inputData` до `neuralNetworkModel`.
Взаємодія з моделюю:
`neuralNetworkModel` обробляє отримані дані за допомогою
повідомлення `processData` і визначає результат, відсилаючи токен
даних `result` назад до `soundAnalyzer`;
`soundAnalyzer` відсилає повідомлення `displayResult` до
`userInterface` для відображення результату користувачу;
`userInterface` використовує повідомлення `notifyUser` до
`notificationManager` для повідомлення користувача про результат за
допомогою анімації або повідомлення.
3.2.5.4. Діаграма скінченого автомату
Одним із етапів проектування є створення діаграми скінченого автомату
(діаграма станів). Оскільки складність діаграми напряму залежить від кількості
класів та складності системи, важливим кроком є розділення діаграми на
складові частини. А саме, діаграма станів користувацького інтерфейсу (User
Interface), менеджеру доступів та звукового аналізатора. Спроектуємо діаграму
(рисунок 3.13) та опишемо першу частину.
Стани:
ініціалізовано (Initialized), стан представляє момент запуску додатку,
73
ЧДТУ.232219.024 ПЗ
коли користувацький інтерфейс готовий до взаємодії з користувачем;
очікування дозволу (WaitingForPermission) - інтерфейс знаходиться в
режимі очікування відповіді користувача на запит дозволу на запис
звуку;
стан помилки (ErrorState) - активується, якщо користувач відмовляє у
наданні дозволу на запис. Відображається інформація про помилку з
можливістю переходу в налаштування для зміни дозволів;
Рисунок 3.13 - Діаграм станів інтерфейсу користувача
інтерфейс запису (RecordingUI) - видимий під час процесу запису
звуку;
інтерфейс ідентифікації (IdentifyingUI) - інтерфейс, що
відображається під час процесу ідентифікації звуку;
74
ЧДТУ.232219.024 ПЗ
інтерфейс результату (ResultUI) - показує результат ідентифікації
звуку — успішно впізнано чи ні.
Переходи:
із стану ініціалізовано до очікування дозволу - цей перехід
відбувається автоматично після запуску застосунку;
із очікування дозволу до інтерфейсу запису - активізується, коли
користувач надає дозвіл на запис;
із очікування дозволу до стану помилки - якщо користувач відмовляє
в наданні дозволу;
із інтерфейсу запису до інтерфейсу ідентифікації - цей перехід
відбувається, коли завершується процес запису;
із інтерфейсу ідентифікації до інтерфейсу результату - по завершенню
процесу ідентифікації звуку.
Наступним кроком спроектуємо діаграму станів менеджера доступів
(рисунок 3.14). Він відіграє ключову роль у управлінні дозволами на запис
звуку в додатку та забезпечує коректне переведення між станами, базуючись на
діях користувача, і гарантує, що процес запису звуку може бути ініційований
лише після отримання відповідного дозволу. Ця логіка дозволяє не тільки
дотримуватися політики конфіденційності та безпеки, але й забезпечує
користувачам контроль над їхніми даними та приватністю.
Стани:
бездіяльність (Idle), початковий стан до будь-якої активності, коли
дозволи ще не запитувались;
запит дозволу (RequestingPermission), стан, в якому клас запитує у
користувача дозвіл на запис звуку;
дозвіл отримано (PermissionGranted), стан, що вказує на те, що
користувач надав дозвіл на запис звуку;
дозвіл відмовлено (PermissionDenied), стан, що вказує на відмову
користувача у наданні дозволу на запис звуку.
Переходи:
75
ЧДТУ.232219.024 ПЗ
від бездіяльності до запиту дозволу: ініціюється при першому запуску
додатку або коли користувач намагається відновити дозвіл на запис
звуку;
від запиту дозволу до отримання дозволу: відбувається, коли
користувач надає дозвіл на запис;
від запиту дозволу до в дозволі відмовлено: активізується, коли
користувач відмовляє у наданні дозволу.
Рисунок 3.14 - Діаграм станів менеджера доступів
76
ЧДТУ.232219.024 ПЗ
Останнім кроком спроектуємо (рисунок 3.15) та опишемо діаграму станів
для класу аналізу звукових повідомлень (SoundAnalyzer).
Стани:
очікування (Waiting) - початковий стан, в якому клас чекає на
отримання даних звуку для аналізу;
аналіз звуку (AnalyzingSound) - стан, в якому клас аналізує отримані
дані звуку;
вдало проаналізовано (AnalysisSuccessful) - стан, який сигналізує про
успішне визначення і ідентифікацію звукових даних;
помилка аналізу (AnalysisFailed): Стан, який вказує на невдачу у
процесі аналізу звуку.
Переходи:
із очікування до аналізу звуку - цей перехід відбувається, коли клас
отримує дані звуку для аналізу;
із аналізу звуку до вдало аналізовано - активізується, коли аналіз
звуку успішно завершено та ідентифіковані ключові характеристики;
із аналізу звуку до помилки аналізу - відбувається у випадку, коли не
вдається коректно проаналізувати звук або відсутній позитивний
результат ідентифікації.
Висновки до розділу
В процесі проектування, моделювання архітектури та моделювання
поведінки системи прийшов до висновків, що процес проектування
програмного забезпечення це складний процес, який на мою думку потребує
значної уваги від розробника, проте в довгостроковій перспективі дозволяє
зменшити час на розробку програмного забезпечення, зменшенні кількості
багів та можливість подальшого розширення.
Слід зауважити, що деякі із діаграм, на етапі розробки, можуть
змінюватись, оскільки не можливо спроектувати програмне забезпечення, без
77
ЧДТУ.232219.024 ПЗ
подальшого покращення та змін, оскільки популярним є Agile підхід, що
дозволяє розширювати продукт і швидко додавати та змінювати функціонал.
78
ЧДТУ.232219.024 ПЗ
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
4.1.1 Розробка програмного комплексу
4.1.1.1 Обґрунтування вибору засобів реалізації
Виходячи із поставленої задачі розробки програмного забезпечення
програмнго агента класифікації звукового повідомлення, як свій або чужий, на
платформі IOS виберемо засоби реалізації:
середовище розробки;
мову програмування;
набір засобів для розробки;
базу даних.
Також окреслимо параметри оптимізації процесу розробки, які на мою
думку можуть бути використані, для прийняття рішення щодо засобів
реалізації, а саме:
часові (кількість часу на реалізацію);
функціональні (наявність необхідного функціоналу);
додаткові (популярність, стабільність, ризикованість).
Першим кроком, який буде впливати на наступні, буде визначення мови
програмування. Оскільки чітко визначено, що платформа програмного засобу
має бути IOS та вважаючи на закритість платформи для сторонніх розробників
зі сторони виробника Apple [65], оптимальним буде вибір серед двох мов
програмування:
Objective-C;
Swift.
Серед переваг останньої є швидкість розробки, нижча кількість багів,
ідентичний функціонал в порівнянні з першою, популярність серед
розробників, рекомендації виробника Apple, щодо використання. Також, слід
зауважити на складність підтримки програмних продуктів та знаходження
79
ЧДТУ.232219.024 ПЗ
інших розробників для мови програмування Objective-C [66]. Тому було обрано
мову програмування Swift.
Другим кроком виберемо середовище розробки. Єдиним доступним
варіантом, для платформи IOS та мови програмування Swift є Xcode. Це
зумовлено особливостями розробки від виробника Apple та відсутності
інтеграції іншими середовищами, такими як VSCode [67].
Третім кроком визначимо набір засобів для розробки. Головні функції,
які необхідні:
запис, обробка і збереження аудіо за допомогою мікрофона;
класифікація аудіо повідомлень за допомогою готової моделі
нейронної мережі;
відображення та робота з інтерфейсом користувача.
Враховуючи деталі роботи IOS платформи, існує два набори інструментів
для роботи зі звуком. Перший – це Core Audio, який дозволяє запис, обробку,
управління доступом до мікрофону. Другий – Audio Kit, що представляє собою
обгортку над першим інструментом, у більш зручний та простий спосіб.
Основною перевагою другого набору інструментів, є простота використання,
більша кількість прикладів, та вже реалізована обробка негативних сценаріїв,
без додаткових витрат часу [68]. Враховуючи це, було обрано останній, тобто
Audio Kit.
Для класифікації аудіо повідомлень за допомогою готової моделі
нейронної мережі, існує два основних варіанти, це використання Tensor Flow
lite моделі, та Core ML моделі. В більшості характеристик, такі як час на
інтеграцію та реалізацію, час роботи, моделі ідентичні. Ключовою відмінністю
є пріорітарність, розмір, зручність інтеграції, швидкість роботи останньої та
можливість до навчання, що є ключовим для програмного засобу [69].
З точки зору відображення та роботи з інтерфейсом користувача, існує
два основних програмних засоби, це UI Kit та Swift UI. Ключова перевага
останнього, це можливість більш швидкої реалізації інтерфейсу користувача за
рахунок декларативного методу, що дозволяє уникати опису потоку контролю
80
ЧДТУ.232219.024 ПЗ
і концентруватися на тому, що необхідно зробити, а не як саме це зробити.
Такий підхід дозволяє значно знизити час на розробку інтерфейсу користувача
[70].
Четвертим і останнім кроком аргументуємо вибір бази даних. Існує два
ключових варіанти вибору при використанні платформи IOS, це Core Data та
Swift Data. Перший побудований на базі реляційної бази даних SQL Lite, другий
є обгорткою над першим, з використанням мета програмування та генерації
коду. Перевагою останнього є менша кількість коду необхідна розробнику для
реалізації і опису бази даних та ключових об’єктів, та швидкість реалізації
простих взаємодій [71]. Тому було обрано Swift Data.
Для зручності представимо таблицю 4.1 обраних варіантів та їх ключові
переваги.
Таблиця 4.1
Обрані засоби реалізації
Тип засобу Назва Параметри оптимізації
Середовище
Xcode Часові, функціональні
розробки
Мова програмування Swift Часові, функціональні
Запис, обробка та
Audio Kit Часові
збереження аудіо
Класифікація аудіо
Core ML Додаткові
повідомлень
Інтерфейс
Swift UI Часові, функціональні
користувача
База даних Swift Data Часові
4.1.1.2 Опис структурної (функціональної) схеми
Функціональна схема (рисунок 4.1) відображує процес класифікації
звукового повідомлення. Запис звуку починається з активації мікрофона для
81
ЧДТУ.232219.024 ПЗ
запису звукового сигналу. Записаний звуковий сигнал розбивається на
сегменти заданої довжини. Це може бути реалізовано за допомогою алгоритмів
сегментації, які можуть визначати кордони на основі тиші або зміни звукових
характеристик [72]. Кожен сегмент звуку перетворюється в числові значення,
які можуть бути амплітудами, фазами чи іншими характеристиками,
отриманими через Фур’є-перетворення або інші методи аналізу сигналів.
Нейромережева модель, яка була попередньо тренована, завантажується в
додаток з локального сховища пристрою. Завантажена модель використовує
числові дані для прогнозування, класифікуючи звуковий сегмент як свій або
чужий. Процес включає подачу даних на вхід моделі та отримання відповіді.
Результати класифікації представляються користувачу через графічний
інтерфейс. Виведення включає в себе текстове повідомлення та деталізацію
класифікації по сегментам.
Рисунок 4.1 - Функціональна схема класифікації
На рисунку 4.2 відображено структурну схему для класифікації звукових
повідомлень.
82
ЧДТУ.232219.024 ПЗ
Рисунок 4.2 - Структурна схема класифікації
Схема починається з запису звуку через мікрофон, використовуючи
можливості фреймворків AVFoundation та AudioKit, що дозволяє захопити
аудіо дані. Захоплені звукові повідомлення потім сегментуються з
використанням Core Audio, щоб підготувати дані для аналізу. Після сегментації
відбувається перетворення аудіо сегментів у числові значення за допомогою
швидкого перетворення Фур'є (FFT) використовуючи фреймворк Accelerate
[73].
Оброблені дані подаються в натреновану модель CoreML для
класифікації, яка визначає, чи є повідомлення своїм чи чужим. Результати
класифікації обробляються і фінальні результати відображаються користувачу
через інтерфейс, створений за допомогою SwiftUI.
83
ЧДТУ.232219.024 ПЗ
Цей процес відбувається послідовно, де кожен наступний крок залежить
від результатів попереднього, що забезпечує плавний потік даних від
захоплення до відображення результатів.
4.1.1.3 Опис логічної схеми системи
Опишемо та зобразимо (рисунок 4.3) логічну схему класифікації
звукового повідомлення.
Рисунок 4.3 – Логічна схема
На зображенні представлено логічну схему процесу, що складається з
різних етапів. Схема починається з верхнього лівого кута, де круглий символ
84
ЧДТУ.232219.024 ПЗ
позначає початок процесу. Від нього веде стрілка до першої дії - "Запуск UI",
після чого процес переходить до стану "UI запущено".
Далі, з цього стану ведуть дві паралельні гілки. Ліва гілка продовжується
дією "Запуск анімації", за якою слід стан "Анімація зупинена". Права гілка має
дію "Запис звуку", яка переходить у стан "Звук записано". Обидва ці стани
об'єднуються і ведуть до дії "Запуск класифікації".
Після цього процес переходить у стан "Класифікація завершена", з якого
починається інша паралельна частина процесу, представлена на правій стороні
схеми. Верхня гілка цієї паралельної секції включає дію "Дані збережено в БД"
(база даних), а нижня гілка включає дві дії: "Дані відображено на UI" та
"Відображення результатів на UI".
Ці дії також направлені до спільної точки, що веде до фінальної дії
"Інтерпретація результатів", після чого процес завершується круглим символом
"Кінець" у верхньому правому куті схеми.
Горизонтальні лінії між гілками на схемі символізують синхронізацію
або паралелізм у процесі. Ця схема може бути використана для візуалізації
етапів роботи програмного забезпечення або системи, де "UI" буде
користувацьким інтерфейсом, "БД" - базою даних, а "класифікація" та
"інтерпретація результатів" - частинами обробки даних та прийняття рішень.
4.1.1.4 Розробка бази даних
Оскільки база даних не є ключовим компонентом програмного
забезпечення із класифікації звукових повідомлень тому буде представлена у
спрощеному вигляді.
На етапі концептуального моделювання основна увага приділяється
високорівневому опису бізнес-понять та їх взаємозв'язків. Модель буде
включати сутність "Користувач" з унікальними ідентифікаторами та сутність
"Аудіо Класифікація", що містить інформацію про тривалість, дату, URL аудіо
файлу, а також масив метаданих. Метадані включають такі аспекти, як мітки
(labels), рівень впевненості (confidence) та тривалість кожного фрагменту.
85
ЧДТУ.232219.024 ПЗ
Відносини між користувачами та аудіо класифікаціями представлені як "один
до багатьох".
На етапі логічного моделювання зосередимося на детальному описі того,
як система буде зберігати та обробляти дані. Модель описує структуру даних,
включаючи типи даних та їх атрибути. Для сутності "Користувач" буде
визначено лише поле username, в свою чергу у моделі "Аудіо Класифікації" -
поля для тривалості, дати, URL файлу та структурований масив метаданих.
Особлива увага приділяється організації метаданих, що будуть реалізовані як
вкладені структури.
Фізична модель представлена на рисунку 4.4.
Рисунок 4.4 – Фізична модель бази даних
Останній етап включає розробку фактичної структури бази даних.
Створюються таблиці, визначаються поля (стовпці) для кожної сутності та
налаштовуються відносини між ними. Передбачим таблицю "Користувачі" з
86
ЧДТУ.232219.024 ПЗ
відповідними полями для персональної інформації, а також таблицю "Аудіо
Класифікації" з полями для зберігання деталей аудіо запису. Оптимальне
зберігання та доступ до метаданих, які реалізовані як частина запису аудіо
класифікації.
4.1.1.5 Розробка інтерфейсу користувача
Розробимо інтерфейс користувача враховуючи вимоги запропоновані
Якобом Нільсеном, а саме: простота використання, консистентність, зворотний
зв'язок, дизайн, зорієнтований на помилки, гнучкість та ефективність
використання, естетика та мінімалістичний дизайн, визнання, а не
запам'ятовування, допомога користувачам розпізнавати, діагностувати та
виправляти помилки, допомога та документація [74].
Враховуючи вище згадані принципи, спроектуємо інтерфейс
користувача. Буде складатися з трьох екранів, головного, екрану результатів та
деталей.
Перший екран є мінімалістичним, для того, щоб сфокусувати увагу
користувача тільки на важливій інформації та збільшити воронку
використання. Головна кнопка початку має збільшену область натискання, це
дозволяє зменшити кількість некоректних спрацювань. Після натискання
з’являється анімація запису звуків через мікрофон та кнопка відміни запису.
Кнопка відміни розташована зліва вгорі, для того, щоб зменшити кількість
натискання та бути впевненим, що користувач не натисне її випадково.
Після завершення запису звукового повідомлення буде відображено
екран результатів класифікації свій або чужий. Для того, щоб сфокусувати
увагу користувача на важливій інформації. Справа вгорі розташована кнопка з
іконкою інформації. Таке розташування зумовлено необхідністю зменшити
складність натискання, в порівнянні із кнопкою відміни, проте знизити ризик
випадкового натискання.
При натисканні кнопки з іконкою інформації буде відображено екран
деталізації про результат класифікації, який складається із списку сегментів
повідомлень, відсотку впевненості класифікації, мітки класифікації для
87
ЧДТУ.232219.024 ПЗ
кожного із сегментів. Такий екран дозволяє детальніше ознайомитися із тим, як
відбувалась класифікація та на якому етапі були наявні відмінні від основного
класифікації.
4.1.1.6 Опис розробки програмних компонентів
Проект програмної реалізації класифікатора звукових повідомлень
складається із декількох модулів, а саме:
модифікатори;
візуальні компоненти;
екрани;
стилі.
Кожен із модулів може складатися із під модулів або пакетів, наприклад,
модулі екранів складається із трьох пакетів:
головний екран;
екран деталізації результатів;
екран переможця класифікації.
Детальна структура раніше згаданих модулів і пакети в середовищі Xcode
представлені на рисунку 4.5.
Модуль модифікаторів складається із всіх модифікаторів, що можуть
бути використані для Swift UI компонентів. Модуль візуальних компонентів
складається із класів, які можуть бути повторно використані на будь-якому
екрані, наприклад компонент анімації при записі аудіо повідомлення. Модуль
стилів описує основі кольори, шрифти та текстові стилі, що можуть бути
використані на будь-якому із екранів.
Більш детально зупинимося на модулі екранів, розглянувши ключові
компоненти і класи, які реалізують ключові процеси класифікації, а саме:
запис аудіо повідомлення;
класифікація;
інтерпретація і розрахунок результатів.
88
ЧДТУ.232219.024 ПЗ
Рисунок 4.5 – Структура проекту
Розгорнута структура модулів зображена на рисунку 4.6. Запис аудіо
повідомлення відбувається шляхом використання пакету AudioKit, який було
описано раніше, що використовується в якості обгортки над Core Audio.
Класифікація вже записаного аудіо повідомлення відбувається за
допомогою двох класів, класифікатора та спостерігача за результатами
класифікації. Для аналізу використано бібліотеку Sound Analysis яка є
частиною інструментарію стандартної бібліотеки від Apple. Ця бібліотека має
можливість аналізувати аудіо повідомлення використовуючи алгоритм
перетворення FFT та раніше створеної моделі класифікації за допомогою Core
ML. Спостерігач класифікації отримує результати класифікації, та перетворює
їх у адаптований список, що буде зручний для користувача, для кожного із
сегментів класифікації. Додаткові бібліотеки не використовує.
89
ЧДТУ.232219.024 ПЗ
Рисунок 4.6 – Розгорнута структура модулів кожного екрану
Останнім етапом реалізується інтерпретація результатів, яка реалізує
алгоритм класифікації свій чужий, який описували раніше в теоретичних і
експериментальних дослідженнях, за допомого використання порогового
значення класифікації для кожного із сегментів. Додаткові бібліотеки не
використовує.
4.1.2 Тестування системи
Опишемо схему та етапи тестування програмного засобу для класифікації
звукових повідомлень.
Об’єктом тестування в нашому випадку буде мобільний додаток для
класифікації звукових повідомлень, як свій або чужий. Основні компоненти,
що потребують тестування:
90
ЧДТУ.232219.024 ПЗ
інтерфейс користувача:
завантаження додатку;
запис звукового повідомлення;
відміна запису повідомлення;
відображення результатів класифікації;
відображення деталей класифікації.
запис звукового повідомлення у локальне сховище;
аналіз звукового повідомлення і його класифікація;
інтерпретація результатів та класифікація.
Метою тестування є перевірка коректності роботи додатку, зокрема, його
спроможності вірно класифікувати звукові повідомлення, як свій або чужий, а
також забезпечення стабільності та відповідності додатку вимогам і стандартам
iOS.
В якості технологій тестування автоматизований та ручний методи.
Наявність ручного метода зумовлено обмеженням перевірки запису аудіо у
функціональних тестах. Ручне тестування допоможе перевірити
користувацький інтерфейс і загальну поведінку додатку. Автоматизоване
тестування (за допомогою фреймворку XCTest) буде використано для більш
глибокої перевірки функціональних можливостей додатку.
Більш детально опишемо програму тестування, розпочавши з ручного
тестування. Першим кроком необхідно перевірити позитивні сценарії:
користувач запускає додаток, натискає кнопку початку запису,
озвучує повідомлення, має відкритися екран з повідомленням свій або
чужий;
користувач після відкриття екрану результату класифікації натискає
кнопку з деталями класифікації, після чого має відобразитися екран із
списком, для кожного із сегментів класифікації;
користувач після відкриття екрану деталей класифікації, при гортанні
сторінки вниз має бачити останній результат класифікації, причому
91
ЧДТУ.232219.024 ПЗ
результати класифікації мають бути від 0 до останньої секунди всього
повідомлення.
Після чого описати негативні сценарії, а саме:
користувач запускає додаток, натискає кнопку початку запису і
натискає кнопку відміни, має зупинитися запис повідомлення та
відображення анімації;
користувач після відкриття екрану результату класифікації, жестом
одного пальця проводить згори до низу по відкритому екрану, після
чого екран має закритися і користувач має побачити головний екран
запису;
користувач після відкриття екрану деталей класифікації, натискає
кнопку закриття з іконкою хрестика, після чого екран має закритися і
користувач має побачити головний екран запису;
Автоматизоване тестування полягає в написанні тестів для основних
класів, а саме, запису звукових повідомлень, класифікації, наглядача за
результатами та інтерпретації результатів. Ці тести були реалізовані для всіх
класів в окремому модулі тестів, що зображено на рисунку 4.7.
Рисунок 4.7 – Структура unit тестів
4.1.2.1 Модульне тестування
Раніше визначені модулі, так як запис аудіо повідомлення, класифікація
та інтерпретація, в процесі розробки було перевірено їх головні функції для
кожного із цих модулів, а саме:
запис аудіо повідомлення;
зупинка запису повідомлення;
92
ЧДТУ.232219.024 ПЗ
видалення файлу запису;
класифікація повідомлення на основі аудіо файлу, як свій або
чужий;
зупинка класифікації;
розрахунок результату класифікації на основі сегментів.
На першому кроці було перевірено, що модуль створює аудіо запис та
завершує його, для виділеного проміжку часу довжиною 5 секунд. Також було
перевірено, що аудіо записане та відтворюється і на ньому чути звукове
повідомлення, яке щойно було записано. Наступним кроком було перевірено
видалення файлу запису шляхом виклику методу видалення, та перевірки
наявності файлу в локальному сховищі.
На другому кроці було перевірено, що модуль при виклику метода
класифікації аудіо повідомлення, повертає результати класифікації у вигляді
набору даних класифікації для кожного із сегменту, причому кількість
елементів у масиві відповідає кількості очікуваних сегментів, що обраховуєтеся
за формулою описаною раніше 2.5.
Останнім етапом було проведено тестування, результати представлені в
таблиці 4.1.
Таблиця 4.1
Результати проходження модульних тестів
№ Опис тесту Результат проходження
тесту
1 Запис аудіо повідомлення успішно
2 Зупинка запису повідомлення успішно
3 Видалення файлу запису успішно
4 Класифікація повідомлення успішно
Продовження таблиці 4.1
93
ЧДТУ.232219.024 ПЗ
5 Зупинка класифікації успішно
6 Розрахунок результату класифікації на успішно
основі сегментів
4.1.2.2 Інтеграційне тестування
До процесу інтеграційного тестування було залучено інженера з якості,
який перевірив спільну роботу модулів, які успішно працюють разом та мають
можливість передавати необхідну інформацію в інший модуль.
Цей процес складався із декількох етапів, а саме:
перевірка спрацювання початку запису при виклику метода обробки
натискання кнопки початку запису;
перевірка передачі аудіо файлу до метода класифікації і початку
класифікації;
перевірка результату класифікації для кожного із сегментів;
перевірка передачі даних до модулю, де відбувався розрахунок
результату класифікації;
перевірка оброблених результатів на співпадіння з очікуваним.
Результат проходження тестів представлений у таблиці 4.2.
Таблиця 4.2
Результат проходження інтеграційних тестів
№ Опис тесту Результат проходження
тесту
1 Спрацювання початку запису при виклику успішно
метода обробки натискання кнопки
2 Передачі аудіо файлу до метода класифікації успішно
і початку класифікації
Продовження таблиці 4.2
94
ЧДТУ.232219.024 ПЗ
3 Відображення класифікації для кожного із успішно
сегментів при натисканні кнопки інформації
4.1.2.3 Системне тестування
До процесу системного тестування було залучено стороннього інженера
з якості, який перевірив роботи мобільного додатку в цілому, який успішно
пройшов тестування.
Процес складався із декількох кроків:
загального тестування:
тестування запису аудіо повідомлень;
тестування зупинки та відновлення запису;
тестування видалення записів;
тестування класифікації повідомлень;
тестування інтерпретації результатів;
тестування продуктивності:
тестування часу відгуку додатку;
тестування споживання ресурсів;
тестування безпеки:
тестування доступу до даних;
тестування інтерфейсу користувача:
тестування відповідності рекомендаціям Apple;
тестування зручності.
Результати проходження тестів представлені в таблиці 4.3.
Таблиця 4.3
Результат проходження системних тестів
№ Опис тестування Результат проходження
тесту
1 Загальне успішно
95
ЧДТУ.232219.024 ПЗ
2 Сумісності успішно
3 Продуктивності успішно
4 Безпеки успішно
5 Інтерфейсу користувача успішно
4.1.2.4 Приймальне тестування
В якості приймального тестування було використано процес перевірки
від Apple Review Team, щодо готовності додатку до публікації в AppStore.
Такий механізм дозволяє перевірити мобільний додаток за внутрішніми
стандартами Apple, без додаткових витрат, окрім стандартної річної підписки
для розробників. Під час перевірки існує декілька статусів, один із яких, у разі
успішної перевірки – це Testing. Цей статус інформує, що перевірка пройшла
успішно і додаток отримав статус готовності до публічного тестування.
Було завантажено збірку додатку для перевірки і через 48 годин було
отримано схвальний статус, щодо проходження перевірки.
4.1.3 Приклади впровадженого програмного комплексу
Відобразимо детально приклади впровадження кожного із екранів
реалізованого мобільного додатку програмнго агента. Перший екран одразу
після завантаження додатку зображує можливість розпочати запис аудіо
повідомлення, зображено на рисунку 4.8.
96
ЧДТУ.232219.024 ПЗ
Рисунок 4.8 – Головний екран старту запису повідомлення
Наступним кроком зобразимо екран відображення процесу запису
звукового повідомлення з можливістю зупинити запис, що зображено на
рисунку 4.9. Після успішного запису, відбувається процес класифікації, в
результаті якого відображається інформація, свій або чужий, що зображено на
рисунку 4.10.
97
ЧДТУ.232219.024 ПЗ
Рисунок 4.9 – Екран процесу запису повідомлення
Рисунок 4.9 – Екран результатів класифікації
98
ЧДТУ.232219.024 ПЗ
При натисканні кнопки деталей, що знаходиться вгорі справа,
відображається екран з деталями результатів класифікації по сегментам, що
зображений на рисунку 4.10.
В свою чергу інструкція користувача представлена в додатку Б.
99
ЧДТУ.232219.024 ПЗ
ВИСНОВКИ
Процес підвищення інформативності масиву вхідних даних для
класифікації та аналізу звукових повідомлень є багатокомпонентною задачею,
яка потребувала дослідження, оскільки відсутні публічно доступні реалізації
необхідних програмних засобів.
Отримані результати із побудови словника ознак дозволив отримати
масив вхідних даних достатньої інформативності. Задачу бінарної класифікації
свій або чужий було вирішено за допомогою створення моделі нейронної
мережі, перетворення звукового повідомлення в числові значення за
допомогою перетворення Фур’є, виокремлення звукових характеристик та
інтерпретацію результатів. Це дозволило збільшити кількість правильно
класифікованих звуків до 96%, зменшити кількість звукових повідомлень для
навчання на 20% шляхом використання специфічного розміру вікна, визначити
діапазон фільтрації за частотою. Також було визначено оптимальний розмір
вікна у 0.5 секунди для голосових повідомлень та кількість звукових
повідомлень на навчання моделі нейронної мережевої у вигляді 80 на 20, для
навчального та тестового набору повідомлень, загальною довжини не більше
180 секунд.
Отримані результати дозволять в подальшому розширювати область
застосування і типи звуків, що можуть бути класифіковані, а також
застосування інших платформ, таких як Android та Arduino. При використанні
інших платформ гостро постає процес числового перетворення, оскільки він
має бути ідентичним в процесі тренування моделі, так і використання на
платформах.
Враховуючи вище зазначене можна стверджувати, що задачі виконані в
повному обсязі.
100
ЧДТУ.232219.024 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Audio Segmentation Techniques and Applications Based on Deep Learning /
Shruti Aggarwal, Vasukidevi G, S. Selvakanmani, Bhaskar Pant, Kiranjeet Kaur,
Amit Verma, Geleta Negasa Binegde // Scientific Programming – 2022. – Стаття
7994191. URL: https://www.hindawi.com/journals/sp/2022/7994191/ (дата
звернення: 08.12.2023).
2 Audio and Acoustic Signal Processing’s Major Impact on Smartphones / Heinz
Teutsch // Signal Processing Society – 2016. URL:
https://signalprocessingsociety.org/publications-resources/blog/audio-and-acoustic-
signal-processing%E2%80%99s-major-impact-smartphones (дата звернення
08.12.2023).
3 Discriminative frequency filter banks learning with neural networks / Teng
Zhang, Ji Wu // Journal on Audio, Speech, and Music Processing – 2019. - № 1. – С.
101. URL: https://asmp-eurasipjournals.springeropen.com/articles/10.1186/s13636-
018-0144-6 (дата звернення 08.12.2023).
4 Applications of Fourier Analysis to Audio Signal Processing: An Investigation
of Chord Detection Algorithms / Nathan Lenssen // Claremont – 2013. – Стаття 704.
URL: https://scholarship.claremont.edu/cmc_theses/704/ (дата звернення
08.12.2023).
5 Audio classification with complex neural networks / Ivan Chernenkiy, Nikita
Trufanov, Dobroslav Egorov, Oleg Kravchenko // AIP Conference Proceedings –
2023. – Стаття 2895405. URL: https://doi.org/10.1063/5.0136882 (дата звернення
08.12.2023).
6 Data Augmentation and Deep Learning Methods in Sound Classification: A
Systematic Review / Olusola O. Abayomi-Alli, Robertas Damaševiˇcius, Atika Qazi,
Mariam Adedoyin-Olowe, Sanjay Misra // Electronics – 2022. - №11. – Стаття
11223795. URL: https://doi.org/10.3390/electronics11223795 (дата звернення
09.12.2023).
7 Tactile displays for auditory augmentation–A scoping review and reflections
on music applications for hearing impaired users / Razvan Paisa, Niels Christia
101
ЧДТУ.232219.024 ПЗ
Nilsson, Stefania Serafin // Frontiers in Computer Science – 2023. - №5. – Стаття
1085539. URL: https://doi.org/10.3389/fcomp.2023.1085539 (дата звернення
09.12.2023).
8 Data augmentation on convolutional neural networks to classify mechanical
noise / Asith Abeysinghe, Sitthichart Tohmuang, John Laurence Davy, Mohammad
Fard // Applied Acoustics – 2023. - №203. – Стаття 109209. URL:
https://doi.org/10.1016/j.apacoust.2023.109209 (дата звернення 09.12.2023).
9 Deep Learning with Optimization Techniques for the Classification of Spoken
English Digit / Jane Oruh, Serestina Viriri // ICCI – 2021. – С. 494 – 507. URL:
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9534619/ (дата звернення
09.12.2023).
10 Hopf physical reservoir computer for reconfigurable sound recognition / Md
Raf E. Ul Shougat, XiaoFu Li, Siyao Shao, Kathleen McGarvey, Edmon Perkins //
Nature - Scientific Reports – 2023. - №13. – Стаття 8719. URL:
https://www.nature.com/articles/s41598-023-35760-x (дата звернення:
09.12.2023).
11 Lightweight and efficient end-to-end speech recognition using low-rank
transformer / Genta Indra Winata, Samuel Cahyawijaya, Zhaojiang Lin, Zihan Liu,
Pascale Fung // Cornel – 2020. – Стаття 13923. URL:
https://ar5iv.labs.arxiv.org/html/1910.13923 (дата звернення: 09.12.2023).
12 Optimized Audio Classification and Segmentation Algorithm by Using
Ensemble Methods / Saadia Zahid, Fawad Hussain, Muhammad Rashid, Muhammad
Haroon Yousaf, Hafiz Adnan Habib // Mathematical Problems in Engineering – 2015.
– Стаття 209814. URL: https://www.hindawi.com/journals/mpe/2015/209814/ (дата
звернення: 09.12.2023).
13 The maximum audible low-pass cutoff frequency for speech / Brian B.
Monson, Jacob Caravello // JASA – 2019. – С. 496 – 501. URL:
https://doi.org/10.1121/1.5140032 (дата звернення 10.12.2023).
14 Emotion recognition and confidence ratings predicted by vocal stimulus type
and prosodic parameters / Adi Lausen, Kurt Hammerschmidt // Humanities and
102
ЧДТУ.232219.024 ПЗ
Social Sciences Communications – 2020. - №7. – Стаття 2. URL:
https://www.nature.com/articles/s41599-020-0499-z (дата звернення 10.12.2023).
15 The paradoxical role of emotional intensity in the perception of vocal affect
/ N. Holz, P. Larrouy-Maestri & D. Poeppel // Nature - Scientific Reports – 2021. -
№11. – Стаття 9663. URL: https://www.nature.com/articles/s41598-021-88431-0
(дата звернення 10.12.2023).
16 The Language, Tone and Prosody of Emotions: Neural Substrates and
Dynamics of Spoken-Word Emotion Perception / Einat Liebenthal, David A.
Silbersweig, Emily Stern // Frontiers in Neuroscience – 2016. - №10. – Стаття 3389.
URL: https://doi.org/10.3389/fnins.2016.00506 (дата звернення 10.12.2023).
17 Noise reduction by adaptive-SIN filtering for retinal OCT images / Yan Hu,
Jianfeng Ren, Jianlong Yang, Ruibing Bai & Jiang Liu // Nature - Scientific Reports
– 2021. - №11. – Стаття 19498. URL: https://www.nature.com/articles/s41598-021-
98832-w (дата звернення 10.12.2023).
18 Analysis of Dirichlet and Generalized “Hamming” window functions in the
fractional Fourier transform domains / Sanjay Kumar, Kulbir Singh, Rajiv Saxena //
Signal Processing – 2011. - №91. – С. 600 – 606. URL:
https://doi.org/10.1016/j.sigpro.2010.04.011 (дата звернення 10.12.2023).
19 Advances in adaptive filtering theory and applications to acoustic and speech
signal processing / Markus Rupp, Walter Kellermann, Abdelhak Zoubir, Gerhard
Schmidt // EURASIP – 2016. – Стаття 63. URL: https://asp-
eurasipjournals.springeropen.com/articles/10.1186/s13634-016-0361-z (дата
звернення 10.12.2023).
20 Filtered-X Least Mean Fourth (FXLMF) and Leaky FXLMF adaptive
algorithms / Ali M. Al Omour, Abdelmalek Zidouri, Naveed Iqbal, Azzedine
Zerguine // EURASIP – 2016. – Стаття 39. URL: https://asp-
eurasipjournals.springeropen.com/articles/10.1186/s13634-016-0337-z (дата
звернення 10.12.2023).
21 Signal processing techniques for seat belt microphone arrays / Vasudev
Kandade Rajan, Mohamed Krini, Klaus Rodemer // EURASIP – 2016. – Стаття 35.
103
ЧДТУ.232219.024 ПЗ
URL: https://asp-eurasipjournals.springeropen.com/articles/10.1186/s13634-016-
0332-4 (дата звернення 10.12.2023).
22 The Source–Filter Theory of Speech / Isao Tokuda // Oxford Linguistics –
2021. – Стаття 894. URL: https://doi.org/10.1093/acrefore/9780199384655.013.894
(дата звернення 10.12.2023).
23 Deep Learning for Audio Signal Processing / Hendrik Purwins, Bo Li,
Tuomas Virtanen, Jan Schlüter, Shuo-yiin Chang, Tara Sainath // Journal of Selected
Topics of Signal Processing – 2019. - №13. – С. 206 – 219. URL:
http://doi.org/10.1109/JSTSP.2019.2908700 (дата звернення: 10.12.2023).
24 iPhone/iPad-Based Interactive Laboratory for Signal Processing in Mobile
Devices / Jinru Liu, Jayaraman J Thiagarajan, Andreas S Spanias // ECE – 2011. –
Стаття 229771. URL: https://peer.asee.org/iphone-ipad-based-interactive-
laboratory-for-signal-processing-in-mobile-devices (дата звернення: 10.12.2023).
25 A lightweight hybrid deep learning system for cardiac valvular disease
classification / Yazan Al-Issa, Ali Mohammad Alqudah // Nature – Scientific Reports
– 2022. - №12. – Стаття 14297. URL: https://www.nature.com/articles/s41598-022-
18293-7 (дата звернення 10.12.2023).
26 A Review of Differentiable Digital Signal Processing for Music & Speech
Synthesis / Ben Hayes, Jordie Shier, Gyorgy Fazekas, Andrew McPherson,
Charalampos Saitis // Frontiers in Computer Science – 2023. - №5. – Стаття 12841.
URL: https://www.frontiersin.org/articles/10.3389/frsip.2023.1284100 (дата
звернення 10.12.2023).
27 Speaker Recognition and Fast Fourier Transform / Nilu Singh, R. A. Khan //
IJAR – 2015. - №5. – Стаття 7. URL: http://dx.doi.org/10.13140/RG.2.1.2722.0969
(дата звернення 10.12.2023).
28 Generating and Searching Families of FFT Algorithms / Steve Haynal, Heidi
Haynal // Journal on Satisfiability, Boolean Modeling and Computation – 2011. - №7.
– C. 145 – 187. URL: https://www.doi.org/10.3233/SAT190084 (дата звернення
10.12.2023).
104
ЧДТУ.232219.024 ПЗ
29 Further studies of a FFT-based auditory spectrum with application in audio
classification / Wei Chu, Benoît Champagne // ICSP Proceedings – 2008. - №9. URL:
https://www.ece.mcgill.ca/~bchamp/Papers/Conference/ICSP2008.pdf (дата
звернення 10.12.2023).
30 Merlin The Story / Cornell University // Cornell Lab – 2023. URL:
https://merlin.allaboutbirds.org/the-story/ (дата звернення 14.12.2023).
31 Discover, Search, and Play Any Song by Using Just Your Voice /
SoundHound AI – 2023. URL: https://www.soundhound.com/soundhound/ (дата
звернення 14.12.2023).
32 Classification of Imbalanced Data Using Deep Learning with Adding Noise
/ Wan-Wei Fan, Ching-Hung Lee // Journal of Sensors – 2021. – Стаття 1735386.
URL: https://doi.org/10.1155/2021/1735386 (дата звернення 14.12.2023).
33 Interpreting machine‑learning models in transformed feature space with an
application to remote‑sensing classification / Alexander Brenning // Machine
Learning – 2023. - №112. – С.3455 – 3471. URL: https://doi.org/10.1007/s10994-
023-06327-8 (дата звернення 15.12.2023).
34 Regression as Classification: Influence of Task Formulation on Neural
Network Features / Lawrence Stewart, Francis Bach, Quentin Berthet, Jean-Philippe
Vert // HAL – 2023. – Стаття 03846706. URL: https://hal.science/hal-
03846706v2/preview/sample_paper.pdf (дата звернення 15.12.2023).
35 A Comprehensive Survey of Loss Functions in Machine Learning / Qi Wang,
Yue Ma, Kun Zhao, Yingjie Tian // Annals of Data Science – 2022. - №9. – С.187 –
212. URL: https://faculty.ist.psu.edu/vhonavar/Courses/ds310/lossfunc.pdf (дата
звернення 16.12.2023).
36 General Performance Score for classification problems / Isaac Martin De
Diego, Ana R. Redondo, Ruben R. Fernandez, Jorge Navarro, Javier M. Moguerza //
Applied Intelligence – 2021. - №52. – С.12049-12063. URL:
https://doi.org/10.1007/s10489-021-03041-7 (дата звернення 16.12.2023).
37 Amplitude-scan classification using artificial neural networks / Kunal K.
Dansingani, Kiran Kumar Vupparaboina, Surya Teja Devarkonda, Soumya Jana, Jay
105
ЧДТУ.232219.024 ПЗ
Chhablani & K. Bailey Freund // Nature – Scientific Reports – 2018. - №8. – Стаття
12451. URL: https://www.nature.com/articles/s41598-018-31021-4 (дата звернення
16.12.2023).
38 An Investigation of the Effectiveness of Phase for Audio Classification /
Shunsuke Hidaka, Kohei Wakamiya, Tokihiko Kaburagi // ICASSP– 2022. – С.3708-
3712. URL: https://doi.org/10.1109/ICASSP43922.2022.9746037 (дата звернення
16.12.2023).
39 Deep Classification of Sound: A Concise Review / S. Bhattacharya, N. Das,
S. Sahu, A. Mondal & S. Borah // Proceeding of First Doctoral Symposium on
Natural Computing Research – 2021. – С.33-43. URL:
http://dx.doi.org/10.1007/978-981-33-4073-2_4 (дата звернення 16.12.2023).
40 Environmental sound classification using temporal-frequency attention based
convolutional neural network / Wenjie Mu, Bo Yin, Xianqing Huang, Jiali Xu &
Zehua Du // Nature – Scientific Reports – 2021. - №11. – Стаття 21552. URL:
https://www.nature.com/articles/s41598-021-01045-4 (дата звернення 16.12.2023).
41 A two level strategy for audio segmentation / Sébastien Lefèvre, Nicole
Vincent // Digital Signal Processing – 2011. - №21. – С.270-277. URL:
https://hal.science/hal-00512744/document (дата звернення 17.12.2023).
42 Discrete Fourier transform techniques for noise reduction and digital
enhancement of analytical signals / M. Farooq Wahab a, Fabrice Gritti b, Thomas C.
O'Haver c // TrAC Trends in Analytical Chemistry – 2021. - №143. – Стаття 116354.
URL: https://doi.org/10.1016/j.trac.2021.116354 (дата звернення 17.12.2023).
43 Speech/music classification using phase-based and magnitude-based features
/ Mrinmoy Bhattacharjee, S.R. Mahadeva Prasanna, Prithwijit Guha // Speech
Communication – 2022. - №142. – С.34-48. URL:
https://doi.org/10.1016/j.specom.2022.06.005 (дата звернення 17.12.2023).
44 Multi-Representation Knowledge Distillation For Audio Classification /
Liang Gao, Kele Xu, Huaimin Wang, Yuxing Peng // Multimedia Tools and
Applications – 2022. - №81. – С.5089-5112. URL:
https://arxiv.org/pdf/2002.09607.pdf (дата звернення 17.12.2023).
106
ЧДТУ.232219.024 ПЗ
45 Keras Developer Guide / François Chollet // Keras – 2023. URL:
https://keras.io/guides/sequential_model (дата звернення 17.12.2023).
46 Simple audio recognition: Recognizing keywords // TensorFlowOrg – 2023.
URL: https://www.tensorflow.org/tutorials/audio/simple_audio (дата звернення
17.12.2023).
47 Multivariate Time Series Forecasting with LSTMs in Keras / Jason Brownlee
// Machine Learning Mastery – 2020. URL:
https://machinelearningmastery.com/multivariate-time-series-forecasting-lstms-
keras (дата звернення 17.12.2023).
48 LSTM Networks for Time Series Forecasting / Jason Brownlee // Machine
Learning Mastery – 2020. URL https://machinelearningmastery.com/use-features-
lstm-networks-time-series-forecasting (дата звернення 17.12.2023).
49 Dropout: A Simple Way to Prevent Neural Networks from Overfitting /
Nitish Srivastava, Geoffrey Hinton, Alex Krizhevsky, Ilya Sutskever, Ruslan
Salakhutdinov // Journal of Machine Learning Research – 2014. - № 15. – С.1929.
URL: https://jmlr.org/papers/volume15/srivastava14a/srivastava14a.pdf (дата
звернення 17.12.2023).
50 Adam: a method for stochastic optimization / Diederik P. Kingma, Jimmy
Lei Ba // 3rd International Conference for Learning Representations – 2015. URL:
https://arxiv.org/pdf/1412.6980.pdf (дата звернення 17.12.2023).
51 Cross-Entropy Loss Functions: Theoretical Analysis and Applications / Anqi
Mao, Mehryar Mohri, Yutao Zhong // ICML – 2023. - № 992. – С. 23803. URL:
https://ar5iv.labs.arxiv.org/html/2304.07288 (дата звернення 17.12.2023).
52 Multiple levels of linguistic and paralinguistic features contribute to voice
recognition / Jean Mary Zarate, Xing Tian, Kevin J. P. Woods, David Poeppel //
Scientific Reports – 2015. - №5. – С.11475. URL:
https://www.nature.com/articles/srep11475 (дата звернення 17.12.2023).
53 Data segmentation algorithms: Univariate mean change and beyond / Haeran
Cho, Claudia Kirch // Econometrics and Statistics – 2021. - №1. URL:
https://doi.org/10.1016/j.ecosta.2021.10.008 (дата звернення 21.12.2023).
107
ЧДТУ.232219.024 ПЗ
54 Scikit-learn: Machine Learning in Python / Fabian Pedregosa, Ga ̈el
Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel,
Mathieu Blondel, Andreas Mu ̈ller, Joel Nothman, Gilles Louppe, Peter Prettenhofer,
Ron Weiss, Vincent Dubourg, Jake Vanderplas, Alexandre Passos // Journal of
Machine Learning Research – 2011. - №12. URL:
https://arxiv.org/pdf/1201.0490.pdf (дата звернення 21.12.2023).
55 How to make models more useful / C. Michael Barton, Allen Lee, Marco A.
Janssen, H. R. Albert Jagers // Earth, Atmospheric and planetary sciences – 2022. -
№35. – Стаття 119. URL: https://doi.org/10.1073/pnas.2202112119 (дата
звернення 21.12.2023).
56 Optimized derivative fast Fourier transform with high resolution and low
noise from encoded time signals: Ovarian NMR spectroscopy / Dzevad Belkic &
Karen Belkic // Journal of Mathematical Chemistry – 2023. – Стаття 1553. URL:
Journal of Mathematical Chemistry Article (дата звернення 21.12.2023).
57 Enhancing threshold neural network via suprathreshold stochastic resonance
for pattern classification / Xiaojie Liu, Lingling Duan, Fabing Duan, François
Chapeau-Blondeau, Derek Abbott // Physics Letters A – 2021. - №403. – Стаття
127387. URL: https://doi.org/10.1016/j.physleta.2021.127387 (дата звернення
21.12.2023).
58 A systematic review of machine learning classification methodologies for
modelling passenger mode choice / Tim Hillel, Michel Bierlaire, Mohammed Z.E.B.
Elshafie, Ying Jin // Journal of Choice Modelling – 2021. - №38. – Стаття 100221.
URL: https://doi.org/10.1016/j.jocm.2020.100221 (дата звернення 21.12.2023).
59 Accuracy versus reliability-based modelling approaches for medical decision
making / Sepideh Etemadi, Mehdi Khashei // Computers in Biology and Medicine –
2022. - №141. Стаття 105138. URL:
https://doi.org/10.1016/j.compbiomed.2021.105138 (дата звернення 21.12.2023).
60 Precision magnetic field modelling and control for wearable
magnetoencephalography / Molly Rea, Niall Holmes, Ryan M. Hill, Elena Boto,
James Leggett, Lucy J. Edwards, David Woolger, Eliot Dawson, Vishal Shah, James
108
ЧДТУ.232219.024 ПЗ
Osborne, Richard Bowtell, Matthew J. Brookes // NeuroImage – 2021. - №241.
Стаття 118401. URL: https://doi.org/10.1016/j.neuroimage.2021.118401 (дата
звернення 21.12.2023).
61 About SampleSwap.org / Canton Becker // Sample Swap – 2023. URL:
https://sampleswap.org/about/ (дата звернення 25.12.2023).
62 Data augmentation approaches for improving animal audio classification /
Loris Nanni, Gianluca Maguolo, Michelangelo Paci // Ecological Informatics – 2020.
- №57. – Стаття 101084. URL: https://doi.org/10.1016/j.ecoinf.2020.101084 (дата
звернення 25.12.2023).
63 Classifying Human Voices by Using Hybrid SFX Time-Series Preprocessing
and Ensemble Feature Selection / Simon Fong, Kun Lan, Raymond Wong // Biomed
Res Int. – 2013. – Стаття 720834. URL: http://dx.doi.org/10.1155/2013/720834
(дата звернення 25.12.2023).
64 Comparison of the prediction accuracy of machine learning algorithms in
crosslinguistic vowel classification / Georgios P. Georgiou // Nature - Scientific
Reports – 2023. - №13. – Стаття 15594. URL: https://doi.org/10.1038/s41598-023-
42818-3 (дата звернення 25.12.2023).
65 Apple Ecosystem: closed and effective / John Dudovskiy // Business
Research Methodology – 2023. – Стаття 7308. URL: https://research-
methodology.net/apple-ecosystem-closed-effective (дата звернення 26.12.2023).
66 Swift a New Programming Language for Development and Education /
Rostislav Fojtik // International Conference on Digital Science – 2019. – C. 284 –
295. URL: http://dx.doi.org/10.1007/978-3-030-37737-3_26 (дата звернення
26.12.2023).
67 Developing educational iPhone, Android and Windows smartphone cross-
platform apps to facilitate understanding of clinical genomics terminology / Adam P.
Tobias, Edward S. Tobias // Applied & Translational Genomics – 2015. - №6. – С.5-
17. URL: https://doi.org/10.1016/j.atg.2015.08.001 (дата звернення 26.12.2023).
68 Swift audio synthesis, processing, & analysis platform for iOS, macOS and
tvOS / Aurelius Prochazka // AudioKit – 2023. URL:
109
ЧДТУ.232219.024 ПЗ
https://www.audiokit.io/AudioKit/documentation/audiokit (дата звернення
26.12.2023).
69 Machine Learning for Science: State of the Art and Future Prospects / Eric
Mjolsness, Dennis Decoste // Science – 2021. - №293. – Стаття 5537. URL:
http://dx.doi.org/10.1126/science.293.5537.2051 (дата звернення 26.12.2023).
70 UIKit vs. SwiftUI: How to Choose the Right Framework for Your App /
Jeroen L. // Getstream – 2022. URL: https://getstream.io/blog/uikit-vs-swiftui/ (дата
звернення 26.12.2023).
71 Interpreting the location data extracted from the Apple Health database /
Luke Jennings, Matthew Sorell, Hugo G. Espinosa // Forensic Science International:
Digital Investigation – 2023. - №44. – Стаття 301504. URL:
https://doi.org/10.1016/j.fsidi.2023.301504 (дата звернення 26.12.2023).
72 A new data augmentation method to use in machine learning algorithms using
statistical measurements / Emre Avuçlu // Measurement – 2021. - №180. – Стаття
109577. URL: https://doi.org/10.1016/j.measurement.2021.109577 (дата звернення
26.12.2023).
73 An efficient dataflow accelerator for scientific applications / Xiaochun YeXu,
Tan Meng, Meng Wu // Future Generation Computer Systems – 2020. - №1. – Стаття
112. URL: http://dx.doi.org/10.1016/j.future.2020.03.023 (дата звернення
26.12.2023).
74 Usability engineering / Jakob Nielsen // Morgan Kaufmann – 1994. – ISBN:
0-12-518406-9. URL:
https://uweb.engr.arizona.edu/~ece596c/lysecky/uploads/Main/Lec9.pdf (дата
звернення 27.12.2023).
110
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_____________ Голуб С.В.
„____” _________________ 2023 р.
Аналізатор звукових повідомлень на платформі IOS
Специфікація
482.ЧДТУ 232219-01
Листів 2
Розробник ________________ Загородній В.М.
Керівник ________________ Немченко В.В.
Контроль ________________ Півень О.Б.
2024
111
482.ЧДТУ 232219-01 2
Позначення Найменування Примітка
482.ЧДТУ 232219-01 34 01 Інструкція користувача
112
ДОДАТОК Б
Аналізатор звукових повідомлень на платформі IOS
Інструкція користувача
482.ЧДТУ 232219-01 34 01
Листів 2
Розробник ________________ Загородній В.М.
2024
113
Першим кроком необхідно зробити архів, відкривши програмний
продукт за допомого Xcode обравши Any iOS device в якості напрямку зборки.
Після чого необхідно натиснути Product – Archive із верхнього меню.
Розпочнеться процес архівування. Після завершення архівування відкриєтеся
вікно Organizer із списком доступних додатків для дистрибуції.
Побідний механізм архівування необхідний, оскільки Apple обмежила
механізм дистрибуції для своїх платформи, унеможливлюючи встановлення
сторонніх додатків, як це можливо для Android.
Після архівування необхідно обрати варіант дистрибуції натиснувши
Distribute App обравши опції із переліку доступних. Після успішної
дистрибуції, необхідно встановити додаток на мобільний пристрій, в
залежності від раніше обраного варіанту.
Після встановлення необхідно запустити мобільний додаток натиснувши
на іконку Sound Analyzer і при запиті на доступ, дозволити використання
мікрофону додатком.
Другим кроком опишемо інструкцію щодо користування додатком. Для
початку процесу необхідно натиснути Tap to start. Після натискання почнеться
процес запису аудіо повідомлення, причому на екрані буде відображена
анімація у вигляді еквалайзера і кнопка відміни Cancel. Якщо натиснути
відміна, процес запису і класифікації буде припинено. Необхідно піднести
пристрій ближче до джерела звуку по можливості подалі від шумів.
Після завершення запису, що відбудеться автоматично, буде відображено
екран з результатом класифікації свій або чужий. Справа вгорі буде
відображено іконку інформації, при натисканні на яку буде відображено екран
з результатами класифікації для кожного із сегментів звукового повідомлення.
При натисканні на кнопку закриття, екран з деталями буде закрито і буде
відображено головний екран, де можливо повторити процес знову.
114