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

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

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

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

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

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

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

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

Выводы по второй главе

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

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

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

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

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

При разработке модели «поиска кратчайшего пути», была определена эффективность его работы в контексте среды социальной сети Twitter. Отмечена высокая скорость обработки класса запросов типа POST.

Генерация графа из 1 миллиарда вершин заняла около 2 часов на кластере Amazon EC2 со 100 рабочими узлами типа m1.large. 4. Определение демографических атрибутов пользователей. При заполнении своего профиля в социальной сети пользователи зачастую по ошибке или преднамеренно не заполняют некоторые поля либо дают ложную информацию о фактах своей биографии, интересах и предпочтениях.



3. Программная реализация алгоритма моделирования распространения информации в социальной сети «Twitter»

3.1 Описание и анализ технологий для реализации задачи моделирования алгоритма

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

Среди различных форм организации и предоставления таких услуг, к которым относятся Saas (Software as a Service), Paas (Platform as a Service) и Iaas (Infrastructure as a Service), последняя является наиболее гибким решением, позволяющие разворачивать распределены «виртуальные офисы» и формировать программное окружение аналогичное тому, которое установлено на персональном компьютере или локальном сервере. Фундаментальный сдвиг в самой природе обработки информации. Она смещается в сторону модели Utility Computing, то есть предоставление вычислительных ресурсов по принципу коммунальных услуг, предполагает, во-первых, выполнение большинства вычислительных задач в специализированных дата-центрах, и, во-вторых, доставку полученных результатов по каналам Internet аналогично электрической энергии.

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

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

Традиционные архитектуры облачных систем предусматривают их построение на базе многоуровневой сетевой инфраструктуры виртуальных центров обработки данных (ЦОД) [8] и поддержки в виде программной платформы с набором сервисов. Типичная архитектура любого облачного ЦОД имеет иерархическую структуру, состоящую из 3 основных уровней:

Уровня ядра (Core). На этом уровне работают маршрутизаторы или коммутаторы 3 уровня, которые составляют основу всей сети дата-центра с высокоскоростными портами (10/40/100 GbЕ) для маршрутизации потоков между WAN и сети дата-центра.

Уровня агрегации (Aggregation или Distribution). На этом уровне также функционируют коммутаторы 3 уровня, основное назначение которых - распределение нагрузки между локальными сетями дата-центра.

Уровня доступа (Access). На этом уровне располагаются конечные точки (сервера, рабочие станции и др.) И сетевое оборудование, связывает конечные точки с уровнем агрегации. На уровне доступа функционируют кластера дата-центров, состоящих из множества физических серверов и большого количества виртуальных машин на каждом из них. На этом же уровне чаще всего располагается общая сеть хранения данных SAN (Storage Area Network). Группа, состоящая из взаимосвязанных компонентов хранения данных, вычислительных и сетевых ресурсов, которые работают совместно на уровне доступа, чтобы предоставить сервис или приложение клиенту называется точкой доставки или POD (Point of delivery).

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

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

Компоненты низкого уровня - сервера, которые объединяются в кластер. На каждом физическом сервере функционирует несколько виртуальных машин, то есть на одном физическом сетевом интерфейсе есть несколько виртуальных, обменом между которыми управляет программный компонент гипервизор (Virtual Machine Monitor / Hypervisor).

Облачные IT-инфраструктуры учебного заведения включают в себя следующие компоненты:

· ядро облака - ядро всей IT-инфраструктуры;

· персональные компьютеры в лабораториях, являются узлами облака.

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

· социальная сеть для коммуникаций и поиска контактов;

· обменник идеями и проектами (онлайн-платформа по поиску работы);

· рабочее место для планирования и координации работы;

· база примеров коопераций и проектов, которая прогнозирует успех и дает советы.

Главным примером портала онлайн-общество GeoNet [15], которое объединяю разработчиков, исследователей, студентов, просто всех заинтересованных в развитии географически информационных технологий. Такое общество, направленное на информационные технологии и компьютерные науки, может быть даже более масштабным. В то же время, есть цель развить функционал профессиональных социальных сетей как LinkedIn [16] для построения резюме участников, добавить функциональность по трудоустройству на примере фрилансерских платформы oDesk [17], обеспечить облачный проектной и конфигурационный менеджмент как в YouTrack [18], так GitHub [19] соответственно.

Кроме того, уверенность в безопасности и приватности базируется на примере Telegram Messenger [1]. Конечно, все указанные веб-ресурсы являются лишь примерами и окончательный функционал должен соответствовать обобщенной группе участников: ученые и практики. Привлечение участников и определение приоритетов функций планируется через конференции, семинары (вебинары) и другие мероприятия.

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

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

В качестве хранилища было выбрано решение от Firebase, которое позволяет пользователю размещать файлы на удаленных серверах с помощью клиента или с использованием веб-интерфейса через браузер. При установке клиентского программного обеспечения Firebase на компьютере создается папка, синхронизированная с сервисом. Хотя главный акцент технологии делается на синхронизации и обмене информацией, Firebase ведёт историю загрузок, чтобы после удаления файлов с сервера была возможность восстановить данные [14]. Также ведется история изменения файлов, которая доступна на период последних 30 дней, кроме этого доступна функция бессрочной истории изменения файлов «PackRat».

История изменения файлов ведется по принципу diff-кодирование, чтобы сэкономить место, занимаемое файлами. В истории изменения записывается только отличие одной версии файла от другой. Файлы, загруженные через клиента, не имеют ограничения на размер, но файлы, загруженные через веб-интерфейс, ограниченные 300 МБ. Есть также возможность выкладывать файлы для общего доступа через папку «Public», что позволяет использовать сервис в качестве файлообменника. В версиях 0.8.x также появилась возможность предоставления в общий доступ любой папки в «My Firebase» для дальнейшего доступа через так называемый «shareable link», то есть через веб-интерфейс. Для совместной работы над проектами сервис имеет возможность создания «Shared» папок для общего доступа лиц, имеющих разные учетные записи на сервисе. Доступна автоматическая синхронизация файлов и папок и хранения версий с возможностью отката.

Для использования вышеупомянутых технологий от Firebase в приложениях был использован Firebase Cоre API. Защищенное соединение устанавливается с помощью токена и требует подтверждения от пользователя при использовании сервиса в приложении впервые.

Чтобы избежать постоянных подтверждений при передаче или загрузке файла, токен сохраняется в SharedPreferences [3] классе программы. Для работы синхронизации фоне был использован интерфейс AssyncTask [6]. Он дает возможность асинхронно выполнить код, не нарушая при этом работу потока графического интерфейса и рекомендован производителем для использования в задачах, требующих время исполнения не более 20-30 секунд для достижения оптимальной производительности интерфейса. Этот же интерфейс используется также в методах загрузки и закачки программы.

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

Облачные операционные системы представляют собой среду для выполнения программного кода на различных языках программирования. Corezoid обеспечивает поддержку JavaScript и Erlang.

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

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

В Corezoid API существует несколько способов сохранять настройки пользователей и информацию в зависимости от их назначения и использования.

SharedPreferences - класс для хранения настроек и небольших объемов информации другого типа [7]. Получить доступ к нему можно с любого класса, связанного с Activity или View. Минус - завязан на графический интерфейс и не подходит для хранения больших объемов информации. Класс SharedPreferences по умолчанию используется в классе PreferenceActivity для всех его параметров. В приложении от SHome SharedPreferences используется для хранения веб токена сервиса Firebase, настроек и лога системы при сбое. Пример использования:

SharedPreferences prefs = context.getSharedPreferences (FIREBASE_NAME, 0);

SharedPreferences.Editor edit = prefs.edit (); edit.putString ("KEY_TOKEN_PAIR", tokenPair) edit.commit ();

SQL Сonnector - класс, для развертывания и доступа к встроенной в систему Android базы данных SQL lite

Используется для хранения и последующей обработки больших объемов информации в базе SQL типа. В приложении SHome используется для хранения истории прогноз погоды, показаний с датчиков. Временные файлы или TempFile - файлы, которые будут удалены после закрытия программы. Используются для хранения временной информации.В системе SHome временные файлы используются для записи данных из БД для отправки в облачное хранилище. Также в бета-версии программы лог краш записывается во временный файл и отправляется на почту разработчиков.

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

Программа создается на языке программирования ActionScript 3 с помощью программного пакета Adobe Flash Builder 4.1 и Adobe Flash Professional CS5. Такой выбор обусловлен возможностями API Twitter и удобством интерфейса создает моего приложения благодаря технологии Adobe Flash.

Структура программы включает 10 классов, реализующих предусмотренную функциональность. Функции программы:

* Регистрация пользователя;

* Получение информации из профиля с помощью API «Twitter»;

* Отложенный постинг («Мои Заметки» > «Отложенный постинг»);

* Обработка информации с помощью «Corezoid» и «Twitter»;

* Вывод информации пользователю («База данных» > «Форма результатов»);

* Вывод информации администратору («XML База данных» > «Администратор») (рисунок 8).

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

Рисунок 8 - Схема работы приложения



3.2 Программная реализация алгоритма для серверной части системы

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

Структура стандартного сообщения выглядит следующим образом:

· Параметр;

· Действие;

· Значения.

Для ограничения возможных опций создания сообщения используется связка из private классов и статических методов для создания их объектов. То есть, программист не может создать экземпляр сообщения непосредственно, минуя статические методы, а значит и формирования сообщения с неверными параметрами исключено. Часто разработчики выносят этот функционал на графический интерфейс, однако подход по отделению логики от GUI зарекомендовал себя как более надежный, поэтому реализация была имплементирована именно таким образом.Размещено на http://www.allbest.ru/

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

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

На рисунке 9 представлена реляционная модель базы данных web-ориентированной информационной системы оценки меню пользователя, состоящая из таких сущностей как:

Рисунок 9 - Реляционная модель базы данных web-ориентированной информационной системы

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

· применимость к ориентированным и неориентированным графам;

· учёт весов на рёбрах;

· поиск как пересекающихся, так и непересекающихся сообществ;

· поиск как локальных (среди ближайших контактов пользователя), так

· и глобальных сообществ;

· низкая вычислительная сложность;

· возможность распределённой реализации в рамках вычислительной

· модели Pregel.

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

Рисунок 10 - Система обработки сообщений

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

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

Рисунок 11 - Дамп базы данных

Таким образом, элементом набора данных для каждого атрибута и языка является набор символьных строк, полученных из текстов сообщений и 2 профиля одного пользователя в Twitter, а также значение атрибута у данного пользователя в Facebook. На этапе построения признакового описания из сообщений пользователей извлекаются лингвистические признаки. Из полученных токенов строится набор признаков в виде N-грамм размером от 1 до 3 с учётом порядка токенов. Каждый тип признаков представлен двумя подтипами: с учётом и без учёта регистра символов. Итоговый вектор признаков для пользователя является бинарным, то есть содержит только информацию о наличии или отсутствии признака в его текстовых данных. Количество экземпляров одного признака игнорируется. На этапе отбора информативных признаков применяется метод, основанный на расчёте условной взаимной информации.

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

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

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

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

ER-модель базы данных, интегрированной с алгоритмом показана на рисунке 12.

Рисунок 12 - ER-модель базы данных



Алгоритмическая модель в системе Corezoid показана на рисунке 13.

Рисунок 13 - Алгоритмическая модель в системе Corezoid

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

Рисунок 14 - Главная алгоритмическая ветвь



3.3 Проектирование и разработка клиентского приложения

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

· Родной вид для операционной системы;

· Интуитивность;

· Дружелюбие к пользователю;

· Простота настроек.

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

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

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

Родной вид программы помогает пользователю быстро разобраться с интерфейсом и кроме того делает само приложение гармоничной частью той операционной системы, в которой он используется. Приложение функционирует в операционной системе Coreziod и должен соответствовать концепциям дизайна, определенным в Google. Собирательное название таких концепций - дизайн материалов или Material Design этого типа дизайна: в его рамках объекты «отвечают» пользователю тенями и реакцией на прикосновения. На первый взгляд новый концепт слишком «простой». Он плоский и многослойный. Слои обозначены тенями. Идея такая же, как в физической книги или тетради, и заключается в «перелистывании страниц». Разработчики получили возможность задавать определения угла отдельных элементов интерфейса и прорисовать тени в режиме реального времени.

«Материальный» дизайн web-ресурса характеризует жирные яркие шрифты и адаптивная «палитра», что позволяет приложениям приспосабливать свои цвета к цветовой гамме отображаемого им контента. Галерея найдет тона отраженной ней картинки, а музыкальный плеер - обложки воспроизводимого альбома. Это простые примеры того, на что способна эта самая знаменитая адаптивная «палитра» [8].

Другой ключевой особенностью Material design является отклик на касания пользователя. Нажатие кнопки анимирован. То есть, пользователь будет видеть, на какие элементы интерфейса он «нажимает». Эта возможность распространяется на все программы, страницы, меню и другие составляющие операционной системы [9].



Рисунок 15 - Пример интерфейса авторизации пользователя

Вся логика web-приложений строится вокруг классов, унаследованных от View или Activity, так как получить доступ к ресурсам приложения можно только через них или их Context классы. Однако динамично можно менять только виджеты помощью Holder-классов или заменой фрагмента на другой. Рассмотрим эти продходы в сравнении:

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

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

Создать новое Activity. Ранее, до появления Holder и Fragment, это был единственный способ для создания программного продукта. Информация с одной Activity в другое можно было передать через Intent класс, необходимый для перехода. Минус такого подхода в том, что нужно создавать трех разных Activity: для двух вариаций ориентации экрана и для планшета. Также явным недостатком является перерисовка всего экрана вместо его части. Google рекомендует использовать Activity только в том случае, когда невозможно сделать те же операции с фрагментами.

Все три подхода используются в построении комплексных программ и их элементов навигации. Для переключения между экранами используется Navigation Drawer шаблон или просто боковое меню. Как элемент навигации боковое меню найболее часто используется в приложениях с несколькими разнотипными информационными экранами [2]. В формате XML - это просто тип разметки с встроенным учетной выводом сокращений-переходов.

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

3.4 Руководство пользователя

Для начала использования сервиса следует ввести в адресной строке браузера адрес сайта mob.writer-com.com.

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

На экране Вы увидите фирменный логотип Twitter виде птицы синего цвета. Для перехода к формам ввода сообщений нажмите на данный логотип.

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

Если Вы нажмете кнопку «Отмена», то осуществите возврат на главную страницу сервиса mob.writer-com.com.

Вы также можете восстановить свой пароль от Twitter, для чего достаточно нажать кнопку «Забыли пароль?». На следующем шаге система предложит ввести Ваш адрес электронной почты, куда будет отправлен пароль. После авторизации в Twitter перед Вами отобразится страница с формами, где Вы можете ввести сообщения, которые будут опубликованы.

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

После того, как Вы введете весь медиа-план сообщений, следует нажать кнопку «Публиковать», чтобы инициализировать процесс публикации и отслеживания постов в Twitter (рисунок 16).

Рисунок 16 - Ввод сообщений постов

Следить за статистикой работы системы (рисунок 17) представляется возможным посредством статистической панели Corezoid.

Для этого перейдите на сайт Corezoid.com, авторизируйтесь.

Рисунок 17 - Список задач

Далее Нажмите на кнопку «Dashboard» (рисунок 18) и в режиме реального времени отслеживайте прогресс публикации Вашего медиа-плана.

Рисунок 18 - Прогресс публикации медиа-плана

Общая модель работы системы отображена на диаграмме активности (рисунок 19).



Рисунок 19 - Диаграмма активности

Выводы по третьей главе

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

Способы интерракции реализованы с целью создания лучшего опыта пользователя. Навигация между частями приложения выполняется посредством использования шаблона Navigation Drawer от Google. Результат соответствует представлениям заказчика о системе и согласован в технической документации.

Разработана реляционная модель баз данных web-ориентированной информационной системы как базовый компонент облачных операционных систем.

Разработана алгоритмическая модель в системе Corezoid как инструмент проектирования бизнес-процессов для обработки запросов.

Разработан интерфейс системы как экран взаимодействия с пользователем.

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

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



4 Оценка эффективности реализованного метода и алгоритма распространения информации

4.1 Оценка статистических выходных данных

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

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

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

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

Пользователю доступны фильтры, чтобы корректировать доступ к его личным данным («Приватность).

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

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

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

Рисунок 20 - Панель администрирования

Также в приложении доступна общяя информация о всех пользователей, установивших приложение. Это категория «Мои друзья», где доступны функции просмотра информации всех друзей пользователя, друзей на сайте, а также просмотр заявок в друзья.

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

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

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

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

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

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

4.2 Описание входных данных

На первом этапе исследования проверим характеристики скорости работы системы, подставив случайные значения в расчетные формулы примененных алгоритмов метода динамического программирования, имеющего сложность O(w*n). Полученные данные отобразим в виде графов (рисунок 21).

Рисунок 21 - Данные для расчета производительности

Если необходимо найти расстояние от одной вершины к другим или ко всем вершинам графа и веса всех ребер графа является положительными или равны нулю, то наиболее эффективным оказывается алгоритм Дейкстры со временем работы О (m lgn) [20].

Если же веса ребер могут быть отрицательными, то необходимо применять алгоритм Беллмана-Форда, время работы которого О (nm). Если необходимо найти расстояния между всеми парами вершин графа, граф является разряженным и все ребра имеют неотъемлемые веса, то можно выполнить n раз алгоритм Дейкстры. Если же граф является разряженным, но в нем могут быть ребра с отрицательными весами, то необходимо использовать алгоритм Джонсона. Если необходимо найти расстояния между всеми парами вершин, веса ребер могут быть отрицательными и граф не является разряженным (m стремится к n2), то необходимо использовать алгоритм Флойда-Уоршола. Ни один из приведенных алгоритмов не может быть применен для графов, которые содержат негативные циклы. Однако алгоритм Беллмана-Форда (как и алгоритм Джонсона), а также алгоритм Флойда-Уоршола могут выявить такие циклы.

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

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

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

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

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

Опубликуем в аккаунте твиттер посты со следующим содержанием: «1», «2», «3». Пост с текстом «2» будет опубликован, когда кто-либо «лайкнет» пост 1. Пост с текстом «3» будет опубликован, когда кто-либо лайнет пост 2.

4.3 Описание результатов эксперимента

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

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

* загрузить базу данных XML с сервера на локальный компьютер;

* импортировать XML в Microsoft Access, используя штатный механизм Access;

* с помощью средств Microsoft Access сделать выборку;

* обработать выборку с помощью Microsoft Access или Microsoft Excel.

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

В общем информация внутри XML базы данных хранятся в таком виде:

<UserInfo>

<Код> 1 </ Код>

<id_vk> 1702950 </ id_vk>

<Name> Батырбек </ Name>

<SecondName> Айналимов </ SecondName>

<BD> 27.05.1990 </ BD>

<Sex> 1 </ Sex>

<Contry> Россия </ Contry>

<City> Волжский </ City>

<Param1> 1 </ Param1>

...

<Param20> 5 </ Param20>

</ UserInfo>

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

Таким образом конечный XML файл выглядит следующим образом:

<? xml version = "1.0" encoding = "UTF-8"?>

<dataroot xmlns: od = «urn: schemas-microsoft-com: officedata» xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance» xsi: noNamespaceSchemaLocation = «XML2.xsd» generated = " 2012-05-08T00: 20: 51 ">

<o>

<Код> 1 </ Код>

<i> 1702950 </ i>

<n> Батырбек </ n>

<s> ч </ s>

<b> 1990-05-27 </ b>

<c> Россия </ c>

<t> Вожский </ t>

<p> 10101001011101010135 </ p>

</ o>

</ dataroot>

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

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

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

Важно понимать, что репрезентативность выборки и ошибка выборки - разные явления. Репрезентативность, в отличие от ошибки никак не зависит от размера выборки.

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

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

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

Выборки делятся на два типа:

* Вероятностные

* Невероятностные

1. Вероятностные выборки

1.1 Случайная выборка (простой случайный отбор). Такая выборка предполагает однородность генеральной совокупности, одинаковую вероятность доступности всех элементов, наличие полного списка всех элементов. При отборе элементов, как правило, используется таблица случайных чисел.

1.2 Механическая (систематическая) выборка. Разновидность случайной выборки, упорядоченная по какому-либо признаку (алфавитный порядок, номер телефона, дата рождения и т.д.). Первый элемент отбирается случайно, затем, с шагом 'n' отбирается каждый 'k'первый элемент. Размер генеральной совокупности, при этом - N = n * k

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

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

2. Невероятностные выборки. Отбор в такой выборке осуществляется не по принципам случайности, а по субъективным критериям - доступности, типичности, равного представительства и т.д.

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

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

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

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

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

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

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

* Размер генеральной совокупности. Обозначать его как А.

* Размер выборки. Обозначать его как В.

* Доля признаки (вариативность). Ожидаемая доля признаки, для которого рассчитывается ошибка. Обозначать ее как С.

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