前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >[答疑]业务序列图推导出系统的三个用例注册SIM卡、申请激活、审核激活申请

[答疑]业务序列图推导出系统的三个用例注册SIM卡、申请激活、审核激活申请

作者头像
用户6288414
发布2021-04-22 10:53:05
5730
发布2021-04-22 10:53:05
举报
文章被收录于专栏:软件方法

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-04-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 UMLChina 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云直播
云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档