ПРОЕКТИРОВАНИЕ ДИАЛОГА С ПОЛЬЗОВАТЕЛЕМ ПОСРЕДСТВОМ ТРАНЗИТИВНЫХ СЕТЕЙ

Проектирование диалога с пользователем

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

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

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

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

Проектировать диалог можно с использованием двух видов нотаций:

1. текстовая (логика диалога описывается на специализированном языке);

2. графическая (логика диалога представлена в виде диаграмм).

Структура пользовательского интерфейса.

Рис. 4.1. Общая структура пользовательского интерфейса

 

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

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

Прикладной интерфейс – это специализированные программы для обращения к БД или алгоритмам обработки, не принадлежащие приложению. В качестве прикладного интерфейса может выступать BDE или ODBC. С ними модуль логики диалога общается через команды для БД: delete, insert, update, create, drop. В ответ на команду интерфейс может генерировать обратный сигнал – семантическую обратную связь. Он в свою очередь может изменить контекст системы. Формы и объекты могут взаимодействовать с интерфейсом, минуя модуль логики диалога, в том случае, если такое взаимодействие не изменяет состояние системы. Приложения Windows характеризуются тем, что одновременно на экране может быть несколько форм, при этом каждая форма имеет свой внутренний диалог. В этом случае диалог приложения называется конкурентным. В таких приложениях модуль логики диалога содержит диалоги всех форм, а также диалог, отвечающий за взаимодействие этих форм. Диалог формы может содержаться и внутри модуля формы.

Простая транзитивная сеть

Одним из наиболее простых способов отражения логики диалога является простая транзитивная сеть (STN – State Transition Network). Это графический способ представления диалога.

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

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

Edit1 Имя таблицы

DBGrid1 Содержимое таблицы

ListBox1 Рабочий список

ОК

Далее

Memo1 Текст запроса

Edit2 Значения

ListBox2 Список операторов математических и логических

Рис. 4.2. Макет формы

 

Форма имеет 2 режима работы:

1. Режим таблицы (Первый пункт меню). В Edit1 вводится имя таблицы, а при нажатии «ОК» происходит попытка связи с БД. Если попытка успешна, то данные можно редактировать в объекте DBGrid1.

2. Режим запроса. При помощи двух TEdit и двух TListBox формируется текст запроса при этом Edit1 для ввода имени таблицы доступен только вначале. После нажатия «Далее» пользователь работает со списком ListBox1, показывающим поля таблицы. По двойному щелчку добавляются поля из списка в раздел select запроса (Memo1). Для начала формирования раздела where повторно нажимается кнопка «Далее». После нажатия «Далее» поля из ListBox1 добавляются уже в раздел where для первого условия. Математические операции сравнения берутся из ListBox2, значения, с которыми сравниваются поля – из Edit2. После выбора поля для условия нажимается «Далее», выбирается операция для условия, после следующего нажатия «Далее» - параметр сравнения с полем. Все это переносится в Memo1, причем после этого можно сформировать другие условия (ListBox2 содержит пункты and и or). Далее схема повторяется. После нажатия «ОК» выполняется запрос, и его результат можно просмотреть в DBGrid1. Основная проблема: какие объекты доступны в тот или иной момент времени, и какие действия может выполнить пользователь.

На рисунке 4.3. представлен граф переходов:

Рис. 4.3. Описание логики диалога с пользователем

 

Входное состояние на диаграмме напрямую не отображается. На графе существует переход «извне» в первое состояние. Состояние finish необходимо для указания точки выхода из приложения. Такие вершины содержатся в графе логики диалога всегда независимо от количества и смысла других состояний.

Достоинства простой транзитивной сети:

1. точное формальное описание диалога;

2. диалог реализуется в простой табличной форме;

3. реализация диалога легко редактируется и дополняется.

Недостатки простой транзитивной сети:

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

Рис. 4.4. Пример графа

 

Рис. 4.5. Пример графа

 

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

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

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: