книги / Проектирование автоматизированных информационных систем на основе объектно-ориентированного подхода
..pdfДля реализации работы пользователя с накладными вводятся гра ничные классы. При этом необходимо помнить, что работа с наклад ными осуществляется как в офисе, так и на складе. Набор опций, предоставляемый офисной формой (бухгалтерский модуль), отлича ется от набора опций складской формы (АРМ кладовщика), но ряд опций одинаков для обеих форм. Поэтому создадим базовый класс «WaybillForm» (форма работы с накладной), содержащий следующие общие операции для обеих форм:
-select () (выделить накладную);
-display() (отобразить атрибуты накладной);
-find() (найти накладную);
-changeStatus() (state: char *) (изменить статус накладной). Затем создадим производные классы от «WaybillForm»: «Waybill-
OfficeForm» и «WaybillWarehouseForm» (рис. П3.23).
Рис. П3.23. Отношение наследования для форм работы с накладными
Операции производных классов не нуждаются в комментариях (так как аналогичны тем операциям, которые использовались при описании заказа), за исключением операции «displayPositions», кото рая отображает на экране позиции выбранной накладной, и операции «changeDisplayList()», обеспечивающей переход накладной из одного списка в другой при изменении статуса накладной.
Бухгалтер, в отличие от кладовщика, имеет возможность моди фицировать накладную, включая ее строки. Поэтому необходимо создать еще один класс поддержки работы со строками (рис. П3.24).
Рис. П3.24. Опции формы бухгалтерского модуля
Рис. П3.25. Опции работы с накладными
По аналогии с заказами создаются классы управления: «WaybillWarehouseControl», «WaybillOfficeControl», «WaybillOfficePosControl». Полная диаграмма классов работы с накладными пред ставлена на рис. П3.25.
В разд. 4.2 содержится полное описание процедуры возврата то вара клиентом. При этом создается документ - акт возврата товара. Система, как и в ранее описанных случаях работы с документами, предоставляет стандартный набор опций: создание, удаление, печать акта и т.д. Из новых опций только одна - печать договорного согла шения. Данная операция называется «printAgreement» и заключается в создании твердой копии договорного соглашения с содержимым, приведенным в разд. 4.2.
Структура класса «RetumAct» (акт возврата) аналогична структу ре накладной и заказа. Акт содержит некоторую шапку, в которой указывается номер и дата акта, а также подробное описание причины возврата, т.е. выявленного дефекта, и товарные позиции/строки, ко торые содержат информацию о количестве возвращаемого товара.
Рис. П3.26. Диаграмма классов акта возврата товара
Структура и связи акта представлены на рис. П3.26.
Планирование поставок очередной партии товара для дальней шей реализации - одна из самых важных задач, решаемая аналитика ми, экономистами и логистами. От того, насколько оптимально будет выстроена цепочка поставок, зависит финансовый результат деятель ности предприятия.
Мы не будем заострять внимание на разработке интерфейса и форм обработки данных, а рассмотрим структуру самого плана закупок.
Каждый план составляется на определенный период планирования и утверждается руководителем предприятия. Пока этот период не ис тек, план является действующим. По истечении периода план закрыва ется. Поэтому класс «PurchasePlan» (план закупок) должен иметь ат рибуты, определяющие период действия плана и его статус, а также номер и дату составления плана для идентификации в системе:
-planNumber (номер плана);
-planDate (дата составления);
-startDate (дата начала действия плана);
-finishDate (дата окончания действия плана);
-status (статус плана).
Рис. П3.27. План закупок
План составляется для каждой номенклатурной позиции. Поэто му необходимо создать еще один класс, который бы детализировал
плановое количество по каждой товарной позиции. Назовем данный класс «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).
Выписка накладной |
Выписка накладной |
(from Logical View ) |
|
Рис. ПЗ.ЗО. Реализация прецедента «Выписка накладной»
2:displayf)
------ >
Рис. П3.31. Печать накладной. Диаграмма сотрудничества
Rational Rose позволяет автоматически создавать диаграмму со трудничества по диаграмме последовательностей и наоборот. Прове рим, как это работает на практике. Создадим несложную диаграмму последовательностей для сценария регистрации сотрудника предпри ятия в системе управления складом (рис. П3.32).
Employee : LoainForm : Svstem llser
1 |
---------------------- |
|
|
|
|
|
inputNameQ |
|
|
|
display |
|
inputPassword() |
i==i |
checkUserQ
register^)
Tl
Рис. П3.32. Регистрация в системе. Диаграмма последовательностей
Затем с помощью меню «Browse» > «Create Collaboration Dia
gram» создадим диаграмму сотрудничества (рис. ПЗ.ЗЗ).
2: display 4: checkUser()
Рис. ПЗ.ЗЗ. Регистрация в системе. Диаграмма сотрудничества
Диаграмма состояний определяет последовательность состояний объекта, вызванных последовательностью событий.
Рассмотрим построение диаграммы для объектов класса «Order» (заказ).
Из спецификации прецедентов следует, что заказ может быть в трех состояниях: «Новый», «Оплаченный» и «Отмененный». В со стояние «Новый» заказ попадает сразу после своего создания и нахо дится в нем до момента перевода его менеджером в состояние «Опла ченный». Событием к переходу является поступление денег в кассу или на расчетный счет предприятия. Условие перехода - оплата долж на производиться не позднее 10 дней со дня оформления заказа. В случае если оплата не производится или производится позже, отве денных 10 дней, заказ переходит в состояние «Отмененный». Соот ветствующая диаграмма состояний представлена на рис. П3.34.
Рис. П3.34. Диаграмма состояний заказа
Далее рассмотрим построение диаграммы состояний для товарно транспортной накладной. Все вновь созданные накладные попадают в состояние «Новая». После печати накладной она переходит в со стояние «Выписанная». В этот момент электронная накладная стано вится доступной кладовщику на складе, и он начинает сборку заказа. По окончании сборки кладовщик переводит накладную в состояние «Готовая». Если по каким-то причинам на складе не оказалось нуж ного товара (брак в партии, просрочка поставщика и т.п.), что делает невозможным сборку заказа, накладная переходит в состояние «При
остановленная». После того как товар отгружен клиенту, накладная переходит в состояние «Отгруженная». Диаграмма состояний для на кладной изображена на рис. П3.35.
Рис. П3.35. Диаграмма состояний для накладной
Диаграмма состояний для плана закупок содержит три состояния: «Новый», «Утвержденный» и «Закрытый» (рис. П3.36). В состояние «Новый» план попадает сразу после своего создания, в состояние «Утвержденный» - после утверждения. По истечении периода дейст вия план переходит в состояние «Закрытый».
