Понятие сценария диалога

Общие положения

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

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

• разделять решение задачи во времени;

• решать задачу по частям;

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

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

Пример сценария диалога

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

Экран 1 Задача «Расчет заработной платы»

Укажите номер расчетного месяца

Будете решать задачу в полном объеме?

Да

Нет

(ответ= «нет»)

Экран 2 Выберите группу подразделений для расчета Профессорско-преподавательский состав Хозяйственная часть Библиотека Вычислительный центр ....

Экран 3 Для каких кафедр выполнять расчет? 1. Для всех 2. Для отдельных

Экран 4 Выберите кафедру: Кафедра философии Кафедра финансов Кафедра социологии Кафедра экономической теории

Экран 5 Для всей кафедры выполнять расчет? 1. Для всей 2. Для отдельного преподавателя

Экран 6 Выберите преподавателя Андреев И.Д. Банников Л.О. … Савченко Т.Б. Синицин С.И.

Рисунок В22 – Фрагмент сценария диалога

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

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

Использование сценария диалога при просмотре и анализе результатов решения

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

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

Перечень обязательных выходных документов, отражающих результаты решения задачи <название задачи> Документ 1 Документ 2 … 4. Документ n

Рисунок В23 – Фрагмент перечня выходных документов по задаче

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

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

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

К исходным данным предъявляются следующие требования:

• небольшой объем, чтобы решение было как можно более быстрым;

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

• реальность, т.е. отражение фактической информации о той предметной области, для которой предназначена задача.

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

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

При выполнении соответствующей лабораторной работы по постановке задачи в контрольном примере должны привести:

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

• заполненные локальные классификаторы (если классификатор имеет небольшой объем, например, до 100 наименований), фрагмент классификатора (если классификатор содержит, например, более 100 наименований);

• все расчеты, сопровождающие решение;

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

• примеры использования запросной системы для ответа на нерегламентированные запросы (если запросная система в задаче используется).

Программное обеспечение задачи

Все предыдущее описание относилось к так называемому «домашинному» периоду решения задачи. Но задачей нельзя будет пользоваться, пока она не воплотится в конечный программный продукт. И здесь возможны три пути:

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

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

• проектирование специального программного обеспечения.

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

Третий же путь сопряжен с определенными трудностями:

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

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

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

• общие характеристики пакета программ;

• возможные режимы работы;

• подробная пошаговая инструкция по использованию;

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

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

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

Схемы взаимодействия участников решения задачи

В решении задачи принимают участие три типа специалистов:

• постановщик задачи;

• программист;

• пользователь готового программного продукта.

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

1 вариант

Пользователь делает описание постановки задачи



Передает описание задачи программисту



Программист создает программный продукт



Программный продукт передается пользователю

2 вариант

Пользо-ватель форми-рует свои требо-вания к задаче



Передает требова-ния постановщику задачи



Поста-новщик задачи делает ее описание



Передает описание задачи програм-мисту



Про-грам-мист создает прог-рам- мный продукт



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

3 вариант

Постановщик задачи делает ее описание



Передает описание задачи программисту



Программист создает программный продукт



Программный продукт передается пользователю

4 вариант

Постановщик задачи делает ее описание



Сам создает программный продукт



Программный продукт передается пользователю

5 вариант

Постановщик задачи делает ее описание



Сам создает программный продукт



Сам работает с готовой программой

Рисунок В24 – Схемы взаимодействия участников постановки задачи

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

• Функциональная спецификация (описание применения);

• Руководство пользователя (подробные инструкции по работе со всеми программами пакета);

• Руководство программиста.

Приложение Г

Пример выполнения технического проекта

УТВЕРЖДАЮ Директор «ИП Черных Ольга Владимировна» _______________ Черных О.В. ___ _______________ 2011 г. Печать

УТВЕРЖДАЮ студентка гр. АСУ-07-2 НИ ИрГТУ ______________ Черенкова Л.И. ___ _________________ 2011 г. Печать

НИ ИрГТУ, кафедра АС, студентка группы АСУ-07-2

^{наименование организации – разработчика ТП на АС}

Интернет-магазин

^{наименование вида АС}

Салон Магазин «Кофе Маг»

^{наименование объекта автоматизации}

АСУ «Кофе Маг»

^{сокращенное наименование АС}