Добавил:
eipimru
У меня есть канал с приколами: t.me/urmipies_garbage Подпишитесь пж-пж!!!!
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:laba / laba.pdf
3Пользователь1:NИстория прослушиваний
4Пользователь1:1Роль
5Фонотека1:NАудиозапись
6Аудиозапись1:1Метаданные аудиозаписи
7Плейлист1:NЭлемент плейлиста
8Аудиозапись1:NЭлемент плейлиста
9История прослушиваний1:NАудиозапись
12
3Логика работы системы и бизнес процессы
3.1Бизнес-процессы
Процесс 1: Добавление трека
1.Пользователь загружает файл
2.Система валидирует (формат, размер)
3.Система извлекает метаданные (ID3 теги)
4.Система сохраняет в БД
5.Система индексирует для поиска
6.Система обновляет вид коллекции пользователя
Процесс 2: Поиск трека
1.Пользователь вводит текст в поисковую строку
2.Пользователь может добавить фильтры (жанр, исполнитель, год и т.д.)
3.Система фильтрует данные
4.Система ранжирует результаты
5.Система отображает результаты
6.Пользователь выбирает трек или уточняет поиск
Процесс 3: Прослушивание и сбор статистики
1.Пользователь нажимает кнопку проигрывания трека
2.Система загружает аудиобуфер
3.Система включает проигрывание
4.Система отслеживает время проигрывания
5.При завершении трека система сохраняет:
1.track_id
2.user_id
3.played_date
4.duration_listened
Процесс 4: Создание плейлиста
1.Пользователь нажимает кнопку создания плейлиста
2.Пользователь вводит название и описание плейлиста
3.Пользователь наполняет плейлист треками
13
4.Пользователь нажимает кнопку сохранения плейлиста
5.Система сохраняет плейлист
6.Система отображает плейлист с треками
Процесс 5: Анализ статистики
1.Пользователь выбирает период (день/неделя/месяц/год)
2.Система запрашивает статистику за этот период
3.Система вычисляет метрики:
–Всего времени прослушивания
–Топ-5 треков
–Топ-5 исполнителей
–Самый активный день
4.Система отображает метрики
14
4Разработка технического задания
4.1Общие сведения о системе
Разрабатываемая система представляет собой веб-приложение для
формирования, хранения и анализа личной музыкальной фонотеки
пользователя. Система предназначена для централизованного управления
аудиозаписями и связанными с ними метаданными, а также для получения
аналитической информации о содержимом фонотеки.
Система является автоматизированной информационной системой
пользовательского уровня и функционирует в среде веб-браузера.
4.2Основание для разработки
Техническое задание разработано на основании ГОСТ 34.602–
2020 «Автоматизированные системы. Техническое задание на создание
автоматизированной системы» с учетом специфики учебного проекта по
дисциплине «Мультимедийные информационные системы».
Необходимость разработки обусловлена потребностью в формализации
процессов хранения и анализа личных музыкальных коллекций с
использованием современных веб-технологий.
4.3Цель и назначение системы
Целью разработки является создание веб-приложения, обеспечивающего
удобное и структурированное ведение личной музыкальной фонотеки, а
также анализ её содержимого с предоставлением статистических данных
пользователю.
Назначение системы:
1.хранение аудиозаписей и их метаданных;
2.упорядочивание музыкальной коллекции;
3.обеспечение быстрого поиска и фильтрации композиций;
15
4.формирование статистики и аналитических показателей по фонотеке.
4.4Характеристика объектов автоматизации
Объектом автоматизации является процесс управления личной
музыкальной фонотекой пользователя, включающий:
1.добавление и удаление аудиозаписей;
2.хранение и обновление метаданных;
3.организацию композиций по различным признакам;
4.анализ пользовательской музыкальной коллекции.
Автоматизация направлена на снижение трудозатрат пользователя при
работе с фонотекой и повышение наглядности представления музыкальных
данных.
4.5Функциональные требования
Система должна обеспечивать выполнение следующих функций:
4.6Функциональные требования
4.6.1Требования к управлению учётными записями
1.Система должна предоставлять возможность регистрации нового
пользователя через email и пароль
2.Система должна поддерживать аутентификацию через OAuth2
провайдеров (Google, Apple, Spotify)
3.Система должна предоставлять возможность восстановления пароля
4.Пользователь должен иметь возможность редактировать свой
профиль (аватар, имя, описание)
5.Система должна поддерживать двухфакторную аутентификацию
(2FA)
16
4.6.2Требования к управлению музыкальной коллекцией
1.Система должна автоматически извлекать метаданные из
аудиофайлов
2.Пользователь должен иметь возможность редактировать метаданные
вручную
3.Система должна обогащать метаданные из внешних источников
4.6.3Требования к организации и категоризации
1.Пользователь должен иметь возможность изменять плейлисты:
–Создание пустого плейлиста
–Переименование, изменение описания
4.6.4Требования по поиску и фильтрации
1.Поиск по всей коллекции:
–По названию трека, исполнителю, альбому
–По текстам песен (если доступно)
–По пользовательским тегам и комментариям
2.Расширенная фильтрация по множеству критериев:
–По жанру, году, рейтингу
–По формату, битрейту
–По дате добавления, частоте прослушивания
3.Сохранение последних поисковых запросов
4.6.5Аналитика и статистика
1.Анализ фонотеки:
–Подсчет общего количества аудиозаписей
–Распределение композиций по жанрам и исполнителям
–Формирование статистики прослушиваний.
17
4.7Нефункциональные требования (QoS)
Нефункциональные требования описывают качество
функционирования системы.
4.7.1Требования к производительности
1.Время отклика системы:
–Поиск по коллекции до 50,000 треков: < 1 секунды
–Загрузка страницы каталога: < 2 секунды
–Начало воспроизведения трека: < 500 мс
–Загрузка аудиофайла: < 3 секунды для файла 10 МБ
2.Пропускная способность:
–Поддержка 10,000 одновременных пользователей
–1,000 одновременных потоковых трансляций
–Обработка 100 транзакций в секунду
3.Время доступности:
–99.5% uptime
Коэффициент использования 99,5% был выбран на основании
требования к надежности, характерного для мультимедийных систем.
𝑇
Кисп=
𝑇
работы
𝑇
работы
— это общее время работы системы за год (в данном случае
работы
+𝑇
простоя
принимается 8760 часов), а T_простоя — это допустимое время простоя. Для
коэффициента 99,5% максимальное время простоя составляет 0.005 × 8760 = 43.8
часавгод. Таким образом, система должна быть доступна не менее 8756,2 часов
в год.
4.7.2Требования к обучаемости
Обучаемость системы оценивается исходя из времени, которое
потребуется пользователю для освоения интерфейса аудиопроигрывателя.
18
На основании ГОСТ 91.726-3 и проведенного анализа минималистичного
интерфейса системы, предполагается, что пользователь с базовыми навыками
работы на ПК освоит управление системой за 5-20 минут. Этот диапазон был
выбран на основе следующих параметров:
–Квалификация пользователя: человек, владеющий компьютером на
базовом уровне, должен легко понимать функции проигрывателя
(воспроизведение трека, настройка громкости и т.д.).
–простота интерфейса: минималистичный интерфейс позволяет
пользователю интуитивно находить основные элементы управления,
не тратя время на изучение дополнительных функций или сложных
меню.
4.7.3Требования к удобству использования
Интерфейс должен быть интуитивно понятным и не требовать
предварительного обучения.
Пользователь должен иметь возможность выполнить основные
операции (добавление трека, поиск, просмотр статистики) не более чем за 3–
4 действия.
Длительная работа пользователя с системой не должна вызывать
утомления, что достигается логичной навигацией и минимальным
количеством лишних элементов интерфейса.
4.7.4Требования к надежности
Доступность системы — не менее 99 % времени.
Потеря пользовательских данных при сбоях не допускается.
Корректность данных должна обеспечиваться механизмами целостности
базы данных.
19
4.7.5Требования к безопасности
Хранение паролей пользователей осуществляется только в виде хэшей.
Доступ к фонотеке возможен только после успешной аутентификации
пользователя.
Пользователь имеет доступ исключительно к собственной фонотеке.
4.8Ограничения и допущения
В рамках данной системы вводятся следующие ограничения:
1.поддерживается работа только с аудиофайлами, загруженными
пользователем;
2.отсутствует интеграция с внешними музыкальными сервисами;
3.рекомендательные системы и обработка аудиосигнала не
реализуются.
4.9Требования к программному и техническому обеспечению
1.Клиентская часть должна работать в современных веб-браузерах.
2.Серверная часть должна обеспечивать хранение данных и обработку
запросов пользователей.
3.Система управления базами данных должна поддерживать
реляционную модель данных.
20
5Архитектура приложения
Архитектура приложения представляет трёхуровневую
клиент‑серверную систему: уровень представления, уровень бизнес-логики и
сервер СУБД (слой доступа к данным). Схема приложения представлена на
картинке
5.1Уровень представления (клиент)
Слой представления реализуется в виде веб-страницы, которую
пользователь может открыть через интернет-браузер на своём устройстве.
Основные функции:
–Отображение медиатеки
5.2Уровень бизнес-логики
Сервер приложений реализует бизнес‑логику сервиса и выступает
промежуточным звеном между клиентом и СУБД. На этом уровне
выполняются: проверка учетных данных пользователя, обработка поиска
и рекомендаций, ведение истории прослушиваний, формирование
SQL‑запросов к базе данных и обработка результатов перед отправкой на
клиент.
Для реализации использованы следующие технологии: Python 3.10, Flask
(или Django, в зависимости от выбора команды), PostgreSQL 16 в качестве СУБД,
а также интеграция с S3-совместимым объектным хранилищем для хранения
аудиофайлов медитаций.
Серверное приложение реализовано в виде монолита, что соответствует
выбранной архитектуре (раздел 3). Внутренняя структура организована в
виде модулей, каждый из которых отвечает за определённую область
функциональности:
1.auth_module— управление пользователями, аутентификация,
авторизация, ролевая модель
21