【问题标题】:How to describe algorithms when doing Use Cases?做用例时如何描述算法?
【发布时间】:2010-07-16 13:31:04
【问题描述】:

假设我正在为具有评分系统的游戏制作Use Case。您在游戏中所做的每个动作都会增加/减少您在游戏中的分数。

这是我Use Case的草图:

1. ...
2. ...
...
8. The Player makes (some move).
9. The System registers the play and calculates his new score.

计算这个新分数的背后有一些算法。我应该在Use Case 中说明吗?我应该在另一个Use Case 中声明吗?我应该简单地省略算法实现的细节吗?

Use Case 是陈述这些事情的正确位置吗?还是应该Use Case 只关心PlayerSystemGame)之间的交互?

我想说我可能想在某处写下这些细节(如果不仅仅是为了确保我真的理解它们)。所以在我看来,也许最好的选择是制作另一个用例来描述它们的工作原理?

Use Cases 通常如何处理这些事情?谢谢

【问题讨论】:

    标签: oop uml use-case


    【解决方案1】:

    算法不是用户和系统之间的交互以创造价值。

    它们是用例的脚注或附录。

    它们通常很重要,但它们不是互动。因此将它们放在附录中。


    还有。所有用例均由 Actor 发起。他们的演员想玩他们的游戏;他们发起的事情。系统通常不能启动动作——它是被动的,对参与者做出响应。

    【讨论】:

    • 另一个问题。当游戏开始时,当前分数设置为零。我应该定义一个声明或不声明的操作吗?根据我从您的回答中了解到的情况,我会说不。
    • 我可以双向争论。我认为说“系统开始新游戏,分数设置为 0”没有任何害处
    • 另外,在系统发送第一条消息的情况下启动用例是否有意义?
    • 参与者启动用例。时期。演员开始游戏。游戏响应 Actor
    • 如果有系统打电话让我玩,我会换药!
    【解决方案2】:

    算法不属于用例。将它们提取到业务规则部分或文档中。

    【讨论】:

      【解决方案3】:

      我建议您使用活动图来表示算法,并在这种情况下让您的用例步骤保持简单。 我也同意“Johann Strydom”的立场。

      狮子座

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2017-02-02
        • 1970-01-01
        • 2013-01-29
        • 2016-07-08
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多