Разработка сайта для редакции газеты «Химик»

• ВВЕДЕНИЕ
• 1. ИНФОРМАЦИОННЫЙ ОБЗОР РЕШЕНИЙ
• 1.1 Сущность и функции ресурса СМИ
• 1.2 Анализ продукта компании FarbaSite CMS
• 1.3 Анализ продукта Joomla CMS
• 1.4 Постановка задачи
• 2. ВЫБОР МЕТОДА РЕШЕНИЯ ЗАДАЧИ
• 2.1 Серверные языки программирования
• 2.2 Выбор языка программирования клиентской части
• 2.3 Особенности Model-View-Controller
• 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
• 3.1 UML-диаграммы использования системы
• 3.2 Проектирование базы данных
• 3.3 Создание web-интерфейса web-ресурса
• 4. ОХОРОНА ПРАЦІ ТА ТА БЕЗПЕКА В НАДЗВИЧАЙНИХ СИТУАЦІЯХ
• 4.1 Характеристика приміщення, в якому проводилось виконання дипломної роботи
• 4.2 Шкідливі та небезпечні фактори при роботі з ПЕОМ
• 4.3 Розрахунок природного та штучного освітлення
• 4.4 Можливі аварії, катастрофи, стихійні лиха, причини виникнення подій та їх наслідки для області та України
• ВЫВОДЫ
• Список литературы
• ПРИЛОЖЕНИЕ

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

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

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

Электронная среда обладает целым рядом несомненных преимуществ и возможностей, среди которых:

· интерактивный характер коммуникации;

· доступность информации в течение 24 часов пользователям Всего мира;

· оперативное обновление информации, в том числе ее дополнение с учетом вопросов или предложений посетителей сайта;

· предоставление неограниченного объема информации, причем помимо текстовой и графической, еще звуковой и видеоинформации;

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

· персонализация информации, предназначенной для различных целевых групп;

· многоаспектный и быстрый поиск необходимых сведений в больших массивах информации;

· получение сведений о посещаемости сайта, т. е. его результативности как средства коммуникации;

· создание сайтов, посвященных отдельным темам или разделам, или ориентированным на различные целевые аудитории.

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

Исходя из цели, необходимо решить основные задачи:

1. Проанализировать и охарактеризовать существующие разработки сайтов СМИ, сделать их сравнительный анализ.

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

3. Подключить базу данных.

4. Создать web-интерфейс по стилю схожий с газетой .

5. Обработать данные для контента сайта.

1. ИНФОРМАЦИОННЫЙ ОБЗОР РЕШЕНИЙ

1.1 Сущность и функции ресурса СМИ

Интернет был создан как способ передачи текстовой информации. Поэтому печатные СМИ и информационные агентства столкнулись с его влиянием раньше, чем электронная пресса. СМИ в Интернете начинались с простого дублирования информации в Интернет, так в 1993 году появилась точная копия газеты Washington Post. Постепенное перетекание традиционных СМИ в интернет сопровождалось появлением новых видов сетевых СМИ, таких как интернет-издание (интернет-газета, интернет-журнал) — 1994;1996 годы, интернет-радио (1998 год) и интернет-телевидение (1999 год). Научная общественность уже проявила интерес к двум первым видам, однако интернет-телевидение все еще остается неизученным.

На ноябрь 2004 года число зарегистрированных интернет-ресурсов в разделе «СМИ» каталога «Яндекс» составляет 3477.

Требования к созданию сайта, предназначенного для интернет СМИ, сильно отличаются от требований, которые выдвигаются при создании сайта для, например, информационных целей юридической компании.

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

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

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

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

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

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

1.2 Анализ продукта компании FarbaSite CMS

FarbaSite CMS —это высокотехнологичная система управления сайтом (CMS):

Рисунок 1.1 — Вход в администрирование сайта FarbaSite

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

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

Система прав и безопасности позволяет обслуживать разные группы пользователей с разными правами и возможностями.

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

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

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

Все ли в порядке на сайте проверит система самотестирования ядра сайта.

Использование php4. xx позволяет разместить сайт на большинстве профессиональных хостинг-площадок.

Рисунок 1.2 — Структура сайта Система является платной. Цена на создание сайта имеет такие значения:

34 900 — 37 900 гривен, на создание уйдет 12−18 месяцев.

Техническая поддержка сайта 2 900 — 7 900 гривен в месяц на протяжении года.

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

1.3 Анализ продукта Joomla CMS

Joomla — это бесплатная CMS, которая написана на PHP, использует базу данных MySQL, имеет открытый исходный код и, к тому же, отлично документирована. Joomla! — самостоятельный продукт, который выделился в 2005 году вследствие разделения группы разработчиков известной крупной CMS Mambo.

На сегодняшний день существует 2 версии Joomla: 1.0 и 1.5. Версия 1.0 — это преемница Mambo, совместимая практически со всеми компонентами, модулями и мамботами своей предшественницы. Версия 1.5 — это полностью новый самостоятельный продукт, разработанный, что называется «с нуля». К преимуществам использования версии 1.0 следует отнести огромное количество уже написанных под нее расширений, с помощью которых, даже при отсутствии знаний по веб-программированию, можно создать полнофункциональный сайт СМИ. Версия Joomla 1.5 более требовательна к ресурсам сервера, поэтому предъявляет высокие требования к хостингу.

Для корректной работы с Joomla! к серверу предъявляются следующие технические требования:

· PHP 4.2.x или выше;

· MySQL 3.23.x или выше;

· Apache 1.13.19 или выше.

Рисунок 1.3 — Вход в администрирование сайта Joomla

Какие возможности предоставляет Joomla?

Joomla — предоставляет огромные возможности по администрированию сайта. Вот лишь некоторые из них:

· возможность создавать неограниченное количество страниц;

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

· возможность сделать оригинальный дизайн благодаря полностью настраиваемым схемам расположения элементов по 5 областям;

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

· возможность создания собственной библиотеки — для последующего использования с любого места сайта;

· наличие различных модулей — последние новости, счетчик посещений, подробная статистика посещений, гостевая книга, форум и т. д.;

· наличие модуля приёма от удалённых авторов новостей, статей и ссылок;

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

· наличие менеджера архива, в который можно поместить старые статьи;

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

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

· наличие модулей персональных страниц — возможность «оживить» свой сайт;

· экономное использование места на сервере за счет использование базы данных MySQL;

· наличие системы управления баннерами.

Кроме того, Joomla! совместима с серверами Linux, FreeBSD, MacOSX server, Solaris и AIX, что позволяет широко использовать ее, независимо от сервера, установленного хостером.

Joomla! — многофункциональный инструмент. Она позволяет создавать сайты разной степени сложности: сайты-визитки, корпоративные сайты, интернет-ресурсы, СМИ-ресурсы. С помощью Joomla! можно также создавать интернет-магазины.

1.4 Постановка задачи

Таким образом, в работе необходимо разработать и программно реализовать информационную web-систему ресурса редакции газеты «Химик» .

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

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

2. ВЫБОР МЕТОДА РЕШЕНИЯ ЗАДАЧИ

Для решения задачи необходимо сделать следующее:

1. спроектировать ресурс, который бы смог быстро обрабатывать и передавать данные;

2. выбрать базу данных для хранения информации;

3. разработать карту сайта для отображения данных.

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

2.1 Серверные языки программирования

PHP — это широко распространённый открытый язык скриптинга (сценариев) общего назначения, который создан специально для Web и который можно внедрять в HTML. Его синтаксис происходит от C, Java и Perl и лёгок для понимания и изучения.

Необходимо обратить внимание на отличие способа совмещения выполняемого кода и презентационной части в скрипта на языке PHP от скриптов, написанных на языках Perl или C — вместо написания программы с большим количеством команд для вывода HTML, пишется HTML-скрипт с некоторым количеством встроенного кода для выполнения каких-либо действий (в данном случае — для вывода некоторого текста). Код PHP заключён в специальные начальный и конечный тэги, что позволяет входить в и выходить из «режима PHP», причём делать это именно там, где это необходимо.

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

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

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

PHP в основном сориентирован на серверный скриптинг, поэтому может делать всё то, что делают CGI-программы: сбор данных форм, динамическую генерацию содержимого страницы или приём и отправку cookie. Но функциональность PHP намного шире.

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

Серверный скриптинг. Это наиболее традиционная и главная сфера применения PHP. Для выполнения этой работы необходимы три вещи. Разборщик кода PHP (CGI или серверный модуль), web-сервер и web-браузер. Сервер должен быть запущен и должен иметь соединение с инсталлированным и сконфигурированным PHP. Можно получить вывод PHP-программы в web-браузер, просматривая PHP-страницу на сервере.

Скриптинг командной строки. Можно создать и запустить PHP-скрипт на выполнение без сервера или браузера. Для этого необходим только разборщик PHP. Этот тип использования идеально подходит для регулярного выполнения скрипта с помощью программы cron (в *nix или Linux) или Task Scheduler (в Windows). Эти скрипты можно использовать также для задач простейшего текстового процессинга/обработки.

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

PHP может использоваться на всех крупных операционных системах (ОС), включая Linux, многие варианты Unix (HP-UX, Solaris, OpenBSD и Mac OS X), Microsoft Windows, RISC OS и, возможно, другие, что не создает проблем при переходе от платформы к платформе. PHP имеет поддержку для большинства существующих web-серверов. Это ApacheHTTPD, Microsoft IIS, nginx и многие другие. Для большинства этих серверов PHP имеет модули. В других, поддерживающих стандарт CGI, PHP может работать как CGI-процессор.

Следуя из написанного выше, можно сделать вывод, что с помощью PHP можно получить свободу выбора ОС и web-сервера. Более того, можно также выбрать использование процедурного или объектно-ориентированного варианта программирования или их сочетания. Хотя не всякая стандартная возможность OOП реализована в текущей версии PHP, многие библиотеки кодов и большие приложения (включая библиотеку PEAR) написаны только с использованием OOП-кода.

В PHP программист не имеет ограничений в выводе ориентируясь только на HTML. PHP может выводить изображения, PDF-файлы, скрипты на языке JavaScript, клипы Adobe Flash (используя расширения libswf и Ming), генерируемые на лету. Легко можно выводить любой текст, включая XHTML, и любой другой XML-файл. PHP может автоматически генерировать эти файлы и сохранять их в файловой системе, формируя серверный кэш для динамического содержимого, или создания отчётов.

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

Список поддерживаемых PHP библиотек доступа к БД достаточно широк и включает следующие популярные серверы и форматы:

· Oracle

· dBase

· InterBase

· PostgreSQL

· mSQL

· MS SQL

· Sybase

· IBM DB2

· MySQL

· SQLite

· Informix

· ODBC

PHP поддерживает взаимодействие с другими службами по таким протоколам, как LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (под Windows) и множество других. В случае отсутствия непосредственной программной реализации того или иного сетевого протокола в PHP, существует возможность открыть обычный сетевой сокет и взаимодействовать с удаленным сервисом согласно его протоколу. Другой популярной технологией серверного скриптования является ASP. ASP по своей сути не является языком программирования, это акроним для Active Server Pages, в действительности, в программах ASP используется VBScript или JScript. Наибольшим недостатком ASP является то, что он сам по себе является проприетарной системой, которая используется исключительно на Microsoft Internet Information Server (IIS). Это ограничивает его применение серверами на платформе Windows.

Считается, что ASP громоздок и работает медленнее, чем PHP, а также менее устойчив к внешним атакам. Одним из преимуществ ASP можно считать использование языка программирования VBScript для написания сценариев, который, относительно легко освоить, будучи знакомым с программированием на Visual Basic. Так-же поддержка ASP по умолчанию встроена в web-сервер IIS, что упрощает подготовительную стадию разработки приложений с его использованием.

Еще одной интересной альтернативой PHP является язык программирования Perl. Наиболее важным преимуществом PHP по сравнению с Perl является то, что PHP был разработан для скриптинга на web, а перед Perl ставились более широкие задачи, в том числе и скриптинг на web, поэтому он получился намного более сложным. Главное отличие работы интерпретаторов PHP и Perl — постоянное присутствие в памяти первого интерпретатора, через который просто проходят скрипты по мере их вызова, а сформированная HTML страница — отсылается клиенту. Второй интерпретатор загружается в память и выгружается по мере необходимости, причём для каждого скрипта вызывается один интерпретатор, что может повлиять на производительность сервера.

Гибкость и сложность синтаксиса Perl облегчает написание кода, но делает его трудно читаемым. PHP имеет более однозначный и строгий формат без потери гибкости. PHP легче встраивается в существующий HTML, нежели Perl. PHP имеет почти такую же хорошую функциональность, что и Perl: конструкции, синтаксис и т. д. без усложнения Perl. PHP развивается быстрее Perl, с каждой новой версией приобретает новые функции и более гибкий синтаксис, а также улучшается стабильность и безопасность. Это подтверждает тот факт, что в глобальной сети сейчас присутствует множество проектов, которые написаны на PHP и работают быстро, без сбоев. Попробуем обобщить всё, что касается преимуществ PHP, которых нет в Perl:

Контекстно-зависимые include, которые видят переменные верхнего уровня;

Расширенные теги  — что и называется удобным встраиванием в HTML;

Высокая скорость работы с БД и огромное количество поддерживаемых баз данных, где Perl по скорости проигрывает;

Встроенная поддержка XML в PHP;

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

Быстрые темпы развития и поддержка огромным количеством пользователей в Internet;

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

В последнее время также стали популярны некоторые новые языки программирования, как Ruby или Python, но они, как правило ориентированы на работу со своими каркасами приложений, такими как Ruby On Rails или Django, а поэтому применяются для создания полноценных сложных приложений, нежели для написания простых скриптов и требуют развертывания сервера приложений, работающим в связке в web-сервером, обслуживающим HTTP запросы. То же касается и достаточно старых технологий с применением языка Java, таких как JavaServletes или менее абстрактными JavaServerPages.

Ниже приведены результаты анализа преимуществ и недостатков (табл. 2.1).

Таблица 2.1 — Сравнение технологий серверного скриптинга

2.2 Выбор языка программирования клиентской части

Главным требованием при написании данного приложения является его кроссплатформенность, что исключило использование таких проприетарных технологий, как Adobe Flash, Microsoft Silverlight и JavaFX. Их использование подразумевает наличие на клиентском web-браузере установленного расширения для поддержки той или иной технологии. На мобильных устройствах их поддержка довольно ограничена либо вообще отсутствует.

Также очень важным недостатком этих технологий является то, что текстовая и мультимедийная информация, включённая в приложения, созданные с использованием данных технологий, не может быть полноценно проиндексирована современными поисковыми системами, что, в итоге, как исключает их использования в качестве подсистемы поиска контента на web-сайте, так и ограничивает продвижение конечного web-сайта в глобальных рейтингах поиска. Учитывая новые возможности HTML5 и CSS3, детально описанные в информационной части данной работы, с широкой поддержкой в современных web-браузерах, как на десктопных, так и на мобильных платформах, тройка HTML5, CSS3, JavaScript на сегодняшний день представляет пока единственную универсальную технологию, позволяющую создавать динамичные клиентские кроссплатформенные web-приложения.

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

На данный момент на рынке программного обеспечения существует несколько подобных библиотек. Рассмотрим наиболее широко используемые из них, а именно jQuery, Prototype и Dojo.

jQuery — это библиотека, фокусирующаяся на взаимодействии JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к любому элементу DOM, обращаться к атрибутам и содержимому элементов DOM, манипулировать ими. Также библиотека jQuery предоставляет удобный API по работе с Ajax. Она предоставляет разработчику следующие возможности:

· Движок кросс-браузерных CSS-селекторов Sizzle, который существует в данный момент в виде отдельного проекта;

· Навигация по дереву DOM, включая поддержку XPath как плагина;

· Поддержка события DOM;

· Визуальные эффекты;

· AJAX-дополнения;

· JavaScript-плагины.

Точно так же, как CSS отделяет визуализацию от структуры HTML, jQuery отделяет поведение от структуры HTML. Например, вместо прямого указания на обработчик события нажатия кнопки, управление передаётся jQuery, идентифицирующей кнопки и затем преобразовывающий его в обработчик события. Такое разделение поведения и структуры также называется принципом ненавязчивого JavaScript.

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

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

Другой схожей по функциональности с jQuery библиотекой является Prototype. Ее главной задачей является добавление поддержки более объектно-ориентированного программирования в JavaScript, нежели манипуляции объектами DOM. Prototype не имеет встроенной поддержки анимации, которая обеспечивается дополнительной библиотекой Scriptaculus, что в результате, выводит ее из разряда легковесных библиотек, так как суммарный исходный код занимает более 200 килобайт.

Третьей из рассматриваемых нами библиотек является Dojo. Это свободная модульная библиотека JavaScript, создана с целью упростить ускоренную разработку основанных на JavaScript или AJAX web-приложений и web-сайтов. Как и jQuery она предоставляет гибкие возможности по манипулированию объектами DOM и их анимацией, но при этом является очень тяжеловесной — объем библиотеки достигает нескольких мегабайт.

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

Таблица 2.2 — Сравнение библиотек JavaScript

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

2.3 Описание Model-View-Controller

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

«Оригинальный» MVC

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

Впервые паттерн MVC появился в языке SmallTalk в конце семидесятых. Собственно задача была хорошо всем знакомая, надо было придумать архитектурное решение, которое позволяло бы манипулировать графическими представлениями данных некоего приложения, таким образом, чтобы изменение Представления этих данных не влияло на бизнес-логику и данные (Модель) приложения, а так же, чтобы была возможность иметь несколько Представлений для одной Модели. Таким решением и стал паттерн MVC, идея которого родилась в недрах Xerox PARK, и получила свое первое публичное упоминание в документации к SmallTalk'80. В классическом варианте, MVC состоит из трех частей, которые и дали ему название.

Model (Модель) Под Моделью, обычно понимается часть содержащая в себе функциональную логику приложения, иными словами то, что обычно называем «Business Layer», «Бизнес-слой» или «Слой бизнес логики». Как именно организован этот слой, по большому счету не важно, однако есть ряд ключевых моментов, на которых остановимся позднее. Основная цель паттерна — сделать так, чтобы Модель была полностью независима от остальных частей и практически ничего не знала об их существовании, что позволило бы менять и Контроллер и Представление модели, не трогая саму Модель и даже позволить функционирование нескольких экземпляров Представлений и Контроллеров с одной Моделью одновременно. Вследствие чего, Модель ни при каких условиях не может содержать ссылок на объекты Представления или Контроллера. Обычно различают несколько типов паттернов в зависимости от роли модели.

Passive Model (пассивная модель) — Модель не имеет вообще никаких способов воздействовать на Представление или Контроллер и только используется ими в качестве источника данных для отображения. Все изменения модели отслеживаются Контроллером и он же отвечает за перерисовку Представления, если это необходимо.

Active Model (активная модель) — Модель имеет возможность оповестить Представлениео том, что в ней произошли некие изменения, и Представление может эти изменения отобразить.

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

View (Представление) В обязанности Представления входит отображение данных полученных от Модели. Обычно Представление имеет свободный доступ к Модели и может брать из нее данные, однако это доступ только на чтение, ничего менять в Модели или даже просто вызывать методы приводящие к изменению ее внутреннего состояния, Представлению позволять нельзя. В случае активной Модели, Представление может подписаться на события изменения Модели и перерисовываться, забрав измененные данные, при получении соответствующего оповещения.

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

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

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

Таким образом, типичная схема взаимодействия компонентов паттерна выглядит примерно так: Контроллер перехватывает событие извне и в соответствии с заложенной в него логикой, реагирует на это событие изменяя Mодель, посредством вызова соответствующего метода Модели. После изменения Модель бросает событие о том что она изменилась, и все подписанные на это события Представления, получив его, обращаются к Модели за обновленными данными, после чего их и отображают (рис. 2.1).

Рис. 2.1 — Схема MVC

При этом еще в описании оригинального шаблона упоминалось, что выделение отдельного Контроллера не так важно как отделение Представления от Модели и Контроллер вполне может быть интегрирован в Представление, тем более что в классическом варианте MVC логики в Контроллере не очень много.

Говоря о типовом решении модель — представление — контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления.

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

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

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

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

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

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

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

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

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

сайт электронный программирование клиентский

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

Необходимо осуществить описание программной реализации приложения. В качестве инструмента для реализации поставленных задач данной работы будем использовать PHP Expert Editor и базу данных MySQL.

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

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

Рисунок 3.1 — Информационная модель системы В соответствии с формулированным требованием, проектируемый web-ресурс можно представить в виде UML-диаграмм использования (рис. 3.2−3.7). Например, подсистема пользователей представлена на рисунке 3.2.

Рисунок 3.2 — UML-диаграмма использования «подсистемы пользователей»

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

Подсистема редакции представлена на рисунке 3.3.

Рисунок 3.3 — UML-диаграмма использования «подсистема редакции»

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

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

Подсистема каталога редакции представлена на рисунке 3.4

Рисунок 3.4 — UML-диаграмма использования «подсистема каталога редакции»

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

Подсистема приватные сообщения представлена на рисунке 3.5.

Рисунок 3.5 UML-диаграмма использования «подсистема приватных сообщений»

Подсистема оповещения на электронную почту представлена на рисунке 3.6.

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

Рисунок 3.6 UML-диаграмма использования «оповещения»

Подсистема сообществ представлена на рисунке 3.7.

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

3.2 Проектирование базы данных

Наша система создается для хранения и управления данными. Следующий шаг при проектировании — продумать, как будут эти данные храниться. Проектирование базы будет производиться по подсистемам:

1. Подсистема пользователей Вся информация, предоставляемая подсистемой, информация о пользователе, роль пользователяи уровень пользователя будет храниться в таблицах:

а) users;

б) roles;

В таблице users будет храниться информация о пользователях, а именно:

а) индивидуальный номер пользователя (id);

б) электронная почта пользователя (email);

в) имя пользователя (name);

г) фамилия пользователя (surname);

д) логин пользователя (nick);

ж) стать пользователя (sex);

е) дата рождения пользователя (birthday);

з) сайт пользователя (site);

и) статус пользователя (status);

й) информация о себе (about);

к) у каждого пользователя будет ссылка на роль (role_id);

В таблице roles будет хранится информация о роли пользователя в системе, а именно:

а) индивидуальный номер роли (id);

б) название роли (name);

в) приоритет роли (weight).

После преобразования описания данных в отношения получим:

а) users (id, email, name, surname, nick, sex, birthday, site, status, about, role_id, level_id);

б) roles (id, name, weight);

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

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

Таблица 3.1 — Зависимости полей подсистемы пользователей от первичного ключа

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

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

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

Рисунок 3.9 — ERD-диаграмма подсистемы пользователей

2. Подсистема новостей Вся информация предоставляемая подсистемой, информация о новостях будет храниться в таблице:

а) news;

б) steps;

в) recommended_news;

г) recommended_news _users.

В таблице news будет храниться информация о новостях, а именно:

а) индивидуальный номер новости (id);

б) название новости (title);

в) краткое описание новости (small_news);

г) полное описание новости (big_news);

д) количество просмотров (views);

е) автор статьи (user_id).

В таблице recommended_news будет храниться информация рекомендуемых новостях к данному рецепту, а именно:

а) индивидуальный номер (id);

б) ссылка на новость, к которому рекомендуют (url_id);

в) ссылка на новость, который рекомендуют (url2_id);

г) количество рекомендаций (vote).

В таблице recommended_news_users будет храниться информация о том, какие пользователи рекомендовали какие новости, а именно:

а) индивидуальный номер (id);

б) ссылка на таблицу рекомендаций (recommended_news_id);

в) ссылка на пользователя (user_id).

Преобразуем описания данных в отношения:

а) news (id, title, small_news, big_news, user_id, views);

б) recommended_news (id, url_id, ul2_id);

в) recommended_news_users (id, recommended_news_id, user_id)

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

Таблица 3.2 — Зависимости полей подсистемы рецептов от первичного ключа

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

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

3.3 Создание web-интерфейса web-ресурса

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

1 Логотип сайта

2 Навигационное меню

3 «Подвал»

На главной странице сайта основным содержанием страницы будет информация об основных разделах сайта (Main). Модель главной страницы имеет вид: