Программное обеспечение информационной системы для расширения функциональности социальных сетей «Anonym»

Оглавление

1. Введение 3

2. Описание предметной области. Постановка задачи 5

3. Проектирование серверной части 5

3.1 Выделение сущности и атрибутов 5

3.2 Выделение связей между сущностями. 5

3.2.1 Связи один к одному (1:1) 5

3.2.2 Связи один ко многим (1:М) 5

3.2.3 Связи многие ко многим (М:М) 5

3.3 Модели базы данных 5

3.4 Нормализация отношений 5

3.5 Описание таблиц и атрибутов. 5

3.6 Разработка запросов к БД 5

4. Проектирование клиентской части 5

4.1 Архитектура ПО 5

4.2 Обоснование выбора языка программирования для реализации системы 5

4.3 Выбор инструментальных средств (СУБД) 5

4.4 Разработка функциональных схем приложения 5

4.5 Разработка интерфейса приложения 5

Заключение 5

Список использованной литературы 5

Приложение А 5


  1. Введение

Согласно статистическим данным, состоянием на 2014 год, более 3,8 млрд людей пользуется интернетом. В списке самых посещаемых сайтов самые популярные в Украине социальные сети «Вконтакте» и «Facebook» находятся в первой десятке.

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

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

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

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

ICQ (англ. I seekYou —«я ищу тебя») —централизованная служба мгновенного обмена сообщениями сети Интернет, в настоящее время принадлежащая инвестиционному фонду Mail.ru Group. ICQ является централизованной службой мгновенного обмена сообщениями, использующей протокол OSCAR. Пользователь службы работает с программой-клиентом, запущенной на устройстве, соединённом с сетью Интернет. Мессенджер подключается к серверу. Через сервер осуществляется поиск и связь с другими клиентами, а обмен служебными данными, сообщениями между пользователями может осуществляться как через сервер, так и без его участия. Как и в большинстве мощных сетевых систем, обслуживающих огромное количество клиентских запросов, этот сервер не единственный и некоторые из них являются кластерами серверов.

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


  1. Описание предметной области. Постановка задачи

Система мгновенного обмена сообщениями, Система обмена мгновенными сообщениями (англ. Instantmessaging, IM) —службы мгновенных сообщений (InstantMessagingService, IMS), программы онлайн-консультанты (OnlineSaler) и программы-клиенты (InstantMessenger, IM) для обмена сообщениями в реальном времени через Интернет. Могут передаваться текстовые сообщения, звуковые сигналы, изображения, видео, а также производиться такие действия, как совместное рисование или игры. Многие из таких программ-клиентов могут применяться для организации групповых текстовых чатов или видеоконференций.

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


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

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

Реализовать возможность:

  • отправки сообщений;
  • добавления пользователя в список избранного;
  • вывода информации о пользователе;
  • вывод списка избранного пользователя;
  • вывод сообщений.

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


3.Проектирование серверной части

3.1 Выделение сущности и атрибутов

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

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

Рассмотрев предметную область было решено, что в данной предметной области нужно использовать5сущностей: User, Messages, Opinions, VKFavorites, FBFavorites.

Общая информация о сущностях представлена в таблице3.1.

Таблица 3.1 –Сущности БД

Название сущности

Описание

User

Информация о пользователя

Message

Приватные сообщения

Opinion

Публичные мнения

VKFavorite

Избранные пользователи Вконтакте

FBFavorite

Избранные пользователи Facebook


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

Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности.

Рассмотрев все сущности выделим их атрибуты:

Сущность «User» имеет такие атрибуты:

  • objectId
  • username
  • password
  • createdAt

Сущность «Message» имеет такие атрибуты:

  • objectId
  • IDUser
  • Message
  • IsAnonym
  • createdAt
  • IDSender
  • SenderName

Сущность «Opinion» имеет такие атрибуты:

  • objectId
  • IDUser
  • Message
  • IsAnonym
  • createdAt
  • IDSender
  • SenderName

Сущность «VKFavorite» имеет такие атрибуты:

  • objectId
  • IDUser
  • IDFavoriteUser
  • createdAt

Сущность «FBFavorite» имеет такие атрибуты:

  • objectId
  • IDUser
  • IDFavoriteUser
  • createdAt

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

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

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

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

3.2 Выделение связей между сущностями.

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

Проблема  представления семантики давно  интересовала разработчиков, и в  семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "EntityRelationship" (ER-модель), стала фактическим стандартом при инфологическом моделировании баз данных. 
       В основе ER-модели лежат следующие  базовые понятия:
       Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. 
       Объект, которому соответствует понятие  сущности, имеет свой набор атрибутов —характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.
       Между сущностями могут быть установлены  связи —бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности.


3.2.1 Связи один к одному (1:1)

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

В данной работе не используется такая связь.

3.2.2 Связи один ко многим (1:М)

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

В данной работе не используется такая связь.

3.2.3 Связи многие ко многим (М:М)

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

В данной работе не используется такая связь.


3.3 Модели базы данных

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

Рисунок3.1 –Физическая модель


3.4 Нормализация отношений

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

Цель:

  • исключить дублирования данных;
  • обеспечить целостность данных

Автоматически происходило  соответственные изменения связных с ним объектов.

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

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

Вторая  нормальная форма (2НФ). Для 2НФ требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен.

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

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

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

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

Все сущности находятся в первой нормальной форме, потому что они:

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

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

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

3.5 Описание таблиц и атрибутов.

Таблица 2.1- "User"

Название поля

Тип

Ограничение

Описание

objectId

string

PK

Идентификатор пользователя

username

string

Имя пользователя (до 255 символов)

password

string

Пароль пользователя (до 255 символов)

createdAt

dateTime

Время создания записи


Таблица 2.2 - "Messages"

Название поля

Тип

Ограничение

Описание

objectId

string

PK

Идентификатор сообщения

IDUser

string

Идентификатор пользователя получателя (берется из соц.сети)

Message

string

Текст сообщения (до 255 символов)

IsAnonym

bool

Показатель анонимности

createdAt

dateTime

Дата и время добавления сообщения

IDSender

string

Идентификатор пользователя отправителя (берется из соц. сети)

SenderName

string

Имя отправителя (до 255 символов)

Таблица2.3 - "Opinions"

Название поля

Тип

Ограничение

Описание

objectId

string

PK

Идентификатор мнения

IDUser

string

Идентификатор пользователя получателя (берется из соц.сети)

Message

string

Текст мнения (до 255 символов)

IsAnonym

bool

Показатель анонимности

createdAt

dateTime

Дата и время добавления мнения

IDSender

string

Идентификатор пользователя отправителя (берется из соц. сети)

SenderName

string

Имя отправителя (до 255 символов)

Таблица2.4 - "VKFavorites"

Название поля

Тип

Ограничение

Описание

objectId

string

PK

Идентификатор записи

IDUser

string

Идентификатор активного пользователя (берется из соц. сети)

IDFavoriteUser

string

Идентификатор пользователя из списка избранного (берется из соц. сети)

createdAt

dateTime

Дата и время создания записи

Таблица2.5 - "FBFavorites"

Название поля

Тип

Ограничение

Описание

objectId

string

PK

Идентификатор записи

IDUser

string

Идентификатор активного пользователя (берется из соц. сети)

IDFavoriteUser

string

Идентификатор пользователя из списка избранного (берется из соц. сети)

createdAt

dateTime

Дата и время создания записи

3.6 Разработка запросов к БД

Добавление записи в FBFavorites

INSERTINTOFBFavorites

SELECT FBFavorites.*

FROMFBFavorites;

Вывод избранного выбранного пользователя

SELECT FBFavorites.IdFavoriteUser

FROM FBFavorites

WHERE (("IdUser"=[link].[Iduser]));

Добавлениеновогосообщения

INSERTINTOMessages

SELECT Messages.*

FROM Messages;

Добавлениеновогомнения

INSERT INTO Opinions

SELECT Opinions.*

FROM Opinions;

Вывод анонимных сообщений выбранного пользователя

SELECTMessages.Message

FROM Messages

WHERE (("IsAnonym"="Истина" & "IDUser"=[link].[IdUser]));


4.Проектирование клиентской части