Файл: Выпускная квалификационная работа бакалавра.pdf

15
2.3 Проектирование базы данных
База данных является важнейшим элементом любой информационной системы. Laravel на данный момент поддерживает работу со следующими
СУБД:
 MySQL
 Postgres
 SQLite
 SQL Server
Для реализации всех необходимых возможностей нашего веб-сервиса вполне будет достаточно свободной реляционной СУБД MySQL.
В ходе изучения предметной области были выделены следующие основные сущности:
 Пользователь
 Отзыв
 Список контактов
 Контакт
 Категория
 Статья
 Контент для соц сетей
При проектировании базы данных предметной области, была получена
ER-модель, изображенная на рисунке 5

16
Рисунок 5 – ER-модель базы данных предметной области в нотации Баркера
При проектировании выяснилось, что в таблице Пользователь необходимо будет хранить много информации, будь то основные характеристики врача – имя, место проведения практики(адрес работы), так и дополнительные, такие как токены аутентификации в социальных сетях, данные доступа к личному блогу, информация о аккаунтах на специализированных сервисах отзывов и т.д. Было принято решение выделить две дополнительные сущности для уменьшения количества атрибутов в основной таблице. Были выделены две дополнительные сущности:
 Данные авторизации, где будет храниться информация об авторизации в соц. сетях. Пример атрибутов: facebook_token, fb_account_id,
fb_profile_image.

17
 Настройки, где будет храниться информация о настройках для авторизации на личном блоге, аккаунтах на специализированных сервисах отзывов.
Пример атрибутов:
yelp_id,
zocdoc_id,
google_place_id.
Краткая характеристика остальных сущностей:
 Пользователь – содержит основную информацию о пользователе веб- сервиса. Пользователем выступает частный мед. работник или администратор сайта. Пример атрибутов: role, first_name, email.
 Отзыв – информация об отзыве о конкретном враче(пользователе).
Пример атрибутов: title, text, rating.
 Контакт – информация о пациенте, представленная в виде его email- адреса, имени, фамилии.
 Список email-адресов – предопределенные списки с контактами пациентов. Используются для массовой рассылки полезного контента или важной информации клиентам.
 Статья
–
администрацией веб-сервиса подразумевается написание\поиск статей на различную тематику. Такие статьи врач сможет использовать в своих целях, чтобы поделиться или со своими пациентами или как-то прокомментировать их, используя блог.
 Контент – имеется в виду контент для соц. сетей. Суть использования походит на Статью, но это более универсальная сущность. То есть, например, можно и просто картинкой поделиться с медицинской тематикой. Или просто цитатой известного доктора. Контент также предоставляется администрацией сервиса.
 Категория – Используется для разделения статей, генерируемых администрацией сервиса, на категории. Здесь под категорией имеется в виду сфера деятельности докторов. К примеру, статьи для стоматологов совершенно не подходят для терапевтов.

18
2.4 Проектирование архитектуры приложения
Чтобы понять, какие классы нам нужны и их взаимодействие между собой, необходимо специфицировать варианты использования. На рисунке 6 и рисунке 7 изображена диаграмма вариантов использования для пользователя и администратора соответственно. Диаграммы представлены сразу на английском языке, т.к выглядит более семантически-значимо.
Рисунок 6 – Диаграмма вариантов использования для роли
“Пользователь”

19
Рисунок 7 – Диаграмма вариантов использования для роли
«Администратор»
Некоторые пояснения:
 Customer – User - пользователь, аутентифицированный участник системы, имеет следующие возможности: o
Размещать статьи\контент в интегрированный блог, при этом, может использовать статьи, написанные или найденные заранее администраторами веб-сервиса. o
Следить за своей репутацией у пациентов, просматривая и анализируя отзывы, собранные в специальной вкладке. o
Размещать контент в социальные сети, при этом, также, может использовать контент, найденный или сгенерированный администраторами сервиса, в том числе, с возможностью установления расписания или отложенного постинга. o
Создавать, просматривать, изменять или удалять предустановленные списки email-адресов(контактов)

20 o
Устраивать массовые email-рассылки.
Опционально использовать встроенный шаблон для предложения пациентам оставить отзыв о данном враче после приема.
 Admin – Пользователь с ролью администратора сервера. Может управлять всем контентом сервиса.
На рисунке 8 отображена полученная диаграмма классов.

21
Р
исун
ок
8
–
общая д
иа
гр
ам
м
а кл
асс
ов
.

22
3. Реализация
При обработке запросов, Laravel опирается на систему маршрутизации, которая сопоставляет все входящие запросы с определенными в системе маршрутами, которые указывают какой контроллер и метод должен обработать данный запрос.
В Laravel мощная и гибкая система маршрутизации. Все маршруты определяются в файле routes.php. Например, сгенерированные маршруты для контроллера UserController можно увидеть на таблице 1:
Verb
Path
Action
Route Name
GET
/
user index user.index
GET
/
user
/
create create user.create
POST
/
user store user.store
GET
/
user
/
{
id
}
show user.show
GET
/
user
/
{
id
}
/
edit edit user.edit
PUT/PATCH
/
user
/
{
id
}
update user.update
DELETE
/
user
/
{
id
}
destroy user.destroy
Таблица 1 – Маршруты, создаваемые Laravel для определенного контроллера
Покажем обработку запроса на примере варианта использования
“Manage profile”. Когда пользователь хочет просмотреть свой профиль – он обращается через ссылку на адрес /user/id. По заданному маршруту, запрос перенаправляется на метод show контроллера UserController, который, в свою очередь, делает запрос к классу модели User, получает экземпляр класса
Eloquent[2], и вызывает метод отрисовки представления(view), которое и увидит пользователь.

23
Для наглядности, покажем диаграмму последовательностей на рисунке
9.
Рисунок 9 – Диаграмма последовательностей просмотра профиля
Подобным образом реализуются все маршруты в веб-сервисе. Ниже, на рисунке 10 представлены классы с некоторыми полями и методами, используемые для отображения домашней страницы сервиса с данными о количестве текущих подписчиков в различных социальных сетях, а также количестве различных типов отзывов со специализированных сервисов отзывов. На рисунке 11 представлен внешний вид этой страницы.

24
Рисунок 10 – Диаграмма классов отображения домашней страницы
Рисунок 11 – Внешний вид домашней страницы
Продемонстрируем реализацию части необходимого функционала. Для примера будет взят модуль размещения контента в социальных сетях.
Пользователь может вставить в специальное текстовое поле ссылку на статью/новость. В частности, будет рассмотрен метод получения мета-данных статьи/новости по ссылке.
За обработку логики модуля отвечает контроллер SocialController.
Данные получаются через Open Graph тэги[7] на странице. Используется класс
ContentExtracter и внешняя библиотека OpenGraph, где реализован удобный парсинг мета-тэгов.
Протокол Open Graph позволяет любой веб-странице стать полноценным объектом в социальных сетях. Например, протокол используется на Facebook, чтобы разрешить любой веб-странице иметь такую же функциональность, как и любой другой объект на Facebook. Хотя многие различные технологии и схемы существуют и могут быть объединены вместе, нет ни одной технологии, которая предоставляет достаточно информации, чтобы красочно представлять какие-либо веб-страницы внутри социальных сетей. Протокол Open Graph строится на этих существующих технологиях и

25 предоставляет разработчикам возможность реализовать все это в одном протоколе. Простота разработки является ключевой задачей протокола Open
Graph, сообщили многие, на основе технических проектных решений.
Основные Метаданные:
 og:title - Название объекта, как он должен отображаться в графе
 og:type - Типы объектов
 og:image - URL-адрес изображения, который должен определить объект в графе для изображения.
 og:url - Канонический URL-адрес объекта, который будет использоваться в качестве его постоянного ID.
На рисунке 12 изображена диаграмма классов, использующихся для реализации данного функционала. На рисунке 13 – диаграмма последовательностей. Рисунок 14 – итоговый пользовательский интерфейс для страницы размещения контента в социальные сети.
Рисунок 12 – Диаграмма классов получения мета-данных страницы

26
Рисунок 13 – Диаграмма последовательностей получения мета-данных
страницы по ссылке
Рисунок 14 – Внешний вид страницы размещения контента в соц. сети
Также рассмотрим реализацию модуля размещения контента в удаленный блог.
WordPress имеет два механизма публикации постов. Первый – web интерфейс (в данном случае он нас не интересует). И второй – с помощью
XML-RPC. RPC расшифровывается как Remote Procedure Call (удаленный вызов процедур/функций). В принципе эта технология очень похожа на обычные запросы. От клиента к серверу передается строка с данными. Но
XML-RPC требует, чтобы эта строка имела специальный формат. Используя

27
XML-RPC можно опубликовать пост с помощью всего одного запроса, а специальные библиотеки позволяют не углубляться в тонкости стандарта. Для наших целей была найдена библиотека IXR - The Incutio XML-RPC Library.
Алгоритм удаленного размещения статьи в общем случае, примерно выглядит так:
1. Загружается библиотека XML-RPC и указывается адрес блога, для которого будет идти публикация (отмечу, что если необходимо опубликовать пост в несколько блогов, то метод вызывается для каждого
URL-а отдельно);
2. Формируется XML-RPC запрос.
3. В завершении сформированный XML запрос отправляется на сервер, и в зависимости от ответа принимается решение о результатах публикации.
Диаграмма используемых классов изображена на рисунке 15. Диаграмма последовательностей – на рисунке 16.

28
Рисунок 15 – Диаграмма классов модуля размещения контента в удаленный
блог
Рисунок 16 – Диаграмма последовательностей модуля размещения контента
в удаленный блог
Результаты реализации остальных частей веб-сервиса, можно посмотреть в приложении 1.

29
Заключение
Целью данной работы являлась разработка веб-сервиса, который бы предоставлял частным работникам медицинской сферы необходимый функционал для управления своими инструментами для интернет-маркетинга из одного места.
В ходе выполнения работы был выполнен анализ существующих систем, выявлены требования к разрабатываемому приложению, спроектирована архитектура и реализован веб-сервис для интернет-маркетинга частных работников медицины.
Таким образом, все поставленные задачи выполнены и цель работы достигнута.
Разработанный веб-сервис введен в эксплуатацию на поддомене сайта www.doctorhero.com по адресу app.doctorhero.com.

30
Список использованной литературы
1. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма [и др.]. – СПб.: Питер, 2001. - 368 с.
2. Документация по работе с php-фреймворком Laravel [Электронный ресурс] // URL: https://laravel.com/docs/5.2 (дата обращения: 08.04.2016).
3. Клиентская библиотека работы с URL [Электронный ресурс] // URL: http://php.net/manual/ru/book.curl.php (дата обращения: 14.04.2016).
4. Справочник по CSS [Электронный ресурс] // URL: http://htmlbook.ru/css (дата обращения: 27.03.2016).
5. Справочник по PHP [Электронный ресурс] // URL: http://www.php.su (дата обращения: 20.04.2016).
6. Удаленная публикация в WordPress через XML-RPC [Электронный ресурс] // URL: http://azzrael.ru/wordpress-xml-rpc-metaweblog-api (дата обращения: 14.04.2016).
7. The Open Graph protocol [Электронный ресурс] // URL: http://ogp.me/ (дата обращения: 14.02.2016).

31
Приложение 1. Руководство пользователя
Нарисунке 11 изображен главный экран веб-сервиса. Навигационное меню слева отображает ссылки на страницы с инструментами интернет- маркетинга. Над ним изображение профиля и ссылка на страницу профиля. В правом верхнем углу ссылка на панель настроек аккаунта и кнопка Выхода.
Продемонстрируем некоторые варианты использования от лица пользователя:
Manage profile – Рисунок 17 -секция настроек разбита на вкладки. В каждой вкладке настройки сгруппированы по типу.
Рисунок 17 – Настройки профиля
Вкладка секции настроек - Авторизация в соц сетях. Рисунок 18
Рисунок 18 – Авторизация в социальных сетях

32
Blogposting – снизу секция готовых статей. На рисунке 19 - выпадающий список позволяет отфильтровать статьи по нужной категории. При нажатии на кнопку Select – статья вставится в поле для редактирования. При нажатии на кнопку Post – статья разместится на блоге пользователя.
Рисунок 19 – Размещение контента в блог
Reputation monitor – рисунок 20 – страница со всеми отзывами пользователя, собранными с разных сервисов отзывов. Можно увидеть подсчет количества типов отзывов. Выпадающий список сверху позволяет отфильтровать отзывы по конкретному сервису отзывов.
Рисунок 20 – Просмотр отзывов

33
Social media – на рисунке 21используется контент, предоставленный администраторами сервисами. Достаточно навести на изображение с нужным контентом. Появится кнопка, позволяющая разместить контент в поле для отправки в соц.сети. Галочки соответственно определяют, в какую именно соц. сеть необходимо выполнить размещение контента. Также можно вставить свою ссылку в поле ввода текста. Из страницы, расположенной по адресу ссылки будет выделена полезная информация и отобразится предпросмотр, как размещенная ссылка будет выглядеть в социальных сетях, куда пользователь собирается разместить контент.
Рисунок 21 – Размещение контента в социальные сети
Mailing letters – нарисунке 22 изображен процесс отправки писем. Она может осуществляться как одному пациенту, так и нескольким. Имеется возможность выбора из преднастроенных списков адресов. Также, список может загружаться из .csv файла.

34
Рисунок 22 – Рассылка писем пациентам