Читаем Фреймы для представления знаний полностью

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

<p>3.6. Аналогии и альтернативные описания</p>

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

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

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

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

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

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

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT