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

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

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

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

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

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

Введение

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

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

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

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

Пояснительная записка дипломной работы выполнена в соответствии с ГОСТ 7.9-95, ГОСТ 7.32-2001, ГОСТ 15.101-98, ГОСТ 19.105-78, ГОСТ 19.404-79, СТП КубГТУ 1.9.2-2003, МР КубГТУ 4.4.3-2004.

В первом разделе отражен результат анализа области разработки, а именно: приведены общие сведения о CMS, архитектура CMS, критерии оценки CMS, обоснование целесообразности создания CMS, а также техническое задание на разработку CMS. Данный раздел выполнен в соответствие с ГОСТ Р 1.5-2004, ГОСТ Р ИСО 9000-2008, ГОСТ Р ИСО 9001-2008.

Во втором разделе представлены результаты проектирования CMS: эскизный проект, включающий в себя use-case диаграммы для каждого типа пользователей компонента для CMS и диаграммы классов и диаграммы последовательности, результаты проектирования БД CMS и результаты проектирования GUI. Данный раздел выполнен в соответствии с ГОСТ 19.102-77, ГОСТ 19.104-78, ГОСТ 19.202-78, ГОСТ 19.402-78, ГОСТ 19.701-90, Р-50-77-88.В третьем разделе представлено руководство пользователя и руководство программиста, выполненные в соответствие с ГОСТ 19.503-79, ГОСТ 19.504-79, 19.505-79.

В четвертом разделе представлено технико-экономическое обоснование эффективности CMS «SiteONas», выполненное в соответствие с ГОСТ 19.502-78.

В пятом разделе произведена оценка соответствия производственного помещения санитарным нормам. Данный раздел выполнен в соответствие с ГОСТ 8.417-2002.

В конце пояснительной записки к дипломному проекту приведен список используемой литературы, включая электронные ресурсы, оформленный в соответствие с ГОСТ 7.1-2003, ГОСТ 7.12-93, ГОСТ 7.80-2000, ГОСТ 7.82-2011.

1. Анализ предметной области

1.1 Общие сведения о CMS

CMS - ИС, используемая для обеспечения и организации совместного процесса создания, редактирования и управления контентом.

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

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

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

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

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

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

Использование CMS предоставляет следующие преимущества:

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

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

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

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

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

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

1.2 Модели представления данных в CMS

Существует классификация CMS, основанная на модели представления данных - объектной, сетевой или модульной.

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

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

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

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

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

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

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

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

1.3 Критерии оценки CMS

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

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

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

-редактировать контент страниц, включая добавление/удаление графики;

-добавлять новые страницы;

-изменять структуру сайта и различные метаданные;

-настраивать регистрационные формы;

-управлять опросами, голосованиями и форумами;

-вести статистику посещений;

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

-управлять дизайном.;

-распределять права по управлению сайтом среди пользователей.

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

Безопасность CMS второй по важности после функциональности критерий. Надо учитывать как надёжность системы со стороны внешних атак, так и от неосторожных действий пользователей системы.

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

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

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

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

Ниже представлено краткое сравнение наиболее популярных в настоящее время CMS 1C-Битрикс, Joomla! и Wordpress.

Расширяемость

1С-Битрикс - существует постоянно расширяемая линейка модулей. Есть возможность изменять функционал модулей, посредством программирования.

Joomla - архив плагинов Joomla насчитывает более 2000 разнообразнейших элементов.

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

Безопасность

1С-Битрикс - система признана экспертами в области защиты информации безопасной.

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

WordPress - Каждый новый шаг в обновлении сопровождается обновлением системы безопасности.

Стоимость

1С-Битрикс - стоимость варьируется от 5 000 до 250 000 руб, в зависимости от функциональности.

Joomla - свободно распространяемый ПП.

WordPress - свободно распространяемый ПП.

Документация

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

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

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

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

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

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

1.4 Преимущества разработки собственной CMS

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

На рисунке 1 отражена статистика распределения популярных сайтов между CMS за 1 квартал 2011 г. с сайта itrack.ru, построенная на основе данных, полученных при анализе более 1000 сайтов из списка «TOP-100» сайта Liveinternet, выбранных из десяти тематик: авто, медицина, новости и сми, недвижимость, банки, развлечения, путешествия, работа, товары и услуги [3].

Рисунок 1 - Статистика использования CMS в популярных проектах

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

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

Большинство CMS обладают следующими недостатками:

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

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

низкий уровень безопасности CMS с открытым исходным кодом;

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

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

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

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

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

При разработке собственной CMS учитываются все вышеперечисленные недостатки, и в итоге CMS имеет следующие преимущества перед «коробочными» CMS:

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

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

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

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

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

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

1.5 Средства, используемые для разработки CMS

При разработке CMS могут быть использованы такие технологии как LAMP или ASP.NET. Рассмотрим эти технологии подробнее:

LAMP (аббревиатура Linux, Apache, MySQL, PHP) - популярный набор серверного ПО, используемый для разработки интернет-ресурсов. Данная технология предоставляется подавляющим большинством хостинговых компаний и является наиболее распространенной в сети Интернет. LAMP включает в себя следующие компоненты:

PHP 5 - мощный серверный язык, позволяющий создавать скрипты, использующиеся в динамических сайтах; [4]

MySQL - популярная СУБД, обеспечивающая хранение данных на сервере; [5,6,7]

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

Linux - бесплатная ОС, имеющая большой набор сетевых утилит. [8]

ASP.NET в связке с IIS и MSSQL. Данная технология использует языки программирования, входящие в комплект.NET Framework. Преимущественно скрипты ASP.NET используют веб-сервер IIS. На сегодняшний день ограниченное число хостингов предлагает услуги для ASP-приложений. [9]

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

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

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

контроллер (поведение). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции. [10, 11, 12]

1.6 Техническое задание на разработку CMS

1.6.1 Введение

Наименование программы: CMS SiteONas.

Цель: повышение эффективности управления контентом Интернет-ресурсов.

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

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

1.6.2 Основания для разработки

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

Использованные ГОСТы:

ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы;

ГОСТ 19.201-78. Техническое задание. Требования к содержанию и оформлению.

Организация, утвердившая этот документ: Армавирский механико-технологический институт (филиал) ФГБОУ ВПО «Кубанский Государственный технологический университет».

Ниже приведены должностные обязанности при работе с CMS.

Суперадминистратор. Пользователь, авторизованный с ролью «Суперадминистратор», имеет следующие должностные обязанности:

управление конфигурацией CMS;

управление пользователями CMS;

управление сайтами пользователей CMS;

управление лицевыми счетами пользователей CMS;

оповещение пользователей CMS о технических работах, окончании срока оплаты и т.п.

Администратор. Пользователь, авторизованный с ролью «Администратор», имеет следующие должностные обязанности:

добавление модуля CMS на сайт;

удаление модуля CMS с сайта;

публикация материала на сайте;

доступ к документации CMS;

смена шаблона дизайна сайта;

управление стилями CSS;

управление балансом лицевого счета;

управление доменом сайта;

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

1.6.3 Назначение разработки

CMS предназначена для:

добавления, удаления, редактирования информации в БД CMS;

добавления, удаления дополнительных модулей;

публикации информации на сайте;

изменения структурной разметки сайта;

изменения дизайна сайта.

1.6.4 Требования к CMS

Требования к функциональным характеристикам.

Архитектура разрабатываемой CMS приведена на рисунке 2.

Рисунок 2 - Архитектура CMS «SiteONas»

Разрабатываемая CMS строится согласно шаблону проектирования MVC. Кодировкой, используемой при разработке CMS, является UTF-8.

Базовая комплектация CMS включает в себя:

ядро CMS;

базовый набор модулей;

базовый набор шаблонов;

документацию.

Ниже описаны компоненты, включенные в базовую комплектацию CMS:

а) Ядро CMS. Управляет модулями CMS. Обеспечивает взаимодействие между классами CMS. Обрабатывает запросы пользователей. В ядро CMS входят следующие компоненты:

библиотека базовых классов (фреймворк);

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

подсистема управления модулями CMS;

подсистема управления пользователями CMS;

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

подсистема управления CSS стилями;

файлы конфигурации.

б) Библиотека базовых классов (фреймворк).

В качестве библиотеки базовых классов для CMS был выбран PHP фреймворк Yii. Данный фреймворк обладает такими преимуществами как:

простая установка;

большое количество документации;

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

поддержка ООП;

лицензия New BSD, позволяющая свободно использовать этот фреймворк в коммерческих и open-source проектах.

Yii включает в себя такие классы, необходимые для разработки CMS, как класс взаимодействия с БД, шаблонизатор, классы валидации и обработки ошибок и др.

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

Шаблонизатор. Компонент системы, ответственный за формирование содержимого страниц сайта на основе шаблонов дизайна.

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

Класс обработки ошибок. Предоставляет методы, обрабатывающие возникающие ошибки в CMS, выдающий соответствующие сообщения об ошибках.

Класс обеспечения безопасности запросов. Предоставляет методы, обрабатывающие входные данные, полученные от пользователя. Осуществляет проверку на наличие SQL-Injection и XSS.

Система распределения прав доступа. Осуществляет проверку уровня прав пользователя для осуществления определенных действий с CMS. Реализуется на уровне контроллера.

в) Подсистема управления личными счетами пользователей. Позволяет администратору CMS оплачивать сайт через API различных платежных систем, просматривать и распечатывать финансовую отчетность по оплате сайта.

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

д) Подсистема управления пользователями CMS. Предназначена для регистрации, редактирования, удаления пользователей CMS. Позволяет редактировать личную информацию пользователей.

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

ж) Подсистема управления CSS стилями. Предназначена для «тонкой» настройки дизайна сайта. Позволяет задавать набор правил CSS для использующихся на сайте элементов структурной разметки.

з) Файлы конфигурации. Файлы настроек, хранящие базовые настройки CMS.

и) Базовый набор модулей. В базовый комплект CMS входят следующие модули:

создание, редактирование и публикация статических страниц;

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

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

новости. Позволяет вывести на страницу 5 последних новостей. Организует подробный просмотр текста новости;

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

видеогалерея. Позволяет создавать видеогалерею, используя популярные сервисы видеохостинга;

поиск по сайту. Организует поиск информации по контенту, имеющемуся на сайте;

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

обратная связь. Позволяет отправлять e-mail администратору сайта.

к) Базовый набор шаблонов.

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

Требования к надежности

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

а) организацией бесперебойного питания технических средств;

б) использованием лицензионного ПО;

в) ограничение доступа пользователей к БД с целью предотвращения несанкционированного доступа;

г) обеспечение целостности БД;

д) периодическое, не реже одного раза в неделю, резервирование информации, находящейся в БД.

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

Условия эксплуатации

Климатические условия эксплуатации должны соответствовать условиям эксплуатации технических средств.

Минимальное количество персонала, требуемого для работы CMS, должно составлять не менее 1 штатной единицы - администратора.

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

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

задача администрирования БД;

задача создания резервных копий БД;

систематическое обновление информации.

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

В состав технических средств должен входить Интернет-сервер, поддерживающий передачу данных по FTP, включающий в себя процессор Pentium IV с частотой не менее 1 GHz, оперативную память объемом не менее 256 Мегабайт, свободное место на сервере не менее 50 Мегабайт, ОС Linux или Windows.

Требования к информационной и программной совместимости

Базовый язык программирования CMS - PHP версии 5.2.

CMS должна работать на основе сервера БД, работающим под управлением MySQL Server. Необходимо выбрать виртуальный хостинг, или выделенный сервер, на котором установлена следующая конфигурация:

ОС Linux не ниже версии 2.6;

веб-сервер Apache не ниже версии 1.3.41;

сервер БД MySQL не ниже версии 5.0;

PHP-интерпретатор не ниже версии 5.1.

дополнительные модули (cron и т.п.)

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

Форматы данных, используемые в CMS:

файлы серверных скриптов, включая файлы настройки CMS, имеют расширение.php;

изображения элементов управления CMS имеют расширение.png;

подключаемые шаблоны и модули CMS хранятся в архивах с расширениями.rar,.tar,.zip;

файлы журналов событий имеют расширение.log;

файл «тонкой» настройки web-сервера имеет расширение.htaccess.

Для доступа к CMS на ПК клиента должен быть доступ к сети интернет и установлен браузер Internet Explorer (не ниже версии 6.0), Opera, Safari, Mozilla Firefox или Google Chrome.

Требования к эргономике

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

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

Экранные формы CMS должны быть рассчитаны на разрешение экрана 1280*768. Дизайн системы должен быть разработан так, чтобы все поля экранной формы были доступны без дополнительной горизонтальной прокрутки и, по возможности, вертикальной прокрутки.

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

Рисунок 2 - Оповещение пользователя о вводе обязательных данных

Также должен вестись файл протоколирования ошибок системы (log-файл), доступный для чтения пользователям CMS с ролью «Суперадминистратор».

1.6.5 Требования к программной документации

В комплект документации в обязательном порядке должны входить:

техническое задание;

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

текст программы;

руководство пользователя;

руководство программиста.

Программная документация должна быть оформлена в соответствии с ЕСПД (ГОСТ 19).

1.6.6 Технико-экономические показатели

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

1.6.7 Стадии и этапы разработки

Стадии разработки

Разработка CMS «SiteONas» должна быть проведена в следующие стадии:

анализ требований к системе;

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

разработка системы;

тестирование;

внедрение;

сопровождение и эксплуатация.

Этапы разработки

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

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

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

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

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

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

1.6.8 Порядок контроля и приемки

Приемо-сдаточные испытания должны проводиться на объекте Заказчика в оговоренные сроки, представленных в таблице 1. Ход проведения приемо-сдаточных испытаний Заказчик и Исполнитель документируют в Протоколе проведения испытаний. На основании Протокола проведения испытаний Исполнитель совместно с Заказчиком подписывает Акт приемки-сдачи программы в эксплуатацию.

Таблица 1 - Этапы и сроки сдачи проекта

Этапы

Сроки

Анализ требований к системе

15 декабря 2011 г. - 8 января 2012 г.

Проектирование системы

9 января 2012 г. - 15 февраля 2012 г.

Разработка системы

16 марта 2012 г. - 8 мая 2012 г.

Тестирование

9 мая 2012 г. - 20 мая 2012 г.

Внедрение

21 мая 2012 г. - 30 мая 2012 г.

Сопровождение и эксплуатация

с 1 июня 2012 г. - 15 июня 2012 г.

2. Проектирование CMS

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

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

Выделяют такие преимущества UML как:

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

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

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

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

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

В настоящее время UML широко распространен при проектировании информационных систем и продолжает динамично развиваться. [13, 14, 15, 16, 17]

2.1 Проектирование функций пользователей CMS «SiteONas» с ролью «Суперадминистратор»

Диаграмма вариантов использования для пользователя с ролью «Суперадминистратор» приведена на рисунке 3.

Рисунок 3 - Диаграмма вариантов использования для пользователя c ролью «Суперадминистратор»

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

Вариант использования Авторизация

Краткое описание. Данный вариант использования описывает авторизацию пользователя в административном разделе CMS.

Основной поток событий

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

1) Появляется форма авторизации, содержащая поля ввода имени и пароля.

2) После ввода имени и пароля, пользователь нажимает кнопку ОК.

3) Система авторизует пользователя.

Альтернативные потоки

Неправильные имя/пароль

1) Система выдает сообщение об ошибке

2) Пользователь повторяет попытку ввода имени и пароля.

Предусловия

Регистрация в системе.

Постусловия

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

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

Краткое описание. Данный вариант использования описывает регистрацию нового пользователя в административном разделе CMS.

Основной поток событий

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

1) Появляется форма регистрации нового пользователя.

2) После ввода обязательных данных о новом пользователе (логин, e-mail, тариф), пользователь нажимает кнопку ОК.

3) В систему добавляется новый пользователь CMS.

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

5) После подтверждения регистрации, в системе пользователь отмечается как «активный».

Альтернативные потоки

Ввод некорректного e-mail или уже существующего e-mail.

1) Система выдает сообщение об ошибке

2) Пользователю выводится форма регистрации нового пользователя.

Отсутствие подтверждения регистрации пользователя.

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

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

Если вариант использования закончится успешно, в системе появится новый пользователь с ролью «Администратор».

Вариант использования Блокирование пользователя CMS

Краткое описание. Данный вариант использования описывает блокирование пользователя в административном разделе CMS.

Основной поток событий

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

1) Появляется форма подтверждения блокировки пользователя.

2) После подтверждения блокировки нажатием кнопки «ОК», в системе пользователь отмечается как «заблокированный», сайты, связанные с этим пользователем, блокируются.

Альтернативные потоки

Выбор кнопки «Отмена» в форме подтверждения блокировки пользователя.

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

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

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Вариант использования Удаление пользователя CMS

Краткое описание. Данный вариант использования описывает удаление пользователя в административном разделе CMS.

Основной поток событий

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

1) Появляется форма подтверждения удаления пользователя.

2) После подтверждения удаления нажатием кнопки «ОК», пользователь и связанные с ним сайты удаляются из системы.

Альтернативные потоки

Выбор кнопки «Отмена» в форме подтверждения удаления пользователя.

1) Форма подтверждения удаления пользователя закрывается.

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

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Вариант использования Зачисление средств на лицевой счет пользователя CMS.

Краткое описание. Данный вариант использования описывает процесс зачисления средств на лицевой счет пользователя CMS.

Основной поток событий

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

1) Появляется форма зачисления средств на счет пользователя CMS.

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

3) Сумма подтверждается нажатием кнопки «ОК» формы зачисления средств.

Альтернативные потоки

Выбор кнопки «Отмена» в форме зачисления средств на счет пользователя CMS.

1) Форма зачисления средств на счет пользователя CMS закрывается.

2) Баланс лицевого счета выбранного пользователя остается без изменения.

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Вариант использования Снятие средств с лицевого счет пользователя CMS.

Краткое описание. Данный вариант использования описывает процесс снятия средств с лицевого счета пользователя CMS.

Основной поток событий

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

1) Появляется форма списания средств со счета пользователя CMS.

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

3) Сумма подтверждается нажатием кнопки «ОК» формы списания средств.

Альтернативные потоки

Выбор кнопки «Отмена» в форме списания средств со счета пользователя CMS.

1) Форма списания средств со счета пользователя CMS закрывается.

2) Баланс лицевого счета выбранного пользователя остается без изменения.

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Вариант использования Изменение конфигурации CMS

Краткое описание. Данный вариант использования описывает изменение настройки CMS.

Основной поток событий

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

1) Открывается окно настройки СMS.

2) Пользователь выбирает соответствующие настройкам переключатели.

3) После ввода настроек нажимается кнопка Сохранить и настройки сохраняются в БД CMS.

Альтернативные потоки

Нажатие кнопки Отмена прерывает изменение настроек CMS.

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Вариант использования Рассылка уведомлений пользователям CMS.

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

Основной поток событий

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

1) Появляется форма рассылки уведомлений пользователя CMS.

2) Суперадминистратор вводит текст электронного письма.

3) Суперадминистратор выбирает пользователей, которым предназначена рассылка, из списка пользователей CMS или выбирает «Выбрать всех».

4) После нажатия кнопки «Отправить», электронные письма отправляются на выбранные электронные адреса.

Альтернативные потоки

Альтернативные потоки отсутствуют.

Предусловия

Авторизация в системе с ролью «Суперадминистратор».

Постусловия

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

Классы, участвующие в вариантах использования пользователя с ролью «Суперадминистратор», представлены в таблице 2.

Таблица 2 - Классы, участвующие в вариантах использования пользователя с ролью «Суперадминистратор»

Вариант использования

Классы

Авторизация в системе

CWebApplication, UserIdentity, Users, CUserIdentity, CActiveRecord

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

CWebApplication, CController, UsersController, Users, CMailer, CActiveRecord

Блокирование пользователя CMS

CWebApplication, CController, UsersController, Users, Sites, CMailer, CActiveRecord

Удаление пользователя CMS

CWebApplication, CController, UsersController, Users, CActiveRecord

Зачисление средств на лицевой счет пользователя CMS

CWebApplication, CController, BillingController,Billing, Users, CActiveRecord

Снятие средств с лицевого счета пользователя CMS

CWebApplication, CController, BillingController,Billing, Users, CActiveRecord

Изменение конфигурации CMS

CWebApplication, CActiveRecord

Рассылка уведомлений пользователям CMS

CWebApplication, CController, MailerController, Mailer, CMailer

Выход из системы

CWebApplication, Sites, UserIdentity

В таблице 3 приведена спецификация классов для вариантов использования пользователя с ролью «Суперадминистратор».

Таблица 3 - Спецификация классов вариантов использования пользователя с ролью «Суперадминистратор»

Класс

Описание

Свойства и методы

CWebApplication

Класс фреймворка. Представляет собой контекст выполнения web-приложения.

run(), processRequest(), runController()

CUserIdentity

Класс фреймворка. Предназначен для авторизации и аутентификации пользователей

authenticate()

UserIdentity

Наследник CUserIdentity. Предназначен для управления пользователями CMS

user, authenticate(), getUserId(), getSiteId(), checkPermission()

CActiveRecord

Класс фреймворка. Предназначен для работы с БД посредством модели ORM. Реализует модель паттерна MVC.

db, validators, model(), find(), findAll(), findByPk(), save(), insert(), update(), delete(), validate()

Users

Наследник CActiveRecord. Модель MVC. Представляет собой объект таблицы «users».

model(), tableName(), relations(), search(), getFullName()

Sites

Наследник CActiveRecord. Модель MVC. Представляет собой объект таблицы «sites».

model(), tableName(), relations(), search_user_sites(), getSiteTitleLink(), denyDomains()

Billing

Наследник CActiveRecord. Модель MVC. Представляет собой объект таблицы «billing».

model(), tableName(), relations(), search(), getCurrentUserBalance(),getLogSum(), getIsPagesLimit()

CController

Класс фреймворка. Предназначен для реализации бизнес-правил приложения. Реализует контроллер MVC.

layout, id, redirect(), render(), runAction(), filterAccessControl(), run()

UsersController

Наследник CController. Контроллер MVC. Реализует основные методы для управления пользователями CMS.

actionRegister(), actionProfile(), actionUpdate(), loadModel(), actionAdmin()

BillingController

Наследник CController. Контроллер MVC. Реализует основные методы для управления личными счетами пользователей CMS.

actionInputsum(), actionDeposit(), actionDebit(), actionPayment(), actionYamoney(), actionBank(), actionInvoice(), actionAdmin()

MailerController

Наследник CController. Контроллер MVC. Реализует основные методы для рассылки электронных писем.

actionCreate(), actionUpdate(), loadModel(), actionAdmin(), actionDelete()

2.2 Спецификация варианта использования «Регистрация нового пользователя»

На рисунке 4 представлена диаграмма классов для варианта использования «Регистрация нового пользователя».

Рисунок 4 - Диаграмма классов для варианта использования «Распределение прав доступа»

Класс DFX_Administrator предназначен для реализации интерфейса административной панели CMS.

Класс DFX_User предназначен для управления пользователями CMS.

Класс CActiveRecord предназначен для работы с БД CMS согласно модели ORM.

В таблице 4 представлено описание атрибутов и методов класса DFX_Administrator

Таблица 4 - Описание атрибутов и методов класса DFX_Administrator

Атрибут / метод

Тип

Описание

users

DFX_User[]

Массив пользователей данной CMS

showUsers()

void

Метод, предназначенный для вывода на экран всех пользователей CMS

renderView()

void

Метод, предназначенный для вывода формы добавления нового пользователя

showMessage()

void

Метод, предназначенный для вывода сообщения о результате добавлении информации в БД

В таблице 5 представлено описание атрибутов и методов класса DFX_User.

Таблица 5 - Описание атрибутов и методов класса DFX_User

Атрибут / метод

Тип

Описание

user_name

string

Атрибут, представляющий имя пользователя CMS, указанное при регистрации

user_type

int

Атрибут, представляющий тип пользователя CMS

authorization()

boolean

Метод, предназначенный для авторизации пользователя в CMS. В случае авторизации возвращает true, в противном случае - false

getUserList

DFX_User[]

Метод, возвращающий массив объектов, представляющих пользователей CMS

saveUser

void

Метод, предназначенный для сохранения пользователя в БД CMS

В таблице 6 представлено описание атрибутов и методов класса CActiveRecord

Таблица 6 - Описание атрибутов и методов класса CActiveRecord

Атрибут/метод

Тип

Описание

db

CDbConnection

Атрибут, представляющий ссылку на текущее активное соединение с БД CMS

insert()

boolean

Метод, вставляющий запись в БД CMS. В случае успешной вставки записи возвращает true, в противном случае - false

save()

boolean

Метод, сохраняющий изменения, внесенные в БД CMS. В случае сохранения возвращает true, в противном случае - false

Диаграмма последовательности для варианта использования «Регистрация нового пользователя» для пользователя с ролью «Суперадминистратор» изображена на рисунке 5.

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

Опишем поток событий для диаграммы последовательности.

Вариант использования «Регистрация нового пользователя»

Краткое описание. Данный вариант использования описывает регистрацию нового пользователя с ролью «Администратор» в административном разделе CMS.

Основной поток событий

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

1) В классе DFX_Administrator вызывается метод класса DFX_User getUserList(), который возвращает список пользователей CMS.

2) Метод showUsers() выводит список пользователей на экран.

3) Пользователь выбирает пункт меню «Добавить нового пользователя».

4) Метод renderView() отображает на экране форму добавления нового пользователя с необходимыми полями.

5) Пользователь вводит в поля требуемую информацию и нажимает кнопку «Сохранить», инициируя метод saveUser()

6) Метод saveUser() класса DFX_User получает ссылку на объект класса ActiveRecord и вызывает методы insert() - вставляющий новые данные в таблицу и save() - сохраняющий таблицу в БД CMS.

7) В случае успешного сохранения информации в БД CMS пользователю выводится сообщение об успешном добавлении нового пользователя. В противном случае - сообщение об ошибки.

Предусловия

Авторизация в системе с ролью «Суперадминистратор». Для авторизации в системе необходимо:

1) Ввести адрес панели администрирования в адресной строке браузера.

2) В появившемся окне авторизации ввести логин и пароль.

3) В методе Autorization() класса DFX_User выполняется проверка введенного логина и пароля, в случае успешной авторизации пользователя, открывается панель администрирования.

Постусловия

Если вариант использования закончится успешно, в системе будет создан новый пользователь с ролью «Администратор».

2.3 Проектирование функций пользователей CMS «SiteONas» с ролью «Администратор»

На рисунке 6 изображена диаграмма последовательности для пользователя с ролью «Администратор».

Рисунок 6 - Диаграмма вариантов использования для пользователя с ролью «Администратор»

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

Вариант использования Доступ к документации CMS


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

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