close

Вход

Забыли?

вход по аккаунту

Абашин Александр Александрович. Информационная технология выявления виртуальных сообществ и сбора сообщений виртуальной социальной сети «Facebook»

код для вставки
АННОТАЦИЯ
ВКР 59 с., 26 рис., 2 табл., 12 источников, 1 прил.
ИНФОРМАЦИОННАЯ
ТЕХНОЛОГИЯ,
СБОР
ДАННЫХ,
PYTHON,
СОЦИАЛЬНЫЕ СЕТИ, СОЦИАЛЬНЫЙ ГРАФ.
Выпускная квалификационная работа посвящена разработке прототипа
информационной технологии сбора сообщений виртуальной социальной сети
«Facebook».
В первой главе проводится анализ предметной области, выбираются методы и
средства разработки прототипа, формируются функциональные требования к
разрабатываемой технологии.
Во второй главе описывается структура и принцип функционирования
прототипа: выбирается СУБД, описывается структура базы данных, и обеспечение
надежности и безопасности мобильной информационной системы. В третьей главе
представлены общие алгоритмы функционирования технологии: описываются
алгоритмы функционирования технологии, разрабатывается пользовательский
интерфейс
веб-приложения
информационной
технологии
сбора
сообщений
виртуальной социальной сети «Facebook».
В заключении сделаны основные выводы по выпускной квалификационной
работе.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
6
1 АНАЛИЗ ПРОБЛЕМЫ ВЫЯВЛЕНИЕ ВИРТУАЛЬНЫХ СООБЩЕСТВ И СБОРА
СООБЩЕНИЙ ВИРТУАЛЬНОЙ СОЦИАЛЬНОЙ СЕТИ
7
1.1 Анализ предметной области задачи выявления виртуальных сообществ и сбора
сообщений виртуальной социальной сети «Facebook»
8
1.2 Анализ существующих аналогов технологии выявления виртуальных сообществ
и сбора сообщений виртуальной социальной сети «Facebook»
11
1.3 Постановка задачи: выявления виртуальных сообществ и сбора сообщений
виртуальной социальной сети «Facebook», разработка функциональных и
нефункциональных требований
2
ПРОЕКТИРОВАНИЕ
ПРОТОТИПА
11
ТЕХНОЛОГИИ
ВЫЯВЛЕНИЯ
ВИРТУАЛЬНЫХ СООБЩЕСТВ И СБОРА СООБЩЕНИЙ ВИРТУАЛЬНОЙ
СОЦИАЛЬНОЙ СЕТИ «FACEBOOK»
17
2.1 Выбор принципов функционирования технлогии ыявления виртуальных
сообщств и сбора сообщений виртуальной социальной сети «Facebook»
14
2.2 Проектирование базы данных информационной технологии выявления
виртуальных сообществ виртуальной социальной сети «Facebook»
23
2.3 Обеспечение целостности и защищенности информации в базе данных
информационной технологии выявления виртуальных сообществ и сбора
сообщений участников виртуальной социальной сети «Facebook»
28
3 РАЗРАБОТКА ПРОТОТИПА ТЕХНОЛОГИИ ВЫЯВЛЕНИЯ ВИРТУАЛЬНЫХ
СООБЩЕСТВ И СБОРА СООБЩЕНИЙ ВИРТУАЛЬНОЙ СОЦИАЛЬНОЙ СЕТИ
«FACEBOOK»
31
3.1 Разработка алгоритмов функционирования прототипа
32
3.2 Разработка пользовательского интерфейса прототипа технологии выявления
вртуальных сообществ и сбора сообщений участников виртуальной социальной
сети «Facebook»
41
ЗАКЛЮЧЕНИЕ
48
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
49
ПРИЛОЖЕНИЕ А ФРАГМЕНТ КОДА
51
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
53
ВВЕДЕНИЕ
Сегодня социальные сети стали неотъемлемой частью жизни современного
человека. Крупнейшей социальной сетью мира стал «Facebook», объединив более двух
миллиардов пользователей. С каждым днем растёт число виртуальных сетевых
сообществ, создаваемых по различным темам и интересам. Многие участники
социальных сетей используют различные методы автоматизации при взаимодействии с
сообществами и остальными пользователями, применяют программные комплексы,
выполняющие рутинные задачи. Эти автоматизированные решения помогают
пользователям освободиться от ряда рутинных задач, продвигают продукт, ведут
продажу, собирают нужную информацию, уведомляют о событиях. Таким образом
задача сбора сообщений может быть расширена предварительной оценкой сообщений,
помимо основного сбора информации.
Целью данной выпускной квалификационной работы является разработка
программного комплекса для сбора сообщений в социальной сети «Facebook».
В процессе выполнения дипломной работы необходимо:
− провести анализ методов сбора данных;
− применить выбранные методы сбора данных;
− сформировать
функциональные
требования
к
разрабатываемой
информационной технологии;
− разработать структуру прототипа и описать принципы её функционирования;
− разработать прототип технологии и алгоритмы его функционирования.
1 АНАЛИЗ ПРОБЛЕМЫ ВЫЯВЛЕНИЯ ВИРТУАЛЬНЫХ СООБЩЕСТВ И
СБОРА СООБЩЕНИЙ ВИРТУАЛЬНОЙ СОЦИАЛЬНОЙ СЕТИ
«FACEBOOK»
1.1 Анализ предметной области задачи выявления виртуальных сообществ и
сбора сообщений виртуальной социальной сети «Facebook»
Социальные сети - это веб-сайты, либо иные сервисы, во всемирной сети
Интернет, где генерируемый контент (информационное содержание конкретного
носителя: сайта, газеты, книги и так далее), создается самими пользователями
социальной сети. Различные социальные сети по-разному разделяют роли создателей и
потребителей контента. К примеру, крупнейшая интернет-энциклопедия Wikipedia
поощряет своих пользователей, создающих и проверяющих на достоверность контент,
при помощи выдачи участникам прав на загрузку материалов и удаление статей.
Исследуемая в рамках данной работы виртуальная социальная сеть «Facebook»
позволяет любому своему пользователю создавать контент в виде постов (публикаций
на личных страничках, либо же в сообществах, содержащих текстовую и мультимедиа
информацию), оценкой которых могут заниматься остальные пользователи, при помощи
пометки «Мне нравится», позволяющей не только показать отношение пользователя к
прочитанной публикации, но и распространить пост среди пользователей сети. В рамках
данной работы взаимодействие с виртуальной социальной сетью (ВСС) «Facebook»
ограничено задачей выявления сообществ и сбора сообщений пользователей. Под
сообществом в рамках ВСС понимается группа пользователей, взаимодействующих при
помощи специального источника информации, с целью удовлетворения своих взаимных
интересов.
Задача сбора сообщений не является инновационной, на сегодняшний день эта
проблема давно стала основополагающей задачей для маркетологов, исследующих
различные ВСС. Однако, огромные аудитории ВСС привлекают внимание не только
исследователей
рынка.
ВСС
являются
средством
пропаганды
различных
противоправных действий общества, чему способствуют такие особенности ВСС, как:

непосредственный диалог с пользователем;

быстрое распространение информации;

высокая степень анонимности.
Социальная сеть «Facebook» является одной из наиболее старых, среди подобных
социальных сетей.
Обладая наиболее крупной пользовательской аудиторией,
«Facebook» одной из первых начали применять новые методы для представления своей
структуры. Так, благодаря подходу, называемому социальный граф, становится
возможным
упростить
сложную
структуру
социальной
сети,
состоящей
из
пользователей и связей между ними. Пример социального графа представлен на рисунке
1.
Рисунок 1 – Пример социального графа
В основе понятия «социальный граф» лежит построение графа знакомств между
людьми в обществе, что помогает получить информацию о человеке и его окружении.
Особенности социального графа:

связи отображают особенности, как для отдельных социальных объектов,
так и для графа в целом;

разделение на сегменты (кластеры) – деление, при котором объекты
социального графа делятся на группы по выбранному критерию;
С помощью социальных графов решают следующие задачи:

идентификация пользователей – обнаружение профилей, принадлежащих
одному человеку, в нескольких социальных сетях;

поиск в социальной сети – вид поиска, основанный на анализе связей между
социальными объектами;

создание рекомендаций – алгоритм предлагает пользователю завязать
знакомство, либо же рекомендует к просмотру определенный контент, коррелирующий
с поисковыми запросами пользователя;

сбор информации – построение социального графа на основе данных,
полученных в результате сканирования страниц различных социальных сетей.
Статистический анализ социальных сетей выявил ряд
интересных и иногда неочевидных свойств:
1. «Маленький диаметр» или «феномен шести рукопожатий». Если мы определим
диаметр
социальной сети как среднюю длину пути между двумя ее членами (узлами) или
как 90%квантиль расстояния между ними, то в большинстве социальных сетей в интернете
эта величина
равна приблизительно 6-7, даже при миллионах пользователей и миллиардах
связей. Это связано
прежде всего с тем, что большинство пользователей не желает быть на периферии
сообщества, а
стремится приблизиться как можно ближе к «авторитетам» и «хабам».
2. «Сужающийся диаметр». В момент образования социальная сеть представляет
собой большой набор мало связанных сообществ. В процессе развития эти сообщества
соединяются друг с другом, а затем образуется гигантский связанный кластер с малым
диаметром, а также небольшое количество «маргинальных» сообществ. В дальнейшем
диаметр сети продолжает уменьшаться, так как новые члены присоединяются к
основному сообществу. Неочевидным является тот факт, что величина второго и
третьего по величине сообщества не растет даже линейно по мере роста общего числа
членов, присоединяющихся к гигантскому кластеру.
3. «Транзитивность сетей»: если два пользователя имеют общего «друга», то с
большей, чем ожидаемо, вероятностью они также являются (или станут) взаимными
друзьями. Т.е. в социальных сетях возникает большое количество «треугольников».
4. «Гравитация»: существует корреляция между весом соседних узлов:
«авторитетные» члены сообщества имеют гораздо больший вес связи друг с другом, чем
ожидаемый. Веса связей определяются числом взаимных комментариев и прочими
характеристиками, описывающими интенсивность взаимодействия.
5. «Heavy tails». Распределение связей внутри социальной сети имеет «тяжелые
хвосты»: существует немного «авторитетных» пользователей с огромным количеством
связей и большое количество «обычных» пользователей с почти нормальным
распределением связей между собой.
1.2 Анализ существующих аналогов технологии выявления виртуальных
сообществ и сбора сообщений виртуальной социальной сети «Facebook»
Одним из аналогов разрабатываемой информационной технологии выявления
виртуальных сообществ и сбора сообщений виртуальной социальной сети «Facebook»
являются технологии мониторинга социальных сетей.
Интернет-сервис «Klout» представляет собой инструмент анализа популярности
человека с помощью оценки его профилей в социальных сетях. Этот сервис
предоставляет возможность оценки пользовательской аудитории и является способом
мониторинга социальной аудитории пользователя – анализ оценок его публикаций,
отображение
социальной
динамики
персонального
аккаунта,
либо
страницы
предприятия.
При анализе динамического изменения популярности страницы отображается с
помощью диаграмм и графиков. Оценка представляется для различных по времени
промежутков – результат одного дня и динамические изменения в течении 90 дней.
Возможна оценка соответствия публикуемого контента запросам аудитории, делающая
сообщения более актуальными. Данный сервис не удовлетворяет требованиям
поставленной задачи, так как он не позволяет визуализировать социальный граф
отношений участников виртуальной социальной сети «Facebook», а выполняет только
функции сбора статистики.
Еще одним аналогом для разрабатываемой технологии является сервис
«HowSociable» – инструмент мониторинга аудитории страницы в сети Интернет.
Кардинально отличается от предыдущего тем, что свой анализ сервис проводит не
только для страниц в сети Интернет, но и для брендов, компаний, фирм.
Предоставляемая сервисом оценка позволяет судить о росте, либо же снижении
популярности того или иного объекта. Данный инструмент
«YouScan» – сервис для мониторинга ВСС с элементами функционала для
группового взаимодействия при работе с социальной сетью содержит защиту от спама,
фильтрацию, категоризацию. Позволяет создавать настраиваемые отчеты о работе
технологии, добавлять задания для других пользователей. Сервис не удовлетворяет
требованиям поставленной задачи, так как система не дает возможности долгосрочного
сбора данных, а осуществляет одномоментный сбор без повторения операции. В таблице
2 приведено сравнение выбранной технологии и ее аналогов по выбранным критериям.
Таблица 2 – Сравнение аналогов разрабатываемой информационной технологии
Название
Klout
Характеристика
HowSociable
Youscan
Разрабатываема
я
технология
Понятный
пользовательский
-
+
-
+
+
-
+
+
-
+
+
+
-
-
-
+
-
+
-
+
интерфейс
Возможность
настройки
количества
выводимых
данных
Высокая скорость
работы
Работает
без
предварительной
регистрации
Открытый
исходный код
Таким
образом,
разрабатываемая
технология
должна
производить
сбор
сообщений участников ВСС «Facebook», собирая публикации с этих страниц, а затем
сохранять эти данные в собственной базе данных и выводить результат работы по
запросу в формате социального графа. Также необходим инструмент для визуализации
собранной информации.
1.3 Постановка задачи: выявления виртуальных сообществ и сбора сообщений
виртуальной социальной сети «Facebook», разработка функциональных и
нефункциональных требований
Исходя из обозначенных выше причин, возникает необходимость в разработке
решения задачи выявления виртуальных сообществ и сбора сообщений ВСС
«Facebook».
Основные требования к системе описаны при помощи языка UML и диаграммы
вариантов
использования.
Основная
диаграмма
прецедентов
взаимодействия
пользователя с прототипом технологии выявления сообществ и сбора сообщений
представлена на рисунке 2.
Рисунок 2 – Диаграмма прецедентов взаимодействия пользователя с прототипом
Как можно увидеть из представленной диаграммы, пользователь сможет находить
объекты наблюдения и визуализировать социальный граф отношений между
пользователями ВСС «Facebook». Кроме того, необходимой функцией станет
отображение выявленных сообществ на построенном социальном графе. Граф должен
быть интерактивным – легко поддающимся воздействию пользователя и дающим отклик
на его действия.
Целью данной выпускной квалификационной работы является разработка
прототипа информационной технологии для выявления виртуальных сообществ и сбора
сообщений в виртуальной социальной сети «Facebook».
В процессе выполнения дипломной работы необходимо:

провести анализ особенностей ВСС «Facebook» среди аналогичных ВСС;

сформировать
функциональные
и
нефункциональные
требования
к
разрабатываемой информационной технологии;

провести анализ методов сбора данных;

разработать базу данных для хранения собранных сообщений участников

разработать структуру информационной технологии и описать принципы ее
ВСС;
функционирования;

разработать приложение и алгоритмы его функционирования.
После рассмотрения аналогичных технологий и анализа их достоинств и
недостатков, можно сформулировать набор требований к разрабатываемой технологии:
−
реализация функции для добавления участников социальной сети в систему,
используя идентификатор пользователя в социальной сети;
−
функция для взаимодействия с сообществами ВСС «Facebook», добавлять
пользователей в систему, объединенных в сообщество;
−
возможность удаления участника социальной сети из системы;
−
предусмотреть различные режимы сбора сообщений: разовый и длительный
(сбор на протяжении определенного времени);
−
реализация средства визуализации связей между объектами наблюдения
(средство визуализации социального графа);
−
добавление средства поиска и просмотра объектов исследования;
−
реализация средства просмотра истории публикации пользовательских
сообщений с устанавливаемым сроком давности;
−
предусмотреть способ фильтрации участников ВСС по заявленным
критериям: пол, возраст, указанное место жительства.
2 ПРОЕКТИРОВАНИЕ ПРОТОТИПА ТЕХНОЛОГИИ ВЫЯВЛЕНИЯ
ВИРТУАЛЬНЫХ СООБЩЕСТВ И СБОРА СООБЩЕНИЙ ВИРТУАЛЬНОЙ
СОЦИАЛЬНОЙ СЕТИ «FACEBOOK»
2.1 Выбор принципов функционирования технологии выявления виртуальных
сообществ и сбора сообщений виртуальной социальной сети «Facebook»
Прототип технологии выявления виртуальных сообществ и сбора сообщений
участников ВСС «Facebook» необходимо представить в виде веб-приложения,
взаимодействующего с интернет-ресурсом непосредственно. Кроме того, необходимо
обратить внимание на значительную территориальную рассредоточенность точек входа
пользователей в разрабатываемую информационную технологию.
Система должна интегрироваться на сторонний доменный адрес и хостинг,
предоставляемый клиентом, так как для каждого учреждения, использующего данную
информационную технологию, существует определенный интересующийся круг
участников социальной сети.
Кроме того, необходимо предусмотреть режим работы прототипа. Необходимо
выбрать между веб-краулером и классическим парсингом. Веб-краулеры представляют
из себя часть поисковой системы, предназначенную для сканирования веб-страниц, с
целью обновления данных об их содержимом, а также с целью добавления новых, ранее
не пройденных. В простейшем варианте исполнения, веб-краулер строится из пяти
функциональных компонентов, выполняемых как отдельные процессы:
−
«URL» сервер получает URL-адрес из файла и передает его
остальным процессам-краулерам программы;
−
процесс-краулер процесс, непосредственно выполняющий
функции обхода веб-страниц и сбора с них данных;
−
процесс
сохранения
собранного
предполагает
передачу
полученных данных процессу сохранения для сжатия и сохранения
информации в хранилище (на диск);
−
процесс индексации извлекает ссылки на сохраненный файл, а
затем сохраняет отдельно;
−
«URL» - преобразователь считывает ссылки, сохраненные в
файл и преобразовывает относительные ссылки в абсолютные, которые
считывает процесс «URL» - сервера, для дальнейшего наблюдения.
Парсер же выполняет последовательное преобразование HTML-страниц в иной,
структурированный формат. Исходя из поставленной задачи, был выбран для
реализации подход с использованием веб-краулера, позволяющий вести сбор
сообщений на протяжении определенного времени.
Для
разработки
прототипа
технологии
были
выбраны
следующие
инструментальные средства:
− язык разработки серверной части программы: Python;
− фреймворк для разработки на указанном языке: Python Flask;
− язык разработки клиентской части приложения: VueJS;
− для оформления пользовательского интерфейса использовать язык разметки
HTML и набор стилей CSS.
Язык программирования Python был выбран, так как после написания
программного кода на данном языке программирования происходит интерпретация
программного кода в промежуточный байт-код, который будет исполняться
виртуальной машиной – абстрактным исполнителем, не привязанным к конкретной
системе, архитектуре или аппаратным решениям системы, что делает данный язык не
зависящим от системы, на которой исполняется программный код. Разрабатываемая
система будет выполнена в формате классического веб-приложения, а значит,
приобретет характерные для веб-приложения черты:
−
выполнение происходит за счет браузера;
−
независимость от операционной системы;
−
разделение на клиентскую и серверную части (клиент-сервер).
Классическим способом построения веб-приложения является шаблон MVC,
основной идеей которого стало разделение данных приложения, пользовательского
интерфейса и управляющей логики на три отдельных компонента: модель (все данные и
операции над ними, также содержит), представление (отвечает за видимое пользователю
представление данных модели) и контроллер (управляет взаимодействием модели и
представления) – таким образом, что модификация каждого компонента может
осуществляться независимо [1]. Составные части MVC представлены на рисунке 3.
Рисунок 3 – Паттерн Model-View-Controller
Помимо языка программирования необходимо выбрать средства, упрощающие
работу с конкретной задачей. Для языка Python таким средством является фреймворк
для разработки веб-приложений.
Фреймворком называют программное обеспечение, облегчающее разработку и
объединение разных компонентов большого программного проекта. В данном случае
оптимальным
выбором
станет
фреймворк
«Flask»
для
выбранного
языка
программирования.
К основным достоинствам фреймворка «Flask» относятся:
− качественная и полная документация с примерами;
− простота и гибкость;
− отсутствие структурных ограничений;
− высокая скорость работы фреймворка;
− нетребовательность к ресурсам.
Для клиентской части информационной технологии выбран язык VueJS. Он
представляет собой наиболее простой и надежный фреймворк среди многих подобных
решений,
с
обширными
библиотеками и проектами.
возможностями
для
интеграции
с
существующими
Пользовательский
интерфейс
разрабатываемого
приложения
является
отдельными веб-страницами. Формируются такие страницы при помощи языка
гипертекстовой разметки HTML.
Первым шагом конструирования станет представление архитектуры прототипа.
При помощи диаграммы размещений, представленной на рисунке 4, становится
возможно представить физическую модель взаимодействия аппаратных компонентов
глобальной сети и программных составляющих.
Рисунок 4 –Диаграмма размещений
На данной диаграмме представлена схема взаимодействия основных устройств, а
именно сервера «Facebook», сервера хостинга, на котором развернуто приложение и
персонального
компьютера
пользователя,
где
находится
база
данных,
и
пользовательский интерфейс, который отображает процесс и результаты работы
приложения. Получая запрос от пользовательского интерфейса, веб-приложение
посредством Facebook Graph API выполняет запрос к серверам «Facebook», получает
данные, в соответствии с запросом, после чего передает их на компьютер пользователя,
для отображения в пользовательском интерфейсе и сохранения в базе данных.
Для того, чтобы представить структуру прототипа и описать его, необходимо
использовать диаграмму компонентов приложения.
Эта
диаграмма
позволяет
представить основные принципы построения и архитектуры веб-приложения,
визуализировать шаблон построения MVC, использованный в данном случае.
Диаграмма представлена на рисунке 5.
Рисунок 5 –Диаграмма компонентов прототипа информационной технологии
На рисунке определены основные сущности шаблона MVC – модель, контроллер
и представление. Компоненты, образующие представление, являются узлами вебприложения, HTML-страницами, которые в совокупности составляют пользовательский
интерфейс приложения. В роли компонентов контроллера выступает основная часть
python-приложения, выполняющая роль краулера, и ресурсы Facebook Graph API
Explorer – интерфейса Facebook Graph API, позволяющего выполнять запросы как
непосредственно с использованием самого интерфейса, так и с помощью запроса к нему
от иного приложения. Модель приложения образована функциями и методами,
отвечающими за получение данных: форму авторизации, функция добавления
участника, функция добавления сообщества, а также функцией вывода результата
работы приложения. Кроме того, указаны подключаемые компоненты, такие как пакет
facebook-sdk и фреймворк Flask, упрощающие работу прототипа. Facebook-sdk является
пакетом, разработанным для взаимодействия python приложений с виртуальной
социальной сетью «Facebook». Flask обеспечивает работу веб-приложения, при помощи
системы шаблонов и декораторов, создавая функциональные HTML-страницы, из
которых состоит веб-приложение.
Последним этапом представлено описание логики диалога пользователя с
прототипом информационной технологии выявления виртуальных сообществ и сбора
сообщений участников виртуальной социальной сети «Facebook». Для решения этой
задачи был выбран такой инструмент, как диаграммы состояний языка моделирования
UML.
Диаграмма состояний используется для описания последовательности переходов
объекта из одного состояний в другой, а также показывает все возможные состояния, в
которых может находиться объект. Диаграмма состояний имеет схожую семантику с
диаграммой деятельности, только деятельность здесь заменена состоянием, а переходы
символизируют действия.
Основными элементами диаграммы являются «Состояние» и «Переход».
Состояние может содержать только имя или имя и дополнительно список
внутренних действий, содержащий перечень действий, которые выполняются во время
ожидания объекта в данном состоянии.
Переход может быть инициирован событием, которое отражается на диаграмме
состояний.
На рисунках 6 - 10 показаны диаграммы состояний разрабатываемой
информационной технологии.
Рисунок 6 – Диаграмма состояний диалога пользователя с прототипом при
авторизации в системе
В данной диаграмме описан процесс входа в учетную запись пользователя
системы. После отображения веб-страницы с формой для авторизации, пользователь
вводит логин и пароль. В зависимости от введенных данных, возможно произвести вход
в систему как рядовой пользователь и как супер-пользователь, в то время, как введенные
данные, не зарегистрированные в системе, приведут к сообщению об ошибке. После
успешной авторизации, пользователь сможет работать в системе. Алгоритм работы с
пользовательским интерфейсом системы, показан на рисунке 6.
Рисунок 7 – Диаграмма состояний диалога пользователя с прототипом при
взаимодействии с основным полем
После
успешного
завершения
авторизации
пользователь
начнет
взаимодействовать с прототипом при помощи главного меню, в котором сможет
выбрать необходимую функцию, с помощью выбора одного из пунктов меню.
Получившийся результат возможно визуализировать средствами прототипа.
Рисунок 8 – Диаграмма состояний вывода истории пользовательских сообщений
участника ВСС
При визуализации результата работы прототипа по полученному идентификатору,
выполняется запрос на сервер, после чего по данным, полученным в ответ на запрос
выстраивается массив и указываются связи между элементами массива. Последним
этапом визуализации является построение социального графа.
Рисунок 9 – Диаграмма состояний вывода истории пользовательских сообщений
участника ВСС
Рисунок 10 – Диаграмма состояний вывода истории пользовательских
сообщений участника ВСС
2.2 Проектирование базы данных информационной технологии выявления
виртуальных сообществ виртуальной социальной сети «Facebook»
Для хранения данных прототипа использована база данных.
На сегодняшний день существует достаточно много систем управления базами
данных (СУБД). Для выбора подходящего варианта необходимо рассмотреть наиболее
популярные варианты.
После анализа существующих вариантов, были выделены главные преимущества и
недостатки рассмотренных систем.
Oracle Database является крайне современной, надежной, практически эталонной
СУБД. Однако, будучи платным продуктом компании «Oracle», не подходит для
написания выпускной квалификационной работы.
MySQL – одно из самых популярных решений при созданиии базы данных. Являясь
весьма популярным инструментом управления базами данных, MySQL прекрасно
документирована, легка в установке и поддерживается большинством операционных
систем. Ощутимым недостатком при использовании данной СУБД становится
быстродействие системы при работе с такими типами данных, как json, вследствии чего,
от данного варианта необходимо отказаться.
MicrosoftSQL server достаточно хорошо зарекомендовал себя на рынке СУБД.
Простота, надежность и скорость работы делают ее отличным выбором при построении
базы данных проекта, однако заявленная производителем цена данного продукта не
позволяет использовать это решение.
MongoDB – это в какой-то мере уникальная система, отличающаяся простотой
эксплуатации и быстротой работы. Использование NoSQL является как положительной,
так и отрицательной чертой данной СУБД. Эта особенность позволяет MongoDB с
легкостью оперировать традиционными типами данных для NoSQL, такими, как json.
Но в то же время, отказ от языка SQL создает дополнительные трудности для
разработчика. Использование NoSQL стало решающим фактором при отказе от
использования MongoDB.
После анализа современных СУБД с открытым кодом, была выбрана СУБД
PostgreSQL. Причиной выбора стали функциональные особенности PostgreSQL. В
данной СУБД :
− поддержка JSON в PostgreSQL позволяет перейти к хранению schema-less
данных в SQL базе данных.
− открытый код базы данных означает, что СУБД является не только бесплатным,
но и весьма гибким инструментом, позволяющим проводить разностороннюю
настройку, в отличии от платных аналогов, где многие параметры являются закрытыми
в силу нежелания создателей терять прибыль;
− интуитивно понятный язык запросов SQL прост в освоении для каждого
пользователя, ввиду понятного синтаксиса и обилия обучающих материалов;
Поддержка JSON может быть полезна, когда структура данных требует
определённой гибкости: например, если в процессе разработки структура всё ещё
меняется или неизвестно, какие поля будет содержать объект данных. Тип данных
JSON обеспечивает проверку корректности, что позволяет использовать
специализированные JSON операторы и функции, встроенные в Postgre для
выполнения запросов и манипулирования данными. Также доступен тип JSONB
— двоичная разновидность формата JSON, который хранится наиболее
оптимальным способом;
JSONB обычно является предпочтительным форматом, поскольку требует меньше
места для объектов, может быть проиндексирован и обрабатывается быстрее, так как
не требует повторного синтаксического анализа.
Для хранения пользовательских сообщений участников социальной сети, их
персональной информации необходимо использовать базу данных. Подключение к базе
данных будет инициировано непосредственно в коде прототипа информационной
технологии. В таблице 2 представлено сравнение описанных аналогов по выбранным
критериям:
Таблица 2 – Сравнение наиболее популярных СУБД
Название
MySQ
MSQL-
Mongo
PostgreS
L
server
DB
QL
-
+
-
+
+
-
+
+
+
+
+
-
+
+
+
+
+
+
-
+
-
+
-
+
+
Oracle 12c
Хар-ка
Работа с json
без
дополнений
Открытый
код базы
Высокая
скорость
работы
Использовани
е SQL
Бесплатный
продукт
С помощью таблицы можно увидеть, что такие СУБД, как Oracle, MySQL, Microsoft
SQL server и MongoDB не подходят для требуемой задачи, не соответствуя некоторым
критериям. Кроме того, каждая из этих СУБД обладает своими достоинствами и
недостатками, однако из всех была выбрана именно Postgres для решения поставленной
задачи.
В базе данных должны присутствовать четыре основных сущности. К ним относятся:
− сущность «Пользователь», которая хранит персональную информацию об
участнике социальной сети (идентификатор страницы, имя и фамилию, пол, и так далее);
− сущность
«Группа»,
которая
предназначена
для
хранения
сообществ
социальной сети (идентификатор страницы сообщества и название сообщества);
− сущность «Данные пользователей», содержащая информацию обо всех
зарегистрированных в системе пользователях(логин, пароль, статус доступа)
− сущность
«Активность
пользователя»,
предназначенная
для
хранения
пользовательских сообщений участника социальной сети (идентификатор участника в
базе данных, день публикации сообщения, статус и данные об устройстве, с которого
участник входил в сеть).
Помимо
основных
сущностей,
есть
вспомогательная
сущность
«Пользователь_в_группе», отвечающая за принадлежность участника социальной сети
одному или нескольким сообществам.
На рисунке 10 представлена концептуальная схема базы данных, используемая в
программе.
Рисунок 11– Концептуальная схема базы данных
Получившуюся концептуальную схему базы данных необходимо преобразовать в
реляционную схему. Для этого необходимо:
1) каждая сущность превращается в таблицу. Имя сущности становится именем
таблицы;
2) каждый атрибут становится возможным столбцом с тем же именем;
3) компоненты
уникального
идентификатора
сущности
превращаются
в
первичные ключи;
4) связи многие-к-одному (и один-ко-многим) становятся внешними ключами;
5) создаются уникальные индексы для первичного ключа и внешних ключей.
Реляционная схема базы данных, получившаяся после преобразования, показана на
рисунке 12.
Рисунок 12 – Реляционная схема базы данных
2.3 Структура системы учета товаров детского магазина
При создании любой базы данных разработчик руководствуется не только
личными соображениями о принципах построения структуры хранилища данных.
Одним из аспектов разработки хранилища данных станет обеспечение целостности и
безопасности данных.
Для обеспечения целостности базы данных используются специальные триггеры
ON DELETE {CASCADE}.
При помощи каскадных ограничений ссылочной целостности можно определить
список действий, которые SQL-сервер будет принимать при попытке пользователем
удалить или обновить ключ в таблице, на который указывают еще существующие
внешние ключи.
Триггер ON DELETE {CASCADE} указывает, что при попытке удалить строку с
ключом, на которую ссылаются внешние ключи в строках других таблиц, все строки,
содержащие эти внешние ключи, также должны быть удалены.
Таким образом, при удалении данных об участнике ВСС из базы данных, также
будут удалены записи в таблицах, связанных с сущностью «Участник».
Кроме того, предусмотрены меры защиты информации от несанкционированного
доступа сторонних лиц. Помимо условий получения учетных данных, не лишним будет
обезопасить сам сервер от нежелательных взаимодействий с нежелательными
пользователями. Данного результата можно добиться, работая с созданной базой данных
с настройками по умолчанию. Это достигается при помощи файла pg_hba.conf, который
поддерживает только локальный адрес замыкания, что позволит избежать соединения с
внешними узлами. Данный файл в формате вывода консольного текстового редактора
Vim представлен на рисунке 12.
Рисунок 12 - Конфигурация базы данных
Помимо этого, необходимо предусмотреть шифрование используемых данных. В
PostgreSQL предусмотрено шифрование хранимых паролей по умолчанию – хранящиеся
в базе пароли шифруются в виде хешей MD5. Принцип работы хэш преобразований
основан на свертке входного массива в битовую строку, имеющую фиксированный
размер в случае с MD5 в 128 бит. Таким образом, благодаря процедуре хеширования
хранимые ключи пользователей остаются защищенными и недоступны даже
администраторам базы данных.
3 РАЗРАБОТКА ПРОТОТИПА ТЕХНОЛОГИИ ВЫЯВЛЕНИЯ
ВИРТУАЛЬНЫХ СООБЩЕСТВ И СБОРА СООБЩЕНИЙ ВИРТУАЛЬНОЙ
СОЦИАЛЬНОЙ СЕТИ «FACEBOOK»
3.1 Разработка алгоритмов функционирования прототипа
Как и на многих современных интернет-сайтах, в данном прототипе присутствует
необходимость в авторизации, позволяющая пользователю получиь доступ к прототипу.
В данном прототипе исключена возможность регистрации, в соответствии с
требованиями
к
которой,
данное
приложение
может
использоваться
только
ограниченным кругом лиц, которым право доступа будет предоставлено согласно их
полномочиям.
Для использования всех возможностей программы, пользователь должен ввести
выданные ему логин и пароль.
В системе предусмотрено наличие двух видов прав доступа – супер пользователь
(администратор) и рядовой пользователь, которым предоставлены различные наборы
функционала программы. Такое разграничение сделано для обеспечения безопасности
использования системы.
Вход в систему связан с использованием контроллера входа. Вводя данные,
пользователь передает информацию со своим логином и паролем контроллеру для
обработки, после чего система проверяет наличие такой пары логина и пароля в базе
данных. В зависимости от результата проверки, контроллеру возвращается значение,
обозначающее наличие, либо отсутствие таких данных в БД.
Алгоритм авторизации в модели представлен на рисунке 13.
Рисунок 13 – Схема алгоритма авторизации пользователя в прототипе
информационной технологии
Для визуализации графа достаточно просто ввести идентификатор пользователя
социальной сети «Facebook».
Затем система работает по следующему алгоритму:
− очистить поле вывода графа;
− получить друзей по данному идентификатору;
− получить данные по каждому другу (ФИО, аватар);
− построить
корректную
последовательность
данных
для
дальнейшей
визуализации графа: создать все вершины графа (друзей и основной идентификатор),
затем соединить их ребрами с основным идентификатором;
− для каждого друга получить его друзей ("друзья 2");
− для каждого друга из "дрзья 2" проверить, есть ли данный человек в графе, если
есть, то добавить ребро между другом и другом из "друзья 2";
− визуализировать граф по полученным данным.
Алгоритм визуализации графа представлен на рисунке 14.
Рисунок 14 – Алгоритм авторизации пользователя в модели, лист 1
Рисунок 14, лист 2
Для того чтобы добавить участника виртуальной социальной сети «Facebook» в
систему для отслеживания его публикаций, алгоритму добавления необходимо
получить только его идентификатор – короткий адрес в социальной сети, по которому
доступен участник или группа/сообщество.
После ввода пользователем приложения идентификатора участника социальной
сети, контроллер сразу же передаст данные в модель, которая в свою очередь произведет
над полученными данными необходимые манипуляции и вернет результат.
Как только в модель поступают данные (а именно идентификатор участника),
подключается
библиотека,
разработанная
специально
для
данного
проекта,
облегчающая взаимодействие с Facebook Graph API.
После подключения библиотеки, на основе полученного идентификатора
составляется и отправляется запрос к Graph API. Запрос содержит в себе наборы
входных параметров. Входными параметрами в данном случае является идентификатор
участника, а также названия полей, запрашиваемых у сервера. Список выходных
параметров содержит поля, значащиеся в самом запросе, а также id страницы,
выводимое даже при запросе без каких-либо параметров параметров:
− имя, фамилия и пол участника;
− фотография участника;
− место проживания участника;
− дату рождения участника;
− текущий статус участника на момент публикации (в сети, не в сети);
− устройство, с которого проявляется активность в социальной сети.
− Id страницы
Далее вызывается процедура обработки полученных данных.
Входным параметром процедуры добавления участника виртуальной социальной
сети «Facebook» является файл формата JSON, с типовой структурой, характерной для
данного файла. На рисунке 15 представлен вывод информации о последних пятнадцати
публикациях публичной страницы.
Рисунок 15 – Алгоритм работы модели добавления
участника, лист 1
Рисунок 15, лист 2
После выбора пункта меню «Добавить участника для отслеживания его
пользовательских
сообщений»
загружается
представление
модели
добавления
участников.
В данном представлении пользователь может ввести идентификатор страницы
участника социальной сети «Facebook» в предназначенное для этого поле ввода, после
чего нажать кнопку «Добавить».
Стоит учесть, что ссылка на страницу пользователя должна быть в формате
«1202972309788589», т.е. необходимо не полностью копировать ссылку на участника
социальной сети, а лишь часть, отсекая «https://www.facebook.com/».
После выбора пункта меню «Показать историю пользовательских сообщений
участников группы или сообщества» происходит визуализация участников сообщества
и их связей, что отражено на рисунке 16.
Рисунок
16 –
Алгоритм работы модели добавления сообщества, лист 1
Рисунок 16, лист 2
После того, как прототип загрузит данные для вывода пользовательских
сообщений участника социальной сети, будет вызвана функция, входным параметром
которой является идентификатор участника в базе данных.
Тело функции представляет собой два запроса на выборку из базы данных, один
из которых вернет персональную информацию об участнике по его идентификатору, а
другой – информацию о пользовательских сообщениях данного участника.
Так как входной параметр функции не может быть пустым (входным параметром
служит идентификатор участника в базе данных), не нужно проводить проверку на
корректность входных данных. Алгоритм работы модели представлен на рисунке 17.
Рисунок 17 – Алгоритм работы процедуры вывода пользовательских сообщений
участника
После выбора пользователем пункта меню «Добавить участника в систему»
(независимо от прав пользователя, полученных при авторизации в системе) заработает
процедура добавления участников, в которой пользователю предлагается указать
ссылку на участника «Facebook».
Как только процедура добавления участника в систему отправит данные в
контроллер (методом POST), будет загружена модель добавления участников в систему.
Результатом работы модели станет возврат идентификатора участника, добавленного в
базу данных. При успешном добавлении будет загружена модель вывода участников и
её представление.
Если результатом стало значение 0 (участник с таким идентификатором страницы
уже есть в базе данных), то будет выведено соответствующее сообщение.
3.2 Разработка пользовательского интерфейса прототипа технологии
выявления виртуальных сообществ и сбора сообщений участников виртуальной
социальной сети «Facebook»
Одной из важных частей прототипа информационной технологии является
интерфейс (внешний вид). Он играет связующую роль между пользователем и системой.
Чем понятнее интерфейс, тем эффективнее взаимодействие с пользователем.
При разработке системы построения социальных графов был выбрал первый
подход «Ориентированность на пользователя». Была получена информация о том, что
должно быть в интерфейсе веб–приложения и на основании этих данных был реализован
интерфейс.
Общие принципы интерфейса веб–приложения:
 понятность. Интерфейс должен быть как можно более простым для понимания
пользователем;
 кроссбраузерность. Веб–приложение должно выглядеть и работать одинаково в
разных браузерах;
 универсальность. Веб–приложение должно подстраиваться под различные
разрешения дисплеев.
Понятность достигается это за счет уменьшения количества элементов управления
и создания различных подсказок. Также необходимо учитывает с какими трудностями
может столкнуться пользователь.
Универсальность достигается с помощью таблиц стилей (CSS) или с помощью
скриптов написанных на Javascript. При этом учитывается процентное соотношение с
шириной и высотой разрешения дисплея, на котором показывается сайт.
После
ввода
некорректной
комбинации
логина
и
пароля,
появится
предупреждение для пользователя о некорректном вводе.
После успешной авторизации в системе, произойдет переход на основную
страницу, содержащую текст с подсказками по работе с системой, страница
представлена на рисунке 18.
Рисунок 18 – Стартовая страница пользователя
3.2.2 Разработка интерфейса построения графа
Далее следует вкладка «Построить граф» интерфейс которой показан на рисунке
19. На этой вкладке реализуются функции построения графа. Левая часть страницы
отвечает за визуализацию, а правая - за получение данных об участниках и вывод
информации об определенном участнике.
Рисунок 19 – Интерфейс страницы отображения графа
Левое поле используется для визуализации графа. Оно будет заполнено после того
как пользователь введет в поле идентификатор участника социальной сети и нажмет
кнопку «Построить граф».
Поле для ввода идентификатора участника виртуальной социальной сети
«Facebook» находится справа.
Ниже поля для ввода идентификатора находится элемент для вывода списка.
Данное
поле
служит для
вывода
списка
друзей,
полученных по
данному
идентификатору пользователя.
По завершению работы скрипта будет сформирован список друзей и построено
визуальное отображение социального графа (рисунок 21).
Рисунок 21 – Построение социального графа
При нажатии на фамилию и имя из списка друзей центром графа автоматически
станет вершина, которая отвечает за друга, на которого произошло нажатие. Также
информация о пользователе сменится на информацию о выбранном друге (рисунок 22).
Далее следует вкладка «Активность», интерфейс которой показан на рисунке 23.
Данная вкладка служит для вывода полученных результатов сбора сообщений участника
социальной сети. На странице находятся три основных элемента:

выпадающий список с идентификаторами;

кнопка для получения информации об участнике;

поле для вывода результата сбора;
таблица для вывода результатов представлена на рисунке 22.
Рисунок 22 – Интерфейс вкладки «Активность»
После выбора идентификатора участника и нажатия кнопки «Проверить
данные» будет заполнена таблица. Данные для заполнения таблицы будут взяты из базы
данных по выбранному идентификатору (рисунок 23).
Рисунок 23 – Интерфейс вкладки «Активность»
Затем следует вкладка «Управление отслеживание активности», интерфейс
которой изображен на рисунке 24.
Рисунок 24 – Интерфейс вкладки «Управление отслеживанием активности»
ЗАКЛЮЧЕНИЕ
В результате выполнения работы был реализован прототип технологии
выявления виртуальных сообществ и сбора сообщений виртуальной социальной сети
«Facebook».
При выполнении этапов разработки было уделено внимание к работе с
методами API социальной сети «Facebook».
Была создан прототип, строить социальные графы на основе введенного
идентификатора пользователя, находить общих друзей по списку идентификаторов,
отслеживать активность участников, выводить результат в табличном виде и
управлять отслеживанием.
Выполнена реализация модулей прототипа.
Произведено тестирование системы на основе реальных участников социальной
сети «Facebook».
Выделены следующие возможные пути развития программного комплекса –
внедрение функций для анализа пользовательской аудитории и добавление крупных
сообществ с участниками в систему для уменьшения временных затрат.
Были решены следующие задачи:
− проведен анализ особенностей ВСС «Facebook» среди аналогичных ВСС;
− сформированы требования к разрабатываемой информационной технологии;
− проведен анализ методов сбора данных;
− разработана база данных для хранения собранных сообщений участников ВСС;
− разработана структура информационной технологии и описать принципы
функционирования;
− разработано приложение и алгоритмы его функционирования.
Цель работы была достигнута.
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1. Олькина, Е.В. Методические указания по оформлению пояснительных записок
к курсовым проектам (работам) и отчётов по практикам в соответствии с требованиями
государственных стандартов [Текст] / Е. В. Олькина; рецензент О. В. Конюхова. –
ОрёлГТУ, 2017. - 54 с.
2. Олькина, Е.В. Методические указания по оформлению электронных материалов
[Текст] / Е.В. Олькина. – ОрёлГТУ, 2010. - 21 с.: ил.
3. Гринберг М. Разработка web–приложений с использованием Flask на Python
[Текст]:[пер. с англ.] / А.Н. Киселева –М.: ДМК Пресс, 2014. – 272 с.: ил.
4. Харрингтон Джен Л. Проектирование реляционных баз данных. [Текст]/ Джен
Л. Харрингтон – М.: Лори, 2006. – 230 с. – 1500 экз. – ISBN 5–85582–082–3.
5. Электронная энциклопедия. Язык моделирования UML [Электронный ресурс].
– Режим доступа: http://ru.wikipedia.org/wiki/UML. (Дата обращения: 14.06.2018).
6. Документация для разработчиков по API «Facebook» [Электронный ресурс]. –
Режим
доступа:
https://developers.facebook.com/docs/graph-api
(Дата
обращения:
14.06.2018).
7. Официальный сайт фреймворка Python Flask [Электронный ресурс]. – Режим
доступа: http://flask.pocoo.org. (Дата обращения: 14.06.2018).
8. Официальный сайт библиотеки spin.js [Электронный ресурс]. – Режим доступа:
http://spin.js.org/. (Дата обращения: 14.06.2018).
9. Противодействие распространению наркотиков [Электронный ресурс]. – Режим
доступа: http://fskn-friends.ru. (Дата обращения: 14.06.2018).
10. Википедия – свободная энциклопедия [Электронный ресурс]. – Режим
доступа: http://wikipedia.org. (Дата обращения: 15.06.2018).
11. Ньюман М.Дж. Алгоритм быстрого поиска структурных сообществ в
социальных сетях, 2004
12. Аггарвал Ч, Анализ данных социальных сетей, 2011
ПРИЛОЖЕНИЕ А ФРАГМЕНТ КОДА
import
facebook
import
os
import unittest
import inspect
try:
from urllib.parse import parse_qs, urlencode,
urlparse except ImportError:
from urlparse import parse_qs,
urlparse from urllib import
urlencode
from . import version
version
= version. version
FACEBOOK_GRAPH_URL
=
"https://graph.facebook.com/"
FACEBOOK_WWW_URL
=
"https://www.facebook.com/"
FACEBOOK_OAUTH_DIALOG_PATH
=
"dialog/oauth?" VALID_API_VERSIONS = [
"2.6", "2.7", "2.8", "2.9", "2.10", "2.11", "2.12", "3.0"]
VALID_SEARCH_TYPES = ["place", "placetopic"]
class GraphAPI(object):
def
init (self, access_token=None, timeout=None,
version=None, proxies=None, session=None):
# The default version is only used if the version kwarg
does
not
exist.
default_version
=
VALID_API_VERSIONS[0]
self.access_token
=
access_token self.timeout
= timeout self.proxies =
proxies
self.session = session or requests.Session()
if version:
version_regex
=
re.compile("^\d\.\d{1,2}$") match
=
version_regex.search(str(version))
if match is not None:
if
str(version)
not
in
VALID_API_VERSIONS:
raise
GraphAPIError("Valid API versions
are " +
str(VALID_API_VERSIONS).strip('[]'))
else:
self.version = "v" + str(version)
else:
raise GraphAPIError("Version number
should be in the" " following
format: #.# (e.g. 2.0).")
else:
self.version = "v" +
default_version
def get_permissions(self, user_id):
return self.request("{0}/{1}".format(self.version, id), args)
def
get_objects(self,
ids,
**args):
args["ids"]
=
",".join(ids)
return self.request(self.version + "/", args)
def
search(self,
type,
**args):
"""https://developers.facebook.com/docs/plac
es/search"""
if
type
not
in
VALID_SEARCH_TYPES:
raise GraphAPIError('Valid types are: %s' % ', '.join(VALID_SEARCH_TYPES))
args["type"] = type
return self.request(self.version + "/search/", args)
def get_connections(self, id, connection_name,
**args): return self.request(
"{0}/{1}/{2}".format(self.version, id, connection_name), args)
def get_all_connections(self, id, connection_name,
**args): while True:
page
=
self.get_connections(id,
connection_name, **args) for post in
page['data']:
yield post
next
=
page.get('paging',
{}).get('next') if not next:
return
args
=
parse_qs(urlparse(next).query)
del args['access_token']
def put_object(self, parent_object, connection_name, **data):
assert self.access_token, "Write operations require an
access token" return self.request(
"{0}/{1}/{2}".format(self.version,
parent_object,
connection_name), post_args=data,
method="POST")
def put_comment(self, object_id, message):
return self.put_object(object_id, "comments", message=message)
def put_like(self, object_id):
return self.put_object(object_id, "likes")
def delete_object(self, id):
self.request("{0}/{1}".format(self.version, id), method="DELETE")
def
delete_request(self,
user_id,
self.request("{0}_{1}".format(request_id,
method="DELETE")
def put_photo(self, image, album_path="me/photos",
**kwargs): return self.request(
request_id):
user_id),
"{0}/{1}".format(self.version,
album_path), post_args=kwargs,
files={"source": image},
method="POST")
def get_version(self):
args = {"access_token": self.access_token}
try:
response
=
self.session.request(
"GET",
FACEBOOK_GRAPH_URL + self.version
+ "/me", params=args,
timeout=self.timeout,
proxies=self.proxies)
except requests.HTTPError as e:
response
=
json.loads(e.read()) raise
GraphAPIError(response)
try:
headers = response.headers
version
=
headers["facebook-apiversion"].replace("v", "") return str(version)
except Exception:
raise GraphAPIError("API version number not available")
def request(
self, path, args=None, post_args=None, files=None,
method=None): if args is None:
args = dict()
if post_args is not
None: method =
"POST"
if self.access_token:
if post_args and "access_token" not in
post_args: post_args["access_token"] =
self.access_token
elif "access_token" not in args:
args["access_token"]
=
self.access_token
try:
response
=
self.session.request( method
or
"GET",
FACEBOOK_GRAPH_UR
L + path,
timeout=self.timeout,
params=args,
data=post_args,
proxies=self.proxies,
files=files)
except
requests.HTTPError as
e:
response
=
json.loads(e.read())
raise
GraphAPIError(respons
e)
headers = response.headers
if 'json' in headers['contenttype']:
result
=
response.json()
elif
'image/'
in
headers['content-type']:
mimetype
=
headers['content-type']
result
=
{"data":
response.content,
"mime-type":
mimetype,
"url":
response.url}
elif
"access_token"
in
parse_qs(response.text): query_str =
parse_qs(response.text)
if "access_token" in query_str:
result
=
{"access_token":
query_str["access_token"][0]} if "expires" in
query_str:
result["expires"] = query_str["expires"][0]
else:
raise GraphAPIError(response.json())
else:
raise GraphAPIError('Maintype was not text, image, or querystring')
if
result and isinstance(result, dict) and
result.get("error"): raise GraphAPIError(result)
return result
def get_app_access_token(self, app_id, app_secret,
offline=False): if offline:
return
"{0}|{1}".format(app_id,
app_secret) else:
args
=
{'grant_type':
'client_credentials', 'client_id':
app_id,
'client_secret': app_secret}
return
self.request("{0}/oauth/access_token".format
(self.version), args=args)["access_token"]
def get_access_token_from_code(
self, code, redirect_uri, app_id,
app_secret): args = {
"code":
code,
"redirect_uri":
redirect_uri,
"client_id": app_id,
"client_secret":
app_secret}
return
self.request(
"{0}/oauth/access_token".format(self.ver
sion), args)
def extend_access_token(self, app_id,
app_secret): args = {
"client_id":
app_id,
"client_secret":
app_secret,
"grant_type":
"fb_exchange_token",
"fb_exchange_token": self.access_token,
}
return
self.request("{0}/oauth/access_token".format(s
elf.version), args=args)
def debug_access_token(self, token, app_id,
app_secret): args = {
"input_token": token,
"access_token": "{0}|{1}".format(app_id, app_secret)
}
return self.request(self.version + "/" + "debug_token", args=args)
def
get_auth_url(self,
app_id,
perms=None,
**kwargs):
"{0}{1}/{2}".format(
FACEBOOK_WWW_URL,
self.version,
FACEBOOK_OAUTH_DIALOG
_PATH,
)
args = {
"client_id":
app_id,
"redirect_uri":
canvas_url,
}
if perms:
args["scope"]
=
",".join(perms)
args.update(kwargs)
return url + urlencode(args)
class
GraphAPIError(Excepti
on): def init (self,
result):
canvas_url,
url
=
self.result
=
result self.code
= None try:
self.type
=
result["error_code"] except
(KeyError, TypeError):
self.type = ""
try:
self.message
=
result["error_description"]
except
(KeyError, TypeError):
try:
self.message
=
result["error"]["message"] self.code
= result["error"].get("code")
if not self.type:
self.type
=
result["error"].get("type", "") except
(KeyError, TypeError):
try:
self.message
=
result["error_msg"]
except
(KeyError, TypeError):
self.message = result
Exception.
init
(self,
self.message)
def get_user_from_cookie(cookies, app_id,
app_secret): cookie = cookies.get("fbsr_" +
app_id, "")
if not cookie:
return None
parsed_request = parse_signed_request(cookie,
app_secret) if not parsed_request:
return None
try:
result
=
GraphAPI().get_access_token_from_
code( parsed_request["code"], "",
app_id, app_secret)
except
GraphAPIError:
return None
result["uid"]
parsed_request["user_id"]
result
=
return
def parse_signed_request(signed_request,
app_secret): try:
encoded_sig, payload = map(str, signed_request.split('.', 1))
sig = base64.urlsafe_b64decode(encoded_sig + "=" *
((4 - len(encoded_sig) % 4)
%
4))
data
=
base64.urlsafe_b64decode(payload + "=" *
((4 - len(payload) % 4) % 4))
except IndexError:
return False
except
TypeError:
return False
except
binascii.Error:
return False
data = json.loads(data.decode('ascii'))
if data.get('algorithm', '').upper() !=
'HMAC-SHA256': return False
app_secret = app_secret.encode('ascii')
payload = payload.encode('ascii')
expected_sig = hmac.new(app_secret,
msg=payload,
digestmod=hashlib.sha256).digest(
)
if sig != expected_sig:
return False
return data
ПРИЛОЖЕНИЕ А ФРАГМЕНТЫ КОДА
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6. Характеристики
содержания
Характеристики документа
на электронном носителе
Презентация.pptx
Демонстрационные плакаты
к выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Использование документа Операционная система
Windows 7, Microsoft
PowerPoint 2010
13.06.2018
Дата и время
копирования документа
Дата создания документа 29.05.2018
Дата утверждения
06.06.2018
документа
Автор
Абашин А.А.
Изготовитель
Абашин А.А.
Удостоверяющий лист
Ссылки на другие
№ 140025
документы
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
Объем информации
78336 Б
документа
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Наименование плаката
(слайда) №11
Титульный лист
Общие сведения о структуре
социальной сети «Facebook»
Обзор аналогов технологии
Реляционная схема базы
данных
Описание компонентов
программы
Логика диалога пользователя
и
приложения
Алгоритм построения графа
вывода участников
Пользовательский интерфейс
стартовой страницы
прототипа приложения
Пользовательский интерфейс
страницы прототипа
приложения
Пользовательский интерфейс
отображения участника ВСС
в прототипе приложения
Пользовательский интерфейс
страницы прототипа
приложения
1/--страниц
Пожаловаться на содержимое документа