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/9087| Title: | Телеграм-бот для прослуховування музики |
| Authors: | Немченко, Вадим Вячеславович Прокопенко, Олег Іванович |
| Keywords: | Телеграм-бот;прослуховування музики |
| Issue Date: | 2025 |
| Abstract: | Виконавець: Прокопенко Олег Іванович. Назва кваліфікаційної бакалаврської роботи: "Телеграм-бот для прослуховування музики". Спеціальність: 121 «Інженерія програмного забезпечення». Установа: Черкаський державний технологічний університет (ЧДТУ). Місто, рік: Черкаси, 2025 рік. Основні ідеї, результати та висновки кваліфікаційної бакалаврської роботи: Основні ідеї: ‒ розробка Telegram-бота для пошуку музики через YouTube та надсилання її у вигляді аудіо в месенджер; ‒ підтримка плейлистів, черги запитів та повідомлень про статус виконання; ‒ інтеграція з Telegram API та конвертація відео у звук. ntegration with Telegram API and audio extraction from video. Результати: ‒ створено Telegram-бот із чергою запитів та асинхронною обробкою; ‒ реалізовано пошук і завантаження музики з YouTube (включно з плейлистами); ‒ автоматично конвертуються відео у аудіофайли та надсилаються користувачам; ‒ додано повідомлення про статуси (очікування, обробка, завершення); ‒ проведено тестування і оптимізацію роботи бота. Висновки: ‒ бот є зручним інструментом для прослуховування музики з YouTube; ‒ застосовані технології (Python, Telegram API, asyncio) забезпечують ефективну роботу; ‒ рішення легко масштабувати та розширювати. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9087 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра 2025 - Прокопенко.pdf Restricted Access | 5.55 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Телеграм-бот для прослуховування музики»
Виконав: студент 4 курсу, групи ПЗ-2104
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Прокопенко О. І.
(прізвище та ініціали)
Керівник Немченко В. В.
(прізвище та ініціали)
Рецензент Чайка І. В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
______________________С. Голуб
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Прокопенко Олег Іванович
(прізвище, ім’я, по батькові)
1. Тема роботи: «Телеграм-бот для прослуховування музики»
Керівник роботи к.т.н., доцент Немченко Вадим В`ячеславович,
Затверджені наказом Черкаського державного технологічного університету №53/03/03
від «25» лютого 2025 року
2. Строк подання студентом роботи 16 червня 2025
3. Вхідні дані до роботи: модульний застосунок для планування та організації часу,
індивідуальне налаштування відображення даних.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результату дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток А – Документація________________________________________________
Додаток Б – Специфікація програми________________________________________
Додаток В – Текст програми_______________________________________________
Додаток Г – Презентаційний матеріал_______________________________________
6. Консультанти розділів роботи
7. Дата видачі завдання 2 грудня 2024 року.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п випускної
роботи
1 Постановка задачі вересень виконано
2 Підготовка завдання вересень виконано
3 Погодження завдання вересень виконано
4 Затвердження завдання жовтень виконано
Основна стадія жовтень
1 Підбір матеріалів жовтень виконано
2 Аналіз шляхів вирішення поставленої задачі листопад виконано
3 Розрахунок основних параметрів роботи листопад виконано
4 Вибір кінцевого варіанту проектного рішення січень виконано
5 Оформлення первісної редакції роботи січень виконано
Заключна стадія березень
1 Узгодження прийнятих проектних рішень з травень виконано
керівником
2 Оформлення пояснювальної записки роботи в червень виконано
кінцевій редакції
3 Попередній захист роботи червень виконано
4 Затвердження роботи червень виконано
5 Рецензування роботи червень виконано
6 Захист роботи червень
Студент _____________________ Прокопенко О.І.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Немченко В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Виконавець: Прокопенко Олег Іванович.
Назва кваліфікаційної бакалаврської роботи: "Телеграм-бот для
прослуховування музики".
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2025 рік.
Основні ідеї, результати та висновки кваліфікаційної бакалаврської
роботи:
Основні ідеї:
‒ розробка Telegram-бота для пошуку музики через YouTube та надсилання
її у вигляді аудіо в месенджер;
‒ підтримка плейлистів, черги запитів та повідомлень про статус виконання;
‒ інтеграція з Telegram API та конвертація відео у звук. ntegration with
Telegram API and audio extraction from video.
Результати:
‒ створено Telegram-бот із чергою запитів та асинхронною обробкою;
‒ реалізовано пошук і завантаження музики з YouTube (включно з
плейлистами);
‒ автоматично конвертуються відео у аудіофайли та надсилаються
користувачам;
‒ додано повідомлення про статуси (очікування, обробка, завершення);
‒ проведено тестування і оптимізацію роботи бота.
Висновки:
‒ бот є зручним інструментом для прослуховування музики з YouTube;
‒ застосовані технології (Python, Telegram API, asyncio) забезпечують
ефективну роботу;
‒ рішення легко масштабувати та розширювати.
ANNOTATION
Performer: Prokopenko Oleh Ivanovych.
Title of the qualified bachelor’s work: " Telegram-bot for listening to music"
Specialty: 121 "Software Engineering"
Institution: Cherkasy State Technological University (CSTU).
City, year: Cherkasy, 2025.
Main ideas, results, and conclusions of the qualified bachelor’s work:
Main ideas:
‒ development of a Telegram bot that searches for music via YouTube and delivers it
as audio files in the messenger;
‒ support for playlists, request queuing, and status notifications;
‒ Integration with Telegram API and audio extraction from video
Results:
‒ a Telegram bot was developed with asynchronous request queue handling;
‒ implemented music search and download from YouTube, including playlists;
‒ automatic video-to-audio conversion and file delivery to users;
‒ status messages added (waiting, processing, completed);
‒ functionality tested and optimized.
Conclusions:
‒ the bot is a convenient tool for listening to music from YouTube;
‒ applied technologies (Python, Telegram API, asyncio) ensure efficient performance;
‒ the solution is scalable and ready for further development.
ЧДТУ 252166.017 ПЗ
ЗМІСТ
ВСТУП ....................................................................................................................... 9
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ........................................................................................... 12
1.1 Основні визначення ...................................................................................... 12
1.2 Аналіз та моніторинг сучасних Telegram-ботів ......................................... 13
1.3 Методи реалізації сучасних Telegram-ботів............................................... 17
1.4 Постановка задач .......................................................................................... 19
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ ............................................................... 21
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ............................................................................................................................ 22
2.1 Моделювання предметної області .............................................................. 22
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області .................................................................................... 22
2.1.2 Елементи моделювання предметної області ....................................... 24
2.1.3 Робоча область моделювання ............................................................... 26
2.2 Формування та аналіз вимог ........................................................................ 27
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги .......................................................................................... 27
2.2.2 Формування вимог за допомогою діаграми прецедентів. ................. 29
2.3 Проектування логічної структури програмного комплексу ..................... 32
ЧДТУ 252166-017 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Прокопенко О. І. «Телеграм-бот для Літ. Лист Листів
Перевір. Немченко В. В. прослуховування музики» 3
Рецензент Чайка І. В. Пояснювальна записка.
Н. Контр. Півень О. Б. ФІТІС, кафедра ПЗАС, ПЗ-2104
Затверд. Голуб С. В.
ЧДТУ 252166.017 ПЗ
2.3.1 Діаграми класів ...................................................................................... 33
2.3.2 Діаграма пакетів .................................................................................... 36
2.4 Архітектурне проектування ......................................................................... 38
2.4.1 Діаграма компонентів ........................................................................... 39
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ............................................................................................................... 41
2.5 Моделювання поведінки системи ............................................................... 44
2.5.1 Діаграма діяльності ............................................................................... 44
2.5.2 Діаграма послідовності ......................................................................... 46
2.5.3 Діаграма комунікації ............................................................................. 47
2.5.4 Діаграма скінченого автомату .............................................................. 50
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ ................................................................ 53
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
............................................................................................................................................ 54
3.1 Розробка програмного комплексу ............................................................... 54
3.1.1 Обґрунтування вибору засобів реалізації............................................ 54
3.1.2 Опис структурної (функціональної) схеми ......................................... 55
3.1.3 Опис логічної схеми системи ............................................................... 57
3.1.4 Розробка бази даних .............................................................................. 59
3.1.5 Розробка інтерфейсу користувача........................................................ 60
3.1.6 Опис розробки програмних компонентів ............................................ 61
3.2 Тестування системи ...................................................................................... 63
3.2.1 Модульне тестування ............................................................................ 65
3.2.2 Інтеграційне тестування ........................................................................ 68
3.2.3 Системне тестування ............................................................................. 72
3.2.4 Приймальне тестування ........................................................................ 74
ЧДТУ 252166-017 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 252166.017 ПЗ
3.3 Приклади впровадженого програмного комплексу .................................. 77
3.3.1 Опис функціоналу користувача Telegram-бота MusicBot ................. 78
3.3.2 Розгортання системи ............................................................................. 81
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ ............................................................... 84
ВИСНОВКИ ............................................................................................................ 85
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .............................................................. 86
ДОДАТОК А ........................................................................................................... 88
ДОДАТОК Б ............................................................................................................ 90
ДОДАТОК В ........................................................................................................... 98
ДОДАТОК Г .......................................................................................................... 103
ЧДТУ 252166-017 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 252166.017 ПЗ
ВСТУП
Актуальність теми визначається зростаючою потребою користувачів у
програмному забезпеченні, яке надає зручний та швидкий доступ до музичного
контенту через сучасні месенджери. Одним із найпопулярніших інструментів є
Telegram, що дозволяє створювати інтерактивних ботів, які можуть виконувати
широкий спектр задач, зокрема пошук та прослуховування музики. Розробка
програмного забезпечення для Telegram-бота, який дозволяє здійснювати пошук
треків за допомогою YouTube, створює зручний музичний сервіс без потреби
відкривати сторонні програми чи веб-сайти. Актуальність таких сервісів зростає в
умовах повсюдного використання смартфонів, коли користувачі прагнуть до
максимальної автоматизації і зручності взаємодії з цифровим контентом.
У свою чергу, для розробників і власників цифрових рішень, Telegram-боти є
ефективним засобом доставки сервісу, взаємодії з аудиторією, підвищення лояльності
користувачів. Вони дозволяють масштабувати функціональність без необхідності
розробки повноцінного застосунку, знижуючи витрати на підтримку інтерфейсу та
інфраструктури. Інтеграція з YouTube відкриває доступ до величезної
медіабібліотеки, а також надає можливість автоматичного збирання даних про
вподобання користувачів, що дозволяє покращити персоналізацію сервісу та
розширити його функціональність у майбутньому.
Метою розробки є створення програмного забезпечення у вигляді Telegram-
бота, який дозволяє користувачам здійснювати пошук та прослуховування музичних
композицій через інтеграцію з платформою YouTube, забезпечуючи зручність
використання та швидкий доступ до контенту.
Завданням є розробка програмного забезпечення у вигляді Telegram-бота з
архітектурою, яка відповідає сучасним стандартам. Реалізація функції пошуку
музичних композицій за назвою або її частиною, завантаження та відправки
аудіофайлів користувачеві. Організація обробки черги запитів для запобігання
одночасному виконанню кількох запитів. Додатково реалізовано підтримку пошуку
по YouTube-плейлистах, а також надсилання аудіо треків у порядку їх розміщення у
списку відтворення.
9
ЧДТУ 252166.017 ПЗ
Об’єктом розробки є процеси створення програмного забезпечення та
інфраструктури, які забезпечують ефективну роботу Telegram-бота для пошуку та
прослуховування музики.
– Telegram-бот – основний інтерфейс взаємодії з користувачем у Telegram,
який обробляє команди, надсилає повідомлення та аудіо;
– серверна частина – відповідає за логіку обробки запитів, пошук на YouTube,
обробку аудіо та взаємодію з Telegram API [1];
– файлова система або тимчасове сховище – використовується для зберігання
завантажених аудіофайлів перед їх відправкою користувачам.
Предметом розробки є процес побудови програмного забезпечення у вигляді
Telegram-бота, що дозволяє здійснювати пошук, завантаження та прослуховування
музичних композицій з YouTube через Telegram.
Методи проектування та конструювання:
– мова програмування Python [3] з бібліотекою aiogram [2] – була обрана через
її зручність у створенні Telegram-ботів, підтримку асинхронного
програмування та активну спільноту розробників. Aiogram забезпечує
ефективну обробку запитів користувача та зручний інтерфейс для взаємодії
з Telegram API;
– yt-dlp [4] – інструмент для завантаження аудіо з YouTube, використовується
для отримання MP3-файлів із заданих посилань або пошукових запитів;
– ffmpeg [6] – інструмент для обробки мультимедійних файлів,
використовується для конвертації відео у формат аудіо;
– Pyrogram [8] – бібліотека для роботи з Telegram API, використовувалась на
етапі тестування передачі файлів у Telegram;
– Railway [7] – хмарна платформа для розгортання серверних застосунків.
Була використана для хостингу Telegram-бота;
– Git [11] та GitHub [12] – системи контролю версій, які дозволяли керувати
історією змін, працювати над проєктом у команді та зберігати резервні копії;
– PyCharm [13] – інтегроване середовище розробки (IDE), що
використовувалося під час створення логіки Telegram-бота.
10
ЧДТУ 252166.017 ПЗ
Також були використані діаграми UML [17] для візуалізації архітектури та
взаємодії компонентів Telegram-бота, включаючи діаграми активності та
послідовностей.
Опис отриманих результатів:
Було створено програмне забезпечення у вигляді Telegram-бота, який дозволяє
здійснювати пошук та прослуховування музики за допомогою запитів у чаті Telegram.
Бот інтегрований із сервісом YouTube через інструмент yt-dlp для отримання
аудіофайлів. Реалізовано функціонал пошуку треків за ключовими словами,
завантаження треку, його обробка за допомогою ffmpeg та відправлення у вигляді
аудіо повідомлення. Забезпечено черговість запитів від користувачів – нові запити
обробляються після завершення поточного, з відповідним інформуванням у чаті.
Також додано підтримку YouTube-плейлистів з можливістю поетапного надсилання
треків. Бекенд бота відповідає архітектурі RESTful API, що дозволяє гнучко
масштабувати функціональність у майбутньому. Проєкт розгорнуто на платформі
Railway. Виконано модульне, інтеграційне, системне та приймальне тестування
функціоналу.
Практичне значення отриманих результатів:
Розроблене програмне забезпечення у вигляді Telegram-бот надає користувачам
зручний інструмент для пошуку та прослуховування музики без потреби
встановлювати додаткові програми чи використовувати браузер. Завдяки підтримці
фільтрації за назвою та можливості роботи з плейлистами, бот забезпечує гнучке та
персоналізоване користування. Інтерфейс Telegram є зрозумілим та доступним
широкому колу користувачів. Автоматизація процесів завантаження та обробки
музики знижує навантаження на користувача. Власник бота отримує інструмент з
можливістю масштабування, аналітики та подальшого розвитку, включаючи
введення рекомендаційної системи, статистики прослуховувань та інтеграцію з
іншими медіаплатформами.
11
ЧДТУ 252166.017 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Основні визначення
Потенційні користувачі – це особи, які мають намір знайти та прослухати
музичні треки через онлайн-сервіси. Зазвичай потенційні користувачі проходять
кілька етапів у процесі пошуку та прослуховування музики за допомогою Telegram-
бота. Першим кроком є формування запиту, наприклад, введення назви треку,
виконавця або посилання на відео з YouTube.
Після надсилання запиту Telegram-бот обробляє його, виконує пошук
аудіофайлу, а потім надсилає користувачу відповідний музичний трек. У разі потреби
користувач може додати нові запити до черги або взаємодіяти з функціоналом, як-от
перегляд черги, скасування запиту тощо. Це включає спрощену систему взаємодії –
достатньо мати встановлений Telegram і доступ до мережі інтернет.
Потенційні користувачі можуть взаємодіяти з Telegram-ботом через мобільні
додатки, веб-версію Telegram або десктопні застосунки. Telegram забезпечує просту і
стабільну платформу обміну повідомленнями, що дозволяє швидко отримувати
відповіді від бота та переглядати надіслані треки, використовуючи вбудований
аудіоплеєр.
Telegram-бот для прослуховування музики – це програмне забезпечення,
реалізоване у вигляді Telegram-бота, яке дозволяє користувачам знаходити та
прослуховувати музичні треки з відкритих джерел, зокрема з YouTube. Такий бот
може бути розміщений на хмарній платформі та працювати цілодобово,
забезпечуючи доступ до музики будь-коли.
Telegram-бот надає користувачу набір функцій, зокрема прийом пошукових
запитів, обробку відео з YouTube, конвертацію в аудіоформат, надсилання готового
файлу у чат, обробку плейлистів, чергування запитів тощо. Ключовими
можливостями є простота інтерфейсу, швидкість реакції, підтримка черги, а також
можливість розширення функціоналу у майбутньому.
12
ЧДТУ 252166.017 ПЗ
Серед основних переваг Telegram-ботів є можливість використання аналітики
Telegram API. Завдяки інтеграції з Telegram, можна аналізувати кількість
користувачів, частоту використання команд, популярність запитів, навантаження на
сервер та ефективність черги. Ці дані дозволяють вдосконалювати систему
черговості, покращувати стабільність роботи бота та адаптувати функціонал до
запитів реальних користувачів.
Важливою складовою Telegram-бота є також клієнтський сервіс. Це може
включати інформативні відповіді при виникненні помилок (наприклад, "Please wait
for the current track to finish"), автоматичне повідомлення про завершення обробки
запиту, інтеграцію з кнопками керування в чаті та логування для технічної підтримки.
Додатково Telegram-боти можуть інтегрувати інноваційні функції, зокрема
підтримку голосових запитів, генерацію обкладинок треків на основі штучного
інтелекту, рекомендації за жанром або настрієм, інтеграцію з зовнішніми базами
даних музики. Це дозволяє надати більш гнучкий та інноваційний досвід
користування, збільшуючи залученість та зменшуючи кількість повторних запитів на
той самий контент.
1.2 Аналіз та моніторинг сучасних Telegram-ботів
У період стрімкого розвитку онлайн-сервісів та зростання популярності
музичних платформ виникає необхідність у глибокому аналізі вже існуючих
Telegram-ботів для відтворення музики. У цьому контексті було досліджено
функціонал трьох популярних ботів, орієнтованих на відтворення музичних треків
(рис. 1.1, рис. 1.2, рис. 1.3). Особливу увагу приділено зручності користування,
швидкості реакції, стабільності роботи та підтримці кількох запитів одночасно.
Користувальницький досвід відіграє ключову роль у залученні постійних
користувачів. Тому під час аналізу було оцінено, наскільки ефективно бот обробляє
запити, як швидко він відповідає, та чи може впоратись із декількома запитами, що
надійшли майже одночасно.
Ось перелік та аналіз найбільш популярних аналогів моєї роботи, знайдених
мною:
13
ЧДТУ 252166.017 ПЗ
1 @Shazambot
Опис: Бот-детектор пісень на основі Shazam API. Ви надсилаєте фрагмент аудіо
чи відео, і бот повертає назву треку, виконавця, альбом тощо. Має близько 650 000
щомісячних користувачів.
Переваги:
‒ швидка ідентифікація: за лічені секунди надає точну інформацію про трек;
‒ підтримка медіа: працює з голосовими повідомленнями, відео чи лінками;
‒ популярний і стабільний: велика база користувачів свідчить про
надійність.
Недоліки:
‒ лише розпізнавання: не надає скачування треків, може лише
перенаправити на стрімінг-сервіси;
‒ можливі збої: як і всі боти, іноді може не відповідати;
‒ читайте конфіденційність: використовує ваші аудіо-фрагменти, але
детальної політики бот не публікує.
Рисунок 1.1 – Приклад роботи бота @Shazambot
14
ЧДТУ 252166.017 ПЗ
2 @YtbAudioBot
Опис: Призначений для завантаження аудіо з YouTube – пісні, подкасти тощо.
Має близько 320 000 щомісячних користувачів.
Переваги:
‒ завантаження аудіо: швидко конвертує youtube-відео в аудіофайли
(ймовірно mp3);
‒ зручний інтерфейс: командна робота через бота, недоступність через
контакт-канал;
‒ чітка база користувачів: значна аудиторія, що свідчить про стабільність.
Недоліки:
‒ може порушувати авторське право: завантаження контенту з youtube часто
суперечить правилам сервісу;
‒ якість аудіо: часто обмежується якостями 128–192 kbps;
‒ залежність від youtube: при блокуванні api – бот може перестати працювати.
Рисунок 1.2 – Приклад роботи бота @YtbAudioBot
15
ЧДТУ 252166.017 ПЗ
3 @AusensBot
Опис: Загальний медіа-даунлоудер – підтримує музику та інші медіа.
Переваги:
‒ багатомовність контенту: окрім аудіо, підтримує інші види медіа;
‒ реклама та канал новин: має інформаційну підтримку користувачів
(@ausensbotnews).
Недоліки:
‒ менша популярність: без даних про аудиторію, складно оцінити надійність;
‒ реклама: наявність може відволікати;
‒ неясна якість умов: невідомо, які джерела використовуються для
завантаження.
Рисунок 1.3 – Приклад роботи бота @AusensBot
16
ЧДТУ 252166.017 ПЗ
Метою аналізу є створення власного Telegram-бота, що дозволяє знаходити та
слухати музику, враховуючи недоліки та переваги вже існуючих рішень. Це дає змогу
запозичити найкращі практики, а також реалізувати функції, які демонструють
ефективність на практиці. Розробка Telegram-бота передбачає застосування сучасних
технологій, реалізацію функціоналу пошуку, обробки, доставки музичних треків і
подальше вдосконалення системи.
1.3 Методи реалізації сучасних Telegram-ботів
Розробка Telegram-ботів часто виконується з використанням наступних мов
програмування та технологій: Python, бібліотека aiogram – для створення асинхронної
взаємодії з Telegram API, а також модулі yt-dlp, ffmpeg, aiohttp – для обробки
мультимедійного контенту та завантаження аудіо з онлайн-ресурсів.
Забезпечення безпеки та стабільної роботи Telegram-бота є ключовим аспектом,
оскільки бот взаємодіє з даними користувачів і сторонніми API. Для цього
використовують токени з обмеженим доступом, ізоляцію середовища виконання, а
також асинхронну обробку подій, що дозволяє уникати перевантаження сервера. Для
додаткової безпеки можуть впроваджуватись механізми валідації введених даних,
обробки виключень і обмеження запитів до сторонніх сервісів.
Інтеграція бота з інструментами логування, моніторингу та аналітики
(наприклад, через власні логи або зовнішні сервіси на кшталт Railway logs, Grafana
або Telegram Bot Analytics) дозволяє відстежувати активність користувачів, помилки
та покращувати якість сервісу.
Для розробки Telegram-бота для прослуховування музики з використанням
Python, можна застосувати наступні методи та засоби:
‒ мова програмування Python – одна з найпопулярніших у сфері автоматизації
та розробки Telegram-ботів. Вона має широкий набір бібліотек, включаючи
aiogram, telethon, asyncio [9], що дозволяють створювати асинхронні,
масштабовані та зручні у підтримці Telegram-боти;
17
ЧДТУ 252166.017 ПЗ
‒ aiogram – сучасний асинхронний фреймворк для Telegram-ботів, який
дозволяє ефективно обробляти вхідні повідомлення, працювати з FSM
(Finite State Machine), забезпечуючи гнучку логіку діалогу з користувачем;
‒ yt-dlp – бібліотека для завантаження аудіо– та відеофайлів з YouTube, що
підтримує численні формати та платформи. У поєднанні з ffmpeg дозволяє
отримувати та конвертувати музичний контент у формат, зручний для
Telegram;
‒ ffmpeg – потужний інструмент командного рядка для обробки
мультимедійних даних, який використовується для конвертації відео в
аудіо, обрізки, зменшення якості файлів та іншої підготовки аудіо перед
відправкою;
‒ Railway – платформа для хостингу Python-застосунків, яка дозволяє швидко
розгорнути Telegram-бота без складної конфігурації сервера. Підтримує
автоматичні оновлення, середовище змінних та логування;
‒ Git та GitHub – системи контролю версій, що дозволяють ефективно
керувати кодовою базою, співпрацювати з іншими розробниками та
відстежувати зміни;
‒ PyCharm – інтегроване середовище розробки для Python, що надає широкі
можливості для написання, відладки та тестування коду. Має підтримку
віртуальних середовищ, інтеграцію з Git та автоформатування коду;
‒ VS code – легкий редактор коду, зручний для редагування клієнтської
частини бота (наприклад, шаблонів повідомлень, стилів або документації).
Перелічені інструменти у поєднанні дозволяють створити повноцінного та
ефективного Telegram-бота, який забезпечує зручну та інтерактивну взаємодію з
користувачем. Такий бот здатен оперативно обробляти запити на відтворення музики,
формувати відповіді у вигляді аудіофайлів, підтримувати чергу запитів, а також
гарантувати високий рівень надійності та безпеки в роботі.
Використання мови програмування Python у зв’язці з асинхронним
фреймворком aiogram дає змогу реалізувати гнучку та ефективну логіку обробки
повідомлень, команд і подій Telegram API. Завдяки цьому бот здатен масштабуватись
18
ЧДТУ 252166.017 ПЗ
під більшу кількість користувачів і підтримувати стабільну роботу в режимі
реального часу. Бібліотека yt-dlp використовується для завантаження музики з
YouTube, а ffmpeg – для конвертації та обробки медіафайлів, забезпечуючи високу
якість аудіо та зручність подальшого використання.
Для підтримки зручного та організованого процесу розробки залучаються
системи контролю версій, зокрема Git, що дозволяє ефективно керувати змінами в
коді, співпрацювати в команді та повертатися до попередніх версій за потреби.
Використання середовищ розробки, таких як PyCharm або Visual Studio Code [14],
створює сприятливе середовище для розробника, завдяки розширеним можливостям
налагодження, автодоповнення коду та інтеграції з іншими інструментами.
Таким чином, усі ці компоненти працюють у синергії та сприяють створенню
Telegram-бота, який є не лише функціональним і продуктивним, але й надійним,
зручним у використанні та привабливим для кінцевого користувача.
1.4 Постановка задач
Метою даної кваліфікаційної роботи є розробка та впровадження програмного
забезпечення у вигляді функціонального Telegram-бота для прослуховування музики,
який дозволяє зручно шукати та отримувати музичні треки з YouTube через інтерфейс
месенджера Telegram. В результаті аналізу предметної області, були сформовані
наступні функціональні та нефункціональні вимоги до програмного комплексу:
1 Реалізація пошуку музики за запитом користувача: Бот повинен обробляти
текстові повідомлення з назвою треку або виконавця та повертати
відповідний аудіофайл.
2 Підтримка черги запитів: При надходженні нових запитів під час обробки
попереднього, бот повинен повідомити користувача про очікування та
автоматично перейти до наступного запиту після завершення попереднього.
3 Завантаження та обробка аудіо: Бот повинен завантажувати музичний
контент з YouTube, конвертувати його в аудіоформат та відправляти
користувачу. Для цього використовуються yt-dlp та ffmpeg.
19
ЧДТУ 252166.017 ПЗ
4 Обробка YouTube-плейлистів: У разі, якщо користувач надає посилання на
плейлист, бот повинен поетапно обробляти кожен трек та надсилати у
відповідь.
5 Механізм обмеження та безпеки: Бот повинен мати захист від надмірного
навантаження (rate limiting), фільтрацію некоректних запитів та запобігання
спаму;
6 Швидкість реагування: Затримка між надсиланням запиту користувача та
початком обробки не повинна перевищувати 1 секунду. Загальний час
відповіді при нормальному завантаженні – до 10 секунд;
7 Рекомендована стабільність роботи при безперервному використанні
протягом щонайменше 24 годин без збоїв або витоку пам’яті.
Для розробки бізнес-логіки бота використовується мова програмування Python
з фреймворком aiogram, який забезпечує ефективну обробку подій Telegram API. Для
завантаження аудіо з YouTube використовується yt-dlp, для його обробки – ffmpeg.
Середовище розробки – PyCharm, з підтримкою віртуальних середовищ, Git та
налагодження коду. Для тестування функціональності Telegram-бота застосовується
Postman для REST-запитів і перевірки відповіді сервера Railway. Тестування
охоплює: модульне, інтеграційне, системне та приймальне тестування, що гарантує
надійність та відповідність розробленого програмного продукту очікуванням
користувачів.
20
ЧДТУ 252166.017 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто основні поняття, пов’язані з Telegram-
ботами для прослуховування музики, проведено аналіз існуючих рішень на ринку, а
також описано технології, які використовуються для їх реалізації. Було виявлено, що
Telegram-боти надають зручний та швидкий спосіб доступу до музичного контенту,
особливо завдяки інтеграції з платформами на кшталт YouTube.
Проаналізовані приклади існуючих ботів, зокрема @Shazambot, @YtbAudioBot
та @AusensBot, дозволили виокремити їх сильні та слабкі сторони. Це дало змогу
сформулювати чітке бачення функціоналу, якого має досягти власний Telegram-бот,
а також уникнути поширених недоліків аналогічних рішень.
У розділі також охарактеризовано сучасні методи та засоби реалізації Telegram-
ботів, зокрема використання Python, бібліотеки aiogram, інструментів yt-dlp і ffmpeg,
а також хмарної платформи Railway. Це дозволяє забезпечити ефективну обробку
запитів, завантаження та обробку аудіо, чергову обробку запитів і надійну роботу в
режимі 24/7.
У результаті було сформульовано чітке технічне завдання для реалізації
Telegram-бота, який буде орієнтований на користувацький комфорт,
функціональність, швидкість обробки запитів і масштабованість. У подальших
розділах буде здійснено розробку та тестування такого програмного рішення.
21
ЧДТУ 252166.017 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
2.1 Моделювання предметної області
Моделювання предметної області – це фундаментальний етап розробки
програмного забезпечення, який дозволяє формалізувати знання про функціонування
системи, визначити її основні об’єкти, властивості та взаємозв’язки між ними. У
рамках даного дипломного проєкту розроблено Telegram-бот під назвою MusicBot,
який забезпечує автоматизований пошук музичних треків на платформі YouTube, їх
завантаження у форматі mp3 та доставлення кінцевому користувачу через чат-
інтерфейс Telegram.
У цій предметній області ключовою є інтеграція з зовнішнім API (YouTube),
конвертація відеоконтенту в аудіоформат та асинхронна обробка запитів
користувачів у черзі з урахуванням обмежень Telegram API.
Метою моделювання є побудова логічної структури функціонування бота, що
включає користувача, його запити, процеси пошуку та завантаження контенту, а
також внутрішні механізми синхронізації, зокрема чергу обробки запитів.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область Telegram-бота MusicBot охоплює обробку
мультимедійних запитів, інтеграцію з YouTube, обробку аудіофайлів, взаємодію з
Telegram API та користувачем. Система повинна підтримувати пошук треків за
текстовим запитом, обробку YouTube-плейлистів, конвертацію відео в аудіоформат,
завантаження та доставку контенту користувачу, управління чергою запитів, а також
обробку помилок і тайм-аутів. Крім того, бот має забезпечувати зручний і швидкий
інтерфейс для користувача, мінімізуючи час очікування. Розширюваність архітектури
дозволяє легко додавати нові функції або інтегрувати додаткові сервіси.
22
ЧДТУ 252166.017 ПЗ
Рисунок 2.1 – Модель предметної області музиичного телеграм-бота
23
ЧДТУ 252166.017 ПЗ
Модель предметної області бота описує основні компоненти системи:
користувача, запит, трек, плейлист, чергу обробки та взаємозв’язки між ними. Всі
сутності взаємодіють у межах асинхронного робочого середовища з можливістю
обробки кількох одночасних запитів по черзі. Telegram використовується як основний
інтерфейс.
Словник предметної області
‒ користувач – Telegram-клієнт, який взаємодіє з ботом, надсилаючи запити;
‒ запит – повідомлення від користувача: назва пісні або посилання на відео;
‒ трек – аудіофайл у форматі mp3, створений внаслідок обробки запиту;
‒ плейлист – YouTube-плейлист, що містить множину відео для
завантаження;
‒ черга – система обробки запитів послідовно у порядку надходження;
‒ yt-dlp – бібліотека для завантаження відео з YouTube;
‒ ffmpeg – інструмент для конвертації відео в аудіоформат;
‒ aiogram – Python-фреймворк для створення Telegram-ботів;
‒ dispatcher – компонент, що відповідає за маршрутизацію повідомлень у
aiogram;
‒ handler – функція-обробник певного типу вхідного повідомлення;
‒ Telegram API – інтерфейс, через який бот надсилає повідомлення,
аудіофайли тощо.
2.1.2 Елементи моделювання предметної області
У цьому підрозділі представлено детальний опис основних сутностей, які
формують логічну модель системи, а також наведено їх ключові атрибути та
взаємозв’язки між собою. Розуміння цих сутностей є критично важливим для
побудови структурованої архітектури, що забезпечує ефективну роботу Telegram-
бота MusicBot.
1 Користувач (User)
Опис: Користувач Telegram, який взаємодіє з ботом.
Атрибути:
‒ унікальний ідентифікатор користувача (Telegram) (user_id);
24
ЧДТУ 252166.017 ПЗ
‒ нікнейм користувача (username);
‒ час останнього запиту (last_request_time).
2 Запит (Request)
Опис: Повідомлення користувача, яке запускає процес пошуку музики.
Атрибути:
‒ унікальний ідентифікатор запиту (request_id);
‒ відправник запиту (user_id);
‒ текст запиту або посилання (query_text);
‒ статус (waiting, processing, done, error) (status);
‒ дата й час запиту (timestamp).
3 Трек (Track)
Опис: Результат пошуку – mp3-файл, отриманий з відео.
Атрибути:
‒ ідентифікатор (track_id);
‒ пов’язаний запит (request_id);
‒ назва треку (title);
‒ тривалість (duration);
‒ шлях до збереженого аудіо (file_path).
4 Плейлист (Playlist)
Опис: Набір треків, витягнутий з одного посилання.
Атрибути:
‒ ідентифікатор (playlist_id);
‒ назва плейлиста (title);
‒ список об'єктів track (track_list);
‒ зв’язок із запитом (request_id).
5 Черга (Queue)
Опис: Механізм, який керує обробкою запитів по черзі.
Атрибути:
‒ масив запитів у стані очікування (pending_requests);
‒ поточний запит, що обробляється (active_request).
25
ЧДТУ 252166.017 ПЗ
Взаємозв'язки між об'єктами:
1 Користувач (User) ↔ Запит (Request)
‒ один користувач може надіслати багато запитів;
‒ кожен запит належить лише одному користувачу.
Взаємозв'язок: 1 користувач → багато запитів (One-to-Many).
2 Запит (Request) ↔ Трек (Track)
‒ один запит може містити один або кілька треків (наприклад, у випадку
плейлиста);
‒ кожен трек пов'язаний із конкретним запитом.
Взаємозв'язок: 1 запит → багато треків (One-to-Many).
3 Запит (Request) ↔ Плейлист (Playlist)
‒ запит може бути пов'язаний з плейлистом, якщо надане посилання веде
на youtube playlist;
‒ один плейлист створюється лише на основі одного запиту.
Взаємозв'язок: 1 запит → 1 плейлист (One-to-One).
4 Плейлист (Playlist) ↔ Трек (Track)
‒ один плейлист містить багато треків;
‒ кожен трек з плейлиста знає, до якого плейлиста він належить.
Взаємозв'язок: 1 плейлист → багато треків (One-to-Many).
5 Черга (Queue) ↔ Запити (Request)
‒ черга містить набір запитів, що очікують на обробку;
‒ активний запит знаходиться окремо у статусі "обробляється".
Взаємозв'язок: багато запитів → одна черга (Many-to-One).
2.1.3 Робоча область моделювання
Робоча область моделювання Telegram-бота охоплює комплекс технічних та
логічних аспектів, необхідних для забезпечення коректної та ефективної взаємодії
користувача з програмним забезпеченням. Основними компонентами є інтеграція з
Telegram Bot API для отримання та надсилання повідомлень, асинхронна обробка
запитів для підвищення продуктивності та уникнення блокування потоку, а також
реалізація логіки пошуку й завантаження аудіоконтенту за допомогою сторонніх
26
ЧДТУ 252166.017 ПЗ
інструментів, таких як yt-dlp для отримання даних з YouTube та ffmpeg для обробки
медіафайлів.
Особливу увагу приділено впровадженню системи черги запитів, яка
забезпечує послідовну обробку кожного користувацького запиту без виникнення
конфліктів і дублювання процесів. Це дозволяє гарантувати стабільну роботу бота
навіть у випадку високого навантаження або великої кількості одночасних
користувачів.
Для формалізації логіки, структури та взаємозв’язків усіх ключових
компонентів Telegram-бота були розроблені відповідні UML-діаграми. Діаграма
класів дозволяє візуально представити основні сутності системи, їх атрибути та
взаємозв’язки. Діаграма прецедентів ілюструє типові сценарії взаємодії користувача
з ботом. Діаграма компонентів описує архітектурну структуру програмного
забезпечення, включаючи зовнішні бібліотеки та модулі. Діаграми діяльності та
послідовності демонструють динаміку виконання запитів, включаючи черговість дій
і обмін повідомленнями між компонентами системи.
Загалом, модельна частина проєкту забезпечує наочне уявлення про внутрішню
будову системи, полегшує подальшу розробку, тестування й супровід Telegram-бота.
2.2 Формування та аналіз вимог
У цьому розділі акцентована увага на формуванні та аналізі вимог до інтернет-
магазину мобільної техніки, що є важливим етапом у процесі розробки будь якого
програмного комплексу. Вимоги визначають, що система інтернет-магазину повинна
робити, і як вона повинна працювати.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги
Первинні вимоги формуються на основі загального бачення призначення
системи і основних задач, які вона повинна вирішувати. У випадку MusicBot ці
вимоги наступні:
‒ система повинна забезпечити зручний і швидкий доступ до аудіоконтенту з
youtube через telegram;
27
ЧДТУ 252166.017 ПЗ
‒ користувач повинен мати можливість надсилати текстовий запит або
посилання на відео/плейлист;
‒ telegram-бот повинен завантажити відповідний трек, конвертувати його у
формат .mp3 і надіслати назад у чат;
‒ усі запити мають оброблятись по черзі, без втрати або блокування системи.
Детальні вимоги конкретизують окремі функціональні аспекти системи, що
реалізуються на рівні коду, бібліотек і взаємодії з API:
‒ система повинна підтримувати як одиничні відеозапити, так і плейлисти з
youtube (обробка кількох треків послідовно);
‒ telegram-бот повинен інформувати користувача про стан обробки запиту;
‒ бот має обробляти помилки (наприклад, недійсне посилання або недоступне
відео) і повідомляти про них користувача.
У процесі розробки програми виникають дві основні групи вимог: вимоги
замовника та вимоги розробника.
Вимоги замовника – ці вимоги відображають очікування кінцевого
користувача:
‒ простота у використанні – взаємодія лише через telegram;
‒ мінімальні очікування часу відповіді;
‒ висока якість аудіофайлу;
‒ підтримка плейлистів для отримання кількох треків за один запит;
‒ інформування про статус обробки запиту.
Вимоги розробника – ці вимоги базуються на технічних реаліях, що
забезпечують стабільність і масштабованість системи::
‒ використання бібліотек yt-dlp, ffmpeg та aiogram;
‒ побудова асинхронного циклу обробки з чергою запитів (asyncio.queue або
власна черга);
‒ можливість запуску на будь-якому сервері з підтримкою 3.10+.
Функціональні вимоги – це вимоги, які безпосередньо визначають
функціональність Telegram-бота:
‒ реєстрація бота через botfather і обробка команди /start;
28
ЧДТУ 252166.017 ПЗ
‒ обробка текстових повідомлень, що містять назву треку або посилання на
відео/плейлист;
‒ пошук відео на youtube за текстом (через yt-dlp);
‒ завантаження відео, конвертація у .mp3, надсилання файлу;
‒ повідомлення про стан (пошук, черга, помилка);
‒ обробка плейлистів – поетапне завантаження треків;
‒ виведення підсумкового повідомлення після завершення обробки.
Нефункціональні вимоги – ці вимоги стосуються якості функціонування, а не
функціоналу системи:
‒ продуктивність: відповідь на одиничний запит – не більше 10 секунд;
‒ безпека: немає збереження персональних даних; усі дії – у межах telegram-
чату;
‒ надійність: система повинна обробляти всі запити без втрати даних;
‒ масштабованість: можливість обробки запитів від кількох користувачів
послідовно;
‒ зручність: інтерфейс – стандартне листування в telegram.
2.2.2 Формування вимог за допомогою діаграми прецедентів.
Діаграма прецедентів (use case diagram) – це один із типів діаграм UML, який
описує функціональні вимоги до системи з точки зору взаємодії користувачів
(акторів) із системою. Вона відображає основні сценарії використання системи,
показує, які дії може виконувати користувач, і як система реагує на ці дії.
Ключовими елементами діаграми є:
‒ актори – зовнішні користувачі або інші системи, що взаємодіють із
досліджуваною системою;
‒ прецеденти (випадки використання) – дії або функції, які система виконує у
відповідь на запити акторів;
‒ зз’язки – лінії, що показують взаємодію між акторами та прецедентами.
Ця діаграма є корисним інструментом для початкового етапу проєктування,
оскільки допомагає чітко визначити вимоги до системи та зрозуміти очікувану
поведінку з точки зору користувача.
29
ЧДТУ 252166.017 ПЗ
Рисунок 2.2 – Діаграма прецедентів музиичного телеграм-бота
Опис Прецедентів
Надалі наданий перелік основних прецедентів, що відображають функціональні
можливості програмного забезпечення:
1 Запуск бота
Актори: Користувач.
Опис: Користувач ініціює взаємодію з ботом за допомогою команди /start.
30
ЧДТУ 252166.017 ПЗ
Далі надані кроки користувача.
1 Користувач надсилає повідомлення /start.
2 Користувач очікує відповіді від бота.
Результат: користувач отримує привітальне повідомлення з короткою
інструкцією користування ботом.
2 Надсилання запиту на завантаження треку
Актори: Користувач.
Опис: Користувач надсилає запит із назвою пісні або посиланням на YouTube-
відео.
Далі надані кроки користувача.
1 Користувач вводить текстовий запит або вставляє посилання на відео.
2 Користувач надсилає повідомлення в чат.
3 Користувач отримує повідомлення про початок пошуку або про
наявність черги.
4 Користувач очікує завершення завантаження.
5 Користувач отримує mp3-файл з треком.
Результат: користувач отримує конвертований аудіофайл у чаті Telegram.
3 Надсилання запиту під час активного завантаження
Актори: Користувач.
Опис: Користувач надсилає запит, поки інший запит ще обробляється.
Далі надані кроки користувача.
1 Користувач надсилає запит у чат.
2 Користувач отримує повідомлення “Please wait for the current track to
finish”.
3 Користувач очікує, поки система завершить попередній запит.
4 Користувач отримує повідомлення “Now searching for the next track...”
після завершення попереднього запиту.
Результат: запит користувача обробляється у порядку черги після завершення
поточного завантаження.
31
ЧДТУ 252166.017 ПЗ
4 Завантаження YouTube-плейлиста
Актори: Користувач.
Опис: Користувач надсилає посилання на плейлист для послідовного
завантаження декількох треків.
Далі надані кроки користувача.
1 Користувач вставляє посилання на YouTube-плейлист.
2 Користувач надсилає запит у чат.
3 Користувач отримує повідомлення про початок обробки плейлиста.
4 Користувач очікує послідовного отримання mp3-файлів із кожного
відео.
Результат: користувач отримує в чаті кілька треків, завантажених із плейлиста.
5 Обробка помилки (некоректний запит)
Актори: Користувач.
Опис: Користувач надсилає некоректний запит (недійсне посилання, відео
недоступне або перевищено ліміт Telegram).
Далі надані кроки користувача.
1 Користувач надсилає повідомлення із запитом.
2 Користувач очікує обробки.
3 Користувач отримує повідомлення про помилку з описом проблеми.
Результат: користувач інформується про помилку та має змогу скорегувати свій
запит.
2.3 Проектування логічної структури програмного комплексу
Проєктування логічної структури програмного комплексу є ключовим етапом у
процесі розробки, під час якого визначаються основні функціональні компоненти
системи, їхні завдання, роль у загальній архітектурі та взаємозв’язки між ними. На
цьому етапі формується абстрактна модель програмного забезпечення, яка дозволяє
описати логіку обробки даних, потоки інформації та механізми взаємодії між
окремими модулями без прив’язки до конкретної мови програмування, середовища
виконання або технічних деталей реалізації.
32
ЧДТУ 252166.017 ПЗ
Головною метою логічного проєктування є створення узагальненої структури,
яка виступає основою для подальших етапів фізичного проєктування та реалізації.
Така модель забезпечує чітке розуміння функціональних можливостей системи,
дозволяє виявити потенційні проблеми ще до початку кодування та дає змогу
зосередитися на логіці роботи програми.
Логічне проєктування також значно спрощує процес тестування, оскільки
дозволяє будувати модульні та інтеграційні тести на основі вже визначених
функціональних одиниць. Крім того, добре спроєктована логічна структура сприяє
зручному обслуговуванню та масштабуванню програмного комплексу в
майбутньому, що особливо важливо для проєктів із розрахунком на тривалий цикл
експлуатації або розширення функціоналу.
У підсумку, логічне проєктування виступає містком між аналізом вимог і
технічною реалізацією системи, забезпечуючи основу для якісної, структурованої та
гнучкої архітектури програмного забезпечення.
2.3.1 Діаграми класів
Рисунок 2.3 – Спрощена діаграма класів музиичного телеграм-бота
33
ЧДТУ 252166.017 ПЗ
Рисунок 2.4 – Діаграма класів музиичного телеграм-бота
Опис кожної таблиці з атрибутами:
1 User (Користувач)
Зберігає інформацію про користувача, який надсилає запити боту.
‒ user_id: int – унікальний ідентифікатор користувача;
‒ username: str – ім’я користувача (Telegram-нік);
‒ last_request_time: datetime – час останнього запиту від цього
користувача.
34
ЧДТУ 252166.017 ПЗ
2 Request (Запит)
Представляє музичний запит, який користувач надіслав боту;
‒ request_id: int – унікальний ідентифікатор запиту;
‒ user: user – користувач, який створив запит;
‒ query_text: str – текст запиту (наприклад, назва треку або посилання);
‒ status: str – статус запиту (наприклад, "очікує", "виконується",
"завершено");
‒ timestamp: datetime – час створення запиту.
3 QueueManager (Менеджер черги)
Керує чергою запитів, що обробляються ботом.
‒ pending_requests: list<request> – список запитів, які ще не були
оброблені;
‒ active_request: Request – поточний запит, що обробляється.
4 Playlist (Плейлист)
Містить список треків, що були отримані в результаті одного запиту
(наприклад, якщо користувач надіслав посилання на YouTube-плейлист).
‒ playlist_id: int – унікальний ідентифікатор плейлиста;
‒ request: Request – запит, який згенерував цей плейлист;
‒ title: str – назва плейлиста;
‒ tracks: list<track> – мписок треків, що входять до плейлиста.
5 Track (Трек)
Представляє окремий музичний трек, що був знайдений і оброблений на основі
запиту.
‒ track_id: int – унікальний ідентифікатор треку;
‒ request: Request – запит, у результаті якого був знайдений трек;
‒ title: str – назва треку;
‒ duration: str – тривалість треку;
‒ file_path: str – шлях до збереженого аудіофайлу;
‒ youtube_url: str – посилання на трек на YouTube.
35
ЧДТУ 252166.017 ПЗ
Зв'язки між таблицями:
‒ один user може створити багато request;
‒ один request може бути оброблений queuemanager, створити один playlist та
багато track;
‒ один playlist включає багато track;
‒ кожен track пов’язаний із одним request (але може входити до плейлиста).
2.3.2 Діаграма пакетів
Рисунок 2.5 – Діаграма пакетів музиичного телеграм-бота
Логічна структура Telegram-бота MusicBot реалізована у вигляді чітко
структурованих модулів і пакетів, кожен з яких відповідає за окремий компонент або
функціональність системи. Такий підхід до організації коду забезпечує розділення
відповідальностей між різними частинами програми, що є важливою складовою
якісної архітектури програмного забезпечення.
Кожен модуль виконує конкретне завдання. Це дозволяє легко орієнтуватися в
структурі проєкту, швидко знаходити та змінювати потрібний фрагмент коду, а також
спрощує процес налагодження та автоматичного тестування.
36
ЧДТУ 252166.017 ПЗ
1 Пакет bot
Файл: main.py
Призначення: Головна точка входу в застосунок. Запускає бота, ініціалізує
обробники команд і плеєрів, виконує налаштування.
Зв’язки:
‒ викликає обробники команд із handlers/commands.py;
‒ передає обробку плейлистів у handlers/playlist_handler.py;
‒ використовує налаштування з config/config.py.
2 Пакет handlers
Файли:
‒ commands.py: Обробляє основні команди користувача (наприклад,
пошук треків);
‒ playlist_handler.py: Відповідає за обробку запитів на відтворення
плейлистів.
Зв’язки:
commands.py:
‒ використовує utils/youtube.py для пошуку музики;
‒ викликає utils/downloader.py для завантаження треків;
‒ звертається до utils/queue_manager.py для перевірки черги.
playlist_handler.py:
‒ взаємодіє з queue_manager.py для керування чергою;
3 Пакет config
Файл: config.py
Призначення: Містить налаштування для запуску та роботи бота (токен,
параметри API тощо).
Зв’язки:
‒ використовується в main.py для ініціалізації параметрів бота.
37
ЧДТУ 252166.017 ПЗ
4 Пакет utils
Файли:
‒ youtube.py: Пошук музики на YouTube за ключовими словами або
посиланням;
‒ downloader.py: Завантаження аудіофайлів із YouTube;
‒ queue_manager.py: Перевірка та керування чергою запитів на
відтворення.
Зв’язки:
‒ youtube.py викликається з commands.py для пошуку музики;
‒ downloader.py викликається з commands.py для завантаження треків;
‒ queue_manager.py використовується як у commands.py, так і у
playlist_handler.py для керування чергою.
Загальний принцип взаємодії:
1 Користувач надсилає команду → main.py передає її в commands.py.
2 commands.py виконує пошук через youtube.py, завантаження через
downloader.py, додає завдання до черги через queue_manager.py.
3 Якщо це плейлист – керування здійснює playlist_handler.py.
4 Налаштування для всієї системи зчитуються з config.py.
2.4 Архітектурне проектування
Архітектурне проєктування є одним із найважливіших етапів розробки
програмного забезпечення, на якому формується загальне бачення структури
системи. У рамках цього процесу визначаються основні компоненти програмного
комплексу, їх функціональне призначення, способи взаємодії між собою, а також
обираються відповідні технології, інструменти та платформи для реалізації.
Архітектура системи визначає, яким чином будуть організовані всі частини програми,
як вони будуть взаємодіяти з користувачем, зовнішніми сервісами та апаратним
забезпеченням.
38
ЧДТУ 252166.017 ПЗ
Метою архітектурного проєктування є побудова надійної, масштабованої та
гнучкої структури, яка зможе не лише задовольнити всі функціональні вимоги
замовника, але й відповідати нефункціональним характеристикам, таким як
продуктивність, безпека, підтримуваність, адаптивність до змін та можливість
подальшого розширення. Правильно спроєктована архітектура дозволяє уникнути
критичних помилок на пізніших етапах розробки, зменшує технічні ризики та
забезпечує ефективне використання ресурсів.
Результатом цього етапу є створення архітектурної моделі або схеми, яка
включає в себе опис усіх основних модулів, інтерфейсів, механізмів обміну даними,
а також обґрунтування вибору технологій. Така модель виступає своєрідною
«дорожньою картою» для подальшої деталізації, кодування, тестування та
впровадження системи. Вона також є основою для координації роботи команди
розробників, оскільки дозволяє забезпечити узгоджене розуміння структури
програмного продукту.
Таким чином, архітектурне проєктування є критично важливою фазою, що
закладає фундамент для ефективної реалізації та тривалої експлуатації програмного
забезпечення.
2.4.1 Діаграма компонентів
Огляд ключових структурних елементів і логічних блоків архітектури Telegram-
бота MusicBot охоплює детальний аналіз внутрішньої організації системи, що
забезпечує чітку, злагоджену взаємодію між усіма її компонентами. Архітектура
побудована таким чином, щоб гарантувати не лише ефективну обробку запитів
користувачів, а й стабільну роботу сервісу в умовах навантаження. Основні
структурні елементи охоплюють модулі обробки повідомлень, черги запитів, блоки
завантаження та обробки медіаконтенту, а також механізми асинхронної взаємодії,
що дозволяють уникнути блокувань під час виконання тривалих операцій:
1 Telegram Client:
‒ опис: це клієнтський застосунок (мобільний/десктопний telegram), через
який користувач взаємодіє з ботом;
39
ЧДТУ 252166.017 ПЗ
‒ функції: надсилання команд та запитів, отримання повідомлень, mp3-
файлів, інструкцій.
2 Telegram Bot API (Gateway):
‒ опис: проміжний сервер telegram, що пересилає запити до бота і назад –
відповіді до користувача;
‒ функції: прийом текстових повідомлень, команд, відправлення
аудіофайлів користувачу.
3 Bot Server (MusicBot Application):
‒ опис: основна серверна частина системи, реалізована на python з
використанням фреймворку aiogram;
‒ підкомпоненти: commandhandler, requesthandler, queuemanager,
downloader, converter.
4 Storage (Файлова система):
‒ опис: локальне або тимчасове сховище для збереження відео– та
аудіофайлів перед їх надсиланням;
‒ функції: збереження завантажених відеофайлів, зберігання mp3-файлів
для telegram.
Зв'язки між компонентами:
‒ Telegram Client ↔ Telegram Bot API;
‒ Telegram Bot API ↔ Bot Server;
‒ Bot Server ↔ yt-dlp, ffmpeg;
‒ Bot Server ↔ Файлова система;
‒ Bot Server ↔ Telegram Bot API (для надсилання результату).
40
ЧДТУ 252166.017 ПЗ
Рисунок 2.6 – Діаграма компонентів музиичного телеграм-бота
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Опис розгортання програмної системи на апаратних засобах:
Telegram-бот MusicBot розгорнутий як серверна програма на хмарній
платформі Railway, що дозволяє автоматично запускати Python-додатки, керувати
середовищем виконання та зберігати секрети, зокрема токен бота, у змінних оточення
(Variables). Така інфраструктура дозволяє швидко і безпечно розгорнути бот у
продакшн. Архітектура розгортання:
41
ЧДТУ 252166.017 ПЗ
1 Клієнтський пристрій:
‒ призначення: надсилання запитів до telegram;
‒ програмне забезпечення: telegram app.
2 Telegram Gateway (API):
‒ призначення: проміжний шлюз між користувачем і ботом;
‒ програмне забезпечення: telegram bot api.
3 Сервер Railway:
‒ призначення: хостинг і виконання telegram-бота;
‒ програмне забезпечення: python 3.10+, railway.
4 yt-dlp:
‒ призначення: завантаження відео з youtube;
‒ програмне забезпечення: python-бібліотека.
5 ffmpeg:
‒ призначення: конвертація відео у mp3;
‒ програмне забезпечення: зовнішня утиліта.
6 Файлова система Railway:
‒ призначення: тимчасове збереження mp3-файлів;
‒ програмне забезпечення: tmp-директорія контейнера.
Опис середовища:
‒ розгортання: репозиторій github інтегровано з railway;
‒ ci/cd: автоматичне оновлення після пушу до репозиторію;
‒ secrets: telegram bot token збережено в variables;
‒ автоматичний запуск: railway запускає сервіс у режимі polling;
‒ обмеження: збереження mp3-файлів тимчасове, після надсилання telegram
вони видаляються.
Взаємодія вузлів:
– користувач взаємодіє з ботом через telegram;
– telegram bot api надсилає запити до railway-сервера;
42
ЧДТУ 252166.017 ПЗ
– railway запускає код бота, який обробляє запит;
– yt-dlp та ffmpeg виконують завантаження і конвертацію.
– Результат надсилається користувачу через Telegram API.
Рисунок 2.7 – Діаграма розгортання музиичного телеграм-бота
43
ЧДТУ 252166.017 ПЗ
2.5 Моделювання поведінки системи
Моделювання поведінки системи – це процес створення моделей, які описують,
як система реагує на внутрішні та зовнішні події протягом свого функціонування.
Основна мета цього етапу – відобразити динамічні аспекти роботи системи, її реакції
на дії користувачів або інші сигнали, а також зміну станів об'єктів.
2.5.1 Діаграма діяльності
Опис діаграми діяльності:
1 Запуск взаємодії:
‒ користувач запускає telegram-бота (команда /start) або надсилає
повідомлення;
‒ бот аналізує тип запиту: текстовий запит або посилання.
2 Обробка черги:
‒ якщо інший запит обробляється – користувачу виводиться повідомлення
“please wait for the current track to finish”, запит зберігається у чергу;
‒ якщо черга порожня – запит передається в обробку.
3 Пошук і завантаження:
‒ бот визначає, чи це одиночне відео чи плейлист;
‒ запускається завантаження відповідного відео через yt-dlp.
4 Конвертація:
‒ після завантаження відео викликається ffmpeg;
‒ відео конвертується у формат mp3.
5 Надсилання:
‒ готовий mp3-файл надсилається у чат telegram;
‒ якщо є інші запити в черз – бот переходить до наступного.
6 Завершення:
‒ тимчасові файли видаляються;
‒ завершується обробка запиту.
44
ЧДТУ 252166.017 ПЗ
Рисунок 2.8 – Діаграма діяльності музиичного телеграм-бота
45
ЧДТУ 252166.017 ПЗ
2.5.2 Діаграма послідовності
Рисунок 2.9 – Діаграма послідовності музиичного телеграм-бота
Основні етапи взаємодії описані нижче:
1 Отримання запиту
‒ користувач → telegram: надсилає запит (текст або посилання);
‒ telegram → бот: пересилає повідомлення.
2 Обробка повідомлення
‒ бот перевіряє чергу;
46
ЧДТУ 252166.017 ПЗ
‒ якщо черга порожня – одразу переходить до завантаження;
‒ якщо черга непорожня – ставить запит у чергу.
3 Завантаження та обробка
‒ бот → yt-dlp: виконує запит для завантаження відео;
‒ yt-dlp → бот: передає інформацію про файл;
‒ бот → ffmpeg: виконує конвертацію в mp3.
4 Надсилання результату
‒ бот → telegram api: надсилає аудіофайл користувачу;
‒ telegram api → користувач: отримує готовий mp3.
5 Перехід до наступного
‒ бот → черга: витягує наступний запит і повторює цикл.
2.5.3 Діаграма комунікації
Основні етапи взаємодії:
1 Отримання текстового запиту
Мета: Прийняти текстове повідомлення користувача (назва треку або
посилання) для подальшої обробки.
Далі наведені ключові кроки взаємодії.
1 Користувач надсилає повідомлення у чат Telegram.
2 Telegram API перенаправляє повідомлення до Telegram-бота.
3 Dispatcher (бібліотека aiogram) викликає відповідний Handler.
4 Handler передає запит до модуля QueueManager.
5 Якщо бот не зайнятий – виконується завантаження через Downloader.
2 Завантаження відео з YouTube
Мета: Завантажити відео або аудіо з YouTube за запитом користувача.
Далі наведені ключові кроки взаємодії.
1 Handler викликає функцію download_audio() з модуля Downloader.
2 Downloader взаємодіє з утилітою yt-dlp, передаючи URL або пошуковий
запит.
3 yt-dlp повертає завантажений файл або метадані.
47
ЧДТУ 252166.017 ПЗ
4 Downloader передає шлях до завантаженого відео для конвертації.
3 Конвертація відео в аудіо
Мета: Перетворити відеофайл у формат .mp3 за допомогою ffmpeg.
Далі наведені ключові кроки взаємодії.
1 Converter приймає шлях до відеофайлу.
2 Converter викликає системну команду через ffmpeg для витягнення
аудіо.
3 Після успішної обробки, Converter повертає шлях до mp3-файлу.
4 Файл передається Handler для надсилання.
4 Надсилання результату користувачу
Мета: Передати готовий трек користувачу в Telegram.
Далі наведені ключові кроки взаємодії.
1 Handler надсилає аудіофайл через Telegram API.
2 Користувач отримує mp3-файл у чаті.
3 У разі обробки плейлиста – виконується повторення кроків для кожного
треку.
4 Після завершення – бот надсилає повідомлення про завершення або
переходить до наступного запиту в черзі.
5 Обробка помилок
Мета: Повідомити користувача про проблему у разі помилки на будь-якому з
етапів.
Далі наведені ключові кроки взаємодії.
1 Якщо на етапі завантаження виникає помилка – Downloader генерує
виняток.
2 Handler перехоплює виняток і формує відповідь.
3 Користувач отримує повідомлення про невдалий запит із поясненням.
6 Перехід до наступного запиту
Мета: Забезпечити послідовну обробку кількох запитів у черзі.
Далі наведені ключові кроки взаємодії.
48
ЧДТУ 252166.017 ПЗ
1 QueueManager перевіряє наявність запитів у черзі.
2 Якщо черга не порожня – активується наступний запит.
3 Повторюється повний цикл взаємодії.
Рисунок 2.10 – Діаграма комунікації музиичного телеграм-бота
49
ЧДТУ 252166.017 ПЗ
2.5.4 Діаграма скінченого автомату
Опис основних компонентів діаграми взаємодії:
1 Користувач – взаємодіє з ботом, надсилаючи повідомлення.
2 Telegram API – посередник між користувачем і серверною частиною.
3 Сервер Telegram-бота – виконує обробку запиту.
4 Черга обробки – визначає порядок виконання запитів.
5 Зовнішні модулі – yt-dlp для завантаження, ffmpeg для конвертації.
6 Сховище – тимчасово зберігає файли.
Основні сценарії взаємодії відображено на діаграмі скінченного автомата, яка
ілюструє послідовність переходів між станами бота залежно від дій користувача.
Зокрема, показано стани очікування запиту, обробки введеної інформації, пошуку
музики, завантаження та надсилання аудіофайлу. Також враховано сценарії обробки
помилок і повторних запитів, які надходять до завершення попередньої операції.
Діаграма дозволяє чітко зрозуміти логіку роботи системи та її реакцію на різні події:
1 Отримання запиту
Процес: Користувач надсилає повідомлення у чат Telegram, яке пересилається
через Telegram API до бота.
Далі надано послідовність процесу.
1 Користувач надсилає повідомлення.
2 Telegram API доставляє повідомлення до сервера.
3 Бот змінює стан на "Очікує перевірку черги".
2 Перевірка черги
Процес: Бот визначає, чи може обробити запит негайно, чи поставити в чергу.
Далі надано послідовність процесу.
1 Якщо черга порожня – стан переходить до "Завантаження".
2 Якщо запит потрапляє в чергу – стан переходить у "Очікування".
3 Завантаження відео
Процес: yt-dlp виконує завантаження відео за запитом користувача.
50
ЧДТУ 252166.017 ПЗ
Далі надано послідовність процесу.
1 Бот запускає yt-dlp з параметрами пошуку або посилання.
2 Після завершення завантаження – перехід до стану "Конвертація".
4 Конвертація у формат mp3
Процес: ffmpeg витягує аудіо з відеофайлу.
Далі надано послідовність процесу.
1 Бот передає шлях до відео у ffmpeg.
2 ffmpeg створює аудіофайл.
3 У разі успіху – перехід до стану "Надсилання результату".
5 Надсилання результату користувачу
Процес: mp3-файл надсилається назад користувачеві через Telegram API.
Далі надано послідовність процесу.
1 Бот формує повідомлення з аудіофайлом.
2 Telegram API надсилає файл у чат.
3 Бот змінює стан на "Завершено".
6 Завершення обробки
Процес: Очистка тимчасових файлів та оновлення черги.
Далі надано послідовність процесу.
1 Видалення тимчасових відео та аудіо.
2 Якщо в черзі є наступний запит – перехід до обробки наступного.
3 Якщо черга порожня – повернення до стану "Очікування запиту".
7 Обробка помилки
Процес: У разі виняткової ситуації (наприклад, відео недоступне), бот інформує
користувача.
Далі надано послідовність процесу.
1 Виникає помилка (наприклад, yt-dlp не знайшов відео).
2 Бот формує повідомлення про помилку.
3 Стан змінюється на "Завершено з помилкою".
4 Перехід до наступного запиту або повернення до очікування.
51
ЧДТУ 252166.017 ПЗ
Рисунок 2.11 – Діаграма скінченого автомату музиичного телеграм-бота
52
ЧДТУ 252166.017 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі дипломної роботи проведено ґрунтовне впровадження
результатів дослідження у процес проєктування Telegram-бота MusicBot, що дозволяє
автоматизовано здійснювати пошук та доставку музичного контенту з YouTube до
користувачів через платформу Telegram. Детально змодельовано предметну область,
включаючи ключові сутності системи (користувач, запит, трек, плейлист, черга) та
визначено їх атрибути й взаємозв’язки.
Проаналізовано та формалізовано вимоги до програмного забезпечення – як
функціональні, так і нефункціональні – з урахуванням очікувань як користувачів, так
і розробників. Побудовано комплекс діаграм UML (діаграма прецедентів, класів,
компонентів, послідовності, діяльності тощо), які наочно ілюструють логіку
функціонування бота, структуру системи та динаміку її роботи. Також розроблено
архітектурну модель, що забезпечує масштабованість, гнучкість та продуктивність
системи в умовах реального використання.
Важливою частиною є реалізація механізму асинхронної черги, що гарантує
стабільну обробку запитів навіть за підвищеного навантаження. Розгортання на
платформі Railway демонструє ефективне використання хмарної інфраструктури для
безперервного сервісу.
Таким чином, у межах даного розділу створено концептуальну та технічну
основу для успішної реалізації Telegram-бота MusicBot, що дозволяє перейти до
практичної частини розробки, тестування та впровадження програмного продукту.
53
ЧДТУ 252166.017 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
Розробка програмного комплексу Telegram-бота MusicBot стала ключовим
етапом у реалізації мого дипломного проєкту. На цьому етапі результати аналізу
предметної області, сформульовані функціональні вимоги та технічні обмеження
були втілені у повноцінну програмну реалізацію. Основною метою проєкту стало
створення Telegram-бота, здатного шукати та надсилати аудіофайли з YouTube у
відповідь на запити користувачів, а також обробляти плейлисти, забезпечуючи
стабільну та чергову передачу треків.
Проєкт реалізовано за принципами модульної архітектури, що забезпечує
простоту масштабування та підтримки. Telegram-бот був реалізований на мові Python
із застосуванням бібліотек aiogram, yt_dlp, ffmpeg, asyncio, а також розгорнутий на
хмарній платформі Railway, що дозволяє забезпечити цілодобову доступність сервісу.
Зберігання конфіденційних даних (зокрема токена Telegram API) реалізовано через
.env файл, що захищений системою змінних середовища Railway.
Основні компоненти системи:
‒ telegram API – інтерфейс взаємодії з користувачем;
‒ менеджер черги запитів – забезпечує обробку лише одного запиту за раз;
‒ модуль завантаження медіа – реалізує пошук та конвертацію відео з
YouTube у формат .mp3;
‒ асинхронний планувальник – дозволяє уникнути блокування при обробці
великих плейлистів.
‒ система повідомлень – відповідає за інформування користувача про стан
завантаження, пошуку та черги.
3.1.1 Обґрунтування вибору засобів реалізації
Вибір засобів реалізації для MusicBot був зумовлений необхідністю
забезпечення високої швидкодії, асинхронної обробки запитів, підтримки взаємодії з
API Telegram та YouTube, а також простоти розгортання у хмарному середовищі.
Ураховуючи ці вимоги, було прийнято рішення використовувати мову
54
ЧДТУ 252166.017 ПЗ
програмування Python, яка добре підходить для створення Telegram-ботів завдяки
своїй простоті, великій кількості бібліотек та активному співтовариству.
Основною бібліотекою для інтеграції з Telegram API обрано aiogram, оскільки
вона забезпечує зручну реалізацію асинхронної логіки, що є критично важливим для
зменшення затримок при роботі з користувачем.
Для завантаження аудіо з YouTube використано yt_dlp – форк популярного
youtube-dl [5], який відрізняється стабільною підтримкою та широкими
можливостями при обробці відео та плейлистів. Для конвертації відео у формат .mp3
використано ffmpeg, що є галузевим стандартом обробки мультимедійних файлів.
Система реалізована із застосуванням асинхронної моделі програмування
(asyncio), що дозволяє ефективно обробляти одночасні запити, не блокуючи основний
потік виконання. Це критично важливо при роботі з великими YouTube-плейлистами
або одночасних запитах користувачів.
Хмарне розгортання реалізовано на платформі Railway, яка забезпечує
автоматичне створення середовища виконання, підтримує .env змінні, дозволяє легко
оновлювати додаток без складного налаштування серверної інфраструктури. Такий
підхід зменшує витрати на обслуговування сервера та забезпечує стабільну роботу
бота 24/7.
Таким чином, вибір інструментів базувався на критеріях продуктивності,
підтримки асинхронності, простоти використання, а також можливості
автоматичного розгортання у хмарному середовищі.
3.1.2 Опис структурної (функціональної) схеми
На рисунку 3.1 представлена структурна схема Telegram-бота MusicBot,а на
рисунку 3.2 – функціональна. Обидві схеми демонструть основні етапи обробки
запиту користувача – від надсилання команди до отримання аудіофайлу.
Користувач надсилає текстовий запит (наприклад, назву пісні або посилання на
плейлист) у чат із ботом. Цей запит обробляється за допомогою Telegram API, після
чого передається у внутрішній модуль керування чергою. Якщо попередній запит ще
не завершено, користувач отримує повідомлення «Please wait for the current track to
55
ЧДТУ 252166.017 ПЗ
finish.», і запит ставиться в чергу. Після завершення поточного завантаження система
переходить до обробки наступного запиту.
Модуль пошуку використовує бібліотеку yt_dlp, яка проводить запит до
YouTube та отримує посилання на відео або список треків з плейлисту. Відео
конвертується у .mp3 за допомогою ffmpeg, після чого відправляється користувачеві
у вигляді аудіофайлу.
Протягом усього процесу користувач отримує оновлення у вигляді повідомлень
Telegram: початок пошуку, очікування завершення черги, завершення обробки тощо.
Така схема дозволяє забезпечити зручну, зрозумілу і стабільну взаємодію з
користувачем, навіть при одночасній роботі з кількома запитами.
Рисунок 3.1 – Структурна схема музиичного телеграм-бота
56
ЧДТУ 252166.017 ПЗ
Рисунок 3.1 – Функціональна схема
3.1.3 Опис логічної схеми системи
Логічна схема Telegram-бота MusicBot побудована на послідовній та
ізольованій обробці запитів, що забезпечує уникнення конфліктів та повторної
обробки. У системі передбачено декілька логічних етапів:
1 Ініціалізація системи. При запуску бот підключається до Telegram API,
встановлює прослуховувачі повідомлень і готує середовище для обробки
запитів (asyncio.run(), завантаження змінних середовища з .env тощо).
2 Обробка вхідного запиту. Бот приймає повідомлення користувача. Якщо
попередній запит ще виконується, новий запит додається до черги. В
іншому випадку обробка починається негайно.
3 Завантаження даних з YouTube. Використовується yt_dlp, що або
завантажує перший результат за запитом, або послідовно завантажує треки
з YouTube-плейлисту. Обробка ведеться у тимчасовій директорії.
4 Конвертація у mp3. Після завантаження відео передається у ffmpeg, який
виконує конвертацію у формат .mp3.
5 Надсилання файлу користувачу. Telegram API використовується для
передачі mp3-файлу, після чого система переходить до наступного запиту з
черги.
57
ЧДТУ 252166.017 ПЗ
6 Завершення циклу. Після завершення всіх запитів бот очікує на нове
повідомлення. Система побудована так, щоб уникати зависань та повторної
обробки повідомлень.
Рисунок 3.2 – Блок-схема логічної роботи системи.
58
ЧДТУ 252166.017 ПЗ
3.1.4 Розробка бази даних
У процесі розробки Telegram-бота MusicBot, який здійснює пошук музичних
композицій на платформі YouTube та надсилає їх у вигляді аудіофайлів
користувачеві, було прийнято рішення не використовувати систему управління
базами даних (СУБД). Це рішення має низку аргументованих технічних і
функціональних причин:
1 Відсутність потреби у довготривалому зберіганні даних
MusicBot не потребує збереження станів користувачів, історії запитів або інших
даних, які мають зберігатися між сесіями роботи бота. Усі запити обробляються в
режимі реального часу, і результати не потребують подальшого аналізу чи обліку. Це
дозволяє уникнути зайвих залежностей від зовнішніх СУБД.
2 Статус «безстанового» застосунку (stateless architecture)
Бот функціонує як безстановий сервіс – кожен запит обробляється незалежно,
і результат надсилається користувачеві без потреби у контексті попередніх запитів.
Це спрощує логіку роботи бота та дозволяє масштабувати його або перезапускати без
втрати критичних даних.
3 Заміна збереження на тимчасову обробку
Для обробки кожного запиту використовується тимчасове зберігання – зокрема,
кеш-файли або тимчасові директорії для завантаження відео та конвертації їх у аудіо.
Ці файли автоматично видаляються після завершення процесу надсилання аудіо, тому
довготривале збереження не передбачено.
4 Безпека і приватність
Відсутність СУБД виключає потребу зберігати особисті дані користувачів,
ідентифікатори, IP-адреси або історію переглядів. Це позитивно впливає на рівень
безпеки та приватності, що є важливим у контексті використання сторонніх API
(YouTube) та месенджера Telegram.
5 Простота архітектури та підтримки
Завдяки відсутності бази даних, проєкт залишається максимально простим та
легким у розгортанні. Бота можна швидко задеплоїти на будь-якій хмарній платформі
59
ЧДТУ 252166.017 ПЗ
(наприклад, Railway або Heroku) без необхідності налаштування додаткових сервісів
чи з’єднань до бази даних.
Таким чином, для реалізації функціоналу Telegram-бота MusicBot використання
СУБД не є доцільним. Архітектура застосунку цілком задовольняє вимоги до обробки
запитів без потреби у довготривалому зберіганні інформації. Це дозволило досягти
простоти, гнучкості та високої швидкодії сервісу.
3.1.5 Розробка інтерфейсу користувача
У процесі розробки Telegram-бота MusicBot окрема розробка графічного
інтерфейсу користувача не здійснювалась. Це пов’язано з тим, що проєкт
реалізований у вигляді бота для месенджера Telegram, який вже містить вбудований
стандартний інтерфейс для взаємодії з ботами.
1 Telegram як середовище виконання інтерфейсу
Telegram надає єдиний уніфікований користувацький інтерфейс, який включає:
‒ вікно чату з ботом;
‒ текстове поле для введення запитів;
‒ кнопки швидкого доступу (inline-кнопки, reply-кнопки, меню команд);
‒ підтримку мультимедійного контенту (аудіо, відео, документи тощо).
Таким чином, користувачі взаємодіють з MusicBot у звичному для себе
середовищі без необхідності освоювати новий інтерфейс.
2 Використання бот-команд і повідомлень
Інтерфейс реалізовано шляхом надсилання користувачем текстових
повідомлень або команд (наприклад, посилань на відео або плейлисти з YouTube). Бот
реагує на ці запити, надсилаючи текстові відповіді (статуси) або аудіофайли. Таким
чином, уся взаємодія відбувається через інтуїтивно зрозумілий діалоговий інтерфейс,
який не потребує візуального дизайну або розмітки.
3 Переваги використання стандартного інтерфейсу Telegram
‒ кросплатформеність: один і той самий інтерфейс доступний на android,
ios, windows, macos, linux і у веб-версії telegram;
‒ зручність: користувачам не потрібно нічого встановлювати або вивчати
– усе виглядає знайомо;
60
ЧДТУ 252166.017 ПЗ
‒ швидкість розробки: немає потреби у верстці, front-end технологіях чи
дизайні;
‒ безпека та підтримка: telegram самостійно відповідає за безпечне
введення даних та стабільність інтерфейсу.
Інтерфейс користувача бота MusicBot повністю базується на стандартних
можливостях Telegram. Власна розробка графічного інтерфейсу не здійснювалась,
оскільки це не було необхідним з технічної точки зору. Такий підхід дозволив
зосередитись на функціональній частині проєкту, залишаючи взаємодію з
користувачем максимально простою, зрозумілою та зручною.
3.1.6 Опис розробки програмних компонентів
Telegram-бот MusicBot реалізований із дотриманням принципів модульності,
розділення відповідальностей та повторного використання коду, що дозволяє
забезпечити надійність, масштабованість та спрощене обслуговування програмної
системи. Основна мета розробки полягала у створенні асинхронного Telegram-бота,
здатного обробляти запити користувачів на завантаження аудіо з YouTube, а також
підтримувати чергу запитів та обробку YouTube-плейлистів.
Основні компоненти програмної системи:
1 Модуль взаємодії з Telegram (TelegramHandler)
Цей модуль побудований на основі бібліотеки aiogram та відповідає за:
‒ отримання текстових повідомлень від користувача;
‒ ініціалізацію бота та диспетчера;
‒ обробку команд /start, текстових запитів, а також повідомлень з
YouTube-посиланнями;
‒ надсилання повідомлень про поточний стан запиту: «Please wait for the
current track to finish.», «Now searching for the next track…», тощо.
Завдяки використанню декораторів @dp.message_handler() реалізовано зручну
маршрутизацію запитів за типом повідомлення.
2 Модуль черги запитів (QueueManager)
Один з найважливіших компонентів системи. Він реалізує:
‒ послідовну обробку запитів (один за раз);
61
ЧДТУ 252166.017 ПЗ
‒ буферизацію повідомлень у черзі;
‒ логіку переходу до наступного запиту тільки після завершення
попереднього.
Використання черги реалізовано на основі структури asyncio.Queue або змінної
is_processing, що дозволяє забезпечити простий, але ефективний механізм блокування
одночасної обробки декількох запитів, запобігаючи дублюванню роботи та
перевантаженню системи.
3 Модуль пошуку та завантаження медіа (YouTubeDownloader)
Цей компонент реалізований за допомогою бібліотеки yt_dlp і відповідає за:
‒ пошук відео на YouTube за текстовим запитом або URL;
‒ обробку YouTube-плейлистів із поетапним завантаженням кожного
треку;
‒ збереження відеофайлів у тимчасову директорію;
‒ завантаження у найвищій доступній якості із параметрами аудіо
(bestaudio).
Для отримання метаданих (назва треку, тривалість, автор тощо) також
використовується функціонал yt_dlp.
4 Модуль конвертації аудіо (AudioConverter)
Для конвертації відеофайлів у формат .mp3 використовується виклик системної
утиліти ffmpeg. Компонент виконує такі задачі:
‒ конвертація аудіо у формат, сумісний із Telegram (MP3, 128 кбіт/с);
‒ обробка назв файлів, видалення непотрібних символів;
‒ перевірка успішності завершення процесу перед надсиланням.
Цей модуль інтегровано з модулем YouTubeDownloader через асинхронну
функцію, що дозволяє уникати блокувань основного потоку.
5 Модуль відправки файлів (Sender)
Відповідає за:
‒ надсилання готового аудіофайлу користувачу;
‒ додавання супровідного підпису, назви треку;
62
ЧДТУ 252166.017 ПЗ
‒ видалення тимчасових файлів після відправки для оптимізації
використання пам’яті.
Забезпечено обробку помилок на етапі надсилання (наприклад, якщо Telegram
не приймає файл через розмір або неправильний формат).
6 Модуль конфігурації середовища (ConfigManager)
У даному компоненті реалізовано:
‒ завантаження змінних середовища з .env файлу за допомогою бібліотеки
dotenv [10];
‒ приховування токена Telegram API при публікації коду;
‒ підтримка окремих параметрів конфігурації для Railway.
Це дозволяє відокремити логіку та конфігурацію, що є хорошою практикою з
точки зору безпеки та масштабованості.
7 Хмарне середовище розгортання (Railway integration)
Завдяки використанню Railway реалізовано:
‒ автоматичне розгортання при пуші до GitHub;
‒ зберігання токена Telegram API у змінних середовища;
‒ зручне масштабування та моніторинг логів у веб-інтерфейсі;
‒ запуск фонових процесів (бота) без потреби в окремому сервері.
Railway дає змогу підтримувати стабільну роботу бота без постійної участі
розробника.
Усі компоненти тісно пов’язані між собою, але реалізовані у вигляді окремих
модулів, що дозволяє легко підтримувати проєкт, тестувати його частинами,
розширювати новими функціями (наприклад, розпізнавання голосових команд,
інтеграція з іншими стрімінговими сервісами тощо.
3.2 Тестування системи
У розробці будь-якого програмного забезпечення, тестування системи є одним
з найважливіших етапів. Метою цього процесу є виявлення та подальше виправлення
помилок, забезпечення відповідності програмного продукту визначеним вимогам і
забезпечення його надійності та стабільності в умовах реального використання. У
63
ЧДТУ 252166.017 ПЗ
цьому розділі будуть ретельно розглянуті різні підходи та методології тестування та
представлені практичні рішення, а також результати проведеного тестування.
Тестування використовують для перевірки різних аспектів програмного
комплексу, включаючи:
1. Перевірка функціональності – допомагає забезпечити правильність виконання
усіх функцій відповідно до специфікації та вимог користувача;
2. Оцінка продуктивності – допомагає визначити, наскільки ефективно система
працює під різним навантаженням, швидкість обробки запитів, витрати
ресурсів;
3. Перевірка безпеки – тестування системи на захищеність від потенційних загроз
та вразливостей.
Це Це лише кілька прикладів, адже на практиці тестування охоплює майже
кожен аспект, що виникає під час розробки, впровадження та супроводу програмного
забезпечення. Об’єктом тестування у цьому проєкті є Telegram-бот, який реалізує
обробку запитів користувача, завантаження музики з YouTube, керування чергою
треків, обробку можливих помилок, а також взаємодію з Telegram Bot API.
Щоб успішно протестувати розроблений застосунок і забезпечити його
стабільну роботу, ми застосовуватимемо послідовний і поетапний підхід до
проведення тестування. Кожен етап буде включати визначення обсягу тестування для
відповідного методу, вибір конкретної стратегії тестування, а також формування
переліку тестових випадків, необхідних для перевірки правильності реалізації
окремих функцій і логічних модулів системи.
Після виконання кожного етапу тестування буде проведено аналіз отриманих
результатів для виявлення можливих недоліків. У разі виявлення помилок або
некоректної роботи певного компонента буде здійснено виправлення коду з
подальшим повторним тестуванням для підтвердження усунення проблеми та
стабільності роботи системи загалом.
У наступних підрозділах ми розглянемо кілька підходів до тестування
розробленого Telegram-бота для прослуховування музики, а також окреслимо
особливості їх застосування в контексті реалізованої архітектури
64
ЧДТУ 252166.017 ПЗ
3.2.1 Модульне тестування
Обсяг тестування
Модульне тестування включає перевірку окремих логічних частин бота,
зокрема обробників команд, черги треків, повідомлень про помилки та станів
завантаження. Таким чином, ми протестуємо такі модулі:
‒ handle_search_query – обробник текстових повідомлень, що містять
пошуковий запит. Перевіряється правильне формування відповіді
користувачу, генерація повідомлення про очікування, а також запуск логіки
пошуку треку на YouTube;
‒ track_queue_manager – модуль черги треків. Перевіряється логіка
постановки в чергу, очікування завершення попереднього треку, передача
управління наступному;
‒ send_audio_file – функція відправки аудіофайлу користувачу. Перевіряється
успішна передача, відповідне повідомлення після завершення надсилання;
‒ error_handler – перевіряється правильність обробки виняткових ситуацій,
зокрема при неможливості завантажити трек, порожньому запиті,
непідтримуваному типі даних тощо.
Стратегія тестування
У ході тестування ми будемо перевіряти виклики основних функцій із
використанням тестових даних, щоб переконатися у правильності їх роботи.
Особливу увагу буде приділено обробці станів черги, а також взаємодії з Telegram
API, яка буде перевірятись за допомогою мок-об’єктів, що дає змогу емулювати
зовнішні запити без реального підключення до сервера.
Також здійснюватиметься тестування реакції бота на різноманітні нестандартні
ситуації, зокрема: некоректні або надмірні запити, відсутність інтернет-з'єднання,
помилки при завантаженні музики з YouTube чи проблеми з обробкою файлів.
Перевірятиметься здатність системи адекватно реагувати на такі виняткові ситуації
без порушення основної логіки роботи.
Основні дії включатимуть симуляцію надсилання повідомлень до бота,
перевірку правильності обробки черги треків, тестування відповідей у чаті та
65
ЧДТУ 252166.017 ПЗ
контроль переходу до наступного треку після завершення поточного. Це дозволить
комплексно оцінити стабільність, функціональність і надійність Telegram-бота під час
його експлуатації.
Тестові випадки
Таблиця 3.1
Тестовий випадок модульного тестування №1
Тест-кейс № 1
Опис Відправлення запиту на пошук треку
Передумови Користувач надсилає текстове повідомлення з назвою треку
Кроки 1. Симуляція надсилання повідомлення з текстом “Nirvana Smells
Like Teen Spirit”.
2. Перевірка реакції функції handle_search_query.
Очікуваний – Бот надсилає повідомлення "Searching and downloading the
результат track..".
– Починається пошук на YouTube.
Фактичний – Бот надсилає повідомлення "Searching and downloading the
результат track..".
– Починається пошук на YouTube.
Пройдено Так
Таблиця 3.2
Тестовий випадок модульного тестування №2
Тест-кейс № 2
Опис Повторний запит при активному завантаженні
Передумови Один трек ще обробляється
Кроки 1. Надсилання запиту на пошук нового треку під час надсилання
попереднього.
Очікуваний – Бот надсилає повідомлення "Please wait for the current track to
результат finish."
66
ЧДТУ 252166.017 ПЗ
Продовження таблиці 3.2
Фактичний – Бот надсилає повідомлення "Please wait for the current track to
результат finish."
Пройдено Так
Таблиця 3.3
Тестовий випадок модульного тестування №3
Тест-кейс № 3
Опис Завершення черги треків
Передумови У черзі кілька треків
Кроки 1. Надсилання декількох запитів.
2. Очікування поки кожен трек надіслано.
Очікуваний – Після завершення одного треку бот надсилає "Now searching for
результат the next track..."
Фактичний – Після завершення одного треку бот надсилає "Now searching for
результат the next track..."
Пройдено Так
Таблиця 3.4
Тестовий випадок модульного тестування №4
Тест-кейс № 4
Опис Некоректний пошуковий запит
Передумови Надіслане повідомлення не дало результатів
Кроки 1. Надсилання завідомо некоректного текстового повідомлення.
Очікуваний – Бот надсилає повідомлення "No results found".
результат
Фактичний – Бот надсилає повідомлення "No results found".
результат
Пройдено Так
67
ЧДТУ 252166.017 ПЗ
Таблиця 3.5
Тестовий випадок модульного тестування №5
Тест-кейс № 5
Опис Помилка при завантаженні плейлиста
Передумови Плейлист не містить в собі треків
Кроки 1.Надіслати посилання на пустий плейлист.
Очікуваний – Відображення повідомлення "No tracks found in playlist".
результат
Фактичний – Відображення повідомлення "No tracks found in playlist".
результат
Пройдено Так
Аналіз проведеного тестування
У ході цього етапу тестування було проведено перевірку основних
функціональних модулів Telegram-бота MusicBot, зокрема обробки пошукових
запитів користувачів, механізму керування чергою треків, а також системи обробки
помилок і виняткових ситуацій. До початку безпосереднього тестування було
детально визначено обсяг перевірки, сформовано загальну стратегію тестування,
обрано підхід до валідації функціональності та розроблено набір тестових випадків
для покриття ключових сценаріїв використання. Тестування проводилося як у
звичайних умовах, так і в ситуаціях з навантаженням для перевірки стабільності та
надійності системи. У результаті всі заплановані тести були успішно виконані, що
підтвердило відповідність реалізованої функціональності заявленим вимогам і
очікуванням користувача. Враховуючи успішне проходження тестів без критичних
зауважень, цей етап тестування можна вважати повністю завершеним.
3.2.2 Інтеграційне тестування
Обсяг тестування
Для інтеграційного тестування було проведено перевірку всіх доступних
ендпоінтів та функцій Telegram-бота MusicBot. Метою даного тестування є перевірка
68
ЧДТУ 252166.017 ПЗ
коректної взаємодії між різними модулями системи, а також відповідності результатів
очікуваним значенням. Основні функції, які були протестовані:
‒ /start – ініціалізація бота;
‒ введення назви треку – пошук музики за назвою;
‒ відправлення посилання на youtube – завантаження та надсилання треку;
‒ надсилання youtube-плейлиста – поетапна обробка треків із плейлиста;
‒ обробка одночасних запитів – перевірка черги повідомлень;
‒ повідомлення про стан обробки – тестування виводу повідомлень про
очікування та початок пошуку.
Стратегія тестування
Для цього тестування була використана стратегія Big Bang Integration Testing.
У межах цієї стратегії всі модулі (пошук, завантаження, надсилання аудіо, обробка
черги, обробка команд Telegram) були інтегровані одночасно, після чого проведено
тестування усієї системи як єдиного цілого. Перевагами цього підходу є можливість
швидко отримати повну картину роботи системи та зекономити час на окреме
тестування кожного модуля.
Тестові випадки
Таблиця 3.6
Тестовий випадок інтеграційного тестування №1
Тест-кейс №1 1
Опис Ініціалізація бота командою /start
Передумови Бот повинен бути запущеним та доступним
Кроки 1. Надіслати повідомлення "/start" у Telegram-чат
Очікуваний Бот надсилає привітальне повідомлення.
результат
Фактичний Бот надсилає привітальне повідомлення.
результат
Пройдено Так
69
ЧДТУ 252166.017 ПЗ
Таблиця 3.7
Тестовий випадок інтеграційного тестування №2
Тест-кейс №2 2
Опис Пошук та отримання музики за назвою
Передумови Бот повинен бути активним
1. Ввести в чат назву пісні (наприклад, “Eminem Without
Кроки
Me”)
Очікуваний результат
Фактичний результат
Пройдено Так
Таблиця 3.8
Тестовий випадок інтеграційного тестування №3
Тест-кейс №3 3
Опис Надсилання YouTube-посилання на трек
Передумови Бот запущено, доступ до YouTube активний
Кроки 1. Надіслати повідомлення з посиланням на відео YouTube
Очікуваний Бот надсилає аудіофайл відповідного треку.
результат
Фактичний Бот надсилає аудіофайл відповідного треку.
результат
Пройдено Так
Таблиця 3.9
Тестовий випадок інтеграційного тестування №4
Тест-кейс № 4
Опис Надсилання YouTube-плейлиста
Передумови Бот повинен бути активним
Кроки 1. Надіслати посилання на YouTube-плейлист
70
ЧДТУ 252166.017 ПЗ
Продовження таблиці 3.9
Очікуваний Бот обробляє треки з плейлиста послідовно, надсилає їх по
результат одному.
Фактичний Бот обробляє треки з плейлиста послідовно, надсилає їх по
результат одному.
Пройдено Так
Таблиця 3.10
Тестовий випадок інтеграційного тестування №5
Тест-кейс № 5
Опис Перевірка черги запитів під час одночасного надсилання
Передумови Бот повинен оброблювати запити по черзі
Кроки 1. Надіслати новий запит до завершення попереднього
Очікуваний Бот надсилає повідомлення: "Please wait for the current track to
результат finish.".
Фактичний Бот надсилає повідомлення: "Please wait for the current track to
результат finish.".
Пройдено Так
Таблиця 3.11
Тестовий випадок інтеграційного тестування №6
Тест-кейс № 6
Опис Повідомлення про початок пошуку після завершення
попереднього запиту
Передумови Один запит завершено, новий запит у черзі
Кроки 1. Дочекатися завершення попереднього треку
2. Перевірити, чи надходить повідомлення про старт нового
Очікуваний Бот надсилає: "Now searching for the next track...".
результат
71
ЧДТУ 252166.017 ПЗ
Продовження таблиці 3.12
Фактичний Бот надсилає: "Now searching for the next track...".
результат
Пройдено Так
Аналіз проведеного тестування
Як можна побачити, усі тести були виконані успішно. Це свідчить про те, що у
всіх визначених тестових випадках ми отримали результат, який відповідає
очікуванням. Таким чином, можна зробити висновок, що інтеграційне тестування за
стратегією Big Bang завершено успішно, і виправлення помилок не вимагається,
оскільки жодних помилок не виявлено. Повторне тестування не проводиться.
3.2.3 Системне тестування
Обсяг тестування
У системному тестуванні охоплюються всі компоненти телеграм-бота після їх
інтеграції, що дозволяє протестувати роботу всієї системи у цілому. Цей вид
тестування забезпечує ретельну перевірку на відповідність системи визначеним
функціональним та нефункціональним вимогам. Метою такого тестування є
виявлення дефектів, що можуть виникнути при взаємодії окремих модулів чи частин
системи. Ми перевіримо взаємодію клієнтського застосунку (інтерфейсу користувача
в Telegram), серверної частини та модуля для завантаження та обробки аудіо з
YouTube.
Стратегія тестування
Для перевірки продуктивності запитів ми використаємо інструмент Postman,
який дозволяє надсилати HTTP-запити на локальний сервер Telegram-бота та
отримувати статистичну інформацію про час відповіді, обсяг даних, навантаження на
систему тощо. Перевірка взаємодії між модулями проводитиметься шляхом UML
тестування сценарію реєстрації нового користувача через Telegram, надсилання
команди на пошук треку та перевірки, чи бот обробив запит, виконав пошук,
72
ЧДТУ 252166.017 ПЗ
завантажив файл та надіслав аудіо. Це дозволить перевірити, що всі основні модулі
працюють узгоджено.
Тестові випадки
Таблиця 3.12
Тестовий випадок системного тестування №1
Тест-кейс № 1
Опис Показник продуктивності запиту на завантаження одного треку з
YouTube
Передумови Сервер Telegram-бота повинен бути запущеним
Кроки 1. Ввести в чат назву пісні (наприклад, “Eminem Without Me”)
Очікуваний Час обробки запиту до надсилання треку не перевищує 20 секунд
результат
Фактичний Час обробки запиту до надсилання треку – 10 секунд.
результат
Пройдено Так
Таблиця 3.13
Тестовий випадок системного тестування №2
Тест-кейс № 2
Опис Показник продуктивності запиту на відтворення плейлиста
Передумови Сервер Telegram-бота повинен бути запущеним
Кроки 1. Надіслати посилання на YouTube-плейлист
Очікуваний Час відповіді на перший трек з плейлиста не перевищує 25
результат секунд.
Фактичний Час відповіді на перший трек з плейлиста– 10 секунд.
результат
Пройдено Так
73
ЧДТУ 252166.017 ПЗ
Таблиця 3.14
Тестовий випадок системного тестування №3
Тест-кейс №3 3
Опис Перевірка взаємодії між Telegram-ботом, серверною частиною та
системою обробки медіа
Передумови Сервер Telegram-бота має бути запущеним
Кроки 1. Ввести в чат назву пісні (наприклад, “Eminem Without Me”)
2. Дочекатися надсилання аудіофайлу у відповідь
Очікуваний – Відео знайдене на YouTube;
результат – Аудіофайл завантажено, оброблено, надіслано користувачу.
Фактичний – Відео знайдене на YouTube;
результат – Аудіофайл завантажено, оброблено, надіслано користувачу.
Пройдено Так
Аналіз проведеного тестування
Згідно з результатами проведеного системного тестування, можемо
підтвердити відповідність фактичної продуктивності Telegram-бота функціональним
вимогам. Продуктивність в межах очікувань, бот успішно взаємодіє з Telegram API,
серверною частиною та медіамодулем для завантаження з YouTube. Всі перевірки
показали стабільну роботу під час обробки запитів.
3.2.4 Приймальне тестування
Обсяг тестування
Приймальне тестування охоплює всі функціональні та нефункціональні вимоги
до телеграм-бота для прослуховування музики, що були визначені у розділі
формування вимог за допомогою діаграми прецедентів та у текстовому форматі. Мета
цього тестування полягає у тому, щоб переконатись у відповідності розробленого
продукту всім визначеним на етапі проєктування бізнес-вимогам.
Стратегія тестування
На першому етапі ми детально проаналізуємо всі бізнес-вимоги до готового
продукту та визначимо перелік вимог, що будуть перевірятись під час цього
74
ЧДТУ 252166.017 ПЗ
тестування. Після того, як ми визначили перелік вимог, ми розробимо детальний чек-
лист та послідовно виконаємо усі тестові випадки. У кінці тестування проаналізуємо
результати та підіб’ємо підсумок.
Проведення тестування
Для початку, розглянемо вимоги, які були визначені на етапі проєктування та
які слід перевірити:
Для користувача:
‒ надсилання запиту на пошук треку за назвою;
‒ отримання аудіофайлу після обробки запиту;
‒ виведення повідомлення про зайнятість бота у разі надсилання нового
запиту під час обробки попереднього;
‒ підтримка обробки youtube-плейлистів;
‒ отримання повідомлення про наступний трек у черзі.
Для розробника (через адміністративний доступ або внутрішню перевірку
логів):
‒ перевірка обробки черги запитів;
‒ обробка виключень при недоступності відео;
‒ коректна логіка завершення відправки файлу користувачу.
Опираючись на цей список розробимо детальні тестові випадки та протестуємо
представлені у них сценарії:
Таблиця 3.15
Тестовий випадок приймального тестування №1
Тест-кейс № 1
Опис Надсилання запиту на пошук треку
Кроки 1. Надіслати боту повідомлення з назвою будь-якого популярного
треку
Очікуваний
результат
Пройдено Так
75
ЧДТУ 252166.017 ПЗ
Таблиця 3.16
Тестовий випадок приймального тестування №2
Тест-кейс № 2
Опис Відповідь бота при повторному запиті під час обробки
попереднього
Кроки 1. Надіслати запит на пошук треку.
2. Поки бот обробляє запит, надіслати ще один запит
Очікуваний Бот надсилає повідомлення: «Please wait for the current track to
результат finish.».
Пройдено Так
Таблиця 3.17
Тестовий випадок приймального тестування №3
Тест-кейс № 3
Опис Обробка YouTube-плейлиста
Кроки 1. Надіслати боту посилання на YouTube-плейлист
Очікуваний – Бот надсилає треки з плейлиста по черзі у вигляді аудіофайлів.
результат
Пройдено Так
Таблиця 3.18
Тестовий випадок приймального тестування №4
Тест-кейс № 4
Опис Отримання повідомлення про початок обробки наступного треку
Кроки 1. Надіслати декілька треків поспіль (черга)
2. Дочекатись завершення першого запиту
Очікуваний – Після завершення надсилання першого треку бот надсилає
результат повідомлення: «Now searching for the next track…».
Пройдено Так
76
ЧДТУ 252166.017 ПЗ
Таблиця 3.19
Тестовий випадок приймального тестування №5
Тест-кейс № 5
Опис Перевірка обробки помилок (недоступне відео)
Кроки 1. Надіслати боту посилання на неіснуюче або обмежене відео
Очікуваний – Бот надсилає повідомлення про помилку або неможливість
результат обробки запиту.
Пройдено Так
Таблиця 3.20
Тестовий випадок приймального тестування №6
Тест-кейс № 6
Опис Обробка запитів черги
Кроки 1. Надіслати кілька запитів з різних акаунтів (при емуляції або
командній перевірці)
Очікуваний – Бот обробляє запити по черзі відповідно до логіки
результат
Пройдено Так
Аналіз проведеного тестування
Проаналізувавши бізнес-вимоги, які були визначені на етапі проєктування, було
складено перелік тестових випадків необхідних для перевірки на відповідність
вимогам. Відтворивши усі сценарії, ми переконались у тому, що усі визначені вимоги
задоволені і проходять тестування. Приймальне тестування можна рахувати
успішним, продукт готовий до видачі замовнику.
3.3 Приклади впровадженого програмного комплексу
У цьому підрозділі наведено приклади роботи впровадженого програмного
комплексу — Telegram-бота MusicBot. Продемонстровано основні сценарії взаємодії
користувача з ботом, зокрема надсилання пошукового запиту, отримання аудіотреку,
обробку черги запитів та реакцію на помилки. Ілюстрації дозволяють оцінити
77
ЧДТУ 252166.017 ПЗ
функціональність, зручність використання та відповідність системи заявленим
вимогам.
3.3.1 Опис функціоналу користувача Telegram-бота MusicBot
Після запуску Telegram-бота, користувач потрапляє до головного меню
(рис. 3.1), в якому він отримує коротке вітальне повідомлення із запрошенням ввести
назву музичного треку або посилання на нього. Основне призначення бота – пошук
музичних композицій на платформі YouTube, їх завантаження та надсилання
користувачу у вигляді аудіофайлу.
Рисунок 3.1 – Головне меню бота
78
ЧДТУ 252166.017 ПЗ
У верхній частині вікна чату знаходиться стандартна шапка Telegram-бота
(рис. 3.2), яка містить назву бота, аватар (якщо встановлено), а також статус
користувача (наприклад, «бот»).
Рисунок 3.2 – Інтерфейс Telegram-бота у вікні чату
Для початку роботи достатньо надіслати пошуковий запит або посилання на
відео/плейлист YouTube. У разі, якщо попередній трек ще обробляється, бот
повідомить користувача відповідним повідомленням (рис. 3.3), яке вказує на
необхідність дочекатися завершення обробки.
Рисунок 3.3 – Повідомлення про обробку попереднього запиту
Після завершення попередньої обробки бот автоматично переходить до
обробки нового запиту, про що інформує повідомленням (рис. 3.4), де вказано, що
розпочато пошук наступного треку.
Рисунок 3.4 – Повідомлення про початок пошуку нового треку
79
ЧДТУ 252166.017 ПЗ
Пошук треків може здійснюватись як за назвою, так і за прямим посиланням на
YouTube. У разі виявлення валідного відео, бот завантажує аудіодоріжку, конвертує
її у формат .mp3 і надсилає користувачу у вигляді окремого повідомлення (рис. 3.5).
Рисунок 3.5 – Надсилання аудіофайлу користувачу
Якщо було надіслано посилання на YouTube-плейлист, бот розпізнає його як
набір треків, обробляє по черзі кожну композицію та надсилає окремі аудіофайли
(рис. 3.6). Таким чином реалізовано підтримку цілого плейлисту з послідовною
обробкою треків.
Рисунок 3.6 – Обробка YouTube-плейлисту
80
ЧДТУ 252166.017 ПЗ
У разі виникнення помилки (наприклад, невалідне посилання або відсутність
треків за запитом), бот виводить відповідне повідомлення з поясненням проблеми
(рис. 3.7), що покращує взаємодію з користувачем і дозволяє йому скоригувати запит.
Рисунок 3.7 – Повідомлення про помилку обробки запиту
Завдяки простому та інтуїтивному інтерфейсу, Telegram-бот MusicBot
забезпечує комфортне користування основною функцією – пошуком та
прослуховуванням музики через аудіофайли з YouTube. Бот автоматично обробляє
чергу запитів, підтримує обробку плейлистів та забезпечує взаємодію з користувачем
через повідомлення і команди Telegram.
3.3.2 Розгортання системи
У межах реалізації програмного комплексу Telegram-бота MusicBot було
реалізовано розгортання системи з використанням сучасних інструментів
автоматизації, системи контролю версій та хмарного хостингу. Основною метою
81
ЧДТУ 252166.017 ПЗ
стало забезпечення стабільної роботи бота в продакшн-середовищі з мінімальними
затратами на підтримку та адміністрування.
Для цього було обрано хмарну платформу Railway, яка дозволяє
автоматизувати процес розгортання, масштабування та моніторингу ботів,
побудованих на Python. Рішення про використання Railway було прийнято з огляду
на його переваги:
‒ швидке розгортання через GitHub-інтеграцію;
‒ підтримка .env-змінних для безпечного зберігання конфіденційних даних
(токен Telegram API);
‒ автоматичне оновлення після кожного коміту до репозиторію;
‒ відсутність потреби у ручному налаштуванні інфраструктури або VPS-
серверів
Послідовність дій для розгортання системи:
1 Публікація коду: увесь код Telegram-бота було розміщено в публічному
репозиторії GitHub за посиланням: https://github.com/PZ2104Oleh/MusicBot.
2 Створення проєкту в Railway: через офіційний інтерфейс Railway було
створено новий проєкт, пов’язаний із репозиторієм GitHub. Railway
автоматично зчитує Procfile або entrypoint для запуску Python-скрипту
(main.py), що запускає Telegram-бота.
3 Налаштування змінних середовища: з метою безпеки токен Telegram API
зберігається не в коді, а у спеціальному розділі Variables на Railway. Змінна
BOT_TOKEN додається вручну через інтерфейс та використовується
всередині бота через модуль dotenv.
4 Автоматичний запуск і моніторинг: після кожного оновлення репозиторію
Railway автоматично перезапускає бота та виводить логи в зручному
форматі. Це дозволяє швидко виявляти помилки та спостерігати за
поведінкою бота в режимі реального часу.
5 Тестування в продуктивному середовищі: після розгортання було виконано
тестову сесію в Telegram для перевірки роботи запитів, черги, обробки
82
ЧДТУ 252166.017 ПЗ
плейлистів, помилкових запитів, тощо. Усі функції працювали стабільно без
збоїв.
Таким чином, реалізовано повністю автоматизоване розгортання Telegram-
бота, що дозволяє не тільки швидко оновлювати систему, а й гарантує її стабільну
роботу у хмарному середовищі. Такий підхід значно спрощує підтримку проєкту,
виключає потребу у власному сервері та забезпечує готовність до масштабування в
разі зростання кількості користувачів
83
ЧДТУ 252166.017 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було детально розглянуто процес розробки та тестування
Telegram-бота MusicBot, призначеного для пошуку та надсилання музичних
композицій із YouTube. На етапі розробки було обґрунтовано вибір технологій,
реалізовано архітектуру програмного комплексу на основі модульного підходу,
описано функціональну, структурну та логічну схеми роботи системи. Особливу
увагу приділено реалізації черги запитів, обробці плейлистів і підтримці
асинхронного виконання, що забезпечує стабільну роботу навіть при підвищеному
навантаженні.
Було впроваджено хмарне розгортання на платформі Railway, що гарантує
цілодобову доступність бота, а також безпечне зберігання конфіденційних даних
через систему змінних середовища. Відмова від використання бази даних дозволила
значно спростити архітектуру, зберігаючи при цьому необхідну функціональність
завдяки тимчасовому зберіганню файлів.
У розділі проведено комплексне тестування програмного забезпечення:
модульне, інтеграційне, системне та приймальне. Результати тестів підтвердили
правильність реалованої логіки, відповідність функціональних можливостей вимогам
користувача, а також надійність і стабільність роботи системи. Усі тестові сценарії
пройдено успішно без виявлення критичних помилок.
Таким чином, розділ демонструє, що реалізований Telegram-бот MusicBot
повністю відповідає поставленим завданням, є технічно коректним, зручним у
використанні та готовим до практичного застосування.
84
ЧДТУ 252166.017 ПЗ
ВИСНОВКИ
У межах дипломної роботи було успішно реалізовано повний цикл розробки
Telegram-бота MusicBot, призначеного для автоматизованого пошуку та доставки
музичних композицій із YouTube до користувачів платформи Telegram. У результаті
виконано ґрунтовний аналіз предметної області, опрацьовано сучасні технічні
рішення та реалізовано конкурентоспроможний програмний продукт, що відповідає
актуальним вимогам користувачів.
На етапі теоретичного дослідження були проаналізовані існуючі рішення,
зокрема популярні Telegram-боти, що надихнуло на формування чіткого бачення
функціоналу майбутньої системи. Ретельно обрані технології — Python, бібліотека
aiogram, інструменти yt-dlp та ffmpeg, а також хмарна платформа Railway — стали
основою ефективного, продуктивного та масштабованого рішення.
У процесі проєктування було змодельовано предметну область, сформульовано
функціональні й нефункціональні вимоги, створено низку UML-діаграм, що
відображають структуру та логіку роботи системи. Особливу увагу приділено
реалізації асинхронної черги обробки запитів і підтримці плейлистів, що забезпечує
стабільну роботу навіть за умов підвищеного навантаження.
На завершальному етапі виконано розгортання на хмарній платформі Railway
із застосуванням змінних середовища для безпечного зберігання конфіденційної
інформації. Система пройшла комплексне тестування на всіх рівнях, що підтвердило
її працездатність, відповідність вимогам та готовність до реального використання.
Таким чином, створений Telegram-бот MusicBot є технічно завершеним,
надійним, функціональним та зручним сервісом для прослуховування музики, що має
потенціал до подальшого розвитку та масштабування.
85
ЧДТУ 252166.017 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Telegram Bot API – Офіційна документація API Telegram для створення
ботів: https://core.telegram.org/bots/api
2 Aiogram – Асинхронний Telegram-фреймворк на Python:
https://docs.aiogram.dev
3 Python 3.10 – Офіційна документація мови програмування:
https://docs.python.org/3.10/
4 yt-dlp – Інструмент для завантаження відео та аудіо з YouTube:
https://github.com/yt-dlp/yt-dlp
5 youtube-dl – Оригінальний проєкт, на основі якого створено yt-dlp:
https://github.com/ytdl-org/youtube-dl
6 FFmpeg – Універсальний інструмент для обробки мультимедіа:
https://ffmpeg.org
7 Railway – Хмарна платформа для хостингу застосунків: https://railway.app
8 Pyrogram – Telegram-бібліотека на Python: https://docs.pyrogram.org
9 asyncio – Стандартна бібліотека для асинхронного програмування в Python:
https://docs.python.org/3/library/asyncio.html
10 dotenv – Бібліотека для роботи з .env-файлами:
https://pypi.org/project/python-dotenv/
11 Git – Система контролю версій: https://git-scm.com
12 GitHub – Хостинг для розробників: https://github.com
13 PyCharm – Середовище розробки для Python:
https://www.jetbrains.com/pycharm/
14 Visual Studio Code (VS Code) – Редактор коду з підтримкою Python:
https://code.visualstudio.com
15 Docker – Платформа контейнеризації для деплою застосунків:
https://www.docker.com
16 YouTube Data API v3 – Офіційне API для взаємодії з YouTube:
https://developers.google.com/youtube/v3
86
ЧДТУ 252166.017 ПЗ
17 UML 2.5 Specification – Опис стандартів моделювання програмного
забезпечення: https://www.omg.org/spec/UML/2.5.1/
18 Refactoring.Guru – Design Patterns in Python – Шаблони проєктування в
Python: https://refactoring.guru/uk/design-patterns/python
87
ЧДТУ 252166.017 ПЗ
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
“____” ______________ 2025 р.
«Телеграм-бот для прослуховування музики»
Специфікація
482.ЧДТУ 252166.017
Листів 2
Розробник ________________ Прокопенко О. І.
Керівник ________________ Немченко О. І.
2025
88
ЧДТУ 252166.017 ПЗ
Позначення Найменування Примітка
Документація
482.ЧДТУ 252166.12.01 Текст програми
482.ЧДТУ 252166.34.01 Інструкція користувачеві
482.ЧДТУ 252166.90.01 Графічні матеріали
89
ЧДТУ 252166.017 ПЗ
ДОДАТОК Б
«Телеграм-бот для прослуховування музики»
Текст програми
482.ЧДТУ 252166.34.01
Листів 8
Розробник ________________ Прокопенко О. І.
2025
90
ЧДТУ 252166.017 ПЗ
.gitignore:
.env
__pycache__
venv/
.idea
cache
tmp
Dockerfile:
FROM python:3.10-slim
RUN apt update && apt install -y ffmpeg
WORKDIR /app
COPY . /app
RUN pip install --no-cache-dir -r requirements.txt
CMD ["python", "bot.py"]
bot.py:
import os
import sys
import shutil
import logging
import asyncio
import time
import re
from collections import defaultdict
from telegram import Update
from telegram.ext import ApplicationBuilder, CommandHandler,
MessageHandler, filters, ContextTypes
from config import BOT_TOKEN
from downloader import search_youtube, download_audio_file,
extract_playlist # обновлённый импорт
logging.basicConfig(
level=logging.INFO,
format="%(levelname)s:%(name)s:%(message)s",
stream=sys.stdout
)
91
ЧДТУ 252166.017 ПЗ
TMP_BASE = "tmp"
INACTIVITY_TIMEOUT = 600
user_queues = defaultdict(asyncio.Queue)
user_tasks = {}
last_active = {}
YOUTUBE_URL_RE =
re.compile(r'(https?://)?(www\.)?(youtube\.com|youtu\.be)/')
def get_user_tmp_path(user_id):
return os.path.join(TMP_BASE, str(user_id))
def ensure_tmp_path(user_id):
path = get_user_tmp_path(user_id)
os.makedirs(path, exist_ok=True)
return path
def clear_tmp_for_user(user_id):
user_path = get_user_tmp_path(user_id)
if os.path.exists(user_path):
shutil.rmtree(user_path)
async def start(update: Update, context:
ContextTypes.DEFAULT_TYPE):
await update.message.reply_text("Hi! Send me a track name
or YouTube link and I'll find and send it to you ��")
async def handle_query(update: Update, context:
ContextTypes.DEFAULT_TYPE):
user_id = update.effective_user.id
message_text = update.message.text.strip()
last_active[user_id] = time.time()
queue = user_queues[user_id]
# Обработка плейлиста
if "list=" in message_text and
YOUTUBE_URL_RE.match(message_text):
playlist = extract_playlist(message_text)
if not playlist:
await update.message.reply_text("No tracks found
in playlist ��")
92
ЧДТУ 252166.017 ПЗ
return
for item in playlist:
await queue.put((item['url'], update))
else:
await queue.put((message_text, update))
if user_id in user_tasks:
await update.message.reply_text("⏳ Please wait for
the current track to finish.")
return
task = asyncio.create_task(process_user_queue(user_id,
context))
user_tasks[user_id] = task
async def process_user_queue(user_id: int, context:
ContextTypes.DEFAULT_TYPE):
queue = user_queues[user_id]
while not queue.empty():
query, update = await queue.get()
if not queue.empty():
try:
await update.message.reply_text("▶️ Now
searching for the next track...")
except Exception as e:
logging.warning(f"Failed to send 'Now
searching...' for user {user_id}: {e}")
try:
await update.message.reply_text("�� Searching and
downloading the track...")
if YOUTUBE_URL_RE.match(query):
url = query
title = None
else:
results = search_youtube(query)
if not results:
await update.message.reply_text("No
results found ��")
continue
url = results[0]['url']
93
ЧДТУ 252166.017 ПЗ
title = results[0]['title']
user_tmp = ensure_tmp_path(user_id)
file_path, actual_title = download_audio_file(url,
user_tmp)
await
update.message.reply_audio(audio=open(file_path, 'rb'),
title=actual_title or title)
except Exception as e:
logging.error(f"Error for user {user_id}: {e}")
if not queue.empty():
next_query, next_update = queue._queue[0]
try:
await next_update.message.reply_text("▶️ Now
searching for the next track...")
except Exception as e:
logging.warning(f"Failed to send 'Now
searching...' for user {user_id}: {e}")
user_tasks.pop(user_id, None)
async def cleanup_loop():
while True:
await asyncio.sleep(60)
now = time.time()
for user_id, last_time in list(last_active.items()):
if now - last_time > INACTIVITY_TIMEOUT:
clear_tmp_for_user(user_id)
logging.info(f"Cleared tmp for user {user_id}
due to inactivity.")
del last_active[user_id]
user_queues.pop(user_id, None)
if __name__ == "__main__":
os.makedirs(TMP_BASE, exist_ok=True)
async def on_startup(app):
asyncio.create_task(cleanup_loop())
app =
ApplicationBuilder().token(BOT_TOKEN).post_init(on_startup).bu
ild()
94
ЧДТУ 252166.017 ПЗ
app.add_handler(CommandHandler("start", start))
app.add_handler(MessageHandler(filters.TEXT &
~filters.COMMAND, handle_query))
app.run_polling()
config.py:
import os
BOT_TOKEN = os.getenv('BOT_TOKEN')
downloader.py:
import os
import yt_dlp
import hashlib
import json
COOKIES_FILE = 'cookies.txt'
def hash_url(url):
return hashlib.md5(url.encode()).hexdigest()
def search_youtube(query, limit=1):
ydl_opts = {
'format': 'bestaudio/best',
'noplaylist': True,
'default_search': f'ytsearch{limit}',
'quiet': True,
'cookiefile': COOKIES_FILE,
}
with yt_dlp.YoutubeDL(ydl_opts) as ydl:
info = ydl.extract_info(query, download=False)
entries = info.get('entries', [])
return [{
'title': e['title'],
'url': e['webpage_url']
} for e in entries]
def extract_playlist(playlist_url):
ydl_opts = {
'quiet': True,
'cookiefile': COOKIES_FILE,
'extract_flat': True,
}
95
ЧДТУ 252166.017 ПЗ
with yt_dlp.YoutubeDL(ydl_opts) as ydl:
info = ydl.extract_info(playlist_url, download=False)
entries = info.get('entries', [])
return [{
'title': e.get('title'),
'url': e.get('url') if e.get('url',
'').startswith('http') else
f"https://www.youtube.com/watch?v={e['id']}"
} for e in entries]
def download_audio_file(url, output_dir):
file_hash = hash_url(url)
mp3_path = os.path.join(output_dir, f"{file_hash}.mp3")
meta_path = os.path.join(output_dir, f"{file_hash}.json")
if os.path.exists(mp3_path) and os.path.exists(meta_path):
with open(meta_path, 'r') as f:
meta = json.load(f)
return mp3_path, meta.get('title')
ydl_opts = {
'format': 'bestaudio/best',
'outtmpl': os.path.join(output_dir,
f"{file_hash}.%(ext)s"),
'quiet': True,
'cookiefile': COOKIES_FILE,
'postprocessors': [{
'key': 'FFmpegExtractAudio',
'preferredcodec': 'mp3',
'preferredquality': '192',
}],
}
with yt_dlp.YoutubeDL(ydl_opts) as ydl:
info = ydl.extract_info(url, download=True)
with open(meta_path, 'w') as f:
json.dump({'title': info['title']}, f)
return mp3_path, info['title']
requirements.txt:
anyio==4.9.0
APScheduler==3.11.0
certifi==2025.1.31
ffmpeg-python==0.2.0
future==1.0.0
h11==0.14.0
96
ЧДТУ 252166.017 ПЗ
httpcore==1.0.8
httpx==0.28.1
idna==3.10
pydub==0.25.1
python-telegram-bot==22.0
sniffio==1.3.1
typing_extensions==4.13.2
tzdata==2025.2
tzlocal==5.3.1
yt-dlp==2025.06.09
97
ЧДТУ 252166.017 ПЗ
ДОДАТОК В
«Телеграм-бот для прослуховування музики»
Інструкція користувачеві
482.ЧДТУ 252166.94.01
Листів 5
Розробник ________________ Прокопенко О. І.
2025
98
ЧДТУ 252166.017 ПЗ
Для початку використання бота користувач має зайти в додаток Telegram та
написати в стрічку пошуку у лівому верхньому кутку застосунку (рис В.1) тег бота
(@musicatempusbot) та вибрати перший варіант з наданих (рис В.2)
Рисунок В.1 – Стрічка пошуку застосунку Telegram
Рисунок В.2 – Знайдений Телеграм-бот
Після натискання на знайдений варіант користувач побачить опись можливостей
бота (рис В.3) та кнопку “START” (рис В.4), після натиснення на яку розпочнеться
пряма взаємодія користувача з ботом.
Рисунок В.3 – Опис призначення бота
Рисунок В.4 – Кнопка START
99
ЧДТУ 252166.017 ПЗ
Коли користувач натисне на кнопку “START” бот активізується та надішле
привітальне повідомлення (рис В.5), яке повідомляє користувача про можливість
знаходження треків як за назвою, так і за посиланням з YouTube.
Рисунок В.5 – Привітальне повідомлення бота
Далі у користувача є три шляхи, перший з яких – написати в чат сценічне ім’я
музичного виконавця то назву його треку та відправити, після чого виведеться
повідомлення, яке сповістить користувача про початок процесів пошуку, завантаження,
конвертації та вивантаження в чат композиції (рис В.6) і вже через декілька секунд в
чаті з’явиться потрібний трек (рис В.7)
Рисунок В.6 – Повідомлення про початок процесів
Рисунок В.7 – Результат запиту користувача
Другий шлях, який може обрати користувач – це надіслати в чат посилання з
YouTube на конкретний трек (рис В.8), яке запустить той самий процес, що і у
100
ЧДТУ 252166.017 ПЗ
попередньому варіанті, але минуючи етап пошуку, так як користувач надсилає прямий
шлях.
Рисунок В.8 – Результат запиту з прямим посиланням на трек з YouTube
І, нарешті, третій шлях, який може вибрати користувач – надіслати посилання на
плейлист з YouTube, в якому може міститись декілька пісень. В такому випадку бот буде
почергово обробляти кожен трек з плейлиста як окремий запит і надсилати їх по черзі
(рис В.9)
101
ЧДТУ 252166.017 ПЗ
Рисунок В.9 – Результат запиту з посиланням на плейлист
102
ЧДТУ 252166.017 ПЗ
ДОДАТОК Г
«Телеграм-бот для прослуховування музики»
Графічні матеріали
482.ЧДТУ 252166.90.01
Листів 13
Розробник ________________ Прокопенко О. І.
Керівник ________________ Немченко О. І.
2025
103
ЧДТУ 252166.017 ПЗ
Рисунок Г.1 – Тема роботи
Рисунок Г 2 – Вступ
104
ЧДТУ 252166.017 ПЗ
Рисунок Г.3 – Вимоги
Рисунок Г.4 – Аналіз існуючих рішень 1
105
ЧДТУ 252166.017 ПЗ
Рисунок Г.5 – Аналіз існуючих рішень 2
Рисунок Г.6 – Аналіз існуючих рішень 3
106
ЧДТУ 252166.017 ПЗ
Рисунок Г.7 – Засоби розробки
Рисунок Г.8 – Діаграма прецедентів
107
ЧДТУ 252166.017 ПЗ
Рисунок Г.9 – Діаграма класів
Рисунок Г.10 – Діаграма пакетів
108
ЧДТУ 252166.017 ПЗ
Рисунок Г.11 – Діаграма компонентів
Рисунок Г.12 – Діаграма розгортання
109
ЧДТУ 252166.017 ПЗ
Рисунок Г.13 – Діаграма діяльності
Рисунок Г.14 – Діаграма послідовності
110
ЧДТУ 252166.017 ПЗ
Рисунок Г.15 – Діаграма комунікації
Рисунок Г.16 – Діаграма скінченного автомату
111
ЧДТУ 252166.017 ПЗ
Рисунок Г.17 – Структурна та функціональна схеми
Рисунок Г.18 – Логічна схема
112
ЧДТУ 252166.017 ПЗ
Рисунок Г.19 – розробка бази даних
Рисунок Г.20 – Розробка інтерфейсу користувача
113
ЧДТУ 252166.017 ПЗ
Рисунок Г.21 – Тестування
Рисунок Г.22 – Висновки
114
ЧДТУ 252166.017 ПЗ
Рисунок Г.23 – Відео
115