Технологии разработки распределенных корпоративных систем обучения от компании РЕЛЭКС.

Алексей Киселев (ЗАО НПП "РЕЛЭКС")

Потребность рынка в системах обучения понятна. Есть несколько основных направлений, в которых проявляется активность:

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

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

Рассмотрим типичные задачи, которые клиент хотел бы решить при помощи подобной системы.

• Компания имеет значительный объем документации, и хотела бы обеспечить возможность on-line доступа к этой информации. При этом документация, хотя обычно и следует определенному стилю оформления, но часто бывает довольно разнородна в смысле форматов представления - это может быть HTML, doc, pdf, quark или любой другой формат представления документов.
• Представление данных клиент хотел бы видеть в структурированном виде.
• Компания имеет представительства в нескольких странах, соответственно, документация может быть представлена на нескольких языках.
• Помимо обеспечения доступа к документам, компания хочет иметь некоторую статистику обращения к документам. Например, знать, какие документы пользуются наибольшей популярностью, что наиболее сложно с плане усвоения, насколько полно потребитель усвоил материал.
• Проверка знаний, полученных в процессе ознакомления - не просто набор контрольных вопросов. Эти вопросы должны быть связаны некоторым образом с материалом, они также должны варьироваться по сложности - иначе получить объективную оценку степени усвоения материала практически невозможно.

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

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

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

Это - самая общая схема системы, решающей вышеперечисленные задачи. Рассмотрим каждую из составных частей более подробно.

Внутреннее представление

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

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

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

Импорт content

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

Основное назначение и область применения нашей реализации подсистемы импорта - быстрая конвертация XML документов, документов в форматах MS Word, RTF, TXT, Power Point, QuarkX Press, PageMaker в набор объектов для создания обучающего content. Примером такой конвертации может быть процесс преобразования тестов в формате MS Word в набор текстовых ресурсов и вопросов системы. Процесс конвертации управляется скриптом на языке VB Script. В простейшем случае может быть получен один текстовый ресурс из документа, в более сложном варианте (наиболее распространенном) скрипт может опираться на информацию о логическом делении документа на секции, подсекции, вопросы и т.д. на основании различных элементов оформления (стиль, шрифт, размер и т.д.)

Архитектура подсистемы импорта

Возможности подсистемы:

• Позволяет конвертировать данные из любого формата в любой, используя в качестве промежуточного XML (внутреннее представление).
• Гибкость для входных форматов определяется расширяемым набором модулей для анализа исходного формата (парсеры).
• Содержит готовый набор парсеров для HTML, XML, MS Word, WordPerfect, PowerPoint, Quark Express, PageMaker (различный набор поддерживаемых свойств).
• Обработка on-line - HTML страниц (как пример, возможно использование для хранения в базе курса валют, ленты новостей, серверов - справочников и т.д.).
• Гибкость выходных форматов поддерживается набором модулей, которые упаковывают данные (packers).
• Стандартный набор packers: XML текстовый файл, import/export файл системы - т.е. content, готовый для импорта в общий репозитарий ресурсов.
• XOB позволяет выполнять сложную логическую конвертацию данных за счет использования скриптового языка управления процессом конвертирования.
• Для облегчения обработки данных подсистема импорта содержит механизм Active Schema, представляющий иерархию скриптов с условиями активации. На основе этого механизма можно разрабатывать сложные системы, повторно использовать код скрипта для конвертации, вести эффективную разработку группой программистов. Механизм представляет собой для пользователя описание конечного автомата с условиями активации для отдельных скриптов. Это позволяет управлять разбором исходного материала в соответствии с его естественной организацией (глава, раздел и т.д.).
• Механизм работы со стилями текстов (анализ и автоматическое соответствие, удобно для приведения набора документов к единому стилю).
• Поддержка Unicode
• Использование как ActiveX компоненты.

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

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

• документы (текстовые ресурсы);
• вопросы, feedbacks (подсказки и сообщения, выдаваемые как реакция системы на ответ пользователя);
• media ресурсы - image, video, audio, applet, activeX component, flash - в общем все, что может быть показано в составе документа;
• ссылки на другие документы представляемого курса, либо ссылки на какие-то web-resources.

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

• Легкость поиска любого ресурса и интерфейс для модификации свойств и содержания.
• Удобство совместной работы над content, предусматривающее механизм блокирования ресурсов для модификации, версионность объектов (от примитивных до высокоуровневых), архивные версии.
• Удаленный доступ для редактирования, off-line режим.
• Прозрачный импорт - экспорт ресурсов из одной системы с другую, например, из одного курса в другой, расположенный на разных серверах разработки (с этим тесно связана проблема publishing готовых продуктов, так как система позволяет работать подобным образом со всеми типами объектов системы)
• Механизм мета атрибутов ресурсов, позволяющий сопоставить с конкретным ресурсом набор свойств, например размер, тип, формат, уровень сложности, предназначение. Использование мета атрибутов позволяет решить множество проблем - например, поиск (найти все изображения в формате gif размером более 100 kB для того, чтобы рассмотреть вопрос об их редактировании), генерация динамических обучающих ресурсов, как дополнительная информация для генерации разнообразных отчетов.

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

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

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

На последнем пункте следует остановиться и рассмотреть его подробнее.

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

Для решения этой задачи вводится некая абстрактная структура, иерархическое представление модели области знаний - content tree. Узлы его позволяют осуществлять привязку к себе различных объектов - входящих в тест вопросов, документов курса, различных вспомогательных ресурсов. Этот механизм позволяет на основании ответов пользователя на вопросы строить динамические обучающие ресурсы, разноуровневые отчеты (для пользователя, для обучающего, для руководства и т.д.)

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

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

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

Еще одно немаловажное достоинство описанной архитектуры - это возможность переиспользования ресурсов - от простых текстовых страниц до тестов. Потребность в этом очевидна - реальный пример: курс математики для четвертого и шестого класса должен включать в себя один и тот же тест - отличие только в том, что в курсе четвертого класса он выступает как серьезный оценочный тест, а в курсе шестого - как материал для повторения. Соответственно, переиспользовать можно и необходимо как базовые ресурсы, так и сам тест - это выражение концепции т.н. Reusable Learning Objects (RLO). Переиспользование ресурсов значительно сокращает их необходимое количество в случае большого количества связанных по смыслу курсов

Аспект переиспользования ресурсов является одной из предпосылок создания таких объектов системы, как шаблоны документов. Шаблоны в нашей системе бывают двух типов - это статические, использование которых позволяет создавать документы стандартизованного вида, значительно облегчая сам процесс создания, и шаблоны времени исполнения (run-time templates). Шаблоны второго типа являются составной частью уровня представления информации, и позволяют представить на странице динамическую информацию, доступную только в процессе сессии работы пользователя с курсом (самый простой пример - это вставка в тело документа имени пользователя, в данный момент работающего с курсом).

Уровень представления данных

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

Для перевода документов из внутреннего представления в HTML применяется соответствующий механизм трансформации с изменяемыми стилями представления. Стиль представления может включать в себя набор XSL-скриптов, run-time templates для различных типов ресурсов. Например, вам необходимо показать все документы внутри таблицы, в первой ячейке которой впечатано имя пользователя, далее - название продукта, далее - порядковый номер страницы внутри теста. При этом для документов-вопросов типа Multiple Choice использовать таблицу одной ширины, а для всех остальных - другой. При этом, естественно, только в рамках этого курса, поскольку в другом правила будут другими.

Эту задачу позволяет решить механизм стилей. Стиль - поименованный набор типизованных XSL, run-time templates, css - всего необходимого для трансформации, доставки и представления пользователю ресурса в конечном его представлении. Свой собственный стиль может иметь курс, конфигурация, тест, конкретный ресурс (внутри или вне теста). Этот набор стилей образует иерархию, и на ее основе система доставки решает, использовать ли default трансформацию для представления этого ресурса или на каком то из уровней было принято решение о перекрытии стиля.

Интерфейс пользователя

Гибкость и мощность внутренних механизмов обработки, тонкость настройки - это все процессы, скрытые от конечного пользователя. Клиент сталкивается с конечной реализацией - но и здесь наша система предлагает уникальные по своей сложности, во многом не имеющие аналогов у конкурентов решения. Активное использование JavaScript и DHTML в клиентском интерфейсе позволяет реализовать высокоуровневый интерфейс наряду с логикой уже на клиентской части Delivery Engine, что позволяет реализовать сложные задачи взаимодействия с клиентом без "утяжеления" приложения использованием Java, либо ActiveX. Это позволяет работать клиентскому приложению во всех операционных системах (Windows, Solaris, Linux, MacOS) с наиболее распространенными типами web-браузеров (IE, NC версий 4.xx и выше) без каких либо видимых различий.

Помимо типичных для подобного класса систем типов вопросов (interactions) Multiple Choice, Multiple Response, Selection, Fill-in-Blanks пользователю могут быть представлены Hot Spots - как основанные на изображениях, так и текстовые (!), Drag'n'Drop, Connect - не имеющие, либо имеющие гораздо более слабую реализацию у конкурирующих продуктов. Недаром независимые аналитики отметили многообразие видов и мощность реализации interactions именно у нашей системы

Немаловажной задачей в процессе усвоения материала является возможность поиска интересующей информации в рамках предложенного материала. Это стандартная функция для подобных систем . Следует сказать, что механизм ее реализации сильно зависит от используемых технологий. Самая гибкая в мире система поиска может быть реализована только с использованием СУБД ЛИНТЕР!

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

CD-delivery

Помимо on-line режима обучения возможен и off-line, реализуемый с помощью подсистемы экспорта готового продукта из нашей системы. В дальнейшем полученный материал можно использовать различными способами - например, включить CD, содержащий набор курсов и тестов в комплект с изданным учебным пособием

LMS

Немаловажной задачей для систем подобного класса является реализация функций Learning Management System (систем, обеспечивающих управление процессом обучения ), либо взаимодействие с системами, их реализующими. Стандарты, описывающие эти задачи и процессы взаимодействия, ранее создавались Aviation Industry CBT (Computer Based Training) Committee (AICC), ныне же эти работы выполняет комитет Advanced Distributed Learning (www.adlnet.org).

Удовлетворение de-facto мировым стандартам позволяет с легкостью взаимодействовать с аналогичными системами, переиспользовать content сторонних разработчиков - одним словом, конкурировать взаимодействуя.

Общие задачи систем подобного уровня

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

• Надежность и отказоустойчивость (работа в режиме 24x7x365, 99.90%), transparent fail-over ( восстановление системы и пользовательских сессий после обрывов соединения, сбоев оборудования )
• Масштабируемость
• Load Balancing - динамическое перераспределение нагрузки меж несколькими серверами
• Clustering - "связанная" работа набора серверов
• Logging & auditing - контроль и информация для анализа
• Легкость администрирования
• Resources pooling & caching - разделение ресурсов
• Security - разграничение доступа, сохранность финансовой информации клиентов

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

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