Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Проектирование автоматизированных информационных систем на основе о..pdf
Скачиваний:
27
Добавлен:
15.11.2022
Размер:
10.45 Mб
Скачать

Стоит отметить, что такие классы, как «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, яв­ ляются классами границ, поскольку обслуживают процессы взаимо­ действия между системой и ее окружением, обеспечивая интерфейсы

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]