Oracle Power Objects

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

объемов работы.

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

инструментария, разработка начинается с сервера базы данных или с внешнего

интерфейса. Средства разработки Oracle Power Objects позволяют сначала

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

компоненты приложения-клиента. После того, как интерфейс пользователя

завершен, при необходимости, можно сформировать под него объекты базы

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

представлениями, Обычно, если проектировщик работает с приложением, в

котором для соединения компонентов внешнего интерфейса с сервером базы

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

написание этих процедур, пока не будет удовлетворен интерфейсом

пользователя и пока не будут определены все объекты базы данных. В

противном случае, при переопределении объектов базы данных или компонентов

интерфейса ему придется тратить много времени на редактирования и переделки

кода программы.

С другой стороны, высококачественные инструментальные средства

клиент/сервер часто требуют, чтобы их проектирование было начато с

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

интерфейс. Учитывая как сложность и важность правильной организации

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

разработке этих видов приложений сервер базы данных должен иметь приоритет.

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

данных и внешним интерфейсом, вместо исключительного проектирования первым

того или другого, (Однако, обычно, все равно один раздел приложения базы

данных сначала получает акцент, даже если впоследствии ему не уделяется

исключительное внимание). Если проектировщик имеет ясную совокупную картину

требуемых объектов и их отношений, Oracle Power Objects помогает

существенно упростить этот вид инкрементной разработки.

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

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

> Необходимо применить в приложении интерфейса клиента какие- либо

производственные стандарты, например, для финансовых расчетов.

> Необходимо сосредоточить усилия на обеспечении правильного

выполнения приложением последовательности действий некоторого

процесса.

> Используются уже имеющиеся объекты базы данных, для которых

необходимо просто сформировать интерфейс. Однако, при этом, все

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

данных некоторые небольшие модификации. Например, может быть

принято решение о том, что инициирование отдельного бизнес-

правила можно перенести с сервера на клиент, устраняя тем самым

потребность в хранимой процедуре сервера, разработанной для этой

задачи.

> Приложение не предназначено для интенсивного доступа к базе

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

пользователя.

В этих случаях Oracle Power Objects позволяет по отдельности

проектировать и тестировать различные формы и отчеты, которые

составляют интерфейс пользователя. Следовательно, разработка

приложения, которая начинается с внешнего интерфейса, может

выполняться пошагово или фронтом: разработчик может или проектировать

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

компонентами одновременно. На этом этапе, модификации объектов не

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

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

отчетов, классов и других объектов приложения решаются вопросы

навигации между ними и добавляется программный код, в котором

устанавливаются бизнес-правила и выполняются задачи обработки данных

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

Объекты интерфейса и их связанные таблицы или представления

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

структурно часто дублируют формы и отчеты, в которых выводятся их

записи.

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

следующие вопросы:

> Какими будут главные формы, которые пользователь увидит на

экране? Они будут, вероятно первыми объектами, которые должны

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

представлениями.

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

приложение? Иными словами, следует тщательно продумать, как легко

пользователь сможет вводить данные, осуществлять навигацию между

формами и выполнять другие операции внутри приложения. Кроме

того, необходимо оценить, как приложение организует работу

пользователя и задает ли оно разумный темп при решении задач.

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

Objects и затем импортированы? Например, если планируется

добавлять растровые образы или другие OLE-объекты, возможно,

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

приложения.

> Где лучше и как лучше установить ограничения? Например, если

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

регистрации заказов, не содержала значений, превышающих некоторый

объем, возможно, будет лучше установить это ограничение на

клиенте через код Oracle Basic, а не на сервере через триггер.

Для этого потребуется добавить необходимый код Oracle Basic,

который будет прерывать транзакцию до ее фиксации, если она

превышает установленный объем заказа.

> Как лучше представить документ? В данном случае, «документ» -

отдельный объект, такой как заказ на приобретение, который

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

будет содержать данные, относящиеся к заказу, на одной форме.

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

форму» на несколько меньших форм.

> Какие компоненты интерфейса будут повторяться в приложении? Если

имеются объекты, неоднократно появляющиеся в приложении,

вероятно, их следует проектировать как пользовательские классы,

сохраненные или в приложении или библиотеке, Экземпляры

пользовательских классов мажно добавлять к формам и отчетам,

вместо того, чтобы много раз генерировать одни и те же объекты.

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

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

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

изменения в исходном классе.

Главный недостаток первоначальной разработки внешнего интерфейса

заключается в том, что проектирование базы данных – обычно, одна из

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

случае к интерфейсу пользователя приковано основное внимание разработчика.

То, что хорошо смотрится в экранной форме, может быть трудно выразимо с

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

Основные функции Oracle Power Objects, которые позволяют начать

разработку с внешнего интерфейса, включают:

> Инструментальные средства GUI (графический пользовательский

интерфейс) для быстрого создания новых объектов внешнего

интерфейса.

> Объекты приложений многократного использования, созданные как

пользовательские классы или объекты библиотек.

> Возможность всесторонне тестировать отдельные компоненты

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

перехода к созданию других объектов приложения.

> Отладчик периода выполнения, который может запрашивать свойства,

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

Если начинать с сервера базы данных

При этом подходе, прежде, чем приступить к формированию интерфейса,

проектировщик начинает с разработки модели данных (разработка всех таблиц и

представлений). Необходимость начать с объектов базы данных может быть

обусловлена несколькими причинами:

> Приложение будет использовать большое количество таблиц и

представлений сложной структуры. Проектировщики, которые работают

с реляционными базами данных, знают, как важно иметь ясное

представление относительно объектов базы данных и их отношений.

Этим в дальнейшем предотвращаются проблемы, вызванные сколько-

нибудь значительными корректировками этих объектов. Если в одной

из таблиц отношения один-к-многим изменяется тип данного для

ключевого значения, это может разрушить отношение между главной и

подчиненными таблицами.

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

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

определить объекты базы данных, а также триггеры и хранимые

процедуры, которые из защищают. Затем уже можно переходить к

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

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

сервере кодов ошибок и передача их в читабельном виде

пользователю.

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

когда поля формы – простое отображение таблиц и представлений

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

> Защита сервера – приоритетная задача.

> Для повышения производительности требуется вначале произвести на

компонентах сервера специальные процедуры (например,

индексирование или нормализацию таблиц).

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

различными внешними интерфейсами.

> Приложение использует сложные отношения один-к-многим или

вычисляемые значения. В таких случаях требуется тщательно

спроектировать таблицы и представления, чтобы отношения один-к-

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

того, правильно построенная модель данных сэкономит время при

работе приложения за счет уменьшения сложности уравнений,

оперирующих данными.

Если проектирование начинается с сервера, имеется возможность

сформировать эффективную модель данных, отражающую информацию из реальной

жизни. Объектом реальной жизни может быть любой объект (например, данные

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

т.д.), который требуется описать в одной или больше таблиц.

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

следующие вопросы:

> Какие требуются объекты базы данных? Иными словами, что будет

представлять собой модель данных?

> Как следует оптимизировать структуру данных с точки зрения

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

> Какие таблицы или представления будут основными? Почти в каждой

модели данных некоторые таблицы более важны, нежели другие.

Следовательно, необходимо рассмотреть весьма вероятное событие,

когда в сети клиент/сервер к этой таблице попытается обратиться

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

защиты важных данных от разрушительных изменений (например,

модификаций ключевых значений в отношении один-к-многим), а также

от несанкционированного доступа. Для реализации этих мер имеется

широкий диапазон средств – от определения пользовательских

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

данных, до написания триггеров, которые при некоторых условиях

предотвращают проведение изменений в базе данных.

> Какие бизнес-правила целесообразно установить на сервере? Здесь

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

сервера работой по обслуживанию каждого бизнес-правила и

необходимостью установки на сервере важных ограничений, которые

должны гарантировать целостность и согласованность данных

приложений всех клиентов.

Как проектировать пользовательские классы и библиотеки

Прежде, чем приступать к разработке приложения, необходимо рассмотреть

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

объектов или наборов объектов. Вот некоторые примеры таких объектов:

> Эмблема компании, которая присутствует на многих формах и

отчетах.

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

> Набор элементов управления, используемых для фильтрования и

сортировки записей.

> Группа переключателей, используемых для обеспечения стандартного

набора опций в нескольких формах

> Ряд текстовых полей, выводящих в нескольких формах информацию

заказчика, продавца или компании.

Создавая эти объекты как пользовательские классы, сохраненные в

приложении или в библиотеке, разработчик получает следующие преимущества:

> После того, как объекты созданы, добавление их к форме может

выполняться простой операцией drag-and-drop.

> В Oracle Power Objects экземпляры пользовательского класса или

объекты библиотеки наследуют свойства и методы определения

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

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

используемых объектов приложения выполняется намного быстрее,

если они создаются как экземпляры. При этом, чтобы провести

изменение по всем экземплярам, требуется изменить лишь

определение пользовательского класса или объекта библиотеки.

Решение по созданию объекта приложения многократного использования как

пользовательского класса принимается по результатам ответа на вопрос: этот

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

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

приложении?

> Если предполагается использовать объект в нескольких приложениях,

целесообразно создать его как объект библиотеки (или как объект-

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

собственную библиотеку, подобную библиотеке динамической

компоновке (DLL) в среде Windows.

> Если планируется использовать объект только в одном приложении,

можно создать его как пользовательский класс, При хранении

пользовательского класса в приложении уменьшается количество

поддерживаемых объектов-файлов.

> Oracle Power Objects позволяет создавать как объекты библиотеки

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

классы – наиболее применяемый тип объектов библиотеки, так как

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

так и элементов управления.

Заключение

Суммируя вышеизложенное:

> База данных содержит объекты, предназначенные для хранения и

организации информации.

> Сеанс обеспечивает доступ к базе данных, а также к коллекции

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

пользователя базы данных.

> Приложения внешнего интерфейса выполняют запросы базы данных,

заполняя информацией наборы записей.

Наборы записей обычно связываются с объектами-контейнерами, которые

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

данных.

Несмотря на то, что Oracle Power Objects обеспечивает обширный набор

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

и предназначен, в первую очередь, для формирования приложений базы данных в

среде клиент/сервер. Используя один и тот же внешний интерфейс в системе

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

защиты, эффективности, масштабируемости и другим важным функциям. Кроме

того, Oracle Power Objects позволяет устанавливать и поддерживать

специфические требования к данным средствами как приложения-клиента, так и

сервера базы данных.

OPO - новый продукт на рынке средств разработки приложений

клиент/сервер. У него нет за спиной богатой истории развития и как чисто

инструментального языка (Visual Basic, Delphi) и как инструмента создания

приложений для системы клиент/сервер (Forms). Первую версию скорее можно

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

Если будет улучшен пользовательский интерфейс Среды разработки, введена

полная поддержка OLE и особенно OLE Automation, будут созданы драйверы для

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

репозитарий приложения, то OPO действительно может стать весьма интересным

продуктом.

Список литературы

Г.Анзер: «Oracle Power Objects», Мосва, АБФ, 1997

www.oraclub.trecom.tomsk.su/articles/mir-ora/program/23.htm

Страницы: 1, 2, 3, 4