стью повторного использования. Будут сформулированы требова-
ния для интегрированных ИКОС и разработан прототип архитек-
туры ИКОС, ориентированной на интеграцию.
Основное требование к интегрированной ИКОС: интегриро-
ванная система должна быть не просто суммой, а фактической ин-
теграцией ее компонентов. В работе [11] рассмотрены два аспекта
реальной интеграции. Во-первых, необходимо, чтобы один из ком-
понентов мог использовать возможности другого компонента, а
также обмениваться с ним данными или совместно их использовать.
Во-вторых, во время работы обучаемых с любым из компонентов
результаты его работы должны учитывать другие компоненты для
адаптации к уровню знаний и индивидуальным особенностям каж-
дого отдельного обучаемого. Например, во время работа с гиперме-
дийным компонентом обучаемый может узнать что-то новое. Обу-
чающий компонент должен учесть это во избежание повторной по-
дачи уже изученного материала. Первый аспект мы называем тех-
нической интеграцией, а второй – понятийной интеграцией.
Для того, чтобы добиться понятийной интеграции, нужна не-
которая центральная модель обучаемого, которая бы собирала и
интегрировала информацию о нем изо всех компонентов системы.
Центральная модель может использоваться интеллектуальными и
неинтеллектуальными компонентами для адаптации их работы к
текущему статусу обучаемого.
В работе [12] предлагается проект архитектуры ИКОС как
совокупности независимых повторно используемых модулей, свя-
занных с центральной моделью обучаемого (рис. 52,а). Модули
разделяются на два типа: основанные на знаниях модули или аген-
ты (например, модуль планирования курса обучения), которые со-
держат различные виды знаний и обеспечивают интеллектуаль-
ность системы, и интерфейсные модули или инструментальные
средства, которые взаимодействуют непосредственно с пользова-
телем. Оба вида модулей должны иметь возможность взаимодей-
ствия с другими модулями.
В данной работе говорится об ориентированной на интегра-
цию архитектуре, компоненты которой могут являться различны-
ми отдельными приложениями, включая коммерческие пакеты.
Важный вклад данной работы – это централизованная архитектура
с гибким взаимодействием между компонентами, основанными на
каком-нибудь протоколе связи между приложениями, например
Apple Events и DDE. Выделим два аспекта данной архитектуры: