Средства разработки диалоговых систем

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

- описать подсистемы

- определить интерфейсы и согласовать с проблемными задачами и вычислительной средой

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

- выработать обобщённый взгляд на диалоговую систему в целом

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

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

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

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

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

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

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

Также широко применяют CASE-технологии.

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

Диаграмма прецедентов использования в ОО-проектировании ЭИС. Эти диаграммы выявляют основные бизнес-процессы как последовательности транзакцй.

Диаграммы взаимодействия объектов в ОО-проектировании описывают динамическое взаимодействие объектов в форме диаграммы последовательностей или в форме кооперативной диаграммы.

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

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

38Методология проектирования «сверху-вниз».

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

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (rapid application development – технологии быстрой разработки приложений, 1991). Согласно этой технологии ЭИ разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при прототипной технологии сокращается число итераций и меньше возникает ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование ЭИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ЭИС все большее значение придается ведению общесистемного репозитория и использованию CASE-технологий.

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

· анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;

· проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

· конструирование. Специалисты-разработчики проектируют рабочую версию ЭИС с использованием языков 4-го поколения;

· внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ЭИС.

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

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

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

Стр.192.

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

- разработка отдельных компонентов программы

- кодирование компонентов

- отладка и интеграция

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

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

- выполнеие кодирования с отладкой.

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