【问题标题】:UML Use case: Waiting for another use case to finishUML 用例:等待另一个用例完成
【发布时间】:2015-01-19 18:22:17
【问题描述】:

我正在尝试建模一个用例,基本上就是在问答节目中如何进行一轮。用例中的参与者是测验大师;他向参与者提问。

在这个用例中发生了很多事情,但我的问题归结为测验管理员必须等待玩家按下按钮并回答他提出的问题以便判断(对或错误)。

演员“候选人”有一个单独的用例来回答测验大师提出的问题。

我如何模拟测验管理员必须等待其他参与者完成用例才能继续他自己的用例的事实?还是将它们全部分成较小的用例更好。不过我的老师建议不要这样做,所以我在这里寻求第二个意见。

【问题讨论】:

标签: uml use-case-diagram


【解决方案1】:

您可以按照 user3934037 的建议进行包含,也可以将其设为单独的用例并使用前置/后置条件 在那种情况下,你会有用例

  • -> 前提条件:候选人准备就绪

    -> 后置条件:问的问题

  • 回答问题

    -> 前提条件:提出的问题

    -> 后置条件:问题已回复

  • 法官回应

    -> 前提条件:已回答问题

    -> 后置条件:响应判断

不是将用例按顺序连接在一起,而是让它们彼此独立。用例“判断响应”不是在等待特定用例完成,而是在等待先决条件得到满足,然而这已经成为现实。

一般来说,我建议在用例分析之外保留执行顺序(并将其留在业务流程建模中)

【讨论】:

    【解决方案2】:

    UseCase 声明建模系统的有用功能。没有任何方法可以定义您在示例中描述的执行方面。 如果您需要定义一些事件处理或动作,请使用一些行为元素(Activity、StateMachine 或 Interaction)。

    【讨论】:

      【解决方案3】:

      我同意 Geert 的观点,但我会更强烈地建议他的方法。用例并非旨在解释任何类型的流程、时期。您可以使用前置条件和后置条件来推断执行顺序,但如果您想清楚地了解用例的执行顺序,请采纳 Vladimir 的建议并用活动图将其映射出来。

      【讨论】:

      • @xmojmr:你说的很对。我已经删除了最后两段。感谢您的关注!
      【解决方案4】:

      我想先说这个.. UML 中没有正确的答案。如果你能用你的 uml 图正确地解释你的想法,那就是答案。 我认为这可以通过 include>> 关系来解决。 CaseA ---include>>-->CaseB 表示满足CaseB 时可以执行CaseA。

      例如,

      “从账户中取款”----包括>>---->“验证用户”

      我猜它也可以用来描述每个用例的顺序。 :)

      【讨论】:

      • Include 只表示在执行包含用例时必须执行包含用例。它没有指定任何顺序。
      【解决方案5】:

      UML 明确地没有通过推荐 (AFAIK) 来满足这种需求。这似乎表明您当前的用例分析中有一些奇怪。也许使用design scopesgoal levels 将您的用例图结构化为多个详细级别会消除排序

      这就是 Alistair Cockburn 在“用例目标与设计范围”一文中建议平衡用例密度的方法

      另见:

      【讨论】:

        猜你喜欢
        • 2017-06-15
        • 2021-07-13
        • 1970-01-01
        • 2021-01-02
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多