Дистанционное обучение

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

Аннотация

дистанционный обучение мультиагентный moodle

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



Введение

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

Дистанционное обучение занимает всё большую роль в модернизации образования. Согласно приказу 137 Министерства образования и науки РФ от 06.05.2005 «Об использовании дистанционных образовательных технологий», итоговый контроль при обучении с помощью ДОТ (дистанционных образовательных технологиях) можно проводить как очно, так и дистанционно. Госдума РФ рассматривает проект поправок к закону об образовании, связанных с дистанционным обучением.

На данный момент существуют системы управления обучением, позволяющие проводить дистанционное обучение средствами сети Internet, такие как ATutor, Claroline, Dokeos, LAMS, Moodle, OLAT, OpenACS, Sakai.

Аргументация выбора системы Moodle.

Обзор систем управления обучением.

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

авторские программные продукты (Authoring Packages),

системы управления обучением (Learning Management Systems - LMS),

системы управления контентом (содержимым учебных курсов) (Content Management Systems - CMS),

системы управления учебным контентом (Learning Content Management Systems - LCMS)

Свободно распространяемые LMS\LCMS

На основе анализа существующих OpenSource систем LMS\LCMS были выделены следующие: ATutor, Claroline, Dokeos, LAMS, Moodle, OLAT, OpenACS, Sakai. Основными критериями отбора были выбраны степень поддержки системы и многоязыковое сопровождение.

ATutor (http://www.atutor.ca/) представляет собой свободно распространяемую web-ориентированную систему управления учебным контентом, разработанную с учетом идей доступности и адаптируемости. Администраторы могут обновить или инсталлировать Atutor за несколько минут, разработать собственные шаблоны оформления системы. Преподаватели могут быстро собирать, структурировать содержание учебного материала для проведения занятий on-line. Обучаемые работают с гибкой, адаптивной средой обучения.

Claroline (Classroom Online) (http://www.claroline.net/) - платформа построения сайтов дистанционного обучения, созданная с учетом пожеланий преподавателей. Приложение было создано в институте педагогики и мультимедиа католического университета в Лувене. Продукт бесплатен и доступен. Требует установки PHP/MySQL/Apache. Claroline позволяет создавать уроки, редактировать их содержимое, управлять ими. Приложение включает генератор викторин, форумы, календарь, функцию разграничения доступа к документам, каталог ссылок, систему контроля за успехами обучаемого, модуль авторизации.

Dokeos (http://www.dokeos.com/) - платформа построения сайтов дистанционного обучения, основанная на ветке (fork) Claroline (версии 1.4.2.). Ветка представляет собой клон свободно распространяемого программного продукта, созданный с целью изменить приложение-оригинал в том или ином направлении.

Dokeos - результат работы некоторых членов первоначальной команды разработчиков Claroline, которые задумали:

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

Dokeos бесплатен и останется таковым, поскольку лицензия Claroline (GNU/GPL) предполагает, что ветки подпадают под ту же лицензию.

LAMS (http://www.lamscommunity.org). Спецификация IMS Learning Design была подготовлена в 2003 году. В ее основу положены результаты работы Открытого университета Нидерландов (Open University of the Netherlands - OUNL) по языку образовательного моделирования «Educational Modelling Language» (EML), при помощи которого описывается «метамодель» разработки учебного процесса.

На основе данной спецификации была создана «Система управления последовательностью учебных действий» Learning Activity Management System (LAMS). LAMS предоставляет преподавателям визуальные средства для разработки структуры учебного процесса, позволяющие задавать последовательность видов учебной деятельности.

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

Moodle (http://moodle.org/) - приложение, предназначенное для организации online-уроков и обучающих web-сайтов. Проект был задуман для распространения социо-конструктивистского подхода в обучении.

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

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

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

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

Web-сайт Moodle бесплатно оказывает пользователям платформы качественную поддержку. Этому способствует многочисленное сообщество.

OLAT (http://www.olat.org). Разработка системы началась еще в 1999 году в University of Zurich, Switzerland, где она является основной образовательной платформой электронного обучения.

OpenACS (http://openacs.org)(Open Architecture Community System) это система для разработки масштабируемых, переносимых образовательных ресурсов. Она является основой для многих компаний и университетов, занимающихся использованием технологий электронного обучения.

Sakai (http://sakaiproject.org/) представляет собой онлайн систему организации учебного образовательного пространства. Sakai является системой с полностью открытым исходным кодом, которая поддерживается сообществом разработчиков. В систему интегрирована поддержка стандартов и спецификаций IMS Common Cartridge, SCORM.

Анализ OpenSource LMS\LCMS

Проведенный анализ показал, что систем LMS\LCMS «Moodle» является наиболее подходящей платформой для организации дистанционного обучения.

Обзор существующих подходов к расширению возможностей системы Moodle.

Структура системы Moodle.

Moodle (модульная объектно-ориентированная динамическая учебная среда) -- свободная система управления обучением (LMS), распространяющаяся по лицензии GNU General Public License. Moodle написана на PHP с использованием SQL-базы данных (MySQL, PostgreSQL, Microsoft SQL Server и др. БД -- используется ADO DB XML). Moodle может работать с объектами SCO и отвечает стандарту SCORM.

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

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

Структуру Moodle можно описать подобной схемой:

Подходы к расширению возможностей системы Moodle.

Исходя из структуры можно выделить следующие подходы к расширению возможностей учебной среды Moodle:

Изменение ядра системы.

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

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

Написание модулей для системы.

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

Moodle позволяет подключать следующие типы модулей:

Элементы курса

Отчеты администратора

Типы заданий

Плагины аутентификации

Блоки

Форматы курсов

Отчеты по курсам

Поля базы данных (для элемента курса "База данных")

Плагины подписки на курсы

Фильтры

Отчеты по оценкам

Форматы экспорта оценок

Форматы импорта оценок

Портфолио

Типы вопросов в тестах

Форматы импорта/экспорта тестов

Отчеты по тестам

Хранилища файлов

Типы ресурсов

Плагины поиска

Написание независимого программного обеспечения на той же предметной области.

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

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

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

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

Комбинированный

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

Анализ подходов к расширению возможностей системы Moodle.

Постановка задачи.

Актуальность

LMS Moodle является на данный момент одной из самых динамично развивающихся систем дистанционного обучения. Moodle переведена на десятки языков, в том числе и русский и используется почти в 50 тысячах организаций из более чем 200 стран мира. В Российской Федерации зарегистрировано более 400 инсталляций. Количество пользователей Moodle в некоторых инсталляциях достигает 40 тысяч человек.

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

Цель

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

Решаемые задачи

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

Техническое исследование системы Moodle.

Выбор типа подключаемого модуля расширения системы Moodle, наиболее удовлетворяющего целям дипломного проектирования.

Разработка структуры и реализация модуля.

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

Написание руководства по установке и эксплуатации созданного модуля.

Свойства объекта разработки

Объект разработки должен обладать следующими свойствами:

Модуль должен реализовывать:

Интерфейс, связывающий систему Moodle и мультиагентную систему дистанционного обучения

Пользовательский интерфейс

Модуль не должен влиять на скорость загрузки страницы.

Модуль должен быть гибко настраиваемым.

Модуль должен выполнять все требования совместимости, предъявляемые к модулям в системе.

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

Модуль удовлетворяет требованиям системы к подключаемым модулям соответствующего типа.

Модуль должен быть реализован с использованием скриптового языка PHP.

Проектирование

Техническое исследование системы Moodle.

Введение

Moodle является системой управления курсами (CMS - Course Management System), распространяемой в соответствии с условиями лицензии GNU Public License и в связи с этим обладает рядом особенностей, присущих бесплатному свободно распространяемому программному обеспечению. В их числе - отсутствие завершенной документации. Поэтому данное исследование проводится на основании самих исходных кодов системы Moodle с минимальным привлечением документации с официального сайта системы. В настоящее время система активно развивается, поэтому перед прямым использованием результатов исследования необходимо убедиться в том, что версия пользователя совпадает с версией, которая была исследована.

В данном исследовании рассматривается система Moodle версии 1.9.5 от 30 мая 2009г.

Требования

Аппаратное обеспечение

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

Доступный объем ПЗУ: не менее 160 МБ. Для хранения учебных материалов, используемых в обучении, будет необходим дополнительный объем.

Доступный объем ОЗУ: не менее 256 МБ. Рекомендуется 1ГБ. Можно считать, что система Moodle может обслуживать по 50 пользователей одновременно на каждый 1 ГБ доступной оперативной памяти. Точность этого правила зависит от конкретной комбинации используемого аппаратного и программного обеспечения.

Программное обеспечение

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

Веб-сервер. Большинство предпочитают Apache, но Moodle будет хорошо работать и с любым другим веб-сервером, который поддерживает PHP, например IIS на Windows платформе.

На данный момент существует 2 основные версии (ветки) PHP: PHP4 и PHP5. В зависимости от версии Moodle предъявляет следующие требования:

Для Moodle версии 1.4 или выше: поддерживаются PHP4 (версия 4.1.0 или выше) или PHP5 (версия 5.1.0 или выше).

Для Moodle версии 1.6 или выше: поддерживаются PHP4 (версия 4.3.0 или выше) или PHP5 (версия 5.1.0 или выше).

Настройки PHP

safe_mode должна быть отключена

memory_limit должна иметь значение по-крайней мере 16M (32M рекомендуется для Moodle 1.7 и 40M для Moodle 1.8 или выше).

session.save_handler должно иметь значение files.

Библиотеки и расширения PHP

mbstring обязателен для Moodle 1.6 и выше. Это расширение предназначено для работы с многобайтными строками и особенно важно для русскоязычных инсталяций.

iconv обязателен для Moodle 1.6 и выше.

библиотека GD и FreeType 2 необходимы для создания графиков, диаграмм и для построения страниц логов.

Расширение mysql необходимо, если вы используете MySQL.

Расширение pgsql необходимо, если вы используете PostgreSQL.

Расширение zlib необходимо для работы с архивами zip.

Расширение curl рекомендуется для Moodle 1.8 и выше.

Расширение tokenizer рекомендуется для Moodle 1.8 и выше.

Расширения curl и openssl необходимы для функционирования Moodle network - сетевое взаимодействия нескольких инсталяций Moodle (для Moodle 1.8 и выше).

Могут потребоваться другие расширения PHP, особенно если используется внешняя аутентификация и/или запись на курсы (например, расширение LDAP для аутентификации с использованием LDAP или расширение sockets для Chat-сервера).

Работающий сервер СУБД: MySQL или PostgreSQL полностью поддерживаются и совместимы для использования с Moodle. Поддержка Microsoft SQL Server и Oracle была добавлена в Moodle 1.7.

Для Moodle 1.5 требуется MySQL не ниже 3.23 или PostgreSQL не ниже 7.4.

Для Moodle 1.6 требуется MySQL не ниже 4.1.16 (4.1.12 если вы используете только языки на основе латинского алфавита) или PostgreSQL не ниже 7.4.

Для Moodle 1.7 требуется MySQL не ниже 4.1.16 (4.1.12 если вы используете только языки на основе латинского алфавита), PostgreSQL не ниже 7.4 или Microsoft SQL Server 2005 (версия 9 или SQL Server Express 2005).

Опция MySQL"strict mode" должна быть отключена.

Минимально возможная версия PostgreSQL - 7.4, но Moodle широко используется и с 8.0 и 8.1.

Процесс установки.

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

Процесс установки системы Moodle автоматизирован, поэтому не требует знакомства с внутренним устройством системы. Для запуска процесса установки необходимо обеспечить доступ к дистрибутиву Moodle средствами веб-сервера (в случае веб-сервера Apache это означает поместить дистрибутив в папку htdocs/httpdocs). Процесс установки описан в файле install.php, который находится в корневой папке дистрибутива. Для его правильной активации необходимо обратиться к нему с помощью программы-браузера. При обращении по адресу, соответствующему файлу install.php, отображается страница мастера установки, для нормальной работы которого требуется, чтобы браузер поддерживал и принимал cookies от сайта с системой. В ходе работы мастера необходимо ввести параметры, необходимые Moodle для инициализации основных конфигурационных файлов. Помимо этого, будет произведена диагностика установленного программного комплекса (веб-сервер+интерпретатор PHP и СУБД) на корректную взаимную работу, проверены необходимые параметры интерпретатора PHP. После завершения работы мастера будет создан файл config.php, который будет содержать основные параметры конфигурации системы и будет в дальнейшем задействован в работе. После создания файла config.php при первом посещении сайта установленной системы Moodle будет произведено создание таблиц Moodle в базе данных.

По успешному завершению этого процесса, остается последний шаг в подготовке системы к использованию - настройка регулярного исполнения скрипта cron.php. Этот скрипт выполняет трудоемкие функции, которые необходимо осуществлять относительно редко, поэтому они не вызываются ни в одном из скриптов, формирующих ответы на запросы пользователя по соображениям быстродействия. В связи с этим необходимо, чтобы существовал внешний по отношению к системе Moodle запросчик, который с некоторой периодичностью (разработчики системы рекомендуют интервал 5 минут) вызывал бы скрипт cron.php на исполнение. Реализация этой задачи различается в зависимости от операционной системы и установленного программного обеспечения, поэтому не существует подходящего для всех способа ее реализации. В целом путь решения этой задачи таков: необходимо средствами операционной системы, либо с помощью дополнительного ПО организовать регулярную интерпретацию скрипта cron.php интерпретатором PHP сервера, на котором функционирует система Moodle.

На этом установка Moodle завершена, система готова к использованию.

Схема хранения в базе данных.

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

adodb_logsql

mdl_assignment

mdl_assignment_submissions

mdl_backup_config

mdl_backup_courses

mdl_backup_files

mdl_backup_ids

mdl_backup_log

mdl_block

mdl_block_instance

mdl_block_pinned

mdl_block_rss_client

mdl_block_search_documents

mdl_cache_filters

mdl_cache_flags

mdl_cache_text

mdl_capabilities

mdl_chat

mdl_chat_messages

mdl_chat_users

mdl_choice

mdl_choice_answers

mdl_choice_options

mdl_config

mdl_config_plugins

mdl_context

mdl_context_temp

mdl_course

mdl_course_allowed_modules

mdl_course_categories

mdl_course_display

mdl_course_meta

mdl_course_modules

mdl_course_request

mdl_course_sections

mdl_data

mdl_data_comments

mdl_data_content

mdl_data_fields

mdl_data_ratings

mdl_data_records

mdl_enrol_authorize

mdl_enrol_authorize_refunds

mdl_enrol_paypal

mdl_event

mdl_events_handlers

mdl_events_queue

mdl_events_queue_handlers

mdl_forum

mdl_forum_discussions

mdl_forum_posts

mdl_forum_queue

mdl_forum_ratings

mdl_forum_read

mdl_forum_subscriptions

mdl_forum_track_prefs

mdl_glossary

mdl_glossary_alias

mdl_glossary_categories

mdl_glossary_comments

mdl_glossary_entries

mdl_glossary_entries_categories

mdl_glossary_formats

mdl_glossary_ratings

mdl_grade_categories

mdl_grade_categories_history

mdl_grade_grades

mdl_grade_grades_history

mdl_grade_import_newitem

mdl_grade_import_values

mdl_grade_items

mdl_grade_items_history

mdl_grade_letters

mdl_grade_outcomes

mdl_grade_outcomes_courses

mdl_grade_outcomes_history

mdl_grade_settings

mdl_groupings

mdl_groupings_groups

mdl_groups

mdl_groups_members

mdl_hotpot

mdl_hotpot_attempts

mdl_hotpot_details

mdl_hotpot_questions

mdl_hotpot_responses

mdl_hotpot_strings

mdl_journal

mdl_journal_entries

mdl_label

mdl_lams

mdl_lesson

mdl_lesson_answers

mdl_lesson_attempts

mdl_lesson_branch

mdl_lesson_default

mdl_lesson_grades

mdl_lesson_high_scores

mdl_lesson_pages

mdl_lesson_timer

mdl_log

mdl_log_display

mdl_message

mdl_message_contacts

mdl_message_read

mdl_mnet_application

mdl_mnet_enrol_assignments

mdl_mnet_enrol_course

mdl_mnet_host

mdl_mnet_host2service

mdl_mnet_log

mdl_mnet_rpc

mdl_mnet_service

mdl_mnet_service2rpc

mdl_mnet_session

mdl_mnet_sso_access_control

mdl_modules

mdl_newnameforthetable

mdl_post

mdl_question

mdl_question_answers

mdl_question_attempts

mdl_question_calculated

mdl_question_categories

mdl_question_dataset_definitions

mdl_question_dataset_items

mdl_question_datasets

mdl_question_match

mdl_question_match_sub

mdl_question_multianswer

mdl_question_multichoice

mdl_question_numerical

mdl_question_numerical_units

mdl_question_randomsamatch

mdl_question_sessions

mdl_question_shortanswer

mdl_question_states

mdl_question_truefalse

mdl_quiz

mdl_quiz_attempts

mdl_quiz_feedback

mdl_quiz_grades

mdl_quiz_question_instances

mdl_quiz_question_versions

mdl_resource

mdl_role

mdl_role_allow_assign

mdl_role_allow_override

mdl_role_assignments

mdl_role_capabilities

mdl_role_names

mdl_role_sortorder

mdl_scale

mdl_scale_history

mdl_scorm

mdl_scorm_scoes

mdl_scorm_scoes_data

mdl_scorm_scoes_track

mdl_scorm_seq_mapinfo

mdl_scorm_seq_objective

mdl_scorm_seq_rolluprule

mdl_scorm_seq_rolluprulecond

mdl_scorm_seq_rulecond

mdl_scorm_seq_ruleconds

mdl_sessions2

mdl_stats_daily

mdl_stats_monthly

mdl_stats_user_daily

mdl_stats_user_monthly

mdl_stats_user_weekly

mdl_stats_weekly

mdl_survey

mdl_survey_analysis

mdl_survey_answers

mdl_survey_questions

mdl_tag

mdl_tag_correlation

mdl_tag_instance

mdl_timezone

mdl_user

mdl_user_info_category

mdl_user_info_data

mdl_user_info_field

mdl_user_lastaccess

mdl_user_preferences

mdl_user_private_key

mdl_webdav_locks

mdl_wiki

mdl_wiki_entries

mdl_wiki_locks

mdl_wiki_pages

mdl_workshop

mdl_workshop_assessments

mdl_workshop_comments

mdl_workshop_elements

mdl_workshop_grades

mdl_workshop_rubrics

mdl_workshop_stockcomments

mdl_workshop_submissions

Краткое описание назначения некоторых из этих таблиц приведено ниже.

Типы подключаемых модулей расширения в Moodle.

Activity modules - большие модули, вовлекающие студентов и преподавателей во взаимодействие (обычно формируют множество страниц, содержат сложную систему управления). Например: wiki (движок Wikipedia в Moodle), forum (форумы в Moodle).

Admin reports - дополнительные отчеты, доступные администратору сайта.

Assignment types - дополнительные типы заданий.

Authentication plugins - дополнительные способы аутентификации пользователей.

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

Course formats - дополнительные способы организации курса (например разделяемый по неделям, разделяемый по темам).

Course reports - дополнительные отчеты по курсу.

Database fields - поддержка дополнительных структур данных, при работе с БД.

Database presets

Enrolment plugins - дополнительные средства оплаты обучения.

Filters - дополнительные средства преобразования текста, введенного пользователем.

Gradebook plugins

Gradebook report - отчет по успеваемости студентов в рамках курса.

Gradebook export - дополнительные средства выгрузки данных об успеваемости студентов.

Gradebook import - дополнительные средства загрузки данных об успеваемости студентов.

Question engine - дополнительные типы вопросов для использования в системе (например тестовые, числовые, с текстовым ответом)

Question import/export formats - дополнительные средства загрузки/выгрузки вопросов в систему.

Quiz reports - дополнительные отчеты по результатам выполнения студентами тестов.

Resource types - дополнительные типы ресурсов.

SSO plugins

Search engine adapters - дополнительные адаптеры для преобразования внутренних данных других модулей к формату встроенного в систему Moodle механизма поиска для предоставления возможности пользователям производить поиск по данных этих модулей.

Программный интерфейс модуля типа “block”

Для создания модуля типа “block” в системе Moodle необходимо описать класс, определяющий функциональность этого модуля. Этот класс должен являться наследником класса block_base, в котором определена базовая функциональность блоков, а также реализована интеграция в систему. При этом необходимо переопределить в этом классе следующие методы:

init() - функция, задачей которой является установка значений полей title и version. Первое используется как заголовок модуля и будет отображаться как имя модуля в системе Moodle, а второе, являясь обязательным, используется только для блоков, которые работают с базой данных для того, чтобы дать возможность разработчику изменять структуру хранимых данных от версии к версии с сохранением работоспособности модуля. Принято присваивать полю version значение в формате ГГГГММДД00, то есть для версии выпущенной 30го мая 2009 года необходимо использовать значение 2009053000.

get_content() - функция, которая вызывается каждый раз при открытии страницы курса, на которой задействован блок. Возвращаемым значением должен быть экземпляр класса stdClass с определенными полями text и footer. Значение поля text - будет выведено в основной части блока (значение этого поля может быть текстом с html разметкой), а значение поля footer - меньшим шрифтом под основным содержимым (html также разрешен). Возвращаемое значение (содержимое блока, отображаемое на странице курса) должно быть сохранено в поле content описываемого класса.

Таким образом, простейший модуль типа “block” описывается следующим кодом:

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

Описанный выше простейший блок является полноправным модулем системы Moodle - в случае, если его поместить в папку blocks в корневом каталоге дистрибутива системы и после этого обратиться к странице администратора (http://moodlesite/admin), блок будет установлен, и пользователи, у которых есть соответствующие права, смогут добавлять этот блок к странице курса.

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

Поля, разрешенные для присваивания.

title - заголовок (имя) модуля в системе; разрешено прямое присваивание в методе init().

content_type - тип блока. Может принимать одно из двух значений BLOCK_TYPE_TEXT (обычный блок) и BLOCK_TYPE_LIST (блок, отображающий список). Типы различаются организацией поля content и методом вывода блока на страницу. Разрешено прямое присваивание в методе init().

content - содержание блока для отображения при вызове со страницы курса. Должно присваиваться и обновляться в методе get_content().

edit_controls - разрешенные действия с блоком (создается методом _add_edit_controls())

version - версия модуля. Должна быть определена в методе init().

cron - время в секундах между запусками метода cron(), описанного далее. Если присвоено значение 0, запусков не будет вовсе.

pinned - не может быть передвинут, всегда отображается

Методы, доступные для переопределения.

after_install()

before_delete()

after_restore($restore)

get_title()

get_content_type()

has_config()

config_print()

config_save($data)

applicable_formats()

preferred_width()

hide_header()

html_attributes()

specialization()

instance_allow_config()

instance_allow_multiple()

instance_config_print()

instance_config_save($data,$pinned=false)

instance_create()

instance_delete()

user_can_edit()

user_can_addto(&$page)

Проектирование модуля интеграции.

Правила построения модуля.

Были сформулированы правила для проектирования модулей для связи с мультиагентной средой, согласно которой модуль должен удовлетворять следующим условиям:

Модуль должен быть Объектно-Ориентированным.

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

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

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

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

Входные и выходные данные

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

Ответ от мультиагентной системы приходит в формате описанном по стандартам SOAP, и десереализуется в PHP-переменные.

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

Процесс ввода настроек должен отвечать следующим требованиям:

не занимать много времени

пользователь должен быть ознакомлен с JSON форматом представления данных

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

связь между преподавателем и сервером системы Moodle возможна только с помощью общественных каналов сети Интернет

доступ к серверу из сети Интернет разрешен только для взаимодействия с программой веб-сервера по протоколу http

серверу доступен сервер баз данных под управлением СУБД, совместимой с системой Moodle, а также интерпретатор скриптового языка PHP, интегрированный с веб-сервером.

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

Общие настройки

Заголовок блока

Локальный путь, где расположен клиент дл обмена данных с МАС

Настройки клиента

Полный путь до WSDL, содержащего описание сервисов MAS

Адрес Proxy-сервера

Логин (proxy)

Порт (proxy)

Пароль (proxy)

Connect timeout

Responce timeout

Сервис по умолчанию

Данные для сервиса по умолчанию

Шаблон для вывода по умолчанию

Тип авторизации

Логин (авторизация)

Пароль (авторизация)

Запросы к МАС, которые не требуют ответа, но их необходимо посылать при каждом обновлении страницы

Ввод этих настроек осуществляется со страницы настройки блока:



Выходными данными модуля являются:

Пользовательский интерфейс модуля

Интерфейс ввода настроек модуля

Методы решения задачи

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

На основании этого наиболее подходящим для выполнения поставленной задачи представляется тип модуля “block”, так как он предоставляет готовые механизмы инициализации БД при установке и хранения параметров, достаточно просто интегрируется в систему, а также посредством стандартизированного механизма предоставляет возможность выводить данные на странице курса.

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

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

Алгоритм решения задачи



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

Схема данных работы модуля

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

Все необходимые для работы системы данные хранятся в базе данных под управлением СУБД (с которой у интерпретатора PHP налажена связь через внутреннюю сеть) или в оперативной памяти, как параметры, переданные в http запросе.

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

На основании адреса запрошенной страницы запускается на исполнение нужный скрипт. Запущенный на исполнение скрипт PHP запрашивает у СУБД нужные данные, СУБД производит выборку из БД и возвращает данные интерпретатору PHP.

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

Структура модуля интеграции

Модуль построен на базе стандартного модуля LMS Moodle типа «Блок».

Модуль можно разделить на несколько частей:

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

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

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

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

Схема работы модуля интеграции

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

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

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

Описание интерфейсов общения с мультиагентной системой

Интерфейсы общения с мультиагентной системой построены на безе библиотеки nuSOAP и включают в себя реализацию языка описания веб-сервисов WSDL и протокола SOAP.

WSDL

Для описания интерфейса программной компоненты, включая спецификацию корректных сообщений, был разработан язык WSDL (Web Service Definition Language). Описание на языке WSDL включает в себя следующие семь составляющих:



Рис. 2.6.1. Составные части WSDL документа.

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

Описание входящих и исходящих сообщений, которые связываются с описанными типами данных.

Описание операций (сервисов программной компоненты), с каждой из которых связывается входящее и исходящее сообщение.

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

Описание привязок ( binding ), связывающие типы портов и их сообщений с определенным типом кодирования тела пакета, а также с версией протокола SOAP.

Описание портов, связывающие типы портов и соответствующие им привязки с конкретными URL.

Общее описание службы (интерфейса программной компоненты) как совокупности портов.

Упрощенная структура WSDL-документа:

<wsdl:definitions>

<wsdl:types>...</wsdl:types>

<wsdl:message>...<wsdl:message/>

<wsdl:portType>...</wsdl:portType>

<wsdl:binding>...</wsdl:binding>

<wsdl:service>...<wsdl:service>

<wsdl:definitions>

С помощью нескольких элементов обозначаются главные разделы WSDL-документа.

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

SOAP

SOAP - протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался, в основном, для реализации удалённого вызова процедур, а название было аббревиатурой: Simple Object Access Protocol - простой протокол доступа к объектам. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируется технологии веб-сервисов.

Сообщение SOAP выглядит так:

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

</env:Header>

<env:Body>

</env:Body>

</env:Envelope>

Заголовок SOAP является расширением, предоставляющим способ передачи в SOAP-сообщениях информации, вообще говоря не являющейся полезной для приложения. Подобная "контрольная" информация включает, например, директивы прохождения сообщения или контекстную информацию, относящуюся к обработке сообщения. Это позволяет подстраивать SOAP-сообщения под каждое конкретное приложение. Следующие непосредственно за env:Header дочерние элементы называются заголовочными блоками. Они представляют логическую группировку данных, которые, как показано позже, могут быть индивидуально адресованы SOAP-узлам, встречаемым сообщением на пути от отправителя к конечному получателю.

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

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

Для вызова SOAP RPC требуется следующая информация:

Адрес SOAP-узла места назначения;

Имя процедуры либо метода;

Наименования и значения всех аргументов, передаваемых процедуре или методу вместе с выходными параметрами и возвращаемым значением;

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

Определение шаблона обмена сообщениями, а также так называемого "Web-метода", которые будут использоваться для передачи RPC.

Данные, которые могут быть переданы как часть заголовочных блоков SOAP. Эти данные не являются обязательными.

SOAP также предлагает проектировщику приложений общую функцию, называемую Web-методом SOAP, которая позволяет приложениям полностью контролировать выбор так называемого "Web-метода" - одного из GET, POST, PUT, DELETE, чья семантика определена в спецификациях HTTP Web-метод может использоваться поверх привязки. Эта функция гарантирует, что SOAP-приложения могут взаимодействовать поверх привязки образом, совместимым с архитектурными принципами World Wide Web. (Говоря кратко, простота и масштабируемость Web существует в значительной степени благодаря существованию множества "общеупотребительных" методов (GET, POST, PUT, DELETE), которые могут быть использованы для взаимодействия с любым ресурсом Web посредством URI.) Функция SOAP Web-метод поддерживается HTTP-привязкой SOAP, хотя, в принципе, она доступна и для всех других привязок SOAP к нижележащим протоколам.

Преимущества SOAP:

Обеспечивает взаимодействие программных систем независимо от платформы.

Использование интернет-протокола HTTP обеспечивает взаимодействие программных систем через межсетевой экран.

Недостатки SOAP:

Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки.

Хотя SOAP является стандартом, различные программы часто генерируют сообщения в несовместимом формате. Например, запрос сгенерированный AXIS-клиентом, не будет понят сервером WebLogic.

Схема сетевого взаимодействия системы Moodle и мультиагентной системы.

Moodle и мультиагентная система «общаются» по принципам взаимодействия веб-сервисов:

Клиентское приложение инициализирует SOAPClient

SOAPClient читает файлы описания методов веб-сервиса (WSDL).

SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет на сервер. Возможно использование любого транспортного протокола, но, как правило, используется HTTP.

Пакет принимает серверное приложение, создает объект SOAPServer и передает ему пакет запроса

SOAPServer читает описание веб-сервиса, загружает описание и пакет запроса в XML DOM деревья

SOAPServer вызывает метод объекта/приложения, реализующего сервис

Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту

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

Расчет надежности программного комплекса

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

Основное свойство, описываемое количественными характеристиками - работоспособность. Утрата работоспособности - отказ.

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

Основные характеристики надежности для невосстанавливаемых изделий:

вероятность безотказной работы за время t: P(t);

вероятность отказа за время t: Q(t)= 1 - P(t);

интенсивность отказов (t) - указывает среднее число отказов, возникающее за единицу времени эксплуатации изделия;

среднее время наработки изделия до отказа T0.

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

В расчетах времени до отказа t считается случайной величиной, поэтому используется аппарат теории вероятностей.

Свойства (аксиомы):

P(0)=1 (рассматривается эксплуатация работоспособных изделий);

Lim t ? P(t)=0 (работоспособность не может быть сохранена неограниченное время);

(для невосстанавливаемых) dP(t)/dt?0 (после отказа изделие не восстанавливается).

Выбор показателя надежности:

Если невосстанавливаемое изделие работает однократно в течение небольшого заданного отрезка времени tзад. <<T, то в качестве показателя подходит P(t) или Q(t)

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

Методика расчета надежности невосстанавливаемых изделий

Условия расчета:

расчет производится для этапа нормальной эксплуатации изделия, поэтому считают (t)-const;

создают надежностную схему изделия, причем считают, что отказ элемента (группы элементов), включенных в надежностную схему, приводит к отказу всего изделия;

каждый элемент, включаемый в надежностную схему, характеризуется интенсивностью отказов i и вероятностью безотказной работы Pi(t); считают, что отказы отдельных элементов независимы между собой (хотя бы в первом приближении), поэтому вероятность безотказной работы изделия Pизд(t) (по теории вероятностей):

Pизд.(t)=P1(t) * P2(t) * …* Pn(t) =

а интенсивность отказов изделия изд

изд=1 + 2 + …+ n =

(складываются показатели степени в выражении P=exp(-t) ),

тогда для среднего времени наработки на отказ Tизд = 1/изд

Надежностная схема:

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



Методика расчета надежности восстанавливаемых изделий и систем

Процесс эксплуатации восстанавливаемых систем и изделий отличается от такого же процесса для невосстанавливаемых тем, что наряду с потоком отказов элементов изделия присутствуют стадии ремонта отказавших элементов, т.е. присутствует поток восстановления элементов. Для восстанавливаемых систем не выполняется третье свойство характеристик надежности: dP(t)/dt<0. За период времени t могут отказать два элемента системы, а быть восстановленными - три аналогичных элемента, а значит производная dP(t)/dt>0.

Характеристики надежности восстанавливаемых систем должны описывать как поток отказов элементов, так и поток восстановлений. Для описания потока отказов используются, по-прежнему, интенсивность отказов и среднее время наработки на отказ T, а для описания потока восстановлений - интенсивность восстановлений и среднее время восстановлений ТВ.

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

КГ=Т/(Т+ТВ), ТВ=1/

Условиями приближенного расчета надежности восстанавливаемых изделий и систем являются следующие положения:

время восстановления намного меньше времени наработки элемента на отказ;

интенсивность отказов и восстановлений - постоянные величины;

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

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

; ; .

Связь характеристик можно выразить следующим образом:

, поскольку >>.

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

Резервирование приводит к появлению групп параллельно включенных элементов в надежностной схеме. Для определения характеристик параллельного включения элементов , КГ и в подсистеме при горячем резервировании используются выражения:

...