Технология построения языков спецификаций классов задач, ориентированных на пользователей

Необходимость в разработке новых методик постановки и решения задач на компьютере объясняется тем, что появление относительно дешевых, малогабаритных, надежных и быстродействующих персональных компьютеров [98] обеспечило их доступность массовому пользователю. Появилась реальная возможность обеспечить каждого специалиста персональным компьютером, способным решать многообразные, в том числе и достаточно сложные задачи [32]. Данная ситуация наступила настолько быстро, что возник разрыв между необходимой и фактической подготовленностью основной массы потенциальных пользователей, способных ставить и решать свои задачи [95] на персональных компьютерах. Причин этому несколько:

• недостаточные знания, умения и навыки постановки задачи в точных математических терминах;

• неумение выбирать или разрабатывать эффективные алгоритмы решения задачи;

• незнание формальных языков программирования и инструментальных программных средств;

• отсутствие знаний, умений и навыков перевода постановки своей задачи с языка предметной (профессиональной) области на «язык компьютера» и другие.

И если некоторые из указанных проблем можно разрешить сравнительно быстро (например, изучив язык программирования [130]), то решение других проблем (например, формулировка задачи в терминах предметной области пользователя и ее точный перевод на формальный язык, а, далее, на «язык компьютера» [82]) вызывает серьезные затруднения.

Отметим, что всегда одной из центральных проблем области человеческих знаний и деятельности была и остается проблема корректной постановки задачи, в самом широком смысле этого слова [9, 27, 28]. Эта проблема относится как к решению повседневных бытовых, так и самых сложных научных и производственных задач. С момента появления вычислительных устройств, и особенно с появлением персональных компьютеров, эта проблема еще более обострилась, поскольку теперь к решению задач приобщилась еще большая аудитория (к профессионалам математикам и программистам добавились, так называемые, непрограммирующие профессионалы — конечные пользователи [110, 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).

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

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

Таким образом, возникают следующие задачи исследования.

1. Изучить принципиальную возможность разработки теории, методологии и технологии постановки и решения задач на компьютере самими пользователями в полном соответствии с их интеллектуальными ресурсами и их интеллектуальными запросами.

2. Разработать и теоретически обосновать методику и процедуры оценки интеллектуальных ресурсов и интеллектуальных запросов различных категорий пользователей.

3. Разработать теоретический аппарат и методику организации диалога с пользователем на языке его предметной области, как при постановке задачи, так и при анализе результатов ее решения.

4. Разработать архитектуру инструментальной программной системы, обеспечивающей поддержку языков спецификаций задач, ориентированных на пользователей.

Для позиционирования места работы в ряду других следует отметить следующие особенности.

I. Рассматриваемые в работе языки спецификаций задач, ориентированные на пользователя, направлены на разрешение проблемы взаимопонимания и разнесения ответственности между заказчиками (постановщиками задач, пользователями) и разработчиками программного обеспечения (программистами), т. е. рассматривается проблема общения заказчиков с разработчиками. При этом за заказчиком остается право самостоятельно осуществлять точную постановку задачи, а за разработчиком (если это необходимо) — создавать адекватное поставленной задаче программное обеспечение. Окончательное решение задачи на компьютере остается за самим пользователем. Общение заказчика с разработчиком ведется только на уровне синтаксиса. Иначе говоря, заказчик несет полную ответственность за точность постановки задачи, а разработчик отвечает за точность синтаксической реализации задачи в виде программного продукта.

II. Понятность задачи для пользователя классифицируется тремя следующими уровнями общности рассмотрения понятия задачи: a) «Г-задача» — задача понятна пользователю, т. е. он может сформулировать критерий, позволяющий эффективно отделять решение задачи от ее нерешения', b) «Г-полузадача» — при постановке задачи явно указан критерий определяющий только решение задачи, т. е. решения задачи составляют рекурсивно перечислимое множество, а нерешения — никак не определяютсяc) «Г-томление» — пользователь может указать только нерешение задачи. Что же при этом является решением задачи и как это определяется ничего не сказано. Так, например, в 1932 году Колмогоров [170] предложил интуиционистское пропозициональное исчисление трактовать как исчисление задач. При этом он не определил ни что такое задача, ни что такое решение. Импликацию он истолковывал следующим образом: импликация а—> Ь {а влечет Ь) означает, что имеется общий метод сведения задачи Ь к задаче а. Затем Клини предложил уточнить термин «сведение» как алгоритм, который по каждому решению задачи, а выдает решение задачи Ь.

Замечание 1. Два последних случая будем связывать с принятием безответственных решений, и рассматривать их не будем.

Замечание 2. Конструктивный подход в определении задачи совпадает с классическим определением в том случае, когда задача осмысленна, т. е. является Тзадачей.

Теперь укажем некоторые ограничения применения рассматриваемой методики, опирающейся на языки спецификаций задач, ориентированные на пользователя.

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

2. Принципиальный отказ от универсальности в определении языков спецификаций задач в пользу эффективности. Чем плоха универсальность и какие здесь могут быть «подводные камни» достаточно хорошо известно и с теоретической и с практической стороны.

3. Проблема «машинного нуля» [26] или презумпция неточности. Кто может гарантировать, что если известен результат и известен путь его получения, то можно отправляясь от результата однозначно прийти к исходным посылкам (нарушение транзитивности)?

4. В основе проводимых исследований (предшествующих теоретическому обобщению) лежит значительный этап практических разработок программных систем, хотя он и не является единственно определяющим фактором. Анализ данного этапа позволил выделить некоторые особенности решения задач на компьютерах, которые были положены в основу рассматриваемого подхода от задач. Так, например, а) разработанное программное обеспечение только тогда долго и эффективно эксплуатируется, когда в постановке задачи и формировании технического задания на разработку программного обеспечения непосредственное участие принимает сам заказчикЬ) сам процесс постановки задачи оказывается успешным тогда, когда язык общения заказчика с исполнителем бывает с одной стороны простым, удобным и понятным, а с другой — точным и формальнымс) разработанное программное обеспечение только тогда эффективно, когда при его разработке отказываются от принципа универсальностис!) было замечено также, что знания о предметной области пользователя не монотонны по отношению к его знаниям о задачах из той же самой предметной областие) пользователи, как правило, в практических действиях руководствуются не предметной областью (имеется ввиду модель предметной области [109]), а оперируют понятием, которое определено в работе как «поле» задач этой предметной области.

Эти и некоторые другие особенности решения задач на компьютерах позволяют по иному взглянуть на сами понятия: задача, программа, «жизненный цикл» программного обеспеченияспецификация задачитехнология решения задачи на компьютере и др.

Конечно же, в реальной практике решения задач не только указанные выше особенности играют существенную роль, однако в массовых случаях (при решении задач анализа данных и принятия решений, при разработке информационных систем, систем управления различными процессами, при создании обучающих систем и решении многих других задач) именно они играют определяющую роль. При этом хотелось бы, чтобы программист не уподоблялся тому врачу, который ставит диагноз только по одному из симптомов (не проповедовал бы «ползучий эмпиризм»).

Теперь несколько слов об ограниченности применения разработанной технологии построения языков спецификаций классов задач, ориентированных на пользовтаелей.

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

Пример 1. Чем отличается доказательство того, что пятый постулат геометрии Евклида эквивалентен теореме о сумме внутренних углов треугольника, от попыток геодезическим способом измерять сумму внутренних углов треугольника"?

Пример 2. Если в качестве исходных аксиом выбрать заповеди «Не убий» и «Не прелюбодействуй», то они явно будут иметь разный вес, по крайней мере, не будут эквивалентными.

Таким образом, недостаток аксиоматического метода, который может привести к неприятным ситуациям, заключается именно в том, что вообще-то аксиомы должны иметь разные веса (например, в смысле того, как часто вы пользуетесь аксиомой, у которой «вес сомнительности» больше, чем у других используемых аксиом). Это особенно важно при решении задач, связанных с деятельностью, или с мыследеятельностью, когда при аксиоматическом методе это свойство веса аксиом утрачивается. Решение этой проблемы остается за заказчиком.

Вместе с тем, чем точнее система аксиом отражает предметную область, тем решение задачи будет точнее.

Другой пример. Учет длины доказательства. Все может быть формально правильно построено, но результат может оказаться неправильным в интерпретации заказчика и именно потому, что недоучтены веса используемых аксиом. Поэтому при оценке интеллектуальных ресурсов пользователей необходимо учитывать не только длину правильно распознаваемых выводов, но и, например, вес используемых в доказательстве аксиом. Заметим, что исследование зависимостей интеллектуальных ресурсов пользователей от весов аксиом и других возможных характеристик выходит за рамки данной работы, хотя и имеет право на существование.

Следует заметить, что и длина правильно распознаваемых выводов тоже кое-что говорит об интеллектуальных ресурсах пользователя, особенно в тех случаях, когда мы говорим о формульных задачах на доказательства, понимаемым всеми участниками процесса решения задач на компьютере на интуитивном уровне.

Заметим, что понимание ограниченности аксиоматического метода в смысле Геделя в данном случае неприемлемо. Это нечто совсем другое. Отсюда вывод: при аксиоматическом изложении трудно добиться того, чтобы все аксиомы были равно приемлемы. Пока же предлагается исходить из рав-новзвешенности и равноприменимости аксиом для заказчика.

II. Желательно учитывать не только то, КАК будет работать система, если бы она работала идеально, но и ЧТО будет, если она будет работать плохо. Что будет, когда система будет откланяться от того, что в ней предусмотрено? Видимо, в этих случаях необходимо предусмотреть некоторые другие механизмы организации взаимодействия заказчиков и исполнителей, и другой методики решения задач на компьютерах. Здесь также играют роль предпочтения неуниверсальности. Это же может выражаться и в виде нечеткости самих понятий, но в этом случае предлагается поступать особым образом, описанным далее в главе III. Такие ситуации в данной работе не рассматриваются и не исследуются, хотя на практике они также могут встречаться.

III. Желание обеспечить пользователя методикой, теорией и технологией постановки и решения задач на компьютере предполагает, что и сам пользователь и спецификатор обладают необходимыми знаниями о своих предметных областях. Хотелось бы научиться как-то, оценивать их, так называемые, интеллектуальные потребности (задачи, которые они решают) и их интеллектуальные возможности (ресурсы, которыми они обладают). Это позволит получить ответ на вопрос о том, насколько точно (адекватно) пользователь понимает свою задачу, чтобы иметь возможность принимать ответственные решения, как при постановке задачи, так и при оценке результатов ее решения. Один из способов такой оценки интеллектуальных ресурсов и интеллектуальных запросов пользователей описан в главе III.

IV. Если пользователь получил решение своей задачи, и оно его не удовлетворяет, то можно рассмотреть две ситуации: первая — мы считаем, что пользователь сам виноват во всемвторая — мы признаем, что пользователь может не знать всех особенностей компьютерной реализации и соответственно не может указать их в спецификации своей задачи. В этом случае исполнитель может включить в реализацию программы фрагменты, способные повысить эффективность программного обеспечения, решающего задачу пользователя (например, алгоритмические логики [39]). Однако при этом необходимо быть особенно осторожным и учесть следующее обстоятельство. Может возникнуть следующая опасная ситуация — берется конкретная задача, потом она обобщается, затем конкретизируется и в результате решается уже совсем другая задача, не та которую имел ввиду пользователь.

V. В рассмотрение введен критерий, отделяющий решение задачи от ее нерешения. Но может быть в рассматриваемом «поле» задач и есть и еще что-то, что нашим критерием не улавливается, (что не является ни решением и ни нерешением)? Тогда имеет смысл говорить о системе критериев, поскольку меняется само понятие истины. Здесь можно вспомнить теорему Геделя, о существовании арифметической формулы, которая истинна, но не доказуема в арифметике: если она и истинна, то в каком-то другом, не таком смысле, что, а + Ь = Ь + а.

Для решения перечисленных выше задач имелись следующие предпосылки. Методологическую основу исследований составляет анализ понятий задачи и «поля» задач, рассматриваемый в рамках нового подхода к философии математики [4], а теоретическую базу исследований составляет математический аппарат относительно конструктивных систем, адаптированный применительно к языкам спецификаций задач [105, 111]. Технологические основы апробированы при решении практических задач и описаны в [55,65−67,70−71,73−74].

Научная новизна. Впервые предъявлен, разработан и согласован с формальным определением осмысленности задачи язык спецификаций классов задач, ориентированных на пользователя. В отличие от других языков спецификаций задач (например, интуиционистской логики исчисления задач, когда при конструировании задач из элементарных задач теряется осмысленность задачи), в данном подходе этот существенный момент учтен. Дано формальное определение осмысленной задачи. Это значительно более узкое понятие, чем понятие задачи, употребляемое в общематематическом смысле. В результате предложено вместо исчисления задач употреблять понятие <толя задач" - алгебраическая система, носителем которой является множество задач, на которых заданы отношения и операции, причем так, что эти отношения и операции интересны пользователю.

Осмысленность задач разбита на два класса: 1) осмысленность задачи в принципе и 2) осмысленность задачи для реального пользователя. Во втором случае учтено то, что осмысленность задачи для реального пользователя зависит от его интеллектуальных возможностей. Получены достаточно любопытные результаты — в частности доказана теорема, свидетельствующая о немонотонной зависимости знаний пользователя о предметной области и знаний пользователя о задачах из этой же предметной области.

Дано определение интеллектуальных потребностей {интеллектуальных запросов) пользователя в виде так называемого «поля» задач. Дано определение интеллектуальных возможностей (интеллектуальных ресурсов) пользователя, согласованных с его интеллектуальными потребностями, предста-вимые как измеримые характеристики и приведена процедура их измерения. Ресурс (данного человека) р относительно (данной аксиоматической системы) Т есть тройка гез (р, Т) =(т](р, Т), щ2(р, Т), ш3)(р, Т)) натуральных чисел т1(р, Т)> ш2(р, Т), т3(р, Т) таких, что:

• т](р, Т) — наибольшая длина доказательств в Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку степени убедительности для данного человекар

• гп2(р, Т) — наибольшая длина последовательностей символов алфавита языка системы Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку (субъективной уверенности р в) безошибочной распознаваемости их р как формул (или не формул) языка системытз (р, Т) — таких, что и Ш2(р, Т), но применительно к термам. Здесь Т описание предметной области пользователя.

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

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

Основные результаты, выносимые на защиту.

1. Технология построения языков спецификаций классов задач, ориентированных на пользователей, обеспечивающая конечному пользователю удобную, самостоятельную и точную постановку осмысленной задачи, учитывающая особенности ее решения на компьютере.

2. Процедура оценки интеллектуальных ресурсов и интеллектуальных запросов пользователей при постановке и решении задач своей предметной области. Данная процедура имеет самостоятельный интерес, например, при оценке профессиональных качеств каждого специалиста в коллективе разработчиков программного обеспечения.

3. Теоретические основы организации удобного для пользователя диалога в терминах его предметной области, при самостоятельной постановке и решении задач на компьютерах.

4. Архитектура инструментального комплекса в технологии языков спецификаций классов задач, ориентированных на пользователей, базирующаяся на понятии В-модуля и Управляющего Массива.

Диссертация состоит из введения, четырех глав, разбитых на параграфы и заключения. Параграфы разбиты на пункты.

Заключение

.

На защиту выносятся следующие результаты.

1. Разработано новое научное направление постановки и решения задач на персональном компьютере самими конечными пользователями, в соответствии с их интеллектуальными ресурсами и их интеллектуальными запросами, основанное на языках спецификаций классов задач.

2. Разработана, теоретически обоснована и применена на практике (для технических, экономических задач и задач обучения) технология построения языков спецификаций классов задач, ориентированных на конечных пользователей. Основу данной технологии составляют понятие и понятность задачи для пользователя, относительно конструктивная система Т (аксиоматическая система Т), интеллектуальный ресурс и интеллектуальный запрос, задачная система, «поле» осмысленных задач и др.

3. Разработаны процедуры измерения интеллектуальных ресурсов (знаний, умений и навыков) и их соответствия интеллектуальным запросам (задачам) пользователей в языках спецификаций классов задач, ориентированных на пользователей, позволяющие, при некоторых разумных ограничениях, приписать испытуемому человеку (пользователю) р, рассуждающему в рамках аксиоматической системы Т, интеллектуальный ресурс: гев (р, Т) = (т,(р, Т), т2(р, Т), ш3(р, Т)), где.

Ш}(р, Т) — наибольшая длина доказательств в Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку степени убедительности для данного человека рт2(р, Т) — наибольшая длина последовательностей символов алфавита языка системы Т, все еще имеющих достаточно высокую (заранее фиксированную) балльную оценку (субъективной уверенности р в) безошибочной распознаваемости их р как формул (или не формул) языка системыт3(р, Т) — таких, что и т2(р, Т), но применительно к термам—.

4. Разработана лингвистическая составляющая, обеспечивающая удобный интерфейс пользователю как при постановке задачи, так и при оценке его интеллектуальных ресурсов и запросов в языках спецификаций классов задач, ориентированных на пользователей. В основе лингвистической составляющей — синтаксис языков спецификаций задач и проекция языка предметной области на некоторый эталонный язык этой же предметной области;

5. Разработаны инструментальные программные средства и архитектура программного комплекса обеспечения и поддержки технологии работ в языках спецификаций классов задач, ориентированных на пользователей. В основе разработки лежат понятия В-модуля и Управляющего Массива, а также согласования имеющихся сил и средств по уровням профессиональной подготовленности разработчиков проекта.

Предложенная схема решения задач на компьютере позволяет получить ответ на вопрос о том, как может (если вообще может) проектировщик программного обеспечения разумным образом учесть на этапе конструирования своей системы интеллектуальные ресурсы и интеллектуальные запросы данной категории пользователей создаваемой программной системы. Такого рода учет — залог умения управлять такими параметрами, как стоимость и качество разработки программного обеспечения, повышающими спрос на рынке компьютерных услуг.