我正在尝试为用例建模,基本上就是如何在测验节目中播放一轮。用例中的演员是测验主持人;他向参与者提问。
在这个用例中有很多事情发生但我的问题归结为quizmaster必须等待玩家按下他的按钮并回答他所问的问题才能判断(对或者错了)。
演员“候选人”有一个单独的用例来回答问答主管提出的问题。
我如何模拟quizmaster在继续使用自己的用例之前必须等待另一个actor进行用例的事实?或者将它们全部分成更小的用例更好。我的老师建议反对,尽管我在这里寻找第二意见。
答案 0 :(得分:4)
您可以使用建议的用户3934037进行包含,也可以将其设置为单独的用例并使用前/后条件 在这种情况下,你会有用例
提问
- >前提条件:候选人准备好了
- >后置条件:提出问题
回答问题
- >前提条件:提出问题
- >后置条件:问题已回复
判断回复
- >前提条件:回答问题
- >后置条件:回答判断
不是将序列中的用例链接在一起,而是将它们彼此独立。用例“判断响应”不等待特定用例完成,它等待直到满足前提条件,然而这就是。
总的来说,我建议保持执行顺序不被用例分析(并将其保留在业务流程建模中)
答案 1 :(得分:3)
UseCase声明建模系统的有用功能。没有任何方法可以像您在示例中描述的那样定义执行方面。 如果您需要定义一些事件处理或操作,请使用一些行为元素(Activity,StateMachine或Interaction)。
答案 2 :(得分:3)
我同意Geert的意见,除了我会更强烈地建议他的做法。用例并不是为了解释任何类型的流量,周期而设计的。您可以使用前置条件和后置条件来推断执行的顺序,但是如果您想要清楚地了解用例的执行顺序,请参考Vladimir的建议并使用活动图将其映射出来。
答案 3 :(得分:2)
我想先说一下..在UML中没有正确的答案。如果你能用你的uml图正确解释你的思想,那就是答案。 我认为这可以通过<< include >>来解决。关系。 CaseA ---<< include >> - > CaseB表示在满足CaseB时可以执行CaseA。
例如,
“从帐户中提取资金”----<< include >> ----> “验证用户”
我想它也可以用来描述每个用例的顺序。 :)
答案 4 :(得分:0)
UML明确没有通过推荐(AFAIK)来满足这种需求。它似乎表明您当前的用例分析中存在奇数。也许使用design scopes和goal levels将用例图构建到几个细节级别将消除排序
这就是Alistair Cockburn建议在“用例目标与设计范围”一文中平衡用例密度的方法
另见: