Рис. 7. Интерфейс клиентского приложения

Выводы

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

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

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

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

5.3 Разработка сервера взаимодействия

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

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

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

– Прослушивание установленного порта по HTTP протоколу;

– Подключение поисковой программы;

– Подключение клиентских приложений;

– Обработка трафика и его передача между модулями.

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

5.3.2 Написание программного кода

Серверную логику рекомендуется разрабатывать на основе фреймворка Node.js [18], что позволит использовать уже разработанные функции для подключения/отключения устройств и передачу данных. Логика подключения и отключения следует реализовывать на основе ключевых слов, например, “connection” и “disconnection”. Работу сервера следует логировать, что позволит не только следить за нагрузкой путем анализа данных, но и вовремя определить возникший при взаимодействии баг, если таковой будет допущен.

Выводы

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

5.4 Разработка поисковой программы

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

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

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

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

– Обработка запроса на поиск такая, как сериализация JSON-данных в читаемый формат (например, ранее определенной структуры Account).

– Создание параллельных поисковых запросов для каждой отдельной социальной сети. Необходимо сформировать пакеты JSON-данных в соответствии с API ресурса назначения [19].

– Обработка ответа. Данные, которые были получены в результате поиска, необходимо объединить в единый пакет.

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

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

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

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

1) Модель SocketIOManager, которая будет отвечать за взаимодействие с библиотекой Socket.io.

2) Модель ServerInteractionManager, которая будет отвечать за отправку запросов и получение ответов. Для данной модели следует разработать следующие:

a. Получение пакетов данных от сервера;

b. Установление сессии с сервером;

c. Отправка обработанных данных.

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

a. Подготовка JSON-пакетов как для сервера, так и для социальных сетей;

b. Обработка пакетов данных;

c. Проверка полученных на данных на предмет единственного или множественного ответа по поиску.

4) Модели FacebookManager, VKManager, InstagramManager и OKManager, которые должны отвечать за формирование и отправку запросов на поиск в соответствии с API ресурсов назначения.

5) Структура Account, которая потребуется для удобства использования данных о каком-либо профиле.

6) Модель Session, которая потребуется для конфигурации необходимых параметров для установления сессии.

7) Модель ErrorHandling, которая будет отвечать за обработку ошибок, используя Throwing технологию, что необходимо для обеспечения гибкости и отказоустойчивости [21].

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

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

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

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

– Alamofire, которая позволит взаимодействовать с API социальных сетей посредством HTTP протокола верхнего уровня и TCP протокола транспортного уровня [22].

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

Выводы

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

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

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

6. Средства обеспечения информационной безопасности

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

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

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

Так как на данном этапе модель сервиса по поиску информации человека в интернете не подразумевает разработку системы авторизации пользователей, то для ограничения доступа в приложение следует реализовать локальную авторизацию. Для этой задачи можно использовать встроенную в среду разработку IDE Xcode библиотеку GenericKeychain и внешний фреймворк CryptoSwift [23]. Первый фреймворк поможет взаимодействовать с Keychain через программный код по названию сервиса и какого-либо уникального идентификатора пользователя (например, номер мобильного телефона), второй обеспечит возможность использовать криптографические алгоритмы для шифрования пароля. Стоит отметить, что Keychain не шифрует хранимые данные по умолчанию, и, если его взломают, то пароль будет скомпрометирован, поэтому следует озаботится шифрованием самостоятельно. Подобная связка преобразует текст пароля в набор символов. Следовательно, формула по созданию хэша пароля получилась следующая: Уникальная строка (соль) + Идентификатор + Пароль, шифруемая, например, алгоритмом SHA-2.

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

Система шифрования рабочей памяти, названная Data Protection, которую разработали в компании Apple для защиты хранимых данных, имеет четыре слоя безопасности, так называемые FileProtectionType:

1) Защита отключена (none);

2) Включена полная защита (complete);

3) Только к данным открытых файлов есть доступ (completeUnlessOpen);

4) Только к данным при разблокированном устройстве есть доступ (completeUntilFirstUserAuthentication).

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

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

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

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

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

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

Прототипы программных компонентов запускались на реальных устройствах (не симуляторах): MacBook Pro Retina 15-inch Late 2013 (с ОС MacOS High Sierra version 10.13.4) и iPhone 6 Plus A1524 (с ОС iOS 11.3).

7.2 Оценка эффективности прототипа клиентского приложения

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

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

– 590.32 мс. заняла инициализация приложения,

– 43.15 мс. занял запуск приложения,

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

– 5.39 с. Заняли установка сессий с серверами социальных сетей и прохождение авторизаций,

– 28.43 с. заняли формирование запроса и взаимодействие с серверами.

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

Другим измеренным показателем являлась нагрузка CPU, таким образом проведенные итерации показали, что пиковый показатель нагрузки соответствует 28%. Самым трудоемким процессом оказалась инициализация табличных контроллеров (рис. 8).

Рис. 8. Измерение нагрузки на CPU

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

Рис. 9. Измерение занятой оперативной памяти

В случае с мобильным устройство любые процессы влияют на заряд аккумулятора. Конечно, данный показатель наиболее показателен для игр, одна расчеты влияния в случае с разработанным прототипом также были произведены. Результаты замеров (рис. 10) показали среднее влияние приложения в момент инициализации табличных представлений на заряд аккумулятора. О точности производимых замеров тяжело судить в том числе и из-за не оригинальности самого аккумулятора, к тому же его объем деградировал до 80%.



Рис. 10. Измерение влияния на заряд аккумулятора

Также для оценки эффективности принятых решений при разработке модели мобильного приложения было измерено использование сети (рис. 11). Полученные результаты измерения метрики показали, что средняя скорость соединения мобильного клиента с удаленными серверами социальных сетей была в среднем 3.8 КБ/с (или 30.4 Кбит/с) при получении и 1.5 КБ/с (или 12 Кбит/с) при отправке. Один такой проход показал, что приложение получает в среднем 11.5 КБ данных, а отправляет около 9.4 КБ. Для замеров использовалось беспроводное соединения с интернетом на частоте 5 ГГц.

Рис. 11. Измерение сетевой нагрузки

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

7.3 Оценка эффективности поисковой программы

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

Проведенные итерации показали следующие усредненные значения скорости:

– 243.50 мс. заняла инициализация программы,

– 208.41 мс. занял запуск.

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

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

Рис. 12. Измерение нагрузки на CPU

Следующим параметром для измерений стала занятая оперативная память. Проанализировать сколько будет использоваться оперативной памяти в реальных условиях на данном этапе невозможно, однако по графику (рис. 13) можно заметить, что один запрос занял около 20.5 МБ.

Рис. 13. Измерение занятой оперативной памяти

Наконец, последней метрикой стала измерение сети. Результаты одной итерации отображены на рисунке 14. По ним видно, что при запросе информации у удаленного сервера скорость соединения была около 3.6 КБ/с (или 28,8 Кбит/с) при получении и около 1 КБ/с (или 1 Кбит/с) при отправке. За один проход программа получила 5.2 КБ данных и отправила 2.4 КБ.

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

Рис. 14. Измерение сетевой нагрузки

Выводы

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

Заключение

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

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

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

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

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

Список использованных источников

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

1) iOS Client Server Communication. URL: https://www1.in.tum.de/lehrstuhl_1/home/98-teaching/tutorials/540-ios14intro-client-server-communication (дата обращения 05.12.2017).

2) Apple Developer Documentation. URL: https://developer.apple.com/documentation/ (дата обращения 10.01.2018).

3) Socket.io v2.0.3 Documentation. URL: https://socket.io/docs/ (дата обращения 15.01.2018).

4) Model View Controller template. URL: https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html (дата обращения 16.01.2018).

5) Антон Коршунов. Задачи и методы определения атрибутов пользователей социальных сетей. Труды 15-й Всероссийской научной конференции «Электронные библиотеки: перспективные методы и технологии, электронные коллекции» - RCDL'2013.

6) Francois Fleuret. Fast Binary Feature Selection with Conditional Mutual Information. 2004. С. 1531-1555.

7) Koby Crammer, Ofer Dekel, Joseph Keshet, Shai Shalev-Shwartz, Yoram Singer. Online Passive-Aggressive Algorithms. 2006. С. 551-585.

8) Faiyaz Al Zamal, Wendy Liu, Derek Ruths. Homophily and Latent Attribute Inference: Inferring Latent Attributes of Twitter Users from Neighbors. 2012. С. 320.

9) Delip Rao, David Yarowsky, Abhishek Shreevats, Manaswi Gupta. Classifying Latent User Attributes in Twitter. 2010. С. 200.

10) Stanford University. Developing iOS 11 Apps with Swift. URL: https://itunes.apple.com/lv/course/developing-ios-11-apps-with-swift/id1309275316 (дата обращения 20.01.2018).

11) Plymouth University. iOS Development in Swift. URL: https://itunes.apple.com/us/course/ios-development-in-swift/id950659946 (дата обращения 25.01.2018).

12) Apple. The Swift Programming Language (Swift 4.1). Cupertino: Apple inc., 2018. С. 521.

13) Facebook SDK for iOS. URL: https://developers.facebook.com/docs/ios (дата обращения 02.02.2018).

14) Вконтакте SDK for iOS. URL: https://vk.com/dev/ios_sdk (дата обращения 08.02.2018).

15) Instagram API. URL: https://www.instagram.com/developer/ (дата обращения 12.02.2018).

16) Одноклассники SDK for iOS. URL: https://apiok.ru/dev/sdk/ios (дата обращения 20.02.2018).

17) Apple. Using Swift with Cocoa and Objective C (Swift 4.1 beta). Cupertino: Apple inc., 2018. C. 66.

18) Node.js v7.10.1 Documentation. URL: https://nodejs.org/docs/latest-v7.x/api/ (дата обращения 19.01.2018).

19) The Graph API. URL: https://developers.facebook.com/docs/graph-api (дата обращения 26.02.2018).

20) Matthew Mathias, John Gallagher. Swift Programming: The Big Nerd Ranch Guide. Atlanta: Big Nerd Ranch LLC, 2015. C. 480.

21) Janie Clayton,э Alexis Gallagher,э Matt Galloway,э Ben Morrow,э Cosmin Pupaza,э Steven van Impe. Swift Apprentice Third Edition: Beginning Programming with Swift 4. Rockingham: Razeware LLC, 2017. C. 436.

22) Alamofire v4.6.0 Documentation. URL: https://github.com/Alamofire/Alamofire/tree/master/docs (дата обращения 13.01.2018).

23) Matthijs Hollemans,э Fahim Farook. iOS Apprentice Sixth Edition: Beginning iOS development with Swift 4. Rockingham: Razeware LLC, 2017. C. 774.

24) Derek Selander. Advanced Apple Debugging & Reverse Engineering. Rockingham: Razeware LLC, 2017.

Размещено на Allbest.ru

...