Содержание к диссертации
Введение
1 Обзор существующих подходов к исследуемой проблеме 22
1.1 Решение задач в языках императивного типа 27
1.2 Решение задач в языках декларативного типа 31
1.3 Доказательное программирование 42
1.4 Особенности подхода от задач 48
1.4.1 Первый уровень общности 61
1.4.2 Второй уровень общности 64
1.4.3 Третий уровень общности 68
2 Теоретические основы языков спецификаций задач 81
2.1 Концепция технологии построения языков спецификаций классов задач, ориентированных на пользователей 82
2.2 Интеллектуальные ресурсы и интеллектуальные запросы пользователей 83
2.2.1 Интеллектуальные ресурсы пользователей 84
2.2.1.1 «Парадокс кучи» 88
2.2.1.2 Оценка интеллектуального ресурса пользователя 89
2.2.1.3 Интеллектуальный ресурс сообщества пользователей 90
2.2.2 Интеллектуальные запросы пользователей 91
2.2.1 Интеллектуальные запросы идеального пользователя 92
2.2.2 Интеллектуальные запросы реального пользователя 95
2.3 Языки и логики спецификаций задач для идеальных пользователей 96
2.3.1 Языки 99
2.3.2 Х-логики 113
2.3.3 Xsym- логики 116
2.3.4 Немонотонность некоторых Х-логик 119
2.3.5 Представления логик спецификаций задач и конструктивные системы 122
2.3.5.1 Представления Х-логик 122
2.3.5.2 Конструктивные системы 124
2.4 Языки и логики спецификаций задач для реальных пользователей 130
2.4.1 Яех-языки 130
2.4.2 Логики 134
2.4.3 (Xsym, res)- логики 137
2.4.4 Немонотонность некоторых (X, гах)-логик 140
2.5 Представления логик спецификаций для реальных пользователей 143
2.5.1 Представления (X, res)-novm 143
2.5.2 Лея-конструктивные системы 144
3 Алгоритмические проблемы языков спецификаций задач 146
3.1 Измерение интеллектуальных ресурсов пользователей 147
3.1.1 Алгоритм измерения интеллектуальных ресурсов пользователей 147
3.1.1.1 Терм-калибровка 152
3.1.1.2 Шкала уверенности TS 162
3.1.2 Измерение т3(р,Т) ресурса res(p,Т) 164
3.1.3 Измерениет2(р,Т) 165
3.1.4 Измерение nti(p,Т) 167
3.2 Особенности организации диалога в языках спецификаций задач 168
3.2.1 Организация диалога с реальным пользователем 169
3.2.2 Длина текста и сложность текста 169
3.2.3 Синтаксис, семантика и прагматика 171
3.2.3.1 Синтаксис 174
3.2.3.2 Оценка синтаксической сложности текста 177
3.2.4 Особенности формулировки задачи в языках спецификаций 182
3.2.4.1 Тестирование 183
3.2.4.2 Пример формальной спецификации задачи 184
3.2.5 Некоторые комментарии и обоснования 192
3.2.6 Реализационные аспекты диалога 196
4 Реализационные аспекты применения языков спецификаций классов задач, ориентированных на пользователей 199
4.1 Применение языков спецификаций задач в экономике и технике 200
4.1.1 Спецификация экономической задачи «Инвестиционное проектирование и управление проектами» 201
4.1.2 Реализация интернет-проекта «Инвестиционный менеджмент (в инновационной сфере) 206
4.1.3 Спецификация технической задачи «Системные основы информатики» 219
4.1.4 Реализация программы «Системные основы информатики» 222
4.1.4.1 Комплекс обучающих программ «Конструктор IBM PC» 226
4.1.4.2 Аппаратные основы информатики. «Конструктор IBM PC» 231
4.1.4.3 Работа с конструктором IBM PC 236
4.1.4.4 Конфигурирование персонального компьютера 238
4.1.4.5 С ЧЕГО начать и КАК это делается 243
4.1.4.6 Лабораторный практикум 245
4.1.4.7 Задания лабораторного практикума 245
4.2 Инструментарий для реализации языков спецификаций задач 251
4.2.1 Измерение интеллектуальных ресурсов пользователей. Система «PLAST» 251
4.2.1.1 Определение интеллектуальных ресурсов пользователя 255
4.2.1.2 Схема постановки задачи пользователем/? 259
4.2.2 Среда спецификационной деятельности. Система «СИГМА-ТЗ» 261
4.2.2.1 Схема решения задач в системе «Сигма-ТЗ» 262
4.2.2.2. Формирование исходных спецификаций в «Сигма-ТЗ» 264
4.3 Инструментальный комплекс языков спецификаций задач 280
4.3.1 Архитектура инструментальной системы «ТеКоРЗ» 280
4.3.1.1 Базисный уровень технологического комплекса решения задач 282
4.3.1.2.Модули 284
4.3.1.3 Управляющий массив 287
4.3.1.4 Организация программного обеспечения на базисном уровне 288
4.3.1.4.1 Решение задач на базисном уровне 289
4.3.1.4.2 Технологический этап решения задач в «ТеКоРЗ» 290
4.3.1.4.3 Свойства качественных решений Г-задач 294
4.3.2 Инструмент отбора стратегий исполнения модулей 295
4.3.2.1 Схема работы ТГ-конструктора 297
4.3.2.2 Структура и состав ТС-конструктора 302
Заключение 305
Список используемых источников 307
- Решение задач в языках декларативного типа
- Языки и логики спецификаций задач для идеальных пользователей
- Пример формальной спецификации задачи
- Реализация интернет-проекта «Инвестиционный менеджмент (в инновационной сфере)
Введение к работе
Необходимость в разработке новых методик постановки и решения задач на компьютере объясняется тем, что появление относительно дешевых, малогабаритных, надежных и быстродействующих персональных компьютеров [98] обеспечило их доступность массовому пользователю. Появилась реальная возможность обеспечить каждого специалиста персональным компьютером, способным решать многообразные, в том числе и достаточно сложные задачи [32]. Данная ситуация наступила настолько быстро, что возник разрыв между необходимой и фактической подготовленностью основной массы потенциальных пользователей, способных ставить и решать свои задачи [95] на персональных компьютерах. Причин этому несколько:
недостаточные знания, умения и навыки постановки задачи в точных математических терминах;
неумение выбирать или разрабатывать эффективные алгоритмы решения задачи;
незнание формальных языков программирования и инструментальных программных средств;
отсутствие знаний, умений и навыков перевода постановки своей задачи с языка предметной (профессиональной) области на «язык компьютера» и другие.
И если некоторые из указанных проблем можно разрешить сравнительно быстро (например, изучив язык программирования [130]), то решение других проблем (например, формулировка задачи в терминах предметной области пользователя и ее точный перевод на формальный язык, а, далее, на «язык компьютера» [82]) вызывает серьезные затруднения.
Отметим, что всегда одной из центральных проблем области человеческих знаний и деятельности была и остается проблема корректной поста-
ноеки задачи, в самом широком смысле этого слова [9, 27, 28]. Эта проблема относится как к решению повседневных бытовых, так и самых сложных научных и производственных задач. С момента появления вычислительных устройств, и особенно с появлением персональных компьютеров, эта проблема еще более обострилась, поскольку теперь к решению задач приобщилась еще большая аудитория (к профессионалам математикам и программистам добавились, так называемые, непрограммирующие профессионалы -конечные пользователи [ПО, 120]). Последние же составляют подавляющую часть работающего населения мира.
Можно выделить два подхода в решении вышеперечисленных проблем, которые существуют в настоящее время в информатике. Один подход базируется на исчислении задач. Когда из множества элементарных задач, не вызывающих сомнения в отношении их осмысленности, конструируются более сложные задачи. И хотя осмысленность такой вновь построенной задачи считается (по умолчанию) бесспорной - этот факт вызывает подозрение. Почему же тогда так часто возникают конфликты между заказчиками и разработчиками программного обеспечения?
Другой подход основан на «поле» осмысленных задач данной предметной области пользователя. В отличие от предыдущего подхода, конструирование задач здесь не осуществляется, а задача рассматривается целиком и, более того, она ставится в соответствие задачам из блока задач предметной области. В этом случае нет необходимости в какой-либо дополнительной проверке на ее осмысленность, поскольку для пользователя она осмысленна с самого начала. Конечно же, остается определить: «Что такое осмысленная задача?» При этом подходе задача считается понятной пользователю, если он может любой предъявленный ему результат расчетов на компьютере признать решением своей задачи, или признать нерешением своей задачи. В работе рассматривается этот второй подход, для которого разработаны языки спецификаций задач, ориентированные на пользователя.
Традиционно в процессе решения задач на компьютере участвуют несколько групп специалистов. С одной стороны - это постановщики задач, они являются заказчиками программного обеспечения, а с другой стороны -программисты (системные, прикладные, конструкторы программных систем, аналитики и т.д.). Отсюда и возникают две основные проблемы в решении задач на компьютере. Они связаны с разрешением проблемы взаимопонимания, возникающими как между различными группами программистов (системными, прикладными, конструкторами), так и между заказчиками и разработчиками программного обеспечения.
Решение проблемы взаимопонимания между различными группами программистов ищут на пути разработки различных технологий программирования [4, 12-14, 16-17, 42, 49, 90], а решение проблемы взаимопонимания между заказчиками и программистами ищут на пути разработки новых методик постановки задач, например [26-31, 37, 39, 43, 75], предполагающих их решение на компьютере.
Языки спецификаций задач, ориентированные на пользователей, относятся ко второй группе проблем, а именно, решение проблемы точной постановки задачи из данной предметной области, следовательно, и на разрешение проблемы взаимопонимания между заказчиками и разработчиками.
При этом от пользователя требуется точная постановка задачи, а от программиста - разработка надежного программного обеспечения по задаче, поставленной пользователем, при обязательном указании программисту критерия оценки правильности работы программы.
Вместе с тем, очень часто задачи оказываются настолько сложными, а на поиск решений отводится так мало времени (иногда доли секунды), что возникает необходимость в автоматизации процесса решения задачи на компьютере по ее спецификации. Например, такие задачи постоянно возникают в управлении сложными химическими, термоядерными и технологическими процессами в производстве; задачи, решаемые в управлении косми-
ческими аппаратами, воздушными и морскими судами; при решении целого ряда военных задач и во многих других ситуациях. Цена ошибки при этом резко возрастает и часто становится сопоставима с последствиями природных катастроф.
Все это еще более актуализирует проблему разработки языков спецификаций задач, ориентированных на пользователей [86]. При этом специфика работы пользователя требует от него самостоятельной точной постановки задачи, а от программистов - эффективной реализации программного обеспечения по заказу пользователя.
Таким образом, в схеме решения задач на компьютере на первое место выходит процесс точной постановки задачи, предполагающий решение проблемы разработки языков спецификаций задач, ориентированных на конечных пользователей и особенно на тех из них, кто постоянно решает свои задачи на компьютере.
До последнего времени от пользователя требовалось не столько умение точно поставить свою задачу для ее решения на компьютере, сколько умение описать ее программисту или постановщику, переадресовав последним ее точную постановку. Другой подход: пользователю предлагали изучить язык программирования («вторая грамотность» [36, 37]) и изучив возможности компьютера по решению определенного класса задач, самостоятельно разработать требуемое программное обеспечение. Иначе говоря, самому поставить и решить свою задачу. Естественно, что при этом пользователю нужно было знать не только и, может быть даже не столько то, ЧТО он хочет, сколько уметь точно описать КАК желаемое ЧТО должно быть реализовано на компьютере. Вот эти ЧТО и КАК и явились главной преградой на пути массового применения персональных компьютеров.
Здесь и далее: термин ЗАЧЕМ отвечает за прагматику; термин ЧТО -за семантику; термин КАК - за синтаксис.
Заметим, что подавляющее большинство пользователей персональных компьютеров относится к так называемым «непрограммирующим профессионалам», т.е. к специалистам, работающими с уже готовым программным обеспечением [35]. Именно они, представители всех сфер человеческой деятельности, и являются основными постановщиками задач, предполагающих их решение на компьютерах. Их часто именуют «конечными пользователями» [120] (чтобы отличать от программистов, исполняющих роль посредников между пользователем и компьютером). Естественно, что когда каждый специалист в своей предметной области станет конечным пользователем, никакой армии программистов-посредников не хватит. Попытки обучить всех программированию, возведя его в ранг «второй грамотности» не дали положительных результатов по вполне понятным причинам (нельзя всех обучить программированию).
Более рациональным представляется научить пользователя точно ставить и решать свои задачи на компьютере, а за профессиональными программистами оставить функции создания удобных средств общения пользователя с компьютером, которыми мог бы легко (без серьезных усилий) овладеть любой специалист в своей предметной области, не знакомый с программированием, но знающий, конечно, что именно может дать применение компьютера в его профессиональной деятельности [45].
Иначе говоря, возникает острая необходимость в разработке методов и средств автоматизированного (человеко-машинного) процесса точной постановки и решения задач на компьютере.
Многочисленные попытки решить данную проблему автоматизации построения алгоритмов и программ по спецификациям задач, привели к появлению и широкому распространению языка логического стиля - ПРОЛОГ [51,52,117,129,131,148].
В отличие от языков фон-неймановского типа [11, 104, 124, 130] (когда программист вынужден был смотреть на решение своей задачи как на про-
цесс планирования вычислений) в логическом программировании [10, 31, 51-52, 60, 91, 131, 148] сознательно переходят на разделение описания задачи (в специальных терминах) от метода ее решения на компьютере. Иначе говоря, происходит переход от императивных языков постановки и решения задач, к декларативным языкам. Это позволило применить к описанию задачи универсальный способ вычислений функций и отношений, составляющих содержание задачи (метод резолюций). Правда, на практике вновь происходит смешение чисто логических и вычислительных аспектов вследствие жесткого детерминизма исполнения логических программ.
Помимо логического программирования в настоящее время широко используются и другие идеи автоматизации построения программ, заимствованные из математической логики. Подробный анализ существующих на сегодня методов решения задач на компьютере приведен в обзоре (см. главу I).
И все же решение проблемы, связанной со спецификационными аспектами, возникающими при постановке задачи, допускающими ее решение на компьютере, остается главным.
В работе предлагается искать решение данной проблемы, построения языков спецификаций задач, ориентированных на пользователей на пути учета интеллектуальных ресурсов пользователей и их соответствия интеллектуальным запросам данной категории пользователей. При этом под интеллектуальными ресурсами пользователей предлагается понимать их профессиональные знания, умения и навыки и оценивать по одной из характеристик: по максимальной длине текста, полученного в результате расчетов на компьютере, которую пользователь способен распознать как решение или как нерешение своей задачи. А под интеллектуальными запросами будем понимать сами задачи, решаемые пользователями. При этом все решения, принимаемые пользователем, должны быть ответственными, а средства общения, создаваемые для него - удобными для применения.
Таким образом, возникают следующие задачи исследования.
Изучить принципиальную возможность разработки теории, методологии и технологии постановки и решения задач на компьютере самими пользователями в полном соответствии с их интеллектуальными ресурсами и их интеллектуальными запросами.
Разработать и теоретически обосновать методику и процедуры оценки интеллектуальных ресурсов и интеллектуальных запросов различных категорий пользователей.
Разработать теоретический аппарат и методику организации диалога с пользователем на языке его предметной области, как при постановке задачи, так и при анализе результатов ее решения.
Разработать архитектуру инструментальной программной системы, обеспечивающей поддержку языков спецификаций задач, ориентированных на пользователей.
Для позиционирования места работы в ряду других следует отметить следующие особенности.
I. Рассматриваемые в работе языки спецификаций задач, ориентированные на пользователя, направлены на разрешение проблемы взаимопонимания и разнесения ответственности между заказчиками (постановщиками задач, пользователями) и разработчиками программного обеспечения (программистами), т.е. рассматривается проблема общения заказчиков с разработчиками. При этом за заказчиком остается право самостоятельно осуществлять точную постановку задачи, а за разработчиком (если это необходимо) - создавать адекватное поставленной задаче программное обеспечение. Окончательное решение задачи на компьютере остается за самим пользователем. Общение заказчика с разработчиком ведется только на уровне синтаксиса. Иначе говоря, заказчик несет полную ответственность за точность постановки задачи, а разработчик отвечает за точность синтаксической реализации задачи в виде программного продукта.
II. Понятность задачи для пользователя классифицируется тремя следующими уровнями общности рассмотрения понятия задачи:
«Г-задача» - задача понятна пользователю, т.е. он может сформулировать критерий, позволяющий эффективно отделять решение задачи от ее нерешения;
«Г-полузадача» - при постановке задачи явно указан критерий определяющий только решение задачи, т.е. решения задачи составляют рекурсивно перечислимое множество, а нерешения - никак не определяются;
«Г-томление» - пользователь может указать только нерешение задачи. Что же при этом является решением задачи и как это определяется ничего не сказано. Так, например, в 1932 году Колмогоров [170] предложил интуиционистское пропозициональное исчисление трактовать как исчисление задач. При этом он не определил ни что такое задача, ни что такое решение. Импликацию он истолковывал следующим образом: импликация а -» b {а влечет Ь) означает, что имеется общий метод сведения задачи b к задаче а. Затем Клини предложил уточнить термин «сведение» как алгоритм, который по каждому решению задачи а выдает решение задачи Ъ.
Замечание 1. Два последних случая будем связывать с принятием безответственных решений, и рассматривать их не будем.
Замечание 2. Конструктивный подход в определении задачи совпадает с классическим определением в том случае, когда задача осмысленна, т.е. является Г-задачей.
Теперь укажем некоторые ограничения применения рассматриваемой методики, опирающейся на языки спецификаций задач, ориентированные на пользователя.
1. В работе рассматриваются только осмысленные задачи из некоторой предметной области, которые являются в некотором смысле равномерными, единообразными. Например, как при рассмотрении относительной вычислимости. Если есть произвольная исходная функция, о которой что-
либо известно и есть алгоритм сведения исходной функции к результирующей (например, примитивно-рекурсивной относительно этой исходной), то можно делать какие-то вразумительные суждения и о результирующей функции. Иначе говоря, такие задачи, для которых заказчик явно указал критерий различения решения и нерешения задачи. Все другие случаи (например, когда такой критерий явно сформулировать нельзя) в данной методике не рассматриваются.
Принципиальный отказ от универсальности в определении языков спецификаций задач в пользу эффективности. Чем плоха универсальность и какие здесь могут быть «подводные камни» достаточно хорошо известно и с теоретической и с практической стороны.
Проблема «машинного нуля» [26] или презумпция неточности. Кто может гарантировать, что если известен результат и известен путь его получения, то можно отправляясь от результата однозначно прийти к исходным посылкам (нарушение транзитивности)?
В основе проводимых исследований (предшествующих теоретическому обобщению) лежит значительный этап практических разработок программных систем, хотя он и не является единственно определяющим фактором. Анализ данного этапа позволил выделить некоторые особенности решения задач на компьютерах, которые были положены в основу рассматриваемого подхода от задач. Так, например, а) разработанное программное обеспечение только тогда долго и эффективно эксплуатируется, когда в постановке задачи и формировании технического задания на разработку программного обеспечения непосредственное участие принимает сам заказчик; Ь) сам процесс постановки задачи оказывается успешным тогда, когда язык общения заказчика с исполнителем бывает с одной стороны простым, удобным и понятным, а с другой - точным и формальным; с) разработанное программное обеспечение только тогда эффективно, когда при его разработке отказываются от принципа универсальности; d) было замечено также, что
знания о предметной области пользователя не монотонны по отношению к его знаниям о задачах из той же самой предметной области; е) пользователи, как правило, в практических действиях руководствуются не предметной областью (имеется ввиду модель предметной области [109]), а оперируют понятием, которое определено в работе как «поле» задач этой предметной области.
Эти и некоторые другие особенности решения задач на компьютерах позволяют по иному взглянуть на сами понятия: задача, программа, «жизненный цикл» программного обеспечения; спецификация задачи; технология решения задачи на компьютере и др.
Конечно же, в реальной практике решения задач не только указанные выше особенности играют существенную роль, однако в массовых случаях (при решении задач анализа данных и принятия решений, при разработке информационных систем, систем управления различными процессами, при создании обучающих систем и решении многих других задач) именно они играют определяющую роль. При этом хотелось бы, чтобы программист не уподоблялся тому врачу, который ставит диагноз только по одному из симптомов (не проповедовал бы «ползучий эмпиризм»).
Теперь несколько слов об ограниченности применения разработанной технологии построения языков спецификаций классов задач, ориентированных на пользовтаелей.
I. Выбранный в качестве основного, аксиоматический метод построения теории, конечно же обладает рядом ограничений в практическом при-менении (от выбора системы аксиом существенно зависит вся дальнейшая работа). Например, при выборе систем аксиом часто необходимо учитывать вес каждой аксиомы в выбранной системе. Однако во многих практических случаях аксиоматический метод позволяет достичь желаемых результатов (например, когда идеальный объект очень близок к реальному объекту). Заметим, что аксиоматическая система рассуждений обладает следующим
свойством: она может быть либо точной, либо никакой. В рассматриваемой методике это обстоятельство играет существенную роль и учитывается в определении квалификации пользователей, т.е. его интеллектуальных ресурсов и интеллектуальных запросов. Подтверждением сказанному могут служить следующие примеры.
Пример 1. Чем отличается доказательство того, что пятый постулат геометрии Евклида эквивалентен теореме о сумме внутренних углов треугольника, от попыток геодезическим способом измерять сумму внутренних углов треугольника»?
Пример 2. Если в качестве исходных аксиом выбрать заповеди «Не убий» и «Не прелюбодействуй», то они явно будут иметь разный вес, по крайней мере, не будут эквивалентными.
Таким образом, недостаток аксиоматического метода, который может привести к неприятным ситуациям, заключается именно в том, что вообще-то аксиомы должны иметь разные веса (например, в смысле того, как часто вы пользуетесь аксиомой, у которой «вес сомнительности» больше, чем у других используемых аксиом). Это особенно важно при решении задач, связанных с деятельностью, или с мыследеятельностью, когда при аксиоматическом методе это свойство веса аксиом утрачивается. Решение этой проблемы остается за заказчиком.
Вместе с тем, чем точнее система аксиом отражает предметную область, тем решение задачи будет точнее.
Другой пример. Учет длины доказательства. Все может быть формально правильно построено, но результат может оказаться неправильным в интерпретации заказчика и именно потому, что недоучтены веса используемых аксиом. Поэтому при оценке интеллектуальных ресурсов пользователей необходимо учитывать не только длину правильно распознаваемых выводов, но и, например, вес используемых в доказательстве аксиом. Заметим, что исследование зависимостей интеллектуальных ресурсов пользователей от
весов аксиом и других возможных характеристик выходит за рамки данной работы, хотя и имеет право на существование.
Следует заметить, что и длина правильно распознаваемых выводов тоже кое-что говорит об интеллектуальных ресурсах пользователя, особенно в тех случаях, когда мы говорим о формульных задачах на доказательства, понимаемым всеми участниками процесса решения задач на компьютере на интуитивном уровне.
Заметим, что понимание ограниченности аксиоматического метода в смысле Геделя в данном случае неприемлемо. Это нечто совсем другое. Отсюда вывод: при аксиоматическом изложении трудно добиться того, чтобы все аксиомы были равно приемлемы. Пока же предлагается исходить из рав-новзвешенности и равноприменимости аксиом для заказчика.
Желательно учитывать не только то, КАК будет работать система, если бы она работала идеально, но и ЧТО будет, если она будет работать плохо. Что будет, когда система будет откланяться от того, что в ней предусмотрено? Видимо, в этих случаях необходимо предусмотреть некоторые другие механизмы организации взаимодействия заказчиков и исполнителей, и другой методики решения задач на компьютерах. Здесь также играют роль предпочтения неуниверсальности. Это же может выражаться и в виде нечеткости самих понятий, но в этом случае предлагается поступать особым образом, описанным далее в главе III. Такие ситуации в данной работе не рассматриваются и не исследуются, хотя на практике они также могут встречаться.
Желание обеспечить пользователя методикой, теорией и технологией постановки и решения задач на компьютере предполагает, что и сам пользователь и спецификатор обладают необходимыми знаниями о своих предметных областях. Хотелось бы научиться как-то, оценивать их, так называемые, интеллектуальные потребности (задачи, которые они решают) и их интеллектуальные возможности (ресурсы, которыми они обладают). Это
позволит получить ответ на вопрос о том, насколько точно (адекватно) пользователь понимает свою задачу, чтобы иметь возможность принимать ответственные решения, как при постановке задачи, так и при оценке результатов ее решения. Один из способов такой оценки интеллектуальных ресурсов и интеллектуальных запросов пользователей описан в главе III.
Если пользователь получил решение своей задачи, и оно его не удовлетворяет, то можно рассмотреть две ситуации: первая - мы считаем, что пользователь сам виноват во всем; вторая - мы признаем, что пользователь может не знать всех особенностей компьютерной реализации и соответственно не может указать их в спецификации своей задачи. В этом случае исполнитель может включить в реализацию программы фрагменты, способные повысить эффективность программного обеспечения, решающего задачу пользователя (например, алгоритмические логики [39]). Однако при этом необходимо быть особенно осторожным и учесть следующее обстоятельство. Может возникнуть следующая опасная ситуация - берется конкретная задача, потом она обобщается, затем конкретизируется и в результате решается уже совсем другая задача, не та которую имел ввиду пользователь.
В рассмотрение введен критерий, отделяющий решение задачи от ее нерешения. Но может быть в рассматриваемом «поле» задач U есть и еще что-то, что нашим критерием не улавливается, (что не является ни решением и ни нерешением)? Тогда имеет смысл говорить о системе критериев, поскольку меняется само понятие истины. Здесь можно вспомнить теорему Геделя, о существовании арифметической формулы, которая истинна, но не доказуема в арифметике: если она и истинна, то в каком-то другом, не таком смысле, что а + Ъ = Ъ + а.
Для решения перечисленных выше задач имелись следующие предпосылки. Методологическую основу исследований составляет анализ понятий задачи и «поля» задач, рассматриваемый в рамках нового подхода к философии математики [41], а теоретическую базу исследований составляет мате-
матический аппарат относительно конструктивных систем, адаптированный применительно к языкам спецификаций задач [105, 111]. Технологические основы апробированы при решении практических задач и описаны в [55,65-67,70-71,73-74].
Научная новизна. Впервые предъявлен, разработан и согласован с формальным определением осмысленности задачи язык спецификаций классов задач, ориентированных на пользователя. В отличие от других языков спецификаций задач (например, интуиционистской логики исчисления задач, когда при конструировании задач из элементарных задач теряется осмысленность задачи), в данном подходе этот существенный момент учтен. Дано формальное определение осмысленной задачи. Это значительно более узкое понятие, чем понятие задачи, употребляемое в общематематическом смысле. В результате предложено вместо исчисления задач употреблять понятие «поля задач» - алгебраическая система, носителем которой является множество задач, на которых заданы отношения и операции, причем так, что эти отношения и операции интересны пользователю.
Осмысленность задач разбита на два класса: 1) осмысленность задачи в принципе и 2) осмысленность задачи для реального пользователя. Во втором случае учтено то, что осмысленность задачи для реального пользователя зависит от его интеллектуальных возможностей. Получены достаточно любопытные результаты - в частности доказана теорема, свидетельствующая о немонотонной зависимости знаний пользователя о предметной области и знаний пользователя о задачах из этой же предметной области.
Дано определение интеллектуальных потребностей (интеллектуальных запросов) пользователя в виде так называемого «поля» задач. Дано определение интеллектуальных возможностей (интеллектуальных ресурсов) пользователя, согласованных с его интеллектуальными потребностями, предста-вимые как измеримые характеристики и приведена процедура их измерения. Ресурс (данного человека) р относительно (данной аксиоматической систе-
мы) Т есть тройка res(p,T) =(mj(p,T), m2(p,T), m3)(p,T)) натуральных чисел mi(p,T), m2(p,T), m3(p,T) таких, что:
mi(p,T) — наибольшая длина доказательств в Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку степени убедительности для данного человека/»;
rri2(p,T) — наибольшая длина последовательностей символов алфавита языка системы Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку (субъективной уверенности р в) безошибочной распознаваемости их р как формул (или не формул) языка системы;
гпз(р,Т) — таких, что и т2(р,Т), но применительно к термам. Здесь Т описание предметной области пользователя.
Разработаны основы организации интерфейса с пользователем на языке, являющемся проекцией языка предметной области, обеспечивающем пользователю комфортные условия при точной постановке и решении своих задач на компьютере.
Предложена архитектура и принципы организации инструментальной программной системы поддержки языков спецификаций классов задач, ориентированных на пользователей, в основу которых положены оригинальные идеи В-модуля и Управляющего Массива.
Основные результаты, выносимые на защиту.
Технология построения языков спецификаций классов задач, ориентированных на пользователей, обеспечивающая конечному пользователю удобную, самостоятельную и точную постановку осмысленной задачи, учитывающая особенности ее решения на компьютере.
Процедура оценки интеллектуальных ресурсов и интеллектуальных запросов пользователей при постановке и решении задач своей предметной области. Данная процедура имеет самостоятельный интерес, например, при
оценке профессиональных качеств каждого специалиста в коллективе разработчиков программного обеспечения.
Теоретические основы организации удобного для пользователя диалога в терминах его предметной области, при самостоятельной постановке и решении задач на компьютерах.
Архитектура инструментального комплекса в технологии языков спецификаций классов задач, ориентированных на пользователей, базирующаяся на понятии В-модуля и Управляющего Массива.
Диссертация состоит из введения, четырех глав, разбитых на параграфы и заключения. Параграфы разбиты на пункты.
Во введении рассматривается актуальность проведенных исследований, сформулированы задачи исследований, указана их новизна, а так же теоретическая и практическая ценность.
В первой главе приведен обзор методов и средств, предшествующих исследованиям, связанным с разработкой языков спецификаций классов задач, ориентированным на пользователей. Проводится сравнение предлагаемого подхода с методами логического и семантического программирования, и указываются его особенности.
Во второй главе приводится теоретическое и методологическое обоснование технологии построения языков спецификаций классов задач, ориентированных на пользователей, опирающиеся на новый подход к философии математики, предложенный Ю.Л Ершовым [41]. Рассматривается аппарат относительно конструктивных систем [111], адаптированный применительно к языкам спецификаций задач, ориентированных на пользователя и обосновывается корректность вводимых понятий.
В третьей главе рассматриваются процедуры оценки интеллектуальных ресурсов пользователей и их соответствия интеллектуальным запросам пользователей, а также рассматриваются особенности организации диалога с пользователем по оценке его интеллектуальных ресурсов при постановке им
задачи, для ее последующего решения на компьютере. Процедуры оценки интеллектуальных ресурсов могут иметь самостоятельный интерес, как при оценке профессиональных качеств специалистов, так и в других случаях, например, при оценке эффективности применяемых методов обучения.
В четвертой главе рассматриваются практические особенности применения технологии построения языков спецификаций классов задач, ориентированных на пользователей в задачах экономики, техники и преподавания информатики, а также приведены проекты и программные системы поддержки технологического комплекса, реализующего методологию подхода от задач. Указываются особенности организации программного обеспечения, создающего комфортную среду для пользователя, самостоятельно ставящего и решающего свои задачи на компьютере с использованием языков спецификаций задач.
В заключении приведены результаты исследований автора, выносимые на защиту.
По результатам, изложенным в диссертации, имеется 26 публикаций [44-46, 54-55, 65-88, 113, 180], в том числе одна монография. Основные результаты опубликованы в журналах реестра ВАК.
Результаты исследований докладывались на Втором Сибирском Конгрессе по прикладной и индустриальной математике, в 1996 г., в г. Новосибирске; на ряде Международных конференций «Новые информационные технологии в университетском образовании», в Новосибирске, в 1994, 1995, 1997, 1998, 2001 и 2003 гг.; в Томске, в 2000 г.; в Кемерово, в 2002 г.; Of the second International scientific conference in therepublic of Kazakhstan "The informative technologies and control", KazITC'99, Almaty, 1999 г., на III Международной конференции «Идентификация систем и задачи управления» (SICPRO'04), в 2004 г., в Москве; на 3-й Интернет-конференции, в Тамбове, в 2002 г.; на III Всероссийской конференции «Математика, информатика, управленеи» в 2004 г., в Иркутске; на четвертой Всероссийской конферен-
ции с международным участием «Новые информационные технологии в исследовании сложных структур», в Томске, в 2002 г., на научно-методической конференции СибГУТИ, в 2004 г., в Новосибирске.
Были сделаны доклады в ведущих научных центрах: в Институте математики СО РАН (г. Новосибирск); в Институте вычислительных технологий СО РАН (г. Новосибирск); в Институте динамики систем и теории управления СО РАН (г. Иркутск); в Объединенном Институте Ядерных Исследований (г. Дубна); в Институте Электронных Управляющих Машин и на факультете ВМиК МГУ (г. Москва); в Томском государственном политехническом университете (г. Томск) и Кемеровском государственном университете (г. Кемерово).
Список используемых источников приводится в алфавитном порядке, а работы автора в хронологическом порядке.
1 Обзор существующих подходов к исследуемой проблеме (ИЛИ «ЗАЧЕМ» необходимы данные исследования?)
Отличительной особенностью современного этапа развития вычислительной техники является стремительное расширение сферы ее применения. В связи с этим постоянно ощущается потребность в новых компьютерных методах и средствах постановки и решения задач, ориентированных на конечного пользователя [91, 103].
Вначале проясним термин конечный пользователь. Конечный пользователь - это последний, основной потребитель компьютерной системы, использующий программное изделие после того, как оно полностью разработано и выставлено на продажу. Термин используется для того, чтобы различать два класса пользователей - те специалисты, которым требуется законченная, работающая без ошибок программа (это конечные пользователи), и те специалисты, которые могут использовать этот продукт в целях разработки новых программных продуктов (это программисты). Термин конечный пользователь обычно подразумевает индивида с относительно низким уровнем знания компьютера. Если вы не программист или инженер, вы - почти наверняка конечный пользователь.
Процесс решения задачи на компьютере проходит четыре основных фазы:
описание задачи в терминах предметной области (прагматический этап);
спецификация задачи или описание ее на формальном языке (теоретический этап);
выбор и/или создание эффективного программного обеспечения (технологический этап);
решение задачи и анализ результатов (практический этап).
Наибольшую трудность у пользователя вызывает переход от п. 1 к п. 2, т.е. от описания задачи в терминах предметной области к ее корректному и конструктивному описанию на формальном языке. Существующие в настоящее время традиционные подходы в информатике при постановке и решении задач на компьютере предполагают два пути решения указанной проблемы:
специалист от программирования пытается извлечь задачу из пользователя (императивный подход);
пользователю предлагают освоить формальный язык (например, ПРОЛОГ) и на нем ставить и решать свои задачи (декларативный подход).
В первом случае пользователь лишен гарантии того, что будет решена именно его задач, так как никто лучше него самого не знает ее. Во втором, ему необходимо приложить дополнительные и, зачастую, очень значительные усилия по освоению нового для него формального языка.
В тоже время, если задача поставлена некорректно, то нет никакой уверенности, что она будет решена вообще. Если все же удастся ее решить, то неизвестно что за задача решена, пользователя или какая-то другая.
Таким образом, все еще широко распространена практика решения задач на компьютере, при которой конечный пользователь очень часто оказывается почти сторонним наблюдателем процесса создания программного продукта, предназначенного для решения его задачи. Даже современные CASE-технологии (например, реализованные на языке UML [12-14, 17, 97]) не полностью освободились от указанного недостатка. Очень показателен, в этом плане, процесс решения задачи, приведенный на рисунок 1 [104]. Здесь достаточно наглядно представлены проблемы, которые возникают в результате привлечения к решению задачи пользователя различных специалистов по computer science.
Как было описано в техническом задании
Как было предложено организатором разработки
Как было спроектировано ведущим Как было реализовано
системным специалистом программистами
Как было внедрено
Чего хотел пользователь
Рисунок 1. Стандартная схема решения задач на компьютере
Обратите внимание на нижние два фрагменты рисунка 1: «Какую задачу собирался решать пользователь и, что из этого получилось в итоге?» То, каким трансформациям подвергалась задача, в результате привлечения к ее решению различных специалистов, ярко продемонстрировано на осталь-
ных фрагментах рисунка 1. Эта типичная проблема, возникающая при решении задач на компьютере, особенно остро встала с появлением и широким распространением персональных компьютеров. Появление персональных компьютеров существенно изменило и условия труда значительной части специалистов различных сфер человеческой деятельности. Данная ситуация наступила так внезапно, что возник разрыв между необходимой и фактической подготовленностью основной массы потенциальных пользователей, способных ставить и готовых решать свои задачи на персональных компьютерах.
Казалось бы, персональные компьютеры для того и создавались, чтобы пользователь смог сам решать на них свои задачи. Но одно дело собрать компьютер и оснастить его каким-то системным программным обеспечением, и совсем другое - научить конкретного специалиста (не математика и не программиста) ставить и решать свои задачи на компьютере.
Возникает естественный вопрос: «Что же необходимо учесть при создании программного обеспечения для решения какого-либо определенного класса задач?» И в более общей постановке: "Как может (и может ли вообще) проектировщик программного обеспечения, на этапе конструирования программной системы, разумным образом учесть интеллектуальные ресурсы и интеллектуальные запросы данной категории пользователей, на которую рассчитана создаваемая им программная система?»
Разумные ответы на эти вопросы - залог умения управлять такими факторами, как стоимость и качество разработки программного обеспечения, а главное - пользователь получает возможность непосредственного решения своих задач на компьютере, не прибегая, при этом, к услугам программистов. Безусловно, такие разработки должны повысить спрос на рынке компьютерных услуг.
Приведенные выше рассуждения, конечно же, не новы. Однако до сих пор автору неизвестно не только программного обеспечения, но и готовых
методик, полностью решающих данную проблему, а существующие же подходы - вызывают сомнения в их практической ценности.
Постоянно возрастающие требования, предъявляемые к качеству постановки и решения задач на компьютере [11, 21, 31, 33-34, 95] связаны в первую очередь с тем, что ошибки, возникающие в этом случае, могут иметь далеко идущие последствия, соизмеримые в отдельных случаях с ущербом, причиняемым природными катастрофами.
Поиск методов и средств, гарантирующих правильность постановки и решения задач, осложняется тем обстоятельством, что непрерывно увеличивается, как масштабность и сложность самих решаемых задач, так и переориентация все большего количества пользователей, из различных сфер деятельности, на решение своих задач на компьютере. Зачастую решение таких задач оказывается под силу только целым коллективам специалистов, а это, в свою очередь, предъявляет еще большие требования к точности исходных формулировок задач, а также требует создания соответствующих им методов и средств [2, 32, 61, 98, 115].
В настоящее время развито два основных направления в решении задач; на компьютерах. Первое направление связано с традиционными (постоянно модернизируемыми) методами императивного подхода к решению задач, когда от пользователя требуются знания не столько того ЧТО он хочет сделать на компьютере, сколько знания того КАК он это должен сделать. Иначе говоря, ему требуется не умение корректно поставить свою задачу, а квалифицированно владеть компьютером и языками программирования. Такая методика работы более подходит крупным компьютерным фирмам, специализирующимся на разработке программного обеспечения для заказчиков. Другой подход ориентирован на декларативный метод решения задач на компьютерах, когда от пользователя требуется только корректно и ответить на вопрос о том ЧТО он собирается делать на компьютере, а все остальное за него выполняется автоматически. Данная методика решения задач более
удобна для конечных пользователей, основным инструментом которых является персональный компьютер. Заметим, что в обоих случаях от пользователя не требуется отвечать на вопрос, ЗАЧЕМ он это делает.
Решение задач в языках декларативного типа
Появление формальных языков программирования [130] (особенно языков высокого уровня), реализация принципа модульного программирования и реализация подхода, предложенного Виртом, существенно помогло человеку в общении с компьютером при решении его задач. Появилась возможность не удобный и не привычный для человека язык «единичек и ноликов» компьютера заменить на более понятный - алгоритмический язык постановки и решения задачи. В этот период преобладает эмпирический подход к поиску и реализации идей и концепций программирования. Возникают такие новые понятия, как: «открытая» и «замкнутая» программы; «процедура»; «компиляция»; «интерпретация» и др. Этот, безусловно, положительный фактор способствовал научному подходу к процессу программирования и к теоретическим исследованиям в области программирования. Однако же, вместе с появлением формальных языков программирования возникла и новая проблема - не все пользователи компьютеров могли быстро и в полном объеме овладеть формальными языками программирования. Преодолению этого отрицательного фактора в программировании были посвящены последующие этапы развития вычислительной техники и компьютерных технологий, а возникшая при этом свободная ниша немедленно заполнилась новыми специалистами - программистами.
Программисты могли быстро перевести готовый алгоритм решения задачи на формальный язык «понятный» компьютеру (язык программирования или машинный язык), но, к сожалению, разработать сам алгоритм решения задачи, не говоря уже о том, чтобы поставить задачу, зачастую им было не под силу. Так возник тандем: пользователь — программист, который существует и поныне.
Следующим этапом в развитии императивных языков программирования видимо следует считать появление различных нотаций языков программирования и технологий, призванных обеспечить больше удобств пользователю, а, значит, и способствующих более точному извлечению из заказчика-пользователя постановки его задачи. Наиболее перспективной из предлагаемых нотаций видимо следует считать графическую нотацию, когда задача и алгоритм ее решения отображаются в виде схем, графов, диаграмм и т.п. К ним относятся: НІРО-технология [4], R-технология [16], 7і-технология [54] и современные CASE-технологии, например, базирующиеся на языке UML [12-14, 17, 97]. Графическая нотация зачастую позволяет конечному пользователю лучше понять и представить свою задачу еще на этапе ее формулировки или, в крайнем случае, на этапе прототипирования. Такую же нотацию используют и следующие технологии: Rational Rose, BPwin, Silverrun, Process Analyst и Paradigm Plus(P+) [12, 13, 17, 59, 97].
Так, например, язык UML - это графический язык для визуализации, специфицирования, конструирования и документирования артефактов программной системы. Его используют для того, чтобы моделировать системы. Модель - это упрощение реальности, абстракция, которая создается для лучшего понимания системы. Система, очень часто разложенная на ряд под-систем, - это множество элементов, организованных некоторым образом для выполнения определенной цели [187]. Системы описываются набором моделей, по возможности рассматривающих ее с различных точек зрения. Важными составляющими частями модели являются, прежде всего, структурные сущности.
UML - Unified Modeling Language - в настоящее время принят OMG в качестве стандарта, поддержан целым спектром инструментальных программных средств визуального моделирования, совместной разработки (поддерживаются основные языки программирования C++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder), автоматизированного тестирования и документирования, охватывающих жизненный цикл создания программных систем.
Можно назвать и другие развивающиеся технологии программирования (например, .NET Framework), нацеленные на получение качественного программного обеспечения. А, например, в методе гиперпрограммирования [42] рассматривается такая организация процесса разработки программ, при которой программа формируется в виде дерева фрагментов, представляющих собой значения некоторых выделенных метапеременных используемого языка программирования. Существенно, что каждое вхождение метапере-менной представлено помеченной метапеременной, т.е. парой, состоящей из символа метапеременной и метки, конкретизирующей вариант значения этой метапеременной, хранящихся в соответствующих «библиотеках».
Однако при всех своих достоинствах, указанные выше технологии не лишены одного, на наш взгляд, очень существенного недостатка — все они предполагают наличие «посредника» между конечным пользователем и компьютером в лице аналитика — главного лица, отвечающего за постановку задачи пользователя. Связано это с тем, что остается необходимость окончательного описания процесса решения задачи на компьютере программистом, в терминах императивного языка. Этот факт не добавляет энтузиазма конечному пользователю в постановке и решении своих задач, особенно, при их решении на персональных компьютерах.
Особенно неудобным оказалось применение указанных выше подходов при решении достаточно сложных, но не масштабных задач, накладные расходы оказались неприемлемо велики, а полной гарантии корректного решения задачи пользователя не обеспечивалось. Вместе с тем, именно такие задачи, в основном, и решаются на персональных компьютерах.
Именно по этой причине, в последнее время, все большее внимание стали уделять, так называемому, математическому подходу к решению задач на персональных компьютерах, основное внимание при котором уделяется корректной и конструктивной постановке задачи и применению декларативного метода ее решения.
Языки и логики спецификаций задач для идеальных пользователей
Итак, интеллектуальные запросы идеального пользователя р — это множество всех формульных Гр-задач , где Тр - теория предметной области, которой исходно располагает р. Подчеркнем, что это понимание запросов зиждется на предположении, что идеальный пользователь р полностью репрезентируется теорией Тр. Однако не следует забывать, что это - упрощающее предположение. Более реалистичным было бы предположить, что репрезентация пользователя - это не просто какая-то теория Тр, а пара (Tp,res(p,Tp)), где res (р,Тр) - интеллектуальный ресурс пользователя/?.
Этому более реалистичному предположению отвечает термин задача для реального пользователя р как сокращение для «формульная Тр-задача, доступная пониманию р» и термин интеллектуальные запросы реального пользователя р как сокращение для «множество всех таких задач».
Дальнейшее изложение распадается на две части. Первая соответствует предположению, что пользователь р репрезентируется теорией Тр (идеальный пользователь), а сообщество пользователей п относительно - классом т= {Z(p)\peTz} теорий Tp(=L(p)) в одном и том же языке (сообщество идеальных пользователей). Вторая часть соответствует предположению, что пользователь р репрезентируется парой (Тр res(p, Тр)) (реальный пользователь), а сообщество пользователей 71 относительно Е - парой (r.res), где г = pL, res - RES(TI,1L) (сообщество реальных пользователей).
Вторую часть можно рассматривать как релятивизацию первой к интеллектуальным ресурсам пользователей.
Рассмотрим формальные выкладки, связанные с приведенными выше неформальными рассуждениями. Прежде чем мы перейдем к точным формулировкам, сделаем ряд замечаний, касающихся особенностей применения аппарата математической логики в рассматриваемых прикладных исследованиях по информатике. Начнем с вопроса о том: «Что такое задача»? Рассмотрение будем вести сверху вниз, т.е. от самого общего к более конкретному. Выше отмечалось, что задача - это неудовлетворенное чувство любопытства. В самом общем смысле задача понимается следующим образом. В жизни нас часто посещают (или мы сами их генерируем) некоторые беспокойства, от которых мы хотели бы избавиться. Эти беспокойства бывают двух видов: одни понятны нам и тогда они перерастают в задачи; другие не понятны и тогда они так и остаются в виде «томлений». Эти два вида беспокойств мы как-то умеем отличать друг от друга. Заметим, что очень важно сохранить это свойство «различать беспокойства» и по отношению к практике постановки и решения задач. Что значит: «Задать задачу» в нашем смысле? Это значит сформулировать ее в точных терминах (например, математических) и указать критерий отделения решения задачи от ее нерешения. Для более точного описания вводимых далее понятий воспользуемся теорией нумераций. Пусть задано множество U всех возможных претендентов на задачи. Тогда задать понятную нам задачу - это значит разбить данное множество на подмножества решений и на подмножества нерешений задачи. Второй вопрос: «Что значит - задача нам понятна»? Нам понятно беспокойство, если мы уверены, что любой предъявленный нам предмет из некоторого исходно предполагаемого класса U мы в состоянии признать как утоления или как не утоление нашего беспокойства. Следовательно, задача понятна нам тогда и только тогда, когда у нас есть класс U и есть критерий, позволяющий нам уверенно отделять в U её решения от её нерешения. Третий вопрос: «Как можно описать всевозможные такие уверенности»? Сразу отметим, что если класс U предполагается эффективно перечислимым или, ещё лучше, эффективно разрешимым множеством, то в принципе можно было бы предложить сколь угодно много таких описаний, а если класс U предполагается не эффективно перечислимым множеством, то автору неизвестно ни одного такого описания. Думается, что, и никто не знает. Поэтому впредь будем предполагать класс U - эффективно разрешимым множеством. А раз так, то можно считать, что любая уверенность упомянутого распознавания в U обеспечивается общерекурсивным алгоритмом, который по каждому элементу множества U говорит: «утоляется мое беспокойство или не утоляется». Вывод. Следовательно, каждая задача — это рекурсивное подмножество множества U. А множество всех осмысленных (т.е. понятных) задач — это множество всех таких подмножеств. Описать все такие подмножества — означает задать какую-то нумерацию этих подмножеств. В сторону заметим, что в нашем случае это означает задать часть языка спецификаций задач (но не весь язык). Для этой части зарезервируем название: язык формулировок {не спецификаций) задач. Если бы речь шла о рекурсивно-перечислимых подмножествах, то, как известно, существует бесконечно много хороших, в математическом отношении, нумераций (универсальных, общерекурсивных). Например, одна из них, постовская. Определение. Пусть л семейство всех рекурсивно-перечислимых подмножеств со. Нумерация v: со — л называется вычислимой, если множество пар { х, у \х є vy) рекурсивно перечислимо. Но известно также, что не существует ни одной общерекурсивной нумерации класса всех рекурсивных подмножеств. Если нумерация вычислима (п,х), то не все подмножества U нумеруются, либо все нумеруются, но тогда нумерация не вычислима.
Пример формальной спецификации задачи
Простейший способ определения разностного порога состоит в следующем. Для данного нормального раздражения N создаем (или отыскиваем) переменное раздражение V, заметно большее, чем N, и уменьшаем его до тех пор, пока различие сделается впервые незаметным. Фиксируем полученное при этом значение Vo переменного раздражения. Затем мы его снова увеличиваем, пока оно не покажется впервые снова заметно большим, чем N. Пусть этому соответствует значение Vj. Величина h(N) которая лежит посередине между впервые заметным различием и впервые незаметным различием, есть верхний пункт равенства (в N) : h(N) =-(V0+Vx). Величина AN, определяемая соотношением AN = h(N) - N, называется верхним разностным порогом (в N).
Нижний разностный порог 5N (в N) определяется аналогичным образом, что, впрочем, для нас не существенно, ибо эта часть метода минимальных изменений не будет использоваться при реализации процедуры отыскания ТСрсР
Начиная с этого момента, мы под стимулом раздражения (для испытуемого) понимаем произвольное слово х (распознаваемое им как терм или не терм), а под величиной этого раздражения, измеряемой в абсолютной шкале, — длину \х\ слова х. Под ощущением, вызываемым стимулом раздражения (словом) х, понимается теперь субъективно воспринимаемое испытуемым человеком чувство некоторой (быть может, очень малой) уверенности, которой сопровождается акт распознавания данным человеком слова х как терма или не терма. Если уверенность, связанная с распознаванием х, принимается за данное ощущение, то уверенность, связанную с распознаванием у, мы считаем заметно отличным ощущением от данного, если и только если имеет место —iT}(x,y); и мы считаем ее едва заметно отличным ощущением от данного, если и только если имеет место -іТ](х,у), и для всякого слова z, длина \z\ которого является промежуточной между длинами х и [у, имеет место Tj(x,z). В соответствии с этими замечаниями следует понимать и смысл заявления, что h(\x\) обозначает верхний пункт равенства в \х\, а Л(\х\) обозначает верхний разностный порог (в \х\).
Теперь простейшая реализация искомой процедуры может быть описана достаточно просто. Этап 1. Берем пустое слово (т.е., слово нулевой длины) в качестве исходного терм-калибра а і для р. Этап 2. Для а/ методом минимальных изменений определяем верхний пункт равенства h(\ai\) в я/; берем произвольное слово в алфавите А1 длины h(\a}\); объявляем это слово вторым терм-калибром а2, для р. Этап 3. Для слова я? методом минимальных изменений определяем верхний пункт равенства h(h(\ai\)) в h(\ai\); берем произвольное слово в алфавите А1 длины h(h(\a/\)); объявляем это слово третьим терм-калибром аз для р. Этап 4. Для слова аз методом минимальных изменений определяем ... и т.д. Осуществляем столько таких этапов, сколько (например, т 1) мы собираемся иметь различных балльных оценок субъективной уверенности испытуемого р в правильность признания им распознаваемых слов термами или не термами. В силу п.п. «а»-«и», это осуществление всегда возможно. Мы, таким образом, получаем для р терм-калибровку ТСра — (а і, а2, а3) ..., а из m терм-калибров а і, а2, а3, ..., ат(дяяр). Выше уже была намечена схема использования терм-калибровки ТСра, для измерения субъективной уверенности испытуемого при распознавании им термов сигнатуры ст. Теперь рассмотрим эту тему более подробно. Условимся говорить, что уверенность, связанная с распознаванием х, равна і баллам (имеет і баллов), если и только если JC \at\ и Tat(x), и меньше і баллов (имеет і баллов), если и только если х я, и —ІГа х). Логическая корректность приведенного определения "баллов уверенности" обеспечивается положениями «а»-«и», что непосредственно очевидно. Заметим лишь, что вместо баллов 1,..., /, /+1,... мы с равным успехом могли бы, соответственно видоизменив последующие обозначения, говорить о баллах q (l),..., (p(i), q (i+1),..., где ср—произвольное строго монотонное преобразование числовой оси в себя. По этой, собственно, причине мы называем нашу шкалу возможных значений уверенности, обозначим ее через ТТ, именно балльной шкалой, а не как-либо иначе. Что касается эмпирического смысла рассматриваемой системы баллов, то он согласован со следующими неформальными замечаниями. Во-первых, уверенность тем больше, чем меньше ее балл; в частности, максимальная уверенность в результате распознавания слова х как терма или не терма достигается испытуемым тогда и только тогда, когда T(x,aj), например, при х = \aj\ или просто при х = aj. Во-вторых, уверенность в результате распознавания слова х как терма или не терма тем меньше, чем больше неуверенность. В-третьих, уверенность в указанном результате тем меньше, чем слово х длиннее. В-четвертых, два слова xj и х2 могут иметь разные баллы уверенности, даже если они терм-равны для испытуемого, чем и предотвращается «парадокс кучи». В заключение этого параграфа приведем схему алгоритма измерения интеллектуальных ресурсов пользователей, решающих свои задачи на компьютере и применяющих для этого язык спецификаций задач.
Реализация интернет-проекта «Инвестиционный менеджмент (в инновационной сфере)
То, что длина текста - недостаточный показатель его сложности, в особенности верно для естественных языков [102]. Например, известный текст «Дом, который построил Джек, ... », содержащий много последовательно присоединяемых справа уточняющих конструкций, воспринимается легко, а текст, построенный по симметричной схеме, в которой уточнения множатся не справа, а слева от главного предложения, - довольно трудно.
Воспринимаемость текста зависит от его структуры. Значит, оценка длины любого убедительного текста (терма, формулы, доказательства) должна мажорировать некоторую более сложную оценку, отражающую структуру этого текста.
Для применения метода оценки интеллектуальных ресурсов и интеллектуальных запросов пользователей в языках спецификаций задач необходим только синтаксис (а не семантика и прагматика) текста, специфицирующего задачу [79]. Поэтому естественно принять дополнительную гипотезу, согласно которой именно синтаксис и является той структурой, которую следует учитывать при оценке допустимой длины убедительного доказательства.
Процедура тестирования может проводиться одним из двух способов: на формальном языке или на естественном языке. Выбор зависит от того, знаком ли тот, кому предъявляется доказательство, с логической символикой. Если да, то в ходе диалога тестируется способность этого человека распознавать тексты логического языка, если нет - вся процедура тестирования представляет собой диалог на естественном языке (предъявляются не логические тексты, а их перевод на естественный язык).
Если синтаксис логического языка — понятие достаточно определённое, то о синтаксисе естественного языка этого сказать нельзя. Одному и тому же тексту (языку) можно поставить в соответствие разные виды синтаксиса. Ниже проясняются (до требуемой степени) основания отделения синтаксиса от семантики и прагматики; выделяется подходящий нашим целям тип синтаксиса; предлагается способ оценки синтаксической сложности убедительного текста; намечаются пути организации и реализации процедуры оценивания длины убедительного доказательства. В общей семиотике синтаксис определяют как отношения на множестве знаков (задающие возможности их комбинирования в тексте); семантику - как отношения между знаками и тем что они обозначают; прагматику — как отношения между знаками и теми кто их использует. Эти, достаточно общие, определения конкретизируются по-разному даже применительно к языкам одного и того же сорта. Так, одни считают, что у формальных языков вообще нет прагматики, другие - что таковая имеется. Синтаксис формальных языков обычно понимают как совокупность правил построения текстов, как исчисление. Семантику — как интерпретацию текстов этого исчисления на некоторой модели. Прагматику (если её вообще усматривают) - как зависимость способов использования языка от целей его использования. Синтаксис, семантику, прагматику формальных языков считают автономными областями с чёткими границами. В лингвистике те же понятия оказались пересекающимися: лингвистический синтаксис неотделим от лингвистической семантики и т.д. Нет чёткой формулировки оснований такого деления, из-за чего, неясно, что собой представляет синтаксис произвольного подъязыка естественного языка, например, подъязыка, используемого для формулировки и решения определённой задачи. (Совсем не очевидно, что такой синтаксис - часть синтаксиса языка в целом.) Общепринятое разделение этих трёх аспектов - синтаксиса, семантики, прагматики - в естественном языке в значительной мере диктуется интересами и традициями самой лингвистики. В каких отношениях это разделение приемлемо за её пределами - вопрос открытый. Синтаксис, семантику, прагматику можно трактовать как разные этапы процесса понимания текста. Хотя этот процесс часто протекает очень быстро, в нём всегда присутствуют два момента5, на каждом из которых он мог бы прерваться, не приведя к успеху: восприятие чего-то как языкового текста, восприятие чего-то как мысли, обозначенной текстом. Для того чтобы понять, что некоторый текст написан на английском языке, совсем не обязательно понимать смысл этого текста. Можно понять, что сказано, не поняв смысл сказанного. Текст связан с предметом или ситуацией не непосредственно, подобно ярлыку, а через промежуточное звено - мысль, задающую (неформально) алгоритм соотнесения текста с реальностью. Понимание какого-либо алгоритма и реальное его использование - разные вещи. Соответственно можно понять, о чём сказано в тексте, так и не поняв, ЗАЧЕМ (в связи с чем) это сказано . Выражение «понятный текст», тем самым, неоднозначно: 1) понятно, ЧТО сказано; не понятно, о чём сказано; 2) понятно, ЧТО и о чём сказано; не понятно, ЗАЧЕМ сказано; 3) понятно, ЧТО, о чём и ЗАЧЕМ сказано. Какая из этих степеней понятности будет достигнута, зависит как от текста, так и от воспринимающего его человека. Эти степени понятности соотносимы с синтаксисом, семантикой, прагматикой.
В первом случае человек усматривает в заданном тексте какой-то синтаксис, но не семантику и прагматику. Пример - известный текст Л. Щербы «Глокая куздра штеко будланула бокра и кудрячит бокрёнка». Законные сомнения здесь могут относиться лишь к правильности усмотрения синтаксиса: «действительно ли третье слово - это обстоятельство действия?», «не играет ли это слово роль несогласованного определения при втором слове?» (как в выражении «большая собака динго»).
Во втором случае человек усматривает в заданном тексте какой-то синтаксис и какую-то семантику, но не прагматику (соответственно здесь законны сомнения лишь в правильности усмотрения синтаксиса и семантики). Этот пункт охватывает те случаи, когда текст воспринят как высказанный «ни к селу, ни к городу» (не бессмысленен, но никак не связан с ситуацией произнесения). Человек может перефразировать текст, не разрушая имеющееся его понимание, но не может связать этот текст с реальностью.
В третьем случае человек усматривает в заданном тексте и какой-то синтаксис, и какую-то семантику, и какую-то прагматику.
Можно сказать, что в первом случае синтаксис отделён от семантики и прагматики (по причине их отсутствия), а во втором - синтаксис и семантика отделены от прагматики (по причине её отсутствия). Проблема в том, чтобы понять, каковы основания отделения синтаксиса от семантики и прагматики в третьем случае.
Похожие диссертации на Технология построения языков спецификаций классов задач, ориентированных на пользователей
