Предыдущая страница реферата | 1  2  3 | Следующая страница реферата

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

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

Вышеупомянутые соображения заставили нас пересмотреть простую архитектуру на основе модели студента. Мы сделали это за несколько шагов, немедленно применяя и проверяя новые решения в наших ITEM/PG и ITEM/IP-II средах. Следующий раздел представляет улучшенную архитектуру, основанную на модели студента для ИОС, где каждый из компонентов (модулей) может использовать и/или модифицировать модель студента без потери информации.

Улучшенная архитектура, основанная на модели студента

Архитектура, основанная на модели студента, делит модель студента на две части – основную модель студента и проекции (рисунок 1). Основная модель студента (далее просто модель студента) находится в центре среды и собирает информацию о данном студенте из различных источников. О взаимодействии студента с любым из компонентов системы сообщают модели студента. Примеры: "в момент времени T1 студент посещает гиперузел понятия C1 в течение S1 секунд", "в момент времени T2 студенту показали пример решения задачи, который касается понятий C1, ..., Cn", "работая с редактором в момент времени T3, студент успешно использовал понятия C1, ..., См". Эти сообщения помечаются временем и хранятся в форме стандартных событий, непосредственно связанных с узлами модели проблемной области. Никакая дальнейшая обработка не выполняется, чтобы избежать потери важной информации. Основная модель студента объединяет всю информацию о студенте, которая может использоваться для адаптации.

Рисунок 1: Улучшенная архитектура, основанная на модели студента

Примечание: Это не тот рисунок, что показан в статье 1994 (к которому я не имею источника), а подобный рисунок из статьи AIED' 95

Компоненты ИОС не используют непосредственно модель студента, а вместо этого используют локальные виды студента, которые мы называем проекциями. Проекция представляет ту информацию о студенте, которая является существенной для компонента, чтобы приспособить его работу к студенту. Компонент имеет настолько полную проекцию, насколько требуется для адаптации. Проекция создается и обновляется из основной модели студента специальным набором правил названных проектором. Каждый компонент имеет свою собственную проекцию и проектор, что обеспечивает интерфейс между компонентом и основной моделью студента. Одна часть правил проектора используется, чтобы проецировать основную модель студента в локальную проекцию. Эти правила обращаются к модели студента в их левых сторонах и содержат команды для модификации проекций в их правых сторонах. Пример: "если студент читает описание структуры Ci, и студент просматривает работу структуры Ci с первым уровнем визуализации более 15 раз, тогда установить второй уровень визуализации для структуры Ci". Другая часть правил проектора используется, чтобы обеспечить обратное проецирование: проецировать результаты работы студента с компонентом в форму стандартных событий, используемых основной моделью студента. Например: "если в момент времени T1 студент посещает гиперузел для понятия Ci на более чем 30 секунд, тогда, если в момент времени T1, студент читает описание понятия Ci". Больше примеров использования проекций в реальной ИОС может быть найдено в (Brusilovsky P., Zyryanov M., 1993).

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

Мы считаем, что предложенная архитектура на основе модели студента является хорошим базисом для создания интегрированной обучающей среды или любой другой интегрированной адаптивной системы, которая состоит из набора различных компонентов. Использование проекций и правил обеспечивает открытую архитектуру с хорошей степенью гибкости. Так как работа компонента зависит от проекции, мы можем настроить работу для конкретного использования, изменяя правила проектора (или даже проекцию непосредственно), без влияния на другие компоненты. Новый компонент может быть легко интегрирован в среду, создав набор правил, которые соединяют центральную модель с данным компонентом и его локальным видом студента. Если новый компонент требует новых форм взаимодействия, которые не могут проецироваться в существующий набор стандартных событий, этот набор может быть расширен. Например, событие "в момент времени T1 студент слушал объяснение понятия Ci из мультимедийной записи" может быть спроецировано в событие "в момент времени T1, студент читает описание понятие Ci" или может быть зарегистрировано как новый вид события. Если конкретный модуль должен принять во внимание новый вид событий для лучшей адаптации, его проектор может быть дополнен. Таким образом, открытая архитектура локализирует и максимизирует изменения в развивающейся системе.

Мы должны обратить внимание, что подобные архитектуры были предложены другими авторами для моделирования пользователя в различных областях (Kay J., 1990; Sukaviriya P., Foley D., 1993; Kobsa A.; Müller D.; Nill A., 1994). Это дает нам явную уверенность, что наша улучшенная архитектура является достаточно общей, чтобы использоваться во множестве областей.

Обсуждение

Важная проблема, которая должна быть обсуждена в контексте предложенной архитектуры, основанной на модели студента – уместность адаптации. Система может использовать очень сложные стратегии, чтобы обеспечить студента "оптимальным" следующим обучающим воздействием, уровнем визуализации или подробностью справки. Проблема состоит в том, соглашается ли студент с выбором. Студент мог предпочесть другое воздействие, более (менее) насыщенную визуализацию, или более (менее) подробную справку. Чтобы справиться с этой проблемой, мы думаем, что адаптация не должна быть навязчива, и студент должен хотя бы быть обеспечен выбором: принять обеспечиваемую системой автоматизированную адаптацию или выключить адаптацию. Наш опыт с заданием последовательности задач (Brusilovsky P.L., 1992a) показывает, что новички имеют тенденцию соглашаться с выбором системы, в то время как опытные студенты часто предпочитают делать свой выбор из полного списка уместных обучающих воздействий. В ITEM/IP студент имеет выбор между адаптивной и подробной визуализацией, между адаптированной и полной справкой в реальном времени.

Следующий шаг – обеспечить студента возможностью "приспособить адаптацию" или настроить механизм адаптации, если он не удовлетворен адаптацией. Модель студента обеспечена хорошим средством высокого уровня, чтобы студент мог управлять адаптацией. Это ведет нас к области просматриваемых (или исследуемых) и изменчивых моделей студента. Эти идеи сейчас становятся все более популярными в области ИСО (Self J., 1988; Corbett A.T., Anderson J.R., 1992). Множество работ в этом направлении было сделано в области адаптивных интерфейсов (Kay J., 1990; Böcker, Hohl, Schwab, 1990). Книга (Schneider-Hufschmidt M.; Kuehme T.; Malinowski U., 1993) обеспечивает хорошее обобщение этих усилий и предлагает таксономию различных видов совместной адаптации, где часть работы делается системой и другая часть студентом.

Мы счиаем, что предложенная улучшенная архитектура на основе модели студента обеспечивает хорошую базу для различных видов совместной адаптации. Эта архитектура дает возможность студенту отдельно управлять механизмами адаптации различных компонентов системы. Настройка конкретной проекции или механизма адаптации не повлияет на другие части системы. Несколько хороших идей о настройке механизма адаптации для гипермедиа могут быть найдены в (Kaplan C.; Fenwick J; Chen J., 1993).

Список литературы

 [Benyon D.R., Murray D.M., 1993] Benyon D.R., Murray D.M. Applying user modeling to human-computer interaction design. AI Review 6: 43-69.

[Böcker H.-D.; Hohl H.; Schwab T. 1990] Böcker, H.-D.; Hohl, H.; and Schwab, T. Individualizing Hypertext. In Proceedings of the Third International Conference on Human-Computer Interaction, INTERACT'90, 931-936. Amsterdam: North-Holland.

[Breuker J.,  1990] Breuker J. EUROHELP: Developing intelligent help systems. Final Report on the P280 ESPRIT Project EUROHELP. Brussles: EC.

[Brusilovsky P.L., 1992a] Brusilovsky P.L. A framework for intelligent knowledge sequencing and task sequencing. In Proceedings of the Second International Conference on Intelligent Tutoring Systems, ITS'92, 499-506. Berlin: Springer-Verlag.

[Brusilovsky P.L., 1992b] Brusilovsky P.L. Intelligent Tutor, Environment and Manual for Introductory Programming. Educational and Training Technology International 29(1): 26-34.

[Brusilovsky P., 1993] Brusilovsky P. Student as user: Towards an adaptive interface for an intelligent learning environment. In Proceedings of World Conference on Artificial Intelligence and Education, AI-ED'93, 386-393. Charlottesville: AACE

[Brusilovsky P.; Pesin L.; Zyryanov M., 1993] Brusilovsky P.; Pesin L.; Zyryanov M. Towards an adaptive hypermedia component for an intelligent learning environment. In Bass, L.J; Gornostaev, J; and Unger, C. eds. Human-Computer Interaction., 348-358. Berlin: Springer-Verlag.

[Brusilovsky P., Zyryanov M., 1993] Brusilovsky P., Zyryanov M. Intelligent Tutor, Environment and Manual for Physical Geography. In Proceedings of the Seventh International PEG Conference, PEG'93, 63-73. Edinburgh.

[Brusilovsky V., 1993] Brusilovsky V. Task sequencing in an intelligent learning environment for calculus. In Proceedings of the Seventh International PEG Conference, PEG'93, 57-62. Edinburgh.

[Brusilovsky P., Pesin, L., 1994] Brusilovsky P., Pesin, L. ISIS-Tutor: An adaptive hypertext learning environments: In Proceedings of Japan-CIS Symposium on knowledge based software engineering, 83-87. Tokyo: Isshinsa, Ltd.

[Burton R.R., 1988] Burton R.R. The environment module of intelligent tutoring systems. In Polson, M.C. and Richardson, J.J. eds. Foundations of intelligent tutoring systems. Hillsdale: Lawrence Erlbaum Associates.

Рекомендуем скачать другие рефераты по теме: література реферат, сочинения по русскому языку.





Предыдущая страница реферата | 1  2  3 | Следующая страница реферата