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

Наконец, третьим аналогом можно назвать видеокурсы Интернет Университета Информационных Технологий (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].

В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select (Windows), epoll (Linux), kqueue (FreeBSD) и eventport (Solaris). Рабочие процессы выполняют цикл обработки событий от дескрипторов. Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие как writev и sendfile, то nginx применяет их по возможности [10].

Для эффективного управления памятью nginx использует пулы. Пул — это последовательность предварительно выделенных блоков динамической памяти. Длина блока варируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путем продвижения указателя на незанятую область с учетом выравнивания. Если незанятой области во всех блоках нехватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL, либо длину блока, то он полностью выделяется из кучи. Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание [15].

4.5.2 Выбор СУБД

Самыми известными СУБД при работе с сайтами являются MySQL, PostgreSQL. Также используются MSSQL, Oracle, Firebird и некоторые другие. Большая популярность MySQL и PostgreSQL по сравнению с проприетарными СУБД обусловлена большим сообществом разработчиков, открытостью продуктов и огромными возможностями по настройке быстродействия баз данных.

Если сравнивать конкретно MySQL и PostgreSQL, то можно выявить следующие преимущества MySQL:

• соответствие стандартам SQL – начиная с пятой версии MySQL большое внимание разработчиками удалялось соответствию стандартам SQL. В MySQL запросы максимально соответствют стандартам SQL'99;

• большее количество платформ – MySQL изначально разрабатывался как кроссплатформенная СУБД. В Windows MySQL работает как служба, в *nix – как демон. PostgreSQL изначально разрабатывался как СУБД, работающая в *nix-системах;

• скорость работы на простых запросах – огромное преимущество MySQL заключается именно в скорости работы простых запросов. Благодаря тому, что в MySQL используются различные типы таблицам, а типом таблиц по умолчанию является MyISAM, реализуется огромная скорость при работе с простыми запросами. В то же время, тип тпблиц InnoDB позволяет осуществлять транзакции, следить за целостностью данных, но в данной случае уже не будет выигрыша в скорости запросов;

• стабильность работы – исторически сложилось, что MySQL довольно стабильная СУБД. PostgreSQL – более молодая, в то время как из-за более раннего начала разработки у MySQL сложилось большее сообщество разработчиков;

• безопасность, связанная со стабильностью – сообщество разработчиков MySQL за все эти годы нашли и устранили огромное количество уязвимостей, что позволяет считать MySQL одной из самых защищенных СУБД;

• работа с большими объектами – в MySQL реализована поддержка бинарных объектов практически неограниченных размеров в полях типа BLOB, что отсутствует у PostgreSQL;

• возможности для легкого изменения таблиц – в MySQL реализованы возможности легкого изменения таблиц, что отсутствует в PostgreSQL.

В то же время у PostgreSQL есть свои преимущества:

• стабильность – несмотря на то, что сообщество разработчиков MySQL больше, сама PostgreSQL изначально проектировалась как более стабильная СУБД. Плюс в этом свою роль сыграло то, что MySQL долго избавлялся от наследия своих третьей и четвертой сравнительно нестабильных версий;

• скорость работы (процедуры) – PostgreSQL выигрывает в производительности на сложных запросах, логически построенных процедурах;

• целостность данных – PostgreSQL позволяет оперировать с данными, не перекладывая логику на ЯП. При разработке кода программисту не придется думать о целостности данных в БД;

• специальные вещи (триггеры, процедуры, функции...) - многие вещи, которые реализуются в MySQL только в последних релизах.

Как можно увидеть, главным преимуществом MySQL являются скорость работы на простых запросах (логика БД довольно простая и не требует процедур для реализации). Это преимуществом было выбрано в качестве основного при выборе СУБД.

В то же время было необходимо выбрать тип таблиц MySQL. Исторически сложилось, что типом таблиц по умолчанию в MySQL является MyISAM. Вторым по популярности типом таблиц является InnoDB. В настоящее время разрабатывается альтернатива InnoDB – Falcon, однако использование его на production-серверах не рекомендуется. В то же время существуют и другие типы таблиц, например:

• HEAP (все хранится в памяти)

• MERGE (совокупность таблиц MyISAM)

• Maria (обновленный MyISAM с возможностями транзакций)

При анализе преимущества и недостатков стандартного типа таблиц MySQL были выявлены следующие его преимущества:

• полнотекстовый поиск

• преимущество в скорости на простых выборках

• работа “из коробки”

Анализ преимуществ InnoDB выявил следующие пункты:

• поддержка транзакций

• целостность/внешние ключи

• преимущество в скорости на сложных выборках

• более полное соответствие стандартам

Как можно увидеть, InnoDB позволяет переложить логику на СУБД, в то время как стандартный тип таблиц позволяет использовать преимущество простых выборок (а их будет гораздо больше чем сложных). Также в MyISAM реализована возможность полнотекстового поиска (хотя она довольно требовательна к наличию индексов). И что немаловажно – возможность работы с типом “из коробки” [13]. Трудно сказать, преимущество это или недостаток, однако при развертывании каких-либо систем преимущество отдается проверенным продуктам. Настройка движка InnoDB до сих пор является довольно объемной темой, проработка которой не относится к написанию дипломной работы. Поэтому было отдано предпочтение типу таблиц MyISAM [11].

4.5.3 Выбор серверного ЯП и клиентского фреймворка

Связующим звеном между СУБД и веб-сервером является язык программирования. В настоящее время самыми популярными и ипользуемыми серверными ЯП при разработке веб-приложений являются python, php, jsp и ruby. Стандартом ЯП для создания клиентских веб-приложений в сети Интернет является javascript. Вопросом для разработчика в настоящее время становится лишь “какой фреймворк для работы с javascript стоит выбрать”. Самыми известными фреймворками являются jquery, prototype, dojo, extjs.

В качестве серверного ЯП был выбран php, который на данный момент является самым попялурным серверным ЯП в России для создания веб-приложений. PHP обладает рядом преимуществ, приведенных ниже [9].

Главными факторами PHP являются предоставление средств для быстрого и эффективного решения поставленных задач и практичность, обусловленная шестью важными характеристиками:

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

• простотой – сценарий РНР может состоять из большого числа строк или из одной строки — все зависит от специфики поставленной задачи. Программисту не приходится подгружать библиотеки или указывать специальные параметры компиляции. Механизм РНР просто начинает выполнять код после первой экранирующей последовательности (). Если код имеет правильный синтаксис, он исполняется в точности так, как указал программист. PHP – язык, который может быть встроен непосредственно в HTML-код страниц, которые, в свою очередь будут корректно обрабатываться PHP-интерпретатором. Большое разнообразие функций PHP избавят вас от написания многострочных пользовательских функций. В то же время существует больше количество фреймворков и CMS, написанных как разработчиками-одиночками, так и большими сообществами программистов;

• эффективностью – важное преимущество PHP заключается в том, что он не нуждается в компиляторе, и позволяет обрабатывать сценарии непосредственно на сервере. По некоторым оценкам, большинство PHP-сценариев (особенно не очень больших размеров) обрабатываются быстрее аналогичных им программ, написанных на других ЯП. Однако, чтобы не делали разработчики PHP, откомпилированные исполняемые файлы будут работать значительно быстрее – в десятки, а иногда и в сотни раз, поскольку откомпилированные программы по сути являются уже инструкциями в машинном коде, в то время как интерпретатор PHP лишь построчно исполняет инструкции, описанные программистом. В то же время, производительность PHP вполне достаточна для создания вполне объемных и многофункциональных веб-приложений;

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

• гибкостью – поскольку РНР является встраиваемым языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя РНР обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, XML и другие языки. Нет проблем и с зависимостью от браузеров, поскольку PHP является серверным ЯП и никак не связан с браузерами. В сущности, сценарии РНР могут передаваться любым устройствам с браузерами, включая сотовые телефоны, электронные записные книжки, пейджеры и портативные компьютеры, не говоря уже о традиционных ПК. РНР в целом является платформенно-независимым языком, поскольку он не содержит кода, ориентированного на конкретный веб-сервер. Благодаря этим возможностям РНР занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов;

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

В качестве клиентского фреймворка был выбран jquery из-за его большей распространенности и лучшей документации [16]. Также, были просмотрены результаты тестов сравнения данных фреймворков по скорости в браузерах Safari/Webkit (рисунок 15), Firefox/Gecko (рисунок 16) и Explorer8/Trident (рисунок 17):