плановое количество по каждой товарной позиции. Назовем данный класс «PurchasePlanPosition». Атрибуты класса следующие:

-measureUnit (единица измерения);

-planQuantity (плановое количество);

-factQuantity (выполнено фактически);

-isMain (признак основного плана).

Атрибута «factQuantity» может и не быть в этом классе, в этом случае фактическое значение отгрузки будет вычисляться в аналити­ ческом отчете по актам приемки. Атрибут «isMain» определяет тип позиции плана: основная или корректирующая. Основной план со­ ставляется в начале планового периода, а затем может быть откор­ ректирован путем добавления позиций с отрицательными или поло­ жительными значениями. Соответствующая диаграмма классов пред­ ставлена на рис. П3.27.

6. Диаграмма взаимодействия

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

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

Создадим реализацию прецедента «Согласование заказа» (рис. П3.28).

(from Logical View)

Построим для данной реализации диаграмму последовательно­ стей, которая будет описывать сценарий размещения нового заказа, и назовем эту диаграмму, соответственно, «Размещение нового зака­ за». На данной диаграмме отразим взаимодействие объектов классов: «Customer» (клиент), «Manager» (менеджер), «OrderForm» (форма ра­ боты с заказами), «OrderControl» (контроль заказа), «OrderPosition» (позиция заказа), «OrderPosForm» (форма работы с позициями зака­ за). Построенная диаграмма представлена на рис. П3.29.

Диаграммы последовательностей не только отображают взаимо­ действие объектов, но и позволяют определить/отыскать операции, которые должны выполнять те или иные классы.

Рис. П3.29. Диаграмма последовательностей для описания процесса «Создание заказа»

Диаграмма сотрудничества представляет альтернативный способ описания взаимодействия объектов и акцентирует внимание в пер­ вую очередь на организации объектов.

Создадим реализацию прецедента «Выписка накладной» (рис. ПЗ.ЗО) и построим диаграмму сотрудничества для сценария «Печать накладной» (рис. П3.31).

Рис. ПЗ.ЗО. Реализация прецедента «Выписка накладной»

2:displayf)

------ >

Рис. П3.31. Печать накладной. Диаграмма сотрудничества

Rational Rose позволяет автоматически создавать диаграмму со­ трудничества по диаграмме последовательностей и наоборот. Прове­ рим, как это работает на практике. Создадим несложную диаграмму последовательностей для сценария регистрации сотрудника предпри­ ятия в системе управления складом (рис. П3.32).

Employee : LoainForm : Svstem llser

checkUserQ

register^)

Tl

Рис. П3.32. Регистрация в системе. Диаграмма последовательностей

Затем с помощью меню «Browse» > «Create Collaboration Dia­

gram» создадим диаграмму сотрудничества (рис. ПЗ.ЗЗ).

2: display 4: checkUser()

Рис. ПЗ.ЗЗ. Регистрация в системе. Диаграмма сотрудничества

Теперь можно легко сгенерировать программный код классов, реализуемых компонентом «Order» (выделив компоненты «Order» и выбрав пункт меню «Tool/OH-/Code Generation»). Ниже представ­ лен фрагмент программного кода файла заголовка с расширением М для классов компонента «Order». Часть комментариев, которые фор­ мируются автоматически Rational Rose, была удалена с целью уменьшения объема кода.

# i f n d e f O r d e r _ h

# d e f i n e O r d e r _ h 1

b r i g h t ) ;

/ / П о л у ч и т ь д е й с т в у ю щ у ю ц е н у п о п р а й с - л и с т у d o u b l e g e t A c t u a l P r i c e ( ) ;

/ / П о л у ч е н и е ц е н ы с у ч е т о м н а л о г о в d o u b l e g e t A c t u a l T a x P r i c e ( ) ;

d o u b l e c a l c A m o u n t T a x ( ) ;

P r o d u c t * t h e P r o d u c t ;

/ / З а к а з

c l a s s O r d e r

{

p u b l i c :

O r d e r ( ) ;

На диаграмме, представленной на рис. П3.55, изображены только идентифицирующие отношения (Identifying Relationships) и список таб­ лиц совпадает с числом классов соответствующей диаграммы. Это не означает, что число классов и их структура будут всегда совпадать с ре­ ляционной моделью. Рассмотрим пример диаграммы модели данных, структура которой отличается от соответствующей диаграммы классов.

Рис. П3.56. Диаграмма заказа продукции

Построим диаграмму для заказа продукции. Соответствующая диаграмма классов представлена на рис. П3.15.

На диаграмме классов представлены классы: «Customer», «Or­ der», «OrderPositon» и «Product». Диаграмма данных будет содержать четыре одноименные таблицы и ряд дополнительных таблиц. К до­ полнительным таблицам отнесем таблицу единиц измерений, табли­ цу состояний документов и таблицу, определяющую набор состояний для конкретного документа.

Диаграмма для заказа продукции представлена на рис. П3.56. Таблица «Заказ» была названа «PROD_ORDER», потому что «ORDER» является служебным словом языка запросов SQL.

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

Рассмотрим пример создания триггера для таблицы «ORDERPOSITION». Назначение создаваемого триггера - автома­ тический расчет стоимости товарной позиции.

Для этого в окне спецификации таблицы «ORDER POSITION» перейдем на закладку «Triggers» и, воспользовавшись кнопкой «New», создадим новый триггер. Изменим системное имя триггера на «CALC_VALUES_BUI». Далее отметим события активации триггера («Trigger Event»): «Insert» и «Update». Для «Update» укажем поля «PRODUCT_ID», «MEASURE_UNIT_ID». Тип триггера («Trigger Туре») установим в «Before». Свойство «Granularity», определяющее, когда должен отрабатывать триггер, установим в «Row». В тело триг­ гера («Action Body») поместим текст, представленный ниже:

DECLARE

V_DATE DATE;

Begin

/^Определим дату заказа*/

SELECT ORDER_DATE

INTO V _DATE

FROM PROD_ORDER

WHERE I D = : NEW. O R D E R _ ID ;

/*Получим действующую цену без налогов на переданный продукт*/

:NEW.P R IC E : = F _ G E T _ C U R R E N T _ P R IC E ( :NEW.PRO DUCT _ID, :N E W .M E A SU R E _ U N IT _ ID , V _ D A T E , 0 ) ;

/*Рассчитаем сумму без налогов*/

:NEW.AMOUNT : = ROUND ( : NEW.P R IC E * : NEW.QUANTITY, 2 ) ;

CREATE TABLE PRODUCT (

ID NUMBER ( 1 0 ) NOT N U LL,

PRODUCT CODE VARCHAR2 ( 3 2 ) NOT NULL,

)

/

ALTER TABLE DEPARTMENT ADD ( CONSTRAINT FK_DEPARTMENT2 FOREIGN KEY (COMPANY_ID, O F F I C E _ I D ) REFERENCES O F F IC E

( COMPANY_ID, I D ) )

/