Обучающее программное обеспечение.
© Сергей Симонович, 1994.
В последние полтора года наши читатели активно поднимают вопрос о необходимости развития обучающего программного обеспечения на базе "Спектрума". Проблема не нова. Мы сами с этого начинали лет шесть назад, но тогда эти идеи мало кому были нужны. Впоследствии не раз ещё делались попытки вернуться к этой теме ("Спектрум в школе" всегда был первым разделом в ZX-РЕВЮ), но вопрос всё равно вяз. Сегодня уже не мы его поднимаем, об этом говорят сотни читателей в своих письмах и, поверьте, это не случайно.
Если "Спектрум" входит в полосу конкурентного развития и будет жить "от творчества" масс, то надо подумать и о том поле, на котором это творчество будет происходить. Клайв Синклер "сделал" карьеру "Спектруму", а сам получил титул лорда на том, что оснастил компьютером тысячи английских школ, то есть, удачно сыграл на поле народного образования. И здесь есть над, чем призадуматься.
Нам известны всего лишь девять разных жанров игровых программ. В каждом из них кто-то уже сказал свое весомое слово и очень трудно придумать что-то принципиально новое. Можно, конечно, предположить, что когда-то кто-то выпустит ELITE-35 или DIZZY-49, но все равно логический предел есть, и он не за горами.
Совсем иначе дело обстоит в обучающем программировании. Это поле неисчерпаемо, да и не может быть исчерпано. Если нации уже нечему будет учиться, то. Одним словом, один только список школьных дисциплин во много раз превосходит список жанров игровых программ. А сколько в каждой дисциплине разделов и тем?! А сколько учебников написано по каждой теме?! А почему останавливаться только на школьных проблемах? Существуют ведь вузы и техникумы. А ведь учиться можно не только научным дисциплинам. Сколько вопросов и тем не связаны с наукой, а относятся к культуре и искусству!
Одним словом, если есть неисчерпаемое поле для деятельности, к тому же такое, для подъема которого не надо собирать команды по тридцать человек, а работать в одиночку или в небольшой группе - то это только обучающие программы.
Открытым, правда, остается вопрос, насколько они кому-либо нужны, и будет ли на них спрос? Но это уже зависит от качества программы, от того, насколько талантливо она сделана и что в нее заложено.
Данная статья предназначена как раз для тех, кто хочет попробовать свои силы в этой области. Сразу скажем, что, несмотря на то, что мы интересуемся этим вопросом уже не первый год, все-таки фактического материала у нас маловато. Очень это дело неразвито не только у нас, но и за рубежом. Неслучайно, кстати, многие зарубежные фирмы заказывают программы этого класса нашим российским программистам. Тем не менее, мы постараемся разобраться с некоторыми проблемами, которые возникают при создании обучающих программ.
Тему считаем незаконченной, а только открытой. С огромной радостью примем соображения наших читателей, развивающих эту тему дальше (реализуйте свою потребность в контактах).
1. Опыт классификации обучающих программ.
1.1. Информационная программа.
Концептуально это самый простой вид обучающей программы. Гладкий текст, переписанный из учебника, который воспроизводится на экране по нажатию клавиши (возможно, что и с иллюстрациями) - вот самый негодный пример того, что может быть сделано в этом жанре.
В "простоте" как раз и заключается вся сложность. Как сделать этот текст не просто "читаемым", а ещё и читаемым с увлечением, как сделать, чтобы компьютер был более удобен, чем книга - в этом-то вся проблема и состоит.
Генеральное преимущество компьютера перед книгой - в его интерактивности. То есть, в ответ на разные реакции пользователя книга всегда даст одно и то же, а компьютер должен реагировать по-разному. Как использовать интерактивность в простой информационной программе - решать Вам. Самое простое, что можно здесь предложить - это организовать экранное меню (это уже интерактивность) и, конечно же, время от времени подкидывать пользователю
конкретные вопросы, а по результатам ответов соответственно реагировать.
До последнего времени мы не знали ни одного удачного образца подобной информационной программы для "Спектрума", но сейчас такой образец появился - это последние выпуски журнала "Спектрофон" (авторы Матвеев Ю.А. и Шишлянников С.Я.). Правда, "Спектрофон" - это не обучающая программа, но если информационную часть в нём сделать обучающей, то это будет достойный образец.
Многочисленные шрифты, каждый из которых несет свою органическую нагрузку, умелое управление цветом для выделения нужных мест, звуковое сопровождение, настраивающее на новую тему, удачное инкорпорирование спрайтов в тексте, не перегруженная структура меню, возможность выйти из информационного блока в заранее подготовленную независимую программу и многое-многое другое из оболочки этого журнала, посвященного игровым программам, может быть использовано в качестве пожеланий разработчикам будущих информационно-обучающих систем.
А то, что такие разработчики найдутся, можно быть уверенными. Рынки страны завалены многочисленными demo-роликами, в которых под музыкальное сопровождение при отличной анимации передаются килобайты поздравлений, пожеланий и всякой прочей очень "важной" информации. Впрочем, эти demo-ролики свою задачу исполняют блестяще. Они должны быть демонстрационными, вот и демонстрируют, что в стране есть множество способных программистов, способных на решение подобных задач. Заодно, кстати, они выполняют очень важную "синклер-функцию" (удовлетворяют потребность в самореализации и самоутверждении, что для молодых людей, конечно, необходимо).
1.2. Моделирующая программа.
Это несложный, но очень важный класс обучающих программ. Здесь абсолютно необходима графика и анимация. Суть программы состоит в том, что на экране моделируется некоторый физический процесс или явление.
Классический пример - бросание камня под углом к горизонту. Графически на экране можно показать, как зависит длина полета камня от угла бросания.
Другой пример - моделирование ситуации при обгоне на дороге (см. рис. 1). Автомобиль А должен обогнать автомобиль В, едущий со скоростью V1. Им навстречу едет автомобиль С со скоростью V2 . Должны также учитываться такие параметры, как расстояние L и длина обгоняемого автомобиля Lb. Пользователь должен ввести скорость обгона (Va) и программа покажет ему, что с ним будет в данной ситуации.
Рис. 1
Звук, музыка, скрип тормозов, звон разбитого стекла - все должно быть использовано, чтобы отучить будущего водителя обгонять с выездом на полосу встречного движения без достаточных оснований, а заодно побудить попробовать свои силы в программе ещё разок.
Моделировать можно что угодно. Очень интересно моделировать колебательные процессы, например колебания маятника, пружины, уровня жидкости в сообщающихся сосудах, заряда конденсатора в колебательном контуре и т.п. Возможность пользователя изменять параметры системы по ходу процесса, (например, менять сопротивление в колебательном контуре) делает программы этого класса интерактивными. Это отличная замена лабораторным работам, особенно в учебных заведениях, не располагающих для этого достаточной технической базой.
1.3. Демонстрационная программа.
По своей сути она не очень отличается от моделирующей, здесь тоже надо средствами графики и анимации показать процесс или явление, но поскольку речь идет только о демонстрации, она может быть не интерактивной, то есть не ждёт от пользователя никаких вводов данных, а просто показывает заранее заложенный сценарий (например, работу четырехтактного двигателя внутреннего сгорания, ядерного реактора, токарного станка.).
Поскольку демонстрация здесь самый главный момент, программа обязательно должна работать красиво. Если в моделирующей программе можно допустить, чтобы автомобили были кубиками, то здесь это абсолютно не проходит.
1.4. Программа-экзаменатор.
Программы этого типа знакомы всем, кто когда-нибудь сдавал экзамены в ГАИ. Программа содержит блок вопросов (по возможности сопровождающихся иллюстрациями) и заранее определенный перечень готовых ответов, только один из которых правильный.
Программы этого типа хорошо подходят практически для любых наук и дисциплин. Разновидностью подобных программ могут быть программы по арифметике "реши пример", по русскому языку "вставь пропущенное слово", по физике "определи размерность" и многие другие.
2. Поощрять или наказывать?
Большая проблема в обучающем программировании связана с системой поощрений и наказаний. Как поощрить пользователя за правильный ответ? Наказывать или не наказывать за неправильный, а если наказывать, то как? Последнее слово в этой проблеме ещё до конца не сказано, и у каждого из наших читателей есть необъятное поле для экспериментов.
Но, прежде чем говорить о поощрениях за правильный ответ, нам надо ещё определиться со стимулированием учебной активности. Если у пользователя нет стимула для того, чтобы добраться хотя бы до середины программы, то все Ваши ухищрения и изобретения так, и останутся неоцененными и неузнанными.
Наибольшую трудность в смысле стимулирования представляют программы 1-го типа (информационные программы). Само собой разумеется, что если текст посвящен чему-то очень интересному (как, например, в журнале "Спектрофон"), то само содержание уже является достаточным стимулом для того, чтобы читатель двигался вперед. Ну, а если программа посвящена такой скучной теме, как "Распределение трудовых ресурсов по климатическим поясам?".
В этом случае Вы должны использовать сильный стимул, который можно выразить словами: "А что же дальше?". Приведем пример. Если при рассказе о зонах пустынь и степей в Вашей программе будет звучать музыка, характерная для этих регионов, то у пользователя невольно появится желание дойти до описания трудовых ресурсов в тундре, дабы послушать, какая музыка будет там.
То же самое касается и графики, особенно анимации. Она должна быть использована для стимулирования желания идти дальше. При этом неважно, что Ваша анимация, может быть, простой и бесхитростной (дым от костра, движущиеся облака и пр.). Опыт показывает, что компьютерная анимация при любой простоте является очень выразительной.
Но и статическая графика тоже является важным элементом. Достаточно сделать разные фоновые экраны для разных разделов программы, и у пользователя появится желание, как можно быстрее просмотреть все темы. В качестве барьера можно поставить контрольные вопросы в конце каждой темы. Здесь есть хорошо знакомый пример - программа Bomb Jack. Главный герой игры собирает "бомбы" и получает за это очки. Различным уровням игры соответствуют различные фоновые картинки (от древнеегипетских пирамид до фантастических городов будущего). Горячее желание узнать, что будет дальше, стимулирует пользователя к тому, чтобы приложить максимум возможных усилий для перехода на новый уровень.
Рис. 2,3.
На этом же строится и система поощрений. Фактически, у Вас есть только три системы поощрений: текстовым сообщением, графикой, музыкой. И все эти средства должны вызывать желание узнать, "что же дальше?". Так, например, получив, пять раз подряд сообщение "Отлично! Молодец!" пользователь может потерять интерес к работе, понимая, что ничего нового ему эта программа не сулит.
Достаточно широко в обучающих программах применяется система поощрений в виде постепенно проявляющейся или постепенно открывающейся картинки. Можно усложнить игру, " выдавая" за правильные решения какие-то фрагменты рисунка, из которых потом можно будет сложить красивую картинку (вознаграждать фрагментом за правильные ответы, а игрой по их выкладыванию - за пройденную тему).
Здесь есть характерная ошибка, нередко встречающаяся в обучающих программах, в которых пользователь имеет крайне ограниченное время на ответы. Естественный стресс, который здесь возникает, совсем не располагает к тому, чтобы получать удовольствие от созерцания подобных "наград". Либо пользователь не обращает на них внимания, либо они его раздражают, сбивая с ритма. В остродинамичных ситуациях лучше "поощрять" звуком, а не графикой, оставляя её на итоговое поощрение по окончании раздела (темы, блока).
Теперь о системе наказаний. Как наказывать, да и надо ли это делать - большая проблема. В игровых программах в большинстве случаев система "наказаний" присутствует. Это потеря очередной "жизни" с последующим возвратом к началу игры (или к началу уровня). Так получается, что если в качестве "поощрения" пользователю дают что-то новенькое, интересное и по возможности неожиданное, то в качестве "наказания" его вынуждают заниматься чем-то известным, пройденным и уже неинтересным. Покопавшись в своей библиотеке игровых программ, Вы легко выделите те игры, в которых система наказаний является "гуманной" и дружественной и в которых система наказаний неоправданно "жестока" и нецелесообразна. Самое жестокое наказание, с которым Вам приходится сталкиваться в игровых программах, относится к кассетным играм с многочисленными догружаемыми уровнями, в которых после "гибели" на N-ном уровне Вам приходится перематывать ленту на начало, перезагружать первый уровень и проходить всё заново с новыми подзагрузками. Такие игры не пользуются устойчивым спросом -их создатели явно "перемудрили".
Таким образом, "наказанием" в обучающей компьютерной программе должна быть необходимость повторения каких-то процессов, уже не являющихся для пользователя новыми. И можно даже вывести эмпирическую зависимость: "Чем серьёзнее провинность, тем более длительным (по времени) должен быть повторяющийся блок". Поскольку "повторение - мать учения", в обучающих программах этим можно отлично пользоваться для закрепления уже пройденного материала.
Понятие "длительным", однако, здесь не всегда совпадает с понятием "скучным". Например, если пользователь не решил примера (7*8=?), то можно предложить ему "расстрелять" несколько воздушных шариков, на которых записан правильный ответ и чем чаще встречается подобная ошибка, тем "шариков" может быть больше. При этом всегда следует иметь в виду два важных момента:
•S выдавая правильный ответ, всегда надо напоминать сам вопрос (увлекаясь "охотой за шариками", играющий забывает, к чему они относятся);
Рис. 4.
В заключение этого раздела мы призываем всех наших читателей к исследованию возможных способов "наказаний" и "поощрений" в обучающих программах. Тема практически неисчерпаема и каждый, независимо от стажа работы с компьютером и от личного опыта, может внести свой вклад в общее исследование.
3. Некоторые методические приемы.
Методические приемы, заложенные в основу будущей обучающей программы (игры) могут быть крайне многообразны. Их могут быть тысячи, хотя никто до сих пор не пробовал их обобщить и проанализировать. Это опять же огромное поле для Вашей самостоятельной деятельности и для Вашей фантазии. В качестве же первого примера мы остановимся здесь только на некоторых.
Самым важным, что объединяет любые приёмы, является принцип интерактивности. Поскольку интерактивность - основное свойство, отличающее компьютерную обучающую программу от книги или учебника, то при разработке любых своих новых приемов следует всегда спрашивать себя: "А где здесь интерактивность?". То есть, может пользователь своими действиями повлиять на ход развития сюжета или нет? Если он этого сделать не в состоянии, лучше такую программу не выпускать, а вместо нее написать методическое пособие, распечатать его на принтере и раздать ученикам.
3.1. Иерархическая структура.
Программное меню - это уже элемент интерактивности и этим надо умело пользоваться. Иерархическая структура программы не должна быть ни слишком простой, ни слишком сложной. Желательно не допускать глубокой вложенности меню (более трех уровней). В играх это не очень важно, но в обучающих программах пользователь должен быть в состоянии удержать эту структуру в уме без особого напряжения. Это способствует созданию и закреплению цельного видения всей темы. В образовании крайне важно не только хорошо знать суть того или иного вопроса, но и хорошо представлять хотя бы в общих чертах, как он увязан с другими смежными разделами. Так, например, изучая в физике тему "Работа", ученик должен понимать, как к ней относятся темы "Сила", "Энергия", "Единицы измерения" и т.п.
Из тех же соображений целостности подхода должны быть ограничены и размеры каждого из вложенных меню. Они не должны превышать 7 пунктов. Единственный случай, когда их может быть больше (до 10) - при включении в меню служебных (квазистандартных) функций типа LOAD, SAVE, SOUND ON/OFF и т.п.
3.2. Интерактивная графика.
Это очень сильный, но редко применяющийся в силу естественной сложности прием. Среди обучающих программ для "Спектрума" мы не знаем известных примеров, но в игровых программах он применяется очень широко в аркадных, традиционных, логических и других играх (практически всегда в аркадных адвентюрах есть интерактивная графика).
Приведем пример из программы "Locomotion". На экране в беспорядке "разбросаны" фишки, представляющие фрагменты рельсового пути локомотива. Передвигая, их Вы должны собрать непрерывный путь, по которому локомотив пройдет из пункта А в пункт В без аварий.
•f следует помнить, что во время активных действий (работа с клавиатурой или джойстиком) поле зрения играющего сужается непосредственно до места положения курсора и он "не видит" никакую ин формацию, если она помещена в стороне (см. рис. 4)._
Можно предложить аналогичную схему для лабораторных работ по физике. Выбирая из меню стандартные элементы (резисторы, элементы питания, проводники, выключатели, лампочки, амперметры, вольтметры и т.п.), пользователь создает на экране свою электрическую цепь. Сканируя экран, программа заполняет соответствующий массив в оперативной памяти, а затем по заранее разработанным процедурам вычисляет суммарное сопротивление цепи, значения тока в ветвях и т.п. Любые изменения в графике на экране (перестановки элементов) приводят к изменениям в массиве данных и отражаются на результатах расчета (рис.5).
Рис. 5.
Способов использования интерактивной графики может быть сколько угодно и это один из наиболее прогрессивных путей создания обучающих программ.
3.3. Контекстные приемы.
Ключевые слова в обучающей программе полезно выделять цветом (и/или шрифтом) и создавать для них свой программный словарь (строковый массив) терминов. Он может пригодиться. Как в адвентюрных играх программа "понимает" слова из заранее заготовленного словаря, так обучающая программа должна "понимать" ключевые слова, относящиеся к данному уроку. Так, например, в описательной части программы, посвященной двигателю внутреннего сгорания, можно сказать, что его основными элементами являются ЦИЛИНДР, ПОРШЕНЬ, ШАТУН, КЛАПАН ВПУСКНОЙ, КЛАПАН ВЫПУСКНОЙ и пр. Выделенные слова являются ключевыми. Далее, по ходу описания, можно предлагать пользователю самому вставлять пропущенные в тексте слова, выбирая их из ключевых. При этом даже такой рутинный процесс, как чтение, делается интерактивным.
Периодически можно тестировать усвоение прочитанного материала с помощью иллюстраций, в которых пользователь должен сам проставить названия узлов и деталей из того же словаря.
Наличие словаря "ключевых слов" и выражений позволяет организовывать контекстный поиск, контекстные подсказки и даже гипертекстные структуры. Если у Вас есть такой словарь, то Вы в состоянии организовать сканирование экрана по "горячей клавише" в поисках ключевых слов. "Горячую клавишу" на БЕЙСИКе несложно организовать с помощью INKEY$, а из машинного кода можно использовать как процедуры, опрашивающие клавиатуру, так и с помощью прерываний 2-го рода (правильно работают не на всех отечественных моделях).
Наиболее широко контекстный поиск применим в программах, обучающих языкам (по одной клавише можно выдавать перевод слова, на котором установлен курсор на экране, а по другой, например транскрипцию.) Контекстный поиск может быть также использован в любых других программах для выдачи определений, справочной информации и даже графики. Так, например, если Ваша программа посвящена русской литературе XIX века и А. С. Пушкин включен в контекстный словарь ключевых слов, то при нажатии на "горячую клавишу" и установке курсора на это ключевое слово, программа может выдавать на экран краткую справку о творчестве великого поэта и даже показывать его портрет. Предыдущий экран необходимо сохранять в памяти, чтобы, выйдя из "справки", вернуться в него без проблем.
4. Проблемы ближайшей перспективы.
4.1. Организация структур данных.
Основной проблемой на ближайшую перспективу является необходимость наличия автоматических средств для создания обучающих программ, иначе широкое производство
20
отечественного программного обеспечения в сжатые сроки не развернуть. К счастью, широкое распространение по России дисковых систем, работающих под системами TR-DOS и iS-DOS, позволяет решить эту проблему.
Главным направлением Ваших исследований на ближайший период должно стать развитие технологий, используемых для работы с базами данных применительно к обучающим программам. Принципиально структура данных в обучающей программе ничем не отличается от базы данных. Можно считать, что обучающая программа - это БАЗА ЗНАНИЙ.
Структура файла базы данных включает такие понятия, как ПОЛЯ и ЗАПИСИ и имеет вид прямоугольной матрицы._____
|
|
ПОЛЕ 1 |
ПОЛЕ 2 |
ПОЛЕ 3 |
|
ПОЛЕ N |
|
ЗАПИСЬ 1 ЗАПИСЬ 2 |
|
|
|
|
|
|
ЗАПИСЬ М |
Мы не будем здесь останавливаться на объяснении технологии организации данных в такую структуру. Этому посвящено большое количество книг и публикаций в журналах. Рассмотрим только, какие поля могут Вам потребоваться в обучающих программах.
Символьное поле.
В этом поле может быть записана любая текстовая информация. Длина поля (в байтах) равна необходимой Вам максимальной длине записи.
Целочисленное поле.
Поле для записи целых чисел от 0 до 65535. Длина - 2 байта.
Числовое поле.
Поле для записи чисел с плавающей точкой. Длина такого поля должна быть равной пяти байтам, поскольку в "Спектруме" действительные числа представляются в пятибайтной форме.
Поле даты.
Для записи календарной даты общепринятым считается использование 8-ми байтов. Рекомендованным форматом может быть, например ДД.ММ.ГГ (например 25.03.94). В качестве разделителя мы использовали точку (.), хотя иногда применяют "слэш" (/) или двоеточие (:).
Поле даты практически повсеместно применяется в базах данных, предназначенных для ведения какого-либо учёта (складского, регистрационного и пр.). На первый взгляд, в нем нет необходимости для обучающих программ, но это не так. Существует целый спектр проектов, основанных на том, что программа сама оценивает способности учащегося по результатам предыдущих сеансов (они записаны в протокольном файле на диске) и может оценить динамику его успехов, если даты всех "успехов" и "неудач" ей известны. Так программа автоматически настраивается на уровень пользователя и демонстрирует искусственный интеллект. В свое время (1991г.) мы успешно распространяли первую выполненную в таком стиле программу обучения английскому языку DINEX (Динамический Экзаменатор).
Поле переменной длины.
Если ожидается, что символьное поле будет иметь очень большую длину, причём в разных записях эта длина будет сильно варьироваться, целесообразно сделать его полем переменной длины (мемо-поле). Несмотря на свое название, это поле может иметь вполне фиксированную длину, например для системы TRDOS - 8 байтов, а для iS-DOS - 12 байтов. В нём может содержаться только имя файла, в котором на самом деле и хранится текстовая информация. Этот файл может иметь любую длину и при нем есть небольшой указательный (индексный файл), с помощью которого для любого номера записи будет быстро найдена и выбрана информация из основного файла.
Графическое поле.
Хранить графику в базе данных, разумеется, нецелесообразно. И здесь надо поступать так же, как и для поля переменной длины. Достаточно хранить номер экрана (один или два байта). Поскольку графические экраны имеют стандартную длину, то отпадает необходимость в индексном файле. По номеру экрана он будет найден в основном файле и выдан на дисплей. Если экраны хранятся в скомпрессированном виде, то придется либо создавать сопутствующий индексный файл, либо разделять экраны друг от друга с помощью маркеров. Хотя использование индексного файла - безусловно, более грамотный и быстроработающий приём.
Поле спрайтов.
Если Вы хотите, чтобы в текст Вашей программы автоматически имплантировались графические шаблоны, то можно предусмотреть и поле спрайтов. Длина этого поля может быть равна одному байту, если Вы используете не более 255 разных спрайтов. Все спрайты могут храниться в одном файле и извлекаться оттуда по номеру (если их длины одинаковы) или с помощью индексного файла, если их длины различаются.
Для себя (или централизованно в виде квазистандарта) следует решить вопрос о том, в каком формате хранятся спрайты. Как хранится информация о координатах левого верхнего угла, о ширине и высоте, о графических атрибутах.
Логическое поле.
Логические поля имеют длину в один байт, который может иметь только два значения: 0 или 1, T(rue) или F(alse), Y(es) или N(o) . В программе используются как флаги. Так, например, если пользователь уже решил данную задачу (обработал N-ную ЗАПИСЬ), то в логическом поле нужно поставить 1 и программа больше не предложит ему эту задачу для решения (или не предложит её сегодня, но может предложить завтра, сверившись с календарной датой по полю ДАТА).
Можно при первом запуске программы предварительно занулять все логические поля, но можно этого и не делать, тогда программа сможет "знать" предысторию того, как Вы с ней работали в прошлом.
Логические поля удобны для отгрузки состояния программы на диск. Во многих случаях достаточно отгрузить только логическое поле под именем, заданным пользователем. Продолжая программу на следующий день, пользователь может подгрузить логическое поле (вернуться к ранее отложенному состоянию) или начать все сначала. Правда, на практике отгрузки ТОЛЬКО логического поля бывает недостаточно. Для полного сохранения состояния программы нужно отгрузить ещё и все программные переменные, и текущий образ экрана.
Вычисляемые поля.
В своей программе Вы можете связывать свои поля с помощью каких-то математических, логических и других отношений. При этом у Вас могут быть поля, которые при создании программы заполнять и не надо. Они заполнятся автоматически по программе после начала работы.
Такими соотношениям могут быть, например:
ПОЛЕ 3 = ПОЛЕ 2 * ПОЛЕ 1
ПОЛЕ 3 = ПОЛЕ 2 / ПОЛЕ 1 - ПОЛЕ 4
ПОЛЕ 3 = (1 TO 3) ПОЛЕ 2
Здесь под (1 ТО 3) мы понимаем "вырезание" первых трёх символов из содержимого символьного ПОЛЯ 2 и помещение результата в ПОЛЕ 3. Таким образом, вычисляемые поля могут быть не только числовыми, но и символьными и любыми другими.
Прочие поля.
Возможность создания в базе полей любых других типов - дело Вашей фантазии.
Пример организации данных в обучающей программе.
|
ПОЛЕ |
Тип |
Длина |
Назначение |
|
1 |
Симв |
100 |
Описание задачи |
|
2 |
Граф |
1 |
Номер иллюстрации |
|
3 |
Симв |
30 |
Формулировка вопроса |
|
4 |
Симв |
50 |
Демонстрационный пример |
|
5 |
Числ |
5 |
Правильный ответ |
|
6 |
Лог |
1 |
Контрольный флаг (задача уже решена) |
|
7 |
Симв |
30 |
Подсказка 1-го уровня при неверном решении |
|
8 |
Лог |
1 |
Контрольный флаг (один неверный ответ) |
|
9 |
Симв |
30 |
Подсказка 2-го уровня при повторном неверном ответе |
|
10 |
Лог |
1 |
Контрольный флаг (два неверных ответа) |
11 Целое 2 Адрес процедуры, запускаемой при решении задачи (поощрение)
12 Целое 2 Адрес процедуры, запускаемой при не решении задачи с трех
попыток (наказание)
13 Дата 8 Дата проведения сеанса
В качестве примера ниже приведен фрагмент экрана из нашего программного комплекса АНГРАМ (курс грамматики английского языка)._
4.2. Над чем стоит поработать нашим читателям.
Несмотря на то, что "Спектруму" в России уже не менее десяти лет, существует ещё немало вопросов, которыми никто глубоко не занимался. Каждый может внести свой посильный вклад в общее дело. Вот прикидочный (далеко не полный) список вопросов, которыми стоит заняться нашим читателям:
•S предложить новые виды и типы обучающих программ;
•S предложить приемы поощрения и "наказания" пользователя при работе с обучающей программой;
•S предложить приемы повышения интерактивности обучающей программы; •S предложить формат "хэдера" файла прямого доступа базы знаний; •S разработать и утвердить форматы для хранения в базе следующих объектов:
• экранов и сегментов экрана в компрессированном виде;
• графических шаблонов и спрайтов;
• мемо-полей (полей переменной длины);
•S - разработать релоцируемые процедуры для работы с файлами прямого доступа:
• поиск начала нужной записи;
• поиск поля;
• считывание/запись информации в поле;
• упаковка файла после удаления промежуточной записи;
• раздвижка файла при вставке записи;
• сортировка записей по заданному полю;
• и мн. др.
•S разработать формат файла для создания библиотек процедур в объектном коде; •S подготовить программу - библиотекарь для включения новых процедур в библиотеки; S модернизировать АССЕМБЛЕР для работы с библиотеками процедур. •S подготовить программу ЛИНКЕР (редактор связей), объединяющую пользовательский объектный код с процедурами, взятыми из библиотек по их имени.
