Интеллектуальные учебные среды по программированию:

аргументы за интеграцию и адаптацию


Петр Брусиловский

Международный Центр Научной и Технической Информации, Москва, Россия
(В настоящее время - кафедра психологии Трирского Университета, D-54286 Трир, Германия)
Адрес эл. почты: [email protected]

Аннотация

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

Введение

С момента появления интеллектуальных обучающих систем (ИОС), популярной областью применения данных систем для разработчиков было обучение программированию. Был разработан ряд мощных методов для помощи новичкам и десятки реальных ИОС и ИУС, которые были описаны в сотнях статей. Обучение программированию можно считать примером успешного приложения ИИ в образовании. Попытка построить таксономию существующих ИОС и ИУС по программированию показывает, что существующие системы охватывают практически все направления классификации. Даже если ограничиться новейшими и наиболее известными системами (т.е. системами, описанными в ряде статей с 1992 по 1995 годы), мы можем обнаружить, что данные системы поддерживают:

• изучение широко спектра языков программирования, включая процедурные языки [Fix & Wiedenbeck, 1992; Ueno, 1994], функциональные языки [Corbett & Anderson, 1993], объектно-ориентированные языки [Chee, Tan & Chan, 1993], языки логического программирования [Gegg-Harrison, 1992], подъязыки [Ramadhan & du Boulay, 1993; Lelouche & Dion, 1994], графические языки [Möbus, Thole & Schröder, 1993], языки параллельного программирования [Herzog, 1992] и некоторые специализированные языки, такие как КОБОЛ [McKendree, Radlinski & Atwood, 1992],

• приобретение знаний и навыков, необходимых для выполнения всех основных шагов реального программирования: постановка задачи [Rozinajova & Navrat, 1993], детализация [Möbus et al., 1993; Verdejo, Fernandez & Urretavizcaya, 1993], планирование [Fix & Wiedenbeck, 1992; Möbus et al., 1993]; кодирование [Corbett & Anderson, 1993; Singley, Carrol & Alpert, 1993]; тестирование и отладка [Brna, Hernandes & Pain, 1993];

• некоторые действия, которые обычно выполняет преподаватель в учебном процессе: адаптивное руководство обучаемым при прохождении последним курса обучения [Brusilovsky, 1992b], предоставление обучаемому соответствующих примеров [Weber, 1995] и задач [Brusilovsky, 1992b; Gegg-Harrison, 1992], помощь обучаемому в процессе решения задачи [Corbett & Anderson, 1993], исправление ошибок [Brette, 1994; Ueno, 1994] в решениях обучаемого и предоставление обучаемому правильного решения [Chee et al., 1993];
  

• 
  различные действия обучаемого, направленные на усвоение учебного материала и решение задач: просмотр различных источников информации [Fischer et al., 1992; Linn, 1992], проигрывание программ-примеров [Weber, 1995], разработка программы и кодирование [Hohmann, Guzdial & Soloway, 1992; Price, McCalla & Greer, 1994], визуальное исполнение и отладка [Eisenstadt, Price & Domingue, 1993; Merrill et al., 1992].

Начинающий ученый, который в поисках области, куда действительно можно привнести что-то новое, анализирует существующую литературу по ИУС для обучения программированию, может решить, что в данной области уже нельзя сделать ничего нового. Все возможные направления уже исследованы несколькими учеными. По каждому этапу учебного процесса, там, где преподавателю или обучаемому требуется помощь компьютера, можно найти несколько статей, в которых говорится о подходящих методах предоставления помощи и способах их внедрения. К сожалению, преподавателю, которого интересует не чтение материалов обо всех этих интеллектуальных средствах, а применение их на практике, ситуация представляется совершенно по-другому. После 20 лет исследований немногие ИОС или ИУС по программированию постоянно используются в реальном учебном процессе, и большая часть из них неприменима вне стен университета, в котором они были разработаны. С другой стороны, все компьютерные программы по программированию в университетах и школах являются неинтеллектуальными автоматизированными обучающими системами, программными средами и гипермедийными системами. Что это: успех или неудача интеллектуальных технологий?

Почему ИУС по программированию не используются в классах


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

Для того чтобы подробнее объяснить это, посмотрим на ситуацию с точки зрения разработчика. Современные интеллектуальные и неинтеллектуальные системы по программированию достаточно сложны. Каждый компонент стоит нескольких человеко-лет исследований, и, как мы уже выяснили, для того, чтобы быть действительно полезной, система должна включать в себя несколько компонентов. Что может сделать в одиночку в такой ситуации молодой ученый (например, докторант), который хочет сделать ощутимый и в то же время полезный с практической точки зрения вклад в эту область? Способ первый: сконцентрировать усилия и разработать один оригинальный компонент ИОС, который может демонстрировать новую идею, но не может быть использован на практике из-за отсутствия от остальных компонент. Способ второй: распределить усилия между несколькими компонентами и попытаться создать полезную систему, но, в конечном счете, изготовить только игрушечный образец. Только если исследователю очень повезло, и он входит в большую группу ученых, у него есть шансы разработать что-то интересное, то, что будет работать в контексте более крупной ИОС. Однако группы сталкиваются с теми же проблемами, поскольку возможности группы обычно ограничены. Обычно группы стараются сосредоточиться на интеллектуальных компонентах ИУС и не любят терять время на создание компонентов, выходящих за рамки их научных интересов, даже если эти важны для пользователя.

Интеграция может решить проблемы


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

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

В результате многие разработчики тратят годы работы на создание неполных систем, которые не могут быть использованы преподавателями. Многие из таких неполных систем включают оригинальные компоненты, воплощающие интересные идеи, но из-за того, что данные компоненты нельзя использовать повторно, эти идеи никогда не реализуются на практике и обычно умирают вместе с системой, когда интересы разработчика меняются. Для того чтобы остановить этот процесс, для ИУС необходимо разработать новую архитектуру, ориентированную на интеграцию. Эта архитектура должна содействовать разработке ИУС как интеграции повторно используемых компонентов. При этом каждая вновь разработанная ИУС будет являться несомненным вкладом в данную область. Идеи и усилия разработчиков никогда больше не будут теряться, потому все оригинальные элементы системы могут быть использованы множеством других людей. Хорошая архитектура, ориентированная на интеграцию, очень важна и может стать ключом к успеху. Яркими примерами этого являются команды Unix и веб-страницы. В обоих случаях, для достижения определенной цели разработчику нужно лишь создать новые необходимые команды или страницы, включив их (при помощи оболочки Unix или гиперссылок) в работу предшественников. В свою очередь, будущие разработчики смогут повторно применить эти новые команды или страницы.

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

Архитектура ИУС, ориентированная на интеграцию


Основное требование к интегрированной ИУС: интегрированная система должна быть не просто суммой, а фактической интеграцией её компонентов. В нашей предыдущей работе [Brusilovsky, Pesin & Zyryanov, 1993] мы рассмотрели два аспекта реальной интеграции. Во-первых, необходимо, чтобы один из компонентов мог использовать возможности другого компонента, а так же обмениваться с ним данными или совместно их использовать. Например, блоку проверки программ для прогона тестируемой программы нужен языковой интерпретатор. Во-вторых, во время работы обучаемых с любым из компонентов результаты его работы должны учитывать другие компоненты для адаптации к уровню знаний и индивидуальным особенностям каждого отдельного обучаемого. Например, во время работа с гипермедийным компонентом обучаемый может узнать что-то новое. Обучающий компонент должен учесть это во избежание повторной подачи уже изученного материала. Первый аспект мы называем технической интеграцией, а второй – понятийной интеграцией.

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

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

• 
  возможность лёгкого повторного использования отдельного компонента в другой системе;
  
• 
  возможность лёгкой интеграции нового компонента в систему (т.е. легкое подключение его к модели обучаемого и другим компонентам);
  
• 
  возможность лёгкой замены отдельного компонента (включая и модель обучаемого!) на аналогичный с минимальным изменением компонентов, которые с ним взаимодействуют.
  

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

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

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

• 
  Взаимодействие. Как создать гибкий интерфейс между компонентами, который позволит им обмениваться информацией и контролировать друг друга? Каким образом компонент может взаимодействовать с «немыми» компонентами, например, с профессиональным программным окружением, которое не поддерживает ни одну стандартную архитектуру?
  
• 
  Моделирование обучаемого. Как создать интерфейс между компонентом и моделью обучаемого, который позволит компоненту предоставлять информацию модели, и использовать это для адаптации? Какая модель обучаемого необходима?
  
• 
  Оболочки. Какие типы родовых модулей, основанных на знаниях, могут быть полезными и как их разрабатывать?
  
• 
  Адаптивный интерфейс. Как, используя модель обучаемого, сделать стандартные интерфейсные компоненты ИУС по программированию (например, редактор структур) адаптивными? Как сделать их приспосабливаемыми к контексту приложения?
  

Проведенная работа дает основу для дальнейших исследований

Ряд проектов уже дали хорошую основу для исследований архитектур, ориентированных на интеграцию. К аспектам межкомпонентного взаимодействия обратились авторы работы по архитектурам ИОС с методологией «классной доски» [McCalla, Greer & Scent, 1990] и позднее члены франко-говорящего сообщества ученых в новой работе по многоагентным архитектурам ИОС и ИУС [Futtersack & Labat, 1992; Girard, Gauthier & Levesque, 1992]. Многоагентная ИУС – это набор независимых компонентов, таких как решающее устройство, среда или учебный планировщик, которые могут иметь локальные знания и взаимодействовать путем обмена сообщениями. Исследование многоагентных архитектур также изучает вопросы родовых агентов и централизованного моделирования обучаемых [Néhémie, 1992].

В новейших исследованиях [Ritter & Koedinger, 1995; van Rosmalen, 1994] рассматриваются более специализированные аспекты межкомпонентного взаимодействия. В данных работах говорится об ориентированной на интеграцию архитектуре, компоненты которой могут являться различными отдельными приложениями, включая коммерческие пакеты. Важный вклад данной работы - это централизованная архитектура с гибким взаимодействием между компонентами, основанными на каком-нибудь протоколе связи между приложениями, например, Apple Events и DDE. Два аспекта данной архитектуры: независимый от приложений язык общения семантического уровня и центр контроля, который собирает и доставляет все межкомпонентные сообщения.

В работах по различным оболочкам ИОС говорится о проблемах родовых компонентов, основанных на знаниях. В них приведены хорошие примеры различных компонентов для контроля за обучением, основанном на педагогическом знании [Major & Reichgelt, 1992; Murray & Woolf, 1992; Van Marcke, 1992; Vassileva, 1990; Vivet, 1988]. Менее изученной областью только с одним примером [Anderson & Pelletier, 1991] являются оболочки поддержки решения задач, основанные на анализе предметной области.

К вопросу централизованного моделирования обучаемого обращаются авторы исследования по моделированию обучаемого и оболочкам моделирования пользователей [Kay, 1995; Kobsa & Pohl, 1995; Paiva & Self, 1994]. Все эти оболочки разработаны для сбора информации о пользователе из различных источников и для обслуживания запросов от различных приложений о пользователе. Следует отметить, что большая часть работы по адаптивным интерфейсам [Schneider-Hufschmidt, Kühme & Malinowski, 1993] была сделана вне традиционной области ИОС.

Наша группа из МГУ внесла вклад во все четыре направления исследований. Сначала мы изучали технические аспекты интеграции и проблему родовых компонентов. Мы разрабатывали различные компоненты ИУС как отдельные процессы UNIX, взаимодействующие по каналам. В частности, мы разработали два «родовых» компонента для упорядочивания задач [Brusilovsky, 1992a] и моделирования обучаемого и «повторно использовали» их в двух различных системах. Позже нам пришлось поменять платформу с UNIX на однозадачную DOS, что вынудило нас сконцентрироваться на понятийных аспектах интеграции. В следующих абзацах мы описываем нашу текущую работу по архитектуре с центральной моделью обучаемого и по разработке различных адаптивных компонентов для нескольких ИУС по программированию.


На пути к полной адаптации и понятийной интеграции

Наша работа в МГУ сосредоточена вокруг двух проблем создания интегрированной ИУС: проблема полной адаптации и проблема понятийной интеграции. Эти проблемы тесно связаны друг с другом. ИУС полностью адаптивна, если все ее компоненты могут динамически адаптироваться к отдельному обучаемому. Большинство ИОС и обучающих компонентов ИУС могут адаптировать свою работу (обучение) к заданному обучаемому, однако очень немногие среды программирования и гипермедийные компоненты могут это делать. Одной из наших целей являлось создание адаптивных сред программирования и гипермедийных компонентов ИУС [Brusilovsky, 1993]. В наших средах программирования адаптивными мы сделали визуального интерпретатора и языкового редактора программ. Визуальный интерпретатор ITEM/IP [Brusilovsky, 1992b] использует текущий уровень знаний обучаемого для того, чтобы обеспечить адаптивную обработку ошибки и адаптивную визуализацию. В более поздней системе ITEM/IP-II мы добавили адаптивную пояснительную визуализацию [Brusilovsky, 1994b] и адаптивный структурный редактор. Последняя наша работа посвящена адаптивному гипермедийному компоненту ИУС. В ITEM/IP мы попробовали адаптивный метод представления и изучили проблемы адаптивной поддержки навигации в ISIS-Tutor [Brusilovsky, 1994a; Brusilovsky et al., 1993].

Понятийная интеграция предполагает, что результаты работы обучаемых с любым компонентом во время занятий должны быть приняты во внимание другими компонентами для того, чтобы адаптировать свои параметры к изменившемуся уровню знаний определенного обучаемого. Наш подход к понятийной интеграции заключается в идее центральной модели обучаемого. Данная модель должна собирать всю информацию об обучаемом и должна быть доступной для всех компонентов ИУС. После того, как мы испробовали решения, основанные на традиционной оверлейной модели студента, мы разработали архитектуру ИУС с центральной моделью обучаемого [Brusilovsky, 1994c], которая может считаться развитием архитектуры, ориентированной на интеграцию, относительно аспектов передачи информации между компонентами и центральной моделью обучаемого (рис. 1б).





Рис. 1. (а) Архитектура интегрированной ИУС и

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


В архитектуре с центральной моделью обучаемого эта модель разделена на две части: центральная модель обучаемого и проекции. Центральная модель обучаемого находится в центре среды и собирает из разных источников информацию о данном студенте. Модель студента получает сообщения о взаимодействии студента с каким-либо из компонентов, представленные в виде стандартных событий понятийного уровня. Например: «в момент времени Т студент посещает гиперузел понятия С в течение S секунд». Отмечается время этих стандартных событий, и они сохраняются в модели. С тем чтобы предотвратить потерю важной информации, дальнейшая обработка данных не производится. Главная модель обучаемого – это хранилище всей информации о нем, которую можно использовать для адаптации.

Компоненты ИУС напрямую не используют модель обучаемого, а вместо этого используют локальное представление обучаемого, которое мы называем проекцией. Проекция отображает ту информацию об обучаемом, которая кажется компоненту необходимой для адаптации своей работы к обучаемому. Компонент имеет настолько богатую и широкую проекцию, насколько это ему нужно для адаптации. Проекция строится и обновляется из главной модели обучаемого с помощью специального набора правил, называемого проектором. У каждого компонента есть своя собственная проекция и проектировщик, которые предоставляют интерфейс между компонентом и главной моделью обучаемого. Подмножество правил проектировщика используется для проецирования главной модели обучаемого в локальную проекцию. Эти правила используют модель обучаемого в своей правой части (условие) и содержат команды для обновления проекции в своей левой части (действие). Другое подмножество правил проектора используется для предоставления обратной проекции: при необходимости результаты работы обучаемого с компонентом проецируются в форму стандартных сообщений, которые использует главная модель обучаемого. Примеры использования проекций можно найти в Brusilovsky, 1994c; Brusilovsky & Zyryanov, 1993].

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

Использование проекций и правил обеспечивает открытую архитектуру с хорошей степенью гибкости. Поскольку характеристики компонента зависят от проекции, то для определенного применения мы можем настроить характеристики путем изменения правил проектировщика (или даже самой проекции) без влияния на другие компоненты. Новый компонент можно с легкостью интегрировать в среду, разработав набор правил, по которым центральная модель с данным компонентом соединяется с локальным представлением обучаемого. Если новому компоненту необходимы новые виды взаимодействия, которые нельзя спроецировать в существующий набор стандартных событий, этот набор можно расширить. Например, событие «в момент времени Т обучаемый услышал изложение понятия С из мультимедийной записи» можно спроецировать в событие «в момент времени Т обучаемый прочитал описание понятия С» или записать как новый вид события. Если определенному модулю для лучшей адаптации нужно принять во внимание новый вид события, его проектировщика можно обновить. Таким образом, использование проекций и правил обеспечивает как раз тот уровень гибкости, который требуется для ориентированной на интеграцию архитектуры.


Итог: мечты или реальное будущее?

В этой статье мы обосновали необходимость будущих исследований ориентированной на интеграцию архитектуры ИУС и рассмотрели проделанную работу, которая дает основу для исследований в данном направлении. Анализ существующих исследований позволил нам представить свойства будущей ИУС, когда совместными усилиями сообщества ИУС будет разработана общая архитектура, ориентированная на интеграцию, и произойдет ли это вообще. Такая ИУС, возможно, будет набором независимых компонентов, интегрированных вокруг центральной модели обучаемого. Некоторые компоненты, основанные на знаниях, такие как планировщик курса обучения или компонент поддержки решения задач будут усовершенствованы путем обработки подходящих родовых компонентов. Некоторые компоненты ИУС будут разработаны авторами ИУС, некоторые будут повторно использованы из других проектов ИУС, а некоторые станут, безусловно, коммерческими системами. Все эти компоненты, однако, смогут посылать модели информацию об обучаемом и использовать модель для адаптации. Каждый компонент сможет контролировать другие компоненты и обмениваться с ними данными. На физическом уровне взаимодействие между компонентами будет осуществлено путем использования взаимодействия между модулями, приложениями и даже по сети [Price et al., 1994]. В последнем случае некоторые богатые знаниями компоненты ИУС могут работать на мощных удаленных компьютерах в другой части света.

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


Литература


Anderson, J. R. & Pelletier, R. (1991). A development system for model-tracing tutors. In L. Birnbaum (Eds.), Proceedings of International Conference on the Learning Sciences (pp. 1-8). Charlottesville: AACE.

Brette, J.-F. (1994). Contextual guidance on type constraint errors in Pascal/V. In J.-L. Dessalles (Eds.), Proceedings of CALISCE'94, International conference on Computer Aided Learning and Instruction in SCience and Engineering, (pp. 337-344). Paris: Telecom.

Brna, P., Hernandes, E. R., & Pain, H. (1993). Learning prolog debugging skills. Proceedings of Seventh International PEG Conference (pp. 561-568). Edinburgh.

Brusilovsky, P. (1993). Student as user: Towards an adaptive interface for an intelligent learning environment. In P. Brna, S. Ohlsson, & H. Pain (Eds.), Proceedings of AI-ED'93, (pp. 386-393). Charlottesville: AACE.

Brusilovsky, P. (1994a). Adaptive hypermedia: the state of the art. In P. Brusilovsky (Eds.), Proceedings of East-West International Conference on Multimedia, Hypermedia and Virtual Reality (pp. 24-29). Moscow: ICSTI.

Brusilovsky, P. (1994b). Explanatory visualization in an educational programming environment: connecting examples with general knowledge. In B. Blumenthal, J. Gornostaev, & C. Unger (Eds.), Human-Computer Interaction (pp. 202-212). Berlin: Springer-Verlag.

Brusilovsky, P. (1994c). Student model centered architecture for intelligent learning environment. Proceedings of 4-th International Conference on User Modeling (pp. 31-36). Hyannis: MITRE.

Brusilovsky, P., Pesin, L., & Zyryanov, M. (1993). Towards an adaptive hypermedia component for an intelligent learning environment. In L. J. Bass, J. Gornostaev, & C. Unger (Eds.), Human-Computer Interaction (pp. 348-358). Berlin: Springer-Verlag.

Brusilovsky, P. & Zyryanov, M. (1993). Intelligent tutor, environment and manual for physical geography. Proceedings of Seventh International PEG Conference (pp. 63-73). Edinburgh.

Brusilovsky, P. L. (1992a). A framework for intelligent knowledge sequencing and task sequencing. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems (pp. 499-506). Berlin: Springer-Verlag.

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

Chee, Y. S., Tan, J. T., & Chan, T. (1993). Applying cognitive apprenticeship to the teaching of Smalltalk in a computer based learning environment. Proceedings of 7-th International PEG Conference (pp. 569-588).

Corbett, A. T. & Anderson, J. R. (1993). Student modeling in an intelligent programming tutor. In G. Dettori, B. du Boulay, & E. Lemut (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 135-144). Berlin: Springer-Verlag.

Eisenstadt, M., Price, B. A., & Domingue, J. (1993). Redressing ITS fallacies via software visualization. In G. Dettori, B. du Boulay, & E. Lemut (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 220-234). Berlin: Springer-Verlag.

Fischer, G., Girgensohn, A., Nakakoji, K., & Redmiles, D. (1992). Supporting software designers with integrated domain-oriented design environments. IEEE Trans. Software Engeneering, SE-18(6), 511-522.

Fix, V. & Wiedenbeck, S. (1992). Designing a tool for learning ADA using empirical studies. Proceedings of 5-th Workshop of the "Psychology of programming interest group" (PPIG5) (pp. 237-246). Paris: INRIA.

Futtersack, M. & Labat, J.-M. (1992). QUIZ, a distributed intelligent tutoring system. In I. Tomek (Eds.), Proceedings of 4th International Conference, ICCAL'92 (pp. 225-237). Berlin: Springer-Verlag.

Gegg-Harrison, T. S. (1992). Adapting instruction to the student's capabilities. Journal of Artificial Intelligence in Education, 3(2), 169-181.

Girard, J., Gauthier, G., & Levesque, S. (1992). Une architecture multiagent. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 172-182). Berlin: Springer-Verlag.

Herzog, C. (1992). From elementary knowledge schemes towards heuristic expertise - designing an ITS in the field of parallel programming. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 183-190). Berlin: Springer-Verlag.

Hohmann, L., Guzdial, M., & Soloway, E. (1992). SODA: a computer-aided design environment for the doing and learning of software design. In I. Tomek (Eds.), Proceedings of ICCAL'92 (pp. 307-318). Berlin: Springer-Verlag.

Kay, J. (1995). The UM toolkit for cooperative user models. User Modeling and User Adapted Interaction, 4 (3), 149-196.

Kobsa, A. & Pohl, W. (1995). The BGP-MS user modeling system. User Modeling and User Adapted Interaction, 4(2), 59-106.

Lelouche, R., & Dion, P. (1994). Using the model-tracing methodology in a learning environment with a non-directive tutoring strategy. In J.-L. Dessalles (Eds.), Proceedings of CALISCE'94, International conference on Computer Aided Learning and Instruction in Science and Engineering, (pp. 259-268). Paris: Telecom.

Linn, M. C. (1992). How can hypermedia tools help teach programming. Learning and Instruction, 2,119-139.

Major, N. & Reichgelt, H. (1992). COCA: A shell for intelligent tutoring systems. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 523-530). Berlin: Springer-Verlag.

McCalla, G. I., Greer, J. E., & Scent Research Team. (1990). SCENT-3: An architecture for intelligent advising in problem-solving domains. In C. Frasson & G. Gauthier (Eds.), Intelligent Tutoring Systems: At the crossroads of artificial intelligence and education (pp. 140-161). Norwood: Ablex Publishing.

McKendree, J., Radlinski, B., & Atwood, M. E. (1992). The Grace Tutor: a qualified success. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 677-684). Berlin: Springer-Verlag.

Merrill, D. C., Reiser, B. J., Beekelaar, R., & Hamid, A. (1992). Making process visible: Scaffolding learning with reasoning-congruent representations. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems (pp. 103-110). Berlin: Springer-Verlag.

Möbus, C., Thole, H.-J., & Schröder, O. (1993). Interactive support of planning in a functional, visual programming language. In P. Brna, S. Ohlsson, & H. Pain (Eds.), Proceedings of AI-ED'93, (pp. 262-269).

Murray, T. & Woolf, B. P. (1992). Tools for teacher participation in ITS design. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 593-600). Berlin: Springer-Verlag.

Néhémie, P. (1992). A systemic approach for student modelling in a multi-agent aided learning environment. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems(pp. 475-482). Berlin: Springer-Verlag.

Paiva, A. & Self, J. (1994). TAGUS - a user and learner modeling system. Proceedings of 4-th International Conference on User Modeling (pp. 43-49). Hyannis: MITRE.

Price, B. R., McCalla, G. I., & Greer, J. E. (1994). Combining scaffolding and diagnosis in a distributed tutoring system. In P. Brusilovsky, S. Dikareva, J. Greer, & V. Petrushin (Eds.), Proceedings of 3-rd East-West Conference on Computer Technologies in Education (EW-ED'94) (pp. 189-194). Moscow: ICSTI.

Ramadhan, H. & du Boulay, B. (1993). Programming environments for novices. In G. Dettori, B. du Boulay, & E. Lemut (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 125-134). Berlin: Springer-Verlag.

Ritter, S. & Koedinger, K. R. (1995). Towards lightweight tutoring agents. Proc.of AI-ED'95, See this volume

Rozinajova, V. & Navrat, P. (1993). Making programming knowledge explicit. Computers and Education, 21(4), 281-299.

Schneider-Hufschmidt, M., Kühme, T., & Malinowski, U. (Ed.). (1993). Adaptive user interfaces: Principles and practice. Amsterdam: North-Holland.

Singley, M. K., Carrol, J. M., & Alpert, S. R. (1993). Incidental reification of goals in an intelligent tutor for Smalltalk. In G. Dettori, B. du Boulay, & E. Lemut (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 145-155). Berlin: Springer-Verlag.

Ueno, H. (1994). Integrated intelligent programming environment for learning programming. IEICE Transactions on information and systems, E77-D(1), 68-79.

Van Marcke, K. (1992). Instructional expertise. In C. Frasson, G. Gauthier, & G. I. McCalla (Eds.), Intelligent Tutoring Systems (pp. 234-243). Berlin: Springer-Verlag.

van Rosmalen, P. (1994). SAM, Simulation and Multimedia. In T. de Jong & L. Sarti (Eds.), Design and production of multimedia and simulation-based learning material (pp. 167-187). Dordrecht: Kluwer.

Vassileva, J. (1990). An architecture and methodology for creating a domain-independent, plan-based intelligent tutoring system. Educational and Training Technology International, 27(4), 386-397.

Verdejo, M. F., Fernandez, I., & Urretavizcaya, M. T. (1993). Methodology and design issues in Capra, an environment for learning program construction. In G. Dettori, B. du Boulay, & E. Lemut (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 156-171). Berlin: Springer-Verlag.

Vivet, M. (1988). Knowledge-based tutors. Towards the design of a shell. International Journal of Educational Research, 12(8), 839-850.

Weber, G. (1995). Providing Examples and Individual Remindings in an Intelligent Programming Environment. Proceedings of AI-ED'95, See this volume.

Благодарности

Я хочу поблагодарить Ben du Boulay, Jim Greer и Gerhard Weber, которые оказали влияние на развитие идей, представленных в этой статье. В части данной работы автору помогли Королевское Научное Общество (Royal Society Fellowship) и Общество «Фонд им. Александра фон Гумбольдта» (Alexander von Humboldt-Stiftung Fellowship).