Создание интернет-сервиса, социальной сети – "Image Poster"

Анализ клиентской части программного обеспечения для социальной сети "Image Poster". Выбор типовой архитектуры. Разработка UML–диаграмм для программного обеспечения для социальной сети. Интерфейс клиентской части. Загрузка и комментирование фотографий.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 25.05.2017
Размер файла 3,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Реферат

Пояснительная записка к данной работе содержит:

81 страницы, 20 иллюстраций, 15 таблиц.

Цель диплома - создание интернет-сервиса, социальной сети - “Image Poster”

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

Реферат

Пояснювальна записка до даної роботи містить:

81 сторінки, 20 ілюстрацій, 15 таблиць.

Мета диплома - створення інтернет-сервісу, соціальної мережі “Image Poster”.

В результаті проведеної роботи були розроблені необхідні алгоритми для обробки даних. В якості середовища розробки використовувався пакет Visual Studio 2013.

Abstract

Explanatory Note to this paper contains:

81 pages, 20 illustrations, 15 tables.

The purpose of the diploma - the creation of the Internet service, the social network - "Image Poster"

As a result of this work we have been developed the necessary algorithms for data processing. As a development environment used by Visual Studio 2013 package.

Содержание

1. ВВЕДЕНИЕ

1.1 Постановка задачи к выпускной работе бакалавра

1.2 Описание предметной области

1.3 Актуальность

1.4 Цели создания роботы

2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ

2.1 Проектирование БД

2.2 Use case диаграмма

2.3 Диаграмма активности

2.4 Диаграмма размещений

2.5 Диаграмма классов

3. ОПИСАНИЕ ПРОГРАММНОЙ РЕАЛИЗАЦИИ

3.1 Описание предметной области

3.2 Описание постановки задачи. Функциональная структура АИС

3.3 Характеристика комплекса задач

3.4 Выходная информация

4. МОДЕЛИРОВАННИЕ СИСТЕМЫ

4.1 Концептуальная модель системы

4.2 Концептуальная модель данных

4.3 Логическое проектирование. Логическая модель данных

4.4 Алгоритм работы автоматизированной системы

Рисунок 4.2 - Алгоритм взаимодействия с системой

4.5 Информационная безопасность системы

4.6 Разработка программно-информационного компонента. Обоснование выбора среды разработки

4.7 Физическая модель данных

5. РАЗРАБОТКА ИНТЕРФЕСА

5.1 Описание пользовательского интерфейса и программных модулей

5.3 Страница Авторизации

5.4 Регистрация

5.5 Домашняя страница

5.6 Новости

5.7 Друзья

6. ТЕСТИРОВАНИЕ ПО

6.1 Цели и задачи тестирования ПО

6.2 Цель системного тестирования ПО

6.3 Цель интеграционного тестирования ПО

7. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

7.1 Описание продукции

7.2 Разработка перечня работ по проектированию ПО.

7.3 Расчет сметы затрат и цены разработки ПО

ЗАКЛЮЧЕНИЕ

Перечень ссылок

ПРИЛОЖЕНИЕ А . Техническое задание

ПРИЛОЖЕНИЕ Б. Исходный код приложения:

ПРИЛОЖЕНИЕ В. Презентация проекта.

1. ВВЕДЕНИЕ

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

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

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

Влияние социальных сетей на жизнь людей огромное, многие даже не осознают до конца масштабы этого явления, а ведь социальные сети - это уже самое популярное занятие в Интернете. Сегодня из 100 самых посещаемых сайтов в мире 20 - это классические социальные сети и еще 60 - в той или иной степени социализированы. Более 80% компаний по всему миру использую социальные сети в работе. Около 78% людей доверяют информации из социальных сетей. Через них даже устраиваются целые революции. Социальные сети стали самым центром современного Интернета.

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

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

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

1.1 Постановка задачи к выпускной работе бакалавра

Во время выполнения выпускной работы бакалавра, в результате которой должно быть спроектировано, реализовано и протестировано ПО интернет-сервиса, социальной сети «Image Poster» необходимо выполнить роль аналитика программного обеспечения, а именно:

1. Провести анализ требований клиентской части ПО для социальной сети «Image Poster» на основе которого определить требования к ПО.

2. Спроектировать программное обеспечение, выполнив следующие задачи:

a) выбор типовой архитектуры.

b) разработка UML - диаграмм для ПО для социальной сети:

- диаграммы вариантов использования;

- диаграммы классов;

- диаграмма активности;

- диаграмма размещений;

c) спроектировать интерфейс клиентской части ПО для социальной сети «Image Poster».

d) обосновать выбор средств разработки клиентской части ПО для социальной сети «Image Poster».

3. Разработать клиентскую часть ПО для социальной сети «Image Poster».

4. Провести тестирование ПО для социальной сети «Image Poster».

1.2 Описание предметной области

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

Основные характеристики социальной сети:

1) Простота и понятность интерфейса;

2) Реализация функций социальной сети;

3) Адаптивный дизайн;

1.3 Актуальность

Актуальность работы заключается в создании социального, некоммерческого web-приложения - социальной сети “Image Poster”. созданного с использованием технологии ASP.NET. Для реализации базы данных была использована среда MS SQL. Для доступа к данным использовалось ORM-решение для платформы .NET Entity Framework;

Был разработан сервис с возможностью делать посты с изображениями и добавлениями комментариев.

1.4 Цели создания роботы

Дипломный проект проводится с целью:

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

- углубления теоретических знаний в соответствии с заданной темой;

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

- формирования умений использовать справочную, нормативную и правовую документацию;

- подтверждения квалификации бакалавра.

2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ

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

На рисунке 2.1 - Классы сущностей.

Рисунок 2.1 - Entity классы

Рисунок 2.2 -Классы связывающие базу данных и логику.

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

Разбил проект на 3 основные части. К каждой из части написан контроллер.

Рисунок 2.3 - «Контроллеры»

Рисунок 2.4 - «Представления»

2.1 Проектирование БД

При реализации поставленной задачи была спроектирована база данных.

Основная таблица - users. В ней хранится вся информация о пользователе: ид, имя, фамилия, аватар и подписчики.

Таблица «post» хранит в себе информацию о постах. Тут задаётся ид поста, дата создания, содержимое, которое состоит из изображения и сообщения, а также ссылка на пользователя, который создал этот пост.

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

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

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

Схему базы данных можно увидеть на рисунке 2.5

Рисунок 2.5 - база данных системы

2.2 Use case диаграмма

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

Рисунок 2.6 - use case диаграмма приложения.

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

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

Так же пользователь может удалить свой аккаунт.

2.3 Диаграмма активности

Диаграмма активности представляет собой модель взаимодействия клиента - веб-сервера - Сервера БД на программном уровне.

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

Сама диаграмма представлена на рисунке 2.3

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

2.4 Диаграмма размещений

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

Данная работа представляет собой веб-сервис, следовательно, отраженные на ней взаимосвязи имеют такую структуру, показанную на рисунке 2.7.

Рисунок 2.7 - Диаграмма размещений.

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

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

2.5 Диаграмма классов

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

Рисунок 2.8

В данной диаграмме показаны классы контроллеров - основного элемента управления в системе. Программа была разбита на 3 проекта, и каждый проект имеет свой контроллер.

· Base controller - основной контроллер в системе, осуществляющий взаимосвязь между двумя другими.

· Home controller - осуществляет работу непосредственно с сайтом, его внешним видом.

· Account controller - осуществляет работу между клиентом и системой, содержит в себе элементы управления страницей.

3.ОПИСАНИЕ ПРОГРАММНОЙ РЕАЛИЗАЦИИ

Приложение реализовано с помощью технологии ASP.NET MVC. Такая структура подразумевает разделение приложение на такие составляющие как модель, представление, контроллер. Объекты моделей являются частями приложения, реализующими логику для домена данных приложения. Объекты моделей часто получают и сохраняют состояние модели в базе данных. Например, объект Post может получать информацию из базы данных, работать с ней, а затем записывать обновленные данные в таблицу Post базы данных.

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

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

Шаблон MVC позволяет создавать приложения, различные аспекты которых (логика ввода, бизнес-логика и логика интерфейса) разделены, но достаточно тесно взаимодействуют друг с другом. Эта схема указывает расположение каждого вида логики в приложении. Пользовательский интерфейс располагается в представлении. Логика ввода располагается в контроллере. Бизнес-логика находится в модели.

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

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

Entity Framework (EF) -- объектно-ориентированная технология доступа к данным, является object-relational mapping (ORM) решением для .NET Framework от Microsoft. Предоставляет возможность взаимодействия с объектами как посредством LINQ в виде LINQ to Entities, так и с использованием Entity SQL. Для облегчения построения web-решений используется как ADO.NET Data Services (Astoria), так и связка из Windows Communication Foundation и Windows Presentation Foundation, позволяющая строить многоуровневые приложения, реализуя один из шаблонов проектирования MVC, MVP или MVVM.

Entity Framework подразумевает создание классов соответственно таблицам базы данных.

Для создания web-интерфейса использовались такие технологии как HTML, CSS, JavaScript, jQuery.

3.1 Описание предметной области

Предметная область состоит из таких сущностей: пользователь, подписчики пользователя, пост, комментарий к нему. Сущность пользователь позволяет создавать пользователя. Сущность подписчиков позволяет подписываться и смотреть кто подписан на тебя (получать уведомление о размещение постов). Каждый пользователь идентифицируется по его id. У каждого пользователя есть посты и подписчики. Так же есть сущность комментарий. Она позволяет добавлять комментарии к постам.

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

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

Таким образом, структуру социальной сети и взаимодействие процессов в ней можно представить в виде, изображенном на рисунке 3.1

Рисунок 3.1 - Структура социальной сети.

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

Процесс работы в системе можно описать следующим образом:

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

- он авторизуется в системе и получает полный доступ к своему личному кабинету;

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

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

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

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

3.2 Описание постановки задачи. Функциональная структура АИС

В результате анализа предметной области была составлена функциональная структура АИС, приведенная на рисунке 3.2.

В АИС выделены три основные функции:

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

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

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

Рисунок 3.2 - функциональная структура АИС.

3.3 Характеристика комплекса задач

Описание выявленных задач данной АИС:

1) функция «Авторизация и аутентификация» должна решать следующие задачи:

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

- сохранение его учетных данных в БД, причем пароль должен храниться в надежно зашифрованном виде;

- доступ к функциям системы посредством авторизации;

- смена пароля пользователя;

- защита от атак типа SQL-Injection.

2) функция «Личный кабинет» должна решать следующие задачи:

- доступ к возможностям системы в своем кабинете;

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

- управления личными сообщениями;

- управления личными настройками пользователя.

3) функция «Администрирование» должна выполнять задачи:

- редактирование шаблонов оформления сайта;

- работы с учетными записями пользователей;

- работы с их анкетными данными;

3.4 Выходная информация

В виду специфики системы вся выходная информация представлена в виде экранных форм, технически реализованных как web-страницы.

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

Таблица 3.1 - Описание экранных форм

ID

Наименование

Задача

Периодичность

Э1

Главная страница

Приглашение входа в систему, ссылка для регистрации

При каждом входе пользователей в систему

Э2

Страница регистрации

Форма для ввода придуманных пользователем логина и пароля

При первом запуске системы

Э3

Страница профиля

Отображение ссылок для входа в возможности системы, на ней выводятся также анкетные данные

При успешных авторизациях и по требованию пользователя

Э4

Страница новостей

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

По требованию пользователя

Э5

Страница анкетных данных

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

По требованию пользователя

Э6

Страница загрузки аватара

Содержит элемент управления выбором файла и текущий аватар

По требованию пользователя

Э7

Страница управления пользователями

Содержит элемент ввода ID пользователя и элемент управления для редактирования его анкеты, а также возможность его блокировки

По требованию администратора

В состав выходных сообщения входят структурные единицы, перечисленные в таблице 3.2.

Таблица 3.2 - Структурные единицы

Наименование

Формат

Псевдоним

Строка символов, до 20 символов

Логин и пароль

Строки текста, до 20 символов

Фотография

Изображение, до 10 Мб

Текст сообщения

Строки текста, до 1 Кб

Аватар

Изображение, до 1 Мб

Исходный код

Текст, до 20 Кб

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

Таблица 3.3 - Входные данные

ID

Наименование

Форма получения

Источник

Срок получения

Q1

Анкета пользователя

Электронная

Пользователь

После заполнения

Q2

Личное сообщение

Электронная

Пользователь

После заполнения

Q3

Фотография

Электронная

Пользователь

После заполнения

Q4

Код шаблонов

Электронная

Администратор

После заполнения

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

4. МОДЕЛИРОВАННИЕ СИСТЕМЫ

4.1 Концептуальная модель системы

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

Технические средства серверной части должны соответствовать минимальным системным требованиям:

- процессор Pentium 4 3,2 ГГц;

- ОЗУ -2 Гб ;

- 1 Гб свободного пространства на жестком диске;

- видеокарта - 32 Мб с поддержкой разрешения 800х600 и 32-битного цвета или выше;

- клавиатура;

- операционная система - в случае Windows-систем: Windows 2000 Server/Windows XP Professional/Windows 2003 Server/Windows 2008 Server; в случае UNIX-систем: FreeBSD 6.5+, OpenBSD 4+, Linux (любой дистрибутив) с ядром версии 2.6+.

К клиентским машинам предъявляются обычные для работы в Интернете требования:

- процессор Pentium 1000 Гц;

- 128 Мб ОЗУ;

- от 500 до 1000 Мб на жестком диске;

- видеокарта 32 Мб с поддержкой разрешения 800х600 и 32-битного цвета или выше;

- клавиатура;

- мышь;

- операционная система - Microsoft Windows 98/ME/NT/2000/XP/2003/Vista, Linux 2.4+, MacOS 9+, FreeBSD 5+, OpenBSD 3+, NetBSD.

4.2 Концептуальная модель данных

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

Рисунок 4.1 - . Концептуальная модель данных

4.3 Логическое проектирование. Логическая модель данных

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

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

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

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

Таблица 4.1 Сущности - Атрибуты

Сущность

Первичный ключ

Атрибуты

Пользователь

Уникальный ключ пользователя

Номер пользователя

Номер пользователя

Логин

Пароль

Статус в системе

Анкета пользователя

Уникальный ключ пользователя

Номер пользователя

Номер пользователя

Псевдоним

Дата рождения

Номер ICQ

Интересы

Хобби

Род занятий

Аватар

Сообщения

Уникальный ключ сообщения

Номер сообщения

Номер сообщения

Номер отправителя

Номер адресата

Тема

Текст сообщения

Дата и время

Статус удаления

Фотографии

Уникальный ключ фотографии

Номер закладки

Номер закладки

Номер пользователя

Название

Описание

URL-адрес

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

4.4 Алгоритм работы автоматизированной системы

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

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

1) добавление данных, происходит посредством оператора языка SQL INSERT;

2) удаление данных - с помощью оператора языка SQL DELETE;

3) изменение данных - посредством оператора языка SQL UPDATE;

4) вывод данных - в поля редактирования, с помощью оператора языка SQL SELECT и средств клиента;

Рассмотрим алгоритм работы автоматизированной системы в укрупненном виде.

Он приведен на рисунке 4.2

Рисунок 4.2 - Алгоритм взаимодействия с системой

4.5 Информационная безопасность системы

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

Отказ в обслуживании. Бывает двух типов: обычный (DoS) и распределенный (DDoS), который гораздо опаснее. Если при обычном типе атаки участие в ней принимают 1 или несколько компьютеров, то подобная атака обычно не может нанести ущерба при наличии достаточно мощного сервера и достаточно широкой пропускной способности его канала. Кроме того, достаточно средствами сервера узнать IP-адрес атакующего (это можно сделать при помощи как специальных пакетов - систем обнаружения атак (IDS), так и при помощи простых программ - анализаторов логов и сетевой активности). Затем можно средствами ОС, МСЭ или специализированными программами запретить подключения с этих адресов. Однако при распределенной атаке злоумышленник имеет большую сеть компьютеров (обычно зараженных вирусами типа «троянский конь», и владельцы их даже не догадываются о сетевой активности этих компьютеров), которым он может отдавать команды для отправки пакетов на ресурс. Такие сети называются «ботнетами» и защититься от их атаки весьма сложно. По достижению суммарной пропускной способности их каналов равенства каналу сервера он начинает заметно сбоить, а в его работе начинаются заметные задержки. По превышению пропускной способности сервер перестает успевать обрабатывать запросы и либо зависает, либо самопроизвольно завершает свою работу с ошибкой. Блокировать приходится целые подсети, что не всегда представляется возможным.

Подбор паролей. Данный тип атак производится путем перебора всех возможных комбинаций логина и пароля на какой-либо сервис или для доступа в закрытую часть сайта. Взломщик может воспользоваться как готовыми программами, такими как MyBrute для Windows или консольный переборщик hydra для UNIX-систем, так и программами собственного написания, сделанными специально для подбора пароля для входа на конкретный ресурс. Атака производится либо одним из трех типов (по словарю, посимвольный перебор, перебор с учетом известной части пароля), так и комбинированным методом. Защититься от атак можно, блокируя подключения с IP-адресов proxy-серверов, которыми пользуется взломщик, а также используя сложные пароли типа kF1pwZ86NG3t!

Атаки на уязвимые сервисы. Посредством специальных программ (например, nmap) взломщик может сделать сканирование сервисов системы («fingerprinting»), узнать их версии. Имея на руках описание свежей ошибки в одном из сервисов, взломщик может дождаться появления программы взлома под эту версию (т.н. эксплоит) либо написать подобную программу сам, что предполагает его высокую квалификацию. Наиболее профессиональные хакеры самостоятельно ищут ошибки в программном обеспечении и создают «0-day»-эксплоиты, находящиеся в распоряжении узкого круга знакомых хакера. Подобные программы являются наиболее опасными, т.к. об ошибках в ПО неизвестно более никому, а уязвимые сервисы имеют тысячи ресурсов по всему миру. Защиты от них, что естественно, найти невозможно. От обычных же эксплоитов можно защититься, постоянно следя за новостями мира информационной безопасности и устанавливая новые, безопасные версии сервисов.

Атаки на сценарии. В PHP-сценариях существует угроза локального или удаленного внедрения файлов, а также SQL-инъекции как причина двух типичных недочетов программистов. В первом случае, если программист использует в сценарии файлы, то возможно указать в качестве параметра скрипта такой путь к файлу, который будет прочтен и отображен на экране, к примеру, /etc/passwd. В случае SQL-инъекции взломщик меняет параметры скрипта таким образом, что запрос к БД становится уязвимым.

Если передается числовой параметр, то его можно заменить на -1 OR 1=1, в результате чего выполнится условие 1=1, всегда равное true, и из БД будут выбраны все данные. Также может быть использован оператор UNION, позволяющий задать еще несколько запросов вкупе к тому, который уже выполняется. Защититься от подобного можно, тщательно фильтруя содержимое переменной и приводя ее к числовому типу, после чего проверяя ее на корректность. Также можно обрезать лишние символы, к примеру, если точно известно, что параметр id не может быть более 99999, следует обрезать строку-параметр до 5 символов, после чего уже приводить ее к числу и проверять.

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

SELECT id_news, news_date, news_caption, news_text, news_id_author FROM news

WHERE news_caption = LIKE('%Test%'), где Test - строка, передеваемая в качестве параметра скрипту, то взломщик может передать следующий параметр:

text = ')+and+(news_id_author='1')/*

В результате этого внутри сценария появится запрос

SELECT id_news, news_date, news_caption, news_text, news_id_author FROM news

WHERE news_caption = LIKE('%') AND (news_id_author='1')/*%)

В этом запросе комментарий отсечет ненужные символы и будут выведены только статьи под авторством автора № 1 с любыми заголовками.

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

4.6 Разработка программно-информационного компонента. Обоснование выбора среды разработки

программный обеспечение социальный сеть

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

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

1) система должна быть надежной;

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

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

4) должна включать в себя помощь и подсказки по эксплуатации;

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

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

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

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

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

- Visual Basic Script - имеет возможности, превосходящие в клиентском плане возможности JavaScript (например, запись и чтение из файлов, навигация по файловой системе), а также является языком серверных сценариев в технологии ASP (позволяя, например, работать с БД). Однако его работоспособность на клиентской части ограничена только браузером Internet Explorer, а о недостатках ASP будет изложено ниже.

- Adobe Flash и ActionScript - технологии, позволяющие создать красочное интерактивное клиентское приложение. Однако данным решениям присуща излишняя медлительность (производительность скриптового языка ActionScript слишком мала), большой объем, занимаемый flash-роликом, сильная нагрузка на процессор клиента, а также невозможность отображения при использовании клиентом устаревшей версии flash-плеера, ОС или браузера, не поддерживающего Flash или программ, блокирующих такое содержимое (файрволлы, компрессоры трафика). Кроме того, для создания Flash-приложений требуется коммерческое приложение Flash MX.

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

В настоящее время на рынке программного обеспечения лидируют разработки open source - Apache и Internet Information Server от компании Microsoft. IIS обладает меньшей степенью защищенности, чем Apache, что обусловлено большим числом найденных в нем ошибок безопасности. Хотя его и можно загрузить бесплатно или установить сразу вместе с Windows, хостинг с IIS (а, следовательно, и Windows Server) обойдется значительно дороже (в 2-3 раза) хостинга под управлением UNIX. Кроме того, следует отметить, что IIS работает только под Windows, в то время как Apache - практически под любой современной ОС. В то же время Apache имеет весьма сложный конфигурационный файл, который необходимо редактировать вручную, а IIS - удобный графический конфигуратор.

В целом, можно сказать, что оба этих продукта равны по возможностям и отличаются лишь деталями реализации. Однако то, что связка Apache+MySQL+PHP уже давно стала классической, а также практически полное отсутствие затрат на разработку позволяет выбрать Apache как наиболее приемлемый вариант.

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

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

- SQLite - нереляционная СУБД, все данные таблиц хранятся в одном файле, а работа с ними поддерживается при помощи удобного интерфейса, поддерживающего ANSI SQL. Также необходимо отметить, что она неявляется демоном (сервисом) в обычном смысле этого слова - это встраиваемая библиотека, и в ее основе не лежит технология «клиент-сервер» - все реализуется как составная часть программного модуля. Благодаря такому устройству потребляет намного меньше памяти, чем прочие СУБД, и дает существенный выигрыш в производительности. Однако на больших объемах данных этот выигрыш исчезает. Применяется главным образом в небольших проектах, хостингах, где нет поддержки СУБД, а также в некоторых настольных приложениях.

- MySQL - СУБД, обеспечивающая высокую надежность, производительность, поддержку расширенного относительно ANSI SQL формата этого языка. Имеет хорошо продуманную внутреннюю организацию, что позволяет удобно и быстро получать данные из таблиц. Используется в средних проектах, так как на очень больших объемах данных начинает проигрывать по производительности PostgreSQL. Однако ее скорости хватает практически во всех случаях. Поддерживает все необходимые функции: разграничение полномочий, тонкое конфигурирование, служебные таблицы.

- Microsoft SQL Server - коммерческая СУБД, работающая только под Windows. Имеет удобный графический конфигуратор, поддержку большого числа форматов данных, отличную призводительность. Однако ее бесплатная версия Express Edition имеет слишком много ограничений и лишена нормального конфигуратора.

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

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

- ASP - скорее не ЯП, а серверная технология. Ее ЯП является VBScript, а выполняться такие сценарии могут лишь под управлением IIS. Ввиду использования Apache данная технология, несмотря на свою мощь и большое количество порталов, построенных на ней, нам не подходит.

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

- PHP - простой и очень мощный ЯП, поддерживающий работу со множеством СУБД, файловой системой, регулярными выражениями. Отлично подходит для работы с MySQL и Apache. Весьма производителен за счет того, что является транслирующим интерпретатором. Также удобен тот факт, что PHP позволяет внедрять HTML-содержимое внутрь сценариев, в том числе разделяя его вывод по условиям, в цикле и т.д.

4.7 Физическая модель данных

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

Таблица 4.2 - аватары (avatars)

Поле

Тип

Длина

Описание

Avatar_id

INT

11

Уникальный номер аватара

Filename

VARCHAR

100

Путь к аватару

Таблица 4.3 - фото (photo)

Поле

Тип

Длина

Описание

Link_id

INT

11

Уникальный номер ссылки

User_id

INT

11

Уникальный номер пользователя

Title

VARCHAR

255

Название фото

Url

MEDIUMTEXT

65535

Адрес фото

Descr

MEDIUMTEXT

65535

Описание фото

Catid

INT

11

Идентификатор категории

Таблица 4.4 - категории (categories)

Поле

Тип

Длина

Описание

Catid

INT

11

Уникальный идентификатор категории

Name

VARCHAR

100

Название категории

Таблица 4.5 - личные сообщения (pm)

Поле

Тип

Длина

Описание

Id_mess

INT

11

Номер сообщения

Fid

INT

11

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

Tid

INT

11

Идентификатор получателя

Title

VARCHAR

30

Тема сообщения

Message

TEXT

65535

Текст сообщения

Dt

DateTime

18

Дата и время отправки

Таблица 4.6 - данные пользователей (user_details)

Поле

Тип

Длина

Описание

Id

INT

11

Уникальный номер пользователя

Nick

VARCHAR

20

Псевдоним (никнейм)

FIO

VARCHAR

80

ФИО

Birth

INT

11

Дата рождения в формате метки времени UNIX

Avatar_id

INT

11

Уникальный идентификатор аватара

Таблица 4.7 - учетные записи пользователей (users)

Поле

Тип

Длина

Описание

Id

INT

11

Уникальный номер пользователя

Login

INT

11

Имя пользователя в системе

Password

INT

11

Пароль в зашифрованном виде

Salt

VARCHAR

30

Случайная строка, используется для шифрования пароля

Status

TEXT

65535

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

5. РАЗРАБОТКА ИНТЕРФЕСА

5.1 Описание пользовательского интерфейса и программных модулей

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

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

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

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

4) информации не должно быть слишком много, чтобы в ней было легко ориентироваться;

5) для визуального оформления и эстетически приятного восприятия информации следует вводить графические элементы - фоновые картинки и прочую графику, использовать различные шрифты;

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

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

5.2 Страница Авторизации

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

Если пользователь при входе поставит галочку «запомнить», то сценарий запишет на его ПК cookies (cookie-набор), в котором в зашифрованном виде будет сохранен пароль и логин. При следующем входе в систему пользователю не нужно будет их вводить заново.

Рис. 5.1 Страница авторизации на английском языке.

Рис. 5.2 Страница авторизации на русском языке.

5.3 Регистрация

Форма регистрации нового пользователя показана на рисунке 7

Как правило, большинство крупных сервисов при регистрации требуют ее подтверждения по email. Посмотрим, как сделать подобный механизм в ASP.NET MVC.

Рисунок 5.3 Форма регистрации на русском языке.

Рисунок 5.4. Форма регистрации на английском языке.

5.4 Домашняя страница

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

Рисунок 5.5 Страница - «Домой»

5.5 Новости

Далее пользователь, по желанию может перейти в раздел «Новости», где отображена вся деятельность его друзей. Загруженные фотографии друзей. Там же есть возможность комментировать фото.

Ваши фото также отображаются на странице новостей

Рисунок 5.6 Страница новостей.

5.7 Друзья

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

Рисунок 5.7. Страница «Друзья».

6. Тестирование ПО

6.1 Цели и задачи тестирования ПО

Целью составления плана тестирования является описание процесса тестирования программного обеспечения социальной сети «Image Poster»

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

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

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

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

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

6.2 Цель системного тестирования ПО

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

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

Целью системного тестирования ПО для социальной сети «Image Poster», является проверка функциональности, анализ результатов тестирования.

6.3 Цель интеграционного тестирования ПО

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

6.4 Последовательность системного тестирования ПО

Для проверки функциональных и нефункциональных требований к ПО были разработаны тестовые случае (Таблица 6.2).

Таблица 6.2 - Описание тестовых случаев

Тестовый случай

Описание

1

Регистрация пользователя с логином, длина которого превышает 20 символов.

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

2

Регистрация пользователя с логином, длина которого меньше 6 символов.

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


Подобные документы

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

    контрольная работа [112,5 K], добавлен 15.12.2010

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

    курсовая работа [1,3 M], добавлен 22.12.2014

  • Выбор программного средства для клиентской и серверной части. Требования к программному обеспечению. Анализ приложений "Gmote", "Remote for VLC", "Пульт MPC&VLC", "The Remote Control". Схема функционирования клиентской части. Тестирование окна управления.

    дипломная работа [1,5 M], добавлен 31.03.2013

  • Устройство соединения сегментов сети. Выбор необходимого программного обеспечения на современном предприятии. Расчет стоимости оборудования. Выбор принтеров для необходимого программного обеспечения. Структура базового технического обеспечения компании.

    презентация [492,4 K], добавлен 02.08.2015

  • Характерные особенности социальной сети. Описание социальных сетей "Facebook", "Вконтакте", "Одноклассники". Разработка собственного подобного сайта, с регистрацией профилей, загрузкой изображений, отправкой сообщений, поиском, разграничением приватности.

    курсовая работа [1,9 M], добавлен 30.01.2014

  • Обзор вариантов использования компьютерных сетей в муниципальном образовании. Компьютерные сети и их топологии. Выбор и обоснование архитектуры сети школы, её оборудование и защита. Использование программного обеспечения "1С:ХроноГраф Школа 3.0 Проф".

    курсовая работа [2,8 M], добавлен 09.11.2016

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

    презентация [2,1 M], добавлен 03.05.2015

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

    курсовая работа [48,0 K], добавлен 07.08.2013

  • Последовательность конфигурирования клиентского программного обеспечения для работы в сети. Парметры настройки и подключения сетевого принтера. Обновление конфигурации программы 1С: Предприятие. Анализ аппаратного обеспечения сети данной организации.

    отчет по практике [1,6 M], добавлен 22.01.2011

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

    курсовая работа [5,3 M], добавлен 22.12.2010

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.