Содержание к диссертации
Введение
Глава I. Исследование направлений повышения эффективности информационного обслуживания пользователей в АСГС ..II
1.1.. Анализ особенностей информационного обслуживания пользователей в АСГС ;... І4
1.2. Выбор способа взаимодействия с базой данных АБД АСГС '. 34
Глава 2. Исследование принципов построения адаптивной диалоговой системы 52
2.1. Моделирование диалога в системе информационно-справочного обслуживания АЭД АСГС . 52
2.2. Разработка методов управления многоуровневым диалогом 66
2;3. Разработка входного языка системы и методов реализации его синтаксически управляемого перевода .82
Глава 3. Практическая реализация адаптивной диалоговой системы АБД АСГС 104
3.1. Программная реализация адаптивной диалоговой системы АБД АСГС 105
3.2. Разработка технологии решения задач статистического анализа с использованием диалоговой системы АВД АСГС 117
Заключение... 137
Литература..139
- Выбор способа взаимодействия с базой данных АБД АСГС
- Разработка методов управления многоуровневым диалогом
- Разработка входного языка системы и методов реализации его синтаксически управляемого перевода
- Разработка технологии решения задач статистического анализа с использованием диалоговой системы АВД АСГС
Выбор способа взаимодействия с базой данных АБД АСГС
Эффективность обработки информации с применением ЭВМ существенно зависит от того, насколько полно соответствует система обработки данных специфическим требованиям, предъявляемым к ней ее пользователями. Для определения этих требований разработчику системы обработки данных необходимо иметь характеристику будущих пользователей /обобщенный портрет пользователя/.
Расширение сферы использования ЭВМ в ходе развития технических, информационных и программных средств АСГС неизбежно потребовало узкой специализации работников, вовлекаемых в процесс машинной обработки статистической информации. Это привело к естественному разбиению пользователей АСГС на группы, каждая из которых специализируется в определенной прикладной области и ставит в связи с этим перед ЭВМ свои задачи; Выделим по этим признакам три группы пользователей АСГС: программисты, эксплуатационники и внешние пользователи.
Характерной особенностью первой группы пользователей является то, что ЭВМ выступает для них в качестве объекта непосредственного приложения профессиональной деятельности /создание программного продукта/. В то же время ЭВМ является для них и основным инструментом достижения результата. Это диктует необходимость обязательной специальной подготовки в области вычислительной техники и программирования.
В свою очередь, данная группа пользователей делится на системных и прикладных программистов. Системные программисты специализируются в области создания средств эффективного использования ресурсов ЭВМ. Рассматриваемая категория пользователей возникла прежде всего в связи с потребностями самой вычислительной техники.
Прикладные программисты занимаются разработкой средств решения конкретных задач на ЭВМ. Они являются промежуточными пользователями, своего рода посредниками между конечными потребителями информации и ЭВМ. Отметим, что в системах обработки информации, для которых характерно отсутствие средств непосредственного доступа к данным конечных пользователей, прикладные программисты являются ее основными пользователями.
Внедрение АСУ и машинной обработки информации привело к появлению разнородной по составу и значительной в количественном отношении службы эксплуатации программного обеспечения ЭВМ. К функциям данной группы пользователей относятся: подготовка и комплектация исходных данных для машинной обработки, проведение расчетов на ЭВМ, комплектование результатов и доставка их конечному потребителю информации. Наличие такой группы пользователей оправдано, если решаемая на ЭВМ задача характеризуется громоздким технологическим циклом, требующим специальных знаний и навыков в области эксплуатации ЭВМ, если для решения задачи требуется подготовка больших массивов исходных данных, выполнение значительного количества чисто технических операций. К такому типу задач в АСГС относится, например, обработка текущей статистической отчетности с помощью КЭОИ. Решения подобных задач обычно не связано с оперативностью получения результата и может, следовательно, осуществляться в пакетном режиме.
Отметим, что в условиях функционирования банков данных в группу эксплуатационников относятся и администраторы данных /40/; В их задачу входит определение состава и первоначальное формирование базы данных, а также последующее регулярное поддержание ее в актуальном состоянии. Недооценка значения данной категории пользователей существенно сказывается на качестве функционирова - 36 ния банка данных. Будем подразделять администраторов данных на администраторов прикладных областей, администраторов баз данных и администраторов приложений
Отличительной особенностью группы эксплуатационников является то, что, не интересуясь содержательной стороной информации, эта группа рассматривает ее как объект приложения определенного способа обработки. Поэтому областью профессиональных интересов данной группы пользователей является технология машинной обработки информации, операционная среда, в которой функционирует конкретная задача, и технические возможности вычислительной установки, на которую рассчитана эксплуатация программного продукта.
Остановимся далее на характеристик внешних пользователей АСГС. Как было показано в разделе I.I, развитие в рамках внедрения второй очереди АСГС технических и программных средств, связанное в первую очередь с распространением в вычислительной системе ЦСУ СССР ЭВМ третьего поколения и с разработкой типовой программной продукции - СУВД, постепенно снимает ограничения на использование единого информационного фонда данных при обработке статистической информации. Широкие возможности по использованию этих данных, предоставляемые режимом информационно-справочного обслуживания АВД АСГС, создают предпосылки к расширению круга пользователей АСГС за счет экономистов различных подразделений ЦСУ СССР.
Разработка методов управления многоуровневым диалогом
Формальное описание структуры диалога, выполненное в терминах теории графов, позволяет выполнить дальнейшее исследование методов управления многоуровневым диалогом. При анализе диалоговых структур будем использовать аналитический способ задания графов, в частности, применять следующие математические конструкции:
I. Матрицу смежности графа G(4yF), которая может служить инструментом исследования при определении длины маршрута в графе, их общего количества, средней длины маршрута и т.д. А. 2. Степень вершины P(j() , полустепенъ захода Р (Ц) вершины и , полустепень исхода Р Гу) вершины у .
Наличие в графе петель /рис. 2.1.2./ осложняет анализ характеристик диалога: количество маршрутов, средняя длина маршрута, глубина маршрута и т.д. Однако любой ориентированный граф с петлями может быть представлен графом-деревом путем тиражирования вершин, имеющих петли. Чтобы получаемое граф-дерево было конечным, дуге, инцидентной только одной вершине исходного графа, присваивается вес, ограничивающий количество прохождений данной дуги. При этом количество повторений тиражируемой вершины в граф-дереве определяется в соответствии со значением ее полустепени захода. Содержательно такое ограничение интерпретируется как невозможность выполнения одной и той же операции в диалоге бесконечного числа раз.
Покажем, как базовые примитивы структуры диалога, выделенные нами при построении модели , могут быть преобразованы в соответствующее граф-дерево, если применить к ним семантические правила информационного языка банка данных.
Наличие петли у вершины \JH в подграфе первого уровня диалога /рис. 2.2Л./ означает возможность описания в запросе серии показателей. Дуге, инцидентной только вершине UH , назначим вес, ограничивающий максимально допустимое количество показателей в запросе. Это статика структуры. Значение данного веса, определяемое как m = г (у ц ) , рассчитывается системой в сеансе связи в зависимости от имеющегося ресурса оперативной памяти ЭВМ, выделяемой при размещении каждого обрабатываемого запроса. Текущее же значение, которое принимает гп в конкретном сеансе связи, зависит от смыслового содержания решаемой задачи. Поэтому оно определяется пользователем, но при этом контролируется системой. Это динамика структуры.
Отметим, что поскольку вершина LL связана с расшифровывающим ее подграфом второго уровня диалога, ее тиражирование на . первом уровне порождает построение соответствующего граф-дерева и для второго уровня диалога /рис. 2.2.I./.
Рассмотрим далее процесс формирования производного показателя по маршруту, начинающемуся в вершине цЧ1 и заканчивающемуся в вершине мЧ7 /рис. 2.2.2./. Вершины подграфа отождествляются с моментами завершения следующих событий: U4l - установление системой необходимости формирования именно производного показателя; UHS - получение от пользователя формулы для расчета показателя; уче - получение показателя, расшифровывающего левую часть формулы; учг - получение показателя, расшифровывающего очередной операнд в правой части формулы.
Дуге, инцидентной только вершине U47 , присваивается вес, ограничивающий количество показателей, расшифровывающих операнды формулы. Его значений, определяемое как К Р+(имт) , зависит от вида формулы расчета производного показателя. Например, для производного показателя вида: А=В+С/Д, где формула содержит в правой части три операнда В, С, Д, необходимо трижды тиражировать вершину иН7 в соответствующем граф-дереве.
Следующий пример иллюстрирует процесс формирования реквизитов показателя, задающих для СУЩ его семантическое описание; Количество реквизитов для каждого показателя является переменной величиной. Эта величина есть функция типа решаемой задачи и целей пользователя. Тип решаемой задачи предопределяет максимально допустимое множество реквизитов любого показателя. Выбор необходимых реквизитов, но уже только внутри допускаемого множества, выполняется пользователем под контролем системы. Тип показателя, выбранная пользователем форма его задания также ограничивают допустимое множество реквизитов. Следовательно, процесс формирования реквизитов показателя для конкретного сеанса связи целесообразно строить по индивидуальному сценарию диалога для каждого показателя. Такой сценарий, содержащий, только необходимые по смыслу формируемого запроса шаги диалога, уменьшает потенциально возможное количество ошибок пользователя и сокращает время формулирования запроса.
Разработка входного языка системы и методов реализации его синтаксически управляемого перевода
При определении основных требований к диалоговой системе было показано, что основным средством, обеспечивающим удобную форму ведения диалога, гарантирующую высокий уровень взаимопонимания партнеров, является развитый проблемно-ориентированный язык системы.
.Анализ предметной области проектируемой системы и специфических черт, присущих ее будущим пользователям, позволяет сформулировать следующие требования к входному диалоговому языку: - мощность выразительных средств языка, достаточная для формулирования и обработки любого запроса, допускаемого АБД АСГС; - наличие средств, позволяющих адекватно описать запрос к АІЩ АСГС в терминах предметной области пользователя; - простота и лаконичность конструкций языка, гарантирующие успешное его освоение; - соблюдение принципа умолчания и неполноты информации, терпимость к ошибкам пользователя; - наличие развитой справочной службы; - обеспечение равноправности партнеров в диалоге за счет включения в язык средств управления ходом диалога; - гибкость к изменению функциональных возможностей системы.
При создании многоуровневой диалоговой системы представляется целесообразной разработка многослойной, иерархической структуры языка, включающей подмножества, ориентированные на отдельные уровни диалога. При этом композиционное единство языка достигается тем, что требования, предъявляемые к языку вцелом, должны выполняться и для любого его подмножества. В частности, такие требования, как возможность адекватного описания запроса в терминах предметной области пользователя, наличие развитой справочной службы, возможность управления диалогом, гибкость к изменению функциональных возможностей системы, терпимость к ошибкам пользователя должны найти свое отражение при реализации языка любого уровня.
Однако создание семейства языков позволяет учесть и противоречивость требований различных групп пользователей за счет локализации ряда черт языка в рамках некоторого его подмножества. Так, например, простота и лаконичность являются неотъемлемым и естественным свойством языка нижнего уровня диалога. При работе на этом уровне пользователь "не видит" формируемого запроса, т.к. ЭВМ самостоятельно строит его в результате целенаправленного опроса партнера. В этих условиях можно организовать разбиение информации, принимаемой от пользователя, на простейшие элементы. Следовательно, язык нижнего уровня диалога удобно представить в виде выбора по меню. Понятно, что при такой форм е взаимодействия, когда сообщения ЭВМ формулируются в виде подробных, развернутых инструкций выбора одного из возможных вариантов ответа, сообщения пользователя можно превратить лишь в указатель на один из них.
Можно с уверенностью предположить, что ведение детализированного диалога на простейшем для пользователя языке в сочетании с возможностями развитой справочной службы практически полностью исключит неудачное завершение сеанса связи для неопытного пользователя из-за его ошибок.
Поскольку верхний уровень диалога ориентирован на квалифицированного пользователя и предполагает его самостоятельность при формулировании информационных потребностей, язык этого уровня должен содержать средства для явного описания запроса в тер - 84 минах предметной области. Текст запроса, составленный на этом языке, будет представлять собой последовательность предложений, задающих для СУЩ требуемые характеристики объектов статистического наблюдения и способы их обработки, Внимание разработчика при создании языка верхнего уровня диалога должно быть сконцентрировано на таких требованиях, как мощность выразительных средств языка, соблюдение принципа умолчания и неполноты информации и т.д.
Входной язык диалоговой системы имеет специфические особенности, порождаемые именно диалоговым способом общения партнеров. В связи с этим его разработка существенно отличается от создания других искусственных языков, имеющих одностороннюю направленность, например, алгоритмических языков программирования.
Мы определили диалог как процесс структурированного обмена сообщениями между партнерами. Следовательно, при разработке диалогового языка необходимо выделять конструкции, функционально связанные с каждым шагом диалога. При этом каждая конструкция языка должна включать реплики обоих партнеров, отражающие знания из предметной области, в которой ведется диалог. Реплики партнеров оформляются в языке в виде связанных между собой сообщений ЭВМ и пользователя, построение которых подчиняется определенным синтаксическим правилам.
Разработка технологии решения задач статистического анализа с использованием диалоговой системы АВД АСГС
При рассмотрении работы модуля управления диалогом за рамками обсуждения остались вопросы, связанные с организацией дисциплины обслуживания очередей терминальных устройств. Их решение не. является в данном случае принципиальным, т.к. оно может меняться в конкретных условиях реализации ПО ДС в зависимости от используемой версии операционной системы ЭВМ.
Рассмотрим далее организацию контроля запроса, получаемого в ходе диалога партнеров. Выбор наилучшей стратегии выполнения контроля запроса имеет первостепенное значение для улучшения эксплуатационных характеристик АВД АСГС, т.к. всестороннее и качественное его проведение на стадии формирования запроса сокращает время его пребывания в стадии обработки банком данных.
При проектировании контролирующих функций диалоговой системы ставятся две взаимосвязанные задачи: определение всех видов контроля запроса, доступных на стадии его формирования, и выбор момента выполнения контроля в диалоговом сеансе.
Эти задачи решены при реализации диалоговой системы следующим образом. В системе принят метод поэтапного контроля запроса, заключающийся в том, что индивидуальному контролю подвергается каждый формируемый в данный момент фрагмент запроса, имеющий законченное смысловое содержание. Ошибочный фрагмент не может быть помещен в запрос, т.к. система при его обнаружении вынуждает пользователя немедленно предпринять меры по его исправлению. При этом продолжение диалога возможно только после получения правильного ответа в текущем шаге диалога. В ряде случаев, когда формирование законченного смыслового фрагмента запроса выполняется за ряд шагов диалога /низший уровень диалога/, его контроль осуществляется на заключительном шаге. В этом случае для исправления ошибки повторяется вся последовательность шагов диалога, связанная с формированием данного фрагмента.
Отметим, что метод поэтапного контроля запроса обладает дополнительным преимуществом по сравнению с методом сквозного контроля запроса после завершения его формирования. А именно, идентификация ошибок пользователя в момент их совершения и последующая корректировка , возможно, с подключением справочной службы способствуют быстрому обучению правилам работы с системой.
В целях обеспечения всесторонней проверки сообщение пользователя на каждом шаге диалога подвергается двум видам контроля: синтаксическому и семантическому. Первый вид контроля выполняется для всех без исключения шагов диалога модулем контроля по формату, входящим в состав подсистемы управления диалогом. Семантический контроль выполняется только для тех шагов диалога, в которых заканчивается формирование смысловых фрагментов запроса. Этот вид контроля осуществляется соответствующей программой, входящей в цепочку обрабатывающих программ шага диалога.
Заключительным этапом формирования запроса является его сквозной контроль. Его целью является обнаружение остаточных нарушений семантических связей между элементами запроса, проверить которые не представлялось возможным на отдельном шаге диалога. При обнаружении ошибок такого рода пользователь получает соответствующее аварийное сообщение и ему предоставляется возможность диалоговой корректировки неверных элементов запроса.
Модуль управления диалогом обращается к модулю обработки аварийных ситуаций во всех случаях неблагополучного завершения контроля сообщений пользователя. Последний, установив соответствующее значение системных ключей, моделирует аварийную ситуацию и тем самым не позволяет модулю управления диалогом осуществить переход к следующему шагу диалога. Кроме того,модуль обработки аварийных ситуаций выполняет окончательное редактирование конкретного аварийного сообщения для передачи его модулю ввода-вывода. Полный текст этого сообщения содержит три составляющих: текст первоначального сообщения ЭВМ для текущего шага диалога, текст полученного от пользователя ошибочного ответа, текст идентификации ошибки, сформированный соответствующей программой контроля. Получив, таким образом, на экране терминала "историю создания" своей ошибки, пользователь имеет полную информацию для ее анализа и исправления. Если и этого недостаточно, пользователь имеет возможность попросить помощь у справочной службы системы введя соответствующую директиву.
