刘京城 2020-4-14 23:01

。。。。(注：这是一个人的昵称，不是省略号)

首先，执行者是同一个，那么思考焦点要关注“过数”用例是不是“发放父作业单”用例的一个步骤，和行为操作的频率无关，而是和责任有关，和逻辑有关；

如果确定不是一个步骤，那么只是存在这样一个状态的变化，就是“过数”用例的执行会产生逐步改变达到“发放父作业单”用例的前置条件，你说所的过数员的期望，应该是系统提供一个任务提醒用例；

其次，思考的焦点还是应该退后一步，就是回到你的业务序列图上去，如果业务序列图上责任分配出现问题的话，那么集中在系统用例这里思考这些就是有点误入歧途了，毕竟系统用例是从业务序列图推导得到的，不应该存在这样疑惑不清的地方；既然你的序列图上存在“技术员”、“过数元”、“仓管员”、“投料工程师”这些人脑系统，但是很明显你的序列图只表达了他们使用系统的请求，但没有表达业务责任在这些人脑系统中的请求责任逻辑序列，也就是说你没有用序列图把真实的业务用例描述清楚，尤其是责任过程；

关于用例名，使用一个动宾短语来恰当的描述一个用例，本身就很难，如果不恰当的话，可以写一段备注语句来详细描述用例，不用在命名上太过耗费精力，也许哪天你会突然发现更好的名称，再改就是了。

@刘京城 看到你发的，我的一点思考，希望有帮助

还是听潘老师的

UMLChina潘加宇

发放父作业单是过数用例的步骤。它的发生频率是由“过数”的发生决定的。

这个和取现金是最后系统要出一张小票一样的，不能武断认为“不是一个事情”。

起名“过数”就可以了，后面列举的都是过数用例的步骤。

还是拿取现金类比，取现金，不只是吐钞票，还有扣除账户余额，打印收据，如果取钱的人身份有问题还要暗地报警.....这都是取现金过程中，在尽量朝储户目标迈进的前提下，根据其他涉众利益安排的情节。

京城困惑的一个根源，可能是只考虑了台上的演员，忘了照顾台下的观众。

刘京城 2020-4-15 14:38

谢谢潘老师！确实，我没想到在一个用例里面，可以安排一些情节以照顾到其它涉众的利益，尤其是当这些情节与本身这个用例感觉没多大关系时(就像暗地里报警已经跟取钱没多大关系了）

@。。。。感谢你的这些思考，对我有帮助。当时我也感觉发放父作业单有点像是一个自动任务，只是被过数触发而已，不该当作过数用例的实现。不过按潘老师那样理解也就通了。以后多交流