Название: Вопросно-ответное программирование человеко-компьютерной деятельности( Соснин П.И.) Жанр: Информационные системы и технологии Просмотров: 1903 |
3.2. вопросно-ответная модель данных3.2.1. Специфика QA-данныхВ разработках приложений, созданных с помощью инструментария WIQA, в первую очередь в приложениях DocWIQA, EduWIQA и TechWIQA, используется и регулярно подтверждает свою полезность QA-модель данных, визуальное представление которой (на экране монитора) приведено на рис. 3.10. QA-протокол Дерево задач Plug-ins Другие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], нашедшей (особенно в недалёком прошлом) много различных применений.
![]() ![]() ![]() индексное имя (устанавливается автоматически при создании); тип единицы (первый выделенный в визуализации индексного имени символ, который устанавливается создателем единицы); идентификатор основной задачи (проекта, к которому относитсяQA-единица); идентификатор родительской QA-единицы; содержательное представление (текстовая строка,раскрывающая информационное содержание единицы); «владелец» (имя субъекта, который создал единицу и/или несёт за неё ответственность); время последней модификации поля содержания (предыдущие состояния могут сохраняться); состояние завершённости (с набором типовых значений); черновик (текстовая строка, регистрирующая полезную информацию о единице, в частности ретроспективу её создания, которая регистрируется ответственным за единицу).Разработка приложений в среде WIQA использовалась (и будет использоваться в дальнейшем) для расширения её инструментального потенциала, в том числе и потенциала вложенного в QA-модель данных. Для расширения открыты набор отношений, атрибутика, библиотека функций доступа, а также погружение QA-модели в различные СУБД.Все отмеченные возможности расширений проверены и в определённом объёме материализованы. Так, например, каждое созданное в среде WIQA приложение приводило к необходимости введения новых плагинов, дополняющих базовый набор отношений, представляющих «задачи», «вопросы» и «ответы».Дополнительные отношения образуют около базового набора два слоя(рис. 3.12), первый из которых состоит из отношений с атрибутикой, включающей атрибуты из базового набора (отношения прямой
связности). С остальными отношениями базовый набор
связанопосредованно.Остальные отношения базы данныхОтношения прямой
связностиБазовый набор 3.2.3. Дополнительная атрибутикаРасширение потенциала QA-данныхВ число полезных расширений потенциала QA-данных входит механизм дополнительной атрибутики, предназначенный для расширения атрибутики, вызванного любыми причинами (например, разработка новых плагинов или создание пользовательских QA-программ), причём, такого расширения, в котором не требуется вводить в QA-базу данных новые отношения или изменять уже существующие.Такое расширение обеспечивает служебный плагин, получивший название «Дополнительная атрибутика». Разумеется, этот плагин, вводит в базу данных собственные дополнительные отношения, которые открывают возможность для творческого приписывания свойств любой единице дерева задач или любой единице QA-протокола, но они используются для эмуляции очередных полезных отношений.Полезность такого механизма будет продемонстрирована ниже на конкретных примерах. Сначала объясним специфику дополнительной атрибутики и средства её реализации.В практике программирования приложений, использующих реляционные базы данных с объектной ориентацией (применение ER-диаграмм в проектировании), сложился и широко используется механизм объектно-реляционных преобразований. Этот механизм нацелен на формирование и использование объектов (классов), в каждом из которых интегрируются: данные (как поля объекта) из определённых отношений базы данных; возможно дополнительные другие данные (поля объекта); методы, определяющие существование объекта. Объектно-реляционный подход согласуется с базовой
интерпретацией«задач», «вопросов» и «ответов» как интерактивных
конструктов, к которым пользователь имеет прямой доступа с различными целями.
Определённый объём такого доступа запрограммирован в
плагине«Вопросно-ответный протокол».Как отмечалось в предыдущем параграфе,
разработка новых плагинов приводила и приводит к расширению базы данных системы
WIQA. Именно для облегчения таких расширений в состав системы WIQA и
включены средства дополнительной атрибутики.Важнейшим направлением расширения
системы WIQA является разработка новых приложений на основе её потенциала. По
этой причине в создании средств дополнительной атрибутики учтены два основных
направления её применения – применение, инвариантное к содержанию приложений
(инвариантные атрибуты), и применение, учитывающее содержательную
специфику приложений (специализированные Раскроем детали дополнительной атрибутики (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.
ОтношениеQAregмеханизмыQA-доступа Набор классов АА ОтношенияR(АА) Виртуальное отношение Rkсервер клиент механизмы доступа ААпользователь и/или новая функциональностьРис. 3.13. Объектно-реляционное развитие базы данныхНабор отношений R(АА) выбран и материализован из расчёта на объявление оказавшегося необходимы дополнительного атрибута ААi, возможно включающего подчинённые атрибуты ААij, с учётом типа и необходимых свойств, причём, принадлежащих не только виртуальному отношению Rk. Созданный атрибут ААi связывается с определённым узлом дерева задач или вопросно-ответного протокола или узами тех конструктов, которые QA-данные представляют.Если дополнительные атрибуты вводятся, то они применяются в определённых случаях, которые могут повторяться, что приводит к прецедентной форме реакций на дополнительные атрибуты и их группы (возможно с использованием базовых атрибутов). А значит, в работы с дополнительной атрибутикой рационально включить механизмы работы с прецедентами WIQA.Net.Прецедентная форма открыта для её автоматизированного и автоматического использования, в том числе в QA-программировании и разработке очередных плагинов. Пример использованияВ текущем состоянии развития средств дополнительной атрибутики они включены в работы с документами, в интерфейсное прототипирование концептуальных решений задач, в механизмы меточной защиты информационно-программных ресурсов и в средства вопросно-ответного программирования. Представим одно из применений дополнительных атрибутов на примере работ с проектными документами, используемыми в разработках автоматизированных систем (российские стандарты 34-й серии).С каждым из типов проектных документов связана типовая задача документирования, экземпляр которой создаётся в дереве задач разрабатываемого проекта в результате загрузки в дерево шаблона документа из библиотеки шаблонов. QA-формы хранения шаблона и его экземпляра в дереве задач подобны, различия только в содержании полей, предназначенных для регистрации ответов.Идентичность QA-структуры шаблона и его экземпляра позволяет единожды назначить полезные дополнительные атрибуты для QA-шаблона документа и обеспечить их передачу любому числу экземпляров документов при их загрузке в дерево задач.Один из дополнительных атрибутов, включенный в процесс документирования, предназначен для переноса содержания документа из его QA-представления в форму традиционного представления (назовём её «копией документа»), с возможностью использования версий «копии документа» (например, ориентированных на печать или визуальный просмотр с различными целями).Для обеспечения переноса информации в системе документирования используется ещё один тип шаблонов – «шаблоны отчётов», в структуру каждого из которых (и тоже единожды) встроены в соответствующем месте текста «шаблона отчёта» имена соответствующих дополнительных атрибутов, по сути дела, указывающих, в какое место должен быть перенесён текст из соответствующей единицы QA-документа. Представленный атрибут выполняет функции адресной связки между структурными единицами QA-документа и «шаблона отчёта» для этого документа |
|