2007-6-1 14:14:26 wjun555： 在我业务建模时，对于一个用，例如：部门员工维护设备。那么这个用例的业务执行者是业务工人。 1.这个用例能在业务用例里体现吗？如果是，那么业务工人不是就变成研究对象外的执行者了？ 2.如果这个用例只能在系统用例里体现，那么在做业务建模时不是缺少了这个用例表述了吗？ 3.这个用例很重要，不能缺少，那么在哪个阶段出现更合适呢？
2007-6-1 14:14:44 潘： 要说用例，你要先说研究对象是什么
2007-6-1 14:15:01 潘： 你是在做业务建模还是做需求呢
2007-6-1 14:15:36 wjun555： 做需求
2007-6-1 14:16:05 潘： 做需求，那么研究对象就是"待开发系统"
2007-6-1 14:16:48 wjun555： 业务单元是某部门
2007-6-1 14:17:01 潘： 系统外的人，机器，只要和系统交互的，都是系统执行者。业务工人之类的概念是业务建模的时候用的，研究对象是业务组织，工人在组织内部。
2007-6-1 14:17:17 wjun555： 不好意思，我们这边都是涉密系统，只能举例了
2007-6-1 14:17:40 潘： 还记得我们课上说的"这个系统的业务用例是什么"这个问题吗
2007-6-1 14:18:15 wjun555： 我现在要做需求，但是我想从业务建模做起，这样可以直接推出系统用例
2007-6-1 14:18:58 潘： 那么你现在要研究的是"某个业务组织"的用例了？
2007-6-1 14:19:06 wjun555： 对
2007-6-1 14:19:20 wjun555： 但是现在执行者是组织内部员工
2007-6-1 14:19:48 潘： 那么，你的这个"某个业务组织"是什么呢
2007-6-1 14:20:03 潘： 但是现在执行者是组织内部员工－－你又开始糊涂了
2007-6-1 14:20:23 wjun555： 对
2007-6-1 14:20:23 潘： 你现在要研究的是"某个业务组织"的用例了？
2007-6-1 14:20:47 wjun555： 我明白您的意思
2007-6-1 14:21:12 wjun555： 就是说要跳出某部门的概念，缩小范围到某个组织？
2007-6-1 14:21:17 wjun555： 是这个意思吗？
2007-6-1 14:21:23 潘： 无所谓啊
2007-6-1 14:21:36 潘： 关键是你的研究对象要清楚就行
2007-6-1 14:22:02 潘： 一个部门也行，一个公司也行，一个集团公司也行，整个中国也行
2007-6-1 14:22:07 wjun555： 呵呵。。。。
2007-6-1 14:22:10 潘： 但你首先要说清楚啊
2007-6-1 14:22:47 wjun555： 我明白了，我太拘泥于形式了。觉得一个范围定下，就只能对这个框框建模
2007-6-1 14:22:50 wjun555： 呵呵。。。。
2007-6-1 14:23:49 潘： 我们那个课上的器材例子模型已经说得挺清楚的，再好好看看
2007-6-1 14:24:17 wjun555： 呵呵。。。
2007-6-1 14:24:37 wjun555： 被那个框框邦住了
2007-6-1 14:24:49 wjun555： 那个框框是可以变的我到忘记了
2007-6-1 14:24:56 潘： 把图打印出来的比较一下各图之间联系即可
2007-6-1 14:25:11 wjun555： 恩
2007-6-1 14:25:18 wjun555： 哦，还有一个问题
2007-6-1 14:25:29 潘： 请说
2007-6-1 14:25:54 wjun555： 就是在系统建模时，按照步骤是先有系统用例
2007-6-1 14:26:01 wjun555： 然后有用例文档
2007-6-1 14:26:18 wjun555： 通过用例文档画出序列图
2007-6-1 14:26:31 wjun555： 这个过程是这样的吧？
2007-6-1 14:27:46 潘： *愿景 0 业务建模 0.1 选择业务单元 0.2 业务执行者 0.3 业务用例 0.4 详细描述
业务用例（业务序列图） 1 需求 1.1 把待开发新系统放到业务序列图，结合愿景，寻找改进点 1.2 把新系统的责
任映射到系统用例图 1.3 书写用例文档 2.分析（结构） 2.1 识别类和属性 2.2 识别泛化 2.3 识别关联 3.分析（行
为） 3.1 结合用例文档和类图，通过画序列图，把用例文档中的责任分配到类中 4. 设计 4.1 从头建立数据层 4.2
精化业务层 4.3 精化表示层
2007-6-1 14:28:44 wjun555： 恩
2007-6-1 14:29:11 wjun555： 我是按这个步骤来走，不过总想先画序列图，然后根据序列图出用例文档
2007-6-1 14:29:59 潘： 问题是：什么序列图
2007-6-1 14:30:24 潘： 有两个地方要画序列图，业务用例的序列图，系统用例的序列图
2007-6-1 14:30:34 wjun555： 恩
2007-6-1 14:30:49 潘： 序列图述用例的"实现"，不可能先有序列图才有用例
2007-6-1 14:31:13 wjun555： 但是业务用例往往是概念上很大
2007-6-1 14:31:18 潘： 除非你把序列图不当作"实现"
2007-6-1 14:31:21 wjun555： 包括的业务用例很多
2007-6-1 14:31:32 wjun555： 包括系统用例很多
2007-6-1 14:31:35 wjun555： 打错
2007-6-1 14:32:36 潘： 然后呢
2007-6-1 14:33:51 wjun555： 就是在业务用例里，每个指向系统的箭头都可以导出一个系统用例
2007-6-1 14:34:17 wjun555： 但是每个系统用例又有它自己的操作步骤
2007-6-1 14:34:54 潘： 对呀，这有什么问题呢
2007-6-1 14:35:21 wjun555： 但是，用例文档是对系统用例的步骤描述呀
2007-6-1 14:36:04 wjun555： 这样，通过画出系统用例图可以直接表述这个过程呀
2007-6-1 14:36:24 wjun555： 我觉得这样地方可能有什么概念我每明白
2007-6-1 14:36:34 wjun555： 所以想问一下
2007-6-1 14:36:46 潘： 通过画出系统用例图可以直接表述这个过程呀?--通过画出系统序列图可以直接表述这个过程呀？
2007-6-1 14:38:14 wjun555： 因为系统用例的序列图基本上是分析设计的基础了
2007-6-1 14:38:27 wjun555： 有界面UI 这样的对象出现
2007-6-1 14:39:07 wjun555： 这样的图就可以直接表述用例文档的步骤描述了
2007-6-1 14:39:28 wjun555： 那画图做不是更方便吗
2007-6-1 14:39:34 潘： 那么为什么不直接用代码来表达用例文档的步骤描述呢？
2007-6-1 14:39:53 wjun555： 呵呵。。。。
2007-6-1 14:40:13 潘： 只有一个原因：因为那些需求（问题），而是设计（解决方案）
2007-6-1 14:40:33 潘： 1. 业务人员提交借用单 2. 系统验证借用单合法 3. 系统保存借用单 4. 系统提示保存成功，通知不是填单人的借用人
2007-6-1 14:40:40 潘： *1-4 应在1 秒内完成 *支持100 人同时填写借用单
2007-6-1 14:40:47 潘： 这是需求
2007-6-1 14:41:35 潘： 里面没有假设系统如何构造，更没有假设系统是用面向对象方法构造，也没有假设有什么类
2007-6-1 14:41:45 wjun555： 可能是我不太喜欢写文字吧
2007-6-1 14:41:55 wjun555： 所以希望可以偷懒，呵呵。。。。
2007-6-1 14:42:02 潘： 不喜欢也得写，要习惯说人话
2007-6-1 14:42:24 wjun555： 有点明白，但是还需要琢磨一下
2007-6-1 14:42:34 潘： 因为你的系统要满足涉众的要求，不是说代码运行稳定有个东西用就行
2007-6-1 14:43:03 wjun555： 需求跟设计，这个在以前做的时候都是没有边界的
2007-6-1 14:43:14 潘： 需求是涉众能够理解和验证的东西，你要把这个和其他的东西分开
2007-6-1 14:43:24 wjun555： 不过现在有契约的概念，这个还需要领悟一下
2007-6-1 14:44:06 wjun555： 喜欢您的侦探似的追问方式，呵呵。。。。
2007-6-1 14:44:10 潘： 偷懒可以不画类图和系统序列图，直接投入编码这个倒是小问题，因为它们都是解决方案的一部分
2007-6-1 14:44:11 wjun555： 在努力学习中
2007-6-1 14:44:34 潘： 但不能够把涉众的"问题"和你的"解决方案"混在一起 |