Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата

Следовательно, при управлении транзакциями внутри приложения клиент/сервер Oracle Power Objects предоставляет возможности установления бизнес-правил, регулирования информационной нагрузки сети и поддержания целостности данных. Например, отдельное бизнес-правило может устанавливаться как ограничение базы данных или как часть приложения- клиента.

Подход к разработке, реализуемый в Oracle Power Objects

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

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

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

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

Если начать с клиента

Обычно, с разработки внешнего интерфейса начинают, когда…

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

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

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

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

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

(вычисления).

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

Если вначале разрабатывается внешний интерфейс, следует ответить на следующие вопросы:

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

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

> Какие объекты должны быть определены вне приложения Oracle Power

Objects и затем импортированы? Например, если планируется добавлять растровые образы или другие OLE-объекты, возможно, вначале придется разработать некоторые из этих ресурсов приложения.

> Где лучше и как лучше установить ограничения? Например, если требуется гарантировать, чтобы транзакция, введенная в приложении регистрации заказов, не содержала значений, превышающих некоторый объем, возможно, будет лучше установить это ограничение на клиенте через код Oracle Basic, а не на сервере через триггер.

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

> Как лучше представить документ? В данном случае, «документ» - отдельный объект, такой как заказ на приобретение, который заполгяеься в приложении. Можно поместить каждое поле, которое будет содержать данные, относящиеся к заказу, на одной форме.

Однако, для удобочитаемости, возможно, лучше будет разбить «мега- форму» на несколько меньших форм.

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

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





Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата