98313

Проектирование и разработка информационно-развлекательного портала

Дипломная

Информатика, кибернетика и программирование

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

Русский

2015-11-02

9.09 MB

0 чел.

Проектирование и разработка информационно-развлекательного портала

Содержание


Техническое задание

  1.  Общие сведения
    1.  Полное наименование системы и её условное обозначение

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

Условное обозначение Системы – «Relax».

  1.  Плановые сроки начала и окончания работы

Разработка данной системы была начата 05.07.2010 г.

  1.  Порядок оформления работы

Стадии:

Техническое задание

а) Обоснование перспективности реализуемого проекта:

- постановка задачи;

- сбор базовых материалов;

- установка критериев системы;

- необходимость проведения исследовательских работ;

  b) Исследовательская работа:

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

   - определение требований к техническим средствам;

- обоснование практической возможности реализации данного проекта;

  в) Разработка и утверждение технического задания:

   - определение требований к проекту;

- определение стадий, этапов и сроков разработки проекта и документации на нее;

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

 2) Технический проект

  а)  разработка технического проекта:

- определение формы представления входных и выходных данных;

   - определение конфигурации технических средств;

  b) утверждение технического проекта:

   - установка плана по разработке проекта;

   - создание пояснительной записки;

-  утверждение технического проекта;  

  1.  Назначение и цели создания Системы
    1.  Назначение системы

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

  1.  Цели создания системы

В связи с основным назначением системы, можно выделить ряд целей:

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

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

  1.  Задачи создания системы

Для достижения поставленных целей предполагается решить следующие задачи:

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

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

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

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

- ведение ряда статистик (посещения внешних ресурсов, число обращений к местным данным);

- учет пожеланий, исправлений, дополнений, поступающих от пользователей портала;

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

  1.  Характеристика объекта автоматизации
    1.  Краткие сведения об объекте автоматизации

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

  1.  Технические требования к информационной системе «Развлекательный портал»
    1.  Требования к системе в целом

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

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

- структура сайта должна быть интуитивно понятна и обеспечивать соответствующие интерфейсы для получения ресурсов;

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

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

- использование промышленного программного обеспечения;

- использование общепризнанных и широко используемых стандартов и правил;

- высокая степень масштабирования системы;

  1.  Требования к структуре и функционированию системы

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

  1.  Подсистема инсталляции портала
    1.  Автоматическое разворачивание и создание всех необходимых каталогов и файлов;
    2.  Создание базы данных;
  2.  Подсистема оформления
    1.  Возможность менять настройки, касающиеся дизайна сайта, оставляя неизменной его основы;
    2.  Несущественное изменение оформление меню, карты фалов;
  3.  Подсистема ввода и размещения новостей, администрирования ее информационного наполнения включает в себя следующие функции:
    1.  добавление, редактирование, форматирование и размещение информации;
  4.  Подсистема хранения, систематизации файлов
    1.  Добавление/удаление/замена категорий, пунктов;
    2.  проверка на физическое наличие загружаемых файлов;
    3.  выставление рейтинга популярности и возможности оставления комментариев незарегистрированным пользователям с защитой от ботов;
    4.  прием пожеланий по поводу размещения и добавления файлов;
  5.  Подсистема авторизации и операций с аккаунтами
    1.  Система регистрации и опознавания пользователей;
    2.  Деление всех пользователей на следующие группы:
      1.  Администратор – имеет доступ к базе данных, доступ к аккаунтам пользователей, шаблоны отправляемых писем, манипуляции с файлами загрузки, права на полный контроль над чатом, добавление игр на игровой раздел;
      2.  Зарегистрированный пользователь – доступ к своему профилю, возможность добавления файлов;
      3.  Редактор разделов – добавление/удаление/перемещение  разделов, все операции с новостями, с содержанием раздела;
      4.  Модератор – чата, возможность удаления сообщений/тем, блокировки пользователей;
  6.  Подсистема кабинета клиента:
    1.  Редактирование профиля: пароль, личные данные, список открытых сведений о нем, смена аватара, рейтинг популярности;
    2.  Создание тем, добавление файлов, оставлять сообщения организации сайта;

  1.  Подсистема развлекательной страницы:
    1.  Разбиение по жанрам и темам;
    2.  Создание краткого описания к размещаемым переходам;
    3.  Возможность комментирования;

  1.  Требования к численности и квалификации персонала

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

В состав персонала, необходимого для обеспечения эксплуатации Системы, должны входить:

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

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

  1.  Требования к приспособляемости и масштабируемости системы

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

- при изменении количества потребителей информации;

- при изменении количества поставщиков информации;

  1.  Разделение доступа

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

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

-добавление элементов;

-редактирование элементов;

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

  1.  Управление доступом пользователей к системе

Для управления доступом пользователей к ресурсам администратор Системы должен иметь возможность выполнять следующие действия:

- просматривать список пользователей Системы;

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

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

  1.  Требование эксплуатации

Данный будет работать под управлением сервиса TomCat и использовать MsSQL сервер для поддержания баз данных, соответственно необходимо  наличие данных программных средств, установленных на эксплуатируемом сервере. Так же сервер должен иметь установленный Java интерпретатор и соответствующий пакет классов JRE.

  1.  Общие требования к информации

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

- структурированность. Информация на Портале должна быть четко структурирована и доступна для нахождения; 

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

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

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

  1.  Статистика

Для определения эффекта от создания Internet-портала необходимо выделить следующие параметры:

- число посещений в единицу времени;

- география посещений;

- число зарегистрировавшихся пользователей.

  1.   Состав и содержание работ по разработке системы

Стадии разработки          Срок выполнения

1 Исследование предметной области задачи   

2 Согласование и утверждение технического задания

3 Проектирование   

4 Защита проекта   

  1.   Состав и содержание работ по созданию системы

Документ «Техническое задание» должен быть выполнен в соответствии с документом «ГОСТ 19.106-78 разработку программы или программного изделия для вычислительных машин».

Графические документы должны представлять собой диаграммы, составленные на Унифицированном Языке Моделирования (Unified Modeling Language), который предоставляет объектно-ориентированный метод разработки программного обеспечения с поддержанием объектно-ориентированной реализации.

  1.  
    Исследовательская часть
    1.  Обоснование выбора СУБД

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

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

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

1) поддерживаемый размер базы данных:

- несколько мегабайт: MS Access, XML, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL

- до сотни мегабайт: MS Access, Парадокс, Dbase, Foxpro/VFP, MySQL, PostgreSQL, Interbase

- гигабайты: MySQL, PostgreSQL, Interbase, Informix, MS SQL Server, Oracle, SyBase,

- сотни гигабайт и больше: MS SQL Server, Oracle, SyBase

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

2) Количество одновременных пользователей

- доступ одного пользователя: MS Excel, Парадокс, Dbase, MS Access, MySQL, PostgreSQL

- до десятка пользователей: Парадокс, Dbase, Foxpro/VFP, MS Access, MySQL, PostgreSQL

- несколько десятков пользователей: MySQL, PostgreSQL, Interbase, Informix

- сотни пользователей: PostgreSQL, Interbase, MS SQL Server, Oracle, SyBase, DB/2

- тысячи пользователей: MS SQL Server, Oracle, SyBase, DB/2

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

3) Цена базы данных

- полностью бесплатно:  MySQL, PostgreSQL, Interbase (некоторые клоны)

- формально бесплатен: MS Excel, Парадокс, Dbase, Foxpro/VFP, MS Access

- дешёвые сервера: Interbase (некоторые клоны), Informix, старые версии SyBase

- дорогие сервера: MS SQL Server, Oracle, SyBase

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

4) Защита данных

- никакая: MS Excel

- слабая: Парадокс, Dbase, Foxpro/VFP, MS Access

- сильная: MS SQL Server, Oracle, SyBase, DB/2, Interbase, Informix, MySQL, PostgreSQL

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

5) Платформа 

- Windows only: MS SQL Server, SyBase, Парадокс, Dbase, Foxpro/VFP, MS Access, MS Excel

- Unix/Linux only: PostgreSQL

- Windows+Linux: Oracle, DB/2, Interbase, MySQL, SyBase

Разъяснение: несомненно, что большинство серверов работают под управлением Unix-подобных систем, но для России так же характерно большое распространение Windows-серверов, поэтому желательно чтобы СУБД работала под обе платформы.

6) Мощность языка SQL, возможности базы данных (View, Stored procedures, agents, backup, репликации и т.п)

- очень слабые: MS Excel

- слабые: Парадокс, Dbase, Foxpro/VFP, MS Access, MySQL

- развитые: Interbase, Informix, PostgreSQL

- мощные:MS SQL Server, Oracle, SyBase, DB/2

Разъяснение: весьма большим плюсом для СУБД является уже реализованные возможности по резервированию данных, ведению журналов и создания backup с возможностью сохранения не только на локальной машине. Это повышает ее отказоустойчивость и обеспечивает наилучшую сохранность данных пользователя.

7) Требования к параметрам сервера:

- неприхотливые: MySQL, PostgreSQL, Парадокс, Dbase, Foxpro/VFP, MS Access,MS Excel

- чувствительные: Interbase, Informix, SyBase

- требуют отдельных мощных серверов: MS SQL Server, Oracle, DB/2

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

8) Сложность настройки, установки, администрирования, желательность специально обученного персонала для администрирования:

- никаких сложностей, администрирование не требуется: MS Excel, XML, CSV

- минимальные либо небольшие сложности: Парадокс, Dbase, Foxpro/VFP, MS Access

- первоначальная настройка плюс минимальная поддержка: PostgreSQL, MySQL

- требуются специальные знания в достаточно большом объёме: Interbase, Informix

- желательно наличие специалиста по базам данных: MS SQL Server, Oracle, SyBase

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

В итоге в рассмотрение были взяты 2 СУБД: MySQL и PostgreSQL. По многим параметрам они схожи, но PostgreSQL выигрывает по многим ключевым параметрам, таким как полная поддержка стандарта ANSI SQL92, поддержка транзакций и мощность языка. Но выбор останавливается на MySQL, так как последний является мультиплатформенным. Но стоит отметить, что оба языка имеют драйвера jdbc, что позволит в дальнейшем сменить сервер БД на более мощный PostgreSQL без значительных преобразований самого проекта.

  1.  Обоснование выбора  сервлетов или CGI-скриптов

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

В ранних версиях Web-сервер мог динамически конструировать страницу, создавая отдельный процесс для обработки каждого запроса клиента. Чтобы получать необходимую информацию, процесс мог открывать соединения к одной или нескольким базам данных. Он обшался с Web-сервером через интерфейс, известный как Common Gateway Interface (CGI). CGI позволял отдельному процессу читать данные из HTTP-запроса и записывать данные в HTTP-ответ. Для построения CGI-программ использовался ряд различных языков, включая С, C++ и Perl.

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

Сервлеты обеспечивают несколько преимуществ по сравнению с CGI-интерфейсом:

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

- Сервлеты не зависят от платформы, потому что они написаны на Java. Несколько Web-серверов от таких поставщиков, как Sun, Netscape и Microsoft, предлагают Scrvlet API. Программы, разработанные для этого API, могут быть перемешены в любую из указанных сред без перетрансляции.

- Менеджер безопасности Java (Java Security Manager) на сервере поддерживает набор ограничений для зашиты ресурсов на машине сервера.

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

  1.  Обоснование выбора  Web-сервера

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

Apache Tomcat— возможно, наиболее популярный Java-ориентированный Web-сервер и контейнер сервлетов. Это относительно облегченный контейнер сервлетов, популярность которого за последние несколько лет существенно возросла. Выбор пал на этот продукт потому, что с ним уже знакомо достаточно много разработчиков. Сервер Tomcat также может быть заменен на более надежный Web-сервер или сервер приложений, такой как WebLogic от ВЕА.

  1.  Обоснование выбора  дополнительных технологий

Среда Hibernate — это объектно-реляционная (Object-to-RelationalOR) отказоустойчивая среда выполнения Java. Она вполне может подойти для разработчиков Java средней квалификации, а не только экспертов по технологиям OR. Сейчас Hibernate — возможно, наиболее широко используемая среда выполнения OR в мире разработчиков Java. Она также является хорошей альтернативой Entity Beans, что, вероятно, послужило одной из причин того, что EJB 3 имеет теперь много методов из Hibernate (JDO и Toplink). Исходя из этого, мое решение использовать Hibernate было даже проще, чем выбор среды выполнения Web.

Среда Spring Framework, содержащая большое количество классов и пакетов, была разработана как модульная среда, которая может быть поэтапно или частично введена в проект, т.е. использованы будут только необходимые средства (например, среда выполнения Web). Среда Spring дополняет систему Java/JEE, предоставляя контейнер инверсии управления (Inversion of ControlIoC), среду выполнения Web, слой абстракции управления транзакциями, вспомогательные классы JDBC, API планирования задач, возможности электронной почты и многое другое.

Среда Spring является лидером в области контейнеров IоС; однако и ее среда выполнения Web также удивительно популярна. Spring была выбрана в качестве среды выполнения Web потому, что необходимы также и другие ее возможности, такие как IоС, управление транзакциями, электронная почта, планирование и т.д. Среда выполнения Web Spring MVC не имеет аналогов в области отказоустойчивости и гибкости.

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

Рис 1. Взаимодействие технологий

  1.  
    Конструкторская часть

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

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

- общие сведения о пользователе;

- контактная информация;

- статистика активности;

- роли, назначенные пользователю;

- данные для его аутефикации;

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

- наименование ролей;

- список всевозможных операций;

Рис. 2 Схема данных пользователя

Для удобной работы с новостями потребуется отдельная таблица, включающую:

- непосредственно информацию;

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

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

Рис. 3 Схема данных новостей

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

- наименование критерия;

- ссылка на критерий внешнего уровня или идентификатор корневого критерия;

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

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

- сообщение;

- дата добавления;

- идентификатор файла;

И, непосредственно, таблица файлов:

- название файла;

- ссылка на пользователя, добавившего его;

- ссылка на таблицу критерий;

- физическое расположение файла или его ссылка.

- является ли локальным;

- описание;

Рис. 4 Схема данных файлов

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

Таким образом для групповых чатов структура таблицы выглядит следующим образом:

- идентификатор комнаты

- название комнаты

- пароль (в том случае, если является приватной)

- файл, с которым связан данный чат

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

Чтобы связать пользователей и чаты, введена промежуточная таблица:

- идентификатор комнаты или чата

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

- логическое значение, позволяющее определить заблокирован ли пользователь для этого группового чата

Рис. 5 Схема данных чата

  1.  Прототип пользовательского интерфейса

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

Рис. 5  Вид основного меню

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

Рис. 6 Последовательность экранов

  1.  Алгоритмы

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

Рис. 7 Добавление ресурса на сервер

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

Рис. 8 Формирование древа каталогов

Рис. 9 Раскрытие каталога

  1.  Описание логической структуры классов и функций приложения
    1.  Описание обслуживающих классов

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

- таблица «пользователи» - класс Users:

Поля:  id,  id_prof,  mail, statistics, photo, reg_date, block, password, login;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «профили» - класс Profile:

Поля: id, name, red_users, red_news, red_files, red_desing;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «новости» - класс News:

Поля: id, author_id, add_date, head, text, show_new;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «каталоги» - класс Types:

Поля: id, id_next, title;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «файлы» - класс Files:

Поля: id, id_user, id_type, file_name, description, is_local;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «комментарии к файлам» - класс CommentsFiles:

Поля: id, id_user, id_file, text, add_date;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «групповые чаты» - класс ChatRoom:

Поля: id, name, password, file, id_moderator;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

- таблица «связь пользователь-чат» - класс Users_chats:

Поля: id, id_user, id_chat, id_block;

Методы: конструктор по умолчанию; «геттеры» и «сеттеры полей»;

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

Соответственно были созданы конфигурационные файлы «мэпинга» - правила отражения объектов в записи таблиц, наделением их специализированными свойствами. Так же был создан конфигурационный файл для Hibernate.

- hibernate.cfg – файл описывает используемый диалект, параметры подключения к базе данных (логин, пароль, имя базы, используемый драйвер), классы самого Hibernate и другое;

- Users.hbm – файл отражения класса Users в таблицу «пользователи»;

- Profile.hbm - файл отражения класса Profile в таблицу «профили»;

- Types.hbm - файл отражения класса Types в таблицу «каталоги»;

- News.hbm - файл отражения класса News в таблицу «новости»;

- Files.hbm - файл отражения класса Files в таблицу «файлы»;

- CommentsFiles.hbm - файл отражения класса CommentsFiles в таблицу «комментарии к файлам»;

- ChatRoom.hbm - файл отражения класса ChatRoom в таблицу «групповые чаты»;

- Users_chats.hbm - файл отражения класса Users_chats в таблицу «групповые чаты»;

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

Поля: sessionFactory – сессия Hibernate;

Методы: buildSessionFactory – создание подключенияж

Далее для удобного управления и манипулирования данными базы данных были созданы соответствующие классы-менеджеры, выполняющие основные запросы к базе и выдающие результат в форме объектов:

UsersManager

Методы:

getHourlyUsers – получение всех данных из таблицы в виде списка объектов Users;

getByLoginPassword – получение пользователя из базы по его логину и паролю;

getByLogin – поиск пользователей с данным логином;

blockById – заблокировать пользователя с данным идентификатором;

changeProfile – меняет роль (профиль) пользователя на указанный;

getById – возвращает пользователя по идентификатору;

getHTTPbyID – возвращает данные пользователя по идентификатору в виде строки, содержащей HTML код и предназначенный для размещения на странице;

add – добавляет запись в таблицу, соответствующую объекту;

Update – обновляет запись в таблице, соответствующую объекту Users;

ProfileManager

Методы:

getHourlyProfiles - получение всех данных из таблицы в виде списка объектов Profiles;

getProfilesById – получение роли из базы данных по идентификатору;

getHourlyProfilesInSelectTag – получение ролей из базы данных в виде строки, содержащий HTML код всплывающего списка ролей;

NewsManager

Методы:

getHourlyNews - получение всех данных из таблицы в виде списка объектов News;

getHourlyCurrentNews – получение списка объектов News, которые отображаются на главной странице;

getHourlyOldNews – получение списка объектов News, которые не отображаются на главной странице;

add - добавляет запись в таблицу, соответствующую объекту News;

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

blockById – убирает с вывода на главную страницу;

TypesManager

Методы:

getHourlyTypes - получение всех данных из таблицы в виде списка объектов Types;

getById – получение класса каталог по идентификатору;

getSubDir – получение в виде списка объектов каталога, находящихся в заданном;

add - добавляет запись в таблицу, соответствующую объекту;

Update - обновляет запись в таблице, соответствующую объекту Types;

Delete – удаляет запись из таблицы, соответствующую  объекту Types;

FilesManager

Методы:

getHourlyFiles - получение всех данных из таблицы в виде списка объектов Files;

getById  – получение класса файл по идентификатору;

getById_type – получение списка объектов файл, содержащихся в каталоге с заданным идентификатором;

add - добавляет запись в таблицу, соответствующую объекту Files;

Update - обновляет запись в таблице, соответствующую объекту Files;

Delete – удаляет запись из таблицы, соответствующую  объекту Files;

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

- поиск лишь по определенным каталогам

- искать ключевые слова лишь в названии

- искать ключевые слова лишь в описании

- искать везде

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

SaveFile

Поля:

header – информация не касающаяся содержания файла;

boundary – граница разделения полей внутри потока;

beginSliceIndex – начальный индекс содержания файла в потоке;

endSliceIndex; - конечный индекс содержания файла в потоке;

Методы:

extractData – извлечение массива байтов содержания файла;

getBoundary – получение границы разделения полей;

getFileName – выделение имени файла в заголовке;

CommentsFilesManager

Методы:

getById – получение класс комментарий файла по идентификатору;

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

add - добавляет запись в таблицу, соответствующую объекту CommentsFiles;

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

Update - обновляет запись в таблице, соответствующую объекту CommentsFiles;

Delete – удаляет запись из таблицы, соответствующую  объекту CommentsFiles;

ChatRoomManager

Методы:

getById – получение класс групповой чат по идентификатору;

add - добавляет запись в таблицу, соответствующую объекту ChatRoom;

Update - обновляет запись в таблице, соответствующую объекту ChatRoom;

Delete – удаляет запись из таблицы, соответствующую  объекту ChatRoom;

GetChatFile – возвращает файл, ассоциированный с данным чатом, для  заполнения разговора для вновь присоединившихся пользователей;

CheckPassword – проверяет соответствует ли введенный пользователем пароль тому, что установлен для данного чата по соответствующему идентификатору;

ModeratorCommand – анализатор команд, посланных модератором или другим пользователем чата, и вызов соответствующих команд для их выполнения, так же выполняет проверку на права выполнения данных команд;

BlockUSer – блокирует пользователя по нику (каждому в соответствие ставится его идентификатор);

SendPrivate – отправка индивидуального сообщения выбранному пользователю;

ClearFile – выполняет чистку файла при превышении им 300 кб

UsersСhatsManager

Методы:

getByIdUser – получение списка классов группового чата, к которым подключен пользователь по идентификатору пользователя;

getByIdChat – получение списка классов пользователей,  которые подключены к данному чату по идентификатору чата;

add - добавляет запись в таблицу, соответствующую объекту Users_Chats;

Update - обновляет запись в таблице, соответствующую объекту Users_Chats;

Delete – удаляет запись из таблицы, соответствующую  объекту Users_Chats;

 BlockUser – блокирует пользователя для данного чата по идентификатору пользователя и чата;

ValidationManager

Класс, занимающейся проверкой корректности данных во всем проекте.

Методы:

checkLogOnName – проверяет указанное имя пользователя на уникальность;

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

checkFileName – проверяет имя файла на наличие недопустимых символов

checkLink – проверяет введенные пользователем ссылки на наличие синтаксических ошибок – чтобы  они соответствовали ссылкам на файлы

checkFolders -  отслеживает соответствие записи папок, присутствующих в БД и их физическое наличие на сервере

  1.  Описание классов, реализующих основную логику

AddFile – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Поля:

usersFileDir – директория в корневом каталоге проекта для размещения ресурсов;

Методы:

service – выполняет такие действия как:

- проверка прав доступа клиента;

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

- запись присланного ресурса на сервер в нужную директорию и делает соответствующую запись в базе данных «файлы»;

- обновляет статистику клиента, добавившего файл в таблице «пользователи»;

AddPhoto – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Поля:

usersPhotoDir – директория в корневом каталоге проекта для размещения фотографий пользователей;

Методы:

service – выполняет такие действия как:

- проверка прав доступа клиента;

- запись присланного файла на сервер в определенную директорию и делает соответствующую запись в базе данных «пользователи»;

getTypeFileByName – получает расширение файла из его названия;

 

Registration – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Методы:

service – выполняет такие действия как:

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

- добавление записи в таблицу «пользователи»;

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

- обновление таблицы «пользователи»;

Authorization – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Методы:

service – выполняет такие действия как:

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

AuthorizationManager – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Методы:

service – выполняет такие действия как:

- анализ действий выполняемых клиентом (авторизация, выход из своего профиля) и в зависимости от этого – переход к соответствующему сервлету;

- заполнение полей сессии данными клиента;

 

CommentsEdit – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента

Методы:

service – выполняет такие действия как:

- проверка прав доступа клиента;

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

CreateFileList – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

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

- формирование древа каталогов по уровням;

- раскрытие выбранного каталога по уровням;

- показ содержимого каталога;

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

- показ дополнительной информации о файле;

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

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

FileDownload – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

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

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

FileEdit – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

- выполняет редактирование каталогов – их перемещение по уровням и переименование;

- выполняет редактирование файлов – их переименование и изменение описания;

- выполняет обновление таблиц, соответственно «каталоги» либо «файлы»;

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

 

AjaxManagerFiles – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

- удаление и добавления каталогов;

- удаление файлов;

- выполняет обновление таблиц, соответственно «каталоги» либо «файлы»;

AjaxManagerNews – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

- добавления новостей;

- выводить ли новость на главную страницу;

- выполняет обновление таблицы «новости»;

AjaxManagerUsers – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

- блокирование акаунта пользователя;

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

- просмотр полной информации о пользователе;

- выполняет обновление таблицы «пользователи»;

AjaxManagerСhat – является наследником класса HttpServlet – сервлет, обрабатывающий запросы клиента.  

Методы:

service – выполняет такие действия как:

- блокирование/разблокирование пользователя;

- создание/удаление чата;

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

- анализ на наличие команд;

- контроль за файлами чатов;

- присоединение/удаление пользователя из чата;

  1.  Описание файлов JavaScript

XMLHttpRequest  

Функции:

createReqObj – в зависимости от браузера возвращает объект, реализующий запрос на сервер;

bdAdmin  

Функции:

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

blockRow – получает идентификатор пользователя  – посылает данные на обработку сервлету для блокировки или разблокировки пользователя;

showRow – получает идентификатор пользователя – посылает данные на обработку сервлету для получения всей информации о пользователе – полученные данные вставляет в соответствующую строку;

newsAdmin

Функции:

addNews – формирует форму для заполнения новой новости;

blockRow – получает идентификатор новости – посылает данные на обработку сервлету для блокировки или разблокировки новости;

postNews – посылает данные новой новости сервлету для ее добавления;

fileAdmin

Функции:

remFolder  – формирует форму для удаления каталога;

addFolder  – формирует форму для добавления каталога;

postFolderRemove– посылает данные удаляемого каталога сервлету для его удаления;

postFolder – посылает данные нового каталога сервлету для его добавления;

fileCommentsAdmin

Функции:

delComment – посылает идентификатор удаляемого комментария сервлету для его удаления;

fileActions

Функции:

delFile – посылает идентификатор удаляемого файла сервлету для его удаления;

clock

Функции:

initTag – выполняет формирование необходимой структуры для вывода часов;

setjpg – подгружает необходимые изображения цифр;

clockTick – выполняет ежесекундное обновление формы, согласно текущему времени;

chatRoom

Функции:

createChat – посылает необходимую информацию для создания чата;

deleteChat – посылает необходимую информацию для создания чата;

connectChat – посылает необходимую информацию для соединения с выбранным чатов

disconnectChat – посылает необходимую информацию для разрыва соединения с данным чатов

sendMessage – отсылка сообщения в нужный чат

refreshChats – систематически обновляет список чатов

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

  1.  Описание логической структуры jsp страниц
    1.  Страницы, относящиеся к администрированию 

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

fileAdmin – страница  содержит скриплет, выполняющий запрос к базе данных по выборке древо каталогов и формы для их редактирования, добавления и удаления папок;

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

desingAdmin – страница содержит скриплет, выполняющая поиск всех файлов, относящихся к дизайну сайта и предоставляет возможность их удаления, а так же замены css файла стиля и отката к предыдущей версии файла, выводит форму для загрузки новых файлов, связанных с дизайном страницы;

  1.  Части, общие для всех страниц 

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

headFiles – часть заголовка страницы для раздела «файлы»;

headMain – часть заголовка страницы для раздела «главная»;

headSearch – часть заголовка страницы для раздела «поиск»;

headChat– часть заголовка страницы для раздела «чат»;

kategory – часть страницы  получения переходов по возможным разделам редактирования для администраторов;

reklama – часть страницы с рекламой;

end – содержит нижнюю часть всех страниц;

contacts – часть страницы, содержащей информацию о разработчике;

notFound – страница выводится для тех разделов, которые еще не реализованы в проекте;

  1.  Страницы, относящиеся к работы с профилем пользователя 

regUser – страница содержит форму для регистрации пользователя;

addPhoto – форма для выбора аватара пользователя;

editUser – страница  содержит скриплет для получения данных о пользователе и заполнение формы с полученными данными для их редактирования;

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

welcome_user - страница содержит скриплет, который в зависимости от действий пользователя (вход, выход, ошибка входа) выводит соответствующие сообщения;

  1.  Страницы, относящиеся к разделу файлы 

files – страница  содержит скриплет, который в зависимости от извлеченных данных включает блок со сформированным древом каталогов;

addFile – страница содержит скриплет, который в зависимости от типа выбранного ресурса предоставляет ту или иную форму для заполнения;

editFile – страница  содержит форму для заполнения первичной информации о загружаемом ресурсе;

editFilesAtributions – страница  содержит форму для редактирования информации о загруженном ресурсе;

filesShow – страница  одержит скриплет, который получает и раскрывает полную информацию о файле, включая комментарии к нему;

  1.  Страницы, относящиеся к разделу поиск

search – страница  содержит скриплет, который в зависимости от критериев поиска выводит список всех найденных файлов, здесь же содержится форма для поиска;

  1.  Страницы, относящиеся к разделу чат

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

  1.  
    Технологическая часть
    1.  Руководство пользователя

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

  1.  Регистрация нового пользователя и редактирование профиля 
  2.  На главной странице необходимо перейти по ссылке 1 (рис.1). Заполнить форму регистрации и нажать кнопку «Принять» (рис.2). Если регистрация прошла успешно, то можно на главной странице ввести введенные данные (ссылка 2), указанные на предыдущей странице (рис. 1).
  3.  Если авторизация произошла успешно, то появится страница приветствия (рис. 3) или ошибки (рис. 4) .
  4.  Для изменения профиля необходимо перейти по ссылке 3 (рис. 3). На форме указать предыдущий пароль и внести изменения в данные, для смены фотографии перейти по ссылке 4 (рис. 5) В предложенной форме выбрать фото и нажать «Приять» (рис. 6).
  5.  Для выхода из профиля нажать кнопку «Выход» (рис. 3).
    1.  Раздел файлы 

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

  1.  Для просмотра каталогов – в верхней панели перейти по ссылке 5 (рис. 1).
  2.  Слева выбрать интересующий каталог. При нажатии на выбранный каталог произойдет раскрытие каталога (если таковой имеет подпапки). Уровни каталогов обозначаются отступом справа «--». Если выбранная папка содержит файлы, то в центре отобразится таблица с названием, описанием и действиями доступными к этому ресурсу.
  3.  Для  того, чтобы получить ресурс – необходимо перейти по ссылке «скачать» (ссылка 6 рис .7) напротив выбранного ресурса.
  4.  Для просмотра всей информации о ресурсе нужно перейти по ссылке «просмотр» (ссылка 6 рис .7) напротив выбранного ресурса - откроется страница по типу рис. 8.
  5.  Для просмотра информации о пользователе, добавившего ресурс или комментарий к нему, необходимо перейти по одной из ссылок 7 (рис. 8). Откроется страница с данными пользователя (доступно для зарегистрированных пользователей) (рис. 9)
  6.  Можно оставить комментарий к ресурсу: заполнить текстовое поле и нажать кнопку «Принять» (ссылка 8, рис. 8).
  7.  Для добавления собственного ресурса – перейти по ссылке 9 (рис. 7). Затем заполнить данные форме, включающую тип ресурса и его описание и нажать кнопку «Далее» (рис. 10). Далее по типу страницы добавления фотографии (рис. 6) – выбрать файл и нажать «Принять».
  8.  Для файлов, которые были загружены вами, появляется дополнительная опция по редактированию их отображаемого имени и информации о них. Для этого необходимо перейти по ссылке 10 (рис. 11)  и исправить данные формы по типу рис. 10.
    1.  Раздел чаты

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

  1.  При открытии данного пункта в правой части можно увидеть раскрывающийся список всех  созданных чатов, разделенных на 2 категории (рис.20, ссылка 24):
    1.  Общедоступные чаты – к которым можно присоединиться и тут же начать участие в беседе
    2.  Закрытые чаты – к которым можно присоединиться, предварительно указав пароль, заданный создателем чата
  2.  Ввод сообщений и команд можно вводить в нижнее текстовое окно в каждом чате (рис.21, ссылка 25), так же по вкладкам осуществляется переход по открытым чатам
  3.  Первоначально всегда открыт чат «Гостевая», где происходить обслуживание пользователей:
    1.  !create <имя чата> !pass <пароль для чата> - создаст новый чат с указанным именем и паролем, пароль можно опускать, тогда создастся открытый чат
    2.  !kick <имя пользователя> - закрывает чат для указанного пользователя (блокирование происходит на время 30 мин)
    3.  !send <пользователь> <текст сообщения> - отсылает указанному пользователю индивидуальное сообщение, используется, например, для сообщения пароля для закрытого чата

  1.  Руководство администратора
    1.  Администратор пользователей 

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

  1.  Блокирование акаунта осуществляется путем нажатия ссылки 11 (рис. 12) «Блок./Разблок», напротив соответствующего пользователя. При этом должна изменится ячейка статуса пользователя
  2.  Для просмотра всей информации о пользователе необходимо нажать ссылку 12 (рис. 12) – произойдет перестройка строки по типу рис. 13.
  3.  Для назначения новой роли пользователю – необходимо выбрать из выпадающего списка необходимую роль и нажать «Применить» (ссылка 13, рис. 13)
    1.  Администратор новостей 

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

  1.  Чтобы определить будет ли новость выводится на главной странице, необходимо нажать на ссылку 14 (рис. 14) напротив соответствующей новости. При этом должна произойти смена состояния новости.
  2.  Возможен вывод на экран лишь активных или лишь скрытых новостей – для этого из выпадающего списка выбрать необходимое и нажать «Принять» (ссылка 15, рис. 14).
  3.  Для добавления новости нажимаем на ссылку 16 (рис. 14) и заполняем форму. Поля заголовок и текст обязательны к заполнению, остальные поля сервлет может заполнить самостоятельно, подставив текущего пользователя и текущую дату.
    1.  Администратор каталогов и файлов

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

  1.  Чтобы изменить информацию о каталоге необходимо выбрать из выпадающего списка родительский каталог, изменить название каталога и нажать кнопку «Ок» (ссылка 17, рис. 15) – все элементы располагаются напротив соответствующих элементов. Корневой каталог  - это каталог Root.
    1.  Чтобы удалить каталог – необходимо нажать ссылку 18 (рис. 15) «Удалить папку» и в появившейся форме, в выпадающем списке выбрать необходимый каталог и нажать «Принять». Стоит отметить, что все файлы в данном каталоге будут так же удалены, а подкаталоги перейдут на верхний уровень.
    2.  Чтобы добавить каталог – необходимо нажать ссылку 18 (рис. 15) «Добавить новую папку» и в появившейся форме заполнить все поля и нажать «Принять». После этого должно появиться сообщение о том что «Папка успешно добавлена». Для того увидеть вновь созданный каталог в дереве,  необходимо перегрузить страницу.
    3.  Администратор каталогов и файлов имеет возможность удалять и редактировать ресурсы. Так в разделе «Файлы» администратор имеет возможность удалять любые ресурсы (ссылка 19, рис.16). При этом должно появиться сообщение «Файл успешно удален».
    4.  Администратор каталогов и файлов так же имеет возможность удалять комментарии к файлам. Для этого необходимо нажать «Просмотр» любого ресурса и нажать ссылку 20 (рис. 17) «Удалить комментарий» под ненужным комментарием. При этом должно появиться на месте ссылки сообщение «Комментарий успешно удален»
      1.  Администратор дизайна

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

  1.  Чтобы удалить какой-либо файл, не нужный для дизайна, необходимо нажать «Удалить», напротив соответствующего файла. Пример ссылка 22, рис.18
  2.  Для добавления файла (за исключением *.сss) мы выбираем его в обозревателе и нажимаем «Принять». Выбранный файл загрузится в нужный каталог на сервере. Пример ссылка 21, рис.18
  3.  Заменить таблицу стилей (*.css) можно способом, описанным в пункте 2
  4.  Стоит отметить, что всегда можно вернутся к старому шаблону, который неявно сохраняется на сервере. Это возможно будет, конечно же, при наличие всех необходимых файлов ресурсов. Для возврата к предыдущему *.css нажимаем кнопку «Откатить» ссылка 23, рис.19
  5.  
    Литература
  6.  Анил Химраджани - Гибкая разработка приложений на Java с помощью Spring, Hibernate и Eclipse, «Вильямс», 2008. – 352 с.
  7.  Браун, Ханикатт - HTML 3.2 в подлиннике, Москва – 1300 с.
  8.  Брюс У. Пери - Java сервлеты и JSP. Сборник рецептов, КУДИЦ-ПРЕСС, 2006. - 768 с.
  9.  Гари Мак – Hibernate Tutorial, 2006 г. – 9 с.
  10.  Герберт Шилдт - Полный справочник по Java SE6.
  11.  Пери - Java сервлеты и JSP: сборник рецептов, Кудиц-образ, 2001 г. – 768 с.
  12.  П.Ноутон, Г.Шилдт. JAVA 2, Москва, 2004. – 1034 с.
  13.  Ричард Вагнер Аллен Вайк -  Java Script, Москва, 2001 г. – 454 с.
  14.  Хорстман, Корнелл - Java 2 Библиотека профессионала, т.1 Основы, 7-изд, «Вильямс», 2007. – 896 с.
  15.   Хорстман, Корнелл - Java 2 Библиотека профессионала  т.2 Тонкости программирования, 7-изд, «Вильямс», 2007. – 1168 с.

Интернет источники:

  1.  tutorials.javadev.ru/index.html
    1.  www.w3schools.com
      1.  www.ibm.com
        1.  samsonov.bn.by/lib/hibernate
        2.  www.sql.ru

  1.  
    Приложение 1. Изображения, упоминаемые в документе

Рис. 1 Главная страница

Рис. 2 Форма регистрации

Рис. 3 Форма приветствия

Рис. 4 Ошибка авторизации

Рис. 5 Редактирование профиля

Рис. 6 Добавление аватара

Рис. 7 Раздел Файлы

Рис. 8 Просмотр выбранного ресурса

Рис. 9 Просмотр пользователя

Рис. 10 Добавление ресурса

Рис. 11 Редактирование загруженного файла

Рис. 12 Администратор пользователей

Рис. 13 Просмотр пользователя

Рис. 14 Администратор новостей

Рис. 15 Администратор файлов

Рис. 16 Удаление файлов

Рис. 17 Удаление комментариев

Рис. 18 Администратор дизайна

Рис. 19 Возврат к предыдущему дизайну

Рис. 20 Просмотр и создание чата

Рис. 21 Переключение между чатами и управление

PAGE  5


 

А также другие работы, которые могут Вас заинтересовать

70623. Внутренние стрелки 216.25 KB
  Для связи работ между собой используются внутренние стрелки то есть стрелки которые не касаются границы диаграммы начинаются у одной и кончаются у другой работы. Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту например...
70625. Инструментальная среда BPwin 150.84 KB
  Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере cseсредства BPwin. BPwin поддерживает три методологии моделирования: функциональное моделирование IDEF0; описание бизнес-процессов IDEF3...
70626. Синтетическая методика 34.72 KB
  Под лучшим описанием в данном случае понимается наименьшая ошибка при попытке по полученной модели предсказать поведение реальной системы. На уровне общего описания системы функциональные методики допускают значительную степень произвола в выборе общих интерфейсов системы...
70627. Объектно-ориентированная методика 38.73 KB
  Объектно-ориентированный подход использует объектную декомпозицию при этом статическая структура описывается в терминах объектов и связей между ними а поведение системы описывается в терминах обмена сообщениями между объектами.
70628. Функциональная методика потоков данных 38.4 KB
  Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных процессы работы преобразования входных потоков данных...
70629. Функционально-ориентированные и объектно-ориентированные методологии описания предметной области 48.7 KB
  Функциональные методики наиболее известной из которых является методика IDEF рассматривают организацию как набор функций преобразующий поступающий поток информации в выходной поток. Функциональная методика IDEF0 Методологию IDEF0 можно считать следующим этапом развития хорошо...
70630. Функциональная структура 38.65 KB
  Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы материальные денежные информационные.