勤瘦(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 实事求是来啊。不会等到没卡借这么狼狈才去补卡吧