ВЫВОД ПО ГЛАВЕ 2
ООО «Максимал» реализует собственные проекты различной сложности с достаточно большой аудиторией пользователей, в связи с чем компании очень важна стабильная и корректная работа своих проектов.
В рамках данной главы была изучена деятельность компании заказчика, рассмотрена организационная структура, информационная система и программное обеспечение, используемое в компании.
Для решения задач по снижению времени тестирования новых версий приложений и своевременного определения возможных проблем при индексации новой версии приложения поисковыми системами, компании необходим инструмент, который позволит проводить своевременный аудит технического состояния и внутренних SEO факторов.
Для формирования требований к системе была построена модель бизнес-процесса аудита веб-приложений, которая включает в себя следующие под процессы:
формирование задачи;
создание аудита;
аудит;
формирование отчета;
анализ аудита.
На основе представленной модели сформировано техническое задание к системе технического и SEO аудита веб-приложений.
ГЛАВА 3 РАЗРАБОТКА И ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
3.1 Описание этапов разработки системы
Стадии и этапы разработки представлены в таблице 4.
Таблица 4 – Стадии и этапы разработки системы
№ п/п
|
Название этапа
|
Сроки в днях
|
1
|
Анализ предметной области
|
5 дней
|
2
|
Определение требований
|
2 дня
|
3
|
Проектирование
|
10 дней
|
4
|
Программирование
|
20 дней
|
5
|
Тестирование и отладка
|
10 дней
|
6
|
Написание руководств для пользователей
|
3 дня
|
7
|
Внедрение
|
1 день
|
3.1.1 Проектирование системы
На рисунке 16 представлена диаграмма вариантов использования системы.
Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между актерами и вариантами использования.
Диаграмма вариантов использования — это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:
определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
сформулировать общие требования к функциональному поведению проектируемой системы;
разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Рассматривая диаграмму вариантов использования в качестве модели бизнес-системы, можно ассоциировать ее с «черным ящиком». Концептуальный характер этой диаграммы проявляется в том, что подробная детализация диаграммы или включение в нее элементов физического уровня представления на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. Эти аспекты должны быть сознательно скрыты от разработчика на диаграмме вариантов использования.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров и отношений между этими элементами. При этом отдельные элементы диаграммы заключают в прямоугольник, который обозначает границы проектируемой системы. В то же время отношения, которые могут быть изображены на данном графе, представляют собой только фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Базовыми элементами диаграммы вариантов использования являются вариант использования и актер [19].
Рисунок 16 – Диаграмма вариантов использования системы
3.1.2 Проектирование хранения данных
Проанализировав требования к информационной системе и в соответствии с техническим заданием спроектируем базу данных, в которой будет хранится пользователи системы и информация об аудитах и заданиях. Схема спроектированной базы данных отображена на рисунке 17.
Рисунок 17 – Схема базы данных
В качестве системы управления базами данных для построения базы данных системы была выбрана СУБД MySQL.
База данных системы состоит из трех таблиц:
аудиты – в этой таблице хранится информация о созданных в системе аудитах. Описание полей таблицы представлено в таблице 5;
пользователи – в этой таблице хранится список пользователей системы. Описание полей таблицы представлено в таблице 6;
задачи – содержит список задач, которые должна выполнять система по расписанию. Описание полей таблицы представлено в таблице 7.
Таблица 5 – Структура таблицы «Аудиты»
№ п.п.
|
Название поля
|
Тип поля
|
Описание
|
1
|
id
|
int
|
id аудита
|
2
|
users_id
|
int
|
id пользователя создавшего аудит
|
3
|
title
|
varchar
|
Название аудита
|
4
|
url
|
varchar
|
Адрес сканируемого сайта
|
5
|
access_log
|
varchar
|
Путь к файлу access.log
|
Продолжение таблицы 5
6
|
access_log_format
|
varchar
|
Формат файла access.log
|
7
|
sitemap
|
varchar
|
Путь к файлу sitemap.xml
|
8
|
ignore_elements
|
varchar
|
Список игнорируемых селекторов при парсинге
|
9
|
user_agent
|
varchar
|
User-Agent для парсинга страниц
|
10
|
state
|
tinyint
|
Статус аудита
|
11
|
created_at
|
datetime
|
Дата и время создания аудита
|
12
|
protocol
|
varchar
|
Список протоколов для парсинга
|
13
|
subdomain
|
tinyint
|
Булево значение определяюшие необходимость сканирования поддоменов
|
14
|
robots
|
tinyint
|
Булево значение определяюшие необходимость учета условий файла robots.txt
|
15
|
nofollow
|
tinyint
|
Булево значение определяюшие необходимость учета тегов nofollow
|
16
|
linklimit
|
int
|
Значение задающие лимит на сканирование страниц
|
17
|
launched_at
|
datetime
|
Дата и время запуска аудита
|
18
|
completed_at
|
datetime
|
Дата и время завершения аудита
|
19
|
creator
|
varchar
|
Определяет кто создал аудит, пользователь или система
|
20
|
source
|
varchar
|
Определяет список источников для парсинга
|
21
|
source_audit
|
int
|
id аудита выбранного в качестве источника ссылочной массы
|
Таблица 6 – Структура таблицы «Пользователи»
№ п.п.
|
Название поля
|
Тип поля
|
Описание
|
1
|
id
|
int
|
id пользователя
|
2
|
email
|
varchar
|
Email
|
3
|
password
|
varchar
|
Пароль
|
4
|
permissions
|
varchar
|
Определяет уровень доступа пользователя к настройкам системы
|
5
|
activated
|
tinyint
|
Булево значение определяюшие активирована ли учетная запись
|
6
|
activation_code
|
varchar
|
Код активации
|
7
|
activated_at
|
datetime
|
Дата и время активации
|
8
|
last_login
|
datetime
|
Дата и время последнего входа
|
9
|
persist_code
|
varchar
|
Код сессии пользователя
|
10
|
reset_password_code
|
varchar
|
Код сброса пароля
|
11
|
name
|
varchar
|
Имя пользователя
|
12
|
created_at
|
datetime
|
Дата и время создания пользователя
|
13
|
updated_at
|
datetime
|
Дата и время изменения записи
|
Таблица 7 – Структура таблицы «Задачи»
№ п.п.
|
Название поля
|
Тип поля
|
Описание
|
1
|
id
|
int
|
id задачи
|
2
|
users_id
|
int
|
id пользователя
|
3
|
audits_id
|
int
|
id аудита
|
4
|
enable
|
tinyint
|
Булево значение определяюшие активирована ли задача
|
5
|
interval
|
int
|
Интнрвал выполнения задачи
|
6
|
description
|
varchar
|
Описание задачи
|
7
|
lastlaunch
|
datetime
|
Дата и время последнего выполнения задачи
|
Продолжение таблицы 7
№ п.п.
|
Название поля
|
Тип поля
|
Описание
|
8
|
new
|
tinyint
|
Булево значение определявшие первый запуск задачи
|
9
|
duration
|
int
|
Продолжительность выполнения задачи
|
Для хранения отчетов аудита используется поисковый движок Elasticsearch, как документо-ориентированная СУБД.
Документо-ориентированная СУБД (англ. document-oriented database) — СУБД, специально предназначенная для хранения иерархических структур данных (документов) и обычно реализуемая с помощью подхода NoSQL. В основе документоориентированных СУБД лежат документные хранилища (англ. document store), имеющие структуру дерева (иногда леса). Структура дерева начинается с корневого узла и может содержать несколько внутренних и листовых узлов. Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, что позволяет даже при достаточно сложной структуре находить место (путь) искомых данных. Интерфейс для поиска позволяет находить по запросу документы и части документов. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память [24].
Elasticsearch — документо-ориентированная база данных: весь пул объектов, по которому необходимо делать поиск, должен быть проиндексирован, а значит, перед индексацией документы должны быть денормализованы. Это увеличивает производительность извлечения (так как вам не требуются join-запросы), требует больше дискового пространства (из-за хранения избыточной информации), но при этом обеспечить консистентность и актуальность данных (любое измерение затрагивает все документы, содержащие изменяемый объект) становится сложнее. Однако это идеальный вариант, если документ необходимо сохранить один раз, а читать его будут много раз.
В Elasticsearch не надо указывать схему данных заранее. Достаточно отправить JSON-документ, и сервер сам выполнит необходимые операции, чтобы определить его тип. Это хорошо работает, когда речь идет о числовых и логических типах данных и о временных метках. Для строк будет использоваться стандартный анализатор, который подходит для базовых операций.
Lucene, на основе которой построен Elasticsearch, имеет поддержку транзакций, хотя Elasticsearch при этом не имеет транзакций в привычном понимании этого слова. То есть откатить отправленный документ или работать с группой документов атомарно невозможно. Зато Elasticsearch имеет функцию write-ahead-log, обеспечивающую надежность операции и исключающую необходимость использовать дорогой Lucene-коммит. Также можно указать уровень консистентности операций индексирования, то есть сколько реплик должны признать операцию прежде, чем вернуть результат.
Elasticsearch обеспечивает манипуляции с данными и поиск практически в реальном времени. По умолчанию, между индексированием/обновлением/удалением данных и появлением этих изменений в результатах поиска проходит одна секунда. Это отличает Elasticsearch от систем SQL, в которых все изменения видны после завершения транзакций [10].
3.1.3 Разработка системы
Так как в процессе анализа средств проектирования системы, для построения архитектуры системы был выбран сервис-ориентированный подход или так называемая сервис-ориентированная архитектура, то все элементы системы должны быть выполнены в виде отдельных приложений (утилит) использующих для обмена информацией общую шину сообщений. В связи с этим система была разбита на следующие сервисы:
пользовательская панель – веб-интерфейс для взаимодействия пользователя с системой;
балансировщик – сервис, управляющий процессами сервисов конкретного аудита;
парсер – сервис парсинга данных с веб-страниц;
сепаратор – сервис, фильтрующий страницы для парсинга;
парсер файлов стандарта sitemap;
парсер файлов журналов логирования (access.log, error.log);
менеджер хранилища – сервис, управляющий записью данных в Elasticsearch.
Давайте рассмотрим данные части системы подробнее.
3.1.3.1 Пользовательская панель
Данный компонент системы представляет собой веб-интерфейс для взаимодействия пользователя с системой. В качестве языка программирования данного приложения используется язык PHP и фреймворк Phalcon. Интерфейс панели представлен на рисунке 18.
Рисунок 18 – Интерфейс пользовательской панели.
С помощью данного интерфейса пользователь может совершать следующие действия:
регистрация;
вход на сайт;
создание аудита;
запуск, пауза и остановка аудита;
просмотр отчетов;
фильтрацию данных отчетов;
выгрузку отчетов;
сравнение отчетов;
создание заданий на проверку.
3.1.3.2 Балансировщик
Данный сервис написан на языке программирования Go и позволяет клиентской части приложения взаимодействовать с серверной частью, посредствам командам, передаваемым по HTTP протоколу.
В зависимости от принятой команды сервис может запускать, останавливать либо менять конфигурацию других сервисов.
3.1.3.3 Парсер
Данный сервис сканирует веб-страницы и находит на них следующие данные:
ссылка на страницу;
источник ссылки;
текст ссылки;
тип ссылки;
target ссылки;
переадресации;
статус;
тип контента;
размер контента;
заголовок страницы;
длина заголовка;
дубликаты заголовков;
мета теги;
длина мета тегов;
дубликаты мета тегов;
заголовки на странице;
ссылки на другие страницы.
Далее он передает наеденные данные менеджеру хранилища, а все найденные на странице ссылке сепаратору.
Схема работы парсера представлена на рисунке 19.
Рисунок 19 – Схема работы компонента «Парсер»
3.1.3.4 Сепаратор
Данный компонент фильтрует ссылки согласно условиям, заданным при создании аудита, отбрасывает повторяющиеся страницы, и передает менеджеру хранилища данные о родителе страницы, для последующего построения дерева страниц в отчетах.
Для хранения списка страниц аудита и нахождения дублей сервисом используется журналируемое хранилище Redis.
Redis (REmote DIctionary Server) — это нереляционная высокопроизводительная СУБД. Redis хранит все данные в памяти, доступ к данным осуществляется по ключу. Опционально копия данных может храниться на диске. Этот подход обеспечивает производительность, в десятки раз превосходящую производительность реляционных СУБД, а также упрощает секционирование (шардинг) данных [14].
3.1.3.5 Менеджер хранилища
Данный сервис предназначен для записи данных в Elasticsearch пакетами по 1000 записей либо по превышению лимита времени. Это позволяет снизить нагрузку на каналы передачи данных и упростить обработку информации со стороны Elasticsearch [8].
|
