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

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

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

3.2. вопросно-ответная модель данных

3.2.1. Специфика QA-данныхВ разработках приложений, созданных с помощью инструментария WIQA,   в   первую   очередь   в   приложениях   DocWIQA,   EduWIQA и TechWIQA, используется и регулярно подтверждает свою полезность QA-модель данных, визуальное представление которой (на экране монитора) приведено на рис. 3.10.

QA-протокол

Дерево задач Plug-ins

ДругиеQA-протоколы Графика

Текст(возможно редактирование)   ПерсонификацияРис. 3.10. Визуализация вопросно-ответных данныхВ  первоначальной  интерпретации  её  содержимого  QA-модель данных,  используемая  в  QA-моделировании  задач,  (была) предназначена для формирования и регистрации:  дерева задач проекта, каждая «задача» которого реализована как интерактивный   объект,   с   декларативной   частью,   размещенной в вопросно-ответной базе данных, и операциями (над объектом и их совокупностями),    осуществляемыми    с    использованием    запросов к содержимому базы; QA-модели для каждой задачи, состоящей из иерархически связанной совокупности интерактивных объектов «вопрос» и «ответ», которые хранятся в той же базе данных и используются подобно объектам типа «задача».

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

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

  образование  иерархической  совокупности  групп  QA-единиц,в   том      числе  и          таких, которым            может быть    приписан       статус«целостности»; серверная форма размещения базы данных с клиентским доступом в корпоративной сети, с возможностью санкционирования доступа из Интернета;  другие полезные возможности.Ко всем названным возможностям можно (и целесообразно) относиться с позиций программирования. Одним из направлений программирования с использованием QA-данных   является развитие инструментария WIQA.Net за счёт разработки новых плагинов (расширений).Ещё одним направлением программирования с QA-данными как для расширения WIQA.Net, так и для создания приложений на базе этого инструментария является создание программных агентов и их коалиций.3.2.2. Логическая модель  QA-данныхДля материализации QA-данных в инструментарии WIQA.Net используется        реляционная        база        данных,        ориентированная в спецификациях на создание и использование связной совокупности иерархический деревьев «задач», «вопросов» и «ответов», в частности согласованных деревьев  «вопросов»  и  «ответов,  пример  которых приведён на рис. 3.11.Если в интерпретации узлов иерархических деревьев абстрагироваться от   того,   что   они   представляют  собой   задачи,   вопросы   и   ответы, то абстрактная структура данных окажется подобной иерархической модели данных [14], нашедшей (особенно в недалёком прошлом) много различных применений.

Bt

  индексное имя (устанавливается автоматически при создании); тип единицы (первый выделенный в визуализации индексного имени символ, который устанавливается создателем единицы);  идентификатор основной задачи (проекта, к которому относитсяQA-единица);  идентификатор родительской QA-единицы;  содержательное           представление           (текстовая      строка,раскрывающая информационное содержание единицы);  «владелец» (имя субъекта, который создал единицу и/или несёт за неё ответственность); время последней модификации поля содержания (предыдущие состояния могут сохраняться);  состояние завершённости (с набором типовых значений); черновик    (текстовая    строка,    регистрирующая   полезную информацию о единице, в частности ретроспективу её создания, которая регистрируется ответственным за единицу).Разработка приложений в среде WIQA использовалась (и будет использоваться в дальнейшем) для расширения её инструментального потенциала, в том числе и потенциала вложенного в QA-модель данных. Для расширения открыты набор отношений, атрибутика, библиотека функций доступа, а также погружение QA-модели в различные СУБД.Все        отмеченные        возможности       расширений        проверены и в определённом объёме материализованы. Так, например, каждое созданное в среде WIQA приложение приводило к необходимости введения новых плагинов, дополняющих базовый набор отношений, представляющих «задачи», «вопросы» и «ответы».Дополнительные отношения образуют около базового набора два слоя(рис.  3.12),  первый из  которых состоит из  отношений с  атрибутикой,

включающей    атрибуты     из        базового         набора            (отношения    прямой связности).   С            остальными   отношениями           базовый          набор  связанопосредованно.Остальные отношения базы данныхОтношения прямой связностиБазовый наборРис. 3.12.  Связность отношений базы данных среды WIQAВведение дополнительных отношений приводит к тому, что набор свойств интерактивных объектов «задача», «вопрос» и «ответ» расширяется, а значит, расширяется и набор тех свойств, которые можно приписать QA-данным.Представим    ряд    таких    дополнительных    отношений    (таблиц). К их числу относится таблица прилагаемых файлов QARegFiles (qaId: Идентификатор QA-единицы, к которой прилагается файл, fileName: Название файла, description: Описание файла). Ещё одним примером табличного расширения является таблица иконок IconTable (name: Название иконки, folder: Название директории, в которой она находится, iconBytes: содержимое иконки, sizeX: Размер иконки по X, sizeY: Размер иконки по Y), вводящая в индексное имя (адрес) QA-единицы графический символ (визуальная маркировка типа единицы).

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

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

Раскроем детали дополнительной атрибутики (Additional Attributes, обозначим АА), представив их на уровне специализированного языка LAA описания дополнительных атрибутов {AAi}.В  общем  случае  для  дополнительного  атрибута  AAi    определены и программно доступны:  собственное     имя      N(AAi)            и          значение         V(AAi),           которые регистрируется в строках символов;   тип Tj(AAi), который также имеет имя N(Tj) и значение V(Tj),заданные строками символов;  набор   подчинённых   атрибутов   {AAik},   каждый   из   которых определяется по общим правилам;  набор операций (методов) над атрибутом AAi, доступный через обращение к нему как к упакованному классу.Другими словами, каждый атрибут определяется как программно материализованный и доступный объект, открывающий возможность использовать его в объектах, построенных с помощью объектно- реляционных преобразований отношений, вложенных в QA-базу данных. Напомним, что QA-база размещена на сервере, а объект может быть построен как для его употребления как на сервере, так и клиентом. Поэтому методы могут быть серверными и клиентскими.МеханизмыЯзык LAA  является описательным языком, раскрывающим структуру объектов, построенных с помощью объектно-реляционных преобразований. Как уже было отмечено, для построения таких объектов в    состав    инструментария    WIQA    включён    специальный    плагин«Дополнительная атрибутика», обеспечивающий формирование дополнительных  атрибутов  и  их  комплексов,  а  также  их  связывание с отношениями и полями в QA-базе данных.

Плагин настроен только на те отношения, строки которых визуализируются в операционных обстановках системы WIQA. К таким отношениям    относятся    отношение    QAReg,    открывающее    доступ к  Z-,  Q-  и  A-объектам  дерева  задач  и  QA-протоколов  этих  задач, и отношение, регистрирующее QA-шаблоны разных типов (методик, документов, типовых QA-программ).Плагин  разработан  таким  образом,  что  его  функции  инвариантны к специфике методов тех объектов, которые создаются с его помощью. Создание и включение методов в создаваемый объект лежат за рамками ответственности плагина «Дополнительная атрибутика».По сути дела плагин «Дополнительная атрибутика» предоставляет создателям объектов, использующих его средства, упакованные в объекты (на языке C#) атрибуты реляционных отношений, дополненные специализированными дополнительными атрибутами. Плагин также обеспечивает   связывание   «упакованных   атрибутов»   в   комплексы, а также предоставляет интерактивный доступ к таким конструктам.Плагин «Дополнительная атрибутика» разработан как открытое программное образование, в котором набор базовых методов, обеспечивающих создание дополнительных атрибутов, расширяется (расширяется набор серверных и клиентских методов базовых классов плагина).Как отмечалось выше, функциональность плагина определяет набор отношений R(АА), дополнительно включённых в QA-базу, в частности, для эмуляции очередных отношений (виртуальных отношений), полезных для развития функционального потенциала инструментария WIQA или приложения, созданного с помощью инструментария WIQA. Объектно- реляционное  развитие  информационного  потенциала  QA-базы схематично представлено на рис. 3.13.

Базовые QA-атрибуты

ОтношениеQAregмеханизмыQA-доступа Набор классов АА ОтношенияR(АА) Виртуальное отношение Rkсервер клиент

механизмы доступа ААпользователь и/или новая функциональностьРис. 3.13. Объектно-реляционное развитие базы данныхНабор   отношений  R(АА)   выбран   и   материализован  из   расчёта на объявление оказавшегося необходимы дополнительного атрибута ААi, возможно  включающего  подчинённые  атрибуты  ААij,  с  учётом  типа и необходимых свойств, причём, принадлежащих не только виртуальному отношению Rk. Созданный атрибут ААi  связывается с определённым узлом дерева задач или вопросно-ответного протокола или узами тех конструктов, которые QA-данные представляют.Если   дополнительные  атрибуты  вводятся,  то   они   применяются в  определённых  случаях,  которые  могут  повторяться,  что  приводит к прецедентной форме реакций на дополнительные атрибуты и их группы (возможно с  использованием базовых  атрибутов). А  значит,  в  работы с дополнительной атрибутикой рационально включить механизмы работы с прецедентами WIQA.Net.Прецедентная     форма     открыта     для     её     автоматизированного и автоматического использования, в том числе в QA-программировании и разработке очередных плагинов.

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

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