【问题标题】:How to portray visibility in Use Case Diagram如何在用例图中描绘可见性
【发布时间】:2021-01-30 23:25:54
【问题描述】:

上下文

想象一个活动管理网站,活动策划者可以在其中发布活动。假设我们有三个 Actor:non-registered userregistered userEvent Planner。活动策划者可以发布活动,可以是公开的(非注册用户可以看到)或私人的(只有注册用户可以看到)。

问题

我如何描述所有用户都可以看到公共事件而只有注册用户可以看到私人事件的事实?

附加问题:我应该将“查看即将发生的事件”和“查看过去的事件”分成两个不同的用例还是应该有一个“查看事件” " 用例?

我的一些想法

以下图表是我想到的一些潜在解决方案,但我不确定它们的正确性。

有单独的用例

使用扩展

将“查看事件”作为总体用例

【问题讨论】:

  • 您忘记了(最好的恕我直言)选项只有一个用例查看事件。您可以在场景描述中指定非注册用户只能看到公共事件。无需为此创建不同的用例。

标签: uml use-case use-case-diagram


【解决方案1】:

您要么接受 Geert 的建议并仅使用 See events 用例,要么应保留第一个用例。是否将See events 拆分为私有/公共在很大程度上取决于您正在设计的系统。因此,考虑到需要拆分(因为这两个事件的处理方式会非常不同),您应该使用您的第一个草图。在这里很清楚谁可以处理哪个UC。只需一个 UC,您就可以附加一个约束,例如 {only registered user can see private events}

您的第二个似乎没有意义。 «extend» 是多余的,因为参与者已经与用例有直接关系。这种关系意味着扩展用例是在事件过程中选择性地执行的。因此,在观看私人活动的同时,也可以看到公共活动。

最后一个建议只是功能分解。与参与者没有联系的用例不是用例,因为它不会带来附加值。您可以使用通用用例(私有/公共是 See event 的特化),但我始终建议不要使用该构造。 UCs 的泛化有点矛盾。 UC 应显示为所考虑系统的参与者带来的独特附加值。但是,如果您可以概括,那么它并不是真正独特的。与明确定义属性/操作覆盖的类泛化不同,UC 缺少这样的描述,需要进行大量解释。

【讨论】:

  • 你能举个例子,你认为什么时候像这样拆分用例是明智的,什么时候不明智?
  • 没有简单的规则/示例。如果您对私人/公共事件的处理方式非常不同,您会这样做。从我的角度来看,我认为处理是相同的,只是私人事件被锁定,所以你应该使用单个 UC 和约束。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-06
  • 1970-01-01
  • 1970-01-01
  • 2015-05-17
  • 2020-02-28
相关资源
最近更新 更多