Название: Вопросно-ответное программирование человеко-компьютерной деятельности( Соснин П.И.)

Жанр: Информационные системы и технологии

Просмотров: 1875


4.4. средства qa-программирования

4.4.1. ТрансляторыОбразцы прецедентов, в том числе и те, в основу которых положено QA-программирование, создают для их повторного использования. Так как QA-программы ориентированы на их исполнение, как человеком, так и компьютером, то их исходный код должен переводиться в исполняемый код, как для I-процессора, так и для K-процессора. Выше было  отмечено,  что  ответственность  за  перевод  в  OwnWIQA возлагается на трансляторы QA-процессора.

Разработно   и   проверено   шесть   трансляторов,  два   из   которых являются интерпретаторами, а четыре ‒ компиляторами. В принципе, достаточно одного интерпретатора и одного компилятора, но, из-за специфики QA-программирования ряда задач и условий их повторного решения, минимальный набор трансляторов был расширен.В  минимальном наборе  объектно-ориентированный интерпретатор и соответствующий ему компилятор, ориентированный на К-процессор в том смысле, о котором было сказано в предыдущем пункте.В число дополнительных трансляторов включены:  интерпретатор QA-программ, в которых отсутствуют операторы циклов (циклические работы приходится эмулировать доступными операторами), что позволяет интерпретировать операторы, независимо друг  от  друга  (к  специфике  интерпретатора  относится  и  то,  что он   выводит   на   динамическую   компиляцию   построенного   кода с использованием средств .Net); компилятор,    обеспечивающий    разработку    интерфейсных модулей, включающих традиционные компьютерные интерфейсы, выводящие  на  исполняемые  коды  традиционных  типов,  а  также на коды QA-программ; компилятор, который является упрощенной версией объектно- ориентированного компилятора, обслуживающей автоматическую проверку условий доступа к прецедентам; компилятор,  который  предназначен  для  проверки  условий оперативного повторного исполнения образца прецедента, для его реализации в виде агента.Из представленных трансляторов детально представим только объектно-ориентированный интерпретатор, поскольку вложенные в него решения используются и в других трансляторах.

4.4.2. Объектно-ориентированный интерпретаторСпецифика интерпретатораСпецифику второй версии интерпретатора псевдокодовых программ определяют механизмы перехода к исполняемому коду и возможность построения объектно-ориентированных QA-программ. В процесс интерпретации используются формирование промежуточного паскале- подобного кода, метод рекурсивного спуска, преобразование в обратную польскую запись и исполнение действий, вложенных в операторы.Интерпретация  очередного  оператора  начинается  с  его  перевода на промежуточный язык (грамматика приведена в Приложении 1), заключающегося в сопоставлении оператора с соответствующим ему шаблоном, заменой синонимов ключевыми словами и пропуском последовательностей символов, не соответствующих грамматике языка.Метод рекурсивного спуска используется для разбора основных конструкций грамматики. Для реализации метода для таких элементов языка,   как   операции   INPUT,   OUTPUT,   конструкций   IF-THEN, IF-THEN-ELSE, операций присваивания, объявлений меток (LABEL), переходов по ним (GOTO) были созданы функции, осуществляющие разбор выражения.Главным для рекурсивного спуска является то, что функции разбора могут рекурсивно вызывать друг друга, в том числе и в формах прямой рекурсии. Например, при разборе конструкции IF-THEN-ELSE внутри неё может встретиться ещё одно условие, для которого опять будет вызвана функция, соответствующая разбору этой конструкции.В процессе подобного разбора происходит, например, выделение арифметических и логических выражений. Разбор таких выражений осуществляется в три этапа:

  сначала      происходит      замена      всех      имён      переменных их значениями;  затем   осуществляется   вызов   функций,   которые   содержатся в выражении;  после     чего     осуществляется     преобразование     выражения в постфиксную нотацию (обратная польская запись) с последующим вычислением значения выражения.Обратная польская запись (ОПЗ) ‒ представляет собой одну из форм записи выражений и операторов, отличительной особенностью которой является то, что все аргументы (или операнды) расположены перед операцией   (оператором).   Например,   выражение   в    традиционнойалгебраической форме(a+d)*c-b/(e+d)в ОПЗ будет иметь следующий видеa d + c * b e d + / -.Важнейшим достоинством ОПЗ является то, что вычисление, например, приведённого выражение может быть произведено за один просмотр цепочки слева направо. То же самое справедливо для любой конструкции, представленной в виде ОПЗ.В  данной  работе  применяется  алгоритм  Дейкстры  для  перевода из обычной скобочной инфиксной записи выражений в постфиксную обратную  польскую  запись.  Для  реализации  алгоритма  используется стек с приоритетами, в который по ходу просмотра строки помещаются операции.Входная строка просматривается «слева направо», и если входной символ  является  операндом,  то  он  переносится  в  выходную  строку, иначе обрабатывается по нижеприведенному принципу.  ели стек пуст, то операция просто заносится в стек;

  если  в  стеке  верхняя  операция  (элемент  стека)  имеет  более низкий приоритет, то анализируемая операция вводится в стек;  если в стеке верхняя операция имеет более высокий приоритет, то из стека выталкиваются в выходную строку все элементы, до тех пор,   пока   не   встретится   операция   с   приоритетом,   ниже   чем у рассматриваемой, после чего она проталкивается в стек; если входной символ "(", то он проталкивается в стек, а, если входной символ ")", то он выталкивает из стека в выходную строку все операции до ближайшей "(" (сами скобки при выводе из стека взаимно уничтожаются и в выходную строку не попадают).После того, как исследуемая строка преобразована в ОПЗ, она используется для управления вычислением по следующему алгоритму:1. Если очередной символ обрабатываемой постфиксной строки –операнд, то он переносится в стек операндов.2. Если очередной символ – знак операции, то из стека  извлекаются два операнда и с ними производится операция, находящаяся в конце текущего состояния обрабатываемой строки, после чего результат помещается в стек операндов, а проведённая операция удаляется из постфиксной записи.3. Когда обработка постфиксной строки завешена, в стеке операндов остаётся один элемент, который и является результатом вычислений.Отметим, что одной из проблем интерпретации, является возможная запись  интерпретируемого  оператора  более  чем  на  одном  элементе QA-данных. Например, объявление цикла может быть записано в одной QA-единице, а тело – во вложенных единицах. Ещё одна проблема связана с синхронизацией выполнения программы с её отображением в вопросно-ответном дереве.

Операционная обстановка

Базовая           операционная

обстановка     процесса

интерпретации

приведена   на   рис.   4.14   с

использованием   меток,

раскрывающих

назначение её областей.

 

 

Рис. 4.14. Главное окно интерпретатора с запросом на ввод данныхСлева визуализируется текст QA-программы. В верхнем правом окне наблюдается обрабатываемый оператор, нижнее правое окно используется для визуализации ряда запросов пользователя.По запросу «Промежуточный код» отображается результат преобразования псевдокода в промежуточный паскале-подобный код, содержащий только команды для выполнения компьютером. Команда«Словарь»   обеспечивает   управление   словарём   синонимов.   Запрос«Атрибуты» открывает доступ к дополнительной атрибутике, связанной с обрабатываемой строкой псевдокода. Вкладка «Значения переменных» позволяет  отслеживать  переменные,  объявленные  в  процессе выполнения      вопросно-ответной      программы      и      просматривать их значения. По запросу «Функции» открывается возможность работы с библиотеками функций.

В главном меню окна интерпретатора два пункта – «Выполнение» и «Прервать». Пункт меню «Выполнить» активизирует исполнение очередного шага псевдокодовой программы с возможностью  «Задать переменную» (вызывает мастер описания переменных, позволяющий пользователю в интерактивном режиме присваивать переменным типовую атрибутику и значения).  Кроме того «Выполнение» открывает доступ пользователя к функции «Работа с ошибками» (позволяет отображать или прятать окно демона контроля ошибок, отображающее ошибки, которые содержит вопросно-ответная псевдокодовая программа), а также доступ к функции «Закрыть» (закрывает главное окно интерпретатора и выгружает интерпретатор из памяти).Пункт «Прервать» осуществляет прерывание выполнения методики и запись в атрибутику текущего узла дерева вопросно-ответной программы информацию о прерывании.Объявление переменныхКак и любая другая программа, вопросно-ответная псевдокодовая программа оперирует с данными, представленными простыми переменными,  константами  и  массивами.  Для  хранения  переменных в вопросно-ответном протоколе используется дополнительная атрибутика.Для того чтобы в строке QA-программы была объявлена переменная, необходимо  вне  зависимости  от  её  типа,  чтобы  текст  этого  узла содержал имя новой переменной, а дополнительная атрибутика узла содержала атрибут «Тип переменной» со значением, содержащим её тип.В псевдокодовых вопросно-ответных программах могут быть использованы следующие простые типы данных: Целое число, число с плавающей запятой, логический булевый тип, строка. У объявления

переменной простого типа должна быть только одна выходящая из него ветка дерева, содержащая значение переменной.Для хранения сложных типов данных используется тот же принцип, как и для хранения простых типов, но дополнительный атрибут, содержащий тип переменной, создаётся как атрибут со свойствами, описывающими размерности и типы элементов. Составные части сложных типов данных записываются как объявления простых типов в ветках QA-данного, соответствующего объявлению переменной сложного типа. Сложными типами в данном интерпретаторе могут выступать одномерные, двухмерные и трехмерные массивы.Для     спецификации     переменных     используется     приписанная им дополнительная атрибутика (рис. 4.15). Она позволяет, во-первых, при приостановке выполнения работы сохранять значения переменных, а во-вторых, избежать необходимости объявления переменных в тексте программы. Если переменная находится в дополнительном атрибуте текущей QA-единицы, или в атрибуте тех единиц, интерпретация содержимого которых была осуществлена раньше, переменная считается объявленной. В атрибутике кроме имени переменной хранится ее тип и значение.Рис. 4.15.Дополнительные атрибуты QA-единицы

Для простых типов данных значения дополнительных атрибутов узлапредставлены в таблице 4.2:Таблица 4.2

Тип переменной

Значение атрибута

Integer (Целый)

Целое число

Double (С плавающей точкой)

Дробный

Boolean (Логический тип)

Логический

String (Строковый)

Строка

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

 

 

 

 
Для хранения сложных типов переменных возможны следующие значения    атрибутов:    Одномерный    массив,    двухмерный    массив (рис. 4.16), трехмерный массив. В вопросно-ответном протоколе одномерный массив представляется как узел дерева, в тексте которого содержится имя переменной, а ветками, которые выходят из него, являются объявления переменных какого-либо простого типа.Рис. 4.16. Представление одномерного и двухмерного массивов

Дополнительная атрибутика узла, содержащего массивы, содержит атрибут «VarType»: «Тип переменной» как атрибут со свойствами.Этому атрибуту приписываются следующие свойства:  Базовый тип.  Количество элементов в первом измерении.  Количество       элементов      во        втором            измерении            (для     двух-и трехмерных массивов).  Количество  элементов  в  первом  измерении  (для  трехмерных массивов).Для объявления переменных используется мастер создания переменных, вызываемый из меню главного окна (рис. 4.17) интерпретатора «Выполнение»/«Задать переменную».Рис. 4.17. Мастер создания переменныхВ строку ввода имени переменной автоматически вставляется имя переменной, определенное из текста выбранного узла дерева программы.

Мастер  позволяет  выбрать  тип  переменной,  и,  в  зависимости  от этого, открывает то или иное окно для инициализации (рис. 4.18). После объявления переменной информация о ней добавляется в атрибутику узла дерева программы. Кроме этого, при обнаружении необъявленной переменной, демон контроля ошибок автоматически вызывает для неё мастер  создания  переменных,  в  котором  пользователь  имеет возможность указать её тип.Рис. 4.18. Мастер создания переменных

Работа с объектами и дополнительной атрибутикойДля поддержки объектно-ориентированного программирования грамматика псевдокодового языка была дополнена операциями доступа к  полям  и  методам  класса,  а  также  –  создания  дополнительных атрибутов произвольного типа.Работа с полями метода, как и с дополнительными атрибутами, осуществляется так же, как и с переменными – им можно присваивать значения, использовать в арифметических и логических выражениях, осуществлять над ними операции ввода-вывода. Для получения доступа к полю FIELD1 переменной &a& используется запись:&a& -> &field1&К примеру,        присвоить      переменной   &c&    значение         FIELD1,умноженное на 2, можно следующим образом:&c& := &a& -> &field1& * 2При выполнении операции присваивания, если объект не содержит запрашиваемого поля, оно автоматически создаётся.Имеется  возможность  создать  атрибут  произвольного  типа.  Для этого перед именем атрибута следует указать его тип, например, запись:&a& -> (AttrType)&newattr& := 1вызывает создание дополнительного атрибута &newattr& типа AttrType и  привязывает  его  A-единице  вопросно-ответного  протокола, содержащей    значение    переменной    &a&.     Если     тип     AttrType не существует, происходит его создание.Для вызова метода Method объекта &a& используется запись&a& -> &Method& (p1, p2, p3, …, pn),которая используется так же, как вызов функции из подключаемой библиотеки, где p1, p2, p3, …, pn ‒ параметры функции. Вызовы методов можно  использовать  в  арифметических  и  логических  выражениях.

Записи имён полей и методов к регистру не чувствительны, возможна замена их синонимами.Для добавления метода из процедуры, реализованной в псевдокоде, используется пункт меню «Добавить метод», который открывает диалоговое   окно   (рис.   4.19),   позволяющий   привязать   процедуру из реализованных в псевдокоде как метод.Рис. 4.19. Диалоговое окно выбора методаДля использования в качестве метода функции из подключаемой библиотеки  используется  кнопка  «Как  метод»  вкладки  «Функции» (рис. 4.20):Рис. 20. Вкладка «Функции»Дополнительная атрибутика единиц вопросно-ответного протокола позволяет         реализовать         объектно-ориентированный        подход

в псевдокодовом программировании (рис. 4.21). Любая объявленная переменная считается объектом. Объект может содержать как поля, так и  методы.  Для  их  описания используются дополнительные атрибуты A-единицы, содержащей значение переменной.Рис. 4.21. Переменная &a& с присвоенным значением.Поле представляет собой дополнительный атрибут типа FIELD, имя атрибута – имя поля класса, значение – значение поля.В качестве метода может выступать любая, объявленная ранее процедура или функция из заранее скомпилированной библиотеки функций.    Метод    привязывается    к    дополнительной    атрибутике A-единицы вопросно-ответного протокола (рис. 4.22), содержащей значение единицы, следующим образом:1.   Создаётся атрибут типа Method.2.   Имя атрибута устанавливается в соответствие с именем процедуры или функции.3.   Этот атрибут присваивается (assign) А-единице вопросно-ответного протокола.4. Значение атрибута устанавливается в «pcode» для процедур, содержащихся в исполняемом псевдокоде, в случае использования скомпилированной подключаемой библиотеки функций – в значении указывается имя файла библиотеки функций.

Рис. 4.22. Пример с дополнительными атрибутамиНа  рис.  4.22  показаны  дополнительные  атрибуты,  присвоенные A-единице переменной &a&.  Эти  атрибуты содержат  информацию о двух полях и двух методах, содержащихся в объекте &a&. Детали приписывания значений приведены в таблице 4.3:Таблица 4.3

Часть объекта

Имя

Описание

Поле

FIELD1

Значение поля: 10

Поле

FIELD2

Значение поля: 376

Метод

formula1

Представляет  собой  метод,  содержащийся  впсевдокоде выполняемой программы. На рис.4.21  показана  процедура,  являющаяся  этим методом

Метод

CPUTemp

Метод,  содержащийся  в  скомпилированнойподключаемой библиотеке функций hwlib.dll

Словарь синонимовКак говорилось выше, для замены синонимов ключевыми словами потребовалось программное решение,  позволяющее  автоматизировать эту операцию и дать пользователю возможность расширять этот словарь.Плагин реализует следующую функциональность:             Добавление ключевого слова            Поиск всех ключевых слов          Добавление синонима к ключевому слову         Поиск синонимов к ключевому слову    Поиск ключевого слова по синонимуИсходя из особенностей реализации первого этапа интерпретации, поиск ключевого слова по синониму должен вернуть ключевое слово даже  в  том  случае,  если  в  качестве  входного  параметра  задан  не синоним, а само ключевое слово.Рис. 4.23. Клиентская часть словаря синонимов.

Демон контроля ошибокДля облегчения разработки псевдокодовых программ был создан демон проверки ошибок. Он реализован в виде отдельного класса, который с заданным интервалом времени запускает интерпретатор для загруженной псевдокодовой программы с параметром проверки. Запуск интерпретатора с параметром проверки имеет ряд особенностей:  Измененные значения переменных не сохраняются.  При выполнении операций ввода вместо запроса пользователя значение вводимой переменной не изменяется.  Операции вывода значения пользователю не выполняются.  При    выполнении  условного            оператора       выполняются оба действия – после THEN и после ELSE.  Циклы выполняются один раз.  Оператор GOTO не выполняется.  При возникновении ошибки выполнение продолжается.При возвращении интерпретатором сообщения об ошибке она попадает в список, который может быть извлечён из демона, к примеру, для отображения пользователю в окне.Подключаемые библиотеки функцийПодключаемые библиотеки функций реализуются как динамические библиотеки классов Microsoft.NET. Каждая библиотека функций содержит в себе массив с описаниями функций и статические методы, возвращающие название библиотеки и список функций с описаниями, которые эта библиотека содержит.При подключении библиотеки происходит получение из неё списка функций  и  имени  библиотеки,  после  чего  с  помощью  серверного плагина список функций погружается в базу данных.

Интерпретатор псевдокода в промежуточный код, встречая имя функции,  сохраняет  его  и  передаёт  в  промежуточный  код. Интерпретатор промежуточного кода, встречая самостоятельный вызов функции или её использование в выражениях, вызывает соответствующий  метод  библиотеки  классов,  передавая  в  него указанные параметры. После чего используется возвращённое значение функции.Библиотеки функций представляют собой библиотеки классов Microsoft.NET,    содержащие    в    себе    функции    и    их    описания. В библиотеке функций указываются такие её характеристики, как имя библиотеки, текстовые описания  функций и  тип  их  выходного параметра.Библиотека функций реализуется следующим образом:namespace FuncLib{public class ExtFunctions{private static string[,] functions = {{"<Имя функции1>", "<Тип возвращаемого значения>", "<Текстовое описание>"},{"<Имя функции2>", "<Тип возвращаемого значения>", "<Текстовоеописание>"},{"<Имя функции3>", "<Тип возвращаемого значения>", "<Текстовое описание>"},{"<Имя функции4>", "<Тип возвращаемого значения>", "<Текстовоеописание>"}};private static string LibName = "<Имя библиотеки>";public static string[,] GetFunctions(){return functions;}public static string GetLibName(){return LibName;}}}

Для  каждой  функции  программируется  соответствующий  метод класса ExtFunctions. Возвращаемый тип указывается в массиве functionsв соответствии с таблицей 4.4:Таблица 4.4

Возвращаемый тип функции

Тип в массиве functions

void

VOID

Int

INTEGER

bool

BOOLEAN

double

DOUBLE

4.4.3. Формирователь интерфейсных сборокОдной из принципиальных составляющих современных компьютерных  программ  является  интерфейсная  оболочка, выполняющая как функции, обеспечивающие человеко-компьютерное взаимодействие, так и функции интеграции составных частей сложных программ в целостности.По крайней мере, по этим причинам в QA-программирование задач целесообразно ввести средства создания традиционных интерфейсов. Такие средства разработаны и их набор  включены в состав комплекса OwnWIQA. В основу построения необходимых пользователю интерфейсных модулей также положено QA-программирование.QA-программа каждого интерфейсного модуля формируются автоматизировано, из предварительно построенной интерфейсной диаграммы.Интерфейсная диаграмма – это «block and line» схема интерфейсного модуля, в которой интегрируются аналог диаграммы прецедентов (use-case диаграммы), диаграмматическая модель предметной области (в форме набора классов, согласованного с use-case диаграммой) и контекстная диаграмма, объединяющая интерфейсные элемены в группы.

Интерфейсные диаграммы определены и специфицированы так, что для построения интерфейсного модуля пользователь должен  нарисовать его схему (в форме интерфейсной диаграммы), которая затем будет автоматически   переведена   в   предварительный   код   интерфейсной QA-программы.Пользователю OwnWIQA для создания традиционных человеко-компьютерных интерфейсов предоставляется набор инструментов QA-программирования, который специализирован на построения таких интерфейсов, причём, связанных с исполняемыми кодами .Полная последовательность действий и преобразований [33], приводящая к построению интерфейсного модуля, включает следующие работы:1. Сформировать интерфейсную диаграмму с использованием встроенного редактора.2.  Сформировать в вопросно-ответном протоколе абстрактную модель пользовательского интерфейса на основе построенной интерфейсной диаграммы.3.  Сформировать     конкретную     модель     пользовательского интерфейса в вопросно-ответном протоколе на основе данных абстрактной модели и интерфейсных прецедентов.4.  Конкретизировать конкретную модель в автоматизированном режиме    с    целью    выбора    необходимых    элементов    управления и определения условий их использования.5.   Если      достигнут      необходимый      уровень      детализации, то сформировать псевдокодовое представление пользовательского интерфейса.6.   Из псевдокодового представления сформировать интерфейсную сборку на целевой платформе.

7.   Если  необходимо ‒  внести изменения в  необходимые модели и повторить методику с нужного шага до генерации исполняемой сборки на целевой платформе.В основу приведённой совокупности работ положены механизмы аспектно-ориентированного выбора и визуализации точек интерактивного    взаимодействия,    их    псевдокодовое    кодирование и   сериализация  с   использованием  xml-преобразований,  выводящих на библиотеку кодов интерфейсных метрик.На скриншоте операционной обстановки (рис. 4.24), обслуживающей автоматизированное   построение   интерфейсных   модулей,   отраженаважная роль дополнительной атрибутики.КомандыQA-программаБиблиотека атрибутовАтрибутыРис. 4.24. Атрибутика в построении интерфейсных модулейВ процессе формирования интерфейсных модулей, интерфейсные элементы, выводящие на процессы, связываются с соответствующими исполняемыми кодами.  При  необходимости модно  строит  не  только

сборки в рамках интерфейсного модуля, но и связывать такое модули в необходимые программные образования.4.4.4. Инструментальная среда QA-программированияПредставленные выше средства QA-программирования, ориентированного на прецеденты, обеспечивают решение типичных задач инструментальных сред компьютерного программирования, что приводит к вопросам их комплектации и организации, подобной инструментальным средам компьютерного программирования.Традиционно в состав инструментальной среды программирования включают  средства работы с файлами определённых типов, текстовый редактор, обслуживающий построение текстов программ, а также средства трансляции, тестирования и отладки.Из перечисленных средств, в комплекс OwnWIQA явно или неявно включены все, правда, их организация средства доступа, отличаются от традиционных. Организующую основу QA-программирования определяет  их  систематизация,  вложенная  в  комплекс  OwnWIQA. В этой систематизации отсутствует удобная для QA-программирования системная работа с файлами.Принято решение расширить систематизацию OwnWIQA, нацелив её на удобную работу с файлами. Для этого создаётся специализированная подсистема, разработка которой на момент написания текста монографии практически завершена. Особо важным является то, что эта подсистема выводит пользователя на запись исходного кода QA-программ за рамками QA-протоколов. Для этих целей в число инструментов включены текстовый и графический редакторы.Текстовый редактор обеспечивает формирование и регистрацию необходимых пользователю QA-текстов в rtf-формате. В таких текстах

пользователь  маркирует  QA-единицы,  в  том  числе,  отделяя  их  друг от друга, с помощью исходных системных имён (как тегов).При построении QA-текстов открыт обмен с другими компонентами или  приложениями  через  буфер,  что  позволяет,  в  принципе, формировать необходимые тексты в других текстовых редакторах, например     в     Microsoft     Word.     Однако     перенос     QA-текстов в их представление в QA-базе осуществляется только из встроенного в OwnWIQA текстового редактора.Для переноса QA-текстов из инструментальной среды в QA-базу используются  механизмы  xml-сериализации.  В  процессе  загрузки  в QA-базу   системные   имена   настраиваются   на    «место   загрузки» QA-программы.

 

 
В графический редактор встроены средства индексации текстовых меток, позволяющие связать эти метки с файлами и использовать их для перехода к исполняемым кодам. На рис. 4.25 представлена операционная обстановка графического редактора с рисунком «block and line» схемы, соответствующей сборке образца прецедента.Рис. 4.25. Диаграмматическая сборка моделей прецедента

Пример демонстрирует ещё одну возможность осуществлять интерфейсную сборку QA-программ в более сложные программные образования.Завершая пункт и главу, отметим, что в инструментальную интерпретацию  WIQA.Net,  унаследованную  комплексом  OwnNet, можно  внести дополнение. В  систему инструментов OwnWIQA встроена инструментальная среда QA-программирования, ориентированного на прецеденты. В интегральном плане среда OwnWIQA – это инструментальная среда персональной человеко- компьютерной деятельности, основанной на прецедентах, для построения,    освоения    и     использования    которых    используется QA-программирование.В постоянном развитии комплекса WIQA, обусловленном разработкой  очередных  приложений  с  использованием  его инструментов, создание комплекса OwnWIQA привело к  включению в инструментарий WIQA средств QA-псевдопрограммирования, ориентированного на прецеденты. Такие средства существенно расширили  возможности  QA-программирования,  которые  были встроены в комплекс WIQA до разработки OwnWIQA.Выводы по четвёртой главе1. Одной из специфик инструментария WIQA является то, что он способен    выполнять    функции    оболочки,    которая    включается в приложения, разработанные в среде WIQA.2. Оболочка, наследуемая приложением, адаптируется под его предметные задачи, исходя из двух версий её интерпретации – интерфейсной и инструментальной.3. В интерфейсной интерпретации QA-процессор выполняет функции посредника между активностями человека и компьютера, который     настроен    на     построение    и     использование    моделей QA-рассуждений,                   способствующих                   естественному

программированию,   с   одной   стороны,   и   обслуживает   запросычеловека к компьютеру, с другой стороны.4.      Интерфейсная      интерпретация      методов      и      средств QA-моделирования    позволяет    утверждать,    что    за    применением QA-процессора стоят новые, существенно отличающиеся от известных, средства человеко-компьютерного взаимодействия.5. Сущность инструментальной интерпретации комплекса WIQA определяет то, что комплекс способен обеспечить разработку приложений,  в  которых  человеку  или  группе  лиц  приходится оперативно решать задачи в человеко-компьютерных средах, опираясь на опыт предыдущей человеко-компьютерной деятельности.6.  Специфика инструментальной интерпретации заключается втом, средства разработки приложений наследуются из комплекса WIQA как инвариантное ядро (комплекс базовых программных, обслуживающих концептуальное решение задач), к которому добавляются программные расширения, учитывающие специфику создаваемых приложений.7.            Материальное            сопровождение            интерфейсной и инструментальной интерпретаций комплекса WIQA открыло возможность для построения комплекса OwnWIQA, обслуживающего персональную человеко-компьютерную деятельность простого человека, создающего и использующего в такой деятельности необходимые образцы прецедентов.8. Эволюция QA-моделирования, по ходу которой были освоены простейшие формы QA-программирования, в комплексе OwnWIQA доведена до форм вопросно-ответного псевдопрограммирования, позволяющих простому человеку создавать нетривиальные программы.9. Сложность QA-программ, доступная конкретному пользователю инструментов OwnWIQA, соответствует тем способностям естественного программирования (N-программирования, Natural Programming), которыми он обладает.10.        Вложенные        в        комплекс        OwnWIQA        средства QA-программирования обеспечивают создание QA-программ всех типов, о которых говорилось в монографии, среди которых вопросно- ответные       псевдопрограммы       наиболее       приближены       как к N-программам, так и к К-программам.11. В QA-программировании, как и программировании любого другого  типа,  используется  рациональный  учёт     дополнительности«данные  +  операции»,  в  котором  принципиальное  место  занимаетQA-модель данных.

12. Потенциал QA-модели данных достаточен для эмуляции на её основе  любых  традиционных  типов  данных,  каждый  из  которых, кроме присущих ему свойств, реализованных с помощью средств дополнительной атрибутики, наследует исключительно полезные для псевдопрограммирования свойства QA-модели данных.13. Создатель QA-программы, объявляя любую переменную традиционного  типа,  может  существенно  расширить  как декларативную, так и операционную составляющие типа, в частности, вложив в объявление необходимый ему объём семантики.14. Потенциал QA-модели данных достаточен и для эмуляции традиционных операторов псевдоязыков программирования, причём, также как и в эмуляции данных, любой эмулированный QA-оператор наследует свойства QA-модели данных.15. В эмуляции QA-переменных и QA-операторов различаются системная эмуляция, встроенная в комплекс OwnWIQA и доступная для QA-программирования любых задач, и эмуляция, вводимая пользователем для QA-программирования его собственных задач, если такая эмуляция принесёт ему пользу.16. Системная эмуляция реализована в объёме, позволяющем создавать  объектно-ориентированные  псевдопрограммы,  а   также с использованием средств, обеспечивающих построение образцов прецедентов, в том числе и в формах программных агентов.17.      Материализована      не      только      системная      эмуляция, но и инструментальная среда QA-программирования, обеспечивающая традиционные    потоки    работ    построения,    трансляции,    отладки и тестирования QA-программ любых типов.18. Инструментальная среда QA-программирования предоставляет пользователю    набор    средств    для    введения    в    QA-программыисполняемых кодов других типов, а также для сборки  QA-программ в комплексы, в том числе и для сборки образцов прецедентов.