Содержание к диссертации
Введение
Глава 1. Задачи автоматического процесса обучения с использованием современных информационных систем 9
1.1. Роль обучающих программ в системе дистанционного образования, их основные особенности и характеристики 9
1.2. Анализ ситуации сложившейся в системе удаленного образования, использующего автоматизированные обучающие системы 15
1.3. Постановка задачи 26
1.4. Выводы 35
Глава 2. Описание компонентов автоматизированных обучающих систем 36
2.1. Интерфейсы взаимодействия компонентов 36
2.2. Структура взаимодействия компонентов АОС и функционирование ядра обучающего комплекса 43
2.3. Функциональное строение компонента «Представление знаний»... 50
2.4. Функциональное строение компонента «База знаний» 52
2.5. Функциональное строение компонента «Контроль знаний» 58
2.6. Функциональное строение компонента «Статистика» 60
2.7. Модель оценки эффективности компонентных АОС 64
2.8. Выводы 69
Глава 3. Программная реализация структуры компонентов АОС 70
3.1. Главные требования к компонентам 70
3.2. Использование COM (Component Object Model) для реализации структуры компонентов : 73
3.3. Предоставление интерфейса компонентом 77
3.4. Включение и агрегирование 84
3.5. Реализация компонентов в исполняемых файлах и взаимодействие удаленных компонентов 87
3.6. Обеспечение надежности АОС 98
3.7. Выводы 105
Заключение 106
Литература
- Анализ ситуации сложившейся в системе удаленного образования, использующего автоматизированные обучающие системы
- Структура взаимодействия компонентов АОС и функционирование ядра обучающего комплекса
- Функциональное строение компонента «База знаний»
- Использование COM (Component Object Model) для реализации структуры компонентов
Введение к работе
Актуальность исследования.
Научный прогресс характеризуется интенсивным накоплением знаний и стремительным увеличением объема информации. Происходит стремительный процесс компьютеризации общества: за последний десяток лет компьютеры перешли из области «у папы в институте» в область их домашнего и повсеместного применения. В компьютерных классах большинства школ стоят достаточно мощные мультимедийные станции, не говоря уже о высших учебных заведениях. В этих условиях всё большее значение приобретает поиск новых методов и средств повышения эффективности процесса обучения. Одним из наиболее перспективных путей, является путь использования автоматизированных обучающих систем (АОС), которые базируются на современной вычислительной технике и составляют основу компьютерных технологий обучения. В настоящее время, как в нашей стране, так и за рубежом создано и функционирует большое количество АОС по различным дисциплинам. Многие абитуриенты помимо чтения методической литературы, рекомендованной ВУЗом для поступления, приобретают АОС содержащие не только подготовительную литературу, но и возможность предварительной проверки уровня знаний. Множество крупных издателей программного обеспечения (ПО) в России, видя такую заинтересованность со стороны покупателей, также организовывают свои отделы по созданию АОС в качестве «домашних репетиторов», включающих в себя как стандартную школьную программу, так и расширенную программу для поступления в специализированные ВУЗы.
Однако, разработка АОС достаточно сложный и ресурсоемкий процесс. Помимо того, что ПО содержит в себе множество разносторонних технологий, таких как: хранение и представление знаний, работа с различными графическими форматами и вывод информации, защита данных и ведение статистики; одновременно с этим остро встает проблема наполнения АОС и разработка обучающего процесса. Концентрировать усилия в обоих направлениях зачастую бывает невозможно из-за нехватки кадров, времени и материальных средств. Поэтому, задача минимизации времени и материальных средств на разработку программного обеспечения АОС как никогда актуальна и востребована на современном рынке.
Цели и задачи исследования.
Основной целью диссертации является создание гибкой среды разработки, позволяющей за минимальное время и с минимальными затратами создать необходимое программное обеспечение для АОС. Достижение этой цели обеспечивается практическим решением следующих взаимосвязанных задач: анализ существующих АОС, выявление задач стоящих перед ними, исследование основных технологий, применяемых при разработке АОС; построение модели-класса взаимодействия элементов АОС, пригодной для решения всех задач стоящих перед современными АОС; разработка системы интерфейсов взаимодействия компонентов АОС; разработка инструментальных средств, реализующих полученную модель.
Практически полезные эффекты, достижение которых ожидается в случае успешного решения задачи исследований, заключаются в следующем: сокращение времени разработки за счет использования компонент от сторонних разработчиков и простоты их встраивания в свою систему, а так же благодаря четкой структуре интерфейсов; повышение надежности системы за счет использования уже готовых и оттестированных компонент и применения метода структурированной обработки исключений при возникновении критических ситуаций в компонентах.
Объект исследования.
Объектом исследования является гибкая среда разработки программного обеспечения для АОС.
Предмет исследований.
Исследования и разработка методов и средств минимизации времени и материальных ресурсов на разработку АОС определили предмет исследований диссертационной работы.
Методологическая и теоретическая основы.
Исследования базируются на методах математического моделирования и имитационного моделирования, а также теории автоматизированного проектирования, методах системного анализа, метода обобщений и метода экспертных оценок.
Научная новизна.
На научную новизну претендуют: принцип организации и разработки АОС, основанный на компонентных системах программного обеспечения; структура интерфейсов взаимодействия компонентов АОС, скрывающая детали внутренней реализации компонентов; способ повышения надежности АОС за счет механизма структурированной обработки исключений.
Практическая значимость исследования.
Практическую ценность работы составляет как разработка функционирования ядра компонентной АОС, так и система интерфейсов для связи компонентов. Все это обеспечивает реализацию базовой структуры компонентной АОС, готовой к расширению и дополнению для дальнейшего практического применения. Результаты исследования, как в полном объеме, так и р частном (использование отдельных компонент) могут применять все разработчики АОС практически на любой стадии проектирования и создания.
В первой главе рассмотрены основные функции характерные для современных АОС. Произведен анализ существующих АОС, их основных характеристик и особенностей с позиций их соответствия сформулированным требованиям. Произведена выборка трех основных представителей на рынке современных АОС и перечислены их параметры и используемые технологии. Определяются область, объект, направление и предмет исследования. Формулируется задача исследований и производится выбор подхода к ее решению. Приведены формализованное описание модели компонентной АОС, а также определены те ее свойства, которые могут помочь в решении поставленной задачи. Вводится понятие ортогональных компонентов и понятие интерфейса. По результатам анализа сформулированы выводы.
Во второй главе вырабатывается подход к построению модели компонентной АОС, как системы ортогональных компонентов связанных друг с другом посредством интерфейсов. Дается описание интерфейсов взаимодействия компонентов, основные требования, которым они должны удовлетворять, и свойства, которыми они должны обладать. Объясняется необходимость использования интерфейсов в компонентных системах. Дается описание структуры взаимодействия компонентов АОС, его ядра и задачи на него возложенные. Помимо этого, приведено функциональное строение основных компонентов АОС, задачи которые они должны решать и интерфейсы посредством которых организована их связь с остальными компонентами системы.
В третьей главе описана реализация модели компонентной АОС. Сформулированы основные требования к компонентам системы. Предлагается технология, удовлетворяющая этим требованиям, и обосновывается выбор этой технологии. Констатируются основные требования к системе в целом, обосновываются архитектурные решения. Описываются основные правила при работе с данной технологией и их расширение для использования в АОС. Показаны основные методы для создания удаленных компонентов и возможности системы для их реализации. Предлагается технология обеспечения надежности компонентных АОС при возникновении критических ошибок в любом из ее компонентов.
В заключении констатируется, что поставленная задача исследований, предполагающая повышение производительности разработки ПО для АОС путем создания гибкой среды разработки, решена. Перечисляются эффекты, достигнутые в результате решения задачи исследований, производится анализ с наиболее распространенными АОС, выявляются качественные отличия от них разработанной модели, выраженные в различных подходах к проектированию. Очерчены перспективы дальнейших исследований в рамках предметной области с целью повышения эффективности проектирования подобных систем.
В приложениях представлен перечень основных интерфейсов предоставляемых компонентами АОС. Приводится введение в язык описания интерфейсов IDL и примеры использования компилятора MIDL.
Анализ ситуации сложившейся в системе удаленного образования, использующего автоматизированные обучающие системы
Для анализа ситуации рассмотрим два продукта успешно развивающихся на рынке обучающих программ и один некоммерческий продукт, разработанный Современным Гуманитарным Университетом г. Москвы. Выборка произведена случайным образом из более чем двадцати различных обучающих программных комплексов. Рассматривать их все не имеет смысла, так как представленная ниже информация укажет все необходимые различия и сходства.
Первый продукт распространяет компания «МАГНАМЕДИЯ», являющаяся членом ассоциации разработчиков, издателей и распространителей программного обеспечения «РУССКИЙ ЩИТ». Обучающий продукт принадлежит серии «TeachPro» и разработан "Algorithm - Service" CJSC и Multimedia Technologies and Distance Learning Ltd в 2000-м году. Рассмотрению подвергалась АОС по теме «Химия: Общая химия». По словам разработчиков для успешного освоения представленного материала в системе предусмотрено несколько режимов обучения [89]: в режиме ФИЛЬМ осуществляется непрерывная демонстрация приемов работы с пояснениями лектора, в режиме ШАГ урок разбивается на некоторое количество частей или шагов. Каждый шаг определяет некоторый фрагмент материала, о котором говорит лектор. После прослушивания одного шага лекция прерывается, и обучаемый может по выбору начать слушать следующий шаг либо еще раз прослушать предыдущий. в режиме КОНТРОЛЬ пользователь может оценить накопленные знания. При этом необходимо самостоятельно ответить на вопросы, которые поставит перед обучаемым лектор.
Весь учебный курс разделен на лекции (или главы). Лекции делятся на уроки. Сама оболочка представляет собой панель инструментов, напоминающую панель видеомагнитофона, и графическую область, на которой и выводится необходимая информация. Урок дается ученику как видеолекция, сочетающая в себе необходимую текстовую информацию, плавно возникающую по мере надобности, анимированные картинки, поясняющие текст, и закадровый голос. Урок в любой момент можно остановить, переместится назад или вперед. Контроль знаний происходит в режиме теста, где на поставленный вопрос предоставляется несколько вариантов ответа. Из статистической информации оболочка предоставляет время работы с системой в течение одного сеанса.
Следующая АОС, распространяется фирмой «1С», под названием «1С: РЕПЕТИТОР. ФИЗИКА» (Версия 1.5) Как говорят сами разработчики: «предлагаемое изложение школьного курса физики является первой в России попыткой создания учебного пособия, использующего уникальные возможности современного мультимедийного ПК и охватывающего все разделы физики 9-11 классов» [87]. Стоит учесть, что это пособие было выпущено в 1998 году. При подготовке этого пособия учебный материал был специально подобран в соответствии с программой по физике для общеобразовательных школ. Для удобства пользователя названия тем, вошедших в данное пособие, практически совпадают с соответствующими параграфами учебников. И проработка пособия очень похожа на повторение всего школьного курса физики на уровне требований общеобразовательной школы. Некоторое смещение акцентов в изложении материала по сравнению с базовым курсом связано с желанием авторов представить материал максимально сжато, но без потери основных идей.
Структура пособия такова. Пользователь может начать работу над одним из шестидесяти конкретных вопросов по пяти основным разделам школьной физики: механика, молекулярная физика, электричество и магнетизм, электромагнитные волны и оптика, теория относительности и квантовая физика. В каждом вопросе пользователь получает: текст с формулами, содержащий объяснение темы (иногда минимально необходимое, для более сложных вопросов - развернутое); рисунки и графики, относящиеся к теме и включающие элементы анимации, а также обязательный элемент взаимодействия с пользователем, позволяющий во многих случаях менять параметры в формулах для физических закономерностей и немедленно отслеживать результат этих изменений на экране; биографические сведения о некоторых ученых, внесших важный вклад в развитие физики; тесты на усвоение материала темы (при желании предоставляется возможность увидеть полное правильное решение первого теста; второй тест дает только правильный ответ); задачи по теме (первая задача приводится с полным решением, для второй - дается только ответ); возможность вызова в любой момент справок, касающихся системы единиц, фундаментальных физических постоянных, таблиц численных значений ряда физических величин; возможность вызова "шпаргалки", содержащей основные формулы физики; возможность вызова справочника основных формул школьного курса математики; возможность вызова калькулятора.
Структура взаимодействия компонентов АОС и функционирование ядра обучающего комплекса
Как было представлено в первой главе, взаимодействие компонентов происходит посредством унифицированных интерфейсов и механизма передачи сообщений ядру. Каждый компонент представляет собой замкнутую систему, отвечающую за функционирование какой-либо части обучающего комплекса. Взаимодействие компонентов друг с другом напрямую запрещено, это возможно лишь при помощи ядра системы. Однако некоторые составляющие компонентов, могут взаимодействовать друг с другом без участия ядра. Рассмотрим общую схему взаимодействия элементов компонента «Представление знаний».
Как видно из рисунка элементы управления главного окна приложения, могут взаимодействовать друг с другом посредством обычных методов операционной системы. Более того, двустороннее общение пользователя с обучающим комплексом происходит именно внутри компонента. Тем самым обеспечивается достаточно высокий уровень их взаимодействия и не происходит скатывания до уровня «мелких» частей, подобных «кнопке» или «статическому тексту». Тем не менее, компоненты АОС рассмотренные в первой главе разбиты на подкомпоненты, отвечающие за определенную логическую часть работы родительского компонента. Например, на схеме приведен подкомпонент «Вывод статистики», и, скорее всего, его разработку будет вести та организация, которая разрабатывала и сам компонент «Статистика». Разработчик компонента «Представление знаний» просто реализует методы для встраивания вышеуказанного подкомпонента [15, 28].
При загрузке компонента в память, он регистрирует свои интерфейсы в ядре. Это позволяет абстрагироваться клиенту от компонента и работать только с интерфейсами. Клиент посылает запрос, на выполнение какой либо операции ядру (получает интерфейс для выполнения этой операции) и производит необходимые действия только при помощи интерфейса. Какой именно компонент будет обрабатывать его запросы, и каким образом клиенту знать необязательно. Такой подход позволяет разбивать компоненты на подкомпоненты без оказания существенного влияния на структуру клиентов работающих с ними. Таким образом, одной из основополагающих задач ядра, является маршрутизация запросов на получение интерфейсов. Очевидно, что один компонент можно подменить другим, таким образом, что клиент, работающий с ними, не увидит разницы. Более того, структура самих компонентов может быть существенно изменена. Допустим, у нас имеется один компонент, отвечающий за несколько операций одновременно. Каждая операция соотнесена с внешним интерфейсом. Можно создать несколько новых компонент, для каждой операции в отдельности. Эти компоненты будут предоставлять только те интерфейсы, которые соответствуют их операциям. Рис. 2-2. Взаимодействие компонентов посредством ядра. Рассмотрим рисунок 2-2. Левая часть его отображает ситуацию, когда несколько операций заключены в одном «Компоненте №1». Он предоставляет для работы клиенту два интерфейса IX и IY. В правой части рисунка, новый разработчик создает уже два компонента: «Компонент №2» и «Компонент №3», работа которых вместе, эквивалентна работе одного «Компонента №1». Каждый из них предоставляет свой интерфейс, соответственно IX и IY, эквивалентный базовому. Как видно из рисунка, клиент подобной подмены не заметит, так как интерфейсы остались прежними и схема работы с ними не изменилась, а ядро скрыло все внутренние изменения в системе. И так, работа клиента с компонентом посредством интерфейсов позволяет абстрагироваться от структуры компонента, а запрос на получение интерфейса через ядро системы позволяет клиенту, вообще абстрагироваться от компонента. Тем самым достигается необходимая независимость компонентов АОС.
Механизм передачи сообщений, является не менее важным, для взаимодействия компонентов, что и механизм интерфейсов. Именно он позволяет АОС превратиться из простого набора компонент, в динамическую систему. Помимо этого вводится многозадачность уже на уровне компонентов обучающей системы. Достигается это благодаря тому, что сообщения могут выполняться не синхронизированно с остальными компонентами, то есть достаточно послать сообщение на выполнение какого либо действия и можно продолжать работу, не дожидаясь результатов выполнения запроса. Реализуется подобная механика посредством очереди сообщений, уникальной для каждого компонента. В каждый момент времени, сообщения перемещаются из очереди в обработчик сообщений компонента. Благодаря этому, одним из отличительных качеств сообщений, является возможность их игнорирования компонентом. Следовательно, ядру не надо производить процедуру опроса компонентов на предмет поддержки какого-то сообщения, в случае отсутствия поддержки, сообщение просто будет игнорироваться. Более того, обработку сообщений компонент берет полностью на себя, то есть в случае предоставления ему неверных данных, таких как идентификатор компонента, его версия или адресат, ошибочная ситуация будет обрабатываться на его стороне, тем самым избавляя ядро или клиента от дополнительных проверок на совместимость.
Функциональное строение компонента «База знаний»
В большинстве случаев, преподнести изучаемую информацию не представляет большого труда, существует множество программных продуктов, позволяющих представлять знания в любом виде: текстовом, графическом, в виде анимационных файлов, диаграмм, графиков и многих других. К сожалению, проблема контроля знаний не решается так просто. В большинстве учебных заведений определением уровня знаний все еще занимаются преподаватели, хотя большинство информации преподносится в электронном виде. Обычно проверке подвергаются тексты - ответы на тесты и контрольные вопросы. Такая ситуация сложилась из-за сложности создания искусственного интеллекта, занимающегося обработкой пришедших ответов.
В основном, контроль знаний - это вопросно-ответная модель, представляющая собой постановку вопроса и обработку ответа. Рассмотрим этот процесс подробно. Вопрос генерируется компьютером на основе внесенной в него базы знаний (следует учесть, что эта база знаний должна удовлетворять следующим требованиям: полнота, непротиворечивость и связность). Выглядит это следующим образом: программа выбирает по определенному правилу или случайно шаблон вопроса, состоящий из статического набора слов и некоторых переменных (в которые заносятся данные), затем рассматривает шаблон и определяет какие данные необходимо выбрать из базы, чтобы сгенерировать вопрос. После, основываясь на полученной информации, программа случайным образом или по некоторому правилу, считывает из базы знаний данные, и подставляет их вместо переменных. Ответ может быть предоставлен в нескольких формах. В случае тестового контроля, программа, основываясь на шаблоне ответа, приложенного к вопросу, генерирует правильный ответ (подобно генерации вопроса). И выбрав случайным образом несколько других данных, генерирует неправильные ответы [55]. Функции компонента «Контроль знаний» разделены на три группы, каждая из которых отвечает за свои задачи: функции для работы с базой знаний, позволяют получать эксперту информацию о структуре базы, считывать как отдельные значения из структуры отдельного элемента, так и всю информацию об элементе; функции для работы с шаблонами, следует определить понятие шаблона в данном контексте: «шаблоном строки называется произвольный массив символов, на базе которого возможно построение осмысленных вопросов и ответов с использованием информации из базы знаний». функции для работы со строками, которые позволяют определить число слов в предложении, указать какие символы являются разделителями между словами, а также получение любого слова по его индексу или нахождение слова в предложении, включена реализация алгоритмов сопоставления двух строк на идентичность и т.п. Таким образом, компонент «Контроль знаний» основывающийся на вопросно-ответной модели предстает в следующем виде: \ IGenerateQuestion IStoreKnowledge
Пожалуй, это единственный компонент, деятельность которого так тесно зависит от остальных компонентов. Основные задачи, которые должен выполнять этот компонент, приведены в первой главе. Перечислять их заново не имеет смысла, поэтому сразу приведем его внутреннюю структуру и необходимые интерфейсы.
Как видно из рисунка практически все подкомпоненты взаимодействуют с внешним миром посредством подкомпонента «Безопасность». Задача этого компонента - определение прав доступа текущей сессии и блокировка запросов недоступных для данной сессии [31]. В основном этот компонент является почти прозрачной прослойкой, между клиентом и данными компонента, однако возможно добавление в него какого-либо метода шифрования данных статистики во избежание утечек или изменения важной информации (оценок, времени проведенного за работой и др.). Будем считать, что интерфейсы, входящие в этот подкомпонент и выходящие из него, идентичны, единственное различие - во внутренних интерфейсах возможно отсутствие информации о правах доступа для клиента, пославшего запрос. Единственный подкомпонент не защищенный «Безопасностью» - это подкомпонент «Статистика работы АОС». Генерируемые им сведения содержат скорее административную информацию работе компонента в целом: происходящих в нем важных событиях, возникновении ошибок и т.п. В основном работа с ним возложена на ядро системы, однако и другие компоненты могут заносить дополнительную информацию (см. описание интерфейса ISW). Подкомпонент «Учетные записи» производит создание, удаление или изменение параметров учетных записей пользователей. В его обязанности так же входит настройка прав и привилегий пользователя. В идеальном случае эти данные шифруются посредством «Безопасности» и сохраняются в «Базе знаний». При входе пользователя в программу, по его личным данным определяется его учетная запись и заводится текущая сессия. Она содержит в себе статистику прошлой работы пользователя, текущей его работы, а также права и привилегии. Подкомпонент «Сессия работы с АОС» отвечает за статистическую информацию о пользователе, описанную выше. По завершении сеанса работы, все заносится в базу знаний в учетную запись пользователя, для которого была открыта сессия. Как было сказано выше, текущая сессия хранит в себе права пользователя, именно по ним определяется доступ этого пользователя к тем или иным данным компонента «Статистика». Кроме того, другие компоненты тоже могут использовать данные текущей сессии для вывода или сокрытия некоторой информации.
Использование COM (Component Object Model) для реализации структуры компонентов
Клиент всегда взаимодействует с компонентом через некоторый интерфейс. Для запроса интерфейса предложен специальный интерфейс lUnknown. Определение lUnknown, содержащееся в заголовочном файле UNKNWN.H, входящим в состав Win32 SDK, выглядит так [84]: interface lUnknown { virtual HRESULT stdcall QueryInterface(const IID& iid, void ppv) = 0; virtual ULONG _stdcall AddRef() = 0; virtual ULONG stdcall Release() = 0; };
В lUnknown имеется функция с именем Querylnterface. Клиент вызывает ее, чтобы определить, поддерживает ли компонент некоторый интерфейс. AddRef и Release, которые предоставляют способ управления временем жизни интерфейса.
Все интерфейсы компонентов АОС должны наследовать lUnknown. Таким образом, если у клиента имеется указатель на lUnknown, то он может запросить через него другие интерфейсы.
Поскольку все интерфейсы СОМ наследуют lUnknown, в каждом интерфейсе есть функции Querylnterface, AddRef и Release - три первые функции в vtbl9 (рис. 3-4). Благодаря этому все интерфейсы СОМ можно полиморфно трактовать как интерфейсы lUnknown. Если в первых трех элементах vtbl интерфейса не содержатся указатели на три перечисленные функции, то это не интерфейс СОМ. Так как все интерфейсы наследуют lUnknown, то все они поддерживают Querylnterface. Таким образом, любой интерфейс можно использовать для получения всех остальных интерфейсов, поддерживаемых компонентом. Поскольку все указатели интерфейсов являются также и указателями на lUnknown, то клиенту не требуется хранить отдельный указатель на компонент. Клиент работает только с указателями интерфейсов [108].
Querylnterface возвращает указатель на интерфейс, если компонент его поддерживает; в противном случае возвращается код ошибки (тогда клиент может запросить указатель на другой интерфейс или аккуратно выгрузить компонент). ф У Querylnterface два параметра:
virtual HRESULT stdcall QueryInterface(const IID& iid, void ppv);
Первый параметр — идентификатор интерфейса, так называемая IID-структура10. Второй параметр - адрес, по которому Querylnterface помещает указатель на искомый интерфейс. Querylnterface возвращает HRESULT -просто 32-разрядный код результата, записанный в определенном формате. Querylnterface может возвратить либо S_OK, либо E_NOINTERFACE. Клиент не должен прямо сравнивать возвращаемое Querylnterface значение с этими константами; для проверки надо использовать макросы SUCCEEDED или FAILED.
Рассмотрим, как используется, а затем - как реализуется Querylnterface.
Предположим, что есть указатель на IUnknown, pi. Чтобы определить, можно ли использовать некоторый другой интерфейс, нужно вызвать Querylnterface, передавая ей идентификатор нужного интерфейса. Если Querylnterface отработала успешно, можно пользоваться указателем: void foo(IUnknown pi) { II Определить указатель на интерфейс IX pIX = NULL; // Запросить интерфейс IX HRESULT hr = pI- QueryInterface(IID_IX, (void )&pIX); II Проверить значение результата if(SUCCEEDED(hr)) { // Использовать интерфейс PIX- Fx(); } } В этом фрагменте кода запрашивается у pi интерфейс, идентифицируемый с помощью IID_IX. Определение IID_IX содержится в заголовочном файле, предоставляемом компонентом. Нужно обратить внимание, что pIX устанавливается в NULL перед вызовом Querylnterface. Это пример программирования с защитой от ошибок. Предполагается, что для неудачного запроса Querylnterface должна устанавливать возвращаемый указатель в NULL. Однако, поскольку Querylnterface реализуется программистом компонента, в некоторых реализациях это наверняка не будет сделано. Для безопасности следует установить указатель в NULL самостоятельно.
Реализация Querylnterface. Все, что нужно сделать, - это вернуть указатель интерфейса, соответствующего данному IID. Если интерфейс поддерживается, то функция возвращает S_OK и указатель. В противном
