【问题标题】:UML Use Case Diagram - Raffle SystemUML 用例图 - 抽奖系统
【发布时间】:2017-07-22 13:23:00
【问题描述】:

在这个用例图中,我试图展示抽奖管理员如何在客户进入抽奖后查看更新的抽奖列表。一旦客户进入抽奖,系统将验证并检查重复,如果没有重复,将更新抽奖列表。

下图是我对场景的尝试,但是我不确定它是否正确。你能告诉我吗?

编辑:我有几个问题:

1) 如果我使用抽奖系统本身来验证抽奖条目,我不需要放一个用例进行验证,因为抽奖系统不是演员对吗?

2) 但是,如果演员是抽奖系统的另一位工作人员(他或她手动整理抽奖),验证用例是否适用?

3) 如果是这样,这是说明 (2) 的正确图表吗?

Update entry -- <<includes>> --> Verification

【问题讨论】:

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


    【解决方案1】:

    您的图表有几个错误:

    • System 绝不是外部参与者。它在边界所代表的系统内部起作用。
    • 因此Verification不是一个有效的用例。这是一些内部功能。
    • &lt;&lt;extend&gt;&gt; 反过来工作(将指向另一侧的箭头移动)。
    • &lt;&lt;include&gt;&gt; 也一样。
    • Verification 不是用例的名称。它需要谓词/主语和可选的宾语。
    • 泛化(到 Update entry)对于 UC 来说是个坏主意,而且可能不是您想在这里展示的(那么这里的意图是什么?)。
    • 基本上,UC 旨在为其主要参与者带来附加值。它们与所涉及的功能无关。尽量集中注意力,避免任何倾向于功能分解的事情!

    编辑

    1. 没错。
    2. 如果有人这样做,你就有一个演员和这样一个 UC(尽管应该正确命名)。
    3. 这可能是正确的。 是否正确取决于所考虑的系统的要求(您最终想要达到的目标)

    【讨论】:

    • 您好,非常感谢您的解释!你能看看更新的帖子吗?关于您的解释,我有几个问题。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-07-25
    • 2014-06-11
    • 1970-01-01
    • 2014-07-11
    • 1970-01-01
    相关资源
    最近更新 更多