用例的粒度

粒度给我感觉就是抽象层次

在业务建模阶段 用例的粒度以每个用例能都说明一件完整的事情为宜 即一个用例可以描述一项完整业务的流程 这将有助于明确需求范围

在用例分析阶段 用例的粒度以每一个用例能描述一个完整的事件流为宜 例如提供申请资料,受理业务,现场安装等多个业务流程

在系统建模阶段 用例视角是针对计算机的 因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜 例如 填写申请单,审核申请单,派发任务单等

用例分析是以参与者为中心 因此用例的粒度以能完成参与者的为依据

举例子

某人去了图书馆 查询了书目 出示了借书证 图书管理员查询了该人以前的借书记录 以确保没有未归还的书 最后借道了书 这句话里有几个用例

实际上只有一个用例 就是借书 其他都是为了完成这个借书目的

大项目 如果粒度过于小 那么需求太碎而无法控制 小项目如果太大  可能引发需求太模糊而容易忽略细节

粒度应该在同一粒度  在一个量级 比如在描述一栋建筑的时候 我们总把高度 层数  单元数等结合在一起介绍 而把下水道 插座数为一个量级

用例粒度的误区

粒度的误区首先分不清目标和步骤 分不清目标和步骤 后果就是粒度过于细小 

粒度的另一个误区是需求阶段粒度大小不一 这个问题本质上是因为建模者心目中没有一个清楚的边界

thinking in uml 大象 用例的粒度_业务流程

修改订单就是一个错误的粒度 

因为修改订单是服务于购买商品这个用例  那么修改订单显得格格不入 它并不是一个完整的目标  就比如 介绍一个楼的时候说着开发商信息的时候  突然说每个房间有几个插座 不再一个层次上