Как использовать UML для построения диаграмм системных интерфейсов?

Я изучаю UML и читал о вариантах использования. Все примеры, которые я вижу, относятся к одной системе, и мне было интересно, как можно смоделировать сквозной процесс. Итак, я составил довольно типичный корпоративный сценарий и попытался его смоделировать. У меня есть вопросы, на которые я не смог ответить.

Сценарий. В моем бизнес-варианте покупатель создает корзину, которую продавец получает как заказ.

Поток процесса от начала до конца:

  1. Покупатель создает корзину
  2. Менеджер просматривает корзину и одобряет/отклоняет, и в системе закупок создается заказ на покупку.
  3. Система закупок отправляет все вновь созданные заказы на покупку в системы соответствующих поставщиков.
  4. Поставщик получает заказ на покупку как заказ.

Однако дьявол кроется в деталях, поэтому я решил усложнить его, добавив следующие детали:

  1. Коммуникация системы покупки-покупки является точечной и в режиме реального времени.
  2. Заказ на покупку можно отправить поставщику по факсу или через Интернет. Все заказы помещаются в очередь перед отправкой поставщику. Очередь обрабатывается каждые X минут. Я выбрал 10 минут в качестве интервала
  3. Соединение покупатель-поставщик использует промежуточное ПО (ESB).

Вопросы:

  1. Я считаю, что у меня есть 3 варианта использования системы: покупатель-создает корзину, менеджер-просматривает корзину, время-отправляет заказ на покупку поставщикам. Верно ли это, даже если у меня есть система ESB между системой закупок и системой поставщика?
  2. Поскольку промежуточное ПО не является действующим лицом в одном из приведенных выше вариантов использования, где мне следует моделировать участие ESB в процессе (Закупки->ESB, ESB->Поставщик)?
  3. Я рисую 2 границы системы или 1 границу системы? Я считаю, что у меня должна быть Система Продавца как второстепенное действующее лицо, поэтому у меня есть только Система Покупок и Система Покупок. Или я могу объединить их в систему E2E (например, систему закупок)?

interface use-case esb uml
person PatrickSJ    schedule 28.06.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

  1. Я бы создал отдельные варианты использования для просмотра, утверждения и отклонения корзины, но в остальном я думаю, что ваши варианты использования должны быть достаточно точными. Поскольку система ESB напрямую не используется вашими субъектами, я не думаю, что она уместна в диаграмме вариантов использования.
  2. Вы можете создать диаграмму компонентов для более подробного моделирования отношений между отдельными системами и их подсистемами. это возможно или разумно в диаграмме вариантов использования. Если вы хотите, вы, вероятно, могли бы изолировать ESB в его собственной системной границе с вариантом использования «Доставить заказ на поставку поставщику», отмеченным как зависимость для вариантов использования, связанных с соединением.
  3. Я предлагаю две или три границы системы, в зависимости от того, создаете ли вы собственную границу для ESB. Если система поставщика выходит за рамки вашей компетенции, вам, вероятно, не потребуется слишком подробно моделировать ее — достаточно получить заказ на поставку.
person Kaivosukeltaja    schedule 30.06.2012
comment
2. Это удалось заставить работать с диаграммой последовательности, которая помогла мне смоделировать прослушивание/публикацию, и диаграммой действий для обработки ошибок в случае использования PO. Для варианта использования «Корзина покупок» > «Заказ на покупку» диаграмма компонентов, кажется, работает. - person PatrickSJ; 03.07.2012

arrow_upward
0
arrow_downward

Варианты использования предназначены для описания того, как пользователи системы (действующие лица) взаимодействуют с системой. Они должны быть достаточно простыми, чтобы ваш клиент мог их понять. Поэтому, прежде чем вы начнете ломать голову вопросами о вариантах использования, спросите себя, кто ваш клиент и как вы создаете для него лучшую систему, создавая вариант использования.

(извините за философский ответ...)

person vainolo    schedule 30.06.2012