Для понимания конечной цели, были составлены функциональные требования к веб-приложению:
1. Возможность регистрации
1.1. Ввод личных данных (ФИО, логин, пароль, дата рождения, пол, регион, ссылка ВКонтакте, номер телефона)
1.2. Возможность получать подсказки при заполнении полей анкеты
2. Возможность авторизации на сайте:
2.1. Ввод личных данных (логин, пароль)
2.2. Возможность вводить пароль не более 6 раз (при ошибке)
3. Действия с фильмами
3.1. Неавторизованный пользователь
3.1.1. Просмотр видео
3.1.2. Поиск по году, жанру, стране, режиссеру
3.1.3. Просмотр рейтингов, новинок и случайных фильмов
3.1.4. Просмотр информации о фильме: год, страна, режиссер, сценарист, продюсер, оператор, композитор, монтаж, жанр, возрастное ограничение, продолжительность фильма, актеры)
3.2. Авторизованный пользователь
3.2.1. Просмотр видео
3.2.2. Поиск по году, жанру, стране, режиссеру
3.2.3. Просмотр рейтингов, новинок и случайных фильмов
3.2.4. Просмотр информации о фильме: год, страна, режиссер, сценарист, продюсер, оператор, музыкальное сопровождение, монтаж, жанр, возрастное ограничение, продолжительность ролика, актеры, ссылка на страницу автора ВКонтакте)
3.2.5. Действия с личными фильмами
3.2.5.1. Загрузка фильма
3.2.5.2. Заполнение информации
3.2.5.3. Просмотр рейтингов
3.2.6. Действия с фильмами других режиссеров
3.2.6.1. Просмотр роликов
3.2.6.2. Оценка по 10-балльной шкале
3.2.7. Возможность связаться с автором
На следующем этапе были построены такие UML-диаграммы, как диаграмма вариантов использования (рисунок 5), диаграммы деятельности (рисунки 6-9), диаграммы последовательности (рисунки 10-13).
Рисунок 5. Диаграмма вариантов использования
В ходе создания диаграммы вариантов использования было выделено три роли: администратор, авторизованный и неавторизованный пользователь. На диаграмме видно, что для полноценного использования веб-приложения необходимо быть авторизованным пользователем. Неавторизованные пользователи могут просматривать фильмы, но не могут оценивать их, оставлять комментарии и загружать «свои» фильмы.
Рисунок 6. Диаграмма деятельности (регистрация)
Рисунок 6 демонстрирует процесс регистрации в веб-приложении. Активатором процесса является неавторизованный пользователь. Окончание – сообщение пользователю о статусе регистрации: «Успешно зарегистрирован» либо «Ошибка регистрации» с пояснениями.
Рисунок 7. Диаграмма деятельности (добавление «своего» фильма со стороны пользователя)
Рисунок 8. Диаграмма деятельности (добавление «своего» фильма со стороны администратора)
На рисунках 7, 8 отображен процесс добавления «своего» фильма на ресурс. Этот процесс делится на два подпроцесса: загрузка фильма пользователем и подтверждение и публикация администратором.
Активатором первого подпроцесса является авторизованный пользователь, окончанием – сообщение пользователю «Фильм отправлен на проверку» либо «Ошибка добавления» с пояснениями.
Активатором второго подпроцесса является администратор, окончанием – изменение статуса фильма на «Одобрен» либо «Отклонен».
Рисунок 9. Диаграмма деятельности (добавление оценки фильму)
Активатором процесса на рисунке 9 является авторизованный пользователь, окончание – изменение оценки фильма. Пересчет рейтинга выполняется в базе данных с помощью триггера.
Диаграммы последовательностей, изображенные на рисунках 10-13, соответствуют диаграммам деятельности с идентичными названиями.
Рисунок 10. Диаграмма последовательности (регистрация)
Рисунок 11. Диаграмма последовательности (добавление «своего» фильма со стороны пользователя)
Рисунок 12. Диаграмма последовательности (добавление «своего» фильма со стороны администратора)
Рисунок 13. Диаграмма последовательности (добавление оценки)
После составления UML-диаграмм была составлена логическая модель базы данных (рисунок 14), а затем по этой модели была создана сама база данных. В качестве СУБД была выбрана MS Sql Server. База данных расположена на сервере Microsoft Azure.
Рисунок 14. Логическая модель БД
Основными сущностями являются Film и User, которые хранят данные о фильме и пользователе соответственно. В таблице Б.1 приложения Б подробно описаны поля таблиц.
На рисунке 15 частично представлена диаграмма классов. На диаграмме представлены имеющиеся контроллеры и сервисы. Также в исходном коде веб-приложении есть классы, отвечающие за базу данных и классы, отвечающие за модели для представлений. Для упрощения восприятия рисунков, методы сервисов, которые наследуются от интерфейсов не указаны, но в исходном коде веб-приложения все они реализованы.
Рисунок 15. Диаграмма классов
Из рисунка 15 видно, что в приложении имеется 3 контроллера. FilmsController отвечает за GET- и POST-запросы, связанные с действиями с фильмами, UsersController – за запросы, связанные с пользователями, т.е. оба эти контроллера являются ApiController.
HomeController не выполняет функции API и предназначен для загрузки главного html-файла Index.html.
В сервисах помимо классов, предназначенных для работы с пользователями и фильмами, есть сервис BlobService. Этот сервис предназначен для работы с BLOB-объектами, а конкретно – для загрузки и скачивания фильмов из облачного хранилища.