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

метки: Проектирование, Обработка, Данные, Технологический, Процесс, Задача, Программа, Диалоговый

1. Методы проектирования технологических процессов обработки данных

Задача — основная единица обработки информации. Содержание работ по проектированию процессов обработки экономической информации определяется особенностями экономической задачи, как основной единицы обработки данных в локальных АЭИС.

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

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

Существуют следующие взаимосвязанные методы проектирования 18:

• метод структурного проектирования;
• метод модульного проектирования;
• метод проектирования «сверху-вниз»;
• метод структурного программирования;
• метод HIPO — документирования.

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

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

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

Технология термической обработки стали

... в процессе термообработки стали, которые необходимы при работе и эксплуатации машин, механизмов, приборов. Основная часть Технология термической обработки стали Отжиг I ... термическая и термомеханическая обработка. В данном реферате будут рассмотрены, основные виды термической обработки стали. Выбор темы Тема «Основные виды термической обработки стали» была выбрана, потому, что термообработка сталей ...

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

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

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

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

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

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

Другим ограничением, применяемом в этом методе, являются ограничения на типы используемых операторов и структур. Рекомендуется использование линейных структуры (последовательность взаимосвязанных операторов), иерархической структуры с оператором if и циклических (кольцевых) структур с использованием оператора dowhile. Не рекомендуется применение оператораgoto.

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

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

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

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

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

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

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

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

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

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

Идентифика-тор	Наименование компоненты
U.1.1 Д.1.1. Д.1.2. Д.1.3. Д.1.4. U.2.1. U.2.2. U.2.3. U.2.4. Д.3.1 U.3.1. Д.3.1 U.4.1. Д.4.1. Д.4.2. Д.4.3. Д.5.1. Д.6.1. Д.6.2. Д.6.3. Д.7.1. Д.7.2.	Универсум методов разработки ПО Постановка задачи Комплекс технических средств и операционная система Принципы организации информационной базы Техническое задание на разработку ПО Универсум факторов выделения функциональных блоков Универсум критериев выделения функциональных блоков Универсум подходов к выделению функциональных блоков Универсум методов выделения функциональных блоков Функциональная блок-схема задач Универсум критериев и методов разбиения функциональных блоков Схема взаимосвязи программных модулей и информационных файлов (укрупненный алгоритм) Универсум алгоритмических языков Детальные блок-схемы программных модулей Распечатка программы Описание текста программы Отлаженный текст программы Исходные данные контрольного примера Отлаженный текст программы Описание контрольного примера Документация по программному обеспечению Технологическая документация

Технологическая сеть проектирования процесса обработки информации в пакетном режиме. Схема выполнения работ по проектированию технологического процесса обработки информации для задачи, решаемом в пакетном режиме представлена на рис. 30, а ее компоненты представлены в табл.29 18.

1. Содержанием технологической операции проектирования П.1 — «Анализ требований к задаче, описание задачи» является анализ «Постановки задачи», содержания «Технического задания» на проектирования АЭИС, состава предварительно выбранных на предпроектной стадии КТС и ОС, выработка требований к задаче и разработка «Технического задания» на программирование задачи.

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

На выходе операции получают «Техническое задание» на программирования задачи (Д.1.4).

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

2. Содержание следующих операции проектирования в значительной степени зависит от выбранных методов и инструментов проектирования. В случае использования методов IPT — технологий и в качестве инструмента — процедурно-ориентированного языка программирования, содержанием следующей технологической операцией проектирования П.2 является «Функциональный анализ». Входными данными для выполнения данной операции служат «Постановка задачи» (Д.1.1), «Техническое задание» на разработку программы задачи (Д.1.4) описание выбранного средства разработки универсума методов разработки (U.1.1), факторов выделения функциональных блоков (U.2.1), критериев (U.2.2) и подходов к выделению функциональных блоков (U.2.3).

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

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

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

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

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

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

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

3. Технологическая операция проектирования П.3 — «Разработка укрупненного машинного алгоритма решения задачи» предназначена для реализации внутримашинного технологического процесса обработки данных.

Исходными данными для такой операции являя универсум критериев и методов разбиения функциональных блоков на программные блоки (U.3.1), «Техническое задание» на разработку программы (Д.1.4), «Постановка задачи» (Д.1.1) и функциональная блок-схема задачи (Д.2.1).

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

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

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

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

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

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

4. Технологическая операция проектирования П.4 — «Разработка детальных блок-схем программных модулей и их кодирование» осуществляется на основе блок-схемы укрупненных алгоритмов функциональных блоков (Д.3.1), разработанных на предыдущей операции и универсума алгоритмических языков (U.4.1), Результатом технологической операции проектирования является Д.4.1 — Детальные блок-схемы программных модулей. Процесс кодирования (составление программы) заключается в переводе описаний алгоритма в один (понятных) для ЭВМ языков программирования.

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

Решаемые задачи (пользователем) чаще всего относится к одному классу и могут быть программированы на одном и том же языке. Это гарантирует более быстрое написание программы с меньшим числом ошибок.

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

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

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

Значительного сокращения сроков и трудоемкости программирования задач можно достичь за счет использования готовых программ (ППП, СУБД, библиотеки стандартных программ — БСП).

5. Технологическая операция проектирования П.5 — «Синтаксическая и семантическая отладка программных модулей» осуществляется на основе описания текста (Д.4.3) и распечатки программы (Д.4.2), а также блок-схемы программных модулей (Д.4.1); результатом выполнения этой операции является отлаженный текст программы (Д.5.1).

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

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

6. Технологическая операция проектирования П.6 — «Комплексная отладка программных модулей» выполняется на контрольном примере. На входе операции используют отлаженные тексты программных модулей (Д.5.1) и исходные данные контрольного примера (Д.6.1), а на выходе получают полностью отлаженное программное обеспечение задачи (Д.6.2) и описание контрольного примера.

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

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

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

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

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

7. Технологическая операция проектирования П.7 — «Подготовка программной документации и сдача ее в эксплуатацию». В состав программной документации входят: общее описание задачи, описание структуры программного обеспечения и назначение каждой из ее составных частей, тексты программ, перечни используемых файлов информации; руководства пользователям, программистам и описание контрольного примера (Д.7.1), а также технологическая документация (Д.7.2).

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

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

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

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

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

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

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

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

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

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

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

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

• единая цель информатора и репициента;
• постоянная смена ролей пользователя и ЭВМ;
• общий язык общения;
• наличие общей базы знаний (данных); возможность пополнения базы знаний хотя одним из объектов (субъектов).

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

Характеристика диалоговых систем. Можно выделить несколько характеристик ДС, значения которых определяют процесс диалогового взаимодействия пользователя и ЭВМ: степень оперативности; способность к управлению; способность партнеров к обучению и т. д.

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

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

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

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

Существует также ряд других характеристик ДС, к которым относят:

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

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

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

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

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

Классификация диалоговых систем

№№	Признаки классификации	Классы диалоговых систем
1	По назначению	По управлению процессами в АЭИС Для управления процессами в САПР Для управления процессами в ИПС Для управления процессами в СППР Для управления процессами в ОС
2	По наличию приоритета и способу организации взаимодействия	С приоритетом (человека, ЭВМ) Без приоритета
3	По типу общения	Активное Пассивное
4	По типу сценария	С гибким сценарием С жестким сценарием
5	По форме общения	Директивы Запрос — ответ Шаблоны Подсказки Смешанные языки Меню
6	По типу сложности языка	Формализованные языки (с грамматикой, без грамматики) Естественные языки общения

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

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

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

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

е. проектированием на физическом уровне.

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

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

• ввод-вывод данных;
• ввод директив и их анализ;
• интерпретация директив.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологическая сеть проектирования диалоговых систем. Технологическая сеть проектирования диалоговых систем с языком общения типа «Меню» в случае выбора оригинального проектирования представлена на рис. 31, а ее компоненты представлено в табл.31 18.

1. Технологическая операция проектирования П.1 — «Разработка постановки задачи» осуществляется на базе документа «Техническое задание» на программирование задачи (Д.1.1) и материалов обследования (Д.1.2).

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

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

3. В результате выполнения технологической операции проектирования П.3 — «Выбор языка общения и разработка сценария» получают «Сценарий диалога» (Д.3.1).

На вход операции поступают универсум языков общения (U.3.1) и функциональная структура задачи (Д.2.1).

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

4. В результате выполнения технологической операции проектирования П.4 -«Разработка структуры программного обеспечения» получают дерево программных модулей (Д.4.1)

5. Технологическая операция проектирования П.5 -«Разработка информационного обеспечения» должна включать проектирование системы классификаторов и документов (Д.5.1), системы Экранных кадров (Д.5.2), и информационной базы (Д.5.3).

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

7. Технологическая операция проектирования П.7 — «Выбор ялгоязыка и разработка кодов программных модулей» осуществляется на основе универсума языков программирования (U.7.1), в результате чего получают документы с кодами программных модулей (Д.7.1).

Компоненты технологической сети проектирование диалоговых систем с языком общения типа «Меню»

Идентификатор	Наименованиекомпоненты
Д.1.1. Д.1.2. Д.1.3. Д.2.1. U.3.1. Д.4.1 Д.5.1. Д.5.2. Д.5.3. Д.6.1. U.7.1. Д.7.1. Д.8.1. Д.9.1. Д.9.2. Д.9.3. Д.10.1. Д.11.1. Д.12.1.	Техническое задание Материалы обследования Документ «Постановка задачи» Функциональная структура задачи Универсум языков общения Дерево программных модулей Классификаторы и документы Система экранных кадров Информационная база Укрупненный алгоритм решения задачи Универсум языков программирования Коды программных модулей Совокупность отлаженных модулей Исходные данные контрольного примера Комплекс отлаженных программных модулей Результаты реализации контрольного примера Совокупность программных документов Блок-схема технологическоого процесса Комплект технологической документации

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

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

10. В результате выполнения технологической операции проектирования П.10 -«Разработка программной документации» получают всю совокупность программных документов (Д.10.1).

11. В результате осуществления технологической операции проектирования П.11 — «Разработка блок-схемы технологического процесса» получают документ «Блок-схема технологического процесса» (Д.11.1), содержащий перечень ручных, машинно-ручных и автоматических операций, выполняемых в определенной последовательности пользователем при решении задачи.

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

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

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

Краткие выводы

технологический обработка экономический информация

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

2. Обычно решение экономических задач объединяется в рамках автоматизированных рабочих мест (АРМ), предназначенных для реализации какой-либо цели или функции управления.

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

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

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

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

Основные термины и определения

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

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

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

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