Файл: Средства разработки клиентских программ (Обоснование выбора языка программирования и инструментальных средств для создания макетов и рабочей версии программного продукта).pdf

Рисунок 2 – Создание виртуального окружения проекта.

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

Язык XML был создан с использованием простого обусловленного синтаксиса, для легкого создания и обработки документов как человеком, так и программами. Он является расширяемым, так как не существует конкретных правил написания, кроме синтаксических. Разработчик сам согласует и следует правилам для конкретной области в соответствии с потребностями проекта. Все составляющие элементы документа обобщены в корневую часть. Они могут быть как символьные, так и числовые (дата, имя и прочие типы данных). Каждое поле информации заключается в теги, названия которых определяются также разработчиком. Объекты могут иметь вложенные или дочерние элементы, образуя иерархическую структуру. В документе формата XML могут присутствовать комментарии и различные инструкции. Теги состоят из названия, обособленного треугольными скобками. В закрывающий поле тега перед названием добавляется символ наклонной черты. Пример xml-документа представлен на рис. 3.

Рисунок 3 – Простой пример xml-документа.

Пользователю гораздо удобнее заполнять конфигурационный файл и отправлять на его на ввод разработанной системы. Так как структура языка XML достаточно интуитивно понятна как для человека, так и для электронно-вычислительной машины.

При выборе критериев для поиска научных статей следует обратить внимание на наличие основных составляющих публикации, а также ее метаданных. Практически в любой статье присутствует заголовок, авторы, текст статьи и во многих научно-технических публикациях имеется рубрикатор УДК, позволяющий определить тематику работы. Также стоит отметить, что любая статья, размещенная в глобальной сети в электронном издательстве имеет свой url-адрес. Как правило, перечень url-адресов хранятся на родительской веб-странице в виде блоков гиперссылок. Поэтому в качестве метаданных стоит учитывать так же url-адрес родительской веб-страницы электронных издательств. Многие блоки гиперссылок являются многостраничными, наличие переключателей является неотъемлемой частью задаваемых параметров при сборе информации с публикаций. Последнее, что стоит учесть – это название директории куда будут поступать выходные файлы.

Таким образом, были выделены девять основных критериев для поиска научно-технических статей с их последующим скачиванием:

1. Url-адрес блока с гиперссылками на статьи.
2. Url-адрес гиперссылки на статью.
3. Наличие многостраничности блока с гиперссылками.
4. Название директории для выходных файлов.
5. Заголовок статьи.
6. Инициалы хотя бы одного автора статьи.
7. Отрывок текста статьи.
8. Номер рубрикатора УДК для поиска.
9. Фамилия автора для поиска.

Вид получившейся структуры содержимого входного файла представлен на рис. 4.

Рисунок 4 – Пример структуры содержимого входного xml-документа разработанной системы.

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

Для разработки веб-краулеров был выбран открытый фреймворк сбора данных Scrapy (Рисунок 5).

Рисунок 5 - Scrapy краулер.

Для создания краулера с помощью Scrapy выполнены 3 этапов разработки:

1. Создание паука, который выполняет GET-запросы.
2. Извлечение данных из HTML-документа.
3. Обработка и экспорт данных.

При создании паука указываются начальные url-ссылки, на которые будут происходить запросы. Далее конфигурируются допустимые домены для запроса (Рисунок 6). Все это указывается в классе паука, как атрибуты.

Рисунок 6 – Начальные атрибуты паука.

Далее в функции по умолчанию def parse(self, response) были заданы правила по извлечению html данных. Так как веб-страница представляет собой структурированный html-документ, а структура на электронных сайтах издательств всегда одинаковая: имена авторов хранятся в отдельных тегах указанного класса, а заголовок статьи имеет класс “title”, также можно задавать конкретные блоки для выгрузки в качестве xpath-запросов. (Рисунок 7).

XPath – язык запросов к XML или HTML-документа. Синтаксис в данном отличается от принятого в XML. Xpath запрос обращается в html-документу и получает содержимое определенного блока. В нашем случае при разработке персональных веб-краулеров к определенным веб-сайтам, вычисление и ввод xpath-запросов в коде производится вручную. Указывается блок, в котором хранятся гиперссылки на другие статьи. Происходит извлечение всех ссылок из него. После чего краулером совершается переход по ним на веб-страницы статей. Далее требуемые данные извлекаются со страниц статей так же при помощи xpath-запросов и объединяются в один документ.

Рисунок 7 – Функция def parse() в пауке Scrapy.

Для обработки и экспорта данных используется специализированный класс в библиотеке Scrapy – ItemLoader, который при получении html-страницы так же с помощью либо xpath-запросов, либо css-запросов извлекает предопределенные данные в структуру заданную первоначально в классе Items() (Рисунок 8). Обработанные данные краулер выдает в режиме реального времени на экран пользователя. Настройка экспорта данных реализуется в классе ItemPipelines(), которая служит конвейером между выходными данными системы и входными в экспортные файлы (Рисунок 9). Это могут быть json-файлы, база данных или же обычные текстовые файлы.

Рисунок 8 – Класс item и itemloader для извлечения требуемых данных.

Рисунок 9 – Простейший конвейер просто возвращающий элемент с атрибутами.

После разработки персональных систем следовало уделить внимание тому, что структуры у многих сайтов разные, но все они отображаются в виде html-документа. Основная разница между ними заключается в разном расположении тех или иных требуемых объектах, полях. В персональных краулерах отличие состояло в основном только в xpath-запросах. Однако у многих блоков с гиперссылками имеется переключатель страниц. Значит при разработке универсальной системы было необходимо дополнить функциональность краулера путем парсинга html-тегов и составления персональных xpath-запросов. Для решения этой задачи было принято решение считывать одну статью из конфигурационного входного файла. Иными словами, до запуска системы, она не знает с какой структурой сайта будет работать. Поэтому как только универсальный краулер запущен, он считывает обязательные параметры в xml-документе, ищет их в hml-документе и формирует xpath-запросы а также ищет переключатели страниц, если таковые имеются, что делает систему более универсальной.

С этой задачей хорошо справилась специализированная Python библиотека BeautifulSoup. C помощью нее в теле паука был реализован условный конструктор xpath-запросов. Для создания корректных запросов программа просит пользователя ввести в качестве примера тему одной из существующих статей на выбранном сайте издательств, имя автора, и соответственно предложение из статьи. Для наглядности и быстрой отладки был разработан вначале краулер именно с ручным вводом параметров. Далее условный конструктор составляет запрос из минимум двух тегов с атрибутами (Рисунок 8). К сожалению, такой подход работает не с каждым атрибутом. В основном рубрикаторы, такие как УДК, указываются в самом начале статьи, но основываясь на анализе статей, зачастую это правило обуславливается не началом статьи, а первой страницей статьи. Поэтому BeautifulSoup отлично справилась с данной задачей, но xpath запрос не был сгенерирован для данного поля. При поиске рубрикатора УДК в статье используется метод работы со строками find() из стандартной библиотеки, который представляет html-страницу как обычный текстовый файл.

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

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

Хорошим преимуществом Scrapy является высокая производительность, но в силу того, что сеть Интернет постоянно развивается, в настоящее время на большинстве веб-сайтов стоят определители роботов, похожих на разработанную нами систему. Поэтому в качестве безопасности в настройках веб-краулера необходимо задавать атрибут Download Delay (задержка загрузки), в котором указывается интервала времени между которым будут происходить запросы. В нашем случае выбран параметр 4 секунды. Это нужно, пользователя не блокировали на информационных ресурсах или просили выполнить анти-бот действия. Установка данного интервала уменьшает скорость обработки статей, и данный показатель составляет 15-17 страниц в минуту.

Рисунок 10 – Начало запуска программы с вводом тестовых данных.

В данной работе выбран метод локального хранения собранных данных. Основным преимуществом данного метода является сокращение времени на просмотр скаченных статей, так как не тратится время на дополнительные запросы к серверу базы данных. Программа просит ввести название каталога в котором будут храниться документы (Рисунок 11).

Рисунок 11 – Пример экспорта собранных данных в каталоге.

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

2.2 Экономическое обоснование

Исходя из рыночных расценок разработки программного обеспечения, стоимость разработки подобного приложения колеблется от 0,5 до 2 млн. рублей.

Несмотря на достаточно большую стоимость, данная система позволяет сэкономить достаточно большое количество человеческих и соответственно денежных ресурсов в информационно-аналитических центрах, таких как ВИНИТИ РАН. К примеру, если на предприятии работает 30 человек, которые вручную собирают данные научных статей при зарплате 100 рублей/час, то за год компания потратит за полную сорокачасовую неделю, исходя из того, что в 2018 году 1970 рабочих часов [11], около 6 миллионов рублей. С внедрением разработанной системы в предприятие, число работников будет возможно сократить до 10 человек, которые будут задавать исходные параметры веб-сайтов и контролировать правильную функциональность универсального краулера, автоматизирующего процесс скачивания данных с научных публикаций и статей. Таким образом, экономия в год составит 3 миллиона рублей. В связи с этим срок окупаемости проекта составляет приблизительно 6 месяцев.

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

2.3 Представление продукта

Для наглядного описания принципа работы разработанной системы использован унифицированный язык моделирования UML.

Unified Modeling Language (UML) позволяет графически изображать или описывать объектное моделирование при разработки различных систем. Данный язык на сегодняшний день является открытым и общепринятым стандартом для создания абстрактных моделей разрабатываемых систем.

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