Разработка веб-приложения для информационного обеспечения учебного процесса (видеокасты) (стр. 2 из 8)

Рисунок 2 – Доступ к каналу МГУ им. Ломоносова через категории YouTube

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

Вторым аналогом можно назвать портал видеолекций Московского физико-технического института (http://fvl.fizteh.ru/). Проект явно реализовывался под какую-то конкретную задачу, поскольку за последние 6 месяцев на него не было загружено ни одной видеолекции. Главным достоинством данного проекта является возможность создания курсов, таким образом обучающийся сможет проходить курс, просматривая видеолекции по порядку. На рисунке 3 представлен курс видеолекций на тему “Электричество и магнетизм”.

Рисунок 3 – Курс видеолекций “Электричество и магнетизм” в МФТИ

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

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

Рисунок 4 – Категоризация и внешний вид видеолекций

Наконец, третьим аналогом можно назвать видеокурсы Интернет Университета Информационных Технологий (http://www.intuit.ru/video/). Отличительной особенностью этого раздела ИУИТ является его видеоплеер. Он содержит в себе навигацию по текущему видеокурсу в виде разделов лекции. В правой части видеоплеера расположено само окно плеера, что можно увидеть на рисунке 5.

Рисунок 5 – Видеоплеер ИУИТ

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

3 Анализ вариантов реализации системы

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

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

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

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

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

4 Построение модели системы и разработка технологии реализации

4.1 Диаграмма развертывания

Рисунок 6 – Диаграмма развертывания

На рисунке 6 представлена диаграмма развертывания. Данная схема является стандартной для большинства сайтов в сети Интернет. Клиентские запросы поступают на 80 порт, который слушает веб-сервер nginx, далее запрос или проксируется на apache, или отрабатывает на nginx. Apache в свою очередь взаимодействует с СУБД и системой кэширования (на диаграмме показан Eaccelerator, но на его месте могут быть Memcached или APC) [15].

4.2 Диаграмма компонентов

Рисунок 7 – Диграмма компонентов

Диаграмма компонентов (рисунок 7) хорошо показывает альтернативу связке Apache-MySQL-PHP в лице пакетов Denwer/LAMP. Модули видеокастов, форум и дисциплины вынесены как увеличивающие функционал системы. В то же время система не зависит от них, и сами эти модули самодостаточны. Модуль авторизации вынесен в отдельную часть, поскольку он не реализует дополнительный функционал системы, а является одной из ее частей.

4.3 Диаграммы вариантов использования

4.3.1 Диаграмма вариантов использования для гостя

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

Рисунок 8 – Диаграмма вариантов использования для гостя

4.3.2 Диаграмма вариантов использования для автора

Условно можно сделать разделение “преподавателя” на автора и тьютора. Автор создает сам материал подкаста, в то время как тьютор занимается типичной для него функцией – обучает. На практике часто получается, что эти две роли объединены в одну - “тьютор”.

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

Рисунок 9 – Диаграмма вариантов использования для автора

4.3.3 Диаграмма вариантов использования для преподавателя

Преподаватель в конкретном случае должен обучать студентов и назначать им аудио- и видеокасты к просмотру (рисунок 10).

Рисунок 10 – Диаграмма вариантов использования для преподавателя

4.3.4 Диаграмма вариантов использования для студента

Диаграмма вариантов использования для студента – самая большая из всех, поскольку именно обучающиеся в университете на настоящий момент являются целевой аудиторией данного проекта. Студенты могут просматривать доступные им видеокасты (рисунок 11), просматривать обсуждения, вопросы студентов и ответы преподавателей на эти вопросы в “Обсуждениях”. Студенты могут как просматривать видеокасты, так и слушать аудиокасты загруженные авторами обучающих материалов.

Рисунок 11 – Диаграмма вариантов использования для студента

4.4 Инфологическая модель базы данных

На рисунке 13 представлена инфологическая модель базы данных системы. Подробное описание проиллюстрированной модели представлено в приложении A. Инфологическая модель ядра системы представлена на рисунке 12.

Рисунок 12 – Инфологическая модель ядра системы

Рисунок 13 – Инфологическая модель системы

4.5 Выбор технологии реализации

После рассмотрения возможных аналогов данного проекта было выявлено, что для отдачи мультимедиа контента (в том числе видео- и аудиоконтента) используются веб-сервера nginx и lighttpd. Серверные скрипты в основном используют возможности php, python и bash. В качестве сервера баз данных используются в большинстве случаев MySQL и PostgreSQL. На рисунке 14 представлена стандартная схема работы большинства динамических сайтов в сети Интернет.

Рисунок 14 – Стандартная схема работы динамических сайтов, использующих БД

Как видно из рисунка, запрос пользователя поступает на фронтовый веб-сервер, который слушает 80 порт (стандартный HTTP-порт). Далее фронтовый веб-сервер в зависимости от запроса или проксирует его далее на бэкенд (более тяжеловесный сервер, умеющий обрабатывать динамические запросы, например Apache), или же отдает контент, запрошенный пользователем. В случае проксирования запроса на бэкенд мы можем взаимодействовать с БД посредством какого-либо языка программирования [14].

4.5.1 Выбор веб-сервера

Данная схема работы сайтов является на данный момент стандартной в сети Интернет. В качестве фронтовых веб-серверов в большинстве случае используются nginx и lighttpd. В качестве бэкенда самым известным веб-сервером является Apache. Также возможен вариант работы нескольких веб-серверов Apache (или вобще – нескольких физических серверов) вместе с балансировщиком нагрузки [12]. Вообще, главная причина использование схемы фронтенд-бэкенд – эффективное использование ресурсов. Если клиентов пускать напрямую к бэкенду (например apache+mod_perl) без фронтенда, то серверов под бэкенды потребуется в несколько раз больше [12].