Смекни!
smekni.com

Разработка интернет-приложения для организации электронной доски объявлений (стр. 1 из 6)

1. Постановка и анализ задачи

Постановка задачи: разработать интернет-приложение для организации электронной доски объявлений.

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

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

Приложение должно взаимодействовать с пользователями, то есть должно быть интерактивно, поэтому должно быть написано на одном из языков программирования web-сценариев, таких как Perl, PHP или других. Очевидно, что приложению потребуется оперировать с немалыми массивами данных, поэтому для их надежного хранения потребуется база данных, поскольку случай хранения информации непосредственно в файлах на сервере не является надежным и безопасным из-за проблем со множественным доступом. Приложение устанавливается на интернет-сервере, доступ пользователей к приложению осуществляется через WEB-интерфейс с помощью браузера, например MS Internet Explorer. Таким образом подразумевается, что работа с приложением будет вестись только через HTTP-протокол.

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

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

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

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

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

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

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

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

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

2. Разработка схемы данных

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

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

1) Статические таблицы - предназначены для хранения основных параметров электронной доски объявлений и типов объявлений. Число записей в этих таблицах в процессе работы приложения не меняется, первоначальные значения полей заносятся при инсталляции

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

Рассмотрим назначение и структуру таблиц, используемых в проекте:

1. Таблица OPTIONS.

Статическая таблица, предназначена для хранения основных параметров электронной доски объявлений, состоит из трёх полей:

id name value

id – порядковым номер записи, тип поля smallint (допустимое значение до 32767), ключевое.

name – название параметра, тип поля text (до 65535 символов)

value – значение параметра, тип text.

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

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

2. Таблица ACTION.

Статическая таблица, содержит тип объявлений, состоит всего из двух полей:

id action

id – порядковым номер записи, тип поля smallint, ключевое.

action – название типа объявления, тип поля text.

Содержание записей поля action: предложение, спрос, обмен, аренда, прочее. Значения полей задаются автоматически в процессе инсталляции и в последующем времени не изменяются.

3. Таблица SUBJECT.

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


id topic name

id – идентификатор раздела или подраздела, тип поля int (значение до 2 147 483 647), ключевое. Для того чтобы данный идентификатор был уникальным (с неповторяющимися значениями), полю назначен дополнительный тип auto_increment. При первоначальном создании таблицы значение этого поля равно единице, при добавлении новой записи его значение автоматически инкрементируется. Поскольку удаление записей из таблицы не влияет на значение этого счётчика, мы получаем уникальность идентификатора записи. Для оптимизации поиска по таблице устанавливаем тип поля index.

topic – значение идентификатора раздела каталога, тип поля int, ключевое. Если данная запись описывает не подраздел, а корневой раздел каталога, то значение поля равно 0.

name – название раздела или подраздела каталога, тип поля text.

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

4. Таблица USERS.

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

id login password contact access

id – идентификатор пользователя, тип поля int, ключевое, auto_increment, index.