Критерий
|
Joomla
|
ModX
|
1C-Bitrix
|
Хранилища данных
|
MySql, MS SQL, PostgreSQL
|
MySql, MS SQL
|
MySql, MS SQL, Oracle
|
Управление пользователями
|
+
|
+
|
+
|
Наличие WYSIWYG редактора
|
+ (расширения)
|
+
|
-
|
Доступность (коммерческая)
|
+
|
+
|
-
|
Кроссплатформенность
|
+
|
+
|
+
|
Наличие доступной документации
|
-
|
-
|
+
|
При выборе системы управления содержимым будущего сайта
необходимо учитывать несколько факторов. Согласно [4] , процесс выбора можно
представить в виде диаграммы (см. рис. 1.13).
Рис. 1.13. Процесс внедрения системы управления содержимым
На рисунке важными в данный момент компонентами являются две
входные группы: ресурсы разработчиков и технические ресурсы (железо). Как уже
говорилось ранее, критерии сравнения были подобраны, исходя из профессиональных
умений разработчиков, а также технических и коммерческих возможностей команды:
. Отсутствие бюджета на закупку каких-либо программных
средств.
2. Unix-подобная платформа сервера с поддержкой MySQL.
. Сравнительно низкая производительность и
компетентность команды разработчиков в инструментах разработки, ввиду
отсутствия опыта работы с ними.
Учитывая выдвинутые условия, система 1С-Bitrix не подходит
для использования, т.к. она не является свободно распространяемой, а значит
приобрести ее для команды разработчиков не представляется возможным.
Система управления содержимым Joomla опасна тем, что ее
функционал собирается из множества закачиваемых и собираемых модулей.
Стандартный пакет включает минимальные возможности управления сайтом, а полный
потенциал раскрывается при умелом соединении различных модулей воедино, что
может оказаться проблемой для неопытных пользователей и отразиться на их
производительности.
Как видно из последнего критерия, системы управления
содержимым Joomla и ModX крайне неприветливо относятся к начинающим разработчикам
и требуют иметь некоторый багаж знаний для работы, чего в данном случае ожидать
не приходится. Более того, обобщенной документации, либо каких-либо видео
уроков на русском языке по ним крайне мало.
В конце концов получается так, что ни одна из рассмотренных
систем управления содержимым сайта не сможет обеспечить необходимую быстроту и
простоту разработки виртуального музея НИУ ВШЭ в данных условиях. По этой
причине было принято решение не использовать подобных систем вовсе, а часть
поведения (вроде логики работы с шаблонами у 1C-Bitrix) разработать
собственными средствами. Облегчающим ситуацию также является тот факт, что,
забегая вперед можно сказать, что управление пользователями не несет в себе
почти никакой сложности: планируется использовать только две роли - посетителя,
просматривающего виртуальный музей и музейного работника, управляющего его
содержимым. Подводя итог обзору систем управления содержимым, можно сказать,
что в данном конкретном случае ее использование не так уж и необходимо, при том
что необходимый функционал возможно создать самим, ведь, согласно [5] , первое
и главное правило систем управления содержимым - это то что вы используете не
ту систему, которую следовало бы.
2.
Проектирование подсистемы
Перед переходом к этапу непосредственной разработки
подсистемы необходимо обозначить ее рамки и возможности, т.к. команда
разработчиков работает параллельно, отдельно отвечая и предъявляя уточненные
требования к разрабатываемой подсистеме. Исходными данными каждого члена
команды является техническое задание, разработанное для Виртуального музея НИУ
- ВШЭ в целом, описывающее требования к нему в максимально обобщенной форме.
Именно поэтому для дальнейшей разработки данной подсистемы необходимо, изучив
исходное общее техническое задание, составить частное техническое задание на
конкретную подсистему серверной части.
2.1
Составление частного технического задания
Полученное техническое задание отражает требования для
системы Виртуального музея в целом и лишь немного затрагивает ключевые параметры
разрабатываемой подсистемы серверной части. По этой причине необходимо
разработать частное техническое задание на конкретную подсистему с уточненными
требованиями, конкретным функционалом и условиями работы.
Необходимое частное техническое задание было составлено в
ходе общения с заказчиком, с ним можно ознакомиться в Приложении 1.
Среди наиболее важных и достойных упоминания требований
являются требования к составу выполняемых функций, а именно:
. Добавление/редактирование/удаление экспонатов на
веб-странице.
2. Добавление/редактирование/удаление экспозиций на
веб-странице.
. Добавление шаблонов путем импорта.
. Генерация веб-страницы по шаблону с содержимым
экспоната/экспозиции.
Также стоит перечислить минимальный список веб-страниц,
которые должна уметь генерировать подсистема:
. Разводная страница Виртуального музея со списком
доступных экспозиций, оформленная по шаблону.
2. Страница экспозиции со ссылками на другие экспозиции и
внутренние экспонаты, оформленная по шаблону.
. Страница экспоната со ссылками на другие экспонаты и
экспозиции, оформленная по шаблону.
. Специальная панель администрирования музейного
работника для редактирования экспоната/экспозиции/шаблона.
На основе перечисленных требований можно приступить к этапу
проектирования объектной модели подсистемы.
2.2 Описание
вариантов использования подсистемы
После того, как основные функциональные возможности
подсистемы были формализованы и описаны, можно приступать к формированию общего
видения процесса работы подсистемы, определить ее границы и пользователей.
Удобным инструментом для этого является диаграмма вариантов использования (см.
рис. 2.1).
Рисунок 2.1 Диаграмма вариантов использования
Как сразу можно заметить, разрабатываемая подсистема является
модулем сервера приложений и используется им при генерации веб-страниц. Эта
функция является наиболее важной для подсистемы и именно с ней связаны
бизнес-процессы, автоматизируемые разрабатываемой подсистемой.
Далее идут функции, связанные непосредственно с предметной
областью Виртуального музея, а именно работа с шаблонами, экспонатами и
экспозициями: всем тем, что наполняет Виртуальный музей содержимым. На нижнем
уровне располагаются базовые функции при работе с содержимым (CRUD: create,
read, update, delete). Эти функции имеют несколько меньшее значение, т.к. их
результат может быть без особых усилий получен вручную путем редактирования
исходных данных в месте их нахождения (база данных для экспонатов и экспозиций,
либо файловая система для шаблонов).
Также стоит отметить, что непосредственно с подсистемой могут
работать две группы пользователей: музейный работник, либо верстальщик шаблонов
и обычный пользователь - посетитель Виртуального музея.
Музейный работник в основном вовлечен в работу функций,
обеспечивающих Виртуальный музей содержимым, но он также может взять на себя
роль обычного посетителя и просматривать генерируемые страницы.
Обычный посетитель взаимодействует с подсистемой лишь в одном
ключе. При запросе страниц сервер приложений использует подсистему для
генерации страницы. При этом пользователь может даже и не знать, что страница
была сгенерирована на стороне, а не взята напрямую с сервера приложений.
2.2 Описание
видов деятельности подсистемы
Как уже было сказано ранее, наиболее важной функцией
подсистемы сервера приложений является генерация веб-страниц по определенным
правилам, а точнее согласно некоторому шаблону, который назначается каждой
сущности Виртуального музея, имеющей необходимость быть отображенной на
странице в том или ином виде.
По этой причине следующими рассмотренными диаграммами будут
диаграммы активности, отражающей некоторые динамические аспекты поведения
системы в виде потока управления, переходящего от одной деятельности к другой.
Первая из них - генерации веб-страницы (см. рис. 2.2).
В работе этой функции можно выделить 3 основные сущности:
пользователя, подсистему и хранилище данных.
Рисунок 2.2 Диаграмма активности генерации веб-страницы
Инициатором данной функции является пользователь в момент,
когда пытается перейти на какую-либо страницу Виртуального музея. Подсистема в
ответ на запрос сервера приложений о предоставлении определенной веб-страницы
вначале определяет, по какому шаблону должна быть сгенерирована страница. Эта
информация содержится в объекте из предметной области. После получения и
обработки шаблона подсистема определяет, какие данные должны быть отображены на
странице, согласно шаблону. Далее она формирует запрос к хранилищу данных, где
находятся все возможные реализации всех возможных объектов, присутствующих в
Виртуальном музее, и получает результат в виде содержимого этих объектов. В
конце она заполняет имеющийся шаблон полученным содержимым и возвращает
результат серверу приложений как веб-страницу, которую он сможет вернуть агенту
пользователя (браузеру) для отображения. Пользователь, получив веб-страницу
может нажать на одну из присутствующих там ссылок и запустить весь процесс
заново для нового запроса.
Следуя логике описания диаграммы вариантов использования,
далее можно рассмотреть дополнительные функции в виде входа в подсистему,
редактирования экспоната/экспозиции и импорта шаблона.
Процесс входа в подсистему (см. рис. 2.3) довольно очевиден и
ничем не примечателен: музейный работник нажимает на соответствующую кнопку и
вводит личные данные, после чего подсистема пересылает его на страницу
администрирования в случае их верности, либо сообщает об ошибке.
Рисунок 2.3 Диаграмма активности входа в подсистему
Следующим рассмотренным процессом будет процесс создания
нового объекта предметной области (экспоната/экспозиции) (см. рис.2.4).
Данный процесс может быть инициирован пользователем из
административной панели (после входа в подсистему) в соответствующем списке
(список экспонатов для создания нового экспоната и список экспозиций для
создания новой экспозиции). В ответ на это подсистема вернет форму для
заполнения данных нового объекта. Формирование непосредственного содержимого
начнется после того, как музейный работник выберет необходимый шаблон
отображения, на основе которого подсистема сформирует страницу с предпросмотром
уже добавленного содержимого и возможностью заполнения пустых ячеек, описанных
в выбранном шаблоне. После всех необходимых действий музейный работник завершит
создание нажатием на кнопку "Завершить", дав тем самым подсистеме
команду на добавление нового объекта в хранилище данных.
Рисунок 2.4 Диаграмма активности создания
экспоната/экспозиции
Похожие действия необходимо совершить при редактировании
экспоната/экспозиции (см. рис. 2.5). У каждой записи в списке имеющихся
объектов Виртуального музея есть возможность редактирования параметров и содержимого
путем нажатия на соответствующую кнопку "Настройка". Подсистема
должна будет отобразить страницу редактируемого объекта в соответствии с
прикрепленным к нему шаблону и заполнить ее параметрами и содержимым этого
объекта, чтобы музейный работник смог их изменить и сохранить.
Рисунок 2.5 Диаграмма активности редактирования
экспоната/экспозиции
Последняя из операций редактирования - удаление - также не
несет в себе никакой сложности (см. рис. 2.6). У каждой записи в списке помимо
кнопки изменения присутствует возможность удаления. Для этого необходимо нажать
на кнопку "Удалить" и подсистема избавится от ненужного элемента
Виртуального музея.
Рисунок 2.6 Диаграмма активности удаления
экспоната/экспозиции
Последней нерассмотренной возможностью подсистемы является
возможность назначения отображаемому объекту некоторого шаблона, который будет
определять то, как будет выглядеть на веб-странице любой объект, закрепленный
за данным шаблоном (см. рис. 2.7). На самом деле эта функция является частью
блока редактирования объекта, однако отдельно выделить ее было необходимо, т.к.
она играет важнейшую роль с точки зрения функционирования системы.
Описываемое действие происходит при редактировании
экспоната/экспозиции. Закрепленный за объектом шаблон является одним из его
атрибутов, который можно назначить или сменить в соответствующем выпадающем
списке шаблонов, взятом из хранилища данных. Выбор шаблона и сохранение
изменений происходит по описанной ранее схеме внесения изменений.
Рисунок 2.7 Диаграмма активности назначения шаблона
экспонату/экспозиции
2.3 О писание
сценариев взаимодействия подсистемы
На данном этапе проектирования подсистемы необходимо рассмотреть
основные сценарии взаимодействия объектов для некоторых выявленных прецедентов
(вариантов использования). Для этого можно построить диаграммы
последовательностей, которые могут описывать эти события. Они могут отражать
взаимодействие элементов подсистемы и показывать передаваемую информацию в виде
сообщений. К примеру, один из сценариев выполнения процедуры генерации
веб-страницы может выглядеть следующим образом (см. рис. 2.8).
Данный процесс отражает тот же самый прецедент, что и
соответствующая диаграмма активности, но с некоторыми уточнениями. К примеру,
на диаграмме можно заметить, что шаблон для подсистемы предоставляется
операционной системой, то есть шаблон по сути это файл с некоторой
формализованной разметкой, который разбирается подсистемой и используется для
генерации веб-страницы с использованием данных, полученных от хранилища.
Рисунок 2.8 Диаграмма последовательности генерации
веб-страницы
Следующим важным взаимодействием является назначение некоторому
объекту виртуального музея шаблона отображения (см. рис. 2.9). Данный сценарий
может быть запущен в двух случаях: создании и редактировании
экспоната/экспозиции. Подсистема в ответ на это вернет соответствующий объект
(пустой в случае создания и чем-то заполненный в случае редактирования) и
отобразит его в форме редактирования. В момент, когда музейный работник
попытается открыть список имеющихся шаблонов для выбора, произойдет запрос к
хранилищу данных на получение шаблонов и отображение их в выпадающем списке.
Выбор необходимого шаблона и сохранение изменений завершат данный сценарий.
Рисунок 2.9 Диаграмма последовательности назначения шаблона
Наконец, последним важным сценарием подсистемы является
импорт шаблонов (см. рис. 2.10).
Рисунок 2.10. Диаграмма последовательности импорта шаблона
Запускается сценарий желанием музейного работника добавить
новый шаблон путем нажатия соответствующей кнопки в административной панели. Подсистема
обращается к операционной системе для доступа к файлам. После того, как
музейный работник выбрал необходимый шаблон, подсистема формирует запрос к
хранилищу данных на добавление ссылки к соответствующему шаблону, находящемуся
в файловой системе.
2.4 Описание
диаграммы классов подсистемы
На данный момент осталось лишь описать диаграмму классов,
определяющую типы классов системы и связи между ними. С этой диаграммой можно
ознакомиться ниже (см. рис. 2.11).
Основным связующим элементом подсистемы с хранилищем данных
является драйвер базы данных. Он осуществляет все операции по взаимодействию и
может быть вызван в любом месте подсистемы. На всю подсистему допускается
только один такой объект, поэтому класс должен быть статическим.
Тип содержимого это перечисление, которое в дальнейшем может
измениться. Он отражает то, какой тип содержимого может существовать в
Виртуальном музее.
Экспозиция и артефакт являются главными сущностями предметной
области. Они могут быть отображены и просмотрены по определенным правилам,
поэтому наследуют от двух интерфейсов, описывающих возможное поведение таких
объектов. Они хранят информацию о шаблоне, который используется для их
отображения и о содержимом, которое используется для его наполнения. Экспозиция
в свою очередь может содержать несколько фреймов которые и определяют
наполнение ее содержимого.
Шаблон может быть использован любой сущностью, для которой
предусматривается отображение по определенным правилам и реализует функционал
подстановки определенного содержимого в свою структуру.
На этом моменте можно завершить этап проектирования объектной
модели подсистемы и приступить непосредственно к ее реализации.
Рисунок 2.11. Диаграмма классов
3. Разработка
подсистемы
Наиболее распространенным и поддерживаемым интерпретатором
языка программирования в т. н. "джентельменских наборах"
разработчиков является интерпретатор языка PHP. Именно поэтому данный язык и
был выбран основным инструментом реализации серверной части Виртуального музея.
Учитывая тот факт, что веб-разработка серверных частей не являлось одним из
курсов, пройденных во время обучения на направлении, пришлось предварительно
пройти курс обучения по данному языку [6]. Также очень большую пользу во время
самой разработки оказала онлайн-документация [7], предоставляющая
исчерпывающую информацию о сигнатурах и способах применения различных методов,
реализованных в языке PHP.
Как уже было отмечено на этапе проектирования, наиболее
важным функционалом подсистемы является способность генерирования содержимого
по определенному шаблону.
3.1
Реализация основного функционала подсистемы
Начать стоит с т. н. разводной страницы, являющейся
своеобразным начальным пунктом (см. рис. 3.1), из которого посетитель сможет
перейти на одну из экспозиций или войти в специальную панель администрирования,
в которой присутствует функционал управления содержимым виртуального музея.
Каждая экспозиция здесь представлена в виде плитки с некоторым изображением,
которое может дать первое представление о том, о чем данная экспозиция может
рассказывать. Генерацию этих плиток берет на себя подсистема. Отсутствие
непосредственного сцепления плитки с местом на странице дает множество
вариантов динамической генерации содержимого разводной страницы: первыми можно
выводить новейшие экспозиции или сортировать их расположение по любому другому
критерию.
Для того, чтобы получить доступ к панели администрирования
необходимо иметь логин и пароль от подсистемы (см. рис.3.2). Это обусловлено
тем, что данная панель дает доступ непосредственно к хранилищу данных,
содержимое которого и предоставляется для просмотра на страницах Виртуального
музея. Доступом к этой панели должны обладать только музейные работники,
которые и будут управлять всем имеющимся содержимым. Управляющие элементы
данной формы авторизации создаются самим браузером. Управление учетными
записями пользователя возложено, согласно диаграмме прецедентов, на системного
администратора сервера приложений, на котором работает Виртуальный музей.
Рисунок 3.1 Разводная страница виртуального музея
(динамическая часть)
Рисунок 3.2 Форма авторизации
Нажимая на плитку одной из экспозиций, посетитель попадает на
страницу этой экспозиции, причем эта страница каждый раз генерируется заново и
нигде не хранится в жестком закодированном виде. Генерация осуществляется с
помощью шаблона, который определяет всю разметку страницы, начиная с контейнера
содержимого "content".
Шаблон представляет из себя текстовый файл, похожий на формат
XML, но с небольшим отличием. Он может иметь специальный тег "frame"
с обязательным атрибутом "name", который будет восприниматься
системой как место для замены тега конкретной реализацией. Пример шаблона можно
увидеть ниже (см. рис. 3.3).
Встретив такой тег, система запомнит его и все его атрибуты в
памяти, а затем, когда шаблон будет применен к какой-либо сущности (Экспозиция,
Артефакт) подсистема будет просматривать фреймы, которые имеет сущность и
вставлять их на место в шаблоне. Вставка будет осуществляться при совпадении
атрибутов тега "name" из шаблона и сущности. Если фрейм с именем,
описанным в шаблоне, в сущности будет не найден, подсистема на месте этого фрейма
выведет сообщение об его отсутствии, или любое другое сообщение, которое будет
реализовано на соответствующее событие в классе фрейма подсистемы. Это говорит
о том, что сущность должна реализовывать абсолютно все фреймы, описанные в
шаблоне, для корректного отображения. Такое поведение также присутствует в
механизме работы интерфейсов языков программирования. Сама реализация фрейма
подсистему абсолютно не волнует, и она отобразит именно то, что описано в
реализации конкретного фрейма, находящегося в отображаемой сущности (см. рис.
3.4).
Рисунок 3.4 Пример отсутствующего фрейма
Результатом работы подсистемы будет сгенерированная страница,
заполненная содержимым некоторого объекта (см. рис.3.5). Код функции замены тегов
шаблона на конкретную реализацию фрейма представлен в Приложении 2.
Рисунок 3.5 Пример заполнения шаблона
Как видно из примера, некоторые фреймы были найдены в
отображаемом объекте (intro, outro, image) и были заменены конкретной
реализацией. Более того, атрибуты фреймов, в частности атрибут "alt",
также был перенесен в реализацию помимо самого изображения. Однако, можно
заметить, что некоторые фреймы не смогли найти реализации в данном объекте, о
чем они проинформировали выведением сообщения об отсутствующем фрейме. Способов
решения данной проблемы два: применение другого шаблона для отображения
объекта, либо редактирование содержания этого объекта путем добавления
нереализованных фреймов, описанных в шаблоне.
Помимо главного функционала необходимо было предоставить
возможность сотрудникам Виртуального музея управлять его содержимым прямо
внутри браузера. Для этой цели была разработана специальная административная
панель, которая выводит на страницу все содержимое музея и позволяет совершать
над ним CRUD-операции. Список артефактов музея можно увидеть ниже (см. рис.
3.6).
Рисунок 3.6 Список артефактов музея
Для того, чтобы артефакты можно было использовать в
каких-либо экспозициях, их необходимо вставлять во фреймы. Для этого необходимо
создать фрейм, содержимым которого и будет желаемый артефакт или артефакты (см.
рис. 3.7).
Создание фрейма можно представить в два этапа: сначала
музейный работник вводит имя (имя фрейма играет очень большую роль, т.к. именно
оно используется подсистемой при вставлении фрейма в шаблон) и тип содержимого
фрейма. После того, как был выбран тип содержимого, подсистема создает запрос
хранилищу данных на получение всех артефактов выбранного типа и предоставляет
их в виде списка, из которого можно выбрать требуемый артефакт и завершить
создание фрейма.
Рисунок 3.7 Создание нового фрейма
После того, как необходимые фреймы были созданы, можно
приступать к созданию экспозиции (см. рис. 3.8). Данный процесс напоминает сбор
"лего" по кусочкам Музейный работник должен сразу же выбрать шаблон,
который будет использоваться подсистемой для генерации веб-страницы новой
экспозиции. Сами шаблоны хранятся в файловой системе сервера приложений.
Подсистема находит их по ссылкам, которые хранятся в базе данных, и выводит их
в виде выпадающего списка.
Рисунок 3.8 Добавление новой экспозиции
После выбора шаблона для отображения ниже загрузится содержимое
с пустым шаблоном, в котором все ссылки на необходимые фреймы будут сообщать об
ошибке, т.к. к экспозиции на этот момент еще не было прикреплено ни одного
фрейма (см. рис. 3.9). На момент разработки подсистемы остальные члены команды
находились на разных этапах работы, поэтому некоторые стили и картинки иногда
могли не загружаться или отображаться.
Рисунок 3.9 Пустой шаблон экспозиции
Также на этапе проектирования было выявлено требование,
которое говорило о том, что подсистема должна поддерживать процесс импорта
новых шаблонов. Данный функционал также был реализован на панели
администрирования рядом со списком всех имеющихся в подсистеме шаблонов (см.
рис. 3.10). Для выполнения этого действия необходимо выбрать нужный шаблон и
ввести его описание (для каких типов экспозиций планируется применять данный
шаблон, к примеру). После нажатия на кнопку "загрузить" произойдет
закачивание файла шаблона на сервер приложений. Действие может закончиться
неудачно, если размер выбранного файла превысит максимально допустимый размер,
оговоренный в частном техническом задании (3МБ). Возможность выбора файлов
некорректного формата исключается путем использования маски формата при выборе
файла из файловой системы, однако есть вероятность, что даже при правильном
формате содержимое выбранного файла может не соответствовать синтаксическим
правилам (отсутствие закрывающих тегов там, где они должны быть, к примеру),
что приведет к выводу ошибки при разборе файла.
Рисунок 3.10. Импорт шаблонов
3.2 Итоги
этапа разработки подсистемы
В ходе разработки подсистемы были реализованы все требуемые
функции по управлению содержимым Виртуального музея и генерации веб-страниц.
Разработка велась с применением современных систем контроля версий [8] для
обеспечения безопасности кода в случае непредвиденных обстоятельств. Исходные
коды доступны на ресурсе облачного сервиса Bitbucket [9] .
Объем кода составил около двух тысяч строк на языке
программирования PHP.
Из-за сравнительно малого количества сценариев работы
подсистемы для проведения контроля ее качества был применен подход
исследовательского тестирования
Заключение
В ходе работы над выпускной квалификационной работой командой
разработчиков был проведен анализ предметной области Виртуального музея,
результаты которого отразились на этапе проектирования подсистемы серверной
части.
Также следует отметить, что разработанная подсистема имеет
достаточный функционал для удовлетворения требований Виртуального музея и ее
можно считать Lite версией полноценной системы управления содержимым со
специфичной областью применения.
Работу по стабилизации, тестированию и дополнению функционала
подсистемы планируется проводить не только до окончания работы над дипломной
работой, но и после, т.к. этот проект является командным, относится
непосредственно к НИУ ВШЭ - Пермь и его сопровождение может быть возложено на
последующих студентов.
На данном этапе работу по разработке подсистемы можно считать
завершенной, т.к. она удовлетворяет всем требованиям, поставленным в частном
техническом задании и диаграммах UML.
Библиографический
список
1. Первые
шаги // Руководство Joomla 3.0 [Электронный ресурс]. URL:
http://joomla.ru/docs/administrator/joomla3-start/1742-chto-takoe-joomla (дата
обращения: 15.04.2016).
2. B.
Ray, M. Hickey. ModX: The official guide, MODX, 2011.
. Основные
сведения // Документация для разработчиков 1С-Bitrix [Электронный ресурс]. URL:
http://dev.1c-bitrix.ru/api_help/ (дата обращения: 15.04.2016).
. Jonathan
Kahn, Strategic Content Management // Article [Электронный ресурс]. URL:
http://alistapart.com/article/strategic-content-management (дата обращения:
22.03.2016).
. Rory
Douglas, Managing Your Content Management System // Article [Электронный ресурс].
URL: http://alistapart.com/article/managing-your-content-management-system
(дата обращения: 22.03.2016).
. Онлайн
курсы по PHP // PHP. Быстрый старт [Электронный ресурс] URL:
http://geekbrains.ru/courses/65 (дата обращения: 07.12.2015).
. Справочник
языка PHP // Руководство по PHP [Электронный ресурс]. URL: https: // secure.
php.net/manual/ru/langref. php (дата обращения: 07.12.2015).
. Онлайн
документация // Основы Git [Электронный ресурс] URL: https: //
git-scm.com/book/ru/v1/ (дата обращения: 20.02.2016).
. Репозиторий
проекта "Virtual museum" [Электронный ресурс]. URL: https: //
bitbucket.org/L1feIsGood/museum (дата обращения: 25.05.2016).
Приложения
Приложение 1.
Частное техническое задание
Подсистема виртуального музея ниу вшэ - пермь.
Серверный модуль
Частное техническое задание
ВВЕДЕНИЕ
Наименование программы
Наименование - "Серверный модуль Виртуального музея НИУ
ВШЭ - Пермь". Далее - "Подсистема".
Краткая характеристика области применения программы
Программа предназначена для автоматизации процесса
обслуживания и предоставления содержимого Виртуального музея НИУ ВШЭ - Пермь.
Основание для разработки
Основание для проведения разработки
Основанием для проведения разработки подсистемы является
задание на прохождение преддипломной практики в рамках НИУ ВШЭ - Пермь.
План и график разработки подсистемы согласован с научным
руководителем Кузнецовым Д. Б.
Наименование и условное обозначение темы разработки
Наименование темы разработки - "Разработка подсистемы
Виртуального музея НИУ ВШЭ - Пермь".
Условное обозначение темы разработки (шифр темы) - "А.
В.00001".
Назначение разработки
Подсистема предназначена для автоматизации процесса
управления содержимым Виртуального музея НИУ ВШЭ - Пермь. Содержимое должно
быть использовано сервером приложений при генерации веб-страниц. Права на его
управление предоставляются в соответствии с ролями пользователей.
Функциональное назначение программы
Функциональным назначением программы является генерация
веб-страниц для сервера приложений и предоставление возможности добавления,
изменения и удаления содержимого Виртуального музея НИУ ВШЭ - Пермь
уполномоченным пользователям.
Эксплуатационное назначение программы
Программа является подсистемой сервера приложений,
обслуживающего Виртуальный музей НИУ ВШЭ - Пермь.
Конечными пользователями программы должны являться сотрудники
виртуального музея (музейный работник) и его посетители.
Требования к программе
Требования к функциональным характеристикам
Разграничение прав доступа: все пользователи делятся на 2
категории - музейный работник, посетитель.
Управление хранилищем данных: содержимое Виртуального музея,
находящееся в хранилище данных, контролируется подсистемой.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения
перечисленных ниже функций:
Добавление/редактирование/удаление экспонатов на
веб-странице.
Добавление/редактирование/удаление экспозиций на
веб-странице.
Добавление шаблонов путем импорта.
Генерация веб-страницы по шаблону с содержимым
экспоната/экспозиции.
Добавление/редактирование/удаление пользователей.
Требования к организации входных данных
Входные данные программы должны быть организованы в виде:
хранилища данных с необходимой информацией, а также ссылками на вспомогательные
медиа и метафайлы.
Под медиа файлами понимаются любые возможные ресурсы
Виртуального музея: картинки, видео, звук, которые могут быть включены в
экспонат/экспозицию и должны быть отображены на их странице.
Под метафайлами понимаются специальные текстовые файлы,
использующиеся подсистемой для генерации и разметки веб-страниц и заполнении их
содержимым экспоната/экспозиции: файлы шаблонов в формате.html,. xml,. php.
Файлы указанного формата должны размещаться (храниться) на
локальных или съемных носителях, отформатированных согласно требованиям
операционной системы.
Требования к организации выходных данных
Выходные данные программы должны быть организованы в
виде.html файла, который сервер приложений вернет агенту клиента для отображения
(браузеру).
Состав генерируемых страниц:
Разводная страница Виртуального музея со списком доступных
экспозиций, оформленная по шаблону.
Страница экспозиции со ссылками на другие экспозиции и
внутренние экспонаты, оформленная по шаблону.
Страница экспоната со ссылками на другие экспонаты и
экспозиции, оформленная по шаблону.
Специальная панель администрирования музейного работника для
редактирования экспоната/экспозиции/шаблона.
Страницы по обслуживанию виртуального музея, предоставляющие
список возможностей, согласно п. 4.1.1 данного документа.
Файлы указанного формата не должны размещаться (храниться) на
локальных или съемных носителях, а должны генерироваться каждый раз из шаблонов
согласно запросу пользователя.
Требования к временным характеристикам
Требуемая страница должна генерироваться не дольше 1 секунды
без учета времени обращения к хранилищу данных и файловой системе.
Требования к задержке на выполнение i/o операций не
предъявляются, т.к. сервер приложений не входит в структуру подсистемы и может
иметь любую конфигурацию.
Требования к надежности
Требования к обеспечению надежного (устойчивого)
функционирования программы
Надежное (устойчивое) функционирование программы должно быть
обеспечено выполнением совокупности организационно-технических мероприятий,
перечень которых приведен ниже:
Организацией бесперебойного питания технических средств.
Регулярным выполнением требований ГОСТ 51188-98. Защита
информации.
Испытания программных средств на наличие компьютерных
вирусов.
Необходимым уровнем квалификации сотрудников Виртуального
музея.
Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем
электропитания технических средств (иными внешними факторами), не фатальным
сбоем (не крахом) операционной системы, не должно превышать времени,
необходимого на перезагрузку операционной системы и запуск программы, при
условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью
технических средств, фатальным сбоем (крахом) операционной системы, не должно
превышать времени, требуемого на устранение неисправностей технических средств
и переустановки программных средств.
Отказы из-за некорректных действий оператора
Отказы программы по любым возможным действиям пользователя
(оператора) должны выдавать результат об отсутствующей странице (код ошибки
404).
Условия эксплуатации
Подсистема должна использоваться на ПК устройстве под
управлением Linux-подобной операционной системе.
Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны
обеспечиваться заданные характеристики, должны удовлетворять требованиям,
предъявляемым к техническим средствам в части условий их эксплуатации.
Требования к видам обслуживания
См. Требования к обеспечению надежного (устойчивого)
функционирования программы.
Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы
программы, составляет 3 человека - верстальщик, музейный работник и обычный
посетитель сайтов.
Музейный работник должен обладать практическими навыками
работы с графическим пользовательским интерфейсом веб обозревателя.
Требования к составу и параметрам технических средств
В состав технических средств сервера приложений должен
входитьсовместимый персональный компьютер, включающий в себя:
процессор Core i3 с тактовой частотой, 3 ГГц, не менее;
оперативную память объемом, 2 Гб, не менее;
жесткий диск объемом 1 Тб, и выше;
оптический манипулятор "мышь";
Доступ к Интернету.
Требования к информационной и программной совместимости
Требования к информационным структурам и методам решения
Программа должна являться частью большей системы, со
следующим списком подсистем:
Подсистема предоставления содержимого экспозиций и экспонатов
(данная подсистема).
Подсистема работы с архивом.
Подсистема предоставления ресурсов пользовательского
интерфейса.
Подсистема работы с архивом является источником данных для
данной подсистемы с хранилищем данных под управлением СУБД MYSQL.
Подсистема предоставления ресурсов пользовательского
интерфейса должна предоставлять файлы разметки для отображения на веб-странице.
Текстовые файлы шаблонов разметки не должны иметь
синтаксических ошибок с точки зрения языка HTML или XML и иметь размер не более
3МБ.
Медиа файлы должны иметь корректный формат:
. mp3,. wav для аудиофайлов, размер - не более 10Мб.
. avi,. mkv для видеофайлов, размер - не более 100Мб.
. png,. gif,. jpg для изображений, размер - не более 5Мб.
Требования к исходным кодам и языкам программирования
Все исходные файлы кода должны иметь расширение. php и быть
написаны, соответственно, на языке PHP.
Требования к программным средствам, используемым программой
Системные программные средства, используемые программой,
должны быть представлены локализованной версией операционной системы подобной
Linux.
Требования к защите информации и программ
Доступом к непосредственной информации (серверу приложений)
физически должен иметь только один человек (системный администратор).
Доступом к редактированию содержимого Виртуального музея
должен обладать любой авторизованный музейный работник на любом клиентском
месте работы.
Специальные требования
Программа должна обеспечивать взаимодействие с пользователем
(музейным работником) посредством графического пользовательского
веб-интерфейса, разработанного согласно рекомендациям проектирования
веб-страниц.
Требования к программной документации
Состав программной документации должен включать в себя:
Техническое задание.
Текст программы.
Программу и методики испытаний.
Протокол проведения испытаний.
Руководство пользователя.
Специальные требования к программной документации
Специальные требования к программной документации не
предъявляются.
Технико-экономические показатели
Ориентировочная экономическая эффективность
Ориентировочная экономическая эффективность не
рассчитываются.
Предполагаемая годовая потребность
Предполагаемое число использования программы в день - до 1000
единовременных пользователей.
Стадии и этапы разработки
Стадии разработки
Разработка должна быть проведена в три стадии:
Проектирование архитектуры.
. Рабочее проектирование.
. Внедрение.
Этапы разработки
На стадии разработки технического задания должен быть
выполнен этап разработки, согласования и утверждения настоящего технического
задания.
На стадии проектирования архитектуры должны быть составлены
диаграммы в нотации UML, отражающие структуру и последовательность работы
программы.
На стадии рабочего проектирования должны быть выполнены
перечисленные ниже этапы работ:
. Разработка программы.
. Разработка программной документации.
. Испытания программы.
На стадии внедрения должен быть выполнен этап разработки -
подготовка и передача программы.
Содержание работ по этапам
На этапе разработки технического задания должны быть
выполнены перечисленные ниже работы:
Постановка задачи.
Определение и уточнение требований к техническим средствам.
Определение требований к программе.
Определение стадий, этапов и сроков разработки программы и
документации на неё.
Выбор языков программирования.
Согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена работа по
программированию и отладке программы.
На этапе разработки программной документации должна быть
выполнена разработка программных документов в соответствии с требованиями ГОСТ
19.101-77 и требованием п. "Предварительный состав программной
документации" настоящего технического задания.
На этапе испытаний программы должны быть выполнены
перечисленные ниже виды работ:
Разработка, согласование и утверждение программы и методики
испытаний.
Проведение приемо-сдаточных испытаний.
Корректировка программы и программной документации по
результатам испытаний.
На этапе подготовки и передачи программы должна быть
выполнена работа по подготовке и передаче программы и программной документации
в эксплуатацию.
Порядок контроля и приемки
Виды испытаний
Приемо-сдаточные испытания программы должны проводиться
согласно разработанной и согласованной "Программы и методики
испытаний".
Ход проведения приемо-сдаточных испытаний документируется в
Протоколе проведения испытаний.
Общие требования к приемке работы
После проведения испытаний в полном объеме, на основании
"Протокола испытаний" выносится решение о завершении разработки.
Приложение 2.
Код генерации веб-страницы по шаблону