E n d ;

/

Выполнение скрипта в сессии Oracle 8 создаст все объекты и связи схемы данных «MainSchema».

12. Разработка приложения

Разработка приложения является итоговым этапом проделанной работы. В качестве средства разработки будем использовать C++

Builder и СУБД Oracle 8.

Мы остановили свой выбор именно на C++ Builder, потому что этот инструмент обладает относительной простотой использования

при высоких возможностях.

Так как цель данного раздела - показать, как использовать получен­

ные результаты при создании программного продукта, то мы рассмот­ рим лишь пример программирования одного блока системы. Точнее го­ воря, создадим экранную форму работы с заказами. Для этого придется создать все объекты базы данных, изображенные на рис. П3.56. О том, как это сделать, подробно описано в предыдущем разделе.

Данная форма должна содержать список ранее созданных заказов и предоставлять ряд сервисных операций по работе с ними. Все эти операции прописаны в классе «OrderForm». Конечно, на этапе проек­ тирования мы описали эти операции в довольно общем виде, не ука­ зав у большинства ни типа возвращаемого значения, ни аргументов. Теперь мы имеем возможность превратить заготовки операций в функциональный код.

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

Данная форма не должна содержать никаких элементов управле­ ния, таких как кнопки, выпадающие списки и т.п. Подобные элемен­ ты должны находиться в дочерних окнах. Главное окно, как правило, содержит меню, панели инструментов и строку состояния, а остав­ шееся пространство служит для размещения дочерних окон.

Создадим меню для главной формы. Для этого расположим ком­ понент «MainMenu» с панели инструментов «Standard» на главной форме. Переименуем его в «MainMDIMenu». Затем двойным щелч­ ком на компоненте откроем редактор структуры меню. В данном ре­ дакторе мы можем создать все необходимые пункты главного меню. Создадим их согласно структуре, представленной на рис. П3.61.

Инструкция пользователя

О программе

Рис. П3.61. Структура меню для главной формы

Установим свойство «Menu» нашей формы в «MainMDIMenu». Теперь главная форма будет выглядеть так же, как на рис. П3.62.

Для завершения работы над главной формой поместим на нее па­ нель инструментов (компонент «ТооШаг») и строку состояния (ком­ понент «StatusBar»). Установим свойство «Flat» панели инструментов в «True» и создадим пока всего две кнопки. Одну проассоциируем (свойство кнопки «Menultem») с пунктом меню «Выход», а вторую

{

}

d o u b l e O r d e r : : c a l c P o s Q u a n t i t y ()

{

}

O r d e r P o s i t i o n : : O r d e r P o s i t i o n ()

{

}

O r d e r P o s i t i o n : : O r d e r P o s i t i o n ( c o n s t O r d e r P o s i t i o n & r i g h t )

O r d e r P o s i t i o n : : ~ O r d e r P o s i t i o n ()

{

O r d e r P o s i t i o n & O r d e r P o s i t i o n : : o p e r a t o r = ( c o n s t O r d e r P o ­

s i t i o n S r i g h t )

{

}

Мы видим, что в файле «Order.cpp» содержатся лишь «заглуш­ ки» для соответствующих операций, конструкторов и деструкторов. Прописать функциональную часть той или иной операции придется нам самим.

За поддержку всех действий с заказами отвечает класс «OrderForm», с него и начнем нашу работами с классами от Rational Rose.

Компонент «TADOQuery» формы можно теперь удалить, он больше не понадобится.

При построении строки соединения был указан Microsoft OLE DB Provider For ODBC Drivers. Источник данных MATRIX был настроен ранее как ODBC-соединение с базой данных MATRIX. Пользователь scott (пароль tiger) является демонстрационным пользователем, кото­ рый всегда создается при установке Oracle. Если таблицы, перечис­ ленные в разд. 11, были созданы от другого пользователя, то в строке соединения необходимо указать именно этого пользователя.

Подключим новый модуль «DBParams.h» в модуле «Order.h». Теперь найдем объявление класса «OrderForm» в «Order.h» и до­

бавим еще один атрибут, а точнее говоря, динамический массив идентификаторов - «orderlD»:

c la s s O r d e r F o r m

{

p u b lic :

p r o te c te d : p r iv a t e :

Запрос, который выполняется в данном конструкторе, отбирает только те заказы, которые находятся в состоянии «Новые». Другие состояния менеджера не интересуют.

Доработаем операцию «displayOrder». Изменим ее описание в «Order.h»:

O r d e r * d i s p l a y O r d e r (___ int64 i n d e x ) ;

Так как заказ ассоциирован с конкретным клиентом, то для под­ держки операций обмена данными между классовой моделью и базой данных дополним предок класса «Customer» - класс «Contractor» - целочисленным атрибутом «ГО» и операциями чтения/установки это­ го атрибута «get_ID» и «set_ID». Возможно, придется аналогичным образом дополнить и другие классы, но будем делать это по мере возникновения необходимости.

В «Order.cpp» создадим реализацию операции «displayOrder»:

O r d e r * O r d e r F o r m : : d i s p l a y O r d e r (___int64 i n d e x )

{

O r d e r * C u r r e n t O r d e r ; C u s t o m e r * C u s t ; char* c p ;

N a m e ( " o r d e r _ d a t e " ) - > A s S t r i n g . L e n g t h () + 1 ] ;

N am e ( " c u s t o m e r _ i d " ) - > A s l n t e g e r ) ;

C u r r e n t O r d e r - > s e t _ t h e _ C u s t o m e r ( C u s t ) ;

r e t u r n C u r r e n t O r d e r ;

}

Заполняются только те атрибуты класса «Order», которые будут в дальнейшем формировать визуальный список.

Важно отметить, что мы не смешиваем визуальные компоненты C++ Builder с классами, полученными с помощью Rational Rose. Это позволяет говорить об относительной переносимости этих классов и возможности использования без значительных доработок в другой среде разработки.

Попробуем увидеть, в прямом смысле этого слова, наши резуль­ таты. В качестве упомянутого ранее визуального компонента, под­ держивающего работу со списком данных, вполне подойдет компо­ нент «StringGrid» (панель инструментов «Additional»). Расположим этот компонент на форме «ChildOrderForm» и установим свойство «Align» в «alLeft». Затем расположим на форме еще два компонен­ та: «Splitter» и «Panel» панелей инструментов «Additional» и «Stan­ dard». У первого установим свойство «Align» в «alLeft», а у второго

i f ( C h i l d O r d e r F o r m - > T a g ! = 0 )

{

d e le te C u r r e n t O r d e r F o r m ;

C u r r e n t O r d e r F o r m = n e w O r d e r F o r m f ) ; s e t V i s u a l L i s t ( ) ;

}

Перед модальным вызовом формы «AddOrderForm» обнуляется свойство «Tag» текущей формы. В результате работы пользователя с формой «AddOrderForm» заказ может быть и не создан, например, пользователь нажал кнопку «Отмена». В этом случае нет смысла пе­ реформировывать (обновлять) список заказов форм «ChildOrderForm». А в том случае, если пользователь создал заказ, т.е. заполнил необхо­ димые поля и нажал на кнопку «Создать заказ» (это состояние харак­ теризуется взводом «Tag» в значение, отличное от нуля), необходимо удалить текущий экземпляр «CurrentOrderForm», снова создать его (на конструкторе произойдет чтение новых заказов) и вызвать функции заполнения «set_VisualList()» для отображения обновленного списка заказов на экране.

Также стоит обратить внимание на то, что при открытии формы «AddOrderForm» необходимо заполнить выпадающий список клиен­ тов справочными данными. Эта процедура реализуется функцией «set_CustList()», которая вызывается при активизации формы. Текст функции приведен ниже:

t r a c t o r O r d e r b y n a m e " ) ;

d e le te n e w O r d e r ;

d e le te a d d O r d e r F o r m ;

C h i l d O r d e r F o r m - > T a g = 1 ;

C l o s e ( ) ;

}

При реализации операции добавления нового заказа мы не затро­ нули использование контролирующего класса «OrderControl», хотя реализация его единственной операции «submit()» могла быть весьма простой и заключалась бы в проверке существования ранее созданно­ го заказа с номером и датой, совпадающими с номером и датой ново­ го заказа.

Мы не ставили перед собой цель полностью внедрить все классы, полученные с помощью Rational Rose. Наша задача была показать, что классы из Rational Rose могут действительно работать в реальном проекте без каких-либо переработок.

Тем, кто раньше работал с визуальными компонентами баз дан­ ных Borland C++ Builder или Borland Delphi, проделанная работа с классами может показаться бессмысленной, поскольку посредством этих компонентов можно действительно работать эффективнее на­ прямую с базой данных, минуя промежуточные классы. Но в общем случае подобных компонентов может и не быть. Продуктов, поддер­ живающих разработку на C++, достаточно много и наш подход в этом отношении отличается универсальностью.