3 Проектирование архитектуры
3.1 Анализ языка программирование программирования Ruby и C++
Ruby – динамический язык программирования с открытым исходным кодом с упором на простоту и продуктивность. Он обладает элегантным синтаксисом, который приятно читать и легко писать.
К преимуществам языка программирования Ruby можно отнести следующее:
скорость разработки;
кроссплатформенность;
высокая скорость обработки текстовой информации;
интерпретируемый;
оптимизированный под работу с текстовой и веб-информацией.
Недостатки Ruby:
ресурсоемкость;
сложные алгоритмы машинного обучения работаю вычислительно дольше чем на компилируемых языкаъ.
Ruby – наиболее подходящий язык для разработки прототипов коммерческих проектов, быструю и качественную имплементацию, что весьма способствует облегчению масштабируемости системы.
C++ – компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования.
Разработка языка началась в 1979 году. Целью создания C++ было дополнение C возможностями, удобными для масштабной разработки ПО, с сохранением гибкости, скорости и портабельности C. Вместе с тем создатели C++ стремились сохранить совместимость с C: синтаксис первого основан на синтаксисе последнего, и большинство программ на C будут работать и как C++. Изначально новый язык назывался «C с классами», но затем имя было изменено на C++ – это должно было подчеркнуть как его происхождение от C, так и его превосходство над последним.
Для устранения недостатка языка Ruby в кластеризации для реализации данного модуля системы был выбран С++ как наиболее удобный и быстродействующий из высокоуровневых языков программирования. И так как Ruby очень хорошо комбинируется с С++ без необходимости дополнительно до настройки то была выбрана именно эта комбинация.
Общая схема
Для построение эффективной масштабируемой системы необходимо продумать пути транзакций данных внутри системы, исходя из перспективы расширения приложения, увеличения объема получаемых данных, необходимой легкости модификации без значительных изменений в коде системы с целью повышения точности классификации и оптимизации работы приложения с учетом возможности разработки новых, более эффективных разрабатываемых алгоритмов обработки данных, и удобном порядке взаимодействия пользователя с системой.Начальным шагом на пути к построению такой системы есть построение общей модели архитектуры приложения, изображенной на рисунке 3.1.
Разделение системы на четыре основные подчасти позволит вносить изменения в систему в определенном модуле, улучшая его работу или заменяя на другой, при сохраняющемся интерфейсе взаимодействия с данным подмодулем.
Рисунок 3.1 – Общая схема системы
«Интерфейс» отвечает за получение необходимой информации от пользователя и элементарную логику распределения задач в зависимости от текущего состояния системы. В частности, уведомляет об ошибках последовательности взаимодействия с системой, или выдача релевантных результатов с возможностью допросмотра схожих текстов.
«Парсер» отвечат за предварительную обработку входящей библиотеки, и последующий анализ текстов с целью составления полной карты распределения входных дексрипторов по конечныйм кластерам и общему распределению во всех кластерах.
«Обработчик» ответсвенный за создание, хранение структуры кластеров и дальнейшее её использование для классификации входящих запросов.
«Поисковый движок» выполняет функцию предварительной обработки поставленных запросов, направление запроса на получение индекса в «Обработчик» и вывод релевантых результатов в соответствии с нидексом.
Главным собирающим всю систему воедино модулем есть блок «Интерфейс». В данном модуле происходит взаимодействие с пользователем с целью получения от него ссылки на библиотеку классифицируемых данных и выдачи пользователю данных о принадлежности к определенному файлу его поискового запроса. Более детально структура передачи данных изображена на рисунке 3.2.
Рисунок 3.2 – Передача данных в системе
В результате получается модульная масштабируемая система с высокой производительностью и возможностью длительного поддерживания и расширения функционала. Что позволяет заняться альтернативными применениями данной архитектуры в области анализа текстовой информации и построения различных аналитических выводов, изменяя контекст самой информации или модифицируюя какой либо из модулей.
3.3 Модуль 1: Парсер
Данный модуль, получая на вход адрес библиотеки текстов, анализирует содержимое текстовых массивов и абсорбирует их в удобоваримый универсальный базовый блок-вектор, который является основой для дальнейших аналитических и алгоритмических преобразований и выводов. Подробно схема данного модуля рассмотрена на рисунке 3.3.
Рисунок 3.3 – Блок-схема алгоритма работы Парсера
Универсальный блок-вектор включает в себя наименование слова и его частотная характеристика относительно анализируемого документа. Данный блок-вектор абсорбируется общим частотным словарем который составляется из всех документов входящих в базовый кластер.
3.4 Модуль 2: Обработчик
Полученная информация из Парсера поступает на обработчик для составления иерархической структуры кластеров и их последовательного индексирования. Алгоритм работы «Обработчика» описан на рисунке 3.4.
Рисунок 3.4 – Блок-схема алгоритма работы обработчика
Под индексацией кластеров понимается присвоение кластеру его уникального порядкового номера и составления для него соответствующего для него блока-вектора дескрипторов путем слияния векторов входящих в него документов.
3.5 Модуль 3: Поисковый движок
Данный модуль частично объединяет в себе функционал Парсера и Обработчика, с привнесением своей специфики в процессы обработки и анализа как видно из рисунка 3.5.
Рисунок 3.5 – Блок-схема алгоритма работы поискового движка
Поисковый запрос сначала проходит предварительную обработку, затем кластеризуется, после чего из текущей иерархии кластеров формируется путем сложения индексов кластеров искомый индекс файла. По которому производится поиск в индексной базе из которой в последствии получается конечный путь к файлу или файлам, если выбран более широкий круг поиска.
В отличии от формируемого Парсером входного вектора который формируется для входящий в систему документов поисковые запросы формируются сразу в полный блок-вектор который поступает сразу на кластеризатор, по причине отсутствия необходимости в запоминании его в метаинформацию документа.
Поисковые индексы кластеров хранятся в базе в виде обратного поискового индекса с учетом контекста и экономит пространства на диске за счет использования числового обозначения групп. Поскольку одному кластеру сразу ассоциирован полный набор файлов, в зависимости от вложенности это позволяет избежать дополнительных операций над множествами в пределах базы и получить прирост производительности при работе с ней.