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

Оглавление

• Введение
• 1. Обзор и сравнение систем управления содержимым
• 1.1 Обзор системы управления содержимым Joomla
• 1.2 Обзор системы управления содержимым ModX
• 1.3 Обзор системы управления содержимым 1С-Bitrix
• 2. Проектирование подсистемы
• 2.1 Составление частного технического задания
• 2.2 Описание вариантов использования подсистемы
• 2.2 Описание видов деятельности подсистемы
• 2.3 О писание сценариев взаимодействия подсистемы
• 2.4 Описание диаграммы классов подсистемы
• 3. Разработка подсистемы
• 3.1 Реализация основного функционала подсистемы
• 3.2 Итоги этапа разработки подсистемы
• Заключение
• Библиографический список
• Приложения

Введение

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

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

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

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

1. Рассмотреть и сравнить имеющиеся решения в области управления содержимым сайтов.

2. Проанализировать предметную область (Виртуальный музей НИУ ВШЭ - Пермь).

3. Спроектировать объектную модель хранилища данных виртуального музея.

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

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

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

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

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

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

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

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

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

4. Разработка программы для сервера приложений.

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

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

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

Системы также можно разделить на бесплатные и коммерческие, причем невозможно однозначно выделить лучшую из них, либо с уверенностью сказать, что коммерческие варианты имеют определенный список преимуществ. Это совершенно не так. При рассмотрении различных систем управления содержимым важно понимать, что каждая из них нацелена на решение какой-то конкретной проблемы, и невозможно с легкостью перенести уже существующий веб-сайт с одной системы на другую. Все они требуют индивидуального подхода не только на этапе развертывания, но и на этапе поддержки. К примеру, ярким и очевидным недостатком бесплатных систем управления является отсутствие какой-либо официальной поддержки пользователей, ровно, как и сравнительно долгий, по сравнению с коммерческими версиями, временной промежуток между выходами новых версий. Выбор такой системы может повлечь за собой проблемы в будущем, если она применялась для создания коммерческого веб-сайта ввиду ее небезопасности. Однако, не стоит считать, что, купив платную систему управления содержимым, безопасность сайта и веб-сервера будет приемлемым, т.к. основные усилия разработчиков таких систем были брошены на создание наиболее приятного и удобного пользовательского интерфейса, поскольку он является наиболее очевидным критерием выбора системы для покупателей. При дальнейшем рассмотрении конкретных систем это можно будет заметить. Итак, среди систем управления содержимым, рассматриваемых в качестве пригодных для использования в рамках разработки виртуального музея НИУ ВШЭ были выбраны три наиболее популярные системы на российском рынке: Joomla, 1C-Bitrix и ModX. Их разбору и сравнительному анализу будет посвящена оставшаяся часть главы.

1.1 Обзор системы управления содержимым Joomla

Первой рассмотренной системой управления содержимым будет бесплатная система с открытым исходным кодом - Joomla [1].

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

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

виртуальный музей приложение web

Рис. 1.1 Главное меню Joomla

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

К примеру, выбор меню "Site” отобразит страницу, которая выведет основные настройки сайта, а также позволит настроить для него специальную страницу, отображающуюся в случае его отключения (см. рис. 1.2).

Рис. 1.2 Основные настройки

Более того, Joomla предоставляет функционал по оптимизации механизма поиска сайта для поднятия его позиции в результатах выдачи поисковых систем, что может позволить сэкономить на специалистах данной отрасли, или отказаться от их услуг вовсе (см. рис.1.3).

Рис. 1.3 Оптимизация поиска

Одной из самых основных возможностей систем управления содержимым сайтов конечно же является возможность настройки прав доступа и ролей пользователей. Joomla поддерживает данный функционал в меню "Настройки доступа" (см. рис. 1.4).

Рис. 1.4 Настройки доступа

Наконец, наиболее важная часть системы, с точки зрения наполнения сайта содержимым - добавление нового контента, к примеру статьи, осуществляется с помощью хорошего редактора, работающего по принципу WYSIWYG (What You See Is What You Get), полезного при разработке, позволяющего отображать результат работы сразу же после внесения изменений. В этом смысле у интерпретируемых языков, таких как PHP, появляется очевидное преимущество перед компилируемыми языками. Конечно же, в случае компилируемых языков существует такой механизм, как динамическое прототипирование, но он требует гораздо более высокой квалификации разработчика и намного больших затрат для реализации, не говоря уже о том, что его целесообразно использовать только с действительно большими проектами, время компиляции которых занимает большое количество времени (см. рис. 1.5).

Рис. 1.5 Работа со статьей

Итоги

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

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

1.2 Обзор системы управления содержимым ModX

Следующей рассмотренной системой управления содержимым сайта будет система под названием ModX [2] . Она, так же, как и Joomla, имеет открытый исходный код и открытую лицензию. В случае с ModX можно выделить максимально простой процесс установки, не требующий от пользователя практически никаких дополнительных операций. После входа в систему можно будет увидеть знакомое меню с уже известными по Joomla заголовками, однако содержание нижней части панели предоставляет уже другой функционал (см. рис. 1.6).

Рис. 1.6. Главное меню ModX

В этом описании будут опущены страницы, функционально похожие на варианты из Joomla и выделены новые.

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

Рис. 1.7 Управление ресурсами

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

Рис. 1.8 Работа с контекстами

Еще одной приятной особенностью для пользователя при работе с ModX является встроенная документация по любой интересующей функции (см. рис. 1.9).

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

Рис. 1.9 Справка по функции

Рис. 1.10 Менеджер пакетов

Итоги

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

1.3 Обзор системы управления содержимым 1С-Bitrix

Последней рассмотренной системой управления содержимым сайтов будет платная разработка отечественной компании 1С-Bitrix, являющаяся наиболее распространенной в российском сегменте [3] .

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

Рис. 1.11 Главное меню Bitrix

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

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

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

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

Шаблоны в Bitrix являются ничем иным, как представлениями в понимании MVC, от которого зависит не содержимое компонента (содержимое компонента как раз в компоненте и находится), а его оформление, то есть он определяет расположение и отображение некоторого объекта. Каждый шаблон получается соединением двух его частей: верхней (header) и нижней (footer). Компоненты используют шаблоны для построения содержимого страницы сайта, заполняя их содержимым, которое находится между шапкой (header) и подвалом (footer) шаблона. Также в него могут быть включены боковые панели для различных нужд (см. рис. 1.12).

Итоги:

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

Рис. 1.12 Структура шаблона

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

Оценка систем управления содержимым проводилась в рамках возможностей и нужд разработки виртуального музея НИУ ВШЭ. Это отразилось на итоговых критериях оценки и их значимости (см. табл.1.1).

Табл. 1.1 Сравнительная характеристика систем управления содержимым

Критерий	Joomla	ModX	1C-Bitrix
Хранилища данных	MySql, MS SQL, PostgreSQL	MySql, MS SQL	MySql, MS SQL, Oracle
Управление пользователями	+	+	+
Наличие WYSIWYG редактора	+ (расширения)	+	-
Доступность (коммерческая)	+	+	-
Кроссплатформенность	+	+	+
Наличие доступной документации	-	-	+

При выборе системы управления содержимым будущего сайта необходимо учитывать несколько факторов. Согласно [4] , процесс выбора можно представить в виде диаграммы (см. рис. 1.13).

Рис. 1.13. Процесс внедрения системы управления содержимым

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

1. Отсутствие бюджета на закупку каких-либо программных средств.

2. Unix-подобная платформа сервера с поддержкой MySQL.

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

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

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

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

В конце концов получается так, что ни одна из рассмотренных систем управления содержимым сайта не сможет обеспечить необходимую быстроту и простоту разработки виртуального музея НИУ ВШЭ в данных условиях. По этой причине было принято решение не использовать подобных систем вовсе, а часть поведения (вроде логики работы с шаблонами у 1C-Bitrix) разработать собственными средствами. Облегчающим ситуацию также является тот факт, что, забегая вперед можно сказать, что управление пользователями не несет в себе почти никакой сложности: планируется использовать только две роли - посетителя, просматривающего виртуальный музей и музейного работника, управляющего его содержимым. Подводя итог обзору систем управления содержимым, можно сказать, что в данном конкретном случае ее использование не так уж и необходимо, при том что необходимый функционал возможно создать самим, ведь, согласно [5] , первое и главное правило систем управления содержимым - это то что вы используете не ту систему, которую следовало бы.

2. Проектирование подсистемы

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

2.1 Составление частного технического задания

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

Необходимое частное техническое задание было составлено в ходе общения с заказчиком, с ним можно ознакомиться в Приложении 1.

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

1. Добавление/редактирование/удаление экспонатов на веб-странице.

2. Добавление/редактирование/удаление экспозиций на веб-странице.

3. Добавление шаблонов путем импорта.

4. Назначение экспонату/экспозиции определенного шаблона для отображения.

5. Генерация веб-страницы по шаблону с содержимым экспоната/экспозиции.

Также стоит перечислить минимальный список веб-страниц, которые должна уметь генерировать подсистема:

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

2. Страница экспозиции со ссылками на другие экспозиции и внутренние экспонаты, оформленная по шаблону.

3. Страница экспоната со ссылками на другие экспонаты и экспозиции, оформленная по шаблону.

4. Специальная панель администрирования музейного работника для редактирования экспоната/экспозиции/шаблона.

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

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).

Рисунок 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.

3. Основные сведения // Документация для разработчиков 1С-Bitrix [Электронный ресурс]. URL: http://dev.1c-bitrix.ru/api_help/ (дата обращения: 15.04.2016).

4. Jonathan Kahn, Strategic Content Management // Article [Электронный ресурс]. URL: http://alistapart.com/article/strategic-content-management (дата обращения: 22.03.2016).

5. Rory Douglas, Managing Your Content Management System // Article [Электронный ресурс]. URL: http://alistapart.com/article/managing-your-content-management-system (дата обращения: 22.03.2016).

6. Онлайн курсы по PHP // PHP. Быстрый старт [Электронный ресурс] URL: http://geekbrains.ru/courses/65 (дата обращения: 07.12.2015).

7. Справочник языка PHP // Руководство по PHP [Электронный ресурс]. URL: https: // secure. php.net/manual/ru/langref. php (дата обращения: 07.12.2015).

8. Онлайн документация // Основы Git [Электронный ресурс] URL: https: // git-scm.com/book/ru/v1/ (дата обращения: 20.02.2016).

9. Репозиторий проекта "Virtual museum" [Электронный ресурс]. URL: https: // bitbucket.org/L1feIsGood/museum (дата обращения: 25.05.2016).

Приложения

Приложение 1. Частное техническое задание

Подсистема виртуального музея ниу вшэ - пермь. Серверный модуль

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

ВВЕДЕНИЕ

Наименование программы

Наименование - "Серверный модуль Виртуального музея НИУ ВШЭ - Пермь". Далее - "Подсистема".

Краткая характеристика области применения программы

Программа предназначена для автоматизации процесса обслуживания и предоставления содержимого Виртуального музея НИУ ВШЭ - Пермь.

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

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

Основанием для проведения разработки подсистемы является задание на прохождение преддипломной практики в рамках НИУ ВШЭ - Пермь.

План и график разработки подсистемы согласован с научным руководителем Кузнецовым Д. Б.

Наименование и условное обозначение темы разработки

Наименование темы разработки - "Разработка подсистемы Виртуального музея НИУ ВШЭ - Пермь".

Условное обозначение темы разработки (шифр темы) - "А. В.00001".

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

Подсистема предназначена для автоматизации процесса управления содержимым Виртуального музея НИУ ВШЭ - Пермь. Содержимое должно быть использовано сервером приложений при генерации веб-страниц. Права на его управление предоставляются в соответствии с ролями пользователей.

Функциональное назначение программы

Функциональным назначением программы является генерация веб-страниц для сервера приложений и предоставление возможности добавления, изменения и удаления содержимого Виртуального музея НИУ ВШЭ - Пермь уполномоченным пользователям.

Эксплуатационное назначение программы

Программа является подсистемой сервера приложений, обслуживающего Виртуальный музей НИУ ВШЭ - Пермь.

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

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

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

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

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

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

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

Добавление/редактирование/удаление экспонатов на веб-странице.

Добавление/редактирование/удаление экспозиций на веб-странице.

Добавление шаблонов путем импорта.

Назначение экспонату/экспозиции определенного шаблона для отображения.

Генерация веб-страницы по шаблону с содержимым экспоната/экспозиции.

Добавление/редактирование/удаление пользователей.

Требования к организации входных данных

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

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

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

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

Требования к организации выходных данных

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

Состав генерируемых страниц:

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

Страница экспозиции со ссылками на другие экспозиции и внутренние экспонаты, оформленная по шаблону.

Страница экспоната со ссылками на другие экспонаты и экспозиции, оформленная по шаблону.

Специальная панель администрирования музейного работника для редактирования экспоната/экспозиции/шаблона.

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

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

Требования к временным характеристикам