我正在尝试建模一个用例,基本上就是在问答节目中如何进行一轮。用例中的参与者是测验大师;他向参与者提问。
在这个用例中发生了很多事情,但我的问题归结为测验管理员必须等待玩家按下按钮并回答他提出的问题以便判断(对或错) .
演员“候选人”有一个单独的用例来回答测验大师提出的问题。
我如何模拟测验管理员必须等待另一个参与者做一个用例才能继续他自己的用例的事实?还是将它们全部分成较小的用例更好。我的老师建议不要这样做,所以我在这里寻找第二个意见。
我正在尝试建模一个用例,基本上就是在问答节目中如何进行一轮。用例中的参与者是测验大师;他向参与者提问。
在这个用例中发生了很多事情,但我的问题归结为测验管理员必须等待玩家按下按钮并回答他提出的问题以便判断(对或错) .
演员“候选人”有一个单独的用例来回答测验大师提出的问题。
我如何模拟测验管理员必须等待另一个参与者做一个用例才能继续他自己的用例的事实?还是将它们全部分成较小的用例更好。我的老师建议不要这样做,所以我在这里寻找第二个意见。
您可以按照 user3934037 的建议进行包含,也可以将其设为单独的用例并使用前置/后置条件在这种情况下,您将拥有用例
问问题
-> 前提条件:候选人准备就绪
-> 后置条件:问的问题
回答问题
-> 前提条件:提出的问题
-> 后置条件:问题已回复
法官回应
-> 前提条件:已回答问题
-> 后置条件:响应判断
不是将用例按顺序连接在一起,而是让它们彼此独立。用例“判断响应”不是在等待特定用例完成,而是在等待满足先决条件,然而那是。
一般来说,我建议将执行顺序保留在用例分析之外(并将其留在业务流程建模中)
UseCase 声明建模系统的有用功能。没有任何方法可以定义您在示例中描述的执行方面。如果您需要定义一些事件处理或动作,请使用一些行为元素(Activity、StateMachine 或 Interaction)。
我同意 Geert 的观点,但我会更强烈地建议他的方法。用例并非旨在解释任何类型的流程、时期。您可以使用前置条件和后置条件来推断执行顺序,但如果您想清楚地了解用例的执行顺序,请采纳 Vladimir 的建议并用活动图将其映射出来。
我想先说这个.. UML 中没有正确的答案。如果你能用你的 uml 图正确地解释你的想法,那就是答案。我认为这可以通过 << include >> 关系来解决。CaseA ---<< include >>-->CaseB 表示满足CaseB 时可以执行CaseA。
例如,
“从账户中取款”----<<包括>>---->“验证用户”
我想它也可以用来描述每个用例的顺序。:)