勤瘦(216***56) 16:07:47
潘老师 如果一个系统用例有两个执行者 用例文档应该怎么写呢
吴家龙.NET(7791**62) 16:08:46
画两个小人，是不是啊？
灰色偏灰(334***33) 16:09:32
没听过课么？
apollo(2423**86) 16:11:11
一般情况下，两个角色由于偏重点不同，可能不会是一个用例
勤瘦(216***56) 16:12:29
两年前听过一次公开课 没在教材上找到相关描述 最新版本的软件方法中也没找到
潘加宇(3504847) 16:13:20
你要先说清楚，是两个"主执行者"？
潘加宇(3504847) 16:15:06
参见软件方法P。194
勤瘦(216***56) 16:15:51

勤瘦(216***56) 16:16:13
这种情况 是否可以认为Use Case2有两个主执行者
潘加宇(3504847) 16:18:08
首先，被包含的子用例要被多个用例包含才有意义
潘加宇(3504847) 16:19:15
如果被包含的子用例被多个针对不同执行者的用例包含
潘加宇(3504847) 16:20:00
那么这个子用例也是属于所有这些执行者的
潘加宇(3504847) 16:20:58
用例图上，指向这个子用例的是执行者的超类
潘加宇(3504847) 16:22:10
不过我猜想你的问题根本与此无关，而是犯了错误
潘加宇(3504847) 16:22:39
可以把具体的执行者和用例贴出来看看
勤瘦(216***56) 16:28:53

这是业务用例序列图
勤瘦(216***56) 16:29:31
这张图是否含有错误？
潘加宇(3504847) 16:30:20
par loop可以去掉
你要研究的是客服系统对吧
映射得到两个用例是独立的，哪里来的include
向日葵(10078161) 16:30:24
这应该是两个用例吧
潘加宇(3504847) 16:31:09
include是整理用例文档用的，从文档得来，怎么可能从业务序列图得来吗
勤瘦(216***56) 16:31:10
我画系统用例图时并没有使用include 只是想在群里请教一下是否可以那样画
潘加宇(3504847) 16:31:19
可以
勤瘦(216***56) 16:31:34
我还没说完呢。。。。
潘加宇(3504847) 16:31:37
你这个问题和你刚才的问题是一个问题吗
勤瘦(216***56) 16:31:59
是呀 您等我说完了
勤瘦(216***56) 16:34:03
从业务序列图可以推导出有两个系统用例 但是"UC:查询合作方信息"的主路径中又包含一个扩展路径 也是同步合作方 设置其的目的是 当用户没有查询到合作方信息时可以手动执行一次合作方同步
潘加宇(3504847) 16:35:10
然后，你觉得找合同管理系统提取数据是不是子用例？
勤瘦(216***56) 16:35:37
扩展路径的步骤跟"UC:同步合作方"的步骤是一样的 所以我才想到include
潘加宇(3504847) 16:35:46
你是不是想问"提取合作方全部信息"是不是子用例
勤瘦(216***56) 16:35:58
恩
潘加宇(3504847) 16:36:00
不是，是步骤
潘加宇(3504847) 16:36:33
你还没有写文档，就搞这个，肯定有问题。认真写文档，请求验证改变回应，先不要玩这个
潘加宇(3504847) 16:36:53
文档写了，自然就知道include用在哪里了
勤瘦(216***56) 16:37:09
没写文档 我怎么知道扩展路径的步骤跟"UC:同步合作方"的步骤是一样的呢
勤瘦(216***56) 16:38:14

我的回答有问题
潘加宇(3504847) 16:39:18
子用例是有意义的步骤集合，类似于子函数
潘加宇(3504847) 16:39:32
步骤相当于代码里的一条语句
勤瘦(216***56) 16:39:37
我是想问 当某用例的扩展路径步骤与另一用例的步骤相同 但主执行者不同时
勤瘦(216***56) 16:40:32
这种情况并不能作为include的依据 是这样吗？
潘加宇(3504847) 16:40:43
这个步骤就是"系统请求合同管理系统返回全部和合作方信息"
潘加宇(3504847) 16:41:00
可以发生在很多个用例里
潘加宇(3504847) 16:41:19
执行者 是和 用例 一个级别的概念
潘加宇(3504847) 16:41:41
步骤 和 执行者 不能放在一起说
勤瘦(216***56) 16:41:51
哦。。。
潘加宇(3504847) 16:42:03
这就是一个步骤，还include什么
潘加宇(3504847) 16:42:21
就像就一行代码，还封装一个子函数？
潘加宇(3504847) 16:42:47
用例-路径-步骤
勤瘦(216***56) 16:47:06
一行代码如果多次出现，是可以封装到一个方法中的。。。
潘加宇(3504847) 16:48:26
嗯，说的也是，比喻不合适
潘加宇(3504847) 16:48:57
子用例也是用例，也要有请求-回应的回合，不是步骤
潘加宇(3504847) 16:49:35
嗯，说的也是，比喻不合适--实际上还是合适
勤瘦(216***56) 16:49:35
恩
勤瘦(216***56) 16:51:02
我是看到一个子用例的步骤与另一个用例的步骤一样 就想有没有办法抽象出来
勤瘦(216***56) 16:51:30
就像写程序一样抽象出来
潘加宇(3504847) 16:52:02
需求要具体，设计才要抽象
潘加宇(3504847) 16:52:23
就一步，你抽象什么
潘加宇(3504847) 16:53:16
没有必要，不要用关系
勤瘦(216***56) 16:54:02

勤瘦(216***56) 16:54:07

勤瘦(216***56) 16:55:32
不止是一个步骤。。。。
潘加宇(3504847) 16:55:49
3a3.
不用写
潘加宇(3504847) 16:55:55
3也不用
潘加宇(3504847) 16:56:05
到边界为止
潘加宇(3504847) 16:56:22
本地文件不要写
勤瘦(216***56) 16:56:28
哦
勤瘦(216***56) 16:56:46
3a2和3a3是一对请求和响应呀
潘加宇(3504847) 16:57:01
合同管理系统的事我们管不着
勤瘦(216***56) 16:57:11
哦
潘加宇(3504847) 16:57:29
我们只能针对系统能检测到的做出承诺
潘加宇(3504847) 16:57:47
不能对合同管理系统做的事情做出承诺
勤瘦(216***56) 16:57:50
恩 我这写得有问题
勤瘦(216***56) 16:58:01
恩 一定注意
潘加宇(3504847) 16:58:36
这三步即使看起来一样，还是要分开写，因为回合的第一步不同
勤瘦(216***56) 16:59:11
受教了
apollo(2423**86) 16:59:38
好晕
勤瘦(216***56) 17:00:06
您刚才提到业务序列图中不需要画出par和loop
勤瘦(216***56) 17:02:27
凌晨一点自动同步合作方的同时 客服人员也可能正在查询合作方信息呀
潘加宇(3504847) 17:03:24
par的意思并不是你做你的我可以同时做我的，例如，你吃饭，我喝水，他撒尿可以同时发生就画par
使用的场合是：
做完A后，要等你吃了饭，我喝了水，他撒了尿，才能往下走到B，而吃饭喝水撒尿没有严格顺序
潘加宇(3504847) 17:03:46
就是任务的分叉和结合
勤瘦(216***56) 17:10:34
受教了
勤瘦(216***56) 17:10:58
为什么loop也用得不恰当呢？
勤瘦(216***56) 17:11:50
我想在业务序列图上表述出每天的固定时间自动执行
勤瘦(216***56) 17:12:33
并且与"UC:查询合作方"是同时执行的
勤瘦(216***56) 17:12:40
我应该如何画呢？
勤瘦(216***56) 17:12:50
或者说 无需在业务序列图中表述出来？
潘加宇(3504847) 19:07:48
loop画上去也可以的，我的意思是能不画就不画。因为时间这个业务实体调用已经表明是定期的了
潘加宇(3504847) 19:09:18
增值部员工一天也可以查询很多次，想查就查，要不要也加个loop呢？
潘加宇(3504847) 19:11:48
每天凌晨一点是更细节的的信息，不宜放在业务序列图上。
"定期做"和"时间间隔的具体数据"不要放在一起，"每天凌晨一点"可以放在用例规约的业务规则补充约束里
潘加宇(3504847) 19:13:15
另外，"每天凌晨一点"是不是涉众要求必须这样？如果这个时间可以配置，这个就不是需求了
潘加宇(3504847) 19:14:18
如果要生动，可以时间和客服系统之间的"同步。。。。"旁边加注释"例如每天凌晨一点"
潘加宇(3504847) 19:14:58
不过，这也不算什么大错。你的业务序列图，用例文档水平已经很不错了！
潘加宇(3504847) 19:17:54
回到之前的步骤的问题，为什么不适合分开，因为为不同执行者服务的用例，需求上总会有也应该有细微的差别。
潘加宇(3504847) 19:21:54
例如之前说的那三步，
系统请求合同系统返回信息。步骤确实一样，补充约束方面，字段列表也是一样的，但速度上是否有差别？时间引发同步时可以慢一点，人在旁边等着的时候，可能要求快一点。
保存这一步，步骤和背后的约束应该一样。
但反馈这一步也应该会有差别，时间引发同步可能只是记录同步的情况不需要反馈或者悄悄反馈，而人在旁边等着的同步反馈要清晰醒目。
潘加宇(3504847) 22:21:37
你的用例文档没有涉众利益，这个要加上，没有涉众利益，怎么判断你的需求内容是否正确？虽然写出来的形式正确
勤瘦(216***56) 0:08:55
谢谢潘老师