TypePad Micro - ещё один достойный сервис по созданию и ведению блога. Из его плюсов: очень удобный интерфейс и возможность импорта/экспорта содержимого блога из других сервисов. Но, что касается количества приложений и предлагаемых тем TypePad Micro, то вряд ли оно удовлетворит самого обычного блоггера. Самая дешевая учетная запись обойдется пользователю в $8.95 за месяц и будет включать в себя дополнительные темы оформления, собственный домен, а также техническую поддержку. В эпоху, когда почти все сервисы блогов предлагают многочисленные возможности в бесплатной версии, TypePad Micro выглядит несколько отстающим.
Исходя из обзора аналогов, для разрабатываемой системы необходимо решить несколько проблем, которые были найдены в прямых и непрямых аналогах:
· Система должна принимать во внимание навыки пользователей и быть предельно удобной для всех категорий пользователей;
· Система должна учитывать особенности современной блогосферы.
1.3 Категории пользователей
Для интернет-магазина цифровых ключей компьютерных игр возможны две категории пользователей системы:
· Пользователь - он же автор и/или комментатор.
o Незарегистрированный - может просматривать сайт.
o Зарегистрированный - имеет все возможности незарегистриро-ванного пользователя, а также может просматривать историю своих записей.
· Администратор - имеет доступ к панели управления. В панели управления можно производить редактирование статей, категорий, просматривать список статей, пользователей, статистику интернет-сайта.
1.4 Бизнес-правила
Перед началом проектирования необходимо прописать бизнес-правила разрабатываемой системы. Бизнес-правила представляют собой специализиро-ванный вид логики, описывающей ограничения на образ действий, которые сис-тема или люди должны учитывать в своем поведении. Для разрабатываемой сис-темы были установлены такие правила:
1. Каждая статья характеризуется следующими параметрами:
a. название
b. автор
c. дата написания
d. категория
e. текст статьи
2. Покупатель может выбрать любую тему и написать пост на эту тему.
3. В системе ведется список авторов. Для каждого автора сохраняется имя и электронная почта.
4. Покупатель может написать неограниченное число постов в блог.
5. Написанный пост сохраняется в базе данных вместе с именем и электронной почтой автора.
6. Администратор может добавлять, редактировать и удалять посты и категории.
7. В системе ведется архив удаленных постов.
8. В системе записывается количество просмотров каждого поста. Просмотр - это посещение страницы отдельной статьи на сайте.
9. Покупатель должен иметь возможность просмотра списка своих записей.
10. При добавлении записи в блог ставится дата размещения на сайте.
11. При изменении записи в блоге на странице записи ставится дата изменения.
12. Администратор может просматривать список записей в блоге.
13. Администратор может просматривать статистику сайта.
14. Статистика магазина делится на основную и подробную.
15. Основная статистика магазина содержит в себе такую информацию:
a. Общее количество записей в блоге
b. Общее количество отдельно авторов
c. Общее количество пользователей
16. Подробная статистика магазина имеет возможность выбора временного периода.
17. Подробная статистика должна содержать такую информацию:
a. Количество записей
b. График по количеству просмотров
2. Проектирование
2.1 Use-case диаграмма
На рисунке 3.1 представлена use-case диаграмма. В ней показаны две роли: пользователь и администратор.
Рисунок 2.1 - Use-case диаграмма
В диаграмме пользователь имеет доступ к таким функциям:
· Просмотр списка записей;
· Добавление новых записей в блог (требует авторизации или регистрации);
· Просмотр списка своих записей (требует авторизации или регистрации).
Администратор имеет доступ к таким функциям как:
· Просмотр статистики сайта;
· Просмотр списка всех статей;
· Изменение списка категорий.
Для доступа ко всем функциям администратору необходима авторизация.
2.2 Выбор архитектуры приложения
В компьютерных технологиях трёхуровневая архитектура, а предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных. Схема данной архитектуры показана на рисунке 3.2.
Рисунок 2.2 - Схема трехуровневой архитектуры приложения
Обзор архитектуры:
· Клиент -- это интерфейсный компонент, который представляет первый уровень, приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных, быть нагруженным основной бизнес-логикой и хранить состояние приложения. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными, уже загруженными на терминал;
· Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры базы данных;
· Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
В простейших конфигурациях все компоненты или часть из них могут быть совмещены на одном вычислительном узле. В продуктивных конфигурациях как правило используется выделенный вычислительный узел для сервера баз данных или кластер серверов баз данных, для серверов приложений -- выделенная группа вычислительных узлов, к которым непосредственно подключаются клиенты (терминалы).
По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:
· Масштабируемость. В высоконагруженных приложениях можно распределить нагрузку между несколькими серверами приложений;
· Конфигурируемость -- изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
· Высокая безопасность. Клиент не обращается напрямую к данным, все запросы на сервер приложений проходят валидацию;
· Высокая надёжность. В момент отказа оборудования или пиковых нагрузок можно добавить резервный сервер, на который пойдут запросы клиента;
· Низкие требования к скорости канала между клиентом и сервером приложений;
· Низкие требования к производительности и техническим характеристикам клиента, как следствие большая доступность конечному потребителю. Доступ к приложению можно осуществлять не только с компьютера, но и с мобильного телефона.
По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:
· Более высокая сложность создания приложений;
· Сложнее в разворачивании и администрировании;
· Высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
· Высокие требования к скорости канала между сервером базы данных и серверами приложений.
2.3 Выбор средств разработки
Для серверной части выбран язык программирования Java. На сегодняшний момент язык Java является одним из самых распространенных и популярных языков программирования. Java задумывался как универсальный язык программирования, который можно применять для различного рода задач.
Выбраны технологии в серверной части:
· Spring Framework - ядро платформы, предоставляет базовые средства для создания приложений -- управление компонентами, внедрение зависимостей, транзакции, базовый доступ к БД;
· Spring MVC - компонент, обеспечивающий архитектуру паттерна Model-View-Controller;
· Spring Security - для обеспечения авторизации в приложении, защиты от атак типа фиксация сессии, межсайтовая подделка запроса, и т.д.;
· Hibernate 5 -- это библиотека, которая предназначена для отображения объектов объектно-ориентированного языка в структуры реляционных баз данных.
Spring Framework -- это фреймворк приложений и инверсия контейнера управления для платформы Java. Основные функции фреймворка могут использоваться любым приложением Java, но есть расширения для создания веб-приложений на основе платформы Java EE (Enterprise Edition). Хотя среда не навязывает какую-либо конкретную модель программирования, она стала популярной в сообществе Java как дополнение или даже замена модели Enterprise JavaBeans (EJB). Spring Framework является открытым исходным кодом.
Hibernate ORM (вкратце Hibernate) -- это инструмент объектно-реляционного отображения для языка программирования Java. Он обеспечивает основу для отображения объектно-ориентированной модели предметной области в реляционную базу данных. Hibernate обрабатывает проблемы несоответствия объектно-реляционного импеданса, заменяя прямой постоянный доступ к базе данных высокоуровневыми функциями обработки объектов.
Hibernate -- это бесплатное программное обеспечение, которое распространяется под лицензией GNU Lesser General Public License 2.1.
Основной функцией Hibernate является сопоставление классов Java с таблицами базы данных и сопоставление типов данных Java с типами данных SQL. Hibernate также обеспечивает запрос и поиск данных. Он генерирует вызовы SQL и освобождает разработчика от ручной обработки и преобразования объектов результирующего набора.
В качестве контейнера сервлетов был выбран Jetty, который используется для развертывания приложения на Web-сервер.
Eclipse Jetty -- это сервер HTTP (Web) и контейнер сервлетов Java. В то время как веб-серверы обычно ассоциируются с предоставлением документов людям, Jetty сейчас часто используется для обмена данными между компьютерами, обычно в рамках более крупных программных сред. Jetty разрабатывается как бесплатный проект с открытым исходным кодом как часть Eclipse Foundation. Веб-сервер используется в таких продуктах, как Apache Maven, Apache Spark, Google App Engine, Eclipse. Jetty также является сервером в проектах с открытым исходным кодом, таких как Lift, Eucalyptus, OpenNMS, Red5, Hadoop и I2P. Jetty поддерживает новейший Java Servlet API (с поддержкой JSP), а также протоколы HTTP/2 и WebSocket.
Для клиентской части используется набор языков для веб разработки: HTML, CSS, JS. Стили страниц написаны на языке SASS - это метаязык на основе CSS, предназначенный для увеличения уровня абстракции CSS кода и упрощения файлов каскадных таблиц стилей. Также используется CSS фреймворк Bootstrap 4 он нужен для ускорения верстки сайта и панели управления, а также повышения адаптивности всего веб приложения.
В качестве системы управления базой данных была выбрана MySQL. Это свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle.
2.4 Проектирование базы данных
База данных состоит из 13 таблиц. Схема базы представлена на рисунке 2.3. В приложении А расположена SQL-схема базы данных.
Рисунок 2.3 - Схема базы данных приложения
Описание таблиц базы данных:
Post - таблица для хранения списка статей.
Описание полей:
· Id - уникальный идентификатор
· Title - название статьи
· Content - текст статьи
· Author - автор статьи
· Views - количество просмотров статьи
· Status - статус статьи (активен, скрытый, итд)
· Publish_date - дата добавления на сайт
Category - список категорий записей.
Post_category - таблица связка категории и записи.
Authors - таблица для хранения списка авторов и их статей.
Описание полей:
· Id - уникальный идентификатор автора
· Post_id - идентификатор статьи
Author_post - таблица связка статей и авторов.
User - таблица для хранения пользователей.
Описание полей:
· Id - уникальный идентификатор пользователя
· Discriminator - техническое поле. Используется для ORM Hibernate чтобы разделять пользователей на администраторов и обычных пользователей.
· Username - имя пользователя
· Password - пароль пользователя в зашифрованном виде
· Email - электронная почта покупателя
User_role - таблица связка пользователя и его роли. В приложении всего 2 роли: USER и ADMIN.
Связи:
Связь 1:M между таблицей post и таблицами post_category, content. Установлено правило на удаление CASCADE. То есть при удалении записи из таблицы post, будут удалены связные строки и из дополнительных таблиц.
Связь 1:М между таблицей category и post_category. Установлено правило на удаление CASCADE. То есть при удалении категории из справочника она будет удалена и из таблиц связок.
Связь 1:М между таблицей user и authors. Установлено правило на удаление CASCADE.
Связь 1:М между таблицей user и user_role. Установлено правило на удаление CASCADE.