Объектом разработки является веб-приложение подбора состава музыкального ансамбля.
Цель работы – проектирование и реализация веб-приложения, позволяющего с одной стороны музыкантам находить музыкальные ансамбли для творческого сотрудничества, с другой – организаторам ансамблей приглашать в свои коллективы наиболее подходящих исполнителей.
В результате разработки было спроектировано веб-приложение, предоставляющее удобный фильтрованный поиск музыкантов и ансамблей с возможностью отправки запроса на вступление в группу или приглашения других музыкантов и просмотра контактных данных сокомандников, а также проведено тестирование разработанного продукта методами черного ящика.
Пользователями приложения могут быть как профессиональные музыканты, так и те, кто занимается музыкальным творчеством любительски.
СОДЕРЖАНИЕ
1 Анализ предметной области и уточнение спецификаций 5
1.1 Анализ задания и выбор технологии и инструментальных средств разработки 5
1.2 Объектная декомпозиция предметной области 6
1.3 Разработка диаграммы вариантов использования 7
1.4 Разработка концептуальной модели предметной области 16
2 Проектирование структуры и компонентов программного продукта 18
2.1 Разработка графов абстрактного диалога 18
2.2 Разработка графа состояний интерфейса 20
2.3 Разработка форм пользовательского интерфейса 22
2.4 Разработка диаграммы пакетов и детализации 26
2.5 Разработка базы данных приложения 28
3 Выбор стратегии тестирования и разработка тестов 35
3.1 Функциональное тестирование 35
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 47
Приложение А. Техническое задание. 48
Приложение Б. Руководство пользователя. 57
Приложение В. Фрагмент исходного кода программы 76
Музыкальное искусство беспрерывно сопровождает человечество на его пути. В современном мире значимость музыки не уменьшается, однако с появлением новых направлений и технологий у музыкантов возникают новые требования при поиске идеальных партнеров для творческого сотрудничества. В ответ на эти потребности было спроектировано и разработано веб-приложение подбора состава музыкального ансамбля.
Разработанное приложение предоставляет удобные инструменты как для музыкантов, стремящихся найти группы, так и для организаторов ансамблей, ищущих музыкантов для своих ансамблей. Музыканты имеют возможность направлять запросы на вступление, а администраторы ансамблей вправе принимать или отклонять эти запросы. Кроме того, администраторы могут инициировать приглашения, предлагая музыкантам вступить в их музыкальные ансамбли.
** Для реализации приложения был выбран клиент-серверный архитектурный шаблон MVC, который расшифровывается как «модель-представление-контроллер» (от англ. model-view-controller). В архитектуре MVC модель является компонентом, отвечающим за данные и осуществляющим загрузку и сохранение данных в реляционной базе данных, представление отвечает за взаимодействие с пользователем, а контроллер связывает модель с представлением и определяет поведение программы на действия пользователя. Шаблон MVC удовлетворяет потребностям и специфике реализованного приложения.
Для разработки приложения была выбрана спиральная модель жизненного цикла, как наиболее гибкая, устойчивая к изменениям требований и позволяющая возвращаться между этапами проекта. Благодаря спиральной модели жизненного цикла реализация программы осуществлялась итерационно.
Из-за множества функций и требований к приложению, использовался принцип нисходящего проектирования, позволяющий обнаружить и исправить логические ошибки на более ранних этапах программирования, когда внесение изменений еще не приводит к коренной перестройке всей программы. Нисходящее проектирование позволяет разбивать большую задачу на меньшие подзадачи так, чтобы каждую подзадачу можно было рассматривать независимо.
При проектировании приложения был выбран объектно-ориентированный подход, в основе которого лежит методология объектно ориентированного программирования (ООП). Парадигма программирования ООП основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса, когда как классы образуют иерархию на принципах наследуемости. ООП широко используется в разработке веб-приложений, обеспечивая масштабирование, модульность, расширяемость, возможность повторного использования компонентов. Кроме того, необходимость использования объектно-ориентированного подхода подтверждается наличием пользовательского интерфейса, предполагающего событийное программирование [1]. Так, события играют роль сообщений, посредством которых объекты взаимодействуют друг с другом.
В качестве фреймворка, объединившим в себе архитектурный шаблон MVC и объектно-ориентированный подход, был выбран Ruby on Rails [2]. Серверная часть приложения была реализована именно в этом фреймворке с использованием сверхверхнеуровневого языка программирования Ruby 3.0.2 [3], обладающего богатым набором инструментов, повышающих производительность разработки. Для реализации авторизации и регистрации пользователей на серверной части приложения был выбран инструмент Devise [4]. Клиент-серверная архитектура приложения вызывает потребность использования базы данных. Ruby on Rails может быть интегрирован с любой СУБД, однако была выбрана PostgreSQL [5], как наиболее популярная и легко поддерживаемая на любых операционных системах.
Для интерфейса клиентской части веб-приложения был выбран набор, включающий языки разметки HTML и eRuby, язык декорирования CSS. Этот комплект инструментов поддерживается большинством современных браузеров, а также удобно интегрируется с серверной частью.
В основе объектного подхода разработки лежит объектная декомпозиция, которая помогает представить разрабатываемую программу в виде совокупности объектов и функций, выполняющихся посредством передачи сообщений между ними [6].
В результате анализа технического задания, были выделены основные объекты и определены их взаимодействия друг с другом. Объекты и сообщения между ними представлены на рисунке 1.
Рисунок 1 – Объектная декомпозиция программы подбора состава музыкального ансамбля
В результате объектной декомпозиции, на концептуальном уровне были выделены объекты: пользователь, музыкальный ансамбль, запрос, приглашение, музыкальный инструмент, музыкальный жанр. С одной стороны, пользователь по предпочитаемым музыкальным жанрам и своим музыкальным инструментам ищет музыкальный ансамбль и отправляет запрос на вступление. С другой стороны, создав ансамбль, пользователь управляет им и отправляет приглашения другим пользователям-музыкантам.
Для выявления внешних пользователей приложения и определения их ролей и аспектов их поведения была разработана диаграмма вариантов использования. В результате разработки диаграммы выяснилась потребность в следующих четырех ролях пользователей, причем роли не являются статическими, а определяются в зависимости от ситуации.
- Неавторизованный пользователь. Неавторизованным пользователем считается пользователь, не прошедший этап авторизации. К таким относятся и незарегистрированные в системе пользователи.
- Пользователь (музыкант). Пользователю, прошедшему авторизацию, доступен основной функционал программы. В рамках приложения все пользователи считаются музыкантами.
- Участник ансамбля. Данная роль присваивается тем пользователям, которые вступили в музыкальный ансамбль.
- Администратор ансамбля (организатор ансамбля). Администратором группы может стать любой пользователь, решивший сформировать музыкальный ансамбль.
Стоит отметить, что при формировании ансамбля администратор также может стать участником группы, выбрав музыкальный инструмент.
В соответствии с ролью пользователя был разграничен доступный функционал. Основные варианты использования описаны в таблицах 1-9.
Таблица 1 – Описание варианта использования «Сформировать музыкальный ансамбль»
| Название варианта использования | Сформировать музыкальный ансамбль |
|---|---|
| Цель | Создание музыкального ансамбля. |
| Действующие лица | Любой пользователь |
| Краткое описание | Процесс осуществляет создание музыкального ансамбля с возможностью выбора географических данных группы, музыкальных жанров и количество необходимых музыкальных инструментов. |
| Тип варианта | Основной |
Таблица 2 – Типичный ход событий варианта использования «Сформировать музыкальный ансамбль»
| Действия пользователя | Отклик системы |
|---|---|
| 1. Пользователь переходит на страницу просмотра всех групп. | |
| 2. Пользователь нажимает на кнопку «Сформировать ансамбль». | 3. Система открывает форму создания ансамбля. |
| 4. Пользователь заполняет исходные данные для формирования ансамбля. | |
| 5. Пользователь нажимает на кнопку «Создать». | 6. Система производит валидацию введенных пользователем данных и при успешной валидации записывает в базу данных записи в таблицы музыкальных ансамблей, необходимых инструментов ансамблей и музыкальных жанров ансамблей. |
| 7. Система переводит пользователя на страницу просмотра созданного ансамбля. |
Альтернатива
6. Если пользователь ввел некорректные данные, то система выводит сообщение об ошибках и предлагает исправить их.
Дополнительная информация
1. Возможен выход из режима создания ансамбля при нажатии на кнопку «Вернуться к просмотру групп».
Таблица 3 – Описание варианта использования «Пригласить музыканта в ансамбль»
| Название варианта использования | Пригласить музыканта в ансамбль |
|---|---|
| Цель | Отправка на электронную почту музыканта приглашения вступить в ансамбль |
Продолжение таблицы 3
| Действующие лица | Администратор ансамбля |
|---|---|
| Краткое описание | Результатом выполнения варианта использования является отправленное на электронную почту письмо с приглашением вступить в музыкальный ансамбль. |
| Тип варианта | Основной |
Таблица 4 – Типичный ход событий варианта использования «Пригласить музыканта в ансамбль»
| Действия пользователя | Отклик системы |
|---|---|
| 1. Пользователь переходит на страницу просмотра всех музыкантов или на профиль определенного музыканта. | |
| 2. Пользователь наводит курсором на блок с текстом «Пригласить в ансамбль». | 3. Система раскрывает выпадающий список со всеми музыкальными ансамблями, сформированными текущим пользователем. |
| 4. Пользователь в выпадающем списке выбирает ансамбль, в который желает пригласить музыканта, и нажимает на кнопку с названием группы. | 5. Система создает запись в таблице приглашений. |
| 6. Система отправляет письмо-приглашение на электронную почту музыканта. |
Таблица 5 – Вариант использования «Вступить в ансамбль по приглашению».
| Название варианта использования | Вступить в ансамбль по приглашению |
|---|---|
| Цель | Выдача музыканту прав участника ансамбля. |
| Действующие лица | Музыкант |
| Краткое описание | Перейдя по ссылке из письма с приглашением, музыкант выбирает инструмент, с которым он хотел присоединиться к ансамблю. |
| Тип варианта | Основной |
Таблица 6 – Типичный ход событий. Вариант использования «Вступить в ансамбль по приглашению»
| Действия пользователя | Отклик системы |
|---|---|
| 1. Система при помощи внешнего почтового сервиса отправляет письмо с приглашением вступить в ансамбль. | |
| 2. Пользователь получает письмо. | |
| 3. Пользователь переходит по ссылке из письма. | 4. Система направляет пользователя на форму для выбора инструмента, играя на котором, он желал бы присоединиться к ансамблю. Инструменты для выбора предлагаются из отмеченных в анкете пользователя инструментов. |
| 5. Пользователь выбирает инструмент и нажимает кнопку «Вступить». | 6. Система обновляет статус приглашения в базе данных. |
| 7. Система создает запись в таблице участников ансамблей. | |
| 8. Система выдает права участника ансамбля пользователю. | |
| 9. Система отправляет письмо организатору ансамбля с оповещением о том, что отправленное приглашение было принято. |
Альтернатива
3. Пользователь может не прочитать письмо или не переходить по ссылке.
Таблица 7 – Описание варианта использования «Отправить запрос на вступление в ансамбль»
| Название варианта использования | Отправить запрос на вступление в ансамбль |
|---|---|
| Цель | Оповещение администратора ансамбля о запросе на вступление. |
Продолжение таблицы 7
| Действующие лица | Музыкант |
|---|---|
| Краткое описание | Выбрав подходящий ансамбль, музыкант, желающий вступить в него, отправляет запрос на вступление. |
| Тип варианта | Основной |
Таблица 8 – Типичный ход событий варианта использования «Отправить запрос на вступление в ансамбль»
| Действия пользователя | Отклик системы |
|---|---|
| 1. Пользователь переходит на страницу всех ансамблей или конкретного ансамбля. | |
| 2. Пользователь нажимает на кнопку «Вступить в ансамбль». | 3. Система создает запись в таблице запросов. |
| 4. Система при помощи почтового сервиса отправляет письмо на электронную почту администратора с информацией о запросе. |
Таблица 9 – Описание варианта использования «Принять или отклонить запрос на вступление в ансамбль»
| Название варианта использования | Принять или отклонить на вступление в ансамбль. |
|---|---|
| Цель | Принять решение по пришедшему запросу. |
| Действующие лица | Администратор ансамбля |
| Краткое описание | Получив письмо о запросе другим пользователем на вступление в группу, администратор ансамбля может как принять запрос, так и отклонить его. |
| Тип варианта | Основной |
Таблица 10 – Типичный ход событий варианта использования «Принять или отклонить запрос на вступление в ансамбль»
| Действия пользователя | Отклик системы |
|---|---|
| 1. Пользователь получает письмо с запросом от другого пользователя вступить в ансамбль. | |
| 2. Пользователь переходит по ссылке из письма. | 3. Система переводит пользователя на страницу с подробной информацией о запросе. |
| 4. Пользователь принимает решение по запросу: принимает или отклоняет его. | 5. Система обновляет статус запроса в базе данных. |
| 6. Система отправляет пользователю, отправившему запрос, письмо с результатом. |
В результате анализа вышеописанных вариантов использования программы была разработана диаграмма вариантов использования, демонстрирующая варианты использования программы в зависимости от текущей роли пользователя. Неавторизованному пользователю доступны просмотр страниц ансамблей и музыкантов, однако попытка выполнения других вариантов использования переводят пользователя на страницу авторизации. Участники ансамбля и администраторы ансамбля имеют все возможности музыканта, поэтому их варианты использования унаследованы от последнего. Кроме того, важно отметить, что выполнение некоторых вариантов происходит через внешний почтовый сервис, который представляет собой вторичное лицо, отвечающее за доставку электронных писем пользователям. Разработанная диаграмма представлена на рисунке 2.
Рисунок 2 – Диаграмма вариантов использования
Выявленные варианты использования помогли разделить разрабатываемую программу основных режима работы: поиск музыкантом администратором ансамбля и поиск ансамбля музыкантом. Для лучшего понимания стоит рассмотреть детализацию процесса одного из режимов работы программы, например, последовательность действий при поиске музыканта. В этих целях была разработана диаграмма деятельности, представленная на рисунке 3, охватывающая варианты использования «Просмотреть список музыкантов», «Отфильтровать список музыкантов», «Пригласить музыканта в ансамбль», «Вступить в ансамбль по приглашению», «Просмотреть контактные данные участников ансамбля».
Рисунок 3 – Диаграмма деятельности при поиске музыканта
В разработанной диаграмме деятельности показана последовательность событий, которая приводит в итоговой цели веб-приложения – формирования состава музыкального ансамбля. По окончании описанных действий, то есть при вступлении в группу, музыкант приобретает роль участника группы и получает возможность просматривать контактные данные состава ансамбля для дальнейшего сотрудничества.
На основании выделенных объектов и вариантов использования программы, необходимо провести анализ взаимодействия между объектами и выявить связи между ними и сообщения, передаваемые друг другу для удовлетворения спецификациям и требованиям разрабатываемой программы и для удобства реализации в программе вышеописанных вариантов использования.
Понятия, характерные для предметной области, совпадают с объектами, выделенными на этапе объектной декомпозиции программы:
– пользователь в роли музыканта, администратора ансамбля или участника ансамбля;
– музыкальный ансамбль;
– музыкальный инструмент;
– музыкальный жанр;
– приглашение;
– запрос.
Концептуальная модель предметной области представлена на рисунке 4. Как было сказано в пункте 1.3, у пользователя может быть несколько ролей, которые определяются в зависимости от его действий. В концептуальной модели роли пользователя изображены отдельно для более корректного разделения сообщений между объектами, однако, все роли относятся к одному объекту – пользователь.
Рисунок 4 – Концептуальная модель предметной области
Разработанная концептуальная модель демонстрирует взаимодействия объектов и сообщения, передаваемые между объектами. На диаграмме разграничены сообщения, передаваемые от пользователя, в зависимости от его текущей роли.
Проектирование программного продукта стоит начать с продумывания интерфейсов пользователя. Диалог на верхнем уровне должен обеспечивать реализацию вариантов использования программы на клиентской части программы. Так как в программе реализовано два режима работы, то необходимо рассмотреть диалоги для каждого из режимов как для музыканта, так и для администратора ансамбля.
Для музыканта возможно два сценария: отправка запроса и получение приглашения. На рисунке 5 изображен первый сценарий для музыканта. **
![ref1]
Рисунок 5 – Граф абстрактного диалога программы для музыканта, отправляющего запрос
**
Как видно из рисунка, пользователь самостоятельно ищет ансамбль и после выбора наиболее подходящего отправляет запрос на вступление в него. Спустя некоторое время музыкант получает письмо о решении администратора по запросу: принят или отклонен.
Другой сценарий для музыканта, предполагающий получение приглашения на почту, изображен на рисунке 6. Музыкант может получить письмо с приглашением вступить в ансамбль. Выполнив инструкцию из письма, музыкант может принять приглашение. При нежелании вступать, никаких действий не требуется: письмо можно проигнорировать.
![ref2]
Рисунок 6 – Граф абстрактного диалога программы для музыканта, получившего приглашение
**
Сценарии, показанные на рисунках 5-6, также стоит рассмотреть со стороны администратора ансамбля. На рисунках 7-8 представлены графы абстрактного диалога для администратора ансамбля, отправляющего приглашение и получающего запрос соответственно.
![ref3]
Рисунок 7 – Граф абстрактного диалога программы для администратора ансамбля, приглашающего музыканта в ансамбль
![ref4]**
Рисунок 8 – Граф абстрактного диалога программы для администратора ансамбля, получившего запрос на вступление в ансамбль
Графы абстрактного диалога, представленные выше, позволяют взглянуть на последовательность действий для конкретного пользователя и определить необходимые формы интерфейса для реализации этих действий.
На основании анализа графов абстрактного диалога был разработан общий граф состояний интерфейса, охватывающий все варианты использования и обеспечивающий быстрое переключение между режимами. Клиентская часть приложения в архитектуре MVC реализована в виде представлений, осуществляющих страниц в веб-приложении. Каждое представление может содержать в себе ссылки на другие, что обеспечивает навигацию пользователя по состояниям интерфейса.
На рисунке 9 изображен граф состояний интерфейса веб-приложения.
Рисунок 9 – Граф состояний интерфейса
Представленный на рисунке 9 граф демонстрирует возможные маршруты авторизованного пользователя при подборе состава музыкального ансамбля без учета переходов при указании запросов через ссылку, так как таким образом можно перейти на любую страницу приложения. Стоит обратить внимание на наличие нескольких входов в графе. В разработанном приложении почта играет огромную роль для коммуникации с пользователями и оповещением статуса их приглашения или запроса или поступления новых. Тела писем содержат в себе ссылки на страницы принятия решения по поводу запроса или приглашения, на которые невозможно попасть из основного входа в веб-приложение. Кроме того, навигационная панель позволяет перейти на большую часть страниц.
На графе состояний интерфейса изображены следующие события:
– С1 – переход на главную страницу приложения;
– С2 – переход из навигационной панели на страницы всех музыкантов, всех ансамблей, ансамблей пользователя, анкеты пользователя, настроек пользователя, приглашений пользователя, запросов пользователя;
– С3 – переход на страницу принятия приглашения;
– С4 – переход на страницу принятия решения по запросу;
– С5, С8 –переход на страницу всех ансамблей;
– С7, C12, C13, C14 – переход на страницу ансамбля;
– С6, С11 –переход на страницу всех музыкантов;
– С10 – переход на страницу музыканта;
– С9 – переход на форму создания нового ансамбля;
– С10 – завершение работы с программой.
На основе диаграмм состояния интерфейсов, сценариев использования, описанных выше, были разработаны формы интерфейса, обеспечивающие взаимодействие с пользователем. При разработке экранных форм также учитывались такие важные факторы, как особенности восприятия цвета и особенности фокусирования внимания [1]. Так как более холодные цвета оказывают более спокойное влияние на человека, то выбор был сделан в пользу черничных оттенков, подобранных с помощью палитры цветов, чтобы обеспечить привлечение внимания пользователя, но при этом не переутомить его обилием цветов. Чтобы пользователь был сфокусирован на вариантах использования приложения, экранные формы разрабатывались с минимально возможным текстом и с большими шрифтами в необходимых для акцентирования внимания местах.
**
Диаграмма вариантов использования определяет, что интерфейс пользователя должен обеспечить выбор режима работы и выполнение групп операций каждого режима. Именно поэтому экранная форма главной страницы, представленная на рисунке 10, была разработана с возможностью выбора режима работы: «Поиск музыкантов» и «Поиск групп».
Рисунок 10 – Главная страница приложения
Переключение режима работы возможно не только на главной странице, но и в навигационной панели. Навигационная панель позволяет переключиться в любой момент использования приложения, а также визуально определяет основные функциональные возможности приложения. Кроме того, доступен переход на некоторые страницы из выпадающего списка, что гарантирует переход на любые варианты использования в любой момент использования приложения. Выпадающий список показан на рисунке 11.
Рисунок 11 – Выпадающий список с вариантами использования
Учитывая психофизические особенности человека, связанные с восприятием, запоминанием и обработкой информации, все страницы были разработаны в едином стиле. Например, на интерфейсе страницы всех ансамблей, представленный на рисунке 12, четко разделены ансамбли за счет отображения их в виде карточек. Для быстрого поиска была добавлена панель фильтрации по параметрам, что позволяет убрать неподходящие варианты.
Рисунок 12 – Страница ансамблей
Нажатие на карточку позволяет перейти на страницу ансамбля, показанную на рисунке 13.
Рисунок 13 – Страница просмотра ансамбля
Страница просмотра ансамбля выполнена в таком же стиле, что и другие, и также не содержит визуального шума. На этой странице есть возможность вернуться к просмотру ансамблей или вступить в ансамбль. Нажатие на кнопку вступления отправляет письмо администратору группы, показанное на рисунке 14.
Рисунок 14 – Письмо-запрос на вступление в ансамбль
Основная коммуникация осуществляется посредством почтового сервиса. Причиной этому является тесная интеграция телефонов в жизни людей. Телефон находится в руках человека достаточно много времени на протяжение дня, а электронные письма приходят на телефон в виде уведомлений, которыми можно обратить внимание человека на приложение. Принятие решения по запросам и приглашениям может занять некоторое время, учитывая человеческий фактор, поэтому необходимо доставлять информацию о выполненном действии сразу же.
Таким образом, представленные выше экранные формы с интуитивно понятным интерфейсом и уведомления о событиях на электронную почту должны обеспечить пользователю удобную навигацию по приложению для достижения основной цели использования приложения – подбора состава музыкального ансамбля.
Структура разрабатываемого веб-приложения, реализованного в фреймворке Ruby on Rails, основывается на четырех основных компонентах фреймворка: представления, контроллеры, модели и мейлеры. Диаграмма пакетов представлена на рисунке 15.
Рисунок 15 – Диаграмма пакетов
В качестве представлений используются страницы в формате eRuby. Клиентская часть приложения в виде представлений вызывает методы контроллеров, которые при необходимости могут использовать модели. Модели представляют собой классы, основанные на таблицах базы данных. Контроллеры обрабатывают запросы, приходящие с представлений, и отправляют ответы обратно. В разрабатываемом приложении контроллеры неоднократно используют мейлеры, отвечающие за отправку электронных писем.
На рисунке 16 представлена детализация пакета моделей.
Рисунок 16 – Детализация пакета моделей
Как видно, пакет моделей состоит из интерфейса ApplicationRecord, содержащего необходимые методы для работы с записями таблиц, и моделей, наследуемых от интерфейса и совпадающих с сущностями базы данных.
Для удобства реализации приложения методы серверной части приложения были распределены по контроллерам. На рисунке 17 детализирован пакет контроллеров.
Рисунок 17 – Детализация пакета контроллеров
Таким образом, контроллеры приложения наследуются от интерфейса ApplicationController. К публичным методам контроллеров осуществляются обращения с клиентской части приложения. Так, к примеру, метод send_invitation_mail контроллера приглашений отвечает за вызов мейлера приглашений, который в свою очередь предназначен для отправки писем с приглашениями.
Все содержимые элементы пакетов в фреймворке Ruby on Rails являются классами. Именно поэтому при проектировании приложения не требуется диаграмма классов, так как она полностью совпадает с описанными выше элементами пакетов.
Клиент-серверная архитектура разрабатываемого приложения требует наличие базы данных для полноценной работы с приложением. На основании анализа объектной декомпозиции и концептуальной модели предметной области были определены сущности базы данных приложения и продуманы атрибуты для каждой сущности. Схема базы данных изображена на рисунке 18. Связи между сущностями были выбраны в соответствии с третьей нормальной формой базы данных. К примеру, стоит рассмотреть связь между музыкантами и инструментами. Каждый музыкант может играть на нескольких инструментах, при этом на одном и том же инструменте могут играть разные музыканты. Для этого была создана дополнительная таблица Musician Instrument, содержащая записи о связи музыканта с инструментом. Аналогичным образом устроены связи между музыкантом и музыкальными жанрами, ансамблем и инструментами, ансамблем и жанрами, музыкантами и ансамблями.
Рисунок 18 – Схема базы данных приложения
СОДЕРЖАНИЕ
1 Общие сведения по работе с приложением 3
2 Начало работы с приложением 3
3 Инструкция по работе с приложением 4
3.1 Работа с личной информацией 5
3.2 Работа в режиме поиска ансамблей 9
3.3 Работа в режиме поиска музыкантов 13
4 Завершение работы с приложением 18
Веб-приложение подбора состава музыкального ансамбля предоставляет удобный фильтрованный поиск музыкантов и ансамблей. Сформировав музыкальный ансамбль, администратор может приглашать музыкантов присоединиться. Аналогично, музыканты могут отправлять запросы на вступление в выбранные ими ансамбли и получать письма на электронную почту о принятом решении.
** Неавторизованному пользователю доступны только страницы просмотра всех ансамблей и всех музыкантов. Для дальнейшего взаимодействия с приложением необходимо авторизоваться в системе. Поэтому любые действия неавторизованного пользователя ведут на страницу авторизации (см. рисунок Б.1).
Рисунок Б.1 – Форма авторизации
Для авторизации необходимо ввести электронную почту и пароль, установленный при регистрации. При следующем входе в систему в течение суток повторная авторизация не потребуется. Если в процессе авторизации был установлен флаг "Запомнить меня", то повторная авторизация не потребуется в течение нескольких месяцев.
Незарегистрированный пользователь, нажав на кнопку «Регистрация», переводится на страницу регистрации (см. рисунок Б.2).
Рисунок Б.2 – Форма регистрации в приложении
Заполнив поля электронной почты, пароля и подтверждения почты, пользователю приходит письмо на указанную почту с инструкцией для подтверждения профиля. Перейдя по ссылке из письма, пользователь автоматически авторизовывается в приложении и может им пользоваться полноценно.
** Авторизованный пользователь в самом начале пути ознакомления с веб-приложением попадает на главную страницу, изображенную на рисунке Б.3.
Рисунок Б.3 – Главная страница приложения
Главная страница предоставляет пользователю выбор дальнейшего режима работы: поиск музыкантов или поиск групп.
Перед началом работы в одном из режимов, рекомендуется ознакомиться со страницами с личной информацией пользователя. Выпадающий список выбора страниц отображается при нажатии на иконку в правом верхнем углу навигационной панели, как на рисунке Б.4.
Рисунок Б.4 – выпадающий список с выбором страниц
Нажатие на кнопку «Моя анкета» в выпадающем списке переводит пользователя на страницу его анкеты. Карточка на рисунке Б.5 отображает информацию, заполненную в анкете, а также прикрепленное видео при наличии.
Рисунок Б.5 – страница анкеты
На странице присутствует кнопка «Редактировать анкету», нажав на которую можно заполнить актуальную информацию и загрузить видео демонстрации своих навыков.
Нажатие на кнопку «Мои группы» в выпадающем списке навигационной панели переводит пользователя на страницу ансамблей, на которой представлены собранные пользователем ансамбли и ансамбли, в которых пользователь является участником. Ансамбли пользователя показаны на рисунке Б.6.
Рисунок Б.6 – Страница ансамблей пользователя
Нажатие на кнопку «Настройки» в выпадающем списке навигационной панели переводит пользователя на страницу, редактирования информации пользователя, необходимой пользования приложением: электронная почта и пароль (см. рисунок Б.7). На этой странице также возможно удаление аккаунта.
Рисунок Б.7 – Страница редактирования аккаунта пользователя
Страницы запросов и приглашений представляют собой журнал записей в таблице запросов и приглашений с текущими статусами (см. рисунки Б.8-Б.9).
![ref5]
Рисунок Б.8 – Страница запросов**
Рисунок Б.9 – Страница приглашений
Как показано на рисунке Б.9, отправленные приглашения со статусом «В ожидании» можно отменить.
При выборе пользователем режима «Поиск групп» система осуществляет переход на страницу ансамблей, представленную на рисунке Б.10.
Рисунок Б.10 – Страница ансамблей
На рисунке видно, что каждый ансамбль изображен в виде карточки с минимальной необходимой информацией. Для участников ансамбля на карточке отображается текст «Вы являетесь участником этой группы». При нажатии «Подробнее» открывается страница выбранного ансамбля, как показано на рисунке Б.11.
Рисунок Б.11 – Страница просмотра ансамбля
Как на странице ансамбля, так и на странице всех ансамблей можно выполнить вариант использования «Вступить в группу». При нажатии на кнопку открывается форма выбора инструмента музыканта для создания запроса, который будет отправлен администратору ансамбля. Форма создания запроса представлена на рисунке Б.12.
Рисунок Б.12 – Форма выбора инструмента при создании запроса
на вступление в ансамбль
После отправки запроса администратору ансамбля приходит письмо о запросе, показанное на рисунке Б.13.
Рисунок Б.13 – Письмо о запросе вступить в ансамбль
Перейдя по ссылке из письма, администратор системы попадает на страницу принятия решения по запросу от музыканта. Для этого выводится информация о пользователе и при наличии – видео демонстрации своих навыков. На рисунке Б.14 представлена страница принятия решения.
Рисунок Б.14 – Страница принятия решения по запросу
После принятого администратором решения пользователю музыканту письмо на почту. Кроме этого, на странице запросов меняется статус запроса (см. рисунок Б.15).
![ref5]
Рисунок Б.15 – Страница запросов
Как видно на рисунке статус последнего запроса – «отклонено».
** Для поиска и дальнейшего приглашения музыкантов в ансамбль, пользователь должен иметь созданные ансамбли. В этих ансамблях пользователь в роли администратора ансамбля. При отсутствии ансамблей или при желании создать новый, надо перейти на страницу ансамблей, показанную на рисунке Б.10 и нажать на кнопку «Собрать группу». При нажатии пользователем на кнопку система осуществляет переход на форму создания нового ансамбля, представленную на рисунке Б.16.
Рисунок Б.16 – Форма создания ансамбля
Если администратор ансамбля желает быть участником ансамбля, то ему необходимо выбрать музыкальный инструмент, на котором он будет играть. Оставив это поле пустым, администратор получает роль организатора ансамбля, но при этом не является его участником.
**
Имея созданные ансамбли, можно начать полноценную работу в режиме поиска музыкантов. При выборе режима на главной странице или при переходе из навигационной панели открывается страница музыкантов, изображенная на рисунке Б.17.
Рисунок Б.17 – Страница музыкантов
При наведении курсором на блок «Пригласить в группу» открывается выпадающий список с ансамблями, администратором которых является пользователь (см. рисунок Б.18). Среди отображающихся в списке ансамблей администратор выбирает тот, в который хочет пригласить музыканта.
Рисунок Б.18 – Карточка музыканта
После нажатия на название выбранного ансамбля для приглашения, музыканту отправляется письмо с приглашением вступить в данный ансамбль. Тело письма-приглашения продемонстрировано на рисунке Б.19.
Рисунок Б.19 – Письмо-приглашение вступить в ансамбль
Музыкант, желающий вступить в ансамбль, переходит по ссылке из письма-приглашения, и система его перенаправляет на страницу выбора инструмента для вступления в ансамбль. В выпадающем списке выбор инструментов представляется из инструментов музыканта, отмеченных им в анкете. Форма выбора музыкального инструмента для вступления в ансамбль представлена на рисунке Б.20.
Рисунок Б.20 – Форма выбора музыкального
инструмента для вступления в ансамбль
Вступление в ансамбль открывает пользователю возможность просматривать контактные данные других участников ансамбля для связи и дальнейшего партнерства. Отображение контактных данных участников показано на рисунке Б.21.
Рисунок Б.21 – Страница ансамбля для участника
**
На карточке ансамбля в блоке «Состав» отображается должность участника ансамбля, имя, почта и номер телефона.
Для завершения сеанса работы с панелью администрирования достаточно закрыть текущую вкладку веб-браузера. При следующем входе в систему в течение суток повторная авторизация не потребуется.
Для завершения текущей сессии достаточно нажать на иконку на навигационной панели и выбрать вариант «Выйти». Система осуществит завершение текущей сессии пользователя и перенаправит на страницу авторизации.