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

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

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


3.1. среда вопросно-ответного моделирования задач

3.1.1. Предназначение среды и ретроспектива разработкиСреда вопросно-ответного моделирования задач, в её исходном замысле и предназначении, создавалась автором и его учениками для инструментальной          поддержки          коллектива          разработчиков в  концептуальном  проектировании  сложных  автоматизированных систем (АС), интенсивно использующих программное обеспечение.За  25  лет  исследований  и  разработок  был  создан  ряд  версий вопросно-ответного инструментария, получившего название WIQA (Working In Questions and Answers) [27]. В разработках накоплен богатейший опыт человеко-компьютерной деятельности, объектом которой являются сложные задачи, решение каждой из которых проводится  коллективом  проектировщиков  и  лицами, заинтересованными в разработке АС.Отметим,  что  разработка  сложных  АС  слишком  часто  приводит к результатам, которые не соответствуют запланированным ожиданиям. Значительное число разработок либо прекращается, либо превышает запланированное  время  и  /или  средства,  либо  завершается  в  более бедной версии. Степень успешности, выраженная в процентах числа проектов,  завершившихся  в  соответствии  с  исходными  замыслами и планами, чрезвычайно низка (около 35\%) [42, 73].

Разработка сложных АС связана с решением задач (обозначим их класс    как    Z*),    которое    невозможно    без    строгой    дисциплины и  рационального использования опыта  проектирования, как накопленного в предыдущих разработках, так и оперативно порождаемого в исполняемых проектах. Другими словами, для решения задач типа Z*, образно представленного на рис. 3.1, принципиальное значение имеют прецеденты, вложенные в технологии и обеспеченныенеобходимым инструментарием.

Технология Опыт

Задача Z*

Инструментарий Модели опыта

Рис. 3.1.  Коллективное решение сложных задачТак, например, в технологии RUP для концептуального проектирования проектировщикам доступны около 500 типовых задач, за решениями которых стоят прецеденты, отобранные из лучших практик, эффективным образом представленные и интерактивно доступные по оперативным запросам.Инструментальная среда WIQA предназначена для моделирования задач типа Z*, а значит и всех подчинённых задач, включая типовые проектные задачи. С помощью инструментария WIQA для очередного проекта его разработчики могут собрать и связать в единое целое типовые задачи, модели которых заимствованы из разных технологий, в том числе и из технологии RUP.

В разные годы в создание комплекса средств WIQA, кроме автора монографии, полезные вклады внесли следующие его ученики: Вербиченко Д.С., Беляев К., Левицкий А.Ю., Семенов В.Н., Соснина Е.П., Тюрин С.А., Шамшев А.Б. (средства вопросно-ответного протоколирования решений задач и преобразования QA-протоколов); Ахметов Р.К.,  Валюх В.В.,  Карпова И.Р.,  Кальянов А.К., КононенкоА.И., Сорокин И.Н., Соловьев М.В., Шамшев А.Б. и Шембергер,   (средства предикативной обработки вопросно-ответной документации);  Афанасьев А.Н., Будыхо Е.Ю., Евсеева О.Н., Карпушин А.Н., Касапенко Д.В., Красовский С.П., Павлыгин Э.Д., Шишкин В.В., (практические реализации вопросно-ответных приложений); Власенко О.Ф., Илюхин А.Н., Соловьева М.В., Соснина Е.П. (исследования логик практического рассуждения);  Карпушин  А.Н.,  Маклаев  В.А.,  Мулин  А.С.,  Салмов  А.В., Святов   К.В.,   Степченко   М.В.,   Типикин   В.В.,   Хайруллин   Р.К., Шамшев А.Б. (сетевые версии реализации QA-процессора, в том числе с Web-доступом); Карпушин А.Н., Макаров П.С., Святов К.В., Соснин Д.П. (автоматизированное обучение в вопросно-ответных средах)  Святов К.В., Ярушкина Н.Г. (средства человеко-компьютерного взаимодействия, интерфейсное обеспечение); Хайруллин   Р.К.,   Чикалёва   Н.А.,   Шамшев   А.Б.   (базы прецедентов); Заболотнов  С.А.,  Лапшов  Ю.А.,  Шамшев  А.Б.  (средства псевдокодового программирования и агентные решения, интерпретаторы и компиляторы).

3.1.2. Концептуальное решение задачИнструментарий WIQA предназначен для решения задач на этапе концептуального проектирования АС, когда осуществляется построение концептуальных решений задач, то есть построения решений задач на естественно-профессиональном языке в его алгоритмическом употреблении.Специфика концептуального решения задач в инструментальной среде WIQA отражена на рис. 3.2 и рис. 3.3. На первом из этих рисунков показано, что по   ходу решения основной задачи Z*(t) коллектив проектировщиков шаг за шагом формирует дерево задач проектов, подзадачи которого оперативно распределяются между ними. Каждый из них в рамках возложенной на него ответственности, проводит вопросно-ответный анализ очередной подзадачи для перехода на очередной уровень пошаговой детализации.Форма   оперативного   представления   задач,   ориентированная  наитеративный процесс разработки, приведена на рис. 3.2.

Z*(t) Z1Z11Z12Z1mZ2Z21Z22Z2nZpZp1Zp2Zpr Итеративный процесс+Управляемоераспределение задач+Пошаговая детализация+Вопросно-ответный анализ

Рис. 3.2. Формирование дерева задач

ZI.k(tkN)

ZI.k(tk1)Исходная постановка задачи Процесс решения

ZI.k(tk0) ZZ1                             Z11Z12 1Результат,   полезный   эффект   выполненияПрецедента для каждого участника1В    случае    успешного    решения    ЗадачиПервичного Актора1В случае неудачи (гарантии участникам)1Предусловия     –      ситуация     к      началувыполнения Прецедента1Триггер    –    событие,    которе    запускает выполнение Прецедента

32Z1mZ2Z21Z22Z2nZpZp1Zp2Zpr

Библиотека моделей {QA(MK )}    Q                                 Q11

j

 
Q1       A1Q12Q1m A11A12A1m

Q2       A2Q21Q22Q2n A21A22A2n

Analysis Qp       ApQp1Qp2Qpr Ap1Ap2Apr

Подпись: -121-TransformationRepresentationsVisualizationFigure 2. Logical view

 

121

 

j

 
Библиотека концептуальных моделей {MK }Рис. 3.3. Концептуальное решение задач

Эта сущность заключается в том, что по результатам вопросно- ответного анализа любой постановки задачи или подзадачи ZI.k(tk0), независимо   от   того,   на   каком   уровне   детализации   он   находится и регистрируется, из библиотек вопросно-ответных и концептуальных моделей  (по  ключевым  словам  анализа)  отбираются  подходящие шаблоны, которые включаются в состав концептуального решения.Эти    шаблоны   заполняются   адекватной   информацией,   которая (по цепи обратной связи) включается в очередные детализированные варианты постановки задачи ZI.k(tk1), ZI.k(tk2), ZI.k(tkN). Процесс продолжается до тех пор, пока состояние концептуального решения не окажется достаточным для успешной работы на последующих этапах.Отметим,   что   за   каждым   шаблоном,   выбранным   из   библиотек и включённым в решение задачи, стоит определённая модель прецедента, подтвердившего целесообразность его включения в опыт проектирования.В  дереве  задач  особо  важны  два  типа  задач  –  задачи  проекта и  служебные задачи.  Задачи  ещё  одного  типа,  получившего название«технологические задачи», обеспечивают использование инструментальных средств системы WIQA и также включаются в это дерево, но в служебных целях.В процессе концептуального решения у технологических задач своя роль, которая отражена на рис.

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

удобства  в  работе  с  действиями,  а  также  сокращает  время  доступак командам и плагинам инструментария WIQA.

Проектные задачи ZP Технологические задачи ZT 1Сервисные   tзадачи ZC

МоделиQA(ZP) Модели           2QA(ZC)

Рис. 3.4. Отношения между задачамиЛиния действий 2 открывает непосредственный доступ непосредственно к командам и плагинам, но не к их связным совокупностям. Эта линия остаётся открытой и при наличии линии действий 1. Более того, есть возможность переключаться между линиями, что повышает гибкость в действиях разработчика.3.1.3. Вопросно-ответная модель задачиКаждая задача ZI.k в дереве задач Z*(t) порождается в процессе вопросно-ответного анализа задач ZI как определённый вопрос Qr, на который в опыте проектировщика и доступных ему моделях опыта не нашлось ответа.Кроме  того  для  каждой  задачи  ZI.k  для  построения  её концептуального решения в среде WIQA полезно применять её вопросно- ответный анализ (QA-анализ). По этим двум причинам автором определена вопросно-ответная модель задачи, позволившая единообразным  образом  представить  и  материализовать  задачи  всех типов, решаемые на концептуальном этапе проектирования АС.

Реализация каждой вопросно-ответной модели QA(Zi) задачи Zi начинается  с  загрузки  в  определённый  момент  времени  tp   задачи  Zi в дерево задач проекта АC и закрепления за этой задачей проектировщика Sbr, ответственного за её решение. Именно проектировщик будет создавать   модель    QA(Zi,    t),    возможно   обращаясь   за    помощью к   доступным   интеллектуальным   ресурсам.   Напомним,   что   доступ к модели QA(Zi, t) в любой момент интервала (tp, t) открыт для любого члена группы проектировщиков {Sbr}, получившего на это право.Более того, каждая модель QA(Zi) создаётся как специализированнаяавтоматизированная система ACQA(Zi), включаемая в комплекс WIQA как её  подсистема,  а  роль  образца  для  построения  ACQA(Zi)  выполняет типовая    архитектура    QA-модели,    представленная    на    рис.    3.5.В архитектуре  отражён тот факт, что модель построена на базе задач технологии   RUP,   а,   вернее,   технология   RUP   использовалась   какважнейший источник требований к реализации QA-моделей.Типовые задачи концептуального проектирования в RUPИнтеллектуально-организационный

КоммуникативныйОнтологический

Логико-

 
Проблемно- ОпытаЗадачный видЛогико- Мотивационно-целевойТеоретическийОбучающий

ориентированныйДокументный лингвистический Событийный

Диаграммный Деятельностный

НормативныйЗадачи концептуального проектирования АСРис. 3.5. Архитектура типовой QA-модели

Отметим, что типовая QA-модель, в первую очередь, представляет собой  связанную  совокупность  образцов  (артефактов,  моделей, процедур), которая для каждой задачи и любой из её  подзадач шаг за шагом  (пошаговая  детализации  +  итерации)  наполняется информационным содержанием [27], извлекаемым из реальных рассуждений  разработчиков  АC.  Специфика  типа  задачи  учитывается в настройке архитектурных видов экземпляра модели.Образцы, вложенные в конкретную модель, объединены в группы, каждая  из   которых  отражает  определённый  архитектурный  вид  на QA-модель. Система архитектурных видов, их материальная реализация и    инструментальная    поддержка,    рассчитаны    на    профессионалов и  детально  представлены  в  [27].  Для  содержания  монографии  важна только часть видов и часть инструментального потенциала. По этой причине представим только основные виды QA-модели, а вернее специализированной системы ACQA(Zi).1. Логико-лингвистический вид QA-модели представляет собой еёсистемное представление, образованное с логико-лингвистических позиций, или, другими словами, с позиций логики вопросов и ответов с учётом естественно-профессионального языка L их выражения. В своей простейшей  версии,  когда  у  моделируемой  задачи  отсутствуют подзадачи, логико-лингвистический вид изображён на рис. 3.6.За  каждым  узлом  схемы  рис.  3.6,  помеченным символами Q  и  A с индексами, стоит интерактивный объект, представляющий соответствующий вопрос или ответ. Уникальные индексные имена этих объектов и их содержательное описание на языке L, связанные отношениями логики вопросов и ответов, образуют интерактивную сеть объектов, открытую для развития, визуальных просмотров, навигации по сети и доступа к глубинному содержанию её узлов.

Z.К.1.1QQ1    A1Q11Q12Q1m A11A12A1m

Q2       A2Q21Q22Q2n A21A22A2n

Qp       ApQp1Qp2Qpr Ap1Ap2Apr

Рис. 3.6. Вопросно-ответная схема QA-моделиЛингвистическая составляющая вида дополняет логическую схему текстами каждой её единицы. Динамику вида определяет то, что он создаётся и регистрируется как протокол, во-первых, процесса решения задачи, а, во-вторых, процесса перевода рассуждений, используемых при решении  задачи,  на  язык  вопросов  и  ответов  LQA.  По  этой  причине«Логико-лингвистический      вид»    QA(t)  получил          название«QA-протокола».Отметим, что на множестве «вопросов» и «ответов» принято различать  их  типы  и  подтипы,  выделяя,  например,  «что»-,  «как»- и «ли»-вопросы или вопросы типов «проблема», «задача» или «запрос» [24]. С разных позиций подходят и к типам «ответов», выделяя среди них, например, «решения», «требования» или «идеи».В том случае, когда в решении задачи используются подчинённые и служебные подзадачи, общий QA-протокол задачи состоит из базового QA-протокола главной задачи, связанного с QA-протоколами подчинённых и служебных задач (рис. 3.7).

БазовыйQA-протоколQQ1  A1Q11Q12Q1m A11A12A1m QA-протоколы подчинённых задач

Q2       A2Q21Q22Q2n A21A22A2n QA-протоколы служебных задач

Qp       ApQp1Qp2Qpr Ap1Ap2Apr

Рис. 3.7. Схема логико-лингвистического видаОтметим ещё раз, что «QA-протокол», как и другие виды QA-модели задачи, является интерактивным образованием, открытым для взаимодействия в процессах его формирования и использования.2. Задачный вид. Как уже отмечалось любая задача Z.I.k дерева задач проекта, для которой строится и используется её QA-модель, может включать совокупность подчинённых (проектных и служебных) задач. Схема отношений между задачей Z.K и её подчинёнными задачами, приведена на рис. 3.8, где символ «0» в индексе задачи используется для выделения служебных задач.Схема задачи Z.K, представленная на рис. 3.8 является не только схемой  отношений  между  задачами,  но  и  схемой  отношений  между QA-моделями этих задач. Ничто не мешает приписать  этой схеме статус вида QA-модели, возложив на него функции вида на объект моделирования. Исходя  из  такой  интерпретации, на  базе  схемы  задач

формируется и  используется интерактивный объект  «Задачный вид»,регистрирующий представление задач в рамках QA-модели.

Z.К. «Задачный вид» QA-модели задачи Z.K

Z.К.0. Группа служебных задач

Дерево задач Z.К.1 ZК.0.iZ.К.1.0Z.К.1.1 Группа служебных задачГруппа служебных задач

проекта АС ZК.1.j

Z.K.1.2Рис. 3.8. Типовая схема отношений между задачами в проекте АС«Задачный вид», как и «Логико-лингвистический вид», состоит из вопросов и ответов, но «вопросов-задач» типа Z и «ответов-решений», отражающих опыт решений. В этом плане за «Задачным видом» стоит ZE-модель, входящая в состав QA-модели и включающая ZE-протокол, родственный QA-протоколу. ZE-модель расширяет QA-модель за счёт расширения типологии «вопросов» и «ответов». Поэтому существенная часть того, что относится к QA-моделям, имеет место и для ZE-моделей.«Задачный вид» является динамическим интерактивным объектом, в  жизненном  цикле  которого  «ответы-решения»  проходят  ряд состояний,  обладающих  статусом  «целостности»,  в   число  которых входят «идея-гипотеза решения», «концептуальное решение», «код решения», «результат решения» и «прецедент».

3.1.4. Вопросно-ответный процессорПоследняя версия инструментарий WIQA, представленная структурно на   рис.   3.9,   реализована  на   базе   инструментально-технологических средств  «.Net   3.5»,   включающих  «.Net   Remoting»  для   связыванияраспределённых приложений.QA-база     ADO.Net

QA-плагин ..-плагины Серверные плагины:

Сервер Плагины

 

 

..-plug-in

 
QA-плагин

.NetRemouting ..-плагины

Коннектор ..-агенты-agent

КлиентРис. 3.9. Процессор WIQA.NetНа рисунке версия названа процессором, чтобы подчеркнуть, что её основное  предназначение  –   моделирование  задач  –   осуществляется с  помощью  использования  типовых  конструктов  (интерактивных объектов типов «задача», «вопрос» и «ответ») и операций над ними. Позиционирование инструментария как процессора позволяет легко перейти к его интерпретации как моделирующей среды для разработки приложений     разного     вида,     а     не     только     как     приложения,

поддерживающего    коллективное            концептуальное        проектирование.Процессор WIQA.Net детально представлен в публикации [27].Напомним, что интересы монографии сосредоточены на программировании задач обыкновенным человеком, а не профессиональным программистом. Но такой акцент вовсе не означает, что   для   его   работы   обыкновенному   человеку   будут   достаточны«примитивные»            инструменты.            Нужны           потенциально            мощные инструменты, сложность которых «спрятана» от их пользователей.Ниже процессор WIQA.Net, несмотря на то, что он предназначен для решения сложных задач, будет адаптирован для его применения обыкновенным пользователем для решения тех задач, с которыми он сталкивается. По этой причине, а ещё и потому, что процессор WIQA.Net детально представлен в публикации [27], только эскизно раскроем многослойный компонентный состав этого процессора:Слой баз данных. Реализован с использованием технологии ADO. Net. На него возложена функция хранилища всех данных систем, в том числе  базы  знаний  с  продукциями  декларативного  и  процедурного типов.Серверный рефлексивный слой. Слой реализован в виде набора серверных плагинов. Он формируется динамически во время запуска сервера с использованием технологии динамической рефлексии типов, которая  поддерживается  платформой  .Net  за  счет  наличия  в  каждой сборке блока описания всех типов, содержащихся в сборке.Слой сервера. Слой реализован с использованием технологии .Net Remouting, что позволяет обращаться к нему удалённо с клиентских мест в многопользовательском режиме работы.Слой коннектора (промежуточный слой). Обеспечивает доступ к функциям удалённого объекта. В коннекторе хранится интерфейс сервера.

Расширение функциональности сервера получается за счёт использования функции серверного рефлексивного слоя.Клиент.   Слой   отвечает   за   программную  инкапсуляцию  работы с клиентским рефлексивным слоем (клиентскими плагинами), инкапсуляцию удалённого взаимодействия с сервером (и, следовательно, с серверным рефлексивным слоем и с модулем синхронизации действий пользователя в многопользовательском режиме).Клиентский  рефлексивный  слой.  Слой  состоит  из  двух  частей: части активного взаимодействия с пользователем и части, которая (за счёт работы программных агентов) настраивается на определённые события в системе.3.1.5. Опыт вопросно-ответного моделирования задачПроектированиеКак  уже  отмечалось выше,  инструментарий WIQA разрабатывался для поддержки процессов концептуального проектирования сложных АС коллективом разработчиков в корпоративной сети. Важнейшей составляющей такой поддержки является система технологических задач, обеспечивающих автоматизированную реализацию процесса проектирования в базисе функциональных возможностей, доступных проектировщикам.Система технологических задач представляет собой библиотеку методик, каждая из которых оформлена как псевдопрограмма. В версии WIQA, реализованной на языке Дельфи, в работе с методиками не использовались  средства  автоматизации  их  исполнения проектировщиком. Система методик была представлена в форме сайта, к   которому   можно   было   обратиться   за   подсказкой  об   очередных

действиях  в  очередной  исполняемой  методике.  Методика,  с  которой начиналась работа над проектом, имела следующий вид:1.  Задача  «Концептуальное  проектирование»//  Активизируется с клиентского места руководителя проекта;1.1. Выполнить работу «Открыть проект»1.2. Выполнить работу «Определить сущность проектирования».1.3. Подготовить концептуальное проектирование к итерациям1.4. Выполнить для итерации работу «Решить задачу» для основной задачи проекта1.5. Выбрать задачу ZM  из множества задача {Zr} , где M – индекс

задачи. 1.6. Выполнить работу «Решить задачу» для задачи ZM.1.7.   Выполнить  работу  «Построить  прототип»  для   решённой

задачи ZM.1.8. Если множество задач {Zr} не пусто, то Перейти к п.2.4. иначеЕсли Не достигнута достаточная определённость в результатахконцептуального проектирования, то Перейти к очередной итерации по п.2.3.1.9. Завершить концептуальное проектированиеКаждая работа, названная в методике «Концептуальное проектирование», выполнялась по методике, которая выбиралась из их системы.Проблемы с псевдопараллельным выполнением методик, в первую очередь,    необходимость    прерывания    их    исполнения,    разумеется, с возвратом в точку прерываний, когда для этого появляются условия, привели к решению автоматизировать исполнение методик, разработав для этой цели интерпретатор псевдокодовых программ.Более   того,   для   унификации   библиотек   инструментария  WIQA и единообразного хранения единиц повторного использования, к числу которых относятся и методики (технологические задачи) было решено представлять методики в вопросно-ответной форме («инструкция» –«вопрос», «факт исполнения инструкции» – «ответ»).Представленная       интерпретация            методик          и          их        «интерпретатор»,а  также  «система  прерываний»  встроены  в  версию  инструментария

WIQA.Net, что позволяет считать методики процедурными вопросно-ответными программами, использующими псевдокодовое выражение.Отметим, что псевдопрограммы, кодирующие методики, исполняются проектировщиком,     то      есть      интеллектуальным     процессором, а  компьютер,  вернее  интерпретатор,  обслуживает  управление исполнением методик, причём в условиях псевдопараллельного исполнения с учётом возможных прерываний.ДокументированиеВ рамках приложения инструментария WIQA к концептуальному проектированию была решена задача оперативного встроенного проектного документирования.В системе документирования DocWIQA принципиальную роль выполняют шаблоны документов, с каждым из которых, при его загрузке в дерево задач, связывается определённая задача документирования. Экземпляр шаблона настраивается на место загрузки, в результате чего его вопросно-ответным единицам присваиваются уникальные индексные имена.Шаблоны    документов    в    библиотеке    шаблонов    представлены в вопросно-ответной форме, одной из которых является следующее описание:Описание программы (файл ProgDesc.tem)Q1. Какова общая информация о документе? Q1.1. Каково название изделия?Q1.2. Каков шифр документа?Q1.3. Каков год составления документа? Q2. Какова аннотация документа?Q3. Каковы общие сведения о программе?Q4. Каково функциональное назначение программы? Q5. Какова логическая структура программы?

Q5.1. Каковы параграфы раздела?Q5.2. Какова информация о подразделах?Q6. Каковы используемые технические средства?Q7. Какова информация об установке и загрузке программы? Q7.1. Каковы параграфы раздела?Q7.2. Какова информация о подразделах? Q8. Каковы входные данные программы? Q9. Каковы выходные данные программы?Q10. Какова информация о принятых сокращениях в документе? Q11. Каков перечень ссылочных документов?Подшаблон добавления подраздела (файл ProgDesc.st1)Q1. Каково название подраздела? Q2. Каковы параграфы подраздела?Q3. Какова информация о подразделах?Подшаблон добавления сокращения (файл ProgDesc.st2)Q1. Какова аббревиатура? Q2. Какова расшифровка?По месту загрузки шаблоны, в том числе и шаблон описания программы,  если  он  будет  вызван,  наполняются  предметной информацией. Процесс заполнения экземпляра шаблона информацией интерпретируется как (повторное) решение соответствующей задачи документирования.Решение     задач     документирования     носит     не     процедурный, а декларативный характер. По ходу решения формируется объект, который,     в     общем     случае,     содержит     текстовую,     табличную и графическую информацию. Формируется символьно-графический конструкт, который в последующем будет «исполняться» (читаться, интерпретироваться) повторно.Приведённые    действия     с     конструктом,    подобны     созданию и    исполнению   декларативных   программ.   Из-за    аналогии   задачи

документирования    можно отнести           к          вопросно-ответным псевдопрограммам декларативного типа.ОбучениеНа  инструментальной  основе  комплекса  WIQA  создан  ряд приложений EduWIQA, предназначенных для автоматизированного обучения. К числу таких приложений относится обучающий курс по диагностике неисправностей аппаратного изделия и замене неисправных блоков.В  обучающем курсе  включаются в  дерево  задач  следующие типы задач с их вопросно-ответными моделями: задачи освоения определённых разделов изучаемого материала (повторное исполнение декларативных программ, подобное исполнению декларативных программ документов);  задачи, за которыми стоят лабораторные работы, нацеленные на приобретение умений и навыков диагностирования и ремонта изделия (повторное исполнение вопросно-ответных декларативных программ);  задачи проверки освоенных теоретических и практических знаний с использованием методик тестирования.В  задачах  тестирования  каждый  тест  представляется  как декларативная      вопросно-ответная      программа      (QA-программа), в интерпретации которой используются вычисления.ТехнологияСоздано вопросно-ответное приложение TechWIQA, в котором потенциал инструментария WIQA используется для автоматизации технологической подготовки производства [35]. В приложении используются    шаблоны    и    методики,    для    кодирования    которых

используются как декларативные QA-программы, так и процедурныеQA-программы для следующего перечня шаблонов и частично методик:1. Вопросно-ответные шаблоны1.1. Шаблон справочников1.2. Шаблон структуры изделия1.3. Шаблон структуры задач1.4. Шаблон структуры технологического процесса1.5. Шаблон маршрутной карты1.6. Шаблон технологической инструкции «Термическая обработка полимеров»2.Система методик работы с вопросно-ответной средой конструирования и управления технологическими процессами2.1. Методика подготовки работ с технологическими процессами2.1.1. Методика начальной настройки вопросно-ответной среды2.1.2. Методика моделирования организационной структуры коллектива.2.1.3. Методика регистрации проекта2.1.4. Методика заполнения справочников2.2. Методика организации технологической подготовки производства /группа из восьми подчинённых методик.