譯揮 (25****466) 9:59:24
潘老师，我画了一个业务序列图，在科技项目报销事项在项目系统中经部领导审批通过后，要求将报销数据推送到财务的费用系统中进行财务报销。看看是否合适？

注：项目系统 和 费用系统已经有了，现在需要将两个系统衔接起来。
譯揮 (25****466) 10:01:48
也请各位帮助讨论指点一下啊
潘加宇(3504847) 10:04:19
画得还可以的。
把对象的顺序再排一下，使得从左到右的箭头尽量多
譯揮 (25****466) 10:05:14
好的。有一个问题：我觉得：准备报销数据（）画出来有一定问题，但双想不出好的画法表示。接收报销数据（）可以作为费用系统的用例，那项目系统需要准备报销数据这一步骤，是应该在项目系统中的用例中表示，是否写在领导审批（）的后置条件中呢。
潘加宇(3504847) 10:07:52
首先讨论时要确定研究对象
现在，思维跳到了研究"项目系统"
准备报销数据的步骤（或步骤集合）放在"项目系统"的"审批"用例里描述
其他的照此规律办理
潘加宇(3504847) 10:09:52
领导提交审批结果
系统验证
系统保存，准备报销数据
系统请求费用系统接收报销数据
系统反馈已将数据发给费用系统
譯揮 (25****466) 10:11:37
好的。同理，如果把推送数据放在项目经理结束报销审批流程以后，那就应该放在结束报销审批()中。
譯揮 (25****466) 10:12:50
那"准备报销数据"要不要反映在业务序列中呢？
潘加宇(3504847) 10:13:20
可以不放
潘加宇(3504847) 10:13:38
但如果里面有值得一提的复杂逻辑，可以画
譯揮 (25****466) 10:13:56
是否合适，因为我想到这一步要写到用例规约里，而且在系统用例的序列图中也要画。
潘加宇(3504847) 10:14:31
系统用例没有序列图
潘加宇(3504847) 10:14:36
就是用例规约
譯揮 (25****466) 10:15:04
系统用例的实现图
潘加宇(3504847) 10:15:25
分析序列图
譯揮 (25****466) 10:15:55
就是指这个
潘加宇(3504847) 10:16:20
不但分析序列图要体现（不体现需求怎么实现），代码还要写得更细呢
潘加宇(3504847) 10:17:04
就是从大到小，逐步缩小研究对象
譯揮 (25****466) 10:19:08
就是说，把重要的，适合在这个层次体现的，体现出来。
潘加宇(3504847) 10:20:09
差不多。"准备报销数据"花在业务序列图里是一步，系统用例规约里可以有多次交互，
潘加宇(3504847) 10:21:01
用例规约里的一步"系统****"，可能要体现在分析序列图上成为很多个类的交互。实现成很多类和很多行代码
譯揮 (25****466) 10:22:27
书上讲了，聚焦于系统之间的协作，不必表达过细的交互步骤。问：是否业务序列图上指向自己的动作，一般都是前面那个用例的步骤之一，不是单独的用例。对吧？
潘加宇(3504847) 10:22:48
是
潘加宇(3504847) 10:23:18
是前面那个用例的步骤（或步骤集合）
譯揮 (252****66) 10:23:34

潘加宇(3504847) 10:24:52
各个通知自反消息这里，可以画个虚线指向被通知的人
譯揮 (252****66) 14:36:44
完成的流程画完了，老师看看。

譯揮 (252****66) 14:38:32
现在有一个问题：从项目系统中传送过来的报销数据要被利于在制作报销单据上，这个，在序列图中没有反映。准备写在制作单据（）的用例规约里。
譯揮 (252****66) 14:39:05
要是能反映就好了，有什么办法。
潘加宇(3504847) 14:40:33
还是那个老问题啊，如实反映系统的契约即可，哪有这么多技巧啊
譯揮 分享文件 14:40:40
"项目报销审核付款序列图.docx" 下载
譯揮 (252****66) 14:42:26
看看这个图，行不行？
潘加宇(3504847) 14:45:07
可以。