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

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

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

Пермский филиал федерального государственного автономного образовательного учреждение высшего образования Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Баранова Мария Сергеевна

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

Выпускная квалификационная работа студента образовательной программы «Программная инженерия» по направлению подготовки 09.03.04 Программная инженерия

Рецензент к.т.н., директор ООО «ИТИС» А.С. Иванов

Руководитель старший преподаватель кафедры высшей математики М.В. Крючков

Пермь, 2019



Аннотация

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

В работе затрагиваются такие аспекты разработки программного обеспечения, как анализ предметной области (анализ текущих бизнес-процессов заказчика, анализ требований, анализ подходов к разработке рекомендательных систем), проектирование системы (бизнес-процессы «to-be», база данных, пользовательский интерфейс, рекомендательная система) и реализация системы. Разрабатываемая система предназначена для следующих категорий пользователей: сотрудники департамента культуры и молодёжной политики Администрации г. Перми (ДКиМП), сотрудники подведомственных учреждений ДКиМП, граждане и гости г. Перми.

Работа состоит из трёх глав. Количество страниц: 86. Количество приложений: 3. Количество иллюстраций: 31.



Оглавление

Введение

Глава 1. Анализ предметной области оповещения граждан о событиях

1.1 Анализ бизнес-процессов «as-is»

1.2 Обзор аналогичных систем

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

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

1.4.1 Пользовательские требования

1.4.2 Ограничения

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

1.5 Анализ подходов к реализации рекомендательной системы

1.5.1 Анализ базовых подходов к построению рекомендательных систем

1.5.2 Анализ подходов к построению гибридных рекомендательных систем

Глава 2. Проектирование системы управления анонсами событий

2.1 Анализ бизнес-процессов «to-be»

2.2 Сценарии использования системы

2.2.1 Сценарии использования для подсистемы занесения данных о мероприятиях

2.2.2 Сценарии использования для подсистемы модерации данных о мероприятиях

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

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

2.4 Проектирование интерфейса

2.4.1 Описание пользовательского интерфейса для редактора мероприятий

2.4.2 Описание пользовательского интерфейса для модератора

2.4.3 Описание пользовательского интерфейса для посетителя сайта-афиши

2.5. Проектирование рекомендательной системы

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

Глава 3. Реализация системы

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

3.1.1 Выбор технологий для реализации системы

3.1.2 Особенности выбранных технологий, используемые при реализации системы

3.1.3 Основные классы и методы реализуемого приложения

3.1.4 Реализация рекомендательной системы

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

Заключение

Библиографический список

Приложение А

Приложение Б

Приложение В



Введение

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

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

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

Таким образом, возникла необходимость в системе, которая с одной стороны будет играть роль точки сбора данных от подведомственных учреждений и составлять на основе этих данных отчётные документы, а с другой стороны обеспечит информационную среду, с помощью которой жители и гости г. Перми смогут получить информацию о культурных мероприятиях. Заказчиком программы, реализация которой описывается в данной работе, является департамент культуры и молодёжной политики администрации города Перми. Компания-разработчик - ООО «Инновационные технологии информационных систем» (ООО «ИТИС»).

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

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

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

Проанализировать требования к системе в целом.

Выявить место разрабатываемой программы в данной системе.

Проанализировать бизнес-процессы, реализуемые программой.

Выявить требования к программе.

Выполнить проектирование программы.

Выполнить разработку программы.

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

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

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

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

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

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

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

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

Кроме того, одна из проблем, с которыми сталкиваются некоторые системы - проблема «холодного старта», т.е., сложности при запуске системы с отсутствием данных по пользовательским предпочтениям или пользовательскому поведению [2]. Данную проблему необходимо будет учитывать при разработке описываемой в работе системе, поскольку при первичном запуске системы данные о пользовательском поведении и предпочтениях будут отсутствовать.

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

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

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

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

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



1. Анализ предметной области оповещения граждан о событиях

В данной главе проводится анализ бизнес-процессов «as-is». На основе анализа выявляются недостатки существующих бизнес-процессов и формируются требования к бизнес-процессам «to-be».

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

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

1.1 Анализ бизнес-процессов «as-is»

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

В настоящий момент информация о культурных мероприятиях размещается в виде новостных объявлений на сайтах gorodperm.ru (официальный сайт Администрации г. Перми) и cult.gorodperm.ru (сайт ДКиМП). Процесс размещения новостей на сайте gorodperm.ru см. на рис. 1.1.

Размещение новостей на сайте Администрации г. Перми является сложным бизнес-процессом, имеющим трех участников: подведомственные учреждения, ДКиМП и пресс-служба Администрации г. Перми. Перед тем, как попасть на сайт, информация о мероприятии должна поступить к ДКиМП, а пройдя обработку, поступить к пресс-службе Администрации. Только после одобрения пресс-службой информация о мероприятии поступает на сайт gorodperm.ru.

Рисунок 1.1 - Бизнес-процесс «as-is» размещения информации о культурных мероприятиях на сайте gorodperm.ru

Данный бизнес-процесс имеет несколько недостатков. Во-первых, поскольку сайт gorodperm.ru является официальным сайтом Администрации г. Перми, поступающая на него информация проходит жесткий отбор. Таким образом, на сайт поступают сведения только о крупных городских мероприятиях. В свою очередь для ДКиМП требуется информировать граждан о мероприятиях различного масштаба, в т.ч., незначительных.

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

Первый недостаток частично устраняется ДКиМП с помощью размещения новостных объявлений на сайте cult.gorodperm.ru. Однако, как в случае с сайтом gorodperm.ru, сотрудники ДКиМП вынуждены подготавливать анонсы мероприятий самостоятельно, т.е., второй недостаток существующего бизнес-процесса остается нескорректированным.

Информацию о культурных мероприятиях граждане могут получать с помощью следующих источников:

Афиши на улицах города.

Социальные сети.

Официальный сайт Администрации г. Перми.

Сайт ДКиМП.

Данные источники информации обладают следующими недостатками:

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

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

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

Трудоемкость размещения информации.

Неполнота предоставляемой информации.

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

1.2 Обзор аналогичных систем

В качестве аналогичных систем были исследованы сайты-афиши, на которых размещается информация о мероприятиях, проводимых в г. Перми. Было рассмотрено три сайта:

Яндекс.Афиша (https://afisha.yandex.ru/perm).

Отдых59.ru (https://afisha.59.ru/).

Афиша (https://www.afisha.ru/prm/).

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

Таблица 1.1 - Анализ аналогов сайта-афиши

	Яндекс.Афиша	afisha.ru	afisha.59.ru
Отображение мероприятий по смысловым категориям	+	+	+
Отображение мероприятий, проводимых в ближайшие дни	+	-	+
Возможность оставлять отзывы	+	+	-
Возможность ставить оценки «нравится/не нравится»	+	-	-
Возможность ставить оценки по цифровой шкале	-	+	-
Отображение месторасположения мероприятия на карте	+	+	-
Возможность приобрести билет на мероприятие	+	+	-
Возможность подписки на анонсы событий	+	+	-
Возможность добавлять мероприятия в избранное	+	+	-
Наличие в личном кабинете личного календаря событий	-	+	-
Возможность делиться анонсом мероприятия в социальных сетях	-	+	+
Поиск мероприятий по фильтрам	±	-	+

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

Рисунок 1.2 - Отображение мероприятий по смысловым категориям на «Яндекс.Афише»

Рисунок 1.3 - Отображение мероприятий по смысловым категориям на «Афише»

Рисунок 1.4 - Отображение мероприятий по смысловым категориям на «Отдых59.ru»

На главных страницах «Яндекс.Афиши» и «Отдых59.ru» расположен блок анонсов мероприятий, которые должны состояться в ближайшие дни. Данная возможность является полезной с точки зрения пользовательского опыта, т.к. обеспечивает быстрое решение задачи об организации досуга в ближайшее время. На рис. 1.5 и 1.6 приведены примеры данной особенности.

Рисунок 1.5 - Отображение событий в ближайшие дни на «Яндекс.Афише»

Рисунок 1.6 - Отображение событий в ближайшие дни на «Отдых59.ru»

«Яндекс.Афиша» и «Афиша» позволяют оставлять отзывы на мероприятия и оценить мероприятия (по цифровой шкале или шкале «нравится/не нравится»), таким образом позволяя другим пользователям сайта составить мнение о мероприятии. Функциональность данных сайтов также позволяет добавить авторизованным пользователям мероприятия в «избранное». Оба этих сайта предоставляют возможность подписаться на рассылку анонсов мероприятий по e-mail, что удобно для пользователей, активно пользующихся электронной почтой.

Поиск мероприятий по фильтрам реализован на сайте «Отдых59.ru», а также на «Яндекс.Афише». «Отдых59.ру» позволяет подобрать мероприятия по направленности (кино, концерт, выставка), дню и времени суток (см. рис. 1.7).

Рисунок 1.7 - Поиск мероприятий по критериям на «Отдых59.ru»

На «Яндекс.Афише» фильтры для поиска располагаются на странице конкретной категории событий и являются специализированными для каждой категории. Так, в категориях «Кино» и «Концерты» можно задать такие критерии поиска, как день и жанр, а в разделе «Театр» можно выбрать формат спектакля. Пример приведен на рис. 1.8.

Рисунок 1.8 - Поиск по критериям в разделе «Театр» на «Яндекс.Афише»



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

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

Для выявления пользовательских требований было проведено интервью с основной пользовательской группой - сотрудниками ДКиМП. В результате интервью были выявлены следующие требования верхнего уровня:

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

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

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

Рисунок 1.9 - Основные сценарии использования системы, выявленные в результате анализа пользовательских требований



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

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

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

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

№	Данные	Тип	Примечание
1	Название мероприятия	Строка
2	Направление	Строка	Значение из справочника
3	Вид	Строка	Значение из справочника
4	Возрастное ограничение	Строка	Значение из справочника
5	Минимальная стоимость билетов	Число
6	Максимальная стоимость билетов	Число	Не является обязательным параметром
7	Анннотация	Строка	Не более 500 знаков
8	Описание	Строка	Не более 1200 знаков
9	Район	Строка	Значение из справочника
10	Адрес	Строка
11	Дата начала	Дата
12	Дата окончания	Дата	Не обязательный параметр
13	Время начала	Время
14	Время окончания	Время	Не обязательный параметр
15	Расписание по числам	Составной тип	Не обязательный параметр. Является составным типом данных, состоящим из списка. Элемент списка состоит из даты, времени начала и времени окончания (время окончания не обязательный параметр).
16	Расписание по дням недели	Составной тип	Не обязательный параметр. Является составным типом данных, состоящим из списка. Элемент списка состоит из дня недели, времени начала и времени окончания (время окончания не обязательный параметр).
17	Афиша	Изображение	Допустимые форматы: .png, .jpg
18	Организатор мероприятия	Строка	Заполняется автоматически, данные берутся из учетной записи ПУ-редактора мероприятий
19	Телефон организатора	Строка	Заполняется автоматически, данные берутся из учетной записи ПУ-редактора мероприятий
20	Адрес организатора	Строка	Заполняется автоматически, данные берутся из учетной записи ПУ-редактора мероприятий

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

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

На основе выявленных недостатков существующих бизнес-процессов и пользовательских требований были проанализированы требования к бизнес-процессам «to-be». Данные требования можно разделить на две категории: пользовательские требования и ограничения.

1.4.1 Пользовательские требования

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

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

Даты проведения мероприятия.

Направление мероприятия.

Район проведения мероприятия.

Стоимость билетов.

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

1.4.2 Ограничения

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

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



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

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

Функциональные требования:

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

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

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

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

Даты проведения мероприятия.

Направление мероприятия.

Район проведения мероприятия.

Стоимость билетов.

Сайт-афиша должен давать персональные рекомендации мероприятий зарегистрированным на сайте пользователям.

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

Нефункциональные требования:

Система должна состоять из трех подсистем: подсистема занесения данных о мероприятиях, подсистема модерации данных о мероприятиях, подсистема визуализации культурных мероприятий (сайт-афиша).

Система должна обеспечить работу следующих ролей пользователей:

Редактор мероприятий. Заносит, редактирует и удаляет данные о плановых и фактически состоявшихся мероприятиях.

Модератор. Просматривает, редактирует анонсы мероприятий перед отправкой на сайт-афишу, отправляет новости на сайт-афишу.

Пользователь сайта-афиши. Просматривает анонсы мероприятий, осуществляет поиск мероприятий по критериям.

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

Сайт-афиша должен функционировать на основе системы управления контентом «1С Битрикс».

1.5 Анализ подходов к реализации рекомендательной системы

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

Небольшое (менее 100) количество элементов, подлежащих рекомендации.

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

Необходимо учитывать проблему «холодного старта», т.к. изначально данные о вновь зарегистрированном пользователе будут отсутствовать в системе.

1.5.1 Анализ базовых подходов к построению рекомендательных систем

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

При применении фильтрации, основанной на содержании, пользователю рекомендуются объекты, похожие на те, которые он уже просмотрел или оценил. Степень сходства объектов определяется их содержимым [1]. Данный подход опирается на поведение исключительно одного пользователя, поведение других пользователей в системе не учитывается [4]. Применение фильтрации на основе содержания возможно для постоянно изменяющегося множества элементов, поскольку в профиле пользователя сохраняется информация о свойствах просмотренных им элементов.

Коллаборативная фильтрация, напротив, при поиске элементов для рекомендации учитывает сходство пользователя с другими пользователями [1]. При том конкретному пользователю рекомендуются объекты, просмотренные или оцененные похожими на него пользователями, но не просмотренные им самим.

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

Оба описанных выше подхода сталкиваются с проблемой «холодного старта», поскольку при отсутствии информации о новых пользователях или объектах поиск рекомендаций затрудняется. Частично решить данную проблему помогает применение гибридных подходов, которые сочетают коллаборативную и контентную фильтрацию. Также гибридные подходы потенциально повышают точность рекомендаций [4].

Необходимо отметить, что данные подходы применимы к небольшим множествам данных.

Ниже приведен анализ описанных подходов на соответствие требованиям системы (табл. 1.3).

Таблица 1.3 - Анализ подходов к реализации рекомендательной системы

	Фильтрация, основанная на содержании	Коллаборативная фильтрация	Гибридный подход
Возможность работы с небольшими множествами элементов	+	+	+
Возможность работы с постоянно изменяющимся множеством анонсов мероприятия	+	-	+
Возможность «холодного старта»	-	-	±

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

1.5.2 Анализ подходов к построению гибридных рекомендательных систем

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

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

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

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

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

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

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

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

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

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

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

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

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



Таблица 1.4 - Результаты анализа подходов к построению гибридной рекомендательной системы

	Возможность работы с постоянно изменяющимся множеством анонсов мероприятия	Невысокая трудоемкость реализации алгоритма
Взвешенный	-	+
Переключения	-	-
Смешанный	-	+
Комбинация признаков	+	+
Каскадный	-	-
Мета-обучение	?	-

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

Вывод по главе 1

В главе 1 была изучена предметная область. Были проанализированы бизнес-процессы «as-is» и найдены их слабые стороны. Основными проблемами текущих бизнес-процессов является трудоемкость подготовки анонсов мероприятий, а также отсутствие единой информационной площадки, посредством которой граждане и гости города Перми могли бы узнавать о предстоящих культурных мероприятиях различных масштабов.

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

На основе анализа были сформулированы функциональные и нефункциональные требования к системе. На основе анализа бизнес-процессов и требований будут проектироваться бизнес-процессы «to-be» и сценарии использования системы.

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

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

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



2. Проектирование системы управления анонсами событий

2.1 Анализ бизнес-процессов «to-be»

Процесс размещения анонсов мероприятий представлен в виде диаграммы активностей на рис. 2.1.

Рисунок 2.1 - Бизнес-процесс «to-be» размещения анонса на сайте-афише

Редактор мероприятий подготавливает анонс мероприятия и отправляет его на модерацию. Модератор просматривает и анализирует анонс. В результате анализа модератор может поступить, согласно следующим сценариям:

Отправить анонс на публикацию на сайт-афишу.

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

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

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

Бизнес-процесс поиска мероприятий изменяется следующим образом:

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

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

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

2.2 Сценарии использования системы

Для описанной выше системы можно выделить три подсистемы:

Подсистема занесения данных о мероприятиях (подсистема добавления анонсов мероприятий). Основная роль данной подсистемы - занесение данных по анонсам. Предназначена для редактора мероприятий.

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

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

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

2.2.1 Сценарии использования для подсистемы занесения данных о мероприятиях

Сценарии использования подсистемы см. на рис. 2.2.

Рисунок 2.2 - Сценарии использования для подсистемы занесения данных о мероприятиях



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

Название прецедента: первичное занесение информации о мероприятии.

Цель: занести информацию по анонсу мероприятия в систему.

Триггер: пользователь нажал кнопку «Добавить анонс».

Основной поток:

Действия актора	Отклик системы
1. Пользователь заносит все необходимые данные о мероприятии и нажимает кнопку «Сохранить» (Е1, Е2, Е3).	Система сохраняет данные, присваивает анонсу уникальный идентификатор и отображает форму для заполнения данных по анонсу с занесенными пользователем данными. Также на форме отображается присвоенный анонсу идентификатор. Прецедент завершается. Производится переход к сценарию «Редактирование информации о мероприятии».

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

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

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

Пользователь не ввел название мероприятия и нажал кнопку «Сохранить». Система не отправляет данные на сервер и требует ввести название мероприятия. Прецедент продолжается.

Название прецедента: редактирование информации о мероприятии.

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

Триггеры:

Пользователь выполнил сценарий «Первичное занесение информации о мероприятии».

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

Основной поток:

Действия актора	Отклик системы
1. Пользователь редактирует данные о мероприятии и нажимает кнопку «Сохранить» (Е1, Е2, Е3).	Система сохраняет данные. Прецедент продолжается.

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

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

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

Пользователь удалил название мероприятия и нажал кнопку «Сохранить». Система не отправляет данные на сервер и требует ввести название мероприятия. Прецедент продолжается.

Название прецедента: удаление информации о мероприятии.

Цель: удалить анонс мероприятия из системы.

Триггер: пользователь нажал кнопку «Удалить».

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

Название прецедента: дублирование информации о мероприятии.

Цель: продублировать анонс мероприятия.

Триггер: пользователь нажал кнопку «Дублировать».

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

Название прецедента: отправка информации о мероприятии на модерацию.

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

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

Основной поток: пользователь нажимает кнопку «Отправить на модерацию». Система помечает мероприятие, как отправленное на модерацию. Прецедент завершается.

2.2.2 Сценарии использования для подсистемы модерации данных о мероприятиях

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



Рисунок 2.3 - Сценарии использования для подсистемы модерации данных о мероприятиях

Название прецедента: публикация анонса на сайте.

Цель: опубликовать анонс на сайте-афише.

Триггер: пользователь нажал кнопку «На сайт».

Основной поток: система помечает анонс как опубликованный.

Название прецедента: редактирование анонса.

Цель: изменить данные по анонсу перед отправкой на сайт-афишу.

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

Основной поток:

Действия актора	Отклик системы
1. Пользователь редактирует данные о мероприятии и нажимает кнопку «Сохранить» (Е1, Е2, Е3).	Система сохраняет данные. Прецедент продолжается.



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

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

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

Пользователь удалил название мероприятия и нажал кнопку «Сохранить». Система не отправляет данные на сервер и требует ввести название мероприятия. Прецедент продолжается.

Название прецедента: отклонение анонса.

Цель: отправить анонс на доработку сотруднику подведомственной организации.

Триггер: пользователь нажал кнопку «Отклонить».

Основной поток: анонс помечается как отклоненный.

Название прецедента: снятие анонса с публикации.

Цель: убрать анонс с сайта-афиши.

Триггер: пользователь нажал кнопку «Снять с публикации».

Основной поток: анонс помечается как ожидающий модерации.

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

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



Рисунок 2.4 - Сценарии использования для подсистемы визуализации культурных мероприятий

Название прецедента: просмотр списка анонсов.

Актор: посетитель сайта.

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

Триггеры:

Посетитель сайта зашел на сайт-афишу.

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

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

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

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

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

Название прецедента: просмотр анонса мероприятия на сайте.

Актор: посетитель сайта.

Цель: ознакомиться с детальной информацией о мероприятии.

Триггер: посетитель сайта перешел по ссылке на анонс из списка анонсов.

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

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

После просмотра информации посетитель покинул сайт.

После просмотра информации посетитель перешел на главную страницу сайта.

Название прецедента: поиск анонсов мероприятий на сайте по критериям.

Акторы: посетитель сайта.

Триггеры: посетитель сайта принял решение воспользоваться поиском анонсов по критериям.

Основной поток:

Действия акторов	Отклик системы
1. Посетитель задает поисковые критерии и нажимает кнопку, запускающую поиск.	2. Система выполняет поиск анонсов по заданным критериям. По завершении поиска система отображает найденный список анонсов (Е1).
3. Текущий прецедент завершается. Начинается прецедент «Просмотр списка анонсов».

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

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

Название прецедента: рекомендация мероприятий пользователю на основе пользовательских данных.

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

Триггер: пользователь зашел на сайт.

Основной поток: на основе данных пользовательского профиля (для зарегистрированных пользователей) система выбирает мероприятия для рекомендации и отображает их в специальном блоке на странице сайта-афиши.

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

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

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

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

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

Рисунок 2.5 - Схема архитектуры системы

В нотации UML архитектура системы выглядит следующим образом (рис. 2.6).

Рисунок 2.6 - Диаграмма компонентов, представляющая архитектуру системы

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

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

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

2.4 Проектирование интерфейса

У реализуемой системы имеется три группы пользователей:

1. Редактор мероприятий.

2. Модератор.

3. Посетитель сайта-афиши.

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

На экране со списком анонсов можно выделить следующие крупные структурные элементы:

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

2. Стрелки для пролистывания списка анонсов «постранично».

3. Кнопки для массовых операций.

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

На экране с данными по конкретному анонсу располагаются поля, в которых отображаются эти данные. Структурные элементы обоих типов экранов продемонстрированы в п. 2.3.1 и 2.3.2. В данных пунктах описаны основные экраны подсистем.

Пользовательский интерфейс для посетителя сайта-афиши разрабатывался с использованием метода целеориентированного проектирования, описанного А. Купером [6]. Исследовались цели, которые посетитель сайта-афиши желает достигнуть с помощью данного сайта, и в соответствии с данными целями проектировался пользовательский интерфейс. Подробнее проектирование интерфейса сайта-афиши описано в п. 2.3.3.

...