ГЛАВА 16 Паддвржка цйяостности fey цжиыю

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

Tlie OWttinwr (fiBi ЬдаггЬп1оп to delete ha* orrteri in Ыж ttatAwe; What

woiiMvi do? , . ..

I СиЛочл s ftlftSsB dote*? *e i>fi.hi!;45Ir;nf.r=ijt>irawrrtsJtS[JincSni,

.anfMtr.i-.W.tJlieK.tfrJn-!-.

nl I 3VS :

Fnc ьзоватегь получает подробные разъяснения и может выбрать вариант действий

Если такой вариант реализации вас не устраивает, можете ти на экран пользовательского компьютера окно с запро-

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

Бизнес-правила

Итак, мы рассмотрели внутренние ограничения, струк-

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

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

ЧАСТЬ 3 Праектирозавде пользовательекого иитарфейса

определенного события, удовлетворять реляционной

модели. Но нарушение ограничений, налагаемых бизнес-правилами -

совсем другой случай.

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

если на начальной стадии реализации она была безупречна, бизнес-

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

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

ПРИМЕЧАНИЕ Третий одчай - это когда пользователи намеренно вводят неправильные данные с целью дестабилизировать работу системы. Самые строгие а едва ли помогут защитить систему от

умышленной порчи данных. К счастью, подобные случаи очень редки.

Случайные ошибки при вводе данных

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

лю, как исправить ошибки. Альтернативные варианты следует предусмотреть везде, где только жно. Рассмотрим диалоговое окно, отображаемое при неверном вводе даты: когда означающие

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

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

ГЛАВА 16 nauMfymmii ueisssjTHscTsK базы данных

щи пользователю реализовать в системе, мы поговорим под-

робнее в главе 18.

ипкппнп Date

The Delivery OMt (сЩЁ wheri the customer iijid liln-the t: to

(Idiyeree to the Mlld№l !ффГ!Ы : е. ; UtlfDrtun the

system ismable to IfttHff the date you have **re*-31 /OI.Uj, What ;tiHHilllyou№eCbda?

:. КЙМ* .

I Miht(lг.ir >YluЧJl;W*oгtiюt in>..v ч.-ч

I abou field efttepi datftvSues

Puc -4. Диалоговое окно сообщает пользователю рном вводе даты и предлагает возможные варианты действий

Модель системы и реальность

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

Итак, при проектировании системы и особенно при определении бизнес-правил следует проявлять особую стараясь

предугадать как можно больше нестандартных ситуаций и по возможности пользователям способы выйти из них без нару-шени гности данных. На рис. 16-5 показано диалоговое окно, которое появляется на экране пользовательского компьютера, если дата, введенная в поле Deliverable, предшествует дате, введенной в поле (Дата оформления В этом примере для ввода данных в поле OrderDate используется элемент мения не позво-