【转载】OO系统分析员之路--用例分析系列（2）--用例的类型与粒度

txish

2 用例的类型与粒度
2.1 用例的类型

     在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，
这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握
的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
先说说用例类型的问题。
      用例类型，有的资料翻译为版型，英文原文是stereotype。在Rose中默认
的类型有business usecase , business usecase realization和use case
realization三种。相应的，就是指

业务用例：

业务用例实现：




用例实现：

若不指定类型，则它就是通常意义上的use case ：

      Rose中定义了上述默认类型，但是也可以自定义用例类型。初学用UML建
模的人常常在这些类型中迷失，搞不清楚这些类型是什么含义，什么时候该使用
什么类型。简单说，需求分析中的各个阶段要描述和分析的目标不同，为表达不
同的视角和分析目标，需要使用不同的用例类型。笔者的观点是，用例类型的区
分是为了形式上的统一，但用例类型既然可以自定义，它就是一个很灵活的用法，
不必墨守成规，大可在工作中根据实际情况定义适合自己项目特点和软件过程的
用例类型。不过，默认的用例类型已经几乎可以满足需求分析的各个阶段，自定
义的必要性并不大，并且UML的意义就是使用统一的形式描述需求，因此最好使
用默认的类型。
      说到需求分析阶段，那么需求分析都有些什么阶段呢？一般来说，需求分析
要经过业务建模，用例分析和系统建模三个阶段才能完成需求工作，这三个阶段
分别做什么笔者会在以后的文章的详细阐述，这里为了说明用例类型的含义和使
用，先简单介绍一下。

     1、业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明
书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；

     2、用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又
称为概念模型阶段。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，
但笔者认为其非常重要，业务架构通常在这个阶段产生。

     3、系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常
使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构通常在
这个阶段形成雏形（在系统分析阶段确定）。

     所谓business usecase，是用来描述用户原始需求的，它的含义是站在用
户的角度，使用用户的业务术语来描述用户在其业务领域所做的事情。业务用例
命名，描述都必须采用纯业务语言，而不能出现计算机术语。因为业务模型是系
统分析员与用户讨论需求，达到一致理解的基础，必须使用用户熟悉的，不会有
歧义的专业术语以避免系统分析员与用户对同一事件的理解误差。business
usecase realization是达到需求可追溯要求的一个连接点，是用户在其业务场
景中如何做这一件事的载体。
     笔者自己在用例分析和系统建模阶段不区分用例类型，都使用无类型的use
case，但在这两个阶段，用例的含义还是有所差别的。用例分析阶段，用例主要
是从业务模拟的概念上，从OO的视角来分解、组合业务用例，粗略的建立一个
业务架构。而在系统建模阶段，用例主要是从计算机视角描述需求，规定开发范
围，作为项目计划的依据，为系统设计做准备。usecase realization的含义可
从business usecase realization推知。

2.2 用例的粒度

      粒度是令人迷惑的。比如在ATM取钱的场景中，取钱，读卡，验证账号，打
印回执单等都是可能的用例，显然，取钱包含了后续的其它用例，取钱粒度更大
一些，其它用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小
用例合适呢？这个问题并没有一个标准的规则，笔者可以给大家分享的经验是根
据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说
明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于
明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到
验证密码，填写申请单，查找书目等业务中的一个步骤。在用例分析阶段，用例
的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项
完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽
象业务用例中的概念模型。例如，宽带业务需求中有申请报装，申请迁移地址用
例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个
业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，
因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例
如，填写申请单，审核申请单，派发任务单等。可理解为一个操作界面，或一个
页面流。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是
一个用例的开发工作量在一周左右为宜。
     上述的粒度划分方法笔者是用相对比较具体化的一些依据来说明。实际上，
用例粒度的划分依据（尤其是业务用例）最标准的方法是一个用例的粒度是否合
适，是以该用例是否完成了参与者的某个目的为依据的。这个说法比较笼统，也
比较难以掌握。，举个例子，某人去图书馆，查询了书目，出示了借书证，图书
管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段
话中能得出多少用例呢？请记住一点，用例分析是以参与者为中心的，因此用例
的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，
其它都只是完成这个目的过程——这里讨论的用例指的是业务用例——这个例
子是比较明显的能够区分出参与者完整目的的，在很多情况下可能并没有那么明
显，甚至会有冲突。读者可以从自己实际的情况去找出这种例子。以后的文章中
笔者会做一些讨论。
     但是上述的粒度选择并不是一个标准，只是在大多数情况下这样的粒度选择
是比较合适的。笔者的意思也不是告诉读者上述哪一种是最好的，而只是把一些
常用的比较，划分方法告诉读者，期望的是帮助读者在工作实践中自己总结出一
套适合自己的方法来。现实情况中，一个大型系统和一个很小的系统用例粒度选
择会有较大差异。这种差异是为了适应不同的需求范围。比如， 针对一个50人
年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至
几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用
例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小
一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需
求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于
10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。
      不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度
应该是同一个量级的。这应该很好理解，在描述一栋建筑时，我们总是把高度，
层数，单元数等合在一起介绍，而把下水道位置，插座数量等合在一起介绍。如
果你这样介绍一栋楼：这栋楼有10层，下水道在厨房东南角，预留了15个插座，
共有5个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。
如果对上面两个问题读者还有疑惑，不用着急，在以后的文章中应该会逐步
加深理解。


2.3 相关评论

Question：由 pushboy 发布
“在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。
即一个用例可以描述一项完整的业务流程。”
“在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例
能够描述操作者与计算机的一次完整交互为宜。”
那么，这样一个场景 —— 用户管理，有增删改查
这里，是把 用户管理 作为一个用例，还是把增删改查分别作为用例呢？
他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个
actor发起的动作；怎么来确认呢？
我们的前提是一个普通的比如说财务系统，而不是一个用户管理系统

Answer：这个问题很好，用例的粒度总是在这样左也可右也可之间难以决定。
对这个问题来说，我的观点是业务用例应当用“管理用户”或“维护用户”作为
合适的粒度，而增，删，改，查则在作为系统用例。我的理由是：
      增删改查不能做为一个完整的业务来理解。作为一个管理业务，数据只有先
增，才会有改，才会有删。增删改查结合起来才能完成actor的管理目的，只删
或只增加都不是业务的全部。这篇文章后来我又补充了一条粒度的判断标准，可
以到http://coffeewoo.itpub.net/去看，是否是一项完整业务，要看actor的
目标，而不是事情是否完整。这个例子中，actor的目标是为了增加一个用户吗？
是为了删除一个用户吗？都不是，而是为了管理用户，这个目标包括了用户这个
实体的整个生命周期。
      再讨论深一些，如果业务要求对用户除了增删改查，还有别的要求，例如权
限升级，用户在组织机构中复杂的关系变更，用户与外部系统的交互....实际的
情况可能会更多，那么，如果将每个都作为一个业务用例，很容易造成一个结果，
这些原本与用户这个实体紧密关联，共同组成用户实体生命周期的业务，被割裂
成多个独立的业务，因为定义了多个用例（请参看本人第一篇中的用例特征第一
条）。要知道，在RUP中，用例驱动的含义是，一个用例就是一个分析单元，设
计单元，开发单元，测试单元甚至部署单元。相信读者都知道，把紧密关联的业
务分成多个独立部分去实施是高成本的，高风险的。   
      另外，为什么我要说在系统用例阶段要把增，删，改，查又分出来呢？原因
在于，系统用例的目的是为了将actor的业务用计算机模拟出来。我们都知道，
一般情况下，增，删，改，查对一个actor来说是不会同时发生的，每次actor
只会完成其中的一个行为。分开来，有利于详细分析模拟这一行为的细节而不至
于混淆。另一方面，对WEB应用来说，针对数据的增，删，改，查等，很容易形
成所谓的“模板”，增加用户用这个模板，增加其它基础数据可能也用同一个模
板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可
以复用的。对这个例子来说，在系统用例阶段，我们可以用“管理用户” include
“增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等
等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在
“增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这
也是一种OO思想的体现。
     只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一
定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情
况，查询可以作为一个业务用例出现。
感谢网友pushboy 提出问题。原帖位于：
http://www.itpub.net/507773.html

coffeewoo 发表于:2006.03.03 23:48

Question：
      写得很好,您的观点是十分有效的.
     只是,在用例阶段,我觉得还是要将业务用例和系统用例的角色解释一下作
为补充.业务用例和系统用例的各个角色是不同的.
     业务用例方面角色应该有:业务角色业务员工
     系统用例方面角色应该有:业务角色
什么概念?业务用例的业务角色是指在企业外与企业交互的角色,业务员工
是指在企业内进行工作的角色.(因为业务用例仅仅是对企业内一个部门的业务
做一个粗略的用例)
      系统用例则没有业务员工,只有业务角色,业务角色是指对于整个系统来说
与系统交互的人或其他子系统(因为系统用例是对整个系统的工作进行描述,可
以看作是需求完成后系统的工作结果)
      其他完全同意作者的理论,我的补充也仅仅是一点补充

rwyx 评论于: 2006.09.28 15:54

Question：
      在业务用例模型中审核应该不是一个用例,但这要看你做用例的企业是不是
有一个部门是专门做审核的,如果有一个部门的工作可以用"审核XXX"来定义,那
就是一个用例.否则应该以该部门的主体工作来包含"审核"的动作.而到系统用
例模型时才去将审核作为一个单独用例

rwyx 评论于: 2006.09.28 15:58

Answer：
      关于业务用例和系统用例，您的观点是对的。业务阶段和系统阶段的角色定
义是不一样的，即使是业务阶段，也有business work 和business actor之分。
文章里我是有意忽略这种差别的。因为在实际工作中我觉得，搞那么多概念出来，
除非是很专业的UML人员，否则不会了解这种差异，更不用说客户了。需求文档
是要给客户看的，要给他们解释清楚business work 和business actor很难，
而这两者的虽然概念上不一样，但最后能映射到系统中的也就是角色。因此在实
际工作中，我不再区分它们，而是只使用角色一个概念。
关于审核的回答十分赞同您的意见。

coffeewoo 评论于: 2006.09.28 18:24

Question：
       提个关于过程控制的软件需求分析问题，对于业务管理者来说（一般是中层
们），他们也是系统的用户，但他们参与系统的主要方式是对中层之下用户操作
业务的结果进行查询分析，这样这些查询久的定义成用例。可这些查询用例之间
或是和其他用例之间又没有什么交互，那我是不是需要把每个这样的查询用例当
成一个单独的业务来绘制业务场景图，或是把这些查询弄成一个综合查询业务，
但那样泳道好像太多，没有实际意义。疑惑。

boskin 评论于: 2006.12.18 11:03

Answer：
      MIS系统中唯一一个比较特殊的就是查询了。我在房屋中介实例分析那一篇
中讨论过一部分。
      对于查询这种用例，最特殊的地方就是actor目标是不明确的，查询的目的
可以做很多事情。查询完了只看一看，或者删除一部分，或者打印出来，或者...
目的是很多的。显然如果按目的来分，就会有非常多的查询XX用例。对于查询，
我的建议是将其作为正常用例的extend。例如管理用户用例，要删除一个用例，
显然应当先查询出来才能删除，所以这时查询用户只是管理用户用例的一个
extend。而扩展出来的用例是不单独视为一个用例的，换句话说可以不为它单独分析。
另一方面，查询，除非特殊要求的，否则查询的过程都是一模一样的，输入
条件，点查询，出结果。无非是查询的目标不同。所以即便要为查询专门分析，
例如综合 查询，其重点也不在业务场景图上，而在查询用例所使用到的那些业
务实体。UML在说明功能性需求上是方便的，但在说明这种以数据为中心的内容
上是不擅长 的，什么条件出什么结果应当放在用例规约中去，以文字和表格说
明为好。
coffeewoo 评论于: 2006.12.21 21:56

废话大仙

赞助一个顶

txish

谢谢大仙捧场。

流星

呵呵，找个机会...  

cherie

#无语  

流星

呵呵，找个机会...  

anything

呵呵,明白了  

hasee

谢谢分享  

流星

自从顶贴后，机不死了，网速快了，电池也耐用了，流量也无限了。  

anything

自己知道了