Каждый платеж имеет уникальный номер, выделенный системой.

Здесь тоже два правила, маскирующихся под одно. Первое (относительно уникальности) - это простое правило для данных, которое можно ввести с помощью ограничения PRIMARY KEY или UNIQUE. Второе правило предполагает работу по назначению номера. Мы предположили бы, что структура данных предоставляет механизм для выполнения этой задачи, который может быть последовательностью Oracle или, если нужен более жесткий контроль и бухгалтеры терпеть не могут разрывов в последова- тельности, однострочной таблицей, содержащей следующий свободный Ы номер.

Каждый, кто хорощо знает Oracle, может, конечно, возразить, что логике обработки не нужно знать о механизме назначения номеров. Почему? Потому что мы можем написать триггер BEFOR INSERT уровня строки, применяющий выделенный системой номер. К сожалению, это означает, что процесс не может выбрать только что созданную запись или связать с ней другие записи, потому что не знает номер! Настойчивый сторонник SQL затем напищет триггер так, чтобы он заносил выделенный номер в глобальную переменную пакета, из которой его может выбрать приложение.

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

Все коды валют должны раскрываться, т.е. рядом с кодом при вводе должно

указываться полное название.

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

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

Обновление записей о платежах не разрешается.

Это правило для данных, которое следует вводить при помощи простого триггера BEFOR UPDATE на уровне предложения. Этот триггер должен генерировать ошибку приложения.

Каждое изменение в записях о покупателях требует создания контрольной

записи об изменении.

Это правило для данных, которое следует вводить при помощи триггера BEFOR UPDATE уровня строки в таблице покупателей.

Подготовка и утверждение документации

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

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

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

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

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

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

. nj

Размещение логики

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

Что куда идет?

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

Правила для интерфейса следует реализовать во внешней системе, независимо от того, что она собой представляет - программу на Visual Basic или Delphi, экранную форму, созданную в Oracle Forms, или генератор отчетов.

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

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

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

Для случая, когда независимые процедуры для процессов написаны на PL/SQL, в Oracle Forms есть привлекательное средство, позволяющее перетащить эти процедуры из внешней системы во внутреннюю. Хотя эта возможность очень мощная и подчеркивает, что правила для процессов могут существовать либо в клиентском, либо в серверном пространстве, ее применение несколько ограничивается тем фактом, что Oracle Forms в настоящее время поддерживает лишь PL/SQL версии 1, а не более позднюю и значительно улучшенную версию 2.x, с которой работает процедурная опция Oracle?.

Дублирование

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

Пол человека должен быть либо F ( Ж ), либо М ( М ) В спецификации интерфейса будет полностью обоснованным требование о том, что это правило подлежит проверке, как только пользователь