Исключения: нет.

Предусловия: были получены сайты и шаблоны отчетов Аналитика.

Постусловия: нет.

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

Рисунок 3.10. Диаграмма последовательностей для построения отчёт

69

Описание системных операций:

1. Имя: buildReport(site, template)

Обязанности: запросить у templates-service шаблон и отобразить данные выбранного сайта согласно ему.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: Аналитик выбрал сайт и шаблон для построения отчета

Постусловия: нет.

2. Имя: template(id)

Обязанности: запросить у внутреннего API шаблон и вернуть его report-controller.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос шаблона от report-controller.

Постусловия: нет.

3. Имя: get(api/templateId)

Обязанности: запросить у модели данных шаблон и вернуть его templates-service.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: в случае проблем в работе базы данных сообщить об этом.

Предусловия: пришел запрос шаблона от templates-service.

Постусловия: нет.

4. Имя: findById(templateId)

Обязанности: найти нужный шаблон в базе данных и вернуть его внутреннему API.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос шаблона от внутреннего API

Постусловия: нет.

5. Имя: addNewView(elem)

Обязанности: создать новое абстрактное представление метрики и запросить ее значение у data-service.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос на создание нового представления от report-controller.

Постусловия: создан новый объект AbstractViewController.

6. Имя: getData(counterId, elem)

Обязанности: запросить у внутреннего API значение метрики и вернуть его для представления в AbstractViewController.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос значения метрики от AbstractViewController.

Постусловия: нет.

7. Имя: post(`api/data/counterId')

Обязанности: запросить у Яндекс.Метрики значение метрики и вернуть его data-service.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос значения метрики от data-service.

Постусловия: нет.

8. Имя: get(request)

Обязанности: получить у Яндекс.Метрики значение метрики и вернуть его внутреннему API.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: пришел запрос значения метрики от внутреннего API.

Постусловия: нет.

9. Имя: setData(data)

Обязанности: подготовить и отобразить значение метрики согласно шаблону.

Ссылки: прецедент Построить отчет по шаблону.

Исключения: нет.

Предусловия: было получено значение метрики.

Постусловия: нет.

3.3 Модель базы данных

На данном этапе реализации сервиса необходимо хранить данные об аналитике и шаблонах, которые он создал. Остальная информация запрашивается у Яндекса. На рисунке 3.11 изображена схема базы данных. Аналитик обладает Id, информацией для отображения в шапке сервиса: Email и displayName, информацией для аутентификации пользователя: yandexToken и yandexId. Шаблон характеризуется Id, Name, elements и ссылкой на аналитика, который его создал. Аналитик и шаблон связаны отношением 1:М.

Рисунок 3.11. Схема базы данных

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

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

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

Рисунок 3.12. Прототип интерфейса (управление аккаунтами сервисов веб-аналитики)

После нажатия на кнопку «Добавить аккаунт» открывается форма, изображенная на рисунке 3.13. После успешной привязки аккаунта сервиса веб-аналитики он появляется в списке во вкладке «Аккаунты сервисов веб-аналитики», а сайты, которые на нем отслеживаются, становятся доступными для построения отчетов во вкладке «Построение отчетов».

Рисунок 3.13. Прототип интерфейса (добавление аккаунта сервиса веб-аналитики)

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

Рисунок 3.14. Прототип интерфейса (построение отчета по веб-аналитике сайта)

После выбора шаблона для построения отчета по аналитике интересующего сайта открывается набор представлений, указанный в этом шаблоне и значения, полученные от Яндекс.Метрики.



Глава 4. Программная реализация и стабилизация веб-сервиса

4.1 Модели реализации

Диаграмма развертывания сервиса изображена на рисунке 4.1. Клиент запрашивает у сервера необходимые данные через внутренние API, сервер взаимодействует через модель данных с базой данных, при необходимости данных по аналитике сайта или в процессе аутентификации происходит обращение к Яндексу.

Рисунок 4.1. Диаграмма развертывания сервиса

Структура проекта разрабатывалась таким образом, чтобы любой компонент можно было использовать повторно, как внутри него, так и в другом проекте. Можно выделить два больших блока компонентов: клиент и сервер (рисунок 4.2). Для начала рассмотрим клиент. Клиент включает в себя три папки: components, routes и services.

Рисунок 4.2. Диаграмма компонентов проекта

Папка components включает в себя постоянные элементы страницы сервиса и представления данных из сервисов веб-аналитики (рисунок 4.3). К постоянным элементам относятся шапка страницы и панель навигации, они присутствуют на странице вне зависимости от указанного URL. На первом этапе планируется разработать представление данных в виде графика и таблицы. Все представления основываются на абстрактном представлении, роль которого заключается в получении названия элемента, списка названий метрик и их значений. Файл application.coffee содержит все необходимые ссылки для связи компонентов между собой и пути, по которым необходимо искать файлы для отображения при тех или иных URL. Файл main.less содержит основные стили сервиса.

Рисунок 4.3. Диаграмма компонентов папки components (клиент)

Все компоненты клиента имеют одинаковую структуру. Ее можно рассмотреть на примере панели навигации (рисунок 4.4). Файл index.coffee выполняет связующую роль, файл с этим названием ищется при вызове любого из компонентов. Navbar-controller.coffee содержит логику компонента. В общем случае в этих файлах реализуются запросы данных и их подготовка к отображению. Navbar.html содержит разметку, а navbar.less -- стили.

Рисунок 4.4. Диаграмма компонентов панели навигации (клиент)

Папка routes (рисунок 4.5) содержит компоненты страницы сервиса, которые сменяют друг друга в зависимости от URL, то есть активной вкладки панели навигации. Структура каждого компонента аналогична рассмотренной ранее структуре navbar. В папке reports -- компонент для выбора сайта и шаблона отчета, в папке accounts -- компонент управления аккаунтами сервисов веб-аналитики, в папке templates -- компонент для управления шаблонами отчетов, в папке report -- компонент для построения отчета по выбранным ранее параметрам, в папке 404 -- компонент для отображения ошибки в случае указания URL, по которому не было найдено страницы.

Рисунок 4.5. Диаграмма компонентов для routes (клиент)

В папке services (рисунок 4.6) расположены компоненты, которые отвечают за взаимодействие с сервером. Через них отправляются http запросы к внутреннему API. Их структура схожа со структурой предыдущих компонентов, но в них отсутствуют файлы с разметкой и стилями.

Рисунок 4.6. Диаграмма компонентов для services (клиент)

Сервер включает в себя три папки: api, models и views (рисунок 4.7). Папка api содержит программные интерфейсы, через которые взаимодействуют клиент и сервер. Внутри папки models описывается модель данных, при помощи которой отправляются запросы базе данных. Папка views содержит шаблоны представлений, которые отправляются клиенту для дальнейшей обработки. Также сервер содержит три файла: app.coffee, database.coffee и passport.coffee. Первый файл отвечает за подключение всего необходимого для работы сервиса и рендеринг. Файл database.coffee обеспечивает соединение с базой данных. Файл passport.coffee реализует аутентификацию под профилем Яндекса с использованием сторонней библиотеки [10].

Рисунок 4.7. Диаграмма компонентов сервера

4.2 Выбор технологий и инструментов

Для разработки веб-сервиса используется стек технологий MEAN [11], включающий в себя NoSQL базу данных MongoDB, фреймворк для серверного JavaScript Express, фреймворк для разработки клиентской части AngularJS и платформу для выполнения серверного JavaScript Node.js. Данный стек был выбран, так как в него входят современные и развивающиеся технологии, позволяющие строить гибкие решения с высокой производительностью. Помимо этого, разработчики технологий работают над их качеством в постоянном взаимодействии, что снижает риски при интеграции.



4.2.1 Node.js

Node.js [12] представляет из себя среду для выполнения JavaScript на сервере, что позволяет использовать данный язык для реализации бизнес-логики. Node.js поддерживает асинхронность, но эта возможность основана не на потоках, а на событиях, что добавляет ряд преимуществ. Такой подход упрощает написание кода, повышает производительность и избавляет от блокировок.

Большое влияние на модель событий Node.js оказали Event Machine Ruby и Twisted от Python, но в Node.js цикл событий используется как языковая конструкция, а не библиотека. В других системах для старта цикла событий используется блокирующий вызов. Поведение обычно определяется через функцию обратного вызова в начале скрипта, который завершается стартом работы сервера через блокирующий вызов. В Node.js нет вызовов для запуска цикла событий, это происходит автоматически после выполнения входного скрипта. Когда больше нет функций обратного вызова на исполнение, происходит выход из цикла событий. Такое поведение схоже с поведением браузерного JavaScript -- цикл событий скрывается от пользователя.

4.2.2 Express

Express [13] представляет из себя легкий и гибкий фреймворк для написания приложения Node.js. Он включает в себя базовые функции для мобильных и веб-приложений, при этом можно использовать и функции Node.js. Express обладает минимальной функциональностью и больше направлен на маршрутизацию и промежуточную обработку.

Чтобы прописать, как приложение должно ответить на клиентский запрос по конкретному адресу, необходимо определить маршрут. Маршруты обладают следующей структурой: app.METHOD(PATH, HANDLER), где app -- экземпляр express, METHOD -- один из методов запроса HTTP (например, get, set, put), PATH -- путь, по которому был отправлен клиентский запрос, HANDLER -- обработчик, который будет выполнен в случае сопоставления маршрута. Маршрут может быть обработан функцией, массивом функций или их сочетанием. Для завершения цикла «запрос-ответ» нужно передать ответ клиенту. Для этого нужно вызвать из обработчика метод ответа (например, download, send, json).

Основная особенность express состоит в возможности построения серии вызовов функций промежуточной обработки. Такая функция имеет доступ к объектам запроса и ответа и к следующей функции, которая обычно обозначается переменной next. Выполняемая функция должна либо передать управление следующей функции, либо завершить цикл «запрос-ответ» вызовом одного из методов ответа.

4.2.3 AngularJS

AngularJS -- фреймворк, который позволяет разрабатывать динамичные веб-приложения [14]. Основная особенность AngularJS -- data-binding, который синхронизирует представление и модель данных. При изменениях в модели представление изменяется в соответствии с ним, и наоборот. Вторая базовая особенность AngularJS -- выражения, которые вычисляются в контексте модели.

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

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



4.2.4 MongoDB и Mongoose

MongoDB представляет из себя документно-ориентированную базу данных [15]. Записи в этой базе данных являются документами, которые похожи на JSON объекты. Запись состоит из названия поля и его значения. Значения полей могут включать другие документы, массивы или массивы документов. В рамках данного проекта использование документно-ориентированной базы данных особенно удобно, так как шаблоны отчетов представляют из себя набор JSON объектов.

Mongoose -- это объектное отображение для MongoDB, которое можно использовать в среде Node.js [16]. Чтобы определить структуру документа для MongoDB с помощью Mongoose, необходимо описать его схему. Схема состоит их названий полей с указанием их типов. Схемы компилируются в конструкции, называемые моделями. Экземпляры моделей представляют документы, которые могут быть сохранены в базу или извлечены из нее. Также Mongoose предоставляет широкие возможности поиска, изменения и удаления документов через запросы.

4.3 Реализация модуля аутентификации

На данном этапе было решено реализовать аутентификацию пользователей через их аккаунты Яндекс. Это было сделано при помощи инструмента Passport [10]. Он представляет из себя промежуточный обработчик для Node.js, единственная цель которого -- обработка запросов авторизации. Он поддерживает как и стандартную авторизацию через логин и пароль, так и авторизацию через аккаунты множества сервисов, в том числе через Яндекс. Каждое приложение обладает уникальными требованиями к аутентификации. Механизмы аутентификации, называемые стратегиями, реализуются индивидуально для каждого случая.

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

# Yandex auth

app.get '/auth/yandex', passport.authenticate 'yandex'

app.get '/auth/yandex/callback', passport.authenticate('yandex', {failureRedirect: '/login', successRedirect: '/'})

Внутри стратегии в сервисе создается и сохраняется новый аналитик, если вход был выполнен впервые, и обновляется значение токена доступа, если аналитик уже существует. В стратегию необходимо включать функцию обратного вызова для верификации. Ее цель -- найти пользователя с указанными учетными данными. Если он был найден и поступившие учетные данные валидны, он возвращается Паспорту через вызов return done(null, user). Если данные не валидны, вместо пользователя передается false. Также необходимо учесть возможность возникновения ошибки, например, при недоступности базы данных. В этом случае в качестве параметра передается ошибка. Ниже представлена реализация стратегии внутри сервиса.

passport.use new YandexStrategy({

clientID: YANDEX_CLIENT_ID

clientSecret: YANDEX_CLIENT_SECRET

callbackURL: YANDEX_CLIENT_CALLBACK_URL

}, (accessToken, refreshToken, profile, done) ->

AnalystModel.findOne {yandexId: profile.id}, (err, user) ->

if err then return done err

if user

user.yandexToken = accessToken

user.save()

return done null, user

AnalystModel.create({

email: profile._json.default_email

displayName: profile.displayName

yandexId: profile.id

yandexToken: accessToken

}, done)

)

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

passport.serializeUser (user, callback) -> callback(null, user.id)

passport.deserializeUser (id, callback) ->

AnalystModel.findById(id, callback)

4.4 Реализация модуля управления шаблонами отчетов

Для управления шаблонами отчетов необходимо перейти во вкладку шаблоны. На данном этапе шаблоны добавляются в формате JSON. Для этого нужно поместить шаблон в текстовую область и нажать «Создать». После этого название шаблона добавится в список созданных шаблонов над текстовой областью. Существующие поля можно удалять нажатием на кнопку «Удалить» рядом с шаблоном.

Шаблон включает в себя две пары ключ/значение: name и elements. Elements -- массив элементов, которые должны быть представлены в отчете. Каждый из них является объектом и состоит из названия, типа представления, массива метрик, массива названий метрик для отображения пользователю, дат начала и окончания периода анализа и типа группировки (неделя, месяц и т.д.). Такой формат хранения шаблонов был выбран в связи с удобством взаимодействия с Яндекс.Метрикой, которая принимает запросы в формате JSON.

После добавления шаблона в текстовую область и нажатия на «Создать» вызывается функция контроллера шаблонов, которая вызывает функцию в сервисе шаблонов и отправляет ей на вход шаблон. Как только в контроллер возвращается результат сохранения от сервиса в виде шаблона, происходит его добавление в список шаблонов. Ниже представлена функция добавления шаблона контроллера.

createTemplate: () ->

@templatesService

.createTemplate(JSON.parse($('.new-template').val()))

.then((template) => @templates.push(template))

Из сервиса отправляется HTTP запрос внутреннему API на добавление шаблона и возвращается результат сохранения контроллеру. Ниже представлено, как это реализовано.

createTemplate: (template) ->

@http

.post("/api/template", template)

.then((response) => response.data)

Внутренний API создает новый объект модели шаблона, сохраняет его в базу данных и возвращает результат сервису шаблонов. Код, выполняющий это, представлен ниже.

router.post '/template', (req, res) ->

template = req.body

template.analyst = req.user._id

new TemplateModel(template)

.save((err, template) -> if (err) then res.status(500).send(err) else res.send(template))

При нажатии на кнопку «Удалить» вызывается функция удаления шаблона в контроллере шаблонов. Она вызывает функцию из сервиса шаблонов, отправляя ей Id шаблона. После успешного удаления шаблона контроллер убирает его из списка шаблонов. Реализация удаления в контроллере шаблонов представлена ниже.

deleteTemplate: (templateId) ->

@templatesService

.deleteTemplate(templateId)

.then( => @templates = @templates.filter((t) -> t._id != templateId))

Сервис по аналогии с добавлением шаблона отправляет HTTP запрос внутреннему API на удаление шаблона и возвращает результат контроллеру. Внутренний API обращается к модели данных для удаления указанного шаблона и возвращает сервису результат удаления. Ниже представлена реализация удаления шаблона во внутреннем API.

router.delete '/template/:templateId', (req, res) ->

TemplateModel.remove({_id: req.params.templateId}, (err) ->

if (err) then res.status(500).send(err) else res.send('ok'));

4.5 Реализация модуля формирования отчетов

Для составления отчета нужно перейти во вкладку «Построение отчетов». Предварительно должен быть добавлен необходимый шаблон отчета. После перехода на указанную вкладку открывается список сайтов из Яндекс.Метрики Аналитика. Они запрашиваются контроллером у сервиса сайтов и сервисом сайтов через HTTP запрос у внутреннего API. Ниже представлена реализация запроса списка сайтов (счетчиков) у Яндекс.Метрики во внутреннем API.

router.get '/counters', (req, res) ->

request({

method: "GET"

uri: "https://api-metrika.yandex.ru/management/v1/counters?oauth_token=#{req.user.yandexToken}"

}, (err, response, body) -> res.send body)

Рядом с каждым сайтом размещается кнопка «Построить отчет» (рисунок 4.8). По клику на нее выпадает список созданных Аналитиком шаблонов. Они запрашиваются по аналогичной с сайтами схеме, но внутренний API обращается не к Яндекс.Метрике, а к базе данных через модель данных. Ниже представлена реализация запроса шаблонов Аналитика.

router.get '/templates', (req, res) ->

TemplateModel

find({analyst: req.user._id}, (err, templates) -> if err then res.send([]) else res.send(templates))

Рисунок 4.8. Выбор шаблона для построения отчета

После выбора шаблона рядом с интересующим сайтом начинается построение отчета. Для этого контроллер отчета запрашивает шаблон и выделяет его элементы. Далее последовательно обрабатывается каждый из элементов. Для каждого из них создается абстрактное представление, которое содержит в себе информацию для демонстрации пользователю. Внутри контроллера абстрактного представления происходит обращение к сервису данных для получения значений метрик. Он отправляет запрос внутреннему API, который обращается к Яндекс.Метрике. Ниже представлена реализация запроса значений метрики за нужный период

router.post '/data/:counterId', (req, res) ->

{counterId} = req.params

{metric, date1, date2, group} = req.body

request({

method: "GET"

uri: "https://api-metrika.yandex.ru/stat/v1/data/bytime?ids=#{counterId}&metrics=#{metric}&date1=#{date1}&date2=#{date2}&group=#{group}&oauth_token=#{req.user.yandexToken}"

}, (err, response, body) -> res.send body)

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

<div class="report">

<div ng-repeat="elem in ctrl.getTemplateElements() track by $index">

<div ng-switch="elem.view">

<div ng-switch-when="table">

<table-view counter="ctrl.getCounterId()" visual="elem"></table-view>

</div>

<div ng-switch-when="chart">

<chart-view counter="ctrl.getCounterId()" visual="elem"></chart-view>

</div>

<div ng-switch-default></div>

</div>

</div>

</div>

4.6 Тестирование веб-сервиса

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

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

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



Таблица 4.1. Список тестов для входа в веб-сервис

Количество счетчиков в Яндекс.Метрике	Количество шаблонов
0	0
1	1
3	3

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

Таблица 4.2. Список тестов для выхода из веб-сервиса

Текущий раздел сервиса
Построение отчетов
Шаблоны
Аккаунты сервисов веб-аналитики
Отчет

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

Таблица 4.3. Список тестов для создания шаблона отчета

Количество созданных ранее шаблонов	Количество сайтов в Яндекс.Метрике	Количество элементов в шаблоне	Значение названия шаблона
0	0	0	""
1	1	1	" "
3	3	3	123
0	0	0	Report name
1	1	1	Название отчета

В таблице 4.4 представлен список тестов для удаления шаблона отчета.

Таблица 4.4. Список тестов для удаления шаблона отчета

Количество созданных ранее шаблонов	Количество сайтов в Яндекс.Метрике
0	0
1	1
3	3

Список тестов для построения отчета по шаблону представлен в таблице 4.5. Критичных ошибок в работе данной функции найдено не было, но было сформулировано три замечания. Лучше делать кнопку «Построить отчет» неактивной в случае отсутствия шаблонов у Аналитика. Необходимо отображать название отчета и сайта при демонстрации отчета Аналитику. Стоит сообщать пользователю о причинах невозможности построить отчет, лучше отслеживать допущенные ошибки еще на стадии создания шаблона.Таблица 4.5. Список тестов для построения отчета по шаблону

Значение названия шаблона	Количество элементов в шаблоне	Значение названия элемента	Выбранный вид представления	Количество метрик в элементе	Значения метрик	Названия метрик	Дата начала периода	Дата конца периода	Группировка
""	0	""	""	0	0	""	""	""	day
" "	1	" "	chart	1	десятки	" "	текущая дата	текущая дата	week
123	3	123	table	3	сотни	123	месяц назад	месяц назад	month
Report name	0	Element name	map	0	0	Metric name	месяц вперед	месяц вперед	quarter
Название отчета	1	Название элемента	""	1	десятки	Название метрики	текущая дата	месяц вперед	year
""	3	""	chart	3	0	""	текущая дата	месяц назад	day
" "	0	" "	table	0	десятки	" "	месяц назад	текущая дата	week
123	1	123	map	1	сотни	123	месяц назад	месяц вперед	month
Report name	3	Element name	""	3	0	Metric name	месяц вперед	текущая дата	quarter
Название отчета	0	Название элемента	chart	0	десятки	Название метрики	месяц вперед	месяц назад	year
""	1	""	table	1	0	""	""	текущая дата	day
" "	3	" "	map	3	десятки	" "	""	месяц назад	week
123	0	123	""	0	сотни	123	""	месяц вперед	month
Report name	1	Element name	chart	1	0	Metric name	текущая дата	""	quarter
Название отчета	3	Название элемента	table	3	десятки	Название метрики	месяц назад	""	year
""	0	""	map	0	сотни	""	месяц вперед	""	day

Заключение

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

В процессе анализа предметной области и существующих аналогов было выявлено, что у веб-аналитиков отсутствует удобный инструмент для формирования типовых отчетов по результатам SEO-оптимизации за определенный период. Рассмотренные аналоги (Яндекс.Метрика, Google Analytics и Carrot quest) больше ориентированы на текущий анализ, а для построения типовых отчетов обладают рядом недостатков. В частности, их рабочее пространство организовано неудобно для данного процесса, они обладают довольно сложной структурой, требуют базового понимания разметки веб-страниц, имеют ограничения на количество метрик в отчете, предоставляют небольшое количество вариантов отображения метрик, в некоторых из них отсутствует возможность экспорта отчета. Выявленные недостатки были учтены при дальнейшей работе над сервисом.

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

В связи с ограничением по времени программно реализованы были только модуль аутентификации, модуль формирования отчетов и ограниченная версия модуля управления шаблонами. Аутентификация осуществляется при помощи сторонней библиотеки через аккаунт Яндекса. Создание шаблона пока возможно через его прямое описание при помощи JSON. На стадии реализации удалось поработать с новым инструментарием -- стеком технологий MEAN. Данный стек предоставляет множество современных возможностей для создания динамичных веб-страниц, а также отличается проработанностью взаимодействия между технологиями, которые входят в него.

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

В целом работу над проектом можно считать успешной, но еще есть аспекты, которые нужно проработать перед внедрением. Необходимо реализовать полноценный редактор шаблонов отчетов. Данную задачу лучше решать в рамках отдельного проекта, так как она подразумевает все стадии разработки. Помимо этого нуждается в разработке и тестировании модуль управления аккаунтами сервисов веб-аналитики. Он позволит Аналитику строить отчеты по сайтам, подключенным к разным аккаунтам. По аналогии с взаимодействием с Яндекс.Метрикой следует выстроить взаимодействие с Google Analytics.

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

Библиографический список

1. Неелова Наталия. Sembook. Энциклопедия поискового продвижения Ingate. Спб.: Издательство Питер, 2014, 520 с.

2. Kaushik Avinash. Web Analytics: An Hour a Day. Sybex, 2007, 480 с.

3. Kaushik Avinash. Web Analytics 2.0. Sybex, 2009, 475 с.

4. Коберн Алистер. Современные методы описания функциональных требований к системам. М.: Издательство Лори, 2002, 288 с.

5. Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению. СПб.: БХВ-Петербург, 2014, 736 с.

6. Ларман Крэг. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. М.: Издательский дом Вильямс, 2007, 736 с.

7. API Метрики -- Технологии Яндекса. URL: https://tech.yandex.ru/metrika/ (дата обращения: 24.04.2016).

8. Google Analytics. Google Developers. URL: https://developers.google.com/analytics/ (дата обращения: 17.10.2015).

9. База знаний Carrot quest. URL: https://carrothelp.zendesk.com/hc/ru (дата обращения: 17.10.2015).

10. Passport. URL: http://passportjs.org (дата обращения: 22.04.2016).

11. MEAN.IO. URL: http://mean.io/#!/ (дата обращения: 21.04.2016).

12. Node.js. URL: https://nodejs.org/en/ (дата обращения: 21.04.2016).

13. Express -- Node.js web application framework. URL: http://expressjs.com (дата обращения: 21.04.2016).

14. Angular JS. URL: https://angularjs.org (дата обращения: 21.04.2016).

15. Mongo DB for GIANT Ideas. URL: https://www.mongodb.org (дата обращения: 21.04.2016).

16. Mongoose. URL: http://mongoosejs.com (дата обращения: 21.04.2016).

17. Highcharts. URL: http://www.highcharts.com (дата обращения: 25.04.2016).

Размещено на Allbest.ru

...