Интернет-магазин цифровых ключей компьютерных игр

Размещено на http://www.allbest.ru/

8

федеральное государственное бюджетное образовательное учреждение высшего образования

«Вологодский государственный университет»

«УТВЕРЖДАЮ»

Заведующий кафедрой _________________

_______________________________________

подпись расшифровка

«____» _____________________ 20____г.

ЗАДАНИЕ

на выпускную квалификационную работу / научно-квалификационную работу обучающемуся

Притыченко Ивану Александровичу

ФИО полностью

09.03.01 - Информатика и вычислительная техника код, направление подготовки /специальность

Программное обеспечение средств вычислительной техники и автоматизированных систем направленность (профиль/специализация)

1. Тема ВКР / НКР

Интернет магазин цифровых ключей компьютерных игр (утверждена приказом ректора от 01.11.2018 № 08.00-26/1120).

2. Срок сдачи обучающимся завершенной ВКР / НКР _______________

3. Исходные данные к ВКР / НКР

· Предполагаемое количество одновременных запросов к страницам сайта: 25

· Время загрузки страницы не более 3 секунд.

· Операционная система на сервере: Debian 9

· Поддержка браузеров: Google Chrome, Opera, Mozilla Firefox

· СУБД: MySQL

4. Содержание ВКР / НКР (перечень подлежащих разработке вопросов)

Введение

1. Анализ требований к системе

1.1. Постановка задачи

1.2. Обзор аналогов

1.3. Анализ предметной области

2. Проектирование

2.1. Архитектура приложения

2.2. Выбор средств разработки

2.3. Проектирование базы данных

2.4. Проектирование пользовательского интерфейса

3. Реализация

3.1. Серверная часть системы

3.2. Клиентская часть системы

4. Тестирование

4.1. Методика тестирования

4.2. Результаты тестирования

5. Опытная эксплуатация

Заключение

Список использованных источников

Приложения

5. Перечень графического материала (с точным указанием обязательных чертежей)

1. Цель и задачи ВКР

2. Обзор аналогов

3. Use-case диаграмма

4. Архитектура системы

5. Выбор средств разработки

6. Схема БД

7. Реализация серверной части

8. Реализация клиентской части

9. Результаты тестирования

10. Внедрение

6. _______________________________________

7. Консультант по ВКР / НКР (с указанием относящихся к ним глав ВКР / НКР)

_____________________________________________________________

7.1. Задание по экономической части ВКР / НКР

__________________________________________________________________________________________________________________________________________________________________________

Консультант ______________________ (_____________________)

подпись расшифровка

7.2. Задание по БЖД

___________________________________________________________________________________________________________________

Консультант ______________________ (_____________________) подпись расшифровка

7.3. Задание по __________________________________________________________________

_____________________________________________________________

Консультант ______________________ (_____________________)

подпись расшифровка________________________________________

Дата выдачи задания « » __________ 20___г.

Руководитель ВКР / НКР_________ (____________________)

подпись расшифровка

Задание принял к исполнению ____________ (________________) «___» __________ 20__г.

подпись обучающегося расшифровка

Календарный план выполнения ВКР / НКР

№ п/п	Выполняемая обучающимся работа	Сроки выполнения	Отметка о выполнении	Примечание
1	Анализ требований к системе	20.02.19
2	Проектирование	20.03.19
3	Реализация	20.04.19
4	Тестирование	20.05.19
5	Опытная эксплуатация	1.06.19



С Порядком проверки выпускных квалификационных работ и научно-квалификацион-ных работ на объем заимствований, в том числе содержательных, и размещения на Учебно-методическом портале ознакомлен.

Обучающийся __________ (_______________) «___» __________ 20__г.

подпись расшифровка

Руководитель ВКР / НКР ____________ (______________) «___» __________ 20__г.



Оглавление

Введение

1. Аналитический обзор

1.1 Задачи, решаемые магазином

1.2 Обзор аналогов

1.3 Категории пользователей

1.4 Бизнес-правила

2. Проектирование

2.1 Use-case диаграмма

2.2 Выбор архитектуры приложения

2.3 Выбор средств разработки

2.4 Проектирование базы данных

2.5 Проектирование пользовательского интерфейса

3. Реализация

3.1 Серверная часть системы

3.2 Клиентская часть системы

4. Тестирование

4.1 Методика тестирования

4.2 Результаты тестирования

5. Опытная эксплуатация

5.1 Настройка сервера

5.2 Привязка доменного имени

5.3 Настройка инструментов для автоматического развертывания приложения

Заключение

Список использованных источников

Приложение



Введение

С распространением высокоскоростного интернета, все чаще люди предпочитают покупку игр через интернет, чем покупку игр на дисках. Для покупки цифровой версии игры достаточно зайти на сайт магазина ключей игр или на сайт игровой платформы и произвести оплату интересующего товара. После оплаты покупатель получает лицензионный ключ игры, который необходимо активировать в указанной игровой платформе. Если покупка производилась в самой игровой платформе, то активация ключа произойдет мгновенно. После активации начнется загрузка игры на компьютер пользователя. В большинстве случаев выгоднее покупать компьютерные игры не на сайте игровой платформы, а в магазинах ключей.

Цель дипломного проекта - разработать интернет-магазин цифровых ключей компьютерных игр. Разработка данной системы является актуальной, так как сейчас данные проекты пользуются очень большой популярностью, но текущие решения имеют определённые проблемы, которые были выявлены на этапе обзора аналогов.

Для достижения поставленной цели будут решены следующие задачи:

1. Анализ предметной области и определение требований к системе

2. Проектирование базы данных

3. Разработка приложения, которое будет содержать в себе такие функции:

a. Главная страница сайта со списком игр;

b. Страница с информацией об игре;

c. Регистрация и авторизация на сайте;

d. Корзина товаров и личный кабинет покупателя;

e. Панель управления сайтом для администратора которая должна содержать в себе такие возможности как: добавление, удаление и редактирование игр, просмотр списка заказов, покупателей, просмотр общей статистики магазина.

1. Аналитический обзор

1.1 Задачи, решаемые магазином

Сайт интернет-магазина представляет собой сайт с детальным описанием каждого из товаров и услуг с возможностью заказа товаров и оплаты в режиме online.

Задачи, решаемые интернет-магазином:

Размещение информации о компании в Интернете. У каждого интернет-магазина есть свой бренд, который продвигается в интернете различными способами. Наиболее популярными способами продвижения сайта являются:

· Поисковая оптимизация сайта или SEO. Задачи поисковой оптимизации - привлечение целевого трафика, размещение ссылок на сторонних ресурсах и повышение позиций в поисковой выдаче. Цель - увеличение продаж с продвигаемого ресурса.

· Контекстная реклама в рекламных сетях, таких как Яндекс.Директ, Google Adwords.

· Социальные сети и сообщества. Это способ заявить о себе и получить обратную связь.

Детальное информирование посетителей сайта о каждом товаре или услуге компании. Покупатель должен получить как можно больше информации о товаре, ведь только на основе полученной информации принимается решение о покупке. В случае с интернет-магазином цифровых ключей компьютерных игр на странице товара должны быть размещено как можно больше информации как общей информации (описание, скриншоты, трейлеры, геймплей), так и технической (системные требования).

Организация приема заказов товаров на сайте с помощью корзины товаров покупателя. Благодаря корзине товаров, покупатель может за одно посещение магазина приобрести несколько товаров оформив всего один заказ.

Прием оплаты пластиковыми картами и электронными валютами на сайте. В интернет-магазине цифровых ключей компьютерный игр данная задача является очень важной, так как оплату наличными произвести невозможно, так как товар является цифровым. Этап оплаты должен происходить быстро и просто.

Ведение базы клиентов и истории их заказов на сайте. Важная задача любого магазина - создать базу постоянных покупателей. Для этого необходимо выяснять предпочтения каждого покупателя, чтобы показывать ему наиболее релевантные товары.

1.2 Обзор аналогов

Перед началом разработки системы был проведен поиск готовых решений, с помощью которых можно сделать магазин цифровых ключей компьютерных игр. Прямым аналогом разрабатываемого продукта является только одна система - MyDigiseller [1].

Плюсы данной системы:

· Быстрая установка и настройка;

· База партнерских товаров. Система работает на базе сервиса plati.ru и у администратора есть возможность выставлять товары с этого сервиса на своем магазине.

Минусы системы:

· Стоимость. Базовая версия с очень урезанным функционалом стоит 10000 рублей, а полная версия стоит 150000 рублей;

· Работа на базе сервиса plati.ru. Нет возможности продавать ключи через другие платежные системы.

· Дизайн. В данной системе хоть и есть возможность настройки дизайна, но она ограничивается изменением цвета и положения блоков.

· Невозможно подключить внешнее хранилище ключей. Издатели могут предоставлять свою систему для получения ключей. Для этого система должна иметь возможность выгрузки ключей с сервера издателя.

· Работа на базе WordPress. Так как WordPress очень популярная система, то в ней очень часто находят уязвимости, которые закрываются в обновлениях. Для того чтобы своевременно обновлять систему, необходимо чтобы обновление плагина MyDigiseller приходило с минимальной задержкой.

Самыми главными проблемами рассмотренной системы были выделены ее стоимость и работа на базе стороннего сервиса. Разрабатываемая система должна решить две этих проблемы.

Непрямыми аналогами разрабатываемой системы являются игровые платформы. Наиболее популярные платформы на данный момент Steam, Origin, Uplay, Epic Games Store.

Steam -- онлайн-сервис цифрового распространения компьютерных игр и программ, разработанный и поддерживаемый компанией Valve. Steam выполняет роль средства технической защиты авторских прав, платформы для многопользовательских игр и потокового вещания, а также социальной сети для игроков. Программный клиент Steam также обеспечивает установку и регулярное обновление игр, облачные сохранения игр, текстовую и голосовую связь между игроками.

Origin -- платформа цифровой дистрибуции компании Electronic Arts, которая даёт возможность пользователям приобретать компьютерные игры через Интернет и загружать их с помощью клиента Origin. В Origin используются социальные функции, такие как управление профилем, общение с друзьями в чате и во время игры с помощью внутриигрового приложения, интеграция с Facebook, Xbox Live и PlayStation Network. На данный момент имеется возможность автообновления игр, синхронизация сохранений игр в облачном хранилище, общение во встроенном чате.

Uplay -- сервис цифрового распространения, DRM, сетевой игры и общения, созданный компанией Ubisoft. Поддерживает систему достижений/трофеев, используемую в других подобных сервисах.

Epic Games Store -- онлайн-сервис цифрового распространения компьютерных игр, разработанный и управляемый американской компанией Epic Games. Магазин доступен в качестве веб-сайта и через приложение Epic Games.

Интернет-магазин цифровых ключей компьютерных игр имеет преимущество над игровой платформой с экономической точки зрения. Цены в интернет-магазинах в большинстве случаев меньше, чем, на игровой платформе.

Непрямым аналогом можно считать платформы для создания обычных интернет-магазинов. Примером такой является Wix.com.

Wix.com [2] -- международная облачная платформа, написанная на Scala, для создания и развития интернет-проектов, которая позволяет конструировать сайты и их мобильные версии на HTML5 c помощью инструментов drag-and-drop. Расширять функциональность сайтов можно за счет приложений, разработанных Wix или сторонними компаниями. Например, добавлять плагины социальных сетей, инструменты для онлайн-торговли и электронных рассылок, контактные формы, блоги и др.

Плагин WixStores - расширяет функциональность сайта до полноценного интернет-магазина.

Плюсы данной системы:

· Легкая интеграция. Добавление и настройка занимают мало времени.

· Готовые шаблоны сайтов.

· Различные способы оплаты. Можно выбрать наиболее удобную систему оплаты для магазина.

Минусы системы:

· Система установлена на серверах компании Wix. База данных и файлы сайта находятся на серверах компании Wix. Невозможно оценить безопасность данных.

· Система не учитывает особенности продажи цифровых ключей компьютерных игр.

Таблица 1.1 - Сравнение аналогов разрабатываемой системы

	MyDigiseller	Игровая платформа	WixStores
1. Работа на своих серверах	+/-	-	-
2. Учитываются все особенности продажи цифровых-ключей компьютерных игр	+	+	-
3. Возможность кастомизации страниц магазина	+/-	-	+/-
4. Возможность интеграции с сервером поставщика ключей	-	+	-
5. Выбор сервиса оплаты	-	-	+

Исходя из обзора аналогов, для разрабатываемой системы необходимо решить несколько проблем, которые были найдены в прямых и непрямых аналогах:

· Система не должна зависеть от серверов производителя

· Система должна учитывать особенности торговли цифровыми ключами компьютерных игр.

1.3 Категории пользователей

Для интернет-магазина цифровых ключей компьютерных игр возможны две категории пользователей системы:

· Пользователь - он же покупатель.

o Незарегистрированный - может просматривать сайт, добавлять товары в корзину.

o Зарегистрированный - имеет все возможности незарегистрированного пользователя, а также может оформлять заказ и просматривать историю своих заказов.

· Администратор - имеет доступ к панели управления. В панели управления можно производить редактирование списка игр, жанров, языков, платформ, просматривать список заказов, покупателей, статистику интернет-магазина.

1.4 Бизнес-правила

Перед началом проектирования необходимо прописать бизнес-правила разрабатываемой системы. Бизнес-правила представляют собой специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Для разрабатываемой системы были установлены такие правила:

1. Каждая игра характеризуется следующими параметрами:

a. название

b. платформы

c. разработчик

d. дата выхода

e. языки

f. жанры

g. описание

h. скриншоты

i. цена

2. Покупатель может выбрать любую игру. И если она есть в наличии купить ее.

3. В системе ведется список покупателей. Для каждого покупателя сохраняется имя и электронная почта.

4. Покупатель может купить неограниченное число игр если они есть в наличии.

5. После оплаты заказа покупатель сразу же получает лицензионный ключ продукта.

6. Приобретенный лицензионный ключ сохраняется в базе данных вместе с именем и электронной почтой покупателя.

7. Администратор может добавлять, редактировать и удалять игры.

8. В системе ведется архив удаленных игр.

9. В системе записывается количество просмотров каждой игры. Просмотр - это посещение страницы с игрой на сайте. (Не обязательно производить покупку)

10. В случае утери ключей можно будет восстановить весь список покупок.

11. Покупатель должен иметь возможность просмотра списка своих заказов.

12. При добавлении игры ставится дата размещения на сайте.

13. При изменении статуса игры ставится дата изменения.

14. Администратор может просматривать список заказов.

15. Администратор может просматривать статистику магазина.

16. Статистика магазина делится на основную и подробную.

17. Основная статистика магазина содержит в себе такую информацию:

a. Общее количество игр в магазине

b. Общее количество заказов

c. Общее количество покупателей

18. Подробная статистика магазина имеет возможность выбора временного периода.

19. Подробная статистика должна содержать такую информацию:

a. Количество заказов

b. Общая сумма по заказам

c. График по количеству заказов

20. Администратор может добавлять ключи в систему из внешних источников (серверов поставщика).



2. Проектирование

2.1 Use-case диаграмма

На рисунке 2.1 представлена use-case диаграмма. В ней показаны две роли: пользователь и администратор.

Рисунок 2.1 - Use-case диаграмма

В диаграмме пользователь имеет доступ к таким функциям:

· Просмотр списка товаров;

· Изменение содержания корзины;

· Оформление заказа (требует авторизации или регистрации);

· Оплата заказа (оплата идет через платежную систему);

· Просмотр списка своих заказов (требует авторизации или регистрации).

Администратор имеет доступ к таким функциям как:

· Просмотр статистики магазина;

· Просмотр списка всех заказов;

· Изменение списка товаров.

Для доступа ко всем функциям администратору необходима авторизация.

2.2 Выбор архитектуры приложения

В компьютерных технологиях трёхуровневая архитектура, а предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Схема данной архитектуры показана на рисунке 2.2.

Рисунок 2.2 - Схема трехуровневой архитектуры приложения

Обзор архитектуры:

· Клиент -- это интерфейсный компонент, который представляет первый уровень, приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных, быть нагруженным основной бизнес-логикой и хранить состояние приложения. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными, уже загруженными на терминал;

· Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры базы данных;

· Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

· Масштабируемость. В высоконагруженных приложениях можно распределить нагрузку между несколькими серверами приложений;

· Конфигурируемость -- изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

· Высокая безопасность. Клиент не обращается напрямую к данным, все запросы на сервер приложений проходят валидацию;

· Высокая надёжность. В момент отказа оборудования или пиковых нагрузок можно добавить резервный сервер, на который пойдут запросы клиента;

· Низкие требования к скорости канала между клиентом и сервером приложений;

· Низкие требования к производительности и техническим характеристикам клиента, как следствие большая доступность конечному потребителю. Доступ к приложению можно осуществлять не только с компьютера, но и с мобильного телефона.

По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

· Более высокая сложность создания приложений;

· Сложнее в разворачивании и администрировании;

· Высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;

· Высокие требования к скорости канала между сервером базы данных и серверами приложений.

2.3 Выбор средств разработки

Для серверной части выбран язык программирования Java [3]. На сегодняшний момент язык Java является одним из самых распространенных и популярных языков программирования. Java задумывался как универсальный язык программирования, который можно применять для различного рода задач.

Выбраны технологии в серверной части:

· Spring Framework [4] - ядро платформы, предоставляет базовые средства для создания приложений -- управление компонентами, внедрение зависимостей, транзакции, базовый доступ к БД;

· Spring MVC - компонент, обеспечивающий архитектуру паттерна Model-View-Controller;

· Spring Security - для обеспечения авторизации в приложении, защиты от атак типа фиксация сессии, межсайтовая подделка запроса, и т.д.;

· Hibernate 5 [5] -- это библиотека, которая предназначена для отображения объектов объектно-ориентированного языка в структуры реляционных баз данных.

В качестве контейнера сервелетов был выбран Apache Tomcat 9 [6], который используется для развертывания приложения на Web-сервер.

Для клиентской части используется набор языков для веб разработки: HTML, CSS, JS. Стили страниц написаны на языке SASS - это метаязык на основе CSS, предназначенный для увеличения уровня абстракции CSS кода и упрощения файлов каскадных таблиц стилей. Также используется CSS фреймворк Bootstrap 4 он нужен для ускорения верстки сайта и панели управления, а также повышения адаптивности всего веб приложения. Для взаимодействия с HTML используется JS- фреймворк JQuery. С помощью него производятся асинхронные запросы, взаимодействие и обновление элементов страницы без перезагрузки.

В качестве системы управления базой данных была выбрана MySQL. Это свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle.

2.4 Проектирование базы данных

База данных [7] состоит из 13 таблиц. Схема базы представлена на рисунке 2.3. В приложении 1 расположена SQL-схема базы данных.

Рисунок 2.3 - Схема базы данных приложения

Описание таблиц базы данных:

Game - таблица для хранения списка игр.

Описание полей:

· Id - уникальный идентификатор

· Title - название игры

· Description - описание игры

· Release_date - дата выхода игры

· Poster_image_url - ссылка на постер игры

· Developer - разработчик игры

· Price - цена игры

· Amount - количество, доступное для продажи

· Views - количество просмотров карточки товара

· Status - статус товара (активен, скрытый, итд)

· Publish_date - дата добавления на сайт

· Order_count - количество заказов игры

Genre - список жанров игр.

Game_genre - таблица связка жанра и игры.

Platform - список платформ.

Game_platform - таблица связка платформы и игры.

Language - список языков.

Game_language - таблица связка языка и игры.

Game_screenshot - таблица связка ссылки на скриншот и игры.

Orders - таблица для хранения заказов.

Описание полей:

· Id - уникальный идентификатор заказа

· Date - дата заказа

· Customer_id - идентификатор покупателя

Order_product - таблица связка заказа и товаров, которые были куплены.

Product - таблица для хранения товаров. Товаром является связка игра-лицензионный ключ.

Описание полей:

· Id - уникальный идентификатор товара

· Game_id - идентификатор игры

· License_key - лицензионный ключ игры

User - таблица для хранения пользователей.

Описание полей:

· Id - уникальный идентификатор пользователя

· Discriminator - техническое поле. Используется для ORM Hibernate чтобы разделять пользователей на администраторов и покупателей.

· Username - имя пользователя

· Password - пароль пользователя в зашифрованном виде

· Email - электронная почта покупателя

User_role - таблица связка пользователя и его роли. В приложении всего 2 роли: CUSTOMER и ADMIN.

Связи:

Связь 1:M между таблицей game и таблицами game_language, game_platform, game_genre, game_screenshots. Установлено правило на удаление CASCADE. То есть при удалении игры из таблицы game, будут удалены связные строки и из дополнительных таблиц.

Связь 1:М между таблицей genres и game_genre. Установлено правило на удаление CASCADE. То есть при удалении жанра из справочника он будет удален и из таблиц связок.

Связи таблиц platforms, languages аналогичны предыдущей.

Связь 1:М между таблицей user и orders. Установлено правило на удаление CASCADE.

Связь 1:М между таблицей user и user_role. Установлено правило на удаление CASCADE.

Связь 1:М между таблицей orders и order_product. Установлено правило на удаление CASCADE.

Связь 1:1 между таблицей order_product и product. Установлено правило на удаление CASCADE.

Интерфейс - в широком смысле - определенная стандартами граница между взаимодействующими независимыми объектами. Интерфейс задает параметры, процедуры и характеристики взаимодействия объектов.

Интерфейс пользователя - элементы и компоненты программы, которые способны оказывать влияние на взаимодействие пользователя с программным обеспечением.

2.5 Проектирование пользовательского интерфейса

Есть несколько простых правил, позволяющих интерфейсу магазина быть понятым клиенту.

1. Чем проще, тем лучше. Это вовсе не значит, что должен быть только текст и контактная информация, но на сайте не должно быть бесполезной информации, шрифт должен легко читаться. Графические элементы должны быть были чёткими, выразительными и быстро загружаться. На сайте магазина недопустимо использовать анимацию и звук, которые долго загружаются и отвлекают внимание покупателя.

Человеческий глаз просматривает страницы сайта сверху вниз. Наибольшее внимание сосредотачивается на верхней левой части страницы. Поэтому в верхней части страницы сайта, как правило, размещается наиболее важная информация: название фирмы, логотип, само название сайта и т.д.

Чем проще выполнена верхняя часть страницы, тем легче запомнить название сайта и саму фирму.

2. Товары должны быть распределены по группам. Для наглядности необходимо предусмотреть специальные разделы, содержащие товары, сгруппированные по маркетинговым признакам. Допустим:

· «Новинки» (товары, недавно поступившие в продажу);

· «Популярны» (наиболее просматриваемые товары).

3. При оформлении заказа покупатель должен ввести контактную информацию: логин, пароль, адрес электронной почты, имя. После оформления заказа покупателю отправляется по электронной почте письмо с данными о заказе.

На рисунке 2.4 показан макет главной страницы магазина. На каждой странице сайта вверху закреплено меню, которое содержит ссылки для перехода по различным категориям товаров, а также ссылки на авторизацию, регистрацию, личный кабинет покупателя.

Рисунок 2.4 - Макет главной страницы магазина

На рисунке 2.5 показан макет информации о товаре. Страница информации о товаре разделена на несколько блоков. Слева расположен постер игры, цена и кнопка «добавить в корзину». Справа расположено подробное описание товара и скриншоты.

Также сайт должен быть адаптивен для мобильный устройств. В случае с макетом страницы описания товара страница перестанет делиться на левую и правую часть. На мобильном устройстве левая часть страницы будет выведена выше, а правая часть будет выведена ниже.

Спроектированный интерфейс сочетает в себе два важных аспекта: простота и удобство использования. На страницах размещена только необходимая информация. Количество кнопок и ссылок сведено к минимуму. Благодаря этому пользователю будет легче ориентироваться на сайте.



Рисунок 2.5 - Макет страницы товара



3. Реализация

3.1 Серверная часть системы

Описание пакетов и классов

Перед началом разработки была разработана структура приложения. В языке программирования Java принято разделять классы на пакеты (Package).

Структура приложения:

ru.discoverivan.gameshop - корневой пакет. Соответствует домену приложения. Далее будут описываться внутренние пакеты.

CONTROLLER - пакет в котором находятся контроллеры Spring MVC. обрабатывает запрос пользователя, создаёт соответствующую модель данных приложения и создает отображение данных модели, как правило, генерируя HTML, которые отображаются в браузере.

Классы:

· ShopController - обработка запросов на страницах магазина.

· AdminController - обработка запросов панели управления (/admin).

DB.ENTITY - пакет в котором находятся сущности. В нашем случае используется для ORM Hibernate 5. Сущность представляет собой класс, имеющий скрытые поля, которые такие же, как и в таблице базы данных, а также имеет методы для получения и изменения этих полей.

Классы:

· User - сущность пользователя (таблица базы User).

o Customer - сущность покупателя

o Admin - сущность администратора

· Cart - корзина товаров

· Game - описание игры.

· Genre, Platform, Language - сущность жанров, платформ и языков

· Order - сущность заказа

· Product - сущность товара (связка игра-ключ)

· UserRolesEnum - список ролей пользователей.

DB.DAO - пакет в котором находятся интерфейсы и реализации DAO.

В программном обеспечении data access object (DAO) -- это объект, который предоставляет абстрактный интерфейс к какому-либо типу базы данных или механизму хранения.

Интерфейсы:

· AdminDAO - DAO для сущности Admin.

· CartDAO - DAO для сущности Cart

· CustomerDAO - DAO для сущности Customer

· GameDAO - DAO для сущности Game

· GenreDAO, LanguageDAO, PlatformDAO - DAO для сущностей Genre, Language, Platform соответственно.

· OrderDAO - DAO для сущности Order

· UserDAO - DAO для сущности User

DOMAIN - пакет в котором находятся сервисы. Сервис в нашем случае класс, который реализует бизнес логику определенной части приложения.

Классы:

· AdminService - бизнес логика панели управления сайтом

· CartService - сервис для работы с корзиной товаров. Выполняет работу по преобразованию одного вида представления корзины в другой. Например, из cookies в объект Cart.

· EmailService - сервис для работы с электронной постой. Выполняет отправку писем через SMTP протокол.

· PaginationService - сервис для создания пагинации. Пагинация постраничный вывод объектов.

· SecurityService - сервис для регистрации, авторизации пользователей. Сделан на базе Spring Security.

· ShopService - бизнес логика магазина. Имеет такие методы как создание заказа, работы с личным кабинетом покупателя итд.

· StatsService - сервис для обработки данных и создания отчетов по работе магазина. Например, получения общей суммы заказов, количества заказов, итд.

· UserDetailsService - сервис для связки Spring Security и базы данных.

· UserService - сервис для работы с пользователями.

FILTERS - пакет в котором находятся сервелетные фильтры.

Сервлетный фильтр, в соответствии со спецификацией, это Java-код, пригодный для повторного использования и позволяющий преобразовать содержание HTTP-запросов, HTTP-ответов и информацию, содержащуюся в заголовках HTML. Сервлетный фильтр занимается предварительной обработкой запроса, прежде чем тот попадает в сервлет, и/или последующей обработкой ответа, исходящего из сервлета.

Классы:

· CharacterEncodingFilter - сервелетный фильтр, который преобразует кодировку запросов в UTF-8.

SERVELETS - пакет в котором находятся сервелеты.

Классы:

· ErrorHandler - сервелет, который обрабатывает все ошибки приложения и выводит страницу ошибки вместо стандартной страницы. Пример страницы ошибки на рисунке 2.

TAGS - пакет в котором находятся созданные теги JSTL.

Классы:

· GetCartNumTag - данный тег выводит количество товаров корзине.

Пример использования тега в JSTL коде:

<gshop:getCartNum cartCookie="${cookie.cart.value}"/>



Рисунок 3.1 - Страница ошибки

VALIDATION - пакет в котором классы, реализующие валидацию данных в приложении.

Классы:

· RegisterForm - модель регистрационной формы. Используется в контроллере, чтобы получать объект формы как одно целое, а не по отдельнм полям формы.

· RegisterFormValidotor - данный класс реализует проверку полей формы на правильность заполнения. По окончании проверки возвращается объект ValidationResult.

Зависимости Spring

Среда Spring реализует и продвигает принцип инверсии управления (IOC) или внедрения зависимости (DI) и является по сути IOC-контейнером. Традиционно Spring позволяет разработчику осуществлять управление зависимостями bean-компонентов с помощью конфигурирования на основе XML путем использования XML-файла контекста приложения. Этот файл является внешним для приложения, и в нем содержатся определения bean-компонентов и их зависимостей для этого приложения. В Spring-е бином (bean) называют любой класс, который управляется контейнером Spring.

На рисунке 3 показаны зависимости контроллера панели управления (adminController). В зависимостях есть DAO для взаимодействия с базой данных, а также сервис панели управления, сервис статистики и сервис пагинации (постраничного вывод данных).

Рисунок 3.2 - Зависимости adminController

На рисунке 4 показаны все зависимости контроллера магазина (shopController). В зависимостях есть DAO для взаимодействия с базой данных, сервис безопасности (securityService), который используется для проведения авторизации через Spring Security, сервис магазина (shopService), сервис корзины товаров (cartService), сервис пользователей, который используется для регистрации покупателей, валидаторы форм.

Для сохранения корзины товаров у каждого покупателя было принято решение хранить данные в куках (Cookies).

Cookie - небольшой фрагмент данных, отправленный веб-сервером и хранимый на компьютере пользователя. Веб-клиент (обычно веб-браузер) всякий раз при попытке открыть страницу соответствующего сайта пересылает этот фрагмент данных веб-серверу в составе HTTP-запроса.



Рисунок 3.3 - Зависисмости shopController

Реализация корзины товаров

Корзина заказов в интернет-магазине -- это интерфейс, куда пользователь может добавлять товары, которые он собирается купить. На рисунке 5 показана корзина товаров в которую добавлены 2 товара.

Рисунок 3.4 - Корзина товаров

Так как размер cookie очень ограничен, то при добавлении товара в корзину сохраняется только ее уникальный идентификатор, а уже при заходе на страницу корзины сервер возвращает полную информацию о товаре на основе полученных идентификаторов.

Данные в cookies хранятся в виде json строки. Добавление, удаление, валидацию данных в cookies осуществляет класс cartService.

В процессе работы с JSON данными применяются два процесса: сериализация и десириализация. Сериализация это процесс сохранения состояния объекта в последовательность байт; десериализация это процесс восстановления объекта, из этих байт. Для работы с данными в формате JSON отвечает Java библиотека Jackson.

Методы класса cartService:

· addGameToCartCookie - добавляет id игры в cookie. Для этого производится преобразование json строки в массив, добавление элемента в массив и обратное преобразование в json;

· removeGameFromCartCookie - удаляет id игры из корзины товаров;

· getCartFromCookie - метод осуществляющий преобразование json в массив;

· getCookieFromCart - метод осуществляющий преобразование массива в json строку;

· validateCart - данный метод осуществляет валидацию корзины товаров. Валидацией в данном случае считается проверка на существование игр, которые были добавлены в корзину. Например, если пользователь добавил игру в корзину, а затем через неделю зашел опять, а игру удалили с сайта, то этот метод удалит несуществующую игру из корзины пользователя. Блок-схема алгоритма представлена на рисунке 3.5.

Mapping сущности Game в Hibernate

Mapping (сопоставление, проецирование) Java-классов с таблицами базы данных осуществляется с помощью конфигурационных XML-файлов или Java-аннотаций. При использовании файла XML Hibernate может генерировать скелет исходного кода для классов длительного хранения. В этом нет необходимости, если используется аннотация. Hibernate может использовать файл XML или аннотации для поддержки схемы базы данных. В приложении 3 на странице 89 приведен код этого класса.



Рисунок 3.5 - Блок-схема алгоритма валидации корзины товаров

Рассмотрим подробнее маппинг этого класса. Над объявлением класса мы видим две аннотации:

@Entity - показывает, что это сущность и Hibernate мог начать маппинг.

@Table(name = "game") - указание на название таблицы в базе данных.

У каждого геттера есть свои аннотации. В основном они сильно не отличаются. Например, для поля title имеем такую аннотацию:

@Column(name = "title") - она указывает на название поля в базе данных. Иногда приходится указывать тип данных явно, для этого используется еще один параметр. Например для поля description. В базе оно имеет тип данных TEXT, а в классе тип данных string. Hibernate не может сделать неявное преобразование. Поэтому надо указать columnDefinition = "TEXT".

Также в базе данных у нас есть таблицы связки. Для того чтобы Hibernate корректно получал данные из базы требуется описать эти таблицы. У игры есть таблица связка игра-скриншот. Для поддержки этой таблицы необходимо поставить такую аннотацию:

@ElementCollection(fetch=FetchType.EAGER) - указывает, что это таблица связка. FetchType.EAGER показывает, что Hibernate будет получать данные из таблицы связки сразу.

@CollectionTable(name = "game_screenshot",

joinColumns = @JoinColumn(name = "game_id")) - указываются названия полей и название таблицы связки

@Column(name = "image_url") - название колонки в таблице связке, в которой будут хранится данные.

Благодаря этой аннотации Hibernate получит из таблицы связки данные и представит их в виде Set<String>.

Также используются аннотации @ManyToMany, @OneToMany, @ManyToOne. Они работают с таблицами связками как и аннотация @ ElementCollection, только используются для получения сущностей, а не примитивных типов данных. И по названиям данных аннотаций можно понять что каждая из них используется при определенном типе связи в базе данных.

3.2 Клиентская часть системы

Разработка интерфейса

В структуре приложения есть директория webapp в которой хранятся файлы представления. В нашем случае это файлы jsp, css, js.

Структура директории:

· CSS - директория в которой находятся каскадные таблицы стилей.

· Images - картинки, иконки, итд

· Js - в данной директории находятся файлы JavaScript

· WEB-INF/views - директория с jsp файлами. Файлы разделены на 2 основных директории Admin и Site. В первой директории находятся все файлы относящиеся к панели управления сайтом, во второй директории все файлы, относящиеся к выводу интерфейса для покупателей.

Интерфейс сайта для пользователя разделен на файлы jsp. Каждый файл отвечает за вывод определенной части страницы. Файл может подключать внутри себя другие файлы. Рассмотрим каждый файл отдельно.

· Parts/header.jsp - вывод меню сайта. Файл подключается в каждом файле index.jsp. В меню сайта некоторые ссылки выводятся в зависиморсти от типа пользователя. Блок-схема алгоритма вывода меню сайта показана на рисунке 3.6, а программный код представлен в приложении 4 на странице 139.

o Parts/head-includes.jsp - файл подключается внутри header.jsp и включает в себя блок <head> в котором подключаются необходимые библиотеки и модули

§ Parts/seo.jsp - файл подключается внутри файла head-includes.jsp и включает в себя SEO оптимизацию сайта. Благодаря данному модулю у страницы корректно формируется заголовок и описание необходимых для поисковых систем.

· Parts/footer.jsp - вывод «подвала» сайта, а также подключение js-библиотек, которые должны загружаться после загрузки страницы. Файл подключается в каждом файле index.jsp.

· Index.jsp - главная страница сайта изображена на рисунке 3.7.

· Account/index.jsp - страница личного кабинета покупателя изображена на рисунке 3.8.

· Account/order.jsp - страница со списком заказов пользователя.

· Game-full.jsp - страница с подробным описанием игры.

· Cart.jsp - корзина товаров.



Рисунок 3.6 - Блок-схема алгоритма вывода ссылок в меню сайта

· Buy-success.jsp - страница сообщения об успешной покупке товара.

· Error.jsp - страница ошибки. Данный файл отвечает за вывод сообщений об ошибке со всего приложения.

· Login.jsp - страница авторизации.

· Register.jsp - страница регистрации.

Интерфейс сайта для администратора, как и для покупателя разделен на отдельные файлы. Рассмотрим их.

· Parts/header.jsp - вывод меню панели управления. Файл подключается в каждом корневом файле страницы.

o Parts/head-includes.jsp - файл подключается внутри header.jsp и включает в себя блок <head> в котором подключаются необходимые библиотеки и модули.

· Parts/footer.jsp - вывод «подвала» сайта, а также подключение js-библиотек, которые должны загружаться после загрузки страницы. Файл подключается в каждом файле index.jsp.

Рисунок 3.7 - Главная страница сайта

Рисунок 3.8 - Страница личного кабинета покупателя

· Index.jsp - главная страница панели управления изображена на рисунке 3.9.

· Settings.jsp - страница настроек сайта. На этой странице можно добавлять и удалять администраторов приложения.

· Game - раздел панели управления в котором можно просматривать и редактировать список игр на сайте. Данная директория содержит несколько файлов jsp.

· Order.jsp - раздел панели управления в котором можно просматривать и редактировать список покупателей.

· Stats.jsp - раздел панели управления в котором можно просматривать статистику сайта. Страница изображена на рисунке 3.10.

· Attributes - разделы для редактирования атрибутов товаров. Их всего 3 - жанры, языки, платформы.

· Products/List.jsp - раздел панели управления в котором можно просматривать список продуктов (связка игра-ключ).

· Products/inport.jsp - раздел панели управления в котором можно импортировать ключи с сервера поставщика.

Рисунок 3.9 - Главная страницы панели управления

Рисунок 3.10 - Раздел статистики сайта



При разработке интерфейса были стандартизирован стиль элементов сайта. Созданы универсальные стили страниц (шрифт, фон), ссылок, кнопок.

Разработанный интерфейс полностью соответствует макету и правилам, которые был разработаны на стадии проектирования.

Создание собственного тега JSTL

При разработке меню сайта появилась необходимость выводить количество товаров в корзине товаров. Но так как в jstl нет возможности обрабатывать cookie пользователя. Приходится эту обработку переложить на сервер. Было принято решение создать свой тег jstl.

Для этого потребовалось создать файл WEB-INF/gameshopTags.tld. В данном файле описывается своя библиотека тегов jstl. Код файла находится в приложении В.

Секция описания библиотеки:

· description - описание библиотеки тегов;

· tlib-version - версия библиотеки;

· short-name - краткое описание, которое будет использоваться при использовании тегов.

Секция описания тега:

· name - имя тега.

В итоге для использования тега надо написать в любом месте jsp файла такой код:

<gshop:getCartNum cartCookie="${cookie.cart.value}"/>

Данный тег напечатает число товаров в корзине. В финальном варианте код выглядит так:

<div class="name">

КОРЗИНА

(<gshop:getCartNum cartCookie="${cookie.cart.value}"/>)

</div>



4. Тестирование

4.1 Методика тестирования

Существует много различных способов тестирования программного обеспечения. Для тестирования веб-приложения необходимо выбрать несколько методов тестирования. Необходимо иметь возможность находить дефекты как на стороне клиента (браузера), так и на стороне сервера.

После анализа методов тестирования были выбраны 4 метода:

· модульное тестирование серверной части;

· тестирование верстки клиентской части;

· системное тестирование;

· нагрузочное тестирование.

Модульное тестирование серверной части

Модульное тестирование - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими входными данными, процедурами использования и обработки.

Данный вид тестирования позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

Модульные тесты создаются с помощью фреймворка JUnit 4. JUnit - это фреймворк, разработанный для тестирования программ, написанных с использованием технологии Java.

Тестирование верстки серверной части

Тестирование верстки приложения проходит вручную и состоит из 2 этапов:

1. Визуальное тестирование. На данном этапе тестировщик переходит по страницам сайта и проверяет соответствие верстки макету. Тестирование проводится в разных браузерах и на разных разрешениях экрана, чтобы убедится в правильности отображения сайта и его адаптивности.

2. Валидация HTML кода. Валидация является одним из самых важных аспектов хорошего веб-дизайна. Проверка веб-страницы позволит определить, соответствует ли она стандартам, разработанным Консорциумом Всемирной паутины (W3C). Обычно это делается путем проверки отдельных страниц на валидность с помощью онлайн-сервиса проверки от W3C. Некорректная веб-страница может быть прочитана браузерами по-разному. Это приведет к тому, что посетители, возможно, даже не смогут правильно увидеть контент страницы в своих браузерах. Валидация позволит исправить почти все основные различия и сделает веб-страницу доступной для чтения почти всеми веб-браузерами.

Системное тестирование

Системное тестирование программного обеспечения -- это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.

Для данного вида тестирования были разработаны тест-кейсы. Тест кейс -- это формально описанный алгоритм тестирования программы, специально созданный для определения возникновения в программе определённой ситуации, определённых выходных данных.

Пример разработанного тест-кейса:

Тест-кейс № 1. Создание дубликата аккаунта.

Шаги:

1. Зайти на сайт

2. Перейти на страницу регистрации и ввести следующие данные:

a. Имя: Test

b. Электронная почта: test@test.com

c. Имя пользователя: test

d. Пароль и подтверждение пароля: test123456

3. Нажать на кнопку «создать аккаунт»

4. На главной странице сайта нажать кнопку «выход»

5. Повторить пункт 2

Ожидаемый результат:

Выделение полей «электронная почта» и «логин» красной рамкой и появление сообщения об ошибке рядом с каждым полем.

Тест-кейсы были разработаны на все критичные функции приложения, такие как: регистрация, авторизация, добавление товара в корзину, удаление товара из корзины, оформление заказа, отправка письма на почту покупателя.

Нагрузочное тестирование

Нагрузочное тестирование или тестирование производительности -- это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем ресурсе. В нашем случае это посетители интернет-магазина.

Производительность при этом определяется следующими факторами:

· скоростью работы программного обеспечения;

· скоростью работы аппаратного обеспечения;

· скоростью работы сети.

Во время тестирования могут осуществляться следующие операции, позволяющие более точно измерить производительность и определить «узкое место» системы:

· измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций;

· определение количества пользователей, одновременно работающих с приложением;

· определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций).

Успешно пройденным будем считать тестирование, во время которого сервер ответил на 90% запросов успешно (вернул страницу сайта), ожидание полной загрузки страницы заняло не более 3 секунд.

4.2 Результаты тестирования

Тестирование проводится локально на компьютере разработчика, затем на удаленном сервере приложений. Модульное тестирование запускается внутри интегрированной среды разработки IntelliJ IDEA 2019. Вся бизнес логика приложения покрыта тестами. Результаты тестирования показаны на рисунке 4.1. Все тесты прошли успешно.

Рисунок 4.1 - Результаты модульного тестирования

Первая часть тестирования верстки клиентской части - визуальное тестирование не выявило дефектов. Вторая часть - валидация проводилась через официальный сервис W3C (validator.w3.org). Валидатор не выявил ошибок HTML кода. Результаты валидации показаны на рисунке 4.2. Тестирование верстки клиентской части пройдено успешно.



Рисунок 4.2 - Результаты валидации HTML кода

Во время системного тестирования вручную были проверены все тест-кейсы. Дефектов на данном этапе выявлено не было. Системное тестирование пройдено успешно.

Нагрузочное тестирование проводится с помощью сервиса loaddy.com. С помощью него можно провести нагрузочное тестирование сайта, создавая свой сценарий тестирования. Сценарий тестирования включает в себя такие параметры как:

· Тип нагрузки: равномерная или нарастающая;

· Время проверки: от 1 до 15 минут;

· Количество посетителей. До 100 посетителей бесплатно, далее платно.

Во время тестирования проверяется доступность сайта, время ответа от сервера, время загрузки страницы. Результаты тестирования при максимальной нагрузке за 1 минуту показаны на рисунке 4.3.

При максимальной нагрузке сервер быстро и корректно обрабатывает запросы. Нагрузочное тестирование пройдено успешно.

Приложение прошло все этапы тестирования. Тестирование приложения считаем успешным.



Рисунок 4.3 - Результаты нагрузочного тестирования



5. Опытная эксплуатация

Для запуска приложения в опытную эксплуатацию необходимо выполнить несколько шагов: настройка сервера, привязка доменного имени, настройка инструментов для автоматического развертывания приложения.

5.1 Настройка сервера

Для работы приложения требуется сервер, на котором будет установлен контейнер сервелетов Tomcat 9.

Было принято решение арендовать виртуальный приватный сервер. VPS -- услуга предоставления в аренду так называемого виртуального приватного сервера. В плане управления операционной системой по большей части она соответствует физическому выделенному серверу. В частности: root-доступ, собственные IP-адреса, порты, правила фильтрования и таблицы маршрутизации.

Сервер был арендован у компании ArubaCloud. Основные характеристики:

· Процессор: Intel Xeon 1vCPU

· Оперативная память: 1 Гб

· SSD диск: 20 Гб

· Лимит интернет-траффика: 1 Тб в месяц

Панель управления сервером показана на рисунке 5.1.

В качестве операционной системы выбрана система Debian 9. Debian -- операционная система, состоящая из свободного ПО с открытым исходным кодом. В настоящее время Debian GNU/Linux -- один из самых популярных и важных дистрибутивов GNU/Linux.



Рисунок 5.1 - Панель управления сервером

5.2 Привязка доменного имени

Любой сайт в Интернете имеет доменное имя -- уникальную привязку IP-адреса сервера, на котором находится сайт, к определенной буквенной последовательности.

Домен -- это уникальное алфавитно-цифровое обозначение, которое является необходимым элементом адреса в сети Интернет. Доменное имя позволяет идентифицировать веб-сайт или адрес электронной почты в сети Интернет.

...