CC BY
11
МОДЕЛИ, ИНСТРУМЕНТАРИЙ И ТЕХНОЛОГИИ
УДК 681.32 В. Н. НЕГОДА
О КОНТРОЛЕ ДЕЯТЕЛЬНОСТИ ОБУЧАЕМОГО В УЧЕБНОЙ САПР МИКРОПРОЦЕССОРНЫХ СИСТЕМ
В статье рассматриваются вопросы контроля деятельности в учебных САПР. Строятся общие модели объектов и процессов контроля деятельности, ориентированные на управление деятельностью с помощью сценариев. Рассматриваются вопросы формирования сценариев управляемой деятельности в среде учебной САПР микропроцессорных систем.
ВВЕДЕНИЕ
В соответствии с изложенной в работе [I] концепцией построения учебно-исследовательской системы функционально-логического моделирования (УИС ФЛМ) как основы учебной САПР микропроцессорных систем (МПС), в системе моделирования должен поддерживаться контроль деятельности обучаемого. Сложность организации контроля обусловлена несколькими обстоятельствами. Во-первых, во многих случаях существует много допустимых решений одной проектной задачи. Во-вторых, успешное решение часто может быть достигнуто неэффективными методами, что требует контроля не только конечных результатов, но и процесса их получения. В-третьих, для учебных САПР характерно значительное разнообразие видов проектной деятельности, для контроля которых приходится применять различные подходы. В-четвертых, механизмы контроля учебно-проектной деятельности исследованы мало.
Рассмотрим основные модели объектов и процессов, лежащих в основе управления контролируемой деятельности, применительно к задаче построения учебно-исследовательской САПР МПС. В ходе рассмотрения будем использовать следующие соглашения об именовании объектов и моделей и их параметров:
• ш. .п - подмножество натурального ряда N, лежащее в интервале [п,ш];
• и (А) = {1. . card. (А) } - подмножество натурального ряда, с помощью которого можно занумеровать элементы множества А, задавая его перечислением;
• е (А) - элемент множества А;
• dName - описание объекта, поименованного в рассуждениях именем Name; отделение описания от самого объекта необходимо для того, чтобы можно было обсуждать различные средства описания одних и тех же объектов.
ОБЩИЕ МОДЕЛИ КОНТРОЛИРУЕМОЙ ДЕЯТЕЛЬНОСТИ
Управляемая и контролируемая деятельность СА протекает в среде деятельности AREA^ ^ подразумевает наличие в этой среде средств управления, опирающихся на некоторое множество наборов управляющих данных. Назовем совокупность этих наборов множеством сценариев SCRIPTS^. Будем считать, что сценарий SCRIPT е SCRIPTSса задан множеством описаний актов деятельности ACT* :
SCRIPT - {dACTlr dACT2f . . . , dACT„} , (1)
где dACTi - представление акта деятельности ACTt на некотором языке описания сценариев SL.
Управление деятельностью посредством сценария предполагает наличие в среде AREAca интерпретатора. Для упрощения будем считать, что работа интерпретатора протекает в дискретном времени Т ~ {1. . t_end}, где на каждом шаге t е Т реализуется одно описание из сценария и t__exid -номер шага, завершающего интерпретацию всего сценария. Реализация описания акта, предусматривающего определенную деятельность обучаемого^ заключается в выполнении действий:
1. Выделение текущего описания акта деятельности dACTt = dACT± из сценария SCRIPTSс*, где i е п (SCRIPT).
2. Воссоздание состояния среды деятельности, предписываемого описанием dACTt. Описание должно включать в себя формулировку задания для обучаемого.
3. Восприятие последовательности действий обучаемого MRNIPACT возможно с контролем как самих действий, так и их порядка.
4. Контроль результата деятельности обучаемого и порождение продукта контроля. Результатом деятельности обучаемого является изменение состояния среды AREA^a и данные, порожденные обучаемым. Продукт контроля может заключаться в выводе сообщений, изменении рейтинговых оценок, изменении порядка реализации актов и пр.
5. Формирование значения указателя на следующий акт dACTt+1. В случае линейного сценария множество SCRIPТ упорядочено,и следующим будет интерпретироваться dACTi+1 . В случае сценария с ветвлениями выбор следующего акта dACTt+1 производится на основе результатов деятельности. Для поддержки перехода к заданному акту ему обычно приписывается некоторая метка SLLABact, рассматриваемая либо как отдельный неисполняемый элемент dACTt+1, либо как метка, включаемая в состав описания исполняемого элемента.
Отношение TRACEscrip1. cz Т х SCRIPT , в котором присутствуют только пары вида <t, dACTt>, будем называть трассой процесса интерпретации сценария SCRIPT. Это отношение функционально, так как на одном шаге интерпретируется только один элемент из множества SCRIPT. Один и тот же сценарий в различных случаях может порождать различные трассы, что может быть следствием как различного поведения разных обучаемых, так и различного поведения одного и того же обучаемого при реализации одних и тех же актов в других условиях. Обсуждая это свойство трассы, мы должны включать в рассмотрение множество S__Т совокупностей шагов Т и множество обучаемых S_P. Введем понятие протокола деятельности по сценарию SCRIPT, которое определяется как отношение
PROTscript с S_p х SJT х Т^ х S_IPROTscrzpt , (2)
гДе ттах - максимальное по мощности из множеств
S_IPROTscript ~ множество записей о результатах выполнения актов деятельности во время реализации протокола SCRIPT.
Обобщением понятия протокола обучения по отдельному сценарию является понятие протокола обучения PROTscripts по множеству сценариев SCRIPTSca , которое может быть представлено объединением всех множеств PROTscrxpj. по всем сценариям из SCRIPTSca . Естественно, что при этом элементы множеств S_IPROTSCript должны содержать сведения о сценарии, интерпретация акта деятельности которого порождает информационную единицу е (S_IPROTscript) . Протокол PROTscrjpts образует базу данных протоколов деятельности в среде AREAca,
Сценарии строятся на основе некоторого базового множества актов S_ACT. Свойства элементов этого множества и механизмы формирования и
интерпретации сценариев должны создавать основу для того, чтобы деятельность покрывала широкий спектр контролируемых знаний, выполнялась осознанно и самостоятельно. Кроме того, должны существовать возможности создавать сценарии, поддерживающие обучение существенно различающихся по подготовке обучаемых в условиях разнообразия целей обучения. Для этого естественно потребовать, чтобы S_ACT и созданные над ним сценарии обладали свойствами:
• величина card(S_ACT) должна быть большой;
• разнообразие vari (dACT) актов деятельности в сценарии и в множестве S_ACT должно быть большим;
• возможность POSguess случайного угадывания правильных действий для актов сценария была невысока;
• сложность СОМРсса создания сильными студентами комплектов правильных и легко повторяемых действий была высока.
Строя несколько сценариев над одним множеством S_ACT, мы повышаем рентабельность его создания, т.к. сложность разработки одного контролируемого акта деятельности высока и повторное использование актов в разных сценариях увеличивает эффект от затрат на их разработку.
При создании множества актов деятельности формируется множество замыслов S_PACT, для каждого из которых разрабатывается множество реализаций SS_RPACT. Такой подход, когда для одного замысла PACT е S_PACT строится несколько реализаций RPURPAcr е SS__RPACT , позволяет существенно увеличить мощность множества S_ACT и улучшить параметры vari (dACT), P0SGUBS5 и СОМРССА. Один из наиболее продуктивных методов порождения многих актов контролируемой деятельности на основе одного замысла заключается в модификации значений параметров состояния среды деятельности AEEA^. Объединение всех множеств SS_RPACT по всем замыслам образует множество всех реализаций S_RPACT. Таким образом, множество актов может быть представлено как отношение:
S_ACT d S_PACT х S^RPACT. (3)
Для формирования структуры описания акта учебной деятельности на основе (3) необходимо уточнить структуру реализации замысла RPURPACF. Уточнение строится на основе анализа содержания описанных выше действий по интерпретации dACTt и с достаточной степенью общности может быть представлено следующим образом:
RPUKPact = <CASEact, PRRESact/ PARAMaCT>, (4)
где CASEACt - проблемная ситуация, в которой обучаемый выполняет определенную деятельность; в системе учебного назначения обычно
содержит формулировку задания и некоторое состояние модели среды деятельности; может содержать описание множества допустимых действий обучаемого в этой ситуации;
РКЯЕЗаст - описание процедуры обработки действий пользователя и их конечного результата, которая порождает числовые оценки, модификацию рейтингов и решение о том, какой акт деятельности должен выполняться следующим; описание РКЙЕБАСТ на практике часто содержит данные, обеспечивающие контроль, например, образцы ответов;
РАНАМцст - набор параметров акта деятельности; как минимум, этот
набор должен содержать оценку сложности осуществления акта
деятельности обучаемым; такая оценка необходима для контроля навыков,
где существенно йремя выполнения действий, а также для общего
планирования деятельности с учетом ограниченности времени занятий; в
случае, использования РАНАМцст для поддержки автоматизации
\
проектирования сценариев он может содержать классификационные признаки.
Вектор ЯРиКРЛст является элементом отношения:
КВРАСТ с БСАБЕАСТ х Б_РРВЕБАСТ х БУРАВАМ. (5)
Именно это отношение порождает базу данных описаний актов контролируемой деятельности, над которой работает интерпретатор сценариев. Естественно, что в базе данных фигурируют описания &САБЕаст, ЗРККЕВасъ <ЗРАКАМасг и пр. Чтобы определить подходы к формированию сценариев и их интерпретациигнеобходимо исследовать его свойства.
Самой сложной и наиболее творческой задачей создания 1У5СР.ХРТ является порождение множества замыслов Б_РХШРАСТ . На основе одного замысла можно построить много записей путем вариации параметров среды деятельности и порождения элементов множества Б_САБЕаст , причем этот процесс может быть в определенной степени автоматизирован. В большинстве реальных случаев отношение Б__САБЕАСТ х Б_РИИЕБАСТ> которое является проекцией отношения ВКРАСТ на первые две оси, функционально, т.е. справедливо:
ЕРЯОС: Б_САБЕАСТ Б_РШЕБАСТ.
Функциональная связь ЕРКОС является основой для автоматизации процессов формирования процедур множества Б^РЯКЕБАСТ.
МОДЕЛИ КОНТРОЛИРУЕМЫХ ЗНАНИЙ
В общем случае контроль направлен на проверку знаний, умений и навыков определенной предметной области АЛОМАШ. Будем считать, что для нее определено некоторое конечное множество контролируемых знаний, умений и навыков Б^. Для реальной предметной области АГЮМА1Я несвойственна четкая атомарность входящих в нее знаний. Однако при
создании информационных систем мы вынуждены опираться на данные, которые по своей природе атомарны.
Множество Skn может охватывать раздел учебного курса, весь курс и даже несколько учебных дисциплин. Элемент Ет е Sm будем называть элементом знаний, даже если на практике это умение или навык. При задании множества через перечисление используются декларации элементов DECL^, например: «Знание языка ассемблера», «Умение организовывать передачу параметров в процедуру через стек», «Навыки использования кросс-отладчика» и т.п. Элемент знаний обладает содержанием СОШк» которое в автоматизированной системе учебного назначения обучаемому пытаются передать через определения DEFjq, сг £пвп описания DESgjH с Sees и применения USExn er где S^ Sms и SUSE - множества определений, описаний и применений всех рассматриваемых элементов знаний, В результате в голове обучаемого возникает некоторое содержание LCONTm,vi естественной целью обучения является максимальное его приближение к CONTKк, т.е. уменьшение величины рассогласования dif (CONTm, LCONT^.
Элементы множества S^ по своему содержанию могут пересекаться. Ничто не мешает одновременному присутствию в нем, например, таких деклараций: «Умение программировать циклы» и «Умение программировать циклы со счетчиком». В реальной практике отдельный акт деятельности обучаемого зачастую связан с применением нескольких элементов знаний. Это заставляет рассматривать не только отдельные элементы множеств S^, но и их подмножества SSm с San, причем одновременно допустимо и SS^ tr Sm Пересечение содержания элементов знаний и их агрегация в подмножества обеспечивают некоторую компенсацию от искусственного навязывания предметной области ADOMA.ZN свойства атомарности входящих в нее знаний. В общем случае DEF^ DES*» и VSEm являются множествами, хотя в практике описания предметной области часто первые два множества имеют всего по одному элементу. В учебной системе естественно для повышения эффективности и индивидуализации обучения создавать альтернативные варианты описаний объектов предметной области, поэтому описания DEFfo, и DESja, будем рассматривать как множества.
Множество применений знаний SaSE является основой для организации деятельности обучаемого в учебной САПР, направленной как на уточнение LCONTjw, так и на контроль его близости к CONTkh- Именно это множество служит основой для порождения замыслов актов деятельности. Необходимо уточнить, что описание применения какого-либо объекта или процесса относится к DESxx, а не к USEm.
Для определения подходов к построению множества sUSe и методов проведения контроля в учебной САПР МПС целесообразно различать
следующие виды деятельности: контроль знаний методом опроса; программирование и изучение программно-технических приемов; проектирование структуры и изучение схемотехнических и системотехнических решений МПС; моделирование микропроцессорных устройств (МПУ), под которыми понимаются микропроцессоры (МП) и микроконтроллеры (МК) и микропроцессорные БИС адаптеров связи, котроллеров прерываний, ПДП и т.п.
МОДЕЛИ СРЕДСТВ РЕАЛИЗАЦИИ И СОЗДАНИЯ СЦЕНАРИЕВ
ДЕЯТЕЛЬНОСТИ
Средства реализации и создания сценариев деятельности целесообразно строить как интегрированную среду, исходя из следующих соображений. Во-первых, процессы интерпретации и создания сценариев базируются на общих множествах информационных объектов. Во-вторых, одним из наиболее эффективных методов улучшения параметров vari (dñCTJ, POSsaess и СОМРССА является автоматическая генерация элементов dACT¿ путем вариаций параметров информационных объектов dCASEñCT, dPRRESACT, dPARAMACT и пр. Если осуществить автоматическую генерацию с использованием генераторов случайных чисел, то можно достичь очень большого разнообразия актов деятельности. Для достижения большего эффекта естественно вовлечь в этот процесс разработчиков сценария и преподавателей, ведущих занятия с обучаемым.
Среду деятельности целесообразно представить как совокупность пользователей ACTORS, баз данных DB, модулей обработки данных UNITS и интерфейсов IFACE, связывающих все объекты среды в единое целое. Кроме того, среда должна порождать отчеты REPORTS. Т.е. наиболее общей семиотической моделью среды деятельности является вектор вида:
AREA = <АCTORS, DB, UNITS, IFACE, REPORTS>.
Совокупность всех пользователей ACTORS целесообразно разбить на четыре подмножества: обучаемые S_PUPL, авторы сценариев S_AUTOR преподаватели S_TOTOR я администраторы программно-информационной среды S^MANAG. Очевидно, что права у разных категорий пользователей различны, поэтому система должна поддерживать авторизацию доступа. В этой связи множество ВВ должно включать в себя данные авторизации dbAGCESS, множество UNITS - подсистему авторизации доступа uACCESS, а множество IFACE - интерфейсы xPUPL, iAUTOR, iTUTOR, ¿MANAG.
База данных описаний актов деятельности dbACTS в интегрированной среде с поддержкой автоматической генерации объектов содержит не только элементы dACT± с описанной выше структурой, но н некоторые шаблоны. Интерпретатор сценариев uISCRIPT; извлекая эти данные через интерфейс
iACTS, либо сразу реализует акт деятельности, либо предварительно пропускает набор шаблонов через один или несколько модулей генерации сценария uGSCRIPT, используя семейство интерфейсов iGSCRIPT. Протоколы интерпретации поступают в базу данных dbLOG через интерфейс iLOG, Преподаватель может получать результаты обработки протоколов модулем uLOG через интерфейс i TUTOR При этом он может с помощью генератора отчетов uREPORTS получить различные отчеты о ходе деятельности как по пользователям, так и по сценариям. Обозначим эти множества отчетов,соответственно,как rAPUPL и rSCRIPTS. Естественно, что автор сценариев через интерфейсы 1AUTOR и ¿ACTS может вручную формировать записи dbACT и, кроме того, через интерфейс iGSCRIPT может использовать генераторы uGSCRIPT. При этом автор выполняет функции, близкие к функциям инженера знаний в экспертной системе. Создавая сценарии, он нуждается в информации предметной области (в нашем случае области микропроцессорной техники), которая сосредотачивается в базе данных dbADOMAIN. Кроме того, автору необходимо получать протоколы rSCRIPTS для совершенствования сценариев.
Приведенное выше описание позволяет уточнить AREA следующим образом: ^
ACTORS = {S_PUPL, S_AUTOR/ S_ TUTOR, S_MANAG},
DB = {dbACCESS, dbACTS, dbLOG, dbADOMAIN, dbOTHER},
UNITS = {uACCESS, uISCRlPT, uGSCRIPT, иLOG,
uREPORTS, uOTHER}, IFACE = {iPUPL, iAUTOR, iTUTOR, xMANAG, iLOG,
iACTS, iGSCRIPT, iOTHER}/ REPORTS ~ {rSCRIPTS, rAPUPL, rOTHER}
Элементы dbOTHER, uOTHER, iOTHER, rOTHER включены в приведенное уточнение в связи с тем, что среду управляемой деятельности целесообразно строить как наращиваемую информационную систему. Очевидно, что для случая изучения МПС компонент uOTHER должен включать в себя ориентированные на обучение модели МПУ [2].
Модели приведенных объектов деятельности в среде AREA строятся на описанных выше моделях самой деятельности и предметной области знаний, умений и навыков. Например, структура dbLOG во многом определяется структурой отношения PROTSCript, определенной выражением (2). Однако при уточнении е (S^_IPROTscript) мы должны включить в рассмотрение результат действий REStacr обучаемого, который представляется через измененное состояние модели и порожденные обучаемым объекты данных. Уточняя структуру dbACTS, мы должны взять за основу описания (1), (3), (4), (5). При этом целесообразно включить в рассмотрение описание
множества допустимых действий обучаемого ВБтст в ситуации САЗЕхсг-Это обеспечивает управление уровнем доступности тех или иных манипуляций, например, вызов справочников и приложений, и дает возможность контролировать последовательно осуществляемые манипуляции.
СПИСОК ЛИТЕРАТУРЫ
1. Негода В. Н., О построении учебно-исследовательской системы функционально-логического моделирования микропроцессорных систем // Вестник УлГТУ. Серия «Информационные технологии». Ульяновск: УлГТУ, 1998.
2. Негода В. Н. Структуры программ моделирования микропроцессоров в учебно-исследовательской САПР микропроцессорных систем // Информационные технологии, системы и приборы: Сб. науч. трудов / Ульяновский государственный технический университет. Ульяновск, 1998.
Негода Виктор Николаевич, кандидат технических наук, профессор кафедры «Вычислительная техника» УлГТУ. Окончил радиотехнический факультет Ульяновского политехнического института, Имеет статьи и монографии в области проектирования микропроцессорных систем и автоматизации обучения.
