勤瘦(216***56) 10:29:41
从业务序列图推导出系统的三个用例注册SIM卡、申请激活、审核激活申请
勤瘦(216***56) 10:31:10
勤瘦(216***56) 10:31:31
申请激活其实就是让系统创建了一个激活申请
勤瘦(216***56) 10:32:27
然而 对激活申请的操作 除了创建以外 还有撤消和删除
勤瘦(216***56) 10:35:21
如果撤消和删除都体现在系统用例图中，是否显得过于细化
勤瘦(216***56) 10:36:29
我是否可以这样画系统用例图????
潘加宇(3504847) 16:25:38
首先，你的业务序列图从管理员这个工人和待开发系统打交道画起，有以系统为中心描述业务流程的倾向。
申请、撤消和删除不会无缘无故地发生，发生的频率也是不一样的，甚至通过观察业务流程后，未必以你之前所猜想的那样的方式发生
潘加宇(3504847) 16:25:58
我是否可以这样画系统用例图????--不对。从业务流程里提炼
潘加宇(3504847) 16:27:32
4.3.2 错误：以待开发系统为中心拼凑流程
图4-23 以待开发系统为中心拼凑流程
如图4-23，建模人员没有去调研并按照业务流程的进展来画图，而是想象了自己认为系统应该有的一些功能，把这些功能拼凑起来就变成"业务流程"了。
业务建模时，心中的摄像机应该一路跟随实现业务用例的流程去拍摄，把拍到的故事如实画出来，各个系统只是流程中的一个零件。建模人员常犯的错误就是把自己要开发的系统看得比天还大，把摄像机固定在自己要开发的系统的旁边。
业务建模就是要从业务流程中找到待开发系统的位置，证明您的系统如果有这些功能，对实现业务用例是有帮助的。这样，这个系统就能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？
勤瘦(216***56) 16:40:51
最初的业务序列图是这样
勤瘦(216***56) 16:42:21
但是我想 借卡必然之前 SIM卡管理员必然先注册SIM卡并激活它 所以才加了那些流程
勤瘦(216***56) 17:15:12
4.4的"发布消息"是以业务工人（公司助理）开始
勤瘦(216***56) 17:15:31
最后通过交互概述图将业务流程的各个部分串联在一起
勤瘦(216***56) 17:36:47
由于SIM卡的注册、激活并不是研究对象对外提供的业务 是否就意味着无法从业务流程中提炼这些系统用例了？？
如果可以 我应该如何做呢？
是否应参照4.4的写法，将SIM卡的注册、激活等放在"准备"部分，最后通过交互概述图将其与其它部分串联起来？
潘加宇(3504847) 19:30:58
对的，尽量讲一个对组织有意义的故事，把你的系统放在组织的故事中
潘加宇(3504847) 19:31:44
从你给的资料看，改进的组织应该是SIM卡的管理部门
潘加宇(3504847) 19:32:10
（有这个部门吗？）
潘加宇(3504847) 19:33:29
注册激活SIM卡和借卡发生的频率一样吗？
潘加宇(3504847) 19:34:49
SIM卡管理员不会无缘无故在某个时间去注册和激活SIM卡吧，肯定有诱因的，诱因可能是上级的安排，也可能是有什么事件。
勤瘦(216***56) 20:03:16
改进的组织是部门里的一个小组 它有管理SIM卡的职能 为其它小组提供用于测试业务的SIM卡
勤瘦(216***56) 20:03:49
SIM卡的注册、激活跟借卡的频率是不一样的 所以我这样画业务序列图肯定是错的
勤瘦(216***56) 20:10:25
SIM卡的注册、激活只有在新购入卡的时候才会发生 但购卡行为的触发基本来自于这个小组内部 比如: 卡作废了、需要补充某个省份的SIM卡等等
勤瘦(216***56) 20:11:50
来自于组外的需求很少 但是会有 比如其他某个小组需要一批特殊的卡
勤瘦(216***56) 20:13:03
购卡也是这个小组负责 也就是说购卡人也是一个business worker
勤瘦(216***56) 20:32:02
目前 研究组织的业务用例只有两个：借卡和充值
我想应该再增加一个业务用例-补充SIM卡
勤瘦(216***56) 20:34:52
这个业务用例的business actor还是部门员工 两个business worker：购卡人和SIM卡管理员
部门员工发起请求，负责购卡的组员购买后，再由SIM卡管理员在系统中注册并激活这些SIM卡
潘加宇(3504847) 20:47:11
但购卡行为的触发基本来自于这个小组内部 比如: 卡作废了、需要补充某个省份的SIM卡等等
--也就是说有一个人肉系统会定期或不定期地思考是不是该买卡了，可以画一个时间系统指向这个人肉系统
潘加宇(3504847) 20:48:07
"补充SIM卡"不是单独的用例，可以作为某个用例的一个扩展场景
潘加宇(3504847) 20:48:40
什么时候流程里管理员会知道了"卡作废了"的情况
勤瘦(216***56) 20:55:34
可确实存在其他小组的组员要求这个小组补充SIM卡的情况 这不能视为一个业务用例吗？
潘加宇(3504847) 21:00:22
医院里，医生找张三要小便做检验，张三去上厕所
每天时不时，张三去上厕所
要上长途大巴了，张三去上厕所
潘加宇(3504847) 21:00:45
"上厕所"是"张三"对外提供的用例吗？
潘加宇(3504847) 21:03:31
同理，管理员"补充SIM卡"这个责任可以出现在很多个业务流程里面，这是好事，说明这个责任的复用率高
勤瘦(216***56) 21:03:53
好吧 那我应该如何体现在业务序列图呢？这样才可以提炼出系统用例呀（我指的是SIM卡注册和激活）
勤瘦(216***56) 21:04:17
恩 您说得对
潘加宇(3504847) 21:04:21
讲你观察到的故事啊
潘加宇(3504847) 21:05:23
这个故事里，用到了责任ABC
那个故事里，用到了责任BCD
第三那个故事，用到了责任CDE
第四个故事，用到了责任ACE。
。。。
勤瘦(216***56) 21:06:27
对外提供的业务是借卡 可是这个故事里貌似没有SIM卡注册和激活事情呀。。。。。
潘加宇(3504847) 21:07:30
管理员不会无缘无故"SIM卡注册和激活"，诱因有哪些？
勤瘦(216***56) 21:07:33
您是指这个吧
潘加宇(3504847) 21:07:52
类似这样的
勤瘦(216***56) 21:08:25
简单来说 就是没卡可借的时候 才会发生购卡、注册、激活这件行为
勤瘦(216***56) 21:08:59
OK 我再想想 明天再向您请教
潘加宇(3504847) 21:09:22
什么时候判断有没有卡可借呢？
勤瘦(216***56) 21:09:40
那就只能是借卡的时候了。。。。
龙在天涯(6167**304) 21:09:56
哇，现场直播啊，老师辛苦，
勤瘦(216***56) 21:10:22
我应该在借卡的业务序列图中体现出来
勤瘦(216***56) 21:12:52
当有人借卡的时候 如果SIM卡管理员发现没卡可借了 就会发生购卡、注册、激活 然后告知借卡人卡已到位 由借卡人再次发现借卡请求
潘加宇(3504847) 21:18:15
实事求是来啊。不会等到没卡借这么狼狈才去补卡吧