|
|
|||||||
Пользователь: [login] | настройки | карта сайта | статистика | | |||||||
В данной статье описывается технология создания учебных курсов на базе имитационных программных моделей предметных областей. Впрочем, большая часть того, что будет сказано, относится и к созданию обычных руководств пользователя. 11.04.1994, Левенчук Анатолий
Учебный курс обычно состоит из двух составных частей: Постоянная часть:
Предметная часть (разработка которой осуществляется отдельно для каждой предметной области и модели):
1. Кто создает модель? Коллектив специалистов, создающих Модель, называется ГРУППОЙ. В Группе обычно от 2 до 6 специалистов, которые занимают различные профессиональные ПОЗИЦИИ (мы их будем именовать с прописной буквы). Для создания Модели в Группе должны быть представлены следующие позиции:
Конечно, позиции не обязательно совпадают с реальными людьми: как один человек может занимать несколько разных профессиональных позиций, так и несколько разных людей могут занять одну профессиональную позицию. Но для удобства изложения мы будем отождествлять позицию с человеком, ее представляющим. Программист является профессионалом в области создания работающих программ, он проектирует и пишет текст программы Модели (так называемую РЕАЛИЗАЦИЮ). Эксперт является авторитетом в ПРЕДМЕТНОЙ ОБЛАСТИ, для которой создается Модель. Когнитолог работает с понятийной структурой предметной области и интерфейса, служит переводчиком между Программистом, Экспертом и другими людьми. Писатель обращается к людям, для которых создается Модель и переводит безличный продукт в нечто, приемлемое людьми. Методист заботится о методике овладения создаваемой Моделью, составляет задачи, пишет методические рекомендации для использования Модели в учебном процессе и т.д. 2. Как создают модель? Модель создается в 3 этапа, на каждом из которых свой лидер разработки. Лидер определяется тем, что он знает ТЕХНОЛОГИЮ работы на соответствующем этапе. Тот, кто знает технологию, говорит, что и как делать, а остальные ему помогают.
Этап Лидер (технолог) программирование Программист понятизация Когнитолог оформление Писатель, Методист 2.1. Программирование Этап ПРОГРАММИРОВАНИЯ практически совпадает по способу и технике выполнения с традиционным пониманием. Мы считаем применимым к этапу программирования весь известный опыт создателей программных продуктов, неоднократно описанный в литературе. Не будем поэтому останавливаться на описании подробностей данного процесса. Конечно, вначале нужна концептуальная проработка исполнителя Модели, идея визуализации состояния Модели и т.д. Из методов разработки наиболее подходит быстрое прототипирование (rapid prototyping, быстрое макетирование) - создание макета исполнителя Модели с его последующей доработкой и оптимизацией. В результате программирования должен быть получен ПОЛУФАБРИКАТ - работающая РЕАЛИЗАЦИЯ Модели. Дополнительно полуфабрикат может включать некоторое количество ДОКУМЕНТАЦИИ, подготовленной его создателями. Данный этап выполняется в ходе тесного сотрудничества Эксперта и Программиста с консультациями со стороны других профессиональных позиций. Традиционная технология программирования на этом переходит к этапу сопровождения. Наша же технология требует передачи полученного полуфабриката на этап ПОНЯТИЗАЦИИ. 2.2. Понятизация Слово "ПОНЯТИЗАЦИЯ", давшее название этапу, должно напоминать о двух моментах: построении понятийного аппарата Модели и обеспечении понимания. Лидером (технологом) на данном этапе становится Когнитолог -- в конце концов, речь идет о представлении знаний. Понятизация идет в два приема: на первом шаге профодят РЕФЕРЕНЦИАЛЬНЫЙ АНАЛИЗ, на втором шаге -- находят аналогии и получают ГЛОССАРИЙ Модели. На этапе референциального анализа Группа фиксирует ПОНЯТИЯ, которые были ИСПОЛЬЗОВАНЫ при программировании и описании полуфабриката Модели. Источниками при этом являются:
Понятия фиксируются в виде списка референций (ссылок, упоминаний) объектов Модели, обычно оформляемого в виде списка слов, словосочетаний и выражений. Основным требованием, предъявляемым к списку, является его полнота: фиксации подлежат все синонимы, жаргонные выражения и т.д. Затем для групп понятий из списка референций подбирают АНАЛОГИИ -- образы из обыденной (непрофессиональной) жизни и культуры, облегчающие понимание Модели. На основе найденных аналогий осуществляют перевод списка референций в глоссарий список терминов, в которых выразимы все знания о Модели. Термины из глоссария, в отличие от первоначальных терминов и выражений из списка референций, должны получиться значительно более удобными для описания Модели и осуществления коммуникации по ее поводу. 2.3. Оформление На этапе оформления Модели на основе глоссария и аналогий осуществляются следующие процессы:
3.Технология понятизации Этап Понятизации является основным отличием предлагаемой нами технологии создания учебных курсов на базе имитационных программных моделей предметных областей от обычно применяющихся. Этот этап является в известном смысле нашим "ноу-хау". Поэтому мы остановимся на нем подробнее. На этапе понятизации Когнитолог при помощи Эксперта и Программиста должен обеспечить нахождение АНАЛОГИЙ для облегчения понимания Модели и создание ГЛОССАРИЯ Модели, содержащего термины для выражения знания о Модели. Первое, что должно быть сделано -- это фиксация ПОНЯТИЙ, которые явно или неявно БЫЛИ ИСПОЛЬЗОВАНЫ при программировании и описании Модели и интерфейса. Причем фиксируются не понятия (это идеальные объекты), а РЕФЕРЕНЦИИ (ссылки, упоминания) на эти понятия: слова, термины, выражения, описания объектов и т.п. Считается, что данные референции соответствуют важным для выражения знаний о Модели понятиям, но на этом шаге не делается предположений о том, каким термином мы будем называть это понятие -- таковые термины будут найдены на втором шаге и составят ГЛОССАРИЙ. Выполнять шаг фиксации наиболее просто в том случае, когда существует ДОКУМЕНТАЦИЯ, полученная Программистом и Экспертом на этапе программирования. Эта документация часто представляет собой литературу типа "поток сознания": Программист описывает свою РЕАЛИЗАЦИЮ Модели, не выбирая способов референции понятий Модели, нещадно путая понятия собственно предметной области и структур данных, примененных в реализации, тесно переплетая "программистские заморочки" с жаргонизмами, услышанными от Эксперта. В такой документации мы можем услышать про "кольцевой буфер траекторий частиц", "двусвязный список списков параметров специфицированных запросов" и т.д. Такая документация обычно полностью удовлетворяет других Программистов, но неоправданно сложна для любых других Пользователей, включая даже других Экспертов. Для фиксации списка референций неважен стиль написания подобной документации (например, Программист практически всегда вместо слова "изменение" пишет слово "модификация"), важно то, что большинство понятий для составляемого списка так или иначе упомянуты (и не только большинство, но даже и лишние). Заметим, что нас интересует более глубокий процесс, чем процесс составления "предметного указателя", "индекса" -- нас интересуют не только ЯВНО присутствующие в тексте термины, но и "замаскированные" референции -- те, которые могут не осознаваться авторами текста как ссылки на понятия. Иными словами, фиксировать надо не ОПРЕДЕЛЕНИЕ, а ИСПОЛЬЗОВАНИЕ понятий. Например, для двух приведенных кусочков текста ("кольцевой буфер траекторий частиц", "двусвязный список списков параметров специфицированных запросов") можно заподозрить референцию (упоминание) следующих понятий: частица запрос траектория специфицированный запрос кольцевой буфер параметр запроса список параметров запроса двусвязный список Очень вероятно, что "кольцевой буфер" -- это два слова, осуществляющих референцию (указание, ссылку) на один объект и соответствующее ему понятие. Программист в данном случае зачем-то указал на способ реализации (программистский объект типа "буфер", вид буфера -- кольцевой"). Способ референции таких понятий может сильно измениться после составления глоссария: например, можно не называть то, в чем храниться нечто, а называть содержимое: измеренные траектории (как выяснилось, в кольцевом буфере лежат именно они). Но фиксировать нужно исходные референции -- целесообразно не смешивать этапы референциального анализа и создания "правильного" глоссария. Если в тексте для референции (указания) одного объекта приводятся синонимы -- их надо фиксировать в одной строчке списка через "/". Как искать референции на понятия? Явно упомянутые термины находить легче всего. Для некоторых понятий документация содержит определение называющих их терминов, другие понятия обнаруживают себя по употреблению слов, не принадлежащих общенаучной лексике (необязательно существительных!). Признаками референции на не имеющее своего термина, но важное понятие являются "ПОВТОРИЗМЫ": в тексте часто повторяется какой-либо оборот, может даже целое предложение. Каждый такой оборот должен вызвать подозрение на "РАЗВЕРТКУ" пропущенного термина (употребление вместо термина его развернутого определения). Если Вы встретили в тексте несколько раз выражение "тот, кто ведает мед", то его целесообразно зафиксировать в списке. "СВЕРТКУ" же в слово "медведь" можно провести на следующем шаге - шаге составления глоссария. Но документация существует не всегда и она, как правило, не содержит референции на все необходимые для объяснений и коммуникации по поводу Модели понятия. Другой источник -- сама реализация Модели. Надписи на экране, элементы изображения, всякие атрибуты (жирность, яркость), тексты сообщений модели, имена команд, наименование параметров команд -- все связанные с этими объектами референции необходимо фиксировать. Последний источник -- общение с Экспертом и Программистом. Наилучший прием тут -- спросить их, "как пользоваться...", или "как работает/устроено ...", или "что такое...". Объяснение, следующее за этим, ничем не отличается по его типу от текстов рассмотренной ранее документации (можно записать объяснения на магнитофон, расшифровать и работать с полученным текстом - но так делают редко). Это тот же "поток сознания", только степень подробности изложения можно регулировать в диалоге. Опытный Когнитолог просто беседует с коллегами в режиме активного фильтра: каждое подозрение на референцию нового понятия он обсуждает, а в процессе обсуждения появляются упоминания новых понятий и т.д. Обращайте особое внимание на жаргонизмы и сленг: если некоторые понятия необходимы для коммуникации, а в профессиональном литературном языке не предусмотрена лексика для их референции, то они, как правило, проявляют себя в жаргоне. ГЛОССАРИЙ представляет собой список терминов, достаточных для удобного представления и понимания понятий Модели, особенностей ее реализации и интерфейса. Главным критерием полноты глоссария является его достаточность для обеспечения любой коммуникации по поводу этой Модели. Под достаточностью для любой коммуникации мы понимаем соблюдение принципа "телефона" -- нужно уметь вербально выразить любое состояние Модели и любые с ней действия (как известно, по телефону нельзя сказать: "перемести курсор сюда", "посмотри на это" -- все "сюда" и "это" должны иметь имена). Нужно давать людям способы и шаблоны "проговаривания", строить им жаргон. Программист и Эксперт, как правило, совершенно не заинтересованы в понятизации: после программирования полуфабриката их интерес к разработке резко падает. Нужны большие усилия, чтобы заставить их работать с Когнитологом, особенно, если они впервые участвуют в понятизации. Легче заставить их провести оформление (доработку полуфабриката, внесение изменений в реализацию), чем участвовать в определении списка этих изменений -- переводе Модели на язык Пользователя. Составление глоссария (перевод с языка разработчиков Модели на язык Пользователя) ведется по группам понятий. Группы выделяются интуитивно на основе списка референций. Для каждой группы выполняются следующие два шага:
В результате вместо лексики "птичьего языка", которая появилась "сама" для обслуживания процесса программирования (для общения Программистов и Экспертов), и которую использует (и к которой привыкла и не хочет менять) Группа в момент получения полуфабриката, появляется специально сконструированная лексика для обслуживания процесса использования понятийного аппарата Модели. Эта новая лексика должна быть немедленно использована в дальнейших обсуждениях (заодно она проходит дополнительное тестирование, а разработчики "вживаются" в нее). Не следует продолжать использовать в рабочем общении Группы старые слова и выражения вместо новых терминов. Если использование новых терминов будет неудобным, значит необходимо повторить перевод пока новое множество терминов не сможет удобно обслужить ВСЕ коммуникации. Перевод лучше всего проводить после того, как полуфабрикат реализации готов и список референций получен. Даже если деятельность по переводу проводилась в процессе программирования, все равно хорошо в конце сделать этот шаг отдельно: хотя бы для контроля глоссария. При переводе получается некоторый "приварок": продвижение в ДЕМИСТИФИКАЦИИ (облегчении понимания) предмета за счет улучшения его понятийного аппарата и упрощения лексики. Это безусловно разрушает кастовые профессиональные границы и вызывает негодование у большинства Экспертов. (Гипотеза методологов: сложная терминология профессионалов, запутанные представления нужны им для осознания собственной значимости и особенности как некоторой избранной касты. И только тот, кто за несколько лет овладеет всей заумью неудобной терминологии, будет допущен к профессиональному общению). На самом деле, это проблема: имеет ли приоритет скоростное обучение профессиональному мышлению и навыкам при отсутствии возможности профессиональной коммуникации? Ведь может быть такое, что предложенная при обучении система понятий удобнее традиционно применяющейся, обслуживает все потребности, но наглухо изолирует ученика от профессионального сообщества. Когнитолог должен решать эту проблему в каждом конкретном случае. Так как научная лексика той или иной предметной области, понятийный аппарат развиваются обычно исторически, путем наслоения разных вариантов терминологии, способов описания и т.д., Когнитолог обычно видит все несовершенство понятийного аппарата и способов референции предметной области. Но Эксперт часто сопротивляется любым изменениям. Тем не менее, понятизация предлагает следующий принцип: выбирается самый простой из существующих вариант терминологии предмета, который тщательно структурируется и может даже быть слегка переделан. ПОНИМАНИЕ имеет приоритет перед ТОЧНОСТЬЮ ПРОФЕССИОНАЛЬНОЙ ТЕРМИНОЛОГИИ, ибо учим ПРОФЕССИОНАЛЬНОМУ МЫШЛЕНИЮ, а не СУЩЕСТВУЮЩЕЙ ПРОФЕССИОНАЛЬНОЙ КОММУНИКАЦИИ. Некоторые замечания для выбора терминов
|
[email protected] | Московский Либертариум, 1994-2020 | |