- •Особенности структурного анализа и проектирования информационных систем
- •Введение
- •1. Построение моделей бизнес-процессов по стандарту idef0
- •1.1. Примитивы стандарта idef0
- •1.2. Виды ресурсов стандарта idef0 и их взаимосвязь
- •1.3. Особенности построения моделей по стандарту idef0
- •1.4. Пример декомпозиции процесса
- •1.5. Пример построения диаграмм idef0
- •1.7. Особенности создания диаграмм в программах bpWin и Ramus
- •1.6. Работа с тоннелями
- •1.8. Именование объектов в bpWin
- •1.9. Решение проблем с кодировкой и автоматической проверкой
- •1.10. Варианты заданий по построению моделей бизнес-процессов
- •1.11. Контрольные вопросы
- •1.12. Варианты тестовых заданий по контролю знаний в сфере построения моделей бизнес-процессов
- •2. Построение диаграмм потоков данных
- •2.1. Общие особенности методологии dfd
- •2.2. Внешние сущности
- •2.3. Системы и подсистемы
- •2.4. Процессы
- •2.5. Накопители данных
- •2.6. Потоки данных
- •2.7. Построение иерархии диаграмм потоков данных
- •2.8. Пример построения диаграммы потоков данных в программе bpwin
- •2.9. Особенности построения диаграмм dfd в программе Ramus
- •2.9.1. Создание новой диаграммы, работа с примитивами, классификаторами, особенности декомпозиции
- •2.9.2. Подробный пример построения диаграммы dfd
- •2.10. Варианты заданий по построению диаграмм потоков данных
- •2.11. Контрольные вопросы
- •2.12. Варианты тестовых заданий по контролю знаний в сфере построения диаграмм потоков данных
- •3. Проектирование реляционных баз данных посредством стандарта idef1x
- •3.1. Особенности построения структуры баз данных
- •3.2. Виды связей между таблицами
- •3.3. Особенности стандарта idef1x
- •3.4. Особенности построения схем idef1x в программе ErWin
- •3.4.1. Общие особенности программы ErWin
- •3.4.2. Работа с панелью инструментов и сущностями
- •3.4.3. Работа со связями между таблицами
- •3.5. Особенности построения схем idef1x в программе dbDesigner
- •3.5.1. Особенности работы с программой
- •3.5.2. Необходимые для работы кнопки панели инструментов
- •3.5.3. Настройка внешнего вида схем под стандарт idef1x
- •3.5.4. Работа с таблицами
- •3.5.5. Связи между таблицами
- •3.5.6. Удаление объектов схемы
- •3.5.7. Пример схемы idef1x в dbDesigner
- •3.6. Варианты заданий по построению схем реляционных баз данных
- •3.6. Контрольные вопросы
- •3.7. Варианты тестовых заданий по контролю знаний в сфере построения схем баз данных
- •4. Проектирование диалога с пользователем посредством транзитивных сетей
- •4.1. Проектирование диалога с пользователем
- •4.2. Простая транзитивная сеть
- •4.3. Рекурсивная транзитивная сеть
- •4.4. Подсеть, не связанная с рекурсией
- •4.5. Проектирование конкурентного диалога
- •4.6. Особенности построения транзитивных сетей в программе Dia
- •4.6.1. Подготовка новой панели под создание транзитивных сетей
- •4.6.2. Основные моменты построения транзитивных сетей в программе Dia
- •4.6.3. Пример построения транзитивной сети в программе Dia
- •4.7. Варианты заданий по построению логики диалога с пользователем
- •4.8. Контрольные вопросы
- •4.9. Варианты тестовых заданий по контролю знаний в сфере построения логики диалога пользователя с системой
- •Литература
- •Особенности структурного анализа и проектирования информационных систем
4. Проектирование диалога с пользователем посредством транзитивных сетей
4.1. Проектирование диалога с пользователем
В рамках проектирования пользовательского интерфейса разрабатывается логика диалога с пользователем, куда входит проектирование взаимосвязей форм приложения и взаимосвязей объектов внутри формы.
Пусть существуют 2 формы: одна просматривает данные из таблицы, а другая их редактирует. Если обе формы видимы, то необходимо следить, чтобы изменения во второй форме отражались в первой. Внутри каждой формы могут возникать свои взаимосвязи: объекты могут быть видимы или невидимы в зависимости от состояния других.
Отдельной задачей логики диалога может являться взаимный вызов форм. Часто решение подобных задач производится одновременно с написанием основного текста программы, при этом организация диалога с пользователем перемешивается с выполнением основного алгоритма, что делает текст трудночитаемым.
Если решать возникающие проблемы в процессе программирования, то возможно главные взаимосвязи в приложении выявляются после написания основных частей, и может потребоваться объемная переработка приложения. Целесообразно спроектировать диалог до начала программирования. Такой диалог проще анализировать и редактировать. При коллективной разработке программного средства проектирование диалога и его документирование становятся необходимыми для обеспечения взаимодействия между разработчиками.
Проектировать диалог можно с использованием двух видов нотаций:
текстовая (логика диалога описывается на специализированном языке);
графическая (логика диалога представлена в виде диаграмм).
Структура пользовательского интерфейса.
Рис. 4.1. Общая структура пользовательского интерфейса
При проектировании диалога определяется состояние системы – устойчивое положение системы, в котором пользователь может выполнять какие-либо действия. Некоторые действия могут повлечь изменение состояния системы. Для пользователя приложение – это формы с визуальными объектами. Он воздействует на форму, порождая события. Формы преобразуют события во входные сигналы для логики диалога. Не все события будут входными сигналами, а только те, которые повлекут изменения состояния системы.
При обработке входных сигналов в модуле логики диалога изменяется контекст – набор форм и визуальных объектов, доступных пользователю в данном состоянии системы. Изменение контекста отображается на экране.
Прикладной интерфейс – это специализированные программы для обращения к БД или алгоритмам обработки, не принадлежащие приложению. В качестве прикладного интерфейса может выступать BDE или ODBC. С ними модуль логики диалога общается через команды для БД: delete, insert, update, create, drop. В ответ на команду интерфейс может генерировать обратный сигнал – семантическую обратную связь. Он в свою очередь может изменить контекст системы. Формы и объекты могут взаимодействовать с интерфейсом, минуя модуль логики диалога, в том случае, если такое взаимодействие не изменяет состояние системы. Приложения Windows характеризуются тем, что одновременно на экране может быть несколько форм, при этом каждая форма имеет свой внутренний диалог. В этом случае диалог приложения называется конкурентным. В таких приложениях модуль логики диалога содержит диалоги всех форм, а также диалог, отвечающий за взаимодействие этих форм. Диалог формы может содержаться и внутри модуля формы.
