Глава 9 Проектирование технологических процессов обработки экономической информации в локальных эис

9.1 Организация решения

экономических задач

Содержание работ по проектированию процессов обработки экономической информации определяется особенностями, при­сущими экономической задаче как основной единице обработки данных локальных ЭИС. Под экономической задачей принято понимать взаимосвязанную последовательность операций или действий, выполняемых над одним или несколькими файлами с целью получения хотя бы одного экономического показателя, выдаваемого в форме документа на бумажный носитель или за­писываемого на машинный носитель. Можно выделить следую­щие специфические особенности, свойственные экономическим задачам:

• реализация с помощью решения экономических задач функ­ций управления;

• разрешимость задач (для любой задачи существует некоторое решение);

• алгоритмизируемость задач (с этой точки зрения выделяют хорошо и слабо формализованные задачи);

• структурированность алгоритма решения задачи и возмож­ность разбиения его на блоки и модули;

• преобладание последовательной отработки файлов с исход­ными данными;

• невысокая степень использования математических методов (только 25% задач используют математические методы);

• форматированность входных и выходных данных в виде до­кументов строго определенной формы и содержания;

• связанность экономических задач через общую информаци­онную базу;

• упорядоченность используемых данных по ключевым при­знакам;

• регулярность решения (повторяемость);

• выдача результатов решения задач к определенным срокам.

Экономические задачи характеризуются совокупностью групп параметров, согласно которым можно выделить классы задач. К этим группам параметров можно отнести следующие.

1. Параметры, характеризующие использование входных данных:

• количественные (например, объем файла, количество файлов, объем актуализации и др.);

• качественные (например, характер информации, время изме­нения файла, упорядоченность файла и др.).

2. Параметры, характеризующие получение выходных данных:

• сложность структуры выходных данных;

• срочность изготовления;

• число экземпляров.

3. Параметры, характеризующие алгоритм решения задачи:

• типы операторов (вычислительные, логические, операторы передачи управления, ввода, вывода);

• частота использования операторов;

• вероятность перехода по ветвям алгоритма;

• число повторений в операторах циклов.

4. Параметры оценки сложности обработки:

• время работы;

• объем программы;

• класс сложности программ (простые - 500 симв. / оператор для задач оперативной обработки данных, средние - 5 000 симв. / оператор для аналитических задач, сложные - 20000 симв. / оператор для задач, связанных с решением проблем поддерж­ки принятия решений).

5. Параметры, характеризующие технологию разработки про­граммы реализации задачи на ЭВМ:

• трудоемкость разработки;

• стоимость разработки;

• машинное время отладки.

6. Параметр, характеризующий степень связности задач. Для этого используют коэффициент связности (Ксв), рассчитывае­мый как отношение суммы объема вводимой внешней инфор­мации (Vвнеш) к объему внутренней обрабатываемой информации (Vвнутр)

С этой точки зрения можно выделить локальные задачи, для которых Ксв <1, слабо связанные задачи, средне- и сильно связан­ные задачи при Ксв = 1 и Ксв > 1).

7. Параметр регулярности решения задач, по которым выделя­ют задачи: регулярные (фоновые задачи) и нерегулярные (реше­ние которых носит случайный характер).

8. Параметр оценки периодичности решения задач (в день, декаду, месяц, год).

9. Параметр оценки степени использования (с учетом прав дос­тупа) и сроков использования результатов.

10. Параметр, характеризующий юридическую силу результат­ных документов, получаемых после решения задачи (требующих подписей ответственных лиц или не требующих таковых).

11. Параметр близости средств решения задач к непосредствен­ным пользователям получаемых результатов (локальные и распре­деленные задачи).

12. Параметр, характеризующий режим обработки данных (пакетный, диалоговый, телеобработки, сетевой, реального мас­штаба времени или смешанный).

Все вышеперечисленные параметры должны учитываться про­ектировщиками в процессе разработки проектов автоматизиро­ванного решения экономических задач.

Обычно решение экономических задач объединяется в рам­ках автоматизированных рабочих мест (АРМ), предназначенных для реализации какой-либо цели или функции управления. АРМ проектируется, как правило, в виде функционального пакета при­кладных программ на основе общей информационной базы. Ав­томатизированное рабочее место представляет собой рабочее место персонала автоматизированной системы управления, обо­рудованное средствами, обеспечивающими участие человека в реализации функций управления. АРМ является основным орга­низационным компонентом ЭИС и представляет собой совокуп­ность методических, языковых, программных, информационных и технических средств, обеспечивающих работу пользователя на ЭВМ в конкретной предметной области.

Методическое обеспечение АРМ составляет комплекс инструк­ционных материалов, регламентирующих поведение всех типов пользователей в условиях работы АРМ. Можно выделить два типа пользователей АРМ. Первый тип - специалист предметной области, второй тип - программист, который должен будет со­провождать программное обеспечение АРМ. Методическое обес­печение для первого типа пользователей включает в себя инст­рукционные материалы, которые отражают технологию включе­ния АРМ в работу; обращения к АРМ и выполнение необходимых подготовительных операций; ведение баз данных; обработку и решение задач; поиск и выдачу справок; выключение АРМ в кон­це рабочего дня. Инструкционные материалы для второго типа пользователей содержат сведения о порядке установки пакета; о принятии решений в случае прерываний работы пакета, в случае сбоя в работе техники; о порядке исправления ошибок в пакете; о порядке сопровождения пакета; о порядке доработки пакета с целью адаптации к изменению внешних условий.

Языковые средства АРМ должны ориентироваться на специ­алистов трех типов: разработчика пакета, для которого лингвис­тическим обеспечением будет язык операционной системы и ба­зовый язык разработки пакета; специалиста предметной облас­ти, работающего со входным языком пакета, который должен отражать словарную специфику предметной области и специфи­ку технологии обработки в диалоговом языке типа «МЕНЮ», «запрос - ответ» и в языке подсказок; прикладного программис­та, сопровождающего пакет, для которого языковым средством будут все три типа языка.

Информационное обеспечение АРМ включает в себя:

• классификаторы и справочники;

• средства перекодирования с естественного языка в язык обра­ботки данных;

• макеты входных и выходных документов;

• структуры базы данных конкретной предметной области;

• сценарий диалога в виде совокупности меню или информаци­онных сообщений;

• совокупность текстов помощи.

Если АРМ имеет функцию обучения, то в его состав включа­ются демонстрационные примеры и инструкции по технологии ее использования.

Технические средства АРМ могут включать ПЭВМ, средства локальных сетей и периферийные устройства (сканеры, стриме­ры, плоттеры, факсмодемы и др.).

Программные средства АРМ разделяются на средства обще­го и специализированного назначения. К программным сред­ствам общего назначения относятся: операционные системы, опе­рационные оболочки, СУБД, трансляторы и средства разработ­ки программ. К программным средствам специализированного назначения относятся:

· методо- ориентированные ППП;

· функци­онально-ориентированные ППП

· профессионально-ориентиро­ванные ППП.

К методо- ориентированным относят пакеты, реализующие, например, методы линейного и динамического программирова­ния, статистической обработки информации и др.

К функциональ­но-ориентированным пакетам относятся пакеты обработки бух­галтерских, финансовых документов, управления кадрами, мар­кетинговых исследований, контроля исполнения документов, технической подготовки производства и др.

В состав профессио­нально-ориентированных пакетов входят табличные процессоры, текстовые редакторы, интегрированные пакеты, пакеты деловой графики.

В состав задач, объединенных в одном АРМе, могут входить задачи, решаемые в разных режимах: пакетном, диалоговом, уда­ленного доступа. В последующих параграфах рассматриваются особенности проектирования технологических процессов реше­ния задач в пакетном и диалоговом режимах.

9.2 Проектирование технологических процессов обработки данных в пакетном режиме

К задачам, решаемым в пакетном режиме (запускаемым, как правило, в виде фоновых заданий), относятся задачи, характери­зующиеся следующими признаками: слабой разветвленностью алгоритма, отсутствием необходимости вмешательства пользо­вателя в ход решения и выбора варианта решения, большими объемами обрабатываемых данных и длительным временем ре­шения и получения результатной информации. К таким задачам относятся, например, задачи статистической обработки данных, планирования производственной программы, расчета заработ­ной платы и др.

Процесс проектирования внутримашинной технологии реше­ния задач в пакетном режиме состоит из выполнения ряда опера­ций, содержание и последовательность которых, а также состав получаемых проектных документов зависят от методов и инст­рументальных средств проектирования, выбираемых на предпроектной стадии. В условиях использования оригинальной техно­логии и канонического проектирования к методам и инструмен­тальным средствам проектирования программного обеспечения задач относят методы IPT-технологии проектирования и проце­дурно-ориентированные языки программирования.

В первую группу входит совокупность взаимосвязанных ме­тодов проектирования, которые были разработаны фирмой IBM:

• метод структурного проектирования;

• метод модульного проектирования;

• метод проектирования «сверху-вниз»;

• метод структурного программирования;

• метод HIPO-документирования.

Все эти методы хорошо описаны в различных литературных источниках. Кратко остановимся на содержании каждого из них.

Основной задачей структурного проектирования является выделение полного состава функций, для выполнения которых предназначаются разрабатываемые программные средства зада­чи. Выделяют два главных этапа структурного проектирования:

• этап общего проектирования, после которого проектировщик получает полный состав функциональных блоков и связей между ними;

• этап детального проектирования, задачей которого является определение полного состава программных блоков и связей между ними, показывающего, по какой технологии реализу­ются выявленные ранее функции.

Структурное проектирование позволяет на раннем этапе про­ектирования определить необходимые функции, которые долж­на реализовывать задача в процессе своей эксплуатации и убрать дублирующие.

Модульное проектирование дает возможность разбить про­граммные и функциональные блоки на оптимальное количество модулей небольшой размерности (длиной до пятисот операторов), определить назначение каждого модуля и осуществить иденти­фикацию его входных и выходных параметров.

По своему назначению модули делят на управляющие и ис­полнительные, а по степени общности - на стандартные и ориги­нальные.

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

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

Структурное программирование основывается на выполнении нескольких ограничений. Первое касается размеров модулей и сегментов, согласно которым небольшой по размеру модуль (до 500 операторов) вначале сегментируется на небольшие разделы (сегменты) размером на один лист (до 60 операторов). Дальней­шая сегментация идет в пределах листа с выполнением располо­жения сегментов на листе со сдвигом слева направо для улучше­ния визуальных характеристик программы.

Другим ограничением, применяемым в этом методе, является ограничение на типы используемых операторов и структур. Ре­комендуется использование линейной структуры (последователь­ность взаимосвязанных операторов), иерархической структуры с оператором if и циклических (кольцевых) структур с использова­нием оператора do while. He рекомендуется применение опера­тора go to.

Структурное программирование позволяет повысить степень читаемости программной документации и качество сопровожда­емости программного продукта.

Для обеспечения качественного документирования разработ­ки программного продукта в этой технологии предлагалось ис­пользование нескольких методов, в частности, например, исполь­зование стандартного пакета документов HIPO (иерархия - вход - процесс - выход), в который входят три типа документов.

1. Таблица содержания пакета, в которой рисуется иерархи­ческая структура пакета, состоящего из полной совокупности соподчиненных функциональных блоков.

2. Обзорная схема каждой функции, в которой описываются документы, массивы, данные, идущие на вход функции, этапы обработки и перечень документов и массивов, получаемых на выходе функции.

3. Подробная схема функции (описываются вход, процесс и выход каждого программного блока и дается указание внешних и внутренних потоков информации).

Положительной стороной использования пакета HIPO явля­лась стандартность представления описания программных про­дуктов и возможность поддерживать хорошую его читаемость на этапе эксплуатации и сопровождения. К отрицательным сторо­нам можно отнести: трудность внесения изменений в документа­цию, поскольку документация включает большое количество схем; высокую сложность каждой схемы и большую степень их связанности; высокие требования к квалификации исполнителя.

Схема выполнения работ по проектированию технологичес­кого процесса обработки информации для конкретной задачи, решаемой в пакетном режиме, представлена на рис. 9.1. Содер­жанием первой операции (П1) является анализ описания задачи, полученного в результате выполнения предпроектной стадии, со­держания «Технического задания» к ЭИС; состава предваритель­но выбранных на предпроектной стадии КТС и ОС, выработка требований к задаче и разработка «Технического задания» на про­ектирование задачи.

Рис. 9.1. Технологическая сеть проектирования процесса обработки информации в пакетном режиме

На рис. 9.1 приняты следующие обозначения.

U 1.1 - универсум методов разработки ПО; Д 1.1 - материалы обследования (описание задачи); Д 1.2 - комплекс технических средств и операционная система; Д 1.3 - принципы организации информационной базы; Д1.4 - ТЗ на разработку; Д 2.1 - поста­новка задачи; U 3.1 - универсум факторов выделения функцио­нальных блоков; U 3.2 - универсум критериев выделения функ­циональных блоков; U 3.3 - универсум подходов к выделению функциональных блоков; U 3.4 - универсум методов выделения функциональных блоков;

Д 3.1 - функциональная блок-схема за­дачи; U4.1 - универсум критериев и методов разбиения функци­ональных блоков; Д 4.1 - схема взаимосвязи программных моду­лей и информационных файлов (укрупненный алгоритм); U 5.1 -универсум алгоритмических языков; Д 5.1 - детальные блок-схе­мы программных модулей; Д 5.3 - описание текста программ; Д 5.2 - распечатка программы; Д 6.1 - отлаженный текст про­граммы; Д 7.1 - исходные данные контрольного примера; Д 7.2 -отлаженный текст программы; Д 7.3 - описание контрольного примера; Д 8.1 - документация по ПО; Д 9.1 - технологическая документация.

На вход данной операции поступают «Описание задачи», по­лученное на этапе анализа материалов обследования (Д1.1), опи­сание выбранного комплекса технических средств и операцион­ной системы (Д1.2), принципы организации информационной базы (Д1.3), универсум методов разработки программного обес­печения (U1.1).

На выходе операции получают «Техническое задание» на раз­работку программирования задачи (Д1.4). ТЗ должно отражать: функции управления и операции обработки, выполняемые при решении данной задачи; состав и содержание документов, фай­лов информационной базы; особенности и параметры решаемой задачи.

На второй операции (П2) осуществляется разработка «Поста­новки задачи». Исходными данными для операции служит ТЗ на разработку (Д1.4), полученное на предыдущей операции. В ре­зультате выполнения этой операции получают документ «Поста­новка задачи» (Д2.1), включающий, как об этом было сказано выше, описание цели и назначения решения задачи, экономичес­кую и организационную сущность данной задачи, характеристи­ку регулярности и периодичности счета, формализованный ал­горитм решения, описание входных и выходных сообщений и документов.

Содержание следующих операций проектирования зависит в значительной степени от выбранных методов и инструмента про­ектирования. В случае использования методов IPT-технологии и в качестве инструмента - процедурно-ориентированного языка программирования содержанием следующей операции является функциональный анализ задачи (ПЗ). Входными данными для дан­ной операции служат «Постановка задачи» (Д2.1), «ТЗ на разра­ботку» (Д1.4), описание выбранного средства разработки, уни­версумы методов разработки (U1.1), факторов выделения функ­циональных блоков (U3.1), критериев (U3.2) и подходов к выделению функциональных блоков (U3.3).

Результатом выполнения этой операции является описание общей структуры программного обеспечения задачи и состава функциональных блоков, реализующих основные функции, для которых предназначается данная задача, т.е. ее функциональная блок-схема (ДЗ.1).

Целью выполнения функционального анализа являются вы­бор подхода, с учетом которого анализируется задача, и опреде­ление оптимального числа функциональных блоков. К основным подходам (U3.1), по которым осуществляют разбиение задачи на функциональные блоки, можно отнести следующие:

• достижение минимальных трудовых и стоимостных затрат на стадиях проектирования, внедрения и сопровождения проекта;

• сокращение числа ошибок в тексте за счет повышения степе­ни читаемости текстов программ.

К основным подходам, применяемым при разбиении задач на функциональные блоки (U3.3), относят следующие:

• подход от анализа результатной информации, который приме­няется, если задача связана с выдачей большого числа сводок;

• подход, основанный на анализе состава входных файлов для задач, связанных с организацией загрузки и корректировки файлов информационной базы;

• подход, базирующийся на анализе сложного алгоритма реше­ния задачи, если в нем можно выделить блоки, реализующие функции управления и обработки;

• подход от анализа структуры алгоритма, основывающегося на использовании экономико-математических методов и по­строении математической модели;

• смешанный вариант.

В процессе функционального анализа в качестве критериев разбиения задачи на функциональные блоки (U3.2) выбирают: размерность задачи; территориальную рассредоточенность зада­чи; распределенность решения задачи во времени; количество входных файлов; количество файлов-корректур; количество фун­кциональных связей и др. При этом используют следующие ме­тоды разбиения (U3.4):

• по функциям технологии управления, автоматизируемым с помощью решаемой задачи;

• по операциям обработки;

• смешанный вариант.

Выполнение четвертой операции (П4) связано с разработ­кой укрупненного машинного алгоритма решения задач, реализу­ющего внутримашинный технологический процесс обработки данных.

Исходными данными для такой операции являются универ­сум критериев и методов разбиения функциональных блоков на программные блоки (U4.1), ТЗ (Д1.4), общее описание задачи (Д1.1) и функциональная блок-схема задачи (ДЗ.1). Результатом выполнения операции являются укрупненные блок-схемы алго­ритмов решения задачи по каждому функциональному блоку, представляющие собой схемы взаимосвязи программных моду­лей и информационных файлов (Д4.1).

Следует отметить, что причины и критерии, по которым про­изводится разбиение функциональных блоков на программные модули, остаются те же, что и при выделении функциональных блоков. Блок-схемы алгоритмов функциональных блоков стро­ятся с использованием двух подходов (U4.1):

• классического метода, который характеризуется установлени­ем последовательной связи между программными блоками, реализующими типовые операции обработки экономической информации, что позволяет строить линейную структуру ал­горитма, где связь между отдельными программными блока­ми осуществляется через данные;

• подхода, ориентированного на выделение оригинальных и стандартных программных модулей, к которым можно неод­нократно обращаться как внутри одного функционального модуля, так и из других функциональных модулей.

При использовании первого подхода основной задачей проек­тировщика является определение состава обрабатываемых фай­лов с переменной и постоянной информацией, файлов с резуль­татной информацией, состава и последовательности типовых операций обработки данных, к которым относят следующие:

• чтение записей файлов с переменной информацией;

• сортировку введенных файлов по ключевым признакам;

• чтение записей файлов с постоянной информацией, необхо­димой для выполнения операций обработки;

• выполнение операций обработки над записями с постоянной и переменной первичной информацией и получение файлов с результатной информацией;

• чтение записей файлов со справочной информацией для фор­мирования файлов результатной информации для выдачи ее на печать;

• печать файла результатной информации и получение отчетов или сводных ведомостей.

Особенность второго метода заключается в необходимости построения иерархической структуры взаимосвязи функциональ­ных и входящих в них программных блоков, в которой выделяют управляющие и исполнительные модули. Исполнительные моду­ли, в свою очередь, могут быть подразделены на специальные мо­дули, предназначенные для использования в определенных фун­кциональных блоках, и стандартные модули, которые могут быть использованы при исполнении других функциональных блоков, реализуемых данной задачей. Передача управления между моду­лями в этом случае может осуществляться через данные и через совокупность параметров.

При выполнении следующей операции (П5) осуществляется «Разработка детальных блок-схем программных модулей и их кодирование» (Д5.1). На входе данной операции разработчик ис­пользует блок-схемы укрупненных алгоритмов функциональных блоков (Д4.1), разработанные на предыдущей операции, и уни­версум алгоритмических языков (U5.1). К основным критериям выбора алгоритмических языков относят следующие:

• мощность алгоритмического языка, т.е. наличие достаточ­ного количества языковых конструкций, покрывающих все потребности алгоритма решаемой задачи;

• синтаксическую и семантическую ясность языка, что способ­ствует его быстрому освоению;

• объем алгоритма, размерность программы;

• время написания программы;

• время отладки, трансляции, решения задачи;

• объем памяти, занимаемой разработанной программой;

• диагностические возможности языка;

• совместимость с другими языками;

• возможность удаленной обработки информации;

• возможность управления файлами;

• степень готовности языка;

• надежность языка.

Целью выполнения шестой операции (П6) является осуществ­ление синтаксической и семантической отладки каждого про­граммного модуля (Д6.1), которая осуществляется на основе опи­сания текста (Д5.3) и распечатки (Д5.2) программы, а также блок-схем программных модулей (Д5.1).

На следующей операции (П7) выполняется комплексная от­ладка программных модулей на контрольном примере. На входе операции используют отлаженные тексты программных модулей (Д6.1) и исходные данные контрольного примера (Д7.1), на вы­ходе получают полностью отлаженное программное обеспечение задачи (Д7.2) и описание контрольного примера (Д7.3).

В процессе отладки проектировщик может использовать не­сколько методов контроля правильности работы программы, такие, как: метод усеченного алгоритма; выход на контрольные результаты; контроль времени решения задачи и др.

Заключительной операцией при проектировании технологии. обработки данных на ЭВМ является подготовка программной до­кументации (П8), в состав которой входят: общее описание зада­чи, описание структуры программного обеспечения и назначе­ния каждой из его составных частей, тексты программ, перечни используемых файлов информации, руководства пользователям, программистам и описание контрольного примера (Д8.1). По схеме взаимосвязи программных модулей и информационных файлов (Д4.1) формируется на соответствующей операции (П9) технологическая документация (Д9.1).

Если проектировщик выбирает в качестве инструментария одно из средств частичной автоматизации проектирования ти­повых операций обработки, то состав работ по проектированию процессов обработки данных будет зависеть от его типа.

Выделяют следующие виды средств частичной автоматизации проектирования типовых операций обработки данных:

• библиотеки макрогенераторов;

• библиотеки стандартных подпрограмм;

• генераторы программ;

• интерпретаторы, ориентированные на предметную область.

Суть метода использования библиотеки макрогенератора зак­лючается в том, что проектировщики, исходя из опыта проектиро­вания, выделяют в теле задач часто повторяющиеся последователь­ности операторов, реализующие небольшие функции обработки. На эти последовательности разрабатываются макрорасширения, имена которых обрабатываются макрогенератором, поэтому в тело программы включаются макрокоманды с параметрами, что зна­чительно сокращает объем работ по программированию. В слу­чае использования данного средства проектировщик должен вы­полнить следующие работы:

• анализ алгоритма задачи;

• анализ содержания библиотеки макроопределений (библио­тека макрогенератора);

• написание на базовом языке исходной программы;

• включение в тело программы макрокоманд с параметрами (макроопределения);

• подготовка программы к вводу;

• ввод программы и ее обработка макрогенератором, который включает макрорасширения из библиотеки;

• трансляция и редактирование программы;

• испытание на контрольном примере, подготовка документа­ции.

Если проектировщик использовал библиотеку стандартных подпрограмм, то в состав операций по проектированию должны входить такие операции, как: декомпозиция задачи на функцио­нальные блоки; выбор типовых процедур и состава стандартных подпрограмм; разработка принципов связи программных моду­лей, списков передаваемых параметров; разработка алгоритмов оригинальных программных модулей; выбор языка программи­рования, написание и отладка кодов программ; соединение типовых процедур и оригинальных программных модулей; разра­ботка управляющих модулей; комплексная отладка на конт­рольном примере с разработкой программной документации.

Дальнейшее развитие методика проектирования внутримашинной технологии обработки данных получила при исполь­зовании генераторов программ и программ интерпретирую­щего типа.

 

9.3 Проектирование технологических процессов обработки данных в диалоговом режиме

Диалог - это процесс обмена сообщениями между пользова­телем и ЭВМ, при котором осуществляется постоянная смена ролей информатора и реципиента (пользователя, принимающе­го информацию), причем смена ролей должна быть достаточно оперативной. Процесс диалога должен удовлетворять следующим условиям:

• единая цель информатора и реципиента;

• постоянная смена ролей пользователя и ЭВМ;

• общий язык общения;

• наличие общей базы знаний (данных);

• возможность пополнения базы знаний хотя бы одним из объек­тов (субъектов).

Для осуществления диалога необходимо разработать диало­говую систему (ДС), представляющую собой совокупность тех­нического, информационного, программного, лингвистического обеспечения, предназначенную для выполнения функций управ­ления диалогом, информирования пользователя, ввода информа­ционных сообщений, обработки их с помощью прикладных про­грамм и выдачи результатов.

Можно выделить несколько характеристик ДС, значения ко­торых определяют процесс диалогового взаимодействия пользо­вателя и ЭВМ. Важнейшей из них является степень оперативнос­ти диалога. При этом возможна оперативность двусторонняя или односторонняя - со стороны ЭВМ или человека. В первом слу­чае диалог называется активным со временем ожидания до 2 с., во втором - пассивным, время ожидания при нем может дости­гать 3 мин.

Другой характеристикой диалоговых систем служит способ­ность к управлению. Она тесно связана с такими условиями вы­полнения диалога, как наличие знаний у партнеров и взаимопо­нимания между ними с помощью общего языка. Эта характерис­тика выражается в способности к выдаче таких команд партнеру, которые требуют выполнения некоторых действий, направлен­ных на достижение цели диалога.

В процессе диалога возможно двустороннее управление на базе языка типа «запрос - ответ», одностороннее управление со стороны ЭВМ с языком общения типа «меню», «заполнение шаб­лона» и ответа по «подсказке» или одностороннее управление со стороны пользователя с использованием языка директив (команд).

Важной характеристикой является также способность парт­неров к обучению (накоплению знаний о предметной области) и общего языка взаимодействия. Выделяют системы, которые обес­печивают двустороннее обучение партнеров, и системы с одно­сторонним обучением: со стороны либо пользователя, либо ЭВМ.

Помимо вышеперечисленных существует и ряд других харак­теристик, к которым относят:

• среднее время безотказной работы всей диалоговой системы;

• вероятность безошибочного выполнения диалога;

• коэффициент занятости системы;

• стоимость эксплуатации и разработки диалоговой системы.

Диалоговые системы можно классифицировать по ряду при­знаков (рис. 9.2).

По сфере использования можно выделить системы, применяе­мые в процессах управления экономическими системами, в про­цессах проектирования сложных систем в САПР, в обучающих системах, в системах управления данными и в информационно-поисковых системах.

Рис. 9.2. Схема классификации диалоговых систем

По способу организации взаимодействия и наличию приори­тета при организации этого взаимодействия выделяют системы с приоритетным взаимодействием (человека, ЭВМ) и без приори­тетного взаимодействия. Бесприоритетные системы отличаются случайным характером ведения диалога и малой степенью его организованности. Такие системы не являются характерными для применения в экономических системах, в которых, как правило, используют приоритетные схемы взаимодействия человека или ЭВМ в пределах сценария или предметной области и выбранных средств общения.

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

По форме (языку) общения диалоговые системы делятся на системы с языком общения типа «запрос - ответ», «меню», «шаб­лоны», «подсказки», смешанные варианты. Выбор средств обще­ния определяется требованиями, предъявляемыми к системе вза­имодействия со стороны предметной области и режимами общения.

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

Все проблемы проектирования процессов обработки данных в диалоговом режиме можно объединить в две группы:

• проблемы методологического характера, связанные с выбо­ром принципов и методов проектирования диалоговых сис­тем и разработкой проекта на логическом уровне;

• проблемы, связанные с реализацией конкретного варианта проекта диалоговой системы, т.е. проектированием на физи­ческом уровне.

Проектирование диалоговой системы на логическом уровне включает выбор стратегии проектирования, методов проектиро­вания и оценки системы, принципов и способов логической организации и реализации на ЭВМ процессов взаимодействия. Вы­бор логической структуры диалоговой системы зависит от назна­чения диалоговой системы и используемого языка общения.

При выборе в качестве языка общения языка директив типо­выми подсистемами ДС являются:

• ввод-вывод данных;

• ввод директив и их анализ;

• интерпретация директив.

При использовании для общения языка «меню» или языка «запросов» в диалоговой системе должна присутствовать систе­ма планирования и управления диалогом, или диалоговый мони­тор, в функции которого входят:

• управление процессом диалога;

• обеспечение интерфейса пользователя;

• обеспечение выполнения сервисных или справочных функций;

• анализ и обработка ошибочных ситуаций;