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

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

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


4.2.система операцийимя прецедента pi

:

так как [логическая формула (ЛФ) для мотивов M ={Mk}

в          поскольку  [ ЛФ для целей C = {Cl} ]ы      если [ЛФ для предусловия U'= {U’n} ],б   то реакция rq(t)],о            из-за чего [ЛФ для постусловия U" = {U”m}р      ------------------------------------ life cycle

PT        PL PG       PS tPI       PE

Рис. 4.2. Жизненный цикл построения образца прецедента

В набор практически полезных моделей прецедента,  порождаемых в процессе его разработки, включены:  текстовая модель PT, представляющая постановку задачи Z(Pi),в результате решения которой создан образец прецедента (как определённый результат интеллектуального освоения реального прецедента);   логическая     модель            PL,      конкретизирующая   типовуюлогическую модель (представлена на рис. 4.2) в виде формулы логики предикатов, записанной на языке постановки задачи PT; графическая модель прецедента PG,  представляющая его обобщённо с использованием «block and line» средств (например, диаграммы активности на языке UML);  вопросно-ответная модель PQA, соответствующая задаче Z(Pi);  модель PI, представляющая вложенное в прецедент поведениеисходным кодом его программы;  модель   PЕ,   выводящая   на   исполняемый   код   программы,кодирующей образец прецедента;  схематическая            модель            прецедента     PS        в          виде    его       схемы,интегрирующей все модели прецедента в единое целое.Результат  разработки  интегрируется  в  единое  целое  (рис.  4.3), с которым и связывается материальная форма образца прецедента, размещаемая в базе прецедентов комплекса WIQA.Net.образец прецедента Pi

ИмяКлючиРейтинг PTPQAPLPG          PIPE

Рис. 4.3. Интегральная схема образца прецедента

Представленная материализация образца прецедента подтвердила свою достаточную полноту и полезность, что послужило причиной решения о её включении в комплекс OwnWIQA, но с учётом адаптации. Адаптация заключается в том, что для модели PI предоставлена возможность её кодирования на псевдокоде, представленном ниже. Кроме того для построения модели пользователю предоставляются две возможности  –  псевдокодовое  формирование  интерфейсной  сборки и средства сборки на основе графического редактора с индексированием имён     блоков,     позволяющим    переходить     к     псевдопрограммам и исполняемым кодам других типов.4.2. Вопросно-ответное псевдопрограммирование4.2.1. QA-подход к псевдопрограммированиюПользователь OwnWIQA должен иметь возможность для программирования своего поведения, вкладываемого в образец прецедента. Для такой работы ему предоставляются средства псевдопрограммирования, в которых строки Р-программы он должен регистрировать в той же форме и с помощью тех же средств, которые он использует для ввода в процессы решения задач QA-рассуждения.Одним  из  плюсов  такой  версии  записи  строк  исходного  кода P-программ является то, что в работе со строками и их группами пользователь может применять все операции и преобразования, которые имеются в WIQA и наследуются OwnWIQA для Z-, Q- и A-объектов.По   сути  дела  в   выбранной  версии  записи  строк  псевдокодовZ-, Q- и A-объекты используются как «материал» для записи, но такой«материал», который обладает полезными свойствами для записанных на нём псевдокодов.

В следующем пункте запись строк псевдокодов и полезные свойства будут представлены детальнее для двух основных типов строк, за одним из которых стоят объявления данных, а за другим – операторы действий. Отметим, что запись любой строки Р-программы  производится в поле описания   того   объекта,   на   котором   (как   на   определённого  рода«материале») записывается строка.Для того чтобы строка или группа строк приобрела смысл определённого «данного» или «действия» необходимо осуществить эмуляцию «данного» или «действия», то есть представить его средствами той системы кодирования и хранения, которая используется для материализации строки, кодирующей «данное» или «действие». Для осуществления эмуляции пользователю должны быть предоставлены подходящие средства.Отметим, что новые средства псевдопрограммирования, включённые в комплекс OwnWIQA, дополнительны к средствам псевдопрограммирования, использовавшимся в ранее разработанных приложениях комплекса WIQA, а также то, что они развивают идеи QA-программирования. По этой причине за псевдопрограммами, разрабатываемыми в  среде OwnWIQA, независимо от их типа, сохранено  использовать  общего  названия  «QA-программы».  Ниже будут приведены дополнительные основания правомерности такого названия.4.2.2. Эмуляция QA-данныхВ предыдущей главе в параграфе 3.2 была представлена QA-модель данных в следующих её интерпретациях:  модель  задачи  в  процессе  проектирования  сложных  систем с позиций тех QA-рассуждений, которые использовались или используются при поиске и построения её решения;

  иерархическая   модель   данных,   структура   которой   подобна A-протоколу, узлам которого и их символьному описанию можно приписать интерпретацию, необходимую пользователю; совокупность объектов, каждый из  которых построен для соответствующего    ему    узла    дерева    задач    или    QA-протокола с помощью средств дополнительной атрибутики.Две  последние  интерпретации  в  этой  же  главе  были  связаны с понятием QA-данных, под которыми понимаются визуализируемые поля описаний Z-, Q- и A-объектов, информационное представление каждого из которых как целое хранится в QA-базе данных. Средства дополнительной атрибутики (за счёт объектно-реляционных преобразований)    позволяют    упаковывать    QA-данные,    расширяя их информационное представление, в программные объекты, открывая тем  самым  доступ  к   QA-данным,  подобный  доступу  к   объектам в объектно-ориентированных программах.Потенциала QA-данных вполне достаточно, чтобы настроить его на эмуляцию основных типов данных, используемых в системах программирования, существующих в настоящее время. Представим возможности эмуляции основных типов, введя дополнительно следующие версии интерпретации: «вопрос»  «имя переменной для простого типа данных, используемого           в            традиционном           программировании» и  «ответ»  «значение этой переменной»;  «определённая  композиция  вопросов»    «данные  составного типа (например, данные типа массив, запись, множество, массив записей или таблица, стек, очередь или другой составной тип данных)» и «соответствующая композиция ответов»  «текущее значение данных этого типа».

Представленные    версии    интерпретации    демонстрируют,    что QA-модель данных может быть использована для эмуляции данных различных     известных     типов,     используемых     в     традиционномпрограммировании рис. 4.4.

СкалярМассив Имя QA-данного  → «Вопрос»Значение QA-данного  → «Ответ»

ЗаписьСтрокаСписок DD1    V1D11D12D1mD2               V2D21 V11V12V1mV21

.............. D22                V22

ТаблицаДерево D2nDp                       VpDp1Dp2Dpr V2nVp1Vp2Vpr

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

оператор,        который         обрабатывается         в          составе           исходного      кода транслятором (компилятором или интерпретатором).В обработке таких строк исходного кода накоплен богатейший опыт и  все  необходимые действия, которые должен совершить транслятор с операторами объявления данных, известны [37].Ориентируясь    на    опыт    традиционного    объявлений    данных и  обработки операторов таких  объявления, представим возможности, к которым приводит эмуляция QA-данных, использующая средства дополнительной  атрибутики.  Версия  использования  дополнительнойатрибутики в объявлении одномерного массива приведена на рис. 4.5.

QA-данноеD1. Массив &Абсд & D1.1. Абсд[1]V1.1. 12D1.2. Абсд [2] V1.2. 12D1.3. Абсд [3] V1.3. 12D1.4. Абсд [4] V1.4. 12D1.5. Абсд [5] V1.1. 12 Дополнительные атрибуты

Атрибут

Значение

Тип_данных

Массив

Размерность

1

Тип_элемента

integer

Количество_элементов

5

Другие дополнительные атрибуты

Рис. 4.5. Эмуляция массива данныхВ версии объявления использованы четыре атрибута «Тип данных»со  значением «Массив» и  три подчинённых атрибута «Размерность»,«Тип_элемента»            и            «Количество_элементов»    с          приписанными          им значениями.Как уже отмечалось выше, приписывание дополнительных атрибутов (напомним их символьное обозначение АА) конкретному QA-данному приводит к образованию программных объектов с помощью выполнения

объектно-реляционных преобразований, запрограммированных заранее. Спецификой таких преобразований, отличающей их от других преобразований такого типа, является «создание новых программных объектов для объектов, вложенных в базу данных, при оперативном приписывании им дополнительных атрибутов». Оперативность приписывания заключается в том, что на экране монитора для выбранного наблюдаемого объекта, хранящегося в базе данных, назначаются необходимые дополнительные атрибуты.В таких преобразованиях две ступени, первая из которых обеспечивает встроенное в OwnWIQA её разработчиками объектно- реляционное преобразование, которое создаёт объекты с набором полей, для  каждого  ААi.  В  набор  включены поля,  в  которые записано имя QA-данного и зарегистрировано его значение, а также поля для всех единиц данных введённого атрибута ААi  (тип AAi, значение типа, подчиненные ААij и их определители).На           этой    ступени          в          разделе           методов            используются            толькоконструкторы, а также операции записи и чтения, связывающие  объект с базой данных.На второй ступени в объектные представления вводится специализация, соответствующая типу атрибута, а точнее сказать его предназначению  в  тех  программных  единицах,  где  атрибут используется.У    специализации    два    варианта,    один    из    которых    связан с предназначением, которое запрограммировано разработчиками OwnWIQA и используется в запрограммированном объёме пользователем. Всё связанное с эмуляцией типовых данных относится к этому варианту.

Второй      вариант      открывает      возможность      для      создания (с использованием дополнительных атрибутов) объектов самим пользователем.   Второй    вариант    открыт    для    его    использования в псевдопрограммировании, в котором пользователь, по сути дела, использует объектно-ориентированные средства. Схема интеграции базовых атрибутов и атрибута, обслуживающего объявление переменнойприведено на рис. 4.6.Атрибуты QA-данных

Система базовыхQA-атрибутов Атрибуты пользователя

 

 

 

 

 

Индекс (Адрес)                                                              Имя

Определение

«Владелец»                                               .....................

Время изменения                                              Значение

.....................

Тип «Иконы»

 

 

 
Дополнительные атрибутыТип переменной,Атрибуты типаРис. 4.6. Интеграция базовых атрибутов с атрибутами пользователяПлагин «Дополнительная атрибутика» предоставляет пользователю возможность связать с определённым QA-данным, столько атрибутов, сколько пользователю оказалось необходимо. Такие атрибуты могут вводиться независимо друг от друга или с подчинением, о котором уже говорилось выше.Введение в эмуляцию данных необходимой (для решения задачи) совокупности дополнительных атрибутов  обогащает информационную составляющую разрабатываемой программы. Из принципа дополнительности «данные + операции» известно, что обогащение информационной составляющей, способствует упрощению процедурной составляющей, то есть способствует упрощению кода программы.

В эмуляции данных любой дополнительный атрибут ААi связывается с выбранным объектом Z-, Q- или A-типа, информационное представление которого размещено в QA-базе данных. Связывание устанавливается не только с наблюдаемым на экране монитора «полем описания объекта», а с ним как с целым, а значит и с любым его свойством (атрибутом в QA-базе данных). Следовательно, при программировании конкретного объектно-реляционного преобразования в   создаваемый  программный  агент   можно   вынести   все   атрибуты Z-, Q- или A-объекта.Открыта   и   возможность  связывания   дополнительного  атрибута с  частью  строки,  хранящейся в  «поле  описания объекта». Для  этого часть  строки  можно  выделить  тегами  и  запрограммировать необходимый метод.Рассмотрим ещё один пример эмуляции данных для переменной скалярного  типа  (рис.  4.7),  представляющей  физическую  величину (пусть массу). В этом примере продемонстрируем эффекты, которые могут быть достигнуты с помощью дополнительных атрибутов.Дополнительные атрибуты

Раздел QA-объявлений................................... D1.k. &Колонна & V1.k.12 / Комментарий2...................................

Атрибут

Значение

Тип_данных

Скаляр

Тип_элемента

integer

Другие дополнительные атрибуты

 

Атрибут

Значение

Сила

Упругость

Единица_измерения

Ньютон

Интервал_значений

10000:14000

Материал

Сталь

Коэфф_упругости

Константа

 

 

Рис. 4.7. Объявление QA-переменной

Пример носит демонстрационный характер, но привязан к семантике, пусть   «изменения   размера»   стальной   колонны   из-за   своего   веса. На рисунке приведена только часть необходимых данных, но их достаточно  для  того,  чтобы  утверждать  о  введении  в  объявление QA-переменной её семантики.Так как для семантических атрибутов будут  созданы программные объекты, которые доступны для программирования, то приведённая схема объявления переменных открывает возможность запланированной или    оперативной    работы    с    семантикой.    Например,    контроль за  соблюдением  «природных»  закономерностей  задачи  или  других её закономерностей можно возложить на запланировано созданных программных агентов.Следует   отметить,   что    автоматическое   именование   вопросов и ответов, порождающее их уникальные имена, вводит их естественную адресацию, позволяющую обращаться к данным задачи, эмулированным средствами QA-данным, и их составным частям по системным именам.Рассмотрим ещё одну интерпретации совокупности пар данных,  для которой вопросно-ответная интерпретация может рассматриваться как частный случай. Первую составляющую каждой пары можно рассматривать   как    «условие»,   а    вторую   составляющую   –    как«следствие». Напомним, что в такой версии интерпретации каждая  паразаписей модели, представленной на рис. 1.1, кодирует импликацию:Если «условиеi», то «следствиеk»причём,   с   богатой   атрибутикой,   как   для   «условия»,   так   и   для«следствия».В искусственном интеллекте импликация, связывающая «условие»и  «следствие»,  получила  название  «продукция»  и  используется  для

моделирования  знаний.  Продукционная модель  знаний  считается базовой    формой    для    представления    правил    (закономерностей) в экспертных системах. В продукционную модель в явном виде встроена логика, что позволяет моделировать рассуждения (а значит и выводы на базе продукционных закономерностей), решая задачи в рамках экспертных систем.Отметим, что роль «следствий» в продукциях, составляющих базу знаний, выполняют либо декларативные конструкты (например, такие как «советы» или «рекомендации»), либо императивные конструкты (например, такие как «команды» или «реагирование» в разных формах).4.2.3. Эмуляция операторовДля того чтобы довести QA-средства процессора до потенциала, обеспечивающего программирование приложений, средства эмуляции данных  следует  дополнить  средствами  эмуляции  программных действий. В набор моделируемых программных действий включим следующие основные операторы:Присвоить: «вопрос»  «имя переменной» и «ответ»  «присвоить значение»;Goto: «вопрос»  «условие» и «ответ»  «перейти к определённому оператору QA-программы;If:  «вопрос»    «условие»  Then  «ответ»    «выполнить определённый оператор»;Команда:  «вопрос»    «команда  QA-процессора»  и  «ответ»  «выполнить команду»;Функция:  «вопрос»     «определение  функции»  и   «ответ»  «вычислить значение функции»;

Процедура: «вопрос»    «определение процедуры» и  «ответ»  «выполнить процедуру».End: «вопрос»  «end программы» и «ответ»  «завершить работу с QA-программой».Для введённых операторов будем ориентироваться на следующие толкования функции и процедуры:   любая      функция      определяется      в      виде      выражении на       псевдоалгоритмическом      языке,      подобном      выражениям на алгоритмическом языке; любая процедура представляет собой типовую совокупность действий, каждое из которых доступно в среде QA-процессора для его выполнения по решению пользователя.Набор операторов выбран так, чтобы он обеспечивал построение программы действий в среде QA-процессора WIQA, а интерпретация операторов   приведена   для   того,   чтобы   продемонстрировать,   как из выбранных операторов строится код QA-программы.С представленного набора операторов   начиналось использование псевдопрограммирования в среде WIQA, с помощью которого была решена  задача  управления ресурсными испытанием узлов  самолётов. В  комплекс  WIQA  был  включён  набор  средств,  обеспечивающий первую версию псевдопрограммирования, который затем был усовершенствован для его применения в задаче предикатно- онтологического контроля проектных решений [34]. Эта версия входит в базовый набор компонентов комплекса WIQA, который унаследован комплексом OwnWIQA.Представим некоторые детали псевдопрограммирования задач управления ресурсными испытаниями. Постановки задач, их лексика,

абревиатурные сокращения и методики испытаний были представлены специалистом по ресурсным испытаниям.Следует заметить, что ресурсные испытания это один из видов производственной деятельности, в которой используется оборудование, получившее название испытательные стенды. Автоматизация ресурсных испытаний, в том числе и с помощью компьютеризации процессов, способствует повышению их эффективности. Автоматизируются действия операторов испытательных стендов, которые до автоматизации они выполняли вручную. В этих действиях выделяют подготовку к испытаниям и их осуществление.Что стоит за подготовкой испытаний, для автоматизации которых разрабатывались псевдопрограммы, частично раскрывает словарь, фрагмент которого приведён в таблице 4.1. Этот словарь представляет раздел специализированных операторов псевдоязыка ресурсных испытаний,    каждый    из    которых    понятен    оператору    и    освоен им профессионально. Словарь также вводит технологические переменные,    которые    в    псевдопрограммах   выполняют    функциипрограммных переменных.Таблица 4.1

Оператор

Содержание действия

Результат

1

УСТ МИН ВЫХ ВИНТ

Задать минимальный выход винта  согласно ТУ изделия

L=Lmin

2

УСТ МАКС ВЫХ ВИНТ

Задать максимальный выход винта согласно ТУ изделия

L=Lmax

3

УСТ РАБ ДАВ НАГ

Задать рабочее давление в магистрали нагнетаниястенда

Pgc=Pnom

4

УСТ МАКС ОСЕВ УС

Задать максимальное осевоеусилие данного режима согласно ТУ

P=Pmax

...

..........................

...........................................

 

Ещё один раздел псевдопрограмм составляют те, в которых запрограммированы режимы ресурсных испытаний. Для псевдопрограммирования   режимов    предварительно   использоваласьследующая форма (для упрощения записи введён оператор цикла):Процедура режим 1Б;НАЧАЛОL = Lmin;P gc = Рnom; Nc4 = 0;Пока Nc4 < 5000 циклТ = 2;t = 0;пока   t < T/2 циклР = 2 * Р max(+) * t / T;t = t + 0.1;конец цикла;пока t < T циклР = Рmax(+)  - 2 * Pmax(+) / T * t;t = t + 0.1;конец цикла;Nc4 = Nc4 + 1Конец цикла;Конец процедуры;После      этого      каждая      псевдопрограмма      была      записана в    соответствующую   ей   вопросно-ответную   форму   и   загружена в библиотеку псевдпрограмм ресурсных испытаний. В процессе конкретного испытания необходимая псевдопрограмма загружается из библиотеки и выполняется в режиме интерпретации. Исполняемый код формируется по исходному коду QA-псевдопрограммы с помощью интерпретатора,  выводящего на механизмы динамической компиляции, которые будут представлены ниже.В псевдопрограммировании принято расширять базовый набор операторов,    который    минимально    необходим    для     построения

и использования псевдопрограмм. В частности, набор расширяют, включая в него операторы циклов типа «for», « while-do» и «do-until» . Такое расширение проведено для второй версии псевдопрограммирования для всех названных типов циклов. В этой версии также используются средства дополнительной атрибутики.Дополнительные атрибуты (как и для QA-данных) позволяют обогатить информационное содержание строк QA-псевдопрограмм, которые для транслятора таких программ являются входными данными. Учитывая эту общность, оператора QA-псевдопрограммы  правомерноназывать QA-операторами.Любой QA-оператор представляет собой запись его псевдокода     в     «полях     описаний»     пары     согласованных Q- и A-объектов, с которыми связвана системная дополнительная атрибутика, облегчающая транляцию оператора, а, возможно, и дополнительная атрибутика пользователя, помогающая ему в решении программируемой задачи.Из теории и практики трансляторов компьютерных программ известно, что одной из задач, которую приходится решать в процессе трансляции, является задача определения типа оператора и его границ. В решении такой задачи используют ключевые слова и синтаксис оператора. Легко согласиться, что если тип оператора вводится дополнительным атрибутом, то задача практически снимается.Напомним, что за каждым дополнительным атрибутом стоит объектно-реляционное преобразование, приводящее к построению программного  агента.  Трансляция  операторов  псевдопрограмм относится к системным задачам комплекса OwnWIQA, для которых построение полезных программных объектов проводится автоматически (разумеется, для приписанных дополнительных атрибутов).

Для QA-операторов (как и для QA-данных) открыта возможность пользовательского приписывания им дополнительных атрибутов, полезных для решения программируемой задачи. Это, в частности, позволяет обрабатывать комментарии к операторам (через дополнительный атрибут, выделяющий подстроку комментариев, выделенную тегами), а также программировать действия со строками QA-операторов исполняемой программы.Вернёмся   к   вопросу   о   правомерности   применения   названия QA-программа  для  псевдопрограмм,  исходный  код  которых формируется из QA-данных и QA-операторов.В   лингвистике   в   любом   предложении   выделяют   «тему»   (как то в предложении или тексте, о чём идет речь) и «рему» (как нечто неизвестное, из-за чего было создано предложение). А значит, в любом предложении явно или неявно присутствует вопрос. Операторы, как объявления данных, так и действий являются предложениями. Поэтому их запись в «поле описаний» вопросов соответствует назначению этих полей. Ответом на вопрос-оператор для объявленного в нём данного является значение данного,   которое является ответом на этот вопрос и совершенно правомерно регистрируется в поле «описания» ответа. Для вопроса-оператора представляющего действие ответом является результат выполнения действия, в частности, сам факт его исполнения.На  множестве  вопросов  выделяют  различные  типы.  Например, в  комплексе  WIQA  различаются  вопросы  типов  «проект»,  «задача» и  «запрос».  Для  указания  на  типы,  как  вопросов,  так  и  ответов в комплексах WIQA и OwnWIQA используется системное имя, состоящее из определённой буквы, визуализируемой на экране монитора соответствующей иконкой, и индекса, приписываемого автоматически.

С операторами объявления данных и действий в комплексе OwnWIQA связаны дополнительные типы вопросов, для которых введены иконки для букв D и O для данных и операций соответственно. Для ответов на D-вопросы введён тип V (Value, значение), для ответов на O-вопросы введён тип E (Executed, выполнено).Заметим, что пользователям  комплекса OwnWIQA  предоставлена возможность   вводить   собственные   типы   и   подтипы   QA-данных и QA-операторов и создавать для них собственные иконки.