2006-11-9 9:29:54 德红： 1、要不要写业务用例？ 这个问题很矛盾，原来是没有写业务用例的，直接写系统用例，然后其他人员对业务的来龙去脉不是很理解，看系统用例有点累，后来又去补业务用例，又发现业务用例和系统用例差不多？ 所以不知道应该怎么写业务用例？
2006-11-9 9:30:24 潘： 业务用例和系统用例差不多－－不可能
2006-11-9 9:30:40 潘： 业务用例是描述业务目标，理出需求。所以，是非常有用的。
2006-11-9 9:30:54 德红： 但写出来的东西是差不多的
2006-11-9 9:31:00 潘： 你举一个具体的例子
2006-11-9 9:32:36 德红： 比如新建病人档案的UC，系统UC 和业务UC 的文档写的内容都是涉众利益、前置条件、主事件流、扩展事件流等等这样的内容
2006-11-9 9:33:19 潘： 业务用例的研究对象是"业务组织"，系统用例的研究对象是"待开发系统"
2006-11-9 9:33:33 潘： "新建病人档案"是一个系统用例
2006-11-9 9:34:08 潘： 你要描述用例，要先说清楚：研究对象是什么
2006-11-9 9:34:12 德红： 那业务UC 是什么呢？您能给我一个例子吗？
2006-11-9 9:34:24 潘： 研究对象是什么？
2006-11-9 9:35:02 潘： 你现在假设系统有一个"新建病人档案"的用例，但是你这个需求对不对呢？根据在哪里？
2006-11-9 9:35:16 德红： 就是您原来做过的项目里一个比较有代表性的例子，分别描述UC 业务和系统UC的
2006-11-9 9:35:17 潘： 就要从业务用例和愿景来寻找
2006-11-9 9:35:32 潘： 你要开发的系统是什么？
2006-11-9 9:35:44 潘： "新建病人档案"是什么系统的用例？
2006-11-9 9:36:02 德红： 医院挂号系统的
2006-11-9 9:36:32 潘： 好，系统指"医院挂号系统"，这是一个独立的项目是吧
2006-11-9 9:36:59 德红： 是的
2006-11-9 9:37:47 潘： 那么，为什么要开发"医院挂号系统"呢，到底要改善/能改善那个业务单元的工作？
挂号室？门诊？医院？
2006-11-9 9:38:05 德红： 我把系统UC 传给您看看
2006-11-9 9:38:14 潘： 现在不是看这个的时候
2006-11-9 9:38:31 潘： 你要先搞清楚业务用例的意思
2006-11-9 9:39:38 德红： 我听了您两次课，概念大概都知道，可没有具体写过，您能传个例子看看吗？
2006-11-9 9:39:46 潘： ，为什么要开发"医院挂号系统"呢，到底要改善/能改善那个业务单元的工作？挂号室？门诊？医院？
2006-11-9 9:40:26 潘： 你这是一个系统用例，先不谈这个问题
2006-11-9 9:40:57 潘： 假设选择"挂号室"作为研究对象
2006-11-9 9:41:02 德红： 为了提高挂号室的挂号效率
2006-11-9 9:41:23 潘： 那么，业务执行者"病人"，业务用例"挂号"
2006-11-9 9:41:56 潘： 业务建模的目的就是描述没有你这个系统的时候，挂号的流程，并寻找改进点
2006-11-9 9:42:01 德红： 是的
2006-11-9 9:42:22 德红： 我知道这个概念，但具体怎么描述呢？
2006-11-9 9:42:28 潘： 例如：你假设系统的用例是："挂号员-建立病人档案"
2006-11-9 9:42:35 潘： 凭什么呀
2006-11-9 9:43:03 潘： 为什么不是，"病人->网络挂号，病人－自助挂号"？
2006-11-9 9:43:44 德红： 那当然是要考虑目前的环境了，条件不成熟
2006-11-9 9:44:32 UMLChina 潘加宇答疑专用 发送 model050521.rar
2006-11-9 9:45:44 UMLChina 潘加宇答疑专用 发送对象技术在业务建模中的应用.pdf
2006-11-9 9:46:54 德红： ucdescription.doc 这个文档中描述的是一个系统用例啊？
2006-11-9 9:47:09 潘： 看模型
2006-11-9 9:47:15 潘： 业务用例不用写文档
2006-11-9 9:47:29 潘： 这就是那次你上课讨论的项目啊
2006-11-9 9:48:45 德红： 哦，记起来了，但业务用例您建议怎么描述呢？
2006-11-9 9:49:14 潘： 我的幻灯，还有模型你回去有没有复习啊
2006-11-9 9:51:50 德红： 呵呵，有一段时间没有温习了，准备下去好好做功课
2006-11-9 9:51:58 潘： 再看看
2006-11-9 9:52:45 德红： 还有一个问题也比较麻烦：系统用例文档直接给开发人员看吗？如果给开发人员看的话，不够详细怎么办？是否需要规格说明书？？ 我们原来写了系统用例文档，但是光是系统用例文档，开发人员好像很难理解，不够详细，非要把界面、按钮都列出来，开发人员才能理解，有没有必要写一个包含界面、按钮、业务处理逻辑的文档？
2006-11-9 9:53:52 潘： 是的
2006-11-9 9:54:23 潘： 设计人员必须按照系统用例文档分析设计
2006-11-9 9:54:48 德红： 需要写一个包含界面、按钮、业务处理逻辑的文档？
2006-11-9 9:55:02 潘： 你发过来的已经很丰富了，怎么还做不下去？
2006-11-9 9:55:09 潘： 不需要
2006-11-9 9:55:13 德红： 测试人员看系统用例文档也不是很理解
2006-11-9 9:55:22 潘： 这是设计人员的事情，需求人员没有资格做这个
2006-11-9 9:56:03 潘： 需求只反应涉众要什么，不反应开发人员怎么去做
2006-11-9 9:56:28 潘： 你想想，如果开发人员用汇编，岂不是你的需求要写成汇编语言
2006-11-9 9:56:51 德红： 那可能是人员在理解、在沟通上出现了问题，说明大家对用例文档没有形成一致的思想
2006-11-9 9:57:12 潘： 界面、按钮不用画，但背后隐含的需求才是关键的
2006-11-9 9:57:45 潘： 例如：鼠标活动区域，键盘敲击次数，这些是非功能需求，要从涉众那里捕获
2006-11-9 9:58:43 德红： 哦，是在涉众利益那里进行描述的
2006-11-9 10:00:03 潘： 需求和涉众利益不同，需求是要可验证和度量的，而且是涉众利益的交锋结果
2006-11-9 10:00:49 潘： 例如：买卖东西。买方出10 元，卖方要1000 元，这都是涉众利益。
2006-11-9 10:01:03 德红： 哦，有点理解
2006-11-9 10:01:11 潘： 但最后成交价就一个：300 元。这就是需求规格说明书
2006-11-9 10:01:41 德红： 哦
2006-11-9 10:02:06 德红： 您觉得我们的系统UC 文档有什么问题吗？
2006-11-9 10:02:06 潘： 涉众利益说我要一次操作就完成挂号
2006-11-9 10:02:33 潘： 需求可能做不到，只能尽量照顾，同时还要考虑数据完整，真实，开发成本。。。
2006-11-9 10:09:50 德红： 还有一个问题麻烦您：一个系统整体的流程怎么描述？用流程图还是用例图？如何把一个个的用例串起来？ 现在每个系统UC 都是独立的，没有一种好的方式把整个系统的UC 串联起来？怎样让别人一眼就能看到一个系统的整体概况？？
2006-11-9 10:11:23 德红： 现在缺少一个整体的概念
2006-11-9 10:11:27 德红： 我们写了很多UC，但是每个UC 之间好像都是独立的，一个不是很懂业务的人来看这些UC，他就很茫然，不知道怎么来组织这些UC，是不是要用其他的方式进行描述？
2006-11-9 10:19:37 潘： 看我刚发的文章
2006-11-9 10:22:46 德红： 难道在业务建模阶段就要画这些类图、序列图吗？
2006-11-9 10:22:56 潘： 是
2006-11-9 10:23:06 潘： 业务建模就是指这个
2006-11-9 10:23:23 潘： 或者活动图代替
2006-11-9 10:24:01 德红： 那这个和业务UC，系统UC 有什么关联吗？
2006-11-9 10:24:18 潘： 你先看我的文章
2006-11-9 10:24:24 潘： 还有幻灯片
2006-11-9 10:24:32 潘： 上面都写的很清楚啊
2006-11-9 10:28:01 德红： 好的，我马上温习一下，您能给我一个小型项目的实例吗？比较完整的，包括业务建模、业务用例、系统用例等等方面的
2006-11-9 10:28:46 潘： 刚才发给你了，你能做到这样就可以了 |