所在位置:答疑 - 内容   
有两个角色,审批一个单子,都是confirm 动作
 

2007-7-13  11:39:27  Johnson:  我们有个系统。有两个角色,审批一个单子,都是confirm 动作, 
2007-7-13  11:40:20  Johnson:  但是两个角色做的事情有点差别, 
2007-7-13  11:40:49  Johnson:  定义confirm 这个用例. 
2007-7-13  11:41:20  Johnson:  这两个角色都使用用例合适嘛? 
2007-7-13  11:41:50  Johnson:  都使用同一个confirm 用例.是否合适. 
2007-7-13  11:42:00  Johnson:  还是要分开成两个用例. 
2007-7-13  11:42:04  潘:  用例就是实事求是反应系统提供的价值 
2007-7-13  11:42:35  潘:  你觉得合并有什么不好?分开又有什么不好呢?

2007-7-13  11:43:10  Johnson:  是这样, 
2007-7-13  11:43:41  Johnson:  一个单子Status=0 时候,给一个User 审批后,Status 变成1, 
2007-7-13  11:44:03  潘:  你觉得合并好? 
2007-7-13  11:44:03  Johnson:  然后这个单子再给刚才那个user 的上级再审批, 
2007-7-13  11:44:14  Johnson:  不好. 
2007-7-13  11:44:34  Johnson:  用例文档中描述流程比较混乱 
2007-7-13  11:44:36  潘:  实际上我们课上说清楚了的 
2007-7-13  11:44:51  Johnson:  前置条件也有点区别的. 
2007-7-13  11:45:51  潘:  通常这里面存在混淆的原因:1. 认为名字差不多,就可以抽象出来共用一个用例;2. 认为上级没审批,这个单子就不算完。 
2007-7-13  11:46:28  潘:  首先从形式上,两个主执行者共用一个用例这肯定是错的。 
2007-7-13  11:47:57  潘:  内容上,系统只为用户提供"申请"的价值,并没有承诺单子一定能审批通过。申请完毕,系统为用户提供的服务就结束了,用户不能要求更多,不能因为上级没有批,骂这个系统有问题。 

2007-7-13  11:48:25  Johnson:  恩, 
2007-7-13  11:48:27  Johnson:  对的, 
2007-7-13  11:49:02  潘:  答案很清楚:因为你的研究对象是系统,系统是分别为用户,上级提供服务。所以,应该分开两个用例。 
2007-7-13  11:49:17  Johnson:  现在问题是这样, 
2007-7-13  11:49:29  Johnson:  我们的使用用户有好几个Role, 
2007-7-13  11:49:35  潘:  如果说,研究对象是"上级部门+系统",那么只有一个执行者,一个用例:用户-申请 
2007-7-13  11:50:13  Johnson:  每个Role 都有一定的权限. 
2007-7-13  11:50:32  Johnson:  比如说Create 一个单子, 
2007-7-13  11:50:41  Johnson:  两个Role 都可以, 
2007-7-13  11:51:13  Johnson:  我们Create 单子的用例,是分开还是一块. 
2007-7-13  11:51:25  Johnson:  他们做的动作是一样的, 
2007-7-13  11:52:02  Johnson:  仅仅是用户的Role 不同而已. 
2007-7-13  11:52:20  潘:  要看如何能真实反应涉众的意思 
2007-7-13  11:52:22  潘:  首先 
2007-7-13  11:53:04  潘:  如果在涉众看来,这两个角色在做这个事情的时候,步骤一样,涉及的利益也一样,那就是一个角色嘛 
2007-7-13  11:53:51  潘:  如果说不一样,或者一个角色填单子的一部分,另一个角色填单子的另一部分,那就是两个不同的用例 
2007-7-13  11:54:15  潘:  你把文档给我看看?

2007-7-13  11:54:20  Johnson:  举个例子,这么说吧, 
2007-7-13  11:54:40  Johnson:  A 是工人,B 是他的主管. 
2007-7-13  11:54:56  Johnson:  A 和B 都可以创建单子, 
2007-7-13  11:55:06  Johnson:  A 创建好后,可以给B 审批. 
2007-7-13  11:55:26  Johnson:  但是A 只是具有一般的maintian 的功能. 
2007-7-13  11:55:40  Johnson:  B 审批后,还可以给C 继续审批. 
2007-7-13  11:56:12  潘:  如实画出来即可 
2007-7-13  11:56:15  Johnson:  然后我们就有Create,Confirm,AdvanceConfirm 动作. 
2007-7-13  11:56:22  潘:  主管是工人的一种 
2007-7-13  11:56:26  Johnson:  对. 
2007-7-13  11:56:33  Johnson:  B 比较特殊, 
2007-7-13  11:56:34  潘:  除了工人能干的,主管还可以审批 
2007-7-13  11:56:42  Johnson:  对. 
2007-7-13  11:56:45  潘:  就这样表达出来就行了 
2007-7-13  11:57:58  Johnson:  那我对Create 用例描述的时候,写Role 那一项时候,将A 和B 都写进去呢. 
2007-7-13  11:58:36  潘:  不可能把A 和B 都写进去,主执行者只能有一个 
2007-7-13  11:58:53  Johnson:  那这种情况比较困惑了. 
2007-7-13  11:58:54  潘:  用例是系统和某一类人签的契约 
2007-7-13  11:59:05  Johnson:  实际是A 做的, 
2007-7-13  11:59:09  潘:  为什么,刚才不说主管是工人的一种吗? 
2007-7-13  11:59:55  Johnson:  那直接写A 就可以了. 
2007-7-13  12:00:21  潘:  除非工人能干的,主管有些不能干,那又另外 
2007-7-13  12:00:52  Johnson:  另外还有就是Modify 动作, 
2007-7-13  12:01:01  Johnson:  A 和B,和C 都可以 
2007-7-13  12:01:28  Johnson:  区分是这样,Status=0,A 和B 都可以修改, 
2007-7-13  12:01:36  Johnson:  Status=1 仅仅B 
2007-7-13  12:01:46  Johnson:  可以修改, 
2007-7-13  12:01:57  Johnson:  Status=2 仅仅C 可以修改. 
2007-7-13  12:02:10  Johnson:  Modify 这个用例应该也分开写吧. 
2007-7-13  12:03:35  潘:  不要说status,要说人话。你就说工人能创建,主管能创建能审批也能修改,高级主管还能高级审批,修改审批过的单子。你就实事求是把问题写清楚就完了 
2007-7-13  12:04:46  潘:  发生在眼皮底下的事情,大不了拿个照相机去照相,不用想得那么复杂 
2007-7-13  12:05:24  潘:  参见幻灯片"如何处理登录"

2007-7-13  12:06:57  Johnson:  那Modify 用例应该分开写了哦. 
2007-7-13  12:07:25  Johnson:  按照刚才的说法,就是工人和主管都可以修改. 
2007-7-13  12:07:27  潘:  对呀,还是参见幻灯片,不要从数据库找用例 
2007-7-13  12:07:43  Johnson:  每个角色一个? 
2007-7-13  12:08:17  潘:  这里面的思想是,不管前面干什么,都是对"单子"的表修改字段值,再改变status字段。 
2007-7-13  12:08:46  潘:  问题是你不能把数据库拿去给涉众说,这就是你的系统。 
2007-7-13  12:09:07  潘:  每个角色一个--实事求是就行 

2007-7-13  12:09:36  Johnson:  谢谢潘老师. 
2007-7-13  12:09:39  Johnson:  理解了. 
2007-7-13  12:10:01  潘:  只要实事求是说人话,都是对的。 
2007-7-13  12:10:46  Johnson:  ü UC_001_CreateIntelligence 用例名称 CreateIntelligence 描述 创建Intelligence 角色 2CBSEditor2CBSChiefEditor 前置条件 用户已经以正确身份登录系统。输入 Item# 输出 提交保存后的Intelligence 记录流程 1、 输入Item# 2、 系统检查Item#是否存在 SELECT item AS ItemId,descrip AS ItemName FROM itemmaintainnewegg.dbo.arinvt01 (NOLOCK) WHERE item = @ItemNumber 3、 用户输入Intelligence 信息 4、 系统保存Intelligence 信息(1) 如果选中"Active In
OverviewTab",则执行以下更新: UpdateCo 
2007-7-13  12:10:54  Johnson:  这个是我们一个同事写的, 
2007-7-13  12:11:09  Johnson:  我帮他完善后面的文档. 
2007-7-13  12:11:13  Johnson:  发现很多问题. 
2007-7-13  12:12:07  Johnson:  他这边将角色一栏就写了两个.CBSEditor 和CBSChiefEditor  
2007-7-13  12:12:16  Johnson:  我觉得怪怪的, 
2007-7-13  12:12:49  Johnson:  但是一时有没想到具体哪里违背. 
2007-7-13  12:14:34  潘:  这肯定不对,而且需求和设计没分开,就算是一个人承担两个角色也要分开,因为二者变动频率不同 
2007-7-13  12:15:02  Johnson:  对,是的. 
2007-7-13  12:21:55  潘:  涉众利益要加上 
2007-7-13  14:52:44  Johnson:  上午的问题还有点不明白. 
2007-7-13  14:53:17  Johnson:  用例文档中的输入和输出需要嘛? 
2007-7-13  14:54:33  Johnson:  内容 用例名称:UC 名称,一般采用动名词短语;描述:UC 的说明,比如UC 的目的、涉及业务简述等;角色:主要指UC 的执行者、系统使用者; 前置条件:执行该UC 必须符合的前提条件;输入:输入的业务信息描述,指明输入信息的来源;输出:操作UC 后生成的有效业务信息;流程:UC 的场景描述,分步骤说明使用者和系统发生的动作;异常处理:某一操作步骤的分支流程或异常处理等;约束:某一操作步骤必须提供的内容说明(如具体的信息等)、业务规则描述等; 备注:其它必要的说明,可以包括与该UC相关的用户的意见等等。格式 l 流程中以阿拉伯数字为序号,如果有进一步说明,则在步骤序号后加.#(如2.1、 2.1.1…,以此类推); l 异常处理中序号为"流程"中的步骤序号+小写字母,比如:流程中2 有两个分支,则在异常处理中有两条说明2a、2b,如有进一步说明,规则同上; l 约束中的序号必须是流程或 
2007-7-13  14:54:49  Johnson:  我们这边的用例文档模版是这样的. 
2007-7-13  14:55:21  潘:  输入:输入的业务信息描述,指明输入信息的来源;输出:操作UC 后生成的有效业务信息;--这是典型的IPO 的做法 
2007-7-13  14:55:36  潘:  涉众利益没有,这是不行的 
2007-7-13  14:55:49  潘:  按照我课上的模板即可 

2007-7-13  14:55:54  Johnson:  我们现在还需要这个嘛? 
2007-7-13  14:56:11  Johnson:  我们这边涉众利益是没有的. 
2007-7-13  14:56:35  Johnson:  另外异常流程应该和我们课程讲的扩展流是一样的吧? 
2007-7-13  14:56:38  潘:  是模板里没有还是事实上没有? 
2007-7-13  14:58:18  Johnson:  模版没有. 
2007-7-13  14:58:59  Johnson:  另外异常流程/扩展以及备选流,我理解上应该是等效的吧. 
2007-7-13  14:59:02  潘:  建议加上,这个比起其他部分都重要,其他部分写不写,写得怎样是次要的 
2007-7-13  14:59:20  Johnson:  都是非基本路径. 
2007-7-13  14:59:23  潘:  异常和备选都是扩展,再分一次而已 
2007-7-13  15:00:29  Johnson:  这个怎么讲? 
2007-7-13  15:01:59  潘:  就是说都看成扩展路径就可以了,不用再分那么多 
2007-7-13  15:02:16  Johnson:  ok 
2007-7-13  15:02:32  潘:  备选路径可以看作是执行者来决定的选择,异常是系统来决定的选择 
2007-7-13  15:03:28  Johnson:  另外同样上午上午所讲的那种情况. 
2007-7-13  15:03:38  Johnson:  有多个角色的用户, 
2007-7-13  15:03:54  Johnson:  就是工人,主管,高级主管. 
2007-7-13  15:04:17  Johnson:  他们有很多动作都是一样可以 做的. 
2007-7-13  15:04:30  Johnson:  主管是工人的特例. 
2007-7-13  15:04:55  Johnson:  高级主管和工人,以及主管就不同了,做的动作差别很大. 
2007-7-13  15:05:20  Johnson:  如同样修改单子. 
2007-7-13  15:05:43  Johnson:  工人和主管一样,我可以共用一个用例. 
2007-7-13  15:05:57  Johnson:  让主管继承工人即可. 
2007-7-13  15:06:27  Johnson:  但是高级主管不能继承工人. 
2007-7-13  15:06:54  Johnson:  象Review,Modify 等动作实际和工人是一样. 
2007-7-13  15:07:12  Johnson:  不过所前置条件不同而已. 
2007-7-13  15:07:35  Johnson:  这应该也分成多个用例吧.即  
2007-7-13  15:07:45  Johnson:  工人单独一个,高级主管也单独一个. 
2007-7-13  15:08:11  潘:  不过所前置条件不同而已.--这怎么是一样呢,涉及到的利益和考虑问题的角度都不同 
2007-7-13  15:08:43  Johnson:  比如View,就是看 
2007-7-13  15:08:45  潘:  总理签字,你也签字,两个能一样吗 
2007-7-13  15:08:52  Johnson:  这个应该是一样的吧. 
2007-7-13  15:09:16  潘:  如果一样,就泛化出"单子查看者" 
2007-7-13  15:09:57  Johnson:  其实我们这边的用户是根据Role 的配置来的. 
2007-7-13  15:10:31  Johnson:  每个Role 具备的权限都不一样. 
2007-7-13  15:11:46  Johnson:  同样是View,要看单子的状态. 
2007-7-13  15:12:26  Johnson:  如只有被主管审批后的单子,高级主管才可以看到,其他情况是看不到的. 
2007-7-13  15:12:55  Johnson:  如果泛化出"单子查看者",实际前置条件也不太一样. 
2007-7-13  15:14:03  潘:  内容也不一样啊。返回所有单子,返回已经过审批的单子,返回自己提交的单子... 
2007-7-13  15:14:21  潘:  先分开写,确定一样了再合并
 
2007-7-13  15:14:23  Johnson:  对. 
2007-7-13  15:14:51  Johnson:  分开写觉得似乎有点累赘,但是 
2007-7-13  15:15:08  Johnson:  合并,有觉得有区别. 
2007-7-13  15:15:43  Johnson:  比如,查看单子. 
2007-7-13  15:16:20  Johnson:  功能是一样.无非是列出单子的具体内容,但是每个角色查看的前置条件不同. 
2007-7-13  15:16:44  Johnson:  如工人是一直可以看到的. 
2007-7-13  15:17:08  Johnson:  高级主管是在主管审批后才可以看到. 
2007-7-13  15:17:24  Johnson:  同样批复有Reject 动作, 
2007-7-13  15:17:43  Johnson:  主管Reject 和高级主管的Reject 也不同. 
2007-7-13  15:17:45  潘:  但是每个角色查看的前置条件不同. --前置条件没有不同啊 
2007-7-13  15:17:53  潘:  不同的是内容吧 

2007-7-13  15:17:57  Johnson:  不是, 
2007-7-13  15:18:04  Johnson:  是看单子的状态. 
2007-7-13  15:18:40  Johnson:  如被主管审批后的单子,工人就没法修改了. 
2007-7-13  15:19:23  Johnson:  被主管审批成功的单子,送到高级主管.处,高级主管是可以修改.其他用户是都不能再修改. 
2007-7-13  15:19:43  潘:  分开,照实写就行了 
2007-7-13  15:20:08  Johnson:  如果高级主管Reject 这个单子后送到主管处, 
2007-7-13  15:20:30  Johnson:  主管可以修改,主管Reject 单子到工人处,工人可以修改. 
2007-7-13  15:21:04  Johnson:  所有这些动作都是看单子审批过程到什么状态了. 
2007-7-13  15:21:50  Johnson:  另外我这边用例按照这种分开写,管理上需要分包. 
2007-7-13  15:22:24  Johnson:  可以按照功能分包后,再按照用户分包嘛? 
2007-7-13  15:22:43  潘:  按业务用例分包 
2007-7-13  15:23:04  Johnson:  即第一级是业务分包,第二级按照用户分包. 
2007-7-13  15:23:36  Johnson:  比如这个单子,我就写管理单据, 
2007-7-13  15:23:52  潘:  你这个单那么多人审批是体现公司提供的什么价值,这是业务用例。 
2007-7-13  15:24:27  Johnson:  这个是审批系统啊. 
2007-7-13  15:25:11  潘:  就是一个审批的业务啊,那还分什么包 
2007-7-13  15:26:25  Johnson:  你是说就是一个用例? 
2007-7-13  15:26:48  潘:  一个包 
2007-7-13  15:26:58  潘:  怎么会是一个用例呢

2007-7-13  15:27:43  Johnson:  是一个包. 
2007-7-13  15:28:09  Johnson:  业务上主要是分成两部分. 
2007-7-13  15:28:18  Johnson:  一部分是单据的管理. 
2007-7-13  15:28:30  Johnson:  第二是单据的审批 
2007-7-13  15:29:09  Johnson:  增加修改/查看都是管理. 
2007-7-13  15:29:29  Johnson:  审批,包括多个用户的confirm 和Reject 
2007-7-13  15:30:05  Johnson:  我现在分成这两个包,一个是管理.一个是审批. 
2007-7-13  15:30:37  Johnson:  但是审批里面还有多个步骤,包含了多个用例 
2007-7-13  15:31:34  Johnson:  管理里面,有查看,修改,等,但是每个用户做这个动作还是有区别的 
2007-7-13  15:32:30  潘:  可以 
2007-7-13  15:33:18  Johnson:  但是审批这个包里面还比较复杂,我就再分一级的包. 
2007-7-13  15:33:31  Johnson:  就是说按照用户分.这样是否可以呢? 
2007-7-13  15:33:57  潘:  可以。分包无所谓,分多少内容都不会变 
2007-7-13  15:34:31  Johnson:  还有刚才说的,管理单据,查看和修改还是有点区别的 
2007-7-13  15:34:45  Johnson:  我也按照用户再分了一级包. 
2007-7-13  15:36:24  Johnson:  还有,我现在做的是系统用例,不是业务用例. 
2007-7-13  15:36:51  潘:  但为什么要分包,是要分给不同团队写文档,开发吗 
2007-7-13  15:37:33  Johnson:  逻辑上根据业务逻辑分包这个是正常的. 
2007-7-13  15:38:44  Johnson:  在逻辑的下一级按照用户分包,可以很清楚地区别处那个角色可以做什么. 
2007-7-13  15:39:02  Johnson:  觉得这方面会清楚一点. 
2007-7-13  15:40:09  潘:  如果不是为了分配开发,画在一张大图上即可 
2007-7-13  15:41:26  Johnson:  ok,这个可以. 
2007-7-13  15:42:23  Johnson:  前面讲到的主管和高级主管confirm 和Reject, 
2007-7-13  15:43:00  Johnson:  以及工人/主管和高级主管View/Modify 用例的名字也不太好起. 
2007-7-13  15:44:20  潘:  不好起就加前缀"高级部长审批","部长审批"(罗嗦一点就是"以高级部长身份审批") 
2007-7-13  15:45:22  Johnson:  查看用例也这样嘛? 
2007-7-13  15:45:38  Johnson:  修改用例都这样. 
2007-7-13  15:45:58  Johnson:  这个从业务上应该差不多的,都是查看和修改. 
2007-7-13  15:46:32  潘:  无所谓,你先吧文档写出来看看 
2007-7-13  15:47:14  Johnson:  前面审批分角色审批从业务上说是没有什么疑问的. 
2007-7-13  15:48:01  Johnson:  但是修改单据, 在不同阶段,有时候可以修改,有时候看不到单子没法修改 
2007-7-13  15:48:36  Johnson:  这种情况查看是否要分成多个用户的查看呢? 
2007-7-13  15:49:33  Johnson:  修改也是这样,工人修改/主管修改,高级主管修改? 
2007-7-13  15:49:52  潘:  看区别大不大,实际上很多时候一个用例就可以了。查看者请求查看,系统根据他的身份返回单据 
2007-7-13  15:50:37  Johnson:  单子状态不同, 
2007-7-13  15:51:15  Johnson:  主要是单子状态不同,不同的身份能否查看或者修改 
2007-7-13  15:52:10  Johnson:  就是前面说的, 被主管审批后的才可以被高级主管修改.其他人都修改不了. 
2007-7-13  15:52:38  Johnson:  工人刚创建的单子,还没有发送给主管审批,主管等用户是修改不了的. 
2007-7-13  15:52:53  Johnson:  这个时候,高级主管也是看不到单子的. 
2007-7-13  15:53:14  Johnson:  这种情况我很难定性,区别大不大. 
2007-7-13  15:55:35  潘:  你不要从单子状态,系统之类的角度描述,要说人话,你去问高级主管,你每天在干什么? 
2007-7-13  15:56:07  Johnson:  他修改和审批. 
2007-7-13  15:56:11  潘:  他的回答才是对的,尽量不要用修改状态之类的话 
2007-7-13  15:56:21  Johnson:  他就做这两件事情. 
2007-7-13  15:57:05  Johnson:  我是 想确定,多个用户修改单子是否可以合并到一个用例里面 
2007-7-13  15:58:37  潘:  不可以 
2007-7-13  16:00:27  Johnson:  那我可以这么写吧. 
2007-7-13  16:02:59  Johnson:  对工人的用例可以这么写修改主管尚未审批的单据. 
2007-7-13  16:03:41  Johnson:  主管的修改用例这么写,修改提交主管审批中的单据. 
2007-7-13  16:04:26  Johnson:  主管尚未审批的/提交主管审批中的都是单子状态. 
2007-7-13  16:04:49  Johnson:  就是带上单子的状态. 
2007-7-13  16:05:12  潘:  挺好 
2007-7-13  16:06:09  Johnson:  我看了你以前讲课的幻灯片.中 
2007-7-13  16:06:16  Johnson:  有类似的情况. 
2007-7-13  16:06:45  Johnson:  就是几个User 共用了一个查看缺陷的用例. 
2007-7-13  16:07:16  Johnson:  看到那上面分成了多个用例,用例上面带了还有状态的 
2007-7-13  16:07:16  潘:  左边是错的,右边是对的 
2007-7-13  16:07:22  Johnson:  对 . 
2007-7-13  16:07:58  Johnson:  如果不分类,按照他那样写法就是一个用例有多个主执行者了. 
2007-7-13  16:08:00  Johnson:  这个是错的 
2007-7-13  16:08:38  Johnson:  如果多个用户看似共享了一个用例. 
2007-7-13  16:09:13  Johnson:  我觉得一般要么是是用用例泛化,指向用例. 
2007-7-13  16:09:30  Johnson:  要么就是每个用户一个用例. 
2007-7-13  16:10:14  Johnson:  用例名字差不多,也就是用例名称中带有分类的提示 
2007-7-13  16:11:14  潘:  一般要么是是用用例泛化,指向用例. --执行者泛化