Диаграмма вариантов использования UML, другой актер для зрителя?

Мне интересно, правильная ли моя диаграмма вариантов использования, и может ли кто-нибудь дать мне несколько советов, если это не так.

Это для приложения, в котором пользователи могут войти в систему (всегда требуется). Когда они входят в систему, они видят список сообщений, за которые они могут голосовать как за, так и против (как на Reddit). При выборе поста они могут оставлять и удалять (только свои) комментарии.

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

Наконец-то появился администратор, который может удалять неуместные сообщения и комментарии.

Должен ли я определить, что пользователи могут редактировать и удалять только свои собственные сообщения и комментарии? Если да, то как мне это сделать? Может другой актер?

Заранее спасибо!

Диаграмма


use-case uml
person Community    schedule 30.05.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В ваших UC есть пара недостатков.

  1. Логин вообще не является UC (он не добавляет актору никакой ценности). Это ограничение, которое вы можете применить к UC.
  2. Неверное имя пользователя/пароль, конечно, не UC. Это какое-то сообщение, которое где-то всплывет.
  3. Регистр сам по себе является UC. Подключите его напрямую к пользователю.
  4. Использование обобщения с UC не является хорошей идеей, так как это принесет много материала для обсуждения. Оставьте его на уровне Manage и опишите внутри UC, что это значит.
  5. <<include>> обычно используется неправильно (а именно для функциональной декомпозиции). И вы тоже это делаете. Так что оставьте это в стороне, сконцентрируйтесь на основном UC Manage comments и свяжите его напрямую с актером.

Если по какой-то причине вам нужно описать какой-то порядок для UC, вы можете использовать предварительные условия внутри UC.

person qwerty_so    schedule 30.05.2016

arrow_upward
1
arrow_downward

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

Поскольку в вашей системе комментирование является необязательным, вы определенно использовали неверные отношения. include означает, что включенный UC будет всегда выполняться при выполнении, включая UC. В вашем случае это зависит от решения пользователя, что означает, что вместо этого вы должны использовать extends (и, конечно, в этом случае отношение в противоположном направлении). См. 18.1.3.2 (второй абзац) и 18.1.3.3 (первый абзац). Вы также можете найти подтверждение этого почти в любой книге об анализе на основе UML (например, «UML для бизнес-аналитика» Говарда Подесвы, чтобы назвать один)

Кроме того, я согласен со списком недостатков, приведенным Томасом Килианом.

person Ister    schedule 31.05.2016