Размещено на http://www.allbest.ru/

Аннотация

программный сервис поиск интернет

Выпускная курсовая работа посвящена разработке модели программного комплекса для поиска данных о человеке в интернете под управлением операционной системы iOS для мобильного клиента и под управлением операционной системы MacOS для поисковой программы. Цель данной работы заключается в построении модели эффективного, работоспособного и отказоустойчивого сервиса для конечных пользователей мобильных устройств, выпускаемых компанией Apple.

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

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

Введение

Активный рост объема данных, полученных с помощью популярных сетей, наблюдается каждый год. Статистика говорит, что численность, например, русской аудитории популярных на территории Российской Федерации социальных сетей также увеличивается. Таким образом аудитория "ВКонтакте" насчитывает около 55 млн. пользователей, "Одноклассники" - 40 млн. пользователей, "Facebook" - 25 млн. пользователей. Значение социальных сетей для общества не требует разъяснений: мгновенной общение на больших расстояниях, изучение большого количества научного и художественного материалов, слежение за новостями всего мира и много другое. Логично, что с ростом аудитории и развитием внутренних сервисов растет и количество данных. Их доступность для других пользователей (в том числе и таких третьих лиц, как государственные учреждения) регулируется организацией, которая владеет той или иной социальной сетью.

В 2018 году был сделан еще один шаг на пути к защите персональных данных - постановление Европейского Союза GDPR. Данный регламент влияет на все социальные сети, которые работают на территории Европейского Союза, в силу глобализации сервисов результатами его работы могут воспользоваться не только граждане ЕС, но и все остальные, хоть это и не касается всего.

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

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

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

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

Для достижения поставленной цели требуется решить следующие задачи:

1) Провести информационное обследование существующих аналогов;

2) Проанализировать существующие решения по реализации архитектур подобных программных комплексов;

3) Рассмотреть методы сбора и анализа данных социальных сетей;

4) Разработать программный код клиентского приложения, поисковой программы и сервера;

5) Разработать прототип интерфейса для мобильного клиента;

6) Разработать User Interface для мобильного клиента;

7) Определить средства обеспечения информационной безопасности персональных данных;

8) Оценить скорость метода сбора данных и их группировки по общему признаку;

9) Оценить эффективность принятых решений.

В свою очередь, чтобы решить приведенные задачи потребовалось использование следующих инструментальных средств:

– Xcode - компилятор, позволяющий написать, собрать, запустить и протестировать программный код для приложения клиента и поисковой программы;

– Rested - программа, позволяющая составить HTTP-запросы;

– Brackets - редактор программного кода для реализации логики сервера;

– GitHub - сервис, который позволяет осуществлять контроль версий разрабатываемых объектов;

– Sketch - графический редактор, позволяющий разработать прототип интерфейса мобильного клиента;

– Draw.io - сервис, который позволяет реализовать UML-диаграммы.

А также использование следующих программных ресурсов:

– SocketIO - фреймворк, который позволяет реализовать взаимодействие Клиент-Сервер и Сервер-Поисковик;

– Node.js - библиотека, которая позволяет разрабатывать логику работы сервера;

– Alamofire - фреймворк, который позволяет создавать стандартные HTTP-запросы;

– VK SDK - набор средств для разработки взаимодействия с API "ВКонтакте";

– Facebook SDK - набор средств для разработки взаимодействия с API "Facebook";

– OK SDK - набор средств для разработки взаимодействия с API "Одноклассники".

2. Информационное обследование существующих аналогов

2.1 Общие сведения

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

При разработке алгоритмов поиска и анализа социальных данных необходимо учитывать следующие факторы:

– Степень приватности пользовательского контента (область видимости);

– Вариативность качества персональных данных (ложные аккаунты, спам);

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

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

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

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

2.2 Выбор критериев и сравнение существующих аналогов

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

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

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

Третьим по важности критерием является скорость поиска. Если в случае с частными пользователями поиск будет осуществляться более нескольких минут, то высока вероятность того, что сервисом не будут пользоваться даже, если точность поиска высока.

Распространенные сервисы в аналогичной сфере услуг и их сравнение по основным и общим критериям рассмотрены в таблице 1.

Таблица 1Сравнение основных аналогов по выбранным критериям

Программа или сервис	Входные параметры	Источники поиска	Точность поиска	Скорость поиска	Монетизация
FindFace	Фотография	Вконтакте	80%	~10 сек.	За дополнительные возможности от 149 до 459 руб.
Detector	Номер телефона	Вконтакте, Instagram и Facebook	70% (если есть данные)	1-10 сек.	15 руб.
Встроенный поиск	Любые параметры, представленные в социальной сети	У каждой социальной сети есть свой поиск	60%	1-5 сек.	Бесплатно
Яндекс Поиск	ФИО, возраст, проживание, учеба и работа	Основные социальные сети	50%	~1 сек.	Бесплатно

Выводы

Популярные основные аналоги, которые представлены в таблице 1, по поиску информации о людях имеют различия по выбранным критериям. Исходя их данных таблицы 1, трудно однозначно выбрать сервис, поэтому разрабатываемый в данной работе модель программного комплекса будет объединять в себе лучшие показатели: несколько основных входных параметров, которые представлены в каждой отдельной социальной сети, источниками поиска рассматриваются четыре основные социальные сети, которые популярны на территории Российской Федерации, высокие точность и скорость поиска, бесплатное распространение.

3. Анализ и исследование существующих решений по реализации архитектуры

3.1 Исследование метода реализации распределенной архитектуры для программного комплекса

3.1.1 Распределенная архитектура

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

Основными преимуществами систем с распределенной архитектурой являются:

1) Масштабируемость, которая позволяет добиться увеличения вычислительных мощностей, не изменения структуры распределенной архитектуры;

2) Управление нагрузкой, которая позволяет распределить потоки данных клиентов на менее загруженные серверы;

3) Глобальность, которая позволяет размещать клиентские рабочие станции или сервера в наиболее удобных физических точках.

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

Наиболее распространенная модель распределенной архитектуры в программных комплексах - трехзвенная [1].

Первым звеном в такой архитектуре является пользовательский уровень или уровень представления данных. На данном уровне осуществляется все взаимодействие с пользователем: создание запросов, просмотр и редактирование данных и т.д.

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

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

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

Типичная схема трехзвенной распределенной архитектуры представлена на рисунке 1.

Рис. 1. Типичная схема распределённой архитектуры

3.1.2 Анализ существующих программных решений для реализации распределенной архитектуры

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

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

Такое взаимодействие с сервером может обеспечить технология использования сокетов. Socket - сетевой интерфейс приложения, на котором можно настроить IP-адрес, протокол и номер порта для взаимодействия. Данный выбор позволит поддерживать постоянное прослушивание созданного канала на предмет поступления новых данных, что существенно упростит разработку сетевой части, а также повысит скорость взаимодействия [2].

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

Первой из них является BlueSocket, разработанная компанией IBM. Данный фреймворк включает в себя достаточное для целей количество функций и поддерживаемых протоколов (например, IPV4, IPV6, TCP, UDP и др.), что позволит достаточно гибко настроить сетевое взаимодействие. Поддерживает такие операционные системы, как iOS, MacOS и Linux, однако не поддерживает WatchOS, то есть перспектива разработать клиент на умные часы не реализуема с BlueSocket.

Следующая библиотека - это SwiftSocket. Данная библиотека подойдет для использования на всех платформах, разработанных компанией Apple, однако фреймворк не поддерживает новую версию языка программирования Swift v4 (Swift v5 ориентировочно выйдет в 2019 году), на котором предполагается разработка сервиса, к тому же SwiftSocket плохо документирован и, судя по дате последнего коммита, более не поддерживается.

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

Последняя рассматриваема библиотека для реализации технологии сокетов - Socket.io [3]. Данный фреймворк имеет достаточный для данной работы функционал, исчерпывающую документацию, поддерживает необходимые платформы и адаптирован по Swift 4-й версии, а также регулярно обновляется. Также стоит учитывать большую базу демо-программ и уроков, что позволит увеличить скорость его интеграции с проектом.

3.2 Анализ существующих архитектурных шаблонов для программного кода

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

Одним из первых среди архитектурных шаблонов стал Model-View-Controller (MVC) [4], многие из современных шаблонов реализованы на его основе с учетом выявленных недостатков.

MVC, предлагаемый компанией Apple, состоит из трех частей:

1) Модель (Model). Данная часть ответственна за основную бизнес-логику приложения. Она должна быть независима от других слоев и «не знать» ничего о дизайне элементов. К слою модели можно отнести базу данных, структуры данных или различные менеджеры.

2) Представление (View). Второй слой отвечает за отображение данных на экране. Представление в идеальном случае не должно взаимодействовать с моделью напрямую, данные, которые надо отобразить, данная часть принимает из контроллера. К слою представления можно отнести такие элементы, как таблицы, окна, кнопки и т.д.

3) Контроллер (Controller). Третий слой отвечает за коммуникацию пользователя с моделью через представление. Контроллер является связующим звеном между двумя первыми слоями, используя разные методы. К трем основным методам можно отнести обратные вызовы (callbacks), делегирование (delegation), оповещения (notifications) и др.

Различают два вида реализации архитектуры MVC: passive view и supervising controller. Passive view предполагает, что взаимодействие модели и представления будет происходить исключительно через контроллер, что позволит четко разграничить зоны ответственности и упростит поддержку написанного кода. Такой подход в составлении архитектуры приведет к увеличению массы кода из-за необходимости реализации дополнительных классов сообщений. Supervising controller же, напротив, разрешает взаимодействовать напрямую между моделью и представлением в случаях, когда это уместно. Данная концепция усложнит unit-тестирование и поддержку кода из-за сложных связей.

Следующий архитектурный шаблон из "семейства" MV(X) был разработан, чтобы провести работу над ошибками предыдущего путем создания абстрактного интерфейса для представления. Основное преимущество, которое можно выделить для данного шаблона - слой presenter в силу своей независимости может быть использован несколько раз. Среди недостатков архитектурного шаблона можно выделить такой, как необходимость создания и поддерживания интерфейсов для представлений, следовательно, это приводит к написанию "лишнего" шаблонного кода.

Другой архитектурный шаблон - это Model-View-View Model (MVVM). Его основное отличие - связка с событиями и свойствами view model с элементами представления, то есть и представление, и модель взаимодействуют через слой view model: все подписчики оповещаются при изменении модели, на что происходит реакция подписанного представления, и наоборот.

Помимо представленных архитектурных шаблонов существуют множество других таких, как Clean Swift, View-Interactor-Presenter-Entity-Routing (VIPER), Naked objects, Presentation-Abstraction-Control и т.д.

Для более точного выбора архитектурного шаблона под задачи проекта приведем критерии для оценки альтернатив в таблице 2.

Таблица 2Критерии для оценки альтернатив при выборе архитектурного шаблона

Решение	Распределение обязанностей	Повторное использован	Уровень тестируем	Простота использован	Скорость разработ	Основные недостатки
MVC	Слабо сбалансирован	В большинс случаев невозможно	Низкий	Просто	Высокая	Massive View Controller
MVP	Слабо сбалансирован	Возможно в половине случаев	Высокий	Средне	Низкая	Отсутствие обязанностей у View, много связующего кода
MVVM	Средне сбалансирован	Возможно в большинстве случаев	Высокий	Просто	Средняя	Тяжело отлаживать
Viper	Сбалансирован	Возможно во всех случаях	Высокий	Сложно	Низкая	Тяжело отлаживать, много связующего кода

Далее необходимо рассчитать веса критериев, основываясь на методе аналитических иерархий. Для выполнения метода одним экспертом понадобится:

1) На основе оценок пар критериев составить матрицу парных сравнений;

2) Подсчитав среднее геометрическое строк матриц, определить цены критериев;

3) Подсчитать сумму полученных цен;

4) Определить веса критерием путем деления цены на сумму цен;

5) Определить критерий с максимальным весом.

Наконец, полученную оценку необходимо проверить на согласованность:

1) Подсчитать сумму элементов столбцов;

2) Просуммировав произведения сумм элементов столбцов и весов критериев, подсчитать вспомогательную величину;

3) Определить индекс согласованности;

4) Определить отношение согласованности;

5) Полученное число должно быть менее 0.2, если величина отношения больше, то необходимо уточнение матрицы парных сравнений.

Подсчет критериев методов аналитических иерархий отображен в таблице 3, проверка согласованности показана в таблице 4.

Таблица 3Расчет весов критериев на основе метода аналитических иерархий

	Распредел обязанност	Повторное использов	Уровень тестируем	Простота использов	Скорость разработ	Основн недостат
Распределение обязанностей	1	3	1/5	7	9	1/3
Повторное использование	1/3	1	1/5	3	3	1/3
Уровень тестируемости	5	5	1	7	9	3
Простота использования	1/7	1/3	1/7	1	3	1/5
Скорость разработки	1/9	1/3	1/9	1/3	1	1/7
Основные недостатки	3	3	1/3	5	7	1
Среднее геометрическое	0.66	1.31	0.24	2.50	4.15	0.46
Вес	0.07035	0.14033	0.026197	0.268442	0.445274	0.049407

Таблица 4Проверка экспертной оценки на согласованность

Суммы элементов столбцов	Вспомогательная величина	Индекс согласованности	Отношение согласованности
20.53	6.488	0.098	0.108
7.87
30.00
4.82
2.03
19.33

Проверка экспертной оценки показало, что величина отношения согласованности равна 0.108, что значительно меньше порогового 0.2. Следовательно, оценка критериев была произведена успешно. Сама оценка показала, что наиболее весомый критерий при выборе архитектурного шаблона - это скорость разработки.

Таким образом для написания программного кода в модели сервиса по поиску информации человека в интернете рекомендуется применять архитектурный шаблон MVC по следующим причинам:

– Четкое распределение зон ответственности;

– Высокое распространение среди разработчиков;

– Удобство в использовании в среде разработки Xcode из-за особенностей построения проектов;

– Рекомендации компанией Apple для разработки программ, приложений и расширений под их продукты.

Итоговая архитектурная схема модуля сервиса на базе шаблона MVC изображена на рисунке 2, где стрелками показаны варианты взаимодействия слоев шаблона.

Рис. 2. Итоговая архитектурная схема шаблона MVC

Выводы

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

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

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

Как клиентское приложение, так и программа поиска высоковероятно будут представлять из себя габаритный программный код, который необходимо поддерживать и обновлять из-за высокой скорости изменения рынка, следовательно, выбор гибкой архитектуры особо важен. Анализ существующих решений среди архитектурных шаблонов показал, что наиболее подходящий и удобный с точки зрения разработчика под операционную систему iOS - это паттерн MVC (Model View Controller). Данный шаблон позволяет не только четко разграничить ответственность, но и является распространенным среди других разработчиков, что упростит коммуникацию в команде при разработке сервиса.

4. Методы сбора и анализа данных социальных сетей

4.1 Общие сведения

Анализ данных (Data Mining) - это одно из наиболее актуальных ИТ направлений на данное время. В данном случае под анализом данных подразумевается процесс поиска полезных данных (пригодных к использованию в тех или иных ситуациях) из общего массива данных. Зачастую такую информацию сложно либо невозможно обнаружить при обычном просмотре или переборе из-за большого объема.

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

Разрабатывая алгоритмы анализа данных, следует принимать во внимание следующие факты:

1) Пользователи могут скрывать какую-либо информацию о себе настройками;

2) Пользователи могут иметь несколько аккаунтов в социальных сетях;

3) Возможно выделить хотя бы одно сообщество для каждого пользователя, где пользователи будут знакомы друг с другом;

4) "Друзья" пользователей в социальных сетях будут повторяться.

Не только инфраструктурные, но и алгоритмические решения необходимы для обработки данных социальных сетей, которые позволят учитывать их размерность. Например, социальная сеть Facebook насчитывает более 1 миллиарда профилей и более 100 миллиардов связей. Ежедневно добавляются около 200 миллионов новых фотографий и более 2 миллиардов комментариев. Большинство существующих алгоритмов, которые эффективно решают актуальные задачи, не могут обрабатывать такие массивы данных за разумное время.

Так как данный сервис не имеет цели обрабатывать данные всех профилей социальных сетей, а только искать конкретные аккаунты, то информация далее не будет делать на это упор.

4.2 Сбор первичных данных

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

Этап сбора первичной информации в основном связан с взаимодействием с социальными сетями через программный интерфейс (API), что может привезти к ряду проблем:

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

– Приватность. На данный момент практически все социальные сети закрыли доступ к данным через API для не зарегистрированных пользователей. Это значит, что клиентский модуль обязан иметь механизмы авторизации в социальных сетях и передачи сгенерированного после авторизации токена в поисковую программу для инициализации поисковых запросов.

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

– Размерность данных. Сбор некоторых данных требует инициализации нескольких запросов.

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

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

1) В одной группе все профили должны принадлежать одному человеку;

2) В каждой группе должно находиться не более одного профиля из каждой социальной сети.

Общая схема обработки данных в таком случае изображена на рисунке 3, где происходят следующие процессы:

1) Формирование очереди данных из различных источников для обработки, где данные представляют собой структуру из пары параметров идентификатора пользователя и идентификатор социальной сети;

2) Пакетирование данных и формирование RDD (Resilient Distributed Dataset) для увеличения производительности;

3) Поиск и группировка профилей социальных сетей для каждой из полученных пар, а также поиск всей публичной информации по каждому из профилей (поиск будет осуществляться в несколько итераций, так как существуют лимиты на скорость и количество запросов);

4) Экспорт данных в очередь;

5) Сохранение в базу данных.

Рис. 3. Общая обработки первичных данных социальных сетей

4.3 Обработка данных

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

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

Для удобства использования итоговых данных стоит разделить демографические атрибуты на два подраздела: численные (возраст, доходы и т. д.) и категориальные (раса, взгляды, семейное положение и т. д.). Такое разделение оправдывается тем, что численные категории можно перевести в набор категорий (возраст в возрастные категории).

В ИСП РАН была разработана методология определения демографических атрибутов на примере социальной сети Twitter [5]. Данную методологию стоит принять во внимание при разработке соответствующих алгоритмов.

Методология включает в себя следующие шаги:

1) Сформировать набор данных;

2) Обработать текст;

3) Построить признаковое описание;

4) Отобрать информативные признаки;

5) Обучить;

6) Классифицировать.

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

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

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

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

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

На пятом этапе нужно построить модель классификаций, использую разработанный пассивно-агрессивный алгоритм [7].

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

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

Таблица 5Результаты внешнего тестирования методологии определения демографических атрибутов, разработанной в ИСП РАН

Атрибут	Количество пользователей	Количество сообщений	Точность
Пол	17900	1147000	83%
Возраст	10800	697000	74%
Политические взгляды	800	53000	76%
Семейное положение	1900	202000	89%

Полученная точность определения атрибута довольно высока, если сравнивать с другими исследованиями, например, по определению пола пользователя в социальной сети Twitter: AlZamaletal показало 80,2% [8], а Rao et al 72% [9].

4.4 Группировка данных на основе общих черт

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

Каждый полученный набор данных необходимо обработать отдельно.

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

Определим операции полноты вхождения a -> b (1) и сравнения a <-> b (2).

, (1)

где d - это количество удаления;

r - это количество замен;

s - это количество транспозиций;

len(a) - вычисление длины аргумента.



где dist(a, b) - вычисление расстояния Дамерау-Левенштейна;

fit(i) - возвращение индекса слова строки b, которое поставлено в соответствии слову a[i].

Последняя формула не учитывает порядок слов, знаки препинания и прочие символы (только буквы и цифры). Вначале слова все строк сравниваются попарно, далее используя алгоритм Куна-Манкерса необходимо поставить каждому слову строк a поставить слово строки b, если сумма схожести максимальна из всех пар.

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

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

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

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

Для подобных вычислений подойдут только те пользователи, которые имеют в друзьях более 10 людей с указанием возраста. Далее необходимо разбить полученное количество друзей на группы, основываясь на дне рождения, однако объединять стоит в группы, считая не сначала года, а с осени. Таким образов получатся 15-ти месячные интервалы с 12-ти месячными шагами. Следовательно, данный пользователь скорее всего имеет схожий возраст с пользователя в наибольшей группе.

Подобный алгоритм более точно можно описать с помощью формул. Для этого понадобиться выразить формулу связанности профиля i в интервале y (3).

, (3)

где F₀ - это множество друзей профиля, возраст которого нужно узнать;

F_i - это множество друзей любого профиля;

F_i,y - это множество друзей пользователя, у которых указана дата рождения в годовом интервале y.

Далее необходимо выразить по всем профилям ненормированный коэффициент связанности в годовом интервале y (4).

, (4)

Наконец, получаем итоговую формулу по определению года рождения искомого пользователя (5).

, (5)

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

Выводы

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

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

Далее собранные данные необходимо разработать. Существует большое количество методов по обработке данных, которые разработаны для решения разных задач. К решению задач, поставленных в данной работе, наиболее подходящим оказался метод определения демографических атрибутов, который был описан ИСП РАН.

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

5. Разработка поискового программного комплекса

5.1 Общие сведения

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

Рис. 4. Распределенная архитектура программного комплекса

5.2 Разработка клиентского приложения

5.2.1 Описание базового функционала

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

Для решения приведенных задач необходимо будет разработать следующий функционал [10]:

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

– Инициализация запроса. Данная задача подразумевает формирование JavaScript Object Notation (JSON) пакета данных с включением указанных пользователем параметров поиска, а также настройку параметров запроса для каждой из выбранных социальных сетей.

– Отправка запроса и ожидание ответа. Взаимодействие с сервером, как уже ранее описывалось, будет происходить с использованием технологии сокетов, далее потребуется написать логику ожидания ответа с данными.

– Отображение ответа с сервера. Данная задача подразумевает разработку логики для обработки ответа от сервера, так как возможно три варианта: по указанным параметрам не удалось найти ни одного профиля, удалось найти массив профилей и удалось найти конкретный профиль. Получить последний вариант составляет малую вероятность, так как большинство пользователей социальных сетей либо не указывают номер мобильного телефона, либо скрывают его от всех настройками приватности, а ФИО (как наиболее часто используемый параметр поиска) не является уникальным идентификатором человека (существует много людей с одинаковыми именем и фамилией), к тому же пользователи могут указать в своем профиле недостоверную информацию, что также снижает шанс найти конкретного человека. В большинстве случаев будет возвращаться массив профилей, который необходимо отобразить пользователю, в отображение каждого конкретного профиля необходимо включать "аватар" (при наличии), ФИО и дату рождения (при наличии), чтобы пользователь по ключевым параметрам имел возможность идентифицировать нужный ему профиль. Далее по клику на определенный профиль, приложение должно сформировать запрос с идентификатором конкретного профиля.

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

– Настройки приложения. Как и в случае с историей поиска данная задача не обязательна к исполнению для первого релиза, однако ее реализация позволит пользователю произвести необходимые для уверенности в приложении настройки: установки пароля на доступ к приложению (с помощью pin-кода, технологии touch id или face id), написание отзыва на приложение и в поддержку, изменение цветовой схемы и т.д.

5.2.2 Прототипирование интерфейса

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

В процесс прототипирования обычно входят следующие шаги [11]:

1) Определение начальных требований;

2) Дизайн первого варианта прототипа интерфейса;

3) Демонстрация полученных результатов заказчику и конечному пользователю и обработка полученных отзывов;

4) Доработка первого варианта прототипа с учетом замечаний и предложений.

Шаг по определению начальных требований был выполнен в пункте «4.2.1 Описание базового функционала». По результатам второго шага была разработана первая версия прототипа (рис. 5).

Рис. 5. Первый вариант прототипа клиентского приложения

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

Исходя из вышеописанной проблемы был разработан конечный прототип (рис. 6). Конечно, в коммерческих проектах данный процесс претерпевает несколько итераций.



Рис. 6. Итоговый вариант прототипа клиентского приложения

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

5.2.3 Написание базовых классов и функций

Для решения поставленных задач в разработке модели сервиса понадобится реализовать следующие классы и функции [12]:

1) Контроллер SavedProfilesTableViewController, который должен отвечать за отображение данных сохраненных профилей в таблице. Должен содержать в себе следующий базовый функционал:

a. Отображение базовой информации профилей из массива в отдельных ячейках;

b. Удаление сохраненных профилей;

c. Сортировка сохраненных профилей;

d. Переход на окно детальной информации профиля по нажатию на конкретную ячейку;

e. Поиск по сохраненным профилям;

f. Фильтрация по общим параметрам (Например, стране проживания);

g. Переход на окно поиска человека по параметрам по нажатию на кнопку поиска;

h. Переход на окно настроек приложения по нажатию на кнопку настроек.

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

a. Авторизация в определенных социальных сетях;

b. Установка пароля на вход в приложение и активация входа по touch id или face id;

c. Активация автоматического логирования;

d. Переход на страницу созданного приложения в AppStore для написания отзыва после нажатия на кнопку «Оставить отзыв»;

e. Переход в почтовое приложение для отправки сообщения с прикрепленным лог-файлом в поддержку после нажатия на кнопку «Написать в поддержку».

3) Контроллер SearchingScrollViewController, на котором пользователь сможет инициализировать поисковой запрос с указанными параметрами. Должен содержать в себе следующий базовый функционал:

a. Проверка введенных параметров на достаточность (поиск только по имени с высокой долей вероятности будет не успешным);

b. Формирование асинхронных запросов из указанных пользователем параметров, а также данных, которые требуются API социальных сетей;

c. Активирование окна ожидания ответа без блокирования интерфейса приложения;

d. Отображение полученных данных профилей от социальных сетей с возможностью выбрать конкретный профиль при не однозначном ответе и с возможностью сохранить результат поиска при однозначном.

4) Менеджер SocketIOManager, который должен позволять работать с технологией открытия сокетов. Должен содержать в себе следующий базовый функционал:

a. Установление соединения с сервером при инициализации запроса;

b. Разрыв соединения с сервером при отмене запроса или его успешном завершении;

c. Отправка сформированного пользователем запроса;

d. Ожидание ответа от сервера.

5) Менеджер DataManager, который должен отвечать за обработку полученных данных и их преобразование в удобный для последующего использования формат. Должен содержать в себе следующий базовый функционал:

a. Извлечение необходимых данных из JSON-пакета;

b. Формирование полученных данных в структуру ProfileItem или массив структур.

6) Структура ProfileItem, которая должна содержать все необходимые атрибуты профиля, которые можно использовать в будущем.

5.2.4 Подключение библиотек

Ускорить и упростить разработку описываемого сервиса поможет использование следующих библиотек:

– UIKit - встроенный фреймворк для работы с элементами интерфейса;

– Foundation - встроенный фреймворк с необходимыми для реализации типами данных и большим набором функционала;

– Socket.io - библиотека с поддержкой технологии сокетов для взаимодействия с сервером;

– Facebook SDK - фреймворк "Facebook" для авторизации и реализации запросов [13];

– VK SDK - фреймворк "ВКонтакте" для авторизации и реализации запросов [14];

– Instagram SDK - фреймворк "Instagram" для авторизации и реализации запросов [15];

– OK SDK - фреймворк "Одноклассники" для авторизации и реализации запросов [16].

Библиотеки, которые не встроены в IDE Xcode, следует подключать к проекты с использованием технологии Cocoapods, так как является наиболее быстрым и гибким способом.

5.2.5 Разработка интерфейса

На основе технического задания, приведенных базовых функций и разработанного итогового прототипа был спроектирован интерфейс клиентского приложения (рис. 7).

Разработанный итоговый интерфейс имеет некоторые отличия от представленного выше прототипа (рис. 6) по причине того, что некоторые элементы интерфейса (например, окно отображения найденных профилей) следует реализовывать в коде или в качестве отдельного xib-файла [17]. Стоит также отметить, что при усложнении пользовательского интерфейса следует разбивать крупные разделы на подразделы, расположенные в отдельных storyboard, с навигацией через Navigation Controller.

...