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

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

9.1. Организация решения экономических задач

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

133

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

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

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

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

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

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

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

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

Vвнеш.

Ксв=V

Vвнут.

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

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

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

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

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

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

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

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

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

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

134

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

135

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

136

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

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

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

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

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

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

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

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

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

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

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

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

137

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

U 1.1 - Универсум методов разработки ПО Д 1.1 - Материалы обследования (описание задачи) Д 1.2 - Комплекс технических средств и операционная система Д 1.3 - Принципы организации информационной базы Д 1.4 - ТЗ на разработку Д 2.1 - Постановка задачи

U 3.1 - Универсум факторов выделения функциональных блоков U 3.2 - Универсум критериев выделения функциональных блоков U 3.3 - Универсум подходов к выделения функциональных блоков Д 3.1 - Функциональная блок-схема задачи

U 4.1 - Универсум критериев и методов разбиения функциональных блоков Д 4.1 - Схема взаимосвязи программных модулей и информационных файлов (ук­рупненный алгоритм)

U 5.1 - Универсум алгоритмических языков

Д 5.1 - Детальные блок-схемы программных модулей

Д 6.1 - Описание текста программ

Д 6.2 - Распечатка программы

Д 6.3 - Отлаженный текст программы

Д 7.1 - Исходные данные контрольного примера

Д 7.2 - Отлаженный текст программы

Д 7.3 - Описание контрольного примера

Д 8.1 - Документация по ПО

Д 9.1 - Технологическая документация

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

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

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

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

139

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

140

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

141

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

142

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

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

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

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

существует единая цель информатора и реципиента;

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

наличие общего языка общения;

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

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

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

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

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

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

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

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

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

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

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

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

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

144

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

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

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

145

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вызов обрабатывающих программ;

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

146

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

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

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

описать подсистемы ДС, определить интерфейсы между ними и согласовать с
проблемными задачами и конкретной вычислительной средой;

выявить и учесть возможности и детали поведения ДС, а также определить сер­
висные возможности, предоставляемые пользователям;

выработать обобщенный взгляд на ДС в целом;

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

На этапе рабочего проектирования эта модель выполняет следующие функции:

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

использоваться как средство контроля хода проектирования;

служить средством анализа свойств ДС, оценки заданных параметров и ресурсов,
необходимых для реализации системы, и их оптимизации.

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

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

Для отображения структуры графа G (X,F) используется представление его в виде матрицы смежности первого порядка размерностью nхn, где n - число вершин:

где {ij} ∈ I=1,...n,

n - число вершин графа диалога,

fl,ecnHxjeF(xi)

Г11 = •s

[О, если xj ∉ F(xi)

т.е. элемент этой матрицы rij равен 1, если существует некоторая функция, которая пере­водит систему из состояния xi в xj, и rij равен 0, если не существует связи между xi и xj.

147

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

Основным оператором языка описания ГДП, на котором матрица смежности ото­бражается в виде совокупности векторов (строк) Bк={rкj}, где к∈ I, каждый из которых показывает, с какими вершинами в графе диалогового процесса связана вершина к. Язык описания графов диалоговых процедур предназначен для описания структуры различных графов и функций диалоговых процедур, кроме того, его средствами подключаются обра­батывающие программы для решения задач пользователя. Таким образом, язык предос­тавляет пользователю средства совместного описания структуры диалогового процесса и его функций на каждом шаге диалога. Основные конструкции такого языка предназнача­ются для описания вершин, структуры графа и функций, составляющих диалоговый про­цесс на каждом шаге.

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

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

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

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

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

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

148

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

Конечный детерминированный автомат, соответствующий такому представлению ДС, задают в виде отношения [ ]:

M = (X,Y,Q,(p,n

где X ={xi} - множество входных сообщений (инструкций); Y ={yi} - множество выходных сообщений; Q ={qi} - множество состояний ДС (q0 - начальное состояние); ф : Х *Q → Q - функция переходов; Ψ: Х*Q → Y - функция выходов (обычно Ψ: Q → Y).

Для каждого состояния или входного сообщения разрабатывается программный модуль, непосредственно реализующий действие пользователя, заданное инструкцией Xi, т.е. вводится отображение I:X —→ A или I:Q —→ A, где A={aк} N - набор из N реализующих модулей.

Находясь в состоянии qi, под действием инструкции хj система переходит в со­стояние q i+1= ф (xj,qi), выполняет действие aк = I(xj) или aк =I(qi), выдает пользователю сообщение Yр= Ψ (xj,qi) и останавливается, ожидая следующей инструкции. Таким обра­зом, состояния соответствуют местам прерывания автономной работы системы, когда для ее продолжения необходимо вмешательство пользователя.

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

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

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

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

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

149

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

дования, определения параметров задач и получения описания полного комплекса автома­тизируемых задач и их параметров.

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

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

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

Если выбрана стратегия встраивания диалоговых компонент в тело программы, то далее будут выполняться следующие работы:

Составление «Технического задания» на разработку программного обеспечения
задачи.

Разработка «Постановки задачи».

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

Выполнение  функционального анализа задачи и  получение  функциональной
блок-схема решения задачи.

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

Разработка экранов сообщений и описание их структуры.

Выбор языка программирования. Написание текстов программы.

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

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

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

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

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

150

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

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

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

Далее следует осуществить выбор метода проектирования и инструментального средства проектирования. Наличие инструментальных средств проектирования или их от­сутствие позволяет применять метод оригинального проектирования с помощью таких языков программирования, как языки программирования СУБД, Паскаль, С и другие, или автоматизированного проектирования с использованием, например, диалоговой оболочки или генераторов диалога. Технологическая сеть проектирования диалоговых систем с языком общения типа меню в случае выбора метода оригинального проектирования пред­ставлена на рис. 9.4.

151

 

Элементы информационного обеспечения и состав программных модулей позволя­ет выполнить операцию «Разработка блок-схемы работы системы» (П6) и получить доку­мент «Укрупненный алгоритм решения задачи» (Д6.1).

Операция «Разработка кодов программных модулей и выбор алгоритмического языка» (П7) осуществляется на основе универсума языка программирования (U7.1). На выходе получают документы с кодами программных модулей (Д7.1).

Разработанные программные модули (Д7.1) подвергаются «локальной отладке» (П8), в результате чего получают совокупность отлаженных модулей (Д8.1), а затем на базе исходных данных «Контрольного примера» (Д9.1) проходят «комплексную отладку» (П8), в результате чего получают результатные данные (Д9.3) и отлаженный комплекс программных модулей (Д9.2).

153

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

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

Заключительной операцией (П12) является разработка и получение полного ком­плекта технологической документации и инструкционных карт (Д12.1).

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

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

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

Формирование контрольных примеров и их отладка по каждой задаче.

Подготовка программной и технологической документации.

Вопросы для самопроверки:

Каковы особенности экономических задач, влияющих на содержание проекти­
рования технологии обработки данных?

Каков состав основных параметров и каковы классы экономических задач?

Каков состав операций проектирования технологии обработки информации при
решении задачи в пакетном режиме?

Какие методы разработки программного обеспечения вы знаете?

Каковы методы выделения функциональных и программных блоков?

Каков типовой состав операций технологии обработки информации в пакетном
режиме?

Каков состав критериев выбора алгоритмических языков?

Каков состав средств частичной автоматизации используется для проектирова­
ния процедур обработки данных для задач, решаемых в пакетном режиме?

Что такое «диалоговая система» и каковы классы диалоговых систем?

Каковы методы формализованного описания работы диалоговых систем и их
содержание?

Каковы основные стратегии проектирования процессов обработки данных в
диалоговом режиме и их содержание?

154