к сведению ij

Вы, возможно, помните наш принцип - работать умно, а не напряжен-/ но . Сражаться три месяца с генератором, чтобы заставить его сделать то, что он не хочет, а затем признать свое поражение - не очень умно, если для написания модуля вручную понадобилось бы меньше rpei недель!

Большинство из нас беспокоятся о том, что генераторы сделают с нашим кодом, и просто не доверяют им в достаточной степени!

Ответ на вопрос ценой $64000 о соединении CASE-средства с генератором, звучит так. Если можно установить, что генератор способен генерировать модули необходимой сложности, то будут ли затраты на ввод данных в репозитарий меньшими, чем затраты на создание этих же модулей с полной документацией традиционными методами?

в этой /лаве:

Правила для данных, нроцеесов

и пнтерфет о

Ранлтцеине логики

Вопросы блокировки

Трехуровневые арлитекпи/])ы

Где разместить логику обработки?

в предыдущих главах книги мы изучали структуру базы данных, т.е. структуру так называемой внутренней системы (back end). В части 4 мы рассматриваем структуру программных единиц, называемых внещней системой (front end). 13нещняя система охватывает экранные формы и отчеты, которые поддерживает база данных. В традиционном приложении базы данных эти две системы четко определены: внутренняя включает таблицы, индексы и представления, а внещняя - форматирующую и прикладную логику.

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

Правила для данных, процессов и интерфейса

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

Группы правил

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

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

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

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

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

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

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

Пол человека должен быть либо F ( Ж ), либо М ( М ).

Каждый заказ должен быть предназначен для одного и только одного покупателя.

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

Пособие не должно выплачиваться лицу, сбережения которого превышают $16000.

Только руководитель может санкционировать выплату денежного вознаграждения.

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

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

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