И. Ю. Коробейникова



страница8/11
Дата09.11.2016
Размер3.49 Mb.
Просмотров3059
Скачиваний0
ТипНаучная работа
1   2   3   4   5   6   7   8   9   10   11

ВЫВОД ПО ГЛАВЕ 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].

Каталог: files -> main -> documents -> 2016
2016 -> Допустить к защите
2016 -> Методические рекомендации по выполнению внеаудиторной самостоятельной работы студентов по программе дисциплины
2016 -> Методическая разработка практического занятия по теме «Создание и воспроизведение видеороликов в программе Movie Maker»
2016 -> «Разработка информационного сайта для проекта «Живая история». В работе раскрывается актуальность темы, сформулированы цели и задачи исследования
documents -> Методические указания для студентов очной формы обучения по выполнению
documents -> Методическое пособие по дисциплине «информационная безопасность»
2016 -> Методические рекомендации по выполнению практических работ по дисциплине «Деловой русский язык»
documents -> Комплект оценочных средств Учебная дисциплина ен. 03 Информатика
2016 -> Аварии и катастрофы. Причины, виды, примеры


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10   11


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал