книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода

Стоит отметить, что такие классы, как «Guardian» (охранник), «Driver» (водитель/экспедитор), не являются пользователями систе­ мы, хотя могут фигурировать в различных документах, формируемых системой.

Итогом проделанной работы служит диаграмма классов, представ­ ленная на рис. П3.10. Данная диаграмма полностью определяет струк­ туру предприятия, включая распределение сотрудников по отделам.

5.2. Контрагенты предприятия оптовой торговли

Мы рассмотрели структуру предприятия оптовой торговли. Это предприятие взаимодействует с покупателями, поставщиками, грузоперевозчиками и другими контрагентами. В связи с этим имеет смысл создать отдельный класс «Contractor» (контрагент). Классы «Customer» (покупатель), «Supplier» (поставщик), «Carrier» (перевоз­ чик) и другие будут являться потомками класса «Contractor».

Атрибуты класса «Contractor» следующие:

-name (название контрагента);

-INN (ИНН);

-juridicalAddress (юридический адрес);

-postAddres (почтовый адрес);

-phoneNumber (телефонный номер);

-faxNumber (номер факса);

-contactPerson (представитель контрагента или первое лицо);

-eMail (адрес электронной почты);

-note (примечание).

На рис. П3.11 представлена структура класса «Contractor» и его потом­

ков.

Каждый из контрагентов может иметь один и более расчетных счетов. Расчетный счет будет выделен в отдельный класс. Этот класс назовем «BankAccount» (счет в банке). Атрибуты данного класса представлены ниже:

-account (расчетный счет);

-bankName (название банка);

-corrAccount (корреспондирующий счет);

-INN (ИНН банка);

-BIC (БИК банка);

-city (город);

otherProps (прочие реквизиты).

Рис. П3.11. Контрагент

Класс «Contractor» ассоциативно связан с классом «BankAccount» (рис. П3.12). Кратность ассоциации, проставленная на линии связи, означает, что любой контрагент может иметь несколько расчетных счетов либо не иметь их вообще.

Рис. П3.12. Расчетный счет контрагента

Company

^► name char* <VlNN float

^juridicalAddress char*

^► postAddress char*

1

^► phoneNumber • char* ^► faxNumber ■ char*

	BankAccount
^►	account char*
^►	bankName		char*
^►	corrAccount		char*
3HNN		float
1 . . П fi^BIC		float
^ c ity		char *
^►	otherProps		char*

Рассматриваемое нами предприятие оптовой торговли, в отличие от контрагента, должно иметь как минимум один расчетный счет, по­ скольку предоставляет своим клиентам возможность безналичного расчета. Соответствующий фрагмент диаграммы классов представлен на рис. П3.13.

5.3. Продукция предприятия оптовой торговли

Предприятие оптовой торговли занимается реализацией партий продукции различных производителей. Класс, описывающий специ­ фику конкретного продукта, назовем «Product» (продукт/товар). Ат­ рибуты данного класса следующие:

-productCode (уникальный код продукта);

-паше (название продукта);

-description (описание продукта);

-producer (производитель);

-itemWeight (вес одной единицы).

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

Мы будем классифицировать продукт вторым способом, который заключается в сочетании методов агрегирования и наследования. Связь агрегирования используется для отображения принадлежности класса «Product» к некоторому базовому типу, например «РгоductClassification» (классификация продукта), который уточняется с помощью производных типов «HomeTechniques2» (бытовая техни­ ка), «ComputerTechniques» (оргтехника) и другие (рис. П3.14).

5.4. Заказ продукции

Клиент согласовывает свой заказ с менеджером (в дальнейшем, при развитии системы, заказ может быть оформлен через глобальную сеть Internet без участия менеджера). Заказ и его позиции тоже пред­ ставляют собой отдельные сущности, которые отражают дату по­ ставки, количество и номенклатуру товара. Класс, отражающий спе­ цифику заказа, назовем «Order», а его позиции - «OrderPosition». Эти классы находятся в отношении агрегации (рис. П3.15), поскольку строки заказа являются неотъемлемой частью самого заказа.

Класс «Order» содержит атрибуты:

-orderNumber (номер заказа);

-orderDate (дата заказа);

-shipmentDate (дата отгрузки);

-priority (приоритет);

-status (состояние/статус).

Также класс «Order» включает четыре операции:

-calcAmount() (расчет и выдача денежной суммы по строкам заказа);

-са1сТах() (расчет и выдача суммы налогов по строкам заказа);

-calcTotalAmountO (расчет и выдача полной стоимости заказа);

-calcPosQuantity() (расчет числа позиций продукции по строкам заказа).

Класс «OrderPosition» содержит атрибуты:

-quantity (количество);

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

-price (цена);

-taxPrice (цена с налогами);

-amount (сумма);

-taxAmount (сумма с налогом);

иоперации:

-getActualPriceO (получение действующей цены из прайс-листа);

-getActualTaxPrice() (получение действующей цены с налогом);

-calcAmount (расчет суммы);

-calcTaxAmount (расчет суммы с налогом);

-printBill (сформировать счет на оплату по безналичному расчету);

-printCashBill (сформировать счет для оплаты наличными).

Каждая строка заказа ассоциируется с соответствующим продук­ том (см. рис. П3.15).

Оплата заказа производится наличным или безналичным расче­ том. В обоих случаях клиенту выписывается соответствующий счет на оплату. Структура оплаты представлена на рис. П3.16.

Рис. П3.15. Заказ продукции

На диаграмме, изображенной на рис. П3.16, представлены три новых класса: «Payment» (оплата), «Cash» (наличные) и «ВапкВШ» (безналичный расчет). Класс «Payment» содержит два атрибута:

-paymentDate (дата платежа);

-taxAmount (сумма платежа, включая налоги).

Производные классы «Cash» и «ВапкВШ» определяют вид оплаты. Из диаграммы также следует, что оплата заказа может быть смешанной.

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

-add() (создать новый заказ);

-select() (выделить заказ);

-delete() (удалить выделенный заказ);

-confirmDelete() (запросить подтверждение на удаление выде­ ленного заказа);

-find() (найти заказ по заданным параметрам);

-changeStatus(status: char *) (изменить статус заказа);

-printBankBill() (печатать счет для оплаты через банк);

-printCashBill() (печатать счет для оплаты наличными);

-getProductNetsO (определить остатки по запрошенным продуктам);

-displayOrder() (отобразить атрибуты заказа).

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

Класс «OrderForm» связан отношением агрегирования (рис. П3.17) с классом «OrderPosForm» (форма работы с позициями/строками зака­ за). Класс «OrderPosForm» реализует опции работы со строками заказа. Его операции представлены ниже:

-add() (добавить строку заказа);

-select() (выделить строку заказа);

-deleteQ (удалить строку заказа);

- confirmDelete() (запросить подтверждение на удаление пози­ ции заказа);

-displayPosOrderQ (отобразить атрибуты позиции заказа).

Рис. П3.17. Опции формы работы с заказами

Рис. П3.18. Опции работы с заказами

Стоит отметить, что классы, представленные на рис. П3.17, яв­ ляются классами границ, поскольку обслуживают процессы взаимо­ действия между системой и ее окружением, обеспечивая интерфейсы

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

В спецификации соответствующих прецедентов было указано, что большинство операций с заказами контролируются системой. Поэтому имеет смысл создать классы управления: «OrderControl» (контроль за­ каза) и «OrderPosControl» (контроль строки заказа) - и возложить на них обязанности по контролю за потоком событий. Оба класса выде­ лены стереотипом «control» и содержат некую операцию проверки/подтверждения корректности выполнения действий над заказами и их строками. Назовем данную операцию «submit()». Класс «OrderPos Control» содержит дополнительную операцию «getNet(productCode: char *): double», позволяющую определить остаток по продукту при создании новой строки заказа. Остаток в общем случае рассчитывается вычитанием из прихода товара его расхода и оплаченных, но неотгруженных заказов. Если остаток меньше затребованного количества, то соответствующая строка заказа создана не будет.

Диаграмма классов, объединяющая классы, относящиеся к оформ­ лению заказа, представлена на рис. П3.18.

5.5. Накладная на получение товара

Следующим важным документом, который необходимо рассмот­ реть, является товарно-транспортная накладная. Класс, соответствую­ щий накладной, назовем «Waybill». Товарно-транспортная накладная ассоциирована с получателем и отправителем груза (рис. П3.19).

Рис. П3.19. Ассоциация накладной с грузополучателем и грузоотправителем

Класс «Waybill» содержит следующие атрибуты:

-wbNumber (номер накладной);

-wbDate (дата накладной);

-amount (сумма);

-taxAmount (сумма с налогом);

-netWeight (вес нетто);

-totalWeight (вес брутто по накладной);

-priority (приоритет);

-status (статус накладной);

-factShipmentDate (дата фактической отгрузки);

-factShipmentTime (время фактической отгрузки);

-responsGive (ФИО материально ответственного лица, отпус­ тившего груз);

-cargoRecip (ФИО лица, принявшего груз);

-note (примечания, комментарии);

атакже операции:

-getNetWeight() (получить вес нетто по позициям/строкам на­ кладной);

-getTotalWeight() (получить вес брутто по позициям/строкам накладной).

Накладная, как и заказ, содержит строки, связанные с ней отно­ шением агрегирования (рис. ИЗ.20).

Рис. П3.20. Накладная на отпуск продукции

Класс «WaybillPosition» (строка накладной) содержит атрибуты:

-quantity (количество);

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

-tareWeight (вес упаковки);

-tareKind (вид упаковки);

-price (цена);

-taxPrice (цена с налогом);

-amount (сумма);

-taxAmount (сумма с налогом);

-note (примечания, комментарии).

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

На рис. П3.21 представлена диаграмма классов, на которой изо­ бражены связи накладной с заказом.

Рис. П3.21. Связь накладной с заказом

Позиция накладной, как и позиция заказа, ассоциирована с про­ дуктом (рис. П3.22).

W a y w b illP o s itio n	-----------------	P ro d u c t
1	1