comet
More options Apr 6 2010, 1:25 pm
老师你好！我在画业务序列图的时候碰到一个问题，希望得到您的指导：
我研究的组织是某电子商务网站
业务用例是：消费
业务场景：消费者到网站上购买商品，结算的过程
参与者：消费者，商务网站系统
业务流程：
1.消费者到网站系统上选购了一批商品并确定了订单（系统用例我定为：下单）
2.消费者选择自己的银行卡进行支付（系统用例我定为：付款给商家）
3.网站后台操作员发出结算指令，网站自己做结算（系统用例我定为：结算）
我的疑问点在于：结算这一步，有2 种情况发生，一种是网站后台操作员触发的，一种情况是在消费者支付完自动触发的
网站后台操作员触发的，箭头从网站后台操作员指向商务网站系统，这个我知道
自动触发的那个，我如何在业务序列图中表示，请老师指导
我知道应该是付款给商家这个用例包含了结算这个用例（include 关系），但怎么在业务序列图上表示呢？表示的话，是不是说这两个用例是一个级别的？
UMLChina
More options Apr 7 2010, 9:23 am
参见附件。
业务序列图的抽象程度是"系统之间的协作"，系统内的自我运算可以不画，除了引起分支的运算。例如图中，自我消息"判断××××"可以画，自我消息"结算"不用 画，当然，画也可以。
"结算"只是很多个系统用例里面可能都有的步骤，不是子用例，没有学会熟练写文档之前，不要乱使用或者乱去探讨用例的关系，没有必要。
另外，要结算，是否需要和第三方支付系统协作才能完成。


comet
More options Apr 8 2010, 5:28 pm
"结算"只是很多个系统用例里面可能都有的步骤，老师，很多用例里面都有的步骤，需要抽象出来成为单独的用例吗？
如果单独用例，那是不是 【付款】用例需要include【结算】用例；【确认需干预的结算】也需要include【结算】用例
如果不是单独用例，那不是每个UC 都写这么一大堆的相同的步骤？如果结算步骤改了，不是要改一堆文档？这种情况如何解决呢
UMLChina
More options Apr 9 2010, 12:34 am
include 是复用有意义的步骤集合，相当于代码里面可以被许多模块调用的子函数，单独一句i=5 拿出来复用有什么意义。
步骤的意思就是一步，"系统结算"或"系统请求××系统结算"，怎么会变成一大堆步骤了？你是不是认为结算的算法复杂，里面要分很多步，那不是这个抽象级别考虑的事情，这个写在业务规则里，步骤里只需要写"请求－验证－改变－回应"的行为。
建模的要点之一就是保持抽象级别的一致。
"实现人生价值"包括"读书"、"上班"、"成家"....
"成家"包括"买房"、"买家具"、"结婚"
"买家具"包括"上网站下单"、"收货"
"上网站下单"包括"提交××"，"验证××"，"改变××"，"回应××"
"改变××"包括"合计总价"、"计算运费"
"合计总价"包括"取价格"，"计算单项"，"循环"，"合计所有项"...
"取××"包括N 多行框架提供的代码
"框架提供的任何一行代码"包括操作系统平台提供的若干更底层代码
任何一句软件代码 包括 若干硬件的步骤
晶片的一个动作 包括 多个电子元件的操作
电子元件的操作 包括 许多分子的动作
分子的动作 包括 原子的动作
需求步骤的抽象级别就是"待开发系统"和其它系统（主执行者、辅执行者）之间的交互行为。
UMLChina
More options Apr 9 2010, 12:43 am
补充：子用例也是要满足用例的要求的，也要有"请求。。。。。回应"的完整过程，不可能是步骤。
例如："登录"是一个常见的子用例，它不是步骤，而是一大堆步骤，甚至还有扩展路径
会员提交身份信息
系统验证。。。
系统反馈
扩展：
a.验证失败：
a1.系统。。。。
还有"查询××"，也是一大堆步骤的集合
会员提交查询条件
系统根据条件搜索
系统反馈。。。。
扩展：
搜不到：
系统××××××
没有这样级别的，不要乱用include 关系。否则今天你为了一个步骤拼命想"复用"，明天可能就会想"这些用例都是查同一张表，干脆提升复用性，合并成一个用例好了"
comet
More options Apr 9 2010, 11:09 am
明白了,谢谢老师,在抽象级别上我还需要多多积累