Мастер

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

Рис. 13~ 7 мтеры широко используются в Microsoft Access 2000

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

ботающих с базами данных.

Мастеры также полезны для поддержки сложных сов. Если рабочий процесс состоит из нескольких различных задач, выполняемых в определенном порядке, то структуру пользовательского интерфейса можно организовать в виде мастера. Мастеры незаменимы, если рабочие цесс состоит из множества условных задач, то есть задач, выполнение которых зависит от выполнения торого условия (например сли выполняется условие А, выполнить задачу 3, а затем задачу 4; если выполняется В, перейти к

выполнению задачи

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

ЧАСТЬ 3

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

Если мастер используется в приложении, работающем с базой данных, обратите особое внимание на то, как будут сохраняться введенные пользователями данные. В обычной модели при вводе данных пользователь в любой момент может отменить все выполненные из-..менения, например кнун кнопку Cancel: введенная ;1нфор.маиия

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

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

Не будет лишней возможность приостановить работу с мастером, чтобы продолжить ее Это практичное решение, однако реа-

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

Итоги

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

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

терфейс, использующий стиль Microsoft Outlook. Каждая имеет свои преимущества и недостатки при использовании в конкретных условиях. MDl-приложения более разнообразны: это и классические MDI-системы, и диалоговые панели управления, реализованные в мастере баз данных Access, и интерфейс в виде проекта, примером которого служит Visual Basic. И наконец, интерфейс, организованный в виде мастера чаще всего используется, чтобы облегчить пользователям выполнение задач.

В следующей главе мы рассмотрим внутреннюю структуру форм, определяемую структурой сущностей в модели данных.

Связь между

сущностями

и Формами системы

ГЛАВА

В предыдущих главах этого раздела мы свое

ние в основном на рабочих процессах, а данных оставалась за

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

данные отображать в каждой отдельной форме, зависит от структуры

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

этой форме.

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