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

На правах рукописи

МАЛЬЦЕВ Денис Анатольевич

МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ ЭЛЕМЕНТОВ КОМПОНЕНТНОЙ АВТОМАТИЗИРОВАННОЙ ОБУЧАЮЩЕЙ СИСТЕМЫ

05.13.18 - математическое моделирование, численные методы и комплексы программ

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Ульяновск - 2006

Работа выполнена на кафедре информационных технологий и систем факультета информационных и телекоммуникационных технологий государственного образовательного учреждения высшего профессионального образования Ульяновский государственный университет

Научный руководитель: доктор технических наук, профессор

Кумунжиев Константин Васильевич

Официальные оппоненты: доктор технических наук, профессор

Смагин Алексей Аркадьевич кандидат технических наук, Тетерко Вадим Владимирович

Ведущая организация: ГОУ ВПО Ульяновский государственный

технический университет

Защита диссертации состоится «26» апреля 2006 года в 15 часов 00 минут на заседании диссертационного совета Д 212.278.02 при Ульяновском государственном университете по адресу: г. Ульяновск, ул. Университетская Набережная, 1, ауд. 703.

С диссертацией можно ознакомиться в библиотеке Ульяновского государственного университета

Автореферат разослан «_£/_» мартах 2006 года

Просьба прислать отзыв на автореферат в одном экземпляре, заверенном

печатью организации по адресу:

432970, г. Ульяновск, ул. Л Толстого, д. 42, УлГУ, Управление научных исследований

Ученый секретарь диссертационного совета

¿00 £ А

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность исследования. Научный прогресс характеризуется интенсивным накоплением знаний и стремительным увеличением объема информации. Происходит быстрый процесс компьютеризации общества В компьютерных классах большинства школ стоят достаточно мощные мультимедийные станции, не говоря уже о высших учебных заведениях. В этих условиях веб большее значение приобретает поиск новых методов и средств повышения эффективности процесса обучения. Одним из наиболее перспективных путей, является путь использования автоматизированных обучающих систем (АОС), которые базируются на современной вычислительной технике и составляют основу компьютерных технологий обучения1. В настоящее время, как в нашей стране, так и за рубежом создано и функционирует большое количество АОС по различным дисциплинам. Многие абитуриенты, помимо чтения методической литературы, рекомендованной ВУЗом для поступления, приобретают АОС, содержащие не только подготовительную литературу, но и возможность предварительной проверки уровня знаний2. Множество крупных издателей программного обеспечения (ПО) в России, видя такую заинтересованность со стороны покупателей, также организуют свои отделы по созданию АОС в качестве «домашних репетиторов», включающих в себя как стандартную школьную программу, так и расширенную программу для поступления в специализированные ВУЗы.

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

Объект исследования. Объектом исследования является среда разработки АОС.

Предмет исследований. Методы и средства для повышения эффективности процесса разработки ПО для АОС.

1 Башмаков А И, Башмаков И А Разработка компьютерных учебников и обучающих систем - М Филинъ, 203 - 616 с

1 Баташов А И, Захарова Т Н Реализация метода ускоренного обучения студентов на базе системного проблемного подхода в сочетании с новыми информационными технологиями // Сб науч -метод ст Вып 7 / ВСГГУ -Улан-Удэ, 2001 -С 215-218

1 Морев И А Проблемы компьютерного представления обпазова1баы!йй_информации // Вестник Удмуртского

университета, 2001 №10-11 РОС- НАЦИОНАЛЬН !

БИБЛИОТЕКА

«Из';

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

Для достижения этой цели в работе решены следующие задачи:

• анализ существующих АОС, выявление задач стоящих перед ними, определение их единого внутреннего представления, исследование основных технологий, применяемых при разработке АОС, и выделение методов взаимодействия их элементов;

• построение модели-класса взаимодействия элементов АОС, пригодной для решения основных задач, стоящих перед современными АОС;

• разработка системы интерфейсов взаимодействия элементов АОС;

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

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

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

Научная новизна работы заключается в следующем:

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

• предложена структура интерфейсов взаимодействия элементов АОС, позволяющая подключать компоненты сторонних разработчиков;

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

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

Практически полезные эффекты заключаются в следующем:

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

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

обработки исключений при возникновении критических ситуаций в компонентах.

Апробация работы. Основные научные и практические результаты исследований по теме диссертации докладывались на XII ежегодной научно-практической конференции (г. Ульяновск, 2002г.), I всероссийской научно-практической конференции «Современные технологии в российской системе образования» (г. Пенза, 2003г.), 5-й всероссийской очно-заочной научно-практической конференции «Инновации и информационные технологии в образовании» (Владивосток, 2004г.), III всероссийской научно-практической конференции «Современные технологии в российской системе образования» (г. Пенза, 2005г.), на заседаниях кафедры «Информационных Технологий и Систем» (Ульяновск, 2005). Основные положения, выносимые на защиту.

• принцип организации АОС;

• модель взаимодействия компонентов АОС;

• метод повышения надежности работы АОС при возникновении критических ситуаций в одном из компонентов.

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

Публикации. Материалы диссертации опубликованы в 7 работах Из них 3 статьи и 4 тезиса докладов научных конференций.

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

ОСНОВНЫЕ ПОЛОЖЕНИЯ РАБОТЫ

Во введении дается понятие АОС, рассмотрена актуальность задачи повышения качества и скорости разработки АОС, сформулированы цели и задачи исследования.

В первой главе «Задачи автоматического процесса обучения с использованием современных информационных систем» анализируется ситуация, сложившаяся в системе удаленного образования, использующего автоматизированные обучающие системы В процессе анализа нескольких десятков различных обучающих программных комплексов выявлен следующий спектр задач стоящий перед современными АОС:

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

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

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

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

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

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

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

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

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

1) В основном различные АОС состоят из одинаковых частей, выполняющих сходные задачи. В то же время программы других производителей не подходят для реализации своих замыслов, т.к. преследуют иные цели или иной метод обучения. Разработчик, впервые столкнувшийся с задачей написания АОС, вынужден реализовывать все эти части с нуля

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

3) Ставится задача по реализации модели взаимодействия компонентов АОС Для этого необходимо решить следующие частные подзадачи:

a) анализ предметной области и создание ее концептуальной модели,

b) исследование структуры современных АОС и определение их единого внутреннего представления,

c) разбиение АОС на ортогональные компоненты и формирование интерфейсов для их взаимосвязи,

(!) разработка ядра, обеспечивающего передачу информации от одного компонента АОС к другому. Во второй главе «Формализация компонентов автоматизированных обучающих систем» введено понятие интерфейсов взаимодействия компонентов, а так же приведены основные требования, которым они должны удовлетворять:

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

• полиморфизм - это способность обрабатывать разные объекты единообразно; если два разных компонента поддерживают один и тот же интерфейс, для работы с ними клиент может использовать один и тот же код, таким образом, клиент может работать с разными компонентами полиморфно.

Сформулированы правила, которым должны следовать все реализации интерфейсов:

• клиент всегда получает один и тот же базовый интерфейс;

• можно получить интерфейс снова, если смогли получить его раньше; без фиксированного набора интерфейсов клиент не мог бы сколько-нибудь уверенно определить возможности компонента;

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

• независимо от того, какой интерфейс есть сейчас, можно снова получить интерфейс, с которого начинали;

• если можно получить у компонента некоторый интерфейс, то его можно получить с помощью любого из интерфейсов, поддерживаемых компонентом, то есть, если можно получить интерфейс 1У через IX, а К через ГУ, то К можно получить и через IX.

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

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

Предложено наследовать все интерфейсы в АОС от базового, который обладает следующими возможностями:

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

• Инкремент счетчика владельцев. Используется при прямом копировании указателя на интерфейс.

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

Предложен метод абстрагирования клиента от компонента путем введения промежуточного звена - ядра системы.

Клиент

Клиент

IX

1У

Компонент №1

Рис. 1. Взаимодействие компонентов посредством ядра.

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

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

• загрузка и удаление компонентов;

• перезагрузка компонента в случае его нестабильного поведения или сообщение остальным модулям о некорректной рабоге компонента, корректное завершение работы при возникновении критической ошибки;

• регистрация интерфейсов при загрузке компонента; процедуру регистрации проводит сам компонент, ядро лишь предоставляет необходимые для этого функции;

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

• получение сообщений от операционной системы (ОС) и передача внутренних уведомляющих сообщений соответствующим компонентам.

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

Приведена модель оценки эффективности компонентных АОС В качестве оценочной функции для монолитных АОС используется функция каскадной модели жизненного цикла программного обеспечения:

т = ^(Тот +тпс +ТК +Тт)} где

• Тот - время, затрачиваемое на определение требований, необходимых для решения задачи;

• ТПс - время, затрачиваемое на проектирование системы для решения задачи;

• Тк - время, затрачиваемое на кодирование программных модулей;

• Тт - время, затрачиваемое на тестирование.

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

Т = ^(Тот+р-Тв+(\-р)(Тпс +Тк) + Тт)

, где.

• Тв - время, затрачиваемое на внедрение стороннего компонента в свою систему;

• р - коэффициент, определяющий возможность использования стороннего компонента в своей АОС. Он выглядит следующим образом:

р = шт(1, Ы-к) где

• N - количество компонентов, удовлетворяющих предложенному стандарту взаимодействия компонентов АОС;

• к - коэффициент- универсальности компонента.

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

Используя метрику М.Холстеда выводится, что объем компонентной АОС и, соответственно, время на ее разработку будет меньше времени, затрачиваемого на разработку монолитных АОС И с ростом числа сторонних компонентов, оно будет линейно уменьшаться.

В конце главы сформулированы основные выводы и результаты:

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

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

• Определены методики формализации и построения компонент.

• Исследование и обобщение набора компонент позволило определить структуру и состав компонент, необходимый для реализации полноценной АОС. Показано, что в состав АОС целесообразно включить глобальные компоненты: «Представление знаний», «База знаний», «Контроль знаний» и «Статистика». И в дальнейшем подвергнуть их декомпозиции.

• Разработана технология построения компонент и взаимодействия их посредством ядра.

• По результатам анализа элементов различных АОС, предложены методики построения моделей компонент «Представление знаний», «База знаний», «Контроль знаний» и «Статистика», а так же интерфейсов, предоставляемых ими.

• Определена рекомендуемая модель АОС, ее компонентов и способов их взаимодействия.

В третьей главе «Основные аспекты программной реализации структуры компонентов АОС» сформулированы и объяснены главные требования к компонентам: во-первых, они должны компоноваться динамически; во-вторых, они должны скрывать (или инкапсулировать) детали своей реализации.

Необходимость изоляции клиента от деталей реализации накладывает на компоненты ряд важных ограничений:

1) Компонент должен скрывать используемый язык программирования. Любой клиент должен иметь возможность использовать компонент, независимо от языков программирования, на которых они написаны. Раскрытие языка реализации создает новые зависимости между клиентом и компонентом

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

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

11

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

Наиболее удовлетворяющей всем представленным выше требованиям, в том числе и требованиям к интерфейсам, перечисленным во второй главе, является модель компонентных объектов Microsoft (СОМ). Основные причины при выборе:

• технология поддерживается на множестве платформ;

• с ее помощью можно выполнить почти все требования-

• она не привносит дополнительных ограничений.

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

• Компоненты СОМ полностью независимы от языка программирования

• Компоненты СОМ могут распространяться только в двоичной форме.

• Компоненты СОМ можно прозрачно перемещать по сети. Компонент на удаленной системе рассматривается так же, как компонент на локальном компьютере.

Основные недостатки технологии СОМ:

• зависимость интерфейса от компонента;

• интерфейсы наследуются только от базового IUnknown, таким образом, для расширения компонента нельзя использовать стандартные подходы объектно-ориетированного программирования.

Представлен способ предоставления интерфейса клиентам по его уникальному идентификатору. Однако, как следует из второй главы, в отличие от «чистого» СОМ, компоненты АОС могут получить интерфейс только посредством ядра. Для этого ядро предоставляет функцию QueryTnterface, прототип которой полностью идентичен прототипу из интерфейса IUnknown описанного в спецификации СОМ, но алгоритм отличается от него.

Рис 2 Алгоритм функции Querylnterface в ядре системы

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

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

Включение похоже на включение в С++. Однако, в данном случае включение выполняется на уровне интерфейсов. Внешний компонент содержит указатели на интерфейсы внутреннего. Внешний компонент - просто клиент внутреннего компонента. Используя интерфейсы последнего, он реализует свои собственные интерфейсы.

Внешний компонент

Рис 3 Внешний компонент содержит внутренний компонент и использует его интерфейс К

Внешний компонент может также реализовывать заново интерфейс, поддерживаемый внутренним, передавая последнему вызовы этого интерфейса

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

Внешний компонент

Рис. 4. Внешний компонент содержит внутренний компонент и повторно использует его реализацию интерфейса ГУ

Агрегирование - это особый вид включения. Когда внешний компонент агрегирует интерфейс внутреннего компонента, он не реализует интерфейс последнего заново и не передает ему вызовы этого интерфейса явно (как при включении). Вместо этого внешний компонент передает указатель на интерфейс внутреннего компонента непосредственно клиенту. Далее клиент напрямую вызывает методы интерфейса, принадлежащего внутреннему компоненту. При таком подходе внешний компонент избавлен от необходимости реализовывать заново функции интерфейса и передавать вызовы внутреннему компоненту. Однако внешний компонент не может специализировать какие-либо функции интерфейса. После того, как внешний компонент передаст интерфейс клиенту, гот обращается к внутреннему компоненту самостоятельно. Клиент не должен знать, что он работает с двумя разными компонентами, так как это нарушит инкапсуляцию. Задача агрегирования - заставить внешний и внутренний компоненты вести себя как один компонент. Эта возможность достигается при помощи 0иегу1Шег£асе.

Внешний компонент

Рис 5 Когда внешний компонент агрегирует интерфейс, он передает указатель на него непосредственно клиенту.

Возможны различные сочетания включения и агрегирования. Компонент может специализировать или расширять множество интерфейсов, реализованных многими разными компонентами Некоторые интерфейсы он может включать, другие же агрегировать. Подобные техники программирования называются «design patterns» и подробно описаны во множестве современных книг по проектированию.

Предложено решение для случая, когда приложение уже реализовано в ЕХЕ и, поэтому, предпочтительнее реализовать компонент в ЕХЕ, а не в DLL. В связи с этим возникает проблема расположения компонент в различных процессах Для ее решения в ОС Windows используется локальный вызов процедуры (local procedure call, LPC). LPC - это средство связи между разными процессами на одной и той же машине Для передачи параметров функции из адресного пространства клиента в адресное пространство компонента используется процесс, называемый маршалингом (marshaling). Если оба процесса находятся на одной машине, маршалинг выполняется просто. Данные одного процесса копируются в адресное пространство другого процесса Если процессы находятся на разных машинах, то данные преобразуются в стандартный формат, учитывающий межмашинные различия, например, порядок следования байтов в слове. Для маршалинга компонента предложен интерфейс IMarshal. В процессе создания компонента СОМ запрашивает у него этот интерфейс Затем СОМ вызывает функции-члены этого интерфейса для маршалинга и демаршалинга параметров до и после вызова функций.

Такой способ не совсем универсален, т.к. отвергает работу с интерфейсами, но с самого начала стояла задача унифицировать работу клиента с компонентами - внутри процесса, вне процесса и удаленными Очевидно, что цель не достигнута, если клиенту нужно заботиться о LPC. Для решения этой задачи предлагается следующее Клиент взаимодействует с DLL, которая изображает собой компонент. Эта DLL выполняет за клиента маршалинг и вызовы LPC. В такой компонент называется заместителем (proxy) И так, заместитель - это компонент, который действует как другой компонент. Заместители должны находиться в DLL, так как им необходим доступ к адресному пространству клиента для маршалинга данных, передаваемых ему функциями интерфейса. Но маршалинг - это лишь половина дела; компоненту еще потребуется DLL, называемая заглушкой (stub), для демаршалинга данных, переданных клиентом. Заглушка выполняет также маршалинг данных, возвращаемых компонентом обратно клиенту (рис 6).

Рис. 6. Процесс маршалинга.

Рассмотрено, каким образом, можно повысить стабильность работы подобных систем (рис. 7). При возникновении исключения в одном из компонентов, операционная система прекращает процесс, в котором он выполнялся. После этого, обращения к нему других компонентов или ядра системы так же могут вызывать исключения или аварийное завершение работы. Тем самым разрушается вся система целиком. Идеальным поведением программы, в данном случае, был бы такой: при возникновении исключения, перед тем как операционная система завершит процесс, он посылает уведомление основному компоненту (ядру) с просьбой перезагрузить его. Ядро перезагружает компонент, а остальные процессы даже не будут подозревать о происшествии. В этом случае все компоненты избавляются от необходимости производить проверки на существование, программист избавляется от необходимости вставки рутинного кода и, тем самым, повышается стабильность системы

Для реализации этого алгоритма предложено использовать механизм структурированной обработки исключений (Structured Exception Handling -SEH). Суть механизма SEH состоит в том, что приложение, во время своего выполнения, может установить процедуру обратного вызова, и затем, при возникновении какого-либо исключения, система вызовет эту процедуру, чтобы дать приложению возможность самому обработать исключительную ситуацию. Это позволило бы рассчитывать, что обработчик исключений сможет сам устранить причину возникновения исключения, и даст приложению возможность продолжить свое выполнение. Однако, использование SEH имеет ряд важных недостатков, перекрывающих преимущества, предоставляемых его использованием:

1) Он замещает установленный ранее обработчик новым. Такое поведение говорит, что его использование может привести к тому, что обработчик может быть переустановлен кем угодно.

2) Невозможность отладки обработчика, поскольку функция UnhandledExceptionFilter передает управление отладчику до вызова пользовательского обработчика, мешая нормальной отладке.

Процесс обработки исключительных ситуаций в ОС Windows

Процесс обработки исключительных ситуаций АОС.

Рис. 7 Процесс взаимодействия операционной системы и АОС при возникновении исключительной ситуации

Перечисленные недостатки не всегда устраивают разработчика Предлагается другой способ, как получить управление во время возникновения необработанного исключения. Следуя механизму SEH, если ОС не нашла подходящего обработчика исключений, она вызывает функцию UnhandledExceptionFilter. Эта функция находится в kernel32.dll и имеется во всех версиях Windows.

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

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

Рис 8 Алгоритм установки фильтра необработанных исключений

Функция-переходник имеет две цели - это вызвать фильтр и вернуть управление системной функции.

Основные выводы, сформулированные в третьей главе:

• показано, что для реализации компонентной структуры АОС выгодно использовать технологию СОМ, как наиболее эффективную и удобную для построения модели взаимодействия компонент посредством интерфейсов;

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

• для расширения уже готовых СОМ-компонент от сторонних производителей предложены методы включения и агрегирования, как наиболее эффективные методы независимые от языка программирования.

ОСНОВНЫЕ РЕЗУЛЬТАТЫ И ВЫВОДЫ

1) Определена структура и состав модели компонентной АОС. Показано, что в состав модели целесообразно включить следующие основные элементы, в последствии подлежащие декомпозиции: представление знаний, база

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

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

3) Предложен метод обеспечения надежности работы системы в случае возникновения критических ошибок в каком-либо из компонентов системы. Он основан на механизме структурированной обработки сообщений, встроенном в операционную систему Windows, и является наиболее перспективным в плане простоты использования, удобства встраивания в систему и стабильности работы.

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

СПИСОК ПУБЛИКАЦИЙ ПО ТЕМЕ ДИССЕРТАЦИИ

1. Флоринский A.C., Мальцев Д.А. Базы знаний в обучающих системах // Сборник докладов и тезисов докладов студентов и аспирантов на XII ежегодной Научно-практической конференции «Труды молодых ученых Ульяновского государственного университета», Ульяновск, 2002, С. 19-20.

2. Мальцев Д А. Проблема контроля знаний в автоматизированных системах обучения // Сборник материалов I Всероссийской научно-практической конференции «Современные технологии в российской системе образования», Пенза, 2003, С. 109-111.

3. Мальцев Д.А. Проблема контроля знаний в автоматических обучающих системах // Материалы 5-й Всероссийской очно-заочной научно-практической конференции «Инновации и информационные технологии в образовании», Владивосток, 2004, Книга 2, С. 65-66.

4. Мальцев Д.А. Структура расширяемых обучающих систем на базе технологии СОМ // Сборник материалов Ш Всероссийской научно-практической конференции «Современные технологии в российской системе образования», Пенза, 2005г С. 124-126.

5. Мальцев ДА. Подход к созданию распределенных автоматических обучающих систем (АОС) // Открытое и дистанционное образование, ТГУ, 2005, №3(19), С. 42-45.

6. Мальцев Д.А. Проблема создания расширяемых автоматических обучающих систем (АОС) // Дополнительное профессиональное образование, Москва, 2005, №5(17), С. 36-38.

7. Мальцев Д.А. Обработка критических ошибок в распределенных системах приложений // Информационные технологии моделирования и управления, Научная книга, Воронеж, 2005, Вып. 4(22), С.599-603.

Я" 6 2 5 9

Подписано в печать 14.03.06. Формат 60x84/16. Усл. печ. л. 1,0. Тираж 100 экз. Заказ №26//<#

Отпечатано с оригинал-макета в типографии Издательского центра Ульяновского государственного университета 432970, г. Ульяновск, ул. Л. Толстого, 42

Оглавление.

Введение.

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

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

1.2. Анализ ситуации сложившейся в системе удаленного образования, использующего автоматизированные обучающие системы.

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

1.4. Выводы.

Глава 2. Описание компонентов автоматизированных обучающих систем.

2.1. Интерфейсы взаимодействия компонентов.

2.2. Структура взаимодействия компонентов АОС и функционирование ядра обучающего комплекса.

2.3. Функциональное строение компонента «Представление знаний».

2.4. Функциональное строение компонента «База знаний».

2.5. Функциональное строение компонента «Контроль знаний».

2.6. Функциональное строение компонента «Статистика».

2.7. Модель оценки эффективности компонентных АОС.

2.8. Выводы.

Глава 3. Программная реализация структуры компонентов АОС.

3.1. Главные требования к компонентам.

3.2. Использование COM (Component Object Model) для реализации структуры компонентов.:.

3.3. Предоставление интерфейса компонентом.

3.4. Включение и агрегирование.

3.5. Реализация компонентов в исполняемых файлах и взаимодействие удаленных компонентов.

3.6. Обеспечение надежности АОС.

3.7. Выводы.

Актуальность исследования.

Научный прогресс характеризуется интенсивным накоплением знаний и стремительным увеличением объема информации. Происходит стремительный процесс компьютеризации общества: за последний десяток лет компьютеры перешли из области «у папы в институте» в область их домашнего и повсеместного применения. В компьютерных классах большинства школ стоят достаточно мощные мультимедийные станции, не говоря уже о высших учебных заведениях. В этих условиях всё большее значение приобретает поиск новых методов и средств повышения эффективности процесса обучения. Одним из наиболее перспективных путей, является путь использования автоматизированных обучающих систем (АОС), которые базируются на современной вычислительной технике и составляют основу компьютерных технологий обучения. В настоящее время, как в нашей стране, так и за рубежом создано и функционирует большое количество АОС по различным дисциплинам. Многие абитуриенты помимо чтения методической литературы, рекомендованной ВУЗом для поступления, приобретают АОС содержащие не только подготовительную литературу, но и возможность предварительной проверки уровня знаний. Множество крупных издателей программного обеспечения (ПО) в России, видя такую заинтересованность со стороны покупателей, также организовывают свои отделы по созданию АОС в качестве «домашних репетиторов», включающих в себя как стандартную школьную программу, так и расширенную программу для поступления в специализированные ВУЗы.

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

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

• анализ существующих АОС, выявление задач стоящих перед ними, исследование основных технологий, применяемых при разработке АОС;

• построение модели-класса взаимодействия элементов АОС, пригодной для решения всех задач стоящих перед современными АОС;

• разработка системы интерфейсов взаимодействия компонентов АОС;

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

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

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

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

Объект исследования.

Объектом исследования является гибкая среда разработки программного обеспечения для АОС.

Предмет исследований.

Исследования и разработка методов и средств минимизации времени и материальных ресурсов на разработку АОС определили предмет исследований диссертационной работы.

Методологическая и теоретическая основы.

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

Научная новизна.

На научную новизну претендуют: ® принцип организации и разработки АОС, основанный на компонентных системах программного обеспечения;

• структура интерфейсов взаимодействия компонентов АОС, скрывающая детали внутренней реализации компонентов;

• способ повышения надежности АОС за счет механизма структурированной обработки исключений.

Практическая значимость исследования.

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

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

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

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

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

В приложениях представлен перечень основных интерфейсов предоставляемых компонентами АОС. Приводится введение в язык описания интерфейсов IDL и примеры использования компилятора MIDL.

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

1. Анализ ситуации показал актуальность разработки модели взаимодействия компонентов АОС, использование которой позволяет значительно ускорить процесс создания АОС.

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

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

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

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

6. В результате решения конкретных задач установлено, что при увеличении кампаний, использующих предложенную модель взаимодействия компонентов АОС, время на разработку новой АОС линейно уменьшается. Так же уменьшается трудоемкость построения компонентов АОС, за счет уже готовой базовой структуры.

Заключение.

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

• принцип организации и разработки АОС, основанный на компонентных системах программного обеспечения;

• структура интерфейсов взаимодействия компонентов АОС;

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

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

Результаты исследований диссертационной работы открывают практически полезные эффекты для создания АОС на любой стадии разработки. В числе которых выделяются следующие:

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

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

1. Аванесов B.C. Композиция тестовых заданий: Учебная книга. 3-е издание., доп. - М.: Центр тестирования, 2002. — 240 с.

2. Аверьянов Л.Я. Почему люди задают вопросы. М.: Социолог, 1993. -152 с.

3. Автоматизированное проектирование. / Под ред. Полозова B.C., Буденкова О.А., Роткова С.И. и др. М.: Машиностроение, 1983.

4. Александреску А. Современное проектирование на С++. М.: Издательский дом «Вильяме», 2004. - 336 с.

5. Ален И. Голуб. С и С++. Правила программирования. М.: БИНОМ, 1996.-272 с.

6. Альтшуллер Г.С. Алгоритм изобретения. -М.: Моск. Рабочий, 1973.

7. Басакер Р., Саати Т. Конечные графы и сети. М.: Наука, 1974. - 368 с.

8. Баташов А.И., Захарова Т.Н. Реализация метода ускоренного обучения студентов на базе системного проблемного подхода в сочетании с новыми информационными технологиями. // Сб. науч.-метод. ст. Вып. 7 / ВСГТУ. Улан-Удэ, 2001. - С. 215-218.

9. Башмаков А.И., Башмаков И.А. Разработка компьютерных учебников и обучающих систем. М.: Филинъ, 203. - 616 с.

10. Ю.Бауэр А., Гооз Г. Информатика. М.: Мир, 1976.

11. П.Белнап Н., Стил Т. Логика вопросов и ответов. М.: Прогресс, 1981. -287 с.

12. Богданов Г.М. Проектирование изделий: Организация и методика постановки задачи. М.: Издательство стандартов, 1995. - 144 с.

13. З.Бурков В.Н., Новиков Д.А. Теория активных систем: состояние и перспективы. -М.: Синтег, 1999. 128 с.

14. Бусленко Н.П. Моделирование сложных систем.

15. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-е издание. М.: Бином, 1998. - 560 с.

16. Вагин В.Н. Дедукция и обобщение в системах принятия решений. М.: Наука, 1988.-384 с.

17. Введение в АОС: Методические указания // Сост. Крылова Т.В. Н. Новгород: Изд-во НГТУ, 1987. 68 с.

18. Вербицкий А.А., Комраков Е.С., Чернявская А.Г. Современные образовательные системы: мозаика моделей. Жуковский: МИМ ЛИНК, 2003.-34 с.

19. Вирт Н. Алгоритмы + программы = программы. М.: Мир, 1985.

20. Войшвилло Е.К., Дегтярев М.Г. Логика как часть теории познания и научной методологии. М.: Наука, 1994. - 311 с.

21. Вощинин А.П., Сотиров Г.Р. Оптимизация в условиях неопределенности. Изд-во МЭИ (СССР); Техника (НРБ), 1989. 224 с.

22. Вязгин В.А., Федоров В.В. Математические методы автоматизированного проектирования. -М.: Высшая школа, 1989.

23. Гаврилова Т.А. Хорошевский В.Ф. Базы знаний интеллектуальных систем. М.: Радио и связь, 1992.

24. Горелов И.Н. Разговор с компьютером: Психолингвистический аспектпроблемы. М.: Наука, 1987. - 256 с.

25. Грис Д. Наука программирования. М.: Мир, 1984. - 416 с.

26. Давыдов Э.Г. Исследование операций. М.: Высшая школа, 1990. - 380 с.

27. Демкин В.П., Можаева Г.В. Технологии дистанционного обучения. Томск: Издательство Томского университета, 2003. 106 с.

28. Джонс Дж.К. Методы проектирования. М.: Мир, 1986. - 326с.

29. Дзюбенко А.А. Новые информационные технологии в образовании. -М.: 2000. 104 с.

30. Дитрих Я. Проектирование и конструирование: системный подход. / Пер. спольск. -М.:Мир, 1981.-456 с.

31. Земляков И.Ю. Защищенная система удаленного контроля знаний // Современные средства и системы автоматизации. Томск, 2002. С. 4749.32.3уховицкий С.И., Радчик И.А. Математические методы сетевого планирования. М.: Наука 1965. - 295 с.

32. Ивашенцев В.А. Автоматизированное проектирование вычислительных систем. М.: Изд-во МАИ, 1991.

33. Ивин А.А. Основания логики оценок. -М.: МГУ, 1970.

34. Ивин А.А. Элементарная логика. -М.: Дидакт, 1994.

35. Ивлев. Ю.В. Логика. М.: МГУ, 1992.

36. Ильин Г. Качество дополнительного профессионального образования. -М.: Общество «Знание», 2000 г.

37. Имитационное моделирование. / Черненький В.М., кн.9 Разработка САПР.--М.: Высшая школа, 1990. 110 с.

38. Имон У., Фридман Л. Методология экспертной оценки проектных решений для систем с базами данных. / Пер. с англ. М.: Финансы и статистика, 1986. - 280 с.

39. Иорден. Структурное программирование и конструирование программ. -М.: Мир. 1979.41 .Калинников П. Бумажные технологии или электронное издание? // Высшее образование в России, 1999 №1.

40. Кастеллани К. Автоматизация решения задач управления. / Пер. с англ. -М.: Мир, 1982.-472 с.

41. Киндлер Е. Языки моделирования. -М.: Энергоатомиздат, 1985.

42. Клейнрок Л. Теория массового обслуживания. — М.: Машиностроение, 1979.-432 с.

43. Ковальски Р. Логика в решении проблем. М.: Наука, 1990 - 280 с.

44. Корнилова Т.В., Тихомиров O.K. Принятие интеллектуальных решений в диалоге с компьютером. М.: Изд-во МГУ, 1990. - 192 с.

45. Колмогорова Е.В. Разработка электронных учебных пособий для дистанционного обучения // Открытое и дистанционное образование, 2004. №1(13). С. 30-34.

46. Коутс Р., Влеймник И. Интерфейс «человек-компьютер». М.: Мир, 1990.-501 с.

47. Краснощеков П.С., Петров А.А., Федоров В.В. Информатика и проектирование. М.: Знание, Сер. «Математика, кибернетика», 1986, №10.

48. Кузьмик П.К., Маничев В.Б. Автоматизация функционального проектирования. М.: Высшая школа, 1986.

49. Кузьмин Н. Повышение квалификации на основе дистанционного обучения // Высшее образование в России. 2004. №5. С. 166-167.

50. Левитес Д.Г. Практика обучения: современные технологии. М.: Воронеж, 1998.-С.115-116.

51. Лэнгсам И., Огенстайн М., Тененбаум А. Структуры данных для персональных ЭВМ. М.:Мир, 1989.

52. Лихтциндер Б.Я. Направленное диагностирование по критерию максимальной информационной производительности. // Тезисы республиканской НТК, Житомир, 1991г.

53. Лихтциндер Б.Я. Применение методов направленного диагностирования при машинном контроле знаний. // Материалы НМК ПИИРС, Самара, 1993г.

54. Лужников Ю.К. Системы автоматизации проектирования. -М.: Знание, 1984.

55. Любарский Ю.Я. Интеллектуальные информационные системы. М.: Наука, 1990.

56. Ляудис В.Я. Инновационное обучение и наука. М., 1998. С. 8- 14.

57. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования (SADT) / Пер. с англ. М.: МетаТехнология, 1993. -240 с.

58. Машбиц Е.И. Психолого-педагогические проблемы компьютеризации обучения. -М.: Педагогика, 1988. 192 с.

59. Мейер Б., Бодуэн К. Методы программирования. Т. 1, 2. М.: Мир, 1982.

60. Методы и средства моделирования вычислительных устройств и сетей. / Афанасьев А.Н., Шишкин В.В., Учебное пособие. Ульяновск: УлГТУ, 1996.-87 с.

61. Мильнер Б.З. Управление знаниями. М.: ИНФРА-М, 2003. - 178 с.

62. Михайлишин А.Ю., Захаров В.Ю., Попов Ю.С., Рубин Д.А., Сталковская И.Н. К вопросу о структуре и составе электронного учебно-методического комплекса // Открытое и дистанционное образование, 2003. №3-4. С. 3-12.

63. Морев И.А. Образовательные информационные технологии. 4.1: Обучение: Учебное пособие. Владивосток: Издательство Дальневосточного Университета, 2004. 158 с.

64. Морев И.А. Образовательные информационные технологии. 4.2: Педагогические измерения: Учебное пособие. Владивосток: Издательство Дальневосточного Университета, 2004. 174 с.

65. Морев И.А. Образовательные информационные технологии. Ч.З Дистанционное обучение: Учебное пособие. Владивосток: Издательство Дальневосточного Университета, 2004. 150 с.

66. Морев И.А. Проблемы компьютерного представления образовательной информации. // Вестник Удмуртского университета, 2001 №10-11.

67. Нейлор К. Как построить свою экспертную систему. М.: Энергоатомиздат, 1991. - 286 с.

68. Нестеров А.В., Тимченко В.В., Трапицын С.Ю. Информационные педагогические технологии: Учебное пособие. СПб: Книжный дом, 2003.-340 с.

69. Новиков Д.А., Глотова Н.П. Модели и механизмы управления образовательными сетями и комплексами. М.: Институт управления образованием РАО, 2004. - 142 с.

70. Новиков Д.А. Модели и механизмы управления развитием региональных образовательных систем. М.: ИЛУ РАН, 2001. - 83 с.

71. Норенков И. П., Кузьмик П. К. Информационная поддержка наукоемких изделий. CALS-технологии. -М.: "Издательство МГТУ им. Н. Э. Баумана", 2002. 320 с.

72. Норенков И. П. Основы автоматизированного проектирования. 2-е издание. — М.: "Издательство МГТУ им. Н. Э. Баумана", 2002. 336 с.75.0суга С. Обработка знаний. М.: Мир, 1989. - 292 с.76.0суга С., Саэка Ю. Приобретение знаний. -М.: Мир, 1990.

73. Подбельский В.В. Язык С++: Учеб. Пособие. - М.: Финансы и статистика, 1995.-560с.:ил.

74. Полат Е.С.Теория и практика дистанционного обучения. М.: ACADEMIA, 2004. - 414 с.

75. Попов З.В. Ощение с ЭВМ на естественном языке. М.: Наука, 1982.

76. Попов Э.В. Экспертные системы: Решение неформальных задач в диалоге с ЭВМ. М.: Наука, 1987. - 288 с.

77. Прохоров А.Ф. Конструктор и ЭВМ. М.: Машиностроение, 1987. - 72 с.

78. Ричмонд. У.К. Учителя и машины. Введение в теорию и практику программного обучения. М.: Мир, 1968. - 277 с.

79. Роберт И.В. Современные информационные технологии в образовании: дидактические проблемы; перспективы использования. М.: Школа-Пресс, 1994.-205 с.

80. Роджерсон Д. Основы СОМ. 2-е издание, - М.: Издательско-торговый дом "Русская Редакция", 2000г. - 228 с.

81. Рузавин Г.И. Логика и аргументация. М.: ЮНИТИ, 1997. - 349 с.

82. Рубашкин В.Ш. Представление и анализ смысла в интеллектуальных информационных системах. — М.: Наука, 1989. 192 с.

83. Руководство пользователя. Обучающая программа. «1С: РЕПЕТИТОР. ФИЗИКА»

84. Руководство пользователя. Обучающая программа. «Система автоматизированного контроля знаний».

85. Руководство пользователя. Обучающая программа. «Химия: Общая химия».

86. Савельев А. Инновационное высшее образование. // Высшее образование, №6, 2001. С. 42-46.

87. Системы автоматизированного проектирования. / Под ред. Алана Дж. Пер. с англ. -М.: Наука, 1985. 376 с.

88. Смальян P.M. Теория формальных систем. — М.: Наука, 1981.

89. Страуструп Б. Язык программирования С++, спец. изд. / Пер. с англ. -М.: СПб.: «Издательство БИНОМ» «Невский Диалект», 2001 г. - 1099 е., ил.

90. Таненбаум Э.С., Ван Стеен М. Распределенные системы. Принципы и парадигмы. М.: Издательский дом " Питер ", 2003г. - 880 с.

91. Таунсенд К., Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ. М.: Финансы и статистика, 1990. - 320 с.

92. Технология системного моделирования. М.: Машиностроение; Берлин: Техник, 1988.

93. Усков B.JL, Шереметов Л.Б. Информационные технологии в образовании. М.: «Информационные технологии», «Новые технологии», 2001.

94. Уэно X., Исидзука М. Представление и использование знаний // М, Мир, 1989.

95. Фейс Р. Модальная логика. М.: Наука, 1974. - 520 с.

96. Филатов O.K. Информатизация технологий обучения в высшей школе. М., 2001.-283 с.

97. Хелд М., Карп P.M. Применение динамического программирования к задачам упорядочивания. // Киб. сб. Ст. сер. 1964. Вып. 9.-С. 202-212.

98. Хилл П. Наука и искусство проектирования. / Пер. с англ. М.: Мир, 1973.

99. Шоу А. Логическое проектирование операционных систем. — М.: Мир, 1981.

100. Щенников С.А. Открытое дистанционное образование. М.: Наука, 2002. - 526 с.

101. Экспертные системы: состояния и перспективы. М.: Наука, 1989.-150 с.

102. Энкарначчо Ж., Шлехтендаль Э. Автоматизированное проектирование. Основные понятия и архитектура систем. М.: Мир, 1985.-264 с.

103. Davis R. and Lenat D. Knowledge-based Systems in Artificial Intelligence//McGraw-Hill, 1982.

104. Eddon, Guy, and Henry Eddon. Inside Distributed COM. Redmond, Wash.: Microsoft Press, 1998.

105. Fowler, Martin, with Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Reading, Mass.: Addison Wesley Longman, 1997.

106. Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Mass.: Addison-Wesley, 1995.

107. Gordon J. Win32 Exception handling for assembler programmers. 2002r.// http://www.iorgon.freeserve.co.uk/ExceptFrame.htm

108. Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Upper Saddle River, N.J.: Prentice Hall PTR, 1998.

109. Meyer, Bertrand. Object-Oriented Software Construction.2nd ed. Upper Saddle River, N.J.: Prentice Hall PTR, 1997.

110. Minsky M. A Framework for Representing Knowledge in Psychology of Computer Vision // P.H. Winston (ed.), McGraw-Hill, 1975.

111. Pietrek M. A Crash Course on the Depths of Win32 Structured Exception Handling Microsoft Systems Journal. January, 1997. // http://www.microsoft.com/msi/0197/exception/exception.aspx

112. Thai, Thuan L. Learning DCOM. Cambridge, Mass.: O'Reilly & Associates, 1999.

113. Ueno H. An end-user oriented language to develop knowledge-based expert systems // Proc. COMPCON FALL 83, 1983.

114. Brockschmidt K. Inside OLE. 2nd ed. Redmond, WA, USA: Microsoft Press, 1995. 1194 c.

115. Halstead M.H. Machineindepended computer programming. Spartan books, 1962, P. 143-150.