WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |

«Press Riordan DESIGNING Relational Database Systems Press Ребекка Райордан реляционных баз данных Москва 2001 Р УДК 004 32.973.26-018.2 Р45 Р. ...»

-- [ Страница 4 ] --

Двухуровневые, или клиент-серверные, приложения можно реа лизовать на основе SQL Server. Для этой архитектуры характерно рас пределение операций по обработке и поддержке данных между кли ентской рабочей и сервером. Сервер выполняет операции манипулирования с данными, а клиентский компьютер — все опера ции взаимодействия с пользователем. Принципы, положенные в ос нову двухуровневой архитектуры, можно развить, увеличивая число уровней и, соответственно, число компьютеров, на которых разме шаются компоненты этих уровней.

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

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

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

Сотрудничество при проектировании ГЛАВА Если вы создаете систему, чтобы с ней работали другие люди, вам придется с ними во время разработки. Заметьте: я сказала а не «писать для них документацию». Ни один документ не стоит и ломаного гроша, если его невозможно понять. Вы же не учите иностранный язык, читая Точно так же нельзя понять суть проекта, ознакомившись лишь с описанием структуры таблиц.

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

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

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

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

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

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

• Отдельные технические спецификации для компонента бу дут использовать разработчики.

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

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

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

Скорее всего, первый раздел вашего документа — введение.

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

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

Какие проблемы должна разрешить создаваемая система?

• Является ли выбранное решение оптимальным с точки зрения со отношения «цена — качество»?

• Какие альтернативные варианты рассматривались?

• Каков планируемый срок выполнения проекта?

ГЛАВА • Сколько будет стоить система?

• Как оценить риски для данного проекта?

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

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

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

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

Я также рекомендую честно отвечать на вопрос о рисках.

те, какие опасности могут грозить вам в процессе работы над проек том: технические проблемы, срыв сроков? В каком случае такая опас ность Почему? Не бойтесь, что вас сочтут параноиком, луч ше А теперь спуститесь на грешную землю. Так ли уж велика вероят ность, что то иди иное досадное событие действительно случится и приведет к задержке или невозможности выполнять работу? Конеч ЧАСТЬ но, никто не может дать гарантии, что проектная группа не умрет в результате эпидемии какой-либо опасной болезни или что на ваш офис не обрушится «Боинг». Но вероятность таких событий ничтожно мала. Разумеется, кое-что в проекте будет иногда идти не так, и вас обязательно есть ли у вас на этот случай план действий. Не нужно красочно расписывать все возможные не приятности, но очень важно заранее оповестить руководство о воз можных проблемах.

Если вы — консультант, не пытайтесь обойти молча нием вопрос о своей компетентности. Конечно, первое, о чем спра шивают человека, нанимая на работу — сможет ли он ее выполнить.

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

Обзор системы Этот раздел обязательно должен быть первым в документе.

С ним должны ознакомиться все — и разработчики, и клиенты.

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

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

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

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

Если вы провели анализ «цена — включите в документ его результаты (не обязательно в раздел Я стара юсь не перегружать основной документ множеством Помес тите все подробности в приложения к документу — его станет значи тельно приятнее читать. Но конечно, вопрос вкуса.

То же самое можно сказать о целях документа и его объеме. Если вы подготовите подробный анализ функций системы, свяжете их с целями проекта и расположите эту информацию в порядке убывания ГЛАВА приоритетов это поможет вам в реализации. Но тите, что таблицу, более почти никто не нет Рабочие процессы Способ описания рабочих процессов зависит от того, каким образом вы их исследовали. Если вы строили диаграммы рабочих процессов, включите их в документ. Объясните значения символов, которые пользуете. В любом случае, расскажите, что вы подразумеваете под терминами «процесс», «задача», «деятельность» или любыми другими.

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

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

Описание рабочих процессов — потенциальное поле битвы личных групп читателей вашего документа. Разработчики при обсуж дении рабочих процессов будут оперировать техническими термина ми, вроде: «транзакции были завершены, и данные С другой стороны, заказчики хотят увидеть описание процесса в при вычных им терминах. Эти термины порой совпадают с технически ми, а порой — сильно отличаются от них. Когда такая ситуация воз никает, то правда всегда на стороне заказчика. Разработчики могут принять терминологию клиента, но не наоборот. Если в документе приходится использовать чисто технические термины, обязательно приведите тут же их подробное разъяснение.

К сожалению, это легче сказать, чем сделать. Когда все время име ешь дело с компьютерными системами, легко что многие из часто используемых тобой терминов не являются ными. Я веду специальный список терминов типа «транзакция» или даже «файл» и окончательный вариант документа на предмет наличия таких терминов перед отправкой его заказчику. Это довольно легко сделать с команды Find текстового ЧАСТЬ 2 баз сора. Помните: если клиенту будет хоть что-нибудь непонятно, то скорее всего, ваш документ у него лишь раздражение.

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

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

Во-первых, используйте минимум технической терминологии.

«Таблица», «поле» и «запись» — неизбежное зло. А тер минов «отношение» и «атрибут» лучше избегать, хотя, они более точны с технической точки зрения. Убедитесь, что объяснили значение технических терминов (только не пытайтесь прочесть краткий курс по базам Не так уж это и сложно:

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

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

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

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

ГЛАВА Схема базы данных представляет интерес для разработчиков, о ней совершенно незачем знать заказчику. Если вы не описываете схему базы данных в отдельном документе, поместите ее в раздел приложе ний к основному тексту, А вот саму архитектуру системы и концеп цию безопасности заказчик обязательно должен одобрить. Чтобы луч ше донести до него эту информацию, используйте диаграммы и тек стовое описание архитектуры — эти два способа представления ин формации дополняют друг друга. Концепцию безопасности лучше описать в виде текста, но иногда рисунки и графики более наглядны, особенно система достаточно сложна.

Интерфейс пользователя Лучше всего заранее обсудить с заказчиком, как должен выглядеть ин терфейс пользователя (хотя для небольших систем это Даже если вы не собираетесь разрабатывать интерфейс отдельно от остальной части проекта, неплохо все же показать заказчику сколько примеров пользовательских форм, назвав их Такие примеры помогут ему лучше представить себе внешний вид Но начеку: после этого от вас будут ожидать именно таких экранных форм в конце разработки (неважно, что вы все время твердили заказчику: то, что он видел — только примеры). Если конеч ный вид системы будет сильно отличаться от показанных пользовате лю все ваши благие намерения обернутся против вас.

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

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

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

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

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

Очень трудно не поддаться соблазну и не использовать в качестве скелета системы. В конце концов, если все меню и ные формы уже не переписывать же их заново? Но экран ные формы и меню в прототипе не более чем примеры. Если вы буде те использовать прототип как основу системы, то столкнетесь с теми ограничениями инструментальных которые благополучно обошли, создавая примитивное Поэтому многие архитекторы рекомендуют эк ранных форм с дизайнерских систем, а не средств разра ботки типа Microsoft Access или Visual Basic. Используйте наиболее удобное для вас. Для меня таковыми являются тальные средства разработки. Вы можете применить дизайнерские си стемы или даже системы создания презентаций наподобие Microsoft PowerPoint. Просто помните о том, что создаете не саму систему, а пример, демонстрирующий ее внешний вид.

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

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

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

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

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

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

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

Но в большинстве случаев способ контроля не столь важен, сколь сам его факт.

Специальные средства Работать над вам помогут два средства;

Microsoft Visual SourceSafe и Microsoft Visual Component Manager. Visual SourceSafe со здавался прежде всего как средство контроля за изменениями исход ЧАСТЬ 2 баз ного кода программ, но его можно использовать и для контроля за версиями проектной документации.

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

Visual Component Manager — клиентская часть Microsoft Repository.

Он тесно связан с Enterprise Edition Microsoft Visual Studio и предназ начен для администрирования документации и компонентов, откры тых для общего пользования (а не для помоши в процессе разработ ки). Visual Component Manager позволяет создавать индивидуальные хранилища информации для каждого участника проекта. Это очень удобно, чтобы связать несколько документов на различных пользова тельских компьютерах в одно целое.

Если проект разрабатывается с Visual Studio, та же са мая база данных может быть использована для контроля за версиями разрабатываемых компонентов. К сожалению Visual Component Ma nager не интегрирован с Microsoft Access, хотя теоретически можно ввести в Repository такие возможности.

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

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

ЧАСТЬ Проектирование пользовательского интерфейса Интерфейс как посредник между пользователем и системой ГЛАВА По завершении стадии системного анализа, о которой шла речь в предыдущей части этой книги, у вас должно сложиться четкое пред ставление о том, какие должна выполнять разрабатываемая система. Третья часть книги посвящена вопросам разработки пользо вательского интерфейса.

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

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

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

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

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

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

Итак, каковы же основные критерии, позволяющие отличить хо рошо спроектированный интерфейс от плохо спроектированного? Я считаю, что хороший интерфейс прежде всего эффективно помогает пользователям решать перед ними задачи, не создавая до полнительных трудностей в работе. Такой интерфейс не навязывает пользователям свои собственные «правила совсем напротив — он настолько органично вписывается в рабочий процесс, что почти ЧАСТЬ не заметен. Он прост и удобен;

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

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

Модели интерфейса В книге «About Face: The of User Interface Design» системы: основные принципы разработки пользовательского интер фейса») Алан Купер (Alan Cooper) выделил три аспекта восприятия пользователями различных компьютерных систем (и наоборот, реа лизации определенного подхода компьютерных систем к пользоваге Это ментальная модель, декларируемая модель и модель реали зации. Все они — мощные инструменты для разработки пользовательского интерфейса приложения.

Ментальная модель (mental model) описывает представление пользо вателя о том, что происходит в системе. Как правило, представления пользователей основаны на упрошенных схемах и не совсем точных аналогиях, тем не менее, пользователь имеет вполне адекватное ставление о системе. (Все это не влияет на сам процесс проек тирования интерфейса.) Например, с точки зрения пользователя текстового процессора, работающего с различными документами, нажатие на клавишу кла виатуры приводит к появлению символа на экране монитора — это ментальная модель. На самом деле в системе происходят значительно более сложные процессы, но они выполняются независимо от пользо вателя и потому не относятся к ментальной модели.

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

Пользовательский интерфейс представляет собой декларируемую модель model), которая находится между ментальной лью пользователя и моделью реализации, создаваемой и мой разработчиками. Это модель процесса, которую система ставляет (декларирует) пользователю. При проектировании интер фейса разработчика — сделать незаметными для пользователя как можно больше элементов модели реализации. В идеальном слу ГЛАВА 12 между к чае модель реализации полностью изолирована от пользователя, и поэтому идеальная система практически полностью соответствует ментальной модели. Конечно, на практике редко удается добиться полного соответствия между поведением системы и ментальной мо делью, но следует к этому стремиться.

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

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

Наилучший вариант — формальное тестирование прототипа сис темы на удобство пользовательского интерфейса. К этот подход редко используется на практике, но мой опыт показывает, что подобные эксперименты оправданы. Создав прототип пре доставьте пользователям возможность поработать с ним некоторое время. Затем попросите их рассказать, что, по их мнению, происхо дит, когда они выполняют те или иные действия. Ручаюсь, их ответы будут сильно отличаться от того, что вы ожидали услышать. В отсут ствие прототипа системы вы можете, расспросить пользо вателей, как они представляют себе работу с системой. Или нарисуй те основные элементы пользовательского интерфейса на бумаге и попросите пользователя их прокомментировать. Эти методы хоть и не столь результативны, как работа с прототипом, но все же полезны.

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

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

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

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

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

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

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

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

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

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

Назначьте для каждой команды или другого элемента определенное ЧАСТЬ сочетание клавиш». Предоставьте пользователям возмож ность переопределять стандартные сочетания клавиш. Пользователи эксперты очень любят эти средства, и вам следует обеспечить им мак симально быстрые и рациональные способы выполнения тех или иных действий.

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

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

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

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

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

К этой проблеме мы еще вернемся в главе 16, где будем обсуждать вопросы целостности данных. Искусственное усиление целостности данных — основной способ, с помощью которого СУБД ограничива ют свободу пользователей. Второй способ — использовать режимы (modes), то есть состояния системы, одна из функций которых — ог раничивать взаимодействие с ней пользователей. Стандартные режи мы для систем баз данных — добавление, изменение и просмотр. Од нако система, в которой пользователь должен выбрать одну из команд меню или щелкнуть кнопку, прежде чем сможет изменить запись, которую только что просмотрел, крайне неэффективна.

К сожалению, многие разработчики выбирают именно такой путь — очевидно, за незнанием лучшего способа предотвратить порчу дан ных вследствие ошибки или невнимательности пользователя. Лично я вижу здесь слепое копирование традиционной модели интерфейса, использовавшейся 20 лет назад, с ее непременными атрибутами командами Add, Edit и View в главном меню. Эту парадигму некото рые разработчики пытаются перенести в среду где она со вершенно неуместна. Чтобы избежать подобных ошибок, рекомендую избавиться от идеи излишней опеки над пользователями. Если пользо ватель выполняет какие-либо действия — значит, он знает, что дела ет. Если пользователь хочет изменить запись, он должен иметь воз можность сделать это, не спрашивая ни у кого позволения.

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

Достичь этой цели помогут команды отмены и повтора нескольких действий, легко реализуемые средствами Microsoft Access и Microsoft Visual Basic. Кроме этого, включите в меню команду, по вернуться к последней сохраненной версии, отменив все изменения, сделанные в текущей записи.

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

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

Многие щелкают всякий раз, когда видят это окно, просто по привычке.

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

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

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

ну Рис. 12-1. «В результате изменений может нарушиться ссылочная — пример неинформативного сообщения ГЛАВА 12 между Сообщение на рис. составлено значительно лучше. Оно не только дает объяснение тому, что произошло, на понятном пользова телю языке, но и предоставляет возможность предпринять определен ным образом спланированные действия вместо стандартного выбора между кнопками и Cancel.

Changed Такое сообщение объясняет пользователю и спланировать свои Не перегружайте память пользователя!

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

Нагрузка на память пользователя снизится, если вы будете соблю дать стандарты разработки интерфейса приложений для Windows, со держащиеся в руководстве «Windows Interface Guidelines Software Design» по разработке интерфейса приложений для Вам вряд ли часто отступать от них.

Microsoft Office (в частности, Access) де-факто определяют и исполь зуют другие стандарты. Но прежде чем изменять стан дарты, убедитесь в наличии для этого серьезных оснований. Иначе вы;

вероятнее всего, окажете пользователям медвежью услугу.

Пользу стандартных решений можно проиллюстрировать следую щим примером. Предположим, вы разрабатываете систему для пользо вателей, привыкших работать с приложениями Microsoft Office, и в частности, с Access. При этом интерфейс Access кажется вам, ЧАСТЬ в ногу со временем, весьма бесцветным и не бога тым графическими элементами. И вот вы решаете подобрать соб ственную коллекцию пиктограмм для кнопок управления. Но придут ли пользователи в восторг от такой красоты? Ведь они уже привыкли к тому, что при нажатии кнопки Access выполняет пе реход к записи в таблице. А теперь им придется запоми нать, что для выполнения аналогичного действия в разработанной вами системе нужно щелкнуть кнопку, на которой красуется фото графия вашей любимой собаки или загадочный символ, позаимство ванный из абстрактной живописи.

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

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

Чтобы уменьшить на пользователя, исключите когда от него будет требоваться повторный ввод данных. Здесь часто помогают значения по умолчанию. Если пользователи будут вводить информацию, используя несколько последовательно открывающих ся и связанных друг с другом форм, позаботьтесь, чтобы все связан ные Друг с другом данные автоматически переносились из одной фор мы в Избегайте ввода данных вручную, пусть пользователь, везде, где это имеет смысл, выбирает их из списка. Например, чтобы получить сведения о покупателе Джоне Ду (John Doe), пользователь не должен ломать голову над тем, как именно в базу данных были введены эти имя и фамилия — John Doe, J. Doe или Doe. Но обратите внима ние: я сказала «там, где это имеет смысл». Вряд ли разумно застав лять пользователя ждать, пока система создаст список из 65 тыс. за писей, и выведет его на экран. Очевидно, в подобном случае пользо ватель должен иметь возможность отфильтровать список и из огра ниченного набора значений выбрать нужное.

Чтобы списки были содержательными, включите в них как можно больше дополнительной информации. Пользователи вашей системы не обязаны помнить, например, что Джон Смит (John Smith) — это клиент их живущий в Мадриде, а Джонни Смит (Johnny Smith) — покупатель из Милана. Стандартные элементы управления Microsoft Access — списки и комбинированные окна, позволяют ото ГЛАВА 12 как содержимое нескольких полей. В Visual Basic можно исполь зовать конкатенацию хранящихся в соответствующих полях.

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

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

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

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

Следует ли использовать эти сокращения в разрабатываемой вами системе — однозначного ответа нет. Лично я принимаю решение на основании одного простого правила: если сотрудники часто исполь зуют эти сокращения не только в но и в разговорах друг с другом, я использую эти сокращения в системе. Если пользователи думают и говорят «восточный регион», требование вводить ние создает дополнительные трудности. Но даже если я исполь зую принятые в организации сокращения, то не ограничиваю мно жество допустимых значений только ими, а оставляю пользователям возможность ввести в соответствующее поле и значение регион», и сокращение Будьте последовательны!

Под термином «последовательный интерфейс» мы будем понимать нечто большее, чем правильное размещение команд меню File и Edit, Последовательным должно быть также и поведение системы, и ее вза имодействие с пользователями. Обратите особое внимание на следую ЧАСТЬ шие моменты: как выполняется переход от одной записи к другой, как представлены составные сущности и как пользователи редактируют и добавляют записи в базу данных.

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

По умолчанию в формах Access и Visual Basic ется первая запись из нижележащего набора. Форма также содержит кнопки, позволяющие перемещаться от одной записи набора к дру Однако по разным причинам вам может понадобиться ся от этих стандартных свойств интерфейса. Например, чтобы в фор ме отображалась всего одна и были предусмотрены механиз мы, позволяющие выбрать записи, которые следует отобразить. Та ким механизмом может быть отдельная форма для поиска записи или комбинированное окно, выбрать нужную запись. На рис. показан пример, заимствованный из стандартной базы дан ных Access Developer Solutions и иллюстрирующий этот подход. В нем возможность выбрать нужную запись реализована при ком бинированного окна Edit Products.

Г Рис. 12-3. Пользователи могут выбрать о клиенте Итак, ваше решение отказаться от стандартного механизма пере мещения между записями вполне оправдано. Но, сделав однажды ГЛАВА 12 как и выбор, вы должны его и использовать тот же самый механизм во всех формах системы. Согласитесь, неудобно работать с системой, где перемещение между записями в форме Customers (По купатели) реализовано при помоши стандартных кнопок;

в форме Sales Order для выбора нужной записи требуется щелкнуть кнопку Find Order (Найти а в форме Products (Товары) — дан ные представлены в табличном виде.

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

Другая область, где также нужна последовательность — представ ление составных сущностей. Если в вашей модели некие сущности представлены несколькими таблицами, участвующими в связи ко многим» (классический пример — сущность Sales Order), то вы должны соблюдать определенные правила относительно того, как эти сущности будут отображаться пользователям. Когда те элементы бланка заказа, которые, будучи напечатанными на «превра щаются» в строки, представлены в виде табличном виде, а адрес и телефон в виде списка — это непоследовательно.

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

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

В некоторых случаях совершенно оправдана блокировка сохранен ных записей — то есть механизм, запрещающий непосредственное редактирование таких записей. Например, блокировку записей при ЧАСТЬ 3 Проектирование пользовательского меняют, если нужно, чтобы данные в форме заказа клиента можно было изменять только до тех пор, пока заказанный товар не будет отправлен покупателю. Затем заказ изменяет свой статус и становит ся архивным документом, не изменению;

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

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

Этот способ, хотя не столь прост в реализации, весьма эффективен.

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

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

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

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

Заключительная часть главы была посвящена принципам, лежа щим в основе проектирования пользовательского интерфейса: ответ ственности пользователя за его действия, уменьшение объема инфор мации, которую пользователь должен запоминать;

согласованность интерфейса.

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

Архитектура пользовательского интерфейса ГЛАВА При проектировании пользовательского интерфейса следует в самом начале принять решение об общей структуре интерфейса системы — другими словами, об архитектуре пользовательского интерфейса. В этой главе мы рассмотрим несколько стандартных полное описание которых содержится в руководстве Windows Interface Guidelines for Software Design» («Руководство по разработке интерфей са для Все эти варианты стандартных архи тектур реализованы в распространенных программных продуктах.

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

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

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

ЧАСТЬ 3 интерфейса Затем создается форма Orders (Заказы), данные из таб Customers, доступной из этой формы только для чтения. Чтобы сделать систему «дружественной разработчики предо ставляют пользователю возможность выбрать фамилию покупателя из списка. Затем пользователь должен ввести информацию в остальные поля формы, основываясь на данных таблицы Customers. To что полу чается, напоминает форму из базы данных (рис. 13-1).

Рис. 13-1. Форма Orders из базы данных Northwind Эта форма сама по себе не плоха и не хороша, но с точки зрения поддержки рабочих процессов она не оптимальна. Подумайте о гом, что делает пользователь, который в бланк зака за. Он открывает форму Orders, только чтобы убедиться, что покупа тель, информацию о котором он будет вводить, не зарегистриро ван в системе. Затем ему нужно закрыть эту чтобы открыть какую-то другую и ввести данные о новом покупателе, и только по том он сможет ввести информацию о заказе. Если форма Orders еще не закрыта, пользователю понадобится обновить список Customers (Покупатели), нажав клавиши (или какое-либо другое соче тание), чтобы в этом списке отображались данные о новом покупате ле. Неудобно.

Некоторые разработчики решают эту проблему, включив событие (покупатель отсутствует списке) или создав комбинированное окно, позволяющее ввести имя нового покупателя. При возникновении со бытия пользователю выдается запрос — следует ли ввести информацию о новом пользователе. Если пользователь подтверждает это, открывается форма Customers.

Такое решение проблемы более рационально — пользователю приходится выполнять гораздо меньше разнообразных действий, чем в первом случае. Однако оно все еще не оптимально: пользователь ГЛАВА 13 интерфейса вынужден прерывать выполнение одной данных о заказе) и выполнять другие (обновление списка покупате лей). Значительно лучше позволить пользователю сначала завершить выполнение одной а потом уже к Напри мер, так: если введет имя покупателя, отсутствующее в списке, все поля формы остаются незаполненными;

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

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

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

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

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

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

и многодокументный интерфейс две разновидности архитектуры пользовательского интер фейса — интерфейс (single document interface, когда пользователь работает только с одним окном, содержащим от дельный документ, и многодокументный интерфейс (multiple document interface, MDI), когда пользователь может открыть одновременно не сколько документов в отдельных окнах главного окна приложения.

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

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

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

Архитектура SDI обладает рядом преимуществ. С одним окном пользователям легче работать. Такая архитектура соответствует стан дартному подходу к разработке интерфейса, реализованному в масте рах создания пользовательских документов, широко используемых ГЛАВА Системы SDI очень просто реализовать при помощи Microsoft Visual Basic. С помощью Microsoft Access сделать это не удастся, по скольку все формы содержатся в главном окне Access. Однако можно имитировать архитектуру SDI в приложении, созданном при помощи Access, развернув главную форму системы, открываемую при запуске приложения, во весь экран рабочей станции пользователя, и убрав с панели окна кнопки, позволяющие изменять размер формы на экра не. Access 2000 также позволяет разместить значок окна этой формы на панели задач. Итак, если использовать некоторые особые приемы, система, созданная с помощью Access, может вести себя как прило жение, использующее архитектуру SDI.

Рабочая книга Рабочая книга — это одна из разновидностей архитектуры SDI, где различные представления данных отображаются не в разных окнах, а на разных вкладках одного окна. Типичный пример приложения с такой архитектурой — Microsoft Excel.

Явное архитектуры SDI — она предоставляет пользо вателям вполне надежную рабочую среду, не ограничивая их рамками одной формы. Но реализовать такую систему, обеспечив приемлемое время отклика, часто не так просто. И все же рабочая книга — очень удобный способ отображать различные представления объекта или набора тесно связанных между собой объектов, если не нужно срав нивать эти объекты между собой.

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

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

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

использующий стиль приложения Microsoft Outlook одна разновидность архитектуры пользовательского интерфей са это особый стиль, который я называю «интерфейс, использую щий стиль Outlook», в честь первого приложения, где я увидела по добную Ее характерная особенность — окно приложе ния делится на две области, на одной из которых в определенном порядке расположены значки, а на — документы (рис. 13-2), '• г 6 '- •.

В 11 14 1В тэга г\ S Т Т I Т г 1.

Э 4 Б 6 7 в 7 8 9 12 1.) 2S • 1 -•--• Б 7 В Ч 14 IK II 16 19 Рис. 13-2. стиль разделяет окно приложения на две рабочие области Интерфейс, реализованный в стиле Microsoft Outlook, удобен для приложений, поддерживающих несколько рабочих процессов. Левая ГЛАВА область окна, где размещены значки, обеспечивает прямой доступ пользователей к соответствующим рабочим областям. Эти значки можно сгруппировать по различным функциям, разместив в рабочей области несколько панелей, на каждой из которых расположена от дельная группа значков.

К сожалению, ни Access, ни Visual Basic не предоставляют встро енных элементов управления для реализации такого интерфейса, хотя именно эта архитектура использована в Microsoft Access 2000 при ре главного диалогового окна Database, предоставляющего пользователю доступ ко всем объектам баз данных (рис. 13-3). Одна ко многие компании, разработкой коммерческого программного обеспечения, предоставляют широкий набор компо нентов ActiveX, использующих этот тип архитектуры. Эти компонен ты легко интегрируются в среду разрабатываемого приложения.

form by Orders Product Dialog Products Orders Quarterly Orders Customer quarterly Orders Phone by Dialog Reports Dialog :.

Employees (page break) Suppliers.

13-3. В Microsoft Access 2000 главное окно Database стиль Outlook Если вы используете этот стиль интерфейса, разумно дать пользо вателям возможность скрыть ту область в которой размещают ся как это сделано в Outlook. Эта область предоставляет удоб ные средства навигации, однако после того как нужный документ найден и открыт, инструменты навигации не нужны и только зани мают место на экране.

архитектура Большинство систем баз данных используют различные разновидно сти многодокументной архитектуры интерфейса.

позволяет открывать несколько дочерних окон из главного окна при ложения.

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

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

архитектура MDI Классическая структура — это основное окно, из которого открываются или разные дочерние окна. Стан дартный пример такой архитектуры — Microsoft Word, в окне этого приложения может быть открыто одновременно несколько докумен тов. Число открытых в дочернем окне, ограничивается только объемом оперативной памяти компьютера.

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

В Word имеется специальная команда, выполняемая из команд ной строки — /п. Она позволяет включить или отключить режим от крытия нового окна документа при запуске приложения. Вы можете предусмотреть аналогичную команду в своем пусть, например, пользователи с ее открывают форму Orders (Заказы) и вводят данные.

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

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

С точки зрения графической среды, главное окно приложения содер жит все дочерние окна, открываемые из него;

но далеко не всегда объекты, отображаемые в дочерних окнах, принадлежат этому же при ложению. Так, например, документы Microsoft Word — это отдель ные объекты файловой системы. Зачастую подобная непоследователь ность серьезно затрудняет реализацию системы, а пользователей при водит в замешательство. В системах, базы данных, клиентские приложения, как правило, изолированы от сложностей, связанных с архитектурой СУБД. Но даже в самых простых приложе ниях, работающих с базами данных, далеко не всегда удается полно стью решить все эти проблемы.

Вот пример такой системы: пользователь открыл несколько окон и переходит от одного к другому, причем в каждом из этих окон вы полняет какие-то изменения, не сохраняя их (рис. 13-4).

Рис. 13-4. Модель внутренней структуры главное и окна Что произойдет, когда пользователь выберет в меню File (Файл) команду Save (Сохранить)? Будут сохранены только изменения, сде ланные в окне Suppliers (Поставщики). Для вас это очевидно, посколь ку вы знаете, что команды меню выполняются только для окна, кото рое активно в данный момент. Но известно ли это всем пользовате лям? пользователи не работавшие ранее с Access, могут вполне логично предположить, что если команда выпол няется в приложении то будут сохранены все изменения в базе данных независимо от того, в каком окне они были выполнены.

Простой выход из этой ситуации предлагает руководство Windows Interface Guidelines for Software Design». В меню File можно ввести дополнительную команду Save All (Сохранить все) для сохра нения всех во всех открытых окнах прило жения. Разумеется, это разумное решение, но и оно — всего лишь компромисс. От пользователя такой системы все равно требу ется четко понимать разницу между и объектами, над которыми оно выполняет различные действия.

Это один из нюансов модели реализации, а не ментальной модели пользователя. И он, как правило, вызывает у пользователей большие затруднения. Даже весьма искушенные могут перепутать, забыть или просто не знать, где что хранится в этом приложении. Лично я до сих пор путаю, какие параметры форматирования хранится в списке сти лей в Word, а какие — в самом документе, хотя уже не один год рабо таю с этим приложением.

Но несмотря на все это, «классические» широ ко распространены. Они были и остаются наиболее удобными, если необходимо открывать одновременно несколько окон.

Диалоговая управления Интерфейс многих приложений разрабатывается в стиле диалоговой панели управления. При запуске такого приложения открывается ос новная форма (рис. 13-5). Большинство ее кнопок предназначены вызова различных форм или создания отчетов.

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

Должна признаться, что я несколько предубеждена против данно го решения. Мне все это напоминает неуклюжие программы, напи санные для DOS: возрождается старая концепция структуры команд меню Поиск записи/Редактирование которая только утомляет и раздражает пользователей.

Main i : ', Puc. запуске приложения на экране появляется диалоговая управления Использование интерфейса в виде диалоговой панели однако, вполне оправдано там, где одно приложение несколько различных рабочих и вы не хотите тратить вре мя и силы на разработку интерфейса в стиле Outlook. Оно также по лезно, если нужна возможность открывать одновременно несколько окон. Диалоговая панель верхнего уровня, на которой размешены кнопки, соответствующие рабочим позволяет быстро с приложением.

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

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

Visual Basic — типичный пример этой разновидности интерфейса (рис.

ЧАСТЬ Рис. 13-6. Visual Basic в SD1 — это интерфейс, организованный в виде проекта Открытые окна проекта отображаются на панели задач.

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

Хотя интерфейс, в виде проекта, лишен недостат ков классической модели MDI, в нем существует другое противоре чие — связь между окном проекта и относительно независимыми ок нами, управляемыми из него.

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

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

Если для реализации приложения вы выбрали архитектуру проекта, рекомендую использовать модель окна в Access. Она сочетает легкость которую предоставляет пользователям окно проекта, и отсутствие неудобств, возникающих вследствие связей между основным окном приложения и окном, с которым работает пользователь. Ведь окно Database — часть прило жения с классической ГЛАВА Мастер Мастер — это еше одна разновидность архитектуры интерфейса, ши роко применяемая в приложениях, работающих с базами данных. Как правило, мастер состоит из последовательности диалоговых окон, открываемых в определенном порядке (рис. 13-7).

!' ' • I 13~ 7. широко используются в Microsoft Access Чаше всего мастер используют, чтобы облегчить пользователям выполнение повторяющихся задач — например, при установке и кон фигурировании новых устройств в системе. Но, конечно, их можно и для поддержки рабочих в приложениях, ра ботающих с базами данных.

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

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

Если же порядок выполнения задач не имеет значения, организация пользовательского интерфейса в виде мастера — не самое лучшее ре ЧАСТЬ шение. По крайней мере, предусмотрите альтернативный способ вы полнения этой задачи.

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

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

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

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

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

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

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

Прежде всего, следует определиться, каким образом отразить в форме модель «сущности — связи». Будет ли в ней одна сущность;

или две, между которыми существует связь «один к или две, между которыми существует связь «один ко многим»;

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

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

Сущность Customers (Покупатели), показанная на рис. нахо дится на стороне «многие» всех изображенных на диаграмме связей, за исключением связи между ней и сущностью (Заказы). Ско рее всего, где-то в пользовательском приложении существует форма, предназначенная для ввода и обновления информации о покупате лях. (Такая форма существует, даже если все данные о покупателях, хранимые в системе, были изначально получены из других источни ков или при вводе информации о других сущностях — например, во время заполнения формы при приеме заказа от покупателя). Возмож но, вы не сочтете нужным включать сущность Orders в форму Cus tomers. Ведь на логическом уровне это абсолютно разные сущности, и для ввода данных, представленных в модели сущностью Orders, в си стеме, скорее всего, будет отдельная форма.

Рис. 14-1. Фрагмент диаграммы «сущности — связи» Итак, Customers (Покупатели) находится на стороне «многие» всех связей с сущностями, представленными в форме, пред назначенной для и обновления о покупателях, Поэтому в данном случае ее можно рассматривать как простую сущ ность. Это существенно облегчает процесс проектирования такой ГЛАВА и формы: нужно использовать подчиненные формы и представле ния данных в виде формируемых таблиц (grids). Следует всего лишь выбрать элементы управления, наиболее для каждого из полей Customers (о том, как это сделать, рассказывается в сле дующей главе) и разместить их на проектируемой форме.

Разумеется, размещать элементы управления следует не как попа а по возможности, соблюдая все правила, перечисленные в руко «The Windows Interface Guidelines for Software Design» («Руко водство по разработке интерфейса для Меж ду внешними краями поля формы и элементами управления дима граница шириной в 7 единиц координатной сетки;

расстояние между двумя соседними элементами управления должно составлять не менее 4 единиц координатной сетки;

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

Однако случаи, когда в одной форме нужно разместить множество различных элементов управления, не редки. В Microsoft Access и Microsoft Visual Basic число элементов которые можно разместить в одной форме, ограничено. Для формы или отчета rosoft Access оно не может быть больше 754, причем элементы, вклю ченные в форму и впоследствии удаленные, также входят в это число.

Для формы Microsoft Visual Basic максимальное число элементов уп равления — 254 (при этом двойные «стрелки», увели или уменьшать числовые значения в поле, рассматриваются как один элемент управления).

На практике же, однако, редко встречаются формы, которые со держат более отдельных элементов управления или групп. (За метьте: я сказала «отдельных элементов или групп», поскольку груп па, состоящая из трех переключателей, очевидно, воспринимается как отдельный логический Итак, что же делать, если в вашей модели данных есть простая сущность с 75 атрибутами?

Советую отображать данные по частям, а не все одновременно.

Самый простой выход — сгруппировать поля по какому-либо при знаку или разбить их на отдельные категории. Я сначала выбираю атрибуты, позволяющие однозначно определить эту сущность. Но учтите: список таких сущностей отнюдь не ограничивается ми, входящими в а включает также описательные ат рибуты, позволяющие пользователям проверить, с каким экземпля ром сущности они работают.

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

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

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

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

Разделив атрибуты на несколько групп, определитесь, как эти группы будут представлены в разрабатываемой форме. Можно разме стить несколько вкладок в главной форме — по одной на каждую группу атрибутов. Лично я предпочитаю это решение всем остальным:

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

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

Если вы решили использовать вспомогательные формы, открывае мые из главных, позаботьтесь о поддержке контекста. Пользователи ГЛАВА знать, к какой форме или ее фрагменту относится открытая вспомогательная форма. Чтобы напоминать им об этом, включите во вспомогательную форму некоторые элементы основно го диалогового окна, из которого была открыта эта форма. Не обяза тельно во вспомогательную форму всю группу элементов, к которой она относится — достаточно лишь информации, необходи мой для привязки вспомогательной формы к основной.

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

Если вы не хотите использовать множество вспомогательных окон, разместите всю дополнительную информацию в нескольких подчинен ных формах главной формы (в Basic это специальные элементы управления фреймы). Мне не очень нравится такой под ход, поскольку так довольно сложно поддерживать контекст. Необходимо предусмотреть механизм, пользо вателю в любой момент определить, какую именно из подчиненных форм он видит на экране своего монитора. Если отображение форм на экране управляется при помоши меню, то не так уж просто подсказать пользователю, что для доступа к дополнительным данным из этой фор мы он должен воспользоваться командами меню. Кнопки или пере ключатели тоже не спасут — пользователи могут не понять, почему после щелчка этой кнопки экран принимает совершенно другой вид.

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

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

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

Однако во многих случаях связи между сущностями являются взаи моисключающими: например, связь между сущностями Product (Про дукт), Beverage (Напиток) и Cheese (Сыр). Каждый продукт может от носиться к одной из категорий, но не к обеим одновременно — это может либо напиток, либо сорт сыра. В таких ситуациях исполь зуйте подчиненные формы или фреймы — разумеется, если вы не слишком стеснены ограничениями на размеры основной формы.

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

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

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

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

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

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

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

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

ЧАСТЬ 3 интерфейса Рис. Записи, участвующие в связи со стороны «многие», выводятся одновременно Я предпочитаю режим, при котором в форме отображаются сразу все записи, поскольку он лучше обеспечивает поддержку контекста.

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

Но такой способ не всегда подходит — может понадобиться выво дить записи, участвующие в связи со стороны «многие», по одной (рис. 14-3). В таком случае придется решить две проблемы: дать пользователю понять, что набор не ограничивается одной записью, отображаемой в форме, и обеспечить механизм перехода от одной записи к другой.

Рис. 14-3. Записи, участвующие в связи со стороны выводятся по одной Кнопки в нижней части окна подчиненной формы, пользователю переходить к предыдущей или следующей записи, а так ГЛАВА же перемешаться в начало и набора записей — это стандарт ный механизм навигации Microsoft Access. В данном случае такой подход имеет очевидный недостаток: два совершенно одинаковых элемента управления расположены причем только места их размещения догадаться, что один относится к подчинен ной форме и обеспечивает между записями подчинен ного набора, а другой — к основной форме и управляет ем между записями основного набора. Такое решение, не грубой ошибкой, но и изящным его назвать нельзя.

Иногда механизм можно убрать из основной формы, его другими элементами управления. Но при этом пользова тельский интерфейс должен быть тщательно продуман. Например, в форме на рис. 14-3 можно заменить механизм навигации, позволяю щий перемещаться между записями основного набора, эффективным средством поиска нужных категорий продуктов и выборки соответ ствующих записей. Вряд ли пользователям потребуется просматри вать одну все записи основной формы, содержащие служеб ную информацию. Зато удобное средство выборки записей по задан ным параметрам наверняка окажется весьма Конечно, и иной выход: заменить стандартный меха низм навигации другим средством, обеспечивающим перемещение между записями. Это могут быть специальные кнопки, полоса про крутки или другой нестандартный механизм, разработанный лично вами. Однако ради сохранения согласованности интерфейса следует по возможности избегать использовать различные способы навига ции. Если же это невозможно, выберите парадигму пользовательско го интерфейса и придерживайтесь ее.

Например, определите следующее правило: для перемещения меж ду участвующими в связи со стороны «один», будут исполь зоваться кнопки, похожие на кнопки Forward и Back панели инстру Microsoft Internet а для перемещения между запися ми, участвующими в связи со стороны — стандартный ме ханизм навигации Microsoft Access. Придерживаясь этого правила во всех формах, имеющихся в системе, вы обеспечите согласованность интерфейса. В этом случае во всех формах, представляющих простые сущности, и не в связях со стороны «многие», для перемещения между записями следует использовать кнопки Forward и Back.

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

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

Легко ошибиться, предположив, что между записями, участвующими в связи со стороны существуют дополнительные связи, хотя на самом деле это не так. На рис. 14-4 показана форма с двумя спис ками. При этом совершенно непонятно, принадлежат ли данные те лефонные номера компании, название которой указано в поле Com pany или это номера телефонов чьи фамилии пе речислены в поле. Cascade Coffee Apt 2A Seattle USA : :.'•;

' II Steven J Peacock 555- Плохо организованная форма затрудняет восприятие пользователя ГЛАВА 14 и системы Иерархические структуры Теоретически, любое отношение «один ко многим» представляет со бой иерархическую структуру, обычно термин для характеристики связей, в которых участвуют три и более наборов дан ных, Каждый из элементов, расположенных на более высоком уров не иерархии, участвует в «один ко многим» с элементами более низкого уровня. Иерархические структуры часто применяют в моде лях данных, но отображать их в пользовательских формах приходит ся значительно реже (рис. 14-5).

Order Customers Orders Details Рис. 14-5. между сущностями Customers (Покупатели), Orders (Заказы) и Order Details (Информация о заказе) представляет трехуровневую иерархическую структуру Если в системе используется такая структура, то в большинстве приложений будет следующая архитектура: в форме Customers (Поку патели) данные о заказе представлены в виде сводной таблицы (если в этой форме есть данные о заказе). Данные, относящиеся к сущностям Orders и Order Details, представлены в отдельной форме Orders (Заказы). Форма Orders ссылается на сущность Customers, од нако в этой форме представлена только связь «один ко меж ду Orders и Order Details. И лишь в очень небольшом чис ле случаев может потребоваться создать форму, где данные из всех трех таблиц: Orders и Order Details, — отображаются одно временно.

Сложно сказать, почему возникла это стремление — при проектиро вании пользовательского интерфейса избегать в формах иерархических структур. потому, что случаи, когда их действительно необ ходимо достаточно редки;

кроме того, подобные структу ры довольно трудно представлять в удобном для восприятия виде. Пред положим, что заказчик настаивает на том, чтобы включить в форму, предназначенную для ввода и редактирования данных о покупателях, возможность просматривать информацию о заказах. Эту функциональ ность в системе легко реализовать, отображая записи из таблицы Orders (средний уровень в иерархии) по одной, а записи из таблицы Order Details ~ все сразу. При этом придется в форме позволяющей вво дить и редактировать данные о покупателях, использовать в качестве подчиненной форму, показанную рис. 14-2.

ЧАСТЬ Вероятнее всего, в форме Customers нельзя отображать все записи, относящиеся к сущности Orders, одновременно. Ведь подобная можность нужна пользователям, чтобы узнать, сколько заказов по ступило покупателя, или на какую сумму в среднем он де лает и т. п. Вряд ли, открывая форму Customers, заинтересуются данными, относящимися к конкретным продуктам.

Но им будет весьма сложно ответ на эти вопросы, если все записи, относящиеся к таблице Orders, отображаются в форме Cus одновременно.

Можно отображать в форме Customers только агрегированные дан ные о заказах, позволив пользователям открывать вспомогательную форму Orders, если им будут нужны более подробные сведения. К со такой подход имеет ряд серьезных недостатков.

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

Чтобы избежать всех этих до недавнего времени иерар хическую структуру всего отображали в виде дерева. Элементы управления, позволяющие это сделать — очень действенный и удоб ный инструмент и, пожалуй, его единственный — объем данных, отображаемых пользователю на каждом уровне иерархии, очень ограничен, поскольку все данные должны умещаться в одной строке. Из-за такого ограничения нам, скорее всего, не удастся ис пользовать дерево для представления иерархической структуры: лег ко ли разместить в строке всю информацию о покупателе?

К счастью, в версии 2000 и Visual Basic 6 включены новые позволяющие отображать дополнительную информацию для элементов основной формы в виде отдельного набора записей.

Подчиненные (subdatasheets) Access 2000 поддерживают пред ставление иерархических структур в виде схем, позволяющих рать разные уровни детализации при просмотре (рис.

Хотя по внешнему виду подчиненные таблицы уступают многим другим способам представления данных деревьям), они практичны и удобны. Подчиненные таблицы позволяют реализовать иерархические структуры с числом уровней не более семи, но на каж дом уровне можно реализовать не более одного вложенного набора записей с информацией. Так, невозможно создать ГЛАВА между формами подчиненную таблицу, в которой данные из таблиц Addresses (Адре са) и Orders (Заказы) представлены как элементы одного и того же уровня. Настраиваемый табличный элемент управления Hierarchical в Visual Basic версии 6 позволяет отображать иерархическую в том же виде, что и подчиненные таблицы в Microsoft Access. Различие одно — число вложенных наборов записей на каж дом уровне иерархии для этого элемента управления не ограничено.

21 Nancy Speed) Nancy 1101! Janet erf ( 14-6. Подчиненные таблицы Microsoft Access 2000 позволяют отображать данные иерархических структур К сожалению, элемент управления Hierarchical Flexgrid имеет один недостаток;

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

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

Связи «многие ко многим» И, наконец, последний тип связей — это связи ко представленные в базе данных тремя или более таблицами.

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

Customers Orders.

Order ч | Products,.

Details Рис. 14- 7. Между сущностями и существует связь ко многим», таблицы Orders и Order Details используются как промежуточные Весьма практично отображать пользователю информацию обо всех продуктах, заказанных (таблицу Customers можно сматривать как находящуюся на стороне связи «один») или обо всех пользователях, заказавших данный продукт (таблица Products нахо дится на стороне связи При этом допустимы те же самые приемы, что при представлении в форме связей «один ко многим».

Вам остается только определить, где разместить данные из промежу точной таблицы и как обрабатывать записи на сто роне связи Большинство промежуточных таблид содержит только ключи сущностей, в связи «многие ко Одна ко, как уже упоминалось в главе 3, сама связь иногда имеет атрибуты, которые обычно включают в промежуточную таблицу при моделиро вании данных (рис. 14-7). Если эти атрибуты необходимо включить в разрабатываемую форму, лучше поместить их на стороне Если в форме должны отображаться данные о продуктах, заказан ных каждым из покупателей (при этом таблица Customers находится на стороне «один» связи «один ко то дата заказа, храняща яся в одном из полей таблицы очевидно, относится к данным ГЛАВА о продукте, а не о покупателе. Данные, отображаемые в этой форме, интерпретируются так: «Покупатель X приобрел продукт Y 15 числа этого месяца, а продукт Z — 18 числа этого Если же интер эту связь с другого то таблица Products будет на ходиться на стороне «один» связи «один ко В этом случае в форме представлены сведения о покупателях, заказавших конкретные продукты, например: «Продукт X был приобретен покупателем У числа этого месяца, а покупателем Z — 18 числа этого месяца». Дан ные таблицы Customers представлены в форме так, как бы эта таблица являлась участником связи ко со стороны «многие».

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

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

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

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

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

В большинстве случаев для представления в пользовательских формах связей «многие ко удается применять методы, кото рые используются для представления связей «один ко Но в некоторых ситуациях этот способ неприемлем, и необходимо жать в пользовательской форме связь ко многим» между сущ ностями. Например, менеджер по работе с клиентами, просмат ривая данные о купивших какой-либо товар, захотел уз ЧАСТЬ 3 интерфейса II I III III I нать, какие еще товары заказали эти покупатели, чтобы составить комплексный заказ или стандартный набор продуктов.

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

может быть, это имена и фамилии покупателей, которые приобрели эти продукты, а может быть, поставщиков, продавших эти продукты компании?

Если же отображение данных в виде иерархической структуры ка жется вам чересчур неудобным и громоздким или не нужным пользо вателям, то лучше использовать вспомогательное окно для вывода дополнительной информации, Так легче объяснить пользователю, ка кие данные содержит это окно. Кроме того, во вспомогательных ок нах можно не выводить данные, непосредственно хранимые в табли цах базы данных, заменив их агрегированными данными или другой Допустим, менеджер по работе с клиентами, просматривая спи сок продуктов, приобретенных покупателями, захочет структуриро вать эту информацию как-то иначе: например, в виде списка продук тов, с указанием количества и доли продаж каждого продукта от об объема. Или ему потребуется информация, сколько покупате лей из тех, что приобрели товар А, купили также и сопутствующий товар В, и каков объем продаж товаров А и В по отношению к наибо лее продаваемому продукту С. Конечно, такую информацию можно поместить в отдельном поле главной формы, но вдруг это существен но снизит производительность системы? Ведь для вычисления отно сительных объемов продаж придется выполнять достаточно сложные Поэтому, если эти данные не слишком часто требуются, их лучше поместить в дополнительной форме, которую менеджер бу дет открывать только при необходимости, Оба описанных способа отображения данных для связи «многие ко многим» не являются взаимоисключающими. Например, можно разместить список покупателей, которые приобрели каждый товар, в виде иерархической структуры (подчиненных таблиц) в основной ГЛАВА форме. И кроме того, вывести информацию о десяти покупателях, сделавших самые крупные заказы, во вспомогательной форме, кото рую пользователи откроют при необходимости. Как и в любом дру гом случае, примите исходя из конкретной ситуации.

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

При выборе размещаемых в форме элементов управления опреде фактор — множество сущностей, которые должны быть пред ставлены в этой форме, а также наличие и вид связей между этими сущностями (если в форме представлено несколько сущностей). Вто рой фактор — число атрибутов сущностей, которые будут отображать ся в этой форме. Как правило, число разных элементов или групп элементов, отображаемых пользователю, не превыша ет 25-30.

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

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

Выбор типа элемента управления определяется двумя факторами.

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

Обычно пользователи компьютерных систем, работающих с база ми данных, представляют себе вводимые данные как текстовую ин формацию. Это вполне объяснимо. Предположим, для доступа к которому набору данных вы используете Microsoft Access. Таблица Microsoft Access представляет этот набор данных в виде текстовых полей (рис. Однако на самом деле только поле в этой таблице имеет тип данных text. Поле Number имеет тип ЧАСТЬ поле тип поле Credit Limit — тип currency, а поле Preferred содержит булевы константы (Yes/No).

See И. 15-1. В таблице полей различных типов представлены как текстовые величины Когда разработчики выполняют манипулирования дан ными, они всего принимают но внимание домены, на кото рых определены эти данные. Например, соединения, вы полняемая над двумя полями, в одном из которых хранятся а в другом — булевы значения, даст бессмысленный результат. Тем не менее, существует немало систем, где для представления пользовате лю данных различных типов применяют один и тот же метод и одни и те же элементы интерфейса: как правило, текстовые поля (text boxes). Формально такой подход не является ошибочным: в концов, в текстовых можно представлять данные любых типов.

Однако он нисколько не облегчит работу пользователей с данными.

Текстовое поле следует использовать, только когда никакие другие, более подходящие для этого типа данных элементы управления при менить невозможно, Данные, определенные на домене Date/Time, представляют строку символов определенного формата. Но чтобы могли работать с ними, должны быть представлены в виде реальной даты. Однако представления пользователей о структуре и данных даты, отличаются от представле ний о структуре и организации текстовых данных. Например, если пользователь допустит ошибку при вводе имени покупателя, он про анализирует и исправит ее таким образом: «О! Похоже, имя Smith (Мери Смит) введено неверно: Smith. Нужно исправить ошибку, заменив букву J на букву Но если пользователь увидит ошибку при вводе даты в текстовое поле, то скорее всего, подумает:

«Наверняка эта буква М означает месяц». Выбрав для работы с дата ми элемент управления (например, ГЛАВА рать значения дат, автоматически вычисляя год, месяц и день неде ли), вы обеспечите большее соответствие интерфейса ментальной модели пользователя и существенно облегчите ему работу с системой.

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

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

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

ПРИМЕЧАНИЕ Я не буду подробно останавливаться на разнообразных дополнительных элементах интерфейса: графических фрагментах и звуковых и графических клипах. Эти элементы, как правило, разработаны фирмами, занимающимися выпуском коммер ческого программного обеспечения, в виде встраиваемых компонен тов ActiveX. Наш обзор будет ограничен стандартными компонентами Microsoft Visual Basic и Access. Тем, кто хочет узнать, какие еше допол нительные элементы управления можно использовать при разработке пользовательского интерфейса, я рекомендую обратиться на Web-узел корпорации Microsoft, а также на Web-узлы других компаний — разра ботчиков программного обеспечения. Вполне возможно, что вы най дете там уже готовое решение.

Логические значения Как и многие другие типы данных, логические значения можно пред ставлять в пользовательском интерфейсе как текстовые поля, но я не рекомендую это делать. Рассмотрим пример: в таблице Customer есть поле определенное как булево значение (в Microsoft Access ему соответствует тип данных Yes/No), где хранятся данные о подтверждении кредита. Для представления данных, хранимых в поле CreditApproved таблицы можно использовать текстовое поле, значение которого пользователи будут изменять. Затем ЧАСТЬ действительно ли пользователь ввел одно из допустимых Yes или No — для Access, True или False для других механизмов баз данных. Но если при вводе данных не задано никаких дополнитель ных ограничений, весьма вероятно, что пользователи будут вводить в текстовое поле произвольные значения, например «Условно» или Конечно, есть особые случаи, когда это целесообраз но, и произвольные значения определенным образом обрабатывают ся и интерпретируются системой. Но чаше такая интерпретация гических величин в пользовательском интерфейсе к сниже нию производительности. Гораздо лучше элемент интерфейса, пре доставляющий пользователю возможность выбрать одно из двух воз можных значений. Для этого весьма подходят два элемента ния, которые имеются и в Access, и в Visual Basic — флажки и кноп ки-выключатели (рис. 15-2).

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

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

ГЛАВА Еще несколько важных замечаний. Не используйте ли для отдельных логических значений. В Microsoft Windows нет механизмов, которые запрещали бы делать это, однако в силу сложившихся правил для моделирования отдельных логических значений используют другие элементы управления — флажки. Пере ключатели же применяют там, где пользователю предлагается выб рать один из нескольких взаимоисключающих параметров.

Более того, используя переключатели (в особенности, располо женные рядом) для представления нескольких отдельных логических значений, вы можете ввести пользователя в заблуждение:

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

Например, определенное значение (Номер покупа теля) в записи в форме Orders (Заказы) допустимо тогда и только тог да, когда такой номер имеется в таблице Customers (Покупатели). Если вы решили свести к минимуму операции ввода пользователями дан ных с то поместите в разрабатываемую форму список покупателей и предоставьте пользователям возможность выбрать нужное значение из этого списка.

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

В Visual Basic три вида комбинированных списков (рис.

15-3), которые позволяют отображать пользователю весь список по стоянно или только по требованию (последние называют раскрываю списками). В же — только раскрывающиеся списки.

Кроме того, в списках Visual Basic можно размещать флажки рядом с каждым значением из списка, а в Access — нет.

rtnd I 15-3. В Visual Basic существует вида Руководство «The Windows Interface Guidelines for Software Design» («Руководство по разработке интерфейса для Windows-приложений») рекомендует задавать размер списка так, чтобы на экране менно отображалось от трех до восьми его элементов. Если размеры формы сильно ограничены, и весь список разместить на ней невоз можно, используйте раскрывающиеся списки.

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

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

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

И в Visual Basic, и в Microsoft Access есть интереснейшая возмож ность — отображать пользователю не ту информацию, которая непос редственно хранится в таблице, лишь ее часть или данные из других таблиц. Например, если в качестве первичного ключа в таблице Cus используется поле с автоматически зна чениями или поле Identify, вам придется хранить это значение как внешний ключ в но отображать пользователям дан ные, в этом поле, не имеет смысла. Вместо пер вичного ключа таблицы Orders в форму Orders можно поместить спи сок фамилий и имен покупателей (данные из таблицы из которого пользователи будут выбирать нужные значения.

В Visual Basic это можно сделать, указав различные значения свойств и ListField. В Access используют несколько полей:

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

Возможность отображать значения нескольких полей таблиц в комбинированных окнах, поддерживаемая Microsoft Access, весьма удобна и часто применяется, Жаль, но в Visual Basic она отсутствует.

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

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

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

15-4. и с зависимой фиксацией Хотя многие средства разработки, например Visual Basic, позволя ют генерировать группу кнопок на этапе исполнения, я не советую делать это. Пользователям гораздо удобнее работать с формами, в ко торых все элементы управления расположены на привычных местах, чем с постоянно изменяющимся интерфейсом. Поэтому группы кно или кнопок с зависимой фиксацией следует ис пользовать, только когда число и названия элементов в этих группах постоянны (или по крайней мере, не изменятся до выхода следую щей версии программы). Во всех остальных случаях лучше применять списки или комбинированные окна. При изменении числа или зна чений элементов списков размер элементов управления не меняют ся, и не причиняют пользователям неудобств.

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

В Access, чтобы отображать пользователю записи одну за другой, удобнее всего использовать подчиненную форму в режиме отображе ния одной записи. Задайте свойства в разрабатываемой форме — и Access выполнит за вас основную часть ГЛАВА работы. Чтобы создать такую подчиненную форму в Visual Basic, при дется потрудиться, но взамен вы получите больше возможностей уп равлять данными. В любом случае, этот метод вполне оправдан, если нужно одновременно выбирать несколько значений из списка, и в особенности, если вы собираетесь использовать в разрабатываемой форме множество разных элементов управления.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.