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

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

Введение

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

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

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

1. С помощью среды Zend Studio 8 было разработано ядро системы управления сайтом;

2. С помощью Zend Studio 8 были разработаны обработчики событий, для управления системой;

3. С помощью Notepad++ были созданы каскадные таблицы стилей для оформления панели администрирования.

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

В первом разделе пояснительной записки выполнено предпроектное обследование ГУК «Ставропольская государственная краевая универсальная научная библиотека им. М.Ю. Лермонтова» (далее СГК УНБ им. М.Ю. Лермонтова), сформулировано техническое задание на разработку системы управления сайтом.

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

Третий раздел содержит информацию о программном, информационном и техническом обеспечении проекта.

Четвертый раздел содержит в себе технико-экономическое обоснование проекта.

Библиографический список содержит перечень из 17 источников современной информации использованных при подготовке дипломной работы в том числе: 7 книг, 3 государственных стандарта и 7 ссылок на Web-ресурсы Интернет.

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

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ СГК УНБ им. М.Ю. Лермонтова. ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

1.1 Результаты предпроектного обследования

1.1.1 Объект и методы проведения предпроектного обследования

Основными объектами предпроектного обследования являются:

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

- отдел автоматизации СГК УНБ им. М.Ю. Лермонтова;

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

1.1.2 Программа проведения обследования

Программа обследования учреждения представлена в таблице 1.1. План-график выполнения работ на стадии сбора материалов обследования представлен в таблице 1.2.

Таблица 1.1 - Программа обследования учреждения

Наименование вопроса	Источник информации	Получатель информации
1	2	3
Общая характеристика	Устав СГК УНБ им. М. Ю. Лермонтова	Студент Смитюх А.И.
Организационная структура	Аналогично	Аналогично
Цели деятельности	Аналогично	Аналогично
Наличие проблемных ситуаций в деятельности СГК УНБ им. М. Ю. Лермонтова	Устав СГК УНБ им. М. Ю. Лермонтова	Студент Смитюх А.И.
Цели деятельности отдела автоматизации	Главный специалист по автоматизации	Аналогично
Наличие проблемных ситуаций в деятельности отдела автоматизации	Аналогично	Аналогично
Наличие средств вычислительной техники и программного обеспечения в отделе автоматизации	Аналогично	Аналогично

Таблица 1.2 - План-график выполнения работ на стадии сбора материалов обследования

Наименование работы	Код работы	Исполнитель	Дата начала	Длительность выполнения, дней	Дата окончания
1	2	3	4	5	6
Общая характеристика	001	Разработчик Смитюх А.И.	10.01.11	3	13.01.11
Организационная структура	002	Аналогично	13.01.11	2	15.01.11
Цели деятельности	003	Аналогично	15.01.11	4	19.01.11
Наличие проблемных ситуаций в деятельности СГК УНБ им. М. Ю. Лермонтова	004	Аналогично	19.01.11	16	04.02.11
Цели деятельности отдела автоматизации	005	Разработчик Смитюх А.И.	04.02.11	2	06.02.11
Наличие проблемных ситуаций в деятельности отдела автоматизации	006	Аналогично	06.02.11	22	28.02.11
Наличие средств вычислительной техники и программного обеспечения в отделе автоматизации	007	Аналогично	28.02.11	6	06.03.11
Всего затрачено дней	55

1.1.3 Результаты предпроектного обследования и их анализ

Общая характеристика учреждения. СГК УНБ им. М.Ю. Лермонтова незримо связала страницы своей долголетней истории с судьбой многих поколений жителей г. Ставрополя и Ставропольского края.

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

Фонд библиотеки, способный удовлетворить самые разные интересы, насчитывает свыше 1 млн. 170 тыс. экз. Ценным достоянием библиотеки является богатый фонд редких и краеведческих изданий XVI - XIX столетий. Ежегодно в библиотеку поступает более 20 тыс. новых изданий книг, около 600 наименований периодических изданий, до 1 тыс. документов на различных носителях информации. За год библиотека обслуживает более 40 тыс. жителей г. Ставрополя и Ставропольского края, выдавая им около 1 млн. 200 тыс. документов.

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

Ресурсная обеспеченность и техническая оснащенность библиотеки постоянно пополняются. В библиотеке успешно функционирует локальная компьютерная сеть, состоящая в настоящий момент из 160 автоматизированных рабочих мест. Осуществлен доступ пользователей, в том числе и удаленных, к электронному каталогу библиотеки, который насчитывает более 400 тыс. библиографических записей. Сайт библиотеки, созданный в 2003 году, пользуется большой популярностью. За год его посещают свыше 100 тыс. пользователей.

С 2004 года СГК УНБ им. М. Ю. Лермонтова является полноправным членом Ассоциации Региональных Библиотечных Консорциумов.

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

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

Функциональная структура отдела автоматизации. Управление в любой организации - это процесс взаимодействия между управляющей, управляемой системами (субъектом и объектом управления) и внешней средой.



Рисунок 1.1 - Организационная структура учреждения

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

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

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

В составе учреждения целесообразно выделить три области, представленные в таблице 1.3.

1. Производственная (библиотечная деятельность);

2. Управленческая;

3. Обеспечивающая.

Таблица 1.3 - Функциональные области и задачи

Номер и название функциональной области	Номер и процессы, протекающие в области
1	2
1. Производственная (библиотечная деятельность)	1.1 Предоставление доступа к электронной библиотеке
	1.2 Предоставление доступа к электронному каталогу
1. Производственная (библиотечная деятельность)	1.3 Проведение совместных мероприятий с использованием конференц-зала
2. Управленческая	2.1 Обновление Web-сайта
	2.2 Анализ эффективности функционирования сети
3. Обеспечивающая	3.1 Закупка нового оборудования
	3 2 Обслуживание персональных компьютеров

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

x - полное участие в процессе;

/ - частичное участие в процессе;

0 - ответственность за выполнение процесса.

Таблица 1.4 - Организационно-управленческая модель

Функциональные задачи и подзадачи	Производственная	Управленческая	Обеспечивающая
Исполнители	1.1	1.2	1.3	2.1	2.2	3.1	3.2
Зам. Директора по АХЧ						0	x
Главный специалист по автоматизации	0		0		x	x	/
Ведущий программист	x	/		0	x	/	/
Программист		x		/	/		/
Оператор			x		/

Цели функционирования СГК УНБ им. М. Ю. Лермонтова. В результате проведенного обследования вуза были выделены основные цели, средства их достижения и сформулированы критерии эффективности применяемых мер. При построении «дерева целей» его проектирование идет по методу «от общего к частному». Прекращение декомпозиции цели на более мелкие прекращается в тот момент, когда дальнейший процесс является нецелесообразным в рамках рассмотрения Главной цели. Правильно построенное дерево целей в дальнейшем легко может быть преобразовано в план-график или диаграмму Ганта.

Схема дерева целей представлена на рисунке 1.2. В таблице 1.5 приведены возможные средства и критерии достижения поставленных целей.

Таблица 1.5 - Цели деятельности, средства достижения и критерии оценки уровня достижения цели

Цель	Средства достижения	Критерий эффективности
G1	A11 - Закупка новых библиотечных фондов	Увеличение числа посещений, увеличение перечня выполняемых услуг
	A12 - Открытие новых читательских отделов
G2	A21 - Увеличение количества оплачиваемых мероприятий	Привлечение новых потоков денежных средств
	A22 - Привлечение новых читателей за счет культурных мероприятий
G3	A31 - Привлечение новых читателей, узнавших о библиотеке с помощью официального сайта	Привлечение новых читателей
	A32 - Привлечение новых за счет средств массовой информации

Документооборот - движение документов с момента их получения или создания до завершения исполнения или отправки[3].

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

Рисунок 1.2 - Дерево целей СГК УНЮ им. М. Ю. Лермонтова

Входящие документы - документы, которые поступили на предприятие от внешних партнеров.

Большинство исходящих документов являются ответом организации на соответствующие входящие документы.

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

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

Изучив особенности структуры и организации работы информационной системы СГК УНБ им. М.Ю. Лермонтова можно сделать выводы о необходимости улучшения ее работы.

При подробном изучении структуры и алгоритмов работы системы управления сайтом (далее СУС) в целом были выявлены следующие проблемы:

Таблица 1.6 - Перечень документов отдела автоматизации СГК УНБ им. М.Ю. Лермонтова

Код документа	Название	Кем готовится	Кем используется	Кол-во в год	Периодичность	Примечание
1	Заявка на ремонт оборудования	Зав. отделами	Зав. отделом автоматизации	неограниченно	по мере необходимости	Документ предназначен для учета поломок аппаратуры и своевременного решения возникших проблем
2	Заявка на замену/выдачу нового оборудования	Зав. отделом автоматизации	Бухгалтерия	неограниченно	по мере необходимости	Документ предназначен для организации учета оборудования
3	Заявка на обновление сайта	Зав. отделами	программист	неограниченно	по мере необходимости	Документ, который систематизирует информацию, предоставляемую для обновления сайта
4	Квартальный отчет отдела автоматизации	Зав. отделом автоматизации	Директор	4	3 месяца	Подробный отчет о деятельности отдела за квартал, со скользящими графиками посещаемости сайта



Рисунок 1.3 - Схема документооборота отдела автоматизации СГК УНБ им. М. Ю. Лермонтова

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

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

б) данные для обработки берутся из глобального массива REQUEST, который объединяет массивы GET, POST и COOKIE, что делает алгоритм ненадежным. Это обусловлено тем, что данные для аутентификации могут быть переданы не только методом отправки из формы, но и взяты из адресной сроки, методом GET. Кроме этого они могут быть получены из массива COOKIE, который в свою очередь хранятся на пользовательском компьютере, что позволяет проводить cookie-атаки;

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

2. Отсутствие руководства пользователя делает невозможным написание и подключение к СУС новых модулей и шаблонов без знания устройства СУС в целом и аспектов ее функционирования;

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

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

а) привязка оформления к языку PHP повышает требования к квалификации верстальщика;

б) использование PHP может привести к переносу ошибки, сделанной в шаблоне Web-сайта, непосредственно в СУС, что может привести к выведению сайта из строя, несмотря на работоспособность СУС;

в) восприятие шаблона, содержащего большое количество PHP, вставок затрудняется;

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

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

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

1.2 Формулировка задач проектирования

1.2.1 Общие сведения о системе управления сайтом

Полное наименование подсистемы - «Система управления сайтом СГК УНБ им. М. Ю. Лермнтова».

Код системы - LibNet.

Наименование организации разработчика - СевКавГТУ, факультет ИТТ, кафедра прикладной информатики, студент группы ПИ-061 Смитюх Александр Иванович.

Наименование организации заказчика - ГУК «Ставропольская государственная краевая универсальная научная библиотека им. М. Ю. Лермонтова».

Перечень документов, на основе которых создается система:

отчет о преддипломной практике студента группы ПИ-061Смитюх А. И.;

– Рабочий план отдела автоматизации СГК УНБ им. М.Ю. Лермонтова за 1-2 кварталы 2011г;

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

Источники финансирования - заработная плата программиста СГК УНБ им. М. Ю. Лермнтова.

1.2.2 Назначение, цели создания систему управления сайтом

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

Цели создания систему управления сайтом для СГК УНБ им. М. Ю. Лермонтова:

– уменьшение средств необходимых для сопровождения сайта;

– создание более удобного интерфейса пользователя.

1.2.3 Требования к системе управления сайтом

Заказчик предъявляет следующие требования к системе:

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

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

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

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

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

? создание дополнительных модулей и расширений должно быть простым;

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

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



Рисунок 1.4 - Диаграмма вариантов использования системы управления сайтом

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

Работа по созданию системы управления сайтом делится на четыре основных этапа:

1. Анализ системы управления учреждения с 18.02.2011 по 4.03.2011 г.

2. Кодирование 5.03.2011 по 12.05.2011 г.

3. Отладка и тестирование с 13.05.2011 по 20.05.2011 г.

4. Сдача проектной документации с 21.05.2011 по 25.05.2011 г.

1.2.5 Порядок контроля приемки системы

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

– директор СГК УНБ им. М.Ю. Лермонтова Долина З. Ф.;

– зам. директора по библиотечной работе Москвитина Т. А.;

– зам. директора по научной деятельности Белик В. И.;

– зав. отделом автоматизации Альшанский В. Ю.;

– зав. отделом рекламы Хворостьянова С. В.;

– зав. редакционно-издательским отделом Коротченко В. Г.

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

1.2.6 Требования к документированию

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

– исходные коды систему управления сайтом, представленные в электронной форме, представляющею собой архив zip;

– SQL-сценарий создания базы данных, представленный в файле, с расширением sql;

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

– руководство по написанию обработчиков для системы управления сайтом LibNet.

Перечисленные выше материалы будут переданы на CD-R диске.

1.2.7 Источники разработки

В ходе разработки системы были изучены основные аспекты функционирования подобных систем. Для углубления знаний использовалась специальная литература в частности литература по языку программирования PHP, СУБД MySQL.

Основным источником разработки системы управления сайтом для ГУК «Ставропольская государственная краевая универсальная научная библиотека им. М. Ю. Лермонтова», являются отчет студента Сев-КавГТУ, факультета ИТТ, группы ПИ-061 Смитюх А. И. о преддипломной практике.

Кроме этого, в процессе проектирования применялись различные ГОСТы, такие как, ГОСТ 3.11.09 - 82 «Система технологической документации. Термины и определения основных понятий».

Выводы

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

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

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

4. Работы по созданию шаблона Web-сайта необходимо закончить до окончания преддипломной практики до 25.05.2011 г.

2. Реализация системы управления сайтом LibNet

2.1 Обоснование выбора среды реализации приложения

В качестве среды разработки мною была выбрана Zend Studio 8.0, она обладает рядом преимуществ:

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

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

3. Наличие удобного механизма отслеживания ошибок до запуска сценария;

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

5. Возможность изменения кодировки всего объекта;

6. Наличие удобных средств отладки;

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

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

Для создания логической модели данных системы управления сайтом LibNet был использован бесплатный программный продукт MySQL Workbench 5.2., который позволяет управлять базами данных, располагающимися на локальной машине или удаленными в сети. В нашем случае на сервер была предустановленна СУБД MySQL 5.1.40

сайт администрирование таблица каскадный

2.2.1 Определение сущностей модели базы данных системы управления сайтом

На основе анализа предметной области выделяются сущности, представленные в таблице 2.1.

Таблица 2.1 - Перечень сущностей предметной области

Наименование сущности	Назначение сущности
access_group	Группы доступа пользователей
access_type	Типы доступа пользователей
access_unit	Экземпляры доступа для групп доступа
document	Документа системы
document_field	Динамические поля СУС
document_hierarchy	Иерархия документов системы
document_type	Типы данных системы
document_type_field	Типовые поля типов данных
field_type	Типы полей
marker	Метки шаблонов данных
marker_args	Параметры меток шаблонов данных
marker_function	Функции меток шаблонов данных
setting	Настройки СУС
template	Конвертированные шаблоны данных
user	Пользователи СУС
user_access	Полномочия доступа пользователей
user_group	Группы пользователей
user_group_access	Полномочия доступа групп пользователей
user_relation_group	Отношение пользователей к группам
user_remember	Данные для повторной авторизации

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

1. Сегмент, отвечающий за пользователей и их полномочия, в него входят следующие сущности: user, user_access, user_group, user_group_access, user_relation_group, user_remember, access_group, access_type, access_unit.

2. Сегмент, отвечающий за документы системы управления сайтом LibNet, в него входят следующие сущности: document, document_field, document_hierarchy, document_type, document_type_field, field_type.

3. Сегмент отвечающий за хранение конвертированных шаблонов, в него входят следующие сущности: marker, marker_args, marker_function, template

2.2.2 Определение атрибутов сущностей базы данных системы управления сайтом

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

2.2.3 Определение связей между сущностями базы данных системы управления сайтом

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

В результате анализа было установлено:

? база данных содержит 20 сущностей;

? 11 сущностей являются родительскими;

? 10 сущностей являются дочерними;

? всего создано 18 связей типа «один-ко-многим».

Таблица 2.2 - Атрибуты сущностей базы данных

Сущность	Атрибут	Тип	Ключ	Назначение
1	2	3	4	4
access_group	access_group_id	int(11)	Первичный	Идентификатор группы доступа
	access_group_name	varchar(128)	Нет	Имя группы доступа
	access_group_description	text	Нет	Описание группы доступа
access_type	access_type_id	int(11)	Первичный	Идентификатор типа доступ
	access_type_name	varchar(128)	Нет	Имя типа доступа
	access_type_description	text	Нет	Описание типа доступа
access_unit	access_group_id	int(11)	Первичный	Идентификатор экземпляра доступа
	access_type_id	int(11)	Первичный	Идентификатор типа доступа
	access_unit_value	int(11)	Нет	Значение экземпляра доступа
document	document_id	int(11)	Первичный	Идентификатор документа
	document_type_id	int(11)	Внешний	Идентификатор типа документа
	doc_title	varchar(128)	Нет	Название документа
	template_id	int(11)	Внешний	Идентификатор шаблона документа
	published_time	int(11)	Нет	Время публикации документа
	published_user_id	int(11)	Нет	Идентификатор пользователя, опубликовавшего документ
	create_time	int(11)	Нет	Время создания
	create_user_id	int(11)	Нет	Пользователь, создавший документ
	mod_time	int(11)	Нет	Время изменения
	mod_user_id	int(11)	Нет	Пользователь, изменивший документ
document_field	document_id	int(11)	Первичный	Идентификатор документа
	document_type_field_id	int(11)	Первичный	Идентификатор поля типа документа
	doc_field_value	text	Нет	Значение поля
document_hierarchy	parent_id	int(11)	Первичный	Идентификатор родительского документа
	child_id	int(11)	Первичный	Идентификатор дочернего документа
document_type	document_type_id	int(11)	Первичный	Идентификатор типа документа
	doc_type_title	varchar(128)	Нет	Наименование типа документа
	doc_type_desc	varchar(256)	Нет	Описание типа документа
document_type_field	document_type_field_id	int(11)	Первичный	Идентификатор поля типа документа
	document_type_id	int(11)	Внешний	Идентификатор типа документа
	field_type_id	int(11)	Нет	Идентификатор типа поля
	doc_type_field_name	varchar(128)	Нет	Имя поля типа документа
document_type_field	doc_type_field_title	varchar(128)	Нет	Наименование поля типа документа
	doc_type_field_desc	varchar(256)	Нет	Описание поля типа документа
field_type	field_type_id	int(11)	Первичный	Идентификатор типа поля
	field_type_name	varchar(16)	Нет	Имя типа поля
	field_type_title	varchar(128)	Нет	Наименование типа поля
	field_type_desc	varchar(256)	Нет	Описание типа поля
marker	marker_id	int(11)	Первичный	Идентификатор маркера
	marker_function_id	int(11)	Внешний	Идентификатор функции маркера
	template_id	int(11)	Внешний	Идентификатор шаблона
marker_args	args_number	int(11)	Первичный	Порядковый номер параметра
	args_value	varchar(128)	Нет	Значение параметра
marker_function	marker_function_id	int(11)	Первичный	Идентификатор функции маркера
	marker_function_name	varchar(64)	Нет	Имя функции маркера
setting	setting_id	int(11)	Первичный	Идентификатор настройки
	setting_name	varchar(64)	Нет	Имя настройки
	setting_value	text	Нет	Значение настройки
template	template_id	int(11)	Первичный	Идентификатор шаблона данных
	tpl_name	varchar(128)	Нет	Имя шаблона данных
	tpl_enable	int(11)	Нет	Флажок доступности шаблона данных
	tpl_convert	text	Нет	Преобразованный шаблон данных
	tpl_update	int(11)	Нет	Время обновления шаблона данных
	tpl_filepath	varchar(192)	Нет	Пуль к файлу шаблона данных
user	user_id	int(11)	Первичный	Идентификатор пользователя
	user_name	varchar(100)	Нет	Имя пользователя
	user_email	varchar(50)	Нет	Адрес электронной почты
	user_password_hash	varchar(40)	Нет	Хэш пароля
	registration_date	int(11)	Нет	Дана регистрации
user_access	user_id	int(11)	Первичный	Идентификатор пользователя
	access_group_id	int(11)	Первичный	Идентификатор группы доступа
user_group	user_group_id	int(11)	Первичный	Идентификатор группы пользователей
user_group	user_group_description	varchar(256)	Нет	Описание группы пользователей
user_group_access	user_group_id	int(11)	Первичный	Идентификатор группы пользователей
	access_group_id	int(11)	Первичный	Идентификатор группы доступа
user_relation_group	user_group_id	int(11)	Первичный	Идентификатор группы пользователей
	user_id	int(11)	Первичный	Идентификатор пользователя
user_remember	user_id	int(11)	Первичный	Идентификатор пользователя
	remote_ip	varchar(15)	Первичный	IP адрес компьютера
	time_death	int(11)	Нет	Время окончания

Таблица 2.3 - Данные о взаимодействии сущностей базы данных для СУС СГК УНБ им. М. Ю. Лермонтова

Зависимая сущность	Независимая сущность	Внешний ключ	Тип связи
1	2	3	4
access_unit	access_group	access_group_id	1:M
access_unit	access_type	access_type_id	1:M
document_field	document	document_id	1:M
document_field	document_type_field	document_type_field_id	1:M
document	document_type	document_type_id	1:M
document	template	template_id	1:M
document_type_field	document_type	document_type_id	1:M
document_type_field	field_type	field_type_id	1:M
marker	marker_function	marker_function_id	1:M
marker	template	template_id	1:M
marker_args	marker	marker_id	1:M
user_access	user	user_id	1:M
user_access	access_group	access_group_id	1:M
user_group_access	user_group	user_group_id	1:M
user_group_access	access_group	access_group_id	1:M
user_relation_group	user_group	user_group_id	1:M
user_relation_group	user	user_id	1:M
user_remember	user	user_id	1:M

2.3 Создание физической модели базы данных информационной подсистемы

Для создания физической модели данных мною было использовано бесплатное приложение MySQL Workbench. Данный программный продукт является наследником традиций MySQL Admin. Для создания физической модели используем удобный интерфейс клиента. Для создания таблиц, сначала необходимо выбрать базу данных, с каторой мы собираемся работать, затем нажать кнопку «Add table», как показано на рисунке 2.1.



Рисунок 2.1 - Создание сущностей с помощью MySQL Workbench

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

Рисунок 2.2 - создание сущности document_type

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

Рисунок 2.3 - Создание ERR диаграммы на соединения с БД

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

Рисунок 2.4 - Логическая схема базы данных системы управления сайтом СГК УНБ им. М. Ю. Лермонтова

Генерирование SQL-сценария создания базы данных системы управления сайтом в MySQL Workbench

Генерация кода SQL-сценария создания базы данных может быть вызвана пользователем для активной EER диаграммы. Для этого необходимо выбрать соответствующий пункт меню «Export», как показано на рисунке 2.5. Послу запуска мастера, на экран будет выведено окно, где будет предложено выбрать опции генерации SQL-сценария.

Рисунок 2.5 - Создание SQL-сценария создания базы данных

После завершения работы мастера пользователю будет выведен на экран SQL-сценарий создания базы данных.

2.4 Создание проекта в Zend Studio для реализации проекта

Для создания СУС мною была выбрана среда разработки Zend Studio 8.0 за ряд преимуществ и достоинств, описанных ранее.

Для создания нового проекта, необходимо: в меню выбрать пункт «File» «New» «PHP Project» (рисунок 2.6). После чего откроется меню проекта, как показано на рисунке 2.7. В форме создания проекта заполняем все интересующие нас поля: название проекта, папка, где располагаются исходные коды и версия интерпретатора PHP, которую мы используем.

Рисунок 2.6 - Создание нового PHP проекта в Zend Studio 8.0

Zend Studio обладает внушительным инструментарием для создания и сопровождения проектов написанных на PHP

2.5 Реализация системы управления сайтом

Разработанное приложение имеет клиент-серверную архитектуру, где сервером выступает приложение HTTP сервер, а клиентом является Web-браузер компьютера конечного пользователя. При обращении сервер генерирует HTML код в зависимости от переданных параметров, который будет возвращен клиенту. Система управления сайтом написана без использования Фреймворков. При разработке системы использовались SQL-запросы, выполнение которых было возможно как в СУБД MySQL, так и MS SQL, но рабочей версией была выбрана СУБД MySQL 5.1.40 с поддержкой встроенных процедур.



Рисунок 2.7 - Настройка проекта PHP

2.5.1 Реализация классов системы управления сайтом

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

Все класс можно разделить на три основные группы:

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

2. Классы наследники класса LN_DataBase_Interface, являются классами предоставляющими интерфейс работы с структурными частями системы управления сайтом.

3. Классы наследники класса LN_Master_Element, являются либо обслуживающими классами классов мастеров, либо непосредственно классами мастерами, которые используются для генерации HTML кода.

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

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

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

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



Рисунок 2.8 - Диаграмма классов ядра системы

2.5.2 Создание событии обработки адресной строки

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

function LN_Event_admin_document(LN_DataBase $dbc, $arr_var)

{

// Выполняем запрос `query' к БД

$dbc->query(`query', `session');

$i_count = count($arr_var);

// Заполняем массив маркеров для возврата

for($i = 0; $i < $i_count; ++$i)

{

$output[$arr_var[$i]] = $i;

}

return $output;

}

Данный обработчик будет срабатывать каждый раз, как в адресной строке будет введено /admin/document, причем при добавлении новых параметров в конец адресной строки, они будут передаваться на обработку в качестве элементов массива $arr_var.

Таким образом, обращаясь по адресу /admin/document/edit/147 вы вызываете обработчик LN_Event_admin_document. В этом случае, обработчик вернет массив, состоящий из двух маркеров: маркер edit со значением 0 и маркер 147 со значением 1.

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

2.5.3 Создание обработчиков маркеров

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

Обработчика имеют следующий прототип:

LN_Handler_имя_обработчика(LN_DataBase $dbc, $arr_var)

{

}

Под именем обработчика понимается имя функции маркера, т.е. для маркера шаблона данных [%main_menu%] обработчиком будет LN_Handler_main_menu. Первый параметр передаваемый в функцию, как и в случае с событием будут ссылкой на объект работы с базой данных, вторым параметром будет массив свойств переданных маркеру в скобках, сдесь вызов аналогичен классическому вызову функции, например: [%main_menu(764,test,300)%] передаст массив из трех элементов: 764, test и 300, а значение, которое вернет обработчик, заменит этот маркер в шаблоне данных.

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

2.6.1 Проектирования меню системы управления

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

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

1. Добавление документа;

2. Просмотр документов;

3. Добавление типа данных;

4. Просмотр типов данных;

5. Добавление группы пользователя;

6. Просмотр групп пользователя;

7. Добавление нового пользователя;

8. Просмотр пользователей;

9. Добавление групп доступа;

10. Просмотр групп доступа;

11. Смена пользователя.

Исходя из перечисленного сгруппируем все основные пункты в четыре раздела:

1. Документы, куда будут входить следующие пункты:

а) список документов;

б) добавить документ;

в) типы данных;

г) добавить тип.

2. Пользователи, куда будут входить следующие пункты:

а) список пользователей;

б) добавить пользователя;

в) список групп;

г) добавить группу.

3. Доступ

а) группы доступа;

б) создать группу.

4. Выход, данный пункт позволит сменить пользователя.

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

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

Рисунок 2.9 - Выплывающее меню панели управления

2.6.2 Мастера представления данных системы управления сайтом

Мастер форм. Представляет собой набор средств для создания форм HTML. На рисунках 2.10 и 2.11 показаны формы создания документов разных типов, данные формы формируются одним и тем же кодом.



Рисунок 2.10 - Форма добавления Документа типа «Страница сайта»

Рисунок 2.11 - Форма добавления документа типа «Событие»

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

2.6.3 Типовые отчеты панели управления

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

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

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

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

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

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



Рисунок 2.12 - Табличный отчет списка типов данных

Рисунок 2.13 - Смешанный отчет о типе данных

Выводы

1. Использование ООП при написании приложений на языке PHP 5 предоставляет большие возможности по сравнению с процедурным подходом.

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

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

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

3. ИНФОРМАЦИОННОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

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

Систему управления сайтом LibNet имеет архитектуру «клиент-сервер». Для работы приложения на серверной стороне необходимо наличие следующих программных компонентов:

При использовании HTTP сервера IIS:

? операционная система Windows server 2003/2008/7Pro;

? компонент операционной системы IIS версии 6.5 и выше;

? установленный сервер баз данных MySQL 5.1;

? наличие установленного в систему интерпретатора PHP 5.3.

При использовании сервера Apache:

? операционная система Windows XP/Vista/S2003/S2008/7, Linux

? установленный Web-сервер Apache 2.2;

? наличие установленного интерпретатора PHP 5.3, как компонента HTTP сервера;

? установленный сервер баз данных MySQL 5.1.

Клиентским приложение является любой Web-браузер, установленный на клиентском ПК.

3.2 Функциональное назначение системы управления сайтом LibNet

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

3.3 Описание логической структуры системы управления сайтом

Логическую структуру интерактивных сервисов иллюстрирует схема изображенная на рисунок 3.1.

Рисунок 3.1 - Схема формирования страницы сайта системой управления

3.4 Требование к техническому обеспечению

3.4.1 Требования к техническому обеспечению сервера

Для нормальной работы интерактивных сервисов на стороне сервера необходимо наличие операционной системы Windows XP, СУБД MySQL 5.1, Web-сервера Apache 2.2, языка программирования PHP 5.

Требования к центральному процессору. Для персонального сервера с операционной системой Microsoft Windows XP необходим центральный процессор с тактовой частотой 233 МГц Это минимальной. Обоснование: данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP.

Требования к оперативному запоминающему устройству. Необходимый размер оперативного запоминающего устройства (ОЗУ) рассчитаем по формуле:

W_ОЗУ = W_ОЗУ1 + W_ОЗУ2 + W_ОЗУ3 (3.1)

где - минимально необходимый размер ОЗУ, требуемый для работы операционной системы (ОС);

- объем ОЗУ, требуемый интерактивными сервисами;

W_ОЗУ3 - минимальных требований со стороны дополнительных программных модулей, обеспечивающих работу программного продукта, Мбайт

Значение параметра для серверной версии операционной системы определяется, как 128 Мбайт. Обоснование: данное требование сформулировано разработчиками Microsoft Windows XP, как минимальное.

Значение параметра в рассматриваемом случае определяется необходимостью загрузки в оперативную память сервера интерактивных сервисов и составляет 0,32 Мбайт оперативной памяти.

Значение параметра W_ОЗУ3 в рассматриваемом случае определяется, как сумма требуемой оперативной памяти для программных модулей, обеспечивающих работу интерактивных сервисов. Для СУБД MySQL необходимо минимум 64 Мбайт, для web-сервера Apache 34 Мбайт, для PHP 1 Mбайт, тогда

W_ОЗУ3 = 128 + 34 + 1 = 163 Мбайт.

Таким образом, воспользовавшись формулой (3.1) получаем

W_ОЗУ = 64 + 0,32 + 163 =227,32 Мбайт.

Делаем следующий вывод - для нормальной работы интерактивных сервисов на сервере под управлением операционной системы Microsoft Windows XP будет достаточно 227,32 Мбайт оперативной памяти. Для обеспечения комфортных условий работы информационной подсистемы рекомендуется использовать ОЗУ размером 256 Мбайт и более.

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

, (3.2)

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

- размер временных файлов, создаваемых при работе с программой.

Размер пространства W₁, которое занимает инсталляция интерактивных сервисов, определяется размером занимаемого дискового пространства папкой проекта.

Размер пространства W₁, которое занимает инсталляция интерактивных сервисов доступа, составляет 987 Кбайт.

В процессе эксплуатации интерактивных сервисов могут создаваться временные файлы (запросы и пр.). Размер временных файлов (параметр ) может составить примерно 40 Кбайт памяти жесткого диска.

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

= 987 + 40 = 1027 Кбайт.

3.4.2 Требования к техническому обеспечению клиента

Для нормальной работы на стороне клиента достаточно наличия любого web-браузера и выхода в интернет со скоростью 56,6 Кбит/с.

Требования к центральному процессору. Для персонального компьютера клиента с операционной системой Microsoft Windows XP необходим центральный процессор с тактовой частотой 233 МГц. Данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP. Web-браузер Internet Explorer 6 предустановлен в операционной системе Microsoft Windows XP и не требует дополнительных ресурсов центрального процессора.

Требования к оперативному запоминающему устройству. Для персонального компьютера клиента размер оперативного запоминающего устройства определяется в зависимости от установленной операционной системы и web-браузера. Значение параметра для Microsoft Windows XP определяется, как 128 Мбайт. Обоснование: данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP. Web-браузер Internet Explorer 6 предустановлен в операционной системе Microsoft Windows XP и не требует дополнительной оперативной памяти.

Требования к наличию сводного места на жестком диске. Для персонального компьютера клиента с операционной системой Microsoft Windows XP необходимо 1,5 Гбайт свободного места на жестком диске. Обоснование: данное требование сформулировано фирмой Microsoft, как минимальное при установке Microsoft Windows XP. Web-браузер Internet Explorer 6 предустановлен в операционной системе Microsoft Windows XP и не требует дополнительного дискового пространства.

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

3.5 Установка и вызов интерактивных сервисов

Для установки системы управлением необходимо выполнить ряд предварительных установок и настроек:

1. Произвести установку HTTP сервера Apache 2.2, установочные файлы можно взять на сайте www.apache.org;

Процесс установки состоит их трех шагов:

а) выбор имени сервера, домена сети и почтового ящика администратора, как показано на рисунке 3.2;

Рисунок 3.2 - Выбор имени сервера при установке Apache

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

б) выбор директории, где будет располагаться наш сервер, рекомендую использовать директорию по умолчанию, как показано на рисунке 3.4;

Рисунок 3.3 - Выбор конфигурации Web-сервера Apache

Рисунок 3.4 - Выбор директории расположения Web-сервера

2. Далее необходимо установить сервер баз данных MySQL 5.1, дистрибутивы для установки можно найти на сайте www.mysql.com;

3. Для установки интерпретатора PHP необходимо, как модуля Web-сервера, необходимо распаковать исходные коды в папку на сервере, а затем указать в файле настроек Apache путь к каталогу PHP.