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  潘：  一般要么是是用用例泛化,指向用例. －－执行者泛化